Управление полосой MikroTik: очереди

Кратко Управление полосой на MikroTik держится на трёх инструментах: simple queues для быстрого лимита на клиента, queue tree для иерархии и приоритетов, и PCQ для честного распределения между множеством пользователей без создания отдельной очереди для каждого. Queue tree работает в паре с метками firewall mangle и даёт вам гарантии, потолки и приоритеты. Это руководство показывает, когда применять каждый инструмент, команды RouterOS и как сохранить одну и ту же политику одинаковой на всём парке роутеров.

Что такое управление полосой на MikroTik?

Управление полосой на MikroTik — это использование очередей RouterOS для контроля того, сколько канала может занять каждый клиент, подсеть или класс трафика: ограничение скоростей, гарантирование минимумов и решение, кто уступает, когда канал заполнен. RouterOS реализует очереди на планировщике Hierarchical Token Bucket (HTB), доступном в двух местах: simple queues — упорядоченный список, применяемый по порядку, и queue tree — иерархия, привязанная к интерфейсам или к меткам пакетов из подсистемы mangle файрвола (Документация MikroTik — Queues).

Это различие определяет, насколько масштабируется ваша схема. Simple queue отвечает на вопрос «ограничить этого клиента 50 Mbps». Queue tree отвечает на вопрос «этот аплинк на 500 Mbps делят 300 абонентов, VoIP идёт первым, никто не голодает, а любители тяжёлых загрузок не портят всем вечер». Рано или поздно второй ответ нужен каждому провайдеру.

Шаг 1 — Ограничьте одного клиента через simple queue

Simple queues — это кратчайший путь от проблемы к решению. Укажите IP, подсеть или интерфейс, задайте потолок — и готово:

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

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

Simple queues также сочетаются с аутентификацией абонентов: поле rate-limit в профиле PPPoE создаёт динамическую simple queue на каждую сессию, поэтому тарифы следуют за пользователем, а не за IP. Сторону профиля разбирает наше руководство по серверу PPPoE MikroTik для провайдеров.

Шаг 2 — Промаркируйте трафик через firewall mangle

Queue tree не видит ни «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

У queue tree есть один родитель, удерживающий реальную ёмкость канала, и дочерние очереди, которые её делят:

/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 example):

/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 или по счётчикам queue tree, когда канал под нагрузкой, а не в 3 часа ночи, когда всё простаивает. Если снимать счётчики в пик неудобно, представление Internet Link в MKController держит ту же картину непрерывно — утилизация относительно тарифной скорости; задержка как среднее, максимум и P95; и сколько часов каждый канал провёл выше 90% — чтобы вы настраивали по истории, а не по удачному снимку.

Ёмкость к тому же не постоянна. При схеме резервирования dual-WAN родительский max-limit, настроенный под оптику, становится вымыслом в тот момент, когда трафик уходит на резервный LTE — планируйте вторую политику.

Шаг 6 — Разверните политику на всём парке

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

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

Советы

• Формируйте трафик на том интерфейсе, откуда он уходит из роутера; очереди управляют исходящим направлением, поэтому загрузки формируются на стороне LAN, а отдачи — на стороне WAN.
• Предпочитайте один тип очереди PCQ сотням simple queues, как только переваливаете за несколько десятков абонентов.
• passthrough=no в правилах mark-packet избавляет от лишнего прохода по остальным правилам mangle.
• Всегда делайте бэкап перед тем, как трогать очереди на боевом пограничном роутере, и меняйте по одной переменной за раз.

Перестаньте гадать, куда ушла ваша полоса

Очереди — это разница между тем, чтобы продать тариф и чтобы его выдать. Simple queues ограничивают клиента, queue trees дают структуру и приоритет, PCQ делает справедливость автоматической — а MKController превращает все три в политику, которую вы применяете один раз и обеспечиваете везде: централизованное управление парком, отправка rate-limit и правил файрвола на каждый роутер, история конфигураций с восстановлением в один клик, удалённый доступ без публичного IP и мониторинг Internet Link, отмечающий насыщение канала относительно его тарифной скорости раньше, чем это сделают ваши клиенты.

Начните бесплатный пробный период MKController