GetNet

Ситуация из реальной жизни. Есть клиент, у него какое-то количество коммутаторов, они как-то подключены друг к другу — какими-то портами, зачастую гигабитными. Никакой сети Клоза и трёхуровневой модели. От пользователей поступают заявки: «тормозит».

MikroTik не был бы MikroTik, если бы не имел ограничений — скорее всего, он бы тогда стоил других денег. Используемые чипы имеют определённые аппаратные ограничения, и именно на них построена вся история с распределением разного трафика по разным очередям. Буферы не бесконечные, при переполнении буфера получается дроп. В основном в железе используются простые FIFO-очереди, которые при переполнении начинают дропать пакеты.

На сайте вендора есть таблица коммутаторов, которые умеют всё это великолепие. Ключевые нюансы:

Чёткого алгоритма в стиле «делай раз, два, три, иначе не получится» нет — как обычно в MikroTik. Но за основу можно взять такую последовательность:

Из нюансов: в документации сказана простая, но интересная фраза — при выключении аппаратного QoS желательно перезагрузить коммутатор. То же самое стоит делать и при включении, на всякий случай — не повредит. Здесь есть программная часть (RouterOS) и аппаратная (чип Marvell), который, по сути, программируется через эти команды. Чтобы ничего не произошло, лучше перезагрузиться.

Существуют определённые поля как в заголовке VLAN, так и в IP-пакете, на основе которых можно определять тип трафика.

Раз поля и в заголовке пакета, и в VLAN можно поменять, порты должны различаться по степени доверия.

Для этого в RouterOS есть соответствующие настройки доверия L2 и L3 — то есть доверять ли DSCP-полям и доверять ли PCP-полям:

By default в аппаратном QoS не настроено ничего — полная пустота, даже в 802.1p. Поэтому создаётся несколько трафик-классов, которым сопоставляются DSCP и PCP.

Здесь есть нюанс, на который стоит обратить внимание: дефолтный трафик-класс находится в единице, а трафик-класс с номером один — в нуле.

Каждому пакету назначается соответствие трафик-классу. На интерфейс навешивается тот или иной профиль, в котором указывается соответствие DSCP-меток. Но DSCP-меток гораздо больше — шесть бит, от 0 до 63. Для этого и существуют map — карты, которые описывают, какие DSCP- и PCP-метки соответствуют друг другу и как они распределяются по разным классам. Разумно ориентироваться на стандартные значения, принятые у других вендоров (Cisco и других), — так конфигурация будет ближе к общепринятой.

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

При создании каждого TX manager создаётся 8 очередей. TX manager привязывается к интерфейсу, и автоматом к нему привязываются эти самые 8 очередей. Чем больше TX manager, тем больше очередей — по 8 на каждый.

Дело в том, что у MikroTik используется шареный буфер между всеми интерфейсами — определённый объём (порядка десятков мегабайт в зависимости от модели), в который складываются пакеты. Если портов, скажем, 16, то в момент активной передачи трафика этот объём делится на 16 — и получается размер буфера на интерфейс. Соответственно, часть портов можно объединить в отдельные буферы, а на части портов буфер вообще выключить, если он там не нужен.

Есть дефолтный TX manager, который выкидывает отключенные интерфейсы из общего буфера. Автоматически это пока не реализовано, настраивать придётся руками: на портах, на которых никогда не будет линка, нужно включить TX manager, исключающий их из общего буфера.

В очередях можно настраивать различную логику работы. Понятное дело, той гибкости, что дают деревья очередей или simple queues, здесь не получить — не стоит искать от аппаратного QoS повторения того, что делается на роутере с сотнями PPPoE-клиентов. Количество и очередей, и правил ограничено. Но развесить разные очереди на разный тип трафика и тем самым разрулить скорости — вполне можно. Для каждого трафик-класса (от 0 до 7) на интерфейсе указывается своя скорость.
За распределение трафика по очередям отвечает шедулер:

Есть опции, определяющие, что делать с пакетами внутри очередей. Естественно, дропать — QoS всегда про уничтожение трафика.

Резонный вопрос: неужели в сети всё так хорошо и все пакеты размечены? Ничего подобного — чаще всего половина приложений не ставит ничего. Здесь и работает деление на доверенные и недоверенные интерфейсы.

С помощью switch rules можно назначать QoS-профили на тот или иной тип трафика прямо на коммутаторе: если пакет идёт на такой-то IP-адрес по такому-то протоколу — сразу поставить QoS profile из нужного диапазона. Причём это даёт и второй эффект: коммутатор проставит из профиля DSCP-метку, и дальнейшая передача трафика по сети пойдёт уже с ней. Поле VLAN priority в switch rules больше не используется и остаётся для совместимости со старыми конфигурациями — коммутатор даже предупреждает, что трогать его не надо.

Если же раскраской пакетов для последующей приоритизации на L2 занимается роутер, для этого есть mangle. Первый шаг — очистка лишних полей из заголовков пакетов, приходящих со стороны провайдера: чужие метки лучше почистить, важны свои. Дальше — mark connection на нужные соединения и навешивание на них тех или иных DSCP-меток. Это операция на процессоре, но на роутере ресурсов обычно достаточно, и добавить ещё одно действие для того или иного трафика — не сильно затратно. Тем более что QoS на роутере, скорее всего, и так настраивается. Разумно использовать цепочки — так всё будет гораздо интереснее.