MikroTik kaistanhallinta: jonot

Tiivistelmä MikroTikin kaistanhallinta nojaa kolmeen työkaluun: yksinkertaisiin jonoihin nopeaan asiakaskohtaiseen rajoitukseen, jonopuihin hierarkiaa ja priorisointia varten sekä PCQ:hun tasajakoon monen käyttäjän kesken luomatta jonoa jokaiselle erikseen. Jonopuut yhdistyvät palomuurin mangle-merkintöihin ja antavat sinulle takuut, katot ja prioriteetit. Tämä opas näyttää, milloin kutakin kannattaa käyttää, RouterOS-komennot ja miten pidät saman käytännön yhdenmukaisena koko reititinlaivastossa.

Mitä on kaistanhallinta MikroTikissa?

Kaistanhallinta MikroTikissa tarkoittaa RouterOS-jonojen käyttöä sen hallitsemiseen, kuinka paljon linkistä kukin asiakas, aliverkko tai liikenneluokka saa kuluttaa — rajoittaen nopeuksia, taaten minimit ja päättäen, kuka väistää linkin ollessa täynnä. RouterOS toteuttaa jonot Hierarchical Token Bucket (HTB) -ajastimella, joka on esillä kahdessa paikassa: yksinkertaiset jonot, järjestyksessä sovellettava lista, ja jonopuu, rajapintoihin tai palomuurin mangle-toiminnon pakettimerkkeihin kiinnitetty hierarkia (MikroTik-dokumentaatio — Queues).

Ero ratkaisee, kuinka pitkälle suunnittelusi skaalautuu. Yksinkertainen jono vastaa kysymykseen “rajoita tämä asiakas 50 Mbps:iin.” Jonopuu vastaa kysymykseen “tätä 500 Mbps:n uplinkkiä jakaa 300 tilaajaa, VoIP menee ensin, kukaan ei näänny ja raskaat lataajat eivät pilaa iltaa.” Jokainen ISP tarvitsee lopulta jälkimmäisen vastauksen.

Vaihe 1 — Rajoita yhtä asiakasta yksinkertaisella jonolla

Yksinkertaiset jonot ovat lyhin tie ongelmasta korjaukseen. Kohdista IP-osoitteeseen, aliverkkoon tai rajapintaan, aseta katto, ja olet valmis:

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

max-limit kirjoitetaan muodossa upload/download reitittimen näkökulmasta. Säännöt arvioidaan järjestyksessä ja ensimmäinen osuma voittaa — joten aikainen laaja sääntö nielaisee hiljaa ne tarkat, jotka lisäät myöhemmin. Tämä järjestys on yleisin syy siihen, että “toimiva” jono lakkaa toimimasta, kun joku lisää säännön sen yläpuolelle (MikroTik-dokumentaatio — Queues).

Yksinkertaiset jonot yhdistyvät myös tilaajan todennukseen: PPPoE-profiilin rate-limit-kenttä luo dynaamisen yksinkertaisen jonon istuntoa kohden, joten tilaukset seuraavat käyttäjää eivätkä IP-osoitetta. MikroTik PPPoE-palvelinoppaamme ISP:ille kattaa profiilipuolen.

Vaihe 2 — Merkitse liikenne palomuurin manglella

Jonopuu ei näe “VoIPia” tai “asiakasta 101”; se näkee pakettimerkinnät. Luo ne manglessa merkitsemällä ensin yhteys ja sitten paketit, mikä on halvempaa kuin jokaisen paketin uudelleentarkastus:

/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

Pidä merkintätaksonomia pienenä ja vakaana. Merkinnät ovat sanasto, jota jonosi puhuvat, ja kun laivastossa on kolme sukupolvea satunnaisia merkintänimiä, kukaan ei osaa sanoa, mikä reititin pakottaa mitäkin käytäntöä. Tässä MKControllerin kokoonpanoauditointi ja historia ansaitsevat paikkansa: näet jokaisen reitittimen mangle- ja jonotilan, vertaat sitä aiottuun käytäntöön ja työnnät korjatut säännöt koko laivastoon sen sijaan, että avaisit kolmekymmentä Winbox-istuntoa löytääksesi sen yhden laitteen, joka ei koskaan saanut muutosta.

Vaihe 3 — Rakenna jonopuun hierarkia

Jonopuulla on yksi parent, joka pitää linkin todellista kapasiteettia, ja lapset, jotka jakavat sen:

/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

Kolme kenttää tekee työn. limit-at on takuu, jonka lapsi saa silloinkin, kun linkki on kyllästetty. max-limit on katto, jonka se voi saavuttaa, kun kapasiteettia on vapaana. priority — 1 on korkein, 8 matalin — päättää, mikä lapsi saa ylijäämät ensin, ja pätee vain limit-at- ja max-limit-arvojen välillä (MikroTik-dokumentaatio — Queues). Aseta parentin max-limit siihen, mitä linkki todella toimittaa, ei siihen mitä sopimus sanoo, tai jonosta ei koskaan tule pullonkaulaa eikä se muokkaa mitään.

Vaihe 4 — Lisää PCQ tasajakoa varten

Per Connection Queue (PCQ) on syy siihen, miksi MikroTik skaalautuu tilaajamääriin, jotka tekevät käyttäjäkohtaisesta jonolistasta hallitsemattoman. PCQ-jonotyyppi luokittelee liikenteen osoitekentän mukaan ja luo dynaamisen alijonon jokaiselle erilliselle arvolle soveltaen samaa nopeutta kuhunkin (MikroTik-dokumentaatio — 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

Liitä pcq-down sen lapsen queue-arvoksi, joka kantaa asiakkaiden latausliikennettä, niin jokainen asiakas saa jopa 20 Mbps automaattisesti jaettuna. Aseta pcq-rate=0, niin PCQ jakaa parentin kaistan tasan kaikkien aktiivisten kesken — klassinen “kukaan ei näänny” -kokoonpano. Yksi jonotyyppi korvaa satoja käsin kirjoitettuja merkintöjä.

Sama tasoittava logiikka pätee jaettuun WiFiin: tilauksen nopeusrajoitus ja PCQ-parent yhdessä estävät yhtä vierasta kuluttamasta koko toimipaikan uplinkkiä — katso tunnistepuoli MikroTik HotSpot-kuponkioppaastamme.

Vaihe 5 — Säädä limit-at, max-limit, burst ja priority

Useimmiten rikkinäinen QoS ei ole väärä työkalu, vaan väärät luvut. Pidä jokaisen lapsen limit-at-arvojen summa parentin max-limit-arvossa tai sen alla; jos takuut ylimyyvät linkin, HTB ei voi kunnioittaa niitä ja prioriteetit lakkaavat käyttäytymästä odotetusti. Varaa priority=1 viiveherkälle liikenteelle — VoIP, pelaaminen, DNS — ja anna massasiirtojen elää arvolla 8 anteliaan katon kanssa.

Burst ansaitsee varoituksen. burst-limit, burst-threshold ja burst-time antavat asiakkaan ylittää max-limit-arvon hetkellisesti keskiarvon pysyessä matalana — mainiota nopeustesteihin, huonompaa ylimyydylle linkille. Mittaa komennolla /queue simple print stats tai jonopuun laskureilla, kun linkki on kuormituksessa, ei kello 3 yöllä kun kaikki on jouten. Jos laskureiden lukeminen huipputunnilla ei ole käytännöllistä, MKControllerin Internet Link -näkymä pitää saman kuvan jatkuvasti — käyttöaste suhteessa sovittuun nopeuteen; viive keskiarvona, maksimina ja P95-arvona; ja kuinka monta tuntia kukin linkki vietti yli 90 %:n — joten säädät historiaa vasten, et onnekasta hetkeä vasten.

Kapasiteetti myös liikkuu. Kahden WAN-yhteyden vikasietoisessa kokoonpanossa parentin max-limit, jonka viritit kuidulle, on fiktiota sillä hetkellä, kun liikenne siirtyy LTE-varayhteyteen — suunnittele toinen käytäntö.

Vaihe 6 — Ota käytäntö käyttöön koko laivastossa

Yksi reititin on kokoonpano; sata reititintä on operaatio. Käytännön on nyt oltava identtinen jokaisessa laitteessa, kestettävä teknikko, joka “väliaikaisesti” nosti asiakkaan kattoa, ja oltava palautettavissa, kun tornireititin netinstalloidaan. Mikään RouterOS:ssä ei tee sitä puolestasi.

MKController tekee: laivastonlaajuiset työnnöt jonotyypeistä, rate-limit-profiileista ja palomuurisäännöistä; kokoonpanohistoria, jotta näet milloin rajoitus muuttui ja palautat edellisen version yhdellä klikkauksella; automaattiset varmuuskopiot ennen muutosta; ja turvallinen ulospäin suuntautuva etäkäyttö reitittimiin CGNAT:n takana tai Starlinkissä, ilman julkista IP-osoitetta ja ilman porttiohjausta — lähestymistapa, jonka kuvaamme oppaassa MikroTikin etähallinta CGNAT:n takana. Ja sen Internet Link -valvonta tarkkailee juuri niitä uplinkkejä, jotka juuri muokkasit — lähdekohtainen käyttöaste suhteessa sovittuun nopeuteen, viive P95-arvolla ja kulutus, joka ylittää 75 %:n ja 90 %:n rajat jopa neljästä WAN-lähteestä reititintä kohden — joten saturaatiota kohti hiipivä linkki nousee esiin kojelaudalla ja (Telegram-hälytyksiin yhdistettynä) ilmoituksissasi ennen kuin tilaaja soittaa. ISP:t ja WISP:t, jotka ajavat MikroTikia mittakaavassa, käyttävät sitä, jotta kaistakäytäntö pysyy yhtenä päätöksenä eikä satana.

Vinkit

• Muokkaa siinä rajapinnassa, josta liikenne poistuu reitittimestä; jonot hallitsevat ulosmenevää liikennettä, joten lataukset muokataan LAN-puolella ja lähetykset WAN-puolella.
• Suosi yhtä PCQ-jonotyyppiä satojen yksinkertaisten jonojen sijaan, kun ylität muutaman kymmenen tilaajaa.
• passthrough=no mark-packet-säännöissä säästää turhalta jäljellä olevien mangle-sääntöjen läpikäynniltä.
• Ota aina varmuuskopio ennen kuin kosket jonoihin tuotannon reunalla, ja muuta yksi muuttuja kerrallaan.

Lopeta arvailu, minne kaistasi katosi

Jonot ovat ero tilauksen myymisen ja sen toimittamisen välillä. Yksinkertaiset jonot rajoittavat asiakasta, jonopuut antavat rakenteen ja prioriteetin, PCQ tekee oikeudenmukaisuudesta automaattista — ja MKController muuttaa kaikki kolme käytännöksi, jonka otat käyttöön kerran ja pakotat kaikkialla: keskitetty laivastonhallinta, rate-limit- ja palomuurityönnöt jokaiselle reitittimelle, kokoonpanohistoria yhden klikkauksen palautuksella, etäkäyttö ilman julkista IP-osoitetta ja Internet Link -valvonta, joka merkitsee sovittua nopeuttaan vasten kyllästyvän linkin ennen kuin asiakkaasi tekevät sen.

Aloita ilmainen MKController-kokeilu