Contenu
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
Conditions requises
Les lecteurs de ce document doivent connaître les concepts suivants :
-
priority-group ou frame-relay priority-group - Active le mécanisme de mise en file d'attente des priorités héritées 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é LLQ (Low Latency Queueing) de Cisco et utilise la structure de commande de l'interface de ligne de commande QoS modulaire de qualité de service.
Un routeur peut signaler des pertes de sortie lorsque l’une de ces méthodes est configurée, mais il existe d’importantes différences fonctionnelles 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 laboratoire 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.
Components Used
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 laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, 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 Cisco.
Supprime avec la priorité ip rtp et LLQ
Le Guide de configuration de Cisco IOS met en garde contre les pertes de sortie avec les mécanismes de mise en file d'attente prioritaires suivants :
-
ip rtp priority : Comme la commande ip rtp priority donne la priorité absolue sur d'autres trafics, elle doit être utilisée avec soin. 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, il prend un argument bandwidth qui donne la bande passante maximale. En cas d'encombrement, la réglementation est utilisée pour supprimer des 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 traitées par le planificateur de file d'attente. Dans la fonctionnalité de mise en file d'attente prioritaire 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. S'il y avait toujours du trafic 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 étaient acheminés vers des files d'attente non prioritaires.
Abandons avec la file d'attente prioritaire existante
La mise en file d'attente par priorité (PQ) est le mécanisme de mise en file d'attente par priorité hérité de Cisco. Comme illustré ci-dessous, PQ prend en charge jusqu'à quatre niveaux de file d'attente : élevé, moyen, normal et faible.
L'activation de la mise en file d'attente par priorité sur une interface modifie l'affichage de la file d'attente de sortie, comme illustré ci-dessous. Avant la mise en file d'attente par priorité, l'interface Ethernet utilise une file d'attente de sortie unique 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 maintenant 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 à une interface, les files d'attente prioritaires sur cette interface sont analysées pour rechercher les paquets dans un ordre décroissant de priorité. La file d'attente de priorité élevée est analysée en premier, puis la file d'attente de priorité moyenne, etc. Le paquet situé 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 entraîne le dépassement de la limite de file d'attente configurée par la profondeur de la 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 avec LLQ. La commande priority-list list-number queue-limit modifie la taille d'une file d'attente prioritaire.
Mesure du trafic avec un segment de jeton
LLQ et IP RTP Priority implémentent le régulateur intégré en utilisant un groupement de jetons comme système de mesure du trafic. Cette section examine le concept de seau à jetons.
Un saut à jetons lui-même n'a aucune stratégie de rejet ni de priorité. La métaphore du seau à jetons fonctionne comme suit :
-
Les jetons sont placés dans le saut à un certain débit.
-
Chaque jeton signifie que la source est autorisée à envoyer un certain nombre de bits dans le réseau.
-
Pour envoyer un paquet, le régulateur de trafic doit être en mesure de supprimer un certain 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 soit que le seau ait assez de jetons (dans le cas d'un formateur), soit que le paquet soit ignoré ou marqué (dans le cas d'un régulateur).
-
Le saut lui-même a une capacité spécifique. Si le saut est totalement rempli, les jetons nouvellement arrivés sont ignorés et ne sont pas disponibles pour de futurs paquets. Ainsi, à tout moment, la plus grande rafale qu'une application puisse envoyer sur le réseau est à peu près proportionnelle à la taille du compartiment. Un saut à jetons permet les rafales, mais les lie.
Examinons un exemple d'utilisation de paquets et d'un débit de données garanti de 8 000 bits/s.
-
Dans cet exemple, les compartiments de jeton initiaux commencent complets à 1 000 octets.
-
Lorsqu’un paquet de 450 octets arrive, le paquet est conforme parce que suffisamment d’octets sont disponibles dans le compartiment de jeton de conformité. Le paquet est envoyé et 450 octets sont supprimés du compartiment de jeton, laissant 550 octets.
-
Lorsque le paquet suivant arrive 0,25 secondes plus tard, 250 octets sont ajoutés au segment de jeton (0,25 * 8000)/8), ce qui laisse 700 octets dans le segment de jeton. Si le paquet suivant est de 800 octets, le paquet dépasse et est abandonné. Aucun octet n'est pris du saut à jetons.
Étapes de dépannage du diagnostic des abandons
Étape 1 : collecte des données
Les étapes de collecte des données sont présentées ci-dessous.
-
Exécutez plusieurs fois les commandes suivantes et déterminez la vitesse et la fréquence d'incrémentation des pertes. Utilisez le résultat pour établir une ligne de base de vos modèles de trafic et de vos niveaux de trafic. Déterminez la vitesse de décrochage « normale » 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 - Surveillez la valeur de charge affichée dans le résultat. En outre, assurez-vous que la somme du nombre de pertes par file d'attente dans la sortie 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 sur la sortie, y compris les rejets WRED, les rejets en raison d'une pénurie de mémoire tampon (erreurs de « pas de mémoire tampon ») et même les rejets dans la mémoire de carte de port embarqué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 distinctes « txload » et « rxload ».
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 nom-interface - Recherchez une valeur différente de zéro 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/10Remarque : L'exemple suivant affiche les valeurs correspondantes pour les compteurs « paquets » et « pkts correspondants ». Cette condition indique qu'un grand nombre de paquets sont commutés par processus ou que l'interface est en état d'encombrement extrême. Ces deux conditions peuvent conduire à dépasser 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
-
-
Caractériser les flux de trafic et les paquets dans ces flux.
-
Quelle est la taille moyenne des paquets ?
-
Dans quelle direction la trame de taille MTU circule-t-elle ? 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 passent du serveur FTP au client. Les paquets du client FTP vers le serveur sont des ACK TCP simples.
-
Les paquets utilisent-ils TCP ou UDP ? Le protocole 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.
-
-
Avec Frame Relay, déterminez si les abandons se produisent dans la file d’attente d’interface ou dans une file d’attente par circuit virtuel. Le schéma suivant illustre le flux de paquets à travers un circuit virtuel Frame Relay :
-
La mise en file d'attente prioritaire 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 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 recommencez la surveillance.
Étape 2 - Assurez une bande passante suffisante
Avec LLQ, la réglementation permet un traitement équitable d'autres paquets de données dans d'autres files d'attente CBWFQ ou WFQ basées sur les classes. Pour éviter les pertes 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 d'interface. La priorité RTP IP n'autorise pas le trafic au-delà de la quantité allouée.
Il est toujours plus sûr d'allouer un peu plus de bande passante 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 binaire constant. Cependant, comme le réseau et le routeur ou le commutateur peuvent utiliser une partie de la bande passante pour produire de la gigue et du 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 à Quels octets sont comptés par la mise en file d'attente CoS IP à ATM ? pour plus d'informations.) Bien qu'il ne soit que quelques octets, le CRC impose un impact croissant car les flux de trafic incluent un plus grand nombre de petits paquets.
En outre, sur les interfaces ATM, la bande passante allouée à une file d’attente prioritaire n’inclut pas la surcharge fiscale des cellules ATM suivantes :
-
Tout remplissage 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 remorque AAL5 (ATM Adaptation Layer 5).
-
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 le mode ATM est utilisé, vous devez tenir compte du fait que les frais généraux de taxe sur les cellules ATM 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 Vue d'ensemble de la fonctionnalité de mise en file d'attente à faible latence.
Lorsque vous utilisez la mise en file d'attente par priorité pour transporter des paquets VoIP, référez-vous à Consommation de bande passante de la voix sur IP par appel.
Étape 3 - Assurez-vous que la taille de rafale est suffisante
Le traitement d'une série de paquets quittant une interface via une file d'attente prioritaire dépend de la taille du paquet et du nombre d'octets restant dans le segment de jeton. 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 groupement de jetons comme suit :
-
Le compartiment est rempli de jetons basés sur le 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 groupement de jetons est décrémenté. Sinon, le paquet est abandonné.
La valeur de rafale par défaut du débitmètre de segment de jeton de LLQ est calculée en 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 rafale 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 suivant a été généré sur un circuit virtuel permanent ATM avec un débit de cellules soutenu de 128 kbits/s. Le système de mise en file d'attente ajuste la taille de rafale en fonction de la valeur spécifiée avec la commande priority.
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 commutée configurable (Bc) 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 accueillir des rafales temporaires de trafic 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 1 600 octets à 3 200 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 rafale de 64 paquets arrivait à la file d'attente prioritaire, le compteur de trafic déterminait que la rafale était conforme au débit configuré, mais que le nombre de paquets dépassait la limite de file d'attente. En conséquence, certains paquets ont été abandonnés en queue de bande. L'ID de bogue Cisco CSCdr51979 (clients enregistrés uniquement) résout ce problème en permettant à la taille de file d'attente prioritaire de croître 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 jeu de résultats 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 taux offerts moins les taux de chute ne représentent pas les taux de transmission réels et n'incluent pas les paquets qui se trouvent dans la forme 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 ont normalisé. 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 - Debug priority
La commande debug priority affiche le résultat de la mise en file d'attente prioritaire si les paquets sont supprimés de la file d'attente prioritaire.
Attention : Avant d'utiliser les commandes debug, reportez-vous à Informations importantes sur les commandes Debug. La commande debug priority peut imprimer une grande quantité de résultats de débogage perturbateurs sur un routeur de production. Le montant dépend du niveau de congestion.
L'exemple de sortie 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 réelle de la file d'attente de priorité 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 baisse
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 des cas et documentées dans un rapport de bogue Cisco :
-
L'augmentation des valeurs de seuil maximales pondérées de détection précoce aléatoire (WRED) 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 passe à 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 afin d'empêcher les pertes d'entrée et de permettre l'application du mécanisme de mise en file d'attente prioritaire sortante.
-
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 congestionné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 commutés par 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 uniquement).
Files d'attente prioritaires abandonnées et Frame Relay
Frame Relay est un cas particulier en ce qui concerne la réglementation de la file d’attente prioritaire. La présentation de la fonctionnalité Low Latency Queueing for Frame Relay note la mise en garde suivante : « Le PQ est contrôlé pour s'assurer que les files d'attente justes ne manquent pas de bande passante. Lorsque vous configurez le PQ, vous spécifiez en Kbits/s la bande passante maximale disponible pour cette file d'attente. Les paquets qui dépassent ce maximum sont supprimé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 a été contrôlé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 d'autres paquets non conformes ne sont abandonnés que s'il y a congestion.