Forum aux questions sur QoS (Qualité de service)
Table des matières
Introduction
Ce document répond aux questions les plus fréquentes (Forum aux questions) relatives à la qualité de service (QoS).
Généralités
Q. Qu'est-ce que la qualité de service (QoS) ?
R. La qualité de service (QoS) désigne la capacité d’un réseau à fournir un meilleur service au trafic réseau sélectionné sur diverses technologies sous-jacentes, notamment les réseaux Frame Relay, ATM (Asynchronous Transfer Mode), Ethernet et 802.1, SONET et les réseaux routés IP.
La QoS consiste en un ensemble de technologies qui permettent à des applications de demander et recevoir des niveaux de service prévisibles en termes de capacité de débit de données (bande passante), variations de latence (jitter) et de délais. En particulier, les fonctions QoS offrent un meilleur service réseau, plus prévisible, à l'aide des méthodes suivantes :
Prise en charge de bande passante dédiée.
Amélioration des caractéristiques de perte.
Prévention et gestion de la congestion du réseau.
Formatage du trafic réseau.
Définition des priorités de trafic sur le réseau.
L'Internet Engineering Task Force (IETF) définit les deux architectures suivantes pour la QoS :
Services intégrés (IntServ)
Services différenciés (DiffServ)
IntServ utilise le Resource Reservation Protocol (RSVP) pour signaler explicitement les besoins en QoS du trafic d'une application sur les périphériques du chemin d'accès de bout en bout via le réseau. Si chaque périphérique réseau du chemin d'accès peut réserver la bande passante nécessaire, l'application d'origine peut commencer à transmettre. La RFC 2205 définit le RSVP et la RFC 1633 définit les services IntServ.
DiffServ met l'accent sur la QoS agrégée et dimensionnée. Au lieu de signaler les besoins d'une application en termes de QoS, DiffServ utilise un point de code de services différenciés (DSCP) dans l'en-tête IP pour indiquer les niveaux de QoS requis. La conformité DiffServ sur les routeurs Cisco a été introduite par la version 12.1(5)T du logiciel Cisco IOS®. Pour plus d'informations, référez-vous aux documents suivants :
Q. Que sont la congestion, le délai et la gigue ?
R. Une interface est encombrée lorsqu’elle reçoit plus de trafic qu’elle ne peut en gérer. Les points de congestion du réseau sont de solides candidats pour les mécanismes de qualité de service (QoS). Voici un exemple de points de congestion classiques :
La congestion d'un réseau entraîne des délais. Un réseau et ses périphériques présentent plusieurs types de délais, comme expliqué dans Présentation des délais dans les réseaux de paquets voix. Une variation de délai est appelée gigue, comme expliqué dans Présentation des gigues dans les réseaux de paquets voix (plates-formes Cisco IOS). Les phénomènes de délai et de gigue doivent être contrôlés et minimisés de façon à pouvoir prendre en charge un trafic interactif et en temps réel.
Q. Qu'est-ce que le MQC ?
R. MQC est l’acronyme de Qualité de service (QoS) modulaire Command Line Interface (CLI). Elle est destinée à simplifier la configuration de la QoS sur les routeurs et les commutateurs Cisco en définissant une syntaxe de commandes commune et un ensemble de comportements de QoS résultant sur toutes les plates-formes. Ce modèle remplace la version précédente qui consistait à définir des syntaxes uniques pour chaque fonction QoS et pour chaque plate-forme.
La MQC comprend les trois étapes suivantes :
Définir une classe de trafic en émettant la commande class-map.
Créer une stratégie de trafic en associant la classe de trafic à une ou plusieurs fonctions QoS à l'aide de la commande policy-map.
Lier la stratégie de trafic à l'interface, à la sous-interface ou au circuit virtuel à l'aide de la commande service-policy.
Remarque : vous implémentez les fonctions de conditionnement du trafic de DiffServ, telles que le marquage et la mise en forme, à l'aide de la syntaxe MQC.
Pour plus d'informations, consultez Interface de ligne de commande de qualité de service modulaire.
Q. Que signifie la politique de service prise en charge uniquement sur les interfaces VIP avec le message DCEF activé ?
R. Sur les VIP (Versatile Interface Processors) d'un Cisco 7500, seules les fonctionnalités de qualité de service (QoS) distribuées sont prises en charge dans Cisco IOS 12.1(5)T, 12.1(5)E et 12.0(14)S. L'activation de la technologie Cisco Express Forwarding (dCEF) distribuée active automatiquement la QoS distribuée.
Les interfaces autres que VIP, appelées processeurs d'interface hérités (IPS), prennent en charge les fonctions QoS centrales telles qu'activées sur les processeurs de commutation routage (RSP). Pour plus d'informations, référez-vous aux documents suivants :
Q. Combien de classes une politique de qualité de service (QoS) prend-elle en charge ?
R. Dans les versions de Cisco IOS antérieures à la version 12.2, vous ne pouviez définir qu'un maximum de 256 classes, et vous pouviez définir jusqu'à 256 classes dans chaque politique si les mêmes classes sont réutilisées pour des politiques différentes. Si vous avez deux stratégies, le nombre total de classes des deux stratégies ne doit pas dépasser 256. Si une stratégie inclut la mise en file d'attente pondérée basée sur les classes (CBWFQ) (ce qui signifie qu'elle contient une instruction de bande passante [ou de priorité] dans n'importe quelle classe), le nombre total de classes prises en charge est 64.
Dans Cisco IOS Versions 12.2(12), 12.2(12)T et 12.2(12)S, cette limitation de 256 mappages de classes globales a été modifiée. Il est maintenant possible de configurer jusqu'à 1 024 mappages de classes globales et d'utiliser 256 mappages de classes à l'intérieur du même mappage de stratégies.
Q. Comment les mises à jour de routage et les keepalives PPP (Point-to-Point Protocol) / HDLC (High-Level Data Link Control) sont-elles traitées lorsqu’une stratégie de service est appliquée ?
R. Les routeurs Cisco IOS utilisent les deux mécanismes suivants pour hiérarchiser les paquets de contrôle :
Priorité IP
pak_priority
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. Pour plus d'informations, consultez Comprendre comment les mises à jour de routage et les paquets de contrôle sont mis en file d'attente sur une interface avec une stratégie de service QoS.
Q. La qualité de service (QoS) est-elle prise en charge sur les interfaces configurées avec le routage et le pontage intégrés (IRB) ?
R. Non. Vous ne pouvez pas configurer les fonctions QoS lorsque l'interface est configurée pour IRB.
Classification et marquage
Q. Qu'est-ce que la préclassification de la qualité de service (QoS) ?
R. La préclassification QoS vous permet de faire correspondre et de classer le contenu d’en-tête IP d’origine des paquets soumis à l’encapsulation et/ou au cryptage de tunnel. Cette fonction ne décrit pas le processus de copie de la valeur initiale de l'octet de type de service (ToS) de l'en-tête du paquet d'origine dans l'en-tête du tunnel. Pour plus d'informations, référez-vous aux documents suivants :
Q. Quels champs d’en-tête de paquet peuvent être notés ? Quelles sont les valeurs disponibles ?
R. La fonction de marquage par classe vous permet de définir ou de marquer l'en-tête de couche 2, de couche 3 ou MPLS (Multiprotocol Label Switching) de vos paquets. Pour plus d'informations, référez-vous aux documents suivants :
Q. Puis-je hiérarchiser le trafic en fonction de l’URL ?
R. Oui. La Network Based Application Recognition (NBAR) permet de classer les paquets en fonction de la correspondance des champs de la couche applicative. Avant l'introduction de NBAR, la classification la plus précise était basée sur les numéros de port TCP et UDP de la couche 4. Pour plus d'informations, référez-vous aux documents suivants :
Q. Quelles plates-formes et versions du logiciel Cisco IOS prennent en charge NBAR (Network Based Application Recognition) ?
R. La prise en charge de NBAR est introduite dans les versions suivantes du logiciel Cisco IOS :
Plateforme Version logicielle Cisco IOS minimale 7200 12.1(5)T 7100 12.1(5)T 3660 12.1(5)T 3640 12.1(5)T 3620 12.1(5)T 2600 12.1(5)T 1700 12.2(2)T Remarque : vous devez activer Cisco Express Forwarding (CEF) pour utiliser NBAR.
La NBAR distribuée (DNBAR) est disponible sur les plates-formes suivantes :
Plateforme Version logicielle Cisco IOS minimale 7500 12.2(4)T, 12.1(6)E FlexWAN 12.1(6)E Remarque : NBAR n'est pas pris en charge sur les interfaces VLAN MSFC (Multilayer Switch Feature Card) du Catalyst 6000, sur la gamme Cisco 12000 ou sur le module RSM (Route Switch Module) du Catalyst 5000. Si vous ne trouvez pas une plate-forme particulière dans la liste ci-dessus, contactez le représentant du support technique Cisco.
Gestion de la congestion et de la mise en file d'attente
Q. Quel est l'objectif de la mise en file d'attente ?
R. La mise en file d'attente est conçue pour gérer l'encombrement temporaire sur l'interface d'un périphérique réseau en stockant les paquets excédentaires dans des tampons jusqu'à ce que la bande passante devienne disponible. Les routeurs Cisco IOS prennent en charge plusieurs méthodes de mise en file d'attente de façon à répondre aux besoins variables en termes de bande passante, de gigue et de délai des différentes applications.
Le mécanisme par défaut sur la plupart des interfaces est la mise en file d'attente First In First Out (FIFO). Certains types de trafics sont plus exigeants en termes de délai/gigue. Ainsi, l'un des autres mécanismes de mise en file d'attente suivants doit être configuré ou est activé par défaut :
Mise en file d'attente pondérée (WFQ)
Mise en file d'attente pondérée basée sur les classes (CBWFQ)
Low Latency Queueing (LLQ), qui est en fait une CBWFQ avec une file d'attente par priorité (PQ) (appelée PQCBWFQ)
Mise en file d'attente par priorité (PQ)
Mise en file d'attente personnalisée (CQ)
La mise en file d'attente se produit généralement uniquement sur les interfaces de sortie. Un routeur place en file d'attente les paquets qui sortent d'une interface. Vous pouvez contrôler le trafic entrant, mais vous ne pouvez généralement pas mettre en file d'attente (une exception est la mise en mémoire tampon côté réception sur un routeur de la gamme Cisco 7500 utilisant le transfert distribué Cisco Express Forwarding (dCEF) pour transférer des paquets de l'interface d'entrée vers l'interface de sortie ; pour plus d'informations, référez-vous à Présentation du processeur VIP fonctionnant à 99 % et de la mise en mémoire tampon côté Rx. Sur les plates-formes distribuées de pointe, telles que les gammes Cisco 7500 et 12000, l'interface d'entrée peut utiliser ses propres mémoires tampon de paquets pour stocker le trafic excédentaire commuté vers une interface de sortie congestionnée suite à la décision de commutation de l'interface d'entrée. Dans de rares conditions, généralement quand l'interface d'entrée alimente une interface de sortie plus lente, l'interface d'entrée peut être confrontée à un nombre croissant d'erreurs ignorées lorsqu'elle manque de mémoire de paquets. Une congestion excessive peut engendrer la suppression de la file d'attente de sortie. Les suppressions de files d'attente d'entrée ont généralement une cause d'origine différente. Pour plus d'informations sur le dépannage des suppressions, consultez le document suivant :
Pour plus d'informations, référez-vous aux documents suivants :
Q. Comment fonctionnent la mise en file d'attente pondérée (WFQ) et la mise en file d'attente pondérée basée sur les classes (CBWFQ) ?
R. La mise en file d’attente équitable vise à allouer une part équitable de la bande passante d’une interface entre les conversations actives ou les flux IP. Elle classe les paquets en sous-files d'attente, identifiées par un numéro d'identification de conversation, utilisant un algorithme de hachage basé sur plusieurs champs de l'en-tête IP et la longueur du paquet. La pondération est calculée de la façon suivante :
W=K/(priorité +1)
K= 4 096 avec Cisco IOS 12.0(4)T et les versions antérieures, et 32 384 avec 12.0(5)T et les versions ultérieures.
Plus la pondération est faible, plus la priorité et le partage de la bande passante sont élevés. En plus de la pondération, la longueur du paquet est prise en considération.
CBWFQ permet de définir une classe de trafic et de lui attribuer une garantie de bande passante minimale. L'algorithme derrière ce mécanisme est WFQ, qui explique le nom. Pour configurer CBWFQ, vous définissez des classes spécifiques dans des instructions de classes de mappage. Vous affectez ensuite une stratégie à chaque classe dans un mappage de stratégie. Ce mappage de stratégie sera alors attaché en sortie à une interface. Pour plus d'informations, référez-vous aux documents suivants :
Q. Si une classe CBWFQ (Class Based Weighted Fair Queueing) n'utilise pas sa bande passante, d'autres classes peuvent-elles utiliser la bande passante ?
R. Oui. Bien que les garanties de bande passante fournies par les commandes bandwidth et priority aient été décrites avec des mots tels que « réservé » et « bande passante à mettre de côté », aucune de ces commandes ne met en œuvre une vraie réservation. En d'autres termes, si une classe de trafic n'utilise pas sa bande passante configurée, n'importe quelle bande passante inutilisée est partagée parmi les autres classes.
Le système de mise en file d'attente impose une importante exception à la règle avec une classe prioritaire. Comme noté ci-dessus, la charge offerte d'une classe prioritaire est dosée par un régulateur de trafic. Pendant les états d'encombrement, une classe prioritaire ne peut utiliser aucune bande passante excessive. Pour plus d'informations, reportez-vous à Comparaison des commandes bandwidth et priority d'une stratégie de service QoS.
Q. CBWFQ (Class Based Weighted Fair Queueing) est-il pris en charge sur les sous-interfaces ?
R. Les interfaces logiques Cisco IOS ne prennent pas en charge de manière inhérente un état d’encombrement et ne prennent pas en charge l’application directe d’une stratégie de service qui applique une méthode de mise en file d’attente. Au lieu de cela, vous devez d'abord appliquer le formatage à la sous-interface à l'aide du Generic Traffic Shaping (GTS) ou du formatage basé sur les classes. Pour plus d'informations, consultez Application des fonctions QoS aux sous-interfaces Ethernet.
Q. Quelle est la différence entre les instructions priority et bandwidth dans un policy-map ?
R. Les commandes priority et bandwidth diffèrent à la fois par leur fonctionnalité et par les applications qu’elles prennent généralement en charge. Le tableau suivant récapitule ces différences :
Fonction commande bandwidth commande priority Garantie de bande passante minimale Oui Oui Garantie de bande passante maximale Non Oui Contrôle intégré Non Oui Fournit une faible latence Non Oui Pour plus d'informations, reportez-vous à Comparaison des commandes bandwidth et priority d'une stratégie de service QoS.
Q. Comment la limite de file d'attente est-elle calculée sur le FlexWAN et les processeurs VIP (Versatile Interface Processors) ?
R. En supposant une mémoire SRAM suffisante sur le VIP ou FlexWAN, la limite de file d’attente est calculée sur la base d’un délai maximal de 500 ms avec une taille moyenne de paquet de 250 octets. Voici l'exemple d'une classe avec un Mbits/s de bande passante :
Limite de file d'attente = 1000000/(250 x 8 x 2) = 250
À mesure que la quantité de mémoire de paquets disponible diminue, des limites de file d'attente plus petites sont attribuées, avec un nombre plus grand de circuits virtuels (VC).
Dans l'exemple suivant, un PA-A3 est installé dans une carte FlexWAN de la gamme Cisco 7600 et prend en charge plusieurs sous-interfaces avec des circuits virtuels permanents de 2 Mo (PVC). La stratégie de service est appliquée à chaque circuit virtuel.
class-map match-any XETRA-CLASS match access-group 104 class-map match-any SNA-CLASS match access-group 101 match access-group 102 match access-group 103 policy-map POLICY-2048Kbps class XETRA-CLASS bandwidth 320 class SNA-CLASS bandwidth 512 interface ATM6/0/0 no ip address no atm sonet ilmi-keepalive no ATM ilmi-keepalive ! interface ATM6/0/0.11 point-to-point mtu 1578 bandwidth 2048 ip address 22.161.104.101 255.255.255.252 pvc ABCD class-vc 2048Kbps-PVC service-policy out POLICY-2048KbpsL'interface de mode de transfert asynchrone (ATM) obtient une limite de file d'attente pour l'intégralité de l'interface. La limite est une fonction calculant la quantité totale de mémoire tampon disponible, le nombre d'interfaces physiques sur le FlexWAN et le délai de mise en file d'attente maximal autorisé sur l'interface. Chaque PVC obtient une partie de la limite d'interface en fonction du Sustained Cell Rate (SCR) ou du Minimum Cell Rate (MCR) du PVC, et chaque classe obtient une partie de la limite de PVC en fonction de son allocation de bande passante.
L'exemple de sortie suivant de la commande show policy-map interface est dérivé d'un FlexWAN avec 3687 mémoires tampon globales. Émettez la commande show buffer pour obtenir cette valeur. 50 paquets sont alloués à chaque PVC de 2 Mbits/s en fonction de la bande passante du PVC de 2 Mbits/s (2047/149760 x 3687 = 50). Une partie des 50 paquets est ensuite allouée à chaque classe, comme le montre l'exemple suivant :
service-policy output: POLICY-2048Kbps class-map: XETRA-CLASS (match-any) 687569 packets, 835743045 bytes 5 minute offered rate 48000 bps, drop rate 6000 BPS match: access-group 104 687569 packets, 835743045 bytes 5 minute rate 48000 BPS queue size 0, queue limit 7 packets output 687668, packet drops 22 tail/random drops 22, no buffer drops 0, other drops 0 bandwidth: kbps 320, weight 15 class-map: SNA-CLASS (match-any) 2719163 packets, 469699994 bytes 5 minute offered rate 14000 BPS, drop rate 0 BPS match: access-group 101 1572388 packets, 229528571 bytes 5 minute rate 14000 BPS match: access-group 102 1146056 packets, 239926212 bytes 5 minute rate 0 BPS match: access-group 103 718 packets, 245211 bytes 5 minute rate 0 BPS queue size 0, queue limit 12 packets output 2719227, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 bandwidth: kbps 512, weight 25 queue-limit 100 class-map: class-default (match-any) 6526152 packets, 1302263701 bytes 5 minute offered rate 44000 BPS, drop rate 0 BPS match: any 6526152 packets, 1302263701 bytes 5 minute rate 44000 BPS queue size 0, queue limit 29 packets output 6526840, packet drops 259 tail/random drops 259, no buffer drops 0, other drops 0Si vos flux de trafic utilisent de grandes tailles de paquet, le résultat de la commande show policy-map interface peut signaler une valeur à incrémentation pour les champs no buffer drops dans la mesure où vous pouvez manquer de mémoires tampon avant d'atteindre la limite de la file d'attente. Dans ce cas, essayez de diminuer manuellement les classes queue-limit et non-priority. Pour plus d'informations, consultez Présentation de la transmission de la limite de file d'attente avec CoS IP à ATM.
Q. Comment vérifiez-vous la valeur queue-limit ?
R. Sur les plates-formes non distribuées, la limite de file d'attente est de 64 paquets par défaut. L'exemple de résultat suivant a été capturé sur un routeur de la gamme Cisco 3600 :
november# show policy-map interface s0 Serial0 Service-policy output: policy1 Class-map: class1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 5 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 30 (kbps) Max Threshold 64 (packets) !--- Max Threshold is the queue-limit. (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 2 Match: ip precedence 3 Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 24 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: any
Q. Puis-je activer la mise en file d'attente équitable dans une classe ?
R. La gamme Cisco 7500 avec qualité de service (QoS) distribuée prend en charge une mise en file d’attente équitable par classe. D'autres plates-formes, notamment les gammes Cisco 7200 et Cisco 2600/3600, prennent en charge la mise en file d'attente WFQ (Weighted Fair Queueing) dans la classe par défaut ; toutes les classes de bande passante utilisent la technologie FIFO (First In First Out).
Q. Quelles commandes puis-je utiliser pour surveiller la mise en file d’attente ?
R. Utilisez les commandes suivantes pour surveiller la mise en file d'attente :
show queue {interface} {numéro d'interface} - sur des plateformes Cisco IOS autres que la gamme Cisco 7500, cette commande affiche les files d'attente ou les conversations actives. Si l'interface ou le circuit virtuel n'est pas congestionné, aucune file d'attente ne sera listée. Sur la gamme Cisco 7500, la commande show queue n'est pas prise en charge.
show queueing interface interface-number [vc [[vpi/] vci] - cette commande affiche les statistiques de mise en file d'attente sur une interface ou un circuit virtuel. Même s'il n'y a aucune congestion, vous pourrez toujours voir quelques accès ici. Les paquets commutés par les processus sont toujours pris en compte qu'il y ait ou non congestion. Cisco Express Forwarding (CEF) et les paquets à commutation rapide ne sont pas pris en compte sauf s'il y a congestion. Les mécanismes de mise en file d'attente habituels comme la mise en file d'attente par priorité (PQ), la mise en file d'attente personnalisée (CQ) et la mise en file d'attente pondérée (WFQ) ne fournissent pas de statistiques de classification. Seules les fonctionnalités Modular QoS CLI (MQC) dans les images ultérieures à 12.0(5)T fournissent ces statistiques.
show policy interface {interface}{numéro d'interface} - Le compteur packets compte le nombre de paquets correspondant aux critères de la classe. Ce compteur est incrémenté que l'interface soit ou ne soit pas congestionnée. Le compteur packets matched indique le nombre de paquets correspondant aux critères de la classe quand l'interface a été congestionnée. Pour plus d'informations sur les compteurs de paquets, consultez le document suivant :
Présentation des compteurs de paquets dans la sortie d'interface show policy-map
MIB de statistiques et de configuration QoS basée sur les classes Cisco - Fournit des fonctionnalités de surveillance du protocole de gestion de réseau simple (SNMP).
Q. RSVP peut être utilisé conjointement avec la mise en file d'attente pondérée basée sur les classes (CBWFQ). Lorsque les protocoles Resource Reservation Protocol (RSVP) et CBWFQ sont tous deux configurés pour une interface, RSVP et CBWFQ agissent-ils de façon indépendante, en ayant le même comportement que celui qu'ils auraient si chacun d'eux s'exécutait seul ? RSVP semble se comporter comme si CBWFQ n'était pas configuré en termes de disponibilité, d'estimation et d'allocation de bande passante.
R. Lors de l'utilisation de RSVP et CB-WFQ dans le logiciel Cisco IOS Version 12.1(5)T et ultérieure, le routeur peut fonctionner de telle sorte que les flux RSVP et les classes CBWFQ partagent la bande passante disponible sur une interface ou un circuit virtuel permanent, sans surabonnement.
La version logicielle d'IOS 12.2(1)T et versions ultérieures permet au RSVP d'effectuer un contrôle d'admission en utilisant son propre pool « ip rsvp bandwidth », tandis que la CBWFQ gère la classification, la réglementation et la planification des paquets RSVP. Cela suppose que les paquets soient prémarqués par l'expéditeur et que les paquets non RSVP soient marqués différemment.
Weighted Random Early Detection (WRED) en prévention de congestion
Q. Puis-je activer simultanément la détection WRED (Weighted Random Early Detection) et LLQ (Low Latency Queueing) ou CBWFQ (Class Based Weighted Fair Queueing) ?
R. Oui. La mise en file d'attente définit l'ordre dans lequel les paquets sortent de la file d'attente. En d'autres termes, elle définit un mécanisme de planification des paquets. Elle peut également être utilisée pour fournir une allocation de bande passante équitable et des garanties de bande passante minimales. En revanche, la RFC 2475 définit la suppression comme le « processus de suppression des paquets en fonction de règles spécifiées ». Le « tail-drop » constitue le mécanisme de suppression par défaut, dans lequel l'interface supprime les paquets lorsque la file d'attente est pleine. La détection précoce aléatoire (RED) et la WRED de Cisco constituent d'autres mécanismes de suppression, lesquels suppriment des paquets de façon aléatoire avant que la file d'attente ne soit pleine et cherchent à conserver une profondeur moyenne de file d'attente cohérente. La WRED utilise la valeur de priorité IP des paquets pour prendre une décision de suppression différenciée. Pour plus d'informations, consultez Weighted Random Early Detection (WRED).
Q. Comment puis-je surveiller la détection WRED (Weighted Random Early Detection) et voir qu'elle prend réellement effet ?
R. WRED surveille la profondeur moyenne de la file d’attente et commence à supprimer des paquets lorsque la valeur calculée dépasse la valeur de seuil minimale. Émettez la commande show policy-map interface et contrôlez la valeur de la profondeur moyenne de la file d'attente, come le montre l'exemple suivant :
Router# show policy interface s2/1 Serial2/1 output : p1 Class c1 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 20 (%) (pkts matched/bytes matched) 168174/41370804 (pkts discards/bytes discards/tail drops) 20438/5027748/0 mean queue depth: 39 Dscp Random drop Tail drop Minimum Maximum Mark (Prec) pkts/bytes pkts/bytes threshold threshold probability 0(0) 2362/581052 1996/491016 20 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 [output omitted]
Réglementation et formatage
Q. Quelle est la différence entre le maintien de l'ordre et le façonnage ?
R. Le diagramme suivant illustre la différence clé. Le formatage de trafic retient les paquets excédentaires dans une file d'attente, puis planifie l'excédent pour une transmission ultérieure sur des incréments de temps. Le résultat du formatage de trafic est un débit en sortie en douceur de paquets. En revanche, la réglementation du trafic propage des salves. Quand le débit de trafic atteint le débit maximal configuré, le trafic excessif est extrait (ou marqué une nouvelle fois). Le résultat est un débit en sortie qui apparaît en dents de scie avec des hauts et des bas.
Pour plus d'informations, consultez Vue d'ensemble de la réglementation et du formatage.
Q. Qu’est-ce qu’un « token bucket » et comment fonctionne l’algorithme ?
R. Un compartiment à jetons n'a pas de stratégie de suppression ou de priorité. L'exemple suivant illustre la façon dont le saut à jetons fonctionne :
Les jetons sont placés dans le saut à un certain débit.
Chaque jeton constitue une autorisation pour que la source envoie un certain nombre de bits.
Pour envoyer un paquet, le régulateur de trafic doit pouvoir retirer du saut un certain nombre de jetons égal dans la représentation à la taille de paquet.
Si le nombre de jetons dans le saut est insuffisant pour envoyer un paquet, le paquet attend que le saut ait assez de jetons (dans le cas d'un modélisateur), ou le paquet est ignoré ou dé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 source peut envoyer dans le réseau est approximativement proportionnelle à la taille du saut. Un saut à jetons permet les rafales, mais les lie.
Q. Avec un régulateur de trafic tel que la réglementation basée sur les classes, que signifient Committed Burst (BC) et Excess Burst (Be) et comment dois-je sélectionner ces valeurs ?
R. Un régulateur de trafic ne met pas en mémoire tampon les paquets excédentaires et ne les transmet pas ultérieurement, comme c’est le cas pour un modélisateur. Au lieu de cela, le régulateur exécute une simple stratégie d'envoi ou de non-envoi sans mise en mémoire tampon. Durant les périodes de congestion, puisque vous ne pouvez pas placer les paquets en mémoire tampon, la meilleure solution consiste à supprimer des paquets de façon moins agressive en configurant correctement le mode rafale étendue. Par conséquent, il est important de comprendre que le régulateur utilise les valeurs de rafale normale et de rafale étendue pour être sûr que le débit minimal garanti (CIR) soit atteint.
Les paramètres de rafale sont légèrement modelés sur la règle générique de mise en mémoire tampon destinée aux routeurs. La règle recommande de configurer la mise en mémoire tampon par rapport à la vitesse de transmission des allers-retours de façon à pouvoir accueillir les fenêtres du protocole de contrôle de transmissions (TCP) de toutes les connexions en période de congestion.
Le tableau suivant décrit l'usage et la formule recommandée pour les valeurs de rafale normales et étendues :
Paramètre de rafale Objectif Formule recommandée rafale normale
Implémente un saut à jetons standard.
Fixe la taille maximale du saut à jetons (bien que des jetons puissent être empruntés si Be est supérieur à BC).
Détermine la taille du saut à jetons dans la mesure où les nouveaux jetons sont supprimés et ne sont pas disponibles pour les futurs paquets si le saut atteint sa pleine capacité.
Remarque : 1,5 seconde est le temps de parcours aller-retour typique.
rafale étendue
Implémente un saut à jetons avec des fonctionnalités de rafale étendue.
Désactivé en définissant BC = Be.
Lorsque BC est égal à Be, le régulateur du trafic ne peut pas emprunter de jetons et il supprime simplement le paquet si le nombre de jetons disponibles est insuffisant.
Toutes les plates-formes n'utilisent pas ou ne prennent pas en charge la même plage de valeurs pour un régulateur. Consultez le document suivant pour connaître les valeurs prises en charge pour votre plate-forme spécifique :
Q. Comment la réglementation CAR (Committed Access Rate) ou basée sur les classes détermine-t-elle si un paquet est conforme ou dépasse le CIR (Committed Information Rate) ? Le routeur supprime des paquets et signale un débit dépassé même si le débit conforme est inférieur au CIR configuré.
R. Un régulateur de trafic utilise les valeurs de rafale normale et de rafale étendue pour s’assurer que le CIR configuré est atteint. Il est important de définir des valeurs de rafale suffisamment élevées de façon à garantir un débit correct. Si les valeurs de rafale ne sont pas suffisamment élevées, le débit obtenu peut être largement inférieur au débit configuré. Les rafales provisoires peut avoir une incidence fortement défavorable sur le débit du trafic TCP. Avec le CAR, émettez la commande show interface rate-limit pour contrôler la rafale actuelle et déterminer si la valeur affichée est constamment proche des valeurs BC et Be.
rate-limit 256000 7500 7500 conform-action continue exceed-action drop rate-limit 512000 7500 7500 conform-action continue exceed-action drop router# show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 BPS, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS Output matches: all traffic params: 512000 BPS, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPSPour plus d'informations, référez-vous aux documents suivants :
Q. Les limites de rafale et de file d’attente sont-elles indépendantes l’une de l’autre ?
R. Oui, la rafale du régulateur et la limite de file d'attente sont séparées et indépendantes l'une de l'autre. Vous pouvez considérer le régulateur comme une porte qui autorise un certain nombre de paquets (ou octets) et la file d'attente comme un saut de taille queue limit qui contient les paquets admis avant la transmission sur le réseau. Idéalement, vous voulez que votre saut soit suffisamment grand pour contenir une rafale des octets/paquets admis par la porte (régulateur).
Qualité de service (QoS) des relais de trame
Q. Quelles valeurs dois-je sélectionner pour le débit garanti (CIR), la rafale garantie (BC), la rafale excédentaire (Be) et le débit minimal garanti (MinCIR) ?
R. La mise en forme du trafic Frame Relay, que vous activez en exécutant la commande frame-relay traffic-shaping, prend en charge plusieurs paramètres configurables. Ces paramètres incluent frame-relay cir, frame-relay mincir et frame-relay BC. Consultez les documents suivants pour plus d'informations sur la sélection de ces valeurs et une présentation des commandes show associées :
Q. La mise en file d’attente prioritaire sur l’interface principale Frame Relay fonctionne-t-elle dans Cisco IOS 12.1 ?
R. Les interfaces Frame Relay prennent en charge les mécanismes de mise en file d’attente d’interface et les mécanismes de mise en file d’attente par circuit virtuel (VC). À partir de Cisco IOS 12.0(4)T, la file d'attente d'interface ne prend en charge la mise en file d’attente First In First Out (FIFO) ou la mise en file d'attente par priorité (PQ) par interface que lorsque vous configurez le formatage du trafic Frame Relay (FRTS). Par conséquent, la configuration suivante ne fonctionnera plus si vous effectuez une mise à niveau vers Cisco IOS 12.1.
interface Serial0/0 frame-relay traffic-shaping bandwidth 256 no ip address encapsulation frame-relay IETF priority-group 1 ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 136.238.91.214 255.255.255.252 no ip mroute-cache traffic-shape rate 128000 7936 7936 1000 traffic-shape adaptive 32000 frame-relay interface-dlci 200 IETFSi FRTS n'est pas activé, vous pouvez appliquer une autre méthode de mise en file d'attente, telle que la mise en file d'attente pondérée basée sur les classes (CBWFQ), à l'interface principale, laquelle agit comme un canal de bande passante unique. En outre, depuis Cisco IOS 12.1.1(T), vous pouvez activer la mise en file d'attente d'interface prioritaire (PIPQ) de circuits virtuels permanents (PVC) Frame Relay sur une interface principale Frame Relay. Vous pouvez définir des PVC de priorité élevée, moyenne, normale ou basse et émettre la commande frame-relay interface-queue priority sur l'interface principale, comme dans l'exemple suivant :
interface Serial3/0 description framerelay main interface no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping frame-relay interface-queue priority interface Serial3/0.103 point-to-point description frame-relay subinterface ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 103 class frameclass map-class frame-relay frameclass frame-relay adaptive-shaping becn frame-relay cir 60800 frame-relay BC 7600 frame-relay be 22800 frame-relay mincir 8000 service-policy output queueingpolicy frame-relay interface-queue priority low
Q. Frame Relay Traffic Shaping (FRTS) fonctionne-t-il avec Distributed Cisco Express Forwarding (dCEF) et Distributed Class Based Weighted Fair Queueing (dCBWFQ) ?
R. Depuis la version 12.1(5)T de la plate-forme logicielle Cisco IOS, seule la version distribuée des fonctions QoS est prise en charge sur les VIP de la gamme Cisco 7500. Pour permettre le formatage du trafic sur des interfaces de relais de trame, utilisez le Distributed Traffic Shaping (DTS). Pour plus d'informations, référez-vous aux documents suivants :
Qualité de service (QoS) sur mode de transfert asynchrone (ATM)
Q. Où dois-je appliquer une politique de service avec CBWFQ (Class Based Weighted Fair Queueing) et LLQ (Low Latency Queueing) sur une interface ATM (Asynchronous Transfer Mode) ?
R. À partir de la plate-forme logicielle Cisco IOS 12.2, les interfaces ATM prennent en charge des politiques de service à trois niveaux ou interfaces logiques : interface principale, sous-interface et circuit virtuel permanent (PVC). L'emplacement auquel vous appliquez la stratégie est conditionnée par la fonction de qualité de service (QoS) que vous activez. Les stratégies de mise en file d'attente doivent être appliquées par circuit virtuel (VC) puisque l'interface ATM contrôle le niveau de congestion par circuit virtuel et gère les files d'attente des paquets excédentaires par circuit virtuel. Pour plus d'informations, référez-vous aux documents suivants :
Q. Quels octets sont comptés par les files d’attente de classe de service (CO) IP à ATM (Asynchronous Transfer Mode) ?
R. Les commandes bandwidth et priority configurées dans une politique de service pour activer la mise en file d'attente pondérée basée sur les classes (CBWFQ) et la mise en file d'attente à faible latence (LLQ), respectivement, utilisent une valeur Kbits/s qui compte les mêmes octets de surcharge que ceux comptés par la sortie de commande show interface. En particulier, le système de mise en file d'attente de couche 3 prend en compte le contrôle de la liaison logique / protocole d'accès au sous-réseau (LLC/SNAP). Il ne prend pas en compte ce qui suit :
Trailer de la couche d'adaptation ATM 5 (AAL5)
Remplissage pour faire de la dernière cellule un multiple pair de 48 octets
En-tête de cellule de cinq octets
Quels sont les octets pris en compte par la mise en file d'attente CoS d'IP à ATM
Q. Combien de circuits virtuels (VCS) peuvent prendre en charge une politique de service simultanément ?
R. Le document suivant fournit des directives utiles sur le nombre de VCS ATM (Asynchronous Transfer Mode) pouvant prendre en charge. Environ 200 à 300 circuits virtuels permanents vbr-nrt (PVC) VBR-nrt ont été déployés en toute sécurité :
Prenez en compte également ce qui suit :
Utilisez un processeur de forte capacité. Par exemple, un VIP4-80 fournit de manière significative des performances plus élevées qu'un VIP2-50.
Quantité de mémoire de paquets disponible. Sur le NPE-400, jusqu'à 32 Mo (dans un système de 256 Mo) sont réservés pour la mémoire tampon des paquets. Pour un NPE-200, jusqu'à 16 Mo sont réservés pour des mémoires tampon de paquets sur un système de 128 Mo.
Des configurations avec la Weighted Random Early Detection (WRED) par circuit virtuel fonctionnant simultanément sur un maximum de 200 circuits virtuels ATM ont été intensivement testées. La quantité de mémoire de paquets sur le VIP2-50 pouvant être utilisée pour les files d'attente par circuit virtuel est limitée. Par exemple, un VIP2-50 avec 8 Mo de SRAM fournit 1 085 mémoires tampon de paquets disponibles pour la mise en file d'attente par circuit virtuel de classe de service IP à ATM sur lesquelles la WRED fonctionne. Si 100 PVC ATM ont été configurés et si tous les circuits virtuels ont simultanément fait l'objet d'une congestion excessive (comme cela pourrait être simulé dans des environnements de test où une source contrôlée par un flux autre que TCP serait utilisée), chaque PVC aurait en moyenne une mise en mémoire tampon d'environ 10 paquets, ce qui peut être insuffisant pour que la WRED fonctionne correctement. Les périphériques VIP2-50 avec une SRAM importante sont donc fortement recommandés dans les conceptions comportant un nombre élevé de circuits virtuels ATM exécutant des WRED par circuit virtuel et pouvant faire simultanément l'objet de congestion.
Plus le nombre de PVC configurés actifs est élevé, plus le nombre de Sustained Cell Rate (SCR) devra être faible, et par conséquent, plus la file d'attente requise par la WRED pour fonctionner sur le PVC devra être courte. Ainsi, comme cela est le cas lors de l'utilisation des profils WRED par défaut de la fonction de phase 1 de classe de service (COs) IP à ATM, la configuration de seuils inférieurs de suppression de WRED lorsque la WRED par circuit virtuel est activée sur un très grand nombre de PVC lents congestionnés réduirait le risque de pénurie de mémoire tampon sur le VIP. La pénurie de mémoire tampon sur le VIP n'entraîne aucun dysfonctionnement. Dans le cas de pénurie de mémoire tampon sur le VIP, la fonction de phase 1 de COs d'IP à ATM passe simplement au « tail drop » First In First Out (FIFO) durant la pénurie de mémoire tampon (c'est-à-dire la même stratégie de suppression qui serait utilisée si la fonction de COs d'IP à ATM n'était pas activée sur ce PVC).
Nombre maximal de circuits virtuels simultanés qui peut être raisonnablement pris en charge.
Q. Quel matériel ATM (Asynchronous Transfer Mode) prend en charge les fonctions de classe de service (CO) IP à ATM, notamment CBWFQ (Class-Based Weighted Fair Queueing) et LLQ (Low Latency Queueing) ?
R. Les centraux téléphoniques IP vers ATM font référence à un ensemble de fonctionnalités activées par circuit virtuel (VC, Virtual Circuit). La COs IP à ATM n'est donc pas prise en charge sur le processeur d'interface ATM (AIP), ou sur les processeurs réseau ATM 4500 ou PA-A1. Ce matériel ATM ne prend pas en charge la mise en file d'attente par circuit virtuel, telle que le PA-A3 et la plupart des modules réseau (autres que l'ATM-25) la définissent. Pour plus d'informations, reportez-vous au document suivant :
Voix et qualité de service (QoS)
Q. Comment fonctionne la fragmentation et l’entrelacement de liens (LFI) ?
R. Le trafic interactif, tel que Telnet et Voice over IP, est susceptible d’augmenter la latence lorsque le réseau traite des paquets volumineux, tels que les transferts FTP (File Transfer Protocol) sur un réseau étendu. Le délai de paquets pour le trafic interactif est significatif lorsque les paquets FTP sont placés en file d'attente sur des liaisons WAN plus lentes. Une méthode a été conçue pour fragmenter les paquets les plus grands, et placer en file d'attente les paquets les plus petits (voix) entre les fragments des paquets les plus grands (FTP). Les routeurs Cisco IOS prennent en charge plusieurs mécanismes de fragmentation de la couche 2. Pour plus d'informations, référez-vous aux documents suivants :
Q. Quels outils puis-je utiliser pour surveiller les performances de la voix sur IP ?
R. Cisco propose actuellement plusieurs options de surveillance de la qualité de service (QoS) dans les réseaux utilisant les solutions de voix sur IP de Cisco. Ces solutions ne mesurent pas la qualité vocale à l'aide de la méthode Perceptual Speech Quality Measurement (PSQM) ou de certains des nouveaux algorithmes proposés pour mesurer la qualité vocale. Les outils Agilent (HP) et NetIQ sont disponibles à cet effet. Cisco offre cependant des outils qui donnent une idée de la qualité vocale que vous obtenez en mesurant le délai, la gigue et la perte de paquets. Pour plus d'informations, consultez Utilisation du Service Assurance Agent et de l'Internetwork Performance Monitor de Cisco pour gérer la qualité de service sur des réseaux Voix sur IP.
Q. %SW_MGR-3-CM_ERROR_FEATURE_CLASS : Erreur de fonctionnalité du Gestionnaire de connexions : Classe SSS : (QoS) - erreur d'installation, ignorer.
R. L'erreur d'installation de fonctionnalité observée est un comportement attendu lorsqu'une configuration non valide est appliquée à un modèle. Elle indique que la stratégie de service n'a pas été appliquée en raison d'un conflit. Vous ne devez généralement pas configurer le formatage sur la valeur par défaut des classes de la stratégie enfant dans les mappages de stratégies hiérarchiques ; configurez-le sur la stratégie parente de l'interface. L'impression et le traçage de ce message en sont la conséquence.
Avec des stratégies basées sur les sessions, le formatage des valeurs par défaut des classes doit être uniquement effectué au niveau PVC de la sous-interface. La formatage de l'interface physique n'est pas pris en charge. Si la configuration est effectuée sur l'interface physique, l'occurrence de ce message d'erreur est un comportement attendu.
Dans le cas de LNS, une autre raison pourrait être que la stratégie de service peut être fournie par l'intermédiaire du serveur RADIUS lorsque les sessions sont démarrées. Émettez la commande show tech pour afficher la configuration du serveur RADIUS et toutes les stratégies de service illégales qui sont installées par l'intermédiaire du serveur RADIUS lorsque la session s'ouvre ou devient instable.
Commentaires