ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

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

И еще раз переписал firewall …

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

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

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

    Не найдено

Прочитано: 15 611 раз(а)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 5, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

комментариев 5

  1. admin сказал:

    поле для творчества по автоматизации достаточно.
    если сподоблюсь, то отпишусь.

    А Дмитрию зачет !

  2. DAN сказал:

    Оптимизировать нагрузку, создаваемую системны процессом tasq драйвера em можно путем использования оптимизированных драйверов от Yandex: http://people.yandex-team.ru/~wawa/

    А уменьшить задержку вносимую dummynet посредством выставления перемнной sysctl net.inet.ip.dummynet.io_fast=1

  3. DruG сказал:

    Вы сами Все это пробывали?
    net.inet.ip.dummynet.io_fast — уменьшит задержку только для pipe-ов с пропускной способностью равной или большей 1Mbit/s при HZ=1000.

    Вот так вот объяснили это мне:
    Почему шейпер 64Kbit/s c net.inet.ip.dummynet.io_fast — дает задержку 375ms, при ping-е с размером пакета в 1500bytes ?

    Гранулярность времени в dummynet’е при стандартном ядре (HZ=1000) 1ms, т.е. 64Kbit/s это 64Bit/ms. В Вашем примере размер пакета 1500 байт т.е. 1500*8=12Kbit. 12Kbit через трубу с пропускной способностью 64Bit/tick без задержек проехать никак не могут.

    Можно посчитать, какая должна быть задержка: 12000/64 = 187.5ms в одну сторону. В Вашем примере есть и обратная труба, т.е. задержка
    на Ваши пинги должна быть 187.5 * 2 = 375ms.

    Так-то.

    А дрова Яндекса расчитаны на то чтобы держать огромное количество TCP-сессий, в моем случае — это чистый IP.

  4. DAN сказал:

    Да, рекомендации опробованы.

    Описание того, на что именно влияет переменная net.inet.ip.dummynet.io_fast есть в FreeBSD 7.1-RELEASE Release Notes.

    Что именно оптимизировано в драйверах em от Yandex разъяснено в соответствующем README.

  5. DruG сказал:

    net.inet.ip.dummynet.io_fast — работает у меня еще где-то с Fri Aug 29 14:23:50 MSD 2008 на FreeBSD 7.0-STABLE, а не в только что вышедшем релизе 7.1.
    man ipfw:
    Fast mode allows certain packets to bypass dummynet scheduler (if packet flow does not exceed pipe’s bandwidth).
    Почему этот параметр будет работать для шейпов более 1Mbit/s (это как раз те flows, для которых does not exceed pipe’s bandwidth) — я объяснил выше.

    Про драйверы Yandex — даже спорить не буду — Вы README — не читали 🙂

Добавить комментарий

Вам следует авторизоваться для размещения комментария.