MikroTik управление на трафика: опашки

Обобщение Управлението на трафика на MikroTik се крепи на три инструмента: прости опашки за бързо ограничение на отделен клиент, дървета от опашки за йерархия и приоритет, и PCQ за справедливо споделяне между много потребители, без да създавате отделна опашка за всеки. Дърветата от опашки работят заедно с mangle маркерите на firewall и ви дават гаранции, тавани и приоритети. Това ръководство показва кога да използвате всеки от тях, командите на RouterOS и как да поддържате една и съща политика последователно на целия флот от рутери.

Какво е управление на трафика на MikroTik?

Управлението на трафика на MikroTik е използването на опашки на RouterOS, за да се контролира каква част от даден линк може да консумира всеки клиент, подмрежа или клас трафик — ограничавайки скорости, гарантирайки минимуми и решавайки кой отстъпва, когато линкът е запълнен. RouterOS реализира опашките с планировчик от тип Hierarchical Token Bucket (HTB), достъпен на две места: прости опашки — подреден списък, прилаган последователно — и дърво от опашки — йерархия, прикачена към интерфейси или към маркерите на пакети от mangle механизма на firewall (MikroTik Documentation — Queues).

Разликата определя докъде ще мащабира вашият дизайн. Простата опашка отговаря на „ограничи този клиент до 50 Mbps”. Дървото от опашки отговаря на „този uplink от 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 Documentation — Queues).

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

Стъпка 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 Documentation — Queues). Задайте max-limit на родителя според това, което линкът реално доставя, а не според записаното в договора, иначе опашката никога не става тясното място и никога не оформя нищо.

Стъпка 4 — Добавете PCQ за справедливо споделяне

Per Connection Queue (PCQ) е причината MikroTik да мащабира до брой абонати, който прави списъка с опашки за всеки потребител неуправляем. PCQ тип опашка класифицира трафика по адресно поле и създава динамична подопашка за всяка отделна стойност, прилагайки една и съща скорост към всяка (MikroTik Documentation — 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 родител заедно спират един гост да изразходва uplink-а на обекта — вижте нашето ръководство за настройка на MikroTik HotSpot ваучери за страната на идентификационните данни.

Стъпка 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 или броячите на дървото от опашки, докато линкът е под натоварване, а не в 3 ч. през нощта, когато всичко е неактивно. Ако четенето на броячи в пик не е практично, изгледът Internet Link на MKController поддържа същата картина непрекъснато — натоварване спрямо договорената скорост; закъснение като средно, максимум и P95; и колко часа всеки линк е прекарал над 90% — така настройвате спрямо история, а не спрямо късметлийска моментна снимка.

Капацитетът също се променя. При настройка за dual-WAN failover max-limit на родителя, който сте настроили за оптика, е измислица в мига, в който трафикът попадне на LTE резервата — планирайте втора политика.

Стъпка 6 — Разпространете политиката из целия флот

Един рутер е конфигурация; сто рутера са операция. Политиката вече трябва да е идентична на всяко устройство, да оцелее след техника, който „временно” е вдигнал тавана на клиент, и да може да се възстанови, когато рутер на кула бъде преинсталиран с netinstall. Нищо в RouterOS не прави това вместо вас.

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

Съвети

• Оформяйте на интерфейса, откъдето трафикът напуска рутера; опашките контролират изхода, така че свалянията се оформят от страната на LAN, а качванията — от страната на WAN.
• Предпочитайте един PCQ тип опашка пред стотици прости опашки, щом надхвърлите няколко дузини абонати.
• passthrough=no в правилата mark-packet спестява ненужно преминаване през останалите mangle правила.
• Винаги правете резервно копие, преди да пипате опашките на работещо гранично устройство, и променяйте по една променлива наведнъж.

Спрете да гадаете къде отиде честотната ви лента

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

Активирайте безплатния си пробен период на MKController