Ключевые слова:qos, iptables, traffic, limit, netfilter, iproute2, htb, (найти похожие документы)
From: Sheshka Alexey <sheshka@yahoo.com.>
Date: Mon, 3 Jan 2006 18:21:07 +0000 (UTC)
Subject: Управление трафиком используя iproute2
Оригинал: http://linuxadmin.chat.ru/pulsar/QoS.txt
В этом 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 qdisc add dev $DEVB root handle 1: htb default 30
$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 модем :
$TC qdisc add dev eth0 root tbf rate 128kbit latency 50ms burst 1500
Основным понятием 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 <sheshka@yahoo.com.>, 2002
Перепечатка в бумажных изданиях без согласия автора запрещена.
