Consider below scenario for 20 Mbps shaper and 1500 burst size.
On a shaped WAN access circuit, setting the Class-of-Service (CoS) shaper burst-size to a single MTU (1500 bytes) while the shaping rate was 20 Mbps caused the Network-Control (NC) forwarding-class queue to back up to its depth limit (Qlen 64) and tail-drop traffic. Because SLA monitoring probes ride that queue and a path is declared Down after three consecutive lost probes, the NC SLA flapped and the branch-to-controller data path effectively blackholed — even though the link was almost idle. The shaping rate was never the problem; the burst-size (token-bucket depth) was too shallow to absorb normal packet bursts. Raising burst-size from 1500 to 15000 bytes resolved it immediately.
1. Symptom
- Per-class SLA to the controller (NC/fc_nc) reports 100% loss / path Down; the path flaps.
- Higher-volume classes (EF/BE) look "clean"; only the sparse NC probe visibly fails.
show class-of-services interfaces extensiveshows the affected queue with a non-zero Qlen and TX Dropped incrementing, while the interface's aggregate TX rate is far below the configured rate.
2. What burst-size is in CoS
A shaper is a token bucket, defined by two independent parameters:
- Rate (CIR) — how fast tokens (credit to transmit) are added to the bucket. This sets the long-term average throughput.
- Burst-size (CBS, Committed Burst Size) — the maximum number of bytes the bucket can hold, i.e. how many bytes may be transmitted back-to-back in one instant before the shaper must pause and wait for tokens to refill.
Rate and burst are decoupled. Rate controls the average; burst controls the instantaneous allowance. A correct rate with an undersized burst still breaks, because real traffic does not arrive smoothly paced to the token drip — it arrives in bursts (the data path batches packets through encapsulation/encryption, and NICs deliver frames back-to-back at line rate). The bucket must be deep enough to absorb those bursts.
3. How to size burst-size (industry standard)
Burst-size should represent a time window of the shaped rate, not a fixed byte count and never a single packet. The standard formula:
burst_bytes = rate_bps / 8 * Tc_secondswhere Tc is the committed burst interval. Common industry guidance (e.g. Cisco Bc = CIR/8 * Tc) uses Tc in the 8–25 ms range, with a hard floor of several MTUs.
Worked reference at 20 Mbps (2,500 bytes/ms of refill):
| Burst-size | Time-equivalent | Result |
|---|---|---|
| 1,500 B | 0.6 ms (≈ 1 MTU) | Pathological — one packet of credit |
| 15,000 B | 6 ms | Healthy (the applied fix) |
| 25,000 B | 10 ms | Recommended target |
| 62,500 B | 25 ms | Conservative upper end |
4. What happens when burst-size is set too low
An undersized bucket cannot release incoming bursts. The failure develops in stages:
- A batch of packets arrives back-to-back.
- The shaper transmits packets until the bucket empties (with 1500 B, that is essentially the first packet only).
- Remaining packets in the batch have no tokens, so they are held in the class queue — this is a delay, not yet a drop. Qlen rises.
- Tokens refill slowly (0.6 ms per packet at 20 Mbps), so the queue drains slower than bursts arrive. Qlen climbs toward the queue's depth limit.
- Once Qlen hits the configured limit, the next arrival has nowhere to go and is tail-dropped. TX Dropped increments.
The result is throughput suppression plus latency plus tail-drop while the link is nearly idle — the classic signature of burst starvation rather than congestion.
5. Resolution:
Increase the shaper burst-size to a proper time-based value:
class-of-service {
networks {
INT-WAN {
shaping-rate {
rate 20000; # kbps (unchanged)
burst-size 15000; # bytes (was 1500) — ~6 ms of credit
}
scheduler-map INTF-SCHED;
}
}
}
After the change, the affected queue returned to Qlen 0 with zero drops, and the NC SLA recovered immediately.