Traffic Shaping
Traffic shaping delays/queues packets to hit a target rate; policing drops or remarks excess traffic instantly, with no buffer. Linux shapes via tc (iproute2, latest release v7.1.0, June 2026) using the HTB qdisc: rate is the guaranteed CIR, ceil the max rate a class can borrow from idle siblings, burst/cburst (bytes) size the token bucket, and quantum defaults to rate/r2q (r2q default 10, quantum clamped 1000-200000 bytes). Cisco IOS/IOS XE 17.x split the two: shape average buffers and is outbound-only, police applies inbound or outbound and drops rather than queues. Cloud LBs use token buckets too: AWS WAF rate-based rules default to per-source-IP aggregation over 60/120/300/600s windows checked ~every 10s, capping blocked IPs at 10,000/rule; Envoy's local_ratelimit bucket is per-instance, so N replicas at X req/s = N*X req/s cluster-wide unless global limiting is used.
Pick tc/HTB when you own the Linux box doing the routing — a home gateway, a hypervisor host metering tenant VMs, an ISP edge box — and need free, kernel-level, per-class bandwidth control with borrowing. Do NOT reach for HTB to rate-limit an HTTP API; that's an L2/L3 packet queue, not a request counter. Use NGINX limit_req or a cloud LB's rate-based rule (AWS WAF, Envoy local_ratelimit) instead — they think in requests/sec per key, not bytes/sec per interface. Honest weakness, straight from the LARTC mailing list: r2q/quantum defaults are wrong often enough that "quantum of class X is big/small, consider r2q change" is one of the most common HTB kernel warnings there is, and shaping only ever controls egress — you can't shape what already arrived. Known weakness: HTB's default r2q=10 miscalculates quantum for many real-world rate/MTU combos, producing the notorious "quantum of class X is big/small, consider r2q change" kernel warning and uneven inter-class scheduling until manually overridden.