Mikrotik QoS για IPv4/IPv6

[RyDeR]

Με το QoS τι γίνεται τελικά;

[deniSun]

Με το QoS τι γίνεται τελικά;

Σαν τι να γίνεται;

[RyDeR]

Ανέβηκε καπου; Ειναι κρυφό;

[deniSun]

Από την αρχή του παρόντος έχουν προταθεί πολλά.
Διάλεξε και πάρε.

[dimangelid]

Από την αρχή του παρόντος έχουν προταθεί πολλά.
Διάλεξε και πάρε.

Αναφέρεται προφανώς στο νέο QoS που λες ότι εφαρμόζεις και δεν το έχει δει κανείς.

[deniSun]

[puntomania]

ντάξει στην τελική κανείς δεν είναι υποχρεωμένος... να ανεβάσει το δημιούργημα του, άμα ο deni ήθελε... θα το είχε βάλει... οπότε μην σκάτε!!!

[dimangelid]

Οι ρυθμίσεις;

- - - Updated - - -

ντάξει στην τελική κανείς δεν είναι υποχρεωμένος... να ανεβάσει το δημιούργημα του, άμα ο deni ήθελε... θα το είχε βάλει... οπότε μην σκάτε!!!

Φυσικά δεν είναι υποχρεωμένος κάποιος Αλλά όταν γράφει συνέχεια για το δημιούργημά του και δεν το βλέπουμε, χτυπάει κάπως.

[puntomania]

Οι ρυθμίσεις;

- - - Updated - - -



Φυσικά δεν είναι υποχρεωμένος κάποιος Αλλά όταν γράφει συνέχεια για το δημιούργημά του και δεν το βλέπουμε, χτυπάει κάπως.

κοίτα... μπορεί να το παρέχει ως υπηρεσία... δεν το ξέρουμε αυτό... από την άλλη όμως... και έτοιμο να μας το δώσει... στους περισσότερους μας.. δεν θα δουλέψει έτσι απλά... γιατί ο καθένας μας έχει και διαφορικό setup στα υπόλοιπα... οπότε και πάλι θα πρέπει να ασχοληθούμε.

άρα κατά την άποψή μου... ένας άσχετος.. δε νομίζω ότι θα μπορέσει να το κάνει κάτι.


οπότε deni...

[deniSun]

Οι ρυθμίσεις;

- - - Updated - - -



Φυσικά δεν είναι υποχρεωμένος κάποιος Αλλά όταν γράφει συνέχεια για το δημιούργημά του και δεν το βλέπουμε, χτυπάει κάπως.

Γι αυτό σταμάτησα να γράφω.
Για να μην σας εγείρω την φαντασία.
Σου έδειξα όμως το αποτέλεσμα.
Οπότε... ότι θέλει ας φανταστεί ο κάθε ένας.

[teodor_ch]

Χωρίς drop πακέτα (ειδικά στο upload) σίγουρα δε δουλεύει οπότε μή σκάτε

[macro]

Αφου το εχει ποσταρει πιο πισω.

[deniSun]

Χωρίς drop πακέτα (ειδικά στο upload) σίγουρα δε δουλεύει οπότε μή σκάτε

Photoshopια... τι περίμενες.

[deniSun]

Χρόνια πολλά στις/στους εορτάζουσες/ντες και καλή συνέχεια στις διακοπές σας.
Μπαίνω απευθείας στο ψητό.
Θα ήθελα αναφερθώ στο θέμα του QoS (φυσικά).
Όπως καταλαβαίνει κάποιος διαβάζοντας το παρόν θέμα, έχουν γίνει πολλές συζητήσεις για διάφορα θέματα που δεν έχουν καταλήξει πουθενά και πιστεύω ότι απλά μπέρδεψαν τους περισσότερους μιας και δεν έβγαινε κανένα απολύτως συμπέρασμα παρά μόνο φασαρία γινόταν.
Αποφάσισα λοιπόν όπως καταλάβατε να μην ξανα-ποστάρω έτοιμη λύση (τα συμπεράσματα δικά σας).

Θα αναφερθώ λοιπόν μόνο σε γενικές οδηγίες για κάποιον που θέλει να στήσει ένα σωστό και αποδοτικό QoS.
Ας ξεκινήσουμε από τα, υποτίθεται, αυτονόητα.
Σωστό QoS είναι αυτό που θα μπορεί να διαμοιράσει το BW στους χρήστες ανάλογα με τις προτεραιότητες που του δίνουμε.
Αυτό θα πρέπει να το κάνει με κάποια δικαιοσύνη.
Δικαιοσύνη θα πει ότι αν έχουμε πχ 50Μ στο dw και στις προτεραιότητες έχουμε δώσει υψηλότερη στα dw μέσω ftp και λιγότερη στα torrent, τότε θα μπορεί να πάρει τα 40Μ το ftp και τα 10Μ τα torrent.
Δεν θα μηδενίσει δηλαδή τα torrent ώστε να δώσει όλο το BW στο ftp.
Αποδοτικό θα πει ότι θα μπορεί να κάνει όλη την παραπάνω δουλειά με τους λιγότερους πόρους (μνήμη + cpu load).

Ξεκινάμε από τις προτεραιότητες.
Οι προτεραιότητες ορίζονται από 1-8.

Το πρώτο που πρέπει να κάνουμε είναι να πιάνουμε σωστά όλο το BW.
Όλο το BW δεν μπορούμε να το πιάσουμε, τουλάχιστον όχι όπως το θα το θέλαμε.
Υπάρχουν εφαρμογές πχ skype, teamviewer όπου η κίνησή τους, πλέον, είναι πολύ δύσκολη να εντοπιστεί (οι υποδείξεις που υπάρχουν εκεί έξω απλά δεν λειτουργούν).
Αρκούμαστε λοιπόν σε ένα ποσοστό 90-99% (ανάλογα με τις εφαρμογές μας).
Το «σωστά» που ανέφερα αφορά στο να δηλώσουμε με προσοχή τους κανόνες που θέλουμε πχ την κίνηση web στο 4, που δεν ενδεχομένως να θέλαμε, και όχι στο 5, που μπορεί να την βάλουμε εκ παραδρομής.
Τα παραπάνω γίνονται στα mangle.
Θα πρέπει να βάλουμε τους ίδιους κανόνες και για ν6 εφόσον το χρησιμοποιούμε.
Μια ιεραρχία που χρησιμοποιώ εγώ είναι:
1: VoIP
2: icmp, ntp, dns
3: ack
4: small www
5: big www
7: all others
8: torrents
Το δεύτερο μέρος έχει να κάνει με το σημείο που πρέπει να πιάσουμε την κίνηση.
Πολλοί προτείνουν να πιάνεται η κίνηση στο forward μόνο, άλλοι μόνο στο prerouting και άλλοι στο prerouting και στο postrouting.
Χρησιμοποίησα και τους τρεις τρόπους αλλά σας διαβεβαιώνω ότι δεν είδα καμία διαφορά στην απόδοση.
Στην πράξη πλέον χρησιμοποιώ την τρίτη μέθοδο.
Επειδή με τον τρόπο αυτόν όμως έχουμε πολύ υψηλή κατανάλωση cpu (οι περισσότεροι αν όχι όλοι προτείνουν μόνο mark packets) έχω να σας πω ότι το καλύτερο που πρέπει να κάνετε για την απόδοση που λέγαμε παραπάνω είναι κάνετε τις δηλώσεις ως εξής:
1. mark-connection, prerouting, port, protocol, passthrough=yes, in-interface, new-connection-mark
2. mark-packet, prerouting, connection-mark, new-packet-mark, passthrough=no
3. mark-connection, postrouting, port, protocol, passthrough=yes, out-interface, new-connection-mark
4. mark-packet, postoruting, connection-mark, new-packet-mark, passthrough=no
Υπάρχουν βέβαια και περιπτώσεις όπως δεν πρέπει να κάνουμε μαρκάρισμα σύνδεσης πχ icmp κλπ.

Αφού λοιπόν είμαστε σίγουρα για το ότι πιάνουμε ότι θέλουμε και όπως το θέλουμε και μάλιστα σωστά (πρέπει να γίνουν δοκιμές για να είστε σίγουροι) προχωράμε στον ορισμό των ουρών.
Μπορούμε να έχουμε λοιπόν είτε simple ουρές είτε trees.
Πλέον χρησιμοποιώ trees γιατί με βοηθάει περισσότερο η απεικόνιση.
Στην πράξη δεν είδα καμία διαφορά στην απόδοση με τα simples.
Στα trees λοιπόν θα πρέπει να διαχωρίσουμε την εισερχόμενη και την εξερχόμενη κίνηση.
Η ιεραρχία βασίζεται στο HTB (δεν θα πω περισσότερα γι αυτό).
Θα έχουμε λοιπόν ξεχωριστή ιεραρχία για εισερχόμενη και ξεχωριστή για εξερχόμενη κίνηση.
Οι κανόνες που θα αναφέρω ισχύουν και εξίσου και για τις δύο κατηγορίες.
Θα αναφερθώ λοιπόν μόνο στην μία πχ στο dw (αν και είναι φυσικό ότι το up ενδιαφέρει περισσότερο).

Κανόνας πρώτος: Η ιεραρχία χωρίζεται σε parent και childs.
Parent είναι η ουρά που από κάτω της κρέμονται άλλες ουρές (childs).
Ευνόητος είναι ο ορισμός για τα child.
Ένα parent μπορεί να έχει και από κάτω του άλλα parents.
Το τελευταίο είναι πολύ βολικό για όσους θέλουν να κάνουν bw control (πολλοί το θεωρούν απαραίτητο).
Στα παρακάτω θα αναφερθώ σε προτεραιότητες χωρίς bw control.

Κανόνας δεύτερος: Στα parent ορίζουμε μόνο max-limit (η πραγματική ταχύτητα της σύνδεσής μας πχ 50Μ).
Τα priority, limit-at, queue-type κλπ δεν παίζουν κανένα ρόλο ακόμα και αν ένα parent έχει από πάνω του άλλο parent.

Κανόνας τρίτος: Για κάθε child ορίζουμε τα priority που θέλουμε από 1-8 (1 η υψηλότερη).
Ορίζουμε επίσης τα max-limit (MIR) και limit-at (CIR).
Εφόσον δεν θέλουμε να κάνουμε BW control τα MIR θα είναι σε όλα τα childs ίδια πχ 50Μ.
Τα CIR θα πρέπει να ακολουθούν τον κανόνα MIR (parent) = CIR (child-1) + CIR (child-2) + ...
Εφόσον έχουμε λοιπόν ένα μόνο parent, αυτό της κύριας σύνδεσής μας, το άθροισμα όλων των CIR θα πρέπει να είναι 50Μ.
Δεν θα παίξουμε καθόλου με bucket οπότε και το μηδενίζουμε (από default έχει τιμή).

Ποιον κανόνα λοιπόν ακολουθούμε για να κατανέμουμε τις τιμές των CIR;
Δεν υπάρχει κάποιος κανόνας ούτε κάποιος αλγόριθμος.
Θα σας αναφέρω μόνο τον δικό μου τρόπο και αν θέλετε τον εφαρμόζετε.
Στο ROS έχουμε τρεις καταστάσεις στις ουρές που απεικονίζονται ανάλογα με χρωματισμούς green, yellow, red.
Εδώ θέλει πολύ προσοχή γιατί το state αυτό είναι ανώτερο των priority που ορίζουμε (θα το εξηγήσω παρακάτω).
Green έχουμε όταν οι αιτήσεις μιας ουράς είναι <=CIR της ουράς
Yellow έχουμε όταν οι αιτήσεις είναι >CIR και <=MIR
Red έχουμε όταν οι αιτήσεις είναι >=MIR
Έστω λοιπόν ότι έχουμε δύο ουρές την 1 και την 7.
Αν και οι δύο είναι στο ίδιο state θα εξυπηρετηθούν ανάλογα με το priority που έχουν πχ πρώτα η 1 και μετά η 7.
Αν η 1 είναι σε μεγαλύτερο state από την 7 πχ η 1 σε yellow και η 7 σε green τότε θα εξυπηρετηθεί πρώτα η 7 και μετά η 1.
Αν έχουμε ουρές στο ίδιο state με την ίδια priority τότε εφαρμόζεται σε αυτές ο round robin στο θέμα της προτεραιότητας.
Άρα γίνεται αντιληπτό ότι θα πρέπει να δώσουμε τέτοιες τιμές στα CIR άμεσης προτεραιότητας πχ στις ουρές με τα voip, dns κλπ ώστε πάντα να είναι σε state green.
Έτσι πάντα θα εξυπηρετούνται κατά άμεση προτεραιότητα.
Αυτό μπορεί να γίνει αν μετρήσουμε το BW μια ουράς και να δώσουμε στο CIR της μια μεγαλύτερη τιμή.
Πχ αν στο voip παίζουμε με 250Κ μπορούμε να ορίσουμε 500Κ στο limit-at ώστε να είμαστε σίγουροι ότι πάντα θα είναι στο green.
Ανάλογα λοιπόν θέτουμε τις τιμές σε όλες τις ουρές σύμφωνα με τις ανάγκες μας.

Κανόνας τέταρτος: Ένας βασικός παράγοντας είναι ο τύπος της ουράς.
Και εδώ γίνεται ένα μπάχαλο.
Δεν θα αναφερθώ στο τι κάνει και που χρησιμοποιείται κάθε τύπος ουράς.
Θα πω μόνο ότι εγώ χρησιμοποιώ σε όλες pcq.
Η υλοποίηση που τρέχω είναι χωρίς burst γιατί πλέον με το στήσιμο που έχω δεν το χρειάζομαι.
Ορίζουμε λοιπόν τιμές για το pcq-total-limit και pcq-limit.
Το rate το αφήνω 0 ώστε να έχω καλύτερη χρήση του BW.
Το pcq-limit είναι στην ουσία το buffer μου (το μέγιστο μέγεθος στις αιτήσεις).
Το pcq-total-limit είναι το συνολικό μέγεθος όλως των pcq-limit πχ 50Μ αφού δεν έχω BW control.

Και πόσο λοιπόν ορίζουμε το pcq-limit;
Δεν υπάρχει απάντηση.
Οι ουρές χωρίζονται σε schedulers και shapers.
Η PCQ κάνει και τα δύο.
Αν αυξήσουμε το μέγεθος του buffer θα έχουμε λιγότερα drops αλλά μεγάλο latency.
Αν το μειώσουμε το αντίστροφο.
Και εδώ υπάρχει σύγχυση.
Το να έχω drop packets δεν είναι απαγορευτικό.
Κυρίως στο UP δεν θα με δημιουργούσε πρόβλημα.
Φυσικά και πάλι πρέπει να γίνουν μετρήσεις πχ τι καθυστέρηση θα έχω με μεγάλο buffer και τι με μικρό και drop.
Εξαρτάται φυσικά και από την εφαρμογή.
Μια καθυστέρηση στο voip θα σήμαινε καθυστέρηση στην μετάδοση του ήχου, ενώ ένα drop σπασίματα στην φωνή.
Με το TCP δεν θα είχαμε τέτοια προβλήματα παρά μόνο καθυστερήσεις.
Καλό είναι λοιπόν για κάθε ουρά στο up/dw να ορίσετε ξεχωριστές ουρές ακόμα και αν έχετε ίδιες τιμές σε αυτές (αργότερα μπορεί να χρειάζεται να κάνετε τροποποιήσεις).
Το να ορίσεις ένα μεγάλο buffer σε μια ουρά με υψηλή προτεραιότητα που έχει μικρή κίνηση δεν θα δημιουργούσε πρόβλημα.
Πολύ απλά γιατί στην ουρά αυτή δεν θα γέμιζε ποτέ, πολύ, ο buffer και άρα δεν θα είχες καθυστερήσεις.
Αν όλα λοιπόν πάνε καλά θα πρέπει να δείτε ταυτόχρονα 0-drops και +2-3ms επιβάρυνση στα latency.

Τελευταίος κανόνας είναι να ορίσετε σωστά το classifier των pcq.
Οι περισσότεροι αν όχι όλοι προτείνουν μόνο τον ορισμό του address.
Τι σημαίνει αυτό;
Ότι αν έχεις μια κίνηση ftp από τον .33 ΗΥ αυτή θα πάρει όλο το bw που χρειάζεται πχ 50Μ.
Και αν στην ίδια ουρά έχουμε και κίνηση πχ web τότε και αυτή θα προσπαθήσει να πάρει μέρος από τα 50Μ αλλά πολύ απλά θα μπει στον buffer και θα περιμένει.
Πολύ απλά αυτό σημαίνει ότι σε ουρές που έχουμε πολλές πόρτες, τότε στην πράξη το περισσότερο BW θα πάρει η πόρτα με την πιο επιθετική συμπεριφορά (οι πιο γρήγορες πχ το ftp έναντι του web).
Τι μπορούμε λοιπόν να κάνουμε;
Για να είμαστε λοιπόν δίκαιοι μπορούμε μαζί με το address να ορίσουμε και το port.
Τώρα αντί να πάρει πχ 45Μ το ftp και 5Μ το web, θα πάρει 25Μ το ένα και 25Μ το άλλο στον ίδιο μάλιστα ΗΥ.
Τι θα πει αυτό στην πράξη;
Ότι αν βάλετε για κατέβασμα 5 αρχεία ταυτόχρονα θα πρέπει να δείτε σε αυτά εξίσου 50/5=10Μ.

Και αν εφαρμόσετε όλα τα παραπάνω θα μπορείτε να δείτε ότι να κατεβάζετε με την ίδια ταχύτητα πχ 5 αρχεία, να κατεβάζετε torrent με μικρότερη ταχύτητα (λόγω προτεραιότητας), να ανοίγετε ταυτόχρονα 10 tabs σαν να μην τρέχει τίποτε και να κάνετε traceroute βλέποντας μια μικρή αύξηση της τάξης των 2-3ms.
Όλα αυτά με 0-drops.

Ελπίζω να μην ξέχασα κάτι.

Καλές βουτιές...

ΥΓ
Δεν ανεβάζω screenshots για τους λόγους που ανέφερα.

[deniSun]

Κάνοντας διάφορες δοκιμές παρατήρησα κάτι πολύ περίεργο.
Περίεργο γιατί δεν το έχω δει να αναφέρεται πουθενά ως προϋπόθεση.

Έχω ένα QoS σε tree όπου παίζω μόνο με UP.
Τα mangles είναι μόνο σε επίπεδο postrouting και αφορούν μόνο την εξερχόμενη κίνηση.
Όλα δουλεύουν κανονικά σχετικά με το πιάσιμο της κίνησης.

Χρησιμοποιώντας τα παραπάνω έχω πολύ αργούς χρόνους στις δοκιμές μου.
πχ ανοίγω ταυτόχρονα ~20tabs διάφορου περιεχομένου, με καθαρή cache και dns cache κλπ
και ο μέσος χρόνος που έχω είναι ~30-40s.

Το παραπάνω παρατηρείται και αφήνοντας μόνο το mangle της κίνησης web.
Απλά για να δω αν φταίει κάτι στα mangle αν και όπως είπα είναι ελεγμένο με διάφορα setup (αλλά μυαλό είναι... υπάρχει πάντα η πιθανότητα να ξεφύγει κάτι).

Προσθέτω τώρα στο tree μια ουρά για την εισερχόμενη κίνηση.
Και προσθέτω και ανάλογο mangle για να πιάνω όλο το dw με ένα mangle.
Αν αφήσω μόνο το mangle για πακέτα έχω τα ίδια αποτελέσματα από πάνω.
Αν κάνω ένα mangle για connections τότε ως θαύμα όλα δουλεύουν άψογα.
Οι χρόνοι της δοκιμής πέφτουν στα ~10s.
Αν έχω και connections και packet στο mangle για dw έχω πάλι τους σωστούς χρόνους των ~10s.

Άρα...
Υπάρχει κάπου ότι για να δουλέψει σωστά το tree θα πρέπει να κάνω mangle και το up και το dw;

Και τα πιο περίεργα...
1. Αν στο connections προσθέσω no-mark στο connection-mark τότε παίρνω τους χάλια χρόνους.
2. Αν στο mark-connections προσθέσω ένα όνομα που δεν το κάνω τίποτε παρακάτω με μαρκάρισμα πακέτων, τότε δεν τρέχει τίποτε και παίρνω τους σωστούς χρόνους.
3. Αν κάνω disable στο tree την αντίστοιχη ουρά του dw, τότε και πάλι παίρνω τους σωστούς χρόνους.

Φαίνεται δηλαδή σαν το μόνο που θέλει είναι απλά ένα connection-mark για την εισερχόμενη κίνηση χωρίς να τον νοιάζει τίποτε άλλο.

Λέτε να είναι κάποιο bug;

Η αλήθεια είναι ότι δεν με ενοχλεί και τρομερά γιατί θέλω να μετράω την εξερχόμενη κίνηση.
Αλλά όπως και να το κάνεις είναι σπατάλη πόρων.