Bandwidth Limiting with Simple Queues

Bandwidth Limiting with Simple Queues

RouterOS Version: 7.x+ Difficulty: Beginner Estimated Time: 30 minutes

TL;DR (Quick Start)

For the impatient: here’s the 30-second version.

# Limit client to 5M upload / 10M download with 2M guaranteed
/queue simple add target=192.168.88.100/32 max-limit=5M/10M limit-at=2M/2M name=client-limit

Overview

Simple Queues are RouterOS’s most intuitive tool for bandwidth management, designed to limit and prioritize traffic for specific targets like IP addresses, subnets, or interfaces. Unlike the more complex Queue Tree system, Simple Queues provide an integrated solution that handles both upload and download limitations in a single configuration entry.

Understanding Simple Queues is essential for network administrators who need to ensure fair bandwidth distribution, prevent network congestion, and guarantee service levels for critical applications.

The Queue Hierarchy: Where Simple Queues Fit

RouterOS implements a sophisticated queuing system based on Hierarchical Token Bucket (HTB) algorithm. Understanding this hierarchy is crucial for effective bandwidth management:

Key Concepts:

• Processing Order: Every packet must traverse Simple Queues sequentially until it matches a rule or reaches the end
• Bidirectional Control: Simple Queues can limit both upload and download in a single entry
• Target-Based: Queues identify traffic based on source/destination addresses and interfaces

Understanding Rate Limiting vs. Rate Equalizing

Simple Queues can operate in two fundamental modes, controlled by the queue size parameter:

Rate Limiting (Shaper Mode)

When queue-size=0, packets exceeding the rate limit are dropped immediately:

Incoming Traffic: ████████████████████ (20 Mbps)
Rate Limit:       ██████████           (10 Mbps)
Result:           ██████████           (10 Mbps - excess dropped)

Use cases:

• Strict bandwidth enforcement
• Preventing network abuse
• Compliance with ISP limitations

Rate Equalizing (Scheduler Mode)

When queue-size=unlimited, packets exceeding the rate limit are queued and delayed:

Incoming Traffic: ████████████████████ (20 Mbps burst)
Rate Limit:       ██████████           (10 Mbps)
Result:           ██████████████████████ (20 Mbps delivered over time)

Use cases:

• Smoothing bursty traffic
• Maintaining user experience during congestion
• Buffering for variable-speed connections

The Two-Rate System: CIR and MIR

Simple Queues implement a sophisticated two-rate limiting system:

Committed Information Rate (CIR) - limit-at

The guaranteed minimum bandwidth that a queue will receive regardless of network congestion:

# Guarantee 5 Mbps minimum for critical server
/queue simple add target=192.168.1.100 limit-at=5M/5M max-limit=20M/20M name=critical-server

Maximum Information Rate (MIR) - max-limit

The maximum allowed bandwidth when network capacity is available:

Burst Mechanism: Temporary Speed Boosts

The burst feature allows queues to exceed their max-limit temporarily when average usage is below the threshold:

Burst Parameters

• burst-limit: Maximum speed during burst (e.g., 50M)
• burst-threshold: Average rate trigger for burst allowance (e.g., 8M)
• burst-time: Time window for average calculation (e.g., 8s)

Burst Logic Flow

Example: A user with 10M max-limit can burst to 50M when their average usage over the last 8 seconds is below 8M.

Prerequisites

• RouterOS 7.x+ device with administrative access
• Basic understanding of IP addressing and network interfaces
• Test client connected to ether2 (or adjust interface names accordingly)
• Important: Ensure FastTrack is disabled for traffic you want to queue (see Troubleshooting section)

Configuration Steps

This minimal example demonstrates bandwidth limiting for a single client, showcasing the core Simple Queue functionality.

Step 1: Create Basic Bandwidth Limit

Limit a test client to 10 Mbps download and 5 Mbps upload:

/queue simple add target=192.168.88.100/32 max-limit=5M/10M name=test-client-limit

Step 2: Add Guaranteed Bandwidth

Ensure the client gets at least 2 Mbps even during network congestion:

/queue simple set test-client-limit limit-at=2M/2M

Verification

Confirm the queue is created and processing traffic:

Check Queue Configuration

/queue simple print detail where name=test-client-limit

Expected Output:

Flags: X - disabled, I - invalid, D - dynamic
 0   name="test-client-limit" target=192.168.88.100/32 parent=none packet-marks="" priority=8 queue=default-small/default-small limit-at=2M/2M max-limit=5M/10M
     burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s total-queue=default-small total-priority=8 total-limit-at=0/0 total-max-limit=0/0 total-burst-limit=0/0
     total-burst-threshold=0/0 total-burst-time=0s/0s

Monitor Queue Statistics

/queue simple print stats where name=test-client-limit

Expected Output (when traffic is flowing):

 0   name="test-client-limit" bytes=1,234,567/9,876,543 packets=1,234/9,876 dropped=0/0 rate=1.2Mbps/8.5Mbps packet-rate=15pps/125pps queued-bytes=0/0
     queued-packets=0/0 invalid=no

Advanced Concepts

Target Specification and Traffic Direction

Simple Queues determine traffic direction based on the target specification:

# Target matches source address = UPLOAD traffic
# Target matches destination address = DOWNLOAD traffic

/queue simple add target=192.168.1.100/32 max-limit=5M/10M
# 192.168.1.100 → Internet = 5M upload limit
# Internet → 192.168.1.100 = 10M download limit

Interface-Based Targeting

Target traffic based on the interface rather than IP addresses:

# Limit all traffic on ether2 interface
/queue simple add target="" interface=ether2 max-limit=50M/50M name=ether2-limit

Subnet-Based Limiting

Apply bandwidth limits to entire network segments:

# Limit entire guest network
/queue simple add target=192.168.100.0/24 max-limit=20M/20M name=guest-network-limit

Time-Based Queues

Activate bandwidth limits only during specific time periods:

# Limit gaming traffic during business hours
/queue simple add target=192.168.1.0/24 max-limit=10M/10M time=8h-17h,mon,tue,wed,thu,fri name=business-hours-limit

Packet Mark Integration

Use firewall mangle marks for more sophisticated traffic classification:

# First, mark P2P traffic in firewall mangle
/ip firewall mangle add chain=prerouting action=mark-packet new-packet-mark=p2p-traffic p2p=all-p2p

# Then create queue for marked traffic
/queue simple add packet-marks=p2p-traffic max-limit=1M/1M name=p2p-throttle

Priority and Parent-Child Relationships

Create hierarchical bandwidth allocation:

# Parent queue for entire department
/queue simple add target=10.1.0.0/24 max-limit=100M/100M name=dept-total

# Child queues for specific services
/queue simple add target=10.1.0.10/32 parent=dept-total max-limit=50M/50M name=dept-server priority=1
/queue simple add target=10.1.0.0/24 parent=dept-total max-limit=30M/30M name=dept-users priority=5

Priority Rules:

• Lower numbers = higher priority (1 = highest, 8 = lowest)
• Higher priority queues get bandwidth first
• Priority only matters between child queues of the same parent

Per-Connection Queuing (PCQ)

Distribute bandwidth equally among multiple connections:

# Create PCQ queue types
/queue type add name=pcq-download kind=pcq pcq-rate=2M pcq-classifier=dst-address
/queue type add name=pcq-upload kind=pcq pcq-rate=1M pcq-classifier=src-address

# Apply to subnet
/queue simple add target=192.168.1.0/24 queue=pcq-upload/pcq-download name=fair-sharing

This ensures each IP address gets up to 1M upload and 2M download, regardless of how many connections they have.

Common Use Cases

1. ISP Customer Bandwidth Plans

# Residential 50/10 plan
/queue simple add target=192.168.100.0/24 max-limit=10M/50M name=residential-plan

# Business 100/100 plan with guaranteed 20M
/queue simple add target=10.10.0.0/24 limit-at=20M/20M max-limit=100M/100M name=business-plan

2. Guest Network Limitation

# Limit guest WiFi to prevent abuse
/queue simple add target=192.168.200.0/24 max-limit=5M/20M name=guest-wifi-limit

3. Critical Service Prioritization

# Guarantee bandwidth for VoIP server
/queue simple add target=192.168.1.50/32 limit-at=2M/2M max-limit=10M/10M priority=1 name=voip-server

# Limit bulk file transfers
/queue simple add packet-marks=bulk-transfer max-limit=5M/5M priority=8 name=bulk-limit

4. Fair Bandwidth Distribution

# Equal sharing among users with burst capability
/queue type add name=fair-pcq-down kind=pcq pcq-rate=10M pcq-classifier=dst-address pcq-burst-rate=50M pcq-burst-threshold=5M pcq-burst-time=10s
/queue type add name=fair-pcq-up kind=pcq pcq-rate=5M pcq-classifier=src-address

/queue simple add target=192.168.1.0/24 queue=fair-pcq-up/fair-pcq-down name=fair-users

Troubleshooting

Problem: Queue Shows No Traffic Despite Active Connections

Symptoms:

• Queue statistics show 0 bytes/packets
• Network traffic is flowing normally
• Queue appears correctly configured

Root Cause: FastTrack is bypassing the queue system.

Solution: Disable FastTrack for queued traffic:

# Check current FastTrack rules
/ip firewall filter print where action=fasttrack-connection

# Add exception before FastTrack rule
/ip firewall filter add chain=forward action=accept src-address=192.168.88.100 place-before=0
/ip firewall filter add chain=forward action=accept dst-address=192.168.88.100 place-before=0

# Or disable FastTrack entirely (impacts performance)
/ip firewall filter set [find action=fasttrack-connection] disabled=yes

Problem: Download Limits Not Working

Symptoms:

• Upload limits work correctly
• Download speeds exceed configured limits
• Queue shows upload traffic but minimal download traffic

Root Cause: Incorrect target specification or packet flow understanding.

Diagnosis:

# Check packet flow direction
/tool torch interface=ether2 duration=10

# Verify target matches actual traffic
/queue simple print stats

Solution: Ensure target specification matches the actual traffic direction:

# For a client at 192.168.1.100:
# Correct: target=192.168.1.100/32 (matches both src and dst)
# Wrong: target=192.168.1.100/32 interface=ether1 (conflicting direction)

Problem: Burst Not Working as Expected

Symptoms:

• Traffic never exceeds max-limit
• Burst parameters seem ignored
• Average rate calculations unclear

Diagnosis:

# Monitor burst statistics
/queue simple print stats-detail where name=your-queue

Common Issues:

1. burst-threshold too low: Set it between limit-at and max-limit
2. burst-time too short: Use 8-16 seconds for typical scenarios
3. Continuous high usage: Burst only works when average is below threshold

Solution:

# Properly configured burst example
/queue simple set your-queue burst-limit=50M/50M burst-threshold=8M/8M burst-time=8s/8s

Problem: Multiple Queues Conflicting

Symptoms:

• Unexpected bandwidth allocation
• Some queues not getting expected traffic
• Inconsistent performance

Root Cause: Queue order matters - first match wins.

Solution: Reorder queues from most specific to least specific:

# Check current order
/queue simple print

# Move specific queue before general one
/queue simple move specific-client-queue destination=0

Problem: Parent-Child Queue Issues

Symptoms:

• Child queues exceed parent limits
• Bandwidth not properly distributed
• Priority not working

Diagnosis:

# Check parent-child relationships
/queue simple print where parent!=none

Best Practices:

1. Parent max-limit should be ≥ sum of children max-limits
2. Parent limit-at should be ≥ sum of children limit-at
3. Set priorities only on child queues

Problem: PCQ Not Distributing Fairly

Symptoms:

• Some users getting more bandwidth than others
• PCQ sub-streams not visible
• Uneven distribution

Diagnosis:

# Check PCQ sub-streams
/queue simple print stats where name=your-pcq-queue
# Look for pcq-queues count

Common Issues:

1. Wrong classifier: Use dst-address for download, src-address for upload
2. Insufficient total bandwidth: PCQ rate × expected users should not exceed total
3. NAT interference: PCQ sees translated addresses, not original clients

Solution:

# Correct PCQ for post-NAT scenario
/queue type add name=pcq-lan-down kind=pcq pcq-rate=10M pcq-classifier=dst-address pcq-dst-address-mask=24

Performance Considerations

Hardware Acceleration

Simple Queues disable hardware acceleration, forcing all traffic through the CPU:

# Check if hardware offloading is active
/interface ethernet print where name=ether2
# Look for "auto-negotiation=yes" and "full-duplex=yes"

# Monitor CPU usage during high traffic
/system resource print

Impact:

• Reduced maximum throughput
• Increased CPU utilization
• Higher latency under load

Mitigation:

• Use powerful RouterBOARD models for high-bandwidth queuing
• Consider Queue Tree with hardware-capable queue types
• Implement queuing only where necessary

Memory Usage

Queue buffers consume RAM, especially with large queue sizes:

# Monitor memory usage
/system resource print

# Check queue buffer usage
/queue simple print stats-detail

Guidelines:

• Default queue sizes are usually sufficient
• Increase queue size only for high-latency links
• Monitor memory usage on devices with limited RAM

Scalability Limits

Simple Queues have practical limits:

• Processing overhead: Each packet checks every queue in order
• Rule count: Performance degrades with hundreds of queues
• Update frequency: Frequent queue modifications impact performance

Best Practices:

• Keep queue count reasonable (< 100 for most scenarios)
• Use PCQ for many similar users instead of individual queues
• Place most specific/active queues first in the list

Related Topics

Prerequisites

• IP Address Configuration - understand client addressing
• NAT Masquerade - NAT runs before queuing

Advanced QoS

• Queue Tree - hierarchical bandwidth management with packet marks
• Firewall Mangle - traffic classification for queue tree

Related Topics

• DHCP Server - identify clients for queuing
• Hotspot - per-user bandwidth with hotspot
• Torch - verify queue effectiveness

References

• MikroTik Queue Documentation
• Simple Queue Reference
• Queue Types and Algorithms
• HTB Algorithm Explanation
• PCQ Configuration Examples