Διαχείριση εύρους ζώνης MikroTik: Queues

Περίληψη Η διαχείριση εύρους ζώνης σε MikroTik στηρίζεται σε τρία εργαλεία: simple queues για έναν γρήγορο περιορισμό ανά πελάτη, queue trees για ιεραρχία και priority, και PCQ για δίκαιη κατανομή ανάμεσα σε πολλούς χρήστες χωρίς να δημιουργείτε ξεχωριστό queue για τον καθένα. Τα queue trees συνδυάζονται με firewall mangle marks και σας δίνουν εγγυήσεις, ανώτατα όρια και προτεραιότητες. Αυτός ο οδηγός δείχνει πότε να χρησιμοποιείτε το καθένα, τις εντολές RouterOS, και πώς να κρατάτε την ίδια πολιτική συνεπή σε έναν στόλο από routers.

Τι είναι η διαχείριση εύρους ζώνης σε MikroTik?

Η διαχείριση εύρους ζώνης σε MikroTik είναι η χρήση των queues του RouterOS για τον έλεγχο του πόσο μιας ζεύξης μπορεί να καταναλώνει κάθε πελάτης, υποδίκτυο ή κλάση κίνησης — περιορίζοντας τους ρυθμούς, εγγυώντας ελάχιστα, και αποφασίζοντας ποιος υποχωρεί όταν η ζεύξη γεμίσει. Το RouterOS υλοποιεί τα queues με έναν χρονοπρογραμματιστή Hierarchical Token Bucket (HTB), εκτεθειμένο σε δύο σημεία: τα simple queues, μια διατεταγμένη λίστα που εφαρμόζεται με τη σειρά, και το queue tree, μια ιεραρχία προσαρτημένη σε διεπαφές ή σε packet marks από τη λειτουργία mangle του τείχους προστασίας (Τεκμηρίωση MikroTik — Queues).

Η διάκριση καθορίζει πόσο θα κλιμακωθεί ο σχεδιασμός σας. Ένα simple queue απαντά «περιόρισε αυτόν τον πελάτη στα 50 Mbps». Ένα queue tree απαντά «αυτή η ζεύξη ανόδου των 500 Mbps μοιράζεται από 300 συνδρομητές, το VoIP προηγείται, κανείς δεν στερείται, και οι βαρείς downloaders δεν χαλάνε το βράδυ». Κάθε ISP χρειάζεται τελικά τη δεύτερη απάντηση.

Βήμα 1 — Περιορισμός ενός πελάτη με simple queue

Τα simple queues είναι η συντομότερη διαδρομή από το πρόβλημα στη λύση. Στοχεύστε μια IP, ένα υποδίκτυο ή μια διεπαφή, ορίστε το ανώτατο όριο, και τελειώσατε:

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

Το max-limit γράφεται ως upload/download από τη σκοπιά του router. Οι κανόνες αξιολογούνται με τη σειρά και ο πρώτος που ταιριάζει κερδίζει — έτσι ένας πρώιμος ευρύς κανόνας καταπίνει σιωπηλά τους πιο συγκεκριμένους που προσθέτετε αργότερα. Αυτή η σειρά είναι ο πιο συνηθισμένος λόγος που ένα «λειτουργικό» queue σταματά να λειτουργεί αφότου κάποιος προσθέσει έναν κανόνα από πάνω του (Τεκμηρίωση MikroTik — Queues).

Τα simple queues συνδυάζονται επίσης με την πιστοποίηση συνδρομητών: το πεδίο rate-limit ενός προφίλ PPPoE δημιουργεί ένα δυναμικό simple queue ανά συνεδρία, ώστε τα πλάνα να ακολουθούν τον χρήστη αντί για την IP. Ο οδηγός μας για τον PPPoE server MikroTik για ISP καλύπτει την πλευρά του προφίλ.

Βήμα 2 — Σήμανση κίνησης με firewall mangle

Το queue tree δεν μπορεί να δει «VoIP» ή «πελάτη 101»· βλέπει packet marks. Δημιουργήστε τα στο 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

Κρατήστε την ταξινομία των marks μικρή και σταθερή. Τα marks είναι το λεξιλόγιο που μιλούν τα queues σας, και μόλις ένας στόλος αποκτήσει τρεις γενιές αυτοσχέδιων ονομάτων mark, κανείς δεν μπορεί να πει ποιος router επιβάλλει ποια πολιτική. Εδώ είναι που ο έλεγχος και το ιστορικό ρυθμίσεων του MKController αποδεικνύει την αξία του: δείτε την κατάσταση mangle και queue κάθε router, συγκρίνετέ την με την επιδιωκόμενη πολιτική, και προωθήστε τους διορθωμένους κανόνες σε όλο τον στόλο αντί να ανοίγετε τριάντα συνεδρίες Winbox για να βρείτε το ένα κουτί που δεν έλαβε ποτέ την αλλαγή.

Βήμα 3 — Δόμηση της ιεραρχίας queue tree

Ένα queue tree έχει ένα parent που κρατά την πραγματική χωρητικότητα της ζεύξης, και παιδιά που τη διαιρούν:

/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 — Queues). Ορίστε το max-limit του parent σε αυτό που πραγματικά παραδίδει η ζεύξη, όχι σε αυτό που λέει το συμβόλαιο, αλλιώς το queue δεν γίνεται ποτέ το σημείο συμφόρησης και δεν διαμορφώνει τίποτα.

Βήμα 4 — Προσθήκη PCQ για δίκαιη κατανομή

Το Per Connection Queue (PCQ) είναι ο λόγος που το MikroTik κλιμακώνεται σε πλήθη συνδρομητών που καθιστούν μια λίστα queue ανά χρήστη μη διαχειρίσιμη. Ένας τύπος queue PCQ ταξινομεί την κίνηση βάσει ενός πεδίου διεύθυνσης και δημιουργεί ένα δυναμικό sub-queue για κάθε διακριτή τιμή, εφαρμόζοντας τον ίδιο ρυθμό στο καθένα (Τεκμηρίωση 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

Προσαρτήστε το pcq-down ως το queue του παιδιού που μεταφέρει την κίνηση download των πελατών, και κάθε πελάτης λαμβάνει έως 20 Mbps, κατανεμημένα αυτόματα. Ορίστε pcq-rate=0 και το PCQ διαιρεί το εύρος ζώνης του parent ισομερώς ανάμεσα σε όποιον είναι ενεργός — η κλασική διαμόρφωση «κανείς δεν στερείται». Ένας τύπος queue αντικαθιστά εκατοντάδες χειρόγραφες καταχωρήσεις.

Η ίδια λογική εξίσωσης ισχύει για το κοινόχρηστο WiFi: το όριο ταχύτητας του πλάνου και ένα parent PCQ μαζί εμποδίζουν έναν επισκέπτη να καταναλώσει τη ζεύξη ανόδου ενός χώρου — δείτε τον οδηγό μας για τη ρύθμιση κουπονιών MikroTik HotSpot για την πλευρά των διαπιστευτηρίων.

Βήμα 5 — Ρύθμιση των limit-at, max-limit, burst και priority

Το περισσότερο χαλασμένο QoS δεν είναι λάθος εργαλείο, είναι λάθος αριθμοί. Κρατήστε το άθροισμα του limit-at κάθε παιδιού ίσο ή κάτω από το max-limit του parent· αν οι εγγυήσεις υπερδεσμεύουν τη ζεύξη, το HTB δεν μπορεί να τις τηρήσει και οι προτεραιότητες σταματούν να συμπεριφέρονται όπως περιμένετε. Κρατήστε το priority=1 για κίνηση ευαίσθητη στην καθυστέρηση — VoIP, gaming, DNS — και αφήστε τις μαζικές μεταφορές να ζουν στο 8 με ένα γενναιόδωρο ανώτατο όριο.

Το burst αξίζει μια προειδοποίηση. Τα burst-limit, burst-threshold και burst-time επιτρέπουν σε έναν πελάτη να ξεπερνά για λίγο το max-limit ενώ ο μέσος όρος του παραμένει χαμηλός — εξαιρετικό για speed tests, χειρότερο για μια υπερδεσμευμένη ζεύξη. Μετρήστε με /queue simple print stats ή τους μετρητές του queue tree ενώ η ζεύξη είναι υπό φορτίο, όχι στις 3 τα ξημερώματα όταν όλα είναι αδρανή. Αν η ανάγνωση των μετρητών στην αιχμή δεν είναι πρακτική, η προβολή Internet Link του MKController κρατά την ίδια εικόνα συνεχώς — αξιοποίηση έναντι της συμβατικής ταχύτητας· καθυστέρηση ως μέσος όρος, μέγιστο και P95· και πόσες ώρες πέρασε κάθε ζεύξη πάνω από 90% — ώστε να ρυθμίζετε βάσει ιστορικού, όχι ενός τυχερού στιγμιότυπου.

Η χωρητικότητα επίσης μετακινείται. Σε μια διάταξη dual-WAN failover, το max-limit του parent που ρυθμίσατε για οπτική ίνα είναι μυθοπλασία τη στιγμή που η κίνηση προσγειώνεται στο εφεδρικό LTE — σχεδιάστε μια δεύτερη πολιτική.

Βήμα 6 — Ανάπτυξη της πολιτικής σε όλον τον στόλο

Ένας router είναι μια διαμόρφωση· εκατό routers είναι μια επιχείρηση. Η πολιτική πρέπει τώρα να είναι πανομοιότυπη σε κάθε κουτί, να επιβιώνει από τον τεχνικό που «προσωρινά» ανέβασε το ανώτατο όριο ενός πελάτη, και να είναι ανακτήσιμη όταν ένας router σε πυλώνα υποστεί netinstall. Τίποτα στο RouterOS δεν το κάνει αυτό για εσάς.

Το MKController το κάνει: προωθήσεις σε όλο τον στόλο για τύπους queue, προφίλ rate-limit και κανόνες τείχους προστασίας· ιστορικό ρυθμίσεων, ώστε να βλέπετε πότε άλλαξε ένα όριο και να επαναφέρετε την προηγούμενη έκδοση με ένα κλικ· αυτόματα αντίγραφα ασφαλείας πριν από μια αλλαγή· και ασφαλή εξερχόμενη απομακρυσμένη πρόσβαση σε routers πίσω από CGNAT ή σε Starlink, χωρίς δημόσια IP και χωρίς προώθηση θυρών — η προσέγγιση που περιγράφουμε στο απομακρυσμένη διαχείριση MikroTik πίσω από CGNAT. Και η παρακολούθηση Internet Link επιτηρεί ακριβώς τις ζεύξεις ανόδου που μόλις διαμορφώσατε — αξιοποίηση ανά πηγή έναντι της συμβατικής ταχύτητας, καθυστέρηση με P95, και κατανάλωση που διασχίζει τις ζώνες 75% και 90% σε έως τέσσερις πηγές WAN ανά router — ώστε μια ζεύξη που έρπει προς τον κορεσμό να εμφανίζεται στον πίνακα, και (σε συνδυασμό με ειδοποιήσεις Telegram) στις ειδοποιήσεις σας, πριν τηλεφωνήσει ένας συνδρομητής. Οι ISP και οι WISP που τρέχουν MikroTik σε κλίμακα το χρησιμοποιούν ώστε η πολιτική εύρους ζώνης να παραμένει μία απόφαση, όχι εκατό.

Συμβουλές

• Διαμορφώστε στη διεπαφή από την οποία η κίνηση φεύγει από τον router· τα queues ελέγχουν την έξοδο, οπότε τα downloads διαμορφώνονται στην πλευρά του LAN και τα uploads στην πλευρά του WAN.
• Προτιμήστε έναν τύπο queue PCQ έναντι εκατοντάδων simple queues μόλις ξεπεράσετε μερικές δεκάδες συνδρομητές.
• Το passthrough=no στους κανόνες mark-packet γλιτώνει την περιττή διάσχιση των υπόλοιπων κανόνων mangle.
• Πάντα να κρατάτε αντίγραφο ασφαλείας πριν αγγίξετε queues σε ένα παραγωγικό άκρο, και να αλλάζετε μία μεταβλητή τη φορά.

Σταματήστε να μαντεύετε πού πήγε το εύρος ζώνης σας

Τα queues είναι η διαφορά ανάμεσα στο να πουλάς ένα πλάνο και στο να το παραδίδεις. Τα simple queues περιορίζουν έναν πελάτη, τα queue trees δίνουν δομή και priority, το PCQ κάνει τη δικαιοσύνη αυτόματη — και το MKController μετατρέπει και τα τρία σε μια πολιτική που εφαρμόζετε μία φορά και επιβάλλετε παντού: κεντρική διαχείριση στόλου, προωθήσεις rate-limit και τείχους προστασίας σε κάθε router, ιστορικό ρυθμίσεων με επαναφορά ενός κλικ, απομακρυσμένη πρόσβαση χωρίς δημόσια IP, και παρακολούθηση Internet Link που επισημαίνει μια ζεύξη που κορεσμώνεται έναντι της συμβατικής της ταχύτητας πριν το κάνουν οι πελάτες σας.

Ξεκινήστε τη δωρεάν δοκιμή MKController