Friday, November 17th, 2017

"Справедливый" прозрачный шейпер на FreeBSD

Published on Март 30, 2009 by   ·   Комментариев нет

Задача

Представьте себе, что некий провайдер имеет собственную AS, и соединен с
внешним миром несколькими каналами с BGP. Некоторые из этих каналов
тостые и дешевые, потому что соединяют его лишь с другими местными
провайдерами (зачастую в пределах одного здания). Но основной выход в
Сеть стоит недешево, и его пропускную способность надо экономить,
осторожно деля между клиентами. Для этого мы установим прозрачный шейпер
на Ethernet-канале между нашим маршрутизатором и апстримом.

 [Router]---[Shaper]---[Router]

Наша задача — сделать так, чтобы шейпер равномерно распределял полосу
пропускания между нашими клиентами, создавая у них ощущение
незагруженности канала. При этом не ставится задача точной нарезки
скорости для каждого клиента. Ведь у нас несколько выходов в мир, и
клиент использует сразу все в случайном сочетании. Скорость клиента
определяется лишь в точке его подключения. Это позволяет свести к
минимуму количество настроек шейпера, меняемых во время работы.

Идея

Известно, что в ОС FreeBSD есть dummynet, являющийся шейпером и не
только. А у dummynet есть замечательная возможность создавать
динамические очереди по маскам. Для нас было бы полезно создавать
очереди на основании IP-адресов наших клиентов. Мы решили попробовать. В
случае успеха экономия составит многие тысячи евро.

Принцип деления трафика следующий. Будем создавать динамические очереди
для каждого из наших IP-адресов. При этом в разные очереди будет
попадать следующий трафик:

1) «хороший» TCP (порты 21, 22, 80, 110 и т.д., соль-сахар по вкусу)
2) остальной TCP
3) остальной IP (преимущественно это UDP)

Каждому из этих трех классов трафика назначается вес (параметр weight
для каждой queue). На наш взгляд, разумно назначать вес побольше
третьему классу, чтобы UDP пролетал без задержек и потерь. Второй класс,
наоборот, должен иметь меньший вес, поскольку здесь в основном работают
P2P-программы.

Таким образом, создается до 6 очередей на каждый IP-адрес (до 3 в
каждубю сторону). Все очереди сводятся в две pipe фиксированной скорости
(по одной в каждую сторону).

Реализация

Итак, покупаем сервер с мощным, желательно двуядерным, CPU. В нашем
случае, это Sun Fire x2250 с дополнительной сетевой картой. Не
спрашивайте меня, почему :) Ставим на него FreeBSD 7.1 beta2.
Конфигурируем gmirror (рассмотрено подробно в другой статье на opennet).
Настраиваем /etc/rc.conf таким образом:

        hostname="shaper.mgmt.isp.tld"
        ifconfig_em0="10.1.10.101 netmask 255.255.255.0"
        defaultrouter="10.1.10.1"
        cloned_interfaces="bridge0"
        ifconfig_bridge0="addm em1 addm em2 up"
        ifconfig_em1="up"
        ifconfig_em2="up"
        keymap="us.iso"
        sshd_enable="YES"
        ntpdate_enable=YES
        ntpd_enable=YES
        firewall_enable="YES"
        firewall_script="/etc/ipfw.rules"
        firewall_logging="yes"
        dummynet_enable="yes"

Добавляем в /etc/sysctl.conf

        net.inet.ip.fw.verbose=1
        net.inet.ip.fw.verbose_limit=5
        net.link.bridge.ipfw=1
        net.inet.ip.dummynet.hash_size=1024
        net.inet.ip.fw.dyn_buckets=1024

Затем /etc/ipfw.rules:

        #!/bin/sh

        cmd="ipfw -q"
        lan=em1 # Net0 на корпусе сервера
        wan=em2 # Net1 на корпусе сервера
        urate=95Mbps
        drate=95Mbps

        # Эти TCP-порты будут иметь больший приоритет, нежели остальные.
        # Не идеально, но верно для большинства случаев.
        gtcp="20,21,22,23,25,80,110,179,443,2222,3389,8080,8081"

        # Вес для разных классов трафика
        gtw=3 # Высокоприоритетный TCP
        btw=2 # Остальной TCP
        ipw=4 # Остальной IP (в основном, это UDP)

        $cmd flush
        $cmd pipe flush

        $cmd pipe 100 config bw $drate
        $cmd pipe 200 config bw $urate

        # WAN -> LAN
        $cmd queue 111 config weight $gtw queue 50 pipe 100 gred 0.002/5/15/0.05 mask dst-ip 0xffffffff
        $cmd queue 112 config weight $btw queue 50 pipe 100 gred 0.002/5/15/0.05 mask dst-ip 0xffffffff
        $cmd queue 113 config weight $ipw queue 50 pipe 100 mask dst-ip 0xffffffff

        # LAN -> WAN
        $cmd queue 211 config weight $gtw queue 50 pipe 200 gred 0.002/5/15/0.05 mask src-ip 0xffffffff
        $cmd queue 212 config weight $btw queue 50 pipe 200 gred 0.002/5/15/0.05 mask src-ip 0xffffffff
        $cmd queue 213 config weight $ipw queue 50 pipe 200 mask src-ip 0xffffffff

        # Management and loopback
        $cmd add allow all from any to any via em0
        $cmd add allow all from any to any via lo0

        # Block unwanted traffic
        $cmd add deny all from 192.168.0.0/16 to any
        $cmd add deny all from any to 192.168.0.0/16
        $cmd add deny all from 10.0.0.0/8 to any
        $cmd add deny all from any to 10.0.0.0/8
        $cmd add deny all from 172.16.0.0/12 to any
        $cmd add deny all from any to 172.16.0.0/12
        $cmd add deny all from 127.0.0.0/8 to any
        $cmd add deny all from any to 127.0.0.0/8

        # WAN -> LAN
        $cmd add queue 111 tcp from any to any $gtcp out xmit $lan
        $cmd add queue 111 tcp from any $gtcp to any out xmit $lan
        $cmd add queue 112 tcp from any to any out xmit $lan
        $cmd add queue 113 ip from any to any out xmit $lan

        # LAN -> WAN
        $cmd add queue 211 tcp from any to any $gtcp out xmit $wan
        $cmd add queue 211 tcp from any $gtcp to any out xmit $wan
        $cmd add queue 212 tcp from any to any out xmit $wan
        $cmd add queue 213 ip from any to any out xmit $wan

Настраиваем параметры urate и drate под наши нужды, т.е. чуть меньше,
чем толщина выданного нам канала. В нашем случае, мы платим за 100
мегабит в секунду, но шейпер настраиваем на 95, чтобы очередь
гарантированно образовывалась у нас, а не у апстрима. Включаем шейпер
портами Net0 и Net1 (em1 и em2 в понятиях FreeBSD) в разрыв
Ethernet-сегмента между между рутерами нашего ISP и апстрима.

Результаты

С первых минут работы шейпера наши клиенты почувствовали облегчение, и
перестали жаловаться на качество заграна. пропускная способность канала
используется практически полностью в любое время суток, но это не
создает неудобств. За ночь у нас образовалось около 4900 динамических
очередей (до шести очередей на каждый активный клиентский IP). Два ядра
CPU загружены примерно на 10% каждое, остальные шесть ядер простаивают.
Таким образом, нам вполне хватило бы и одного двуядерного процессора.
Впрочем, сам процессор должен быть по возможности более
высокоскоростным.

Качество работы шейпера позволит данному ISP сэкономить существенную
сумму на заграничном канале.

Развитие идеи

Первоначально мы сделали так, что все клиенты равны между собой в борьбе
за канал. Но можно разделить клиентов на классы, и создавать для более
высоких классов отдельные очереди с увеличенным весом. Например, ввести
классы 1, 2, 5, 10. Базовый вес для каждой из очередей умножать на номер
класса. Например, если ipw=4, то вес для UDP-трафика класса 5 будет
4*5=20. При этом, очевидно, базовый вес должен быть в диапазоне 1-10.
Списки клиентов повышенных классов можно хранить в таблицах ipfw, и
поддерживать их содержимое при помощи скрипта, связанного с базой
данных. Я уже начал это делать, и в будущем обязательно опишу весь

процесс.

zp8497586rq





















































Смотрите также:

Readers Comments (Комментариев нет)

Comments are closed.

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]