Lab 07-05 · PCQ: the same limit for every client, with one rule¶

A café has 60 customers on its WiFi. The owner wants each one to get at most 2 Mbps, so nobody ruins it for the others. With what you know so far, that means 60 simple queues, one per address, and editing them every time the DHCP pool changes. Now imagine a hotel with 600 rooms.

There is a better way: one queue that automatically creates a separate, identical limit for every client it sees. That queue is PCQ. Today you build it the way the course does, and prove with two laptops that both get exactly the same speed.

One queue, many sub-queues¶

PCQ (Per Connection Queuing) is a queue type that splits traffic into sub-streams according to a classifier, and gives each sub-stream its own queue with the same rate.

The motorway again. Until now each toll gate had to be built by hand for one car. PCQ is a smart toll plaza: whenever a car with a new number plate arrives, a new booth opens just for it, with the same speed as all the others. When the car leaves, the booth disappears.

flowchart LR
    IN["<b>Download traffic</b><br>to the LAN"] --> C{"<b>Classifier</b><br>dst-address"}
    C -- "to .200" --> S1["sub-queue .200<br>rate 256k"]
    C -- "to .201" --> S2["sub-queue .201<br>rate 256k"]
    C -- "to .202 ..." --> S3["sub-queue ...<br>rate 256k"]
    S1 --> PC1["pc1"]
    S2 --> PC2["pc2"]
    S3 --> PCN["any new client"]

Its parameters (slide 303)¶

Where the PCQ goes: interface queues¶

A queue type is just a recipe. It does nothing until you attach it somewhere. The course attaches it as an interface queue (Queues → Interface Queues): the queue every packet goes through when it leaves an interface.

The scenario¶

The router starts from the factory configuration with FastTrack already disabled (Lab 07-01) and no queues. In the course the trainer builds PCQ on the class router and the students are the clients; here you build it on r1, and pc1 and pc2 are the clients.

flowchart LR
    INET["<b>internet</b><br>198.51.100.10<br>iperf3 on 5201 and 5202"]
    CAP["<b>class-ap</b><br>10.0.0.1 · 198.51.100.1"]
    subgraph R1["r1 · your router"]
        WAN["ether2 (WAN)<br>upload PCQ"]
        BR["<b>bridge1</b> 192.168.88.1/24<br>ports ether3, ether4<br>download PCQ"]
    end
    PC1["<b>pc1</b><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-05-pcq.zip. Open a terminal inside the 07-05-pcq folder.

sudo containerlab deploy -t topology.clab.yml

Give RouterOS about two minutes to boot. You need three terminals:

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

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

Step 1 · Measure two clients with no queue¶

Start both at the same moment (within a second):

iperf3 -c 198.51.100.10 -R -t 15 -p 5201      # on pc1
iperf3 -c 198.51.100.10 -R -t 15 -p 5202      # on pc2

Expected: together about 1 Mbps, often split unevenly (in our test 629k and 315k).

Done when you have both numbers in your report.

Step 2 · Create the two PCQ queue types¶

One type per direction, as on slide 305.

WinBox: Queues → Queue Types → +. Type Name pcq-download-256k, Kind pcq, Rate 256k, Classifier: tick Dst. Address only. OK. Again: pcq-upload-256k, Kind pcq, Rate 256k, Classifier Src. Address only.

/queue type add name=pcq-download-256k kind=pcq pcq-rate=256k pcq-classifier=dst-address
/queue type add name=pcq-upload-256k kind=pcq pcq-rate=256k pcq-classifier=src-address
/queue type print where kind=pcq

Expected: your two types plus RouterOS's own pcq-upload-default and pcq-download-default (rate 0 = unlimited per sub-stream).

Done when both types show pcq-rate=256k and the right classifier.

Step 3 · Attach them as interface queues¶

Slide 306: the WAN interface gets the upload type and the LAN interface gets the download type.

WinBox: Queues → Interface Queues, double-click ether2, Queue Type pcq-upload-256k. Then ether3 and ether4, Queue Type pcq-download-256k.

/queue interface set ether2 queue=pcq-upload-256k
/queue interface set ether3 queue=pcq-download-256k
/queue interface set ether4 queue=pcq-download-256k
/queue interface print

Expected: ACTIVE-QUEUE shows your PCQ types on those three ports.

Done when the three interfaces show the PCQ types.

Step 4 · Prove that everybody gets the same¶

Repeat Step 1 (both at the same moment). Then one alone, plus an upload:

iperf3 -c 198.51.100.10 -R -t 10 -p 5201      # pc1 alone, download
iperf3 -c 198.51.100.10 -t 10 -p 5201         # pc1 alone, upload

Expected: together, about 210k and 210k, the same for both; alone, still under 256k (each client has its own 256k, it does not get more because the other one is idle). Watch it like the course does, on r1 (Tools → Torch, Interface ether3):

/tool torch interface=ether3

And the course's download on pc1:

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

About 30 kB/s (256 ÷ 8 = 32 kB/s, minus headers), whoever downloads.

Done when both clients get about the same speed, under 256k. Run ./check.sh: it must say lab mtcna-07-05 solved.

If something goes wrong¶

Clean up¶

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

Key takeaways¶

• PCQ creates one sub-stream per client automatically, each with the same rate: one rule instead of hundreds.
• The classifier decides what a client is: dst-address for downloads, src-address for uploads.
• A queue type is a recipe; it works once attached to an interface queue or a simple queue.
• Interface queues act on traffic leaving an interface: download on the LAN ports, upload on the WAN port.
• In RouterOS 7.23 a bridge refuses an interface queue: put it on the bridge's ports.

Quick check¶

This closes Module 7: you can now cap, target, guarantee, burst and share bandwidth fairly. Next module: tunnels.