- Ordonnancement et mise en file d'attente Catalyst 3550 - QOS - Ordonnancement et mise en file d'attente ccnp_cch ccnp_cch

Sommaire • Introduction - Composants utilisés • Capacités de mise en file d'attente sur Catalyst 3550 - Fonctionnalités supportées par les ports Gigabit et non-Gigabit - Fonctionnalités supportées uniquement par les ports Gigabit - Fonctionnalités supportées uniquement par les ports non-Gigabit • Correspondance CoS et file d'attente • File d'attente de priorité stricte (PQ) • Weighted Round robin sur Catalyst 3550 • WRED sur Catalyst 3550 • Elimination en fin de file d'attente sur Catalyst 3550 • Configuration de la taille de la file d'attente sur ports Gigabit • Gestion de file et taille de la file d'attente sur ports non-gigabits • Conclusion ccnp_cch

Introduction ccnp_cch L'ordonnancement en sortie est utilisé pour assurer que du trafic important n'est pas éli- miné en cas de sur-utilisation de la sortie d'une interface. Ce document décrit toutes les techniques et algorithmes inclus dans l'ordonnancement de la sortie sur un commuta- teur Catalyst 3550. Ce document se focalise également sur comment configurer et véri- fier le fonctionnement de l'ordonnancement de sortie sur commutateur Catalyst 3550. Composants utilisés Ce document a été écrit en utilisant un commutateur Catalyst 3550 opérant avec une Release IOS 12.1(12c)EA1. Capacités de mise en file d'attente en sortie des ports des commutateurs Catalyst 3550 Il y a deux types de ports sur les commutateurs Catalyst 3550: les ports Gigabit et les ports non-Gigabit (Ports 10/100 Mb/s). Ces deux types de ports ont des capacités dif- férentes. Ces capacités sont résumées ci-après et sont expliquées plus en détail par la suite. Fonctionnalités supportées par les ports Gigabit et non-Gigabit Chaque port sur le Catalyst 3550 a quatre files d'attente différentes en sortie. Une de ces files peut être configurée en file de priorité stricte. Les files restantes sont configu- rées comme files non prioritaires et sont servies en utilisant WRR (Weigthed Round Ro- bin). Sur tous les ports, la trame est affectée à une des quatre files possibles sur la ba- se de leurs CoS (Class of Service). Fonctionnalités supportées uniquement par les ports Gigabit Les ports Gigabit supportent également un mécanisme de gestion de file d'attente pour chaque file. Chaque file peut être configurée pour utiliser soit WRED (Weigthed Random Early Discard) ou l'élimination en fin de file avec deux seuils. Le trafic de chaque file peut être optimisé (buffers alloués à chaque file). Fonctionnalités supportées uniquement par les ports non-Gigabit Les ports non-Gigabit n'ont aucun mécanisme tel que WRED ou l'élimination en fin de file avec deux seuils. Seule la mise en file d'attente FIFO est supportée sur un port 10/100 Mb/s. Vous ne pouvez pas changer la taille des files sur ces ports. Vous pouvez par contre affecter une taille de résrvation minimale par file. ccnp_cch

Correspondance CoS avec file d'attente Cette section décrit comment le Catalyst 3550 décide de placer chaque trame dans une file d'attente. Une trame est placée dans une file d'après la CoS. chacune des huit va- leurs de CoS sera mappée avec une des quatre files possibles en utilisant la commande de mapping de CoS avec une file d'attente sur une interface. (config−if)# wrr−queue cos−map queue−id cos1... cos8 Un exemple est montré ci-dessous: 3550(config−if)# wrr−queue cos−map 1 0 1 3550(config−if)# wrr−queue cos−map 2 2 3 3550(config−if)# wrr−queue cos−map 3 4 5 3550(config−if)# wrr−queue cos−map 4 6 7 Cet exemple place CoS 0 et 1 dans la file Q1, CoS 2 et 3 dans la file Q2, CoS 4 et 4 dans la file Q3, CoS 6 et 7 dans la file Q4. Le mapping de la CoS avec une file d'attente peut être vérifié en utilisant la commande suivante: cat3550# sh mls qos int gig 0/1 queueing GigabitEthernet0/1 ...Cos−queue map: cos−qid 0 − 1 1 − 1 2 − 2 3 − 2 4 − 3 5 − 3 6 − 4 7 − 4... File de priorité stricte Une file de priorité stricte est toujours servie en premier. Cela signifie que dès qu'il y a une trame dans la file de priorité stricte, la trame est acheminée. Après l'acheminement d'une trame des autres files WRR, la file de priorité stricte est examinée et servie si cela est nécessaire. Une file de priorité stricte est spécialement conçue pour du trafic sensible au délai et à la gigue comme le trafic voix. Une file de priorité stricte entrainer une manque de servi- ce des autres files. Les trames placées dans les autres files WRR ne seront jamais ache- minées si une trame est toujours en attente dans la file de priorité stricte. ccnp_cch

Conseils Pour éviter le manque de service des autres files, portez attention au trafic qui est placé dans la file de priorité stricte. Cette file est typiquement utilisée pour du trafic voix qui normalement génère un faible volume de trafic. Si quelqu'un est capable de transmet- tre un grand volume de trafic avec une priorité CoS allant vers la file de priorité stricte (tel que transfert de fichiers très volumineux ou un backup) cela peut mener à un man- que de service pour l'autre trafic. Pour éviter ce problème, le trafic particulier doit être placé dans la classification/admission et marquage du trafic dans le réseau. Par exem- ple, vous pouvez prendre les précautions suivantes: ● Utiliser un état de QoS non fiable pour tous les ports source non fiables. ● Utiliser la fonctionnalité de port frontière fiable d'un port IP phone Cisco pour être sur qu'il n'est pas utilisé dans l'état fiable pour une autre application. ● Appliquer une politique pour le trafic qui va dans la file d'attente de priorité stricte. Fixer une limite pour la politique de trafic avec une CoS de 5 (DSCP 46) à 100 Mb/s pour un port Gigabit. Pour plus d'informations sur ces points, référez-vous aux documents suivants: ● Comprendre la Politique de QoS et le Marquage sur Catalyst 3550 ● Limite de confiance tierce partie sur Catalyst 3550. Sur le Catalyst 3550, vous pouvez configurer une file d'attente pour être la file de priori- té stricte (toujours Q4) en utilisant cette commande en mode de configuration interface. 3550(config−if)# priority−queue out Si la file de priorité stricte n'est pas configurée sur une interface, Q4 est considérée comme une file WRR standard. Vous pouvez vérifier si la file de priorité stricte est con- figurée sur une interface en entrant la commande listée ci-dessous. NifNif#sh mls qos interface gig 0/1 queueing GigabitEthernet0/1 Egress expedite queue: ena Weighted Round Robin sur Catalyst 3550 WRR est un mécanisme utilisé dans l'ordonnancement en sortie sur le commutateur Catalyst 3550. WRR fonctionne avec trois ou quatre files (s'il n'y a pas de file de priorité stricte). Les files utilisées dans WRR sont vidées par scrutation circulaire pondérée et vous pouvez configurer un poids sur chaque file. Par exemple, les poids peuvent être configurés pour que les files soient servies différem- ment comme cela est montré ci-dessous. ● Service WRR de Q1 : 10% du temps ● Service WRR de Q2 : 20% du temps ● Service WRR de Q3 : 60% du temps ● Service WRR de Q4 : 10% du temps ccnp_cch

Pour chaque file vous pouvez configurer quatre poids (un associé à chaque file) en en- trant la commande suivante: (config−if)#wrr−queue bandwidth weight1 weight2 weight3 weight4 Un exemple est donné ci-dessous: 3550(config)# interface gigabitethernet0/1 3550(config−if)# wrr−queue bandwidth 1 2 3 4 Note: Les poids sont relatifs. Les valeurs suivantes sont utilisées: ● Q1 = weight 1 /(weight1 + weight2 + weight3 + weight4) = 1/(1+2+3+4) = 1/10 ● Q2 = 2/10 ● Q3 = 3/10 ● Q4 = 4/10 WRR peut être implémenté de deux manières: 1. WRR par bande passante : Chaque poids représente une bande passante spécifique pour transmettre. Le poids de Q1 autorise approximativement 10% de la bande pas- sante, Q2 aura 20% de la bande passante et ainsi de suite. Ce système est implé- menté uniquement sur la famille Catalyst 6000 pour l'instant. 2. WRR par paquet : C'est l'algorithme implémenté dans le Catalyst 3550. Ceci veut dire que chaque poids représente un certain nombre de paquets à émettre sans te- nir compte de leur taille. Comme le commutateur Catalyst implémente WRR par paquet, le comportement sui- vant s'applique à la configuration affichée précédemment. ● Q1 transmission de 1 paquet sur 10 ● Q2 transmission de 2 paquets sur 10 ● Q3 transmission de 3 paquets sur 10 ● Q4 transmission de 4 paquets sur 10 Cela est très bien si tous les paquets à transmettre sont tous de la même taille. Vous atteindrez toujours un partage attendu parmi les quatre files. Si la taille moyenne des paquets est différente entre les files, cela a un énorme impact entre ce qui est transmis et ce qui est éliminé en cas de congestion. Par exemple supposons que nous n'avons que deux flux présents sur le commutateur. On suppose également que les conditions sont les suivantes: ● Un trafic de 1 gigabit/s pour du trafic applicatif interactif (80 octets par trame) avec une CoS de 3 placée dans la file Q2. ● Un trafic de 1 gigabit/s pour du transfert de fichiers (1518 octets par trame) avec une CoS de 0 placée dans Q1. Deux files du commutateur seront utilisées pour un débit en sortie de 1 gigabit/s. ccnp_cch

Les deux flux ont besoin de partager le même port Gigabit Les deux flux ont besoin de partager le même port Gigabit. Supposons également qu'un poids égal est configuré pour les files Q1 et Q2. WRR est appliqué par paquet et le volu- me de données transmis pour chaque file sera différent. Le même volume de paquets sera acheminé en sortie de la file mais le commutateur transmet actuellement le volume de données suivant: 77700 paquets par seconde en sortie de Q2 = (77700 x 8 x 64) bit/s (autour de 52 Mb/s) 77700 paquets par seconde en sortie de Q1 = (77700 x 8 x 1500) bit/s (autour de 948 Mb/s) Conseils ● Si vous voulez permettre un accès au réseau équitable pour chaque file, prenez en compte la taille moyenne des paquets. Chaque paquet est sensé être placé dans une file et le poids sera modifié en fonction de cette taille moyenne. Par exemple, si vous voulez donner un accès égal à chacune des quatre files (chaque file doit obtenir ¼ de la bande passante), le trafic sera le suivant: - Dans la file Q1: Trafic Internet Best effort . Suppose que le trafic a une taille moyenne de paquet de 256 octets. - Dans la file Q2: Backup composé de transfert de fichier avec un taille moyenne de packet de 1500 octets. - Dans la file Q3: Flux Vidéo qui sont composés de paquets de 192 octets. - Dans la file Q4: Application Interactive composée de paquets de 64 octets. Ceci crée les conditions suivantes: - Q1: Consomme 4 fois la bande passante allouée à Q4. - Q2: Consomme 24 fois la bande passante allouée à Q4. - Q3: Consomme 3 fois la bande passante allouée à Q4. Pour avoir un accès égal en bande passante, il faut configurer: - Q1 avec un poids de 6 - Q2 avec un poids de 1 - Q3 avec un poids de 8 - Q4 avec un poids de 24 ● Si les poids ci-dessus sont affectés, un partage égal de bande passante parmi les quatre files sera réalisé en cas de congestion. ● Si une file de priorité stricte est validée, les poids WRR sont redistribués par les trois restantes. Le premier exemple avec les poids 1,2,3 et 4 serait comme suit si la file de priorité stricte est validée et Q4 n'est pas configurée. - Q1 = 1 / (1+2+3) = 1 paquet sur 6 - Q2 = 2 paquets sur 6 ¨ - Q3 = 3 paquets sur 6 ccnp_cch

Le poids de file peut être vérifié en entrant la commande show de l'IOS. NifNif#sh mls qos interface gig 0/1 queueing GigabitEthernet0/1 QoS is disabled. Only one queue is used When QoS is enabled, following settings will be applied Egress expedite queue: dis wrr bandwidth weights: qid−weights 1 − 25 2 − 25 3 − 25 4 − 25 Si la file de priorité stricte est validée, le poids de de la file Q4 n'est pas utilisé. Un exemple est donné ci-dessous. NifNif#sh mls qos interface gig 0/1 queueing Egress expedite queue: ena WRED sur Catalyst 3550 WRED est disponible uniquement sur les ports Gigabit des commutateurs de la famille Catalyst 3550. WRED est une modification de RED qui est utilisé pour l'évitement de congestion. RED a les paramètres suivants: ● min-threshold : représente un seuil dans la file. En dessous de ce seuil les trames ne seront pas éliminées. ● max-threshold : représente un autre seuil dans la file. Toutes les trames au dessus de ce seuil seront éliminées. ● slope : probabilité d'élimination de la trame entre les seuils min et max. La probabili- té d'élimination augmente linéairement (avec une certaine pente) avec la taille de la file. La probabilité d'élimination d'une trame dans la file RED est montrée dans le schém a ci-dessous. Notez que tous les commutateurs Catalyst qui doivent implémenter RED permettent d'ajuster la pente. ccnp_cch

Pourcentage de trames éliminées Longueur de file Seuil Minimum Maximum 100% 1. RED avec pente ajustable Pente Linéaire Pourcentage de trames éliminées 100% 2. RED sans pente ajustable Pente Linéaire Longueur de file Seuil Minimum Seuil Maximum Dans WRED, différents services sont pondérés. Vous pouvez définir un service standard et un service premium. Chaque service reçoit un ensemble de seuils. Seuls les trames affectées au service standard sont éliminées quand min-threshold 1 est atteint. Seules les trames du service premium seront éliminées quand min-threshold 2 sera atteint. Si min-threshold 2 est supérieur à min-threshold 1 plus de trames du service standard seront éliminées par rapport aux trames du service premium. Le schéma ci- après mon- tre un exemple de probabilité d'élimination de trames pour chaque service WRED. Les commutateurs Catalyst ne permettent pas d'ajuster le min-threshold, seul le seuil max-threshold. Le min-threshold est toujours fixé à 0 par le matériel. Cela donne une représentation de la probabilité d'élimination qui est implémentée dans le commutateur Catalyst 3550. ccnp_cch

Pourcentage de trames éliminées Pourcentage de trames éliminées 100% 3. WRED avec 2 ensemles de seuils mini et maxi (2 services) Longueur de file Standard Seuil Minimum 1 Premium Seuil Minimum 2 Standard Seuil Maximum Premium Seuil Maximum Pourcentage de trames éliminées 100% 4. WRED avec 2 ensemles de seuils mais avec min-threshold=0 Longueur de file Standard Seuil Maximum Premium Seuil Maximum Toute file avec WRED validé sur le commutateur Catalyst 3550 a toujours une probabi- lité d'élimination non nulle et élimine toujours des trames. Ceci est le résultat de la va- leur du min-threshold qui est toujours fixée à 0. Si l'élimination de trames doit être évi- tée il est bon d'utiliser une élimination en fin de file pondérée comme cela est décrit dans la section suivante. Sur le commutateur Catalyst 3550 WRED peut être configuré avec deux max-threshold différents pour fournir deux services différents. Différents types de trafic seront affectés aux deux seuils selon leurs DSCP (Differentiated Service Code Point). Ceci est différent de l'affectation de file qui dépend uniquement de la CoS de la trame. Une table de cor- respondance DSCP et seuil indique que le seuil sera affecté à chacun des 64 DSCPs. Cette table peut être affichée et modifiée en exécutant la commande suivante: (config−if)# wrr−queue dscp−map threshold_number DSCP_1 DSCP_2 DSCP_8 ccnp_cch

Par exemple, la commande montrée ci-dessous affecte DSCP 26 au seuil 2 Par exemple, la commande montrée ci-dessous affecte DSCP 26 au seuil 2. NifNif(config−if)#wrr−queue dscp−map 2 26 NifNif#sh mls qos int gig 0/1 queue GigabitEthernet0/1 Dscp−threshold map: d1 : d2 0 1 2 3 4 5 6 7 8 9 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 02 01 01 01 2 : 01 01 01 01 02 01 02 01 01 01 3 : 01 01 01 01 01 01 01 01 01 01 4 : 02 01 01 01 01 01 02 01 01 01 5 : 01 01 01 01 01 01 01 01 01 01 6 : 01 01 01 01 Une fois que le mapping DSCP-Seuil a été défini, WRED est validé sur la file de votre choix. Cela est fait en exécutant la commande suivante: (config−if)# wrr−queue random−detect max−thresold Queue_id Threshold_1 Threshold_2 L'exemple montré ci-dessous configure la file Q1 avec un seuil 1 égal à 50% et un seuil 2 égal à 100%, la file Q2 avec un seuil 1 égal à 70% et un seuil 2 égal à 100%. 3550(config)# interface gigabitethernet0/1 3550(config−if)# wrr−queue random−detect max−threshold 1 50 100 3550(config−if)# wrr−queue random−detect max−threshold 2 70 100 3550(config−if)# wrr−queue random−detect max−threshold 3 50 100 3550(config−if)# wrr−queue random−detect max−threshold 4 70 100 Vous pouvez vérifier le type de gestion (WRED ou non) sur chaque file en entrant la commande suivante: nifnif#sh mls qos int gi 0/1 buffers .. qid WRED thresh1 thresh2 1 dis 10 100 2 dis 10 100 3 ena 10 100 4 dis 100 100 ena signifie enable et la file utilise WRED, dis signifie disable et la file utilise l'élimina- tion en fin de file. Vous pouvez également superviser le nombre de paquets éliminés pour chaque seuil en utilisant la commande suivante.: sh mls qos int gig x/x stat WRED drop counts: qid thresh1 thresh2 FreeQ 1 : 327186552 8 1024 2 : 0 0 1024 3 : 37896030 0 1024 4 : 0 0 1024 ccnp_cch

Configuration de la taille de la file d'attente sur ports Gigabit Elimination en fin de file sur commutateur Catalyst 3550 L'élimination en fin de file est le mécanisme par défaut sur les ports Gigabit sur le com- mutateur Catalyst 3550. Chaque port Gigabit a deux seuils d'élimination en fin de file. Un ensemble de DSCPs est affecté à chaque seuil d'élimination en fin de file en utilisant la même correspondance DSCP-Seuil défini dans la section WRED de ce document. Quand un seuil est atteint, les paquets avec un DSCP affecté à ce seuil sont éliminés. Les seuils d'élimination en fin de file peuvent être configurés en entrant la commande suivante: (config−if)# wrr−queue threshold queue−id threshold−percentage1 threshold−percentage2 L'exemple ci-dessous configure la file Q1 avec le seuil d'élimination en fin de file 1 égal à 50%, le seuil 2 égal à 100% et la file Q2 avec un seuil 1 égal à 70% et un seuil 2 égal à 100%. Switch(config−if)# wrr−queue threshold 1 50 100 Switch(config−if)# wrr−queue threshold 2 70 100 Switch(config−if)# wrr−queue threshold 3 60 100 Switch(config−if)# wrr−queue threshold 4 80 100 Configuration de la taille de la file d'attente sur ports Gigabit Le commutateur Catalyst 3550 utilise le buffering centralisé. Cela signifie qu'il n'y a pas de tailles fixes de buffers par port. Il y a toutefois un nombre maximum de paquets pouvant être mis en file d'attente sur un port Gigabit. Cette valeur maximum est fixée à 4096. Par défaut chaque file d'un port Gigabit peut avoir jusqu'à 1024 paquets sans tenir compte de la taille du paquet. Vous pouvez cependant modifier la manière avec laquelle ces paquets sont distribués parmi ces quatre files en utilisant les commandes suivantes: wrr−queue queue−limit Q_size1 Q_size2 Q_size3 Q_size4 Un exemple est donné ci-dessous: 3550(config)# interface gigabitethernet0/1 3550(config−if)# wrr−queue queue−limit 4 3 2 1 Les tailles de files sont relatives. L'exemple ci-dessus montre que Q1 sera quatre fois plus grande que Q4, Q2 trois fois plus grande que Q4 et Q3 deux fois plus grande que Q4. Les 4096 paquets sont distribués comme suit: Q1 = [4 /(1+2+3+4) ] * 4096 = 1639 paquets · Q2 = 0.3 * 4096 = 1229 paquets · Q3 = 0.2 * 4096 = 819 paquets · Q4 = 0.1 * 4096 = 409 paquets · ccnp_cch

La commande suivante vous permet de voir les poids relatifs des buffers partagés entre les quatre files: cat3550# sh mls qos int buffers GigabitEthernet0/1 Notify Q depth: qid−size 1 − 4 2 − 3 3 − 2 4 − 1 ... Vous pouvez également voir combien de paquets chaque file contient en utilisant la commande suivante: cat3550# sh mls qos int gig x/x stat WRED drop counts: qid thresh1 thresh2 FreeQ 1 : 0 0 1639 2 : 0 0 1229 3 : 0 0 819 4 : 0 0 409 Le paramètte FreeQ est dynamique. Le compteur FreeQ donne le nombre de paquets dans la file en affichant la différence taille maximum de la file moins le nombre de pa- quets contenus dans la file. par exemple, s'il y a 39 paquets dans la file Q1, la valeur de FreeQ indique 1600 buffers libres comme cela est montré ci-dessous: cat3550# sh mls qos int gig x/x stat 1 : 0 0 1600 2 : 0 0 1229 3 : 0 0 819 4 : 0 0 409 ccnp_cch

Gestion de file et taille de file sur les ports non-Gigabit Il n'y a pas de gestion de file disponible sur les ports 10/100 Mb/s (pas de WRED ou d'élimination en fin de file avec deux seuils). Les quatre files sont des files FIFO. Il n'y a pas de taille maximum de 4096 paquets sur chaque port. Les ports 10/100 stockent les paquets dans les files jusqu'à ce qu'elles soient pleines. Vous pouvez réserver une taille minimum de file. Ce minimum est fixé à 100 paquets par file par défaut. Vous pouvez modifier cette valeur minimum de réservation par défaut pour chaque file en définissant des valeurs de réservation minimum et en affectant ces valeurs à chacune des files. Ceci peut être fait en exécutant les étapes suivantes: 1. Affecter une taille de buffer pour chaque valeur de réservation minimum Vous pouvez également configurer un maximum de huit valeurs de réservation mini- mum différentes en utilisant la commande suivante: NifNif(config)# mls qos min−reserve min−reserve−level min−reserve−buffersize Ces valeurs de réservation minimum sont globales pour le commutateur. Par défaut toutes les valeurs min-reserve sont fixées à 100 paquets. Par exemple pour configurer un premier niveau de réservation minimum de 150 pa- quets et un deuxième niveau de réservation minimum de 50 paquets, utilisez les com- mandes suivantes: nifnif(config)#mls qos min−reserve ? <1−8> Configure min−reserve level nifnif(config)#mls qos min−reserve 1 ? <10−170> Configure min−reserve buffers nifnif(config)#mls qos min−reserve 1 150 nifnif(config)#mls qos min−reserve 2 50 2. Affecter une des valeurs de réservation minimum à chacune des files. Chacune des files doit avoir une des valeurs de réservation minimum affectée pour savoir combien de buffers sont garantis pour cette file. Par défaut les conditions sui- vantes sont appliquées: Q1 a la valeur min−reserve level 1 affectée. Q2 a la valeur min−reserve level 2 affectée. Q3 a la valeur min−reserve level 3 affectée. Q4 a la valeur min−reserve level 4 affectée. Par défaut toutes les réservations minimum sont égales à 100. Une valeur de réservation minimum peut être affectée par file en utilisant la com- mande suivante en mode interface: (config−if)# wrr−queue min−reserve queue−id min−reserve−level ccnp_cch

Par exemple pour affecter à Q1 une valeur de réservation minimum de niveau 1 et à Q2 une valeur de réservation minimum de niveau 2, utilisez les commandes suivantes: nifnif(config)#int fas 0/1 nifnif(config−if)#wrr−queue min−reserve ? <1−4> queue id nifnif(config−if)#wrr−queue min−reserve 1 ? <1−8> min−reserve level nifnif(config−if)#wrr−queue min−reserve 1 2 nifnif(config−if)#wrr−queue min−reserve 2 1 Le résultat de l'affectation de réservation minimum est vérifié en entrant la commande suivante: nifnif#sh mls qos int fas 0/1 buffers FastEthernet0/1 Minimum reserve buffer size: 150 50 100 100 100 100 100 100 !−−− Montre les valeurs des huit niveaux de réservation minimum. Minimum reserve buffer level select: 2 1 3 4 !−−− Montre le niveau de réservation minimum affecté !−−− à chaque file (de Q1 à Q4). Conclusion L'ordonnancement et la gestion de files d'attente sur un port de Catalyst 3550 demande l'exécution des étapes suivantes: 1. Affecter une CoS à chaque file. 2. Valider la file de priorité stricte (si nécessaire). 3. Affecter un poids WRR prenant en compte la taille de paquet attendue dans la file. 4. Modification des tailles de files (Ports Gigabit uniquement). 5. Valider le mécanisme de gestion de file (WRED ou élimination en fin de file sur les ports Gigabit uniquement). Un ordonnancement et une gestion de files bien appropriés peuvent réduire le délai/la variation de délai pour le trafic Voix/Vidéo, d'éviter les pertes pour du trafic critique. Assurez d'être conformes aux recommandations suivantes pour une performance ma- ximale de l'ordonnancement: ● Classifier le trafic présent dans le réseau en différentes classes par marquage. ● Appliquer une politique de trafic pour le trafic en excès. ccnp_cch