Lab 07-02 · Limit the traffic to one server, not one client¶

Your school wants students to keep using the Internet at full speed for homework, but one streaming site is eating the whole connection every lunch break. Blocking it would cause a riot. Limiting every student would punish the ones doing homework. What the school really wants is: anybody can use that one site, but slowly.

In Lab 07-01 you limited who (one laptop). Today you will limit where to (one server), for everybody, and prove with a second server that the rest of the Internet stays fast.

From "who" to "where to"¶

The target of a simple queue says whose traffic is limited; the Dst. (destination) field says towards which address. A packet goes through the queue only if it matches both.

Back to the motorway from Lab 07-01. Until now the toll gate stopped one car (your laptop) wherever it went. Now the gate stands on the exit to one town (the server): every car taking that exit pays, every other car drives on.

flowchart LR
    subgraph LAN["LAN 192.168.88.0/24"]
        PC1["<b>pc1</b><br>.200"]
        PC2["<b>pc2</b><br>.201"]
    end
    subgraph R1["r1"]
        Q["<b>Queue mikrotik-com</b><br>target: any<br>dst: 198.51.100.10<br>128k up / 256k down"]
    end
    PC1 --> Q
    PC2 --> Q
    Q -- "limited" --> S1["<b>www.mikrotik.com</b><br>198.51.100.10"]
    PC1 -. "not limited" .-> S2["<b>other server</b><br>198.51.100.20"]

The scenario¶

The lab starts where Lab 07-01 ended: FastTrack disabled and a queue laptop that limits pc1 to 128k/256k everywhere. The internet node now answers on two addresses: 198.51.100.10 (www.mikrotik.com) and 198.51.100.20 (an "other server" with no name).

flowchart LR
    INET["<b>internet</b><br>198.51.100.10 = www.mikrotik.com<br>198.51.100.20 = other server"]
    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"]
    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

The free CHR licence caps every virtual port at about 1 Mbps, so "full speed" in this lab means about 1 Mbps.

Start the lab¶

Download the lab files and unzip them: 07-02-queue-to-server.zip. Open a terminal inside the 07-02-queue-to-server folder.

sudo containerlab deploy -t topology.clab.yml

Give RouterOS about two minutes to boot. Then open the router and the laptop:

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

./check.sh (with CLAB_EXEC="docker exec") tells you at any moment what is already solved.

Step 1 · Find the server's address¶

A queue works with addresses, not names. The course says: with the ping tool, find out the address of www.mikrotik.com. On pc1:

ping -c 2 www.mikrotik.com

Expected: PING www.mikrotik.com (198.51.100.10). The router asked its DNS server (class-ap) and got the address. WinBox users can do the same in Tools → Ping.

Done when you know the address: 198.51.100.10.

Step 2 · Measure both servers with the old queue¶

Before changing anything, see what the Lab 07-01 queue does to both servers. On pc1:

iperf3 -c 198.51.100.10 -R -t 6              # www.mikrotik.com
iperf3 -c 198.51.100.20 -R -t 6 -p 5202      # the other server

Expected: both around 175–250 kbps. The laptop queue limits pc1 whatever it talks to.

Done when you have both numbers in your report.

Step 3 · Point the queue at the server¶

The course says: modify the existing simple queue to limit the connection to the mikrotik.com server. Two changes: target becomes any, and Dst. becomes the server.

WinBox: Queues → Simple Queues, double-click laptop. Name mikrotik-com. In Target, remove the laptop address (empty means any). In Dst., type 198.51.100.10. OK.

/queue simple set laptop name=mikrotik-com target=0.0.0.0/0 dst=198.51.100.10/32
/queue simple print

Expected: name="mikrotik-com" target="" dst=198.51.100.10/32 ... max-limit=128k/256k. RouterOS shows 0.0.0.0/0 as an empty target: any address.

Done when the queue shows dst=198.51.100.10/32 and an empty target.

Step 4 · Prove that only one server is limited¶

Run the same two tests again on pc1:

iperf3 -c 198.51.100.10 -R -t 6              # www.mikrotik.com: limited
iperf3 -c 198.51.100.20 -R -t 6 -p 5202      # other server: free

Expected: about 175–250 kbps from 198.51.100.10 and about 900–1,000 kbps from 198.51.100.20. Then the course's download, watching the speed:

curl -o /dev/null http://www.mikrotik.com/routeros.npk

About 30 kB/s (256k ÷ 8 = 32 kB/s, minus headers). Now pc2, which the old queue never touched (docker exec -it clab-mtcna-07-02-pc2 bash):

iperf3 -c 198.51.100.10 -R -t 6

Also limited: the target is any, so every client is caught at that exit. While a test runs you can watch it on r1 with /tool torch interface=ether2 src-address=198.51.100.10/32 (Ctrl+C to stop) and with /queue simple print stats.

Done when .10 is limited for both PCs and .20 is not. Run ./check.sh: it must say lab mtcna-07-02 solved.

If something goes wrong¶

Clean up¶

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

Key takeaways¶

• A simple queue matches target (whose traffic) and Dst. (towards which address).
• Target any (0.0.0.0/0, shown empty) + Dst. = server limits every client, but only with that server.
• max-limit=upload/download is still read from the client's side.
• One simple queue is one gate: all matching clients share its limit.
• Always measure before and after, and compare with something that should not change.

Quick check¶

Next, you will see how to guarantee a minimum speed to each client, not just cap the maximum.