[email protected]

How to test if QoS is working on your VyOS router

To test if QoS is working on your VyOS router, you can use several approaches from clients 192.168.51.100 (LAN) or 192.168.100.11 (DMZ):

1. View QoS Statistics on VyOS Router

First, SSH into the VyOS router and check QoS stats:

# Show QoS policy statistics
show qos interface eth2

# Show detailed class statistics
show queuing interface eth2

# Monitor in real-time
watch -n 1 'show qos interface eth2'

This shows packets/bytes per class and dropped packets.

2. Generate Traffic for Different QoS Classes

Class 10 (Gaming/VoIP – Highest Priority)

From client, test with ports that match class 10:

# Install iperf3 on client and remote server
iperf3 -c <remote-server> -p 3478 -t 60 -b 100M
iperf3 -c <remote-server> -p 8801 -t 60 -b 100M

Class 20 (Video Streaming – HTTP/HTTPS)

# Generate HTTPS traffic
curl -O https://speed.hetzner.de/100MB.bin

# Or continuous download
wget --no-check-certificate https://speed.hetzner.de/1GB.bin

Class 40 (Bulk/Torrents – Lowest Priority)

iperf3 -c <remote-server> -p 6881 -t 60 -b 500M
iperf3 -c <remote-server> -p 51413 -t 60

Default Class (Unmatched Traffic)

# Use a non-matched port
iperf3 -c <remote-server> -p 5000 -t 60 -b 200M

3. Simultaneous Load Testing

To verify priorities work under congestion, run multiple tests simultaneously:

# Terminal 1 (High priority - Gaming)
iperf3 -c <remote-server> -p 3478 -t 120 -b 800M

# Terminal 2 (Medium priority - HTTPS)
iperf3 -c <remote-server> -p 443 -t 120 -b 800M

# Terminal 3 (Low priority - Torrent)
iperf3 -c <remote-server> -p 6881 -t 120 -b 800M

The high-priority traffic should get better throughput/latency.

4. Monitor Packet Classification

On the VyOS router:

# Show which packets are matching which classes
sudo tc -s class show dev eth2

# Show filter matches
sudo tc -s filter show dev eth2

# Real-time monitoring
watch -n 1 'sudo tc -s class show dev eth2'

5. Verify Bandwidth Limits

Generate traffic exceeding the 2500mbit total bandwidth to see shaping in action:

# From client, saturate the connection
iperf3 -c <remote-server> -p 80 -P 10 -t 60

Monitor on router – you should see throughput capped around 2500mbit.

6. Test Latency Under Load

# Terminal 1: Generate heavy load (torrents)
iperf3 -c <remote-server> -p 6881 -t 300 -b 1000M

# Terminal 2: Ping to test latency
ping 8.8.8.8 -i 0.2

Compare latency with and without the torrent traffic. QoS should keep latency reasonable.

Key Indicators QoS is Working: ✅ Different classes show traffic in show qos interface eth2
✅ High-priority traffic maintains low latency under load
✅ Total bandwidth is shaped to ~2500mbit
✅ Low-priority bulk traffic gets deprioritized when congestion occurs

Looking at your output, you’ve discovered a VyOS bug/quirk in how it calculates ceiling values for QoS classes. Here’s what’s happening:

The Problem

Your configuration specifies:

  • Root bandwidth: 2500Mbit
  • Class ceilings as percentages: 80%, 90%, 100%

But tc shows ceiling values like:

  • Class 1:a (Class 10): ceil 8Gbit (should be 80% × 2500 = 2000Mbit)
  • Class 1:14 (Class 20): ceil 9Gbit (should be 90% × 2500 = 2250Mbit)
  • Class 1:1e (Class 30): ceil 10Gbit (should be 100% × 2500 = 2500Mbit)

VyOS appears to be calculating ceilings based on 10Gbit instead of your configured 2500Mbit:

  • 80% × 10Gbit = 8Gbit ✗
  • 90% × 10Gbit = 9Gbit ✗
  • 100% × 10Gbit = 10Gbit ✗

Why This Happens

This is likely related to:

  1. Default interface speed detection – VyOS may be detecting eth2’s hardware capability as 10Gbit
  2. Bug in percentage calculation – VyOS is using the interface’s physical speed instead of the configured policy bandwidth
  3. One class is correct – Class 1:29 shows ceil 2500Mbit correctly, which suggests inconsistent handling

Does It Actually Matter?

Not really, because:

The root class (1:1) correctly shows:

class htb 1:1 root rate 2500Mbit ceil 2500Mbit

Since HTB (Hierarchical Token Bucket) is hierarchical, child classes cannot exceed the parent’s ceiling. Even though child classes have inflated ceil values, they’re still constrained by the root 2500Mbit limit.

Think of it like this:

  • Root says: “Maximum allowed = 2500Mbit”
  • Child says: “I want up to 10Gbit”
  • Root responds: “Too bad, you get 2500Mbit max”

How to Fix/Verify

Option 1: Use Absolute Values Instead of Percentages

delete qos policy shaper WAN-OUT class 10 ceiling
delete qos policy shaper WAN-OUT class 20 ceiling
delete qos policy shaper WAN-OUT class 30 ceiling
delete qos policy shaper WAN-OUT class 40 ceiling
delete qos policy shaper WAN-OUT default ceiling

set qos policy shaper WAN-OUT class 10 ceiling '2000mbit'
set qos policy shaper WAN-OUT class 20 ceiling '2250mbit'
set qos policy shaper WAN-OUT class 30 ceiling '2500mbit'
set qos policy shaper WAN-OUT class 40 ceiling '2500mbit'
set qos policy shaper WAN-OUT default ceiling '2500mbit'
commit

Option 2: Verify It’s Actually Working

Test that total throughput doesn’t exceed 2500Mbit:

# Generate massive traffic from client
iperf3 -c <remote-server> -P 20 -t 60 -b 5000M

# On router, monitor
watch -n 1 'sudo tc -s class show dev eth2 | grep -A2 "class htb 1:1"'

The root class will show the actual sent rate, which should cap around 2500Mbit.

Conclusion

This is a cosmetic bug in VyOS’s QoS configuration translation. Your traffic is still properly shaped to 2500Mbit at the root level. If you want cleaner output, use absolute ceiling values instead of percentages.

Leave a Reply