MikroTik Queue Tree Generator

How to use this

1. Define your plan tiers. Enter each plan name, download and upload speed in Mbps, and your current or projected subscriber count per plan. Start with the two default rows and adjust, or add more tiers.
2. Set interface name and headroom. Enter the RouterOS interface that faces your upstream (commonly pppoe-out1 for PPPoE or ether1 for direct ethernet). Set headroom between 10 and 20 percent for typical Kenyan ISP peak usage patterns.
3. Paste the generated commands into RouterOS. Copy the output block and paste it into a RouterOS terminal or run it via SSH. The commands are idempotent for new queues but will error if a queue with the same name already exists: check existing queues first with /queue type print and /queue tree print.

How it works

RouterOS supports two queue architectures. Simple queues bind a rate limit to a specific IP address and are processed by the CPU in a linear queue. Queue tree queues attach to an interface and are processed hierarchically, allowing parent queues to cap aggregate traffic while child queues distribute that capacity across subscribers. At scale, queue tree is the only practical choice¹.

PCQ (Per Connection Queue) is the queue discipline that makes queue tree per-subscriber rather than per-plan. When you set pcq-classifier=dst-address, RouterOS hashes every outgoing packet by destination IP and assigns it to a sub-queue capped atpcq-rate. The result is fair sharing: if 50 subscribers on the Home 10 plan are all active, each gets 10 Mbps and none can exceed it. For upload, the classifier switches to src-address because the packet is flowing toward the internet and you want to limit by who is sending¹.

The parent queue max-limit is the sum of all tier capacities multiplied by a headroom factor. Headroom prevents the parent from becoming the bottleneck on a partially-loaded network. The formula: parentMax = sum(downMbps × subscribers) × (1 + headroom%). Each tier child queue gets its own max-limit of downMbps × subscriberCountso that one oversubscribed tier cannot consume another tier's allocation.

In a Kenyan ISP context

Kenyan ISPs typically sell residential plans at 10/5 Mbps and 20/10 Mbps, with SMB tiers at 50/25 Mbps and enterprise at 100/50 Mbps or above. Most operators run PPPoE on MikroTik CHR or dedicated hardware routers, with the PPPoE interface (commonlypppoe-out1) as the queue tree parent. The generator defaults to this interface name.

The distinction between CIR (Committed Information Rate) and MIR (Maximum Information Rate) matters here. pcq-rate sets the CIR per subscriber. If a subscriber is the only active user on the plan, they can burst above CIR up to the tier max-limit. When the plan fills up, PCQ distributes the tier capacity equally and each subscriber is capped at CIR. FyberPay's provisioning service generates and pushes these queue configurations automatically when a subscriber's plan changes, so operators do not paste commands manually in production.

For operators using FreeRADIUS with MikroTik, RADIUS attributesMikrotik-Rate-Limit can inject per-subscriber limits without touching the queue tree. However, queue tree with PCQ is superior for aggregate traffic shaping because it handles bursting, fairness, and over-subscription at the platform level rather than per-session.

FAQ

Should I use queue tree or simple queue?

For any ISP with more than 100 subscribers, queue tree is the correct choice. Simple queues are processed sequentially per packet by the RouterOS scheduler, so a single heavy flow can starve every other subscriber. Queue tree with PCQ distributes bandwidth fairly across all subscribers in hardware-accelerated fashion. Simple queues are fine for a handful of fixed connections, but they do not scale.

Does PCQ guarantee per-subscriber speeds?

Yes. With pcq-classifier=dst-address on the download queue, RouterOS creates one virtual sub-queue per destination IP. Each sub-queue is limited to pcq-rate. Similarly, pcq-classifier=src-address on the upload queue limits per source IP. The result: a subscriber on the 10 Mbps plan cannot consume a neighbour's allocation even during peak hours.

How much headroom should I add?

Start at 10-20% over the sum of your sold rates. Below 10%, a single burst period where most subscribers are active can hit the parent max-limit and cause queuing delay: this is what operators experience as "slow internet" complaints in the evenings. Above 20%, you are leaving capacity unused during peak hours that you have paid for at the uplink level. Adjust based on your measured concurrent usage ratio.