В этом HOW-TO я вкратце попытась разъяснить как в GNU/Linux системах управлять трафиком.
Нам понадобится ядро с поддержкой QoS и (опционально) netfilter,
а так же userspace иструменты iproute2 и iptables.
Собираем ядро отвечая на вопросы y
TCP/IP networking (CONFIG_INET) [Y/n/?]y
IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [N/y/?] y
IP: policy routing (CONFIG_IP_MULTIPLE_TABLES) [N/y/?] (NEW) y
IP: use TOS value as routing key (CONFIG_IP_ROUTE_TOS) [N/y/?] (NEW) y
IP: large routing tables (CONFIG_IP_ROUTE_LARGE_TABLES) [N/y/?] (NEW) y
QoS and/or fair queueing (CONFIG_NET_SCHED) [N/y/?] y
CBQ packet scheduler (CONFIG_NET_SCH_CBQ) [N/y/m/?] (NEW) y
HTB packet scheduler (CONFIG_NET_SCH_HTB) [N/y/m/?] (NEW) y
The simplest PRIO pseudoscheduler (CONFIG_NET_SCH_PRIO) [N/y/m/?] (NEW) y
RED queue (CONFIG_NET_SCH_RED) [N/y/m/?] (NEW) y
SFQ queue (CONFIG_NET_SCH_SFQ) [N/y/m/?] (NEW) y
TBF queue (CONFIG_NET_SCH_TBF) [N/y/m/?] (NEW) y
QoS support (CONFIG_NET_QOS) [N/y/?] (NEW) y
Rate estimator (CONFIG_NET_ESTIMATOR) [N/y/?] (NEW) y
Packet classifier API (CONFIG_NET_CLS) [N/y/?] (NEW) y
TC index classifier (CONFIG_NET_CLS_TCINDEX) [N/y/m/?] (NEW) y
Routing table based classifier (CONFIG_NET_CLS_ROUTE4) [N/y/m/?] (NEW) y
Firewall based classifier (CONFIG_NET_CLS_FW) [N/y/m/?] (NEW) y
U32 classifier (CONFIG_NET_CLS_U32) [N/y/m/?] (NEW) y
О включении поддержки netfilter и процедуре компиляции ядра читайте
соответствующие HOWTO.
Я (и не только) придерживась мнения, что для построения иерархии
классов для управления полосой пропускания лучше испоьзовать HTB, неже
ли CBQ. CBQ содержит ряд параметров, которые необходимо эмпиречиски
получать для каждого конкретного случая.
Рассмотрим пример, в котором одному клиенту отводится гарантированая
полоса пропускания в 1mbit/s, другому полоса пропускания 4mbit/s и
выше, всем остальным 2mbit/s и выше. Для начала создадим с помощью HTB
классы :
$TC class add dev $DEVB parent 1: classid 1:1 htb rate 100mbit ceil 100mbit burst 15k
$TC class add dev $DEVB parent 1:1 classid 1:10 htb rate 64kbit ceil 64kbit burst 15k
$TC class add dev $DEVB parent 1:1 classid 1:20 htb rate 4mbit ceil 100mbit burst 15k
$TC class add dev $DEVB parent 1:1 classid 1:30 htb rate 2mbit ceil 100mbit burst 15k
Немного о параметре burst. Дело в том, что "железо" в каждый момент
времени может посылать только один пакет и только с определенной
скорость (100Mbit/s в случае fast ethernet). HTB эмулирует несколько
потоков (flow) посредством переключения между классами. Таким образом
параметр burst задает максимальный обьем данных данного класса, который
может быть пропущен через "железо" без переключения на другие классы.
Отсюда логически следует, что нельзя ставить параметр burst у дочерних
классов больше чем у родительских.
Далее мы должны присоеденить дисциплины для трафика
$TC qdisc add dev $DEVB parent 1:10 red min 1600 max 3210 burst 2 limit 32100 avpkt 1000
$TC qdisc add dev $DEVB parent 1:20 sfq perturb 10
$TC qdisc add dev $DEVB parent 1:30 sfq perturb 10
Этим мы сказали что "резать" трафик в классе 1:10 будем по алгоритму
RED(Random Early Detection), в остальных - по алгоритму SFQ. Параметры
для RED вычисляются следующим образом :
min = (задержка)*bandwidt(bits/s), burst= (2*min+max)/(3*avpkt)), limit= 10*max,
max > 2*min, avpkt 1000 для MTU 1500.
Несколько слов об алгоритмах управления трафиком.
TBF алгоритм пропускает пакеты с определенной заданной скоростью,
хороший выбор если вам просто нужно ограничить скорость на интерфесе.
Используемые параметры rate - нужная нам скорость, latensy -
максимальное время, которое пакет может проводить в очереди, burst
размер "ведра" для токенов в байтах, естественно чем больше вы задаете
rate, тем больше должно быть значение burst.
Пример, ограничение скорости на eth0 к которому подключен dsl модем :
Основным понятием SFQ является поток (flow), трафик разбивается на
достаточно большое количество FIFO очередей, которые переключаюсь по
кругу, таким образом не давая доминировать ни одной из них. Параметры
perturb время реконфигурации (???) и quantum - обьем данных
"выпускаемых" из потока за один раз (по умолчанию MTU, но!! ни в коем
случае не ставьте меньше).
Пример, псевдосправедливая раздача исходящего трафика с определенного интерфейса:
$TC qdisc add dev eth0 root sfq perturb 10
Парамерры для RED вычисляются следующим образом min = (задержка)*bandwidt(bits/s),
burst= (2*min+max)/(3*avpkt)), limit= 10*max, max > 2*min, avpkt 1000 для MTU 1500.
Дальше надо распределить трафик по классам , с помощью tc filter ,
например так :
$TC filter add dev $DEVB protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.15.132 flowid 1:10
отправляем весь трывик у которого получатель 192.168.15.132 в класс 1:10.
Можно распределить по классам предварительно помеченные с помощью
iptables покеты следующим образом:
$iptables -A OUTPUT -t mangle -d 192.168.15.129 -j MARK --set-mark 20
$tc filter add dev $DEVB protocol ip parent 1:0 prio 2 handle 20 fw classid 1:20
Можно использовать более сложные правила для пометки трафика, например :
$iptables -A OUTPUT -t mangle -p tcp -d 192.168.15.129 --sport 80 -j MARK --set-mark 20
Обязательно проверьте с помощью $iptables -L -n -v -t mangle как
маркируюся пакеты, возможно происходит не то что вы ожидали.
Резюмируем
1. Cначала создаем иерархию классов #tc class add ...
2. Добавляем дисциплины #tc qdisc add ...
3. Распределяем трафик по классам #tc filter add ...
(c), Sheshka Alexey, 2002 <sheshka@yahoo.com>
Перепечатка в бумажных изданиях без согласия автора запрещена.
Source Quench rfc777
319 Прочтений • [Краткое руководство об управлении трафиком в GNU/Linux (linux qos traffic iptables iproute2 bandwidth shaper)] [08.05.2012] [Комментариев: 0]
Vova
