qosstats and wshaper

• qosstats displays QoS statistics from Linux TC in a summary table.
• wshaper is a heavily customised version of the WonderShaper QoS script.

qosstats

You can use this utility to display the traffic rates and other salient details of QoS queues in an easy-to-read table form. For example:

[chris@microserver qosstats]$ ./qosstats eth0
eth0
Class Paren Prio  Rate     Ceil  Burst      Sent  Dropped  Backlog   kbps  Pps
==============================================================================
1:1   -     -   100000   100000    6Kb     18372        0    0b/0p   1187  116
1:10  1:1   -    14400    14400    6Kb     18372        0    0b/0p   1187  116
1:11  1:1   0   100000   100000    6Kb         0        0    0b/0p      -    -
1:110 1:10  1     3600    14400    6Kb      2907        0    0b/0p     10   19
1:120 1:10  2        0    14400    2Kb         0        0    0b/0p      -    -
1:130 1:10  3        0     9000    2Kb     15465        0    0b/0p   1176   98
1:140 1:10  3        0     4500    2Kb         0        0    0b/0p      -    -

This tells you that:

• 1:1 is the root class
• 1:10 and 1:11 descend from it
• 1:11 has a much higher bandwidth limit (100 MBps, probably local traffic)
• 1:10 has four classes under it: 1:110 to 1:140
• 1:110 has a the highest priority (1), a guaranteed rate of 3.6 MBps, and maximum rate of 14.4 MBps.
• 1:110 has a current rate of 10 kbps and 19 pps.

This is a typical traffic class layout generated by a wshaper script such as the included one, where 1:110 is used for highest-priority Internet traffic (pings and VoIP) and 1:140 is the lowest priority (backups).

You can watch the statistics live using the watch command:

watch qosstats eth0

Watching the external interface (eth0 in this case) only shows queue status for uploaded traffic. Be sure to monitor the inside interface for downloaded traffic as well.

wshaper

You can use this utility to generate queues on the internal and external interfaces, to monitor and prioritise traffic according to your needs. The script is an example and you will need to customise it.

You will need to set DDEV and UDEV to your downlink (inside) and uplink (outside) devices respectively.

Then set DOWNLINK and UPLINK to about half the bandwidth that you expect to get, and play with them while downloading and uploading large amounts until you get good responsiveness to pings (low latency). You'll need to rerun the wshaper script after every change. watch the output of qosstats and a ping while you do it.

Typically you would get that at 60-80% of maximum capacity, depending on how your connection works. Getting closer to your theoretical maximum is likely to increase delays of all traffic; reducing limits reduces the worst-case delays while also reducing your maximum download and upload speed; therefore you have to choose your tradeoff carefully to suit your needs.

Tests done on the firewall itself will not reveal the effects of traffic shaping on the inside interface DDEV, so you will need to control a computer behind the firewall, both for traffic generation and measurement, to conduct these tests.

The script demonstrates:

• Querying a pmacct SQL database for traffic downloaded and uploaded by each host over a period, and severely restricting or blocking hosts that exceed their quotas.

• Using different quotas at different times of day (thanks Virgin Media).

• Using the iptables CLASSIFY target to set QoS classes for traffic, instead of the tc filter command.

• Classifying based on protocol (e.g. ICMP), source and destination hosts and ports, and TOS (type of service) flags.

• Using different queues with different priorities and limits for ICMP (pings), web, interactive SSH and backups over SSH.

• Using HTB to fairly share bandwidth between classes.

• Using SFQ to fairly share bandwidth between individual connections within a class.