В первой части обзора мы рассмотрели возможности устройства, его настройки и производительность. В этой части мы рассмотрим возможности шейпинга трафика, а также коснемся вопросов безопасности.
Шейпинг трафика
Данное устройство позволяет использовать достаточно сложный механизм шейпинга трафика, поэтому настройки шейпинга могут оказаться слишком сложны для рядовых пользователей. Тем не менее их использование открывает достаточно широкие возможности управления трафиком позволяя избавиться от проблем с распределением полосы пропускания между различными приложениями и рабочими станциями.
Настройка управления трафиком осуществляется с использованием шести классов обслуживания (используется механизм QoS: Quality of Service — качество обслуживания), отличающихся между собой приоритетом. Каждому классу сопоставлена своя очередь пакетов — соответственно, трафик, попадающий в определенную очередь, имеет приоритет класса, с которым эта очередь сопоставлена. Приоритет классов уменьшается в направлении CoS1 -> CoS6. CoS1 используется для передачи служебного трафика, который должен быть передан максимально быстро. Пока есть трафик класса CoS1, никакой трафик с более низким приоритетом не передается. Классы с CoS2 по CoS5 применяются для трафика, требующего гарантированной передачи, распределение полосы пропускания для данных классов происходит в соответствии с алгоритмом Round-Robin, так что всем классам достается какая-то часть полосы пропускания. Класс CoS6 обычно используется для трафика, не критичного к задержкам и потерям (например, скачивание больших файлов из сети, когда потеря пакетов приведет к повторной их передаче, но никак не отразится на передаваемом файле). Если QoS отключен — весь трафик сопоставляется с классом CoS6 (негарантированная доставка), и никаких «усилий» для гарантированной и быстрой передачи критичного к задержкам и потерям трафика устройством не производится.
Распределение полосы пропускания между классами можно изменить (относительно стандартного, которое используется в QoS), используя алгоритмы шейпинга. Данное устройство позволяет использовать следующие алгоритмы: HTB (Hierarchy token bucket), Low Latency Queue Discipline и PRIOWRR (priority based weighted round robin). Перевод некоторых из этих названий на русский язык осуществить практически невозможно без искажения их смысла, а их влияние на поведение трафика рассмотрим на примерах использования в данном устройстве далее по тексту.
Разделение трафика по классам CoS происходит на основании «соглашения о передаче трафика» — TCA (Traffic Conditioning Agreement). TCA используется при попадании пакетов на интерфейс и на выходе с интерфейса устройства. На входе трафик сопоставляется с определенным классом обслуживания CoS, на выходе — трафику, сопоставленному с определенным классом обслуживания, может быть назначен приоритет (поле ToS пакета IPv4 и User Priority VLAN-тэга).
Общая схема работы шейпинга трафика приведена на схеме ниже
Для задания параметров шейпинга трафика в рассматриваемом устройстве используется 4 раздела настроек: Policy Database, Ingress, Egress и Shaper.
В Policy Database задаются политики, позволяющие распределить трафик по соответствующим классам в зависимости от адреса источника/назначения пакетов, протоколов, портов, интерфейсов. Данный раздел также применяется для настройки маршрутизации трафика — при использовании нескольких ATM-соединений можно выбирать соединение, через которое пойдет тот или иной трафик, так что шейпинг трафика — не единственное применение политик.
Разделы настроек Ingress/Egress задают параметры шейпинга трафика на интерфейсах (Ethernet-портах и ATM-соединениях).
Раздел Shaping позволяет выбрать алгоритм шейпинга и задать его параметры.
Раздел настроек Policy Database — база данных политик:
Как было сказано выше, Policy Database также используется для маршрутизации трафика через различные ATM-соединения (данное устройство поддерживает до восьми соединений).
Рассмотрим задаваемые в Policy Database параметры:
- Ingress Interface — интерфейс, через который пакет попадает в устройство
- Destination Interface — интерфейс, который для пакета будет выходным
- DiffServ Code Point — значение параметра записанного в поле TOS (Type of Service) заголовка IP-пакета
Заголовок IPv4 пакета:
Поле ToS IPv4 пакета:
- Source IP/Mask — IP-адрес и маска подсети источника пакета
- Destination IP/Mask — IP-адрес и маска подсети назначения пакета
- Protocol — протокол, к которому применяется данная политика (возможен выбор протокола из выпадающего списка или указание номера протокола)
- Source/Destination port start/end — диапазоны портов источника/назначения пакетов (для протоколов TCP и UDP)
- Source MAC — MAC-адрес источника пакетов
- Local Routing Mark — маркировка пакетов при передаче в пределах устройства (в ОС Linux, которая установлена в рассматриваемом устройстве, данное значение можно использовать при маршрутизации и фильтрации трафика, однако выяснить, как данное значение можно использовать при настройке через WEB-интерфейс, мне не удалось)
При использовании Policy Database для настройки шейпинга трафика, следующие параметры являются входными:
- Destination IP/Mask
- Source IP/Mask
- Source MAC
- Protocol
- Source/Destination port start/end
- Ingress Interface
- DiffServ Code Point
Политики при этом могут назначить пакетам с перечисленными выше входными параметрами исходящий интерфейс (то есть то соединение через которое пойдет этот трафик) — политики маршрутизации трафика и класс CoS — для задания приоритета трафика.
Раздел настроек Ingress:
В разделе Ingress задаются параметры назначения классов обслуживания CoS входящему на определенные интерфейсы трафику, согласно TCA (соглашению о передаче трафика). Здесь выбирается интерфейс, на который поступает трафик, и назначается класс обслуживания, который сопоставляется данному трафику.
По умолчанию весь трафик сопоставляется с классом обслуживания CoS6 — негарантированная доставка. При этом приоритеты, установленные в поле ToS IP-заголовка и User Priority тэга VLAN, не учитываются — весь трафик без разбора ожидает равная участь.
Выбор опции «Layer 2» в верхней части раздела позволяет производить сортировку трафика по классам обслуживания в зависимости от значения полей приоритета в тэге VLAN (второй уровень модели OSI).
Здесь выбирается, какой класс обслуживания сопоставляется с трафиком, имеющим определенный приоритет User Priority в тэге VLAN. Использование соглашения о передаче трафика (TCA) с использованием второго уровня модели OSI (Layer 2) возможно только на интерфейсе ATM-подключения, так как в данной версии прошивки VLAN'ы поддерживаются только на WAN-интерфейсе.
Выбор опции «Layer 3» в верхней части раздела позволяет производить сортировку трафика по классам обслуживания в зависимости от значения полей ToS IP-пакетов
Здесь можно выбрать любой интерфейс устройства. Также есть возможность задать класс обслуживания CoS не-IP-трафику.
Выбор пункта «Static» позволяет статически задать класс обслуживания CoS всему трафику, приходящему на определенный интерфейс.
Раздел настроек Egress:
На выходе из устройства, можно переназначить значения полей приоритета тэга VLAN и ToS заголовка IP-пакета в зависимости от класса обслуживания. По умолчанию никакие поля приоритета трафика не изменяются.
Выбор пункта «Layer 2» (второй уровень модели OSI) в настройках позволяет изменить значение поля User Priority тэга VLAN трафика на выходе из устройства
Изменение тэга VLAN возможно только на интерфейсе ATM-соединения, так как в данной версии прошивки поддержка VLAN-тэгов осуществляется только на WAN-интерфейсе.
Выбор пункта «Layer 3» (третий уровень модели OSI) в настройках позволяет изменить значение поля ToS IP-пакетов, исходящих с определенных интерфейсов устройства.
Раздел настроек Shaper:
В этом разделе задаются настройки распределения трафика между классами обслуживания CoS. По умолчанию трафик распределяется по классам обслуживания в соответствии правилами QoS, которые написаны в начале этой статьи. Настройки данного раздела позволяют изменить это распределение. При этом на выбор предлагается 3 алгоритма шейпинга трафика:
- HTB Queue Discipline
- Low Latency Queue Discipline
- PRIOWRR
Данные алгоритмы уже упоминались по ходу статьи, здесь рассмотрим их более подробно.
HTB Queue Discipline — Hierarchy Token Bucket:
Пользователи ОС Linux, настраивавшие шейпинг трафика, возможно, уже сталкивались с данным алгоритмом и знают, что его настройки имеют несколько больше параметров, чем представлено здесь. Мы рассмотрим использование данного алгоритма на примере данного устройства.
При использовании данного алгоритма мы задаем ширину полосы пропускания для каждого класса обслуживания CoS (c CoS1 по CoS6). При этом можно добиться, чтобы ширина полосы пропускания CoS1 была ниже ширины полосы пропускания CoS6.
Low Latency Queue Discipline:
Данный алгоритм шейпинга принципиально не отличается от представленного выше HTB Queue Discipline, однако класс CoS1 всегда имеет максимальный приоритет (вне зависимости от значения, заданного в параметрах) и может отбирать необходимую часть полосы пропускания у остальных классов.
PRIOWRR — Priority Weighted Round-Robin
Данный алгоритм шейпинга разделяет ширину полосы пропускания по весам, указанным в процентах. Веса задаются для классов с CoS2 по CoS6. Класс CoS1 имеет максимальный приоритет и может занять всю ширину полосы пропускания, вне зависимости от наличия трафика остальных классов.
В поле MAX Rate задается максимальная скорость трафика, исходящего с заданного интерфейса. Данный параметр применим только к алгоритмам HTB Queue Discipline и Low Latency Queue Discipline.
Стоит отметить, что алгоритмы шейпинга могут применяться только к исходящему с интерфейса трафику.
Замечу, что в приведенной в начале статьи схеме показано, что шейпинг применяется после менеджера очередей уже практически перед выходом пакета из устройства, а в настройках шейпинга фигурируют параметры классов этих очередей, что меня несколько смутило. Однако нас больше всего интересует результат, на него и сделаем основной упор.
Тестирование шейпинга трафика
Перед началом тестирования скажу, что при таком наборе настроек невозможно протестировать все варианты работы шейпинга трафика, поэтому проведем лишь основные тесты, чтобы получить базовые представления о работе шейпера.
Тест 1: посмотрим на работу QoS — в документации на прошивку устройства сказано, что класс CoS1 имеет максимальный приоритет и никакие другие данные (трафик с более низким приоритетом CoS2-CoS6) не передаются, пока в очереди есть пакеты класса CoS1. Проверим это на практике — для этого используем раздел интерфейса настройки Ingress (трафик разделяется на классы обслуживания в зависимости от Ethernet-порта, к которому подключены компьютеры, генерирующие трафик). В данном тесте мы будем рассматривать исходящий (LAN->WAN) трафик.
Примечание: тестирование производилось при включенной трансляции сетевых адресов (NAT).
Устройство ведет статистку трафика по классам обслуживания, что помогает определить, не допущена ли ошибка в настройках.
Путем долгих и мучительных манипуляций с различными комбинациями настроек удалось выяснить, что использование стандартного QoS возможно лишь в случае соблюдения двух условий:
- Мы должны разделить трафик по классам обслуживания (в данном тесте для этого использовался раздел настроек Ingress WEB-интерфейса настройки).
- Необходимо выбрать в разделе Shaping любой алгоритм шейпинга трафика (при этом придется настроить необходимые параметры шейпинга). Примечание: для работы QoS необходимо только включить шейпинг (введенные настройки при этом не учитываются) — все настройки шейпинга применяются только, если мы включим на интерфейсе, с которого трафик покидает устройство Egress TCA (используя раздел настроек Egress) — так сказано в документации (цитата «Note — Egress TCA is required if shaper is configured for that interface.»). Если в разделе Shaper ни один из видов шейпинга не выбран — механизм QoS работать не будет (судя по тестам).
Из графика видно, что поток трафика с классом обслуживания CoS1 занимает значительно большую ширину полосы пропускания, нежели поток с классом CoS2, но не совсем ясно почему 2 потока используют лишь малую часть ширины полосы пропускания — 120 кбит/с в то время как ширина обратного канала ADSL позволяет получить скорости порядка 850–900 кбит/с.
При поэтапном запуске потоков трафика наблюдаем,
что трафик с более низким приоритетом (CoS2) занимает большую часть полосы пропускания до тех пор, пока не запущен поток трафика с более высоким приоритетом (CoS1). Даже если мы запускаем всего лишь 1 поток трафика, максимальная скорость составляет порядка 120 кбит/с.
Посмотрим теперь, какова реакция устройства, если мы изменим классы обслуживания с CoS1 и CoS2 на CoS3 и CoS4 — в документации сказано, что трафик класса CoS1 занимает большую часть ширины полосы пропускания, в то время как трафик классов CoS2-CoS5 разделяет ширину полосы пропускания в соответствии с алгоритмом Weightet Round-Robin — то есть распределение скоростей может измениться.
Но, как видно из графика, принципиальных изменений не произошло — то есть устройству, по большому счету, все равно, какой класс обслуживания назначен потокам трафика (CoS1 и CoS2 или же CoS3 и CoS4).
В документации возможностей шейпинга трафика сообщается, что:
- сами алгоритмы шейпинга применяются только к исходящему с определенного интерфейса трафику
- для работы шейпинга необходимо включить Egress TCA (раздел настроек Egress) для интерфейса, на котором используется шейпинг трафика
Для тестирования QoS (проведенные выше тесты) Egress TCA был отключен. Для проведения дальнейших тестов Egress TCA будет включен на интерфейсе шейпинга.
Так как мы пока рассматриваем исходящий (LAN->WAN) трафик, Egress TCA включаем на интерфейсе ATM-подключения.
В настройках шейпера выберем алгоритм HTB Queue Discipline, значение параметра Max Rate зададим в 700 кбит/с, а классам обслуживания CoS3 и CoS4 зададим ширину канала в 100 и 200 кбит/с соответственно (мы специально задаем классу с более высоким приоритетом ширину канала меньше, чем классу с более низким приоритетом). Запустим два потока трафика с классами обслуживания CoS3 и CoS4. Суммарная, заданная для классов обслуживания, скорость трафика не превышает значения Max Rate, так что мы будем считать, что данный параметр не влияет на распределение ширины полосы пропускания трафика.
Как видим, использование алгоритмов шейпинга (напомню, что для их использования необходимо включить Egress TCA в разделе настроек Egress) показывает достаточно хорошие результаты — скорости трафика достаточно точно соответствуют заданным параметрам.
Сделаем так, чтобы оба потока имели одинаковую ширину полосы пропускания — 200 кбит/с на поток, остальные настройки оставим пока без изменений.
Видим, что скорости трафика у обоих потоков примерно одинаковые.
Теперь несколько изменим параметры шейпинга трафика: зададим ширину канала для CoS3 и CoS4 в 100 и 300 кбит/с соответственно, значение параметра Max Rate составило 200 кбит/с — таким образом, мы посмотрим, как распределяется скорость между потоками трафика, когда мы с помощью параметра Max Rate ограничиваем общую ширину канала ниже уровня, установленного для классов обслуживания.
Уменьшение параметра Max Rate ниже уровня суммарной ширины полосы пропускания для классов обслуживания CoS3 и CoS4 (трафик этих классов мы используем в данном тесте) никак не отразилось на скорости трафика — создалось впечатление, что значение параметра Max Rate не оказывает никакого влияния на ширину канала, но включить шейпинг трафика без задания данного параметра не получится.
Таким образом, использование алгоритма шейпинга HTB Queue Discipline позволяет нам задать ту ширину канала, которую мы выделяем для каждого класса обслуживания. Какую роль при этом играет параметр Max Rate не совсем понятно.
Алгоритм шейпинга Low Latency Queue Discipline, судя по документации, аналогичен рассмотренному выше. Разница в том, что класс обслуживания CoS1 всегда имеет максимальный приоритет и может перекрывать ширину канала всем остальным классам обслуживания вне зависимости от заданных параметров.
Как видим, данный график практически полностью аналогичен предыдущему, однако добиться работы механизма Low Latency Queue Discipline после выбора на странице шейпера, мне удалось только после перезагрузке устройства — в противном случае результаты теста сильно отличаются от представленных выше. Напомню, что необходимо выполнить сохранение параметров перед перезагрузкой, иначе все настройки будут потеряны.
PRIORWRR-шейпинг
Настройки шейпинга PRIORWRR позволяют задать ширину полосы пропускания в % для каждого класса обслуживания. Минимальная ширина полосы пропускания, которую устройство позволяет задавать, — 10%. Для трафика класса CoS1 настройки не задаются — он по умолчанию имеет максимальный приоритет.
Зададим настройки шейпинга следующим образом:
- CoS2: 10%
- CoS3: 10%
- CoS4: 60%
- CoS5: 10%
- CoS6: 10%
При этом запустим два потока трафика, подчиняющихся классам обслуживания CoS3 и CoS4. В итоге должны получить, что класс CoS3 должен занимать меньшую ширину полосы пропускания, нежели класс CoS4 (разница в скорости должна составлять примерно 6 раз).
Как видим из графика — поток трафика с классом обслуживания CoS4 занимает значительно большую ширину полосы пропускания, нежели поток с классом CoS3. Скорости различаются примерно в 6 (5.88) раз, как и было задано в параметрах.
В документации сказано, что поток с классом обслуживания CoS1 имеет максимальный приоритет — проверим это на практике.
Видно, что трафик с классом обслуживания CoS1 имеет максимальный приоритет вне зависимости от заданных параметров.
Посмотрим, как поведет себя шейпинг трафика при поэтапном запуске потоков трафика.
Зададим настройки шейпинга следующим образом:
- CoS2: 10%
- CoS3: 10%
- CoS4: 60%
- CoS5: 10%
- CoS6: 10%
Видно, что устройство быстро и адекватно реагирует на появление трафика, которому установлена более широкая полоса пропускания (в данном случае CoS4).
Можно сказать, что шейпинг трафика работает вполне адекватно, остались только некоторые недопонимания, как работает базовый QoS (а точнее, почему при его работе ширина канала так сильно «зарезается»).
Напоследок стоит взглянуть, так ли хорошо обстоят дела с шейпингом входящего (WAN -> LAN) трафика, а также посмотреть, как работают политики, позволяющие назначить класс обслуживания потокам трафика.
Практика показала, что назначение класса обслуживания с помощью политик работает только в том случае, если в разделе Ingress мы выберем пункт Untrusted — то есть весь трафик, попадающий на интерфейс, сопоставляется с классом обслуживания CoS6. Если мы выберем значение Static, и в нем зададим класс обслуживания для всего трафика, приходящего на интерфейс, использование политик не позволит изменить класс обслуживания — весь трафик будет сопоставлен с заданным в Ingress классом обслуживания. Увидеть, с каким классом обслуживания сопоставлен трафик, можно, используя статистику, которую собирает устройство (раздел Status, пункт QOS-TCA NTCA Status). Проведя несколько тестов, было обнаружено, что устройство категорически отказывается производить шейпинг WAN->LAN трафика, хотя, и сопоставляет ему классы обслуживания.
Таким образом, получается, что мы можем использовать шейпинг исходящего (LAN->WAN) трафика, назначив ему классы обслуживания, и не можем осуществлять шейпинг входящего (WAN-> LAN) трафика, хотя также можем назначить ему классы обслуживания (эту возможность можно использовать для изменения значения поля TOS IP-пакетов).
Безопасность
Отчеты о работе Nessus'а приведены ниже:
Nessus не находит ни одной критической уязвимости, однако крайне не рекомендует использовать протокол telnet для управления устройством, так как данный протокол передает приватную информацию (в том числе пароль) в открытом виде через незащищенную сеть.
SSH-доступ к устройству осуществляется только с использованием второй версии протокола.
Выводы:
Как видим, результаты работы над возможностями шейпинга трафика устройства получились очень неоднозначными. Несколько раз замечал, что некоторые параметры вступали в силу только после перезагрузки устройства, хотя должны — сразу по нажатию кнопки «Apply». Не очень понятно, почему так сильно падает скорость при использовании QoS (без использования определенного алгоритма шейпинга) — скорость трафика почти в 8 раз ниже скорости канала. Добиться хоть какой-то работы QoS можно только при выборе алгоритма шейпинга, который в самом QoS никак не участвует.
Настройки устройства позволяют сделать все, чтобы настроить шейпинг входящего (WAN->LAN) трафика, тем не менее, мне не удалось добиться шейпинга трафика в направлении WAN->LAN. Что касается шейпинга LAN->WAN трафика, то можно сказать, что он работает без нареканий при использовании одного из трех алгоритмов (HTB Queue Discipline, Low Latency Queue Discipline или PRIOWRR).
Интерфейс настройки шейпинга очень сложен для рядового пользователя. Некоторую помощь может оказать документация на прошивку устройства, которая, как ни странно, на диске с устройством не поставляется. Скачать ее можно здесь (PDF, EN, 4.2 Мб). В данной документации более подробно описаны все настройки устройства (в том числе и не относящиеся к шейпингу трафика).
Возможность просмотра статистики по шейпингу трафика в интерфейсе устройства может оказать существенную помощь при настройке.
Плюсы:
- Достаточно точный шейпинг исходящего (LAN->WAN) трафика
- Широкий спектр настроек шейпинга
- Возможность использования двух различных алгоритмов шейпинга (на самом деле, их 3, но 2 из них практически аналогичны)
- Высокая безопасность устройства
Минусы:
- Интерфейс настройки шейпинга очень сложен для рядового пользователя
- Не удалось настроить шейпинг входящего (WAN->LAN) трафика
- При использовании QoS скорость существенно снижается
DSLAM предоставлен компанией ZyXEL Communications Corporation
