Καλησπέρα,
Προσπαθώ να ρυθμίσω ένα QoS σε Cisco 886w για μην κολλάει σε παιχνίδια όταν κατεβάζεις ή βλέπεις βίντεο. Η ρύθμιση που έχω κάνει είναι να φτιάξω μία access list 101 για τις διευθύνσεις που θέλω να έχουν προτεραιότητα. Το configuration που έχω κάνει είναι το παρακάτω:
Το πρόβλημα είναι ότι ενώ έχω matching μια χαρά όλα:Κώδικας:access-list 101 remark Important IP Connections for QoS access-list 101 permit ip any 159.153.0.0 0.0.255.255 access-list 101 permit ip any 212.205.126.0 0.0.0.255 access-list 101 permit ip any 37.244.0.0 0.0.63.255 access-list 101 permit ip any 185.60.0.0 0.0.255.255 access-list 101 permit ip any 178.79.0.0 0.0.255.255 access-list 101 permit ip any 24.105.0.0 0.0.255.255 class-map match-any HomeMap description Important Destinations match access-group 101 policy-map HomePolicy description Important Policy class HomeMap priority 5000 interface ATM0 description ATM Connection to ISP bandwidth 10000 backup delay 120 0 backup interface Dialer1 no ip address no atm ilmi-keepalive pvc 8/35 pppoe-client dial-pool-number 1 interface Dialer0 description ADSL link to ISP bandwidth 10000 ... service-policy output HomePolicy
Αν κατεβάσω τίποτα κολλάει ξανά. Δεν κάνει κάποια ιδιαίτερη διαφορά. Συνεχίζει να κολλάει και να έχει μεγάλο latency το παιχνίδι. Δοκίμασα και το bandwidth στο policy-map αντί του priority αλλά πάλι δεν έκανε τίποτα. Ίσως κάτι χάνω, γιατί τα Online Games θέλουν περισσότερο χαμηλό latency και όχι ιδιαίτερο bandwidth. Αν έχει κανένας καμία ιδέα.Κώδικας:router#show policy-map interface dialer 0 Dialer0 Service-policy output: HomePolicy queue stats for all priority classes: queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 Class-map: HomeMap (match-any) 50732 packets, 4808370 bytes 5 minute offered rate 5000 bps, drop rate 0 bps Match: access-group 101 50732 packets, 4808370 bytes 5 minute rate 5000 bps Priority: 5000 kbps, burst bytes 125000, b/w exceed drops: 0 Class-map: class-default (match-any) 4868566 packets, 408321444 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: any queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0
Επίσης να συμπληρώσω ότι τα tests μου τα έκανα κατεβάζοντας από το laptop που συνδέεται στο embedded wireless με wifi και το game είναι στο ethernet interface του router από desktop. Εφόσον το έβαλα στον dialer που περνάνε όλα θα πρέπει να είναι σωστό. Δεν ξέρω μήπως έπρεπε να το εφαρμόσω σε άλλο σημείο. Στο ATM πάντως δεν το παίρνει.
Εμφάνιση 1-9 από 9
Θέμα: QoS σε Cisco 886w
-
08-10-16, 19:07 QoS σε Cisco 886w #1
Τελευταία επεξεργασία από το μέλος boeotian : 08-10-16 στις 19:20.
-
09-10-16, 02:19 Απάντηση: QoS σε Cisco 886w #2
Το service policy το έχεις βάλεις προς τα έξω, συνεπώς, πιάνει το upload σου. Θεωρώντας ότι το παιχνίδι που παίζεις δεν χρειάζεται ιδιαίτερο bandwidth, θα έπαιζα με LLQ. Προσοχή όμως να μη βάλεις τον policer πολύ ψηλά γιατί μπορεί να έχεις προβλήματα στην υπόλοιπη κίνηση.
Για την εισερχόμενη κίνηση, οι επιλογές σου είναι πολύ πιο περιορισμένες. Το πιο εύκολο θα ήταν να φτιάξεις μια πολιτική που να πιάνει το ακριβώς αντίθετο και να το περιορίζει με policer αρκετά κάτω του μέγιστου ρυθμού που πιάνεις. Στην πράξω όμως πάλι υπάρχει πιθανότητα να έχεις πρόβλημα. Γενικά όταν παίρνεις τέτοιες αποφάσεις στο ingress, η αποτελεσματικότητά τους είναι περιορισμένη καθώς η πίεση που ασκείς είναι μετά το πραγματικό bottleneck ( τη γραμμή σου ). Μπορείς να θεωρήσεις ότι οι εφαρμογές θα συμπεριφέρονται καλά και θα αντιδρούν γρήγορα σε packet loss, ρίχνοντας το ρυθμό με τον οποίον στέλνουν δεδομένα σε εσένα. Στην πράξη δεν είναι απίθανο να έχεις μικρές περιόδους congestion ή ακόμα και εφαρμογές που αγνοούν τελείως το packet loss και θεωρούν ότι μπορούν να στείλουν σταθερά με ρυθμό που θα σου προκαλέσει congestion.In theory, practice is the same as theory.
In practice, it isn't.
-
09-10-16, 02:33 Απάντηση: QoS σε Cisco 886w #3
Το service-policy δεν το παίρνει διαφορετικά με input. Μόνο output δέχεται. Αν τώρα αυτό είναι όντως το upload και όχι γενικά το output του interface, τότε ναι δεν έκανα τίποτα, γιατί προφανώς το θέλω στο download. Ίσως και στο upload, αλλά το κύριο είναι το download συνήθως που έχει θέμα. Για LLQ που λες αυτό δεν έχω υλοποιήσει ήδη; Θέλει να ορίσω και το class-default σε fair-queue; Δεν είναι ήδη;
Αυτό που σκεφτόμουν θα ήταν να δοκιμάσω με ip precedence όπως παίζει και το voice. Να χαρακτηρίσω με 5 τα πακέτα που με ενδιαφέρουν να έχουν προτεραιότητα.
Αν κατάλαβα καλά, προτείνεις να κάνω το αντίθετο, δηλαδή να περιορίσω το youtube και download από συγκεκριμένα site. Το σκέφτηκα και αυτό, αλλά το να χαρακτηρίσεις τα destinations που σε ενδιαφέρουν είναι πιο εύκολο, από το να βάζεις κάθε φορά blacklist τα sites που σου τρώνε την γραμμή.
-
09-10-16, 13:40 Απάντηση: QoS σε Cisco 886w #4
Δε θα το πάρει με input γιατί δε μπορείς να κάνεις LLQ ( όπως και γενικά queueing ) στο input. Θα πρέπει να φτιάξεις διαφορετική πολιτική με policing.
To ip precedence δε θα κάνει κάτι.
Πρότεινα στο input να κάνεις το ανάποδο match στην ACL ( deny αυτά που σε ενδιαφέρουν και permit τα υπόλοιπα ). Επίσης θα πρέπει να γυρίσεις και source/destination ανάποδα.
Μπορείς αντί αυτού να προσπαθήσεις να κάνεις LLQ στο output του εσωτερικού σου interface με λίστα που απλά θα έχει γυρισμένα source/destination, αλλά εκεί θα πρέπει να φτιάξεις μια ιεραρχική πολιτική με έναν parent shaper που θα κάνει shape στο ρυθμό που μπορεί να κατεβάσει η dsl σου και ένα child policy για το LLQ. Πάλι ισχύουν αυτά που έγραψα παραπάνω σε σχέση με την αποτελεσματικότητα προφανώς.In theory, practice is the same as theory.
In practice, it isn't.
-
09-10-16, 18:12 Απάντηση: QoS σε Cisco 886w #5
Σε ευχαριστώ για την απάντησή σου. Όχι ότι κατάλαβα ιδιαίτερα τι προτείνεις. Θα βοηθούσε καμία παραπομπή να διαβάσω.
Τώρα για το input και output χρησιμοποιείται για το inbound και outbound traffic τελικά; Και πιο είναι αυτό σε εσωτερικά intefaces. Για παράδειγμα στην δικιά μου περίπτωση έχω:
Κώδικας:WAN <-> ATM0 <-> Dialer0 (Virtual-Access1 bound) <-> FastEthernetN (N=1-4) <-> Wired PC ^ \ -> Wlan-GigabitEthernet0 <-> GigabitEthernet0 (embedded wireless) <-> Dot11Radio0 <-> Wireless PC
-
31-10-16, 23:07 Απάντηση: QoS σε Cisco 886w #6
Τελικά από ότι κατάλαβα εφόσον δεν με αφήνει να κάνω LLQ στο input, το input είναι πάντα ότι έρχεται από το WAN. OK, σε αυτό του έβαλα ένα limit στο youtube στο 1Mbps, αλλά μάλλον κάτι έχω κάνει λάθος γιατί δεν παίζει:
Κώδικας:Service-policy input: LimitSitePolicy Class-map: LimitSitesMap (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol http host "*youtube.com*" police: cir 1000000 bps, bc 31250 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: class-default (match-any) 9233188 packets, 9804306085 bytes 5 minute offered rate 1694000 bps, drop rate 0 bps Match: any
Κώδικας:class-map match-all LimitSitesMap description Limit rate of specific sites match protocol http host "*youtube.com*" policy-map LimitSitePolicy description Limit rate of specific sites policy class LimitSitesMap police cir 1000000 exceed-action drop interface Dialer0 service-policy input LimitSitePolicy
-
01-11-16, 00:32 Απάντηση: QoS σε Cisco 886w #7
Δε γίνεται LLQ/queueing γενικά στο input. Ούτως ή άλλως, είναι ήδη μετά το bottleneck και θα ήταν σχετικά ανούσιο. Το match protocol δε μπορεί να πιάσει https καθώς το host field ( και ο υπόλοιπος http header ) είναι encrypted. Μπορείς να δοκιμάσεις να αλλάξεις τη λογική στην acl που είχες πιο πάνω και να κάνεις policing εκεί. Π.Χ. , να βάλεις deny τα sources που σε ενδιαφέρουν, permit ip any any στο τέλος, και να κάνεις match αυτό.
In theory, practice is the same as theory.
In practice, it isn't.
-
02-11-16, 22:22 Απάντηση: QoS σε Cisco 886w #8
Ναι το κατάλαβα αυτό που λες με την αντίστροφη access list, αλλά έτσι δεν θα περιορίσω όλη την κίνηση σταθερά χωρίς λόγο; Θα μπορούσα να πω δηλαδή από τα 5Mbps της γραμμής όλη η υπόλοιπη κίνηση εκτός από τις IP που με ενδιαφέρει να περιορίζεται στα 4Mbps, αλλά αυτό το 1Mbps γιατί να μην το πάρει και το JDownloader για παράδειγμα όταν η γραμμή δεν χρησιμοποιείται; Εκτός αν υπάρχει κάποιος τρόπος μαγικά να πεις ότι μόνο όταν έχεις και IP από αυτές που σε ενδιαφέρουν να ισχύσει το drop των exceeded packets.
-
03-11-16, 00:35 Απάντηση: QoS σε Cisco 886w #9Ναι το κατάλαβα αυτό που λες με την αντίστροφη access list, αλλά έτσι δεν θα περιορίσω όλη την κίνηση σταθερά χωρίς λόγο;
Θα μπορούσα να πω δηλαδή από τα 5Mbps της γραμμής όλη η υπόλοιπη κίνηση εκτός από τις IP που με ενδιαφέρει να περιορίζεται στα 4Mbps, αλλά αυτό το 1Mbps γιατί να μην το πάρει και το JDownloader για παράδειγμα όταν η γραμμή δεν χρησιμοποιείται;
Queueing κάνουμε στην εξερχόμενη κατεύθυνση ( αν και διαφέρει καμιά φορά ανά κατασκευαστή ή αρχιτεκτονική ), ενώ policing μπορούμε να κάνουμε και στις 2. Εξετάζοντας την περίπτωση της εξερχόμενης, το γενικό πλεονέκτημα του queueing είναι ότι ( όσο έχουμε χώρο στο queue ) προκαλεί αύξηση του latency ( => όσο τα πακέτα παραμένουν στο queue ) αντί για packet loss που θα προκαλούσε το policing. Το tcp γενικά αντιδρά καλύτερα σε αύξηση του latency παρά σε απώλεια πακέτων. Το πρακτικό αποτέλεσμα είναι ότι συνήθως σε policing έχουμε ένα διάγραμμα κίνησης που μοιάζει με πριόνι κι έχει κορυφές κοντά στο όριο που βάλαμε. Αντίστοιχα με shaping έχουμε κάτι πιο κοντά σε ευθεία γραμμή, κοντά στο όριο που βάλαμε ( ή στο όριο του interface, όταν κάνουμε queueing χωρίς shaping ), μαζί με εφαρμογή οποιοδήποτε πολιτικών έχουμε εφαρμόσει.
Το θέμα μας όμως είναι ότι κανένα από τα πλεονεκτήματα του queueing δεν έχει ιδιαίτερο νόημα στην εισερχόμενη κίνηση, γιατί συνήθως το bottleneck είναι πιο πέρα. Π.χ. , έχεις ένα κύκλωμα στα 10mbps και κατεβάζεις μια διανομή linux. Ο server ανεβάζει σιγά σιγά το ρυθμό που στέλνει μέχρι να δει καθυστέρηση ή απώλεια. Ας πούμε ότι κάποια στιγμή προσπαθεί να σου στείλει με 11mbps. Ακόμα κι αν είχες queue για να βάλεις αυτό το έξτρα 1mbps, δε θα φτάσει καν σε εσένα, γιατί το κύκλωμα που έχεις αντέχει 10mbps. Συνεπώς, το packet loss που θα ήθελες να αποτρέψεις, έχει ήδη συμβεί.
Στην πράξη, ακόμα κι αν κάνεις policing στην εισερχόμενη κατεύθυνση, υπάρχει πάντα η περίπτωση αυτός/αυτοί που στέλνουν να μην αντιδράσουν αρκετά γρήγορα και να έχεις πλήρωση του κυκλώματος και packet loss για κάποιο χρονικό διάστημα. Υπάρχουν τεχνικές για να αυξήσεις την αποδοτικότητα και να κάνεις την ( tcp τουλάχιστον ) κίνηση κάπως πιο προβλέψιμη, αλλά αυτό δεν είναι κάτι που θα δεις σε έναν απλό cisco router. Συνεπώς, για να έχεις αρκετά μεγάλη αποτελεσματικότητα, πρέπει να ελέγχεις και το απέναντι άκρο του κυκλώματος και να κάνεις queueing στην εξερχόμενη και από εκεί ( κάτι που ισχύει π.χ. σε περιπτώσεις που ο εκάστοτε πάροχος δίνει voip πάνω από το δικό του δίκτυο, αλλά είναι σχεδόν αδύνατο να ισχύει σε υπηρεσίες Internet ).
Σε τέτοιες περιπτώσεις που ήδη γνωρίζεις ότι δε μπορείς να έχεις πολύ καλό αποτέλεσμα στη μια κατεύθυνση, το καλύτερο που μπορείς να κάνεις είναι να πειραματιστείς και να δεις αν υπάρχει κάτι που να σε βολεύει, καθώς το αποτέλεσμα ποικίλει ανάλογα με την τυπική σου κίνηση και τις απαιτήσεις των εφαρμογών σου.In theory, practice is the same as theory.
In practice, it isn't.
Παρόμοια Θέματα
-
βιβλίο cisco
Από johnyb98 στο φόρουμ NetworkingΜηνύματα: 2Τελευταίο Μήνυμα: 12-10-16, 11:42 -
Cisco 2800 pppoe over ethernet
Από bios176 στο φόρουμ Cisco ADSL modems και routersΜηνύματα: 0Τελευταίο Μήνυμα: 08-10-16, 12:26 -
[Baudtec] Qos σε ρουτερ Baudtec tw263r4-a2
Από ZuperMan στο φόρουμ ADSL & Broadband Hardware, routers και modems...Μηνύματα: 1Τελευταίο Μήνυμα: 01-09-16, 19:12 -
Βοήθεια με QoS σε Baudtec tw263r4-a2
Από Γιάγκος Δράκος στο φόρουμ ADSLΜηνύματα: 5Τελευταίο Μήνυμα: 23-11-15, 02:15
Bookmarks