informatique:cisco:qos
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
informatique:cisco:qos [2009/04/01 10:41] – pteu | informatique:cisco:qos [2013/10/14 20:44] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | {{tag>QOS classification}} | + | {{tag>QoS classification}} |
- | ======QOS====== | + | ======QoS====== |
+ | La **QoS** (Quality Of Service) a pour but d' | ||
- | =====Théorie===== | + | ====Leaky bucket VS token bucket==== |
- | Ressources | + | * **leaky bucket**, algorithme du seau troué |
- | ====Tableau récapitulatif==== | + | * **token bucket**, algorithme du seau à jeton : le seau à jeton démarre plein ; un jeton c'est un crédit de trafic, chaque paquet transmis consomme des jetons ; les jetons se régénèrent au rythme du CIR normalement. Quand il n'y a plus de jetons dans le seau, le trafic est " |
+ | Cet algorithme conserve les bursts (à la différence du lissage du shaping) mais permet d' | ||
- | .. des différentes techniques : | + | =====Modèles de QOS===== |
- | ^ Types de QoS ^ Méthodes | + | * **Best effort** c'est le comportement par défaut d'un routeur, sur lequel est basé Internet ; il ne fournit pas de QoS |
- | | classification & marquing | class-map, DSCP | | + | * pas de garantie de service |
- | | congestion management | + | * pas de différenciation de service |
- | | congestion avoidance | + | * **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' |
- | | shaping/ | + | * basé sur RSVP/CAC pour réserver les ressources |
- | | link efficiency | + | * débit garanti |
- | | CAC | + | * problème de scalabilité (//ne passe pas l' |
+ | * **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 ; c'est un traitement routeur par routeur sans pré-signalisation que l'on nomme **PHB** (Per Hop Behaviour) | ||
+ | * pas de garantie absolue de service | ||
+ | * scalable en utilisant un petit nombre de classes de trafic | ||
+ | |||
+ | |||
+ | =====Implémentation de la QoS===== | ||
+ | |||
+ | * Legacy QoS CLI : peu pratique, configuration interface par interface | ||
+ | * **MQC** (Modular QoS CLI) : configuration modulaire, personnalisable (utilise des // | ||
+ | * Cisco AutoQoS : simple à mettre en place, il exite 2 variantes : VoIP et Enterprise (cf plus bas). L' | ||
+ | * NBAR, CEF et le champ DSCP pour la classification | ||
+ | * LLQ et WRR | ||
+ | * shaping, FRTS | ||
+ | * la compression d' | ||
+ | * la fragmentation de paquets (LFI) | ||
+ | * Cisco SDM QoS Wizard : assistant graphique (via HTTP) de configuration de la QoS | ||
+ | |||
+ | |||
+ | =====Les différents délais d' | ||
+ | |||
+ | * **processing delay** : temps de traitement d'un paquet par le routeur, à partir du moment ou il est reçu sur l' | ||
+ | * **queuing delay** : temps passé par un paquet dans la file d' | ||
+ | * **serialisation delay** : temps mis par le routeur pour émettre un paquet sur le lien ; cela dépend de la bande passante de ce dernier | ||
+ | * **propagation delay** : temps mis par un paquet pour traverser un lien ; cela dépend donc du média (ex : les transmissions satellite ont un temps de propagation beaucoup plus grand que de la fibre optique) | ||
+ | * **transmission delay** : pour moi c'est le même que le temps de sérialisation (à vérifier) | ||
+ | * **end-to-end delay** : temps que met un paquet de bout en bout (du début de la sérialisation de la machine émettrice à la fin de la réception du paquet chez le récepteur) | ||
+ | |||
+ | |||
+ | =====Méthodologie de mise en place===== | ||
+ | |||
+ | Voici les 3 grandes étapes de la mise en place de la QoS dans un réseau : | ||
+ | |||
+ | * Identifier le trafic qui transite par le réseau, et spécifier ses besoins en ressources réseau (bandwidth, delay, jitter, packet loss). | ||
+ | * Grouper les flux qui nécessitent les mêmes besoins dans une même classe | ||
+ | * Définir la politique de QoS qui rejoint les besoins des différentes classes de trafic | ||
+ | |||
+ | |||
+ | =====Les différentes étapes de la QoS===== | ||
+ | |||
+ | ^ Étape | ||
+ | | classification & marquing | ||
+ | | queuing (congestion management) | WFQ, CBWFQ, LLQ | | ||
+ | | congestion avoidance | ||
+ | | shaping/ | ||
+ | | link efficiency | ||
+ | | CAC | ||
====Classification et marquing==== | ====Classification et marquing==== | ||
- | Le marquage peut se faire à différentes couches OSI, dans différents | + | On peut différencier les paquets en fonctions des paramètres suivants : |
- | * champ COS en Ethernet (802.1q/p) | + | * interface d' |
+ | * IP precedence | ||
+ | * DSCP | ||
+ | * IP source ou destination | ||
+ | * application (ports tcp et udp) | ||
+ | |||
+ | Le marquage peut se faire à différentes couches OSI, dans différents | ||
+ | * champ COS (3 bits) en Ethernet (802.1q/ | ||
* champ EXP de l' | * champ EXP de l' | ||
* champ DSCP d'IP | * champ DSCP d'IP | ||
* IP precedence | * IP precedence | ||
+ | * bit DE (Discard Eligible) en Frame Relay | ||
- | L'**IP precedence** est l' | + | L'**IP precedence** est l' |
- | + | ||
- | Le **PHB** (Per-Hop Behavior) est la nouvelle façon d' | + | |
- | **EF** PHB : Expedited Forwarding = low-delay service (VoIP) | + | * **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=== | ===Le champ TOS ou DSCP=== | ||
C'est un champ de 8 bits codées ainsi : | 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. | + | * Les bits 1 et 0 sont "réservés pour un usage futur" |
* Le bit n°2 est toujours à 0 | * Le bit n°2 est toujours à 0 | ||
Line 49: | Line 103: | ||
|1|1|1| | |1|1|1| | ||
|1|1|0| | |1|1|0| | ||
- | |1|0|1|EF | | + | |1|0|1|ef | |
- | |1|0|0|AF 4 | | + | |1|0|0|af 4 | |
- | |0|1|1|AF 3 | | + | |0|1|1|af 3 | |
- | |0|1|0|AF 2 | | + | |0|1|0|af 2 | |
- | |0|0|1|AF 1 | | + | |0|0|1|af 1 | |
|0|0|0|default PHB | | |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 " | + | * Les bits de 4 à 3 définissent le pourcentage de chance de drop par classe (si on utilise AF, car en EF on ne drop pas (logique !), les 2 bits valent " |
Une exception existe pour la valeur "001 000" qui code le trafic **scavenger** (less-than-best-effort, | Une exception existe pour la valeur "001 000" qui code le trafic **scavenger** (less-than-best-effort, | ||
- | Exemple : Si le champ TOS vaut 100010 | + | Exemple : Si le champ TOS vaut 100010, le paquet correspond à de l'af41 (on découpe ainsi : 100-01-0). Ces 6 bits peuvent se lire en décimal : " |
- | Ces 6 bits peuvent se lire en décimal : " | + | |
- | Il existe une notation de classes " | + | Il existe une notation de classes " |
+ | |||
+ | TODO : insérer la table d' | ||
+ | |||
+ | ===Mise en place du marquage=== | ||
+ | |||
+ | 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/ | ||
+ | | ||
+ | |||
+ | * En utilisant des ACLs on peut affiner le " | ||
+ | * dans une class-map on peut spécifier plusieurs paramètres " | ||
+ | |||
+ | ==Vérifications== | ||
+ | |||
+ | show class-map | ||
+ | show policy-map interface fa0/1 | ||
+ | |||
+ | ===QoS pre-classify=== | ||
+ | |||
+ | Dans le cas de VPN, les entêtes IPs sont modifiées donc la classification peut être écrasée. Cisco utilise la fonction **qos pre-clasify** (ou **QoS for VPNs**) pour gérer ce problème. | ||
+ | |||
+ | * Apply the policy to the tunnel interface without '' | ||
+ | * Apply the policy to the physical interface without '' | ||
+ | * Apply the policy to a physical interface and enable '' | ||
+ | |||
+ | Cette fonctionnalité est appelée **QoS for Virtual Private Networks (VPNs)** par Cisco ; certaines versions d'IOS un peu anciennes ne l' | ||
====Mécanismes de queuing==== | ====Mécanismes de queuing==== | ||
- | // | ||
- | * **FIFO** First In First Out, mécanisme | + | Il s'agit du mécanisme |
- | * **PQ** Priority Queuing : on vide en priorité la file de plus haute priorité => implique la famine (starving) | + | |
- | * **RR** Round Robin : méthode de partage équitable entre chaque file (en paquet, pas forcément en débit) : ABCABCABC... | + | |
- | * **WRR** Weighted RR : associe des priorités par file au RR = permet de donné plus de priorité à une file | + | |
- | * **CQ** Custom Queuing c'est le nom du RR chez Cisco | + | |
- | * **WFQ** (Weighted Fair-Queuing) : priorisation automatique, | + | |
- | * **CBWFQ** (Class-Based WFQ) : c'est du WFQ personnalisable | + | |
- | * **LLQ** (Low Latency Queuing) = du CBWFQ avec une file spéciale pour limité | + | * **PQ** (Priority Queuing : on vide en premier toute la file de plus haute priorité => peut créer une situation de famine (starving) des autres files, moins prioritaires, |
+ | * **RR** (Round Robin) : méthode de partage équitable entre chaque file (on pioche un paquet dans chaque file à tour de rôle) | ||
+ | * **WRR** (Weighted RR) : associe des priorités par file au RR = permet de donner plus de priorité à une file | ||
+ | * **CQ** (Custom Queuing) c'est l' | ||
+ | * **WFQ** (Weighted Fair-Queuing) : priorisation automatique, | ||
+ | | ||
+ | * **LLQ** (Low Latency Queuing) = du CBWFQ avec une file spéciale | ||
- | Les mécanismes de gestion de file d' | + | Les mécanismes de gestion de file d' |
show controller se0/1/0 | i tx_limited | show controller se0/1/0 | i tx_limited | ||
| | ||
- | ===WFQ=== | + | Le buffer hardware peut être configuré avec la commande : |
- | * classification : calcul | + | tx-ring-limit < |
- | * drop policy : CDT (nb de messages permis dans la queue) ; HQO (limite de la taille des paquets | + | |
+ | Cependant il faut faire attention car une mauvaise configuration de ce dernier peut annuler toute la politique de QoS (s'il est trop important ou pas assez). | ||
+ | |||
+ | ===Mise en place du WFQ=== | ||
+ | |||
+ | * classification : en fonction | ||
+ | * drop policy : **CDT** (Congestive Discard Threshold) | ||
* scheduling | * scheduling | ||
+ | * c'est la méthode de queuing par défaut chez Cisco pour les interfaces série et les liaisons E1 et inférieures (< 2048 Kbps) | ||
+ | |||
+ | Le WFQ priorise les flux qui ont un petit **finish time** càd les paquets qui mettent le moins de temps à être émis sur le lien. Cela prend en compte la taille du paquet (+ vite émis qu'un gros) ainsi que le remplissage de sa file (on privilégie les files les moins remplies quand on doit déterminer quel paquet dropper si le HQO (nombre max de paquets) est atteind, quitte a dropper un paquet déjà empilé dans une autre file plus longue). | ||
+ | |||
+ | La mise en place est très simple mais n'est possible que sur une interface de moins de 2 Mbps (à valider). | ||
+ | fair-queue [CDT [conversation dynamic-queues [conversation reservable-queues]]] | ||
+ | |||
+ | Réglage de la HQO (le défaut est 1000) : | ||
+ | hold-queue < | ||
+ | |||
+ | ==Vérifs== | ||
- | Vérifs : | ||
show interface se0/1/0 | show interface se0/1/0 | ||
show queue se0/1/0 | show queue se0/1/0 | ||
- | ===Congestion avoidance=== | + | ===Mise en place de LLQ=== |
- | La méthode consiste à droper des paquets dans les buffers d' | + | On travaille sur des paquets déjà taggués en amont et on leur applique une politique de gestion de file d' |
+ | |||
+ | Les classes reconnues sont définies dans des class-map : | ||
+ | |||
+ | class-map match-any ef-traffic | ||
+ | | ||
+ | match protocol icmp | ||
+ | class-map match-all af21-traffic | ||
+ | | ||
+ | class-map match-all af31-traffic | ||
+ | | ||
+ | class-map match-all af11-traffic | ||
+ | | ||
+ | class-map match-all cs1-traffic | ||
+ | | ||
+ | |||
+ | On définit l' | ||
+ | * la **file prioritaire** (~VoIP, propre au LLQ, introduit par la commande '' | ||
+ | * les files af31, af21, af11 et cs1 auront respectivement 40, 20, 13 et 2 % de la bande passante __restante__ (remaining) du lien **minimum** | ||
+ | * le reste (class-default) aura 25% du reste de la bande passante. 2 paramètres sont également présents : l' | ||
+ | |||
+ | Chez Cisco, par défaut, on ne peut pas dépasser 75% de réservation pour toutes les files, les 25% restant étant gardé pour le routage, les entêtes de niveau 2, etc... | ||
+ | |||
+ | L' | ||
+ | |||
+ | policy-map llq-policy | ||
+ | class ef-traffic | ||
+ | priority 168 | ||
+ | class af31-traffic | ||
+ | bandwidth remaining percent 40 | ||
+ | class af21-traffic | ||
+ | bandwidth remaining percent 20 | ||
+ | class af11-traffic | ||
+ | bandwidth remaining percent 13 | ||
+ | class cs1-traffic | ||
+ | bandwidth remaining percent 2 | ||
+ | class class-default | ||
+ | fair-queue 1024 | ||
+ | queue-limit 50 | ||
+ | bandwidth remaining percent 25 | ||
+ | |||
+ | On applique (en output) sur une interface, par exemple la se0/1/0 (toute la QoS précédemment configurée est basée sur le paramètre bandwidth 384 (384 Kbps) de l' | ||
+ | |||
+ | interface Serial0/ | ||
+ | | ||
+ | | ||
+ | |||
+ | Cette interface ne doit pas être en WFQ sous peine de tomber sur le message //Must remove fair-queue configuration first.// | ||
+ | => '' | ||
+ | |||
+ | => la classification se fait en input et le queuing se fait en output. | ||
+ | |||
+ | ==Vérifications== | ||
+ | |||
+ | show class-map | ||
+ | show policy-map interface fa0/1 | ||
+ | |||
+ | |||
+ | ====Congestion avoidance==== | ||
+ | |||
+ | La méthode consiste à droper des paquets dans les buffers d' | ||
+ | * d' | ||
+ | * de faire réagir les sources consommatrices de BW qui utilisent TCP afin qu' | ||
+ | * on jette des paquets aléatoirement = cela touche en moyenne plus les sources les plus consommatrices de bande passante | ||
+ | * cela permet en outre de désynchroniser les flux TCP afin de ne pas avoir de pics de débit simultanés (TCP global synchro) qui amènent les congestions | ||
Les différentes gestions de file d' | Les différentes gestions de file d' | ||
* **RED** Random Early Detection : en fonction du remplissage du buffer, on défini un %age de drop | * **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 | + | * **WRED** Weighted RED = une file RED par type de paquet, avec des seuils différents |
- | ====Protocoles | + | 3 types de " |
- | * H.323 | + | Pour mettre en place du (CB)(W)RED sur un type de classe, il faut passer la commande '' |
- | * **RSVP** | + | |
- | * SCCP | + | |
- | * MGCP | + | |
- | * SIP | + | |
- | ====Modèles de QOS==== | + | policy-map pmap-test |
+ | class match-http | ||
+ | bandwidth percent 20 | ||
+ | random-detect dscp af11 32 36 10 | ||
- | * **Best effort** c' | + | Les paramètres ci-dessus sont facultatifs, |
- | * pas de garantie de service | + | |
- | * pas de différenciation de service | + | |
- | * **IntServ** Integrated Services (RFC 1633) : permet de fournir | + | |
- | * basé sur RSVP/CAC pour réserver | + | |
- | * débit garanti | + | |
- | * problème | + | |
- | * **DiffServ** Differenciated Services (RFC 2474 et 2475) : Utilisation | + | |
- | * pas de garantie absolue | + | |
- | ====Implémentation de la QoS==== | + | ====Shaping/ |
+ | ou //trafic conditioner// | ||
- | * Legacy QoS CLI : peu pratique, configuration interface par interface | + | Policing VS Shaping |
- | * **MQC** Modular QoS CLI : configuration modulaire, personnalisable (utilise des //class-map// et des //policy-map//) | + | {{http://www.cisco.com/image/gif/paws/19645/policevsshape-a.gif}} |
- | * 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' | + | |
- | * fragmentation des gros paquets (LFI ?) | + | |
- | Pour le mettre en place il faut activer le cef et préciser la bandwidth de l' | + | |
- | * Cisco SDM QoS Wizard : assistant graphique (via HTTP) de configuration de la QoS | + | |
+ | ===Lexique=== | ||
+ | >GTS : Generic Traffic Shaping | ||
+ | >CIR Commited Information Rate = mean rate, ou débit souscrit | ||
+ | >CAR Committed Access Rate | ||
+ | >Bc conform burst | ||
+ | >Be excess burst | ||
+ | >pir Peak Information Rate | ||
+ | > | ||
+ | > | ||
+ | > | ||
+ | > | ||
+ | >Cisco recommends the following values for the normal and extended burst parameters: | ||
+ | >normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds | ||
+ | > | ||
- | =====Mise en place===== | ||
- | ====Marquage | + | ===shaping=== |
+ | Le **shaping** c'est du lissage | ||
- | Reconnaissance et marquage du champ DSCP du trafic HTTP et FTP (modèle DiffServ avec MQC). Le concept est simple : | + | {{http:// |
- | | + | |
- | - 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 | + | |
- | access-list | + | * réduit les réémissions TCP en évitant le drop systématique de l' |
- | access-list | + | * applicable uniquement sur une interface " |
+ | * pas de marking (marquage des paquets) | ||
+ | |||
+ | ==Mise en place== | ||
+ | Il existe 2 manières de mettre en place du shaping : | ||
+ | |||
+ | * directement sur une interface | ||
+ | |||
+ | S' | ||
+ | < | ||
+ | int xxx | ||
+ | | ||
+ | </ | ||
+ | |||
+ | ou en utilisant une ACL pour sélectionner le trafic sur lequel s' | ||
+ | < | ||
+ | int xxx | ||
+ | | ||
+ | </ | ||
+ | |||
+ | * ou passer par une class-map (sélection du trafic concerné) et une policy-map (définition de l' | ||
+ | |||
+ | < | ||
+ | class-map match-all toto_class-map | ||
+ | | ||
+ | match any | ||
+ | ! | ||
+ | policy-map toto_policy-map | ||
+ | class toto_class-map | ||
+ | ! envoyer Bc par intervalle | ||
+ | shape average CIR Bc Be | ||
+ | ! envoyer Bc+Be par intervalle | ||
+ | shape peak CIR Bc Be | ||
+ | ! | ||
+ | int xxx | ||
+ | | ||
+ | </ | ||
+ | |||
+ | ===policing=== | ||
+ | Le **policing** est l' | ||
+ | |||
+ | * on peut définir différentes actions (drop, mark + transmit) | ||
+ | * s' | ||
+ | |||
+ | Le policing utilise le concept du **token bucket** (seau à jetons) = les jetons se régénèrent à la vitesse du CIR = Bc / Tc | ||
+ | |||
+ | ===Liens=== | ||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | |||
+ | ====Link efficiency==== | ||
+ | |||
+ | Mécanismes : | ||
+ | * **compression d' | ||
+ | |||
+ | policy-map llq-policy | ||
+ | class ef-traffic | ||
+ | compression header ip rtp | ||
+ | |||
+ | * **compression de payload** (négocié par ppp = il faut l' | ||
+ | |||
+ | int se0/1/0 | ||
+ | | ||
+ | |||
+ | sh compress details | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | 10 min avg ratio xmt/rcv 0.088/ | ||
+ | no bufs xmt 0 no bufs rcv 0 | ||
+ | | ||
+ | |||
+ | * **fragmentation** (**LFI** Link Fragmentation and Interleaving) (/!\ les paquets voix doivent rester + petits que les fragments de data pour rester prioritaire en cas de WFQ). On fragmente pour ne pas retarder les paquets voix quand un gros paquet met du temps à être sérialisé. On fragmente donc le gros paquet, et si un paquet voix arrive, il passera entre 2 fragments (**entrelacement**). | ||
+ | |||
+ | int se0/1/0 | ||
+ | ppp multilink group 1 | ||
+ | int multilink 1 | ||
+ | | ||
+ | ppp multilink fragment delay 10 | ||
+ | ppp multilink interleave | ||
+ | no shut | ||
+ | |||
+ | Le but pour que cela soit efficace est d' | ||
+ | |||
+ | Ces mécanismes sont consommateurs de ressources CPU ; aussi on les utilise surtout sur des interfaces à 64 Kbps ou moins. | ||
+ | |||
+ | ====VAD==== | ||
+ | |||
+ | La **VAD** (Voice Activity Detection) est un système de détection de blancs dans une conversation en VoIP. Cela permet de ne pas transmettre ces données inutiles, et donc de sauvegarder de la bande passante sur le réseau. Il permet de sauver 35% de la bande passante en moyenne (atteint pour un lien qui transmet 24 appels), mais cela dépend du fond sonore, du type d' | ||
+ | |||
+ | |||
+ | =====Mise en place du control-plane===== | ||
+ | |||
+ | Le **CoPP** ou **Control Plane Policing** est un mécanisme censé protéger un routeur des attaques de type DoS en définissant des règles de priorité en cas de forte charge. Il protège le **control plane** (flux faisant fonctionner le réseau, comme les protocoles de routage OSPF ou BGP) et le **management plane** (flux d' | ||
+ | |||
+ | L' | ||
+ | |||
+ | | ||
+ | access-list | ||
+ | access-list | ||
| | ||
- | class-map match-all | + | class-map match-all |
- | match access-group 101 | + | match access-group |
- | | + | |
- | match access-group | + | |
| | ||
- | policy-map | + | policy-map |
- | | + | |
- | set dscp af11 | + | |
- | class match-www | + | |
- | | + | |
| | ||
- | | + | |
- | | + | |
- | * En utilisant des ACLs on peut affiner le " | ||
- | * dans une class-map on peut spécifier plusieurs paramètres " | ||
- | ====Vérifications==== | + | =====Cisco AutoQoS===== |
- | show class-map | + | Il existe 2 types d' |
- | show policy-map | + | |
+ | L' | ||
+ | |||
+ | ====Prérequis==== | ||
+ | |||
+ | * CEF doit être activé sur cette interface | ||
+ | * aucune service-policy ne doit être configurée sur l' | ||
+ | * bien préciser le paramètre bandwidth sur l' | ||
+ | |||
+ | ====Limitations==== | ||
+ | |||
+ | * dans un réseau FR, l' | ||
+ | * si un DLCI est déjà configuré sur une sous-interface | ||
+ | * si une class-map | ||
+ | |||
+ | ====Mise en place de l' | ||
+ | |||
+ | * activer la découverte des protocoles sur une interface | ||
+ | |||
+ | auto discovery qos | ||
+ | |||
+ | * attendre quelques temps (dans l' | ||
+ | |||
+ | auto qos | ||
+ | |||
+ | Vérifications : | ||
+ | |||
+ | show auto qos [interface | ||
+ | show auto discovery qos [interface se0/1/0] | ||
+ | |||
+ | show mls qos interface se0/1/0 | ||
+ | show mls qos maps | ||
=====NBAR===== | =====NBAR===== | ||
- | **NBAR** Network-Based Application Recognition permet l' | + | **NBAR** |
- | **PDLM** Packet Description Language Module : bout de code pour reconnaitre un protocole | + | **PDLM** |
Pour activer NBAR sur une interface (le CEF doit être activé : ''# | Pour activer NBAR sur une interface (le CEF doit être activé : ''# | ||
Line 191: | Line 495: | ||
show ip nbar protocol-discovery {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' | + | Ce nouveau port remplace celui par défaut |
(config)#ip nbar port-map http tcp 80 8080 | (config)#ip nbar port-map http tcp 80 8080 | ||
+ | |||
+ | Pour charger un PLDM : | ||
+ | (config)#ip nbar pldm <nom du pldm> |
informatique/cisco/qos.1238582471.txt.gz · Last modified: 2013/10/14 20:52 (external edit)