Qualité de service (QoS) : Mécanismes d'efficacité de liaison QoS

Présentation de Qos (Qualité de service) sur les commutateurs de la gamme Catalyst 6000

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (19 septembre 2015) | Commentaires


Contenu


Introduction

Ce document explique les capacités de Qualité de service (QoS) disponibles dans les Commutateurs de famille du Catalyst 6000. Ce document couvre des capacités de configuration QoS et fournit quelques exemples de la façon dont QoS peut être mis en application.

Ce document n'est pas censé pour être un guide de configuration. Des exemples de configuration sont utilisés dans tout ce document pour aider à l'explication des caractéristiques de QoS du matériel et du logiciel de famille du Catalyst 6000. Pour la référence de syntaxe pour des structures de commande de QoS, référez-vous s'il vous plaît aux guides suivants de configuration et de commande pour la famille du Catalyst 6000 :

Définir la couche 2 QoS

Tandis que beaucoup peuvent penser que QoS dans des Commutateurs de la couche 2 (L2) est simplement au sujet des trames Ethernet de donner la priorité, pas beaucoup se rendent compte qu'il nécessite beaucoup plus. L2 QoS nécessite ce qui suit :

    1. Scheduling de file d'attente d'entrée : quand la trame entre dans le port, elle peut être assignée à une d'un certain nombre de files d'attente basées sur port avant d'être programmé à l'changement à un port de sortie. Typiquement, de plusieurs files d'attente sont utilisées où le trafic différent exige des niveaux de service différent, ou où la latence de commutateur doit être gardée à un minimum. Par exemple, l'IP a basé le vidéo et les données vocales exigent la basse latence, tellement là peuvent être un besoin de commuter ces données avant de commuter d'autres données telles que le Protocole FTP (File Transfer Protocol), Web, email, telnet, et ainsi de suite.

    2. Classification : le processus de la classification implique d'examiner différents champs dans l'en-tête des Ethernets L2, avec des champs dans l'en-tête IP (couche 3 (L3)) et l'en-tête de Transmission Control Protocol/User Datagram Protocol (TCP/UDP) (couche 4 (L4)) pour aider à déterminer le niveau du service qui sera appliqué à la trame en tant qu'elle transite le commutateur.

    3. Maintien de l'ordre : le maintien de l'ordre est le processus d'examiner une trame Ethernet pour voir s'il a dépassé un débit de prédéfinis du trafic dans une certaine période (typiquement, cette période est un nombre fixe interne au commutateur). Si cette trame soit -de-profil (c'est-à-dire, ce fait partie d'un flux de données au-dessus du raté limit de prédéfinis), elle peut ou être abandonnée ou la valeur de Classe de service (Cos) peut être marquée vers le bas.

    4. Réécrire : le processus de la réécriture est la capacité du commutateur de modifier le cos dans l'en-tête Ethernet ou les bits de Type de service (ToS) dans l'en-tête d'IPV4.

    5. Scheduling de file d'attente de sortie : après les processus de réécriture, le commutateur placera la trame Ethernet dans une file d'attente sortante appropriée (de sortie) pour le changement. Le commutateur exécutera la gestion de mémoire tampon sur cette file d'attente en s'assurant que la mémoire tampon ne déborde pas. Il fera typiquement ceci en utilisant un algorithme (ROUGE) tôt aléatoire d'écart, par lequel des trames aléatoires soient retirées (relâché) de la file d'attente. Le ROUGE pesé (WRED) est un dérivé du ROUGE (utilisé par certains modules dans la famille de Catalyst 6000), par lequel les valeurs CoS soient examinées pour déterminer quelles trames seront abandonnées. Quand les mémoires tampons atteignent des seuils de prédéfinis, des trames de priorité plus basse sont typiquement abandonnées, maintenant les trames plus prioritaires dans la file d'attente.

Ce document explique plus en détail chacun des mécanismes ci-dessus et comment ils associent à la famille du Catalyst 6000 dans les sections suivantes.

Le besoin de QoS dans un commutateur

Les fonds de panier énormes, les millions de paquets commutés par seconde, et les Commutateurs non groupants sont tous synonymes de beaucoup de Commutateurs aujourd'hui. Pourquoi le besoin de QoS ? La réponse est en raison d'encombrement.

Un commutateur peut être le commutateur le plus rapide au monde, mais si vous avez l'un ou l'autre des deux scénarios représentés sur la figure ci-dessus, que commutateur éprouvera l'encombrement. À une époque d'encombrement, si les fonctionnalités de gestion d'encombrement ne sont pas en place, des paquets seront lâchés. Quand des paquets sont lâchés, les retransmissions se produisent. Quand les retransmissions se produisent, la charge du réseau peut augmenter. Dans les réseaux qui sont déjà congestionnés, ceci peut ajouter aux problèmes de performance existants et potentiellement autre dégradez la représentation.

Avec les réseaux convergents, la Gestion d'encombrement est bien plus essentielle. Le trafic sensible de latence tel que la Voix et le vidéo peut être sévèrement affecté si des retards sont encourus. Ajouter simplement plus de mémoires tampons à un commutateur n'allégera pas également nécessairement des problèmes d'encombrement. Le trafic sensible de latence doit être aussi rapide commuté comme possible. D'abord, vous devez identifier cet important trafic par des techniques de classification, et puis implémentez des techniques de gestion de mémoire tampon pour éviter le trafic plus prioritaire d'être lâché pendant l'encombrement. En conclusion, vous devez incorporer des techniques de établissement du programme pour commuter d'importants paquets des files d'attente aussi rapidement que possible. Car vous lirez dedans ce document, la famille du Catalyst 6000 implémente toutes ces techniques, faisant son sous-système un de QoS du plus complet dans le secteur aujourd'hui.

Toutes les techniques de QoS décrites dans la section précédente seront explorées plus en détail dans tout ce document.

Support matériel pour QoS dans la famille du Catalyst 6000

Pour prendre en charge QoS dans la famille du Catalyst 6000, un certain support matériel est exigé. Le matériel qui prend en charge QoS inclut la carte de commutation multicouche (MSFC), la carte de fonctionnalité de stratégie (PFC), et les circuits intégrés spécifiques à l'application de port (ASIC) sur les linecards eux-mêmes. Ce document n'explorera pas les capacités de QoS du MSFC, plutôt il se concentrera sur les capacités de QoS du PFC et des ASIC sur les linecards.

PFC

La version 1 PFC est une carte de fille qui se repose sur le Supervisor I (SupI) et le superviseur IA (SupIA) de la famille du Catalyst 6000. Le PFC2 est une re-rotation du PFC1 et se transporte avec nouveau Supervisor II (SupII) et certains de nouveaux ASIC à bord. Tandis que les PFC1 et le PFC2 sont principalement connus pour leur accélération matérielle de la commutation L3, QoS est l'un de leurs autres buts. Les PFC sont affichés ci-dessous.

Tandis que le PFC 1 et le PFC2 sont essentiellement identique, il y a quelques différences dans la fonctionnalité QoS. À savoir, le PFC2 ajoute ce qui suit :

    1. La capacité d'abaisser la stratégie QoS à une carte de transfert distribué (DFC).

    2. En maintenant l'ordre des décisions soyez légèrement différent. Les PFC1 et le PFC2 prennent en charge le maintien de l'ordre normal par lequel des trames soient abandonnées ou marquées vers le bas si une stratégie d'agrégat ou de microflow renvoie une décision de -de-profil. Cependant, le PFC2 ajoute le soutien d'un débit de dépassement, qui indique un deuxième maintien de l'ordre de niveau que des mesures de stratégie peuvent être prises à.

Quand un régulateur de débit de dépassement est défini, des paquets peuvent être lâchés ou marqués en bas de quand ils dépassent le débit de dépassement. Si une police excédentaire de niveau est placée, la cartographie excédentaire de DSCP est utilisée pour remplacer la valeur DSCP d'origine par une valeur marquée-vers le bas. Si seulement une police normale de niveau est placée, la cartographie normale de DSCP est utilisée. La police excédentaire de niveau aura la priorité pour sélectionner des règles de mappage quand les deux niveaux de police sont placés.

Il est important de noter que les fonctions de QoS décrites dans ce document exécuté par les ASIC mentionnés rapportent des hauts niveaux de représentation. La représentation de QoS dans une famille du Catalyst de base 6000 (sans le module de matrice de commutateur) rapporte 15 MPPS. Des gains de performance supplémentaire peuvent être réalisés pour QoS si des DFC sont utilisés.

DFC

Le DFC peut être relié au WS-X6516-GBIC comme option. Cependant, c'est un élément standard sur la carte WS-X6816-GBIC. Il peut également être pris en charge sur d'autres futurs linecards de matrice tels que le linecard récemment introduit de la matrice 10/100 (WS-X6548-RJ45), le linecard de la matrice RJ21 (WS-X6548-RJ21), et le linecard 100FX (WS-X6524-MM-FX). Le DFC est affiché ci-dessous.

Le DFC permet au linecard de matrice (barre transversale connectée) pour exécuter la commutation locale. Afin de faire ceci, il doit également prendre en charge toutes les stratégies QoS qui ont été définies pour le commutateur. L'administrateur ne peut pas directement configurer le DFC ; en revanche, il est livré sous le contrôle du maître MSFC/PFC sur le superviseur actif. Le PFC primaire abaissera une table de Forwarding Information Base (FIB), qui donne au DFC des tables de son expédition L2 et L3. Il abaissera également une copie des stratégies QoS de sorte qu'ils soient également locaux au linecard. À la suite de ceci, les décisions de commutation locales peuvent mettre en référence la copie locale de toutes les stratégies QoS fournissant des vitesses de traitement de QoS de matériel et rapportant des niveaux supérieurs de la commutation cependant distribuée de représentation.

Le port a basé des ASIC

Pour compléter le tableau de la situation de matériel, chacun des linecards implémente un certain nombre d'ASIC. Ces ASIC implémentent les files d'attente, la mise en mémoire tampon, et les seuils utilisés pour la mémoire temporaire des trames pendant qu'ils transitent le commutateur. Sur les cartes de 10/100, une combinaison des ASIC est utilisée pour provision les 48 10/100 de ports.

Linecards de l'original 10/100 (WS-X6348-RJ45)

Le 10/100 ASIC fournissent une gamme Receive (Rx) et transmettent les files d'attente (TX) pour chaque port de 10/100. Les ASIC fournit la mise en mémoire tampon 128 K par 10/100 port. Référez-vous aux notes de mise à jour pour des détails sur ce qui par mise en mémoire tampon de port est disponible sur chaque linecard. Chaque port sur ce linecard prend en charge une file d'attente de Rx et deux ciel et terre dénoté TX par files d'attente. Ceci est affiché dans le diagramme ci-dessous.

Dans le diagramme ci-dessus, chaque 10/100 ASIC fournit une rubrique pour 12 10/100 de ports. Pour chaque port de 10/100, 128 solutions tampon K sont fournies. Les 128 K de mémoires tampons sont séparés entre chacune des trois files d'attente. Les figures affichées dans la file d'attente ci-dessus ne sont pas les par défaut, cependant, elles sont plutôt une représentation de ce qui pourrait être configuré. La file d'attente simple de Rx obtient 16 K, et la mémoire restante (112 K) est séparés entre les deux files d'attente de Tx. Par défaut (dans CatOS), la file d'attente élevée obtient 20 pour cent de cet espace et la basse file d'attente obtient 80 pour cent. Dans l'IOS de Catalyst, le par défaut est de donner à la file d'attente élevée 10 pour cent et à la basse file d'attente 90 pour cent.

Tandis que la carte fournit la double mise en mémoire tampon d'étape, seulement 10/100 mise en mémoire tampon basée par ASIC est disponible pour être manipulée pendant la configuration QoS.

Linecards de la matrice 10/100 (WS-X6548-RJ45)

Le nouveau 10/100 ASIC fournissent une gamme de Rx et de files d'attente TX pour chaque port de 10/100. Les ASIC fournissent un groupe partagé de mémoire disponible à travers les ports de 10/100. Référez-vous aux notes de mise à jour pour des détails sur ce qui par mise en mémoire tampon de port est disponible sur chaque linecard. Chaque port sur ce linecard prend en charge deux files d'attente de Rx et trois files d'attente TX. Une file d'attente et une file d'attente chacune de Rx TX sont dénotées comme file d'attente prioritaire absolue. Ceci agit en tant que file d'attente à faible latence, qui est idéale pour le trafic sensible de latence tel que le trafic de la voix sur ip (VoIP).

Linecards de GE (WS-X6408A, WS-X6516, WS-X6816)

Pour des linecards de GE, l'ASIC fournit 512 K de par mise en mémoire tampon de port. Une représentation du linecard de GE de huit-port est affichée dans le diagramme ci-dessous.

Comme avec les ports de 10/100, chaque port de GE a trois files d'attente, un Rx et deux files d'attente TX. C'est le par défaut sur le linecard WS-X6408-GBIC, et est affiché dans le diagramme ci-dessous.

Sur la ligne plus nouvelle cartes 16-port GE, les ports GBIC sur le SupIA et SupII, et le port GE WS-X6408A-GBIC 8 cardent, deux files d'attente strictes supplémentaires prioritaire (fournisseur de services) sont fournis. Une file d'attente de fournisseur de services est assignée comme file d'attente de Rx et l'autre est assignée pendant qu'une file d'attente TX. Cette file d'attente de fournisseur de services est utilisée principalement pour le trafic sensible de queue de latence tel que la Voix. Avec la file d'attente de fournisseur de services, n'importe quelles données placées dans cette file d'attente seront traitées avant des données dans les files d'attente de ciel et terre. Seulement quand la file d'attente de fournisseur de services est volonté vide les files d'attente de ciel et terre soyez entretenu.

10 linecards de GE (WS-X6502-10GE)

Dans la dernière moitié de 2001, Cisco a introduit un ensemble de 10 linecards de GE fournissant un port de 10 GE par linecard. Ce module prend un emplacement des 6000 châssis. Les 10 supports QoS de linecard de GE. Pour le port de 10 GE, il fournit deux files d'attente de Rx et trois files d'attente TX. Une file d'attente et une file d'attente chacune de Rx TX sont indiquées comme file d'attente de fournisseur de services. La mise en mémoire tampon est également donnée pour le port, fournissant un total de 256 K de mise en mémoire tampon de Rx et 64 Mo de la mise en mémoire tampon TX. Ce port implémente une structure de la file d'attente 1p1q8t pour le côté de Rx et une structure de la file d'attente 1p2q1t pour le côté TX. Des structures de file d'attente sont détaillées plus tard dans ce document.

Résumé de matériel de QoS de famille du Catalyst 6000

Les composants matériels qui exécutent le QoS ci-dessus fonctionne dans la famille du Catalyst 6000 sont détaillés dans la table ci-dessous.

Support logiciel de famille du Catalyst 6000 pour QoS

Les supports de famille du Catalyst 6000 deux systèmes d'exploitation. La plate-forme logicielle d'origine, CatOS a été dérivée de la base du code utilisée sur la plate-forme de Catalyst 5000. Plus récemment, Cisco a introduit le Cisco IOS® intégré (mode natif) (précédemment connu sous le nom d'IOS indigène), qui utilise une base du code dérivée de l'IOS de routeur de Cisco. Les deux Plateformes de SYSTÈME D'EXPLOITATION (CatOS et Cisco IOS intégré (mode natif)) implémentez le support logiciel pour activer QoS sur la plate-forme de famille de commutateur du Catalyst 6000 utilisant le matériel décrit dans les sections précédentes.

Remarque: Ce document utilise des exemples de configuration des deux Plateformes de SYSTÈME D'EXPLOITATION.

Mécanismes prioritaires dans l'IP et les Ethernets

Pour que tous services QoS soient appliqués aux données, il doit y a une manière d'étiqueter ou donner la priorité à un paquet IP ou à une trame Ethernet. Le tos et les champs de cos sont utilisés pour réaliser ceci.

Tos

Le tos est un champ de à un octet qui existe dans une en-tête d'IPV4. Le champ de tos se compose de huit bits, dont les trois premiers bits sont utilisés pour indiquer la priorité du paquet IP. Ces trois premiers bits désigné sous le nom des bits de Priorité IP. Ces bits peuvent être placés de zéro à sept, avec zéro étant la priorité la plus basse et sept étant les plus prioritaires. Le support a été disponible pour placer la Priorité IP dans l'IOS depuis de nombreuses années. Le soutien de remettre à l'état initial la Priorité IP peut être fait par le MSFC ou par le PFC (indépendant du MSFC). Une configuration de confiance de boîte non approuvée également éliminer toutes configurations de Priorité IP sur une trame entrante.

Les valeurs qui peuvent être placées pour la Priorité IP sont comme suit :

Le diagramme ci-dessous est une représentation des bits de Priorité IP dans l'en-tête de tos. Les trois bits les plus significatifs (MSB) sont interprétés comme bits de Priorité IP.

Plus récemment, l'utilisation du champ de tos a été développée pour entourer les six MSBs, désignés sous le nom du DSCP. Le DSCP a comme conséquence 64 valeurs prioritaires (deux à l'alimentation de six) qui peuvent être assignées au paquet IP.

La famille du Catalyst 6000 peut manipuler le tos. Ceci peut être réalisé utilisant le PFC et/ou le MSFC. Quand une trame entre dans le commutateur, elle sera assignée une valeur DSCP. Cette valeur DSCP est utilisée intérieurement dans le commutateur pour assigner des niveaux de service (stratégies QoS) définis par l'administrateur. Le DSCP peut déjà exister dans une trame et être utilisé, ou le DSCP peut être dérivé du cos existant, de la Priorité IP, ou du DSCP dans la trame (si le port sont de confiance). Une carte est utilisée intérieurement dans le commutateur pour dériver le DSCP. Avec huit valeurs possibles de priorité CoS/IP et 64 valeurs DSCP possibles, la carte par défaut tracera le cos/IPPrec 0 au DSCP 0, cos/IPPrec 1 à DSCP 7, cos/IPPrec 2 à DSCP 15, et ainsi de suite. Ces mappages par défaut peuvent être ignorés par l'administrateur. Quand la trame est programmée à un port de sortie, le cos peut être récrit et la valeur DSCP est utilisée pour dériver le nouveau cos.

Cos

Le cos se rapporte à trois bits dans une en-tête ISL ou une en-tête de 802.1Q qui sont utilisés pour indiquer la priorité de la trame Ethernet pendant qu'elle traverse un réseau commuté. Aux fins de ce document, nous nous référons seulement à l'utilisation de l'en-tête de 802.1Q. Les bits de cos dans l'en-tête de 802.1Q désigné généralement sous le nom des bits 802.1p. Comme on pouvait s'y attendre, il y a trois bits de cos, qui apparie le nombre de bits utilisés pour la Priorité IP. Dans beaucoup de réseaux, pour mettre à jour QoS de bout en bout, un paquet peut traverser les domaines L2 et L3. Pour mettre à jour QoS, le tos peut être tracé au cos, et le cos peut être tracé au tos.

Le diagramme ci-dessous est une trame Ethernet étiquetée avec un champ de 802.1Q, qui se compose d'un Ethertype à deux bits et d'une balise à deux bits. Dans la balise à deux bits sont les bits de priorité utilisateur (connus sous le nom de 802.1p).

Écoulement de QoS dans la famille du Catalyst 6000

QoS dans la famille du Catalyst 6000 est l'implémentation la plus complète de QoS dans des tous les commutateurs Cisco Catalyst en cours. Les sections suivantes décrivent comment les divers processus de QoS sont appliqués à une trame en tant qu'elle transite le commutateur.

Plus tôt dans ce document, on l'a noté qu'il y a un certain nombre d'éléments QOS que beaucoup de Commutateurs L2 et L3 peuvent offrir. Ces éléments sont classification, file d'attente d'entrée programmant, maintenant l'ordre, réécrivant, et programmant de file d'attente de sortie. La différence avec la famille du Catalyst 6000 est que ces éléments de QoS sont appliqués par une engine L2 qui a la vue dans les détails L3 et L4 aussi bien que juste les informations d'en-tête L2. Le diagramme suivant récapitule comment la famille du Catalyst 6000 implémente ces éléments.

Une trame écrit le commutateur et est au commencement traitée par le port ASIC qui a reçu la trame. Il placera la trame dans une file d'attente de Rx. Selon le linecard de famille du Catalyst 6000, il y aura un ou deux files d'attente de Rx.

Le port ASIC emploiera les bits de cos comme indicateur dont file d'attente pour placer la trame dans (si les files d'attente à entrées multiples sont présentes). Si le port est classifié comme non approuvé, le port ASIC peut remplacer les bits existants de cos basés sur une valeur de prédéfinis.

La trame est alors passée à l'engine de l'expédition L2/L3 (PFC), qui classifiera et maintiendra l'ordre sur option (raté limit) la trame. La classification est le processus d'assigner à la trame une valeur DSCP, qui est utilisée intérieurement par le commutateur pour traiter la trame. Le DSCP sera dérivé d'un de ce qui suit :

    1. Une valeur DSCP existante a placé avant la trame écrivant le commutateur

    2. Les bits reçus de Priorité IP ont déjà placé dans l'en-tête d'IPV4. Car il y a 64 valeurs DSCP et seulement huit valeurs de Priorité IP, l'administrateur configurera un mappage qui est utilisé par le commutateur pour dériver le DSCP. Les mappages par défaut sont en place si l'administrateur ne configure pas les cartes.

    3. Les bits reçus de cos ont déjà placé avant la trame écrivant le commutateur. Semblable à la Priorité IP, il y a un maximum de huit valeurs CoS, qui doivent être tracées à une de 64 valeurs DSCP. Cette carte peut être configurée ou le commutateur peut utiliser la carte par défaut en place.

    4. Placez de la trame à l'aide d'une valeur par défaut de DSCP typiquement assignée cependant une entrée de liste de contrôle d'accès (ACL).

Après qu'une valeur DSCP soit assignée à la trame, le maintien de l'ordre (limitation de débit) est appliqué, si une configuration de maintien de l'ordre existe. Le maintien de l'ordre limitera l'écoulement des données par le PFC par la baisse ou le repérage en bas du trafic qui est -de-profil. le -de-profil est un terme utilisé pour indiquer que le trafic a dépassé une limite définie par l'administrateur comme la quantité de bits par seconde que le PFC enverra. Le trafic hors profil peut être abandonné ou la valeur CoS peut être marquée vers le bas. Les PFC1 et le PFC2 prennent en charge actuellement seulement le maintien de l'ordre d'entrée (limitation de débit). Le soutien du maintien de l'ordre d'entrée et sortie sera disponible avec la release d'un nouveau PFC.

Le PFC passera alors la trame au port de sortie pour le traitement. En ce moment, un processus de réécriture est appelé pour modifier les valeurs CoS dans la trame et la valeur de tos dans l'en-tête d'IPV4. Ceci est dérivé du DSCP interne. La trame sera alors placée dans une file d'attente de transmission basée sur sa valeur CoS, prête pour la transmission. Tandis que la trame est dans la file d'attente, le port ASIC surveillera les mémoires tampons et implémentera WRED pour éviter les mémoires tampons du débordement. Un algorithme de planification WRR est alors utilisé pour programmer et transmettre des trames du port de sortie

Chacune des sections ci-dessous explorera cet écoulement donnant plus en détail des exemples de configuration pour chacune des étapes décrites ci-dessus.

Files d'attente, mémoires tampons, seuils, et mappages

Avant que la configuration QoS soit décrite en détail, certains termes doivent être expliqués plus loin pour s'assurer que vous comprenez entièrement les capacités de configuration QoS du commutateur.

Files d'attente

Chaque port sur le commutateur a une gamme de files d'attente d'entrée et sortie qui sont utilisées comme zones de mémoire temporaire pour des données. Les linecards de famille du Catalyst 6000 implémentent des numéros différents de files d'attente pour chaque port. Les files d'attente sont habituellement mises en application dans le matériel ASIC pour chaque port. Sur les linecards de famille du Catalyst 6000 de première génération, la configuration typique était une file d'attente d'entrée et deux files d'attente de sortie. Sur de plus nouveaux linecards (10/100 et GE), l'ASIC implémente un ensemble supplémentaire de deux files d'attente (on entrent et une sortie) ayant pour résultat deux files d'attente d'entrée et trois files d'attente de sortie. Ces deux files d'attente supplémentaires sont les files d'attente spéciales de fournisseur de services utilisées pour le trafic sensible de latence tel que le VoIP. Ils sont entretenus d'une mode de fournisseur de services. C'est-à-dire, si une trame arrive dans la file d'attente de fournisseur de services, l'établissement du programme des trames des files d'attente inférieures est cessé pour traiter la trame dans la file d'attente de fournisseur de services. Seulement quand la file d'attente de fournisseur de services est établissement du programme vide de volonté des paquets des files d'attente inférieures recommencez.

Quand une trame arrive à un port (pour l'entrée ou la sortie) à une époque d'encombrement, elle sera placée dans une file d'attente. La décision derrière laquelle la file d'attente la trame est placée dedans sera typiquement faite a basé sur la valeur CoS dans l'en-tête Ethernet de la trame entrante.

Sur le de sortie, un algorithme de planification sera utilisé pour vider la file d'attente TX (sortie). WRR est la technique utilisée pour réaliser ceci. Pour chaque file d'attente, un coefficient est utilisé pour dicter combien de données seront vidées de la file d'attente avant de passer à la prochaine file d'attente. Le coefficient assigné par l'administrateur est un nombre de 1 à 255 et ceci est assigné à chaque file d'attente TX.

Mémoires tampons

Chaque file d'attente est assignée un espace de mémoire tampon pour enregistrer des données de transit. Le résident sur le port ASIC est la mémoire, qui est fractionnée et allouée sur a par base de port. Pour chaque port de GE, GE ASIC assigne 512 K de l'espace de mémoire tampon. Pour 10/100 de ports, le port ASIC réserve 64 K ou 128 K (selon le linecard) de par mise en mémoire tampon de port. Cet espace de mémoire tampon est alors divisé entre la file d'attente de Rx (d'entrée) et les files d'attente TX (de sortie).

Seuils

Un aspect de transmission de données normale est que si un paquet est lâché, il aura comme conséquence ce paquet étant retransmis (des écoulements de TCP). À une époque d'encombrement, ceci peut ajouter au chargement sur le réseau et potentiellement faire surcharger des mémoires tampons bien plus. Afin de s'assurer que les mémoires tampons ne débordent pas, le commutateur de famille du Catalyst 6000 utilise un certain nombre de techniques pour éviter ceci de l'événement.

Les seuils sont des niveaux imaginaires assignés par le commutateur (ou l'administrateur) qui définissent les points d'utilisation auxquels l'algorithme de Gestion d'encombrement peut commencer des données chutantes de la file d'attente. Sur les ports de famille du Catalyst 6000, il y a en général quatre seuils qui sont associés avec des files d'attente d'entrée. Il y a habituellement deux seuils associés avec des files d'attente de sortie.

Ces seuils sont également déployés, dans le cadre de QoS, comme manière d'assigner des trames avec différentes priorités à ces seuils. Pendant que la mémoire tampon commence à remplir et des seuils sont ouverts une brèche, l'administrateur peut tracer différentes priorités à différents seuils indiquant au commutateur qui encadre devrait être abandonné quand un seuil est dépassé.

Mappages

Dans les files d'attente et les sections de seuil ci-dessus, on lui a mentionné que la valeur CoS dans la trame Ethernet est utilisée pour déterminer dans quelle file d'attente pour placer la trame et à quel point du taux de remplissage de la mémoire tampon est en hausse une trame éligible pour être abandonné. C'est le but des mappages.

Quand QoS est configuré sur la famille du Catalyst 6000, on active des mappages par défaut qui définissent ce qui suit :

  • quels seuils encadre avec les valeurs CoS spécifiques soyez éligible pour être relâché

  • dans quelle file d'attente une trame est placée (basé sur sa valeur CoS)

Tandis que les mappages par défaut existent, ces mappages par défaut peuvent être ignorés par l'administrateur. Le mappage existe pour ce qui suit :

  • Valeurs CoS sur une trame entrante à une valeur DSCP

  • Valeurs de Priorité IP sur une trame entrante à une valeur DSCP

  • Valeurs DSCP à une valeur CoS d'une trame sortante

  • Les valeurs CoS pour relâcher des seuils reçoivent en fonction des files d'attente

  • Valeurs CoS pour relâcher des seuils sur des files d'attente de transmission

  • Valeurs de baisse de DSCP des trames qui dépassent maintenir l'ordre des déclarations

  • Valeurs CoS à une trame avec une adresse MAC spécifique de destination

WRED et WRR

WRED et WRR sont deux algorithmes extrêmement puissants résidents sur la famille du Catalyst 6000. WRED et WRR emploient la balise prioritaire (cos) à l'intérieur d'une trame Ethernet pour fournir la gestion de mémoire tampon améliorée et l'établissement du programme sortant. B

WRED

WRED est un algorithme de gestion de mémoire tampon utilisé par la famille du Catalyst 6000 pour réduire l'incidence de relâcher le trafic prioritaire à une époque d'encombrement. WRED est basé sur l'algorithme ROUGE.

Afin de comprendre le ROUGE et le WRED, revisitez le concept de la Gestion d'écoulement de TCP. La Gestion d'écoulement s'assure que l'expéditeur de TCP n'accable pas le réseau. L'algorithme de slowstart de TCP fait partie de la solution pour adresser ceci. Il dicte que quand des débuts d'un écoulement, un paquet simple est envoyés avant qu'il attende un accusé de réception. Deux paquets sont alors envoyés avant qu'un ACK soit reçu, augmentant graduellement le nombre de paquets envoyés avant que chaque ACK soit reçu. Ceci continuera jusqu'à ce que l'écoulement atteigne un niveau de transmission (c'est-à-dire, envoie le nombre x de paquets) que le réseau peut manipuler sans chargement encourant l'encombrement. Si l'encombrement se produit, l'algorithme de slowstart étranglera soutiennent la taille de la fenêtre (c'est-à-dire, le nombre des paquets envoyés avant d'attendre un accusé de réception), de ce fait réduisant la performance globale pour cette session TCP (écoulement).

Le ROUGE surveillera une file d'attente en tant que lui commence à se remplir. Une fois qu'un certain seuil a été dépassé, des paquets commenceront à être lâchés aléatoirement. Aucun respect n'est donné aux écoulements spécifiques ; en revanche, des paquets aléatoires seront lâchés. Ces paquets pourraient être de haute ou la faible priorité circule. Les paquets lâchés peuvent faire partie des écoulements à courant simple ou plusieurs de TCP. Si de plusieurs écoulements sont affectés, comme décrit ci-dessus, ceci peut avoir une incidence considérable sur chacun circule la taille de la fenêtre.

À la différence du ROUGE, WRED n'est pas comme aléatoire en relâchant des trames. WRED prend en compte la priorité des trames (dans la caisse de famille du Catalyst 6000 il utilise la valeur CoS). Avec WRED, l'administrateur assigne des trames avec certaines valeurs CoS aux seuils spécifiques. Une fois que ces seuils sont dépassés, les trames avec les valeurs CoS qui sont tracées à ces seuils sont éligibles pour être abandonnées. D'autres trames avec des valeurs CoS assignées aux seuils plus élevés sont maintenues dans la file d'attente. Ce processus tient compte pour que des écoulements plus prioritaires soient maintenus intacts maintenant leurs plus grandes tailles de la fenêtre intactes et réduisant la latence impliquée en obtenant les paquets de l'expéditeur au récepteur.

Comment savez-vous si votre linecard prend en charge WRED ? Émettez la commande suivante. Dans la sortie, vérifiez la section qui indique le soutien de WRED sur ce port.

 
Console> show qos info config 2/1 
QoS setting in NVRAM: 
QoS is enabled 
Port 2/1 has 2 transmit queue with 2 drop thresholds (2q2t). 
Port 2/1 has 1 receive queue with 4 drop thresholds (1q4t). 
Interface type:vlan-based 
ACL attached: 
The qos trust type is set to untrusted. 
Default CoS = 0 
Queue and Threshold Mapping: 
Queue Threshold CoS 
----- --------- --------------- 
1     1         0 1 
1     2         2 3 
2     1         4 5 
2     2         6 7 
Rx drop thresholds: 
Rx drop thresholds are disabled for untrusted ports. 
Queue #  Thresholds - percentage (abs values) 
-------  ------------------------------------- 
1        50% 60% 80% 100% 
TX drop thresholds: 
Queue #  Thresholds - percentage (abs values) 
-------  ------------------------------------- 
1        40% 100% 
2        40% 100% 
TX WRED thresholds: 
WRED feature is not supported for this port_type.
!-- Look for this.
Queue Sizes: 
Queue #  Sizes - percentage (abs values) 
-------  ------------------------------------- 
1        80% 
2        20% 
WRR Configuration of ports with speed 1000MBPS: 
Queue #  Ratios (abs values) 
-------  ------------------------------------- 
1        100 
2        255 
Console> (enable)

Au cas où WRED ne serait pas disponible sur un port, le port utilisera une méthode de perte de destination de gestion de mémoire tampon. La perte de destination, en tant que son nom implique, relâche simplement les trames entrantes une fois que les mémoires tampons ont été entièrement utilisées.

WRR

WRR est utilisé pour programmer le trafic en sortie des files d'attente TX. Un algorithme de recherche séquentielle normal alternera entre les files d'attente TX envoyant un nombre équivalent de paquets de chaque file d'attente avant le déplacement à la prochaine file d'attente. L'aspect pesé de WRR permet à l'algorithme de planification pour examiner un coefficient qui a été assigné à la file d'attente. Ceci permet l'accès défini de files d'attente à plus de la bande passante. L'algorithme de planification WRR videra plus de données des files d'attente identifiées que d'autres files d'attente, de ce fait fournissant une polarisation pour les files d'attente indiquées.

La configuration pour WRR et les autres aspects de ce qui ont été décrites ci-dessus sont expliqués dans les sections suivantes.

Configurer le port ASIC a basé QoS sur la famille du Catalyst 6000

La configuration QoS demande au port ASIC ou au PFC d'exécuter une action de QoS. Les sections suivantes regarderont la configuration QoS pour ces deux processus. Sur le port ASIC, la configuration QoS affecte les deux écoulements du trafic en entrée et en sortie.

Du diagramme ci-dessus, il peut voir que les processus suivants de configuration QoS s'appliquent :

    1. états de confiance de ports

    2. l'application du port a basé le cos

    3. Affectation de seuil de baisse de Rx

    4. Cos aux cartes de seuil de baisse de Rx

Quand une trame est traitée par le MSFC ou le PFC, elle est passée au port de sortie ASIC pour une transformation plus ultérieure. Toutes les trames traitées par le MSFC auront leurs valeurs CoS remises à zéro. Ceci doit être pris en compte pour QoS traitant sur des ports de sortie.

Le diagramme ci-dessus affiche le traitement de QoS exécuté par le port ASIC pour le trafic sortant. Certains des processus appelés sur le traitement sortant de QoS incluent ce qui suit :

    1. Perte de destination TX et affectations de seuil WRED

    2. Cos à la perte de destination TX et aux cartes WRED

En outre, non affiché sur le diagramme ci-dessus, est le processus de réaffecter le cos à la trame sortante utilisant un DSCP à la carte de cos.

Les sections suivantes examinent les capacités de configuration QoS des ASIC basés par port plus en détail.

Remarque: Un point important à faire est que quand des commandes de QoS sont appelées utilisant CatOS, elles s'appliquent typiquement à tous les ports avec le type spécifié de file d'attente. Par exemple, si un seuil de baisse WRED est appliqué aux ports avec le type 1p2q2t de file d'attente, ce seuil de baisse WRED est appliqué à tous les ports sur tous les linecards prenant en charge ce type de file d'attente. Avec l'IOS de cat, les commandes de QoS sont en général appliquées au niveau d'interface.

Activation de QoS

Avant que n'importe quelle configuration QoS puisse avoir lieu sur la famille du Catalyst 6000, QoS doit d'abord être activé sur le commutateur. Ceci est réalisé en émettant la commande suivante :

CatOS

 
Console> (enable) set qos enable
!-- QoS is enabled.
Console> (enable)

Cisco IOS intégré (mode natif)

 
Cat6500(config)# mls qos

Quand QoS est activé dans la famille du Catalyst 6000, le commutateur placera une gamme de par défaut de QoS pour le commutateur. Ces par défaut incluent les configurations suivantes :

Ports de confiance et non approuvés

N'importe quel port donné sur la famille du Catalyst 6000 peut être configuré comme fait confiance ou hors sécurité l'état de confiance des ordres de port comment il marque, classifie, et programme la trame en tant que lui transite le commutateur. Par défaut, tous les ports sont dans l'état non approuvé.

Ports non approuvés (valeur par défaut pour des ports)

Si le port est configuré comme port non approuvé, une trame en entrant dans au commencement le port aura son cos et le tos évalue la remise par le port ASIC à zéro. Ceci signifie que la trame sera donnée le service de la priorité la plus basse sur son chemin à travers le commutateur.

Alternativement, l'administrateur peut remettre à l'état initial la valeur CoS de n'importe quelle trame Ethernet qui entre dans un port non approuvé à une valeur prédéterminée. Configurant ceci sera discuté dans une section postérieure.

L'établissement du port en tant que non approuvé demandera au commutateur de ne pas exécuter n'importe quelle manière d'éviter d'encombrement. La manière d'éviter d'encombrement est la méthode utilisée pour relâcher des trames basées sur leurs valeurs CoS une fois qu'elles dépassent des seuils définis pour cette file d'attente. Toutes les trames entrant dans ce port seront également éligibles pour être abandonnées une fois que les mémoires tampons atteignent 100 pour cent.

Dans CatOS, un 10/100 ou un port de GE peut être configuré comme non approuvé en émettant la commande suivante :

CatOS

 
Console> (enable) set port qos 3/16 trust untrusted
!-- Port 3/16 qos set to untrusted. 
Console> (enable)

Cette commande place le port 16 sur le module 3 à un état de non approuvé.

Remarque: Pour le Cisco IOS Integrated (mode natif), le logiciel prend en charge actuellement seulement la confiance de configuration pour des ports de GE.

Cisco IOS intégré (mode natif)

 
Cat6500(config)# interface gigabitethernet 1/1 
Cat6500(config-if)# no mls qos trust

Dans l'exemple ci-dessus, nous écrivons la configuration d'interface et appliquons le forme no de la commande de placer le port car non approuvé puisque c'est IOS.

Ports de confiance

Parfois, les trames Ethernet écrivant un commutateur auront le cos ou le tos plaçant que l'administrateur veut que le commutateur mette à jour pendant que la trame transite le commutateur. Pour ce trafic, l'administrateur peut placer l'état de confiance d'un port où ce trafic entre dans le commutateur comme fait confiance.

Comme cité précédemment, le commutateur emploie une valeur DSCP intérieurement pour assigner un niveau prédéterminé de service à cette trame. Car une trame entre dans un port de confiance, l'administrateur peut configurer le port pour regarder le cos existant, la Priorité IP, ou la valeur DSCP pour placer la valeur de DSCP interne. Alternativement, l'administrateur peut placer un DSCP de prédéfinis à chaque paquet qui entre dans le port.

L'établissement de l'état de confiance d'un port à faire confiance peut être réalisé en émettant la commande suivante :

CatOS

 
Console> (enable) set port qos 3/16 trust trust-cos
!-- Port 3/16 qos set to trust-COs
Console> (enable)

Cette commande s'applique sur le linecard WS-X6548-RJ45 et place l'état de confiance du port 3/16 à faire confiance. Le commutateur emploiera le positionnement de valeur CoS dans la trame entrante pour placer le DSCP interne. Le DSCP est dérivé du l'un ou l'autre une carte par défaut qui a été créée quand QoS a été activé sur le commutateur, ou alternativement d'une carte définie par l'administrateur. Au lieu du mot clé de confiance-cos, l'administrateur peut également utiliser le confiance-dscp ou les mots clé de confiance-ipprec.

Sur les cartes 10/100-line précédentes (WS-X6348-RJ45 et WS-X6248-RJ45), la confiance de port doit être placée en émettant la commande d'acl de set qos. Dans cette commande, un état de confiance peut être assigné par un sous paramètre de la commande d'acl de set qos. L'établissement du cos de confiance sur des ports sur ces linecards n'est pas pris en charge, comme affiché ci-dessous.

 
Console> (enable) set port qos 4/1 trust trust-COs
Trust type trust-COs not supported on this port.
!-- Trust-COs not supported, use acl instead.
Rx thresholds are enabled on port 4/1. 
!-- Need to turn on input queue scheduling.
Port  4/1 qos set to untrusted. 
!-- Trust-COs not supported, so port is set to untrusted.

La commande ci-dessus indique qu'on l'exige pour activer l'établissement du programme de file d'attente d'entrée. Ainsi, pour 10/100 de ports sur les linecards WS-X6248-RJ45 et WS-X6348-RJ45, la commande de confiance-cos de confiance du set port qos x/y doit encore être configurée, bien que pour placer des états de confiance, l'ACL doive être utilisé.

Avec le Cisco IOS intégré (mode natif), la configuration de la confiance peut être exécutée sur une interface de GE et 10/100 de ports sur le nouveau linecard WS-X6548-RJ45.

Cisco IOS intégré (mode natif)

 
Cat6500(config)# interface gigabitethernet 5/4 
Cat6500(config-if)# mls qos trust ip-precedence 
Cat6500(config-if)#

Cet exemple place l'état de confiance du port 5/4 de GE à faire confiance. La valeur de priorité IP de la trame sera utilisée pour dériver la valeur DSCP.

Le port de classification des entrées et de configuration a basé le cos

Sur le d'entrée à un port de commutateur, une trame Ethernet peut avoir son cos changé si elle remplit un des deux critères suivants :

    1. le port est configuré comme non approuvé, ou

    2. la trame Ethernet ne fait pas placer une valeur CoS existante déjà

Si vous souhaitez modifier le cos d'une trame Ethernet entrante, vous devriez émettre la commande suivante :

CatOS

 
Console> (enable) set port qos 3/16 cos 3
!-- Port 3/16 qos set to 3. 
Console> (enable)

Cette commande place le cos des trames Ethernet entrantes sur le port 16 sur le module 3 à une valeur de 3 quand une trame non marquée arrive ou si le port est placé à non approuvé.

Cisco IOS intégré (mode natif)

 
Cat6500(config)# interface fastethernet 5/13 
Cat6500(config-if)# mls qos COs 4
Cat6500(config-if)#

Cette commande place le cos des trames Ethernet entrantes sur le port 13 sur le module 5 à une valeur de 4 quand une trame non marquée arrive ou si le port est placé à non approuvé.

Configurez les seuils de baisse de Rx

Sur le d'entrée au port de commutateur, la trame sera placée dans une file d'attente de Rx. Pour éviter des débordements de tampon, les mises en place du port ASIC quatre seuils sur chaque Rx alignent et emploient ces seuils pour identifier les trames qui peuvent être abandonnées une fois ces seuils ont été dépassées. Le port ASIC emploiera la valeur de set cos de trames pour identifier quelles trames peuvent être abandonnées quand un seuil est dépassé. Cette capacité permet à des trames plus prioritaires pour demeurer dans la mémoire tampon pour plus long quand l'encombrement se produit.

Suivant les indications du diagramme ci-dessus, les trames arrivent et sont placées dans la file d'attente. Comme débuts de file d'attente à remplir, les seuils sont surveillés par le port ASIC. Quand un seuil est ouvert une brèche, des trames avec des valeurs de cos identifiées par l'administrateur sont abandonnées aléatoirement de la file d'attente. Les mappages par défaut de seuil pour une file d'attente 1q4t (trouvée sur linecards WS-X6248-RJ45 et WS-X6348-RJ45) sont comme suit :

  • le seuil 1 est placé à 50% et les valeurs 0 et 1 de cos sont tracées à ce seuil
  • le seuil 2 est placé à 60% et les valeurs 2 et 3 de cos sont tracées à ce seuil
  • le seuil 3 est placé à 80% et les valeurs 4 et 5 de cos sont tracées à ce seuil
  • le seuil 4 est placé à 100% et les valeurs 6 et 7 de cos sont tracées à ce seuil

Pour (trouvé sur des ports de GE) une file d'attente 1P1q4t, les mappages par défaut sont comme suit :

  • le seuil 1 est placé à 50% et les valeurs 0 et 1 de cos sont tracées à ce seuil
  • le seuil 2 est placé à 60% et les valeurs 2 et 3 de cos sont tracées à ce seuil
  • le seuil 3 est placé à 80% et les valeurs 4 de cos sont tracées à ce seuil
  • le seuil 4 est placé à 100% et les valeurs 6 et 7 de cos sont tracées à ce seuil
  • La valeur de cos de 5 est tracée à la file d'attente prioritaire stricte

Pour un 1p1q0t (trouvé sur 10/100 met en communication sur le linecard WS-X6548-RJ45), les mappages par défaut sont comme suit :

  • Les vues avec le cos 5 vont à la file d'attente de Rx de fournisseur de services (file d'attente 2), où le commutateur relâche les trames entrantes seulement quand la mémoire tampon de recevoir-file d'attente de fournisseur de services est de 100 pour cent de pleine.
  • Les vues avec le cos 0, 1, 2, 3, 4, 6, ou 7 vont à la file d'attente standard de Rx. Le commutateur relâche les trames entrantes quand la mémoire tampon de Rx-file d'attente est de 100 pour cent de pleine.

Ces seuils de baisse peuvent être changés par l'administrateur. En outre, les valeurs de cos de par défaut qui sont tracées à chaque seuil peuvent également être changées. Différentes réalisations de file d'attente de Rx de mise en place différente de linecards. Un résumé des types de file d'attente est affiché ci-dessous.

CatOS

 
Console> (enable) set qos drop-threshold 1q4t rx queue 1 20 40 75 100
!-- Rx drop thresholds for queue 1 set at 20%, 40%, 75%, and 100%.
Console> (enable)

Cette commande place les seuils de baisse de réception pour tous les ports d'entrée avec une file d'attente et quatre seuils (dénote 1q4t) à 20%, à 40%, à 75%, et à 100%.

La commande émise dans le Cisco IOS intégré (mode natif) est affichée ci-dessous.

Cisco IOS intégré (mode natif)

 
Cat6500(config-if)# wrr-queue threshold 1 40 50 
Cat6500(config-if)# wrr-queue threshold 2 60 100 

!-- Configures the 4 thresholds for a 1q4t rx queue and.

Cat6500(config-if)# rcv-queue threshold 1 60 75 85 100

!-- Configures for a 1p1q4t rx queue, which applies to 
!-- the new WS-X6548-RJ45 10/100 line card.

Des seuils de baisse de Rx doivent être activés par l'administrateur. Actuellement, la commande de confiance-cos de confiance du set port qos x/y devrait être utilisée pour lancer les seuils de baisse de Rx (où x est le numéro de module et y est le port sur ce module).

Configurer des seuils de baisse TX

Sur un port de sortie, le port aura deux seuils TX qui sont utilisés en tant qu'élément du mécanisme de manière d'éviter d'encombrement, alignent 1 et la file d'attente 1 de la file d'attente 2. est dénotée comme file d'attente à basse priorité standard, et la file d'attente 2 est dénotée comme file d'attente prioritaire standard. Selon les linecards utilisés, ils utiliseront une perte de destination ou un algorithme de Gestion de seuil WRED. Les deux algorithmes utilisent deux seuils pour chaque file d'attente TX.

L'administrateur peut manuellement placer ces seuils comme suit :

CatOS

 
Console> (enable) set qos drop-threshold 2q2t TX queue 1 40 100
!-- TX drop thresholds for queue 1 set at 40% and 100%.
Console> (enable)

Cette commande place les seuils de baisse TX pour le 1par de file d'attente tous les ports de sortie avec deux files d'attente et deux seuils (dénote 2q2t) à 40% et à 100%.

 
Console> (enable) set qos wred 1p2q2t TX queue 1  60 100
!-- WRED thresholds for queue 1 set at 60% 100% on all WRED-capable 1p2q2t ports.
Console> (enable)

Cette commande place les seuils de baisse WRED pour le 1par de file d'attente tous les ports de sortie avec une file d'attente de fournisseur de services, deux files d'attente normales, et deux seuils (dénote 1p2q2t) à 60% et à 100%. La file d'attente 1 est définie comme file d'attente à basse priorité normale et a la priorité la plus basse. La file d'attente 2 est la file d'attente normale prioritaire et a une haute priorité qu'aligner 1. file d'attente 3 est la file d'attente de fournisseur de services et est entretenue en avant de toutes autres files d'attente sur ce port.

La commande émise équivalente dans le Cisco IOS intégré (mode natif) est affichée ci-dessous.

Cisco IOS intégré (mode natif)

 
Cat6500(config-if)# wrr-queue random-detect max-threshold  1 40 100
Cat6500(config-if)#

Ceci place les seuils de baisse WRED pour qu'un port 1p2q2t aligne 1 à 40% pour le seuil 1 (TX) et 100% pour le seuil 2 (TX).

WRED peut également être désactivé s'il y a lieu dans le Cisco IOS intégré (mode natif). La méthode utilisée pour faire ceci est forme d'utiliser n » de la commande. Un exemple de désactiver WRED est affiché comme suit :

Cisco IOS intégré (mode natif)

 
Cat6500(config-if)# no wrr-queue random-detect queue_id

Cartographie de l'adresse MAC aux valeurs de cos

En plus du cos de configuration basé sur une définition globale de port, le commutateur permet l'administrateur aux valeurs de set cos basées sur l'adresse MAC et l'ID DE VLAN de destination. Ceci tient compte des trames destinées pour que les cibles spécifiques soient étiquetées avec une valeur prédéterminée de cos. Cette configuration peut être réalisée en émettant la commande suivante :

CatOS

 
Console> (enable) set qos Mac-COs 00-00-0c-33-2a-4e 200 5
!-- COs 5 is assigned to 00-00-0c-33-2a-4e VLAN 200.
Console> (enable)

Cette commande place le cos de 5 de n'importe quelle trame dont l'adresse MAC de destination est 00-00-0c-33-2a-4e qui était de VLAN 200.

Il n'y a aucune commande équivalente dans le Cisco IOS intégré (mode natif). C'est parce que cette commande est seulement prise en charge quand aucun PFC n'est présent et le Cisco IOS intégré (mode natif) exige d'un PFC de fonctionner.

Cartographie du cos aux seuils

Après que des seuils aient été configurés, l'administrateur peut alors assigner à cos des valeurs à ces seuils, de sorte que quand le seuil a été dépassé, des trames avec des valeurs spécifiques de cos puissent être abandonnées. Habituellement, l'administrateur assignera des trames de priorité plus basse aux seuils inférieurs, de ce fait mettant à jour le trafic plus prioritaire dans la file d'attente si l'encombrement se produit.

La figure ci-dessus affiche une file d'attente d'entrée avec quatre seuils, et comment des valeurs de cos ont été assignées à chaque seuil.

La sortie suivante affiche comment des valeurs de cos peuvent être tracées aux seuils :

CatOS

 
Console> (enable) set qos map 2q2t 1 1 COs 0 1 
!-- QoS TX priority queue and threshold mapped to COs successfully.
Console> (enable)

Cette commande assigne à cos des valeurs de 0 et de 1 pour aligner 1, le seuil 1. La commande équivalente dans le Cisco IOS intégré (mode natif) est affichée ci-dessous.

Cisco IOS intégré (mode natif)

 
Cat6500(config-if)# wrr-queue COs-map  1  1  0  1 
Cat6500(config-if)#

Configurez la bande passante sur des files d'attente TX

Quand une trame est placée dans une file d'attente de sortie, elle sera transmise utilisant un algorithme de planification de sortie. Le processus de programmateur de sortie emploie WRR pour transmettre des trames des files d'attente de sortie. Selon le matériel de linecard étant utilisé, il y a deux, trois, ou quatre files d'attente de transmission par port.

Sur les linecards WS-X6248 et WS-X6348 (avec des structures de file d'attente 2q2t), deux files d'attente TX sont utilisées par le mécanisme WRR pour l'établissement du programme. Sur les linecards WS-X6548 (avec une structure de file d'attente 1p3q1t) il y a quatre files d'attente TX. De ces quatre files d'attente TX, trois files d'attente TX sont entretenues par l'algorithme WRR (la dernière file d'attente TX est une file d'attente de fournisseur de services). Sur des linecards de GE, il y a trois files d'attente TX (utilisant une structure de file d'attente 1p2q2t) ; une de ces files d'attente est une file d'attente de fournisseur de services ainsi les services d'algorithme WRR seulement deux files d'attente TX.

Typiquement, l'administrateur assignera un poids à la file d'attente TX. WRR fonctionne à côté de regarder le coefficient assigné à la file d'attente de port, qui est utilisée intérieurement par le commutateur pour déterminer combien de trafic sera transmis avant de passer à la prochaine file d'attente. Une valeur de coefficient de entre 1 et 255 peut être assignée à chacune de la file d'attente de port.

CatOS

 
Console> (enable) set qos wrr 2q2t 40 80 
!-- QoS wrr ratio set successfully.
Console> (enable)

Cette commande assigne un coefficient de 40 pour aligner 1 et 80 pour aligner 2. Ceci signifie efficacement des deux à un rapports (80 40 = 2 à 1) de la bande passante assignée entre les deux files d'attente. Cette commande la prend effet sur tous les ports avec deux files d'attente et deux seuils sur des ports.

La commande émise équivalente dans le Cisco IOS intégré (mode natif) est affichée ci-dessous.

Cisco IOS intégré (mode natif)

 
Cat6500(config-if)# wrr-queue bandwidth 1 3
Cat6500(config-if)#

Ce qui précède représente des trois à un rapports entre les deux files d'attente. Vous noterez que la version IOS de cat de cette commande s'applique à une interface spécifique seulement.

DSCP à la cartographie de cos

Quand la trame a été placée dans le port de sortie, le port ASIC emploiera le cos assigné pour exécuter la manière d'éviter d'encombrement (c'est-à-dire, WRED) et pour employer également le cos pour déterminer l'établissement du programme de la trame (c'est-à-dire, transmettant la trame). En ce moment, le commutateur emploiera une carte par défaut pour prendre le DSCP assigné et pour tracer cela de nouveau à une valeur de cos. Cette carte par défaut est affichée dans cette table.

Alternativement, l'administrateur peut créer une carte qui sera utilisée par le commutateur pour prendre la valeur assignée de DSCP interne et pour créer une nouvelle valeur de cos de la trame. Des exemples de la façon dont vous aviez l'habitude CatOS et Cisco IOS intégré (mode natif) pour réaliser ceci sont affichés ci-dessous.

CatOS

 
Console> (enable) set qos dscp-cos--map 20-30:5 10-15:3 45-52:7 
!-- QoS dscp-cos-map set successfully.
Console> (enable)

La commande ci-dessus trace les valeurs DSCP 20 à 30 à une valeur de cos de 5, les valeurs DSCP 10 à 15 à l'cos de 3, et les valeurs DSCP 45 cependant à 52 à une valeur de cos de 7. Toutes autres valeurs DSCP utilisent la carte par défaut créée quand QoS a été activé sur le commutateur.

La commande émise équivalente dans le Cisco IOS intégré (mode natif) est affichée ci-dessous.

Cisco IOS intégré (mode natif)

 
Cat6500(config)# mls qos map dscp-cos 20 30 40 50 52 10 1 to 3
Cat6500(config)#

Ce valeurs DSCP de positionnements de 20, de 30, de 40, de 50, de 52, de 10, et de 1 à une valeur de cos de 3.

Classification et maintien de l'ordre avec le PFC

Le PFC prend en charge la classification et le maintien de l'ordre des trames. La classification peut employer un ACL pour assigner (marque) une trame entrante avec une priorité (DSCP). Le maintien de l'ordre permet un flot du trafic à limiter à une bande passante.

Les sections suivantes décriront ces capacités sur le PFC de la perspective du CatOS et des Plateformes intégrées de SYSTÈME D'EXPLOITATION de Cisco IOS (mode natif). Les processus appliqués par le PFC sont affichés dans le diagramme suivant :

Configurez le maintien de l'ordre sur la famille du Catalyst 6000 avec CatOS

La fonction du maintien de l'ordre est cassée dans deux sections, une pour CatOS et une pour le Cisco IOS Integrated (mode natif). Chacun des deux réalisent le même résultat final, mais sont configurés et mis en application dans différentes manières.

Maintien de l'ordre

Le PFC prend en charge la capacité au trafic entrant de raté limit (ou police) au commutateur et peut ramener l'écoulement du trafic à une limite de prédéfinis. Trafiquez au-dessus de cette limite peut être relâché ou avoir la valeur DSCP dans la trame marquée vers le bas à une valeur inférieure.

La limitation de débit de sortie (de sortie) n'est pas actuellement prise en charge dans le PFC1 ou le PFC2. Ceci sera ajouté dans une nouvelle révision du PFC prévu pour la deuxième moitié de 2002 qui prendra en charge le maintien de l'ordre de sortie (ou de sortie).

Le maintien de l'ordre est pris en charge dans le CatOS et le nouveau Cisco IOS intégré (mode natif), bien que la configuration de ces caractéristiques soit très différente. Les sections suivantes décriront la configuration du maintien de l'ordre dans des les deux Plateformes de SYSTÈME D'EXPLOITATION.

Agrégats et Microflows (CatOS)

Les agrégats et le Microflows sont des termes utilisés pour définir la portée du maintien de l'ordre que le PFC exécute.

Un microflow définit le maintien de l'ordre d'un à courant simple. Un écoulement est défini par une session avec une seule adresse MAC SA/DA, l'adresse IP SA/DA, et les numéros de port TCP/UDP. Pour chaque nouvel écoulement qui est initié par un port d'un VLAN, le microflow peut être utilisé pour limiter la quantité de données reçues pour cet écoulement par le commutateur. Dans la définition de microflow, les paquets qui dépassent le raté limit prescrit peuvent ou être lâchés ou ont leur valeur DSCP marquée vers le bas.

Semblable à un microflow, un agrégat peut être utilisé au trafic de raté limit. Cependant, le débit global s'applique à tout le trafic d'arrivée sur un port ou un VLAN qui apparie un ACL de QoS spécifié. Vous pouvez visualiser l'agrégat en tant que maintien de l'ordre du trafic cumulatif qui apparie le profil dans l'entrée de contrôle d'accès (ACE).

L'agrégat et le microflow définissent le niveau de trafic qui peut être reçu dans le commutateur. Un agrégat et un microflow peuvent être assignés en même temps à un port ou à un VLAN.

En définissant des microflows, jusqu'à 63 d'entre eux peuvent être définis et jusqu'à 1023 agrégats peuvent être définis.

Entrées de contrôle d'accès et QoS ACLs (CatOS)

Un ACL de QoS se compose d'une liste d'as définissant un ensemble de règles QoS que le PFC l'utilise pour traiter les trames entrantes. Les as sont semblables à une liste de contrôle d'accès de routeur (RACL). ACE définit la classification, le marquage, et maintenir l'ordre des critères d'une trame entrante. Si une trame entrante apparie les critères réglés à ACE, l'engine de QoS traitera la trame (comme considéré par ACE).

Tout le traitement de QoS est fait dans le matériel, ainsi l'activation de la Réglementation QoS n'affecte pas la représentation du commutateur.

Le PFC2 prend en charge actuellement jusqu'à 500 ACLs et ces ACLs peut se composer de jusqu'à 32000 as (au total). Les nombres réels d'ACE dépendront d'autres services définis et de mémoire disponible dans le PFC.

Il y a trois types d'as qui peuvent être définis. Ils sont IP, IPX, et MAC. Les as IP et IPX examinent les informations d'en-tête L3, tandis que les as basés par MAC examinent seulement les informations d'en-tête L2. Il devrait également noter que des as de MAC peuvent seulement être appliqués au trafic non-IP et non-IPX.

Création maintenant l'ordre des règles

Le processus de créer une règle de maintien de l'ordre nécessite de créer un agrégat (ou le microflow), puis le mappage qui agrègent (ou microflow) à ACE.

Si, par exemple, la condition requise était de limiter tout le trafic IP en entrée sur le port 5/3 à un maximum de 20 Mo, les deux étapes mentionnées ci-dessus doivent être configurées.

D'abord, l'exemple invite tout le trafic IP en entrée pour être limité. Ceci implique qu'un régulateur d'agrégation doit être défini. Un exemple de ceci pourrait être comme suit :

 
Console> (enable) set qos policer aggregate test-flow rate 20000 burst 13 policed-dscp  
!-- Hardware programming in progressÝ
!-- QoS policer for aggregate test-flow created successfully.
Console> (enable)

Nous avons créé le test-écoulement appelé par agrégat. Il définit un débit de 20000 KBPS (20MBPS) et une rafale de 13. Le mot clé de maintenir l'ordre-dscp indique que n'importe quelles données dépassant cette stratégie auront sa valeur DSCP marquée vers le bas comme spécifiée dans une carte de baisse de DSCP (par défaut existe ou ceci peut être modifié par l'administrateur). Un remplaçant à utiliser le mot clé de maintenir l'ordre-dscp est d'utiliser le mot clé de baisse. Le mot clé de baisse relâchera simplement tout le trafic hors profil (le trafic qui tombe extérieur la valeur de rafale répartie).

Les travaux de maintien de l'ordre d'installation sur un seau à jetons perméable complotent, du fait vous définissez une rafale (qui est la quantité de données dans des bits par seconde que vous recevrez en intervalle de temps (fixe) donné), et puis le débit (qui est défini comme quantité de données que vous viderez cette position dans une deuxième simple). N'importe quelles données qui débordent cette position ou sont abandonnées ou ont son DSCP marqué vers le bas. La période de temps donnée (ou l'intervalle) mentionné ci-dessus est de 0.00025 seconde (ou 1/4000th d'une seconde) et est réparée (c'est-à-dire, vous ne pouvez utiliser aucune commandes de configuration de changer ce nombre).

Le numéro 13 de l'exemple ci-dessus représente une position qui recevra jusqu'à 13,000 bits de données chaque 1/4000th d'une seconde. Ceci associe à 52 Mo par seconde (13K * (1/0.00025) ou 13K * 4000). Vous devez toujours s'assurer que votre rafale est configurée pour être égale à ou supérieur au débit auquel vous voulez envoyer des données. En d'autres termes, la rafale devrait être supérieur ou égal à la quantité minimum de données que vous souhaitez transmettre pendant une période donnée. Si la rafale a comme conséquence une figure inférieure à ce que vous avez spécifié en tant que votre débit, le raté limit égalera la rafale. En d'autres termes, si vous définissez un débit de 20 MBITS/S et d'une rafale qui calcule à 15MBPS, votre débit obtiendra seulement jamais à 15MBPS. La question suivante que vous pourriez poser est pourquoi 13 ? Souvenez-vous la rafale définit la profondeur du seau à jetons, ou en d'autres termes, la profondeur de la position utilisée pour recevoir des données entrantes chaque 1/4000th d'une seconde. Ainsi, la rafale a pu être tout nombre pris en charge sur un débit de données d'arrivée supérieur ou égal à 20 Mo par seconde. La rafale minimum qu'on pourrait utiliser pour un raté limit de 20MB est 20000/4000 = 5.

En traitant le régulateur, l'algorithme de réglementation commence en remplissant seau à jetons d'armement complet des jetons. Le nombre de jetons égale la valeur de rafale. Ainsi, si la valeur de rafale est 13, le nombre de jetons dans les égaux 13,000 de position. Pour chaque 1/4000th d'une seconde, l'algorithme de réglementation enverra une quantité de données égales au débit défini divisé par 4000. Pour chaque bit (chiffre binaire) des données transmises, il consomme un jeton de la position. À la fin de l'intervalle, il complétera le niveau de la position avec un nouvel ensemble de jetons. Le nombre de jetons qu'il remplace est défini par le débit/4000. Considérez l'exemple ci-dessus pour comprendre ceci :

Console> (enable) set qos policer aggregate test-flow rate 20000 burst 13

Supposez que c'est des 100 MBITS/S mettent en communication et nous introduisons un flux incessant des 100 MBITS/S dans le port. Nous savons que ceci égalisera à un débit d'entrée de 100,000,000 bits par seconde. Les paramètres ici sont un débit de 20000 et rafale de 13. À l'intervalle de temps t0, il y a un armement complet des jetons dans la position (qui est 13,000). À l'intervalle de temps t0, nous ferons arriver le premier ensemble de données dans le port. Pour cet intervalle de temps, le débit d'arrivée sera des bits par seconde de 100,000,000/4000 = 25,000. Car notre seau à jetons a seulement une profondeur de 13,000 jetons, seulement 13,000 bits des 25,000 bits arrivant dans le port dans cet intervalle sont habilités à l'envoi et 12,000 bits sont abandonnés.

Le débit spécifié définit un taux à terme de 20,000,000 bits par seconde, qui égale 5,000 bits envoyés par le 1/4000th intervalle. Pour chaque 5,000 bits envoyés, il y a 5,000 jetons consommés. Au t1 d'intervalle de temps, encore 25,000 bits de données arrivent, mais la position relâche 12,000 bits. La position est complétée le niveau avec des jetons définis comme débit/4000 (qui égale 5,000 nouveaux jetons). L'algorithme envoie alors le prochain complément des données, qui égalent encore 5,000 bits de données (ceci consomme encore 5,000 jetons) et ainsi de suite pour chaque intervalle.

Essentiellement, n'importe quelles données étant livré au-dessus de la profondeur de position (rafale définie) sont abandonnées. Données laissées plus d'après que des données aient été envoyées (assorti indiqué le débit) soient également abandonnées, faisant la manière pour le prochain ensemble de données de arrivée. Un paquet inachevé est un qui n'a pas été entièrement reçu dans l'intervalle de temps n'est pas relâché mais est gardé jusqu'à ce qu'il ait été entièrement reçu dans le port.

Ce nombre de rafale assume un débit constant du trafic. Cependant, dans les véritables réseaux mondiaux, les données ne sont pas constantes et son écoulement est déterminé par les tailles de la fenêtre de TCP, qui incorporent des accusés de réception de TCP dans l'ordre de transmission. Pour prendre en compte les questions des tailles de la fenêtre de TCP, l'il est recommandé que la valeur de rafale soit doublé. Dans l'exemple ci-dessus, la valeur suggérée de 13 serait configurée réellement en tant que 26.

Un autre point important à faire est celui à l'intervalle de temps 0 (c'est-à-dire, le début d'un cycle de maintien de l'ordre), le seau à jetons est plein des jetons.

Cette stratégie d'agrégat doit maintenant être incorporée à un QoS ACE. ACE est où la spécification est faite pour apparier un ensemble de critères à une trame entrante. Considérez l'exemple suivant. Vous voulez appliquer l'agrégat défini ci-dessus à tout le trafic IP, mais spécifiquement pour le trafic originaire du sous-réseau 10.5.x.x et destiné pour le sous-réseau 203.100.45.x. ACE ressemblerait à ce qui suit :

 
Console> (enable) set qos acl ip test-acl trust-dscp aggregate test-flow tcp 10.5.0.0 203.100.45.0  
!-- Test-acl editbuffer modified. Issue the commit command to apply changes.
Console> (enable)

La commande ci-dessus a créé un IP ACE (dénoté en employant la commande d'IP d'acl de set qos), qui est maintenant associé avec un ACL de QoS appelé le test-acl. Des as ultérieurs qui sont créés et associés avec le test-acl d'ACL sont ajoutés à la fin de la liste d'ACE. L'entrée d'ACE a le test-écoulement d'agrégat associé avec elle. Tous les écoulements de TCP avec un sous-réseau de source de 10.5.0.0 et le sous-réseau de destination de 203.100.45.0 auront cette stratégie appliquée à elle.

ACLs (et les as associés) fournissent un niveau très granulaire de la souplesse de configuration que les administrateurs peuvent utiliser. Un ACL peut se composer d'un ou un certain nombre d'as, et la source et/ou des adresses de destination peut être utilisée aussi bien que les valeurs de port L4 pour identifier les flux particuliers qui sont exigés pour être maintenus l'ordre.

Cependant, avant que le maintien de l'ordre se produise réellement, l'ACL doit être tracé à un port physique ou à un VLAN.

PFC2 maintenant l'ordre des décisions

Pour le PFC2, un changement a été fait de CatOS 7.1 et de CatOS 7.2, qui ont introduit un algorithme "leaky bucket" double pour le maintien de l'ordre. Avec ce nouvel algorithme, il ajoute les deux nouveaux niveaux suivants :

    1. Niveau de maintien de l'ordre normal : ceci égalise dans la première position et définit des paramètres spécifiant la profondeur de la position (rafale) et du débit auxquels des données devraient être envoyées de la position (débit).
    2. Niveau de maintien de l'ordre excédentaire : ceci égalise dans une deuxième position et définit des paramètres spécifiant la profondeur de la position (eburst) et du débit auxquels des données devraient être envoyées de la position (erate).

La manière cette des travaux par processus est que les données commencent à compléter la première position. Le PFC2 reçoit un flux de données entrant inférieur ou égal à la profondeur (valeur de rafale) de la première position. Des données qui débordent de la première position peuvent être marquées vers le bas et sont passées dans la deuxième position. La deuxième position peut recevoir un débit d'entrée de données circulant plus de la position une à une valeur inférieur ou égal à la valeur d'eburst. Des données de la deuxième position sont envoyées à un débit défini par le paramètre d'erate sans le paramètre de débit. Des données qui débordent de la deuxième position peuvent également être marquées vers le bas ou abandonnées.

Un exemple d'un double régulateur de saut percé est comme suit :

Console> (enable) set qos policer aggregate AGG1 rate 10000 policed-dscp erate 12000 drop burst 13 eburst 13

Cet exemple place en place un agrégat appelé l'AGG1 avec du débit du trafic au-dessus de 10 MBITS/S, et sera marqué vers le bas selon la carte maintenue l'ordre de DSCP. Le trafic au-dessus de l'erate (placez à 12 MBITS/S) sera abandonné selon le mot clé de baisse.

L'application des régulateurs d'agrégation au DFC a activé des modules

Il convient noter que l'application des régulateurs d'agrégation sur les linecards non-DFC peut être due réalisé à la manière que les 6000 utilise une engine avant centralisée (PFC) pour expédier le trafic. L'implémentation d'une engine d'expédition de central lui permet de maintenir des statistiques de trafic pour un VLAN donné. Ce processus peut être utilisé pour appliquer un régulateur d'agrégation à un VLAN.

Sur un DFC activé le linecard, cependant, expédiant des décisions sont distribués à ce linecard. Le DFC se rend seulement compte des ports sur son linecard immédiat et est inconscient du mouvement du trafic sur d'autres linecards. Pour cette raison, si un régulateur d'agrégation est appliqué à un VLAN qui a des ports membres à travers de plusieurs modules DFC, le régulateur peut produire des résultats contradictoires. La raison pour ceci est que le DFC peut seulement maintenir des statistiques de port local et ne prend pas en considération des statistiques de port sur d'autres linecards. Pour cette raison, un régulateur d'agrégation appliqué à un VLAN avec des ports membres sur un linecard activé par DFC aura comme conséquence le DFC maintenant l'ordre le trafic à la limite évaluée pour des ports VLAN résidents sur le linecard DFC seulement.

Cartes de baisse de DSCP (CatOS)

Des cartes de baisse de DSCP sont utilisées quand le régulateur est défini au trafic hors profil de baisse au lieu de le relâcher. Le trafic hors profil est défini en tant que ce trafic qui dépasse la configuration définie de rafale.

Une carte par défaut de baisse de DSCP est installée quand QoS est activé. Cette carte par défaut de baisse est répertoriée dans cette table plus tôt dans le document. L'interface de ligne de commande (CLI) permet à un administrateur pour modifier la carte par défaut de baisse en émettant la commande de maintenir l'ordre-dscp-MAP de set qos. Un exemple de ceci est affiché ci-dessous.

Cat6500(config)# set qos policed-dscp-map 20-25:7 33-38:3

Cet exemple modifie la carte maintenue l'ordre de DSCP pour refléter que les valeurs DSCP 20 à 25 seront marquées vers le bas à une valeur DSCP de 7, et des valeurs DSCP de 33 à 38 seront marquées vers le bas à une valeur DSCP de 3.

Traçant des stratégies à VLAN et à ports (CatOS)

Une fois qu'un ACL a été construit, il doit alors être tracé à un port ou à un VLAN pour que cet ACL le prenne effet.

Une commande intéressante qui attrape beaucoup d'inconscients est la configuration par défaut de QoS qui fait tout le port de QoS basé. Si vous appliquez un agrégat (ou le microflow) à un VLAN, il ne le prendra pas effet sur un port à moins que ce port ait été configuré pour QoS basé par VLAN.

 
Console> (enable) set port qos 2/5-10 vlan-based  
!-- Hardware programming in progress Ý
!-- QoS interface is set to vlan-based for ports 2/5-10.
Console> (enable)

Changer QoS basé sur port à QoS basé sur VLAN détache immédiatement tout l'ACLs assigné à ce port, et assigne tous les ACL basée sur VLAN à ce port.

La cartographie de l'ACL à un port (ou au VLAN) est faite en émettant la commande suivante :

 
Console> (enable) set qos acl map test-acl 3/5  
!-- Hardware programming in progress Ý
!-- ACL test-acl is attached to port 3/5.
Console> (enable)

Console> (enable) set qos acl map test-acl 18  
!-- Hardware programming in progress Ý
!-- ACL test-acl is attached to VLAN 18.
Console> (enable)

Même après tracer l'ACL à un port (ou à un VLAN), l'ACL ne le prend toujours pas effet jusqu'à ce que l'ACL soit commis au matériel. Ceci est décrit dans la section suivante. En ce moment, l'ACL réside dans un provisoire éditent la mémoire tampon dans la mémoire. Tandis que dans cette mémoire tampon, l'ACL peut être modifié.

Si vous souhaitez retirer n'importe quel ACLs non engagé qui résident dans l'editbuffer, vous émettriez la commande de repositionnement. Cette commande supprime essentiellement l'ACL de la mémoire tampon d'éditer.

 
Console> (enable) rollback qos acl test-acl 
!-- Rollback for QoS ACL test-acl is successful.
Console> (enable)

ACLs de engagement (CatOS)

Pour appliquer l'ACL de QoS que vous avez défini (ci-dessus), l'ACL doit être commise au matériel. Le processus de l'engagement copie l'ACL de la mémoire tampon provisoire sur le matériel PFC. Une fois résident dans la mémoire PFC, la stratégie définie dans l'ACL de QoS peut être appliquée à tout le trafic qui apparie les as

Pour la facilité de la configuration, la plupart des administrateurs émettent une validation toute la commande. Cependant, vous pouvez commettre un ACL spécifique (un de beaucoup) qui peut actuellement résider dans la mémoire tampon d'éditer. Un exemple de la commande de validation est affiché ci-dessous.

 
Console> (enable) commit qos acl test-acl 
!-- Hardware programming in progress Ý
!-- ACL test-acl is  committed to hardware.  
Console> (enable)

Si vous souhaitez retirer un ACL d'un port (ou d'un VLAN), vous devez effacer la carte qui associe cet ACL à ce port (ou à VLAN) en émettant la commande suivante :

 
Console> (enable) clear qos acl map test-acl 3/5  
!-- Hardware programming in progress Ý
!-- ACL test-acl is detached from port 3/5.
Console>(enable)

Configurez le maintien de l'ordre sur la famille du Catalyst 6000 avec le Cisco IOS intégré (le mode natif)

Le maintien de l'ordre est pris en charge avec le Cisco IOS intégré (mode natif). Cependant, la configuration et l'implémentation de la fonction policière est réalisée utilisant des cartes de stratégie. Classes de chaque de stratégie de carte stratégie d'utilisations de plusieurs pour composer une carte de stratégie et ces classes de stratégie peuvent être définies pour différents écoulements de types de trafic.

Classes de carte de stratégie, en filtrant, en ACL basée sur IOS d'utilisation et en déclarations de correspondance de classe pour identifier le trafic à maintenir l'ordre. Une fois le trafic a été identifié, les classes de stratégie peuvent utiliser des régulateurs d'agrégat et de microflow pour s'appliquer les stratégies de maintien de l'ordre à celle le trafic apparié.

Les sections suivantes expliquent la configuration du maintien de l'ordre pour le Cisco IOS Integrated (mode natif) dans beaucoup plus loin le détail.

Agrégats et Microflows (Cisco IOS intégré (mode natif))

Les agrégats et les microflows sont des termes utilisés pour définir la portée du maintien de l'ordre que le PFC exécute. Semblable à CatOS, à agrégats et à microflows sont également utilisés dans le Cisco IOS intégré (mode natif).

Un microflow définit le maintien de l'ordre d'un à courant simple. Un écoulement est défini par une session avec une seule adresse MAC SA/DA, l'adresse IP SA/DA, et les numéros de port TCP/UDP. Pour chaque nouvel écoulement qui est initié par un port d'un VLAN, le microflow peut être utilisé pour limiter la quantité de données reçues pour cet écoulement par le commutateur. Dans la définition de microflow, les paquets qui dépassent le raté limit prescrit peuvent ou être lâchés ou ont leur valeur DSCP marquée vers le bas. Microflows sont appliqué utilisant la commande d'écoulement de police qui fait partie d'une classe de carte de stratégie.

Pour activer le microflow maintenant l'ordre dans le Cisco IOS intégré (mode natif), il doit être activé globalement sur le commutateur. Ceci peut être réalisé en émettant la commande suivante :

Cat6500(config)# mls qos flow-policing

Le maintien de l'ordre de Microflow peut également être appliqué au trafic ponté, qui est le trafic qui n'est pas L3 commutés. Pour permettre au commutateur de prendre en charge le microflow maintenant l'ordre sur le trafic ponté, émettez la commande suivante :

 
Cat6500(config)# mls qos bridged

Cette commande active également le microflow maintenant l'ordre pour le trafic de multidiffusion. Si le trafic de multidiffusion doit avoir un régulateur de microflow appliqué à lui, cette commande (mls qos bridged) doit être activée.

Semblable à un microflow, un agrégat peut être utilisé au trafic de raté limit. Cependant, le débit global s'applique à tout le trafic d'arrivée sur un port ou un VLAN qui apparie un ACL de QoS spécifié. Vous pouvez visualiser l'agrégat en tant que maintien de l'ordre du trafic cumulatif qui apparie un profil défini du trafic.

Il y a deux formes des agrégats qui peuvent être définis dans le Cisco IOS intégré (mode natif), comme suit :

  • par régulateurs d'agrégation d'interface

  • régulateurs d'agrégation Désignés

Par interface des agrégats sont appliqués à une interface individuelle en émettant l'ordre de police dans une classe de carte de stratégie. Ces classes de carte peuvent être appliquées aux plusieurs interfaces, mais le régulateur maintient l'ordre chaque interface séparément. Des agrégats Désignés sont appliqués à un trafic de groupe de ports et de police à travers toutes les interfaces cumulativement. Des agrégats Désignés sont appliqués en émettant la commande de régulateur d'agrégation de mls qos.

En définissant des microflows, jusqu'à 63 d'entre eux peuvent être définis et jusqu'à 1023 agrégats peuvent être définis.

Création maintenant l'ordre des règles (Cisco IOS intégré (mode natif))

Le processus de créer une règle de maintien de l'ordre nécessite de créer un agrégat (ou le microflow) par l'intermédiaire d'une carte de stratégie et puis de relier cette carte de stratégie à une interface.

Considérez le même exemple créé pour le CatOS. La condition requise était de limiter tout le trafic IP en entrée sur le port 5/3 à un maximum de 20 MBITS/S.

D'abord, une carte de stratégie doit être créée. Créez une carte de stratégie nommée le limite-trafic. Ceci est fait comme suit :

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)#

Vous noterez immédiatement que la demande de commutateur change pour refléter que vous êtes dans le mode de configuration pour créer une classe de carte. Souvenez-vous qu'une carte de stratégie peut contenir des plusieurs classes. Chaque classe contient un ensemble distinct d'actions de stratégie qui peuvent être appliquées à différents flux de trafic.

Nous créerons une classe du trafic pour limiter spécifiquement le trafic entrant à 20 MBITS/S. Nous appellerons cette classe limit-to-20. Ceci est affiché ci-dessous.

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)# class limit-to-20
Cat6500(config-pmap-c)#

La demande change de nouveau pour refléter que vous êtes maintenant en configuration de map class (affiché avec - le c à la fin de la demande). Si vous vouliez appliquer le raté limit pour apparier le trafic entrant spécifique, vous pouvez configurer un ACL et s'appliquer ceci au nom de classe. Si vous voulez appliquer la limite de 20 MBITS/S pour trafiquer originaire du réseau 10.10.1.x, émettez l'ACL suivant :

Cat6500(config)# access-list 101 permit ip 10.10.1.0  0.0.0.255 any

Vous pourriez ajouter cet ACL au nom de classe comme suit :

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)# class limit-to-20 access-group 101
Cat6500(config-pmap-c)#

Une fois que vous avez défini votre class map, vous pouvez maintenant définir différents régulateurs à cette classe. Vous pouvez créer des agrégats (utilisant le mot clé de police), ou des microflows (utilisant le mot clé d'écoulement de police). Créez l'agrégat, comme affiché ci-dessous.

 
Cat6500(config)# policy-map limit-traffic
Cat6500(config-pmap)# class limit-to-20 access-group 101
Cat6500(config-pmap-c)# police 20000000 13000 confirm-action transmit exceed-action drop
Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit
Cat6500(config)#

La déclaration de classe ci-dessus (ordre de police) fixe un raté limit de 20000 k (20 MBITS/S) avec une rafale de 52 MBITS/S (13000 x 4000 = 52MB). Si le trafic apparie le profil et est dans la limite évaluée, l'action est de placer par la déclaration de confirmer-action pour transmettre le trafic de dans-profil. Si le trafic est -de-profil (c'est-à-dire, dans notre exemple au-dessus de la limite de Mo 20), la déclaration d'exceed-action est placée pour relâcher le trafic (c'est-à-dire, dans notre exemple tout le trafic au-dessus de 20 Mo est abandonné).

En configurant un microflow, une mesure semblable est prise. Si nous voulions au raté limit tous les écoulements dans un port qui a apparié un class map donné à 200 K chacun, la configuration de cet écoulement serait semblable à ce qui suit :

 
Cat6500(config)# mls qos flow-policing
Cat6500(config)# policy-map limit-each-flow
Cat6500(config-pmap)# class limit-to-200 
Cat6500(config-pmap-c)# police flow 200000 13000 confirm-action transmit exceed-action drop
Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit

Cartes de baisse de DSCP

Des cartes de baisse de DSCP sont utilisées quand le régulateur est défini au trafic hors profil de baisse au lieu de le relâcher. Le trafic hors profil est défini en tant que ce trafic qui dépasse la configuration définie de rafale.

Une carte par défaut de baisse de DSCP est établie quand QoS est activé. Cette carte par défaut de baisse est répertoriée dans cette table. Le CLI permet à un administrateur pour modifier la carte par défaut de baisse en émettant la commande de maintenir l'ordre-dscp-MAP de set qos. Un exemple de ceci est affiché ci-dessous.

 

Cat6500(config)# mls qos map policed-dscp normal-burst 32 to 16

Cet exemple définit une modification à la carte de dscp maintenue l'ordre par par défaut que la valeur DSCP de 32 sera marquée vers le bas à une valeur DSCP de 16. Pour un port avec ce régulateur défini, n'importe quelles données entrantes avec cette valeur DSCP qui fait partie d'un bloc de données au-dessus de la rafale indiquée auront sa valeur DSCP marquée vers le bas à 16.

Traçant des stratégies à VLAN et à ports (Cisco IOS intégré (mode natif))

Une fois qu'une stratégie a été établie, elle doit alors être tracée à un port ou à un VLAN pour que cette stratégie la prenne effet. À la différence du procédé de validation dans CatOS, il n'y a pas équivalent dans le Cisco IOS intégré (mode natif). Quand une stratégie est tracée à une interface, cette stratégie est en vigueur. Pour tracer la stratégie ci-dessus à une interface, émettez la commande suivante :

 
Cat6500(config)# interface fastethernet 3/5
Cat6500(config-if)# service-policy input limit-traffic

Si une stratégie est tracée à un VLAN, pour chaque port dans le VLAN que vous souhaitez la stratégie VLAN pour s'appliquer à, vous devez informer l'interface que QoS est VLAN basé en émettant la commande de mls qos vlan-based.

 
Cat6500(config)# interface fastethernet 3/5
Cat6500(config-if)# mls qos vlan-based
Cat6500(config-if)# exit
Cat6500(config)# interface vlan 100
Cat6500(config-if)# service-policy input limit-traffic

L'interface arrogante 3/5 faisait partie de VLAN 100, la stratégie nommée le limite-trafic qui a été appliqué à VLAN 100 s'appliquerait également pour relier 3/5.

Configurez la classification sur la famille du Catalyst 6000 avec CatOS

Le PFC introduit le soutien de classifier des données utilisant ACLs qui peut visualiser les informations d'en-tête L2, L3, et L4. Pour un SupI, ou IA (sans PFC), la classification est limitée à utiliser les mots clé de confiance sur des ports.

La section suivante décrit les composants de configuration QoS utilisés par le PFC pour la classification dans le CatOS.

Cos à la cartographie de DSCP (CatOS)

Sur le d'entrée au commutateur, une trame aura une valeur DSCP réglée par le commutateur. Si le port est dans un état de confiance, et l'administrateur a utilisé le mot clé de confiance-cos, le positionnement de valeur de cos dans la trame sera utilisé pour déterminer la valeur DSCP réglée de la trame. Comme indiqué précédemment, le commutateur peut assigner des niveaux de service à la trame pendant qu'il transite le commutateur basé sur la valeur de DSCP interne.

Ce mot clé sur une partie du 10/100 plus tôt de modules (WS-X6248 et WS-X6348) n'est pas pris en charge. Pour ces modules, il est recommandé utilisant ACLs pour appliquer des configurations de cos pour des données entrantes.

Quand QoS est activé, le commutateur crée une carte par défaut. Cette carte est utilisée pour identifier la valeur DSCP qui sera placée basée sur la valeur de cos. Ces cartes sont répertoriées dans cette table plus tôt dans le document. Alternativement, l'administrateur peut installer une seule carte. Un exemple de ceci est affiché ci-dessous.

 
Console> (enable) set qos cos-dscp-map 20 30 1 43 63 12 13 8 
!-- QoS cos-dscp-map set successfully.
Console> (enable)

La commande ci-dessus place la carte suivante :

Cos 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Tandis qu'il est très peu probable que la carte ci-dessus serait utilisée dans un réseau de vie réelle, elle sert à donner une idée de ce qui peut être réalisé utilisant cette commande.

Priorité IP à la cartographie de DSCP (CatOS)

Semblable au cos à la carte de DSCP, une trame peut avoir une valeur DSCP déterminée à partir de l'établissement de Priorité IP de paquets entrant. Ceci se produit toujours seulement si le port est placé à faire confiance par l'administrateur, et ils ont utilisé le mot clé de confiance-ipprec.

Quand QoS est activé, le commutateur crée une carte par défaut. Cette carte est mise en référence dans cette table plus tôt dans ce document. Cette carte est utilisée pour identifier la valeur DSCP qui sera placée basée sur la valeur de priorité IP. Alternativement, l'administrateur peut installer une seule carte. Un exemple de ceci est affiché ci-dessous :

 
Console> (enable) set qos ipprec-dscp-map 20 30 1 43 63 12 13 8 
!-- QoS ipprec-dscp-map set successfully.
Console> (enable)

La commande ci-dessus place la carte suivante :

Priorité IP 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Tandis qu'il est très peu probable que la carte ci-dessus serait utilisée dans un réseau de vie réelle, elle sert à donner une idée de ce qui peut être réalisé utilisant cette commande.

Classification (CatOS)

Quand une trame est passée au PFC pour le traitement, le procédé de classification est exécuté sur la trame. Le PFC emploiera un ACL préconfiguré (ou un ACL par défaut) pour assigner un DSCP à la trame. Au sein d'ACE, un de quatre mots clé est utilisé pour assigner une valeur DSCP. Ils sont comme suit :

    1. TRUST-DSCP (IP ACLs seulement)
    2. TRUST-IPPREC (ACL'= s IP seulement)
    3. TRUST-COS (tout l'ACLs excepté l'IPX et le MAC sur un PFC2)
    4. DSCP

Le mot clé TRUST-DSCP suppose que la trame arrivant dans le PFC a déjà une valeur DSCP réglée avant elle écrivant le commutateur. Le commutateur mettra à jour cette valeur DSCP.

Avec TRUST-IPPREC, le PFC dérivera une valeur DSCP du résident existant de valeur de priorité IP dans le domaine de tos. Le PFC emploiera la Priorité IP aux cartes de DSCP pour assigner le DSCP correct. Une carte par défaut est créée quand QoS est activé sur le commutateur. Alternativement, une carte créée par l'administrateur peut être utilisée pour dériver la valeur DSCP.

Semblable à TRUST-IPPREC, le mot clé TRUS-COS demande au PFC pour dériver une valeur DSCP du cos dans l'en-tête de trame. Il y aura également cos à la carte de DSCP (l'un ou l'autre par défaut d'un administrateur a assigné un) pour aider le PFC en dérivant le DSCP.

Le mot clé de DSCP est utilisé quand une trame arrive d'un port non approuvé. Ceci expose une situation intéressante pour dériver le DSCP. En ce moment, le DSCP configuré dans la déclaration d'acl de set qos est utilisé pour dériver le DSCP. Cependant, il est en ce moment où l'ACLs peut être utilisé pour dériver un DSCP pour le trafic basé sur des critères de classification réglés à ACE. Ceci signifie cela à ACE, un peut employer des critères de classification tels que l'adresse d'origine et destination IP, les numéros de port TCP/UDP, les codes d'ICMP, le type IGMP, des nombres du réseau IPX et du protocole, source MAC et des adresses de destination, et Ethertypes (pour le trafic non-IP et non-IPX seulement) pour identifier le trafic. Ceci signifie qu'ACE pourrait être configuré pour assigner une valeur DSCP spécifique pour dire le trafic http au-dessus du trafic FTP.

Considérez l'exemple suivant :

 
Console> (enable) set port qos 3/5 trust untrusted

L'établissement d'un port en tant que non approuvé demandera au PFC d'employer ACE pour dériver le DSCP de la trame. Si ACE est configuré avec des critères de classification, la personne découle de ce port peut être classifiée avec différentes priorités. Les as suivants illustrent ceci :

 
Console> (enable) set qos acl ip abc dscp 32 tcp any any eq http 
Console> (enable) set qos acl ip ABC dscp 16 tcp any any eq ftp

Dans cet exemple, nous avons deux déclarations d'ACE. Le premier identifie n'importe quel écoulement de TCP (le mot clé est utilisé pour identifier la source et le trafic de destination) dont le numéro de port est 80 (80 = HTTP) pour assigner une valeur DSCP de 32. Le deuxième ACE identifie le trafic originaire de n'importe quel hôte et destiné à n'importe quel hôte dont le nombre de port TCP est 21 (FTP) soient assignés une valeur DSCP de 16.

Configurez la classification sur la famille du Catalyst 6000 avec le Cisco IOS intégré (le mode natif)

La section suivante décrit les composants de configuration QoS utilisés pour prendre en charge la classification sur le PFC utilisant le Cisco IOS intégré (mode natif).

Cos à la cartographie de DSCP (Cisco IOS intégré (mode natif))

Sur le d'entrée au commutateur, une trame aura une valeur DSCP réglée par le commutateur. Si le port est dans un état de confiance, et l'administrateur a utilisé le mot clé de confiance-cos de mls qos (sur des ports de GE ou 10/100 de ports sur les linecards WS-X6548), le positionnement de valeur de cos dans la trame sera utilisé pour déterminer la valeur DSCP réglée de la trame. Comme indiqué précédemment, le commutateur peut assigner des niveaux de service à la trame pendant qu'il transite le commutateur basé sur la valeur de DSCP interne.

Quand QoS est activé, le commutateur crée une carte par défaut. Référez-vous à cette table pour des valeurs par défaut. Cette carte est utilisée pour identifier la valeur DSCP qui sera placée basée sur la valeur de cos. Alternativement, l'administrateur peut installer une seule carte. Un exemple de ceci est affiché ci-dessous.

 
Cat6500(config)# mls qos map cos-dscp 20 30 1 43 63 12 13 8
Cat6500(config)#

La commande ci-dessus place la carte suivante :

Cos 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Tandis qu'il est très peu probable que la carte ci-dessus serait utilisée dans un réseau de vie réelle, elle sert à donner une idée de ce qui peut être réalisé utilisant cette commande.

Priorité IP à la cartographie de DSCP (Cisco IOS intégré (mode natif))

Semblable au cos à la carte de DSCP, une trame peut avoir une valeur DSCP déterminée à partir de l'établissement de Priorité IP de paquets entrant. Ceci se produit toujours seulement si le port est placé à faire confiance par l'administrateur, et ils ont utilisé le mot clé de confiance-ipprec de mls qos. Ce mot clé est seulement pris en charge sur des ports de GE et 10/100 de ports sur les linecards WS-X6548. Pour 10/100 des ports o les linecards WS-X6348 et WS-X6248, ACLs devraient être utilisés pour assigner la confiance de Priorité IP aux données entrantes.

Quand QoS est activé, le commutateur crée une carte par défaut. Référez-vous à cette table pour des valeurs par défaut. Cette carte est utilisée pour identifier la valeur DSCP qui sera placée basée sur la valeur de priorité IP. Alternativement, l'administrateur peut installer une seule carte. Un exemple de ceci est affiché ci-dessous.

 
Cat6500(config)# mls qos map ip-prec-dscp 20 30 1 43 63 12 13 8
Cat6500(config)#

La commande ci-dessus place la carte suivante :

Priorité IP 0 1 2 3 4 5 6 7
DSCP 20 30 1 43 63 12 13 8

Tandis qu'il est très peu probable que la carte ci-dessus serait utilisée dans un réseau de vie réelle, elle sert à donner une idée de ce qui peut être réalisé utilisant cette commande.

Classification (Cisco IOS intégré (mode natif))

Quand une trame est passée au PFC, le processus de la classification peut être exécuté pour assigner une nouvelle priorité à une trame entrante. La mise en garde ici est que ceci peut seulement être fait quand la trame est d'un port non approuvé, ou la trame a été classifiée en tant qu'étant non approuvée.

Une action collective de carte de stratégie peut être utilisée à :

    1. Cos de CONFIANCE
    2. PRIORITÉ IP DE CONFIANCE
    3. DSCP DE CONFIANCE
    4. AUCUNE CONFIANCE

Le mot clé de DSCP de CONFIANCE suppose que la trame arrivant dans le PFC a déjà une valeur DSCP réglée avant elle écrivant le commutateur. Le commutateur mettra à jour cette valeur DSCP.

Avec la PRIORITÉ IP de CONFIANCE, le PFC dérivera une valeur DSCP du résident existant de valeur de priorité IP dans le domaine de tos. Le PFC emploiera une Priorité IP à la carte de DSCP pour assigner le DSCP correct. Une carte par défaut est créée quand QoS est activé sur le commutateur. Alternativement, une carte créée par l'administrateur peut être utilisée pour dériver la valeur DSCP.

Semblable pour FAIRE CONFIANCE À LA PRIORITÉ IP, le mot clé de cos de CONFIANCE demande au PFC pour dériver une valeur DSCP du cos dans l'en-tête de trame. Il y aura également cos à la carte de DSCP (l'un ou l'autre par défaut d'un administrateur a assigné un) pour aider le PFC en dérivant le DSCP.

Un exemple de dériver le DSCP d'une priorité existante (DSCP, Priorité IP, ou cos) est affiché ci-dessous.

 
Cat6500(config)# policy-map assign-dscp-value
Cat6500(config-pmap)# class test 
Cat6500(config-pmap-c)# trust COs
Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit
Cat6500(config)#

Le class map ci-dessus dérivera la valeur DSCP du cos dans l'en-tête Ethernet.

L'AUCUNE forme de CONFIANCE du mot clé n'est utilisée quand une trame arrive d'un port non approuvé. Ceci permet à la trame pour avoir une valeur DSCP assignée au cours du processus du maintien de l'ordre.

Considérez l'exemple suivant de la façon dont une nouvelle priorité (DSCP) peut être assignée à différents écoulements entrant dans le PFC utilisant la définition des politiques suivante.

 
Cat6500(config)# access-list 102 permit tcp any any eq http
Cat6500(config)# policy-map new-dscp-for-flow
Cat6500(config-pmap)# class test access-group 102 
Cat6500(config-pmap-c)# no trust 
Cat6500(config-pmap-c)# police 1000 1 confirm-action set-dscp-transmit 24  Cat6500(config-pmap-c)# exit
Cat6500(config-pmap)# exit
Cat6500(config)#

L'exemple ci-dessus affiche ce qui suit :

    1. Un ACL étant créé pour identifier des écoulements de HTTP entrant dans le port.
    2. Une carte de stratégie a appelé le nouveau-dscp-pour-écoulement.
    3. Un class map (test de noms) ce emploie la liste d'accès 102 pour identifier le trafic que ce class map exécutera son action pour.
    4. Le test de class map placera l'état de confiance de la trame entrante à non approuvé et assignera un DSCP de 24 à cet écoulement.
    5. Ce class map limitera également l'agrégat de tous les écoulements de HTTP à un maximum de 1MB.

Policy server ouvert de terrain communal (COPS)

Les COPS est un protocole qui permet à la famille du Catalyst 6000 d'avoir QoS configuré d'un serveur distant. Actuellement, des COPS est seulement pris en charge utilisant CatOS et fait partie de l'architecture d'intserv pour QoS. Il n'y a actuellement aucun soutien (en date de la date de ce document) des COPS en utilisant le Cisco IOS intégré (mode natif). Tandis que le protocole de COPS diffuse les informations de configuration QoS au commutateur, ce n'est pas la source d'informations de configuration QoS. L'utilisation du protocole de COPS exige d'un gestionnaire externe de QoS de héberger les configurations QoS pour le commutateur. Le gestionnaire externe de QoS initiera le pousser de haut en bas de ces configurations au commutateur utilisant le protocole de COPS. Le QoS Policy Manager de Cisco (QPM) est un exemple d'un gestionnaire externe de QoS.

Ce n'est pas l'intention de ce document pour expliquer le fonctionnement de QPM, mais pour expliquer la configuration exigée sur le commutateur pour prendre en charge des configurations QoS externes de l'utilisation de QPM.

Configuration de COPS

Par défaut, le support de COPS est désactivé. Pour utiliser des COPS sur le commutateur, il doit être activé. Ceci peut être réalisé en émettant la commande suivante :

 
Console> (enable) set qos policy-source cops   
!-- QoS policy source for the switch set to COPS.
Console> (enable)

Quand cette commande est initiée, certaines valeurs par défaut de configuration QoS seront originaires du serveur de COPS. Ceux-ci incluent ce qui suit :

    1. Cos pour aligner des mappages
    2. Affectations de seuils de file d'attente d'entrée et de sortie
    3. Affectations de bande passante WRR
    4. Toutes stratégies d'agrégat et de microflow
    5. DSCP aux cartes de cos pour le trafic en sortie
    6. ACLs
    7. Affectations par défaut de cos de port

Quand des configurations QoS sont exécutées utilisant des COPS, il est important de comprendre que l'application de ces configurations est appliquée d'une manière différente. Plutôt que configurant les ports directement, des COPS est utilisés pour configurer le port ASIC. Le port ASIC contrôle typiquement un groupe de ports, ainsi la configuration de COPS est appliquée à travers un certain nombre de ports en même temps.

Le port ASIC qui est configuré est GE ASIC. Sur des linecards de GE, il y a quatre ports par GE (ports 1-4, 5-8, 9-12, 13-16). Sur ces linecards, la configuration de COPS affecte chaque groupe de ports. Sur 10/100 de linecards (comme discuté plus tôt en ce document), il y a deux groupes d'ASIC, de GE et du 10/100 ASIC. Un GE ASIC existe pour quatre 10/100 ASIC. Chaque 10/100 ASIC prend en charge 12 10/100 de ports. Les COPS configure GE ASIC. Ainsi, en s'appliquant la configuration QoS à 10/100 de linecards par l'intermédiaire des COPS, la configuration s'applique à chacun des 48 10/100 ports.

Quand l'activation des COPS que le support en émettant le set qos policy-source attrape la commande, configuration QoS par l'intermédiaire des COPS est appliquée à tous les ASIC dans le châssis de commutateur. Il est possible de s'appliquer la configuration de COPS à la particularité ASIC. Ceci peut être réalisent utilisant la commande suivante :

 
Console> (enable) set port qos 5/4 policy-source cops   
!-- QoS policy source set to COPS for port (s) 5/1-4.
Console> (enable)

Vous pouvez voir de l'application de la commande ci-dessus que cette commande a été émise sur un module de GE pendant que quatre ports étaient affectés par la commande.

Serveurs et noms de domaine de point de décision politique

Les serveurs de point de décision politique (PDPS) sont les gestionnaires externes de stratégie utilisés pour enregistrer les détails de configuration QoS qui sont abaissés au commutateur. Si des COPS est activés sur le commutateur, le commutateur doit être configuré avec l'adresse IP du gestionnaire externe qui fournira des détails de configuration QoS au commutateur. C'est semblable à quand le SNMP est activé et l'adresse IP de SNMP Manager est définie.

La commande d'identifier le PDPS externe est faite utilisant ce qui suit :

 
Console> (enable) set cops server 192.168.1.1 primary
!-- 192.168.1.1 is added to the COPS diff-serv server table as primary server.
!-- 192.168.1.1 is added to the COPS rsvp server table as primary server.
Console> (enable)

La commande ci-dessus identifie le périphérique 192.168.1.1 en tant que serveur primaire de point de décision.

Quand le commutateur communique avec le PDPS, il doit faire partie d'un domaine défini sur le PDPS. Le PDPS parlera seulement aux Commutateurs que faites partie de son domaine défini ainsi le commutateur doit être configuré pour identifier le domaine de COPS auquel il appartient. Ceci est fait en émettant la commande suivante :

 
Console> (enable) set cops domain name remote-cat6k
!-- Domain name set to remote-cat6k.
Console> (enable)

La commande ci-dessus affiche le commutateur comme étant configuré pour faire partie du domaine nommé remote-cat6k. Ce domaine devrait être défini dans QPM et le commutateur devrait être ajouté à ce domaine.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes



Document ID: 24906