OpenNET: статья - "Справедливый" прозрачный шейпер на FreeBSD (transparent bandwidth shaper dummynet queue ipfw freebsd)

Ключевые слова: transparent, bandwidth, shaper, dummynet, queue, ipfw, freebsd, (найти похожие документы)
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 таким образом: 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, и поддерживать их содержимое при помощи скрипта, связанного с базой данных. Я уже начал это делать, и в будущем обязательно опишу весь процесс.

5, Аноним (-), 11:36, 20/04/2015 [^] [^^] [^^^] [ответить]	+/–
Цель в том, чтобы он попадал только в свою очередь Если у Вас по результатам те... большой текст свёрнут, показать