traffic control

Pre-Alpha. This page describes behavior that may change.

Ze programs per-interface queueing disciplines, classes, and filters from a single traffic-control { } YANG section. The same config is consumed by two backends; the operator chooses one via the backend leaf.

Backends

Backend	Platform	Default	Mechanism
tc	Linux	yes	vishvananda/netlink tc calls (HTB, HFSC, FQ, TBF, netem, ...)
vpp	Linux with VPP	no	GoVPP binary API (policers, QoS egress maps)

Configuration

traffic-control {
    backend tc;
    interface eth0 {
        qdisc {
            type htb;
            class fast {
                rate 10mbit;
                ceil 20mbit;
            }
        }
    }
}

VPP backend compatibility

The VPP backend rejects qdisc and filter types that cannot be represented faithfully in VPP. Rejection fires at ze config commit with a descriptive error.

qdisc type	vpp	Notes
htb with exactly 1 class	accepted	One policer: CIR = Rate kbps, EIR = Ceil kbps (2R3C RFC 2698).
tbf with exactly 1 class	accepted	One policer: CIR = EIR = Rate kbps (1R2C).
htb / tbf with 0 or >1 classes	rejected	Multi-class shaping needs filter-based classification (deferred).
prio	rejected	Class-index to DSCP-value mapping needs explicit design.
hfsc, fq, sfq, fq_codel, netem	rejected	No VPP equivalent.

All filter types are currently rejected under the VPP backend.

Operational notes

• VPP must be running when traffic-control config applies. If VPP is not reachable, Apply waits up to 5 seconds and then fails the commit.
• Rates round up. Ze uses bps internally; VPP uses kbps.
• Interface must exist in VPP. Unknown interface names fail the apply.

See also

• Firewall for stateful packet filtering.
• VPP for the VPP data plane story.
• In-tree traffic control guide for the full reference.

Adapted from main/docs/guide/traffic-control.md.