Mikrotik QOS в распределенных системах или умные шейперы. Часть 3.

Суровая практика

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

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

Первое с чего мы начинаем — это каналы в интернет.

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

Сейчас объясню почему.

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

Во первых, какой бы крутой у вас не стоял балансировщик нагрузки между каналами — всегда будет определенный дисбаланс. Разная нагрузка на каналы хотя бы в 1% нарушит стабильную работу шейпера и минимум 1 абонент на каждом канале будет недополучать тарифной скорости.

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

В третьих, при падении одного из каналов общая емкость изменится, и значение max-limit в очереди станет неактуальным. В результате этого шейпер будет прозрачно пропускать трафик, соблюдая лишь pcq-rate. Кто-то из абонентов будет получать полную скорость, а кто-то вообще ничего.

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

А цена данного функционала — умножение нагрузки процессора от шейпера и числа его правил на количество обслуживаемых каналов.

Второе на что нужно обратить внимание — это гарантированная скорость каналов.

Если скорость на канале плавает в пределах более 20% это очень плохо. Выходов из данной ситуации несколько:

1. Использовать только гарантированные каналы. Это почти миф. Такие каналы предоставляют в основном юр.лицам со всеми вытекающими. Во вторых, если канал приходит в роутер по радио — толку от этого будет мало.
2. Использование не всей емкости канала. Достигается путем длительных тестов и вычисления его средней скорости. Думаю, что вас не сильно порадует фиксированное использование только половины потенциала канала. Зато стабильность значительно возрастет.
3. Использование коммерческих (QOSEvxController) или самописных скриптов для актуализации значения max-limit на канале. Данное решение чуть лучше второго варианта и позволяет получать с канала чуть больше его средней скорости.

Цена вопроса — Договор на юр.лицо или внешние скрипты и некоторые ресурсы процессора.

Третье и последнее по каналам — Тип подключения аплинков. 

Да, я имею ввиду подключение по радио, со всеми вытекающими. При встречном трафике производительность данного канала снижается, и скорость значительно плывет. Решение тоже, что и выше, плюс добавление в конструкцию различных приоритетов для Download/Upload трафика. Данный функционал не добавляет существенной нагрузки на ЦП.

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

Третий вопрос для обсуждения — это: «Нужно ли выделять какому либо типу трафика более высокий приоритет?»

Безусловно, стоит хорошо задуматься о внедрении в конструкцию данного функционала. Разделение потока пакетов хотя бы на два приоритета приведет к увеличению нагрузки на процессор вдвое, а при использовании регулярных выражений хотя бы в одном правиле mangle в десятки раз.

Поэтому использовать данную фишку стоит только владельцам роутеров серии CCR, CHR, X86 с достаточным количеством свободных мегагерц на ядрах процессоров.

Однако полезность данной функции тоже очень положительно влияет на работу сети. 

Во первых, многое зависит от того, кому вы предоставляете интернет.

Есть абоненты, которые с компьютером строго на «вы» и это самая болезненная для технической поддержки группа. Они собирают все тизеры на страницах интернета, соответственно на их компьютере просто зоопарк из вирусов, троянов и загрузчиков, да еще центр обновления у них сам качает, что захочет и когда захочет. А после школы возвращается их ребенок, запускает танки, ловит лаги и начинаются звонки в техническую поддержку. Вы вежливо объясняете, что у них проблемы с компьютером и чаще всего получаете ответ что им «все починили и настроили две недели назад» и что у них проблем быть не может. Ведь папины веселые картинки на весь экран, которые просили положить денег на какой-то номер телефона, удалил мамин знакомый программист с работы.

И чаще всего до таких абонентов трудно достучатся и найти нужные слова для убеждения. Увы, но это так!

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

Абоненты, которые с компьютером на «ты» обычно не звонят по пустякам в техподдержку, сначала проверяют свою машину, потом скорость, а потом уже набирают вас. И боже упаси вас, сказать им, что у них с машиной или сетевой картой, что-то не так, они вам горло перегрызут. Хотя в некоторых, из таких случаев провайдер действительно прав, т.к. человеческий фактор никто не отменял, мы все ошибаемся, забываем про роутер, про ноутбук который качает торренты на кухне и т.д.

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

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

Наиболее остро вопрос стоит у тех субпровайдеров, кто раздает интернет по радио на распространенном оборудовании.

Для примера возьмем базовую станцию Ubiquiti Rocket M5 c хорошей панельной антенной, установленной по всем правилам и работающей на свободной частоте без помех.

К данной базе подключено максимальное число абонентов (30 устройств) и для чистоты теории они все находятся на одинаковом расстоянии и с одинаковыми сигналами.

И вот мы создали тепличные условия для красивой коробочки внутри которой китайское г…

Не скажу что у других производителей все супер внутри корпуса, но данный производитель очень тщательно скрывает очень важный параметр — пакетную производительность данного устройства. 

По своему опыту скажу, что для данного устройства она лежит в пределах 16000-20000. Для Rocket M5 Titatium в районе 20000-25000.

И что это нам дает? При закачке торрентов скоростью 1 мегабит в секунду (не самые мелкие пакеты, если что) генерируется порядка 800-1100 пакетов в секунду.

Это говорит нам, что при самом плохом положении вещей максимальная производительность базы равна 15 мегабитам в секунду. А не 300 мегабит как пишут многие продаваны и не 150 как пишут более честные. А агрегация в суперфрейм тут пустой звук.

Но это самое плохое развитие событий, не все же абоненты качают только торренты, кто-то серфит, кто-то в скайпе сидит, кто-то фильм смотрит и т.д.

Количество пакетов снижается, но скорость растет. Так вот, средняя пропускная способность данной базовой станции в реальных условиях составляет порядка 35-45 мегабит. Ее максимум 70-80 мегабит на крупных пакетах при TCP трафике.

К чему я собственно веду: при 30 абонентах с тарифами в 5 мегабит, данная база не справится в глобальный прайм-тайм, который случается не так уж редко. (Выход ожидаемых фильмов, трансляции спортивных событий и пр.

Даже 20*5 это уже сто мегабит, понятное дело, что на базе есть свои очереди, таймслоты при использовании TDMA и прочее, база как бы обязана раздавать трафик честно и поровну. Но в реальных условиях, когда она явно перегружена по пакетам или радио, при наличии помех, разности расстояний и сигналов, равномерное деление по TDMA просто невозможно.

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

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

Легко сказать, но очень дорого сделать. Ведь каждый сегмент (VLAN). 

Будет умножать нагрузку от шейпера на количество введенных в шейпер сегментов.

Данный функционал, несомненно, нужен беспроводным субпровайдерам, но он приводит к огромному количеству правил и гигантской трате системных ресурсов.

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

Первый роутер следит за скоростями каналов в интернет, приоритезацией и нарезкой скоростей. Далее трафик проходит во второй роутер, на котором шейпер следит за нагрузкой на сегменты сети. А так же за межабонентским трафиком, о котором я и расскажу.

Последний вопрос: «Зачем нужен межабонентский трафик и как больно грабли ударят по лбу?»

Межабонентский трафик нужен в первую очередь для снижения нагрузки на интернет каналы.

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

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

Так же возможна реализация внутренних серверов и сервисов самим провайдером.

Ну, тут я уже предвижу: «Да кому нужны ваши внутренние серваки и ретрекеры? Тут у каждого второго оптика»

У меня есть клиент, официальный провайдер. У него три канала по 4 мегабита от спутниковых модемов и около 400 абонентов. В радиусе 700км нет ни оптики, ни кабеля, ни файфая, ни жопорезов с 3-4g. В общем, ничего нет. Пинг 700мс. А вы тут как сырки в масле, с оптикой и 21 веком. Еще будут вопросы, зачем субпровайдерам кеширующие прокси, ретрекеры и прочие примочки?

Так что межабонентскому трафику быть!

Как бы это хорошо не звучало, это единственная вещь, которую ROS шестой версии не в силах победить. Связано это с тем, что при замене global-in, global-out и global-total которые были в пятой версии, на global который теперь есть в шестой, пропала возможность дважды помечать трафик и дважды прогонять его через HTB.

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

Кто-то скажет или спросит: «В пятой же версии все получится?» Да, конечно. Проверял, работает на ура! Только вот пятая версия имеет свои минусы и уже не подходит под те задачи, которые требуются от этого роутера.

Как же быть? Есть некоторые варианты решения подобной задачи, трафик будет зарегистрирован лишь в одном направлении и с более низким приоритетом, интернет трафик будет иметь более высокий приоритет. Кроме этого данный поток полезно лимитировать. Схема довольно сложная и создается под отдельно взятые конфигурации. Если кто-то из специалистов сейчас прочитал это и понял, о чем я говорю — свяжитесь со мной, возможно, вместе мы придумаем что-то более продвинутое.

Кроме всего этого межабонентский трафик нельзя маркировать на одном роутере с контролем нагрузки на интернет аплинки. Даже если вы решили рискнуть производительностью роутера и сделать комбаин «все в одном» (Контроль нагрузки на каналы+нарезка скорости по тарифам+приоритеты+контроль внутренних сегментов+маркировка межабонентского трафика) то вы через некоторое время заметите, что в корневых очередях каналов в интернет регистрируется нагрузка, которой на самом деле не существует. Это межабонентский трафик маркируется, попадает в очередь, передается в корневую очередь сегмента, а оттуда попадает в очередь канала.

Изменение родителя у очереди канала или сегмента не даст никакого положительного результата. По факту получится, что канал свободен, но шейпер будет думать, что нагрузка на нем есть. Решение данной проблемы — распределенная система.

Ну, вот как бы и решилось что к чему, естественно если есть биллинг, то он должен поддерживать работу с адрес-листами для сообщения микротику какому ip адресу и сколько скорости выдать. Тоже самое относится к скрипту балансировки, он должен сообщать своими списками какой ip адрес, к какому каналу привязан в данный момент времени. Кроме этого если вы создаете распределенную систему на двух роутерах, вам потребуется синхронизация адрес листов между роутерами, реализовать ее можно написав скрипт, либо внешний обработчик на api. Так же в скором времени такой скрипт можно будет приобрести (EvxListSync).
 

Практическая и заключительная часть:

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

Предположим, что у нас есть два канала в интернет и балансировщик, который раскидывает абонентов по каналам и формирует динамически нужные адрес листы ISP1 и ISP2.

Для каждого канала будет создан индивидуальный шейпер.

В примере будут рассмотрены четыре тарифных плана, два для физ.лиц и два для юр.лиц.

Если есть биллинг — он должен добавлять ip адреса пользователей в соответствующие списки для привязки абонента к нужному тарифному плану. Если биллинга нет — заполнять данные адрес листы потребуется вручную.

Кроме всего этого мы разделим трафик по типу на два приоритета.

Разметка

Маркируем весь входящий трафик к адресам из списка «SHAPER_TARGET» назначая пакетам метку «CLASS-B-DL»

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-B-DL dst-address-list=SHAPER_TARGET new-packet-mark=CLASS-B-DL;

Далее отлавливаем пакеты с меткой «CLASS-B-DL» и переразмечаем их, назначая метку более приоритетного класса. В более выскокий приоритет попадут: ICMP, DNS, SSH, TELNET, RDP и пакеты у которых в качестве адреса источника указан любой адрес из списка CLASS-A-SITES.

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-ICMP-DL new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=icmp;

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-DNS_TCP-DL dst-port=53 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-DNS_UDP-DL dst-port=53 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=udp;

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-SSH-DL dst-port=22 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-TELNET-DL dst-port=23 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-RDP-DL dst-port=3389 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;

/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-SITES-DL new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL src-address-list=CLASS-A-SITES;

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

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-B-UL new-packet-mark=CLASS-B-UL src-address-list=SHAPER_TARGET;

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-ICMP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=icmp;

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-DNS_TCP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=53;

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-DNS_UDP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=udp src-port=53;

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-SSH-UP new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=22;

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-TELNET-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=23;

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-RDP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=3389;

/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-SITES-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL src-address-list=CLASS-A-SITES;

После этих действий мы получаем четыре потока промаркированных пакетов:

CLASS-A-DL
CLASS-B-DL
CLASS-A-UL
CLASS-B-UL

Ищем в данных потоках пакеты принадлежащие абонентам, которые в данный момент работают на первом канале и переразмечаем их:

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-A-DL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-A-DL packet-mark=CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-B-DL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-B-DL packet-mark=CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-A-UL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-A-UL packet-mark=CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-B-UL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-B-UL packet-mark=CLASS-B-UL;

После переразметки получим еще четыре дополнительных потока:

ISP1-CLASS-A-DL
ISP1-CLASS-B-DL
ISP1-CLASS-A-UL
ISP1-CLASS-B-UL

Теперь нужно разобрать эти четыре потока на тарифные планы:

Адрес лист «1024-1024-8» в формате «Входящая скорость-Исходящая скорость-Приоритет». Приоритет равен 8 если физ.лицо и 7 если юр.лицо. Так удобнее управлять листами из биллинга.

Выделяем четыре потока для тарифного плана «1024-1024-8» два под загрузку, два под отдачу:

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-A_DL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-B_DL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-A_UL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-B_UL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;

Повторяем действия для трех оставшихся тарифных планов:

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-A_DL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-B_DL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-A_UL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-B_UL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-A_DL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-B_DL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-A_UL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-B_UL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-A_DL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-B_DL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-A_UL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-B_UL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;

После данных действий мы получили 16 потоков промаркированных пакетов.

Потоки канала:

ISP1-CLASS-A-DL
ISP1-CLASS-B-DL
ISP1-CLASS-A-UL
ISP1-CLASS-B-UL

Потеряли актуальность т.к. все пакеты с данными маркировками были переразмечены.

Но общие потоки:

ISP1-CLASS-A-DL
ISP1-CLASS-B-DL
ISP1-CLASS-A-UL
ISP1-CLASS-B-UL

еще содержат пакеты других каналов, в нашем случае: канала ISP2.

Далее нужно произвести переразметку для второго канала, аналогично первому:

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-A-DL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-A-DL packet-mark=CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-B-DL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-B-DL packet-mark=CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-A-UL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-A-UL packet-mark=CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-B-UL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-B-UL packet-mark=CLASS-B-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-A_DL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-B_DL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-A_UL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-B_UL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-A_DL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-B_DL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-A_UL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-B_UL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-A_DL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-B_DL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-A_UL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-B_UL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-A_DL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-B_DL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-A_UL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;

/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-B_UL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;

Получаем еще 16 потоков для второго канала.

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

На этом маркировка закончена.

Профили

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

/queue type add kind=pcq name=DL-1024-1024-8 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;

/queue type add kind=pcq name=UL-1024-1024-8 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;

/queue type add kind=pcq name=DL-2048-2048-8 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;

/queue type add kind=pcq name=UL-2048-2048-8 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;

/queue type add kind=pcq name=DL-1024-1024-7 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;

/queue type add kind=pcq name=UL-1024-1024-7 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;

/queue type add kind=pcq name=DL-2048-2048-7 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;

/queue type add kind=pcq name=UL-2048-2048-7 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;

После того как профили созданы, можно приступать к созданию дерева.

Дерево

Ранее я упоминал о проблемах, которые возникнут при получении интернет каналов по радио, так же вполне вероятно, что провайдер вам выдаст не симметричный канал, либо вы будете использовать adsl или 3-4g.

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

Родительская очередь для первого канала:

/queue tree add name=ISP1-Duplex parent=global queue=default;

Подочереди для симплекса:

/queue tree add name=DL-ISP1 parent=ISP1-Duplex queue=default;
/queue tree add name=UL-ISP1 parent=ISP1-Duplex queue=default;

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

Тарифный план 1024-1024 для физ.лиц на два приоритета+приоритет входящего трафика:

/queue tree add name=DL-ISP1_1024-1024-8_CLASS-A packet-mark=ISP1_1024-1024-8_CLASS-A_DL parent=DL-ISP1 priority=5 queue=DL-1024-1024-8;

/queue tree add name=DL-ISP1_1024-1024-8_CLASS-B packet-mark=ISP1_1024-1024-8_CLASS-B_DL parent=DL-ISP1 priority=6 queue=DL-1024-1024-8;

/queue tree add name=UL-ISP1_1024-1024-8_CLASS-A packet-mark=ISP1_1024-1024-8_CLASS-A_UL parent=UL-ISP1 priority=7 queue=UL-1024-1024-8;

/queue tree add name=UL-ISP1_1024-1024-8_CLASS-B packet-mark=ISP1_1024-1024-8_CLASS-B_UL parent=UL-ISP1 priority=8 queue=UL-1024-1024-8;

Остальные три тарифных плана:

С первым каналом закончили, добавляем очереди второго канала по аналогии с первым:

/queue tree add name=ISP2-Duplex parent=global queue=default;
/queue tree add name=DL-ISP2 parent=ISP2-Duplex queue=default;
/queue tree add name=UL-ISP2 parent=ISP2-Duplex queue=default;

/queue tree add name=DL-ISP2_1024-1024-8_CLASS-A packet-mark=ISP2_1024-1024-8_CLASS-A_DL parent=DL-ISP2 priority=5 queue=DL-1024-1024-8;

/queue tree add name=DL-ISP2_1024-1024-8_CLASS-B packet-mark=ISP2_1024-1024-8_CLASS-B_DL parent=DL-ISP2 priority=6 queue=DL-1024-1024-8;

/queue tree add name=UL-ISP2_1024-1024-8_CLASS-A packet-mark=ISP2_1024-1024-8_CLASS-A_UL parent=UL-ISP2 priority=7 queue=UL-1024-1024-8;

/queue tree add name=UL-ISP2_1024-1024-8_CLASS-B packet-mark=ISP2_1024-1024-8_CLASS-B_UL parent=UL-ISP2 priority=8 queue=UL-1024-1024-8;

/queue tree add name=DL-ISP2_2048-2048-8_CLASS-A packet-mark=ISP2_2048-2048-8_CLASS-A_DL parent=DL-ISP2 priority=5 queue=DL-2048-2048-8;

/queue tree add name=DL-ISP2_2048-2048-8_CLASS-B packet-mark=ISP2_2048-2048-8_CLASS-B_DL parent=DL-ISP2 priority=6 queue=DL-2048-2048-8;

/queue tree add name=UL-ISP2_2048-2048-8_CLASS-A packet-mark=ISP2_2048-2048-8_CLASS-A_UL parent=UL-ISP2 priority=7 queue=UL-2048-2048-8;

/queue tree add name=UL-ISP2_2048-2048-8_CLASS-B packet-mark=ISP2_2048-2048-8_CLASS-B_UL parent=UL-ISP2 priority=8 queue=UL-2048-2048-8;

/queue tree add name=DL-ISP2_1024-1024-7_CLASS-A packet-mark=ISP2_1024-1024-7_CLASS-A_DL parent=DL-ISP2 priority=3 queue=DL-1024-1024-7;

/queue tree add name=DL-ISP2_1024-1024-7_CLASS-B packet-mark=ISP2_1024-1024-7_CLASS-B_DL parent=DL-ISP2 priority=4 queue=DL-1024-1024-7;

/queue tree add name=UL-ISP2_1024-1024-7_CLASS-A packet-mark=ISP2_1024-1024-7_CLASS-A_UL parent=UL-ISP2 priority=5 queue=UL-1024-1024-7;

/queue tree add name=UL-ISP2_1024-1024-7_CLASS-B packet-mark=ISP2_1024-1024-7_CLASS-B_UL parent=UL-ISP2 priority=6 queue=UL-1024-1024-7;

/queue tree add name=DL-ISP2_2048-2048-7_CLASS-A packet-mark=ISP2_2048-2048-7_CLASS-A_DL parent=DL-ISP2 priority=3 queue=DL-2048-2048-7;

/queue tree add name=DL-ISP2_2048-2048-7_CLASS-B packet-mark=ISP2_2048-2048-7_CLASS-B_DL parent=DL-ISP2 priority=4 queue=DL-2048-2048-7;

/queue tree add name=UL-ISP2_2048-2048-7_CLASS-A packet-mark=ISP2_2048-2048-7_CLASS-A_UL parent=UL-ISP2 priority=5 queue=UL-2048-2048-7;

/queue tree add name=UL-ISP2_2048-2048-7_CLASS-B packet-mark=ISP2_2048-2048-7_CLASS-B_UL parent=UL-ISP2 priority=6 queue=UL-2048-2048-7;

После этого нужно внести в адрес лист «SHAPER_TARGET» диапазоны подсетей с абонентами, проследить, что биллинг добавляет адреса абонентов в нужные списки, проверить вносит ли балансировщик адреса абонентов в списки каналов.

Так же требуется задать значения max-limit в корневых очередях, эти значения должны быть на 5-20% ниже реальной скорости, которую вам выдает провайдер.

Итого получилось:

52 правила в Mangle, 8 профилей, 38 очередей

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

16 правил в Mangle для определения типов трафика.
5 каналов * 4 правила для разделения = 20 правил в Mangle
5 каналов * (4 правила на тариф* 12 тарифов)=240 правил в Mangle

Итого правил в mangle = 276 (260 зависят от числа тарифов и каналов)

Профили 

12*2=24

Дерево

5 каналов на 3 корневые очереди =15 очередей
5 каналов * (4 очереди на тариф * 12 тарифов) = 240 очередей

Итого: 255 очередей

И данные цифры вполне нормально уживутся на CCR, CHR, X86 если не баловаться с регулярными выражениями. Если хочется добавить еще одну ступень для определения типа трафика — умножайте число очередей и правил на два.

Для тех, кто вопреки убеждениям хочет прикрутить к данной схеме еще и контроль внутренних сегментов сети на этом же роутере — число правил и очередей умножайте на число сегментов и к полученному значению прибавляйте количество сегментов умноженное на два.
В данном примере, при десяти сегментах количество правил в mangle станет около 2610, а количество очередей примерно 2580.

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

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

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

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

Другие части:

• Mikrotik QOS в распределенных системах или умные шейперы. Часть 1.
• Mikrotik QOS в распределенных системах или умные шейперы. Часть 2.
• Mikrotik QOS в распределенных системах или умные шейперы. Часть 3.
• Mikrotik QOS в распределенных системах или умные шейперы. Часть 4.

© Григорьев Дмитрий https://habrahabr.ru/post/307214/