шейпим трафик, используя tc

trafic control (tc) - один из самых труднопонимаемых для меня инструментов. Помогите, пожалуйста, разобраться.
Из того, что нашарил в рунете, самые вменяемые для понимания статьи:
http://www.xakep.ru/post/49421/default.asp?print=true
http://unixforum.org/index.php?showtopic=123039

На сколько я понял, в tc cуществуют очереди, классы и фильтры. Очереди - это компоненты ядра, ответственные за очерёдность прохождения пакетов. Пакеты в очереди можно задерживать - это и есть шейпинг.

Просматриваю очереди пакетов на сервере:

gadminko@gate:~$ sudo tc qdisc show
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Все три сетевых интерфейса управляются очередями pfifo_fast, которая является неуправляемой. А наша задача - получить возможность управлять трафиком, заменив pfifo_fast на htb, что и делаю:

adminko@gate:~$ sudo tc qdisc add dev eth0 root handle 1: htb default 20
adminko@gate:~$ sudo tc qdisc add dev eth1 root handle 1: htb default 20
adminko@gate:~$ sudo tc qdisc add dev eth2 root handle 1: htb default 20
adminko@gate:~$ sudo tc class add dev eth0 parent 1: classid 1:1 htb 100mbps ceil 100mbps
adminko@gate:~$ sudo tc class add dev eth1 parent 1: classid 1:1 htb 100mbps ceil 100mbps
adminko@gate:~$ sudo tc class add dev eth2 parent 1: classid 1:1 htb 100mbps ceil 100mbps

Это я делаю как написано в руководстве, на которое сослался. При этом, к каждой очереди, классу или фильтру можно ссылаться указывая его хэндл в формате major:minor, символьное именование не предусмотрено.

И тут возникает первый вопрос: почему при подключении очередей htb мы указали умолчальный класс 20, но последующие команды описывают классы с хэндлом 1:1, а не 1:20?
Дальше, смотрим что получилось:

adminko@gate:~$ sudo tc qdisc show
qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 20 direct_packets_stat 142
qdisc htb 1: dev eth1 root refcnt 2 r2q 10 default 20 direct_packets_stat 332
qdisc htb 1: dev eth2 root refcnt 2 r2q 10 default 20 direct_packets_stat 42
adminko@gate:~$ sudo tc class show dev eth0
class htb 1:1 root prio 0 rate 800000Kbit ceil 800000Kbit burst 1600b cburst 1600b
adminko@gate:~$ sudo tc class show dev eth1
class htb 1:1 root prio 0 rate 800000Kbit ceil 800000Kbit burst 1600b cburst 1600b
adminko@gate:~$ sudo tc class show dev eth2
class htb 1:1 root prio 0 rate 800000Kbit ceil 800000Kbit burst 1600b cburst 1600b

Собственно вопросы: почему 800000Kbit, а не 100000 и даже не 102400? Что такое: ceil, burst, cburst, refcnt, r2q?
Теперь о задачах. eth0 - это Интернет, к eth1 подключены отделы, к eth2 - арендаторы. Задача - арендаторам сделать трафик 10Мбит/c, отделам - 5Мбит/c, привелегированным отделам - 30Мбит/с.

adminko@gate:~$ sudo tc class add dev eth2 parent 1:1 classid 1:14 htb rate 10mbps
adminko@gate:~$ sudo tc qdisc add dev eth2 parent 1:14 handle 40:0 sfq perturb 10
adminko@gate:~$ sudo tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.48.0/24 flowid 1:14

Вопросы: почему класс 1:14 должен являться дочерним классом класса 1:1, а не расти из корня 1:0?
Зачем тут вообще "tc qdisc add", и как она имея мажорный номер 0, может находиться под классом 1:14, ведь очереди - это самый высший уровень иерархии?

http://samag.ru/archive/article/134 вот тут более-менее изложены основы.

emerge world
Прочитал. Но не всё понятно. Путаю очереди и классы.

Вот например, если взять такую простую сеть:

Для user1 и user2 входящий интернет-трафик нужно ограничить до 10 Мбит/c, для user3 - до 15 Мбит/с. tc позволяет шейпить только исходящий трафик, поэтому входящий трафик для узлов локалки представляем как исходящий для интерфейса eth1.
То есть создаём root-очередь 1: для eth1, потом эта очередь будет раздваиваться на очереди 1:2, 1:3 и 1:50. В этих очередях пакеты двигаются со скоростью 10, 10 и 15 Мбит/с соответственно. В родительской очереди пакеты должны двигаться быстрее, чтобы разделение потоков работало, так что для 1: скорость должна быть 100 Мбит/с, то есть максимальная скорость передачи для ethernet. То есть псевдодерево должно быть таким:


Но скорость описывается не в очередях, а в классах, то есть нужно создать класс 1:1, в котором как раз должно быть 100 Мбит/с, а классы 1:2, 1:3 и 1:50 должны расти из него. Но посколько user1 и user2 должны иметь одинаковую скорость и входят в одну подсеть 192.168.0.0/29, то можно ограничиться классами 1:2 и 1:50. Правда в них шейпится только трафик где исходящий адрес пакетов - адрес хостов интернета. Если исходящий - gate (пакет локальный) то должно быть 100 Мбит/с, для этого создаётся класс 1:99. То есть псевдодерево должно быть таким:

Потом, следуя написаному, нужно добавить очереди 2:, 50: и 99:, но тут непонятно: в корне очередь является родителем класса, а тут - наоборот. Пакеты управляются очередями, но скорость классами.

Скажите, такой скрипт правилен:

#!/bin/bash
## Очистка очередей
tc qdisc del dev eth0 root htb
tc qdisk del dev eth1 root htb
## Создание корневых очередей и классов
tc qdisc add dev eth0 root handle 1: htb default 99
tc qdisc add dev eth1 root handle 1: htb default 99
tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit  burst 1800000
tc class add dev eth1 parent 1:1 classid 1:99 htb rate 100mbit ceil 100mbit  burst 1800000
## Класс для user1 и user2
tc class add dev eth1 parent 1:1 classid 1:2 htb rate 10mbit ceil 10mbit  burst 16000
tc filter add dev eth1 parent 1: protocol ip match ip dst 192.168.0.0/29 flowid 1:2
## Класс для user3
tc class add dev eth1 parent 1:1 classid 1:3 htb rate 15mbit ceil 15mbit  burst 21000
tc filter add dev eth1 parent 1: protocol ip match ip dst 192.168.0.50 flowid 1:3

Для юзера 3 правило filter можно добавить перед правилом filter для юзера 2 и тогда всех юзеров можно закинуть в одну подсеть. На parent 1:1 classid 1:2 хорошо бы еще добавить sfq, что бы полоса равномерно раздавала трафик между всеми оставшимися юзерами.