Dépannage des pertes de sortie avec mise en file d'attente prioritaire

Introduction

Ce document propose des conseils sur le dépannage des pertes d'émission qui résultent d'une configuration de mise en file d'attente prioritaire sur l'interface d'un routeur.

Conditions préalables

Exigences

Les lecteurs de ce document doivent être familiers avec les concepts suivants :

• priority-group ou frame-relay priority-group- Active le mécanisme de mise en file d'attente prioritaire hérité de Cisco. Prend en charge jusqu'à quatre niveaux de files d'attente prioritaires.

• ip rtp priority ou frame-relay ip rtp priority - Correspond aux numéros de port UDP pour le trafic RTP (Real-Time Protocol) encapsulant les paquets VoIP et place ces paquets dans une file d'attente prioritaire.

• priority - Active la fonctionnalité de mise en file d'attente à faible latence (LLQ) de Cisco et utilise la structure de commande de l'interface de ligne de commande (CLI) de qualité de service modulaire.

Un routeur peut signaler les pertes de sortie lorsque l'une de ces méthodes est configurée, mais il existe des différences fonctionnelles importantes entre les méthodes et la raison des pertes dans chaque cas.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de travaux pratiques spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez sur un réseau qui est en ligne, assurez-vous de bien comprendre l’incidence possible d’une commande avant de l’utiliser.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de travaux pratiques spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez sur un réseau actif, assurez-vous de bien comprendre l’impact potentiel de toute commande avant de l’utiliser.

Conventions

Pour plus d'informations sur les conventions de document, référez-vous à Conventions utilisées dans les conseils techniques de Cisco.

Abandon avec priorité ip rtp et LLQ

Le Guide de configuration de Cisco IOS met en garde contre les pertes de sortie avec ces mécanismes de mise en file d'attente prioritaires :

• ip rtp priority : Étant donné que la commande ip rtp priority donne une priorité absolue sur le reste du trafic, elle doit être utilisée avec précaution. En cas d'encombrement, si le trafic dépasse la bande passante configurée, tout le trafic excédentaire est abandonné.

• priority et LLQ : Lorsque vous spécifiez la commande priority pour une classe, elle prend un argument bandwidth qui donne la bande passante maximale. En cas d'encombrement, la réglementation est utilisée pour abandonner les paquets lorsque la bande passante est dépassée.

Ces deux mécanismes utilisent un régulateur intégré pour mesurer les flux de trafic. L'objectif du régulateur est de s'assurer que les autres files d'attente sont gérées par l'ordonnanceur de mise en file d'attente. Dans la fonctionnalité de mise en file d'attente de priorité d'origine de Cisco, qui utilise les commandes priority-group et priority-list, le planificateur a toujours traité la file d'attente de priorité la plus élevée en premier. Si le trafic était toujours présent dans la file d'attente de priorité élevée, les files d'attente de priorité inférieure étaient privées de bande passante et les paquets destinés aux files d'attente non prioritaires.

Abandons avec file d'attente prioritaire existante

La mise en file d'attente prioritaire (PQ) est le mécanisme de mise en file d'attente prioritaire hérité de Cisco. Comme illustré ci-dessous, PQ prend en charge jusqu'à quatre niveaux de files d'attente : élevé, moyen, normal et faible.

L'activation de la mise en file d'attente prioritaire sur une interface modifie l'affichage de la file d'attente de sortie, comme illustré ci-dessous. Avant la mise en file d’attente prioritaire, l’interface Ethernet utilise une seule file d’attente de sortie avec une taille de file d’attente par défaut de 40 paquets.

R6-2500# show interface ethernet0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1) 
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec) 
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:02, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239407 packets input, 22644297 bytes, 0 no buffer 
     Received 239252 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374436 packets output, 31095372 bytes, 0 underruns 
     0 output errors, 1 collisions, 13 interface resets 
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

Après avoir activé PQ, l’interface Ethernet utilise désormais quatre files d’attente prioritaires avec des limites de file d’attente variables, comme indiqué dans le résultat ci-dessous :

R6-2500(config)# interface ethernet0 
R6-2500(config-if)# priority-group 1 
R6-2500(config-if)# end 
R6-2500# show interface ethernet 0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1)
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:03, output hang never 
  Last clearing of "show interface" counters never 
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: priority-list 1 
  Output queue (queue priority: size/max/drops): 
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239411 packets input, 22644817 bytes, 0 no buffer
     Received 239256 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374440 packets output, 31095658 bytes, 0 underruns
     0 output errors, 1 collisions, 14 interface resets
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

La commande priority-list {list-number} est utilisée pour affecter des flux de trafic à une file d'attente spécifique. Lorsque les paquets arrivent sur une interface, les files d'attente de priorité de cette interface sont analysées pour rechercher les paquets dans un ordre de priorité décroissant. La file d'attente de priorité élevée est d'abord analysée, puis la file d'attente de priorité moyenne, et ainsi de suite. Le paquet en tête de la file d'attente de priorité la plus élevée est choisi pour la transmission. Cette procédure est répétée chaque fois qu’un paquet doit être envoyé.

Chaque file d'attente est définie par une longueur maximale ou par le nombre maximal de paquets que la file d'attente peut contenir. Lorsqu'un paquet entrant provoque le dépassement de la limite de file d'attente configurée par la profondeur de file d'attente actuelle, le paquet est abandonné. Ainsi, comme indiqué ci-dessus, les pertes de sortie avec PQ sont généralement dues au dépassement de la limite de file d'attente et non à un régulateur interne, comme c'est le cas typique avec LLQ. La commande priority-list list-number queue-limit modifie la taille d'une file d'attente prioritaire.

Mesure du trafic avec un compartiment de jetons

LLQ et IP RTP Priority implémentent le régulateur intégré en utilisant un « token bucket » comme système de mesure du trafic. Cette section examine le concept de « saut à jeton ».

Un compartiment de jetons n'a pas de stratégie de suppression ou de priorité. La métaphore du saut à jeton fonctionne comme suit :

• Les jetons sont placés dans le compartiment à un certain débit.

• Chaque jeton signifie l'autorisation pour la source d'envoyer un certain nombre de bits dans le réseau.

• Pour envoyer un paquet, le régulateur de trafic doit pouvoir supprimer un nombre de jetons du compartiment égal en représentation à la taille du paquet.

• S'il n'y a pas assez de jetons dans le compartiment pour envoyer un paquet, le paquet attend jusqu'à ce que le compartiment ait assez de jetons (dans le cas d'un formateur) ou le paquet est rejeté ou marqué vers le bas (dans le cas d'un régulateur).

• Le compartiment lui-même a une capacité spécifiée. Si le compartiment atteint sa capacité maximale, les nouveaux jetons entrants sont rejetés et ne sont pas disponibles pour les paquets futurs. Ainsi, à tout moment, la plus grande rafale qu'une application peut envoyer dans le réseau est à peu près proportionnelle à la taille du compartiment. Un seau à jetons autorise les rafales, mais les délimite.

Prenons un exemple utilisant des paquets et un débit de données garanti (CIR) de 8 000 bits/s.

• Dans cet exemple, les compartiments de jeton initiaux commencent à 1 000 octets.

• Lorsqu'un paquet de 450 octets arrive, il est conforme car suffisamment d'octets sont disponibles dans le compartiment de jeton conforme. Le paquet est envoyé et 450 octets sont supprimés du compartiment à jetons, ce qui laisse 550 octets.

• Lorsque le paquet suivant arrive 0,25 seconde plus tard, 250 octets sont ajoutés au compartiment à jetons (0,25 * 8000)/8), laissant 700 octets dans le compartiment à jetons. Si le paquet suivant est de 800 octets, le paquet dépasse et est abandonné. Aucun octet n'est prélevé dans le compartiment de jeton.

Étapes de dépannage pour diagnostiquer les abandons

Étape 1 : collecte des données

Les étapes de collecte des données sont présentées ci-dessous.

1. Exécutez plusieurs fois les commandes suivantes et déterminez la vitesse et la fréquence d'incrémentation des abandons. Utilisez le résultat pour établir une ligne de base de vos modèles et niveaux de trafic. Déterminez le taux d'abandon « normal » sur l'interface.

   • show queueing interface

     router# show queueing interface hssi 0/0/0
               Interface Hssi0/0/0 queueing strategy: priority
     
               Output queue utilization (queue/count)
     
                high/12301 medium/4 normal/98 low/27415

   • show interface - Surveille la valeur de charge affichée dans la sortie. En outre, assurez-vous que la somme des nombres de pertes par file d'attente dans la sortie de show interface est équivalente au nombre de pertes de sortie. Le compteur show interface output drops doit afficher l'agrégat total de toutes les pertes en sortie, y compris les pertes WRED, les pertes dues à un manque de mémoire tampon (erreurs « sans mémoire tampon ») et même les pertes dans la mémoire de la carte de ports intégrée.

     router# show interface serial 4/1/2
     
     Serial4/1/2 is up, line protocol is up 
     Hardware is cyBus Serial 
     Description: E1 Link to 60W S9/1/2 Backup 
     Internet address is 169.127.18.228/27 
     MTU 1500 bytes, BW 128 Kbit, DLY 21250 usec, rely 255/255, load 183/255 
     Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
     Last input 00:00:00, output 00:00:00, output hang never 
     Last clearing of "show interface" counters 5d10h 
     Input queue: 0/75/0 (size/max/drops); Total output drops: 68277 
     Queueing strategy: priority-list 7 
     Output queue: high 0/450/0, medium 0/350/143, normal 0/110/27266, low 0/100/40868 
     5 minute input rate 959000 bits/sec, 419 packets/sec 
     5 minute output rate 411000 bits/sec, 150 packets/sec 
     144067307 packets input, 4261520425 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     42 input errors, 34 CRC, 0 frame, 0 overrun, 1 ignored, 8 abort 
     69726448 packets output, 2042537282 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 46686454 output buffers swapped out 
     0 carrier transitions

     Remarque : certaines interfaces affichent des valeurs « txload » et « rxload » distinctes.

     Hssi0/0/0 is up, line protocol is up 
      Hardware is cyBus HSSI 
      MTU 1500 bytes, BW 7500 Kbit, DLY 200 usec, 
      reliability 255/255, txload 138/255, rxload 17/255 
      Encapsulation FRAME-RELAY IETF, crc 16, loopback not set 
      Keepalive set (5 sec) 
      LMI enq sent 4704, LMI stat recvd 4704, LMI upd recvd 0, DTE LMI up 
      LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 
      LMI DLCI 1023 LMI type is CISCO frame relay DTE 
      Broadcast queue 0/256, broadcasts sent/dropped 8827/0, interface 
      broadcasts 7651 
      Last input 00:00:00, output 00:00:00, output hang never 
      Last clearing of "show interface" counters 06:31:58 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 84 
      Queueing strategy: priority-list 1 
      Output queue (queue priority: size/max/drops): 
      high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/84 
      5 minute input rate 524000 bits/sec, 589 packets/sec 
      5 minute output rate 4080000 bits/sec, 778 packets/sec 
      11108487 packets input, 1216363830 bytes, 0 no buffer 
      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
      0 parity 
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
      15862186 packets output, 3233772283 bytes, 0 underruns 
      0 output errors, 0 applique, 1 interface resets 
      0 output buffer failures, 2590 output buffers swapped out 
      0 carrier transitions 
      LC=down CA=up TM=down LB=down TA=up LA=down

   • show policy-map interface interface-name - Recherchez une valeur non nulle pour le compteur « pkts discards ».

     Router# show policy-map interface s1/0
      Serial1/0.1: DLCI 100 -
      output : mypolicy
       Class voice
        Weighted Fair Queueing
            Strict Priority
            Output Queue: Conversation 72 
              Bandwidth 16 (kbps) Packets Matched 0
             (pkts discards/bytes discards) 0/0
       Class immediate-data
        Weighted Fair Queueing
            Output Queue: Conversation 73 
              Bandwidth 60 (%) Packets Matched 0
              (pkts discards/bytes discards/tail drops) 0/0/0
              mean queue depth: 0
              drops: class  random   tail     min-th   max-th   mark-prob 
                     0      0        0        64       128      1/10
                     1      0        0        71       128      1/10
                     2      0        0        78       128      1/10
                     3      0        0        85       128      1/10
                     4      0        0        92       128      1/10
                     5      0        0        99       128      1/10
                     6      0        0        106      128      1/10
                     7      0        0        113      128      1/10
                     rsvp   0        0        120      128      1/10

     Remarque : l'exemple suivant affiche les valeurs correspondantes pour les compteurs "packets" et "pkts matches". Cette condition indique qu'un grand nombre de paquets sont en cours de commutation de processus ou que l'interface connaît un encombrement extrême. Ces deux conditions peuvent entraîner le dépassement de la limite de file d'attente d'une classe et doivent être étudiées.

     router# show policy-map interface
     
     Serial4/0 
     
     Service-policy output: policy1 
     
     Class-map: class1 (match-all) 
     189439 packets, 67719268 bytes 
     5 minute offered rate 141000 bps, drop rate 0 bps 
     Match: access-group name ds-class-af3 
     Weighted Fair Queueing 
     Output Queue: Conversation 265 
     Bandwidth 50 (%) Max Threshold 64 (packets) 
     (pkts matched/bytes matched) 189439/67719268 
     (depth/total drops/no-buffer drops) 0/0/0

2. Caractériser les flux de trafic et les paquets dans ces flux.

   • Quelle est la taille moyenne des paquets ?

   • Dans quelle direction circule la trame de la taille MTU ? De nombreux flux de trafic sont asynchrones par rapport à la charge. Par exemple, avec un téléchargement FTP, la plupart des paquets de taille MTU circulent du serveur FTP au client. Les paquets du client FTP vers le serveur sont de simples accusés de réception TCP.

   • Les paquets utilisent-ils TCP ou UDP ? TCP permet à chaque flux d’envoyer un nombre autorisé de paquets avant que la source n’ait besoin de suspendre la transmission et d’attendre que la destination accuse réception des paquets transmis.

3. Avec Frame Relay, déterminez si les pertes se produisent au niveau de la file d’attente d’interface ou d’une file d’attente par circuit virtuel. Le schéma suivant illustre le flux de paquets à travers un circuit virtuel Frame Relay :

   

4. Priority Queueing prend en charge jusqu'à quatre files d'attente de sortie, une par niveau de file d'attente prioritaire et chaque file d'attente est définie par une limite de file d'attente. Le système de mise en file d'attente vérifie la taille de la file d'attente par rapport à la limite de file d'attente configurée avant de placer le paquet dans une file d'attente. Si la file d'attente sélectionnée est pleine, le routeur abandonne le paquet. Essayez d'augmenter la taille de la file d'attente avec la commande priority-list {#} queue-limit et reprenez la surveillance.

Étape 2 - Vérifiez que la bande passante est suffisante

Avec LLQ, la réglementation permet un traitement équitable d'autres paquets de données dans d'autres files d'attente CBWFQ (Class-Based Weighted Fair Queuing) ou WFQ. Pour éviter les abandons de paquets, assurez-vous d'allouer une quantité optimale de bande passante à la file d'attente prioritaire, en tenant compte du type de codec utilisé et des caractéristiques de l'interface. La priorité IP RTP n'autorise pas le trafic au-delà de la quantité allouée.

Il est toujours plus sûr d'allouer un peu plus que la quantité de bande passante requise connue à la file d'attente prioritaire. Par exemple, supposons que vous ayez alloué 24 kbits/s de bande passante, la quantité standard requise pour la transmission vocale, à la file d'attente prioritaire. Cette allocation semble sûre car la transmission des paquets vocaux se fait à un débit constant. Cependant, comme le réseau et le routeur ou le commutateur peuvent utiliser une partie de la bande passante pour produire une gigue et un retard, l’allocation d’un peu plus que la quantité de bande passante requise (par exemple 25 kbits/s) garantit la constance et la disponibilité.

La bande passante allouée à une file d’attente prioritaire inclut toujours l’en-tête d’encapsulation de couche 2. Il n'inclut pas le contrôle de redondance cyclique (CRC). (Reportez-vous à la section Quels octets sont comptés par la mise en file d'attente CoS IP à ATM ? pour plus d'informations.) Bien qu'il ne s'agisse que de quelques octets, le CRC impose un impact croissant, car les flux de trafic incluent un nombre plus élevé de petits paquets.

En outre, sur les interfaces ATM, la bande passante allouée à une file d'attente prioritaire n'inclut pas la surcharge de taxe de cellule ATM suivante :

• Remplissage éventuel par la segmentation et le réassemblage (SAR) pour faire de la dernière cellule d’un paquet un multiple pair de 48 octets.

• CRC de 4 octets de la queue de bande de la couche d’adaptation ATM 5 (AAL5).

• En-tête de cellule ATM de 5 octets.

Lorsque vous calculez la quantité de bande passante à allouer pour une classe de priorité donnée, vous devez tenir compte du fait que les en-têtes de couche 2 sont inclus. Lorsque vous utilisez un guichet automatique, vous devez tenir compte du fait que les frais généraux de taxe sur les cellules de guichet automatique ne sont pas inclus. Vous devez également autoriser la bande passante pour la possibilité de gigue introduite par les périphériques réseau dans le chemin vocal. Reportez-vous à la présentation de la fonctionnalité Low Latency Queueing.

Lorsque vous utilisez la mise en file d'attente par priorité pour transporter des paquets VoIP, référez-vous à Voix sur IP - Consommation de bande passante par appel.

Étape 3 - Vérifiez que la taille de rafale est suffisante

Le traitement d'une série de paquets quittant une interface par une file d'attente prioritaire dépend de la taille du paquet et du nombre d'octets restant dans le compartiment à jetons. Il est important de prendre en compte les caractéristiques du flux de trafic dirigé vers la file d’attente prioritaire, car LLQ utilise un régulateur et non un formateur. Un régulateur utilise un saut de jeton comme suit :

• Le compartiment est rempli de jetons en fonction du taux de classe jusqu'à un maximum du paramètre de rafale.

• Si le nombre de jetons est supérieur ou égal à la taille du paquet, le paquet est envoyé et le compartiment de jetons est décrémenté. Sinon, le paquet est abandonné.

La valeur de rafale par défaut de l'indicateur de trafic de type « token bucket » de LLQ est calculée en tant que 200 millisecondes de trafic au débit de bande passante configuré. Dans certains cas, la valeur par défaut est inadéquate, en particulier lorsque le trafic TCP entre dans la file d'attente prioritaire. Les flux TCP sont généralement en rafales et peuvent nécessiter une taille de rafale supérieure à la valeur par défaut attribuée par le système de mise en file d’attente, en particulier sur les liaisons lentes.

L'exemple de sortie suivant a été généré sur un circuit virtuel permanent ATM avec un débit de cellule soutenu de 128 kbits/s. Le système de mise en file d’attente ajuste la taille de rafale à mesure que la valeur spécifiée par la commande priority change.

7200-17# show policy-map int atm 4/0.500
 ATM4/0.500: VC 1/500 - 
  
Service-policy output: drops 

    Class-map: police (match-all)
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 90 (%) 
        Bandwidth 115 (kbps) Burst 2875 (Bytes) 
        
!--- Burst value of 2875 bytes is assigned when !--- the reserved bandwidth value is 115 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 

7200-17# show policy-map int atm 4/0.500 
 ATM4/0.500: VC 1/500 - 

  Service-policy output: drops 

    Class-map: police (match-all) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 50 (%) 
        Bandwidth 64 (kbps) Burst 1600 (Bytes) 
        
!--- Burst value changes to 1600 bytes when the !--- reserved bandwidth value is changed to 64 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any

La fonctionnalité LLQ a été étendue pour permettre une taille de rafale validée configurable avec la fonctionnalité Configuration de la taille de rafale dans la mise en file d'attente à faible latence. Grâce à cette nouvelle fonctionnalité, le réseau peut désormais prendre en charge des pics de trafic temporaires et gérer le trafic réseau plus efficacement.

Utilisez le paramètre burst avec la commande priority pour augmenter la valeur de rafale de 1600 octets à 3200 octets.

policy-map AV 
  class AV 
  priority percent 50 3200

Remarque : une valeur élevée augmente la bande passante effective que la classe prioritaire peut utiliser et peut donner l'impression que les classes prioritaires obtiennent plus que leur juste part de bande passante.

En outre, le système de mise en file d'attente a initialement attribué une limite de file d'attente interne de 64 paquets à la file d'attente à faible latence. Dans certains cas, lorsqu'une salve de 64 paquets arrivait dans la file d'attente prioritaire, le compteur de trafic déterminait que la salve était conforme au débit configuré, mais que le nombre de paquets dépassait la limite de la file d'attente. Par conséquent, certains paquets ont été abandonnés. L'ID de bogue Cisco CSCdr51979 (clients enregistrés uniquement) résout ce problème en permettant à la taille de la file d'attente prioritaire d'augmenter aussi profondément que le permet le compteur de trafic.

Le résultat suivant a été capturé sur un circuit virtuel permanent Frame Relay configuré avec un débit de données garanti de 56 Kbits/s. Dans le premier ensemble de sortie d'échantillon, le débit offert combiné des classes c1 et c2 est de 76 kbits/s. La raison en est que les valeurs calculées des débits offerts moins les débits d'abandon ne représentent pas les débits de transmission réels et n'incluent pas les paquets qui se trouvent dans le formeur avant qu'ils ne soient transmis.

router# show policy-map int s2/0.1
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 16000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 7311/657990 
         (total drops/bytes drops) 2221/199890 

     Class-map: c2 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 44000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 7310/657900 
         (depth/total drops/no-buffer drops) 64/6650/0 

     Class-map: class-default (match-any) 
       2 packets, 382 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

Dans ce deuxième jeu de résultats, les compteurs d'interface show policy-map se sont normalisés. Sur le circuit virtuel permanent à 56 kbits/s, la classe c1 envoie environ 50 kbits/s et la classe c2 envoie environ 6 kbits/s.

router# show policy-map int s2/0.1 
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 21000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 15961/1436490 
         (total drops/bytes drops) 4864/437760 

     Class-map: c2 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 66000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 15960/1436400 
         (depth/total drops/no-buffer drops) 64/14591/0 

     Class-map: class-default (match-any) 
       5 packets, 1096 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

Étape 4 : priorité de débogage

La commande debug priority affiche le résultat de la mise en file d'attente prioritaire si des paquets sont abandonnés de la file d'attente prioritaire.

Mise en garde :  Avant d'utiliser les commandes debug, référez-vous à Informations importantes sur les commandes Debug. La commande debug priority peut imprimer une grande quantité de sortie de débogage perturbatrice sur un routeur de production. La quantité dépend du niveau d'encombrement.

L'exemple de résultat suivant a été généré sur un Cisco 3640.

r3-3640-5# debug priority 
Priority output queueing debugging is on 

r3-3640-5# ping 10.10.10.2 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
r3-3640-5# 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:41: PQ: Serial0/1 output (Pk size/Q 13/0) 
r3-3640-5#no debug priority 
00:42:51: PQ: Serial0/1 output (Pk size/Q 13/0) 
Priority output queueing debugging is off

Dans la sortie de priorité de débogage suivante, 64 indique la profondeur de file d'attente de priorité réelle au moment où le paquet a été abandonné.

*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64

Autres causes de chute

Les raisons suivantes des pertes de sortie avec LLQ ont été découvertes par le centre d'assistance technique Cisco (TAC) lors du dépannage de cas et documentées dans un rapport de bogue Cisco :

• L'augmentation des valeurs de seuil maximum WRED (Weighted Random Early Detection) sur une autre classe a épuisé les tampons disponibles et entraîné des pertes dans la file d'attente prioritaire. Pour aider à diagnostiquer ce problème, un compteur « no-buffer drops » pour la classe de priorité est prévu pour une prochaine version d'IOS.

• Si la limite de file d'attente de l'interface d'entrée est inférieure à la limite de file d'attente de l'interface de sortie, le paquet abandonne le décalage vers l'interface d'entrée. Ces symptômes sont documentés dans l'ID de bogue Cisco CSCdu89226 (clients enregistrés uniquement) . Résolvez ce problème en dimensionnant la file d'attente d'entrée et la file d'attente de sortie de manière appropriée pour empêcher les pertes d'entrée et permettre au mécanisme de mise en file d'attente prioritaire sortante de prendre effet.

• L'activation d'une fonctionnalité qui n'est pas prise en charge dans le chemin à commutation CEF ou à commutation rapide entraîne la commutation de processus d'un grand nombre de paquets. Avec LLQ, les paquets à commutation de processus sont actuellement contrôlés, que l’interface soit ou non encombrée. En d'autres termes, même si l'interface n'est pas encombrée, le système de mise en file d'attente mesure les paquets à commutation de processus et s'assure que la charge offerte ne dépasse pas la valeur de bande passante configurée avec la commande priority. Ce problème est documenté dans l'ID de bogue Cisco CSCdv86818 (clients enregistrés seulement) .

Abandons des files d'attente prioritaires et Frame Relay

Frame Relay est un cas particulier de réglementation de la file d’attente prioritaire. La présentation de la fonctionnalité Low Latency Queueing for Frame Relay met en garde les points suivants : « Le PQ est contrôlé pour s'assurer que les files d'attente équitables ne sont pas privées de bande passante. Lorsque vous configurez le PQ, vous spécifiez en kbits/s la quantité maximale de bande passante disponible pour cette file d'attente. Les paquets qui dépassent ce maximum sont abandonnés." En d’autres termes, à l’origine, la file d’attente prioritaire d’une stratégie de service configurée dans une classe de mappage Frame Relay était régulée pendant les périodes d’encombrement et de non-encombrement. IOS 12.2 supprime cette exception. PQ est toujours contrôlé avec FRF.12, mais les autres paquets non conformes ne sont abandonnés qu'en cas d'encombrement.

Informations connexes

• Page de support QoS
• Module de fonctionnalités de réglementation du trafic du logiciel Cisco IOS version 12.2
• Support technique - Cisco Systems