Planification QoS et mise en file d'attente sur les commutateurs Catalyst 3550

Introduction

La planification de sortie veille à ce que le trafic important ne soit pas abandonné en cas de surabonnement lourd à la sortie d’une interface. Ce document aborde toutes les techniques et les algorithmes qui sont impliqués dans la planification de sortie sur le commutateur Cisco Catalyst 3550. Ce document se concentre également sur la façon de configurer et vérifier l’exécution de la planification de sortie sur les commutateurs Catalyst 3550.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Les informations de ce document sont basées sur le Catalyst 3550 qui exécute le logiciel Cisco IOS® Version 12.1(12c)EA1.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Fonctionnalité de mise en file d'attente de sortie des ports sur les commutateurs Catalyst 3550

Il existe deux types de ports sur les commutateurs 3550 :

• Ports Gigabit

• Ports non Gigabit (port 10/100 Mbits/s)

Ces deux ports ont des fonctionnalités différentes. Le reste de cette section résume ces fonctionnalités. Les autres sections de ce document expliquent en détail les fonctionnalités.

Fonctionnalités prises en charge par les ports Gigabit et non Gigabit

Chaque port du 3550 comporte quatre files d'attente de sortie différentes. Vous pouvez configurer l'une de ces files d'attente comme file d'attente de priorité stricte. Chacune des files d'attente restantes est configurée en tant que files d'attente de priorité non strictes et est traitée à l'aide du WRR (Weighted Round-Robin). Sur tous les ports, le paquet est attribué à l’une des quatre files d’attente possibles en fonction de la classe de service (CoS).

Fonctionnalités prises en charge uniquement par les ports Gigabit

Les ports Gigabit prennent également en charge un mécanisme de gestion des files d'attente dans chaque file d'attente. Vous pouvez configurer chaque file d'attente pour qu'elle utilise la détection WRED (Weighted Random Early Detection) ou la suppression de queue avec deux seuils. Vous pouvez également régler la taille de chaque file d'attente (la mémoire tampon qui est affectée à chaque file d'attente).

Fonctionnalités prises en charge uniquement par les ports non Gigabit

Les ports non Gigabit ne disposent d'aucun mécanisme de mise en file d'attente, tel que WRED ou tail drop avec deux seuils. Seule la mise en file d'attente FIFO sur un port 10/100 Mbits/s est prise en charge. Vous ne pouvez pas modifier la taille de chacune des quatre files d'attente sur ces ports. Cependant, vous pouvez affecter une taille minimale (min) de réserve par file d'attente.

Mappage CoS/file d'attente

Cette section explique comment le 3550 décide de placer chaque paquet dans une file d'attente. Le paquet est placé dans la file d’attente sur la base de la CoS. Chacune des huit valeurs CoS possibles est mappée à l'une des quatre files d'attente possibles à l'aide de la commande d'interface CoS-to-queue map que cet exemple montre :

(config-if)#wrr-queue cos-map queue-id cos1... cos8

Voici un exemple :

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 montre comment :

• CoS 0 et 1 dans la file d'attente 1 (Q1)

• CoS 2 et 3 au 2e trimestre

• CoS 4 et 5 au 3e trimestre

• CoS 6 et 7 au 4e trimestre

Vous pouvez émettre cette commande afin de vérifier le mappage CoS-to-queue d'un port :

cat3550#show mls qos interface gigabitethernet0/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 d'attente de priorité stricte

Une file d'attente de priorité stricte est toujours vidée en premier. Ainsi, dès qu'il y a un paquet dans la file d'attente de priorité stricte, le paquet est transféré. Une fois chaque paquet transféré à partir d'une des files d'attente WRR, la file d'attente de priorité stricte est vérifiée et vidée si nécessaire.

Une file d'attente de priorité stricte est spécialement conçue pour le trafic sensible aux retards/gigue, tel que la voix. Une file d'attente de priorité stricte peut finir par provoquer la famine des autres files d'attente. Les paquets placés dans les trois autres files d’attente WRR ne sont jamais transférés si un paquet attend dans la file d’attente de priorité stricte.

Conseils

Afin d'éviter la famine des autres files d'attente, prêtez une attention particulière au trafic placé dans la file d'attente prioritaire. Cette file d'attente est généralement utilisée pour le trafic vocal, dont le volume n'est généralement pas très élevé. Cependant, si quelqu'un est capable d'envoyer un trafic de volume élevé avec la priorité CoS à la file d'attente de priorité stricte (comme le transfert de fichiers volumineux ou la sauvegarde), la famine d'autres trafics peut en résulter. Pour éviter ce problème, un trafic spécifique doit être placé dans la classification/admission et le marquage du trafic sur le réseau. Par exemple, vous pouvez prendre les précautions suivantes :

• Utilisez l'état QoS du port non approuvé pour tous les ports source non approuvés.

• Utilisez la fonctionnalité de limite approuvée pour le port du téléphone IP Cisco afin de vous assurer qu'il n'est pas utilisé dans l'état d'approbation configuré pour un téléphone IP pour une autre application.

• Contrôlez le trafic qui va à la file d'attente de priorité stricte. Définissez une limite de contrôle du trafic avec une CoS de 5 (point de code de services différenciés [DSCP] 46) à 100 Mo sur un port Gigabit.

Pour plus d'informations sur ces sujets, reportez-vous aux documents suivants :

• Présentation de la réglementation et de la signalisation QoS (Qualité de service) sur Catalyst 3550

• Configuration d'une frontière de confiance pour assurer la sécurité des ports section Configuration de la QoS (Catalyst 3500)

Sur le modèle 3550, vous pouvez configurer une file d'attente comme file d'attente prioritaire (toujours Q4). Utilisez cette commande en mode interface :

3550(config-if)#priority-queue out

Si la file d'attente prioritaire n'est pas configurée dans une interface, le Q4 est considéré comme une file d'attente WRR standard. La section Weighted Round-Robin on Catalyst 3550 de ce document fournit plus de détails. Vous pouvez vérifier si la file d'attente de priorité stricte est configurée sur une interface si vous émettez la même commande Cisco IOS :

NifNif#show mls qos interface gigabitethernet0/1 queueing 
GigabitEthernet0/1
Egress expedite queue: ena

Robin circulaire pondéré sur Catalyst 3550

WRR est un mécanisme utilisé dans la planification de sortie sur le 3550. WRR fonctionne entre trois ou quatre files d'attente (s'il n'y a pas de file d'attente de priorité stricte). Les files d'attente utilisées dans le WRR sont vidées de manière circulaire et vous pouvez configurer le poids de chaque file d'attente.

Par exemple, vous pouvez configurer les poids de sorte que les files d'attente soient desservies différemment, comme le montre cette liste :

• Q1 du WRR de service : 10 % du temps

• Q2 WRR de service : 20 % du temps

• Q3 du WRR de service : 60 % du temps

• Q4 du WRR de service : 10 % du temps

Pour chaque file d'attente, vous pouvez émettre ces commandes en mode interface afin de configurer les quatre poids (dont un associé à chaque file d'attente) :

(config-f)#wrr-queue bandwidth weight1 weight2 weight3 weight4

Voici un exemple :

3550(config)#interface gigabitethernet 0/1
3550(config-if)#wrr-queue bandwidth 1 2 3 4

Note : Les poids sont relatifs. Ces valeurs sont utilisées :

• Q1 = poids 1 / (poids1 + poids2 + poids3 + poids4) = 1 / (1+2+3+4) = 1/10

• 2e trimestre = 2/10

• 3e trimestre = 3/10

• Q4 = 10/4

WRR peut être mis en oeuvre de deux manières :

• WRR par bande passante : Chaque poids représente une bande passante spécifique autorisée à être envoyée. Le Q1 de poids peut disposer d'environ 10 % de la bande passante, le T2 de 20 % de la bande passante, etc. Ce schéma n'est actuellement mis en oeuvre que dans la gamme Catalyst 6500/6000.

• WRR par paquet : Il s’agit de l’algorithme mis en oeuvre dans le commutateur 3550. Chaque poids représente un certain nombre de paquets à envoyer, quelle que soit leur taille.

Lorsque le 3550 implémente le WRR par paquet, ce comportement s'applique à la configuration de cette section :

• Q1 transmet 1 paquet sur 10

• Q2 transmet 2 paquets sur 10

• Le 3e trimestre transmet 3 paquets sur 10

• Le 4e trimestre transmet 4 paquets sur 10

Les paquets à transmettre peuvent tous avoir la même taille. Vous parvenez toujours à un partage prévisible de la bande passante entre les quatre files d’attente. Cependant, si la taille moyenne des paquets est différente entre les files d’attente, il y a un impact important sur ce qui est transmis et abandonné en cas d’encombrement.

Par exemple, supposez que vous n'avez que deux flux présents dans le commutateur. Hypothétiquement, supposons également que ces conditions sont en place :

• Un Gbit/s de trafic d'applications interactives de petite taille (trames de 80 octets [B]) avec une CoS de 3 est placé au 2e trimestre.

• Un Gbit/s de trafic de transfert de fichiers volumineux (trames 1518-B) avec une CoS de 0 est placé au 1er trimestre.

Deux files d’attente dans le commutateur sont envoyées avec 1 Gbit/s de données.

Les deux flux doivent partager le même port Gigabit de sortie. Supposons que le poids égal est configuré entre Q1 et Q2. Le WRR est appliqué par paquet, et la quantité de données transmises à partir de chaque file d'attente varie entre les deux files d'attente. Le même nombre de paquets est transféré hors de chaque file d'attente, mais le commutateur envoie en fait cette quantité de données :

• 7 700 paquets par seconde (pps) sur Q2 = (7 7700 x 8 x 64) bits par seconde (environ 52 Mbits/s)

• 7 7700 pps sur Q1 = (7 7700 x 8 x 1 500) bits/s (environ 948 Mbits/s)

Conseils

• Si vous voulez autoriser un accès équitable à chaque file d'attente vers le réseau, prenez en compte la taille moyenne de chaque paquet. Chaque paquet doit être placé dans une file d'attente et son poids modifié en conséquence. Par exemple, si vous voulez donner un accès égal à chacune des quatre files d'attente, de sorte que chaque file d'attente reçoive 1/4 de la bande passante, le trafic est le suivant :

  • Au 1er trimestre : Trafic Internet au mieux. Supposez que le trafic a une taille de paquet moyenne de 256 B.

  • Au 2e trimestre : Sauvegarde composée de transfert de fichiers, avec un paquet principalement de 1500 B.

  • Au 3e trimestre : Flux vidéo, qui sont effectués sur des paquets de 192 B.

  • Au 4e trimestre : Application interactive composée principalement d'un paquet de 64 B.

  Ceci crée ces conditions :

  • Le T1 consomme 4 fois plus de bande passante que le T4.

  • Le 2e trimestre consomme 24 fois plus de bande passante que le 4e trimestre.

  • Le T3 consomme 3 fois plus de bande passante que le T4.

• Afin d'avoir un accès égal à la bande passante du réseau, configurez :

  • Q1 avec un poids de 6

  • Q2 avec un poids de 1

  • Q3 avec un poids de 8

  • 4e trimestre avec un poids de 24

• Si vous attribuez ces pondérations, vous obtenez un partage égal de bande passante entre les quatre files d'attente en cas d'encombrement.

• Si la file d'attente de priorité stricte est activée, les pondérations WRR sont redistribuées parmi les trois files d'attente restantes. Si la file d'attente de priorité stricte est activée et que le Q4 n'est pas configuré, le premier exemple avec des poids de 1, 2, 3 et 4 est :

  • Q1 = 1 / (1+2+3) = 1 paquet sur 6

  • Q2 = 2 paquets sur 6

  • Q3 = 3 paquets sur 6

  Vous pouvez émettre cette commande show du logiciel Cisco IOS afin de vérifier le poids de la file d'attente :

  NifNif#show mls qos interface gigabitethernet0/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 d'attente prioritaire d'accélération est activée, le poids du 4e trimestre n'est utilisé que si la file d'attente d'accélération est désactivée. Voici un exemple :

  NifNif#show mls qos interface gigabitethernet0/1 queueing 
  GigabitEthernet0/1
  Egress expedite queue: ena
  wrr bandwidth weights:
  qid-weights
   1 - 25
   2 - 25
   3 - 25
   4 - 25    
  
  !--- The expedite queue is disabled.
  
  

WRED sur les commutateurs Catalyst 3550

WRED est uniquement disponible sur les ports Gigabit des commutateurs de la gamme 3550. WRED est une modification de la détection précoce aléatoire (RED), utilisée pour éviter les encombrements. RED définit les paramètres suivants :

• Seuil min. : Représente un seuil dans une file d'attente. Aucun paquet n'est abandonné en dessous de ce seuil.

• Seuil maximal (max.) : Représente un autre seuil dans une file d'attente. Tous les paquets sont abandonnés au-dessus du seuil maximal.

• Pente : Probabilité de suppression du paquet entre la min et la max. La probabilité de chute augmente linéairement (avec une certaine pente) avec la taille de la file d'attente.

Ce graphique montre la probabilité de perte d'un paquet dans la file d'attente RED :

Remarque : Tous les commutateurs Catalyst qui implémentent le protocole RED vous permettent de régler la pente.

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 différent. Seuls les paquets affectés au service standard sont abandonnés lorsque le seuil minimum 1 est atteint. Seuls les paquets des services premium commencent à être supprimés lorsque le seuil minimum 2 est atteint. Si le seuil minimal 2 est supérieur au seuil minimal 1, plus de paquets du service standard sont supprimés que les paquets des services premium. Ce graphique montre un exemple de probabilité de perte pour chaque service avec WRED :

Remarque : Le commutateur 3550 ne vous permet pas de régler le seuil minimum, mais seulement le seuil maximum. Le seuil minimum est toujours défini sur 0. Ceci donne une probabilité de chute qui représente ce qui est actuellement mis en oeuvre dans le 3550.

Toute file d'attente activée pour WRED sur le 3550 a toujours une probabilité de perte non nulle et abandonne toujours les paquets. C'est le cas, car le seuil minimum est toujours 0. Si vous devez éviter une perte de paquets au maximum, utilisez la perte de queue pondérée, que la section Déclenchement de queue sur les commutateurs Catalyst 3550 décrit.

Conseil : ID de bogue Cisco CSCdz73556 (clients enregistrés uniquement) documente une demande d'amélioration pour la configuration du seuil min.

Pour plus d'informations sur RED et WRED, reportez-vous à la Vue d'ensemble de l'évitement d'encombrement.

Sur le 3550, vous pouvez configurer WRED avec deux seuils max différents afin de fournir deux services différents. Différents types de trafic sont attribués à l'un ou l'autre des seuils, qui dépendent uniquement des DSCP internes. Ceci diffère de l'affectation de file d'attente, qui dépend uniquement de la CoS du paquet. Un mappage de table DSCP-to-threshold détermine le seuil de chacun des 64 DSCP. Vous pouvez émettre cette commande afin de voir et modifier cette table :

(config-if)#wrr-queue dscp-map threshold_number DSCP_1 DSCP_2 DSCP_8

Par exemple, cette commande affecte DSCP 26 au seuil 2 :

NifNif(config-if)#wrr-queue dscp-map 2 26
NifNif#show mls qos interface gigabitethernet0/1 queueing
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 

Après avoir défini la carte DSCP-to-threshold, WRED est activé sur la file d'attente de votre choix. Émettez la commande suivante :

(config-if)#wrr-queue random-detect max-threshold queue_id threshold_1 threshold_2

Cet exemple permet de configurer les éléments suivants :

• Q1 avec seuil 1 = 50 % et seuil 2 = 100 %

• Q2 avec seuil 1 = 70 % et seuil 2 = 100 %

3550(config)#interface gigabitethernet 0/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 émettre cette commande afin de vérifier le type de file d'attente (WRED ou non) sur chaque file d'attente :

nifnif#show mls qos interface gigabitethernet0/1 buffers 
GigabitEthernet0/1
..
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 d'attente utilise WRED. Le dis signifie désactiver, et la file d'attente utilise la suppression de queue.

Vous pouvez également surveiller le nombre de paquets abandonnés pour chaque seuil. Émettez la commande suivante :

show mls qos interface gigabitethernetx/x statistics 
WRED drop counts:
  qid  thresh1    thresh2   FreeQ
   1 : 327186552  8         1024     
   2 : 0          0         1024      
   3 : 37896030   0         1024      
   4 : 0          0         1024

Abandon de queue sur les commutateurs Catalyst 3550

Tail drop est le mécanisme par défaut sur le 3550 sur les ports Gigabit. Chaque port Gigabit peut avoir deux seuils de perte arrière. Un ensemble de DSCP est attribué à chacun des seuils de perte arrière avec l'utilisation du même mappage de seuil DSCP que la section WRED sur les commutateurs Catalyst 3550 de ce document définit. Lorsqu'un seuil est atteint, tous les paquets avec un DSCP affecté à ce seuil sont abandonnés. Vous pouvez émettre cette commande afin de configurer les seuils de perte de queue :

(config-if)#wrr-queue threshold queue-id threshold-percentage1 threshold-percentage2

Cet exemple permet de configurer les éléments suivants :

• Q1 avec seuil de chute de queue 1 = 50 % et seuil 2 = 100 %

• Q2 avec seuil 1 = 70 % et seuil 2 = 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 les ports Gigabit

Le commutateur 3550 utilise la mise en mémoire tampon centralisée. Cela signifie qu'il n'y a pas de taille de tampon fixe par port. Cependant, un nombre fixe de paquets sur un port Gigabit peut être mis en file d'attente. Ce numéro fixe est 4096. Par défaut, chaque file d'attente d'un port Gigabit peut comporter jusqu'à 1 024 paquets, quelle que soit la taille du paquet. Cependant, vous pouvez modifier la façon dont ces 4096 paquets sont répartis entre les quatre files d'attente. Émettez la commande suivante :

wrr-queue queue-limit Q_size1 Q_size2 Q_size3 Q_size4

Voici un exemple :

3550(config)#interface gigabitethernet 0/1
3550(config-if)#wrr-queue queue-limit 4 3 2 1

Ces paramètres de taille de file d'attente sont relatifs. Cet exemple montre que :

• Le T1 est quatre fois plus grand que le T4.

• Le T2 est trois fois plus grand que le T4.

• Le T3 est deux fois plus grand que le T4.

Les paquets 4096 sont redistribués de cette manière :

• 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

Cette commande vous permet de voir les poids relatifs des tampons fractionnés parmi les quatre files d'attente :

cat3550#show mls qos interface buffers
GigabitEthernet0/1
Notify Q depth:
qid-size
1 - 4
2 - 3
3 - 2
4 - 1
...

Vous pouvez également émettre cette commande afin de voir combien de paquets libres chaque file d'attente peut encore contenir :

(config-if)#show mls qos interface gigabitethernetx/x statistics 
 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ètre FreeQ count est dynamique. Le compteur FreeQ indique la taille maximale de la file d'attente moins le nombre de paquets qui sont actuellement dans la file d'attente. Par exemple, s'il y a actuellement 39 paquets au 1er trimestre, 1600 paquets sont libres dans le compte FreeQ. Voici un exemple :

(config-if)#show mls qos interface gigabitethernetx/x statistics 
 WRED drop counts:
 qid  thresh1    thresh2   FreeQ
 1 : 0          0         1600    
 2 : 0          0         1229      
 3 : 0          0         819       
 4 : 0          0         409 

Gestion des files d'attente et taille des files d'attente sur les ports non Gigabit

Il n'existe aucun schéma de gestion de file d'attente disponible sur les ports 10/100 Mbits/s (pas de WRED ou de suppression de queue avec deux seuils). Les quatre files d'attente sont des files d'attente FIFO. Il n'y a pas non plus de taille de file d'attente maximale qui réserve 4 096 paquets pour chaque port Gigabit. Les ports 10/100 Mbits/s stockent les paquets dans chaque file d'attente jusqu'à ce qu'ils soient saturés en raison d'un manque de ressources. Vous pouvez réserver un nombre minimal de paquets par file d'attente. Ce minimum est défini sur 100 paquets par file d'attente par défaut. Vous pouvez modifier cette valeur de réserve minimale pour chaque file d'attente si vous définissez différentes valeurs de réserve minimale et affectez une des valeurs à chaque file d'attente.

Complétez ces étapes afin d'effectuer cette modification :

1. Attribuez une taille de tampon pour chaque valeur de réserve minimale globale.

   Vous pouvez configurer un maximum de huit valeurs de réserve min différentes. Émettez la commande suivante :

   (Config)# mls qos min-reserve min-reserve-level min-reserve-buffersize
   
   

   Ces valeurs de réserve minimale sont globales pour le commutateur. Par défaut, toutes les valeurs de réserve min sont définies sur 100 paquets.

   Par exemple, afin de configurer un niveau de réserve min 1 de 150 paquets et un niveau de réserve min 2 de 50 paquets, émettez ces commandes :

   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. Attribuez une des valeurs de réserve min. à chacune des files d'attente.

   Vous devez affecter chacune des files d'attente à l'une des valeurs de réserve minimale afin de savoir combien de tampons sont garantis pour cette file d'attente. Par défaut, ces conditions s'appliquent :

   • Q1 est affecté au niveau de réserve minimum 1.

   • Q2 est affecté au niveau de réserve minimum 2.

   • Q3 est affecté au niveau de réserve minimum 3.

   • Le T4 est affecté au niveau de réserve minimum 4.

   Par défaut, toutes les valeurs de réserve min sont 100.

   Vous pouvez émettre cette commande d'interface afin d'attribuer une valeur de réserve minimale différente par file d'attente :

   (config-if)#wrr-queue min-reserve queue-id min-reserve-level
   
   

   Par exemple, afin d'attribuer à Q1 une réserve min de 2 et à Q2 une réserve min de 1, émettez cette commande :

   nifnif(config)#interface fastethernet 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
   

   Vous pouvez émettre cette commande afin de vérifier l'affectation de réserve minimale qui donne les résultats suivants :

   nifnif#show mls qos interface fastethernet0/1 buffers 
   FastEthernet0/1
   Minimum reserve buffer size:
   150 50 100 100 100 100 100 100 
   
   !--- This shows the value of all eight min reserve levels.
   
   Minimum reserve buffer level select:
   2 1 3 4 
   
   !--- This shows the min reserve level that is assigned to !--- each queue (from Q1 to Q4).
   
   

Conclusion

La mise en file d'attente et la planification sur un port du 3550 impliquent les étapes suivantes :

1. Attribuez chaque CoS à l'une des files d'attente.

2. Activez les files d'attente de priorité stricte, si nécessaire.

3. Attribuez le poids WRR et tenez compte de la taille de paquet attendue dans la file d'attente.

4. Modifiez la taille de la file d'attente (ports Gigabit uniquement).

5. Activez un mécanisme de gestion de file d'attente (abandon de queue ou WRED, sur les ports Gigabit uniquement).

Une mise en file d'attente et une planification appropriées peuvent réduire les délais/gigue pour le trafic voix/vidéo et éviter les pertes pour le trafic stratégique. Veillez à respecter les consignes suivantes pour optimiser les performances de planification :

• Classez le trafic présent dans le réseau en différentes classes, avec un marquage de confiance ou spécifique.

• Trafic policier en excès.

Informations connexes

• Présentation de la réglementation et de la signalisation QoS (Qualité de service) sur Catalyst 3550
• Configuration de QoS - Documentation produit
• Pages de support pour les produits LAN
• Page de support sur la commutation LAN
• Support et documentation techniques - Cisco Systems