Статья не претендует на охват всей информации по QoS на Mikrotik. Это демонстрация набора правил, позволяющих настроить несложную схему приоритезации трафика и пополнять её по мере необходимости.

Надеюсь, коллеги помогут советами в комментариях.

Говоря о QoS, обычно подразумевают два направления — более или менее равномерное деление канала по количеству пользователей, либо приоритезацию трафика. Направления эти вполне дополняют друг-друга, но для дома, для семьи заниматься делением канала я смысла не вижу и, если вас интересует эта тема, сошлюсь на исчерпывающе раскрывающую тему статью «MikroTik QoS — развенчание мифов».

Я же сосредоточусь на приоретизации трафика, благо это несколько проще.

Ограничение скорости передачи данных может быть выполнено двумя способами:

1. Отбрасываются все пакеты, превышающие лимит скорости передачи (шейпер).

2. Задержка превысивших заданное ограничение скорости передачи пакетов в очереди и отправка их позже, как только появляется такая возможность, т.е. выравнивание скорости передачи (шедулер).

Как видно на иллюстрации, шейпер режет всё, что не влезло, а шедулер просто притормаживает.

Соответственно, именно шедулер нам и нужен.

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

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

Итак, план таков:

prio_1: DNS, ICMP, ACK — в первую очередь идёт служебный трафик. Установка и разрыв соединений, резолвинг имён и т.п.

prio_2: SIP — VoIP очень любит минимальные задержки.

prio_3: SSH и игры — удалённый доступ важен для работы. Игры — для отдыха.

prio_4: RDP и HTTP/HTTPS — веб, видео и т.п.

prio_5: всё, что не опознано выше — в принципе, можно принудительно загнать сюда торренты. Благо дома порты с которых работают клиенты вполне известны.

Маленькое лирическое отступление:

Если мы поищем информацию о QoS в Mikrotik, то найдём несколько вариантов скриптов, начиная от монструозного QOS script by Greg Sowell или явно основанного на нём The Mother of all QoS Trees, заканчивая Traffic Prioritization Script (кстати, советую отнестись к нему с большой осторожностью, автор явно довольно смутно понимает, что делает и поэтому скрипт делает явно не то, что было задумано). У всех этих скриптов есть одна общая проблема — они написаны довольно давно и в значительной степени устарели по одной простой причине — мир изменился.

Сегодня, благодаря всеобщему шифрованию трафика, мы не можем так запросто взять и с помощью L7-regexp отловить трафик youtube, например, или Skype. Поэтому, используя такие скрипты, внимательно отнеситесь к вопросу определения трафика. Это, на мой взгляд, единственная сложность в этом вопросе.

Теперь разметим трафик согласно плана выше. В коде я использую interfaceBandwidth, т.е. ширину канала. У меня он симметричный и равен 100М. Если у вас отличается ширина канала, то необходимо изменить значение interfaceBandwidth на необходимое. Если канал асинхронный, то скрипт будет сложнее за счёт необходимости отдельно маркировать пакеты для входящего и исходящего трафика. Это несложно, но значительно увеличит скрипт, ухудшив его читаемость и, в целом, выходит за рамки статьи.

В address-list я демонстрирую возможность массовой вставки адресов из FQDN (для примера взяты адреса кластеров из wiki Мира Танков). Разумеется, можно просто прописать необходимые IP вручную.

#Set bandwidth of the interface

:local interfaceBandwidth 100M

# address-lists

:for i from=1 to=10 do={/ip firewall address-list add list=WoT address=("login.p"."$i".".worldoftanks.net")}

#

/ip firewall mangle

# prio_1

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=icmp

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=tcp port=53

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=udp port=53

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=tcp tcp-flags=ack packet-size=0-123

# prio_2

add chain=prerouting action=mark-packet new-packet-mark=prio_2 dscp=40

add chain=prerouting action=mark-packet new-packet-mark=prio_2 dscp=46

add chain=prerouting action=mark-packet new-packet-mark=prio_2 protocol=udp port=5060,5061,10000-20000 src-address=192.168.100.110

add chain=prerouting action=mark-packet new-packet-mark=prio_2 protocol=udp port=5060,5061,10000-20000 dst-address=192.168.100.110

# prio_3

add chain=prerouting action=mark-packet new-packet-mark=prio_3 protocol=tcp port=22

add chain=prerouting action=mark-packet new-packet-mark=prio_3 address-list=WoT

# prio_4

add chain=prerouting action=mark-packet new-packet-mark=prio_4 protocol=tcp port=3389

add chain=prerouting action=mark-packet new-packet-mark=prio_4 protocol=tcp port=80,443

# prio_5

add chain=prerouting action=mark-packet new-packet-mark=prio_5

Аккуратно уложим размеченный трафик в очередь:

queue tree add max-limit=$interfaceBandwidth name=QoS_global parent=global priority=1

:for indexA from=1 to=5 do={

/queue tree add \

name=( "prio_" . "$indexA" ) \

parent=QoS_global \

priority=($indexA) \

queue=ethernet-default \

packet-mark=("prio_" . $indexA) \

comment=("Priority " . $indexA . " traffic")

}

И последнее, коль скоро Mikrotik поддерживает WMM, было бы логично разметить трафик и для него.

Делается это тем же mangle-ом с помощью команды set_priority. Согласно wiki Mikrotik'а, таблица приоритетов WMM выглядит довольно причудливо:

1,2 — background

0,3 — best effort

4,5 — video

6,7 — voice.

Разметим приоритеты, используя те же правила, что и для маркировки пакетов:

/ip firewall mangle

# prio_1

add chain=prerouting action=set-priority new-priority=7 protocol=icmp

add chain=prerouting action=set-priority new-priority=7 protocol=tcp port=53

add chain=prerouting action=set-priority new-priority=7 protocol=udp port=53

add chain=prerouting action=set-priority new-priority=7 protocol=tcp tcp-flags=ack packet-size=0-123

# prio_2

add chain=prerouting action=set-priority new-priority=6 dscp=40

add chain=prerouting action=set-priority new-priority=6 dscp=46

add chain=prerouting action=set-priority new-priority=6 protocol=udp port=5060,5061,10000-20000 src-address=192.168.100.110

add chain=prerouting action=set-priority new-priority=6 protocol=udp port=5060,5061,10000-20000 dst-address=192.168.100.110

# prio_3

add chain=prerouting action=set-priority new-priority=5 protocol=tcp port=22

add chain=prerouting action=set-priority new-priority=4 address-list=WoT

# prio_4

add chain=prerouting action=set-priority new-priority=3 protocol=tcp port=3389

В принципе, на этом всё.

В будущем, при необходимости, можно подумать о формировании динамических адресных листов, периодически формируемых из кэша DNS скриптами типа:

:foreach i in=[/ip dns cache all find where (name~"youtube" || name~"facebook" || name~".googlevideo")]

do={:put [/ip dns cache get $i address]}

для отбора онлайнового видео.

Или детектить Skype с помощью поиска upnp-правил:

:foreach i in=[/ip firewall nat find dynamic and comment~"Skype"]

do={:put [/ip firewall nat get $i dst-port]}

Но пока у меня такой необходимости нет.

Скрипты из статьи доступны на GitHub'е. Если у вас что-то не заработало, есть идеи или комментарии — пишите.

Спасибо за внимание!

UPD: В исходной версии поста в скриптах была ошибка (неверно указана цепочка) из-за которой трафик не попадал в очередь. Сейчас она исправлена.

UPD: В тексте скрипта в статье обнаружена ошибка. Прошу использовать версию с GitHub'а.