Présentation de la réglementation et de la signalisation QoS (Qualité de service) sur Catalyst 3550

Introduction

La fonction de réglementation détermine si le niveau de trafic se trouve dans le profil ou le contrat spécifié et vous permet soit d'abandonner le trafic hors profil, soit de le marquer à une valeur DSCP (Differential Services Code Point) différente. Ceci impose un niveau de service contracté.

DSCP est une mesure du niveau de qualité de service (QoS) du paquet. Outre le DSCP, la priorité IP et la classe de service (CoS) sont également utilisées afin de transmettre le niveau de QoS du paquet.

La réglementation ne doit pas être confondue avec le formatage du trafic, bien que les deux s'assurent que le trafic reste dans le profil ou le contrat.

La réglementation ne met pas le trafic en mémoire tampon, donc elle n'affecte pas le délai de transmission. Au lieu de mettre en mémoire tampon les paquets hors profil, la réglementation les supprime ou les marque avec différents niveaux de QoS (marquage DSCP).

Le formatage du trafic met en mémoire tampon le trafic hors profil et lisse les rafales de trafic, mais affecte le délai et la variation de délai. La mise en forme ne peut être appliquée que sur l'interface sortante, tandis que la réglementation peut être appliquée à la fois sur l'interface entrante et sur l'interface sortante.

Le Catalyst 3550 prend en charge la réglementation pour les directions entrantes et sortantes. Le formatage du trafic n'est pas pris en charge.

Le marquage modifie le niveau de QoS du paquet en fonction d'une stratégie.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Versions matérielles et logicielles

La réglementation et le marquage sur le Catalyst 3550 sont pris en charge avec toutes les versions logicielles. Le guide de configuration le plus récent est répertorié ici. Reportez-vous à cette documentation pour connaître toutes les fonctionnalités prises en charge.

• Configuration QoS

Paramètres de marquage et de réglementation QoS

Pour configurer la réglementation, vous devez définir les mappages de stratégie QoS et les appliquer aux ports. On parle alors de QoS basée sur les ports.

Remarque :  La qualité de service basée sur VLAN n'est actuellement pas prise en charge par le Catalyst 3550.

Le régulateur est défini par des paramètres de débit et de rafale, ainsi que par une action pour le trafic hors profil.

Ces deux types de régulateurs sont pris en charge :

• Agrégat

• Individu

Le régulateur d'agrégation agit sur le trafic dans toutes les instances où il est appliqué. Le régulateur individuel agit séparément sur le trafic à travers chaque instance où il est appliqué.

Remarque : sur le Catalyst 3550, le régulateur d'agrégation ne peut être appliqué qu'à différentes classes de la même stratégie. La réglementation d'agrégation sur plusieurs interfaces ou stratégies n'est pas prise en charge.

Par exemple, appliquez le régulateur d'agrégation afin de limiter le trafic de la classe customer1 et de la classe customer2 dans le même policy-map à 1 Mbits/s. Un tel régulateur autorise un trafic de 1 Mbits/s en classe client1 et client2 ensemble. Si vous appliquez le régulateur individuel, le régulateur limite le trafic pour la classe customer1 à 1 Mbits/s et pour la classe customer2 à 1 Mbits/s. Par conséquent, chaque instance du régulateur est distincte.

Ce tableau résume l'action QoS sur le paquet lorsqu'il est traité par les politiques d'entrée et de sortie :

Remarque : il est possible de marquer et de baliser dans la même classe de trafic de la même stratégie. Dans ce cas, tout le trafic de la classe particulière est marqué en premier. La réglementation et la démarcation se produisent sur le trafic déjà marqué.

La réglementation QoS du Catalyst 3550 est conforme à ce concept de « leaky bucket » :

Le nombre de jetons proportionnel aux tailles de paquets de trafic entrant sont placés dans un compartiment de jetons ; le nombre de jetons est égal à la taille du paquet. À intervalles réguliers, un nombre défini de jetons dérivés du débit configuré est supprimé du compartiment. S'il n'y a pas d'emplacement dans le compartiment pour recevoir un paquet entrant, le paquet est considéré comme hors profil et est abandonné ou marqué vers le bas selon l'action de réglementation configurée.

Ce concept est illustré dans cet exemple :

Remarque : le trafic n'est pas mis en mémoire tampon dans le compartiment, comme cela peut apparaître dans cet exemple. Le trafic réel ne traverse pas du tout le compartiment ; le bucket est uniquement utilisé pour décider si le paquet est dans le profil ou hors profil.

Remarque : la mise en oeuvre matérielle de la réglementation peut varier, mais elle est tout de même conforme à ce modèle.

Ces paramètres contrôlent le fonctionnement de la réglementation :

• Débit - définit combien de tokens sont supprimés à chaque intervalle. Ceci définit effectivement le débit de réglementation. Tout le trafic inférieur au débit est considéré dans le profil. Les débits pris en charge vont de 8 Kbits/s à 2 Gbits/s et augmentent de 8 Kbits/s.

• Intervalle - définit à quelle fréquence les tokens sont supprimés du compartiment. L'intervalle est fixé à 0,125 millisecondes (ou 8 000 fois par seconde). Cet intervalle ne peut pas être modifié.

• Rafale : définit la quantité maximale de jetons que le compartiment peut contenir à tout moment. Les rafales prises en charge sont comprises entre 8 000 et 2000000 octets et sont incrémentées de 64 octets.

Remarque : bien que les chaînes d'aide de la ligne de commande affichent une large plage de valeurs, l'option rate-bps ne peut pas dépasser la vitesse de port configurée et l'option burst-byte ne peut pas dépasser 2000000 octets. Si vous entrez une valeur plus élevée, le commutateur rejette la carte de stratégie lorsque vous l'associez à une interface.

Afin de maintenir le débit de trafic spécifié, la rafale ne doit pas être inférieure à la somme de cette équation :

Burstmin (bits) = Rate (bps) / 8000 (1/sec) 

Par exemple, calculez la valeur de rafale minimale afin de maintenir un débit de 1 Mbits/s. Le débit étant défini sur 1 000 Kbits/s, la rafale minimale requise est la somme de cette équation :

1000 (Kbps) / 8000 (1/sec) =125 (bits) 

La taille de rafale minimale prise en charge est de 8 000 octets, ce qui est supérieur à la taille de rafale minimale calculée.

Remarque : en raison de la granularité de la réglementation matérielle, le débit exact et la rafale sont arrondis à la valeur prise en charge la plus proche.

Lorsque vous configurez le débit en rafale, vous devez tenir compte du fait que certains protocoles implémentent des mécanismes qui réagissent à la perte de paquets. Par exemple, le protocole TCP (Transmission Control Protocol) réduit la fenêtre de moitié pour chaque paquet perdu. Cela entraîne un effet de « dents de scie » dans le trafic TCP lorsque TCP tente d'accélérer jusqu'au débit de ligne et est limité par le régulateur. Si le débit moyen du trafic en dents de scie est calculé, ce débit est beaucoup plus faible que le débit réglementé. Cependant, vous pouvez augmenter la rafale afin d'obtenir une meilleure utilisation. Un bon point de départ consiste à définir la rafale comme étant égale au double de la quantité de trafic envoyée avec le débit souhaité pendant le temps de parcours aller-retour (TCP RTT). Si RTT n'est pas connu, vous pouvez doubler la valeur du paramètre de rafale.

Pour la même raison, il n'est pas recommandé de comparer le fonctionnement du régulateur au trafic orienté connexion. Ce scénario affiche généralement des performances inférieures à celles autorisées par le régulateur.

Le trafic non orienté connexion peut également réagir différemment à la réglementation. Par exemple, NFS (Network File System) utilise des blocs, qui peuvent être constitués de plusieurs paquets UDP (User Datagram Protocol). Un paquet abandonné peut déclencher la retransmission de nombreux paquets, même du bloc entier.

Cet exemple calcule la rafale pour une session TCP avec un débit de réglementation de 64 Kbits/s et, étant donné que le RTT TCP est de 0,05 seconde :

<burst> = 2*  *  = 2 * 0.05 [sec] * 64000/8 [bytes/sec] = 800    [bytes] 

Dans cet exemple, <burst> est pour une session TCP. Mettez cette figure à l'échelle pour calculer la moyenne du nombre attendu de sessions transitant par le régulateur.

Remarque : il s'agit d'un exemple uniquement. Dans chaque cas, vous devez évaluer les exigences et le comportement du trafic et des applications par rapport aux ressources disponibles afin de choisir les paramètres de réglementation.

L'action de réglementation peut consister soit à abandonner le paquet, soit à modifier le DSCP du paquet (markdown). Afin de baliser le paquet, une carte DSCP réglementée doit être modifiée. Un mappage DSCP réglementé par défaut signale le paquet au même DSCP. Par conséquent, aucune démarcation ne se produit.

Les paquets peuvent être envoyés dans le désordre lorsqu'un paquet hors profil est marqué sur un DSCP mappé dans une file d'attente de sortie différente du DSCP d'origine. Si l'ordre des paquets est important, balisez les paquets hors profil vers le DSCP mappé à la même file d'attente de sortie que les paquets dans profil.

Fonctions de marquage et de réglementation prises en charge par le Catalyst 3550

Ce tableau récapitule les fonctions de réglementation et de marquage prises en charge par le Catalyst 3550, ventilées par direction :

Une instruction de correspondance est prise en charge par class-map. Voici des instructions de correspondance valides pour la stratégie d'entrée :

• match access-group

• match ip dscp

• match ip precedence

Remarque : sur Catalyst 3550, la commande match interface n'est pas prise en charge et une seule commande match est autorisée dans une carte-classe. Par conséquent, il est difficile de classer tout le trafic entrant par une interface et de contrôler tout le trafic avec un seul régulateur. Reportez-vous à la section How to Classify All Interface Traffic with a Single Policer de ce document.

Il s'agit de l'instruction de correspondance valide pour la stratégie de sortie :

• match ip dscp

Voici des actions de stratégie valides pour la stratégie d'entrée :

• police

• set ip dscp (marquage)

• set ip precedence (marquage)

• trust dscp

• trust ip-precedence

• TRUST CO

Ce tableau présente la matrice des stratégies QoS d'entrée prises en charge :

1. Cette option couvre également la priorité IP correspondante.

2. Cette option couvre la CoS de confiance, la priorité IP et le DSCP.

3. Cette option couvre également la définition de la priorité IP.

Il s'agit de l'action de stratégie valide pour la stratégie de sortie :

• police

Ce tableau présente la matrice des stratégies QoS de sortie prises en charge :

Le marquage permet de modifier le niveau de qualité de service du paquet en fonction de sa classification ou de sa réglementation. La classification divise le trafic en différentes classes pour le traitement QoS en fonction des critères définis.

Le traitement QoS est basé sur le DSCP interne ; mesure du niveau de qualité de service du paquet. Le DSCP interne est dérivé en fonction de la configuration d'approbation. Le système prend en charge les protocoles CoS, DSCP, la priorité IP et les interfaces non approuvées. Trust spécifie le champ à partir duquel le DSCP interne est dérivé pour chaque paquet, comme suit :

• Lors de l'approbation de CoS, le niveau de QoS est dérivé de l'en-tête de couche 2 (L2) du protocole ISL (Inter-Switch Link Protocol) ou du paquet encapsulé 802.1Q.

• Lors de l'approbation de la priorité DSCP ou IP, le système déduit le niveau de QoS du champ de priorité DSCP ou IP du paquet en conséquence.

L'approbation de CoS n'a de sens que sur les interfaces d'agrégation, et l'approbation de DSCP (ou priorité IP) n'a de sens que pour les paquets IP.

Lorsqu'une interface n'est pas approuvée, le DSCP interne est dérivé de la CoS par défaut configurable pour l'interface correspondante. Il s'agit de l'état par défaut lorsque QoS est activé. Si aucune CoS par défaut n'est configurée, la valeur par défaut est zéro.

Une fois le DSCP interne déterminé, il peut être modifié par marquage et réglementation, ou conservé.

Une fois que le paquet a subi le traitement QoS, ses champs de niveau QoS (dans le champ IP/DSCP pour IP et dans l'en-tête ISL/802.1Q, le cas échéant) sont mis à jour à partir du DSCP interne. Il existe ces cartes QoS spéciales pertinentes pour la réglementation :

• DSCP-to-Policed DSCP : utilisé pour dériver le DSCP réglementé lorsque vous démarquez le paquet.

• DSCP-to-CoS : utilisé afin de dériver le niveau CoS du DSCP interne pour mettre à jour l'en-tête du paquet sortant ISL/802.1Q.

• CoS-to-DSCP : utilisé pour dériver le DSCP interne à partir du CoS entrant (en-tête ISL/802.1Q) lorsque l'interface est en mode CoS approuvé.

Il s'agit de considérations importantes spécifiques à la mise en oeuvre :

• La stratégie de service d'entrée ne peut pas être attachée à l'interface lorsque celle-ci est configurée pour faire confiance à l'une des métriques de QoS, telles que CoS/DSCP ou la priorité IP. Afin de faire correspondre la priorité DSCP/IP et la police en entrée, vous devez configurer la confiance pour la classe particulière au sein de la politique, et non sur l'interface. Pour marquer en fonction de la priorité DSCP/IP, aucune approbation ne doit être configurée.

• Seul le trafic IPv4 sans options IP et l'encapsulation ARPA (Advanced Research Projects Agency) Ethernet II sont considérés comme du trafic IP du point de vue du matériel et de la qualité de service. Tout autre trafic est considéré comme non IP, y compris IP avec des options, telles que le protocole SNAP (SubNetwork Access Protocol), IP encapsulé et IPv6.

• Pour les paquets non IP, « match access group » est la seule méthode de classification, car vous ne pouvez pas faire correspondre DSCP pour le trafic non IP. Une liste d'accès MAC (Media Access Control) est utilisée à cette fin ; Les paquets peuvent être mis en correspondance en fonction de l'adresse MAC source, de l'adresse MAC de destination et de l'EtherType. Il n'est pas possible de faire correspondre le trafic IP avec la liste de contrôle d'accès MAC, car le commutateur fait une distinction entre le trafic IP et le trafic non IP.

Configuration et surveillance de la réglementation

Les étapes suivantes sont nécessaires pour configurer la réglementation dans Cisco IOS :

1. Définir un régulateur (pour les régulateurs agrégés)

2. Définir les critères de sélection du trafic pour la réglementation

3. Définir une carte-classe pour sélectionner le trafic à l'aide de critères définis

4. Définir une politique de service à l'aide de class et appliquer un régulateur à la classe spécifiée

5. Appliquer une politique de service à un port

Ces deux types de régulateurs sont pris en charge :

• Agrégat nommé

• Individu

Le régulateur d'agrégation nommé gère le trafic combiné de toutes les classes au sein de la même stratégie, jusqu'à l'endroit où il est appliqué. La réglementation d'agrégation entre différentes interfaces n'est pas prise en charge.

Remarque : le régulateur d'agrégation ne peut pas être appliqué à plusieurs stratégies. Si c'est le cas, ce message d'erreur s'affiche :

QoS: Cannot allocate policer for policy map <policy name>

Considérez cet exemple :

Un générateur de trafic connecté au port GigabitEthernet0/3 envoie environ 17 Mbits/s de trafic UDP avec le port de destination 111. Il y a également du trafic TCP en provenance du port 20. Vous voulez que ces deux flux de trafic soient régulés à 1 Mbits/s, et un trafic excessif doit être abandonné. Cet exemple montre comment cela se fait :

!--- Globally enables QoS.

mls qos

!--- Defines the QoS policer, sets the burst !--- to 16000 for better TCP performance.

mls qos aggregate-policer pol_1mbps 1000000 16000 exceed-action drop

!--- Defines the ACLs to select traffic.

access-list 123 permit udp any any eq 111
access-list 145 permit tcp any eq 20 any

!--- Defines the traffic classes to be policed.

class-map match-all cl_udp111
  match access-group 123
class-map match-all cl_tcp20
  match access-group 145

!--- Defines the QoS policy, and attaches !--- the policer to the traffic classes.

policy-map po_test
  class cl_udp111	
    police aggregate pol_1mbps 
  class cl_tcp20
    police aggregate pol_1mbps 

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test
!

Le premier exemple utilisait le régulateur d'agrégation nommé. Contrairement au contrôleur nommé, le contrôleur individuel gère le trafic séparément sur chaque classe où il est appliqué. Le régulateur individuel est défini dans la configuration du mappage de stratégie. Dans cet exemple, deux classes de trafic sont contrôlées par deux contrôleurs individuels ; cl_udp11 est régulé à 1 Mbit/s par rafale de 8 000 tr/min et cl_tcp20 à 512 Kbit/s par rafale de 32 000 tr/min :

!--- Globally enables QoS.

mls qos

!--- Defines the ACLs to select traffic.

access-list 123 permit udp any any eq 111
access-list 145 permit tcp any eq 20 any

!--- Defines the traffic classes to be policed.

class-map match-all cl_udp111
  match access-group 123
class-map match-all cl_tcp20
  match access-group 145

!--- Defines QoS policy, and creates and attaches !--- the policers to the traffic classes.

policy-map po_test2
  class cl_udp111	
    police 1000000 8000 exceed-action drop
  class cl_tcp20
    police 512000 32000 exceed-action drop

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test2

Cette commande est utilisée afin de surveiller l'opération de réglementation :

cat3550#show mls qos interface g0/3 statistics 
GigabitEthernet0/3
Ingress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
Others: 267718     0          267717     0          0         
Egress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
Others: 590877        n/a       n/a      266303     0         

WRED drop counts:
  qid  thresh1    thresh2   FreeQ
   1 : 0          0         1024      
   2 : 0          0         1024      
   3 : 0          0         8         
   4 : 0          0         1024

Remarque : par défaut, il n'existe aucune statistique par DSCP. Le Catalyst 3550 prend en charge une collecte de statistiques par interface et par direction pour un maximum de huit valeurs DSCP différentes. Cette option est configurée lorsque vous émettez la commande mls qos monitor. Afin de surveiller les statistiques pour les DSCP 8, 16, 24 et 32, vous devez émettre cette commande per-interface :

cat3550(config-if)#mls qos monitor dscp 8 16 24 32

Remarque : la commande mls qos monitor dscp 8 16 24 32 modifie le résultat de la commande show mls qos int g0/3 statistics comme suit :

cat3550#show mls qos interface g0/3 statistics
GigabitEthernet0/3
Ingress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
    8 : 0          0          675053785  0          0         
    16: 1811748    0          0          0          0         ? per DSCP statistics 
    24: 1227820404 15241073   0          0          0         
    32: 0          0          539337294  0          0         
Others: 1658208    0          1658208    0          0         
Egress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
    8 : 675425886     n/a       n/a      0          0         
    16: 0             n/a       n/a      0          0         ? per DSCP statistics
    24: 15239542      n/a       n/a      0          0         
    32: 539289117     n/a       n/a      536486430  0         
Others: 1983055       n/a       n/a      1649446    0         

WRED drop counts:
  qid  thresh1    thresh2   FreeQ
   1 : 0          0         1024      
   2 : 0          0         1024      
   3 : 0          0         6         
   4 : 0          0         1024

Voici une description des champs de l'exemple :

• Incoming : indique le nombre de paquets arrivant de chaque direction

• NO_change : indique le nombre de paquets approuvés (comme le niveau de QoS non modifié)

• Classifié : indique le nombre de paquets auxquels ce DSCP interne a été affecté après classification

• Contrôlé : indique combien de paquets ont été marqués par la réglementation ; DSCP affiché avant le balisage.

• Abandonné : indique le nombre de paquets abandonnés par la réglementation

Tenez compte de ces considérations spécifiques à la mise en oeuvre :

• Si huit valeurs DSCP sont configurées lorsque vous émettez la commande mls qos monitor, le compteur des autres vues lorsque vous émettez la commande show mls qos int statistics peut afficher des informations inadéquates.

• Il n'y a pas de commande spécifique afin de vérifier le débit de trafic offert ou sortant par régulateur.

• Étant donné que les compteurs sont récupérés séquentiellement à partir du matériel, il est possible que les compteurs ne s'additionnent pas correctement. Par exemple, la quantité de paquets contrôlés, classés ou abandonnés peut être légèrement différente du nombre de paquets entrants.

Configurer et surveiller le marquage

Ces étapes sont nécessaires pour configurer le marquage :

1. Définir les critères de classification du trafic

2. Définir les classes de trafic à classer avec les critères précédemment définis

3. Créer une carte de stratégie qui associe des actions de marquage et de réglementation aux classes définies

4. Configurez la ou les interfaces correspondantes en mode d’approbation

5. Appliquer le mappage de stratégie à une interface

Dans cet exemple, vous voulez que le trafic IP entrant vers l'hôte 192.168.192.168 soit marqué avec la priorité IP 6 et réglementé jusqu'à 1 Mbits/s ; le trafic excédentaire doit être marqué en priorité IP 2 :

!--- Globally enables QoS.

mls qos

!--- Defines the ACLs to select traffic.

access-list 167 permit ip any host 192.168.192.168

!--- Defines the traffic class.

class-map match-all cl_2host
  match access-group 167

!--- Defines QoS policy, and creates and attaches !--- the policers to the traffic classes.

policy-map po_test3
  class cl_2host

!--- Marks all the class traffic with the IP precedence 6.

    set ip precedence 6

!--- Polices down to 1 Mbps and marks down according to the QoS map.

    police 1000000 8000 exceed-action policed-dscp-transmit

!--- Modifies the policed DSCP QoS map, so the !--- traffic is marked down from IP precedence 6 to 2. !--- In terms of DSCP, this is from 48 to 16 (DSCP=IPprec x8).

mls qos map policed-dscp  48 to 16

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test3

La même commande show mls qos interface statistics est émise afin de surveiller le marquage. Des exemples de résultats et d'implications sont documentés dans la section de ce document.

Comment classer tout le trafic d'interface avec un seul régulateur

Sur le Catalyst 3550, la commande match interface n'est pas prise en charge, et une seule commande match est autorisée par class-map. En outre, le Catalyst 3550 ne permet pas au trafic IP d'être mis en correspondance par les ACL MAC. Le trafic IP et non IP doit donc être classé avec deux cartes de classe distinctes. Cela complique la classification de tout le trafic entrant dans une interface et la régulation de tout le trafic avec un seul régulateur. L'exemple de configuration ci-dessous vous permet d'accomplir ceci. Dans cette configuration, le trafic IP et le trafic non IP sont mis en correspondance avec deux cartes de classe différentes. Cependant, chacun utilise un régulateur commun pour les deux trafics.

access-list 100 permit ip any any

class-map ip
match access-group 100

!--- This class-map classifies all IP traffic.


mac access-list extended non-ip-acl
permit any any

class-map non-ip
match access-group name non-ip-acl

!--- Class-map classifies all non-IP traffic only. 


mls qos aggregate-policer all-traffic 8000 8000 exceed-action drop

!--- This command configures a common policer that is applied for both IP and non-IP traffic.


policy-map police-all-traffic
class non-ip
police aggregate all-traffic
class ip
police aggregate all-traffic

interface gigabitEthernet 0/7
service-policy input police-all-traffic

!--- This command applies the policy map to the physical interface.

 

Informations connexes

• Configuration de la QoS sur Catalyst 3550
• Pages d'assistance Qualité de service
• Page de support sur la commutation LAN
• Pages de support pour les produits LAN
• Assistance et documentation techniques - Cisco Systems