# ADSL, ADSL 2, ADSL 2+  και  Broadband Hardware > Cisco  ADSL modems και routers >  QoS σε Cisco 886w

## boeotian

Καλησπέρα,

Προσπαθώ να ρυθμίσω ένα QoS σε Cisco 886w για μην κολλάει σε παιχνίδια όταν κατεβάζεις ή βλέπεις βίντεο. Η ρύθμιση που έχω κάνει είναι να φτιάξω μία access list 101 για τις διευθύνσεις που θέλω να έχουν προτεραιότητα. Το configuration που έχω κάνει είναι το παρακάτω:



```
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
```

Το πρόβλημα είναι ότι ενώ έχω matching μια χαρά όλα:



```
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
```

Αν κατεβάσω τίποτα κολλάει ξανά. Δεν κάνει κάποια ιδιαίτερη διαφορά. Συνεχίζει να κολλάει και να έχει μεγάλο latency το παιχνίδι. Δοκίμασα και το bandwidth στο policy-map αντί του priority αλλά πάλι δεν έκανε τίποτα. Ίσως κάτι χάνω, γιατί τα Online Games θέλουν περισσότερο χαμηλό latency και όχι ιδιαίτερο bandwidth. Αν έχει κανένας καμία ιδέα.

Επίσης να συμπληρώσω ότι τα tests μου τα έκανα κατεβάζοντας από το laptop που συνδέεται στο embedded wireless με wifi και το game είναι στο ethernet interface του router από desktop. Εφόσον το έβαλα στον dialer που περνάνε όλα θα πρέπει να είναι σωστό. Δεν ξέρω μήπως έπρεπε να το εφαρμόσω σε άλλο σημείο. Στο ATM πάντως δεν το παίρνει.

----------


## SfH

Το service policy το έχεις βάλεις προς τα έξω, συνεπώς, πιάνει το upload σου. Θεωρώντας ότι το παιχνίδι που παίζεις δεν χρειάζεται ιδιαίτερο bandwidth, θα έπαιζα με LLQ. Προσοχή όμως να μη βάλεις τον policer πολύ ψηλά γιατί μπορεί να έχεις προβλήματα στην υπόλοιπη κίνηση.

Για την εισερχόμενη κίνηση, οι επιλογές σου είναι πολύ πιο περιορισμένες. Το πιο εύκολο θα ήταν να φτιάξεις μια πολιτική που να πιάνει το ακριβώς αντίθετο και να το περιορίζει με policer αρκετά κάτω του μέγιστου ρυθμού που πιάνεις. Στην πράξω όμως πάλι υπάρχει πιθανότητα να έχεις πρόβλημα. Γενικά όταν παίρνεις τέτοιες αποφάσεις στο ingress, η αποτελεσματικότητά τους είναι περιορισμένη καθώς η πίεση που ασκείς είναι μετά το πραγματικό bottleneck ( τη γραμμή σου ). Μπορείς να θεωρήσεις ότι οι εφαρμογές θα συμπεριφέρονται καλά και θα αντιδρούν γρήγορα σε packet loss, ρίχνοντας το ρυθμό με τον οποίον στέλνουν δεδομένα σε εσένα. Στην πράξη δεν είναι απίθανο να έχεις μικρές περιόδους congestion ή ακόμα και εφαρμογές που αγνοούν τελείως το packet loss και θεωρούν ότι μπορούν να στείλουν σταθερά με ρυθμό που θα σου προκαλέσει congestion.

----------


## boeotian

Το 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 που σου τρώνε την γραμμή.

----------


## SfH

Δε θα το πάρει με 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. Πάλι ισχύουν αυτά που έγραψα παραπάνω σε σχέση με την αποτελεσματικότητα προφανώς.

----------


## boeotian

Σε ευχαριστώ για την απάντησή σου. Όχι ότι κατάλαβα ιδιαίτερα τι προτείνεις. Θα βοηθούσε καμία παραπομπή να διαβάσω. 

Τώρα για το 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
```

για το ATM0 το input είναι από WAN, ενώ για το FastEthernet1 το input είναι από το συνδεδεμένο PC; Για τον Dialer που είναι στην μέση τι παίζει;

----------


## boeotian

Τελικά από ότι κατάλαβα εφόσον δεν με αφήνει να κάνω 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
```

το match protocol http δεν πιάνει και το https;

----------


## SfH

Δε γίνεται LLQ/queueing γενικά στο input. Ούτως ή άλλως, είναι ήδη μετά το bottleneck και θα ήταν σχετικά ανούσιο. Το match protocol δε μπορεί να πιάσει https καθώς το host field ( και ο υπόλοιπος http header ) είναι encrypted. Μπορείς να δοκιμάσεις να αλλάξεις τη λογική στην acl που είχες πιο πάνω και να κάνεις policing εκεί. Π.Χ. , να βάλεις deny τα sources που σε ενδιαφέρουν, permit ip any any στο τέλος, και να κάνεις match αυτό.

----------


## boeotian

Ναι το κατάλαβα αυτό που λες με την αντίστροφη access list, αλλά έτσι δεν θα περιορίσω όλη την κίνηση σταθερά χωρίς λόγο; Θα μπορούσα να πω δηλαδή από τα 5Mbps της γραμμής όλη η υπόλοιπη κίνηση εκτός από τις IP που με ενδιαφέρει να περιορίζεται στα 4Mbps, αλλά αυτό το 1Mbps γιατί να μην το πάρει και το JDownloader για παράδειγμα όταν η γραμμή δεν χρησιμοποιείται; Εκτός αν υπάρχει κάποιος τρόπος μαγικά να πεις ότι μόνο όταν έχεις και IP από αυτές που σε ενδιαφέρουν να ισχύσει το drop των exceeded packets.

----------


## SfH

> Ναι το κατάλαβα αυτό που λες με την αντίστροφη access list, αλλά έτσι δεν θα περιορίσω όλη την κίνηση σταθερά χωρίς λόγο;


Σωστά. Θα μπορούσες να φτιάξεις κάποιο EEM για να αλλάζει την πολιτική συγκεκριμένες ώρες ή με κάποια άλλη προϋπόθεση, αλλά δεν ξέρω αν θα είχε ιδιαίτερο νόημα.




> Θα μπορούσα να πω δηλαδή από τα 5Mbps της γραμμής όλη η υπόλοιπη κίνηση εκτός από τις IP που με ενδιαφέρει να περιορίζεται στα 4Mbps, αλλά αυτό το 1Mbps γιατί να μην το πάρει και το JDownloader για παράδειγμα όταν η γραμμή δεν χρησιμοποιείται;


Ας τα πιάσουμε από την αρχή. Έχουμε 2 γενικά εργαλεία ( με διάφορους τρόπους υλοποίησης και συμπληρωματικά εργαλεία που δε θα πιάσω τώρα ) στη διάθεσή μας, το policing και το queueing. Το policing μετράει την κίνηση και αν ξεπεράσει ένα όριο που έχουμε θέσει, πετάει τα πακέτα που "περισσεύουν". Στο queueing έχουμε κάποια προϋπόθεση ( συνήθως είτε shaping, ή πλήρωση του tx-ring αν μιλάμε για κύκλωμα ίδιας χωρητικότητας με το interface ). Όταν πληρείται η προϋπόθεση, η κίνηση που περισσεύει πάει στο queue. Μέσα σε αυτό το queue μπορούμε να κάνουμε διάφορα, όπως να δώσουμε προτεραιότητα ή να προσπαθήσουμε να εγγυηθούμε bandwidth με δικά μας κριτήρια. Συνεπώς έχουμε κάποιο επίπεδο έλεγχου στο ποια πακέτα θα γίνουν drop από το queue. 

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 ).

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

----------

