Commutation LAN : Qualité de service du LAN

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

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (6 octobre 2015) | Commentaires


Contenu


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.

Composants utilisés

Les informations dans ce document sont basées sur le Catalyst 3550 qui exécute la version de logiciel 12.1(12c)EA1 de ½ du ¿  de Cisco IOSïÂ.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

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

Capacité de la file d'attente de sortie de ports sur des Commutateurs du Catalyst 3550

Il y a deux types de ports sur 3550 Commutateurs :

  • Ports de gigabit

  • Le Non-gigabit met en communication (port 10/100-Mbps)

Ces deux ports ont différentes capacités. Le reste de cette section récapitule ces capacités. Les autres sections de ce document expliquent les capacités dans davantage de détail.

Caractéristiques que le gigabit et le Non-gigabit met en communication le support

Chaque port sur les 3550 a quatre files d'attente de sortie différentes. Vous pouvez configurer une de ces files d'attente comme file d'attente prioritaire stricte. Chacune des files d'attente restantes est configurée comme files d'attente prioritaire de nonstrict et est entretenue avec l'utilisation de circulaire pesé (WRR). Sur tous les ports, le paquet est assigné à une des quatre files d'attente possibles sur la base du Classe de service (Cos).

Caractéristiques que seulement le gigabit met en communication le support

Les ports de gigabit prennent en charge également un mécanisme de Gestion de file d'attente dans chaque file d'attente. Vous pouvez configurer chaque file d'attente pour utiliser le Détection précoce directe pondérée (WRED) ou la perte de destination avec deux seuils. En outre, vous pouvez accorder la taille de chaque file d'attente (la mémoire tampon qui est assignée à chaque file d'attente).

Caractéristiques que seulement le Non-gigabit met en communication le support

Les ports de Non-gigabit n'ont aucun mécanisme de mise en file d'attente tel que WRED ou perte de destination avec deux seuils. Seulement la mise en file d'attente FIFO sur un port 10/100-Mbps est prise en charge. Vous ne pouvez pas changer la taille de chacune des quatre files d'attente sur ces ports. Cependant, vous pouvez assigner une taille minimum de réserve (de minute) par file d'attente.

Mappage de Cos-à-file d'attente

Cette section discute comment les 3550 décide de placer chaque paquet dans une file d'attente. Le paquet est placé dans la file d'attente sur la base du cos. Chacune des huit valeurs CoS possibles est tracée à une des quatre files d'attente possibles avec l'utilisation de la commande d'interface de carte de Cos-à-file d'attente que cet exemple affiche :

(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 place :

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

  • Cos 2 et 3 dans Q2

  • Cos 4 et 5 dans Q3

  • Cos 6 et 7 dans Q4

Vous pouvez émettre cette commande afin de vérifier le mappage de Cos-à-file d'attente 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 prioritaire stricte

Une file d'attente prioritaire stricte est toujours vidée d'abord. Ainsi, dès qu'il y aura un paquet dans la file d'attente prioritaire stricte, le paquet est expédié. Après que chaque paquet soit expédié d'une des files d'attente WRR, la file d'attente prioritaire stricte est vérifiée et vidée s'il y a lieu.

Une file d'attente prioritaire stricte est particulièrement conçue pour le retard/trafic sensible au jitter, tel que la Voix. Une file d'attente prioritaire stricte peut par la suite entraîner la famine des autres files d'attente. Des paquets qui sont placés dans les trois autres files d'attente WRR ne sont jamais expédiés si un paquet attend dans la file d'attente prioritaire stricte.

Conseils

Afin d'éviter la famine des autres files d'attente, particulière attention de paiement à quel trafic est placé dans la file d'attente prioritaire. Cette file d'attente est typiquement utilisée pour le trafic vocal, le volume dont n'est typiquement pas très élevé. Cependant, si quelqu'un peut envoyer le trafic à fort débit avec la priorité de cos à la file d'attente prioritaire stricte (telle que le grand transfert de fichiers ou sauvegarde), la famine de l'autre trafic peut résulter. Afin d'éviter ce problème, le trafic spécial doit être placé dans la classification/admission et le marquage du trafic dans le réseau. Par exemple, vous pouvez prendre ces précautions :

  • Servez-vous de l'état non approuvé de QoS de port pour tous les ports non approuvés de source.

  • Servez-vous de la caractéristique de confiance de borne pour le port de téléphone IP de Cisco afin de s'assurer qu'il n'est pas utilisé dans le déclarer de confiance qui est configuré pour un téléphone IP pour une autre application.

  • Maintenez l'ordre le trafic qui va à la file d'attente prioritaire stricte. Fixez une limite pour maintenir l'ordre le trafic avec cos de 5 (point de code de Différenciation de services [DSCP] 46) à 100 Mo sur un port de gigabit.

Pour plus d'informations sur ces thèmes, référez-vous à ces documents :

Sur les 3550, vous pouvez configurer une file d'attente pour être la file d'attente prioritaire (qui est toujours Q4). Utilisez cette commande dans le mode interface :

3550(config-if)#priority-queue out

Si la file d'attente prioritaire n'est pas configurée dans une interface, Q4 est considéré comme file d'attente standard WRR. Le circulaire pesé sur le Catalyst 3550 sections de ce document fournit plus de détails. Vous pouvez vérifier si la file d'attente prioritaire 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

Circulaire pesé sur le Catalyst 3550

WRR est un mécanisme qui est utilisé dans la planification de sortie sur les 3550. WRR fonctionne entre trois ou quatre files d'attente (s'il n'y a aucune file d'attente prioritaire stricte). Les files d'attente qui sont utilisées dans le WRR sont vidées dans une permutation circulaire, et vous peuvent configurer le poids pour chaque file d'attente.

Par exemple, vous pouvez configurer des poids de sorte que les files d'attente soient servies différemment, car cette liste affiche :

  • Service WRR Q1 : 10 pour cent du temps

  • Service WRR Q2 : 20 pour cent du temps

  • Service WRR Q3 : 60 pour cent du temps

  • Service WRR Q4 : 10 pour cent du temps

Pour chaque file d'attente, vous pouvez émettre ces commandes dans le mode interface afin de configurer les quatre poids (un étant 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

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

  • Q1 = poids 1/(weight1 + weight2 + weight3 + weight4) = 1/(1+2+3+4) = 1/10

  • Q2 = 2/10

  • Q3 = 3/10

  • Q4 = 4/10

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

  • WRR par bande passante : Chaque poids représente une bande passante spécifique qui est permise pour être envoyée. On laisse le poids Q1 pour avoir approximativement 10 pour cent de la bande passante, Q2 obtient 20 pour cent de la bande passante, et ainsi de suite. Ce schéma est seulement mis en application dans la gamme Catalyst 6500/6000 à ce moment.

  • WRR par paquet : C'est l'algorithme qui est mis en application dans le commutateur 3550. Chaque poids représente un certain nombre de paquets qui doivent être envoyés, indépendamment de leur taille.

Comme 3550 mises en place WRR par paquet, ce comportement s'applique à la configuration dans cette section :

  • Q1 transmet le 1paquet sur 10

  • Q2 transmet 2 paquets sur 10

  • Q3 transmet 3 paquets sur 10

  • Q4 transmet 4 paquets sur 10

Les paquets à transmettre peuvent tout être la même taille. Vous atteignez toujours partager expectable de la bande passante parmi les quatre files d'attente. Cependant, si la taille moyenne des paquets est différente entre les files d'attente, il y a une grande incidence sur ce qui est transmis et relâché en cas de l'encombrement.

Par exemple, supposez que vous avez seulement deux écoulements actuels dans le commutateur. Hypothétiquement, supposez également que ces conditions sont en place :

  • GBP un du petit trafic de l'application interactif (trames [B] de 80 octets) avec cos de 3 est placés dans Q2.

  • GBP un du trafic de transfert de grand-FILE (trames 1518-B) avec cos de 0 est placés dans Q1.

Deux files d'attente dans le commutateur sont envoyées avec GBP 1 des données.

Les deux flots doivent partager le même port de gigabit de sortie. Supposez que le poids d'égal est configuré entre Q1 et Q2. WRR est appliqué par paquet, et la quantité de données qui sont transmises de chaque file d'attente diffère entre les deux files d'attente. Le même nombre de paquets sont expédiés hors de chaque file d'attente, mais le commutateur envoie réellement cette quantité de données :

  • 77700 paquets par seconde (PPS) hors de Q2 = (77700 x 8 x 64) bits par seconde (bps) (approximativement 52 Mbits/s)

  • 77700 PPS hors de Q1 = (77700 x 8 x 1500) bps (approximativement 948 Mbits/s)

Conseils

  • Si vous voulez permettre l'accès équitable pour chaque file d'attente au réseau, prenez en considération la taille moyenne de chaque paquet. On s'attend à ce que chaque paquet soit placé dans une file d'attente et le poids modifié en conséquence. Par exemple, si vous voulez donner le à égalité d'accès à chacune des quatre files d'attente, tel que chaque file d'attente obtient 1/4 de la bande passante, le trafic est comme suit :

    • Dans Q1 : Le trafic Internet de meilleur effort. Supposez que le trafic a une taille moyenne des paquets de 256 B.

    • Dans Q2 : Sauvegarde composée de transfert de fichiers, avec un paquet principalement de 1500 B.

    • Dans Q3 : Flux vidéos, qui sont faits sur des paquets de 192 B.

    • Dans Q4 : Application interactive qui se compose principalement de paquet de 64 B.

    Ceci crée ces conditions :

    • Q1 consomme 4 fois la bande passante de Q4.

    • Q2 consomme 24 fois la bande passante de Q4.

    • Q3 consomme 3 fois la bande passante de Q4.

  • Afin d'avoir accès égal de bande passante au réseau, configurez :

    • 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 vous assignez ces poids, vous réalisez une bande passante égale partageant parmi les quatre files d'attente en cas de l'encombrement.

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

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

    • Q2 = 2 paquets sur 6

    • Q3 = 3 paquets sur 6

    Vous pouvez émettre cette commande show de logiciel de Cisco IOS afin de vérifier le poids de 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 Q4 est seulement utilisé si la file d'attente d'accélération obtient handicapé. 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 des Commutateurs du Catalyst 3550

WRED est seulement disponible sur des ports de gigabit sur les Commutateurs de gamme 3550. WRED est une modification de Détection précoce aléatoire (RED), qui est utilisée dans la manière d'éviter d'encombrement. Le ROUGE a ces paramètres définis :

  • Seuil minimum : Représente un seuil dans une file d'attente. Aucun paquet n'est lâché au-dessous de ce seuil.

  • Seuil (maximum) maximum : Représente un autre seuil dans une file d'attente. Tous les paquets sont lâchés au-dessus du seuil maximum.

  • Pente : Probabilité pour relâcher le paquet entre la minute et le maximum. La probabilité de perte augmente linéairement (avec une certaine pente) avec la taille de file d'attente.

Ce graphique affiche la probabilité de perte d'un paquet dans la file d'attente ROUGE :

Remarque: Tous les Commutateurs de Catalyst qui implémentent le ROUGE te permettent pour accorder la pente.

/image/gif/paws/24057/187-a.gif

Dans WRED, différents services sont pesés. Vous pouvez définir un service standard et un service premium. Chaque service reçoit un ensemble différent de seuils. Seulement des paquets qui sont assignés au service standard sont lâchés quand le seuil minimum 1 est atteint. Seulement des paquets des services premiums commencent à être lâchés quand le seuil minimum 2 est atteint. Si le seuil minimum 2 est le seuil minimum 1 de supérieur à, plus de paquets du service standard sont lâchés que sont les paquets des services premiums. Ce graphique affiche un exemple de la probabilité de perte pour chaque service avec WRED :

Remarque: Le commutateur 3550 ne permet pas à vous pour accorder le seuil minimum, mais seulement au seuil maximum. Le seuil minimum est toujours embarrassé à 0. Ceci donne une probabilité de perte qui représente ce qui est actuellement mis en application dans les 3550.

/image/gif/paws/24057/187-b.gif

N'importe quelle file d'attente qui est activée pour WRED sur les 3550 a toujours une probabilité de perte différente de zéro et relâche toujours des paquets. C'est le cas parce que le seuil minimum est toujours 0. Si vous devez éviter la perte de paquets à maximum, utilisez le Weighted Tail Drop, que la perte de destination sur la section de Commutateurs du Catalyst 3550 décrit.

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

Pour plus d'informations sur le ROUGE et le WRED, référez-vous à l'aperçu de manière d'éviter d'encombrement.

Sur les 3550, vous pouvez configurer WRED avec deux seuils maximum différents afin de fournir deux services différents. Différents types de trafic sont assignés à l'un ou l'autre de seuil, qui dépend seulement des DSCP internes. Ceci diffère de l'affectation de file d'attente, qui dépend seulement du cos du paquet. Un mappage de table de Dscp-à-seuil décide à quel seuil chacun des 64 DSCPs va. Vous pouvez émettre cette commande afin de voir et modifier ce tableau :

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

Par exemple, cette commande assigne le 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 la définition de la carte de Dscp-à-seuil, WRED est activée 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 configure :

  • Q1 avec le seuil 1 = 50 pour cent et le seuil 2 = 100 pour cent

  • Q2 avec le seuil 1 = 70 pour cent et le seuil 2 = 100 pour cent

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 Mise en file d'attente (WRED ou pas) 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 

L'ena signifie l'enable, et la file d'attente utilise WRED. Le dis signifie le débronchement, et la file d'attente utilise la perte de destination.

Vous pouvez surveillez également le nombre de paquets qui sont lâché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

Perte de destination sur des Commutateurs du Catalyst 3550

La perte de destination est le mécanisme par défaut sur les 3550 sur des ports de gigabit. Chaque port de gigabit peut avoir deux seuils de perte de destination. Un ensemble de DSCPs sont assignés à chacun des seuils de perte de destination avec l'utilisation de la même carte de seuil de DSCP que le WRED sur la section de Commutateurs du Catalyst 3550 de ce document définit. Quand un seuil est atteint, tous les paquets avec un DSCP qui est assigné à ce seuil sont lâchés. Vous pouvez émettre cette commande afin de configurer des seuils de perte de destination :

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

Cet exemple configure :

  • Q1 avec le seuil de perte de destination 1 = 50 pour cent et le seuil 2 = 100 pour cent

  • Q2 avec le seuil 1 = 70 pour cent et le seuil 2 = 100 pour cent

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 taille de file d'attente sur des ports de gigabit

La mise en mémoire tampon centrale de 3550 utilisations de commutateur. Ceci signifie qu'il n'y a aucune taille de mémoire tampon fixe par port. Cependant, il y a un nombre fixe de paquets sur un port de gigabit qui peut être aligné. Ce nombre fixe est 4096. Par défaut, chaque file d'attente dans un port de gigabit peut avoir jusqu'à 1024 paquets, indépendamment de la longueur de paquet. Cependant, vous pouvez modifier la manière dans laquelle ces 4096 paquets sont séparés parmi 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 affiche cela :

  • Q1 est quatre fois plus grand que Q4.

  • Q2 est trois fois plus grand que Q4.

  • Q3 est deux fois plus grand que Q4.

Les 4096 paquets sont redistribués de cette façon :

  • 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 te permet pour voir les poids relatifs de mémoires tampons fendues 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 tenir :

(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 de compte de FreeQ est dynamique. Le compteur de FreeQ donne la taille de file d'attente maximale sans le nombre de paquets qui sont actuellement dans la file d'attente. Par exemple, s'il y a actuellement 39 paquets dans Q1, 1600 paquets sont libres dans le le compte de 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 de file d'attente et taille de file d'attente sur des ports de Non-gigabit

Il n'y a aucun schéma de Gestion de file d'attente disponible sur les ports 10/100-Mbps (aucun WRED ou perte de destination avec deux seuils). Chacune des quatre files d'attente est des files d'attente FIFO. Il n'y a également aucune taille de file d'attente maximale que les réserves 4096 paquets pour chaque gigabit mettent en communication. les ports 10/100-Mbps enregistrent des paquets dans chaque file d'attente jusqu'à ce qu'elle soit pleine en raison d'un manque de ressources. Vous pouvez réserver un nombre minimal de paquets par file d'attente. Ce minimum est placé à 100 paquets par file d'attente par défaut. Vous pouvez modifier cette valeur minimum de réserve pour chaque file d'attente si vous définissez différentes valeurs minimum de réserve et assignez une des valeurs à chaque file d'attente.

Terminez-vous ces étapes afin d'apporter cette modification :

  1. Assignez une taille de mémoire tampon pour chaque valeur minimum globale de réserve.

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

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

    Ces valeurs minimum de réserve sont globales au commutateur. Par défaut, toutes les valeurs minimum de réserve sont placées à 100 paquets.

    Par exemple, afin de configurer un niveau minimum 1 de réserve de 150 paquets et un niveau minimum 2 de réserve 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. Assignez une des valeurs minimum de réserve à chacune des files d'attente.

    Vous devez assigner chacune des files d'attente à une des valeurs minimum de réserve afin de connaître combien de mémoires tampons sont garanties pour cette file d'attente. Par défaut, ces conditions s'appliquent :

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

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

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

    • Q4 est assigné au niveau minimum 4. de réserve.

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

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

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

    Par exemple, afin d'assigner à Q1 une réserve minimum de 2 et à Q2 une réserve minimum de 1, émettent 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 minimum de réserve qui résulte :

    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 queue et l'établissement du programme sur un port sur les 3550 implique ces étapes :

  1. Assignez à chacun le cos à une des files d'attente.

  2. Files d'attente prioritaire strictes d'enable, si nécessaire.

  3. Assignez le poids WRR, et prenez en considération la longueur de paquet prévue dans la file d'attente.

  4. Modifiez la taille de file d'attente (ports de gigabit seulement).

  5. Activez un mécanisme de Gestion de file d'attente (perte de destination ou WRED, sur des ports de gigabit seulement).

La Mise en file d'attente appropriée et l'établissement du programme peuvent réduire le retard/jitter pour la Voix/trafic visuel et éviter la perte pour le trafic crucial. Soyez sûr d'adhérer à ces instructions pour la représentation de établissement du programme maximum :

  • Classifiez le trafic qui est présent dans le réseau dans les classes différentes, avec la confiance ou le marquage spécifique.

  • La police trafique supérieur.


Informations connexes


Document ID: 24057