Шейпер для больших сетей
Шейпер для больших сетей (IPv4/IPv6) средствами iptables, ipset, tc
Особенности работы с большими сетями
В случае, если необходимо назначать индивидуальную скорость для сотен и тысяч адресов в сети, встроенный в etcnet инструментарий eqos становится мало пригодным. По той причине, что для отработки одного правила, в shell-скриптах производится десятки вызовов внешних программ и других скриптов. В результате останов и запуск сайтов с настройками для 3 тыс. классов может растянуться до получаса. В eqos из etcnet фильтры tc создаются линейного типа. В этом случае пакет будет обходить все правила фильтрации, пока не попадет на подходящий, либо не будет отправлен в фильтр по-умолчанию. При количестве правил фильтрации в несколько тысяч, и трафике в десятки тысяч пакетов в секунду, растет загрузка CPU системы и параллельно растут задержки прохождения транзитных пакетов. Это, в свою очередь, отрицательно влияет на комфортность работы с сетью. Аналогичные последствия и при злоупотреблении линейными правилами фильтрации в iptables/ip6tables.
Поэтому не используем eqos, сводим до минимума количество правил в iptables/ip6tables и в tc отказываемся от линейных фильтров.
В случае сети, в которой используется только IPv4, фильтры tc можно построить на основе хэш-таблиц
Предварительные требования к системе
В системе должен быть установлены пакеты
- iproute2-3.8.0-alt1 и новее;
- ipset-6.23-alt1 и новее;
- kernel-modules-ipset-*-6.24-alt1 и новее;
- iptables-1.4.21-alt1.M70P.1 и новее;
Создание дисциплин, классов и очередей
Так как управление трафиком для сотен и тысяч адресов в ручном режиме никто в здравом уме делать не будет, все приведенные здесь конфигурационные файлы есть результат выполнения сторонних программ и скриптов, если это особо не указано. Все параметры для tc и ipset загружаются в batch-режиме.
Итак, в качестве корневой дисциплины была выбрана hfsc, как более экономная к процессорному времени, и ее реализация в ядре linux не имеет global-locks, в отличии от htb, в результате чего нагрузка эффективно распределяется по всем процессорным ядрам в системе.
Пример batch-файла для tc:
/tmp/shape-tc.hfsc: # bondEXT - интерфейс в сторону мира # bondINT - интерфейс в сторону клиентов # # Чистим корневую дисциплину от всех предыдущих настроек qdisc del dev bondEXT root qdisc del dev bondINT root # назначаем корневую дисциплину, и определяем класс по-умолчанию для трафика, не попавшего ни в один определеный класс qdisc add dev bondEXT root handle 1: est 1sec 8sec hfsc default ffff qdisc add dev bondINT root handle 1: est 1sec 8sec hfsc default ffff # создаем корневой класс и определяем его параметры class add dev bondEXT parent 1: classid 1:1 est 1sec 8sec hfsc sc rate 2Gbit ul rate 2Gbit class add dev bondINT parent 1: classid 1:1 est 1sec 8sec hfsc sc rate 2Gbit ul rate 2Gbit # создаем клдасс по-умолчанию для трафика, не попавшего в определенный класс # !!!! ВАЖНО!!!! этот класс, как и фильтр по-умолчанию должен быть создан. filter add dev bondEXT parent 1: protocol ip prio 1000 u32 match u32 0 0 classid 1:ffff filter add dev bondINT parent 1: protocol ip prio 1000 u32 match u32 0 0 classid 1:ffff class add dev bondEXT parent 1: classid 1:ffff est 1sec 8sec hfsc sc umax 1500 dmax 150ms rate 1000kbit ul rate 100Mbit class add dev bondINT parent 1: classid 1:ffff est 1sec 8sec hfsc sc umax 1500 dmax 150ms rate 1000kbit ul rate 100Mbit qdisc add dev bondEXT parent 1:ffff handle ffff: pfifo limit 50000 qdisc add dev bondINT parent 1:ffff handle ffff: pfifo limit 50000
Пример правил для непосредственно управляемых адресов:
class add dev bondINT parent 1: classid 1:b est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 92160kbit ul rate 92160kbit qdisc add dev bondINT parent 1:b handle b: pfifo limit 200 class add dev bondEXT parent 1: classid 1:b est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 92160kbit ul rate 92160kbit qdisc add dev bondEXT parent 1:b handle b: pfifo limit 200 # class add dev bondINT parent 1: classid 1:c est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 2048kbit ul rate 2048kbit qdisc add dev bondINT parent 1:c handle c: pfifo limit 200 class add dev bondEXT parent 1: classid 1:c est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 2048kbit ul rate 2048kbit qdisc add dev bondEXT parent 1:c handle c: pfifo limit 200 # class add dev bondINT parent 1: classid 1:d est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 20480kbit ul rate 20480kbit qdisc add dev bondINT parent 1:d handle d: pfifo limit 200 class add dev bondEXT parent 1: classid 1:d est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 20480kbit ul rate 20480kbit qdisc add dev bondEXT parent 1:d handle d: pfifo limit 200 ... class add dev bondINT parent 1: classid 1:d44 est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 30720kbit ul rate 30720kbit qdisc add dev bondINT parent 1:d44 handle d44: pfifo limit 200 class add dev bondEXT parent 1: classid 1:d44 est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 30720kbit ul rate 30720kbit qdisc add dev bondEXT parent 1:d44 handle d44: pfifo limit 200
Классом 1:b назначена скорость 90Mbit, 1:c - 2Mbit, 1:d - 20Mbit и так далее вплоть до 1:d44 - 30Mbit. Обратите внимание, что в tc определения для классов, очередей и фильтров задаются в шестнадцатиричной системе в диапазоне 1-ffff.
Классификация трафика
Классифицировать трафик можно несколькими способами. Методы u32 match ip dst|src и handle MARK fw flowid нам не подходят, особенно второй метод, когда пакет анализируется два раза - один раз в iptables, когда выставляется MARK, и второй раз, когда помаркорованный пакет вторично анализируется в фильтре tc. Более производителей метод с использованием хэш-таблиц, более подробно можно почитать тут - [1]. Но этот метод подходит только когда в сети используется исключительно IPv4. Отдельно для IPv6 хэштаблицы не реализованы, а обходные методы не обеспечивают должной гибкости и простоты понимания для человека.
Поэтому был использован третий способ.
В ipset, начиная с версии 6.22 была добавлена очень полезный инструмент - оперированием структурой skb на основании правил iptables/ip6tables. Теперь логику классификации можно вынести в правила iptables и ipset.
Для удобства, здесь используется функционал etcnet.
- Создаем сеты, в которые будем вносить адреса:
IPv4
/etc/net/ifaces/default/fw/ipset/nethash/shaper4:
family inet skbinfo
IPv6
/etc/net/ifaces/default/fw/ipset/nethash/shaper6:
family inet6 skbinfo
- Создаем правила iptables, которые будут производить классификацию трафика:
IPv4
/etc/net/ifaces/default/fw/iptables/mangle/POSTROUTING:
-o bondEXT -j SET --map-set shaper4 src --map-prio
-o bondINT -j SET --map-set shaper4 dst --map-prio
IPv6
/etc/net/ifaces/default/fw/ip6tables/mangle/POSTROUTING:
-o bondEXT -j SET --map-set shaper6 src --map-prio
-o bondINT -j SET --map-set shaper6 dst --map-prio
- С помощью стороннего скрипта генерируем batch-файл для ipset такого вида:
/tmp/shape-set.txt: flush shaper4 flush shaper6 # add shaper4 172.16.17.196/32 skbprio 1:b # add shaper4 172.16.17.220/32 skbprio 1:c # add shaper4 172.16.1.2/32 skbprio 1:d add shaper4 172.16.1.5/32 skbprio 1:d add shaper4 172.16.1.10/32 skbprio 1:d add shaper4 172.16.1.12/32 skbprio 1:d add shaper4 172.16.1.14/32 skbprio 1:d add shaper4 172.16.1.31/32 skbprio 1:d add shaper4 172.16.1.103/32 skbprio 1:d add shaper4 172.16.1.128/32 skbprio 1:d add shaper4 172.16.1.184/32 skbprio 1:d add shaper4 172.16.2.115/32 skbprio 1:d add shaper4 172.16.5.198/32 skbprio 1:d add shaper4 172.16.6.38/32 skbprio 1:d add shaper4 172.16.6.58/32 skbprio 1:d add shaper4 172.16.6.69/32 skbprio 1:d add shaper4 172.16.9.228/32 skbprio 1:d add shaper4 172.16.10.208/32 skbprio 1:d add shaper4 172.16.11.67/32 skbprio 1:d add shaper4 172.16.11.68/32 skbprio 1:d add shaper4 172.16.11.147/32 skbprio 1:d add shaper4 172.16.15.213/32 skbprio 1:d add shaper4 172.16.15.214/32 skbprio 1:d add shaper4 172.16.17.75/32 skbprio 1:d ... add shaper4 172.16.17.231/32 skbprio 1:d44 add shaper6 XXXX:4680:26:0:0:0:0:202/124 skbprio 1:d44
обратите внимание, что адреса IPv4 заносятся в сет shaper4, адреса для IPv6 - в shaper6. В этих сетах и происходит присвоение трафику определенные классы. Соответствие идентификаторов классов в batch-файлах tc и ipset возлагается на внешний скрипт генерации.
Загрузка параметров в систему
Загрузка правил производится по крону, запуском такого скрипта:
/usr/local/sbin/shaper.sh:
#!/bin/sh
ВЫЗОВ_СКРИПТА_ГЕНЕРИРУЮЩЕГО_shape-tc.hfsc_И_shape-set.txt
if [ ! -f /tmp/shape-tc.old ]; then
touch /tmp/shape-tc.old
fi
if [ ! -f /tmp/shape-set.old ]; then
touch /tmp/shape-set.old
fi
# данные меняются не так часто, поэтому реальная я перезагрузка
# производится только когда что-то поменялось
T=`diff /tmp/shape-tc.old /tmp/shape-tc.hfsc`
if [ "$T" != "" ]
then
/sbin/tc -force -batch /tmp/shape-tc.hfsc > /dev/null 2>&1
/sbin/ipset -! restore < /tmp/shape-set.txt > /dev/null 2>&1
mv -f /tmp/shape-tc.hfsc /tmp/shape-tc.old
mv -f /tmp/shape-set.txt /tmp/shape-set.old
else
T=`diff /tmp/shape-set.old /tmp/shape-set.txt`
if [ "$T" != "" ]
then
/sbin/tc -force -batch /tmp/shape-tc.hfsc > /dev/null 2>&1
/sbin/ipset -! restore < /tmp/shape-set.txt > /dev/null 2>&1
mv -f /tmp/shape-tc.hfsc /tmp/shape-tc.old
mv -f /tmp/shape-set.txt /tmp/shape-set.old
fi
fi
Полисинг для больших сетей (IPv4/IPv6) средствами nftables
Отличия полсинга от шейпера
Важным отличием полисера от шейпера в том, что полисер при своей работе безусловно отбрасывает те передаваемые пакеты, которые создают превышение по заданной полосе пропускания, в то время как шейпер за счет применения алгоритмов буферизации сглаживает пики превышения. Шейпер оптимально работает в случаях, когда требуется достаточно точно задавать полосы пропускания до десятков мегабит в секунду, при более высоких скоростях происходит большой перерасход памяти на буферизацию задершиваемых данных, высокой нагрузке CPU и ливинообразному падению суммарной производительности системы. Полисер лишен этих недостатков, с его помощью можно задавать полосы пропускания от десятков мегабит до десятков гигабит в секунду.
Реализация средствами nftables
Используя подсистему nftables все правила классификации трафика и присвоения полосы реализуются одним инструментов в одном месте. И за счет того, что правила фильтрации предварительно компилируются в пространстве пользователя и потом загружаются и исполняются в BPF виртуальной машине, значительно повышается производительность системы.
Предварительные требования к системе
В системе должен быть установлены пакеты
- kernel-image-std-def-5.15.23-alt1 и новее
- libmnl-1.0.4-alt2
- libnftnl-1.2.1-alt1
- nftables-1.0.1-alt1
Предварительная конфигурация
Здесь мы создаем таблицу mangle с типом inet, при котором обрабатывается и ipv4 и ipv6 трафик, задаем какие подсети у нас являются локальными, создаем verdict-сеты для ipv4 и ipv6 адресов клиентов на входящий и исходящий трафик, задаем полосу пропускания для локального трафика (обратите внимание, скорость задается в байтах, килобайтах, мегабайтах в секунду) и в цепочках POSTROUTING и PREROUTING указываем правила классификации трафика через механизм vmap
Создаем файл mangle.nft:
table inet mangle {
set localnet4 {
type ipv4_addr
flags interval
elements = {
5.xxx.xxx.0/22,
193.xxx.xxx.0/23,
100.64.0.0/10,
172.16.0.0/12,
10.0.0.0/16,
10.1.1.0/24
}
}
set localnet6 {
type ipv6_addr
flags interval
elements = {
fe80::/10,
2a0e:xxxx::/29,
fd00::/8
}
}
map poly_u_4 {
type ipv4_addr : verdict
flags interval
counter
}
map poly_d_4 {
type ipv4_addr : verdict
flags interval
counter
}
map poly_u_6 {
type ipv6_addr : verdict
flags interval
counter
}
map poly_d_6 {
type ipv6_addr : verdict
flags interval
counter
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
ip daddr @localnet4 ip saddr @localnet4 goto inet_down
ip6 daddr @localnet6 ip6 saddr @localnet6 goto inet_down
ip daddr vmap @poly_d_4
ip6 daddr vmap @poly_d_6
}
chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
ip daddr @localnet4 ip saddr @localnet4 goto inet_down
ip6 daddr @localnet6 ip6 saddr @localnet6 goto inet_down
ip saddr vmap @poly_u_4
ip6 saddr vmap @poly_u_6
}
chain inet_down {
# If from localnet - accept
limit rate over 10000000 kbytes/second counter drop
}
}
Загружаем его через nft -o -f mangle.nft
Правила для задания полосы пропускания
Применение nft add chain / nft add element на массивах в тысячи едениц крайне непроищводительно, то по данным из биллинга скриптами генерим файл конфигурации такого вида:
table inet mangle {
chain policer_dl_10372 {
limit rate over 640 kbytes/second burst 128 kbytes counter drop
}
chain policer_ul_10372 {
limit rate over 640 kbytes/second burst 128 kbytes counter drop
}
chain policer_dl_10612 {
limit rate over 192 kbytes/second burst 38 kbytes counter drop
}
chain policer_ul_10612 {
limit rate over 192 kbytes/second burst 38 kbytes counter drop
}
map poly_d_4 {
type ipv4_addr : verdict
flags interval
elements = {
100.64.2.102/32 : goto policer_dl_10372,
100.64.2.73/32 : goto policer_dl_10612 }
}
map poly_u_4 {
type ipv4_addr : verdict
flags interval
elements = {
100.64.2.102/32 : goto policer_ul_10372,
100.64.2.73/32 : goto policer_ul_10612 }
}
map poly_d_6 {
type ipv6_addr : verdict
flags interval
elements = {
2a0e:xxxx:xxxx:e83:0:0:0:0/64 : goto policer_dl_10612 }
}
map poly_u_6 {
type ipv6_addr : verdict
flags interval
elements = {
2a0e:xxxx:xxxx:e83:0:0:0:0/64 : goto policer_ul_10612 }
}
}
И загружаем его в один прием через
nft -o -f filename.nft
В результате новые цепочки и элементы vmap будут добавлены к существующему содержимому таблицы mangle.
Итоговый результат можно посмотреть через:
nft list table inet mangle