Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

• Название: Linux Advanced Routing & Traffic Control HOWTO
• Автор: Bert Hubert
• Жанр: Программное обеспечение

Оригинальную версию документа вы найдете по адресу http://lartc.org/.

Практическое руководство по применению iproute2 (и в меньшей степени netfilter) для управления трафиком.

---

Уровень приоритета TC_PRIO.. рассчитывается исходя из значения поля TOS (за дополнительной информацией о значениях приоритета пакета, обращайтесь к разделу pfifo_fast).

Теперь создадим классы, через которые пойдет интерактивный и объемный трафик:

# tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 10Mbit \

 rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20 \

 avpkt 1000 split 1:0 defmap c0

# tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 10Mbit \

 rate 8Mbit allot 1514 cell 8 weight 800Kbit prio 7 maxburst 20 \

 avpkt 1000 split 1:0 defmap 3f

В данном случае "узлом разбиения" назначается дисциплина 1:0, это та точка, где будет делаться выбор. Число 0xC0 в двоичном представлении имеет вид 11000000, а 0x3F — 00111111, таким образом оба класса перекрывают весь диапазон возможных приоритетов. Первому классу будут соответствовать пакеты, приоритеты которых имеют 6 и/или 7 биты в установленном состоянии, что соответствует интерактивному и управляющему трафику. Ко второму классу будут отнесены все остальные пакеты.

Таблица выбора для узла 1:0 теперь будет иметь следующий вид:

приоритет класс 0 1:3 1 1:3 2 1:3 3 1:3 4 1:3 5 1:3 6 1:2 7 1:2

Кроме того, можно изменять приоритеты отдельных видов трафика. Для этого используется команда вида: tc class change, например, чтобы повысить приоритет трафика best effort и классифицировать его, как принадлежащий классу 1:2, нужно дать следующую команду:

# tc class change dev eth1 classid 1:2 cbq defmap 01/01

В этом случае, таблица выбора будет иметь следующий вид:

приоритет класс 0 1:2 1 1:3 2 1:3 3 1:3 4 1:3 5 1:3 6 1:2 7 1:2

FIXME: Корректность работы команды tc class change не проверена. Выводы были сделаны исключительно на основе изучения исходных текстов.

9.5.5. Hierarchical Token Bucket

Мартин Девера (Martin Devera) aka <devik> справедливо отмечает, что CBQ слишком сложна и слабо оптимизирована для большинства типичных ситуаций. Его подход более точно соответствует конфигурациям, когда необходимо распределить заданную полосу пропускания между различными видами трафика на полосы гарантированной ширины, с возможностью заимствования.

HTB работает точно так же, как и CBQ, но, в отличие от последней, принцип работы основан не на вычислении времени простоя, а на определении объема трафика, что полностью соответствует названию Token Bucket Filter. Эта дисциплина имеет незначительное число параметров настройки, которые достаточно хорошо описаны на сайте http://luxik.cdi.cz/~devik/qos/htb/.

Хотя конфигурирование HTB — задача достаточно сложная, тем не менее конфигурации хорошо масштабируются. В случае же с CBQ процесс конфигурирования становится слишком сложным даже в самых простых случаях! HTB3 теперь стала частью ядра (начиная с версий 2.4.20-pre1 и 2.5.31). Однако, вам может потребоваться пропатченная версия утилиты tc: старший номер версии htb в ядре и пользовательских утилит должны совпадать, в противном случае tc откажется работать с htb.

Если у вас установлено достаточно свежее или пропатченное ядро, вам определенно стоит посмотреть в сторону HTB!

9.5.5.1. Пример конфигурации.

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

# 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:, который имет достаточно небольшую ширину, но может заимствовать незанятую часть канала.

9.6. Классификация пакетов с помощью фильтров.

Для классификации того или иного пакета, всякий раз вызывается так называемая "цепочка классификации". Эта цепочка состоит из всех фильтров, присоединенных к полноклассовой дисциплине.

Вернемся к дереву:

                   root 1:

                      |

                    _1:1_

                   /  |  \

                  /   |   \

                 /    |    \

               10:   11:   12:

              /   \       /   \

           10:1  10:2   12:1  12:2

Когда пакет необходимо поставить в очередь, проверяется каждая ветвь в цепочке фильтров. Например, некоторый пакет мог бы быть направлен фильтром 1:1 в класс 12: и далее в 12:2.

Фильтр, который сразу отправляет пакет в 12:2, мог бы быть сразу присоединен к 1:1, но в этом случае пакет минует дополнительные проверки, которые могли бы быть сделаны в 12:.

Вы не можете выполнять фильтрацию в обратном порядке, только вниз! Кроме того, все фильтры в HTB должны присоединяться к корню!

Повторюсь еще раз. Пакеты могут фильтроваться (классифицироваться) только в направлении сверху-вниз.

9.6.1. Ряд простых примеров фильтрации.

Для начала продемонстрируем самый обычный случай, который, к счастью, достаточно прост. Допустим, что у нас имеется дисциплина PRIO, с дескриптором 10:, которая содержит три класса и нам нужно весь трафик, отправляемый на 22 порт и с 80 порта, отдать в самую высокоприоритетную полосу, тогда набор фильтров мог бы выглядеть так:

# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \

 ip dport 22 0xffff flowid 10:1

# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \

 ip sport 80 0xffff flowid 10:1

# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2

О чем говорят эти строки? Они говорят: "Присоединить к eth0, к узлу 10:, фильтр u32, с приоритетом 1, который отбирает пакеты, направляемые на порт 22, и передает их в полосу 10:1". Аналогичное высказывание делается относительно пакетов, отправленных с порта 80. И последняя строка говорит о том, что весь неклассифицированный трафик должен отправляться в полосу 10:2.

Вы обязательно должны указывать имя сетевого интерфейса, поскольку каждый из них имеет свое уникальное пространство имен дескрипторов.

Отбор пакетов по IP-адресам выполняется аналогичным образом:

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \

 match ip dst 4.3.2.1/32 flowid 10:1

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \

 match ip src 1.2.3.4/32 flowid 10:1

# tc filter add dev eth0 protocol ip parent 10: prio 2 \

 flowid 10:2

В этой конфигурации весь трафик, идущий на хост 4.3.2.1 и с хоста 1.2.3.4, ставится в очередь с наивысшим приоритетом.

Допускается смешивать проверку IP-адреса и номера порта:

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.1/32 \

 match ip sport 80 0xffff flowid 10:1

9.6.2. Наиболее употребимые способы фильтрации.

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

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..

Это так называемый селектор u32, который может выполнять отбор пакетов по любой его части.

По IP-адресу

По исходящему адресу: match ip src 1.2.3.0/24, по адресу назначения: match ip dst 4.3.2.0/24. Чтобы отобрать пакеты, отправляемые с/на единственный узел сети нужно указать сетевую маску /32 или вообще опустить ее.

По номеру порта

Исходящий порт: match ip sport 80 0xffff, порт назначения: match ip dport 80 0xffff.

По типу протокола, из семейства IP (tcp, udp, icmp, gre, ipsec)

Номера протоколов вы найдете у себя, в файле /etc/protocols . Например, отбор ICMP-пакетов (номер протокола icmp – 1) можно выполнить командой match ip protocol 1 0xff.