The speed limit has no effect

You set a limit, meaning a guest should not swallow the whole line, or your video calls should stop stuttering. The limit is listed in /queue simple print, and nothing changes. The speed test still gets everything, or the priorities you designed are nowhere to be seen.

What it is not: this is rarely a wrong number. A queue set too generously still slows something down visibly. A queue that does nothing at all sees no packets. That is a different kind of fault.

The main reason is the most surprising one: FastTrack. That is the fast path RouterOS uses for connections it already knows, and it skips the firewall and the queues. You cannot have both.

The quick checks, in order

1. Does the counter move? /queue simple print stats, and for a tree /queue tree print stats. A good answer: the bytes climb while you download. If everything stays at zero, no traffic passes and the limit itself has nothing to do with the problem.
2. Is FastTrack on? /ip firewall filter print stats and find the rule with action fasttrack-connection. A good answer when queues are active: that rule is not there, or it is there as a comment. If it is there and its counter climbs fast, your traffic goes around the queues.
3. In which order? Look at the numbering in /queue simple print. Simple queues are walked top to bottom and the first one that matches takes the traffic. A broad queue on the bridge above your per-host limit means that host never gets its turn.
4. With a tree: are marks being set? /ip firewall mangle print stats. A good answer: the rules setting connection marks count up, and so do the rules setting packet marks. A queue tree without a matching packet mark is an empty box.
5. Is the limit below the line? /interface monitor-traffic interface=ether1 during a test. A good answer: the speed stays under what you set. A limit of 500 Mbit/s on a line that delivers 400 does nothing, because there is nothing to restrain.

The usual causes, most common first

The method is Off, so nothing was generated

This is the trap inside the configurator itself and it is the first one to rule out. Set the Method in the QoS section to Off and fill in a list of Limits per host below it, and those limits do not reach the script. The whole section stops as soon as the method is off, per-host limits included. No error appears; there is simply nothing in the script. So pick a method, even when all you want is a per-host cap.

Something else hangs off that: while the method is off, FastTrack stays on. Even if you added those limits by hand, they would still see no traffic.

FastTrack takes the traffic away

Fasttracked traffic passes the firewall and the queues. A queue on a router with FastTrack on only sees the first packets of every connection and nothing after that. Having both is not possible; you choose between peak throughput and control over the sharing.

The limit is above the real line speed

Set the limit a little below what your line really delivers, around 90 to 95 percent. Above that, the queue forms at your provider's modem and not at you, and you have no control there. That is the heart of bufferbloat: the delay builds up in a buffer that belongs to somebody else.

The traffic never passes the router

Two devices in the same VLAN on the same switch talk through the switch chip and never reach the CPU. No queue can limit that.

With a queue tree, the mark is missing

A queue tree works on packet marks. If something is off in the mangle rules, or an earlier rule already marks the traffic differently, you have branches with no traffic in them. Always look at mangle first and at the tree second.

What the configurator does about it

• In the QoS / bandwidth section you pick a method: off, one total limit, fair sharing per host with CAKE, fq_codel or PCQ, or priorities through a queue tree. Fair sharing with CAKE is the default and the right answer for most networks.
• As soon as a method is on, the firewall switches FastTrack off. The tool says so alongside: QoS active means FastTrack off, which raises CPU load and costs throughput on small routers. In the script, a comment sits where the FastTrack rule would have been and says why it is missing.
• Pick a queue tree on an older MIPS router and enter more than 200 Mbit/s, and the tool does the arithmetic: this device shapes in software and with FastTrack off it manages an estimated 200 to 300 Mbit/s, so the CPU becomes the bottleneck and the priorities stop holding. With the suggestion to use fair sharing with CAKE or fq_codel instead: one queue, no mangle rules, far less CPU.
• With two WAN lines and a queue tree, the tool warns that the upload queue hangs on the first WAN interface and the second one is not shaped.
• The queue tree itself is built to be cheap: the expensive matching runs only on the first packet of a connection, which gets a connection mark, and every later packet is classified with a single compare.
• What the tool does not do: it does not warn you when you fill in per-host limits while the method is off. That is the gap most people fall into.

Where the cause lies outside your router

• The provider's modem. With your limit set too high, that modem forms the queue and you notice nothing of your setting.
• Wifi. A slow client on wifi holds the rest back in a way no queue on the router fixes. See Wifi is slow.

Read on: QoS and bandwidth, CPU at 100 percent and Checks about speed.