JMJ QoS Cisco - jm-jurkiewicz.net · JMJ Page Reference QoS Cisco V0.0 9/68 JMJ 2 Convention de...

JMJ QoS Cisco

QoS sur switchs 3750 – 3560 0.00

Auteur(s): Jean-Marc Jurkiewicz Date: 30 avril 2013 Version: 0.00 Status: Draft Reference: QoS_Cisco-V00

JMJ Reference QoS Cisco V0.0

/68

JMJ

Liste d’approbation et de distribution

Approbation Nom/Fonction Date

Fonction Nom

Fonction Nom

Fonction Nom

Liste de distribution Nom/Fonction Date

Fonction Nom


/68

JMJ

Historique du document Version Date Raison du changement 0.00 30 avril 2013 Version initiale


/68

JMJ

Table des matières

1 GLOSSAIRE ............................................................................................................ 8

2 CONVENTION DE STYLE ........................................................................................ 9

3 OBJECTIFS ............................................................................................................ 9

4 AUDIENCE .............................................................................................................. 9

4.1 PRÉ-REQUIS ............................................................................................................... 9

5 DÉFINITIONS ET VOCABULAIRE .......................................................................... 10

5.1 TOS BIT DE L’ENTETE D’UN PAQUET IP ........................................................................... 10 5.2 TABLE COMPLÈTE TOS-IP PRECEDENCE - DSCP ............................................................ 11 5.3 PROBABILITÉ DE REJET ............................................................................................... 13

6 LA QOS SUR UN SWITCH CISCO ........................................................................... 14

6.1 INTRODUCTION .......................................................................................................... 14 6.2 LA QOS SUR UN SWITCH CISCO : RESUME ...................................................................... 14 6.3 PAR DEFAUT ............................................................................................................. 16

6.3.1 Show mls qos .................................................................................................... 16 6.4 ACTIVATION DE LA QOS .............................................................................................. 16 6.5 LES FONCTIONS IMPARTIES A LA QOS ............................................................................. 17 6.6 FONCTIONS QOS SUR LE TRAFIC ENTRANT ...................................................................... 18

6.6.1 Par défaut ......................................................................................................... 18 6.6.2 Classification et marquage ................................................................................ 19

6.6.2.1 Port / interface ........................................................................................ 19 6.6.2.1.1.1 Classification – Port Trust ............................................................. 19

6.6.3 Classification et marquage du traffic entrant : Hic et Nunc ................................. 25 6.6.3.1 Avec limitation de bande passante ............................................................ 26

6.6.3.1.1 police 10000000 8000 ........................................................................ 27 6.6.3.1.1.1 Tocken Bucket ou seau à jeton ..................................................... 27

6.6.3.1.2 Déclassification .................................................................................. 28 6.6.4 Eviter et gerer de la congestion .......................................................................... 29

6.6.4.1 Files d’attente en entrée ........................................................................... 30 6.6.4.1.1 Configuration par défaut ..................................................................... 30

6.6.4.1.1.1 Quels CoS vers quelle file ? ........................................................... 30 6.6.4.1.1.2 Quels DSCP vers quelle file ? ........................................................ 30 6.6.4.1.1.3 A partir de quand y a-t-il rejet de paquets ? ................................... 31 6.6.4.1.1.4 Taille des files d’attente ? .............................................................. 31 6.6.4.1.1.5 Bande passante allouée à la file d’attente prioritaire ? ................... 31 6.6.4.1.1.6 Bandes passantes allouées à chacune des files d’attente ? ............. 32 6.6.4.1.1.7 Seuils de rejet ............................................................................... 34

6.6.5 File d’attente d’entrée par interface physique ..................................................... 36 6.7 FONCTIONS QOS SUR LE TRAFFIC SORTANT ..................................................................... 38

6.7.1 Sans QoS .......................................................................................................... 40 6.7.2 Files d’attente de sortie ..................................................................................... 40

6.7.2.1 Assignation d’une file de sortie en fonction du QoS Label .......................... 40 6.7.2.2 Assignation d’une taille aux files de sortie ................................................. 41 6.7.2.3 Seuils de rejet .......................................................................................... 43 6.7.2.4 Assignation d’un des deux jeux de file d’attente à une interface ................. 44 6.7.2.5 Ordonnanceur de sortie. (SRR) ................................................................. 44

6.7.2.5.1 Limit .................................................................................................. 44 6.7.2.5.2 Shape ................................................................................................. 44 6.7.2.5.3 Share ................................................................................................. 45


/68

JMJ

6.7.2.5.4 File prioritaire..................................................................................... 46 6.7.3 Configuration par défaut. Représentation graphique .......................................... 47

6.7.3.1 Considérations chiffrées ........................................................................... 53 6.7.3.1.1 Hold queue ......................................................................................... 53

6.8 COMMANDES UTILES .................................................................................................. 55 6.8.1 QoS active ? ...................................................................................................... 55 6.8.2 Quel CoS vers quelle file d’entrée ....................................................................... 55 6.8.3 Quel DSCP vers quelle file d’entrée .................................................................... 55 6.8.4 Taille, bande passante et seuils des files d’entrés ............................................... 55 6.8.5 Comment est configurée une interface donnée ................................................... 55 6.8.6 Configuration de l’équipement pour une interface donnée .................................. 56 6.8.7 Quel CoS vers quelle file de sortie ...................................................................... 57 6.8.8 Quel DSCP vers quelle file de sortie ................................................................... 57 6.8.9 Comment sont configurées les files d’attente de sortie par jeu ............................ 58 6.8.10 Quel jeu pour quelle interface .......................................................................... 58 6.8.11 SRR en sortie pour une interface donnée ......................................................... 59 6.8.12 Rejets pour une interface donnée. Par file d’attente .......................................... 59 6.8.13 Rejets par interface. Rejets globaux ................................................................. 60 6.8.14 Distibution des paquets émis et recus en fonction des DSCP ............................ 60

7 SRR ...................................................................................................................... 64

8 FILE D’ATTENTE .................................................................................................. 65

9 CISCO IP PHONE .................................................................................................. 66

10 LIENS ................................................................................................................ 67

11 RECOMMANDATIONS CISCO ............................................................................. 68


/68

JMJ

Table des figures

FIGURE 1: FONCTIONS IMPARTIES À LA QOS SUR UN SWITCH 3750 CISCO .............. 17

FIGURE 2: CLASSIFICATION ET MARQUAGE BASÉES PORT ....................................... 19

FIGURE 3: UTILISATEUR « MALIN » PRIORISANT SON TRAFIC ................................... 23

FIGURE 4: TÉLÉPHONE EN TANT QUE FILTRE DE COS .............................................. 24

FIGURE 5: PC « MALIN » DIRECTEMENT CONNECTÉ AU SWITCH ............................... 24

FIGURE 6: FILE D’ATTENTE, REJET ET ORDONNANCEMENT PAS DÉFAUT ............... 33

FIGURE 7: SRR : SEUILS DE REJETS VS REMPLISSAGE DE LA FILE .......................... 35

FIGURE 8: WRED : SEUILS DE REJETS VS REMPLISSAGE DE LA FILE ....................... 36

FIGURE 9: FONCTIONS QOS SUR LE TRAFFIC SORTANT ........................................... 38

FIGURE 10: ALLOCATIONS DES TAMPONS AUX FILES D’ATTENTE DE SORTIE ......... 39

FIGURE 11: FILES D’ATTENTE DE SORTIE - 1 ........................................................... 48

FIGURE 12: FILE D’ATTENTE DE SORTIE - 3 ............................................................. 50

FIGURE 13: SRR VERSUS WRR ................................................................................... 64

Table des tableaux

TABLE 1: TOS BIT DE L’ENTÊTE D’UN PAQUET IP ..................................................... 10

TABLE 2: VALEUR HÉXADÉCIMALE DES DSCP CODÉS SUR 6 BITS ........................... 10

TABLE 3: VALEUR HEXADÉCIMALE DES DSCP CODÉS SUR 6 BITS : EXEMPLE ......... 10

TABLE 4: VALEUR HEXADÉCIMALE DES DSCP CODÉS SUR 6 BITS “À LA CISCO” ..... 10

TABLE 5: COS-IP PRECEDENCE - DSCP ...................................................................... 13

TABLE 6: DROP PROBABILITY ................................................................................... 13

TABLE 7: TABLE DE CORRESPONDANCE PAR DÉFAUT COS-DSCP. ............................ 18

TABLE 8: FILE D’ATTENTE, REJET ET ORDONNANCEMENT PAS DÉFAUT ................. 33

TABLE 9: SEUILS DE REJETS PAR DÉFAUT ............................................................... 43


/68

JMJ

1 Glossaire

BP Bande passante FIFO First In First Out. QoS Quality of Service SRR Shared/Shaped Round Robin : Algorithme de vidage de files d’attente1 WRR Weighted Roubd Robin. Algorithme de vidage de files d’attente2 WTD Weighted Tail Drop. Mécanisme de gestion de la congestion de files d’attente

1 Voir annexes 2 Voir annexes


/68

JMJ

2 Convention de style

Texte en italique : Terme utilisé appartenant au « vocabulaire » QoS des équipements Cisco et dont la définition est donnée dans ce document.

3 Objectifs

Le but du présent document est de donner des concepts généraux de QoS sur le LAN et d’expliquer leurs implémentations par Cisco sur certains de ses équipements pris en exemple, ainsi que les différentes commandes de ces équipements. Les anglicismes seront autant que possible évités, sans pour autant chercher à tout prix à les exclure, si le terme anglais est le plus approprié à l’explication. Une première version non publiée de ce document date de 2003. Cette version n’a pas été publiée car à l’époque les documentations et avis « d’experts » étaient tous différents et contradictoires. Même provenant du même constructeur, Cisco en l’occurrence, il n’était pas rare que les explications concernant les paramètres d’une commande soient très différentes, et les valeurs à leur attribuer varient du tout au tout. Il me semble qu’aujourd’hui, 10 ans après, la brume s’est quelque peu dissipée et il est possible de trouver, certes au prix d’efforts assez considérables, des explications qui d’une part semblent cohérentes, et d’autre part répétées dans plusieurs documents. Ce n’est pas, je le concède, un signe d’exactitude, mais au moins de cohérence. Entre 2003 et 2013 j’ai toujours mis mon veto à l’introduction de la QoS sur le LAN (pas le WAN) dont j’ai la responsabilité, car personne, aucun expert, aucun spécialiste, n’a jamais réussi à me convaincre qu’il comprenait ce qu’il faisait lorsqu’il « jouait » avec les paramètres de commandes relatives à la QoS. Toutes les nombreuses expériences de QoS tentées se sont toujours soldées par un échec, ou une réussite inexpliquée et inexplicable et où la chance semblait jouer un rôle plus grand que l’adéquate configuration des équipements. A ne jamais oublier :

• N’introduire la QoS que si des problèmes de congestion sont rencontrés, c.à.d si des paquets sont rejetés (packet drop).

• QoS sur le LAN, avec des équipements Cisco revient à définir quels paquets (quelles applications) doivent être rejetés avant les autres paquets/applications. Commencer par établir cette hiérarchie, avec les responsables des applications, avant d’implémenter la QoS est la bonne chronologie de l’implémentation de la QoS, pas l’inverse.

4 Audience

Ce document s’adresse à toute personne en charge de l’administration ou de l’opération d’équipements Cisco avec ou sans implémentation de la QoS.

4.1 Pré-requis Une bonne connaissance du protocole IP ainsi que des équipements Cisco est un plus. Des notions de configuration de ces équipements par CLI, permettront de mieux comprendre certains chapitres.


/68

JMJ

5 Définitions et Vocabulaire

5.1 ToS bit de l’entête d’un paquet IP bits Précedence = TOS DiffServ

Table 1: ToS bit de l’entête d’un paquet IP ToS codé sur 3 bits DiffServ codé sur 6 bits Dans tout ce document, pour convertir en octet les 6 bits du DiffServ, 2 bits sont ajoutés à gauche de ces 6 bits. Ces 2 bits représentent donc 27 et 26 de l’octet ainsi créé. ATTENTION : dans certaines documentations de CISCO, deux bits sont ajoutés à droite et représentent alors 21 et 20. En conséquence six bits de DiffServ de valeur 101110:

Delay Throughput Reliability Unused

Bits supplémentaires 0 0

2^7 2^6

0 0 1 0 1 1 1 0

Table 2: Valeur Héxadécimale des DSCP codés sur 6 bits Seront notés

TOS = 5 (Décimal)

DSCP = 00101110 - Binary

DSCP = 46 - Decimal DSCP = 0x2E DSCP = EF Express Forwarding

DSCP Binary Decimal Hexa

EF 101110 46 2E

Table 3: Valeur hexadécimale des DSCP codés sur 6 bits : Exemple

NOTE Dans certains documents de Cisco, il n’est pas rare de trouver :

DSCP Binary Decimal Hexa

EF 10111000 184 0xB8

Table 4: Valeur hexadécimale des DSCP codés sur 6 bits “à la Cisco”

7 6 5 4 3 2 1 0

Precedence Delay Throughput Reliability Unused

DiffServ Code Point (DSCP) Flow Control


/68

JMJ

5.2 Table complète TOS-IP Precedence - DSCP

7 6 5 4 3 2 1 0

Precedence TOS Precedence Delay Throughput Reliability Unused

DiffServ DiffServ Code Point (DSCP) Flow Control DSCP Binary Decimal Hexa

Bits supplémentaires 0 0 0 0 0 0 Plus Flow Ctrl Default 0 0 0

0 0 0 0 0 1 « Classe ISP » 1

2^7 2^6 0 0 0 0 1 0 2

0 0 0 0 0 0 1 1 3

0 0 0 0 0 1 0 0 4

0 0 0 0 0 1 0 1 5

0 0 0 0 0 1 1 0 6

0 0 0 0 0 1 1 1 7

0 0 0 0 1 0 0 0 CS1 1000 8 8

0 0 0 0 1 0 0 1 9

0 0 0 0 1 0 1 0 AF11 1010 10 A

0 0 0 0 1 0 1 1 B

0 0 0 0 1 1 0 0 AF12 1100 12 C

0 0 0 0 1 1 0 1 D

0 0 0 0 1 1 1 0 AF13 1110 14 E

0 0 0 0 1 1 1 1 F

0 0 0 1 0 0 0 0 CS2 10000 16 10

0 0 0 1 0 0 0 1 11

0 0 0 1 0 0 1 0 AF21 10010 18 12

0 0 0 1 0 0 1 1 13

0 0 0 1 0 1 0 0 AF22 10100 20 14

0 0 0 1 0 1 0 1 15

0 0 0 1 0 1 1 0 AF23 10110 22 16

0 0 0 1 0 1 1 1 17

0 0 0 1 1 0 0 0

Silver

CS3 11000 24 18

0 0 0 1 1 0 0 1 19

0 0 0 1 1 0 1 0 AF31 11010 26 1A

0 0 0 1 1 0 1 1 1B


/68

JMJ

0 0 0 1 1 1 0 0 AF32 11100 28 1C

0 0 0 1 1 1 1 0 1D

0 0 0 1 1 1 1 0 AF33 11110 30 1E

0 0 0 1 1 1 1 1 1F

0 0 1 0 0 0 0 0

Gold

CS4 100000 32 20

0 0 1 0 0 0 0 1 21

0 0 1 0 0 0 1 0 AF41 100010 34 22

0 0 1 0 0 0 1 1 23

0 0 1 0 0 1 0 0 AF42 100100 36 24

0 0 1 0 0 1 0 1 25

0 0 1 0 0 1 1 0 AF43 100110 38 26

0 0 1 0 0 1 1 1 27

0 0 1 0 1 0 0 0

Platinum

CS5 101000 40 28

0 0 1 0 1 0 0 1 29

0 0 1 0 1 0 1 0 2A

0 0 1 0 1 0 1 1 2B

0 0 1 0 1 1 0 0 2C

0 0 1 0 1 1 0 1 2D

0 0 1 0 1 1 1 0 EF 101110 46 2E

0 0 1 0 1 1 1 1 2F

0 0 1 1 0 0 0 0 CS6 110000 48 30

0 0 1 1 0 0 0 1 31

0 0 1 1 0 0 1 0 32

0 0 1 1 0 0 1 1 33

0 0 1 1 0 1 0 0 34

0 0 1 1 0 1 0 1 35

0 0 1 1 0 1 1 0 36

0 0 1 1 0 1 1 1 37

0 0 1 1 1 0 0 0 CS7 111000 56 38

0 0 1 1 1 0 0 1 39

0 0 1 1 1 0 1 0 3A

0 0 1 1 1 0 1 1 3B

0 0 1 1 1 1 0 0 3C


/68

JMJ

0 0 1 1 1 1 0 1 3D

0 0 1 1 1 1 1 0 3E

0 0 1 1 1 1 1 1 3F

A F X Y ignorés

C S X ignorés - toujours 000

Table 5: Cos-IP Precedence - DSCP

5.3 Probabilité de rejet

Per Hop Behaviour (PHB)

DiffServ Code Point (DSCP)

IP Precedence

Default 0

0

Assured Forwarding Low Drop Probability

Medium Drop Probability High Drop Probability

Class 1 AF11 AF12 AF13 1

0 0 1 0 1 0 001100 001110


0 1 0 0 1 0 10100 10110


0 1 1 0 1 0 11100 11110


1 0 0 0 1 0 100100 100110

Expedited Forwarding EF 5

1 0 1 1 1 0

Class Drop probability = 1 Always 0 Drop probability = 2 Drop probability = 3

Table 6: Drop probability


/68

JMJ

6 La QoS sur un switch Cisco

6.1 Introduction Ce document repose en majeure partie sur les documents suivant : http://www.cisco.com/en/US/products/hw/switchs/ps5023/products_tech_note09186a0080883f9e.shtml et http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/configuration/guide/swqos.html et https://supportforums.cisco.com/docs/DOC-8093 Avec la QoS il est possible de définir un traitement préférentiel pour un certain type de trafic au détriment d’un autre type. Cette différentiation repose sur l’utilisation d’un QoS Label. Au niveau 3, les deux QoS Labels de l’entête IP les plus communément utilisés sont les champs d’IP precedence et de DSCP. Au niveau 2, le QoS Label de l’entête d’une trame s’appelle Class of Service (CoS) Dans les exemples qui suivent, nous prendrons comme exemple deux types de switchs Cisco actuellement en service dans le réseau supervisé : Mgth03 : Un 3650, WS-C3560-24PS-S exécutant IOS Version 12.2(25r)SEC, (fc4) et Lish01 : Un 3750, WS-C3750X-48P-S exécutant IOS Version 12.2(25)SEE2, (fc1) sans QoS Lish02 : Un 3750, WS-C3750X-48P-S exécutant IOS Version 12.2(53r)SE2, (fc1) avec QoS Ces switchs peuvent utiliser les QoS Labels de niveau 2 ou de niveau 3. Il est à noter ici que la mise en œuvre de la QoS sur les plateformes C3750/C3560 est différente de celle mise en œuvre sur les plateformes C3750E/C3560E. Ceci est dû en grande partie aux changements apportés aux ASICs équipant ces switchs. De plus, à l’intérieure d’une même famille de plateforme, les versions d’ASIC peuvent changer au cours du temps, générant des changements de comportement dans le traitement de la QoS.

6.2 La QoS sur un switch Cisco : résumé Un switch Cisco détermine en grande partie le traitement à effectuer sur un paquet (au sens large, incluant une trame de niveau 2 et/ou un paquet de niveau 3) en atribuant à chaque paquet une valeur au champ DSCP interne. Ce DSCP interne sert à determiner si le paquet doit être marqué ou policé, quelle file d’attente (queue) doit le traiter ou s’il doit être rejeté (droppé). La valeur du DSCP interne peut ou non être celle du champ DSCP du paquet IP entrant. Le DSCP interne se voit affecter une valeur même pour des protocole non IP (Spanning tree, IPX,…). Il est donc évident que la valeur attribuée à ce DSCP interne est la clée de la QoS. L’attribution d’une valeur au DSCP interne repose sur les 4 configurations possibles d’un port de ces switchs relatives à la confiance accordée au paquet entrant (trust):

1. Non confiant (untrusted) : Les marquages de niveau 2 et/ou 3 sont ignorés et forcés à 0 (par défaut mais modifiable) pour tous les paquets recus.

2. Confiant au CoS: La valeur du CoS transportée par un trunk 802.1Q est acceptée et utilisée comme point d’entrée de la table de correspondance CoS/DSCP pour déterminer la valeur de DSCP interne.

3. Confiant à l’IP precedence : La valeur de l’IP precedence du paquet IP (IPP) entrant est acceptée et utilisée comme point d’entrée de la table de correspondance


/68

JMJ

IPP/DSCP pour déterminer la valeur du DSCP interne. Pour un paquet non-IP le DSCP interne prend la valeur 0. Cette méthode est obsolète et remplacée par:

4. Confiant au DSCP: La valeur du DSCP transportée est acceptée et utilisée comme valeur du DSCP interne. Pour un paquet non-IP le DSCP interne prend la valeur 0.

Un état confiant supplémentaire (non statique comme les 4 ci-dessus) existe et repose sur la reconaissance par CDP de l’objet connecté au port. Cet état supplémentaire est donc très Cisco centrique.

lish02(config-if)#mls qos trust device ? cisco-phone Cisco IP Phone cts Cisco-telepresence ip-camera Cisco video surveillance camera

Il est important de se souvenir que le paquet IP entrant quittera le switch avec un champ DSCP dont la valeur sera celle du DSCP interne déterminé par le switch. Si ce paquet est transporté par un trunk, la valeur du CoS sera affectée des 3 bits de poids fort du DSCP. Ceci peut être inhibé par la commande globale no mls qos rewrite ip dscp. Les chapitres suivant détaillent ces différentes possibilités.


/68

JMJ

6.3 Par defaut Sur ce type de switchs, la QoS est inhibée par défaut. Toutes les trames et paquets restent inaltérés par le switch. Par exemple, un paquet marqué DSCP = EF, transporté par une trame marquée CoS = 5 entre dans le switch, celui-ci ne change pas les valeurs de DSCP et/ou de CoS. Le paquet en question ressortira du switch avec les mêmes valeurs de CoS et de DSCP. Tout le trafic sera traité selon Best Effort, c.à.d. sans traitement préférentiel pour l’un ou l’autre type de paquet : c’est le mode pass-though.

6.3.1 Show mls qos La commande sho mls qos permet de savoir si la QoS est activée ou non

mgth03#sho mls qos QoS is enabled QoS ip packet dscp rewrite is enabled

lish01#sho mls qos QoS is disabled QoS ip packet dscp rewrite is enabled

lish02#sho mls qos QoS is enabled QoS ip packet dscp rewrite is enabled

Nota Bene : Bien que le switch annonce «QoS ip packet dscp rewrite is enabled », le switch ne change pas la valeur du DSCP quand la QoS n’est pas activée.

6.4 Activation de la QoS La commande mls qos active la QoS sur le switch (ou le stack) sur lequel elle est entrée. Il s’agit d’une commande de configuration globale: une fois la commande entrée, les paramètres de QoS prennent leur valeur par défaut, le trafic est classifié Best effort (les champs DSCP et CoS sont forcés à 0), sans policy. Aucune policy map n’est configurée, tous les ports du switch sont dans l’état untrusted. Les paramètres par défaut s’appliquent aux files d’attente d’entrée et de sortie. La QoS doit être globalement activée par cette commande, afin d’activer toutes les fonctions imparties à la QoS, à savoir :

• La classification, • Policing

• Mark down ou drop

• Queueing • Shaping

Il est possible d’affecter une policy-map à un port du switch avant d’activer la QoS, les traitements conformes à la QoS configurée ne prendront effet qu’après que la commande globale mls qos ait été saisie. La commande no mls qos ne supprime pas les policy-maps ni les class-maps précédemment configurées. Basculer d’un état d’activation à l’autre modifie la taille des files d’attente. Durant cette modification, la file d’attente est temporairement stoppée durant la reconfiguration du matériel et le switch rejette les paquets nouvellement arrivés pour cette file d’attente.


/68

JMJ

6.5 Les fonctions imparties à la QoS Une fois la QoS activée, un certain nombre de fonctions imparties à celle-ci sont activées par défaut, sur le trafic entrant comme sur le trafic sortant. La figure suivante offre une vision globale de ces fonctions.

Figure 1: Fonctions imparties à la QoS sur un switch 3750 Cisco Ce sont :

• Les fonctions de QoS sur le trafic entrant (ingress) qui peuvent être configurées par port :

o Classification o Marquage o Policing

• Les tables de correspondance et les files d’attente pour le trafic entrant sont configurées de manière globale (pas par port).

• SRR pour le trafic entrant est configuré globalement. • La bande passante du Stack Ring (quand ceci s’applique) dépend du câblage du

Stack. Si celui-ci est interconnecté en full bandwith, 32Gbps sont disponibles pour un 3750. Cette bande passante est partagée par tous les switchs participants au Stack.

• Les tables de correspondance et les files d’attente pour le trafic sortant sont configurées de manière globale (pas par port). Deux jeux de files d’attente de sorties peuvent être configurées. Chaque port sera configuré pour utiliser l’un ou l’autre de ces jeux.

• SRR pour les files d’attente de sortie est configuré par port. SRR est un mécanisme de vidage de file d’attente qui garantit une bande passante au trafic sortant d’une file d’attente et cela par file d’attente (voir annexe). SRR peut être configuré (mode shape) en assignant un poids maximum à chaque file d’attente, ce poids est converti en pourcentage de bande passante. Le trafic issu de chaque queue est limité à cette valeur en ceci que chaque file d’attente ne peut utiliser au maximum que le pourcentage défini par le poids.


/68

JMJ

6.6 Fonctions QoS sur le trafic entrant

6.6.1 Par défaut Une fois la QoS activée, le switch traite par défaut le trafic entrant de la sorte: Une trame entre par un port du switch. Cette trame n’est pas taggée. Il s’agit d’un access port et la trame n’est pas encapsulée par ISL ou dot1q. Le switch encapsule cette trame dans une trame dot1q La trame dot1q formée est taggée. Ce tag comporte, dans son champ TCI les 3 bits appelés 802.1p priority – aussi appelés CoS-. Ces bits sont forcés à zéro (0). Enfin le switch défini la valeur du DSCP en se basant sur la table de correspondance CoS-DSCP. Cette table indique 0, le DSCP est forcé à zéro. C’est l’entête IP qui est affectée à ce niveau.

lish02#sho mls qos maps cos-dscp Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 24 32 40 48 56

Table 7: Table de correspondance par défaut COS-DSCP. Rem : par défault le CoS représente les 3 bits de poids forts du DSCP codé sur 6 bits, c’est donc la partie entière du DSCP divisé par 8 (Chaque décalage à gauche d’un nombre codé en base B revient à un division par B. 3 décalages à gauche d’un nombre binaire sont une division par 23 = 8) Nota Bene : une valeur de COS = 5 sera traduite en DSCP = 40. (CS5 et non EF) En résumé, les valeurs du CoS et du DSCP sont forcées à zéro par un switch dont la QoS est activée dans une configuration par défaut. (c.à d. quand seule la commande mls qos est entrée).


/68

JMJ

6.6.2 Classification et marquage Sur les types de switchs pris en exemple il est possible de classifier une trame en fonction:

• Des valeurs de CoS/DSCP reçues • D’Access List (ACL)

La configuration reposant sur les valeurs de CoS/DSCP peut s’effectuer selon les 3 manières suivantes:

• Port : utilisation des commandes mls qos basées interface • VLAN : utilisation des commandes mls qos basées VLAN • Configuration reposant sur des class-map et des policy-map

Seule l’une de ces trois méthodes est possible à la fois.

6.6.2.1 Port / interface Il faut se remémorer ici que les switchs pris en exemple – contrairement aux routeurs – marquent les champs CoS/DSCP des trames en utilisant une table de correspondance (qui n’existent pas sur les routeurs).

lish02#sho mls qos maps ? cos-dscp cos-dscp map keyword cos-input-q cos-input queue map keyword cos-output-q cos-output queue map keyword dscp-cos dscp-cos map keyword dscp-input-q dscp-input queue map keyword dscp-mutation dscp-mutation map keyword dscp-output-q dscp-output queue map keyword ip-prec-dscp ip-prec-dscp map keyword policed-dscp policed-dscp map keyword | Output modifiers

Figure 2: Classification et marquage basées Port

6.6.2.1.1.1 Classification – Port Trust “On fait confiance”. Une trame ou un paquet entrant peut déjà être qualifié par un QoS Label. Que faire ?

• Fait-on confiance à ce marquage arrivant ?


/68

JMJ

• Si un PC et un téléphone sont connectés à un port, fait-on confiance au marquage du PC, du téléphone, des deux ?

Si l’on ne fait pas confiance au marquage arrivant, il faudra classifier le paquet en utilisant une Access-List et marquer celui-ci. Si l’on fait confiance au marquage arrivant, fait-on confiance au marquage CoS ou au marquage DSCP? Différents scénarios sont envisageables. Sur un port de ces switchs, les différentes options possibles de trust sont les suivantes :

lish02(config-if)#mls qos trust ? cos cos keyword device trusted device class dscp dscp keyword ip-precedence ip-precedence keyword <cr>

Exemple 1 : Si le port est configuré en access-port ou en Layer 3 port on ne peut utiliser que mls qos trust dscp. Il n’est pas possible d’utiliser mls qos trust cos car sur un port de type acces ou Layer 3, les trames entrantes ne comportent pas de CoS bits, bits uniquement présents dans des trames dot1q ou ISL.

interface GigabitEthernet1/0/1 description **** Layer 3 Port **** no switchport ip address 192.168.10.1 255.255.255.0 mls qos trust dscp end interface GigabitEthernet1/0/2 description **** Access Port **** switchport access vlan 10 switchport mode access mls qos trust dscp end

Exemple 2 : Si le port est configuré en tant que trunk, il est possible de configurer au choix, soit:

• mls qos trust dscp ou • mls qos trust cos.

La table de correspondance dscp-cos sera utilisée pour déterminer la valeur du CoS si le port fait confiance au DSCP. De même, la table de correspondance cos-dscp sera utilisée pour déterminer la valeur du DSCP si le port fait confiance au CoS.

interface GigabitEthernet1/0/3 description **** Trunk Port **** switchport trunk encapsulation dot1q switchport mode trunk switchport trunk native vlan 5 switchport trunk allowed vlan 5,10,20,30,40,50 mls qos trust cos end interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust cos


/68

JMJ

spanning−tree portfast end !−−− The Cisco IP Phone uses IEEE 802.1Q frames for Voice

!−−− VLAN traffic.

Le problème posé avec mls qos trust cos est que le trafic issu d’un téléphone et qualifié CoS = 5 et DSCP = Express Forwarding (EF = 46) sera re-qualifié CoS = 5 et DSCP = 5 x 8 = 40, soit CS5, ce qui est indésirable. La table de correspondance cos-dscp peut être modifiée pour corriger cela en assignant la valeur 46 attribuée à une valeur de COS de 5 par la commande :

mls qos map cos-dscp 0 8 16 24 32 46 48 46

Nota Bene : Il est recommandé que tous les switchs d’un même réseau soient configurés avec les mêmes contenus des tables de correspondance. Rappel : Voice Vlan

Exemple 3 : Si le port est configuré en tant que trunk avec mls qos trust cos, toutes les trames du VLAN natif auront des valeurs de CoS et DSCP égales à 0. Comme les trames du VLAN natif ne sont pas taggées et qu’une trame n’est taggée qu’une fois qu’elle a pénétré dans le switch, le switch assignera la valeur par défaut 0 au CoS, puis la table de correspondance cos-dscp assignera la valeur 0 au DSCP. Nota : La valeur du DSCP d’un paquet issu du VLAN natif est forcée à 0. Il est possible de configurer une valeur différente que 0, comprise entre 0 et 7, en tant que valeur par défaut de CoS pour les trames non taggées. La commande à utiliser est : mls qos cos<0-7>. Cette commande ne change pas la valeur du CoS des trames taggées. Par exemple :

interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust cos spanning−tree portfast !−−− The Cisco IP Phone uses IEEE 802.1Q frames for Voice

!−−− VLAN traffic. Voice VLAN is only supported on access ports and not

!−−− on trunk ports, even though the configuration is allowed.

Soit un PC connecté au Cisco IP Phone connecté à ce port. Le PC émet des trames non taggées qui traversent inchangées le téléphone, quel que soit la configuration « trust » de l’access port du téléphone3. Le téléphone quant à lui émet ses trames taggées dot1q avec un identifiant de VLAN égal à 20.

3 Voir en annexes les différentes facons de configurer le switch d’un Cisco IP Phone


/68

JMJ

Si le port du switch est configuré en tant que mls qos trust cos celui-ci «fait confiance» à la valeur CoS des trames tagguées issues du téléphone, et force à 0 la valeur de CoS des trames non tagguées issues du PC. La table de correspondance CoS-DSCP assigne une valeur de DSCP de 0 au paquet encapsulé dans la trame, car cette table assigne DSCP = 0 pour une valeur de CoS = 0. Si le champ DSCP des paquets issus du PC a une valeur non nulle, celle valeur sera effacée (forcée à 0). Si ce même port est maintenant configuré avec mls qos cos 3, toutes les trames issues du PC se verront dotées d’un CoS de valeur 3, sans altérer la valeur du CoS des trames issues du téléphone.

interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust cos mls qos cos 3 spanning−tree portfast

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_m2.html#wp1041343: bien lire le tableau explicitant cos-value : … to all incoming packets… doit être compris untagged packets on Cos trusted ports.

Si l’on veut forcer le valeur du CoS à 3 pour tous les paquets, que ceux-ci soit taggés ou non, il faut utiliser la commande : mls qos cos 3 override. Cette commande réécrit les valeurs CoS auxquelles il a été « précedemment fait confiance »

interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust cos


/68

JMJ

mls qos cos 3 override !−−− Overrides the mls qos trust cos.

!−−− Applies CoS value 3 on all the incoming packets on both

!−−− the vlan 10 and 20.

Exemple 4 : Soit un port configuré de la sorte :

interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust cos spanning−tree portfast

Figure 3: Utilisateur « malin » priorisant son trafic Si un PC « malveillant » connecté à l’access port d’un téléphone Cisco émet des trames taggées VLAN20, avec une valeur du CoS à 5, le switch traitera ce trafic taggé issu de PC comme un trafic taggé issu du téléphone, ignorant que celui-ci est émis par le PC. En effet, d’une part un Cisco IP phone transmet de manière inchangée4 le trafic reçu sur son access port et d’autre part le port du switch est configuré pour faire confiance au CoS. Le trafic du PC sera géré avec la même priorité que le trafic issu du téléphone. Pour éviter cela, il est possible d’utiliser la commande switchport priority extend cos <cos-value> :

interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust cos switchport priority extend cos 0 !−−− Overrides the CoS value of PC traffic to 0.

spanning−tree portfast

Cette commande demande au port du switch du téléphone de forcer la valeur du CoS des trames issues du PC à 0. Cette commande utilise le protocole CDP –propriétaire Cisco- et ne fonctionne donc qu’avec des téléphones Cisco. CDP doit être autorisé sur le port en question.

4 Voir en annexes les différentes facons de configurer le switch d’un Cisco IP Phone


/68

JMJ

Figure 4: Téléphone en tant que filtre de CoS Exemple 5 : Bien évidemment le PC malveillant peut aussi être connecté directement au switch, sans passer par un téléphone. Dans ce cas la commande précédente qui demande au switch du téléphone de forcer la valeur du CoS à 0 ne sert à rien puisqu’il n’y a pas de téléphone entre le PC et le switch.

Figure 5: PC « malin » directement connecté au switch Bénéficiant du protocole propriétaire CDP, Cisco peut détecter si l’appareil connecté à qui le switch est censé faire confiance est un Cisco Ip Phone, et ne faire confiance qu’aux Cisco IP Phones, en utilisant la commande : mls qos trust device cisco-phone.

interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust cos switchport priority extend cos 0 mls qos trust device cisco−phone !−−− Specify that the Cisco IP Phone is a trusted device.

spanning−tree portfast

N’ayant pas de téléphone IP de marque Cisco pour tester cette commande, je l’interprète de la sorte : Le switch fait confiance au CoS tant que celui-ci qualifie des trames issues de téléphone Cisco. Dans le cas contraire le CoS est forcé à 0. Exemple 6 : Sur cette interface GigabitEthernet1/0/12 est maintenant connecté dans le VLAN 10 un PC dont les QoS Labels doivent être acceptés et traités en conséquence. Comme vu précédemment dans l’exemple 3, étant donné que le PC (c’est un PC non-malin) ne


/68

JMJ

transmet pas de CoS, la valeur de celui-ce est forcé à 0 entrainant l’effacement du DSCP tranmis et sa mise à zéro aussi. Afin de conserver le marquage du PC et de le traiter de manière adéquate, deux solutions s’offrent à nous : La première est d’utiliser MQC pour classifier et marquer en créant une ACL qui match le trafic du PC – par ex. en utilisant l’adresse source ou destination-, puis en créant une class-map qui match cette ACL et enfin en créant une policy-map qui trust ce trafic. La seconde solution consiste à faire confiance au champ DSCP en lieu et place du champ CoS. La table de correspondance DSCP-COS établira la valeur du CoS et l’affectera. La première solution, solution préférée car plus sure, sera détaillée dans le chapitre suivant. Ce qui suit détaille la seconde solution. Seconde Solution :

interface GigabitEthernet1/0/12 description **** Cisco IP Phone **** switchport access vlan 10 switchport mode access switchport voice vlan 20 mls qos trust dscp spanning−tree portfast

6.6.3 Classification et marquage du traffic entrant : Hic et Nunc5 Le réseau (environ 700 switchs et 30000 ports dans 80 filiales) de mon entreprise a été configuré de la sorte : Un vlan Data pour les PC, doté d’un sous réseau spécifique par filiale, le VLAN 308 Un vlan Téléphonie pour les téléphones et l’infrastructure téléphonie (call serveurs,…), doté d’un sous réseau spécifique par filiale, le VLAN 309. Les téléphones IP mis en services sont construits par Alcatel (pas Cisco). On appellera port User un port auquel peut être connecté soit un téléphone, soit un PC, soit un PC derrière un téléphone. Contrainte : tous les ports User de tous les switchs dans toutes les filiales doivent être configurés de la même manière. Le trafic téléphonique doit être marqué/forcé DSCP EF (46). La solution retenue repose sur MCQ : Une access list (ACL) reconnaît un téléphone par son adresse IP (appartenance au VLAN 309). Il y a donc une ACL par filiale. C’est ACL 100 définie de la sorte :

access-list 100 remark VoIP + Vermitler PCs DSCP EF Markiert access-list 100 permit ip 10.118.16.0 0.0.7.255 any

Une class-map est associée à cette ACL :

class-map match-any Business match access-group 110 class-map match-any Video match access-group 131 class-map match-any Voice match access-group 100

5 Ici et maintenant : comment cela est implémenté dans le réseau de mon entreprise


/68

JMJ

Cette class-map est référencée dans un policy-map :

policy-map policy-QoS class Business set dscp cs4 class Voice set dscp ef class Video set dscp af31 class class-default set dscp default

Cette policy-map est appliquée à tous les ports User :

interface FastEthernet0/12 switchport trunk encapsulation dot1q switchport trunk native vlan 308 switchport trunk allowed vlan 308,309 switchport mode trunk service-policy input policy-QoS spanning-tree portfast trunk

Rappel : une policy-map ne peut s’appliquer qu’à l’entrée d’une interface. Appliquer une policy-map annule et remplace toute autre méthode de classification précédemment configurée. Ces différentes configurations conduisent à : La policy policy-QoS s’applique sur tous les ports User. Cette policy consiste à forcer DSCP = EF à tout trafic conforme à la classe Voice. Un trafic conforme à la classe Voice est un trafic qui match l’ACL 100. L’ACL 100 match pour tout objet dont l’adresse IP est dans le Vlan Téléphonie. La policy-map policy-QoS force COS = 0 et DSCP = 0 pour tout trafic non-conforme aux classes Business ou Voice ou Video (non détaillées ici). Il est possible d’assigner d’autres valeurs au COS ou DSCP par défaut. Aucune limitation de bande passante n’est configurée. De plus un port User est configuré en mode trunk, seuls les Vlan Data et Téléphonie sont autorisés.

6.6.3.1 Avec limitation de bande passante La class map définie ci-dessus défini aussi une classe Video, qui marque avec DSCP = AF31 tous les paquets qui vérifient l’ACL 131. Il est possible de limiter le trafic Vidéo entrant (une policy ne peut s’appliquer que sur le trafic entrant) à 10 Mb/s de la sorte :

lish02(config)#policy-map Limit-Video lish02(config-pmap)#class Video lish02(config-pmap-c)#? QoS policy-map class configuration commands: exit Exit from QoS class action configuration mode no Negate or set default values of a command police Police service-policy Configure QoS Service Policy set Set QoS values trust Set trust value for the class <cr>


/68

JMJ

lish02(config-pmap-c)#police ? <8000-10000000000> Bits per second (postfix k, m, g optional; decimal point allowed) aggregate Choose aggregate policer for current class lish02(config-pmap-c)#police 10000000 ? <8000-1000000> Normal burst bytes lish02(config-pmap-c)#police 10000000 8000 ? exceed-action action when rate is exceeded <cr> lish02(config-pmap-c)#police 10000000 8000 exceed-action ? drop drop packet policed-dscp-transmit change dscp per policed-dscp map and send it

La dernière ligne défini ce qu’il convient de faire des paquets lorsque la limite de la bande passante est atteinte. Nous y reviendrons, mais pour l’instant intéressons-nous à la commande

police 10000000 8000

6.6.3.1.1 police 10000000 8000 Cette commande est très déroutante car elle mélange deux unités : les bits par seconde et les bytes. Comment ces paramètres interagissent ils ? Nous voulons limiter à 10Mb/s le trafic vidéo entant, sur un port configuré à 100 Mb/s. Chaque bit reçu/transmis est bien évidemment reçu/transmis à la vitesse du port, soit 100 Mb/s. Pour limiter la bande passante il convient de compter le nombre de bits reçus/transmis durant un intervalle de temps. Les bits (en fait les paquets ou les trames) excédentaires sont soit rejetés, soit déclassés, soit mis en file d’attente. La fenêtre de temps de l’intervalle durant laquelle ces bits sont effectivement transmis n’importe pas, ce qui importe c’est si il a trop de bits à transmettre durant cet intervalle. Admettons que cet intervalle soit de 1 seconde. 10 Mb seront reçus/transmis en 1/10 de secondes sur un port configuré à 100Mb/s. En admettant une transmission continue et constante, ce 1/10 de seconde peut se situer n’ importe où dans la seconde servant d’intervalle de temps. De même deux transmissions continues et constantes de 5Mb « occuperont » deux intervalles de 1/20 de secondes, n’importe lesquels dans la seconde servant d’intervalle de temps. Ces deux situations sont conformes à la limitation désirée de 10 Mb/s. Si l’intervalle de temps de référence est maintenant divisé par deux, soit 500 ms, une transmission de 10 Mb en 1/10 de seconde, ce qui reste conforme à la limitation voulue et qui se situe entièrement dans l’intervalle de temps de référence, verra la moitié des bits violer la limitation, et donc rejetés (si ainsi configuré). Une transmission de deux « blocs » de 5M espacés d’une demi-seconde ne verra pas la moitié des bits violer la limitation, et ne seront pas rejetés (si ainsi configuré). La question est donc comment définir l’intervalle de temps de référence, sachant que le switch n’a aucune idée de la nature du trafic : est-il formé de petits paquets, de grands paquets ? C’est à l’utilisateur de lui apporter des informations supplémentaires.

6.6.3.1.1.1 Tocken Bucket ou seau à jeton Pour gérer cette situation Cisco a implémenté un algorithme nommé Tocken Bucket, ou seau à jetons. En fait plusieurs versions de cet algorithme existent et diffèrent selon la version d’IOS ce qui rend une explication universelle et toujours valable impossible. Merci Cisco !


/68

JMJ

Le principe est le suivant : Pour chaque octet à émettre il doit y avoir un jeton dans le panier. Au départ, le panier est rempli avec un nombre de jetons égal au paramètre Normal Burst Size, soit 8000 dans cet exemple. Soit un paquet à transmettre de taille B octets arrivant au temps T. Soit T1 le temps où le précédant paquet est arrivé. Entre ces deux temps, un certain nombre de « droits d’émission » d’octets sont donnés. Ces droits d’émission d’octets se calculent par la formule :

�� ×�é�� é

8

Dans l’exemple ci-dessus en 1 seconde le nombre d’octets qu’il est autorisé d’émettre est de 10 000 000 / 8 soient 1,25 Mo. La valeur suivante est calculée par l’équipement:

(T-T1) x paramètre bit per second / 8 bits Cette valeur est ajoutée au panier. Si le panier déborde, c.à d. si sa valeur dépasse la valeur définie par le paramètre Normal Burst Size, sa valeur reste limitée au Normal Burst Size (dans certains cas l’excédent peut être attribué à un panier supplémentaire, le « exceed bucket ». A ce moment,

1. Si le nombre de jetons disponibles dans le panier est supérieur à la taille en octets du paquet à transmettre (soit B), le paquet est transmis et B jetons sont retirés du panier.

2. Si le nombre de jetons disponibles dans le panier est inférieur à la taille en octets du paquet à transmettre (soit B), l’action définie en cas de dépassement est exécutée et aucun jeton n’est retiré du panier. (dans ce 2e cas et dans le cas où un exceed bucket existe, B est comparé au nombre de jetons disponible dans le exceed bucket . Si ce nombre de jetons est supérieur à B, l’action définie en cas de dépassement est exécutée et B jetons sont retirés à l’exceed bucket, sinon l’action violate sera exécutée.)

Voir aussi : http://en.wikipedia.org/wiki/Token_bucket http://fr.wikipedia.org/wiki/Seau_%C3%A0_jetons

6.6.3.1.2 Déclassification La commande

lish02(config-pmap-c)#police 10000000 8000 exceed-action policed-dscp-transmit

intime au switch de marquer tout le trafic en excédant en utilisant la table de correspondance policed-dscp. Par défaut cette table est configurée de la sorte

lish02#sh mls qos map policed-dscp Policed-dscp map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 00 01 02 03 04 05 06 07 08 09 1 : 10 11 12 13 14 15 16 17 18 19 2 : 20 21 22 23 24 25 26 27 28 29 3 : 30 31 32 33 34 35 36 37 38 39


/68

JMJ

4 : 40 41 42 43 44 45 46 47 48 49 5 : 50 51 52 53 54 55 56 57 58 59 6 : 60 61 62 63

Par défaut la table de correspondance policed-dscp procède à l’identité : la valeur du DSCP attribuée correspondante au DSCP entrant est la même. Il n’y a pas lieu d’utiliser les valeurs par défaut de cette table. Il peut par contre être intéressant de marquer le trafic excédentaire à la limite fixée avec une valeur de DSCP qualifiant une probabilité de drop (voir page 13 Chapitre 5.3 : Probabilit) supérieure à celle du trafic entrant. Par ex :

lish02(config)#mls qos map policed-dscp 46 to 26 lish02(config)#do sho mls qos map policed-dscp Policed-dscp map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 00 01 02 03 04 05 06 07 08 09 1 : 10 11 12 13 14 15 16 17 18 19 2 : 20 21 22 23 24 25 26 27 28 29 3 : 30 31 32 33 34 35 36 37 38 39 4 : 40 41 42 43 44 45 26 47 48 49 5 : 50 51 52 53 54 55 56 57 58 59 6 : 60 61 62 63

6.6.4 Eviter et gerer de la congestion Les chapitres prédédants ont permis d’établir comment assigner une valeur aux QoS Labels. Ce chapitre nous dévoilera comment les switchs pris en exemple utilisent cette valeur et en quoi elle est cruciale pour éviter et/ou gèrer la congestion. La gestion et l’évitement de congestion est un processus en trois étapes qui sont :

• La mise en file d’attente (queueuing), • Le rejet (dropping) • Et l’ordonnancement (scheduling).

Chaque paquet entrant est placé dans l’une des différentes files d’attente d’entrée logicielles existantes, en fonction de la valeur du QoS Label qui le qualifie. Les switchs pris en exemples disposent de deux files d’attente d’entrée : une fois le trafic entrant classifié et marqué du QoS Label , celui-ci aiguille le trafic dans l’une ou l’autre de ces deux files d’attente selon la valeur du QoS Label. Rappel : Tail-drop Le tail-drop est un mécanisme d’évitement de congestion élémentaire : Telle une FIFO, une fois la file d’attente pleine, les paquets arrivants sont simplement rejetés tant que la file reste pleine, sans tenir compte d’une quelconque priorité entre les paquets rejetés. Chaque paquet est aussi important qu’un autre, il n’y a pas de raison de rejeter un paquet plutôt qu’un autre. L’inconvénient majeur du tail-drop survient lorsque des paquets appartenant à de multiples sessions TCP sont rejetés : De par le protocole (Emission/Acquitement), l’émetteur voyant un paquet rejeté réduit son trafic (TCP Back off ou slow-down conduisant au TCP slow start). Si de multiples sessions sont ainsi perturbées, le trafic diminue drastiquement pour croitre à nouveau jusqu’à la congestion suivante, générant un trafic en dent de scie n’optimisant pas la bande passante disponible, qui passe régulièrement de « sous-exploitée » à « congestionnée ». Les switchs pris en exemple utilisent lorsque la QoS est activée une variante de tail-drop appelée Weighted tail drop (WTD) afin de contrôler la longueur des files d’attente et de rejeter des paquets en fonctions de la classification de ceux-ci, WTD génère 3 seuils (threshold) de rejet par file d’attente.


/68

JMJ

N.B. Le seuil 3 est par défaut positionné à 100 et ne peut être changé

N.B. Les seuils 1 et 2 ne s’appliquent pas consécutivement, mais seul le seuil 1 s’applique

OU le seuil 2 (en fonctions des QoS Labels) Parler d’un troisième seuil à 100% (ce qui revient à dire que quand c’est plein, ca déborde) me parait éxagéré et je préfère ne voir qu’un seuil pour le WTD qui peux prendre 2 valeurs en s’appliquant à des QoS Labels différents.

6.6.4.1 Files d’attente en entrée On se remémore ici la Figure 1: page 17 : Fonctions imparties à la QoS sur un switch 3750 Cisco montrant que les files d’attentes en entrées sont partagées par tous les ports. N.B. Sur les files d’entrées, le seul mode supporté par SRR est le mode sharing. Pour configurer les 3 étapes propres à la gestion de la congestion, les commandes suivantes sont disponibles :

• La mise en file d’attente (queueuing) • le rejet (dropping) • l’ordonnancement (scheduling)]

lish02(config)#mls qos SRR-queue input ? bandwidth Configure SRR bandwidth buffers Configure buffer allocation cos-map Configure cos-map for a queue id dscp-map Configure dscp-map for a queue id priority-queue Configure priority scheduling threshold Configure queue tail-drop thresholds

6.6.4.1.1 Configuration par défaut Les commandes ci-après nous permettent d’établir la configuration des files d’entrées

6.6.4.1.1.1 Quels CoS vers quelle file ?

lish02#sho mls qos maps cos-input-q Cos-inputq-threshold map: cos: 0 1 2 3 4 5 6 7 ------------------------------------ queue-threshold: 1-1 1-1 1-1 1-1 1-1 2-1 1-1 1-1

Tous les paquets transitent par la file 1 hormis ceux marqués C0S=5 qui transitent par la file 2. Quel que soit la valeur du CoS, c’est le seuil1 1 qui s’applique.

6.6.4.1.1.2 Quels DSCP vers quelle file ? En toute logique il devrait y avoir un rapport 8 entre ces deux tables. Effectivement:

lish02#sho mls qos maps dscp-input-q Dscp-inputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------------------ 0 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 1 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 2 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 3 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01


/68

JMJ

4 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01 5 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 6 : 01-01 01-01 01-01 01-01

Tous les paquets transitent par la file 1 hormis ceux marqués DSCP = 40 à 48 qui transitent par la file 2. Quelle que soit la valeur du DSCP, c’est le seuil1 1 qui s’applique. En cas de conflit entre les maps cos et dscp, les valeurs de cette dernière s’appliquent.

6.6.4.1.1.3 A partir de quand y a-t-il rejet de paquets ? Par défaut, les 3 seuils sont positionnés à 100%. Comme le seuil 3 est de toute façon positionné à 100%, seuls les seuils 1 et 2 sont affichés.

lish02#sho mls qos input-queue Queue : 1 2 ---------------------------------------------- buffers : 90 10 bandwidth : 4 4 priority : 0 10 threshold1: 100 100 threshold2: 100 100

6.6.4.1.1.4 Taille des files d’attente ? Cisco IOS réserve une certaine taille mémoire aux tampons (buffers) d’entrée. Ces tampons d’entrée sont partagés par les deux files d’attente d’entrée. La valeur absolue de cette taille n’est pas fournie, mais la taille relative de chacune des 2 files d’attentes est connue par la commande :


L’unité retenue est le tampon (buffer). La file d’attente en entrée numéro 1 se voit attribuer 90 % de tous les tampons d’entrée, la deuxième file se voit attribuer les 10% restant. Pour changer ces valeurs :

lish02(config)#mls qos SRR-queue input buffers ? <0-100> enter percent of buffers for queue 1 lish02(config)#mls qos SRR-queue input buffers 80 15 The sum should be equal to 100

6.6.4.1.1.5 Bande passante allouée à la file d’attente prioritaire ?



/68

JMJ

La file d’attente numéro 2 est définie par défaut comme prioritaire et se voit attribuer 10 % de la bande passante.

N.B. Il s’agit-là de la bande passante interne Pour changer cette valeur (qui doit rester inférieure à 40):

lish02(config)#mls qos SRR-queue input priority-queue 2 bandwidth ? <0-40> enter bandwidth number [0-40]

Assigner zéro lors de cette commande revient à interdire la file prioritaire. Pour changer le rang de la file d’attente prioritaire :

lish02(config)#mls qos SRR-queue input priority-queue ? <1-2> enter priority queue number [1-2]

La file d’attente prioritaire doit être réservée au trafic requérant une garantie de livraison (delivery guaranty). En effet cette file se voit réserver une part de la bande passante interne, quelle que soit la charge du stack ring ou de l’internal ring. La façon dont je perçois cette file d’attente prioritaire est la suivante :

1) Ce n’est pas une file d’attente Strict Priority car celles-ci bloquent le mécanisme de SRR/WRR tant qu’il y a des paquets dans cette file, ce qui n’est pas le cas de cette file prioritaire : la bande passante allouée est définie et limitée à 40 %.

2) Cette file est servie en priorité par SRR et délivre ses paquets tant que la bande passante qui lui est allouée n’est pas consommée. (toujours durant un intervalle de temps). Cette bande passante est donc garantie.

3) Une fois cette bande passante consommée cette file est servie par SRR dans le rapport des bandes passantes telles que définies par « bandwidth ». (voir ci-dessous)

Il est donc possible que les paquets qui entrent dans la file prioritaire ne soient pas tous traités de la même façon. Le terme expedite est à préférer à prioritaire pour cette file d’attente.

6.6.4.1.1.6 Bandes passantes allouées à chacune des files d’attente ? Il est possible de définir le rapport des fréquences auxquelles le SRR va émettre les paquets de chacune des deux files d’attente, et par la même définir la bande passante interne allouée à chacune des files.


Ce sont les termes P1 et P2 de la Figure 6: voir cette figure pour l’explication de ces paramètres. Pour changer ces paramètres :

lish02(config)#mls qos SRR-queue input bandwidth ? <1-100> enter bandwidth weight for queue id 1


/68

JMJ

lish02(config)#mls qos SRR-queue input bandwidth 4 ? <1-100> enter bandwidth weight for queue id 2 lish02(config)#mls qos SRR-queue input bandwidth 4 4 ? <cr>

La taille des files d’attentes (buffers) associée à la bande passante (bandwidth) déterminent combien de données peuvent être émises ou mises en file d’attente avant que des paquets ne soit rejetés (drops). Il faut ici se souvenir que, comme le SRR sur les files d’attente en entrée ne fonctionne qu’en mode shared, les valeurs absolues de ces paramètres sont sans importance, c’est leur rapport qui définit le rapport des bandes passantes allouées à chacune de files d’attente. Tous les paramètres décrits dans les chapitres précédents, obtenus par la commande sho mls qos input-queue


Table 8: File d’attente, rejet et ordonnancement pas défaut permettent d’établir le schéma suivant :

Figure 6: File d’attente, rejet et ordonnancement pas défaut

BP allouée en % : (100 – Expedite) x P1/(P1+P2) = 90 x 4/8 = 45%

BP totale = 100%

SRR-Queue Map COS 0,1,2,3,4,6,7 DSCP 0 à 39, 48 à 63 COS 5 DSCP 40 à 47

Buffer

File 1 90 %

File 2 10 %

100%

SRR

Expedite : 10% de la BP totale

Ring intern (ou Stack)

BP : Bande passante P1 : facteur de pondération de la file 1 P2 : facteur de pondération de la file 2

BP allouée en %: (100 – Expedite) x P1/(P1+P2) = 90 x 4/8 = 45%

Th

resh

old

=

100%


/68

JMJ

6.6.4.1.1.7 Seuils de rejet Placons nous dans le cas ou

• Tous les paquets à traiter sont marqués soit DSCP = 0,1,2,3,4,5,6 soit DSCP = 21,21,22,23, soit DSCP = EF (telephonie).

• Les paquets marqués DSCP = 21,21,22,23, sont « plus importants » et doivent se voir attribués une probabilité de rejet inférieure aux autres paquets.

La file 2 (expedite) reste réservée à la téléphonie. Il convient de placer les autres paquets dans la file 1 avec des seuils de rejets différents. Ceci est réalisé par la commande :

mls qos SRR-queue input dscp-map Queue 1 Threshold 1 0 1 2 3 4 5 6

qui intime au switch de placer dans la file 1 les paquets marqués DSCP = 0,1,2,3,4,5,6 et de leur appliquer le seuil 1 et la commande :

mls qos SRR-queue input dscp-map Queue 1 Threshold 2 20 21 22 23

qui intime au switch de placer dans la file 1 les paquets marqués DSCP = 20 21 22 23 et de leur appliquer le seuil 2 Enfin il faut différencier les deux seuils, représentant la probabilité de rejets, en assignant au seuil 2 un valeur supérieure à celle du seuil 1 : ( 50 et 70 dans ce cas)

lish02(config)#mls qos SRR-queue input threshold ? <1-2> enter threshold queue id (1-2) lish02(config)#mls qos SRR-queue input threshold 1 ? <1-100> enter percent of queue size for threshold 1 lish02(config)#mls qos SRR-queue input threshold 1 50 ? <1-100> enter percent of queue size for threshold 2 lish02(config)#mls qos SRR-queue input threshold 1 50 70

Ces deux seuils signifient que les paquets marqués DSCP = 0,1,2,3,4,5,6 seront rejetés dès que la file 1 sera remplie à 50% (seuil 1) alors que cette même file devra être remplie à 70% (seuil 2) avant de rejetter des paquets marqués DSCP = 20 21 22 23. Ceci peut être représenter de la sorte :


/68

JMJ

Figure 7: SRR : Seuils de rejets Vs remplissage de la file Question : Avec cette configuration, la file d’attente numéro 1 ne sera jamais remplie à plus de 70% puisque tous les paquets, selon les hypothèses de départ, sont marqués soit DSCP = 0,1,2,3,4,5,6 soit DSCP = 20,21,22,23 et seront donc comparés aux seuils 1 ou 2, jamais au seuil 3. Nota Bene : WTD se différencie de WRED en cela que WRED présente une fonction de rejet telle que représentée par le graphe ci-dessous :

Probabilité de rejet

Taux de remplissage de la file d‘attente 50 70 100

100

paquets marqués DSCP = 0,1,2,3,4,5,6

paquets marqués DSCP = 20,21,22,23


/68

JMJ

Figure 8: WRED : Seuils de rejets Vs remplissage de la file

6.6.5 File d’attente d’entrée par interface physique Précédant la file d’attente d’entrée, chaque interface physique (chaque port du switch), dispose d’une file d’attente qu’elle partage avec toutes ses sous-interfaces. Il convient de ne pas confondre ces deux files d’attente. En particulier Selective Packet Discard (SPD) s’applique à la file d’attente d’entrée par interface et non à la file d’attente d’entrée. SPD n’est pas un mécanisme de QoS en tant que telle. Les informations relatives à la file d’attente d’entrée par interface sont obtenues par la commande :

lish02#sho int Gi1/0/2 GigabitEthernet1/0/2 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 6c20.563c.bf02 (bia 6c20.563c.bf02) Description: lish901 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:55, output 00:00:00, output hang never Last clearing of "show interface" counters 2w2d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 20849 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 686000 bits/sec, 172 packets/sec 5 minute output rate 736000 bits/sec, 171 packets/sec 6701499 packets input, 2112904936 bytes, 0 no buffer

Probabilité de rejet

Taux de remplissage de la file d‘attente 50 70 100

100

paquets marqués DSCP = 0,1,2,3,4,5,6

paquets marqués DSCP = 20,21,22,23


/68

JMJ

Received 48892 broadcasts (24440 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 24440 multicast, 0 pause input 0 input packets with dribble condition detected 13441129 packets output, 6873380310 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out

Pour changer cette valeur :

lish02(config)#int Gi1/0/2 lish02(config-if)#hold-queue ? <0-4096> Queue length lish02(config-if)#hold-queue 80 ? in Input queue out Output queue lish02(config-if)#hold-queue 80 in

Nota Bene : Il est recommandé de ne pas diminuer cette valeur sous la valeur par défaut de 75. Les informations relatives à SPD sont obtenues par la commande :

lish02#sho ip spd Current mode: normal. Queue min/max thresholds: 73/74, Headroom: 100, Extended Headroom: 10 IP normal queue: 1, priority queue: 0. SPD special drop mode: none


/68

JMJ

6.7 Fonctions QoS sur le traffic sortant Chaque paquet transmit par une interface transite par un ou plusieurs tampons de sortie. Ces tampons permettent un stockage temporaire au cas ou l’interface doit transmettre plus de paquet que ce qui peut être transmis physiquement. Un switch ne rejette un paquet que lorsqu’il ne dispose plus de suffisemment de tampons de sortie pour entreposer temporairement ce paquet.

Figure 9:Fonctions QoS sur le traffic sortant Sur les switchs pris en exemple, les fonctionnalités de QoS supportées sont la gestion des congestions et leur évitemment. Comme pour le traffic entrant, la gestion et l’évitement des congestions est un processus en trois étapes qui sont :

• La mise en file d’attente (queueuing), • Le rejet (dropping) • Et l’ordonnancement (scheduling).

Sur les switchs pris en exemple, les tampons de sortie sont organisés en quatre files d’attente de sortie, chacune dotée de 3 seuils de rejets, accueillent les paquets à transmettre en fonctions de leurs QoS Labels. Deux jeux de quatre files d’attente de sortie sont configurables sur ces switchs. Comme pour le trafic entrant, le seuil de rejet numéro 3 est fixé à 100%, non modifiable. Attention : comme discuter ultérieurement cette notion de 100& est à prendre avec précaution, notamment si les 2 autres aeuils sont configurer au-delà de 100%. Pour chaque file d’attente de sortie il est possible de configurer

• sa taille (nombre de tampons) • sa réserve (nombre de tampons)


/68

JMJ

• sa taille maximale (nombre de tampons) • ses seuils de rejets (%)

WTD est utilisé pour gérer la taille de chaque file et permet de définir une hiérarchie dans le rejet des paquets, selon leur classification. Rappel : les files d’attente en entrée sont configurées de manière globale, pas par port. Les files d’attentes de sortie sont configurées par port, dans ce sens que pour chaque port il est possible de définir lequel des deux jeux de files d’attente de sortie s’appliquent à ce port. Chaque port ne peut pas être configuré différemment des autres ports, l’un des deux jeux de files d’attente de sortie s’applique à ce port, soit le jeu 1, soit le jeu 2. Les switchs pris en exemple partagent la quantité de tampons de sortie disponible en deux groupes : le groupe Common et le groupe Reserved. Quand une interface a consommé tous ses tampons réservés, elle cherche à puiser des tampons du groupe Common. Le nombre de tampons placé dans le groupe Common est égal au nombre total de tampons moins le nombre de tampons placés dans le groupe Reserved. A l’initialisation, IOS détermine pour chaque ASIC du switch le nombre de tampons réservés. Le rapport Reserved /Common varie de plateforme en plateforme et est modifiable par l’utilisateur. La quantité totale de tampons de sortie étant variable de plateforme en plateforme l’utilisateur n’a pas accès à des valeurs absolues, seulement à des pourcentages. Enfin, l’utilisateur ne peut modifier la quantité de tampons réservés pour une interface donnée, il ne peut que modifier la distribution de ces tampons par-delà les quatre files d’attente de sortie.

Figure 10: Allocations des tampons aux files d’attente de sortie Tout paquet placé dans une file d’attente doit être copié dans un ou plusieurs tampons de sortie avant que d’être transmis (voir paragraphe Erreur ! Source du renvoi introuvable. Erreur ! Source du renvoi introuvable. page Erreur ! Signet non défini.).

Les switchs pris en exemple mettent un œuvre un schéma d’allocation de tampons tel que un nombre minimum de tampons soient reservés à chacune des files d’attente de sortie de chaque interface. Ceci permet d’éviter qu’une file d’attente congestionnée ou qu’une interface congestionnée ne monopolise tous les tampons au détriment des autres files ou interfaces. Avant de placer un paquet dans une file d’attente, l’ASIC effectue plusieurs vérifications selon un schéma d’allocation qui détermine :

1. Si la file d’attente de sortie réceptrice du paquet dispose encore de suffisemment de tampons marqués Reserved pour permettre la transmission du paquet ET que le nombre total de tampons utilisés pour cette interface et cette file d’attente de sortie


/68

JMJ

est inférieur au seuil de rejet configuré, le paquet est mis en file d’attente en utilisant des tampons Reserved.

2. Sinon, y a-t-il assez des tampons Common de disponible pour ce paquet ? Si la

réponse est positive ET que le nombre total de tampons utilisés pour cette interface et cette file d’attente de sortie est inférieur au seuil de rejet configuré, le paquet est mis es file d’attente en utilisant des tampons Common.

3. Sinon le paquet est rejeté.

Ces files d’attentes de sortie sont vidées par SRR, qui dans le cas du trafic sortant, peut être configuré soit en mode sharing soit en mode shaping, contrairement au trafic entrant servi par un SRR en mode sharing uniquement, soit en mode limit. SRR en sortie est configuré par interface. Les seuils de rejets mentionnés ci-dessus sont à comprendre comme un nombre maximum de buffers alloués à une file d’attente de sortie ET une certaine classe de trafic. Comme nous le verrons plus loin dans ce document, avec seulement 4 files d’attente de sortie, il est innévitable que plusieurs classe de trafic utilisent la même file de d’attente de sortie. L’existence de 3 seuils de rejets par file d’attente apporte une granularité supplémentaire dans le traitement des différents classes de trafic. L’exemple suivant permet de résumer les fonctions QoS sur le trafic sortant : Soit un paquet P d’une taille telle que 5 tampons de file de sortie soient nécessaires à le contenir. Ce paquet est à destination de l’interface I ( interface Gi1/0/12 p. ex.). La classification de ce paquet le destine à la file d’attente de sortie #3,notée par la suite TxQ3, le seuil à appliquer est le Seuil1, noté par la suite S1TxQ3. Admettons que TxQ3 de l’interface I soit dotée d’une taille de 50 Tampons-Reserved. Admettons que S1TxQ3 soit positionné à 250 Tampons. Admettons qu’au moment ou le paquet arrive, TxQ3 utilise déjà tous les 50 Tampons-Reserved. Admettons que le nombre total de tampons consommés par toutes les TxQ3 soit de 230 tampons et qu’il reste 30 Tampons-Common de disponibles. Le paquet P est mis en file d’attente car y compris P, le nombre total de tampons consommés par toutes les TxQ3 sera de 230 + 5 = 235 (inférieur à 250) Nota Bene : ceci n’est qu’un exemple. Il n’est pas donné à l’utilisateur de fixer des valeurs absolues aux tailles et seuils, seulement des valeurs relatives, en pourcentage.

6.7.1 Sans QoS Une seule fille d’attente de sortie est disponible, sans seuils de rejet.

6.7.2 Files d’attente de sortie

Les paramètres par défaut de configuration conviennent à la majorité des situations. Il convient de modifier ces paramètres uniquement si le fonctionnement de ces files d’attente est parfaitement compris et que celui ne satisfait pas les paramètres de QoS souhaités.

6.7.2.1 Assignation d’une file de sortie en fonction du QoS Label Comme pour le trafic entrant, c’est le QoS Label qui détermine dans quelle file d’attente, un paquet sera traité, en fonction de la valeur du CoS ou du DSCP.

Par défaut cette assignation est réalisée de la sorte:

lish02#sho mls qos maps cos-output-q Cos-outputq-threshold map: cos: 0 1 2 3 4 5 6 7


/68

JMJ

------------------------------------ queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1 lish02#sho mls qos maps dscp-output-q Dscp-outputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------------------ 0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01 2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01 5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 6 : 04-01 04-01 04-01 04-01

Nota Bene : La file 1 est utilisée pour les paquets marqués CoS = 5 ou DSCP = 40 à 47. C’est la file prioritaire. Pour changer ces valeurs : par exemple pour attribuer la file 2 aux paquets marqués CoS = 5 :

lish02(config)#mls qos SRR-queue output cos-map queue 2 5 lish02#sho mls qos maps cos-output-q Cos-outputq-threshold map: cos: 0 1 2 3 4 5 6 7 ------------------------------------ queue-threshold: 2-1 2-1 3-1 3-1 4-1 2-1 4-1 4-1

6.7.2.2 Assignation d’une taille aux files de sortie La taille mémoire réservée à l’ensemble des quatre files de sortie n’est ni accessible ni modifiable.6

6 Voir aussi page 43 le chapitre 0Il semblerait que la taille de la mémoire allouée aux tampons de sortie ne soit pas extensible, quelque soit la valeur du maximum, celle-ci est limitée en interne : http://www.cisco.com/en/US/docs/switchs/lan/catalyst3750/software/release/12.2_50_se/command/reference/cli1.html While buffer ranges allow individual queues in the queue-set to use more of the common pool when available, the maximum number of packets for each queue is still internally limited to 400 percent, or 4 times the allocated number of buffers. One packet can use one 1 or more buffers.

Pourquoi 400%. Que se passe t il si buffers de la file 1 = 75% : il ne reste plus que 25% de mémoire disponible : comment atteindre 4 x 75%. ??? Encore un mystère… Mon interprétation : Quand il n’y à plus de buffers de sortie disponible, il n’y en à plus, quelque soit la valeur attribuée à maximum. On trouve souvent, par ex à l’URL http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml :" « Two queue sets are configured and queue set 1 is assigned to all the ports by default. Each queue is allocated

25 percent of the total buffer space. Each queue is reserved 50 percent of allocated buffer space which is 12.5

percent of the total buffer space. The sum of all the reserved buffers represents the reserved pool, and the

remaining buffers are part of the common pool. The default configuration sets 400 percent as the maximum

memory that this queue can have before packets are dropped. »


/68

JMJ

Le seul paramétrage possible consiste à définir, par file de sortie, la portion de cette mémoire qui lui est attribuée. De plus cette taille est dépendante de la version d’IOS. (http://puck.nether.net/pipermail/cisco-nsp/2009-March/058758.html et http://puck.nether.net/pipermail/cisco-nsp/2009-March/058761.html) Par défaut chaque file se voit attribuer un quart (25%) de cette taille

lish02#sho mls qos queue-set 1 Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400 lish02#sho mls qos queue-set 2 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400

Pour modifier ces valeurs :

lish02(config)#mls qos queue-set output ? <1-2> queue-set id lish02(config)#mls qos queue-set output 1 ? buffers assign buffers to each egress queue threshold Assign threshold values to a queue lish02(config)#mls qos queue-set output 1 buffers ? <0-99> enter buffer percentage for queue 1 0-99 lish02(config)#mls qos queue-set output 1 buffers 33 ? <1-100> enter buffer percentage for queue 2 1-100 (includes CPU buffer) lish02(config)#mls qos queue-set output 1 buffers 33 33 ? <0-99> enter buffer percentage for queue 3 0-99

Je pense que cette dernière phrase est inexacte (voir page 50 la Figure 12:File d’attente de sortie - 3 : maximum d’une file = 12,5% + 50% = 62.5%), mais du coup je ne comprends pas la configuration par défaut, que je ne peux imaginer fausse. A moins que ???

Considérations chiffrées


/68

JMJ

lish02(config)#mls qos queue-set output 1 buffers 33 33 33 ? <0-99> enter buffer percentage for queue 4 0-99 lish02(config)#mls qos queue-set output 1 buffers 33 33 33 33 The Sum should be equal to 100 percent

6.7.2.3 Seuils de rejet Par défaut, les 3 seuils de rejet de toutes les files d’attente de sortie sont positionnés tel que dans le tableau ci dessous. Ma compréhension d’un seuil 3 dont la valeur est figée à 100% est la suivante : Le seuil 3 n’est pas altérable, sa valeur est figée à « File pleine », soit à une valeur correspondant à la ligne « maximum » du tableau ci dessous.

lish02#sho mls qos queue-set 1 Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400 lish02#sho mls qos queue-set 2 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400

Table 9: Seuils de rejets par défaut Pour modifier ces valeurs :

lish02(config)#mls qos queue-set output 1 threshold ? <1-4> enter queue id in this queue set lish02(config)#mls qos queue-set output 1 threshold 1 ? <1-3200> enter drop threshold1 1-3200 lish02(config)#mls qos queue-set output 1 threshold 1 50 ? <1-3200> enter drop threshold2 1-3200 lish02(config)#mls qos queue-set output 1 threshold 1 50 75 ? <1-100> enter reserved threshold 1-100 lish02(config)#mls qos queue-set output 1 threshold 1 50 75 33 ? <1-3200> enter maximum threshold 1-3200 lish02(config)#mls qos queue-set output 1 threshold 1 50 75 33 444 ? <cr>

Nota Bene : La valeur maximale des seuils de rejet est de 3200%. Sachant que le seuil 3 est fixé et figé à 100%, pourquoi permettre de fixer aux seuils des valeurs supérieures à 100 % ? Réponse : Le seuil 3 doit être considéré comme « file pleine » (maximum) plutôt que 100%. Les paramètres reserve threshold et maximum threshold seront abordés ultérieurement.


/68

JMJ

6.7.2.4 Assignation d’un des deux jeux de file d’attente à une interface

Par défaut, les switches pris en exemple assignent le jeu de files d’attente de sortie numéro 1 à tous les ports. Pour modifier cette assignation

lish02(config)#interface gi 1/0/1 lish02(config-if)#queue-set ?

<1-2> the qset to which this port is mapped

lish02(config-if)#queue-set 2

6.7.2.5 Ordonnanceur de sortie. (SRR) Il est fondamental de se souvenir que l’ordonnanceur de sortie est configuré par interface. L’ordonnanceur de sortie est configurable selon 3 modes qui sont :

• BP partagée ( bandwidth share) • BP fluidifiée (bandwidth shape) • BP limitée (bandwidth limit)

Il est aussi possible de configurer la file d’attente de sortie numéro 1 en tant que file prioritaire. Voir page 46 chapitre 6.7.2.5.4 File prioritaire. Nota Bene : Les limitations de BP réalisées par l’ordonnanceur de sortie s’applique à la bande passante de l’interface physique (du port), par exemple 100 Mb/s, et non comme pour le SSR en entrée à la bande passante de l’Internal Ring.

lish01(config)#int Gi1/0/12 lish01(config-if)#srr-queue bandwidth ? limit Configure bandwidth-limit for this interface shape Configure shaping on transmit queues share Configure shared bandwidth lish01(config-if)#priority-queue ? out egress priority queue lish01(config-if)#priority-queue out

6.7.2.5.1 Limit Il est possible de limiter la bande passante d’une interface à une certaine valeur (en %) par la commande suivante :

lish01(config)#int Gi1/0/12 lish01(config-if)#srr-queue bandwidth limit ? <10-90> enter bandwidth limit for interface as percentage

En fait la valeur retenue par le switch sera le multiple de six le plus proche de la valeur entrée.

6.7.2.5.2 Shape

lish01(config)#int Gi1/0/12 lish01(config-if)#srr-queue bandwidth shape ? <0-65535> enter bandwidth weight for queue id 1


/68

JMJ

lish01(config-if)#srr-queue bandwidth shape 50 ? <0-65535> enter bandwidth weight for queue id 2 lish01(config-if)#srr-queue bandwidth shape 50 40 ? <0-65535> enter bandwidth weight for queue id 3 lish01(config-if)#srr-queue bandwidth shape 50 40 8 ? <0-65535> enter bandwidth weight for queue id 4 lish01(config-if)#srr-queue bandwidth shape 50 40 8 4

Dans ce mode, les valeurs absolues de ces paramètres ont leur importance, ce sont ces valeurs qui définissent la bande passante allouée à chacune de files d’attente. Dans cet exemple, la bande passante est partagée de la sorte : File 1 : 1 / 50 = 2% File 2 : 1 / 40 = 2.5 % File 3 : 1 / 8 = 12.5 % File 4 : ¼ = 25 % Ne pas oublier qu’en mode shaped, la BP est garantie et limitée : la configuration ci-dessus ne permet qu’une utilisation maximale à 25+12.5+2.5+2 = 42% de la BP totale. Une valeur nulle attribuée à ce paramètre configure la fille d’attente relative à ce paramètre en mode shared.

lish01(config-if)#srr-queue bandwidth shape 8 1 0 0 The total bandwidth exceeds 1, Please choose new value QoS: cannot set queue into shaping mode

6.7.2.5.3 Share

lish01(config-if)#srr-queue bandwidth share ? <1-255> enter bandwidth weight for queue id 1 lish01(config-if)#srr-queue bandwidth share 10 ? <1-255> enter bandwidth weight for queue id 2 lish01(config-if)#srr-queue bandwidth share 10 20 ? <1-255> enter bandwidth weight for queue id 3 lish01(config-if)#srr-queue bandwidth share 10 20 40 ? <1-255> enter bandwidth weight for queue id 4 lish01(config-if)#srr-queue bandwidth share 10 20 40 80 ? <cr>

Comme pour les files d’attente en entrée, les valeurs absolues de ces paramètres sont sans importance, c’est leur rapport qui définit le rapport des bandes passantes allouées à chacune de files d’attente. Dans cet exemple, la file 4 se voit octroyer 8 fois la BP de la file1, 4 fois celle de la file 2 et 2 fois de la file 3. File 1 : 10 / (10 + 20 + 40 + 80) File 2 : 20 / (10 + 20 + 40 + 80) File 3 : 40 / (10 + 20 + 40 + 80) File 4 : 80 / (10 + 20 + 40 + 80) Le dénominateur est commun à chacun des rapports de BP => le rapport des BP de chacune des files est le rapport des dénominateurs :


/68

JMJ

��3�

��2�=

4010 + 20 + 40 + 80

2010 + 20 + 40 + 80

= 40

20= 2

6.7.2.5.4 File prioritaire Une file d’attente peut être configurée en tant que file prioritaire (aussi appellée expedite dans certains documents). La file prioritaire sera toujours la file 1 sur les switchs pris en exemple. Pour servir cette file d’attente prioritaire, une priorité stricte s’applique (contrairement à la file prioritaire en entrée), et cette file sera servie par SSR tant qu’elle n’est pas vide : SRR videra cette file avant de chercher à vider les 3 autres files. La file 1 est configurée comme file prioritaire sur une interface par la commande : priority-queue out.

mgth03#sho mls qos interface fa0/12 queueing FastEthernet0/12 Egress Priority Queue : disabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1 mgth03#conf t Enter configuration commands, one per line. End with CNTL/Z. mgth03(config)#int fa0/12 mgth03(config-if)#priority-queue ? out egress priority queue mgth03(config-if)#priority-queue out mgth03(config-if)#end mgth03#sho mls qos interface fa0/12 queueing FastEthernet0/12 Egress Priority Queue : enabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1

Dans cet exemple, pour l’interface Fa0/12 et uniquement pour cette interface, la file d’attente 1 est la file prioritaire. Les paramètres des modes shape et share sont simplement ignorés pour cette interface. Il est donc impossible de limiter la BP d’une file prioritaire. Avec les paramètres du chapitre précedent, et la file 1 configurée prioritaire,

srr-queue bandwidth share 10 20 40 80

le dénominateur pour l’interface configurée devient 20+40+80 = 140. ( la valeur 10 de la file d’attente de sortie 1 est simplement ignorée) La somme des numérateurs conduit aussi à 140 , soit BP(f2+f3+f4) = 1, sachant qu’une partie de la BP à déjà été consommée par la file 1. Ma représentation de ce mécanisme : Une fois la file prioritaire vidée, SSR pour cette interface videra les file 2,3,4 dans un ordre garantissant le respect de ce proportions. Dans cet exemple, 14 « vidages » par SRR viderons les files, que nous assumerons remplies, selon le schéma Tour 1 f2,f3,f4 Tour 2 f2,f3,f4


/68

JMJ

Tour 3 f3,f4,f4 Tour 4 f3,f4,f4 Tour 5 f4,f4, ? Avec ? = f2 afin de recommencer la même séquence de vidage. Ceci n’est qu’une hypothèse. Le fait de configurer la file 1 comme file prioritaire pour une interface ne change en rien le nombre de buffer qui lui sont attribués, ses seuils de rejet, sa taille reservée ni sa taille maximum.

6.7.3 Configuration par défaut. Représentation graphique Le resultat des commandes précédantes permet une représentation graphique de la configuration par défaut des files d’attente de sortie des switchs pris en exemple. Comme SSR est configuré par interface, la commande suivante est nécessaire pour représenter correctement le configuration relative à une interface.

lish01#sho mls qos interface Gi1/0/12 queueing GigabitEthernet1/0/12 QoS is disabled. When QoS is enabled, following settings will be applied Egress Priority Queue : disabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1

lish02#sho mls qos interface Gi1/0/12 queueing GigabitEthernet1/0/12 Egress Priority Queue : disabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1

mgth03#sho mls qos interface Fa0/12 queueing FastEthernet0/12 Egress Priority Queue : disabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1

La représentation graphique en résultant peut être la suivante :


/68

JMJ

Explications concernant la file 1 : Les quatre files d’attente de sortie sont servies par SRR, tant que la la file prioritaire n’est pas validée. Dans le cas de la validation de celle-ci, la première pondération est ignorée (toutes les pondérations relatives à la file 1 sont ignorées) et non utilisée dans le calcul du rapport des BP. Dans notre exemple cette file prioritaire n’est pas validée. Rappel : La pondération en mode shaped prévaut sur la pondération en mode shared.

lish02#sho mls qos interface Gi1/0/12 queueing GigabitEthernet1/0/12 Egress Priority Queue : disabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1

Dans ce cas, la file d’attente numéro 1 se voit octroyer un maximum de 1/25 = 4% de la BP. Chacune des autres files étant configurée en mode shared, elles se voient attribuer au moins 25% de la BP.

Figure 11: Files d’attente de sortie - 1

Internal Ring ou Stack Ring

SRR Queue-Map

Port de Sortie SRR

File 4

File 3

File 2

File 1

100%

Internal Ring ou Stack Ring


/68

JMJ

lish02#sho mls qos queue-set 1 Queueset: 1 Queue : 1 2 3 4 ------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400

Common Pool

Reserved Pool

Mémoire allouée aux files d’attente de sortie = Ensemble des buffers de sortie disponibles = X (par port)

Queue Set 1 S1 = Seuil 1 S2 = Seuil 2

Y = Buffers alloués pour la file 1 = 25 % de X

Reserved = 50 % de Y

S1 = S2 = 100% de Y

File 1

Maximum = 400% de Y


S1 = S2 = 100% de Y

File 2

Maximum = 400% de Y


S1 = S2 = 100% de Y

File 3

Maximum = 400% de Y


S1 = S2 = 100% de Y

File 4

Maximum = 400% de Y





/68

JMJ

Ou encore :

Figure 12: File d’attente de sortie - 3 Explications : Chacune des 4 files se voit allouer 25% de la taille totale de la mémoire allouée aux buffers de sortie. Uniquement 50% de cette taille est réservée, soient 12.5 % , les autres 50% sont versés au Common Pool qui est bien sur de la mémoire allouée aux buffers de sortie, mais non encore attribuée à une file. Les seuils s’appliquent à la mémoire allouée, non à la mémoire reservée : Dans le cas de cet exemple, les seuils seront franchis quand 100% des 25% alloués seront consommés. ATTENTION : Néanmoins, comme la mémoire réservée est de 50% de la mémoire allouée, quand cette valeur est dépassée, la file doit « demander » d’autre(s) buffer(s) au pool commun. Il se peut que celui-ci soit vide à ce moment, et le rejet des paquets pourra débuter dès que la file sera remplie à 50%. Prenon un autre exemple pour mieux illustrer cela avec des valeurs différentes :

mgth03(config)#mls qos queue-set output 2 threshold 4 20 50 67 400 mgth03(config)#mls qos queue-set output 2 buffers 10 10 26 54 mgth03#sho mls qos queue-set 2 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 10 10 26 54 threshold1: 1111 200 100 20 threshold2: 2222 200 100 50 reserved : 98 50 50 67 maximum : 3000 400 400 400 mgth03#


/68

JMJ

Dans cet exemple, la file 4 réserve 67% des 54% des tampons de sortie qui lui sont alloués. La file 4 demandera des buffers au Common Pool lorsqu’elle utilisera tous ces 67%. Il lui est autorisé de croitre jusqu’à 400% de ces 54% alloués. (J’en doute : voir les questions ci-dessous)

• Le seuil 1 est fixé à 20% : dès que 20% des tampons de sortie alloués seront utilisés, les paquets remplissants les conditions de rejets à ce seuil seront rejetés :

o Seuil 1 = 0.2 x 0.54 la taille totale de la mémoire allouée aux buffers de sortie.

• Le seuil 2 est fixé à 50% : dès que des tampons de sortie alloués seront utilisés, les paquets remplissants les conditions de rejets à ce seuil seront rejetés :

o Seuil 2 = 0.5 x 0.54 la taille totale de la mémoire allouée aux buffers de sortie.

• Le seuil 3 est figé à 100% : avec une réservation à 67% il est possible que les paquets remplissants les conditions de rejets à ce seuil ( paquets marqués Q4T3) soit rejetés dès que 67% des tampons de sortie alloués seront utilisés ( pas de tampons disponibles du Common Pool),

o Seuil 3 « potentiel » = 0.67 x 0.54 la taille totale de la mémoire allouée aux buffers de sortie.

• Attention le seuil 3, selom ma compréhension ne s’applique pas au tampons de sortie alloués, mais à la valeur de la ligne « maximum ».

Un maximum de 400% correspond à une file qui prend toute la mémoire allouée aux buffers de sortie, au détriment de toute les autres files. Questions :

1. Quand les seuils peuvent atteindre 3200 d’où vient la mémoire ? Sous quelles condition cette mémoire est elle disponible ?

2. Sachant que le seuil 3 est figé et fixé à 100% pourquoi permettre de fixer aux seuils 1 et 2 des valeurs supérieures à 100% %. Le seuil 3 rejettera les paquets bien avant les seuils 2 et/ou 3.

mgth03(config)#mls qos queue-set output 2 threshold 1 1111 2222 98 3000 mgth03#sho mls qos queue-set 2 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 1111 200 100 100 threshold2: 2222 200 100 100 reserved : 98 50 50 50 maximum : 3000 400 400 400

Il semblerait que la taille de la mémoire allouée aux tampons de sortie ne soit pas extensible, quelque soit la valeur du maximum, celle-ci est limitée en interne : http://www.cisco.com/en/US/docs/switchs/lan/catalyst3750/software/release/12.2_50_se/command/reference/cli1.html While buffer ranges allow individual queues in the queue-set to use more of the common pool when available, the maximum number of packets for each queue is still internally limited to 400 percent, or 4 times the allocated number of buffers. One packet can use one 1 or more buffers.

Pourquoi 400%. Que se passe t il si buffers de la file 1 = 75% : il ne reste plus que 25% de mémoire disponible : comment atteindre 4 x 75%. ??? Encore un mystère… Mon interprétation : Quand il n’y à plus de buffers de sortie disponible, il n’y en à plus, quelque soit la valeur attribuée à maximum.


/68

JMJ

On trouve souvent, par ex à l’URL http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml :" « Two queue sets are configured and queue set 1 is assigned to all the ports by default. Each queue is allocated

25 percent of the total buffer space. Each queue is reserved 50 percent of allocated buffer space which is 12.5

percent of the total buffer space. The sum of all the reserved buffers represents the reserved pool, and the

remaining buffers are part of the common pool. The default configuration sets 400 percent as the maximum

memory that this queue can have before packets are dropped. »

Je pense que cette dernière phrase est inexacte (voir page 50 la Figure 12:File d’attente de sortie - 3 : maximum d’une file = 12,5% + 50% = 62.5%), mais du coup je ne comprends pas la configuration par défaut, que je ne peux imaginer fausse. A moins que ???


/68

JMJ

6.7.3.1 Considérations chiffrées

6.7.3.1.1 Hold queue Le mécanisme SSR vide une file d’attente non pas directement vers une interface de sortie mais vers un tampon intermédiare par interface de sortie. Ce tampon intermédiare est la hold-queue vue ci-dessous, appelé par la suite « tampons de sortie d’une interface ». Le nombre de tampons intermédiare s de sortie d’une interface est de 40 buffers. Chaque buffer à une taille de 256 octets.

mgth03#sho int fa0/20 FastEthernet0/20 is up, line protocol is up (connected) - - Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) =>> Le nombre de tampons intermédiaire de sortie - -

Pour changer la taille révélée par cette commande, il faut :

mgth03(config)#int fa0/20 mgth03(config-if)#hold-queue 4096 out mgth03#sho int fa0/20 FastEthernet0/20 is up, line protocol is up (connected) - - Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/4096 (size/max)

Nota Bene : Il n’est jamais judicieux d’augmenter la hold queue pour éviter des output drops. En effet, cette augmentation aura pour effet potentiel de ralonger le temps entre l’émission du paquet et sa reception, pouvant conduire à des time-out de TCP amenant l’émeteur à re-envoyer un paquet en cours d’acheminement, congestionnant encore d’avantage le réseau. Nota Bene 2 : Que se soit pour les files d’attente d’entrée ou de sortie, celles-ci sont dimensionnées en tampons (buffers), pas en paquets. En admettant qu’un buffer soit de taille 256 octets, un paquet de taille N nécessitera 1 + partie entière(N/256) buffers dans une des files d’entrée et une des files de sortie. La commande suivante nous révèle que le nombre maximum des tampons intermédiaires de sortie, pour l’interface considérée (comme pour toutes les interfaces qu’elles soient physiques (Fa, Gi,…) ou logiques (VLANs y compris le VLAN1) ) est de 40 tampons par défaut. Un tampon est dimensionné à 256 octets. 40 x 256 octets = 10 koctets. Sur une interface à 100 Mb/s il faut 0.8192 ms pour transmettre 10ko ou 20,48 us pour transmettre un tampon de 256 octets.

mgth03#sho int fa0/20 FastEthernet0/20 is up, line protocol is up (connected) - - Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) - -

Soit la configuration suivante : ( MLS QOS est activé)


/68

JMJ

mgth03#sho mls qos queue-set Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 1 2 3 94 threshold1: 1111 200 100 20 threshold2: 2222 200 100 50 reserved : 98 50 50 100 maximum : 3000 400 400 3195

Le nombre de tampons attribués à une interface n’est pas altérée, que cette interface utilise le jeu 1 ou le jeu 2 : Quand cette interface utilise le jeu 1 ( par défaut) :

mgth03#sho int fa0/20 FastEthernet0/20 is up, line protocol is up (connected) - - Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) - -

Quand cette interface utilise le jeu 2 :

mgth03(config)#int fa0/20 mgth03(config-if)#queue-set 2 mgth03#sho int fa0/20 - - Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) - -

Questions : 1) Si l’on augmente la valeur reserved d’une file d’attente et/ou le maximum,

pourquoi la taille de la « Output Queue » des interfaces n’est elle pas modifiée ? Réponse : dans un cas l’on définit les tampons d’une file d’attente, et dans l’autre cas des tampons intermédiaires propres à une interface. Les tampons de l’output queue d’une interface ne soient pas comptabilisés en tant que tampons d’une file d’attente.

2) Est-ce que les 40 tampons de l’output queue d’une interface suffisent à garantir, sur une interface donnée, que la BP de cette interface soit atteinte et maintenue sur une longue periode, disons 1 seconde. Il m’est clair ici qu’un seul tampon de sortie par interface suffit à garantir la BP de l’interface, à la condition indispensable que SRR « remplisse » ce tampon toute les 20,48 us pour une interface à 100 Mb/s, ou 2,048 us pour une interface à 1 Gb/s. La question induite est donc à quelle vitesse maximale SSR peut il « remplir » l’output queue d’une interface ?


/68

JMJ

6.8 Commandes utiles Ce chapitre regroupe les commandes utilisées dans ce document qui permettent de retrouver des informations quant à la configuration de l’équipement relativement à la QoS.

6.8.1 QoS active ?

lish01#sho mls qos QoS is disabled QoS ip packet dscp rewrite is enabled

6.8.2 Quel CoS vers quelle file d’entrée

lish01#sho mls qos maps cos-input-q Cos-inputq-threshold map: cos: 0 1 2 3 4 5 6 7 ------------------------------------ queue-threshold: 1-1 1-1 1-1 1-1 1-1 2-1 1-1 1-1

6.8.3 Quel DSCP vers quelle file d’entrée

lish01#sho mls qos maps dscp-input-q Dscp-inputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------------------ 0 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 1 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 2 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 3 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 4 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01 5 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 6 : 01-01 01-01 01-01 01-01

6.8.4 Taille, bande passante et seuils des files d’entrés

lish01#sho mls qos input-queue Queue : 1 2 ---------------------------------------------- buffers : 90 10 bandwidth : 4 4 priority : 0 10 threshold1: 100 100 threshold2: 100 100 lish01#sho mls qos interface Gi1/0/12

6.8.5 Comment est configurée une interface donnée

lish01#sho mls qos interface Gi1/0/12 GigabitEthernet1/0/12 QoS is disabled. When QoS is enabled, following settings will be applied Attached policy-map for Ingress: policy-QoS trust state: not trusted trust mode: not trusted trust enabled flag: ena COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map Trust device: none


/68

JMJ

qos mode: port-based

6.8.6 Configuration de l’équipement pour une interface donnée

lish01#sho int Gi1/0/12 capabilities GigabitEthernet1/0/12 Model: WS-C3750X-48P Type: 10/100/1000BaseTX Speed: 10,100,1000,auto Duplex: half,full,auto Trunk encap. type: 802.1Q,ISL Trunk mode: on,off,desirable,nonegotiate Channel: yes Broadcast suppression: percentage(0-100) Flowcontrol: rx-(off,on,desired),tx-(none) Fast Start: yes QoS: yes Inline power: yes SPAN: source/destination PortSecure: yes scheduling: rx-(not configurable on per port basis), tx-(4q3t) (3t: Two configurable values and one fixed.) CoS rewrite: yes ToS rewrite: yes UDLD Dot1x: yes

Avec la QoS validée et la file prioritaire activée, cette commande retourne les mêmes valeurs alors que je m’attendais a voir 1P3Q3T. Encore un mystère…

lish01(config)#mls qos lish01(config)#end lish01#sho int Gi1/0/12 capabilities GigabitEthernet1/0/12 Model: WS-C3750X-48P Type: 10/100/1000BaseTX Speed: 10,100,1000,auto Duplex: half,full,auto Trunk encap. type: 802.1Q,ISL Trunk mode: on,off,desirable,nonegotiate Channel: yes Broadcast suppression: percentage(0-100) Flowcontrol: rx-(off,on,desired),tx-(none) Fast Start: yes QoS scheduling: rx-(not configurable on per port basis), tx-(4q3t) (3t: Two configurable values and one fixed.) CoS rewrite: yes ToS rewrite: yes UDLD: yes Inline power: yes SPAN: source/destination PortSecure: yes Dot1x: yes lish01#conf t lish01(config)#int Gi1/0/12 lish01(config-if)#priority-queue out lish01(config-if)#end lish01#sho int Gi1/0/12 capabilities GigabitEthernet1/0/12 Model: WS-C3750X-48P Type: 10/100/1000BaseTX Speed: 10,100,1000,auto Duplex: half,full,auto Trunk encap. type: 802.1Q,ISL Trunk mode: on,off,desirable,nonegotiate


/68

JMJ

Channel: yes Broadcast suppression: percentage(0-100) Flowcontrol: rx-(off,on,desired),tx-(none) Fast Start: yes QoS scheduling: rx-(not configurable on per port basis), tx-(4q3t) (3t: Two configurable values and one fixed.) CoS rewrite: yes ToS rewrite: yes UDLD: yes Inline power: yes SPAN: source/destination PortSecure: yes Dot1x: yes lish01#sho run int gi1/0/12 Building configuration... Current configuration : 405 bytes ! interface GigabitEthernet1/0/12 description lisg200 NAC Disa switchport access vlan 331 switchport mode access priority-queue out snmp trap mac-notification change added snmp trap mac-notification change removed no mdix auto spanning-tree portfast spanning-tree bpduguard enable lacp port-priority 500 channel-group 20 mode passive service-policy input policy-QoS hold-queue 4096 out end

6.8.7 Quel CoS vers quelle file de sortie

lish01#sho mls qos maps cos-output-q Cos-outputq-threshold map: cos: 0 1 2 3 4 5 6 7 ------------------------------------ queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1

6.8.8 Quel DSCP vers quelle file de sortie

lish01#sho mls qos maps dscp-output-q Dscp-outputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------------------ 0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01 2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01 5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 6 : 04-01 04-01 04-01 04-01


/68

JMJ

6.8.9 Comment sont configurées les files d’attente de sortie par jeu

mgth03#sho mls qos queue-set 1 Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400 mgth03#sho mls qos queue-set 2 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 1 2 3 94 threshold1: 1111 200 100 20 threshold2: 2222 200 100 50 reserved : 98 50 50 100 maximum : 3000 400 400 3195

6.8.10 Quel jeu pour quelle interface

lish01#sho run int Gi1/0/11 Building configuration... Current configuration : 392 bytes ! interface GigabitEthernet1/0/11 description Faci100-Jmon_NAC switchport access vlan 330 switchport mode access speed 100 duplex full snmp trap mac-notification change added snmp trap mac-notification change removed no mdix auto no cdp enable no cdp tlv server-location no cdp tlv app spanning-tree portfast spanning-tree bpduguard enable service-policy input policy-QoS end lish01#conf t Enter configuration commands, one per line. End with CNTL/Z. lish01(config)#int gi1/0/11 lish01(config-if)#queue-set 2 lish01#sho run int Gi1/0/11 Building configuration...


/68

JMJ

Current configuration : 405 bytes ! interface GigabitEthernet1/0/11 description Faci100-Jmon_NAC switchport access vlan 330 switchport mode access speed 100 duplex full queue-set 2 snmp trap mac-notification change added snmp trap mac-notification change removed no mdix auto no cdp enable no cdp tlv server-location no cdp tlv app spanning-tree portfast spanning-tree bpduguard enable service-policy input policy-QoS

ou

lish01#sho mls qos interface buffers GigabitEthernet1/0/1 QoS is disabled. When QoS is enabled, following settings will be applied The port is mapped to qset : 1 The allocations between the queues are : 25 25 25 25

ou

lish01#sho mls qos interface queueing GigabitEthernet1/0/1 QoS is disabled. When QoS is enabled, following settings will be applied Egress Priority Queue : disabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1

6.8.11 SRR en sortie pour une interface donnée

lish01#sho mls qos interface Gi1/0/12 queueing GigabitEthernet1/0/12 QoS is disabled. When QoS is enabled, following settings will be applied Egress Priority Queue : disabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 1

6.8.12 Rejets pour une interface donnée. Par file d’attente

lish01#sho platform port-asic stats drop Gi1/0/12 Interface Gi1/0/12 TxQueue Drop Statistics Queue 0 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 1


/68

JMJ

Weight 0 Frames 388914 Weight 1 Frames 0 Weight 2 Frames 0 Queue 2 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 3 Weight 0 Frames 6950195 Weight 1 Frames 0 Weight 2 Frames 1941365 Queue 4 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 5 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 6 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 7 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0

Tiens donc, nous voila avec 7 files d’attente…

6.8.13 Rejets par interface. Rejets globaux

lish02#sho int Gi1/0/12 summary *: interface is up IHQ: pkts in input hold queue IQD: pkts dropped from input queue OHQ: pkts in output hold queue OQD: pkts dropped from output queue RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec) TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec) TRTL: throttle count Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL ------------------------------------------------------------------------- * GigabitEthernet1/0/12 0 0 0 0 4726000 418 115000 217 0

6.8.14 Distibution des paquets émis et recus en fonction des DSCP

lish02#sho mls qos int Gi1/0/12 statistics GigabitEthernet1/0/12 (All statistics are in packets) dscp: incoming ------------------------------- 0 - 4 : 2815904864 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 5371554 0 0 0 30 - 34 : 0 0 2 0 0


/68

JMJ

35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 0 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 dscp: outgoing ------------------------------- 0 - 4 : 211022279 0 0 0 16446 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 128499565 0 0 0 30 - 34 : 0 0 399275 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 6989883 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 cos: incoming ------------------------------- 0 - 4 : 2821343367 0 0 0 0 5 - 7 : 0 0 0 cos: outgoing ------------------------------- 0 - 4 : 1307713780 0 0 128499565 399275 5 - 7 : 0 6989882 5731251 output queues enqueued: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 2 0 0 queue 1: 862804894 921 5731435 queue 2: 125077051 0 0 queue 3: 5434008 0 450289424 output queues dropped: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 1974 0 0 queue 2: 242 0 0 queue 3: 300 0 2266 Policer: Inprofile: 0 OutofProfile: 0

6.8.15 A exploiter

lish01#sho platform pm if-numbers interface gid gpn lpn port slot unit slun port-type lpn-idb gpn-idb ---------------------------------------------------------------------- Gi1/0/1 1 1 1 1/1 1 1 1 local Yes Yes Gi1/0/2 2 2 2 1/0 1 2 2 local Yes Yes Gi1/0/3 3 3 3 1/3 1 3 3 local Yes Yes Gi1/0/4 4 4 4 1/2 1 4 4 local Yes Yes Gi1/0/5 5 5 5 1/5 1 5 5 local Yes Yes Gi1/0/6 6 6 6 1/4 1 6 6 local Yes Yes Gi1/0/7 7 7 7 1/9 1 7 7 local Yes Yes etc etc lish01#


/68

JMJ

lish01#sho platform sf-asic egress-buf-info Egress Buffer Information ========================= Port VN Queue Head Tail CurQ Drain Fill Empty DrainActive ==== == ===== ========== ========== ==== ===== ==== ===== =========== 0 0 0 0x00000000 0x00000000 0 1 1 1 0 0 0 1 0x0000083C 0x0000083C 0 1 1 1 0 0 0 2 0x00000C29 0x00000C29 0 1 1 1 0 0 0 3 0x00000B48 0x00000B48 0 1 1 1 0 0 1 0 0x00000000 0x00000000 0 1 1 1 0 0 1 1 0x00000135 0x00000135 0 1 1 1 0 0 1 2 0x000009B9 0x000009B9 0 1 1 1 0 0 1 3 0x0000030F 0x0000030F 0 1 1 1 0 etc etc

lish01#sho platform sf-asic stat counters


/68

JMJ

ANNEXES


/68

JMJ

7 SRR

SRR remplace WRR (Weighted Roud Robin) sur quasiment toutes les plateformes lorsqu’il s’agit de définir comment vider une file d’attente. SRR et WRR pondèrent tous les deux les files d’attente, la différence majeure résidant dans la façon d’ordonnancer la façon d’extraire des paquets des files d’attente, permettant à SRR de shaper à une certaine valeur le trafic en sortie. La différence essentielle est représentée dans le schéma ci-dessous : Les pondérations sont respectées dans les 2 cas. Il y a bien toujours quatre paquets de la file 3 pour deux paquets de la file 2 et un paquet de la file 1.

Figure 13: SRR Versus WRR Deux modes de fonctionnement de SRR sont possibles :

• Shaped : uniquement sue les files d’attente de sortie • Shaped : les les files d’attente d’entrée et/ou de sortie

Les files d’attente de sortie en mode shaped se réservent une partie de la bande passante du port et émettent leurs paquets régulièrement espacés dans le temps. Ce mode définit à la fois une bande passante garantie et maximale. En mode shared, les files d’attente se voient aussi attribuer une bande passante garantie, mais celle est un minimum en ce sens que si une file prioritaire est vide, SRR n’attend pas que le temps (bande passante) imparti à cette file soit écoulé, mais attribue celui-ci à la file de priorité immédiatement inférieure. Le mode shared est celui délivrant la meilleure efficacité du système de file d’attente, les bandes passante inutilisées par une des files pouvant être réalloués à d’autres files d’attente. Ceci n’est pas possible avec WRR.


/68

JMJ

8 File d’attente

La mise en file d’attente est un moyen de séquencer des paquets avant de les transmettre, soit en interne (entre les files d’entrées et celles de sortie), ou vers l’extérieur. Dans le cas le plus simple les paquets sont transmis dans leur ordre d’arrivée, selon le principe FIFO, sans favoriser certains types de paquet au détriment d’autres types. Tout autre mécanisme que FIFO augmentera les délais de transmission d’un paquet sur le réseau, celui-ci devant être analysé et traité en fonction de critères configurés sur l’équipement. Une vision très simple de la mise en file d’attente est un ré-ordonnancement des paquets entre leur réception et leur émission. Il est important de se souvenir que la mise en file d’attente n’est nécessaire que si le trafic rencontre des difficultés à « traverser » l’équipement. Si ce n’est pas le cas (absence de rejets (drops) ou de congestion), le plus judicieux est de ne rien changer et de conserver les paramètres par défaut. La mise en file d’attente n’augmente pas la bande passante disponible. Elle ne fait que respecter la chronologie d’émission des paquets dictée par l’entreprise qui la met en œuvre et repose sur une hiérarchisation des applications de l’entreprise : quelqu’un doit définir cette hiérarchie.


/68

JMJ

9 Cisco IP Phone

http://www.cisco.com/en/US/docs/switchs/lan/catalyst6500/ios/12.2SX/configuration/guide/voip.pdf trafic voix

switch : Page 3 :


/68

JMJ

10 Liens

http://www.cisco.com/en/US/products/hw/switchs/ps5023/products_tech_note09186a0080883f9e.shtml http://www.cisco.com/en/US/docs/switchs/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swqos.html http://en.wikipedia.org/wiki/Token_bucket http://fr.wikipedia.org/wiki/Seau_%C3%A0_jetons http://en.wikipedia.org/wiki/Congestion_avoidance#Avoidance https://learningnetwork.cisco.com/thread/10679 http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpolsh.html http://rizzitech.blogspot.ch/2010/08/qos-on-cisco-3560-diagram.html http://www-r2.u-strasbg.fr/~pansiot/enseignement/RMM/QoS-3560.pdf http://www.davidsudjiman.info/2012/02/19/cisco-3560-mls-qos-part-2/ http://blog.ine.com/2008/06/26/quick-notes-on-the-3560-egress-queuing/ http://3.bp.blogspot.com/_B1VhU8NS9VM/TGUm56683ZI/AAAAAAAAGWE/Ck8ZiqmeYhs/s1600/3560-QoS-diagram.jpg http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconav_ps1835_TSD_Products_Configuration_Guide_Chapter.html https://supportforums.cisco.com/docs/DOC-8093 http://www.cisco.com/en/US/docs/solutions/Verticals/Education/SRA_Schools/SchoolSRA_QoS_sba.pdf http://www.cisco.com/en/US/prod/collateral/switchs/ps5718/ps708/prod_white_paper0900aecd803e5269.html http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml http://www.cisco.com/en/US/prod/collateral/switchs/ps5718/ps7078/prod_qas0900aecd805bacc7.html http://ccienet.wordpress.com/2012/04/06/3560-queuing-and-scheduling-overview/ http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html


/68

JMJ

11 Recommandations Cisco

Marquage :

Files d’attente de sortie (1P3Q3T)

JMJ QoS Cisco - jm-jurkiewicz.net · JMJ Page Reference QoS Cisco V0.0 9/68 JMJ 2 Convention de...

Documents

Transcript of JMJ QoS Cisco - jm-jurkiewicz.net · JMJ Page Reference QoS Cisco V0.0 9/68 JMJ 2 Convention de...