Subnets.ru blog

Наткнулся в Инете, возьмем на заметочку. Надо будет как нить попробовать 🙂

1. Зачем это надо?
1.1 Уменьшение русрсов процессора, «поедаемого» tasq, поцессом отвечающим за обработку трафика проходящим ч/з интерфейсы em
1.2 Отимизация правил IPFW
1.3 Возможность изменять список безлимитных клиентов без перезагрузки списка правил полностью.
1.4 Снятие ограничений на варианты возможных тарифных планов.
1.5 Устранение задержки при прохождении пакетами через pipe и queue при использовании ipfw.

Извините друзья — спать хочу, комментариев будет мало:
2. Как работает:
2.1 Для каждого абонента должна быть создана отдельная нода в netgraph с заданной пропускной способностью;
2.2 Абоненты «загоняются» в соответствующие ноды, по номерам хуков (tablearg) в таблицах. Последнее возможно без особых трудностей, поскольку ipfw имеет собственную ноду в netgraph.

Пока рассматривается случай только с одним абонентом в таблице — тариф 64Kbit/s.
>cat /etc/rc.firewall
#!/bin/sh
# 1. Global variables
# 1.1 My Interfaces
# 1.1.1 Uplink interface
uif=»fxp1″
unet=»194.128.23.252/30″
uip=»194.128.23.253″

# 1.1.2 Client Interface
cif=»fxp0″
cnet=»172.16.2.252/30″
cip=»172.16.2.253″

# 1.1.3 Contol Interface
mif=»vr0″
mnet=»192.168.23.0/24″
mip=»192.168.23.71″

# 1.2 IPFW executable
fwcmd=’/sbin/ipfw -q’

# 2. Functions (empty by now)
# Suck in tables
if [ -r /etc/rc.firewall.d/unlim64.conf ]; then
. /etc/rc.firewall.d/unlim64.conf
fi

# 3. Default ruleset
# 3.1 Flushing all rules
echo «Flushing all rules.»
${fwcmd} -f flush
${fwcmd} -f pipe flush

# 3.2 Shaper
# 3.2.1 Rules :: Shape IT
# Outgoing traffic — NG_CAR Upstream
${fwcmd} add netgraph tablearg ip from «table(11)» to any out via ${uif}
# Incoming traffic — NG_CAR Downstream
${fwcmd} add netgraph tablearg ip from any to «table(10)» out via ${cif}

>ipfw table 10 list
172.16.2.248/29 14

>ipfw table 11 list
172.16.2.248/29 15

Конфигурируем ноду в netgraph:
>kldload ng_ipfw
>kldload ng_car
>ngctl:
mkpeer ipfw: car 14 upper
name ipfw:14 rate_64
connect rate_64: ipfw: lower 15

Конфигурируем пропускную способность ноды:
# Аналог Cisco Rate-Limit
msg rate_64: setconf { upstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=2 } downstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=2 } }

# Аналог Cisco Traffic Shape:
msg rate_64: setconf { upstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=3 } }

В первом случае:
если полоса не забита:
>ping -s 1472 -i 0.2 -c 200 -S 172.16.2.250 194.128.23.254

200 packets transmitted, 200 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.246/1.340/1.576/0.048 ms

при переполнении полосы:
>ping -s 1472 -i 0.1 -c 200 -S 172.16.2.250 194.128.23.254

200 packets transmitted, 117 packets received, 41% packet loss
round-trip min/avg/max/stddev = 1.150/1.309/1.495/0.061 ms

То есть как и положено — срезаются пики нагрузки при использовании RateLimit.

Во втором случае:

если полоса не забита:
>ping -s 1472 -i 0.2 -c 200 -S 172.16.2.250 194.128.23.254

200 packets transmitted, 200 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.246/1.340/1.576/0.048 ms

при переполнении полосы:
>ping -s 1472 -i 0.1 -c 200 -S 172.16.2.250 194.128.23.254

PING 194.128.23.254 (194.128.23.254) from 172.16.2.250: 1472 data bytes
1480 bytes from 194.128.23.254: icmp_seq=0 ttl=63 time=1.585 ms
1480 bytes from 194.128.23.254: icmp_seq=1 ttl=63 time=1.247 ms
1480 bytes from 194.128.23.254: icmp_seq=2 ttl=63 time=1.211 ms
1480 bytes from 194.128.23.254: icmp_seq=3 ttl=63 time=1.306 ms
1480 bytes from 194.128.23.254: icmp_seq=4 ttl=63 time=1.269 ms
1480 bytes from 194.128.23.254: icmp_seq=5 ttl=63 time=1.233 ms
1480 bytes from 194.128.23.254: icmp_seq=6 ttl=63 time=1.319 ms
1480 bytes from 194.128.23.254: icmp_seq=7 ttl=63 time=1.289 ms
1480 bytes from 194.128.23.254: icmp_seq=8 ttl=63 time=1.246 ms
1480 bytes from 194.128.23.254: icmp_seq=9 ttl=63 time=1.217 ms
1480 bytes from 194.128.23.254: icmp_seq=10 ttl=63 time=5.671 ms
1480 bytes from 194.128.23.254: icmp_seq=11 ttl=63 time=87.592 ms
1480 bytes from 194.128.23.254: icmp_seq=12 ttl=63 time=170.640 ms
1480 bytes from 194.128.23.254: icmp_seq=13 ttl=63 time=252.565 ms
1480 bytes from 194.128.23.254: icmp_seq=14 ttl=63 time=334.611 ms
1480 bytes from 194.128.23.254: icmp_seq=15 ttl=63 time=416.532 ms
1480 bytes from 194.128.23.254: icmp_seq=16 ttl=63 time=499.581 ms
1480 bytes from 194.128.23.254: icmp_seq=17 ttl=63 time=581.503 ms
1480 bytes from 194.128.23.254: icmp_seq=18 ttl=63 time=663.551 ms
1480 bytes from 194.128.23.254: icmp_seq=19 ttl=63 time=745.473 ms
1480 bytes from 194.128.23.254: icmp_seq=20 ttl=63 time=828.516 ms
То есть как и положено — растет задержка при использовании Traffic Shape.

Как все это автоматизировать — пока понятия не имею, в netgraph не разобрался до конца.

3. Что читать чтобы до конца разобраться:
Про классовые и бесклассовые дисциплины обслуживания очередей.
man 8 ipfw
Все о Netgraph
man 4 netgraph
man 4 ng_ipfw
Cisco — QOS для начинающих
man 4 ng_car
Заголовочные файлы к коду ng_car

Автор: Дмитрий Шевченко

Похожие статьи:

Не найдено