Ограничение полосы пропускания

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

Обратите внимание что ссылки на актуальные скрипты LANBilling будут добавлены в течение недели. В данный момент они унифицируются. И могут быть высланы по дополнительному запросу по e-mail в любой момент.

В LANBilling имеется возможность привязки ограничения пропускной способности канала как к учетной записи, так и к тарифу абонента. Установив определенное значение скорости в интерфейсе LANBilling, вы всего лишь добавляете новое свойство учетной записи, но это никак не влияет на фактическую пропускную способность канала пользователя. Дело в том, что реальная регулировка полосы пропускания (шейпинг, от английского shaping) возможна только на маршрутизирующих (коммутирующих) устройствах, через которые проходит трафик. В качестве таких устройств могут выступать PC-маршрутизаторы, маршрутизаторы cisco, управляемые коммутаторы (например, HP Procurve) и т.п. К сожалению, универсального интерфейса взаимодействия с подобными устройствами не существует, поэтому перед системным администратором встает задача настройки этого взаимодействия (написание дополнительных модулей, скриптов управления и т.п.), которое в общем случае определяется спецификой используемого оборудования, топологией сети и другими факторами.

В LANBilling предлагаются следующие механизмы взаимодействия с внешними системами, осуществляющими шейпинг:

1. Средствами внешних скриптов. По определенному событию LANBilling запускает внешний скрипт с рядом параметров, относящихся к конкретной учетной записи. Среди этих параметров имеется значение полосы пропускания, установленной для пользователя (см. описание vg-скриптов в документации: разделы «Файл конфигурации billing.conf», «Система контроля доступа»). Этот скрипт должен осуществлять управление шейпером.

2. При помощи RADIUS-атрибутов. Речь идет об услугах VPN и DialUP, когда NAS является устройством, осуществляющим шейпинг. В ответе на запрос аутентификации RADIUS сервер (он же агент LANBilling) может отсылать атрибут, определенный для данного абонента, который содержит в себе инструкции по управлению пропускной способностью устанавливаемого соединения. В данном случае необходима поддержка этой возможности программным обеспечение со стороны NAS'а. Среди устройств, поддерживающих данный механизм, можно выделить маршрутизаторы Cisco Systems и коммутаторы HP Procurve.

Примеры управляющих скриптов:

Cisco

Маршрутизаторы Сisco Systems позволяют делать шейпинг как по входящему, так и по исходящему трафику (возможность зависит от версии IOS).

1. Статическая привязка скорости к IP адресу

!
interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
rate-limit output access-group 2055 64000 8000 8000 conform-action transmit exceed-action drop
rate-limit output access-group 2057 128000 16000 16000 conform-action transmit exceed-action drop
!
access-list 2055
permit ip any host 192.168.0.107
deny ip any any
!
access-list 2057
permit ip any host 192.168.0.3
deny ip any any
!

В данном примере конфигурации маршрутизатора на интерфейсе FastEthernet0/0 созданы два правила по ограничению исходящего (по отношению к интерфейсу) трафика. Под эти правила согласно access-list попадает трафик хоста 192.168.0.107 (ограничение 64 Кбит) и 192.168.0.3(ограничение 128 Кбит). Автоматизировав редактирование этих инструкций для каждого пользователя, можно динамически управлять пропускной способностью из интерфейса LANBilling. В качестве примера автоматизации можно рассмотреть следующий скрипт. Скрипт написан на языке perl использует telnet для доступа к маршрутизатору и нуждается в редактировании параметров доступа в начале скрипта (cisco_ip, cisco_password, cisco_enable). Этот скрипт принимает в качестве параметров ip адрес, маску и значение пропускной способности, и должен вызываться из процедур vg_on/vg_off.

2. Динамическая привязка скорости к интерфейсу с помощью RADIUS-атрибутов

Когда DialUP (VPN) пользователь успешно прошел аутентификацию, на маршрутизаторе создается новый виртуальный интерфейс. При этом RADIUS агент (сервер) в ответном пакете может передать ряд VSA атрибутов, определяющих параметры вновь созданного соединения. В контексте решения интересует установка значения пропускной способности на этом интерфейсе.

За установку значения полосы пропускания отвечает следующий атрибут:

Radius Code = Access-Accept,
Номер атрибута = 26 (VSA),
Номер Vendor'а = 9 (Cisco),
Номер VSA атрибута = 1,
Тип = строка,
Значение атрибута = lcp:interface-config#1=rate-limit output 192000 24000 24000 conform-action transmit exceed-action drop

В данном примере устанавливается скорость 192kbps на исходящий по отношению к интерфейсу на cisco трафик, т.е. на входящий трафик для пользователя. Ознакомиться с конфигурированием rate-limit на Cisco можно здесь.

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

Linux маршрутизатор

1. Средства ядра ОС

В ОС Linux есть весьма мощное средство управления трафиком - утилита tc, входящая в пакет iproute2. Вся работа с трафиком, в том числе реализация QoS, происходит в ядре. Пакет iproute2 по сути представляет из себя интерфейс взаимодействия с ядром ОС. В интернет можно найти большое количество статей на эту тему (теперь даже на русском языке). В двух словах механизм управления полосой пропускания можно описать следующим образом. На интерфейсе создается очередь пакетов (qdisc). Очередь обрабатывается в соответствии с одним из возможных алгоритмов (PFIFO, CBQ, HTB, TBF, SFQ, RED и т.д.). Существуют бесклассовые и классовые qdisc. Последние допускают создание разветвленной схемы классов трафика в очереди, что обеспечивает более гибкое управление трафиком. Пакет может быть отнесен к тому или иному классу в соответствии с правилами фильтров.

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

Нас будет интересовать только ограничение полосы пропускания для конкретного пользователя. Рассмотрим простейший случай: требуется ограничить скорость на интерфейсе до требуемого значения, скажем 128 Кб/с. Такая необходимость может возникнуть при использовании PoPToP, когда для каждого пользователя создается свой ppp интерфейс. Здесь имеет смысл ограничивать скорость на всем интерфейсе без применения каких-либо фильтров. Для этих целей лучше всего подойдет бесклассовый qdisc TBF.

#tc qdisc add dev ppp0 root tbf rate 128kbit burst 4kb latency 70ms minburst 1540

Этой командой ограничивается исходящая скорость на интерфейсе ppp0 (т.е. скорость входящего трафика для пользователя).

Использованы следующие параметры:

rate - максимальная скорость потока.

burst - количество байт данных, которые можно поместить в буфер в единицу времени. Чем выше скорость потока, тем больше должно быть значение burst. burst не может быть меньше значения MTU (minburst) - 1540 байт для ethernet.

latency - определяет размер буфера по максимальному времени нахождения пакета в буфере. Можно вместо этого указать размер буфера в байтах (параметр limit).

2. Пример использования TC

#tc qdisc add dev eth0 root handle 1: htb
#tc class add dev eth0 parent 1: classid 1:10 htb rate 16kbps burst 2kbps
#tc class add dev eth0 parent 1: classid 1:20 htb rate 32kbps burst 2kbps
#tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.10 flowid 1:10
#tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.20 flowid 1:20
#tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
#tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10

Первой инструкцией на интерфейсе создается htb qdisc. Затем от него ответвляются 2 класса, для которых резервируется скорость 16 и 32 Кбайт/с. Следующие 2 инструкции - это фильтры, привязывающие трафик, принадлежащий к данному ip к конкретному классу. Трафик, который не попадает под правила фильтров, обрабатывается стандартным образом (без ограничений). Следующие 2 команды не являются обязательными. Они определяют тип очереди (sfq qdisc) в каждом из двух созданных классов. По умолчанию всегда используется pfifo очередь, пакеты в которой обрабатываются по принципу first-in-firts-out.

В sfq алгоритме очередность пакетов определяется случайным образом так, чтобы обеспечить равномерное распределение полосы между между различными приложениями (точнее между потоками, определяемыми по src ip, dst ip, src port). Применение sfq в некоторых случаях может помочь избежать ситуации, когда процесс закачки полностью занял полосу и в результате остальные приложения не могут отправлять пакеты.

В вышеприведенном примере мы выделяем гарантированную полосу для каждого из двух пользователей, при этом неиспользуемая часть зарезервированной для них полосы не может быть использована другими. Допуская, что вся сеть 192.168.0.0/24 состоит из пользователей, для которых нужно установит ограничение в 128 Кбит/с каждому, но не имеется желания выделять на них более 2 Мбит/с. В этом случае конфигурация может быть следующей:

#tc qdisc add dev eth0 root handle 1: htb
#tc class add dev eth0 parent 1: classid 1:1 htb rate 250kbps burst 10kbps
#tc class add dev eth0 parent 1:1 classid 1:10 htb rate 16kbps ceil 250kbps burst 2kbps
#tc class add dev eth0 parent 1:1 classid 1:20 htb rate 16kbps ceil 250kbps burst 2kbps
#tc class add dev eth0 parent 1:1 classid 1:30 htb rate 16kbps ceil 250kbps burst 2kbps
...
#tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.1 flowid 1:10
#tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.2 flowid 1:20
#tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.2 flowid 1:30
...

В этом случае пользовательские классы создаются как подклассы одного root класса, определяющего общую пропускную способность, полоса в 2 Мбит/с делится между всеми подклассами в соответствии с их параметрами.

Динамическое управление настройками шейпера через LANBilling должно быть реализовано как часть скриптов vg_on, vg_off, vg_edit. При старте агента эти скрипты запускаются для всех пользователей (vg_off для заблокированных, vg_on для активных). Соответственно vg_on должен добавлять правило для шейпера, а vg_off его удалять. Так же можно использовать vg_create, vg_delete и vg_edit, которые запускаются соответственно при создании, удалении и редактировании учетной записи. В параметрах скрипту передается все необходимое - ip, netmask, полоса пропускания.

Примеры скриптов можно посмотреть здесь.

FreeBSD маршрутизатор

Во FreeBSD существуют две различные реализации QoS: DUMMYNET и ALTQ. Первая используется совместно с ipfw и содержится в базовой комплектации ОС. ALTQ до недавнего времени приходилось устанавливать отдельно, в отличие от dummynet здесь реализованы более гибкие механизмы управления очередями (CBQ, RED...). Для задачи решаемой в рамках этого документа - простого ограничения полосы пропускания для пользователя (группы пользователей) - вполне подойдет dummynet.

1. Примеры настройки шейпера с использованием ipfw+dummynet

В первую очередь, ядро должно быть сконфигурировано со следующими опциями:

options IPFIREWALL
options DUMMYNET
options HZ=1000

Управление трафиком осуществляется при помощи двух объектов: канал или труба(pipe) и очередь(queue). Каналы обладают такими свойствами как пропускная способность, размер очереди пакетов и дополнительная задержка каждого пакета. Канал по сути имитирует линк заданной «толщины». Очереди осуществляют распределение полосы пропускания в соответствии с заданными весами(WFQ).

Канал определяется следующим правилом:

#ipfw pipe 1 config bw 256Kbits queue 20

Канал с номером 1 будет иметь пропускную способность 512 Кбит/с и очередь размером в 40 слотов(пакетов). Направления трафика в данный канал осуществляется обычным правилом firewall'а:

#ipfw add pipe 1 ip from any to 192.168.0.1

Таким образом весь трафик, идущий на ip 192.168.0.1 в локальной сети будет ограничен согласно параметрам созданного pipe'а. Для каждого пользователя в LANBilling с установленным ограничением скорости нужно создать свой pipe и соответствующее правило ipfw. Однако эту задачу можно несколько упростить, благодаря возможности использовать маску при создании канала. Продемонстрируем на примере:

#ipfw pipe 1 config mask dst-addr 0xffffffff bw 256Kbits queue 20

Созданный таким образом канал на самом деле является шаблоном, на основе которого создаются каналы для каждого нового адреса назначения (dst-addr).

Можно статически прописать шаблоны всех используемых скоростей и с помощью средств LANBilling динамически управлять только правилами ipfw, направляющими трафик в тот или иной канал:

#ipfw pipe 1 config mask dst-addr 0xffffffff bw 64Kbits queue 10
#ipfw pipe 2 config mask dst-addr 0xffffffff bw 128Kbits queue 10
#ipfw pipe 3 config mask dst-addr 0xffffffff bw 256Kbits queue 20
#ipfw pipe 4 config mask dst-addr 0xffffffff bw 512Kbits queue 40

2. Пример использования очередей (queue)

Часто возникает необходимость использования приоритезации трафика. Предположим, есть несколько привилегированных пользователей(VIP), которым нужно гарантировать хорошую пропускную способность даже в случае полной загрузки канала. Это можно реализовать, например, так. Всю полосу пропускания необходимо поделить на две очереди: очередь для «VIP персон» и для всех остальных с разными весовыми коэффициентами. На языке ip-фильтра выглядеть это будет следующим образом.

ipfw pipe 1 config bw 1000Kbit/s queue 40
ipfw queue 1 config pipe 1 weight 50 queue 40 mask dst-addr 0xffffffff
ipfw queue 2 config pipe 1 weight 10 queue 40 mask dst-addr 0xffffffff
ipfw add queue 1 ip from any to 192.168.0.0/24
ipfw add queue 2 ip from any to 172.16.0.0/12

Трафик подсети 192.168.0.0/24 попадает в первую (VIP) очередь. В этой очереди в единицу времени обрабатывается в 5 раз больше пакетов, чем во второй. В отличии от pipe здесь не происходит резервирование полосы пропускания, поэтому если VIP очередь пустует, вся полоса (в данном примере 1 Мбит/с) делится между всеми остальными пользователями. В большинстве случаев, чтобы добиться требуемого распределения полосы пропускания между пользователями, необходимо использовать комбинации queue и pipe.

Примечание: следует обратить внимание на значение параметра ядра (sysctl) net.inet.ip.fw.one_pass:

0 - пакет обрабатывается следующим правилом firewall'а при выходе из pipe;
1 - пакет не обрабатывается.