Présentation de la mise en file d'attente des mises à jour de routage et des paquets de contrôle de couche 2 sur une interface dotée d'une stratégie de service QoS

Introduction

Ce document explique comment les messages de protocole de routage, tels que les HELLO et les descripteurs de base de données, ainsi que le trafic de contrôle important sont mis en file d'attente lorsqu'une interface de routeur sortant est configurée avec une stratégie de service à l'aide des commandes de l'interface de ligne de commande (MQC) de qualité de service modulaire.

Plus précisément, ce document passe en revue ces deux mécanismes utilisés par les routeurs Cisco IOS^® pour hiérarchiser les paquets de contrôle :

Champ	Emplacement	Lorsque la priorité est prise en compte
Bits de priorité IP	Type d'octet de service (TOS) dans l'en-tête IP	Fournit la priorité via le réseau
pak_priority	Étiquette de paquet interne à l’intérieur du routeur, attribuée par le pilote d’interface	Fournit la priorité via le routeur (par saut)

Les deux mécanismes sont conçus pour s'assurer que des paquets de contrôle de clé ne sont pas supprimés ou qu'ils sont supprimés en dernier par le routeur et le système de mise en file d'attente lorsqu'une interface de sortie est congestionnée.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Les informations de ce document sont basées sur le logiciel Cisco IOS Version 12.2.

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. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Balises de hiérarchisation de paquets externes

Request for Comments (RFC) 791 définit l'octet TOS dans l'en-tête d'un paquet IP. Bien que RFC 2474 et RFC 2475 redéfinissent cet octet en tant que valeurs DSCP (Differentiated Services Code Point), un routeur Cisco IOS utilise toujours les bits de priorité IP d'origine de l'octet TOS, conformément à RFC 791. Notez comment le RFC définit l'octet TOS :

« Le type de service fournit une indication des paramètres abstraits de la qualité de service désirée. Ces paramètres doivent être utilisés pour guider la sélection des paramètres de service réels lors de la transmission d’un datagramme via un réseau particulier. Plusieurs réseaux offrent une priorité de service, qui considère d'une certaine manière le trafic de haute priorité comme plus important que le trafic d'autres types de trafic (généralement en acceptant uniquement le trafic au-dessus d'une certaine priorité au moment de la charge élevée). »

Comme l'illustre le schéma, le champ de priorité IP occupe les trois bits les plus significatifs de l'octet TOS. Seuls les trois bits de priorité IP reflètent la priorité ou l’importance du paquet, et non la valeur totale de l’octet TOS.

Ce tableau répertorie les valeurs des bits de priorité :

Nombre	Valeur binaire	Name (nom)
0	000	Routine
1	001	Priorité
2	010	Immédiat
3	011	Flash
4	100	Remplacement Flash
5	101	CRITIQUE/ECP
6	110	Contrôle interréseau
7	111	Contrôle du réseau

Cisco IOS attribue une priorité IP de 6 aux paquets de protocole de routage sur le plan de contrôle. Comme indiqué dans la RFC 791, « La désignation de contrôle interréseau est destinée à être utilisée uniquement par les initiateurs du contrôle de passerelle. » Plus précisément, Cisco IOS marque ces paquets de contrôle IP : OSPF (Open Shortest Path First), RIP (Routing Information Protocol), HELLO EIGRP (Enhanced Interior Gateway Routing Protocol) et keepalives. Les paquets Telnet à destination et en provenance du routeur reçoivent également une valeur de priorité IP de 6. La valeur attribuée reste avec les paquets lorsque l'interface de sortie les transmet au réseau.

Balises de hiérarchisation des paquets internes

Alors que la valeur de priorité IP spécifie le traitement d'un datagramme dans sa transmission via le réseau, le mécanisme pak_priority spécifie le traitement d'un paquet lors de sa transmission à l'intérieur du routeur.

Outre le coeur d'un processeur de routeur, chaque interface utilise un contrôleur réseau ou un processeur local, qui exécute un logiciel spécial appelé pilote. Le code du pilote fournit des instructions spécifiques à l'interface.

Lorsqu'il reçoit un paquet, le pilote d'interface copie le paquet d'une petite mémoire tampon FIFO (First-in, First-out) vers une mémoire tampon de données en entrée/sortie (E/S). Il joint ensuite un petit en-tête de paquet à la mémoire tampon. L’en-tête de paquet, appelé structure de type de paquet dans la terminologie Cisco IOS, contient des informations clés sur le bloc de données dans la mémoire tampon. Selon le contenu du paquet, l’en-tête du paquet peut pointer vers l’adresse en mémoire où commence l’en-tête d’encapsulation Ethernet, l’en-tête IP (Internet Protocol) et TCP (Transmission Control Protocol).

Le logiciel Cisco IOS utilise les champs de l’en-tête de paquet pour contrôler le traitement du paquet dans les files d’attente d’interface. L'en-tête de paquet inclut l'indicateur pak_priority, qui indique l'importance relative des paquets marqués pour le système de mise en file d'attente.

Les processus de routage RIP et OSPF qui s’exécutent sur le processeur principal d’un routeur marquent tout le trafic dont ils proviennent avec la priorité IP 6 et pak_priority. En revanche, le protocole BGP (Border Gateway Protocol) demande au protocole TCP de marquer son trafic avec la priorité IP 6, mais ne définit pas pak_priority.

Cisco IOS doit également garantir une faible probabilité de perte pour plusieurs types de paquets de contrôle non IP. Ces types de paquets incluent les suivants :

• Messages de protocole de routage IS-IS (Intermediate System-to-Intermediate System)

• Messages EIGRP (Enhanced Interior Gateway Routing Protocol)

• Le protocole PPP (Point-to-Point Protocol) et le protocole HDLC (High-Level Data Link Control) assurent des keepalives sur les interfaces série et POS (Packet over SONET).

• Cellules OAM (Operations, Administration and Maintenance) et messages ARP (Address Resolution Protocol) sur les interfaces ATM

Puisque ce trafic n'est pas IP, Cisco IOS ne peut pas correspondre à la valeur de priorité IP pour fournir la hiérarchisation. Au lieu de cela, il utilise uniquement la valeur pak_priority interne dans l'en-tête de tampon de paquets.

Remarque : La gamme Cisco Catalyst 6000 / Cisco 7600 prenait initialement en charge le mécanisme pak_priority sur FlexWAN uniquement. Par la suite, des améliorations ont été apportées à la hiérarchisation des paquets de contrôle IP et non IP.

Balises de hiérarchisation des paquets et mise en file d’attente

Les routeurs tels que les routeurs RSP (Route/Switch Processor) Cisco 7500 et les routeurs de bas de gamme (tels que les routeurs des gammes Cisco 7200 et 3600) utilisent un mécanisme différent pour acheminer et contrôler le trafic que le processeur VIP (Versatile Interface Processor) Cisco 7500. Ce tableau récapitule les deux approches et suppose qu'une stratégie de service configurée avec le MQC est appliquée à l'interface de sortie.

Plateforme	Mise en file d'attente des messages pak_priority
Gamme Cisco 7500 (avec QoS et VIP distribués)	Place le trafic pak_priority dans la file d'attente de classe par défaut par défaut ou dans une file d'attente spécifique (séparée) configurée. Lorsqu'ils sont mis en file d'attente par classe par défaut, les paquets vont à l'extrémité arrière de la file d'attente. L'indicateur pak_priority est utilisé pour éviter de supprimer les paquets de haute priorité.
QoS basée sur RSP et autres plates-formes, comprenant les gammes Cisco 7200, 3600 et 2600	Place le trafic pak_priority dans un ensemble distinct de files d'attente autres que class-default. (Voir la section Comprendre les files d'attente spéciales avec des plates-formes non RSP.) Marque ces messages avec une valeur de poids spéciale (actuellement 1024).

En d'autres termes, sur la gamme Cisco 7500, si une stratégie de service de sortie est attachée à l'interface, les paquets sont classés par rapport aux classes de cette stratégie et le paquet pak_priority est placé à la fin de la file d'attente de classe choisie. Si le paquet pak_priority ne correspond à aucune classe définie par l'utilisateur, il est placé à la fin de la file d'attente class-default.

Remarque : avec les méthodes de mise en file d'attente héritées telles que la mise en file d'attente par priorité et la mise en file d'attente personnalisée ou avec une file d'attente FIFO d'interface par défaut, les routeurs non-RSP mettent en file d'attente les messages pak_priority au début de la file d'attente afin d'assurer une latence minimale et une probabilité d'abandon minimale.

Comprendre les files d'attente spéciales avec une plate-forme non RSP

Comme indiqué dans le tableau Balises de hiérarchisation des paquets et mise en file d'attente, les plates-formes de routeurs Cisco telles que les gammes Cisco 7200, 3600 et 2600 placent les messages pak_priority dans un ensemble distinct de files d'attente et non dans l'ensemble de files d'attente par classe.

Il existe trois ensembles de files d’attente sur une interface :

• 2^n ensemble de files d’attente basées sur le flux qui prennent en compte des valeurs d’en-tête telles que les adresses IP source et de destination. Le nombre réel de files d’attente est basé sur la bande passante de l’interface ou du circuit virtuel. Reportez-vous à la description de la commande fair-queue dans la référence des commandes Cisco IOS.

• Files d'attente pour les classes créées par l'utilisateur.

• Files d'attente accessibles sur la base d'un hachage du type de liaison. Par exemple, les microflux IP sont classés par le système de file d'attente équitable en files d'attente basées sur un hachage des adresses et des ports source et de destination, des bits TOS et du numéro de protocole IP. Les messages LMI (Frame Relay Local Management Interface) sont mis en file d’attente en fonction d’un hachage du numéro magique qui indique que le message est LMI. Les messages avec l'indicateur pak_priority entrent dans ces files d'attente de type de liens distinctes.

Ce tableau répertorie les différentes files d'attente et leurs ID de conversation (comme le montre le résultat des commandes show policy-map interface ou show queue) pour une interface avec une bande passante supérieure à 512 Kbits/s.

Numéro de conversation/file d'attente	Type de trafic
1 - 256	Files d'attente de trafic basées sur le flux général. Le trafic qui ne correspond pas à une classe créée par l'utilisateur correspond à la classe par défaut et à l'une des files d'attente basées sur le flux.
257 - 263	Réservé au protocole CDP (Cisco Discovery Protocol) et aux paquets marqués d'un indicateur de priorité haute interne.
264	File d'attente réservée pour la classe de priorité (classes configurées avec la commande priority). Recherchez la valeur « Priorité stricte » pour la classe dans la sortie show policy-map interface. La file d'attente prioritaire utilise un ID de conversation égal au nombre de files d'attente dynamiques plus 8.
265 et plus	Files d'attente pour les classes créées par l'utilisateur.

Remarque : Les valeurs de ce tableau dépendent de la mise en oeuvre et peuvent être modifiées.

Hiérarchiser les paquets IS-IS

Les paquets de contrôle de routage IS-IS (Intermediate System to Intermediate System) sont un cas particulier en ce qui concerne la mise en file d'attente et la hiérarchisation des paquets.

Le IS-IS est le protocole de routage du CLNP (Connectionless Network Protocol) de l'Organisation internationale de normalisation (ISO). Les développeurs de la CLNP considéraient TCP/IP comme une suite de protocoles provisoire que la suite OSI (Open System Interconnection) remplacerait éventuellement. Afin de prendre en charge cette transition prévue, Integrated IS-IS (ou Dual IS-IS) a été créé en tant qu'extension de IS-IS pour fournir un protocole de routage unique capable de router à la fois CLNS (Connectionless-mode Network Service) et IP. Le protocole a été conçu pour fonctionner dans un environnement CLNS pur, un environnement IP pur ou un environnement CLNS/IP double.

Même lorsque IS-IS est utilisé pour acheminer uniquement TCP/IP, IS-IS est toujours un protocole CLNP ISO. Les paquets par lesquels IS-IS communique avec ses homologues sont des unités de données de protocole (PDU) CLNS, ce qui signifie que même dans un environnement IP uniquement, le système de mise en file d'attente et Cisco IOS ne peuvent pas utiliser la priorité IP pour hiérarchiser les messages de contrôle CLNS. Au lieu de cela, les paquets IS-IS reçoivent une priorité via le mécanisme pak_priority à l'intérieur du routeur.

Configurer une stratégie de mise en file d’attente pour les paquets de routage

Cette section traite des trois approches générales de la conception d’une stratégie de mise en file d’attente spécifiquement pour minimiser les risques de perte de paquets de contrôle dans des conditions d’encombrement importantes sur la gamme Cisco 7500 et les VIP. (Souvenez-vous que les plates-formes non RSP placent les paquets de contrôle dans des files d'attente distinctes par défaut.)

Stratégie	Cas d’utilisation	Description de la configuration
Correspondance avec une file d'attente distincte.	Stratégie la plus conservatrice. Assure peu ou pas de chutes.	Utilisez l'interface de ligne de commande QoS modulaire pour configurer une classe distincte et utilisez la commande bandwidth pour affecter une allocation de bande passante minimale au trafic correspondant pendant les périodes d'encombrement. Une classe configurée avec la commande bandwidth utilise un « poids » de planification basé sur la bande passante et non sur la priorité IP. Reportez-vous à Présentation de la mise en file d'attente pondérée basée sur les classes sur ATM.
Associez class-default à fair queuing.	Suffisant pour la plupart des configurations. Certains paquets de contrôle peuvent être supprimés en présence d'encombrement.	Utilisez la priorité IP 6 attribuée automatiquement par Cisco IOS au paquet pour influencer son poids et donc sa part de bande passante. Voir Présentation de la mise en file d'attente pondérée sur ATM.
Associez class-default à la mise en file d'attente FIFO.	Non recommandé pour les liaisons encombrées. Certains paquets de contrôle peuvent être supprimés en présence d'encombrement.	Cette approche ne tient pas compte de la priorité IP. Avec la QoS basée sur VIP, les messages pak_priority sont mis en file d'attente vers la fin de la file d'attente FIFO.

Voici un exemple de création d'une file d'attente séparée pour les paquets de contrôle RIP.

 class-map match-all rp 
   match access-group 104 
! 
 access-list 104 permit udp any eq rip any eq rip 

!--- Create a class-map that matches an ACL permitting RIP. 

! 
 policy-map bandwidth 
   class voip 
     priority 64 
   class bus 
    bandwidth 184 
   class RP 
    bandwidth 8 

!--- Create a policy-map (named "bandwidth") and specify !--- class RP. 
! 
interface Serial1/0:0.1 point-to-point 
  bandwidth 256 
  ip unnumbered Loopback0 
  ip accounting precedence input 
  no cdp enable 
  frame-relay class sample 
  frame-relay interface-dlci 100 IETF 

!--- Apply the map-class named "sample" to the PVC. 

! 
map-class frame-relay sample 
  frame-relay cir 256000 
  frame-relay bc 2560 
  frame-relay mincir 256000 
  no frame-relay adaptive-shaping 
  service-policy output bandwidth 
  frame-relay fragment 160 

!--- Create a frame relay map-class and apply the service !--- policy inside the map-class.

Tenez compte de ces facteurs lorsque vous choisissez l'une des approches suivantes :

• Le protocole de routage particulier utilisé et les valeurs de minuteur configurées pour les HELLO et l'actualisation de la base de données

• Taille de la base de données qui doit être échangée et si seules les mises à jour/modifications ou les tables complètes sont actualisées périodiquement

• La quantité d'encombrement attendue au niveau de l'interface ou du circuit virtuel

En d'autres termes, considérez les chances de mettre réellement en file d'attente les paquets de haute priorité en présence d'encombrement.

QoS et paquets générés localement

Le trafic généré par le routeur représente un cas particulier pour les stratégies de service QoS sortantes. Certains trafics générés localement doivent être traités comme tout autre trafic utilisateur, et le système QoS doit appliquer les mécanismes QoS configurés à ce trafic. Les sondes de performances conçues pour mesurer le comportement des paquets d'une classe donnée sont un exemple de ce type de trafic. D'autres trafics générés localement, notamment les messages de test d'activité de couche 2 et les messages de protocole de routage, sont essentiels au fonctionnement de base du routeur et ne doivent pas être soumis à certaines fonctions de QoS. Par exemple, la détection WRED (Weighted Random Early Detection) ne doit pas supprimer les keepalives de couche 2 lorsque la profondeur moyenne de la file d'attente atteint un seuil élevé

En outre, les paquets destinés au routeur doivent être traités avec soin. Par exemple, n'oubliez pas qu'une stratégie de service qui applique la réglementation basée sur les classes ne doit pas s'appliquer aux paquets destinés au routeur pour éviter de supprimer des messages de contrôle importants.

Remarque : Selon la conception, les paquets générés par le RP ne sont pas pris en compte dans les compteurs CLI QoS modulaires même si ces paquets sont correctement classés/mis en file d'attente. Ces paquets ne sont pas pris en compte dans la sortie de commande show policy-map interface.

Ce tableau indique comment les paquets destinés au routeur et en provenance de celui-ci interagissent actuellement avec les fonctions QoS clés.

Fonctionnalité QoS	Description
Marquage basé sur les classes	À l'origine, il ne fonctionnait que sur les paquets commutés CEF (Cisco Express Forwarding). La prise en charge de la commutation de processus et des méthodes de commutation rapide est présentée dans le logiciel Cisco IOS Version 12.2(5) (CSCdt74738).
Contrôle	Entrant - La limitation de débit peut être appliquée. L'interface entrante doit être configurée avec CEF si le débit d'accès garanti (CAR) (et non la réglementation basée sur les classes) est utilisé. Sur un routeur de la gamme Cisco 7500, la surveillance du trafic peut surveiller uniquement les chemins de commutation CEF. Sortant - Limitation de débit avec le CAR ou les services de police de classe.

Hiérarchiser les paquets sur le Catalyst 6000

Lorsque vous exécutez Cisco IOS sur le superviseur et la carte MSFC (MultiLayer Switch Feature Card) du Catalyst 6000, le RP marque les paquets de contrôle de routage avec la priorité IP 6. Cette valeur notée peut être utilisée avec la planification de sortie pour mapper les paquets de contrôle de routage à la file d'attente élevée, seuil élevé dans le système WRR (Weighted Round Robin). Ce mappage des paquets de contrôle de routage provenant de la MSFC se produit automatiquement tant que la QoS est activée globalement avec la commande mls qos. Si vous activez QoS, le système configure tous les paramètres de mise en file d'attente, tels que les seuils de perte WRED, les bandes passantes WRR et les limites de file d'attente. Lorsque la QoS est désactivée globalement, tous les paquets sont mappés à la file d'attente basse, seuil faible pour la planification de sortie, du WRR.

Comme indiqué dans le chapitre Configuration de la QoS du Guide de configuration Catalyst 6000, la QoS prend en charge la classification, le marquage, la planification et l'évitement de congestion à l'aide de valeurs CoS de couche 2 sur les ports d'entrée Ethernet. La classification, le marquage, la planification et l'évitement de congestion sur les ports d'entrée Ethernet n'utilisent pas ou ne définissent pas de priorité IP de couche 3 ou de valeurs DSCP. En outre, avec n'importe quel moteur de commutation, la QoS prend en charge la planification des ports de sortie Ethernet et l'évitement de congestion avec des valeurs CoS de couche 2. Par conséquent, les paquets IP et non IP cruciaux doivent être mappés à une valeur CoS, même si ces valeurs sont utilisées uniquement en interne dans l'en-tête du bus de données. Les paquets IP cruciaux ont une valeur de priorité IP de 6 mappée à une valeur CoS équivalente de 6. Les paquets cruciaux non-IP, qui incluent les paquets IS-IS qui proviennent de la MSFC, sont marqués avec l'indicateur pak_priority, puis ces paquets marqués sont mappés à une valeur CoS de 6. Ce mappage se produit automatiquement dans les versions actuelles de Cisco IOS.

Ni les contrôleurs d'entrée ni les contrôleurs de sortie ne marquent les paquets provenant de la carte MSFC et destinés à être transmis via une interface Ethernet physique.

La configuration QoS sur le Catalyst 6000 ne fait pas partie de ce document. Référez-vous à Configuration de la qualité de service et à la page de support des commutateurs Catalyst LAN et ATM pour plus d'informations.

Informations connexes

• Pages de support QoS
• Support et documentation techniques - Cisco Systems