Χαίρεται. Έχω στο δίκτυο του σπιτιού ένα mikrotik που έχει το pppoe και τρέχει DHCP, Firewall σε μια 50Μ Cosmote. στο δίκτυο υπάρχουν 10 συσκευές PCs, smartphones, tablets είτε με Windows, είτε με android. Έχω δώσει στατική ΙΡ σε κάθε συσκεή και queue για κάθε συσκευή με μέγιστο 10Μ και σύνολο όλων των queues στα 50Μ.
Θα ήθελα να το κάνω λίγο καλύτερα ώστε στο κάθε queue άσχετα με το πόσο traffic υπαρχει, να δίνει προτεραιότητα στις εφαρμογές conference/voip (zoom, skype, eyeson etc) ενώ άλλες εφαρμογές (πχ Youtube, browsing) να έχουν χαμηλότερη προτεραιότητα. Άρα αν το queue που έχω για τον υπολογιστή μου (10Μ) έχει φτάσει στα όρια του, μόλις ανοίξω πχ skype να παίξει απρόσκοπτα και όλες οι υπόλοοιπες εφαρμογές να περιοριστούν λίγο.
πως μπορώ να το κάνω αυτό?
Εμφάνιση 1-3 από 3
-
12-11-20, 12:42 Προτεραιότητα σε εφαρμογές Conference/Voip #1
-
12-11-20, 13:20 Απάντηση: Προτεραιότητα σε εφαρμογές Conference/Voip #2
Δεν μπορείς.
Τουλάχιστον όχι με το mtik.
Αυτό που κάνεις δουλεύει γιατί μπορεί να κάνει classify το traffic αναλόγως host.
Για να το κάνει δυναμικά πρέπει να μπορεί το tik να αναγνωρίσει το traffic και αναλόγως να το ρίξει σε μια ουρά.
Στα non-encrypted πρωτόκολα γίνεται με βάση port/protocol/con. stream.
Στα encrypted δεν θα σου παίξει.
Και απ'όσο ξέρω zoom/skype/etc είναι όλα encrypted.
Μπορείς να δοκιμάσεις με L7 matcher στο routeros αλλά μην περιμένεις να κάνεις προκοπή.
Θα μπορούσες να δοκιμάσεις με ένα L7-aware firewall (που είναι over-kill για το σπίτι),
αλλά βασικά μάλλον θες περισσότερο bandwidth.
Το QoS/wan optimization στο skype είναι pain-in-the-***.Disclaimer:
Any views or opinions expressed represent the official view of the voices in my head.
-
12-11-20, 18:38 Απάντηση: Προτεραιότητα σε εφαρμογές Conference/Voip #3
Ας τα πάρουμε τα πράγματα με τη σειρά γιατί μερικές φορές αν έχεις ισχυρό κίνητρο ίσως αξίζει να ασχοληθείς και να έχεις και αποτέλεσμα (συνήθως όμως πρέπει να επενδύσεις χρόνο). Επειδή αποδεχόμαστε ότι το L7 identification είναι πλέον δύσκολο έως ακατόρθωτο μας μένει μόνο το L3-L4 identification όπως ορθώς αναφέρει ο K1m0n. Για κάθε επιθυμητή εφαρμογή που θέλεις να εφαρμόσεις QOS θα πρέπει να γνωρίζεις συνήθως όλες τις πιθανές destination IPs της κάθε υπηρεσίας, π.χ. το zoom μπορεί να μιλάει με 2-3 IPs στο cloud τους ή ακόμη και με 13 διαφορετικές (τυχαία νούμερα). Και μάλιστα μπορεί σε ανύποπτη στιγμή να αλλάξουν! Μια τακτική αντιμετώπισης αυτού του προβλήματος είναι η εξής:
1) Standard/official mode: Πρώτα, ψάχνουμε στο documentation της εκάστοτε εφαρμογής
Π.χ. η zoom μπορεί να λέει ότι οι media servers της είναι στο subnet 200.100.80.16/28 ή/και ότι τα audio connections του client ξεκινάνε πάντα με source port 50000-50100 (όλα τα νούμερα είναι τελείως τυχαία) ενώ τα βίντεο connections ξεκινάνε με 50200-50300. Σε αυτήν την περίπτωση είσαι τυχερός και μπορείς να φτιάξεις τα αντίστοιχα mangle rules για να μαρκάρεις τα connections και έπειτα τα πακέτα ώστε δώσεις κάποια προτεραιότητα στα queues και καθάρισες. (Ξανασχολείσαι μόνο αν συνειδητοποιήσεις κάποια στιγμή ότι στα queues δεν φτάνει traffic, άρα κάτι ξεφεύγει, άρα κάτι έχει αλλάξει στα παραγόμενα media πακέτα και ξαναμπαίνεις στο documentation να δεις μήπως έγινε κάποιο update).
2) Desperate mode: ψάχνουμε τα live connections
Μπορείς να κάνεις capture 5-10 κλήσεις με το wireshark ή να τις δεις live στο /ip firewall connections και να καταγράψεις με ποιες IP addresses μιλάει η εφαρμογή (ΓΙΑ MEDIA, δηλαδή ψάχνουμε patterns UDP κυρίως και αν δεν βρούμε UDP ψάχνουμε TCP connections, των 50-100pps σταθερά streams των 80-100kbps για audio, και 250kbps-1Mbps για βίντεο, συνήθως). Αν είσαι λίγο τυχερός μπορεί το 90-95% των κλήσεων (ή ακόμη και όλες) να πηγαίνουν σε συγκεκριμένες IPs, ας πούμε 2 με 3 συγκεκριμένες. Αν κρίνεις ότι έχεις πιάσει την μερίδα του λέοντος με τη «στατιστική ανάλυση» που έχεις κάνει, προχωράς πάλι στη δημιουργία των ανάλογων mangle rules κλπ.
Προσωπικά, προτού παραθέσω το config μου -- για το οποίο είναι ευπρόσδεκτο το οποιοδήποτε σχόλιο μιας και ασχολούμαι με Mikrotik QOS μόλις εδώ και 3 μήνες, ενώ με Cisco έχω εμπειρία ετών – να αναφέρω ότι πάντα κάνω μόνο outgoing queueing και ποτέ incoming. Το incoming το θεωρώ λίγο abusive και πολλές φορές μη αποδοτικό και μη προβλέψιμο, αλλά φυσικά οι απόψεις μπορεί να διίστανται.
To παρακάτω config φτιάχνει 1 parent queue των 10Mbps και 4 children queues για τις αντίστοιχες κατηγορίες εφαρμογών.
Κώδικας:/ip firewall address-list add address=195.x.y.a list=CiscoJabber add address=195.x.y.b list=CiscoJabber add address=94.143.176.220 list=wificallingCosmote add address=94.143.178.220 list=wificallingCosmote add address=94.143.177.210 list=wificallingCosmote /ip firewall mangle add action=mark-connection chain=forward comment="REMOTE Remote_con" dst-address=195.x.y.z \ new-connection-mark=REMOTE_con passthrough=yes add action=mark-connection chain=forward comment="HTPC Remote_con" new-connection-mark=REMOTE_con passthrough=yes \ protocol=tcp src-address=192.168.1.121 src-port=3389 add action=mark-packet chain=forward connection-mark=REMOTE_con new-packet-mark=REMOTE passthrough=no add action=mark-connection chain=forward comment="VOICE Teams_con" new-connection-mark=SIP_con passthrough=\ yes protocol=udp src-port=50000-50019 add action=mark-connection chain=forward comment=CiscoJabber_con dst-address-list=CiscoJabber new-connection-mark=SIP_con \ passthrough=yes protocol=udp add action=mark-connection chain=forward comment=wifi_call_con dst-address-list=wificallingCosmote new-connection-mark=SIP_con \ passthrough=yes protocol=udp add action=mark-packet chain=forward connection-mark=SIP_con new-packet-mark=VOICE passthrough=no add action=mark-connection chain=forward comment="VIDEO Teams_VID" new-connection-mark=VIDEO_con passthrough=\ yes protocol=udp src-port=50020-50039 add action=mark-packet chain=forward connection-mark=VIDEO_con new-packet-mark=VIDEO passthrough=no /queue tree add max-limit=10M name=UPLOAD parent=pppoe-out1 add comment=teams-jabber-wificall limit-at=500k max-limit=2M name=voice packet-mark=VOICE parent=UPLOAD priority=1 add limit-at=3M max-limit=10M name=remote packet-mark=REMOTE parent=UPLOAD priority=3 add limit-at=3M max-limit=10M name=video packet-mark=VIDEO parent=UPLOAD priority=4 add limit-at=3500k max-limit=10M name=rest packet-mark=no-mark parent=UPLOAD
ξέχασα να γράψω ότι το άθροισμα όλων των limit-at (μπορείς να το μεταφράσεις και ως minimum-limit) των children queues θα πρέπει βάσει λογικής να είναι όσο το συνολικό parent queue, ώστε σε συνθήκες congestion όλα τα queues να πιάσουν την limit-at τιμή. Σε συνθήκες non-congestion το κάθε queue μπορεί να πιάσει έως και το max-limit εάν υπάρχει το διαθέσιμο bandwidth.Τελευταία επεξεργασία από το μέλος eliasbats : 12-11-20 στις 19:19. Αιτία: EDIT2: έσβησα ότι είχα γράψει για IPv6
Bookmarks