MikroTik sávszélesség-kezelés: sorok

Összefoglaló A MikroTik sávszélesség-kezelés három eszközön nyugszik: egyszerű sorok egy gyors, kliensenkénti korlátozáshoz, sorfák a hierarchiához és prioritáshoz, valamint PCQ a méltányos elosztáshoz sok felhasználó között anélkül, hogy mindegyikhez külön sort hoznál létre. A sorfák tűzfal mangle jelölésekkel párosulnak, és garanciákat, felső határokat és prioritásokat adnak. Ez az útmutató megmutatja, mikor melyiket használd, a RouterOS parancsokat, és hogyan tartsd ugyanazt a szabályzatot egységesen egy routerflotta egészén.

Mi a sávszélesség-kezelés MikroTikon?

A sávszélesség-kezelés MikroTikon a RouterOS sorok használata annak szabályozására, mennyit fogyaszthat egy kapcsolatból minden ügyfél, alhálózat vagy forgalmi osztály — a sebességek korlátozásával, a minimumok garantálásával, és annak eldöntésével, ki enged, amikor a kapcsolat megtelik. A RouterOS a sorokat egy Hierarchical Token Bucket (HTB) ütemezővel valósítja meg, amely két helyen érhető el: egyszerű sorok, egy sorrendben alkalmazott, rendezett lista, és a sorfa, egy interfészekhez vagy a tűzfal mangle szolgáltatásából származó csomagjelölésekhez kapcsolt hierarchia (MikroTik dokumentáció — Queues).

Ez a különbség dönti el, meddig skálázódik a terved. Egy egyszerű sor arra válaszol: „korlátozd ezt az ügyfelet 50 Mbps-re”. Egy sorfa arra válaszol: „ezt az 500 Mbps-os uplinket 300 előfizető osztja meg, a VoIP megy elsőként, senki nem éhezik, és a nagy letöltők nem teszik tönkre az estét”. Minden ISP-nek végül a második válaszra van szüksége.

1. lépés — Korlátozz egy klienst egyszerű sorral

Az egyszerű sorok a legrövidebb út a problémától a megoldásig. Célozz meg egy IP-t, egy alhálózatot vagy egy interfészt, állítsd be a felső határt, és kész is:

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

A max-limit a router szemszögéből upload/download formában van megadva. A szabályok sorrendben értékelődnek ki, és az első találat nyer — így egy korai, tág szabály csendben elnyeli a később hozzáadott konkrétabbakat. Ez a sorrend a leggyakoribb oka annak, hogy egy „működő” sor leáll, miután valaki fölé beszúr egy szabályt (MikroTik dokumentáció — Queues).

Az egyszerű sorok az előfizető-hitelesítéssel is párosulnak: egy PPPoE-profil rate-limit mezője munkamenetenként dinamikus egyszerű sort hoz létre, így a csomagok a felhasználót követik az IP helyett. ISP-knek szóló MikroTik PPPoE-szerver útmutatónk a profil oldalát tárgyalja.

2. lépés — Jelöld meg a forgalmat tűzfal mangle-lel

A sorfa nem látja a „VoIP”-ot vagy a „101-es ügyfelet”; csomagjelöléseket lát. Hozd létre őket a mangle-ben, előbb a kapcsolatot, majd a csomagokat jelölve, ami olcsóbb, mint minden csomagot újra megvizsgálni:

/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

Tartsd a jelölési taxonómiát kicsinek és stabilnak. A jelölések az a szókincs, amelyet a soraid beszélnek, és ha egy flottában már három generációnyi rögtönzött jelölésnév van, senki nem tudja megmondani, melyik router melyik szabályzatot kényszeríti ki. Itt bizonyít az MKController konfigurációs auditja és előzménye: láthatod minden router mangle- és sorállapotát, összevetheted a szándékolt szabályzattal, és flottaszinten kitolhatod a javított szabályokat, ahelyett hogy harminc Winbox-munkamenetet nyitnál meg, hogy megtaláld azt az egy dobozt, amely sosem kapta meg a változtatást.

3. lépés — Építsd fel a sorfa hierarchiát

Egy sorfának van egy szülője, amely a kapcsolat valódi kapacitását tartja, és gyerekei, amelyek felosztják azt:

/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

Három mező végzi a munkát. A limit-at az a garancia, amelyet egy gyerek akkor is megkap, ha a kapcsolat telített. A max-limit az a felső határ, amelyet elérhet, amikor van szabad kapacitás. A priority — az 1 a legmagasabb, a 8 a legalacsonyabb — dönti el, melyik gyerek kapja meg elsőként a maradékot, és csak a limit-at és a max-limit között érvényes (MikroTik dokumentáció — Queues). A szülő max-limit értékét arra állítsd, amit a kapcsolat ténylegesen szállít, ne arra, amit a szerződés mond, különben a sor sosem válik szűk keresztmetszetté, és sosem alakít semmit.

4. lépés — Adj hozzá PCQ-t a méltányos elosztáshoz

A Per Connection Queue (PCQ) az oka annak, hogy a MikroTik olyan előfizetőszámokra skálázódik, amelyeknél egy felhasználónkénti sorlista kezelhetetlenné válik. Egy PCQ sortípus egy címmező szerint osztályozza a forgalmat, és minden különböző értékhez dinamikus alsort hoz létre, mindegyikre ugyanazt a sebességet alkalmazva (MikroTik dokumentáció — 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

Csatold a pcq-down-t annak a gyereknek a queue beállításaként, amely az ügyfelek letöltési forgalmát hordozza, és minden ügyfél automatikusan kiosztva legfeljebb 20 Mbps-t kap. Állítsd be a pcq-rate=0 értéket, és a PCQ egyenlően osztja szét a szülő sávszélességét mindenki között, aki aktív — a klasszikus „senki nem éhezik” konfiguráció. Egy sortípus több száz kézzel írt bejegyzést vált ki.

Ugyanez a kiegyenlítő logika érvényes a megosztott WiFi-re: a csomag sebességkorlátja és egy PCQ-szülő együtt megakadályozza, hogy egyetlen vendég feleméssze egy helyszín uplinkjét — a hitelesítő adatok oldalához lásd MikroTik HotSpot-utalvány beállítási útmutatónkat.

5. lépés — Hangold a limit-at, max-limit, burst és priority értékeket

A legtöbb elromlott QoS nem rossz eszköz, hanem rossz számok kérdése. Tartsd minden gyerek limit-at értékének összegét a szülő max-limit értékén vagy az alatt; ha a garanciák túltöltik a kapcsolatot, a HTB nem tudja teljesíteni őket, és a prioritások nem úgy viselkednek, ahogy várnád. Tartsd fenn a priority=1 értéket a késleltetésre érzékeny forgalomnak — VoIP, játék, DNS —, a tömeges átviteleket pedig hagyd a 8-on, bőkezű felső határral.

A burst figyelmeztetést érdemel. A burst-limit, a burst-threshold és a burst-time lehetővé teszi, hogy egy kliens rövid időre túllépje a max-limit értéket, miközben az átlaga alacsony marad — remek a sebességtesztekhez, rosszabb egy túlterhelt kapcsolathoz. Mérj a /queue simple print stats paranccsal vagy a sorfa számlálóival, amíg a kapcsolat terhelés alatt van, ne hajnali 3-kor, amikor minden tétlen. Ha csúcsidőben olvasni a számlálókat nem praktikus, az MKController Internet Link nézete folyamatosan ugyanazt a képet tartja — kihasználtság a szerződött sebességhez képest; késleltetés átlagként, maximumként és P95-ként; és hogy hány órát töltött minden kapcsolat 90% felett —, így az előzményekhez hangolsz, nem egy szerencsés pillanatképhez.

A kapacitás is mozog. Egy kétWANos feladatátvételi beállításon a szülő max-limit értéke, amelyet optikára hangoltál, fikció abban a pillanatban, amikor a forgalom az LTE-tartalékra kerül — tervezz egy második szabályzatot.

6. lépés — Vezesd be a szabályzatot az egész flottán

Egy router egy konfiguráció; száz router egy üzemeltetés. A szabályzatnak most minden dobozon azonosnak kell lennie, túl kell élnie a technikust, aki „ideiglenesen” megemelte egy ügyfél felső határát, és helyreállíthatónak kell lennie, amikor egy toronyroutert netinstall-oznak. A RouterOS-ben semmi nem teszi ezt meg helyetted.

Az MKController megteszi: sortípusok, rate-limit profilok és tűzfalszabályok flottaszintű kitolása; konfigurációs előzmény, így láthatod, mikor változott egy korlát, és egy kattintással visszaállíthatod az előző verziót; automatikus mentések egy változtatás előtt; valamint biztonságos kimenő távoli hozzáférés a CGNAT mögötti vagy Starlinken lévő routerekhez, nyilvános IP és port-továbbítás nélkül — ezt a megközelítést írjuk le a MikroTik távoli kezelés CGNAT mögött útmutatóban. Az Internet Link monitorozása pedig pontosan azokat az uplinkeket figyeli, amelyeket az imént alakítottál — forrásonkénti kihasználtság a szerződött sebességhez képest, késleltetés P95-tel, és a 75%-os és 90%-os sávokat átlépő fogyasztás routerenként akár négy WAN-forráson keresztül —, így egy telítődés felé kúszó kapcsolat megjelenik a vezérlőpulton, és (Telegram-riasztásokkal párosítva) az értesítéseidben, mielőtt egy előfizető telefonálna. A MikroTikot nagy léptékben üzemeltető ISP-k és WISP-ek ezzel tartják a sávszélesség-szabályzatot egyetlen döntésnek, nem száznak.

Tippek

• Azon az interfészen alakíts, ahol a forgalom elhagyja a routert; a sorok a kimenő forgalmat szabályozzák, így a letöltéseket a LAN oldalon, a feltöltéseket a WAN oldalon alakítod.
• Részesítsd előnyben az egy PCQ sortípust több száz egyszerű sorral szemben, ha túllépsz néhány tucat előfizetőn.
• A passthrough=no a mark-packet szabályokon megspórolja a maradék mangle-szabályok felesleges bejárását.
• Éles peremhálózaton mindig ments, mielőtt sorokhoz nyúlsz, és egyszerre csak egy változót módosíts.

Ne találgasd, hová tűnt a sávszélességed

A sorok jelentik a különbséget egy csomag eladása és teljesítése között. Az egyszerű sorok korlátoznak egy klienst, a sorfák struktúrát és prioritást adnak, a PCQ automatikussá teszi a méltányosságot — az MKController pedig mindhármat olyan szabályzattá alakítja, amelyet egyszer alkalmazol, és mindenhol kikényszerítesz: központosított flottakezelés, rate-limit és tűzfal kitolása minden routerre, konfigurációs előzmény egykattintásos visszaállítással, távoli hozzáférés nyilvános IP nélkül, és Internet Link monitorozás, amely megjelöli, ha egy kapcsolat a szerződött sebességéhez képest telítődik, még mielőtt az ügyfeleid tennék.

Indítsd el ingyenes MKController-próbaidőszakodat