MikroTik QoS: Simple Queues, Queue Trees, PCQ, FQ-CoDel & CAKE

0 Shares

Quality of Service (QoS) on MikroTik is about controlling how bandwidth is shared when a link becomes busy. A good QoS design can protect voice and interactive traffic, prevent one subscriber or device from consuming the whole uplink, and reduce latency under load. A poor design can add unnecessary complexity, misclassify traffic, or make throughput worse.

RouterOS offers several queueing tools, but they are not all competing alternatives. Simple Queues and Queue Trees are ways to attach shaping and scheduling policies. PCQ is a queue type designed to divide bandwidth among flows or hosts. FQ-CoDel and CAKE are modern queue disciplines intended to improve fairness and control queue delay (bufferbloat). They can be used in different queue configurations where supported by the RouterOS release and device.

This guide explains the differences, when to use each, practical RouterOS examples, FastTrack interactions, testing, and common mistakes. Examples are starting points: adapt interface names, addresses, rates, and queue parameters to your topology and verify behavior on your exact RouterOS version.

What QoS Does on a MikroTik Router

QoS is most useful when traffic competes for a constrained link. If a WAN circuit has ample spare capacity, queue rules may have little visible effect. When the circuit saturates, however, packets build up in buffers. Latency rises, interactive applications feel sluggish, and real-time traffic can suffer even though a speed test reports high throughput.

Shaping deliberately limits traffic slightly below the actual bottleneck rate so the router, rather than an uncontrolled modem or upstream device, manages the queue. Scheduling then decides which packets or flows get served first and how bandwidth is shared. A queue discipline may also isolate flows and actively manage queue delay.

QoS does not create bandwidth. It decides how available capacity is shared during contention. It cannot fix a congested upstream network outside your control, a faulty physical link, or an undersized service plan.

Shaping, scheduling, and queue discipline

Shaping: sets a rate ceiling and smooths traffic to a configured bandwidth.
Scheduling: allocates service among classes or users, using mechanisms such as priority and guaranteed rates.
Fair queuing: prevents a single bulk flow or host from dominating all packet service.
Active queue management (AQM): signals congestion or drops/marks packets before queues become excessively deep, helping control latency.

Simple Queues vs Queue Trees vs PCQ vs FQ-CoDel vs CAKE

Feature	What it is	Best fit
Simple Queues	Convenient per-target shaping and scheduling, with a hierarchical queue list.	Small and medium networks, per-client limits, straightforward policies.
Queue Trees	More flexible hierarchical HTB scheduling, commonly driven by packet marks and attached to interfaces or global parents.	Multi-class QoS, WAN policy, service-provider designs, complex upload/download policies.
PCQ	A queue type that creates subqueues based on classifiers and shares capacity among them.	Fair per-host or per-flow sharing without writing one queue per subscriber.
FQ-CoDel	Flow queueing plus CoDel active queue management to limit persistent queue delay.	Latency-sensitive links with mixed interactive and bulk traffic.
CAKE	An integrated shaper and advanced queue discipline with flow isolation, AQM, and optional DiffServ handling.	WAN edge shaping and bufferbloat control where CPU and version support are sufficient.

The important distinction: PCQ, FQ-CoDel, and CAKE are queue disciplines/types, not replacements for every feature of Simple Queues or Queue Trees. The queue structure determines where policy is attached; the queue type determines how packets are buffered and served.

Simple Queues: The Easiest Per-Client Controls

Simple Queues are usually the fastest way to impose a bandwidth ceiling on a known host or subnet. Each queue can specify a target, upload and download limits, priority, and optional guaranteed or burst rates. Simple Queues are processed in order, so queue order and target overlap matter.

Example: limit one client

The following example limits a single LAN client to 20 Mbps download and 5 Mbps upload. Replace the example address with a real client address and verify the upload/download interpretation for your interface and topology.

/queue/simple
add name="client-192.0.2.10" target=192.0.2.10/32 \
    max-limit=5M/20M

In a Simple Queue, the rate pair is written as upload/download from the router’s perspective for the target. Validate with a controlled test from that client rather than assuming the order matches the labels in your ISP plan.

When Simple Queues work well

You need a small number of per-subscriber or per-device limits.
Policies are mostly independent target ceilings.
You want a readable configuration that is easy to troubleshoot.

Limitations

Large numbers of Simple Queues and complex overlapping targets can increase processing overhead and make queue ordering harder to reason about. Simple Queues also interact with FastTrack: FastTracked traffic bypasses Simple Queues. A configuration can look correct while much of the traffic never reaches the queue.

Queue Trees: Flexible Hierarchical QoS

Queue Trees are useful when you need multiple traffic classes under a shared parent. They use HTB (Hierarchical Token Bucket) concepts such as parent, max-limit, limit-at, and priority. A Queue Tree is directional: shape upload and download separately at the relevant egress points, and remember that the interface parent represents traffic leaving that interface.

Queue Trees commonly use firewall mangle rules to classify packets and assign packet marks. The marks then select the queue branch. Keep classification narrow and deliberate; broad rules can mark management, routing, or unrelated traffic by mistake.

Example: mark a traffic class

This illustrative example marks packets from a chosen subnet. It is not a complete upload/download policy: place the rule in the correct chain for your direction, account for NAT and routing, and create corresponding queue branches at the correct egress parent.

/ip/firewall/mangle
add chain=forward src-address=192.0.2.0/24 \
    action=mark-packet new-packet-mark=lan-clients passthrough=no

Example: attach a queue branch

For traffic leaving a WAN interface, a basic queue branch can be attached to that interface. Confirm that the packet mark is present on packets at that egress and that the configured rate is below the real bottleneck rate.

/queue/tree
add name="lan-client-class" parent=ether1 packet-mark=lan-clients \
    max-limit=80M

This minimal branch demonstrates the relationship between a packet mark and a queue; a production design typically includes a root/parent policy, separate directions, multiple classes, and carefully selected guarantees and ceilings. Do not paste the example unchanged if your WAN interface or direction differs.

When Queue Trees are the better choice

You need multiple classes such as voice, business-critical, normal, and bulk.
You want explicit upload and download policies at different interfaces.
You need parent/child rate guarantees and ceilings.
You are building repeatable ISP or multi-tenant QoS policies.

Queue Trees require more planning than Simple Queues. Design the classification and direction first, then create the hierarchy and test every class under load.

PCQ: Fair Bandwidth Sharing Across Many Hosts

Per Connection Queueing (PCQ) creates subqueues dynamically using a classifier such as source address, destination address, source port, or destination port. It is commonly used to divide a shared bandwidth pool fairly among active clients without creating a separate queue for each one.

For example, a download PCQ classifier based on destination address can divide download traffic among LAN clients. An upload classifier based on source address can divide upload traffic by originating client. With pcq-rate=0, the queue shares the available parent capacity among active subqueues rather than assigning each subqueue a fixed rate.

Example PCQ queue types

/queue/type
add name=pcq-download kind=pcq pcq-classifier=dst-address \
    pcq-rate=0
add name=pcq-upload kind=pcq pcq-classifier=src-address \
    pcq-rate=0

These are queue types only; they do not shape traffic until attached to a Simple Queue or Queue Tree. For example, they can be assigned to the appropriate upload/download queue-type fields in a Simple Queue or used as the queue type on Queue Tree branches. Match the classifier to the direction in which client addresses are visible.

PCQ with Simple Queues

A common small-network approach is a single Simple Queue targeting the LAN subnet, with PCQ types assigned to its upload and download directions. This creates a shared ceiling for the subnet and divides it among active hosts. Check the exact queue-type property names and direction on the RouterOS release you run before applying it.

PCQ with Queue Trees

In a larger design, use packet marks to separate traffic classes and PCQ as the queue type for a class that should be shared fairly among hosts. This lets the parent control total class bandwidth while PCQ distributes that capacity across active clients.

PCQ fairness is not always the fairness you want

Per-address fairness treats each IP address as a participant. A household with many devices may receive a larger aggregate share than a household with one device. Per-connection fairness can also reward applications that open many parallel connections. Choose classifiers based on the subscriber model and policy objective, not simply on the word “fair.”

FQ-CoDel: Reduce Bufferbloat and Protect Interactive Traffic

FQ-CoDel combines flow queuing (FQ) with the Controlled Delay (CoDel) active queue management algorithm. Flow queuing separates traffic into flows so one bulk transfer is less likely to monopolize packet service. CoDel monitors queue delay and manages persistent standing queues, helping reduce latency when a link is saturated.

FQ-CoDel is useful when the main problem is latency under load rather than a need for elaborate per-subscriber rate plans. It can help keep web browsing, voice, gaming, and interactive sessions responsive while large transfers are running.

Example queue type

/queue/type
add name=fq-codel-wan kind=fq-codel

After creating the type, attach it to the appropriate queue or Queue Tree branch that controls the bottleneck. The queue discipline does not by itself guarantee that the WAN bottleneck is shaped at the router. If the modem or provider continues to queue more traffic upstream, latency can remain high.

FQ-CoDel tuning

Start with the RouterOS defaults unless measurement shows a specific reason to change them. Parameters such as target, interval, memory limit, and flow count affect behavior. Changing them without a controlled test can reduce throughput or worsen latency. Availability and exposed parameters can vary with RouterOS version and platform.

CAKE: Integrated Shaping and Advanced Queue Management

CAKE (Common Applications Kept Enhanced) combines shaping, flow isolation, and active queue management in one queue discipline. Depending on the RouterOS implementation and release, it can also use DiffServ tins, NAT awareness, different flow-isolation modes, and link-layer overhead compensation. This makes it attractive for a WAN edge where low latency and fair sharing matter.

CAKE is often a strong candidate for controlling bufferbloat on an Internet connection, but it is not automatically the fastest option on every MikroTik. Shaping and packet scheduling consume CPU. On lower-powered hardware or high-rate links, benchmark throughput, CPU load, and latency before deploying it widely.

Example CAKE queue type

/queue/type
add name=cake-wan kind=cake cake-bandwidth=90M \
    cake-diffserv=diffserv4 cake-nat=yes

This example illustrates the general configuration approach, not a universal drop-in recipe. Confirm the available CAKE properties and accepted values with /queue/type/add ? or the RouterOS documentation for your installed release. Set the shaping bandwidth below the measured sustainable bottleneck rate, and select NAT awareness and DiffServ behavior to match the topology and marking policy.

CAKE flow isolation and DiffServ

Flow isolation determines how CAKE separates traffic for fairness. NAT awareness can help identify internal hosts behind a translated address when supported and correctly configured. DiffServ mode maps packet DSCP markings into service tins; it does not mean that arbitrary DSCP values are trustworthy. Only honor markings from sources you control or have explicitly chosen to trust.

When CAKE is a good fit

A WAN connection suffers from bufferbloat during uploads or downloads.
You want integrated shaping and per-flow fairness rather than a large class hierarchy.
The router has enough CPU headroom at the target throughput.
You can test latency and throughput under simultaneous load.

CAKE and FQ-CoDel are not substitutes for a complete multi-class enterprise policy in every environment. For strict class guarantees, complex service tiers, or large subscriber hierarchies, Queue Trees with deliberate classification may be a better fit.

FastTrack, Hardware Offload, and Queue Interaction

FastTrack is a major source of “my queue does nothing” problems. FastTracked packets bypass several parts of the normal packet-processing path, including Simple Queues and Queue Trees with a global parent. A Queue Tree attached to a specific interface can still be used for traffic that reaches that egress queue, but the design must be tested carefully with the actual FastTrack rules and packet path.

If QoS must apply to all relevant traffic, exclude that traffic from FastTrack or design a queue placement that sees it. Do not disable FastTrack blindly on a busy production router: CPU usage may increase substantially. Compare CPU and throughput before and after any change.

Hardware offload is another consideration. Switching and routing offload capabilities vary by device, chip, and configuration. Features that require CPU-based classification or queue processing may change the forwarding path and throughput. Review MikroTik hardware offloading and performance troubleshooting before assuming the router can apply complex QoS at line rate.

For a deeper explanation of connection states and FastTrack interactions, see MikroTik connection tracking and firewall-state troubleshooting.

How to Choose the Right QoS Design

Small office or home network

Start with one simple shaping policy for the WAN bottleneck and PCQ if you need fair sharing among multiple LAN hosts. If bufferbloat is the main issue and your router has sufficient CPU, test FQ-CoDel or CAKE as the queue discipline. Keep the design simple enough that you can identify which queue is handling each packet.

ISP or hotspot with many subscribers

Use a repeatable subscriber policy. Simple Queues can be straightforward for a smaller subscriber count, while Queue Trees and PCQ can scale more cleanly for shared classes and dynamic per-host fairness. Model the difference between fairness per IP address, per customer, and per connection. A single customer with multiple devices should not unintentionally receive multiple times the intended share.

For broader ISP architecture and subscriber network planning, see MikroTik for ISPs: Scaling Networks with RouterOS.

Business network with traffic classes

Use Queue Trees when you need defined classes such as voice, business applications, standard browsing, and bulk transfers. Classify traffic using robust criteria such as known subnets, interfaces, or trusted DSCP markings. Set guaranteed rates only where the capacity plan supports them, and ensure the sum of guarantees does not exceed the parent capacity.

Latency-sensitive WAN edge

Test CAKE or FQ-CoDel at a shaping rate slightly below the actual bottleneck. Measure loaded latency in both directions. If upload saturation is the main source of delay, upload shaping may deliver the biggest improvement; if download queues form upstream, you may need a slightly conservative download shaper and must accept that results depend on where the provider queues packets.

For traffic visibility before and after QoS changes, use MikroTik NetFlow and ntopng traffic analysis to understand which hosts and applications consume bandwidth.

Testing and Troubleshooting MikroTik QoS

1. Establish a baseline

Measure idle latency, loaded latency, download and upload throughput, packet loss, CPU usage, and interface errors before enabling queues. Test from wired clients where possible to avoid confusing Wi-Fi airtime contention with WAN queue behavior.

2. Confirm the traffic reaches the queue

Inspect queue counters and statistics while generating known traffic. For Queue Trees, verify packet marks with mangle counters and confirm that the selected parent matches the egress direction. For Simple Queues, confirm target matching and queue order. A queue with zero packets is a classification or packet-path problem, not a tuning problem.

3. Test one direction at a time

Run an upload test, then a download test, then simultaneous bidirectional traffic. Confirm that the intended rate ceiling applies in each direction. Remember that upload/download labels and egress interfaces are easy to reverse in asymmetric topologies.

4. Watch CPU and FastTrack

Check CPU load under realistic traffic. Confirm whether FastTrack is bypassing the queues you expect to use. Do not compare queue types using a test where one configuration processes packets in software and another takes a different forwarding path without recording that difference.

5. Change one variable at a time

Change the shaping rate or queue type, then repeat the same test. Avoid simultaneously changing mangle rules, queue hierarchy, FastTrack, and firewall configuration; otherwise it becomes difficult to identify the cause of an improvement or regression.

Useful inspection commands

/queue/simple/print stats
/queue/tree/print stats
/queue/type/print detail
/ip/firewall/mangle/print stats
/ip/firewall/filter/print stats
/tool/profile

Command availability and output formatting can differ slightly by RouterOS release. If counters or behavior do not match expectations, use a methodical CLI workflow such as MikroTik CLI troubleshooting techniques.

Frequently Asked Questions

Are Simple Queues better than Queue Trees?

Neither is universally better. Simple Queues are easier for straightforward per-target limits. Queue Trees provide more control over hierarchical classes and packet-mark-based policies. Choose based on the policy you need and the number of targets and classes.

Is PCQ a replacement for Simple Queues?

No. PCQ is a queue type that can be attached to supported Simple Queue or Queue Tree configurations. It provides dynamic subqueues and fair sharing; the surrounding queue structure still defines the target, parent, and overall bandwidth policy.

Should I use PCQ or CAKE?

PCQ is useful when you need predictable per-host or per-flow sharing inside a broader queue policy. CAKE integrates shaping, flow isolation, and active queue management to reduce queue delay. The best choice depends on whether your primary requirement is subscriber fairness, class-based policy, or low latency under load.

Does FQ-CoDel limit bandwidth?

FQ-CoDel manages flow queues and queue delay; it is not by itself a complete bandwidth plan for an upstream bottleneck. Shape traffic at the actual bottleneck so the queue discipline can manage the queue that forms at your router.

Does CAKE work on every MikroTik router?

Do not assume universal availability or line-rate performance. Check the queue types exposed by your installed RouterOS version and test CPU usage and throughput on the exact hardware. Feature availability and practical capacity are platform-dependent.

Why does FastTrack break my QoS?

FastTracked packets bypass Simple Queues and Queue Trees attached to a global parent. If the traffic you want to shape is FastTracked, the queue may not see it. Adjust the FastTrack design or queue placement deliberately and verify with counters.

What bandwidth should I configure for CAKE or FQ-CoDel?

Shape slightly below the real sustained bottleneck rate, then test under load. The correct margin depends on access technology, ISP variability, protocol overhead, and whether the bottleneck is upstream or downstream. There is no universal percentage that works for every circuit.

Conclusion

For simple per-device limits, start with Simple Queues. For complex traffic classes and hierarchical guarantees, use Queue Trees. Use PCQ when a shared pool needs fair distribution among hosts or flows. Choose FQ-CoDel or CAKE when controlling latency and bufferbloat is the main objective, provided the router has enough processing capacity. In every case, verify packet classification, queue counters, FastTrack behavior, CPU load, and loaded latency. The best MikroTik QoS design is the simplest one that reliably enforces the policy your network actually needs.

Check our list of MikroTik guides