TTR Networks

Intermediate · Traffic shaping with CAKE on Debian · section 3 of 8

Uploads: CAKE on the WAN

✓ Lab-tested 5 November 2026 on Debian 13.7 (kernel 6.12, in a QEMU VM), iproute2 6.15.0, systemd 257, iperf3 3.18

To take control of the queue, the router must become the slowest point: send just under the line's real speed, so packets never pile up in the modem. CAKE does it in one line:

tc qdisc replace dev ens4 root cake bandwidth 4500kbit

That replaces the WAN interface's queueing discipline with CAKE, shaping to 4.5 Mbit/s, 90% of the 5 Mbit/s line. With the same upload running, the average ping drops from 713 ms to 2.2 ms. The upload still gets 4.25 Mbit/s: about 11% less throughput, for a line that's usable again by everyone else.

What CAKE shows you

tc -s qdisc show dev ens4 gives its statistics:

  • Dropped packets: CAKE's AQM drops (or ECN-marks) a few packets from the bulk flows as soon as their queue starts growing, which tells TCP to slow down before the delay builds up. Those 220 drops are what kept the ping fast.
  • Tins: by default (diffserv3), CAKE keeps three priority classes, Bulk, Best Effort and Voice, chosen from each packet's DSCP marking. Traffic marked for voice gets a guaranteed share and low delay; traffic marked as background yields to everything else. Unmarked traffic is Best Effort.
  • The defaults shown in the first line: triple-isolate fairness, nonat, a 100 ms RTT assumption, and raw overhead (no link-layer overhead added; see Tuning).

How much bandwidth to give it

Too high, and the queue moves back into the modem; too low, and you throw away speed. Measure the line's real throughput (several times, at a quiet moment), and start at 85–95% of it. If latency under load is still high, lower it; if it's flat, try raising it in small steps.

CAKE on the WAN interface (real output)
root@gw:~# tc qdisc replace dev ens4 root cake bandwidth 4500kbit && tc qdisc show dev ens4
qdisc cake 8001: root refcnt 2 bandwidth 4500Kbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0 

root@client:~# iperf3 -c 198.51.100.10 -t 20 > /tmp/up.txt & sleep 3; ping -q -c 75 -i 0.2 198.51.100.10 | tail -2; wait; grep receiver /tmp/up.txt
75 packets transmitted, 75 received, 0% packet loss, time 14930ms
rtt min/avg/max/mdev = 0.386/2.212/3.894/0.920 ms
[  5]   0.00-20.01  sec  10.1 MBytes  4.25 Mbits/sec                  receiver

root@gw:~# tc -s qdisc show dev ens4 | head -12
qdisc cake 8001: root refcnt 2 bandwidth 4500Kbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0 
 Sent 11233958 bytes 7508 pkt (dropped 220, overlimits 19482 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 36120b of 4Mb
 capacity estimate: 4500Kbit
 min/max network layer size:           66 /    1514
 min/max overhead-adjusted size:       66 /    1514
 average network hdr offset:           14

                   Bulk  Best Effort        Voice
  thresh      281248bit     4500Kbit     1125Kbit
  target         64.6ms          5ms       16.1ms
  • Lines 1–2: One command. The defaults: three DiffServ tins, triple-isolate fairness, no NAT lookups, raw overhead.
  • Lines 4–7: The same upload: 2.2 ms average ping, at 4.25 Mbit/s.
  • Lines 10–11: 220 packets dropped: the AQM telling the upload to slow down before a queue builds.
  • Lines 19–21: The three tins and their shares of the bandwidth.

Check your understanding

Why shape to 4.5 Mbit/s on a 5 Mbit/s line, instead of 5?

  • So the router, not the modem, is the slowest point, and the queue forms where CAKE can manage it.
  • Because CAKE can't go above 90%.
  • To leave room for other routers.
  • Because the line's speed varies by exactly 10%.