Comprendre les limites de file d'attente et les pertes de sortie sur les plates-formes logicielles IOS

Introduction

Ce document décrit les limites de file d'attente et les pertes de sortie sur les plates-formes logicielles Cisco IOS® et les anciens routeurs d'accès.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Guide de configuration des solutions de qualité de service Cisco IOS®

• QoS : Hierarchical Queueing Framework (HQF)

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :

• Pour Pre-HQF : routeurs Cisco qui exécutent le logiciel Cisco IOS Version 12.3(26)

• Pour HQF : routeurs Cisco qui exécutent le logiciel Cisco IOS version 12.4(22)T

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Conventions

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

Informations générales

Ce document s'applique uniquement aux plates-formes logicielles Cisco IOS®, qui incluent généralement les routeurs des gammes Cisco 7200VXR et Cisco ISR 3800, 2800, 1800, et les anciens routeurs d'accès Cisco qui incluent les gammes 3700, 3600, 2600 et 1700.

Amorce Pondérée Basée Sur Les Classes Pour La Mise En File D'Attente Équitable

Dans les images Cisco IOS antérieures à HQF, toute classe avec une bandwidth commande peut généralement être hiérarchisée par rapport aux classes sans bande passante ou priorité en fonction du poids des classes. Afin de comprendre l'algorithme de planification CBWFQ (Class-Based Weighted Fair Queueing), vous devez d'abord comprendre le concept de pondération, qui est spécifique au flux pour les files d'attente équitables basées sur le flux et spécifique à la classe pour les files d'attente individuelles basées sur la classe dans la file d'attente pondérée basée sur la classe.

La formule permettant de calculer le poids d'une file d'attente équitable basée sur les flux est la suivante :

32384 / (IP Prec + 1)

Les classes définies par l'utilisateur dans une file d'attente pondérée basée sur les classes dérivent leurs pondérations respectives en fonction de la bandwidth commande configurée dans la classe en tant que proportion de la SOMME de toutes les classes de bande passante dans la file d'attente basée sur les classes. La formule exacte est propriétaire.

Dans les images HQF, les files d'attente équitables basées sur le flux, configurables à la fois dans les classes définies par l'utilisateur et dans la classe par défaut avec la file d'attente équitable, sont planifiées de manière égale (au lieu de par poids). En outre, dans HQF, la priorité de planification d'une file d'attente basée sur les classes est déterminée sur la base de l'ordonnanceur HQF et non sur la formule de pondération héritée des classes.

Remarque : cette section ne se veut pas une analyse comportementale complète des opérations de mise en file d'attente par classe. L'intention est d'expliquer comment CBWFQ applique les limites de file d'attente et les pertes de sortie.

Comprendre les limites de file d'attente et les pertes

Classes définies par l'utilisateur configurées avec la commande Priority

Pour les classes définies par l'utilisateur MQC configurées avec n'importe quelle variante de la priority commande, avec priority, priority <kbps> et priority percent inclus.

Comportement pré-HQF

Techniquement, même s'il n'existe aucune interface de ligne de commande (CLI) pour la voir, et qu'elle n'est pas configurable, il existe une file d'attente système masquée qui est partagée par toutes les données de classe de priorité. Il agit comme un référentiel temporaire pour les données prioritaires après leur classification et leur autorisation par le régulateur sensible à la congestion. Les paquets LLQ sont placés dans cette file d'attente système masquée s'ils ne peuvent pas être placés directement sur l'anneau de transmission de l'interface de sortie pendant l'interruption de réception, qui est autrement appelée congestion fonctionnelle. Dans cette situation, du fait de l'encombrement fonctionnel, le paquet est évalué par rapport au régulateur conditionnel LLQ tout au long de l'interruption de réception et tant qu'il appartient toujours au pilote d'interface de réception. Si le paquet n'est pas abandonné par le régulateur conditionnel LLQ, il est placé dans cette file d'attente système LLQ masquée et l'interruption de réception est libérée. Par conséquent, tous les paquets placés dans cette file d'attente système cachée sont conformes au régulateur sensible à la congestion LLQ et peuvent être immédiatement retirés de la file d'attente vers l'anneau de transmission de l'interface de sortie par le planificateur LLQ/CBWFQ.

Malgré l'existence de cette file d'attente, le comportement est différent des files d'attente Cisco IOS créées pour les données non LLQ (telles que les files d'attente à équité et les files d'attente à bande passante) dans le sens où aucune latence de mise en file d'attente supplémentaire (au-delà de la latence de transmission en anneau) ne peut être encourue puisque les paquets dans cette file d'attente peuvent être immédiatement drainés vers l'anneau de transmission par le planificateur LLQ/CBWFQ. Si un paquet de classe de priorité n'est pas abandonné par le régulateur conditionnel pendant l'interruption de réception, alors ce paquet LLQ peut exister brièvement dans cette file d'attente système masquée avant d'être retiré de la file d'attente vers l'anneau de transmission de l'interface de sortie. Dans ce cas, le planificateur LLQ/CBWFQ peut immédiatement présenter le paquet à l'anneau de transmission de l'interface de sortie. Le Conditional Policer s'est exécuté avant d'admettre le paquet à LLQ/CBWFQ. Par conséquent, sa limite est la LLQ au taux de priorité configuré.

En résumé, il est recommandé d’abandonner les données LLQ qui dépassent le taux de priorité en cas d’encombrement plutôt que de subir une latence de mise en file d’attente supplémentaire, qui est un composant fondamental de LLQ. Ce mécanisme de contrôle conditionnel autorise une file d'attente prioritaire stricte et ne permet pas à la file d'attente prioritaire de monopoliser l'interface PLIM entière, ce qui constitue une amélioration par rapport à la fonctionnalité de mise en file d'attente prioritaire héritée de Cisco IOS.

• Limite de file d'attente pré-HQF : NA

• Priorité pré-HQF + comportement de détection aléatoire : NA, WRED non autorisé dans LLQ.

• Pré-HQF priority + fair-queue » behavior : NA, fair-queue non autorisé dans LLQ.

• Pré-HQF priority + random-detect + fair-queue behavior : NA, ni fair-queue ni random-detect pris en charge dans LLQ.

Comportement HQF

Identique à Pre-HQF sauf que la file d'attente masquée n'est plus masquée et que la queue-limit est maintenant configurable et est définie par défaut sur 64 paquets.

• Limite de file d'attente HQF : 64 paquets

• Priorité HQF + comportement de détection aléatoire : NA, WRED non autorisé dans LLQ.

• Priorité HQF + comportement de la file d'attente équitable : NA, la file d'attente équitable n'est pas autorisée dans LLQ.

• HQF priority + random-detect + fair-queue behavior : NA, ni fair-queue ni random-detect pris en charge dans LLQ.

Classes définies par l'utilisateur configurées avec la commande Bandwidth

Pour les classes définies par l'utilisateur MQC configurées avec n'importe quelle variante de la bandwidth commande, avec bandwidth <kbps> , bandwidth percent , et bandwidth remaining percentinclus.

Comportement pré-HQF

La limite de file d'attente par défaut est de 64 paquets, ce qui est réglable. Si, pendant l'interruption de réception, vous devez mettre un paquet en file d'attente, ce qui entraînerait > 64 paquets dans la file d'attente, le paquet est abandonné.

• Pre-HQF queue-limit : 64 paquets, réglables via queue-limit.

• Bande passante pré-HQF + comportement de détection aléatoire :

Exemple :

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

Si une variante de la bande passante est configurée avec une variante de la détection aléatoire, ignorez toute CLI queue-limit, ce qui supprime efficacement toute limite de tampon dans la classe. En d'autres termes, random-detect et queue-limit s'excluent mutuellement dans les images pré-HQF. Avec random-detect as drop strategy, la taille de file d'attente actuelle n'est pas limitée et peut théoriquement occuper chaque tampon alloué à la file d'attente équitable basée sur la classe, où ce nombre de tampons alloués à la file d'attente équitable basée sur la classe est dérivé sur le point d'attachement de la politique de service :

• Interface physique : 1 000 paquets, réglable avec interface CLI hold-queue out

• PVC ATM : 500 paquets, réglable avec PVC CLI vc-hold-queue

• Frame-Relay map-class : 600 paquets, réglables avec frame-relay map-class CLI frame-relay hold-queue

• Stratégie de mise en forme basée sur la classe appliquée à la (sous)interface (pré-HQF) : 1000 paquets, réglables avec les tampons max-shape de la CLI de la classe MQC.

Remarque : tous les exemples de mise en forme Frame Relay et basée sur les classes supposent que la somme des shapers ne dépasse pas la fréquence d'horloge de l'interface.

Remarque : dans les images antérieures à HQF, lorsqu'une politique de mise en forme basée sur les classes est appliquée à une (sous-)interface, méfiez-vous de la vitesse de l'interface physique sous-jacente, car les interfaces <2 Mbits/s peuvent être définies par défaut sur une file d'attente pondérée équitable et les interfaces >2 Mbits/s peuvent être définies par défaut sur FIFO. Dans la pré-HQF, la file d'attente de mise en forme peut alimenter la file d'attente d'interface, que la politique de mise en forme soit attachée au niveau de la sous-interface ou de l'interface physique.

Pendant l'interruption de réception, chaque fois qu'un paquet devient candidat pour une file d'attente de sortie d'interface, la taille moyenne de file d'attente WRED est calculée avec la formule suivante :

Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

Si la taille moyenne de file d'attente résultante est :

• Plus petit que le seuil minimum WRED, mettez le paquet en file d'attente et libérez l'interruption de réception.
• Entre le seuil minimum WRED et le seuil maximum WRED, abandonnez éventuellement le paquet avec une probabilité accrue lorsque la taille moyenne de la file d'attente se rapproche du seuil maximum WRED. Si la taille moyenne de la file d'attente est exactement égale au seuil maximal WRED, le paquet est abandonné en fonction du dénominateur de probabilité de marquage. Le dénominateur de probabilité de marquage sert également de base pour déterminer le pourcentage de paquets pouvant être abandonnés lorsque la limite moyenne de file d'attente n'est pas exactement égale au seuil maximal WRED, mais supérieure au seuil minimal WRED. Voici un exemple graphique :

Limite moyenne de file d'attente non égale au seuil maximal WRED mais supérieure au seuil minimal WRED

• • Si le paquet est abandonné, l'interruption de réception est libérée et une suppression aléatoire est incrémentée. Si le paquet n'est pas abandonné, il est mis en file d'attente et l'interruption de réception est libérée.

  • Supérieur au seuil maximal WRED, abandonnez le paquet, relâchez l'interruption de réception et incrémentez un abandon de fin.

Remarque : la fonction WRED basée sur la priorité IP (par défaut) et la fonction DSCP permet de définir différemment le seuil minimum, le seuil maximum et le dénominateur de probabilité de marque pour différentes valeurs. C'est là que la composante pondérée de la détection précoce aléatoire est évidente. Vous pouvez protéger certaines valeurs ToS par rapport à d'autres valeurs lorsque vous réglez leurs seuils relatifs et marquez les dénominateurs de probabilité.

Lorsque la détection aléatoire et la bande passante sont configurées ensemble, la taille de la file d'attente actuelle peut être supérieure au seuil maximal WRED à tout moment. En effet, les seuils minimum et maximum WRED agissent uniquement en fonction de la taille de file d'attente moyenne (et non actuelle). Cela permet d'expirer toutes les mémoires tampon allouées à la file d'attente basée sur les classes, ce qui peut entraîner des pertes de mémoire tampon qui se produisent n'importe où dans la file d'attente équitable basée sur les classes (référez-vous à l'ID de bogue Cisco CSCsm94757).

• Bande passante pré-HQF + comportement de file d'attente équitable : NA, fair-queue non autorisé dans la classe de bande passante.

• Bande passante pré-HQF + détection aléatoire + comportement de file d'attente équitable : NA, fair-queue non autorisé dans la classe de bande passante

Comportement HQF

Le comportement est le même que celui décrit dans la section Pre-HQF.

• HQF queue-limit : 64 paquets, réglable via queue-limit.

C'est la même chose que dans le cadre pré-HQF.

• Bande passante HQF + comportement de détection aléatoire :

Exemple :

policy-map HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   queue-limit 512
   random-detect

Remarque : la limite de file d'attente par défaut est de 64 paquets.

Le comportement est le même que dans la section équivalente pré-HQF, avec une exception importante. Dans les images HQF, random-detect et queue-limit peuvent coexister dans la même classe définie par l'utilisateur (ou class-default) et queue-limit peut être activé et réglé sur 64 paquets dans une configuration par défaut. En tant que tel, queue-limit peut servir de taille de file d'attente actuelle maximale dans une classe de détection aléatoire, par conséquent, il peut fournir un mécanisme pour limiter les abandons sans tampon décrits dans la section équivalente pré-HQF. En raison de cet ajout, la limite de file d'attente configurée doit être au moins aussi grande que le seuil max-threshold de détection aléatoire, où le seuil max-threshold de détection aléatoire peut être défini par défaut sur 40 paquets, ou bien l'analyseur peut rejeter la configuration.

Ceci introduit un contrôle current-queue-limit dans les classes WRED, dans lequel, même si le calcul de la profondeur moyenne de la file d'attente est inférieur au seuil maximal, si la taille actuelle (et non moyenne) de la file d'attente est supérieure à la limite de la file d'attente, le paquet peut être abandonné, l'interruption de réception libérée et une suppression de fin enregistrée. N'oubliez pas que si la queue-limit est réglée à un niveau suffisamment élevé pour épuiser les tampons de mise en file d'attente agrégés pour la file d'attente basée sur les classes, aucune suppression de tampon ne peut se produire. Les tampons de mise en file d'attente agrégés pour HQF sont définis ici :

• Interface physique : 1 000 paquets, réglable avec interface CLI hold-queue out.

• PVC ATM : 500 paquets, réglable avec PVC CLI vc-hold-queue.

• Frame-Relay map-class : 600 paquets, réglables avec frame-relay map-class CLI frame-relay hold-queue.

• Stratégie de mise en forme basée sur la classe appliquée à l'interface physique dans le code HQF : 1000 paquets, réglable avec une combinaison d'interface CLI hold-queue out et de stratégie enfant queue-limit où la stratégie enfant queue-limit a une limite supérieure d'interface hold-queue out.

• Stratégie de mise en forme basée sur la classe appliquée à la sous-interface dans le code HQF : 512 paquets, non accordable (étudier avec l'équipe de plate-forme QoS NSSTG, doit-elle être accordable).

Remarque : tous les exemples de mise en forme Frame Relay et basée sur les classes supposent que la somme des shapers ne dépasse pas la fréquence d'horloge de l'interface.

Voici un exemple du monde réel :

policy-map JACKLYN
 class 1
    bandwidth 64
    queue-limit 500 packets
     random-detect
     random-detect precedence 1 22 300

Au cours de cette sortie, aucun trafic n'est généré via l'interface :

F340.11.25-7200-5_LAC#show policy-map interface | i queue      
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 0/387595/0

!--- Current_q_depth is 0

        Mean queue depth: 107 packets

!--- last calculation of Average_queue_depth

À ce stade, le trafic est démarré. Le flux n’est pas en rafale à 400 PPS et se compose de trames de 1 000 octets :

F340.11.25-7200-5_LAC#show policy-map interface | i queue
  queue limit 500 packets
  (queue depth/total drops/no-buffer drops) 461/387641/0

!--- 461 is Current_q_depth > Prec 1 max-thresh of 300 
!--- but < "queue-limit 500 packets".

  Mean queue depth: 274 packets

!--- Avg_q_depth is rising, Mark Prob Denom is being used.

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 363/387919/0 

!--- 363 is Current_q_depth and it is falling compared to last 
!--- iteration because WRED is random dropping packets. Mean queue depth: 351 packets 
!--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop 
!--- in addition to random-drop. 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 199/388263/0 
 Mean queue depth: 312 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 303/388339/0 
 Mean queue depth: 276 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 325/388498/0 
 Mean queue depth: 314 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 298/390075/0 
 Mean queue depth: 300 packets  

Notez qu'avec un flux sans rafales, la profondeur moyenne de la file d'attente WRED peut être égale à la profondeur actuelle de la file d'attente, ce qui correspond au comportement attendu.

• Bande passante HQF + comportement de file d'attente équitable :

Lorsque la bande passante et la file d'attente équitable sont appliquées ensemble à une classe définie par l'utilisateur HQF, chaque file d'attente basée sur le flux se voit attribuer une limite de file d'attente égale à .25 * queue-limit. Étant donné que la limite de file d'attente par défaut est de 64 paquets, chaque file d'attente basée sur le flux dans une file d'attente équitable peut se voir attribuer 16 paquets. Si quatre flux traversaient cette classe, par défaut chaque file d'attente de flux aurait 16 paquets, par conséquent vous ne vous attendriez jamais à voir un total de paquets mis en file d'attente de >64 (4 *16). Toutes les pertes en aval d'une file d'attente de flux individuelle sont enregistrées en tant que pertes en aval. Si le nombre de files d'attente de flux était considérablement élevé, tout comme la limite de file d'attente, une autre opportunité de suppression sans tampon se présenterait. Par exemple, si vous supposez que le point d'attachement de stratégie est une interface physique, où 1000 tampons agrégés sont alloués :

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128

Dans cette configuration, un trafic appréciable dans toutes les files d'attente de flux peut affamer les tampons d'interface agrégés et entraîner des pertes sans tampon dans d'autres classes définies par l'utilisateur (voir ID de bogue Cisco CSCsw98427). En effet, 1024 files d'attente de flux, chacune avec une limite de file d'attente de 32 paquets, peuvent facilement dépasser l'allocation de tampon de mise en file d'attente basée sur les classes de l'interface agrégée 1000.

• Bande passante HQF + détection aléatoire + comportement de file d’attente équitable :

Exemple :

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128
  random-detect

Identique à la bande passante et à la file d'attente équitable dans la section, à l'exception de la taille moyenne de file d'attente WRED qui est calculée chaque fois qu'un paquet arrive pour décider si le paquet doit être abandonné de manière aléatoire ou en queue. Comme avec le pré-HQF, toutes les files d'attente de flux peuvent partager une instance de seuils WRED, ce qui signifie que tous les paquets mis en file d'attente vers toutes les files d'attente de flux sont utilisés pour calculer la profondeur moyenne de file d'attente WRED, puis la décision d'abandon applique les seuils WRED minimum et maximum aux paquets agrégés dans toutes les files d'attente de flux. Cependant, un autre écart par rapport à la bande passante et à la file d'attente équitable dans la section, étant donné qu'une instance des seuils WRED s'applique à toutes les files d'attente basées sur les flux, la limite de file d'attente de chaque file d'attente de flux (.25 * « queue-limit ») est ignorée et respecte à la place la limite de file d'attente agrégée Classes pour une vérification de limite de file d'attente actuelle.

Comportement par défaut de classe

Comportement pré-HQF

Dans les versions antérieures à HQF, Class Default prend par défaut la valeur fair-queue, toutes les files d'attente de flux partagent la limite de file d'attente pour la classe (la valeur par défaut est 64) et il n'y a pas de réservation de bande passante. En d'autres termes, le nombre total de paquets mis en file d'attente dans toutes les files d'attente de flux ne peut jamais dépasser la limite de file d'attente. La quantité de paquets mis en file d'attente dans chaque file d'attente de flux peut dépendre du poids calculé de la file d'attente de flux. Inversement, si fair-queue et random-detect sont utilisés ensemble dans class-default, la queue-limit peut être ignorée et toutes les files d'attente de flux peuvent partager les mêmes seuils WRED. Ainsi, tous les paquets actuellement mis en file d'attente dans toutes les files d'attente de flux peuvent être utilisés pour calculer la taille moyenne de file d'attente WRED. Étant donné que la taille de file d'attente actuelle n'a pas de limite supérieure dans cette configuration, l'opportunité de suppression sans tampon est élevée (référez-vous à l'ID de bogue Cisco CSCsm94757).

• Si la bande passante est ajoutée à class-default, cela peut entraîner un comportement décrit dans la section Pre-HQF Behavior - User Defined Classes Configured with the "bandwidth" Command.

• Si la bande passante et la détection aléatoire sont ajoutées à class-default, cela peut entraîner un comportement décrit dans la section Pre-HQF bandwidth + random-detect behavior de Pre-HQF Behavior - User Defined Classes Configured with the "bandwidth".

Remarque : dans le pré-HQF, la bande passante ne peut pas coexister avec la file d'attente équitable dans class-default.

Comportement HQF

Dans HQF, Class Default prend par défaut la valeur d'une file d'attente FIFO et se voit attribuer une pseudo-réservation de bande passante basée sur les allocations restantes des classes définies par l'utilisateur. Ainsi, pour connaître le comportement par défaut de la classe HQF, consultez la section Comportement HQF - Classes définies par l'utilisateur configurées avec la commande « bandwidth ». À tout moment, quelle que soit la configuration, la classe par défaut dans les images HQF peut toujours avoir une réservation de bande passante implicite égale à la bande passante d'interface inutilisée non consommée par les classes définies par l'utilisateur. Par défaut, la classe class-default reçoit au moins 1 % de la bande passante de l'interface ou de la forme parente. Il est également possible de configurer explicitement la CLI de la bande passante dans la classe par défaut.

• Si fair-queue est configuré dans class Class-Default, le comportement correspond à la section HQF bandwidth + fair-queue behavior de HQF Behavior - User Defined Classes Configured with the "bandwidth".

• Si fair-queue et random-detect sont configurés ensemble dans Class-Default, le comportement correspond à la section HQF bandwidth + random-detect + fair-queue behavior de HQF Behavior - User Defined Classes Configuré avec la commande « bandwidth ».

Informations connexes

• Guide de configuration des solutions de qualité de service Cisco IOS, version 12.2SR
• QoS : Hierarchical Queueing Framework (HQF) [Non pris en charge]
• Prise en charge des routeurs
• Assistance technique de Cisco et téléchargements