This is an old revision of the document!
−Table of Contents
QOS classification
QOS
Théorie
Ressources : bandwidth, delay, jitter, packet loss
Tableau récapitulatif
.. des différentes techniques :
Types de QoS | Méthodes |
---|---|
classification & marquing | class-map, DSCP |
congestion management | WFQ, CBWFQ, LLQ |
congestion avoidance | WRED |
shaping/policing | CB-shaping/CB-policing |
link efficiency | cRTP, cPayload, HLPPP |
CAC | gatekeeper, RSVP |
Classification et marquing
- WFQ (Weighted Fair-Queuing) : priorisation automatique, non modifiable de certains flux, basé sur un hash des paquets
- CBWFQ (Class-Based WFQ) : c'est du WFQ personnalisable : on définit des classes associées à des priorités (ex : NBAR)
- LLQ (Low Latency Queuing) = du CFWFQ avec une file spéciale pour limité la latence (PQ) ; pour la voix par exemple. Cela définit une file qui est vidées en priorité avant les autres.
Le marquage peut se faire à différentes couches OSI, dans différents chaps en fonction du protocole :
- champ COS en Ethernet (802.1q/p)
- champ EXP de l'entête MPLS
- champ DSCP d'IP
- IP precedence
L'IP precedence est l'ancienne utilisation du champ TOS d'IP : on n'utilisait que les 3 bits de poids fort (bits 7 à 5) ce qui faisait 6 classes (2 combinaisons étant réservées).
Le PHB (Per-Hop Behavior) est la nouvelle façon d'utiliser le champ TOS
EF PHB : Expedited Forwarding = low-delay service (VoIP) AF PHB : Assured Forwarding = guaranted bandwidth service default PHB : on fait du best-effort
Le champ TOS ou DSCP
C'est un champ de 8 bits codées ainsi :
- Les bits 1 et 0 sont réservés pour un usage futur donc on ne les fait pas apparaitre. C'est ce qui explique pourquoi on note toujours la valeur du champ TOS sur 6 bits.
- Le bit n°2 est toujours à 0
- Les bits 7 à 5 correspondent à
^7^6^5^Correspond à^
1 | 1 | 1 | |
1 | 1 | 0 | |
1 | 0 | 1 | EF |
1 | 0 | 0 | AF 4 |
0 | 1 | 1 | AF 3 |
0 | 1 | 0 | AF 2 |
0 | 0 | 1 | AF 1 |
0 | 0 | 0 | default PHB |
- Les bits de 4 à 3 définissent le pourcentage de chance de drop par classe (si on utilise AF ; car en EF les 2 bits valent “1”) ; donc la valeur la plus faible est la “mieux”. Les valeurs possibles sont 01 10 ou 11 (pas 00).
Une exception existe pour la valeur “001 000” qui code le trafic scavenger (less-than-best-effort, souvent du P2P).
Exemple : Si le champ TOS vaut 100010 (on omet les bits 1 et 0 car on ne s'en sert pas), le paquet correspond à de l'AF41 (on découpe ainsi : 100-01-0). Ces 6 bits peuvent se lire en décimal : “PHB AF41” correspond à “DSCP 34” (ces notations sont équivalentes).
Congestion avoidance
La méthode consiste à droper des paquets dans les buffers d'interface avant son remplissage complet.
Les différentes gestions de file d'attente :
- RED Random Early Detection : en fonction du remplissage du buffer, on défini un %age de drop
- WRED Weighted RED = une file RED par type de paquet
Protocoles de signalisation
- H.323
- RSVP (Ressource Reservation Protocol) : pour réserver les ressources d'un flux RTP (modèle IntServ)
- SCCP
- MGCP
- SIP
Modèles de QOS
- Best effort c'est le comportement par défaut ; il ne fournit pas de QoS
- pas de garantie de service
- pas de différenciation de service
- IntServ Integrated Services (RFC 1633) : permet de fournir de la QoS par réservation de ressource (~réservation de circuit / pour faire du CAC Call Admission Control) ; garantit l'arrivée des paquets
- basé sur RSVP/CAC pour réserver les ressources
- débit garanti
- problème de scalabilité (ne passe pas l'échelle)
- DiffServ Differenciated Services (RFC 2474 et 2475) : Utilisation de classes de services (typiquement le champ TOS/DSCP du paquet IP) qui sont reconnues par les routeurs du réseau (pour faire du PQ)
- pas de garantie absolue de service
Implémentation de la QoS
- Legacy QoS CLI : peu pratique, configuration interface par interface
- MQC Modular QoS CLI : configuration modulaire, personnalisable (utilise des class-map et des policy-map)
- Cisco AutoQoS : simple à mettre en place car il s'agit d'un modèle pré-conçu pour la VoIP. Il utilise :
- NBAR, CEF et champ DSCP pour la classification
- LLQ et WRR
- shaping, FRTS
- compression d'entêtes (cRTP)
- fragmentation des gros paquets (LFI ?)
Pour le mettre en place il faut activer le cef et préciser la bandwidth de l'interface
- Cisco SDM QoS Wizard : assistant graphique (via HTTP) de configuration de la QoS
Mise en place
Marquage de trafic
Reconnaissance et marquage du champ DSCP du trafic HTTP et FTP (modèle DiffServ avec MQC). Le concept est simple :
- définition d'une classe de trafic (class-map) = on matche un trafic (dans notre cas on se sert d'ACLs dans les class-map)
- définition d'une policy pour cette classe = ce qui va être fait à ce trafic (policy-map)
- application de la policy sur une interface (service-policy)
access-list 101 permit cp any any eq ftp access-list 101 permit cp any any eq ftp-data access-list 102 permit cp any any eq www class-map match-all match-ftp match access-group 101 class-map match-all match-www match access-group 102 policy-map mark-apps class match-ftp set dscp af11 class match-www set dscp default interface FastEthernet0/1 service-policy input mark-apps
- En utilisant des ACLs on peut affiner le “match” dans les class-maps.
- dans une class-map on peut spécifier plusieurs paramètres “match”. Dans ce cas on doit choisir la condition ET (
match-all
) ou OU (match-any
) pour indiquer si le trafic doit matcher chaque clause (ET) ou ou moins une (OU).
Vérifications
show class-map show policy-map interface fa0/1
NBAR
NBAR Network-Based Application Recognition permet l'identification des applications/protocoles d'un paquet sur la base de signatures (PDLM) et permet d'en faire de la classification et des statistiques. Il travaille au niveau 4 - 7 mais il ne saura pas reconnaitre du HTTP sur un autre port que le celui qu'on lui spécifie (80 par défaut). Cela veut dire qu'il se base sur le numéro de port pour savoir lire le protocole auquel il s'attend. Ce n'est pas un IPS qui se base sur des signatures applicative et qui peut détecter du HTTP sur un “non-standard port”.
PDLM Packet Description Language Module : bout de code pour reconnaitre un protocole
Pour activer NBAR sur une interface (le CEF doit être activé : #ip cef
) :
(config-if)#ip nbar protocol-discovery
show ip nbar port-map port-map bgp udp 179 port-map bgp tcp 179 port-map citrix udp 1604 [..]
Pour modifier un port d'un protocole connu :
(config)#ip nbar port-map http tcp 8080
Puis, pour voir les statistiques des protocoles {sur l'interface fa0/1} :
show ip nbar protocol-discovery {interface fa0/1}
Ce nouveau port remplace celui par défaut ; pour en rajouter un, on l'ajoute à la suite :
(config)#ip nbar port-map http tcp 80 8080