Керування смугою MikroTik: черги

Стисло Керування смугою на MikroTik тримається на трьох інструментах: прості черги для швидкого обмеження на клієнта, дерева черг для ієрархії та пріоритету і PCQ для справедливого розподілу між багатьма користувачами без окремої черги на кожного. Дерева черг працюють у парі з мітками firewall mangle і дають вам гарантії, стелі та пріоритети. Цей посібник показує, коли застосовувати кожен, які команди RouterOS для цього потрібні та як тримати ту саму політику однаковою на всьому парку роутерів.

Що таке керування смугою на MikroTik?

Керування смугою на MikroTik — це використання черг RouterOS для контролю того, скільки каналу може споживати кожен клієнт, підмережа чи клас трафіку: обмеження швидкостей, гарантування мінімумів і рішення, хто поступається, коли канал заповнений. RouterOS реалізує черги за допомогою планувальника Hierarchical Token Bucket (HTB), доступного у двох місцях: прості черги — упорядкований список, що застосовується послідовно, і дерево черг — ієрархія, прив’язана до інтерфейсів або до міток пакетів із механізму mangle у firewall (Документація MikroTik — Queues).

Ця відмінність визначає, наскільки масштабованим буде ваше рішення. Проста черга відповідає на запит «обмеж цього клієнта до 50 Mbps». Дерево черг відповідає на «цей аплінк на 500 Mbps ділять 300 абонентів, VoIP іде першим, ніхто не голодує, а важкі завантажувачі не псують усім вечір». Кожен провайдер рано чи пізно потребує другої відповіді.

Крок 1 — Обмежте одного клієнта простою чергою

Прості черги — найкоротший шлях від проблеми до розв’язання. Націльтеся на IP, підмережу чи інтерфейс, задайте стелю — і готово:

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

max-limit записується як upload/download з погляду роутера. Правила обробляються по порядку, і перемагає перший збіг — тож раннє широке правило непомітно поглинає конкретніші, які ви додаєте пізніше. Саме цей порядок — найчастіша причина того, що «робоча» черга перестає працювати після того, як хтось додав правило вище за неї (Документація MikroTik — Queues).

Прості черги також працюють у парі з автентифікацією абонентів: поле rate-limit профілю PPPoE створює динамічну просту чергу на кожну сесію, тож тарифи слідують за користувачем, а не за IP. Наш посібник із сервера PPPoE MikroTik для провайдерів розкриває бік профілів.

Крок 2 — Позначте трафік через firewall mangle

Дерево черг не бачить ні «VoIP», ні «клієнта 101» — воно бачить мітки пакетів. Створіть їх у mangle, позначаючи спершу з’єднання, а потім пакети, що дешевше, ніж переінспектувати кожен пакет:

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

Тримайте таксономію міток невеликою й стабільною. Мітки — це словник, яким говорять ваші черги, і щойно в парку з’являється три покоління стихійних імен міток, ніхто вже не скаже, який роутер яку політику застосовує. Ось де аудит конфігурації та історія змін MKController виправдовують себе: подивіться стан mangle і черг кожного роутера, звірте його з задуманою політикою та надішліть виправлені правила на весь парк, замість відкривати тридцять сесій Winbox у пошуках однієї коробки, яка так і не отримала зміну.

Крок 3 — Побудуйте ієрархію дерева черг

Дерево черг має одну батьківську чергу, що тримає реальну ємність каналу, і дочірні, які її ділять:

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

Роботу роблять три поля. limit-at — це гарантія, яку дочірня черга отримує навіть коли канал насичений. max-limit — стеля, якої вона може сягнути, коли ємність вільна. priority — 1 найвищий, 8 найнижчий — визначає, яка дочірня черга першою отримує залишки, і діє лише між limit-at та max-limit (Документація MikroTik — Queues). Задайте max-limit батьківської черги за тим, що канал реально видає, а не за тим, що написано в договорі, інакше черга ніколи не стане вузьким місцем і нічого не формуватиме.

Крок 4 — Додайте PCQ для справедливого розподілу

Per Connection Queue (PCQ) — причина, з якої MikroTik масштабується до кількості абонентів, за якої список черг на кожного користувача стає некерованим. Тип черги PCQ класифікує трафік за полем адреси й створює динамічну підчергу для кожного унікального значення, застосовуючи до кожної однакову швидкість (Документація MikroTik — приклад PCQ):

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=10M pcq-classifier=src-address

Прив’яжіть pcq-down як queue дочірньої черги, що несе завантажувальний трафік клієнтів, — і кожен клієнт отримає до 20 Mbps, виділених автоматично. Задайте pcq-rate=0, і PCQ розділить смугу батьківської черги порівну між усіма активними — класична конфігурація «ніхто не голодує». Один тип черги замінює сотні написаних вручну записів.

Та сама зрівнювальна логіка діє й для спільного WiFi: ліміт швидкості тарифу разом із батьківською чергою PCQ не дають одному гостю з’їсти весь аплінк закладу — див. наш посібник із налаштування ваучерів HotSpot MikroTik щодо боку облікових даних.

Крок 5 — Налаштуйте limit-at, max-limit, burst і priority

Більшість поламаного QoS — це не хибний інструмент, а хибні числа. Тримайте суму limit-at усіх дочірніх черг на рівні max-limit батьківської або нижче; якщо гарантії перевищують канал, HTB не може їх дотримати, і пріоритети перестають поводитися так, як ви очікуєте. Зарезервуйте priority=1 для чутливого до затримок трафіку — VoIP, ігри, DNS — а масові передачі лишіть на 8 із щедрою стелею.

Burst заслуговує на застереження. burst-limit, burst-threshold і burst-time дозволяють клієнту ненадовго перевищити max-limit, поки його середнє значення лишається низьким, — чудово для тестів швидкості, гірше для перевантаженого каналу. Вимірюйте командою /queue simple print stats або лічильниками дерева черг, поки канал під навантаженням, а не о третій ночі, коли все простоює. Якщо читати лічильники в пік непрактично, режим Internet Link у MKController тримає ту саму картину безперервно — використання відносно договірної швидкості; затримка як середнє, максимум і P95; і скільки годин кожен канал провів понад 90% — тож ви налаштовуєте за історією, а не за вдалим знімком.

Ємність теж змінюється. У конфігурації з відмовостійкістю dual-WAN max-limit батьківської черги, який ви налаштували під оптику, стає вигадкою тієї миті, коли трафік переходить на резервний LTE, — сплануйте другу політику.

Крок 6 — Розгорніть політику на весь парк

Один роутер — це конфігурація; сто роутерів — це операційна діяльність. Тепер політика має бути однаковою на кожній коробці, пережити техніка, який «тимчасово» підняв стелю клієнту, і піддаватися відновленню, коли роутер на вежі переустановлюють через netinstall. Ніщо в RouterOS не робить цього за вас.

MKController робить: розсилка на весь парк типів черг, профілів rate-limit і правил firewall; історія конфігурацій, щоб ви бачили, коли змінився ліміт, і відновлювали попередню версію в один клік; автоматичні бекапи перед зміною; і захищений вихідний віддалений доступ до роутерів за CGNAT чи на Starlink — без публічного IP і без прокидання портів — підхід, який ми описуємо в віддаленому керуванні MikroTik за CGNAT. А його моніторинг Internet Link стежить саме за тими аплінками, які ви щойно сформували, — використання по кожному джерелу відносно договірної швидкості, затримка з P95 і споживання, що перетинає межі 75% і 90%, на до чотирьох WAN-джерел на роутер, — тож канал, що повзе до насичення, з’являється на дашборді, а (в парі з оповіщеннями Telegram) і у ваших сповіщеннях, перш ніж зателефонує абонент. Провайдери та WISP, що керують MikroTik у масштабі, використовують його, щоб політика смуги лишалася одним рішенням, а не сотнею.

Поради

• Формуйте на тому інтерфейсі, звідки трафік виходить з роутера; черги контролюють вихідний трафік, тож завантаження формуються з боку LAN, а віддача — з боку WAN.
• Щойно перетнете кілька десятків абонентів, віддавайте перевагу одному типу черги PCQ замість сотень простих черг.
• passthrough=no у правилах mark-packet економить зайвий прохід решти правил mangle.
• Завжди робіть бекап, перш ніж чіпати черги на бойовому граничному роутері, і змінюйте по одній змінній за раз.

Годі гадати, куди зникла ваша смуга

Черги — це різниця між тим, щоб продати тариф і щоб його справді надати. Прості черги обмежують клієнта, дерева черг дають структуру й пріоритет, PCQ робить справедливість автоматичною — а MKController перетворює всі три на політику, яку ви застосовуєте раз і забезпечуєте всюди: централізоване керування парком, розсилка rate-limit і firewall на кожен роутер, історія конфігурацій із відновленням в один клік, віддалений доступ без публічного IP і моніторинг Internet Link, що позначає канал, який насичується відносно договірної швидкості, раніше за ваших клієнтів.

Розпочніть безкоштовний пробний період MKController