Managementul benzii MikroTik: Cozi

Rezumat Managementul benzii pe MikroTik se sprijină pe trei unelte: cozi simple pentru o limitare rapidă per client, arbori de cozi pentru ierarhie și prioritate și PCQ pentru partajare echitabilă între mulți utilizatori fără a crea câte o coadă pentru fiecare. Arborii de cozi se combină cu marcajele firewall mangle și îți oferă garanții, plafoane și priorități. Acest ghid arată când să folosești fiecare, comenzile RouterOS și cum să menții aceeași politică consecventă pe o flotă de routere.

Ce Este Managementul Benzii pe MikroTik?

Managementul benzii pe MikroTik este utilizarea cozilor RouterOS pentru a controla cât dintr-o legătură poate consuma fiecare client, subrețea sau clasă de trafic — limitând ratele, garantând minime și decizând cine cedează când legătura este plină. RouterOS implementează cozile cu un planificator Hierarchical Token Bucket (HTB), expus în două locuri: cozi simple, o listă ordonată aplicată în secvență, și arborele de cozi, o ierarhie atașată interfețelor sau marcajelor de pachete din facilitatea mangle a firewall-ului (Documentația MikroTik — Queues).

Distincția decide cât de mult se va scala arhitectura ta. O coadă simplă răspunde la „limitează acest client la 50 Mbps”. Un arbore de cozi răspunde la „acest uplink de 500 Mbps este împărțit de 300 de abonați, VoIP trece primul, nimeni nu rămâne pe uscat, iar cei care descarcă masiv nu strică seara”. Orice ISP ajunge, mai devreme sau mai târziu, să aibă nevoie de al doilea răspuns.

Pasul 1 — Limitează un client cu o coadă simplă

Cozile simple sunt calea cea mai scurtă de la problemă la soluție. Vizează un IP, o subrețea sau o interfață, setează plafonul și ai terminat:

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

max-limit se scrie ca upload/download din punctul de vedere al routerului. Regulile sunt evaluate în ordine și prima potrivire câștigă — așa că o regulă generală plasată devreme înghite în tăcere pe cele specifice pe care le adaugi mai târziu. Această ordonare este cel mai frecvent motiv pentru care o coadă „funcțională” încetează să funcționeze după ce cineva adaugă o regulă deasupra ei (Documentația MikroTik — Queues).

Cozile simple se combină și cu autentificarea abonaților: câmpul rate-limit al unui profil PPPoE creează o coadă simplă dinamică per sesiune, așa că planurile urmăresc utilizatorul, nu IP-ul. Ghidul nostru despre serverul PPPoE MikroTik pentru furnizorii de internet acoperă partea de profil.

Pasul 2 — Marchează traficul cu firewall mangle

Arborele de cozi nu poate vedea „VoIP” sau „clientul 101”; el vede marcaje de pachete. Creează-le în mangle, marcând mai întâi conexiunea și apoi pachetele, ceea ce este mai ieftin decât reinspectarea fiecărui pachet:

/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

Menține taxonomia marcajelor mică și stabilă. Marcajele sunt vocabularul pe care îl vorbesc cozile tale, iar odată ce o flotă are trei generații de nume de marcaje ad-hoc, nimeni nu mai poate spune care router impune ce politică. Aici își merită locul auditul și istoricul configurațiilor din MKController: vezi starea mangle și a cozilor pentru fiecare router, compar-o cu politica intenționată și trimite regulile corectate la nivel de flotă în loc să deschizi treizeci de sesiuni Winbox ca să găsești unica cutie care nu a primit niciodată modificarea.

Pasul 3 — Construiește ierarhia arborelui de cozi

Un arbore de cozi are un părinte care deține capacitatea reală a legăturii și copii care o împart:

/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

Trei câmpuri fac treaba. limit-at este garanția pe care o primește un copil chiar și atunci când legătura este saturată. max-limit este plafonul pe care îl poate atinge când există capacitate liberă. priority — 1 este cea mai mare, 8 cea mai mică — decide care copil primește primul resturile și se aplică doar între limit-at și max-limit (Documentația MikroTik — Queues). Setează max-limit-ul părintelui la ce livrează efectiv legătura, nu la ce spune contractul, altfel coada nu devine niciodată gâtul de sticlă și nu modelează nimic.

Pasul 4 — Adaugă PCQ pentru partajare echitabilă

Per Connection Queue (PCQ) este motivul pentru care MikroTik se scalează la numere de abonați care fac o listă de cozi per utilizator imposibil de gestionat. Un tip de coadă PCQ clasifică traficul după un câmp de adresă și creează o sub-coadă dinamică pentru fiecare valoare distinctă, aplicând aceeași rată fiecăreia (Documentația 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

Atașează pcq-down ca queue al copilului care poartă traficul de download al clienților, și fiecare client primește până la 20 Mbps, alocați automat. Setează pcq-rate=0 și PCQ împarte banda părintelui în mod egal între toți cei activi — configurația clasică „nimeni nu rămâne pe uscat”. Un singur tip de coadă înlocuiește sute de intrări scrise manual.

Aceeași logică de egalizare se aplică și la WiFi-ul partajat: limita de rată a planului și un părinte PCQ opresc împreună un singur oaspete să consume uplink-ul unei locații — vezi ghidul nostru de configurare a voucherelor HotSpot MikroTik pentru partea de credențiale.

Pasul 5 — Reglează limit-at, max-limit, burst și priority

Majoritatea configurațiilor QoS defecte nu înseamnă o unealtă greșită, ci numere greșite. Menține suma limit-at a fiecărui copil la nivelul sau sub max-limit-ul părintelui; dacă garanțiile suprasolicită legătura, HTB nu le poate onora, iar prioritățile încetează să se comporte așa cum te aștepți. Rezervă priority=1 pentru traficul sensibil la latență — VoIP, gaming, DNS — și lasă transferurile în masă la 8 cu un plafon generos.

Burst-ul merită un avertisment. burst-limit, burst-threshold și burst-time permit unui client să depășească max-limit pentru scurt timp cât timp media rămâne scăzută — excelent pentru testele de viteză, mai puțin bun pentru o legătură suprasolicitată. Măsoară cu /queue simple print stats sau cu contoarele arborelui de cozi în timp ce legătura este sub sarcină, nu la 3 dimineața când totul este inactiv. Dacă citirea contoarelor la vârf nu este practică, vizualizarea Internet Link din MKController păstrează aceeași imagine în mod continuu — utilizarea față de viteza contractată; latența ca medie, maxim și P95; și câte ore a petrecut fiecare legătură peste 90% — astfel încât reglezi în funcție de istoric, nu de o captură norocoasă.

Capacitatea se schimbă și ea. Într-o configurație de failover dual-WAN, max-limit-ul părintelui pe care l-ai reglat pentru fibră devine ficțiune în momentul în care traficul ajunge pe backup-ul LTE — planifică o a doua politică.

Pasul 6 — Implementează politica pe toată flota

Un router este o configurație; o sută de routere sunt o operațiune. Politica trebuie acum să fie identică pe fiecare cutie, să supraviețuiască tehnicianului care „temporar” a ridicat plafonul unui client și să poată fi recuperată când un router de pe turn este reinstalat prin netinstall. Nimic din RouterOS nu face asta în locul tău.

MKController face: trimiteri la nivel de flotă de tipuri de cozi, profiluri rate-limit și reguli de firewall; istoric de configurație, ca să poți vedea când s-a schimbat o limită și să restaurezi versiunea anterioară dintr-un singur clic; copii de rezervă automate înainte de o modificare; și acces remote securizat de ieșire către routere aflate în spatele CGNAT sau pe Starlink, fără IP public și fără redirecționare de porturi — abordarea pe care o descriem în administrarea de la distanță a MikroTik în spatele CGNAT. Iar monitorizarea Internet Link supraveghează chiar uplink-urile pe care tocmai le-ai modelat — utilizarea per sursă față de viteza contractată, latența cu P95 și consumul care trece de pragurile de 75% și 90% pe până la patru surse WAN per router — astfel încât o legătură care se apropie de saturație apare pe panou și (împreună cu alertele Telegram) în notificările tale, înainte ca un abonat să sune. Furnizorii de internet și WISP-urile care rulează MikroTik la scară îl folosesc pentru ca politica de bandă să rămână o singură decizie, nu o sută.

Sfaturi

• Modelează pe interfața de pe care traficul părăsește routerul; cozile controlează egresul, așa că descărcările sunt modelate pe partea LAN, iar încărcările pe partea WAN.
• Preferă un singur tip de coadă PCQ în locul a sute de cozi simple odată ce depășești câteva zeci de abonați.
• passthrough=no pe regulile mark-packet economisește parcurgerea inutilă a regulilor mangle rămase.
• Fă întotdeauna o copie de rezervă înainte de a atinge cozile pe un edge de producție și schimbă câte o singură variabilă pe rând.

Nu mai ghici pe unde ți-a dispărut banda

Cozile sunt diferența dintre a vinde un plan și a-l livra. Cozile simple limitează un client, arborii de cozi oferă structură și prioritate, PCQ face echitatea automată — iar MKController transformă toate cele trei într-o politică pe care o aplici o singură dată și o impui peste tot: gestiune centralizată a flotei, trimiteri de rate-limit și firewall către fiecare router, istoric de configurație cu restaurare dintr-un singur clic, acces remote fără IP public și monitorizare Internet Link care semnalează o legătură care se saturează față de viteza contractată înainte s-o facă clienții tăi.

Începe perioada gratuită de testare MKController