Mode de transfert asynchrone (ATM) : Gestion de trafic ATM

Dépannage des pertes en sortie avec la mise en file d'attente par priorité

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


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 devraient être au courant de ces concepts :

  • le priorité-groupe de priority-group ou de Relais de trames active le mécanisme de mise en file d'attente de priorité héritée de Cisco. Supports jusqu'à quatre niveaux des files d'attente prioritaire.

  • IP RTP Priority ou frame-relay ip rtp priority - Les correspondances sur des numéros de port UDP pour le Protocole RTP (Real-Time Protocol) trafiquent encapsulant des paquets VoIP et placent ces paquets dans une file d'attente prioritaire.

  • priorité - La caractéristique de queue de la basse latence de Cisco d'enables (LLQ) et utilise la structure de commande de l'interface de ligne de commande de QoS de qualité de service modulaire (CLI).

Un routeur peut signaler des suppressions de sortie quand l'un de ces méthodes sont configurées, mais il y a d'importantes différences fonctionnelles entre les méthodes et la raison pour des baisses 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. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous fonctionnez dans un réseau vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle commande avant que vous l'utilisiez.

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 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 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 des conventions de document, référez-vous aux conventions utilisées dans des conseils techniques de Cisco.

Baisses avec l'IP RTP Priority et le LLQ

Le guide de configuration Cisco IOS met en garde contre des suppressions de sortie avec ces mécanismes de mise en file d'attente prioritaires :

  • IP RTP Priority : Puisque la commande d'IP RTP Priority accorde la priorité absolue au-dessus de l'autre trafic, elle devrait être utilisée avec soin. En cas de l'encombrement, si le trafic dépasse la bande passante configurée, puis tout le trafic excédentaire est abandonné.

  • commande prioritaire et LLQ : Quand vous spécifiez la commande prioritaire pour une classe, elle prend un argument de bande passante qui donne la bande passante maximum. En cas de l'encombrement, maintenant l'ordre est utilisé pour relâcher des paquets quand la bande passante est dépassée.

Ces deux mécanismes emploient un contrôle intégré pour doser la circulation. Le but du régulateur est de s'assurer que les autres files d'attente sont entretenues par le programmateur de queue. Dans la fonctionnalité de mise en file d'attente d'origine prioritaire de Cisco, qui utilise les commandes de priority-group et de liste de priorité, le programmateur toujours a entretenu la file d'attente de plus haute priorité d'abord. S'il y avait toujours du trafic dans la file d'attente prioritaire, les files d'attente à faible priorité étaient affamées de la bande passante et des paquets allant aux files d'attente non-prioritaires.

Baisses avec la queue de priorité héritée

Le Fonction Priority Queueing (PQ) est le mécanisme de mise en file d'attente de priorité héritée de Cisco. Comme illustré ci-dessous, PQ prend en charge jusqu'à quatre niveaux des files d'attente : haute, support, normale, et bas.

/image/gif/paws/10105/pqpic.gif

L'activation de la file d'attente à priorité déterminée sur une interface change l'affichage de file d'attente de sortie, comme illustré ci-dessous. Avant la file d'attente à priorité déterminée l'interface Ethernet utilise une file d'attente d'attente à sortie unique avec la taille de la 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 l'activation de PQ l'interface Ethernet maintenant utilise quatre files d'attente prioritaire avec des limites variables de file d'attente, suivant les indications de la sortie 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 de liste de priorité {numéro de liste} est utilisée d'assigner la circulation à une file d'attente spécifique. Pendant que les paquets arrivent à une interface, les files d'attente prioritaire sur cette interface sont balayées pour des paquets dans un ordre de priorité décroissant. La file d'attente prioritaire est balayée d'abord, puis la file d'attente prioritaire moyenne, et ainsi de suite. Le paquet à la tête de la file d'attente la plus prioritaire 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 la file d'attente peut se tenir. Quand un paquet de arrivée ferait dépasser la profondeur de la file d'attente en cours la limite de file d'attente configurée, le paquet est lâché. Ainsi, comme remarquable ci-dessus, les suppressions de sortie avec PQ sont typiquement dues à dépasser la limite de file d'attente et pas d'un régulateur interne, comme cela est le cas typique pour LLQ. La commande de queue-limit de numéro de liste de liste de priorité change la taille d'une file d'attente prioritaire.

Mesure du trafic avec un seau à jetons

LLQ et IP RTP Priority implémentent le contrôle intégré à l'aide d'un seau à jetons comme système de mesure du trafic. Cette section regarde le concept de seau à jetons.

/image/gif/paws/10105/policing.gif

Un saut à jetons lui-même n'a aucune stratégie de rejet ni de priorité. Les travaux de métaphore du seau à jetons le long des lignes suivantes :

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

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

  • Pour envoyer un paquet, le régulateur du trafic doit pouvoir retirer un certain nombre de jetons de la position égale dans la représentation à la longueur de paquet.

  • S'il n'y a pas assez de jetons sont dans la position pour envoyer un paquet, le paquet l'un ou l'autre attend jusqu'à ce que la position ait assez de jetons (dans le cas d'un modélisateur) ou le paquet est jeté ou marqué vers le bas (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, le plus grand a éclaté une application peut envoyer dans le réseau est rudement proportionnel à la taille de la position. Un saut à jetons permet les rafales, mais les lie.

Regardons un exemple utilisant les paquets et un débit de données garanti (CIR) de 8000 bps.

  • Dans cet exemple, les positions de jeton initial démarre complètement à 1000 octets.

  • Quand un paquet de 450 octets arrive, le paquet se conforme parce qu'assez d'octets sont disponibles dans le seau à jetons de conformation. Le paquet est envoyé, et 450 octets sont retirés du seau à jetons, partant de 550 octets.

  • Quand le paquet suivant arrive 0.25 seconde plus tard, 250 octets sont ajoutés au seau à jetons ((0.25 * 8000)/8), partant de 700 octets dans le seau à jetons. Si le paquet suivant est de 800 octets, le paquet dépasse, et est lâché. Aucun octet n'est pris du saut à jetons.

Étapes de dépannage pour diagnostiquer des baisses

Étape 1 - Collectez les données

Les étapes pour collecter des données sont affichées ci-dessous.

  1. Exécutez les commandes suivantes plusieurs fois et déterminez à quelle rapidité et combien de fois les baisses incrémentent. Employez la sortie pour établir une spécification de base de vos structures de trafic et pour trafiquer des niveaux. Figure ce qu'est le débit « normal » de baisse 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 monitor la valeur de charge affichée dans la sortie. En outre, assurez-vous que la somme des comptes de baisse de par-file d'attente dans la sortie d'interface d'exposition est équivalente au compte de suppressions de sortie. Les baisses de sortie d'interface d'exposition contre- devraient afficher tout le agrégat de toutes les baisses sur la sortie, y compris l'écart WRED, l'écart en raison de la pénurie de mémoire tampon (erreurs de « aucune mémoire tampon »), et même les écarts dans la mémoire d'adaptateur intégrée de port.

      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: Rxload » d'affichage de quelques interfaces de « valeurs distinctes de « txload » et.

      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
    • interface-nom de show policy-map interface - Recherchez une valeur différente de zéro pour les « écarts de paquets » contre-.

      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: Les valeurs équivalentes suivantes d'affichages d'exemple de sortie pour les « paquets » et des « paquets ont apparié » des compteurs. Cette condition indique qu'un grand nombre de paquets sont commutés par processus ou que l'interface éprouve l'encombrement extrême. Chacun des deux conditions peuvent mener à dépasser la limite de la file d'attente d'une classe et devraient ê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érisez la circulation et les paquets dans ces écoulements.

    • Quelle est la taille moyenne des paquets ?

    • Dans quelle direction la trame de taille d'une mtu circulent-elles ? Beaucoup de circulation est asynchrone en ce qui concerne le chargement. Par exemple, avec un téléchargement de FTP, la plupart des paquets de taille d'une mtu découlent du ftp server au client. Les paquets du client FTP au serveur sont TCP simple Acks.

    • Les paquets utilisent-ils le TCP ou l'UDP ? Le TCP permet à chaque écoulement pour envoyer un nombre autorisé de paquets avant que la source doive interrompre la transmission et attendre la destination pour reconnaître les paquets transmis.

  3. Avec le Relais de trames, déterminez si les baisses se produisent à la file d'attente d'interface ou à une file d'attente de par-circuit virtuel. Le diagramme suivant montre l'écoulement des paquets par un circuit virtuel à relais de trame :

    /image/gif/paws/10105/priorityqueuedrops1.jpg

  4. La file d'attente à priorité déterminée 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. Les contrôles de système de mise en file d'attente la taille de la file d'attente contre 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 relâche le paquet. Essayez augmenter la taille de file d'attente avec la commande de queue-limit de liste de priorité {#} et reprenez la surveillance.

Étape 2 - Assurez la bande passante suffisante

Avec LLQ, le maintien de l'ordre tient compte du traitement équitable d'autres paquets de données dans l'autre mise en file d'attente pondérée basée sur classe (CBWFQ) ou les files d'attente WFQ. Pour éviter des pertes de paquets, soyez sûr d'allouer une quantité optimale de bande passante à la file d'attente prioritaire, prenant en compte le type des codecs utilisés et de caractéristiques d'interface. L'IP RTP Priority ne permettra pas le trafic au delà de la quantité allouée.

Il est toujours le plus sûr d'allouer légèrement plus que la bande passante requise connue à la file d'attente prioritaire. Par exemple, supposez que vous avez alloué 24 bandes passantes de Kbps, le montant forfaitaire prié pour la transmission vocale, à la file d'attente prioritaire. Cette allocation semble sûre parce que la transmission des paquets vocaux se produit à un débit binaire constant. Cependant, parce que le réseau et le routeur ou le commutateur peuvent employer une partie de la bande passante pour produire le jitter et le retard, allouer légèrement plus que la bande passante requise (telle que 25 Kbps) assure la constance et la Disponibilité.

La bande passante allouée pour une file d'attente prioritaire inclut toujours l'en-tête d'encapsulation de la couche 2. Il n'inclut pas le contrôle de redondance cyclique (CRC). (Référez-vous quels octets sont comptés par la queue de classe de service IP à ATM ? pour en savoir plus.) Bien que ce soit seulement quelques octets, le CRC impose une incidence croissante pendant que la circulation inclut un nombre supérieur de petits paquets.

En outre, sur des interfaces ATM, la bande passante allouée pour une file d'attente prioritaire n'inclut pas le temps système suivant de taxe de cellule ATM :

  • Toute remplissage par la segmentation et le réassemblage (SAR) pour faire à la dernière cellule d'un paquet un multiple égal de 48 octets.

  • CRC 4-byte de la remorque de l'adaptation ATM de couche 5 (AAL5).

  • en-tête de cellule ATM 5-byte.

Quand vous calculez la quantité de bande passante pour allouer pour une classe donnée prioritaire, vous devez expliquer le fait qui posent 2 en-têtes sont inclus. Quand l'atmosphère est utilisée, vous devez expliquer le fait que le temps système de taxe de cellule ATM n'est pas inclus. Vous devez également permettre la bande passante pour la possibilité de jitter introduite par des périphériques de réseau dans le chemin voix. Référez-vous à l'aperçu de fonctionnalité de mise en file d'attente à faible latence.

En utilisant la priorité s'alignant pour porter des paquets VoIP, référez-vous à la voix sur ip - consommation de bande passante par appel.

Étape 3 - Assurez la taille de rafale suffisante

Le traitement d'une gamme de paquets laissant une interface par une file d'attente prioritaire dépend de la taille du paquet et du nombre d'octets demeurant dans le seau à jetons. Il est important de considérer les caractéristiques de la circulation étant dirigée vers la file d'attente prioritaire parce que LLQ utilise un régulateur, pas un modélisateur. Un régulateur utilise un seau à jetons comme suit :

  • La position est remplie de jetons basés sur le débit de classe à un maximum du paramètre de rafale.

  • Si le nombre de jetons est supérieur ou égal à longueur de paquet, le paquet est envoyé, et le seau à jetons est décrémenté. Autrement, le paquet est lâché.

La valeur de rafale par défaut de la mesure du trafic du seau à jetons de LLQ est calculée pendant que 200 millisecondes du trafic à la bande passante configurée évaluent. Dans certains cas, la valeur par défaut est insuffisante, en particulier quand le trafic TCP va dans la file d'attente prioritaire. Les écoulements de TCP sont en général bursty et peuvent exiger une taille de rafale plus grande que le par défaut assigné par le système de mise en file d'attente, en particulier sur les liens lents.

La sortie suivante témoin a été générée sur un PVC atmosphère avec du débit de cellules soutenu de 128 Kbps. Le système de mise en file d'attente ajuste la taille de rafale pendant que la valeur spécifique avec la commande prioritaire 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é de LLQ a été étendue pour permettre une taille configurable de rafale validée (Bc) avec la taille de rafale configurante dans le fonctionnalité de mise en file d'attente à faible latence. Avec cette nouvelle fonctionnalité, le réseau peut maintenant faciliter des rafales de trafic provisoires et traiter le trafic réseau plus efficacement.

Utilisez le paramètre de rafale avec la commande prioritaire d'augmenter les octets de valeur de rafale à partir de 1600 à 3200 octets.

policy-map AV 
  class AV 
  priority percent 50 3200

Remarque: Une valeur élevée augmente la bande passante réelle que la classe prioritaire peut utiliser-et peut donner l'apparence que les classes prioritaires obtiennent plus que leur partie équitable de la bande passante.

En outre, le système de mise en file d'attente a initialement assigné une limite interne de file d'attente de 64 paquets à la file d'attente à faible latence. Dans certains cas, quand une rafale de 64 paquets est arrivée à la file d'attente prioritaire, la mesure du trafic déterminerait que la rafale s'est conformée au débit configuré, mais le nombre de paquets a dépassé la limite de file d'attente. En conséquence, quelques paquets queue-ont été relâchés. L'ID de bogue Cisco CSCdr51979 (clients enregistrés seulement) résout ce problème en permettant à la taille de file d'attente prioritaire pour se développer aussi profond qu'autorisée par la mesure du trafic.

La sortie suivante a été capturée sur un PVC de Relais de trames configuré avec un CIR de 56 Kbps. Dans le premier ensemble de sortie témoin, le débit offert combiné du c1 et les classes C2 est de 76 Kbps. La raison est que les valeurs calculées des débits offerts sans des débits de baisse ne représentent pas les débits de transmission réels et n'incluent pas des paquets se reposant dans le modélisateur avant qu'elles soient transmises.

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 cet deuxième ensemble de sortie, les compteurs de show policy-map interface ont normalisé. Sur le PVC de 56 Kbps, la classe c1 envoie environ 50 Kbps, et la classe C2 envoie environ 6 Kbps.

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 la sortie de queue prioritaire si des paquets sont lâchés de la file d'attente prioritaire.

attention Attention :  Avant d'utiliser les commandes debug, référez-vous à la section Informations importantes sur les commandes Debug. La commande de debug priority peut imprimer un grand nombre de sortie de débogage disruptive sur un routeur de production. La quantité dépend du niveau de l'encombrement.

La sortie suivante témoin a été générée 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 file d'attente prioritaire lorsque le paquet a été lâché.

*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

D'autres causes pour des baisses

Les raisons suivantes pour des suppressions de sortie avec LLQ ont été découvertes par le centre d'assistance technique Cisco (TAC) pendant le cas dépannant et documentées dans un état de bogue Cisco :

  • L'augmentation des valeurs de seuil maximal de Détection précoce directe pondérée (WRED) sur une autre classe a épuisé les mémoires tampons disponibles et a mené aux baisses dans la file d'attente prioritaire. Pour aider à diagnostiquer ce problème, des « baisses d'une NO--mémoire tampon » contre- pour la classe prioritaire est prévues pour une version future d'IOS.

  • Si la limite de la file d'attente de l'interface d'entrée est plus petite que la limite de la file d'attente de l'interface de sortie, les pertes de paquets décalent à l'interface d'entrée. Ces symptômes sont documentés dans l'ID de bogue Cisco CSCdu89226 (clients enregistrés seulement). Résolvez ce problème en classant la file d'attente d'entrée et la file d'attente de sortie convenablement pour empêcher des suppressions d'entrée et pour permettre au mécanisme de mise en file d'attente sortant prioritaire pour prendre effet.

  • L'activation d'une caractéristique qui n'est pas prise en charge dans CEF-commuté ou du chemin à commutation rapide rend un grand nombre de paquets commutés par processus. Avec LLQ, des paquets commutés par processus sont maintenus l'ordre actuellement si l'interface est congestionnée. En d'autres termes, même si l'interface n'est pas congestionnée, le système de mise en file d'attente dose des paquets commutés par processus et s'assure que le chargement offert ne dépasse pas la valeur de bande passante configurée avec la commande prioritaire. Ce problème est documenté dans l'ID de bogue Cisco CSCdv86818 (clients enregistrés seulement).

Baisses et Relais de trames de files d'attente prioritaire

Le Relais de trames est un cas particulier en ce qui concerne maintenir l'ordre la file d'attente prioritaire. La vue d'ensemble des fonctionnalités de Mise en file d'attente à faible latence pour relais de trames note la mise en garde suivante : « Le PQ est maintenu l'ordre pour s'assurer que les files d'attente équitables ne sont pas affamées de la bande passante. Quand vous configurez le PQ, vous spécifiez dans le Kbps la bande passante maximale disponible à cette file d'attente. Des paquets qui dépassent ce maximum sont lâchés. » En d'autres termes, initialement, la file d'attente prioritaire d'une service-stratégie configurée dans une classe de mappage de relais de trame a été maintenue l'ordre au cours des périodes d'encombrement et de non-encombrement. IOS 12.2 enlève cette exception. PQ est encore maintenu l'ordre avec le FRF.12, mais d'autres paquets non conformes sont seulement lâchés s'il y a d'encombrement.


Informations connexes


Document ID: 10105