Скачать traffic shaping


cFos Приоритезация трафика (Traffic Shaping) - Интернет-ускоритель + оптимизатор пинга

Обычная передача данных: Прием данных должен быть подтвержден (ACK-пакеты) прежде, чем можно будет отправить новые данные. Без Traffic Shaping: Передача данных задерживает ACK-пакеты. В результате скорость приема тоже снижается.

cFos Traffic Shaping: ACK-пакеты получают высокий приоритет, позволяя принимать данные на максимальной скорости.

cFos Traffic Shaping уменьшает задержки при передаче данных и позволяет Вам путешествовать в Интернете до трёх раз быстрее. Так что Вы можете использовать всю скорость Вашего соединения!

Во время передачи данных по протоколу TCP/IP получатель посылает обратно специальный сигнал в подтверждение о получении данных. Новые данные отправляются только тогда, когда подтверждение получено. Задержка подтверждений приводит к замедлению скорости передачи, вынуждая отправителя ждать. Особенно это касается DSL и Кабельного Интернета, где загруженный исходящий канал (который итак имеет небольшую пропускную способность) приводит к замедлению скачивания. Это происходит потому, что не хватает исходящей скорости для подтверждающих сигналов.

Стандартным решением для компенсации этого эффекта было увеличение размера TCP-окна, что позволяло отправить больше данных без немедленного подтверждения. Основными проблемами здесь являются увеличение пинга (время ожидания) и существенные задержки во время рендеринга веб-страницы. Задержка до двух секунд не является редкостью для TCP-окна с размером 512КБ. Короче говоря, большие размеры TCP-окна всё равно не позволят Вам получить полную скорость закачки.

С другой стороны, cFos Traffic Shaping выстраивает данные по приоритету в таком порядке, что важные пакеты всегда оказываются раньше обычных. Таким образом, подтверждения всегда приходят вовремя, и передачи никогда не будут забивать Ваше соединение!

Технология cFos Traffic-Shaping, распознавая важные типы пакетов и располагая их в соответствии с приоритетами, не только сглаживает Интернет-трафик, но и обеспечивает низким пингом. Это не только ускоряет серфинг и повышает скорость закачки, но и даёт преимущества в сетевых играх.

Использование cFos Traffic Shaping принесёт Вам такие ощутимые преимущества, как:

Без использования технологии Traffic Shaping пинг может достичь ужасающих двух секунд, которые превратят сеанс Telnet или SSH в рутинную или совсем невыполнимую работу. Но вместе с cFos Traffic Shaping задержка остается минимальной.

Уже одно это должно поднять серфинг на совершенно новый уровень!

Это означает, что во время Интернет-серфинга Вам даже трудно будет заметить, что в фоновом режиме передаются какие-либо данные. Кроме того, такое резкое снижение задержки будет весьма полезно в сетевых играх.

Сначала cFos Traffic Shaping измеряет исходящую и входящую скорости, а так же пинг, для каждого Интернет-соединения. Затем он использует эту информацию для управления очередью всех передач данных. Кроме того, по мере необходимости Traffic Shaping динамически распределяет доступную пропускную способность для каждого подключения.

cFos Traffic Shaping повышает приоритет не только ACK, но и других важных пакетов, например тех, что используются для Telnet и SSH. Таким образом, используя cFos Traffic Shaping, проблемы с загруженным каналом во время файлообмена или отправки почты уйдут в прошлое!

Но не верьте нам на слово, просто убедитесь в этом сами.

Кроме приоритета ACK-пакетов, Traffic Shaping делает или позволяет сделать следующее:

Улучшенная технология Traffic Shaping

Технология cFosSpeed traffic shaping включает в себя две основные составляющие: во-первых, определение максимальных скоростей отдачи и загрузки, доступных для данного канала, а во-вторых, отправка данных со скоростью, которая не превышает скорость отдачи и расстановка приоритетов для отправки остальных данных. Таким образом, более приоритетные данные отправляются в первую очередь. Во время загрузки данных cFosSpeed не может изменить порядок получения пакетов, но программа может замедлить отправляемые пакеты настолько, что канал не «забивается» с их стороны, благодаря чему уменьшается пинг.

cFosSpeed определяет скорости передачи данных путем отправки пакетов. Эти пакеты отправляются с малым значением TTL для их более быстрого возвращения и более точного измерения времени приема-передачи. С этой целью cFosSpeed отправляет запросы ICMP-эхо или небольшие UDP-пакеты в зависимости от того, что в данном конкретном случае эффективнее.

Со временем cFosSpeed регистрирует наименьшее время пинг. В последующем, когда cFosSpeed отмечает увеличение времени пинг, программа определяет, что канал перегружен. С целью предотвращения перегрузки канала cFosSpeed сокращает скорость передачи и/или загрузки.

Данный метод отлично работает для стабильных и работающих все время с одной скоростью и временем отклика средств передачи данных, таких как цифровые абонентские линии (DSL) или кабельные сети. Однако, возникают проблемы с беспроводными и мобильными Интернет-соединениями через UMTS, WiMAX, CDMA, CDMA 2000 и т.д., которые имеют сильно различающееся время пинг. По причине временного увеличения времени пинг cFosSpeed сократит скорости загрузки или отдачи, даже несмотря на то, что данный скачок пинга не был вызван перегруженностью канала. Таким образом, максимальная скорость соединения не будет достигнута и cFosSpeed не сможет использовать всю доступную ширину полосы пропускания канала.

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

Этот анализ статистики отлично работает до тех пор, пока cFosSpeed может быть уверен, что изменения в измеренных задержки при передаче данных отражают нормальное поведение подключения. К сожалению, трафик отправленный или полученный по той же линии другими пользователями, также будет увеличивать время отклика и отравит статистику и, следовательно, вызовет ненужные медленные передачу или прием данных.

cFosSpeed борится с этой проблемой при помощи новой функцией Net Talk: каждый cFosSpeed подключенный к одному маршрутизатору (в той же локальной сети) передает, сколько данных он послал и получил ко всем другим драйверам cFosSpeed. Это позволяет всем драйверам cFosSpeed регулировать их скоростью в зависимости от суммы всего трафика, а не только их собственной части. Результат - более точная статистика данных, что улучшает качество формирования трафика, а это означает, больше данных может быть переданы еще с низким пингом.

Сравнение времени загрузки

Во время одной передачи и двух загрузок cFos позволяет бродить по сети более чем в три раза быстрее, чем драйвер XP! Дата: 09.2004 - DSL 768/128

Для начала имейте в виду, что только один входящий или исходящий поток позволяет измерить только максимальную скорость. Поэтому Вам нужно запустить как минимум два одновременных потока, чтобы измерить эффект от использования cFos Traffic Shaping.

И cFos, и cFosSpeed могут сами себя откалибровать в зависимости от подключения. Обычно, наилучших результатов можно достичь после нескольких дней использования таких программ, которые способны загрузить входящую и исходящую пропускную способность на полной скорости.

Теперь отправьте себе по электронной почте файл размером не менее 5 МБ. На стандартном подключении это займет около пяти минут, в течение которых Вы будете проводить измерения. Перед каждым тестом Вы должны очистить кэш браузера, затем следите за временем загрузки Веб-сайта. Каждый тест нужно повторить несколько раз для максимальной точности.

Одновременная загрузка & передача

= лучше

Например, во время одной загрузки и одной передачи "типичное" DSL соединение 768 Кбит/с должно достигать скорости закачки около 87 Кбайт/с, а исходящая скорость примерно 16 Кбайт/с. Из них 11.5 Кбайт/с доступны для передачи, а оставшиеся 4.5 Кбайт/с используются, чтобы отсылать сигналы подтверждений для закачки.

Один из самых простых и точных способов следить за пингом - это использовать нашу бесплатную утилиту hrPing .

Весь текст и изображения на этой странице могут свободно использоваться.Щелкните на изображении для получения изображения в высоком разрешении.

www.cfos.de

Управление трафиком и шейпинг трафика

Управление трафиком и шейпинг трафика

Авторские права © 2001-2007 Thomas M. Eastep

Авторские права © 2005 Arne Bernin & Thomas M. Eastep

Авторские права © 2007 Russian Translation: Grigory Mokhin

Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке «GNU Free Documentation License».

Важно

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

Предупреждение

Иначе говоря, чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем.

Как минимум, потребуется обратиться к следующим дополнительным источникам:

Начиная с версии 2.5.5 в Shorewall реализована встроенная поддержка управления трафиком и шейпинга трафика. В более ранних версиях эти возможности были ограниченными. Можно было использовать собственный сценарий tcstart (это можно и сейчас), но, за исключением файла tcrules, в файлах конфигурации Shorewall не была предусмотрена возможность определения классов и дисциплин очередей.

До сих пор поддержка управления трафиком является неполной, например, не поддерживаются все опции (и особенно различные алгоритмы очередей) из ядра Linux, но для большинства случаев она будет достаточной. Если у вас уже есть сценарий для управления трафиком, который вы собираетесь использовать и в будущем, то соответствующие инструкции приведены по ссылке ниже в этом документе. Для того чтобы это заработало, требуется включить поддержку управления трафиком в ядре и в Shorewall, как описано далее.

Управление трафиком и шейпинг трафика в Linux

В этом разделе кратко описано, как работает управление трафиком в Linux. Даже если этого должно быть достаточно для настройки управления трафиком в файлах конфигурации Shorewall, мы очень рекомендуем внимательно прочитать руководство Linux Advanced Routing and Shaping HOWTO. Во время написания этого документа текущей версией была 1.0.0.

Начиная с версии 2.2, в Linux реализованы полные возможности управления трафиком. Предусмотрены различные алгоритмы, которые применяются для приоритизации очередей пакетов, выходящих с интерфейса. Стандартный алгоритм называется pfifo, и, как следует из самого названия, это очередь типа первым пришел - первым ушел. Фактически при этом никакого управления трафиком не происходит, и если какое-то соединение забивает весь канал, то этот алгоритм не сможет этого предотвратить.

Для управления трафиком в Shorewall используются два алгоритма, HTB (иерархический набор маркеров) и SFQ (очередь с равноправным стохастическим упорядочением). SFQ использует простую схему: отслеживаются все соединения (tcp или udp), и трафик распределяется между ними. Обычно это работает хорошо. HTB позволяет определить набор классов, между которыми распределяется трафик. Для каждого класса можно указать минимальную и максимальную полосу пропускания, а сами классы упорядочить в иерархическую структуру, чтобы классы с меньшим приоритетом получали доступ к каналу только в том случае, если запросы более важных классы удовлетворены. Встроенные функции управления трафиком в Shorewall позволяют определить такие классы и указать для них полосу пропускания. Внутри самих классов используется SFQ, чтобы их различные внутренние потоки данных обрабатывались как равноправные.

Управлять можно только исходящим трафиком. Причина этого состоит в том, что входящие пакеты уже пришли на сетевую плату, и нужно решить, что с ними делать. Их можно только сбросить, но особого смысла в этом не будет, поскольку пакет уже пришёл, пройдя через узкое место - входящий канал. Следующим узким местом может быть интерфейс, с которого уходит этот пакет, и именно на нём может образовываться очередь. Поэтому определение очередей для входящих пакетов не будет особенно полезным, эти пакеты просто нужно передать как можно быстрее на исходящий интерфейс.

Есть одно исключение. Если ограничить входящий трафик значением чуть меньшим, чем фактическая пропускная способность канала, то будет исключено образование очередей на другом конце соединения. Это бывает полезно, если управление потоком на другом конце канала невозможно, а сам он подключен к сети по более быстрому каналу, например, если вы подключены к провайдеру по кабельному модему или модему DSL, а маршрутизатор провайдера подключен к быстрому магистральному каналу. Поэтому, если отбрасывать слишком быстро приходящие пакеты, то основной протокол сможет это обнаружить и снизить скорость соединения. В TCP такой механизм встроен, в UDP не встроен, но протокол, работающий поверх UDP, может иметь такой механизм.

В таких случаях создание очередей будет иметь неприятные последствия, если есть пакеты, которые должны проходить в первую очередь, как, например, VoIP или ssh. Для таких соединений важно, чтобы пакеты проходили с минимальной задержкой. Для других пакетов, таких как загрузка по HTTP, задержка на несколько секунд не будет иметь значения.

Если на другом конце канала образуется очередь, а маршрутизатор не поддерживает QoS или биты QoS настроены неверно, то пакеты, для которых важна минимальная задержка, будут ждать в той же очереди, что и менее важные пакеты загрузки по HTTP, и задержка может быть большой.

Управление исходящим трафиком достигается посредством распределения потока пакетов по классам. Класс связан ровно с одним сетевым интерфейсом и имеет ряд атрибутов:

  1. PRIORITY - используется для указания приоритетов классов, к которым относятся отправляемые пакеты. Приоритет - это число, при этом 1 задаёт наивысший приоритет, 2 - следующий по важности и т.д.

  2. RATE - скорость, то есть минимальная гарантированная пропускная способность, которая должна обеспечиваться для класса, когда возрастает нагрузка на канал. Классы с более высоким приоритетом (меньшие значения PRIORITY) обслуживаются даже в том случае, если заданы другие классы с гарантированной пропускной способностью, но низшим приоритетом (большие значения PRIORITY).

  3. CEIL - ограничение, максимальная полоса пропускания, которая отводится для класса, когда канал свободен.

  4. MARK - метка. В Netfilter предусмотрены способы маркировки пакетов. Метки пакетов - это числа. В Shorewall они могут принимать значение от 1 до 255. Метки пакетов присваиваются различным типам пакетов согласно правилам, заданным в файле /etc/shorewall/tcrules.

Для каждого интерфейса необходимо задать один класс, который будет классом по умолчанию. К этому классу будут относиться непомеченные данные, то есть пакеты, для которых не задана метка в файле /etc/shorewall/tcrules.

Netfilter также поддерживает метки соединений. Метки соединений можно присвоить соединениям в правилах /etc/shorewall/tcrules, можно скопировать метку пакета в метку соединения (SAVE), или скопировать метку соединения в метку пакета (RESTORE).

Конфигурация ядра Linux

Для работы требуется ядро не ниже 2.4.18. На рисунке показаны опции ядра, которые необходимо включить. Для встроенной поддержки необходимы опции HTB scheduler, Ingress scheduler, PRIO pseudoscheduler и SFQ queue. Прочие планировщики или алгоритмы очередей необязательны.

Также требуются классификаторы u32 и fw из главного меню Networking Options (не показаны).

На следующем рисунке показано, как я настроил QoS у себя в ядре 2.6.13:

Конфигурация ядра изменилась в 2.6.16 -- вот мои рекомендации.

Включение поддержки TC в Shorewall

Поддержку TC требуется включить независимо от того, применяются ли встроенные функции или вы используете собственный сценарий tcstart.

Для включения встроенных функций управления трафиком в Shorewall выполните следующее:

Работа с встроенными функциями управления трафиком и шейпинга

Встроенные в Shorewall функции управления трафиком - это тонкая оболочка для очереди входящих пакетов (ingress qdisc), HTB и SFQ. Эта оболочка позволяет выполнить следующие задачи:

Предупреждение

Встроенные в Shorewall функции управления трафиком ограничены десятью (10) устройствами.

Больше никаких задач встроенные функции управления трафиком не выполняют. Поэтому, чтобы их использовать, необходимо понимать, как работает HTB и управление трафиком в Linux, и как работают метки пакетов Netfilter. За дополнительной информацией обратитесь к ссылкам, приведенным в начале этого документа.

Для задания пропускной способности (как устройств, так и классов) используйте kbit или kbps (для килоБАЙТ в секунду) БЕЗ пробела между числом и единицей измерения (то есть 100kbit НО НЕ 100 kbit). Можно также использовать mbit, mbps или число (означающее байты), но поддерживаются только целые числа (0.5 использовать нельзя).

Для того чтобы правильно настроить устройства, необходимо выяснить фактическую пропускную способность канала в обоих направлениях. Это особенно важно для соединений DSL или любых других, для которых пропускная способность канала не гарантирована. Не верьте числам, которые называет провайдер, но сами измерьте реальную скорость канала. В этом могут помочь различные утилиты в сети, попробуйте поискать "dsl speed test" в google (для Германии можно использовать arcor speed check). Найдите тест поближе к себе.

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

Далее описаны столбцы файла:

Пример 1.

Предположим, что вы работаете с PPP по Ethernet (DSL), а интерфейс - это ppp0. Устройство имеет исходящую скорость 500 кбит и входящую - 6000 кбит

#INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 500kbit

В этом файле можно задать классы, по которым будет распределяться исходящий трафик.

Классификатор fwmark является удобным средством для классификации пакетов при управлении трафиком. В файле «/etc/shorewall/tcrules» эти метки представлены в виде таблицы. Глубже познакомиться с маркировкой пакетов в Netfilter/Shorewall позволяет этот документ.

Обычно метка пакета ставится в цепочке PREROUTING перед тем, как осуществляется замена адресов. При этом невозможно помечать входящие пакеты согласно их целевому адресу, если применяется SNAT или Masquerading. Тем не менее, можно осуществлять маркировку пакетов в цепочке FORWARD, если задать опцию MARK_IN_FORWARD_CHAIN в файле shorewall.conf.

Далее описаны столбцы файла:

Пример 2.

Все пакеты, приходящие на eth2, должны иметь метку 1. Все пакеты, приходящие на eth3 и eth4, должны иметь метку 2. Все пакеты, созданные в системе файрвола, должны иметь метку 3.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) 1 eth2 0.0.0.0/0 all 2 eth3 0.0.0.0/0 all 2 eth4 0.0.0.0/0 all 3 $FW 0.0.0.0/0 all

Пример 3.

Все пакеты GRE (протокол 47), не созданные в системе файрвола и имеющие целевой адрес 155.186.235.151, должны иметь метку 12.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) 12 0.0.0.0/0 155.182.235.151 47

Пример 4.

Все пакеты SSH, приходящие с 192.168.1.0/24 и предназначенные для 155.186.235.151, должны иметь метку 22.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) 22 192.168.1.0/24 155.182.235.151 tcp 22

Пример 5.

Все пакеты SSH, проходящие через первое устройство в файле /etc/shorewall/tcdevices, должны быть отнесены в класс с меткой 10.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT # PORT(S) 1:110 0.0.0.0/0 0.0.0.0/0 tcp 22 1:110 0.0.0.0/0 0.0.0.0/0 tcp - 22

Пример 6.

Все пакеты echo ICMP должны иметь метку 1. Весь трафик протоколов p2p должен иметь метку 4.

Это чуть более сложный случай. Поскольку модуль ipp2p не в состоянии распознать все пакеты в соединении как пакеты P2P, то все соединение помечается как P2P, если совпадение найдено хотя бы для одного пакета. Предполагается, что метка пакета/соединения 0 означает неклассифицированные пакеты.

#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST # PORT(S) GROUP 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0

Последние четыре правила означают следующее:

"Если пакет не был классифицирован (метка пакета 0), то скопировать метку соединения в метку пакета. Если метка пакета уже задана, то никаких действий более не требуется. Если пакет относится к типу P2P, то задать метку пакета 4. Если метка пакета задана, то сохранить ее в качестве метки соединения."

Если подключение к провайдеру выполняется через ppp/pppoe/pppoa, и вы используете управление трафиком, то необходимо перезапустить управление трафиком shorewall. Причина этого состоит в том, что если соединение ppp перезапускается (обычно это происходит как минимум раз в день), то все фильтры и qdisc «tc», связанные с этим интерфейсом, будут удалены.

Самым простым решением будет перезапуск shorewall при повторном установлении соединения. Для этого добавьте в сценарий «/etc/ppp/ip-up.d» следующую строку.

#! /bin/sh /sbin/shorewall refresh

Рабочие примеры

Конфигурация для замены Wondershaper

Встроенные функции управления трафиком позволяют полностью заменить сценарий wondershaper. Примеры файлов конфигурации приведены по адресу "http://www1.shorewall.net/pub/shorewall/Samples/tc4shorewall/. Обратите внимание, что эти примеры необходимо настроить, чтобы они работали в вашей среде. В них предполагается, что интерфейс соединения с провайдером - это ppp0 (для DSL), и для другого типа соединения его необходимо изменить. Также требуется изменить параметры в файле tcdevices.wondershaper, чтобы они отвечали фактической скорости канала. Ниже приведены соответствующие строки из файлов конфигурации. В итоге получается точная замена того, что должен делать wondershaper. Но вы можете и вносить улучшения...

#INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 5000kbit 500kbit#INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 full full 1 tcp-ack,tos-minimize-delay ppp0 2 9*full/10 9*full/10 2 default ppp0 3 8*full/10 8*full/10 2#MARK SOURCE DEST PROTO PORT(S) CLIENT USER # PORT(S) 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply # метка для трафика с низким приоритетом: # mldonkey 3 0.0.0.0/0 0.0.0.0/0 udp - 4666

Wondershaper позволяет определить набор хостов и/или портов, которым присваивается низкий приоритет. Для этого в tcrules этим хостам нужно присвоить метку 3 (как это делается в примерах файлов конфигурации).

Присвоение низкого приоритета хостам

Допустим, что в сценарии wondershaper были следующие параметры (только в качестве примера):

# Низкий приоритет для исходящего трафика - можно оставить пустым, # чтобы применять сетевые маски для низкого приоритета NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28" # Низкий приоритет - маска для назначения NOPRIOHOSTDST=60.0.0.0/24 # Низкий приоритет - порты источника NOPRIOPORTSRC="6662 6663" # Низкий приоритет - порты назначения NOPRIOPORTDST="6662 6663"

Эти параметры будут отражены следующим образом в файле tcrules:

3 192.168.1.128/25 0.0.0.0/0 all 3 192.168.3.28 0.0.0.0/0 all 3 0.0.0.0/0 60.0.0.0/24 all 3 0.0.0.0/0 0.0.0.0/0 udp 6662,6663 3 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663 3 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663 3 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663
Простая конфигурация

Ниже приведен простой пример для общего подключения к Интернет с разных компьютеров. Фактически здесь настроен шейпинг для двух хостов с IP-адресами 192.168.2.23 и 192.168.2.42

#INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 700kbit

Канал имеет входящие 6 мбит и исходящие 700 кбит.

#INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 5*full/10 full 1 tcp-ack,tos-minimize-delay ppp0 2 3*full/10 9*full/10 2 default ppp0 3 2*full/10 8*full/10 2

Добавляется класс для пакетов tcp ack с высоким приоритетом, чтобы ускорить загрузку. Следующие два класса совместно используют большую часть пропускной способности канала для двух хостов, и если соединение свободно, то всю пропускную способность. Так как хосты считаются равноправными, они имеют одинаковый приоритет. Последний класс предназначен для остального трафика.

#MARK SOURCE DEST PROTO PORT(S) CLIENT USER # PORT(S) 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2:F 192.168.2.23 0.0.0.0/0 all 3:F 192.168.2.42 0.0.0.0/0 all

Пакеты ping icmp и ответы помечаются отдельно, как относящиеся к интерактивному классу. Для них метка ставится для обоих хостов.

Замечания для пользователей Xen

Если управление трафиком включено в dom0, но исходящий трафик при этом шейпится неправильно, то причиной этого может быть "выгрузка контрольных сумм" (checksum offloading) в ваших domU. Просмотрите вывод команды "shorewall show tc". Ниже приведен пример:

class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0 Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0) rate 299288bit 3pps backlog 0b 0p requeues 0 lended: 53963 borrowed: 21361 giants: 90174 tokens: -26688 ctokens: -14783

В приведенном примере легко обнаружить две проблемы:

  1. Скорость (299288) заметно превышает установленный предел (230000).

  2. Сообщается о большом числе огромных пакетов (90174).

Эта неполадка устраняется выключением "checksum offloading" в domU с помощью программы ethtool. За инструкциями обратитесь к статье по Xen.

Применение собственных сценариев tc

Замена встроенного файла tcstart

Если вы предпочитаете сами создать файл запуска tc, просто поместите его в /etc/shorewall/tcstart.

В сценарии tcstart вместо вызова программы «tc» используйте функцию run_tc из Shorewall, чтобы при ошибке tc остановить файрвол.

  1. Задайте TC_ENABLED=Yes и CLEAR_TC=Yes

  2. Укажите сценарий /etc/shorewall/tcstart с правилами управления трафиком.

  3. Укажите также необязательный сценарий /etc/shorewall/tcclear для остановки управления трафиком. Обычно это не требуется.

  4. Если сценарий tcstart применяет классификатор «fwmark», то можно помечать пакеты, используя записи из /etc/shorewall/tcrules.

Управление трафиком, внешнее по отношению к Shorewall

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

  1. Задайте TC_ENABLED=No и CLEAR_TC=No

  2. Если сценарий применяет классификатор «fwmark», то можно помечать пакеты, используя записи из /etc/shorewall/tcrules.

www.shorewall.net

Complex Traffic Shaping/Control

Complex Traffic Shaping/Control

Copyright © 2001-2013 Thomas M. Eastep

Copyright © 2005 Arne Bernin & Thomas M. Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

Important

Traffic shaping is complex and the Shorewall community is not well equipped to answer traffic shaping questions. So if you are the type of person who needs "insert tab A into slot B" instructions for everything that you do, then please don't try to implement traffic shaping using Shorewall. You will just frustrate yourself and we won't be able to help you.

Warning

Said another way, reading just Shorewall documentation is not going to give you enough background to use this material.

At a minimum, you will need to refer to at least the following additional information:

Beginning with Shorewall 4.4.6, Shorewall includes two separate implementations of traffic shaping. This document describes the original implementation which is complex and difficult to configure. A much simpler version is described in Simple Traffic Shaping/Control and is highly recommended unless you really need to delay certain traffic passing through your firewall.

Shorewall has builtin support for traffic shaping and control. This support does not cover all options available (and especially all algorithms that can be used to queue traffic) in the Linux kernel but it should fit most needs. If you are using your own script for traffic control and you still want to use it in the future, you will find information on how to do this, later in this document. But for this to work, you will also need to enable traffic shaping in the kernel and Shorewall as covered by the next sections.

Linux traffic shaping and control

This section gives a brief introduction of how controlling traffic with the Linux kernel works. Although this might be enough for configuring it in the Shorewall configuration files, we strongly recommend that you take a deeper look into the Linux Advanced Routing and Shaping HOWTO. At the time of writing this, the current version is 1.0.0.

Since kernel 2.2, Linux has extensive support for controlling traffic. You can define different algorithms that are used to queue the traffic before it leaves an interface. The standard one is called pfifo and is (as the name suggests) of the type First In First out. This means, that it does not shape anything, if you have a connection that eats up all your bandwidth, this queuing algorithm will not stop it from doing so.

For Shorewall traffic shaping we use three algorithms: HTB (Hierarchical Token Bucket), HFSC (Hierarchical Fair Service Curves) and SFQ (Stochastic Fairness Queuing). SFQ is easy to explain: it just tries to track your connections (tcp or udp streams) and balances the traffic between them. This normally works well. HTB and HFSC allow you to define a set of classes, and you can put the traffic you want into these classes. You can define minimum and maximum bandwidth settings for those classes and order them hierarchically (the less prioritized classes only get bandwidth if the more important have what they need). Additionally, HFSC allows you to specify the maximum queuing delay that a packet may experience. Shorewall builtin traffic shaping allows you to define these classes (and their bandwidth limits), and it uses SFQ inside these classes to make sure, that different data streams are handled equally. If SFQ's default notion of a 'stream' doesn't work well for you, you can change it using the flow option described below.

You can shape incoming traffic through use of an Intermediate Functional Block (IFB) device. See below. But beware: using an IFB can result in queues building up both at your ISPs router and at your own.

You shape and control outgoing traffic by assigning the traffic to classes. Each class is associated with exactly one network interface and has a number of attributes:

  1. PRIORITY - Used to give preference to one class over another when selecting a packet to send. The priority is a numeric value with 1 being the highest priority, 2 being the next highest, and so on.

  2. RATE - The minimum bandwidth this class should get, when the traffic load rises. Classes with a higher priority (lower PRIORITY value) are served even if there are others that have a guaranteed bandwidth but have a lower priority (higher PRIORITY value).

  3. CEIL - The maximum bandwidth the class is allowed to use when the link is idle.

  4. MARK - Netfilter has a facility for marking packets. Packet marks have a numeric value which is limited in Shorewall to the values 1-255 (1-16383 if you set WIDE_TC_MARKS=Yes in shorewall.conf (5) ). You assign packet marks to different types of traffic using entries in the /etc/shorewall/mangle file (Shorewall 4.6.0 or later) or /etc/shorewall/tcrules (Prior to Shorewall 4.6.0).

    Note

    In Shorewall 4.4.26, WIDE_TC_MARKS was superseded by TC_BITS which specifies the width in bits of the traffic shaping mark field. The default is based on the setting of WIDE_TC_MARKS so as to provide upward compatibility. See the Packet Marking using /etc/shorewall/mangle article.

One class for each interface must be designated as the default class. This is the class to which unmarked traffic (packets to which you have not assigned a mark value in /etc/shorewall/mangle) is assigned.

Netfilter also supports a mark value on each connection. You can assign connection mark values in /etc/shorewall/mangle (/etc/shorewall/tcrules), you can copy the current packet's mark to the connection mark (SAVE), or you can copy the connection mark value to the current packet's mark (RESTORE). For more information, see this article.

Linux Kernel Configuration

You will need at least kernel 2.4.18 for this to work, please take a look at the following screenshot for what settings you need to enable. For builtin support, you need the HTB scheduler, the Ingress scheduler, the PRIO pseudoscheduler and SFQ queue. The other scheduler or queue algorithms are not needed.

This screen shot shows how I configured QoS in a 2.6.16 Kernel:

And here's my recommendation for a 2.6.21 kernel:

Enable TC support in Shorewall

You need this support whether you use the builtin support or whether you provide your own tcstart script.

To enable the builtin traffic shaping and control in Shorewall, you have to do the following:

Using builtin traffic shaping/control

Shorewall's builtin traffic shaping feature provides a thin layer on top of the ingress qdesc, HTB and SFQ. That translation layer allows you to:

Those few features are really all that builtin traffic shaping/control provides; consequently, you need to understand HTB and/or HFSC and Linux traffic shaping as well as Netfilter packet marking in order to use the facility. Again, please see the links at top of this article.

For defining bandwidths (for either devices or classes) please use kbit or kbps (for Kilobytes per second) and make sure there is NO space between the number and the unit (it is 100kbit not 100 kbit). Using mbit, mbps or a raw number (which means bytes) could be used, but note that only integer numbers are supported (0.5 is not valid).

To properly configure the settings for your devices you need to find out the real up- and downstream rates you have. This is especially the case, if you are using a DSL connection or one of another type that do not have a guaranteed bandwidth. Don't trust the values your provider tells you for this; especially measuring the real download speed is important! There are several online tools that help you find out; search for "dsl speed test" on google (For Germany you can use arcor speed check). Be sure to choose a test site located near you.

This file allows you to define the incoming and outgoing bandwidth for the devices you want traffic shaping to be enabled. That means, if you want to use traffic shaping for a device, you have to define it here. For additional information, see shorewall-tcdevices (5).

Columns in the file are as follows:

Example 1. 

Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. The device has an outgoing bandwidth of 500kbit and an incoming bandwidth of 6000kbit

#INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 500kbit

This file allows you to define the actual classes that are used to split the outgoing traffic. For additional information, see shorewall-tcclasses (5).

/etc/shorewall/mangle and /etc/shorewall/rules

Important

Unlike rules in the shorewall-rules(5) file, evaluation of rules in this file will continue after a match. So the final mark for each packet will be the one assigned by the LAST tcrule that matches.

Also unlike rules in the shorewall-rules(5) file, the mangle (tcrules) file is not stateful. So every packet that goes into, out of or through your firewall is subject to entries in the mangle (tcrules) file.

Because mangle (tcrules) entries are not stateful, it is necessary to understand basic IP socket operation. Here is an edited excerpt from a post on the Shorewall Users list:

For the purposes of this discussion, the world is separated into clients and servers. Servers provide services to clients.

When a server starts, it creates a socket and binds the socket to an address. For AF_INET (IPv4) and AF_INET6 (IPv6) sockets, that address is an ordered triple consisting of an IPv4 or IPv6 address, a protocol, and possibly a port number. Port numbers are only used when the protocol is TCP, UDP, SCTP or DCCP. The protocol and port number used by a server are typically well-known so that clients will be able to connect to it or send datagrams to it. So SSH servers bind to TCP port 22, SMTP servers bind to TCP port 25, etc. We will call this port the SERVER PORT.

When a client want to use the service provided by a server, it also creates a socket and, like the server's socket, the client's socket must be bound to an address. But in the case of the client, the socket is usually given an automatic address binding. For AF_INET and AF_INET6 sockets. the IP address is the IP address of the client system (loose generalization) and the port number is selected from a local port range. On Linux systems, the local port range can be seen by cat /proc/sys/net/ipv4/ip_local_port_range. So it is not possible in advance to determine what port the client will be using. Whatever it is, we'll call it the CLIENT PORT.

Now:

Packets sent from the client to the server will have:

SOURCE PORT = CLIENT PORT

DEST PORT = SERVER PORT

Packets sent from the server to the client will have:

SOURCE PORT = SERVER PORT

DEST PORT = CLIENT PORT

Since the SERVER PORT is generally the only port known ahead of time, we must categorize traffic from the server to the client using the SOURCE PORT.

The fwmark classifier provides a convenient way to classify packets for traffic shaping. The /etc/shorewall/mangle (/etc/shorewall/tcrules) file is used for specifying these marks in a tabular fashion. For an in-depth look at the packet marking facility in Netfilter/Shorewall, please see this article.

For marking forwarded traffic, you must either set MARK_IN_FORWARD_CHAIN=Yes shorewall.conf or by using the :F qualifier (see below).

See shorewall-mangle(5) and shorewall-tcrules(5) for a description of the entries in these files. Note that the mangle file superseded the tcrules file in Shorewall 4.6.0.

The following examples are for the mangle file.

Example 2. 

All packets arriving on eth2 should be marked with 1. All packets arriving on eth3 and eth4 should be marked with 2. All packets originating on the firewall itself should be marked with 3.

#ACTION SOURCE DEST PROTO DPORT MARK(1) eth2 0.0.0.0/0 all MARK(2) eth3 0.0.0.0/0 all MARK(2) eth4 0.0.0.0/0 all MARK(3) $FW 0.0.0.0/0 all

Example 3. 

All GRE (protocol 47) packets destined for 155.186.235.151 should be marked with 12.

#ACTION SOURCE DEST PROTO DPORT MARK(12):T 0.0.0.0/0 155.182.235.151 47

Example 4. 

All SSH request packets originating in 192.168.1.0/24 and destined for 155.186.235.151 should be marked with 22.

#ACTION SOURCE DEST PROTO DPORT MARK(22):T 192.168.1.0/24 155.182.235.151 tcp 22

Example 5. 

All SSH packets packets going out of the first device in in /etc/shorewall/tcdevices should be assigned to the class with mark value 10.

#ACTION SOURCE DEST PROTO DPORT SPORT CLASSIFY(1:110) 0.0.0.0/0 0.0.0.0/0 tcp 22 CLASSIFY(1:110) 0.0.0.0/0 0.0.0.0/0 tcp - 22

Example 6. 

Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer traffic with packet mark 4.

This is a little more complex than otherwise expected. Since the ipp2p module is unable to determine all packets in a connection are P2P packets, we mark the entire connection as P2P if any of the packets are determined to match. We assume packet/connection mark 0 to means unclassified. Traffic originating on the firewall is not covered by this example.

#ACTION SOURCE DEST PROTO DPORT SPORT USER TEST MARK(1) 0.0.0.0/0 0.0.0.0/0 icmp echo-request MARK(1) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 MARK(4) 0.0.0.0/0 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0

The last four rules can be translated as:

"If a packet hasn't been classified (packet mark is 0), copy the connection mark to the packet mark. If the packet mark is set, we're done. If the packet is P2P, set the packet mark to 4. If the packet mark has been set, save it to the connection mark."

Example 7. 

Mark all forwarded VOIP connections with connection mark 1 and ensure that all VOIP packets also receive that mark (assumes that nf_conntrack_sip is loaded).

#ACTION SOURCE DEST PROTO DPORT SPORT USER TEST CONNBYTES TOS HELPER RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 1 0.0.0.0/0 0.0.0.0/0 all - - - - - - sip SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0

If you use ppp/pppoe/pppoa) to connect to your Internet provider and you use traffic shaping you need to restart shorewall traffic shaping. The reason for this is, that if the ppp connection gets restarted (and it usually does this at least daily), all “tc” filters/qdiscs related to that interface are deleted.

The easiest way to achieve this, is just to restart shorewall once the link is up. To achieve this add a small executable script to“/etc/ppp/ip-up.d”.

#! /bin/sh /sbin/shorewall refresh

Sharing a TC configuration between Shorewall and Shorewall6

Beginning with Shorewall 4.4.15, the traffic-shaping configuration in the tcdevices, tcclasses and tcfilters files can be shared between Shorewall and Shorewall6. Only one of the products can control the configuration but the other can configure CLASSIFY rules in its own mangle or tcrules file that refer to the shared classes.

To defined the configuration in Shorewall and shared it with Shorewall6:

Shorewall6 compilations to have access to the tcdevices and tcclasses files although it will create no output. That access allows CLASSIFY rules in /etc/shorewall6/mangle to be validated against the TC configuration.

In this configuration, it is Shorewall that controls TC configuration (except for IPv6 mangle). You can reverse the settings in the files if you want to control the configuration using Shorewall6.

Some network administrators feel that they have to divy up their available bandwidth by IP address rather than by prioritizing the traffic based on the type of traffic. This gets really awkward when there are a large number of local IP addresses.

This section describes the Shorewall facility for making this configuration less tedious (and a lot more efficient). Note that it requires that you install xtables-addons. So before you try this facility, we suggest that first you add the following OPTION to each external interface described in /etc/shorewall/tcdevices:

flow=nfct-src

If you shape traffic on your internal interface(s), then add this to their entries:

flow=dst

You may find that this simple change is all that is needed to control bandwidth hogs like Bit Torrent. If it doesn't, then proceed as described in this section.

The facility has two components:

  1. An IPMARK MARKing command in /etc/shorewall/mangle (/etc/shorewall/tcrules).

  2. An occurs OPTION in /etc/shorewall/tcclasses.

The facility is currently only available with IPv4.

In a sense, the IPMARK target is more like an IPCLASSIFY target in that the mark value is later interpreted as a class ID. A packet mark is 32 bits wide; so is a class ID. The major class occupies the high-order 16 bits and the minor class occupies the low-order 16 bits. So the class ID 1:4ff (remember that class IDs are always in hex) is equivalent to a mark value of 0x104ff. Remember that Shorewall uses the interface number as the major number where the first interface in tcdevices has major number 1, the second has major number 2, and so on.

The IPMARK target assigns a mark to each matching packet based on the either the source or destination IP address. By default, it assigns a mark value equal to the low-order 8 bits of the source address.

The syntax is as follows:

IPMARK[([{src|dst}][,[mask1][,[mask2][,[shift]]]])]

Default values are:

src
mask1 = 0xFF
mask2 = 0x00
shift = 0

src and dst specify whether the mark is to be based on the source or destination address respectively. The selected address is first shifted right by shift, then LANDed with mask1 and then LORed with mask2. The shift argument is intended to be used primarily with IPv6 addresses.

Example:

IPMARK(src,0xff,0x10100) Source IP address is 192.168.4.3 = 0xc0a80403 0xc0a80403 >> 0 = 0xc0a80403 0xc0a80403 LAND 0xFF = 0x03 0x03 LOR 0x10100 = 0x10103 So the mark value is 0x10103 which corresponds to class id 1:103.

It is important to realize that, while class IDs are composed of a major and a minor value, the set of minor values must be unique. You must keep this in mind when deciding how to map IP addresses to class IDs. For example, suppose that your internal network is 192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6). Your first notion might be to use IPMARK(src,0xFF,0x10000) so as to produce class IDs 1:1 through 1:6. But 1:1 is the class ID of the base HTB class on interface 1. So you might chose instead to use IPMARK(src,0xFF,0x10100) as shown in the example above so as to avoid minor class 1.

The occurs option in /etc/shorewall/tcclasses causes the class definition to be replicated many times.

The synax is:

When occurs is used:

  1. The associated device may not have the classify option.

  2. The class may not be the default class.

  3. The class may not have any tos= options (including tcp-ack).

The class should not specify a MARK value. Any MARK value given is ignored with a warning. The RATE and CEIL parameters apply to each instance of the class. So the total RATE represented by an entry with occurs will be the listed RATE multiplied by number.

Example:

/etc/shorewall/tcdevices:

#INTERFACE IN_BANDWIDTH OUT_BANDWIDTH eth0 100mbit 100mbit

/etc/shorewall/tcclasses:

#DEVICE MARK RATE CEIL PRIORITY OPTIONS eth0:101 - 1kbit 230kbit 4 occurs=6

The above defines 6 classes with class IDs 0x101-0x106. Each class has a guaranteed rate of 1kbit/second and a ceiling of 230kbit.

/etc/shoreall/mangle or /etc/shoreall/tcrules:

#ACTION SOURCE DEST IPMARK(src,0xff,0x10100):F 192.168.1.0/29 eth0

This facility also alters the way in which Shorewall generates a class number when none is given. Prior to the implementation of this facility, the class number was constructed by concatinating the MARK value with the either '1' or '10'. '10' was used when there were more than 10 devices defined in /etc/shorewall/tcdevices.

With this facility, a new method is added; class numbers are assigned sequentially beginning with 2. The WIDE_TC_MARKS option in shorewall.conf selects which construction to use. WIDE_TC_MARKS=No (the default) produces pre-Shorewall 4.4 behavior. WIDE_TC_MARKS=Yes (TC_BITS >= 14 in Shorewall 4.4.26 and later) produces the new behavior.

A Shorewall User's Experience

Chuck Kollars has provided an excellent writeup about his traffic shaping experiences.

Configuration to replace Wondershaper

You are able to fully replace the wondershaper script by using the buitin traffic control.. In this example it is assumed that your interface for your Internet connection is ppp0 (for DSL), if you use another connection type, you have to change it. You also need to change the settings in the tcdevices.wondershaper file to reflect your line speed. The relevant lines of the config files follow here. Please note that this is just a 1:1 replacement doing exactly what wondershaper should do. You are free to change it...

#INTERFACE IN_BANDWITH OUT_BANDWIDTH ppp0 5000kbit 500kbit#INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 5*full/10 full 1 tcp-ack,tos-minimize-delay ppp0 2 3*full/10 9*full/10 2 default ppp0 3 2*full/10 8*full/10 2#ACTION SOURCE DEST PROTO DPORT SPORT USER MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-request MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply # mark traffic which should have a lower priority with a 3: # mldonkey MARK(3):F 0.0.0.0/0 0.0.0.0/0 udp - 4666

Wondershaper allows you to define a set of hosts and/or ports you want to classify as low priority. To achieve this , you have to add these hosts to tcrules and set the mark to 3 (true if you use the example configuration files).

Setting hosts to low priority

lets assume the following settings from your old wondershaper script (don't assume these example values are really useful, they are only used for demonstrating ;-):

# low priority OUTGOING traffic - you can leave this blank if you want # low priority source netmasks NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28" # low priority destination netmasks NOPRIOHOSTDST=60.0.0.0/24 # low priority source ports NOPRIOPORTSRC="6662 6663" # low priority destination ports NOPRIOPORTDST="6662 6663"

This would result in the following additional settings to the mangle file:

#ACTION SOURCE DEST PROTO DPORT SPORT USER MARK(3) 192.168.1.128/25 0.0.0.0/0 all MARK(3) 192.168.3.28 0.0.0.0/0 all MARK(3) 0.0.0.0/0 60.0.0.0/24 all MARK(3) 0.0.0.0/0 0.0.0.0/0 udp 6662,6663 MARK(3) 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663 MARK(3) 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663 MARK(3) 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663

This is a simple setup for people sharing an Internet connection and using different computers for this. It just basically shapes between 2 hosts which have the ip addresses 192.168.2.23 and 192.168.2.42

#INTERFACE IN_BANDWITH OUT_BANDWIDTH ppp0 6000kbit 700kbit

We have 6mbit down and 700kbit upstream.

#INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 10kbit 50kbit 1 tcp-ack,tos-minimize-delay ppp0 2 300kbit full 2 ppp0 3 300kbit full 2 ppp0 4 90kbit 200kbit 3 default

We add a class for tcp ack packets with highest priority, so that downloads are fast. The following 2 classes share most of the bandwidth between the 2 hosts, if the connection is idle, they may use full speed. As the hosts should be treated equally they have the same priority. The last class is for the remaining traffic.

#ACTION SOURCE DEST PROTO DPORT SPORT USER MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-request MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply MARK(2):F 192.168.2.23 0.0.0.0/0 all MARK(3):F 192.168.2.42 0.0.0.0/0 all

Corresponding tcrules file:

#ACTION SOURCE DEST PROTO DPORT SPORT USER 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2:F 192.168.2.23 0.0.0.0/0 all 3:F 192.168.2.42 0.0.0.0/0 all

We mark icmp ping and replies so they will go into the fast interactive class and set a mark for each host.

If you are running traffic shaping in your dom0 and traffic shaping doesn't seem to be limiting outgoing traffic properly, it may be due to "checksum offloading" in your domU(s). Check the output of "shorewall show tc". Here's an excerpt from the output of that command:

class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0 Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0) rate 299288bit 3pps backlog 0b 0p requeues 0 lended: 53963 borrowed: 21361 giants: 90174 tokens: -26688 ctokens: -14783

There are two obvious problems in the above output:

  1. The rate (299288) is considerably larger than the ceiling (230000).

  2. There are a large number (90174) of giants reported.

This problem will be corrected by disabling "checksum offloading" in your domU(s) using the ethtool utility. See the one of the Xen articles for instructions.

As mentioned at the top of this article, there is an excellent introduction to HFSC at http://linux-ip.net/articles/hfsc.en/. At the end of that article are 'tc' commands that implement the configuration in the article. Those tc commands correspond to the following Shorewall traffic shaping configuration.

/etc/shorewall/tcdevices:

#INTERFACE IN_BANDWITH OUT_BANDWIDTH OPTIONS eth0 - 1000kbit hfsc

/etc/shorewall/tcclasses:

#INTERFACE MARK RATE CEIL PRIORITY OPTIONS 1:10 1 500kbit full 1 1:20 2 500kbit full 1 1:10:11 3 400kbit:53ms:1500b full 2 1:10:12 4 100kbit:30ms:1500b full 2

The following sub-section offers some notes about the article.

Where Did all of those Magic Numbers come from?

As you read the article, numbers seem to be introduced out of thin air. I'll try to shed some light on those.

There is very clear development of these numbers:

We then learn that the queuing latency can be reduced to 30ms if we use a two-part service curve whose first part is 400kbits/second. Where did those come from?

The final curious number is the latency for class 1:11 - 52.5ms. It is a consequence of everything that has gone before.

To acheive 400kbits/second with 1500-byte packets, 33.33 packets per second are required. So a packet from class 1:11 must be sent every 30 ms. As the article says, "...the maximum transmission delay of this class increases from 30ms to a total of 52.5 ms.". So we are looking for an additional 22.5 ms.

Assume that both class 1:11 and 1:12 transmit for 30 ms at 400kbits/second. That is a total of 800kbits/second for 30ms. So Class 1:11 is punished for the excess. How long is the punishment? The two classes sent 24,000 bits in 30ms; they are only allowed 0.030 * 500,000 = 15,000. So they are 9,000 bits over their quota. The amount of time required to transmit 9,000 bits at 400,000 bits/second is 22.5ms!.

Intermediate Functional Block (IFB) Devices

The principles behind an IFB is fairly simple:

The magic of an IFB comes in the fact that a filter may be defined on a real network interface such that each packet that arrives on that interface is queued for the IFB! In that way, the IFB provides a means for shaping input traffic.

To use an IFB, you must have IFB support in your kernel (configuration option CONFIG_IFB). Assuming that you have a modular kernel, the name of the IFB module is 'ifb' and may be loaded using the command modprobe ifb (if you have modprobe installed) or insmod /path/to/module/ifb.

By default, two IFB devices (ifb0 and ifb1) are created. You can control that using the numifbs option (e.g., modprobe ifb numifbs=1).

To create a single IFB when Shorewall starts, place the following two commands in /etc/shorewall/init:

modprobe ifb numifbs=1 ip link set ifb0 up

Entries in /etc/shorewall/mangle or /etc/shorewall/tcrules have no effect on shaping traffic through an IFB. To allow classification of such traffic, the /etc/shorewall/tcfilters file has been added. Entries in that file create u32 classification rules.

While this file was created to allow shaping of traffic through an IFB, the file may be used for general traffic classification as well. The file is similar to shorewall-mangle(5) with the following key exceptions:

The last point warrants elaboration. When looking at traffic being shaped by an IFB, there are two cases to consider:

  1. Requests — packets being sent from remote clients to local servers. These packets may undergo subsequent DNAT, either as a result of entries in /etc/shorewall/nat or as a result of DNAT or REDIRECT rules.

    Example: /etc/shorewall/rules:

    #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net dmz:192.168.4.5 tcp 80 - 206.124.146.177

    Requests redirected by this rule will have destination IP address 206.124.146.177 and destination port 80.

  2. Responses — packets being sent from remote servers to local clients. These packets may undergo subsequent DNAT as a result of entries in /etc/shorewall/nat or in /etc/shorewall/masq. The packet's destination IP address will be the external address specified in the entry.

    Example: /etc/shorewall/masq:

    #INTERFACE SOURCE ADDRESS eth0 192.168.1.0/24 206.124.146.179

    When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat would be:

    #ACTION SOURCE DEST ... SNAT(206.124.146.179) 192.168.1.0/24 eth0

    HTTP response packets corresponding to requests that fall under that rule will have destination IP address 206.124.146.179 and source port 80.

Beginning with Shorewall 4.4.15, both IPv4 and IPv6 rules can be defined in this file. See shorewall-tcfilters (5) for details.

Columns in the file are as follow. As in all Shorewall configuration files, a hyphen ("-") may be used to indicate that no value is supplied in the column.

CLASS

The interface name or number followed by a colon (":") and the class number.

SOURCE

SOURCE IP address (host or network). DNS names are not allowed.

DEST

DESTINATION IP address (host or network). DNS names are not allowed.

PROTO

Protocol name or number.

DPORT

Comma-separated list of destination port names or numbers. May only be specified if the protocol is TCP, UDP, SCTP or ICMP. Port ranges are supported except for ICMP.

SPORT

Comma-separated list of source port names or numbers. May only be specified if the protocol is TCP, UDP or SCTP. Port ranges are supported.

TOS

Specifies the value of the TOS field. The value can be any of the following:

The hex-numbers must be exactly two digits (e.g., 0x04).

LENGTH

Must be a power of 2 between 32 and 8192 inclusive. Packets with a total length that is strictly less than the specified value will match the rule.

Example:

I've used this configuration on my own firewall. The IFB portion is more for test purposes rather than to serve any well-reasoned QOS strategy.

/etc/shorewall/init:

qt modprobe ifb numifbs=1 qt ip link set dev ifb0 up

/etc/shorewall/interfaces:

#ZONE INTERFACE BROADCAST - ifb0

/etc/shorewall/tcdevices:

#INTERFACE IN_BANDWITH OUT_BANDWIDTH OPTIONS REDIRECT 1:eth0 - 384kbit classify 2:ifb0 - 1300kbit - eth0

/etc/shorewall/tcclasses:

#INTERFACE MARK RATE CEIL PRIORITY OPTIONS 1:110 - 5*full/10 full 1 tcp-ack,tos-minimize-delay 1:120 - 2*full/10 6*full/10 2 default 1:130 - 2*full/10 6*full/10 3 2:110 - 5*full/10 full 1 tcp-ack,tos-minimize-delay 2:120 - 2*full/10 6*full/10 2 default 2:130 - 2*full/10 6*full/10 3

/etc/shorewall/tcfilters:

#INTERFACE: SOURCE DEST PROTO DPORT SPORT # # OUTGOING TRAFFIC # 1:130 206.124.146.178 - tcp - 49441,49442 #BITTORRENT on wookie 1:110 206.124.146.178 #wookie 1:110 206.124.146.179 #SNAT of internal systems 1:110 206.124.146.180 #Work Laptop 1:110 - - icmp echo-request,echo-reply 1:110 - - icmp echo-reply 1:130 206.124.146.177 - tcp - 873,25 #Bulk Traffic # # INCOMING TRAFFIC # 2:110 - 206.124.146.178 #Wookie 2:110 - 206.124.146.179 #SNAT Responses 2:110 - 206.124.146.180 #Work Laptop 2:130 - 206.124.146.177 tcp 25 #Incoming Email.

You can examine the installed filters with the shorewall show filters command. What follows shows the output for eth0 with the filters shown above. Bold font are comments explaining the rules.

gateway:~ # shorewall-lite show filters Shorewall Lite 4.1.6 Classifiers at gateway - Fri Mar 21 08:06:47 PDT 2008 Device eth2: Device eth3: Device eth0: filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 3: ht divisor 1 <========= Start of table 3. parses TCP header filter parent 1: protocol ip pref 10 u32 fh 3::800 order 2048 key ht 3 bkt 0 flowid 1:130 (rule hit 102 success 0) match 03690000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 873 goes to class 1:130 filter parent 1: protocol ip pref 10 u32 fh 2: ht divisor 1 <========= Start of table 2. parses ICMP header filter parent 1: protocol ip pref 10 u32 fh 2::800 order 2048 key ht 2 bkt 0 flowid 1:110 (rule hit 0 success 0) match 08000000/ff000000 at nexthdr+0 (success 0 ) <========= ICMP Type 8 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 2::801 order 2049 key ht 2 bkt 0 flowid 1:110 (rule hit 0 success 0) match 00000000/ff000000 at nexthdr+0 (success 0 ) <========= ICMP Type 0 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1 <========= Start of table 1. parses TCP header filter parent 1: protocol ip pref 10 u32 fh 1::800 order 2048 key ht 1 bkt 0 flowid 1:130 (rule hit 0 success 0) match c1210000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 49441 goes to class 1:130 filter parent 1: protocol ip pref 10 u32 fh 1::801 order 2049 key ht 1 bkt 0 flowid 1:130 (rule hit 0 success 0) match c1220000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 49442 goes to class 1:130 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 <========= Start of Table 800. Packets start here! =============== The following 2 rules are generated by the class definition in /etc/shorewall/classes ================== filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:110 (rule hit 2204 success 138) match 00060000/00ff0000 at 8 (success 396 ) <========= TCP match 05000000/0f00ffc0 at 0 (success 250 ) <========= Header length 20 and Packet Length < 64 match 00100000/00ff0000 at 32 (success 138 ) <========= ACK filter parent 1: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:110 (rule hit 2066 success 0) match 00100000/00100000 at 0 (success 0 ) <========= Minimize-delay goes to class 1:110 =============== Jump to Table 1 if the matches are met ================== filter parent 1: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 bkt 0 link 1: (rule hit 2066 success 0) match ce7c92b2/ffffffff at 12 (success 1039 ) <========= SOURCE 206.124.146.178 match 00060000/00ff0000 at 8 (success 0 ) <========= PROTO TCP offset 0f00>>6 at 0 eat filter parent 1: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:110 (rule hit 2066 success 1039) match ce7c92b2/ffffffff at 12 (success 1039 ) <========= SOURCE 206.124.146.178 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:110 (rule hit 1027 success 132) match ce7c92b3/ffffffff at 12 (success 132 ) <========= SOURCE 206.124.146.179 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:110 (rule hit 895 success 603) match ce7c92b4/ffffffff at 12 (success 603 ) <========= SOURCE 206.124.146.180 goes to class 1:110 =============== Jump to Table 2 if the matches are met ================== filter parent 1: protocol ip pref 10 u32 fh 800::806 order 2054 key ht 800 bkt 0 link 2: (rule hit 292 success 0) match 00010000/00ff0000 at 8 (success 0 ) <========= PROTO ICMP offset 0f00>>6 at 0 eat =============== Jump to Table 3 if the matches are met ================== filter parent 1: protocol ip pref 10 u32 fh 800::807 order 2055 key ht 800 bkt 0 link 3: (rule hit 292 success 0) match ce7c92b1/ffffffff at 12 (success 265 ) <========= SOURCE 206.124.146.177 match 00060000/00ff0000 at 8 (success 102 ) <========= PROTO TCP offset 0f00>>6 at 0 eat

Understanding the output of 'shorewall show tc'

The shorewall show tc (shorewall-lite show tc) command displays information about the current state of traffic shaping. For each device, it executes the following commands:

echo Device $device: tc -s -d qdisc show dev $device echo tc -s -d class show dev $device echo

So, the traffic-shaping output is generated entirely by the tc utility.

Here's the output of for eth0. The configuration is the one shown in the preceding section (the output was obtained almost 24 hours later than the shorewall show filters output shown above).

Device eth0: ============== The primary queuing discipline is HTB (Hierarchical Token Bucket) ==================== qdisc htb 1: r2q 10 default 120 direct_packets_stat 9 ver 3.17 Sent 2133336743 bytes 4484781 pkt (dropped 198, overlimits 4911403 requeues 21) <=========== Note the overlimits and dropped counts rate 0bit 0pps backlog 0b 8p requeues 21 ============== The ingress filter. If you specify IN-BANDWIDTH, you can see the 'dropped' count here. ========= In this case, the packets are being sent to the IFB for shaping qdisc ingress ffff: ---------------- Sent 4069015112 bytes 4997252 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ============ Each of the leaf HTB classes has an SFQ qdisc to ensure that each flow gets its turn ============ qdisc sfq 110: parent 1:110 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 613372519 bytes 2870225 pkt (dropped 0, overlimits 0 requeues 6) rate 0bit 0pps backlog 0b 0p requeues 6 qdisc sfq 120: parent 1:120 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 18434920 bytes 60961 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 130: parent 1:130 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 1501528722 bytes 1553586 pkt (dropped 198, overlimits 0 requeues 15) rate 0bit 0pps backlog 11706b 8p requeues 15 ============= Class 1:110 -- the high-priority class =========== Note the rate and ceiling calculated from 'full' class htb 1:110 parent 1:1 leaf 110: prio 1 quantum 4800 rate 192000bit ceil 384000bit burst 1695b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 0 Sent 613372519 bytes 2870225 pkt (dropped 0, overlimits 0 requeues 0) rate 195672bit 28pps backlog 0b 0p requeues 0 <=========== Note the current rate of traffic. There is no queuing (no packet backlog) lended: 2758458 borrowed: 111773 giants: tokens: 46263 ctokens: 35157 ============== The root class ============ class htb 1:1 root rate 384000bit ceil 384000bit burst 1791b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 7 Sent 2133276316 bytes 4484785 pkt (dropped 0, overlimits 0 requeues 0) <==== Total output traffic since last 'restart' rate 363240bit 45pps backlog 0b 0p requeues 0 lended: 1081936 borrowed: 0 giants: 0 tokens: -52226 ctokens: -52226 ============= Bulk Class (outgoing rsync, email and bittorrent) ============ class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1900 rate 76000bit ceil 230000bit burst 1637b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 1501528722 bytes 1553586 pkt (dropped 198, overlimits 0 requeues 0) rate 162528bit 14pps backlog 0b 8p requeues 0 <======== Queuing is occurring (8 packet backlog). The rate is still below the ceiling. lended: 587134 borrowed: 966459 giants: 0 During peak activity, the rate tops out at around 231000 (just above ceiling). tokens: -30919 ctokens: -97657 ================= Default class (mostly serving web pages) =============== class htb 1:120 parent 1:1 leaf 120: prio 2 quantum 1900 rate 76000bit ceil 230000bit burst 1637b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 18434920 bytes 60961 pkt (dropped 0, overlimits 0 requeues 0) rate 2240bit 2pps backlog 0b 0p requeues 0 lended: 57257 borrowed: 3704 giants: 0 tokens: 156045 ctokens: 54178

Replacing builtin tcstart file

If you prefer your own tcstart file, just install it in /etc/shorewall/tcstart.

In your tcstart script, when you want to run the “tc” utility, use the run_tc function supplied by Shorewall if you want tc errors to stop the firewall.

  1. Set TC_ENABLED=Yes and CLEAR_TC=Yes

  2. Supply an /etc/shorewall/tcstart script to configure your traffic shaping rules.

  3. Optionally supply an /etc/shorewall/tcclear script to stop traffic shaping. That is usually unnecessary.

  4. If your tcstart script uses the “fwmark” classifier, you can mark packets using entries in /etc/shorewall/mangle or /etc/shorewall/tcrules.

Traffic control outside Shorewall

To start traffic shaping when you bring up your network interfaces, you will have to arrange for your traffic shaping configuration script to be run at that time. How you do that is distribution dependent and will not be covered here. You then should:

  1. Set TC_ENABLED=No and CLEAR_TC=No

  2. If your script uses the “fwmark” classifier, you can mark packets using entries in /etc/shorewall/mangle or /etc/shorewall/tcrules.

www.shorewall.org

Traffic Shaping - Knowledge Base

Traffic Shaping

Traffic Shaping involves in queueing traffic rather than dropping it.

Traffic Shaping terminology-

    Tc - Time interval (in milliseconds) over which the committed burst (Bc) can be sent. Tc = Bc/CIR

    Bc - Committed burst size (in bits). This is the amount of traffic that can be sent over an interval Tc

    CIR - Committed Information Rate (in bits per second). The rate defined in the traffic contract

    Shaped Rate - The rate at which a particular traffic is shaped. It could be same as CIR or higher than CIR.

    Be - Excess burst size (in bits). This is the number of bits that can be sent beyond Bc

A Cisco router divides 1 second into multiple sub-seconds. Above, 1 second is divided into 8 intervals (125ms each). Each interval is called Tc. During each Tc, the router sends a burst of traffic which is called Bc.

For example, to achieve a CIR (contract rate) of 128Kbps, the Cisco router will send 16000 bits (Bc = 128000 * 0.125) during the first interval and stop sending any further traffic until the next interval. So, if the access link speed is 1.544Mbps, it will take the Cisco router 10.3ms to send 16000 bits. For the rest of the interval, it will not send any traffic.

Traffic Shaping with no Excess Burst:

Traffic shaping involves the concept of Token Bucket. In the token bucket scenario, each token lets you send 1 bit. The size of the token bucket is Bc. There are two actions that revolve around token bucket and the tokens-

  1. Re-filling of bucket with new tokens
  2. Consumption of tokens by the Shaper to earn the right to send packets
At the beginning of each Tc interval, the token bucket is filled with tokens, but no more than Bc. If there is not enough room in the bucket as the tokens were not used up in the previous interval, some tokens spill out. Those spilled tokens cant be used.

Every time a packet is sent, the Shaper spends tokens from the bucket to buy the right to forward the packet. When the Shaper tries to send the packet, and there are not enough tokens in the bucket, the Shaper must wait until the next interval when the bucket is refilled.

In Cisco IOS, traffic shaping with no excess burst can be configured using shape average <shaping-rate> command from policy-map configuration mode. The "shaping-rate" could be same as CIR or slightly higher than CIR but less than access-link rate.

The following example shows the configuration of average traffic shaping. Traffic shaping is applied to outgoing TCP traffic generated via Iperf.

Traffic shaping with no excess burst

class-map P5001 match access-group 101!policy-map SHAPE class 5001  shape average percent 50!interface fastethernet 0/1 bandwidth 1000 service-policy output SHAPE!

Cisco recommends only the shaping rate should be specified and the inbuilt algorithm will calculate appropriate Bc. Cisco IOS chooses Tc=24ms here. The Bc is calculated as 12000 bits. The Increment value indicates the number of tokens replenished every Tc interval. Also note, the Shaping Active suggests no shaping. The reason being if there is no traffic flowing through the interface, shaping will not be in effect. The Byte Limit indicates the size of the token bucket.
output
Router# show policy-map interface fastethernet 0/1 FastEthernet0/1

  Service-policy output: SHAPE

    Class-map: P5001 (match-all)      5368 packets, 7598188 bytes      5 minute offered rate 99000 bps, drop rate 0 bps      Match: access-group 101      Traffic Shaping           Target/Average   Byte   Sustain   Excess    Interval  Increment             Rate           Limit  bits/int  bits/int  (ms)      (bytes)               50 (%)                0 (ms)      0 (ms)           500000/500000    3000   12000     12000     24        1500

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping        Active Depth                         Delayed   Delayed   Active        -      0         5367      7597242   5343      7587026   no

    Class-map: class-default (match-any)      457 packets, 33974 bytes      5 minute offered rate 0 bps, drop rate 0 bps      Match: any

When Iperf was initiated to generate TCP traffic with 4 different flows, the maximum throughput it could achieve was 481kbps (~500kbps). This is almost equal to the shaping rate 500kbps.
Iperf output

C:\>iperf -c 192.168.2.10 -p 5001 -P 4 -t 60------------------------------------------------------------Client connecting to 192.168.2.10, TCP port 5001TCP window size: 8.00 KByte (default)------------------------------------------------------------[1912] local 192.168.1.10 port 1053 connected with 192.168.2.10 port 5001[1880] local 192.168.1.10 port 1054 connected with 192.168.2.10 port 5001[1864] local 192.168.1.10 port 1055 connected with 192.168.2.10 port 5001[1848] local 192.168.1.10 port 1056 connected with 192.168.2.10 port 5001[ ID] Interval       Transfer     Bandwidth[1864]  0.0-60.5 sec   888 KBytes   120 Kbits/sec[1848]  0.0-60.9 sec   896 KBytes   120 Kbits/sec[1880]  0.0-61.2 sec   904 KBytes   121 Kbits/sec[1912]  0.0-61.2 sec   904 KBytes   121 Kbits/sec[SUM]  0.0-61.2 sec  3.51 MBytes   481 Kbits/sec

Traffic Shaping with Excess Burst:

Traffic shaping implements Be by making the token bucket bigger; of the size of (Bc + Be). There are now Bc+Be worth of tokens in the bucket. Still, at the start of each interval Tc, the Shaper fills the bucket with Bc amount of tokens. However, if due to inactivity during some interval (like in figure 1 above), the bucket can accommodate those Bc worth of tokens since its size has been increased. Now, in the next Tc interval, if there are more bits to send, the Shaper can use these Bc+Be tokens to send that amount of bits. In essence, exceed the shaping rate as long as there are extra tokens left in the bucket.

The diagram below shows that since there was no activity during fifth Tc interval, the Shaper used up those extra tokens and sent Bc+Be worth of bits in the sixth interval.

Shaping at Peak rate:

With shape peak, CB shaping allows Bc+Be bits to be sent every interval even if there has been no period of inactivity. The Shaper replenishes Bc+Be tokens into the bucket.

In Cisco IOS, peak traffic shaping can be configured using shape peak <shaping-rate> command from policy-map configuration mode.

The following example shows the configuration of peak traffic shaping. Traffic shaping is applied to outgoing TCP traffic generated via Iperf.

peak traffic shaping

class-map P5001 match access-group 101!policy-map SHAPE class 5001  shape peak percent 50!interface fastethernet 0/1 bandwidth 1000 service-policy output SHAPE!

Again, the Cisco IOS calculates the appropriate Bc and Be values. It uses Tc=24ms.
Router output
Router# show policy-map interface fastethernet 0/1 FastEthernet0/1

  Service-policy output: SHAPE

    Class-map: P5001 (match-all)      5335 packets, 7555414 bytes      5 minute offered rate 95000 bps, drop rate 0 bps      Match: access-group 101      Traffic Shaping           Target/Average   Byte   Sustain   Excess    Interval  Increment             Rate           Limit  bits/int  bits/int  (ms)      (bytes)               50 (%)                0 (ms)      0 (ms)          1000000/500000    3000   12000     12000     24        3000

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping        Active Depth                         Delayed   Delayed   Active        -      0         5334      7554468   5317      7550502   no

    Class-map: class-default (match-any)      170 packets, 12700 bytes      5 minute offered rate 0 bps, drop rate 0 bps      Match: any

The Iperf output shows that the maximum throughput achieved this time is almost double than average shaping rate.
Iperf output

C:\>iperf -c 192.168.2.10 -p 5001 -P 4 -t 60------------------------------------------------------------Client connecting to 192.168.2.10, TCP port 5001TCP window size: 8.00 KByte (default)------------------------------------------------------------[1912] local 192.168.1.10 port 1061 connected with 192.168.2.10 port 5001[1880] local 192.168.1.10 port 1062 connected with 192.168.2.10 port 5001[1864] local 192.168.1.10 port 1063 connected with 192.168.2.10 port 5001[1848] local 192.168.1.10 port 1064 connected with 192.168.2.10 port 5001[ ID] Interval       Transfer     Bandwidth[1864]  0.0-60.4 sec  1.73 MBytes   240 Kbits/sec[1880]  0.0-60.5 sec  1.73 MBytes   240 Kbits/sec[1912]  0.0-60.5 sec  1.73 MBytes   240 Kbits/sec[1848]  0.0-60.5 sec  1.73 MBytes   240 Kbits/sec[SUM]  0.0-60.5 sec  6.93 MBytes   960 Kbits/sec

sites.google.com

Простой шейпинг трафика в Cisco

Материал просмотрен 3,140 раз(а)

Шейпинг трафика – ограничение пропускной способности канала по определенным критериям. Возможно так же использование QoS (приоритезация). Типичная ситуация. Есть канал от провайдера и несколько абонентов. Нужно разделить его согласно “купленным билетам”. Метод простой, “деревянный”, но действенный.

Взглянем на топологию.

Топология сегмента

Как видно из скрина, мы имеем три виртуальные машины (для простоты я загрузил Linux Microcore), а так же роутер R1. В целях распределения (“вилка”) добавил коммутатор SW1, который играет роль… да просто разделяет один поток на два узла.

Так, с запада у нас якобы сервер 10.0.0.2/24 (на роутере соответственно 10.0.0.1/24). С востока 192.168.0.1/24 на роутере и узлы, админский 192.168.0.10/24 и пользовательский 192.168.0.2/24. С маской я не парился, не до этого.

Настройка серверной части.

Настройка интерфейса

Клиентские настраиваются аналогично с соответствующими адресами.

Теперь пришла пора роутера.R1#conf tEnter configuration commands, one per line. End with CNTL/Z.R1(config)#int fa0/0R1(config-if)#ip addr 10.0.0.1 255.255.255.0R1(config-if)#no shutR1(config-if)#*Mar 1 00:08:50.355: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up*Mar 1 00:08:51.355: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, chR1(config-if)#exitR1(config)#int fa0/1R1(config-if)#ip addr 192.168.0.1 255.255.255.0R1(config-if)#no shutR1(config-if)#*Mar 1 00:10:01.975: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up*Mar 1 00:10:02.975: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, chR1(config-if)#exit

Вот как-то так. Это пока предварительно, чтобы узлы пинговались все. Легко проверить.

Теперь создаём ACL-ы. Это описывалось в соответствующей статье. По ACL-ам будем разделять пользователей, поэтому я просто сделаю через IP адреса.

R1(config)#access-list 102 permit ip 10.0.0.0 0.0.0.255 192.168.0.10 0.0.0.0R1(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 192.168.0.2 0.0.0.0R1(config)#class-map LitlAdminR1(config-cmap)#match access-group 102R1(config-cmap)#exitR1(config)#class-map LitlUserR1(config-cmap)#match access-group 101R1(config-cmap)#exitR1(config)#

Здесь мы создали два класса LitlAdmin для админов (совпадение с ACL 102) и LitlUser для пользователя (совпадение с ACL 101).

R1(config)#policy-map MyPolicyR1(config-pmap)#class LitlAdminR1(config-pmap-c)#shape average 512000R1(config-pmap-c)#exitR1(config-pmap)#class LitlUserR1(config-pmap-c)#shape average 256000R1(config-pmap-c)#exit

Следующий шаг – создание политики. Политика – это как бы набор действий. В ней мы перечисляем нужные классы и указываем что с ними делать. То есть есть политика MyPolicy, в которой сказано, что для класса LitlAdmin нужно шейпить трафик до 512 КБит/сек, а для класса LitlUser – до 256 КБит/сек

Так как классы привязываются непосредственно к ACL-ам, то будет понятно для какого IP какая скорость будет.

Ну чтоже, осталось повесить политику на выходной интерфейс и можно замерять скорость:

R1(config)#int fa0/1R1(config-if)#service-policy output MyPolicy

Замеры скорости

Для этого воспользуемся утилиткой iperf.

Замерим пока “голую” скорость между админом и юзером (не через роутер):

Чистая скорость

Чистыми получаем почти 60 Мбит/с. Пора пускать трафик через роутер.

На пользовательском хосте запустим серверную часть:

# iperf -s

А на сервере – клиентскую

# iperf -c 192.168.0.2

Пользовательская машина

На сервере

Почему именно так? Таким образом мы будем замерять трафик, который пойдёт НА клиентскую машину, чтобы попасть под правила ACL.

А вот результаты с админским узлом:

Админский узел

Примерно так и режется скорость, согласно нашим планам. Здесь всё дело в ACL, если что-то не работает – копать туда. Смотреть, попадают ли пакеты под ACL так:

R1# show access-list

Друзья! Вступайте в нашу группу Вконтакте, чтобы не пропустить новые статьи! Хотите сказать спасибо? Ставьте Like, делайте репост! Это лучшая награда для меня от вас! Так я узнаю о том, что статьи подобного рода вам интересны и пишу чаще и с большим энтузиазмом!

Также, подписывайтесь на наш канал в YouTube! Видео выкладываются весьма регулярно и будет здорово увидеть что-то одним из первых!

litl-admin.ru

Traffic Shaping - O'Reilly Media

Traffic Shaping

08/24/2000

Traffic shaping is the general term given to a broad range of techniques designed to enforce prioritization policies on the transmission of data over a network link. In this month's column, we'll look at some of the IP traffic shaping tools available for Linux and a simple example of how to use them.

Most of us will at some time or another have experienced the effects of network latency and queuing. A common experience is the sometimes frustrating delay before characters are echoed when ssh- or Telnet-connected to a remote host. Any of you who have been forced to use a low speed dial-up PPP or SLIP connection will have seen the effect that a file transfer has on interactive traffic over the connection. The file transfer easily consumes most of the link bandwidth, forcing the Telnet or ssh data to be queued, waiting for a free slot before being transmitted across the link.

This problem occurs because the datagrams containing the file transfer data are given equal priority on the link to the Telnet or ssh datagrams. No consideration is given to the type of data contained within the datagram when queuing it for transmission; queuing is performed on a "First In, First Out" (FIFO) basis, and the datagrams are scheduled for transmission on a "First Come, First Served" basis. When a new datagram arrives at the queue, it is added to the tail of the queue; when the link bandwidth becomes available, the datagram at the head of the queue is transmitted.

Traffic shaping allows us to implement a specific policy that alters the way in which data is queued for transmission. Datagrams associated with file transfers are generally quite large, often MTU sized, while datagrams associated with interactive sessions like ssh or Telnet are often quite small. All data takes time to transmit over a network connection; the larger the datagram, the longer it takes. As a result, if you have to wait for a large datagram associated with a file transfer to be transmitted before your Telnet keystroke can be transmitted, you will perceive considerable delay. Additionally, because file transfers don't need to wait for human input to continue, you can be sure that at any time you hit a key in your Telnet session, there are already not one, but a number of datagrams from the file transfer session sitting in the queue and further compounding the delay. Ultimately, it will take the same amount of time to transmit all of a set of datagrams across a network link, no matter what order they are transmitted in, so at some point you may decide that it is worth trading off a small amount of delay in completing the file transfer for more normal response times for your interactive sessions like ssh or Telnet by giving them higher priority.

Implicit here is a key principle: Traffic shaping affects only data to be transmitted across a link; it is mostly too late to shape data after it has been received. This has deployment implications that we'll look at later.

The shaper device

For some time a simple IP shaping mechanism has been supported by the Linux kernel. This is called the shaper device. The shaper was primarily designed to limit the amount of bandwidth that nominated data paths could consume. The shaper device is a virtual network device that is configured with two important parameters, a bandwidth limit and a physical network device to which it is attached. The sum total of traffic routed via the shaper device will be limited to meet the bandwidth cap by simply discarding any datagrams that would cause the cap to be exceeded.

The shaper device is included in your kernel if you select the Traffic Shaper (EXPERIMENTAL) option when compiling it. It may be built as either a loadable module or an inbuilt device. The shaper uses a special configuration tool called /usr/sbin/shapecfg and is included in most Linux distributions.

To use the shaper, you first attach a physical network device to the master shaper device: shaper0. You then configure the shaper rate limit. Finally you route the traffic you wish to be rate limited via the shaper network device.

Let's assume we have a simple network that looks something like that depicted in Figure 1. We have three Ethernet-based IP networks: 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24. Internetworking these we have two routers, unimaginatively named A and B.

Figure 1. A simple network.

Further, imagine that we wish to shape all traffic routed from the 192.168.1 network to the 192.168.3 network to 5 Mbps while allowing all other traffic to be unshaped.

Remembering that shaping applies only in the forward direction, it should be clear that it makes sense to configure our shaping on the A router. The network configuration on the A router might look something like:

# Configure our ethernet devices # ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up ifconfig eth2 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 up # Associate the shaper device with our eth2 # device and apply the rate limit # # You must do this before bringing the shaper # device up. # shapecfg attach shaper0 eth2 # associate with eth0 shapecfg speed shaper0 5000000 # shape rate limit set to 5Mbps # Configure our shaper device # # The shaper device will usually be configured # with the same IP address as # that of the associated physical device. # ifconfig shaper0 192.168.2.1 netmask 255.255.255.0 up # Configure our routing such that traffic destined # for the 192.168.3 network is shaped and all other # traffic is unshaped. # route add default gw 192.168.2.2 dev eth2 route add 192.168.3.0 netmask 255.255.255.0 gw 192.168.2.2 dev shaper0

This configuration would cause all traffic routed via the shaper0 network device of router A to be rate limited to 5 Mbps. Any data received by the shaper device that would allow it to stay within the set bandwidth limit is sent to the associated physical device for transmission. Any data that would cause the limit to be exceeded is dropped (thrown away).

All traffic routed directly via the Ethernet device is unshaped. In our example any data routed via our default route (most likely destined for the 192.168.2 network!) will be unshaped.

If we wanted to bandwidth limit the data flowing in the reverse direction, i.e., from the 192.168.3 network to the 192.168.1 network, we would use an almost identical configuration on the B router (remember that shaping works in the forward direction only), substituting appropriate IP addresses to reflect the data flowing from right to left on our diagram.

If you carefully design your routing, you can produce a variety of simple and functional IP traffic shaping designs using the shaper device. Exploiting the ip policy routing tool, you could for example cause shaping to be applied only to data sourced from chosen hosts. You can shape anything you can route.

QoS Packet Scheduling, more sophisticated shaping

While the shaper device is useful in many circumstances, many real-world applications demand more flexible and sophisticated shaping techniques. A number of standards exist to implement "Quality of Service" (QoS) in an IP environment. The best known of these are the "Resource ReSerVation Protocol" (RSVP) described in RFC-2205, "Integrated Services" described in RFC-1633, and "Differentiated Services" described in RFC-2475. These each rely heavily on the ability of routers, especially at the edge of a network, to be able to shape the traffic flows they are carrying.

Linux supports a number of the most important QoS mechanisms in quite a flexible and powerful way. Packet classification methods supported include RSVP, firewall marking, route-based, and Ugly 32-bit key. Some of the supported scheduling disciplines are class-based queues (CBQ), token bucket flows (TBF), 3-band priority queues, random early drop (RED), stochastic fairness queueing (SFQ), and Clark-Shenker-Zhang (CSZ). Kernel support for these is provided in the QoS and/or fair queueing kernel configuration menu of the Networking options menu. You should select each of the datagram classifiers and schedulers that you will require. They may be compiled as loadable modules, and this is probably a good idea. Each of the classifiers and schedulers may be combined in a multitude of ways to meet a wide variety of QoS and IP traffic requirements.

The primary tool for configuration of the Linux QoS features is the /sbin/tc (Traffic Control) tool included in the iproute package. To use the tc tool, you must have support for the Kernel/User netlink socket in your kernel.

This is a very rich and complex topic. There is not enough space in this column to adequately cover all you will need to know to deploy IP QoS in your Linux-based networking environment. Fortunately, some good documentation is available on-line that will help you. Saravanan Radhakrishnan has a published document entitled the Linux-IP-QoS-HOWTO; this document provides a good description of the way that the various QoS mechanisms have been implemented in Linux and worked examples of how to use the tc tool.

In a future column, I'll present a worked example of a QoS deployment. In the meantime, have fun exploring the features available and experiment!

Terry Dawson is the author of a number of network-related HOWTO documents for the Linux Documentation Project, a co-author of the 2nd edition of O'Reilly's Linux Network Administrators Guide, and is an active participant in a number of other Linux projects.

Read more Linux Network Administration columns.

Discuss this article in the O'Reilly Network Linux Forum.

Return to the Linux DevCenter.

 

www.onlamp.com


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