MikroTik QoS – простий спосіб втримати Zoom, Google Meet і онлайн-ігри живими, коли хтось у мережі запускає великий upload або забиває канал завантаженнями. У цьому сценарії не потрібен складний PCQ: достатньо правильно обмежити батьківську чергу, позначити чутливий трафік і дати йому вищий пріоритет.
Суть підходу така: QoS на MikroTik починає працювати лише там, де маршрутизатор реально контролює чергу. Тому спершу задають трохи меншу швидкість, ніж дає лінк, а вже потім розкладають трафік за пріоритетами. Без цього будь-яке маркування виглядає красиво тільки в конфігу.
Для homelab і звичайної домашньої мережі цього підходу часто вистачає. Якщо задача – не поділити канал між десятками клієнтів, а прибрати лаги в дзвінках і стрибки ping під навантаженням, проста схема працює краще за важкий QoS-конструктор.
Що саме робимо
Практичний варіант MikroTik QoS для такого сценарію складається з трьох частин: маркування трафіку для відеодзвінків та ігор, одна батьківська черга на upload або на обидва напрямки, і кілька дочірніх черг з різним пріоритетом. Головне – не намагатися класифікувати все підряд.
Найкращий ефект зазвичай дає контроль upload. Саме вихідний канал першим лягає, коли йде backup у хмару, синхронізація фото, torrent або великий rsync назовні. Для Zoom і Meet цього вже достатньо, щоб голос не почав сипатися, а картинка не розвалювалась на квадрати.
Із download ситуація грубіша. Якщо вузьке місце в провайдера або модема перед маршрутизатором, MikroTik бачить проблему запізно. Тому просте пріоритезування найкраще працює на upload, а на download – лише якщо черга формується ще на самому роутері.
Коли PCQ зайвий
PCQ потрібен, коли важливо автоматично розподіляти смугу між багатьма хостами або підмережами. Для 3-10 активних клієнтів у домашній мережі це часто зайва складність. Якщо ціль – не чесний шейпінг для всіх, а низька затримка для кількох типів трафіку, пріоритетні queue tree або simple queues простіші в обслуговуванні.
На практиці складні QoS-схеми в MikroTik ламаються не через сам QoS, а через надмірну класифікацію. Починають маркувати сотні сервісів, CDN, порти і винятки. Через місяць ніхто вже не пам’ятає, чому половина правил дублюється, а ігровий трафік частково йде в default.
Для Zoom, Meet і ігор майже завжди вистачає двох класів: пріоритетний низьколатентний трафік і все інше. Іноді додають окремий низький пріоритет для backup, torrents або великих синхронізацій.
Як налаштувати MikroTik QoS без PCQ
Базова логіка така: спочатку вимірюють реальну швидкість каналу, потім ставлять queue limit трохи нижче цієї межі, далі маркують пакети або з’єднання для Zoom, Meet та ігор, і прив’язують ці мітки до дочірніх черг із вищим пріоритетом.
Назви інтерфейсів, швидкості і списки адрес доведеться підставити під свою схему. Конкретна реалізація залежить від RouterOS, але робочий шаблон виглядає так:
/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=conn-rt-media
protocol=udp dst-port=3478,3479,8801-8810 passthrough=yes comment="Realtime media"
add chain=forward action=mark-packet connection-mark=conn-rt-media
new-packet-mark=pkt-rt-media passthrough=no comment="Mark realtime packets"
add chain=forward action=mark-packet protocol=udp dst-port=50000-65535
new-packet-mark=pkt-games passthrough=no comment="Game UDP range if needed"
/queue tree
add name=wan-upload parent= max-limit=
add name=priority-rt parent=wan-upload packet-mark=pkt-rt-media priority=1 limit-at= max-limit=
add name=priority-games parent=wan-upload packet-mark=pkt-games priority=2 limit-at= max-limit=
add name=bulk parent=wan-upload priority=8 max-limit=
Ідея проста: чутливий до затримки трафік піднімається вище за bulk. Якщо в мережі немає сталого ігрового набору, окрему чергу для games краще не плодити. Достатньо одного realtime-класу.
З чого почати без зайвої класифікації
Спочатку варто зробити мінімум правил. Один клас для медіатрафіку, один default і, за потреби, один low priority для backup. Чим менше евристики, тим легше перевіряти результат. У MikroTik QoS це критично.
- Виміряти реальний upload і download у звичайний час.
- Поставити для черги межу трохи нижче реальної швидкості.
- Позначити тільки чутливий UDP-трафік для дзвінків та ігор.
- Призначити йому вищий пріоритет.
- Відправити решту в default або bulk.
Якщо провайдерський канал сильно плаває, фіксована межа теж почне шкодити. Тоді краще дати трохи більший запас вниз, ніж тримати ліміт впритул до номіналу.
Що маркувати для Zoom, Meet і ігор
Найбезпечніший шлях – маркувати не бренд, а тип трафіку. Для відеодзвінків це зазвичай UDP-медіапотоки та пов’язані з ними з’єднання. Для ігор – UDP від конкретних клієнтів або відомих діапазонів, якщо вони стабільні у вашій мережі.
Маркування по L7 або за довгим списком доменів тут зайве. Воно крихке, додає навантаження і погано переживає зміну CDN або службових адрес. У домашньому середовищі куди надійніше позначати трафік від пристрою, на якому йде дзвінок, або обмеженого набору UDP-потоків.
Неочевидний момент: ігровий трафік рідко потребує великої смуги. Йому потрібна передбачувана черга. Тому резервувати багато bandwidth під ігри сенсу немає. Краще дати вищий пріоритет і маленький гарантований мінімум.
Де така схема ламається
Найчастіше проста схема не працює з трьох причин: ліміт поставлений вище реальної швидкості, трафік маркується не в тій chain, або вузьке місце взагалі не на MikroTik. У всіх трьох випадках черги наче існують, але затримка нікуди не зникає.
Перша помилка – брати цифри з тарифу, а не з вимірів. Якщо upload за тарифом 50 Мбіт/с, а реально ввечері тримається 42, чергу треба будувати нижче 42. Інакше буферизація піде вище по тракту, поза контролем роутера.
Друга – намагатися ловити весь трафік сервісу за портами. Для Zoom і Meet частина допоміжного трафіку може піти інакше. Це нормально. QoS не вимагає ідеальної класифікації всіх пакетів. Достатньо коректно обробити медіапотоки, які чутливі до jitter і втрат.
Третя – увімкнути fasttrack без винятків. Якщо трафік обходить частину обробки, маркування і queue можуть не спрацювати як очікується. Для пріоритетних потоків fasttrack зазвичай доводиться обходити або акуратно виключати.
Ще одна типова межа – дуже дрібні домашні маршрутизатори під великим навантаженням. Коли одночасно працюють NAT, firewall, VPN і черги, запас CPU швидко тане. На слабкому пристрої простий QoS переживе навантаження краще, ніж багатошаровий PCQ із десятками правил.
Як перевірити, що MikroTik QoS реально працює
Перевірка проста: під час активного upload запускають Zoom або Meet, паралельно дивляться на ping і стежать за packet marks та counters у чергах. Якщо пріоритетний трафік потрапляє у свою чергу, а затримка не злітає при забитому каналі, схема працює правильно.
- Запустити стабільний великий upload – backup, копіювання в хмару, тестовий transfer.
- Почати відеодзвінок або голосову сесію.
- Перевірити counters у mangle та queue tree.
- Подивитися, чи не росте ping стрибками під навантаженням.
- Оцінити не середню швидкість, а jitter, уривки голосу і затримку керування в грі.
Корисно тримати окремий безперервний ping до шлюзу провайдера і до зовнішнього вузла. Якщо локально все рівно, а назовні стрибки залишаються, проблема може бути вже не в домашній черзі.
У RouterOS дивляться насамперед на те, чи зростають лічильники в потрібному packet-mark. Якщо трафік не потрапляє в мітку, пріоритету не буде, навіть коли queue tree намальоване без помилок.
Коли цього вже мало
Простий MikroTik QoS добре закриває типовий homelab-сценарій: кілька людей у дзвінках, трохи ігор, фонові синхронізації, NAS і апдейти. Коли в мережі з’являються десятки активних клієнтів, гостьові VLAN, окремі політики для серверів і жорстка потреба в fairness, тоді вже є сенс дивитися в бік складнішої ієрархії або PCQ.
Але до цього моменту найчастіше вистачає акуратної бази: контроль upload, мінімальна класифікація і нормальна перевірка counters. Саме тут проста схема дає найбільше користі за найменшу кількість болю.
Офіційна інформація про RouterOS і черги – на сайті MikroTik.