Lab 07-04 · Burst: fast for a few seconds, limited after¶

Open a web page on a limited connection and you notice it: every click feels sluggish. But a web page is small. If the router let you go much faster for just a couple of seconds, the page would appear instantly, and a big download (which runs for minutes) would still be held at the normal limit. Mobile operators and ISPs use exactly this trick to make cheap plans feel fast.

That trick is called burst. Today you add it to the laptop's queue from Lab 07-01, then measure, second by second, when the router opens the gate and when it closes it again.

The idea: a green wave for short trips¶

A burst lets a queue go above its max-limit, up to a burst-limit, for as long as the client's average speed over the last burst-time seconds stays below the burst-threshold.

Back to the motorway. Your normal speed limit is low. But the road has a "green wave": if you have not been driving much lately, the gates open wide and you can sprint. Once your recent average gets too high, the gates close and you are back to the normal limit. Short trips (web pages) are all sprint; long trips (downloads) are mostly normal speed.

How long does the burst last?¶

Starting from idle (average = 0), the client sprints at the burst-limit. The average over the last 16 seconds climbs, and the burst stops when it reaches the threshold:

burst duration ≈ burst-threshold × burst-time ÷ burst-limit
               ≈ 512k × 16 s ÷ 1M  ≈  8 seconds

In 8 seconds at 1 Mbps the client moves about 8 Mbit = 1 MB, so a web page of a few hundred kilobytes arrives entirely inside the burst. A 2 MiB file does not.

flowchart LR
    A["<b>Idle</b><br>average = 0"] -- "client starts<br>downloading" --> B["<b>Burst on</b><br>up to burst-limit 1M"]
    B -- "16 s average<br>reaches threshold 512k<br>(≈ 8 s)" --> C["<b>Burst off</b><br>back to max-limit 256k"]
    C -- "16 s average falls<br>below threshold 512k" --> B

The scenario¶

The lab starts where Lab 07-01 ended: FastTrack disabled and the queue laptop (target=192.168.88.200/32 max-limit=128k/256k), with no burst.

flowchart LR
    INET["<b>internet</b><br>198.51.100.10<br>www.mikrotik.com + iperf3"]
    CAP["<b>class-ap</b><br>10.0.0.1 · 198.51.100.1"]
    subgraph R1["r1 · your router"]
        WAN["ether2 (WAN)<br>10.0.0.x"]
        BR["<b>bridge1</b><br>192.168.88.1/24<br>queue laptop"]
    end
    PC1["<b>pc1</b> · laptop<br>192.168.88.200"]
    PC2["<b>pc2</b><br>192.168.88.201"]
    INET ---|"198.51.100.0/24"| CAP
    CAP ---|"10.0.0.0/24"| WAN
    WAN --- BR
    BR ---|"ether3"| PC1
    BR ---|"ether4"| PC2

Start the lab¶

Download the lab files and unzip them: 07-04-burst.zip. Open a terminal inside the 07-04-burst folder.

sudo containerlab deploy -t topology.clab.yml

Give RouterOS about two minutes to boot. Then:

ssh admin@clab-mtcna-07-04-r1            # password: admin
docker exec -it clab-mtcna-07-04-pc1 bash

./check.sh (with CLAB_EXEC="docker exec") tells you at any moment what is already solved. It waits 20 seconds in silence before measuring, so that the burst is "recharged".

Step 1 · Measure second by second, without burst¶

iperf3 prints one line per second, which is exactly what you need to see a burst. On pc1:

iperf3 -c 198.51.100.10 -R -t 20 -l 8K

(-l 8K makes iperf3 read in small pieces, so the per-second numbers are smooth.) Expected: every line around 200–260 Kbits/sec, from the first second to the last. And the course's "RouterOS download":

curl -o /dev/null -w "%{time_total} s\n" http://www.mikrotik.com/routeros.npk

Expected: about 67 s (2 MiB = 16.8 Mbit, ÷ 256k ≈ 65 s).

Done when you have the per-second numbers and the curl time in your report.

Step 2 · Add the burst¶

The course: modify the queue created in the previous LAB with burst limit, threshold and time, for upload and download.

WinBox: Queues → Simple Queues, double-click laptop, open the Burst section (slide 298): Burst Limit 1M / 1M, Burst Threshold 512k / 512k, Burst Time 16 / 16. OK.

/queue simple set laptop burst-limit=1M/1M burst-threshold=512k/512k burst-time=16s/16s
/queue simple print

Expected: max-limit=128k/256k burst-limit=1M/1M burst-threshold=512k/512k burst-time=16s/16s.

Done when the queue shows the three burst values.

Step 3 · Watch the burst switch on and off¶

Wait 20 seconds doing nothing (so your 16-second average drops to zero), then on pc1:

iperf3 -c 198.51.100.10 -R -t 40 -l 8K

At the same time, on r1, you can follow it live with Torch:

/tool torch interface=bridge1 src-address=192.168.88.200/32

Expected, from our own run (Kbits/sec per second):

1048 983 983 983 983 983 983 983 655 | 197 262 262 131 393 262 197 262 262 262 197 | 983 983 984 982 983 983 | 393 262 ...
<----------- burst, about 8 s ---------> <------------- max-limit 256k, about 11 s ----------> <--- burst again --->

1. About 8 seconds at ~1 Mbps: the burst, just as the formula predicted.
2. Back to ~256k: the 16-second average reached 512k, the gate closed.
3. The burst comes back: as the fast seconds slide out of the 16-second window, the average falls below 512k and the gate opens again.

Done when you can see at least one burst and one return to ~256k.

Step 4 · Open the website and download RouterOS again¶

The course: open www.mikrotik.com and see how fast the page loads; download the latest RouterOS and watch the speed with Torch. Wait 20 seconds, then on pc1:

curl -w "page: %{time_total} s\n" http://www.mikrotik.com/
curl -o /dev/null -w "%{time_total} s, %{speed_download} bytes/s\n" http://www.mikrotik.com/routeros.npk

Expected: the page arrives instantly (it is tiny, fully inside a burst). The 2 MiB download took about 26 s in our test (about 82,000 bytes/s), instead of about 67 s without burst. Do the ÷8 check: 82,000 bytes/s × 8 ≈ 655 kbps on average, well above the 256k max-limit, because of the repeated bursts.

Done when you have both curl results. Run ./check.sh: it must say lab mtcna-07-04 solved.

If something goes wrong¶

Clean up¶

sudo containerlab destroy -t topology.clab.yml --cleanup

Key takeaways¶

• A burst lets a client exceed its max-limit, up to the burst-limit, while its recent average is low.
• The average is calculated over burst-time seconds; the burst switches off when it passes burst-threshold.
• Burst-time is not the burst's duration: here 16 s of window gave ~8 s of burst (512k × 16 ÷ 1M).
• Bursts make short transfers (web pages) fast; long downloads end up near the normal limit.
• A threshold above max-limit makes the burst return again and again during a long download.

Quick check¶

Next, you will give every client on the LAN the same limit with a single rule: PCQ.