Конфигурация практически идентична вышеприведенному примеру:

# tc qdisc add dev eth0 root handle 1: htb default 30

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k

# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k

Автор рекомендует устанавливать дисциплину SFQ для этих классов:

# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

Добавим фильтры, которые будут выполнять классификацию трафика:

# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20

В результате получаем ясную и понятную конфигурацию — никаких малопонятных чисел, никаких недокументированных параметров.

В HTB все выглядит достаточно прозрачно — классы 10: и 20: имеют гарантированную пропускную способность, при наличии свободной части пропускной способности они заимствуют ее в отношении 5:3.

Неклассифицированый трафик будет отнесен к классу 30:, который имет достаточно небольшую ширину, но может заимствовать незанятую часть канала.

64 порта
ending is 2^16=65536
mask is (2^16)-64=65472 -> convert to hex -> FFC0
32 порта
mask is (2^16)-32=65504 > convert to hex -> FFE0

маски портов