From: Дмитрий Иванов <dimss@stalin.lv.>
Newsgroups: email
Date: Mon, 1 Dec 2008 17:02:14 +0000 (UTC)
Subject: "Справедливый" прозрачный шейпер на FreeBSD
Задача
Представьте себе, что некий провайдер имеет собственную 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 таким образом:
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)
# 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, и
поддерживать их содержимое при помощи скрипта, связанного с базой
данных. Я уже начал это делать, и в будущем обязательно опишу весь
процесс.
Vova
