Simple Queues у RouterOS 7 – це найпростіший спосіб обмежити швидкість для окремого клієнта, пристрою або цілої підмережі. Для домашньої мережі, маленького офісу або homelab цього часто достатньо: задав target, виставив max-limit, перевірив counters – і правило працює. У цій статті розберемо базове налаштування, варіант для підмережі, схему для кількох клієнтів, пріоритети і типові причини, через які черги “ніби є, але не працюють”.

MikroTik сам відокремлює два сценарії: /queue simple для звичайних щоденних задач на кшталт ліміту для одного клієнта або невеликої групи, і /queue tree для складнішої політики з packet marks та глобальним керуванням трафіком. Тому якщо вам потрібно просто обмежити інтернет на ноутбуці, камері, телевізорі або гостьовому VLAN, починати варто саме з Simple Queues.

Як Simple Queue визначає напрямок трафіку

Перед налаштуванням треба зрозуміти одну річ. Simple Queue порівнює target з src і dst адресами пакета. Якщо адреса з target збіглася з src, це upload. Якщо збіглася з dst, це download. Якщо той самий трафік підпадає під обидва варіанти, RouterOS зарахує його як download, бо перевірка dst спрацьовує першою. Через це Simple Queue краще налаштовувати так, щоб пакет збігався або по src, або по dst, але не по обох одразу.

Це особливо важливо, коли ви починаєте різати не тільки інтернет, а й трафік між внутрішніми сегментами. На простому домашньому роутері це часто не помітно, але у VLAN-схемі помилки з target вилазять дуже швидко.

Що означають target, max-limit, limit-at і priority

У Simple Queue головні поля такі:

• target – IP-адреса, підмережа або інтерфейс, для якого діє правило.
• max-limit – максимальна дозволена швидкість. У термінах MikroTik це MIR, тобто верхня межа, до якої потік може розігнатися, якщо смуга вільна.
• limit-at – гарантована швидкість. Це CIR, мінімум, який черга має отримувати навіть при конкуренції з іншими потоками.
• priority – пріоритет дочірньої черги від 1 до 8, де 1 найвищий. Він працює тільки між дочірніми чергами і не має стосунку до burst.

Якщо коротко: max-limit обмежує стелю, limit-at резервує мінімум, а priority каже роутеру, кого годувати першим, коли канал забитий.

Покрокове налаштування Simple Queue для одного пристрою

Найпростіший сценарій – обмежити один хост.

Припустимо, у вас є комп’ютер 192.168.88.10, і ви хочете дати йому не більше 20 мегабіт в обидва боки.

/queue simple
add name=pc1 target=192.168.88.10/32 max-limit=20M/20M

Що тут відбувається:

• name=pc1 – просто ім’я правила;
• target=192.168.88.10/32 – правило діє тільки на цей хост;
• max-limit=20M/20M – до 20 мегабіт на upload і download.

Якщо для цього ж пристрою треба не просто стеля, а гарантований мінімум, додаєте limit-at. Наприклад, мінімум 10 мегабіт, максимум 50:

/queue simple
add name=workstation target=192.168.88.10/32 limit-at=10M/10M max-limit=50M/50M

Це вже корисно для робочих станцій, серверів, відеонагляду або будь-якого трафіку, який не повинен просідати, коли хтось у мережі почав качати великий файл. MikroTik прямо використовує limit-at у своєму прикладі як спосіб гарантувати смугу для сервера.

Як обмежити швидкість для підмережі

Якщо треба порізати весь гостьовий сегмент або окремий VLAN, target можна задати підмережею. Наприклад, для 192.168.50.0/24:

/queue simple
add name=guest target=192.168.50.0/24 max-limit=50M/50M

Такий запис ставить загальну стелю 50 мегабіт на всю підмережу. Це зручно для гостьового Wi-Fi або сегмента з “нешкідливими” клієнтами, де не хочеться розкладати окрему чергу на кожен телефон.

Але тут є межа цього підходу. Одна Simple Queue на підмережу не гарантує чесний розподіл швидкості між усіма хостами. Вона обмежує весь сегмент як один target. Якщо один активний клієнт забере більшу частину смуги, інші можуть залишитися без нормальної швидкості. Для справедливішого поділу між великою кількістю користувачів MikroTik передбачає інші підходи, зокрема через типи черг і складніші схеми.

Як правильно організувати кілька черг для різних клієнтів

Коли клієнтів уже кілька, є два нормальні варіанти.

Перший – просто окремі незалежні черги:

/queue simple
add name=user1 target=192.168.88.11/32 max-limit=20M/20M
add name=user2 target=192.168.88.12/32 max-limit=20M/20M
add name=user3 target=192.168.88.13/32 max-limit=10M/10M

Це робочий варіант для невеликої домашньої мережі, де потрібно кілька окремих лімітів і все.

Другий варіант – ієрархія через parent. Спочатку створюєте батьківську чергу на весь сегмент, а потім дочірні правила для окремих груп або хостів:

/queue simple
add name=lan-total target=192.168.88.0/24 max-limit=100M/100M
add name=admin target=192.168.88.10/32 parent=lan-total limit-at=20M/20M max-limit=50M/50M priority=1
add name=users target=192.168.88.0/25 parent=lan-total max-limit=40M/40M priority=5
add name=guest target=192.168.88.128/25 parent=lan-total max-limit=20M/20M priority=8

Тут уже є сенс у пріоритетах. Робочий комп’ютер з priority=1 отримає більше шансів дотягнутися до свого max-limit, ніж гостьовий сегмент з priority=8. MikroTik прямо зазначає, що пріоритет працює тільки між дочірніми чергами, а батьківська черга має захоплювати весь потрібний трафік, інакше дочірні правила просто не побачать свої пакети.

Є ще одна проста, але корисна рекомендація з документації: сума limit-at у дочірніх чергах не повинна перевищувати max-limit батьківської. Інакше ви самі створюєте конфіг, де всі “гарантовані” смуги вже з’їли весь канал.

Як перевірити, що черга реально працює

Після створення правила треба не просто подивитися на нього в списку, а перевірити статистику. У Simple Queue є counters: rate, bytes, packets, queued-bytes, queued-packets, dropped, borrows, lends. Якщо ви запускаєте трафік з потрібного клієнта, а counters стоять на нулі, проблема не в “поганому інтернеті”, а в конфігурації черги.

Мінімальна перевірка виглядає так:

1. Створили чергу.
2. Запустили трафік з потрібного хоста.
3. Подивилися, чи ростуть rate і bytes.
4. Зіставили фактичну швидкість з max-limit.
5. Якщо не працює – одразу дивитеся FastTrack і target.

На практиці цього достатньо, щоб відразу зрозуміти, чи ви справді shaping-ите трафік, чи просто додали запис у конфіг і заспокоїлися.

Чому Simple Queue часто “не працює”

Найчастіша причина – FastTrack. MikroTik прямо пише: якщо ви використовуєте стандартну конфігурацію, fasttracked трафік обходить Simple Queues. Тому для потрібного трафіку FastTrack треба вимкнути або винести його з fasttrack-правила, інакше черги не спрацюють. Якщо ліміти не застосовуються, це перше, що треба перевірити.

Друга типова причина – невдалий target. Якщо правило задане занадто широко, або трафік збігається з адресою і як src, і як dst, поведінка буде не такою, як ви очікували. У Simple Queue це не дрібниця, а частина самої логіки роботи.

Третя причина – забагато черг. У Simple Queue суворий порядок обробки: кожен пакет іде зверху вниз по списку, поки не знайде потрібне правило або не дійде до кінця. MikroTik наводить простий приклад: якщо черг тисяча, пакет до останньої пройде 999 перевірок. Для звичайного домашнього роутера з кількома правилами це не біда. Для великого списку винятків і сегментів – уже привід переглянути підхід.

Коли Simple Queue вже незручна

Simple Queues добре працюють, поки задача залишається простою: один клієнт, кілька хостів, одна підмережа, батьківська черга з кількома дочірніми. Якщо ж вам потрібна глобальна політика пріоритизації, packet marks через mangle, окреме керування потоками по інтерфейсах або складна Quality of Service, тут уже логічніше дивитися в бік Queue Tree. MikroTik прямо описує Queue Tree як інструмент для advanced queuing tasks і підкреслює, що на відміну від Simple Queue воно не працює як впорядкований список, де пакет послідовно проходить правило за правилом.

Тобто межа проста. Якщо у вас 3-10 правил і зрозуміла схема, Simple Queue – нормальний інструмент. Якщо ви вже почали будувати складну політику на весь трафік, прості черги стають не “простим рішенням”, а джерелом зайвих компромісів.

Висновок

Для MikroTik RouterOS 7 прості черги залишаються найзручнішим способом швидко обмежити швидкість для одного пристрою, кількох клієнтів або цілої підмережі. Робоча схема виглядає так: правильно задати target, виставити max-limit, за потреби додати limit-at, не забути про priority у дочірніх чергах і обов’язково перевірити, чи трафік не обходить усе це через FastTrack.

Якщо потрібне саме покрокове налаштування для більшості домашніх сценаріїв, цього підходу вистачає. Якщо конфіг починає обростати десятками правил, перехресними винятками і складною логікою, краще зупинитися і перейти на Queue Tree, поки Simple Queue не перетворилася на хаос, який страшно чіпати.