QoS sur Cisco 3750

On 10 mars 2011 by Benoit With 17 Comments - CISCO, Protocoles

Introduction

Voici un Test de Qualité de Service (QoS) basé sur des données réelles.
Il permettra de mieux comprendre l’effet des commandes sur le marquage et le traitement des flux effectué par le Switch 3750.

Environnement physique

Ce test de QoS est effectué sur un Switch 3750, il est réalisé avec un injecteur de trafic de type Spirent “TestCenter”.
Le Spirent sert à simuler différents hôtes ainsi que des flux personnalisés dirigés entre les hôtes, de part et d’autre du Switch.
Il injectes les flux dans le Switch et permet de tirer des statistiques des paquets reçus en sortie.

  • Switch Cisco 3750
  • Spirent Testcenter

La topologie physique est décrite dans l’image suivante, le câble 1 du Spirent est connecté au port Gi 1/0/5 du Switch 3750.
Le port 2 du Spirent est connecté au port Gigabit 1/0/3 du Switch 3750.

topo phy

Un flux de 1Gbps est injecté via le port 1 du Spirent dans le Switch.
Le port Gi 1/0/3 du Switch est lui bridé à 100Mbps afin de créer un “goulot d’étranglement”, c’est ici qu’interviendra la configuration de la QoS, dans le but de laisser passer certains flux plus importants que d’autres. Nous allons garantir un pourcentage de bande passante pour chaque flux.

Environnement logique

En parlant de flux, voici ceux que nous allons mettre en place, 3 en tout:

flux

L’image ci-dessus décrit les 3 flux simulés par le Spirent:

  • Flux Data – Ce flux sera dans le VLAN 1 (10.0.1.0/24)
    • La machine 10.0.1.1 envoi 80Mo de paquets faisant chacun 512 Octets vers la machine 10.0.1.2 du même sous-réseau.
  • Flux Voix – Ce flux sera dans le VLAN 2 (10.0.2.0/24)
    • La machine 10.0.2.1 envoi 80Mo de paquets faisant chacun 512 Octets vers la machine 10.0.2.2.
  • Flux Visio – Ce flux sera dans le VLAN 3 (10.0.3.0/24)
    • La machine 10.0.3.1 envoi 80Mo de paquets faisant chacun 512 Octets vers la machine 10.0.3.2.

Nous allons commencer par créer les différents VLANs et leurs interfaces L3.

Configuration des VLANs Switch:

vlan 1
  name data
vlan 2
  name voix
vlan 3
  name visio

interface vlan 1
ip address 10.0.1.254 255.255.255.0
no sh

interface vlan 2
ip address 10.0.2.254 255.255.255.0
no sh

interface vlan 3
ip address 10.0.3.254 255.255.255.0
no sh

Maintenant que les flux sont envoyés au travers du Switch, il est nécessaire de respecter plusieurs étapes afin de mettre en place la QoS:

  1. Activer la QoS
  2. Classification – La classification permet d’identifier les différents flux
  3. Marquage – Le marquage permet de différentier ces différents flux. Nous allons marquer les flux au niveau 3, dans le champ DSCP de l’adresse IPv4.
  4. Gestion de la congestion
    • Queuing / Dropping / Scheduling – Une fois les flux marqués, il ne restera plus qu’a configurer les différents Buffers et la bande passante allouée à chacun des flux.

Activation de la QoS

configure terminal
mls qos

Vérification

show mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

Classification des flux

ACL

Les ACL crées permettent de définir le trafic “intéressant” pour nous. Celui que nous allons marquer ensuite, afin de donner des priorités à certains paquets.

ip access-list 101
permit ip 10.0.1.0 0.0.0.255 any
ip access-list 102
permit ip 10.0.2.0 0.0.0.255 any
ip access-list 103
permit ip 10.0.3.0 0.0.0.255 any

Class-map

Les “class-map” permettent de mettre en relation les ACL avec les policy-map.

class-map match-all cmap_data
101
class-map match-all cmap_voice
102
class-map match-all cmap_visio
103

Marquage des flux

Le marquage se fera dans notre cas au niveau 3. Nous allons modifier le champ DSCP de chaque paquet IP qui passera par ce Switch.

Voici un schéma qui montre le champ DSCP du paquet IPv4.
C’est sur ce champ que nous allons baser notre test, il nous permettra de marquer nos flux avant de les rendre prioritaires.

flux

Au niveau CLI, voici comment celà se traduit. Une Policy-map configurée, puis appliquée aux interfaces d’entrées des flux.

policy-map pmap_interco
 class cmap_voice
  set dscp ef
 class cmap_data
  set dscp default
 class cmap_visio
  set dscp af41

Interface INPUT

Sur l’interface ou le trafic entrera (Gi 1/0/5), nous appliquons la policy pmap_interco. Tout le trafic qui entrera sur cette interface, et qui va “matcher” avec nos ACLs, sera ensuite marqué en fonction de la configuration effectuée dans notre policy-map.

Exemple: Un paquet avec une adresse source (Source address dans le paquet IP) dans le sous réseau 10.0.2.0/24 matchera l’ACL 102, la class-map cmap_voice et sera donc marqué en DSCP EF.

interface GigabitEthernet1/0/5
service-policy input pmap_interco

show mls qos input-queue
Queue     :       1       2
----------------------------------------------
buffers   :      90      10
bandwidth :      90      10
priority  :       0      10
threshold1:     100     100
threshold2:     100     100

Scheduling / Queuing / Dropping

La commande srr-queue appliquée à l’interface de sortie permet de définir le queuing, le scheduling et le dropping.

Switch(config)#mls qos srr-queue input ?

!--- Queueing
buffers         Configure buffer allocation
cos-map         Configure cos-map for a queue id
dscp-map        Configure dscp-map for a queue id

!--- Scheduling
bandwidth       Configure SRR bandwidth
priority-queue  Configure priority scheduling

!--- Dropping
threshold       Configure queue tail-drop thresholds

Interface OUT

Dans notre cas, nous souhaitons répartir la bande passante comme ceci (Ce n’est pas une best-practise, à ne pas reproduire exactement en environnement réel, notamment pour la visio, (1%, c’est un peu léger). Il s’agit ici du résultat que nous souhaiterions obtenir EXACTEMENT au final):

Queue 1 Visio 1% de la Bande passante (BW)
Queue 2 Rien 1% de la BW
Queue  3 Data 88% de la BW
Queue 4 Voix 10% de la BW 
interface GigabitEthernet1/0/3
srr-queue bandwidth share 1 1 88 10

Voici comment vérifier votre configuration:

show mls qos int gi 1/0/3 queueing
GigabitEthernet1/0/3
Egress Priority Queue : disabled
Shaped queue weights (absolute) :  25 0 0 0
Shared queue weights  :  1 1 88 10
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 1

La ligne “Shared queue weights” confirme notre configuration. Nous pensons que la bande passante est alors bien priorisé tel que nous le pensons, mais nous verrons ensuite que d’autres paramètres entrent en jeu, tel que le shaping et qui faussent notre résultat final.

show mls qos int gi 1/0/3 buffers
GigabitEthernet1/0/3
The port is mapped to qset : 1
The allocations between the queues are : 25 25 25 25

Logique de Qos sur le Cisco 3750

Schémas de la logique de QoS interne au Cisco 3750.

Ce schéma est très pratique pour comprendre “visuellement” la façon dont sont gérés les paquets à l’intérieure du Switch.
qos

Dans le tableau ci-dessous, vous pouvez afficher le mapping effectué par votre Switch en INPUT avec la commande show mls qos map dscp-input-q. Le mapping correspond à l’allocation de flux marqués avec certaines valeurs DSCP à la queue 1 ou 2 en entrée du Switch. Vous avez pu voir les queues d’entrée sur le schéma ci-dessus.
Le schéma nous montre que:

  • les flux de donnée (DSCP 0) sont redirigés vers la queue numéro 2.
  • les flux de voix (DSCP EF) sont redirigés vers la queue numéro 1.
  • les flux de visio (DSCP AF41) sont redirigés vers la queue numéro 2.
show mls qos map dscp-input-q
Dscp-inputq-threshold map:
d1 :d2    0     1     2     3     4     5     6     7     8     9
------------------------------------------------------------
0 :    02-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 01-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

Dans le tableau ci-dessous, vous pouvez afficher le mapping effectué par votre Switch en OUTPUT avec la commande show mls qos map dscp-output-q. Le mapping correspond à l’allocation de flux marqués avec certaines valeurs DSCP à la queue 1, 2, 3 ou 4 en sortie du Switch. Vous avez pu voir les queues de sortie sur le schéma ci-dessus.
Le schéma nous montre que:

  • les flux de donnée (DSCP 0) sont redirigés vers la queue numéro 3.
  • les flux de voix (DSCP EF) sont redirigés vers la queue numéro 4.
  • les flux de visio (DSCP AF41) sont redirigés vers la queue numéro 1.
show mls qos map dscp-output-q
Dscp-outputq-threshold map:
d1 :d2    0     1     2     3     4     5     6     7     8     9
------------------------------------------------------------
0 :    03-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

Tests effectués

Après avoir entré la configuration précédente, voici les données obtenus avec l’injecteur de trafic. Pas vraiment les résultats attendus..

Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 748 4 654 710
Visio 99 999 760 9 750 647
Data 99 999 770 85 592 544

PRIORITY-QUEUE OUT
Test de la commande priority-queue out sur l’interface de sortie.

Switch(config)#interface Gi 1/0/3
Switch(config-if)#priority-queue out
Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 636 99 996 771
Visio 99 999 646 0
Data 99 999 651 0

Le trafic Voix est clairement prioritaire par rapport aux autres.

BANDWIDTH LIMIT
Test de la commande srr-queue bandwidth limit sur l’interface de sortie.

Switch(config)#interface Gi 1/0/3
Switch(config-if)#srr-queue bandwidth limit 50
Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 629 4 653 565
Visio 100 000 337 4 988 507
Data 100 000 340 43 791 096

Nous faisons entrer 300Mo de Trafic, l’interface d’entrée est bridée à 100Mo, et l’interface de sortie est maintenant limitée à 50Mo en sortie.

BANDWIDTH SHAPING
Test de la commande srr-queue bandwidth shape sur l’interface de sortie.

Switch(config)#interface Gi 1/0/3
Switch(config-if)#srr-queue bandwidth shape 25 0 0 0
Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 629 4 654 710
Visio 999 999 760 9 750 647
Data 999 999 760 85 592 544 
Switch(config)#interface Gi 1/0/3
Switch(config-if)#srr-queue bandwidth shape 0 0 0 0
Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 629 900 000
Visio 999 999 760 9 008 437
Data 999 999 760 90 088 428 
Switch(config)#interface Gi 1/0/3
Switch(config-if)#srr-queue bandwidth shape 10 10 10 10
Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 629 11 634 393
Visio 999 999 760 11 635 820
Data 999 999 760 11 625 799 
Switch(config)#interface Gi 1/0/3
Switch(config-if)#srr-queue bandwidth shape 20 20 20 20
Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 629 5 817 921
Visio 999 999 760 5 817 919
Data 999 999 760 5 817 920 
Switch(config)#interface Gi 1/0/3
Switch(config-if)#srr-queue bandwidth shape 20 20 20 100
Flux Taux entrée L1 (bps) Taux sortie L1 (bps)
Voix 99 999 629 5 817 883
Visio 999 999 760 1 163 291
Data 999 999 760 5 817 868

Pour conclure sur ces tests de shaping, afin d’avoir notre bande passante de sortie divisée en 1 1 88 10, comme désiré plus haut, il est nécessaire de régler le shaping à 0 0 0 0 sur l’interface de sortie. Par défaut, le shaping est à 25 0 0 0.

Conclusion

D’après les tests effectués, voici les points sur lesquels il est nécessaire de faire très attention.

  1. Le « Strict Priority » prend bien toute la BW disponible, peu importe le sharing/shaping défini.
    Ce qui rend son utilisation dangereuse si on ne l’associe pas à autre chose pour en limiter le débit (en output de préférence).
    Cette commande permet de strictement prioriser les flux tagués en EF (Voix). Si vous envoyez 50Mo de Data et 50Mo de Voix sur un lien 10Mo, en sortie du switch, vous aurez 10Mo de voix, et 0Mo de Data (100% de Drop).
  2. Les pourcentages associés à la commande srr-queue bandwidth share sont respectés lorsqu’aucun shaping n’est défini par la commande srr-queue bandwidth shape. En effet, lorsqu’une valeur est définie pour une file dans la commande shape, elle annule la valeur définie par la commande share.

La lecture des valeurs de ces deux commandes est la suivante :

  • srr-queue bandwidth share
    • 4 valeurs données entre 1 et 255 correspondent à un ratio de BW disponible par rapport aux autres valeurs.
    • Exemple : srr-queue bandwidth share 10 20 30 40
    • ==> la file 3 a une bande passante de 30/(10+20+30+40)
  • srr-queue bandwidth shape
    • 4 valeurs données entre 1 et 65535 correspondent à un ratio de BW disponible, ratio donné par 1/valeur_donnée.
    • Exemple :srr-queue bandwidth shape 10 20 30 40
    • ==> la file 3 a une bande passante de 1/30.

Attention donc aux valeurs de SHAPING / SHARING, afin d’avoir le bon scheduling en sortie.
Merci à Alex pour ces tests très pointus effectués avec le Spirent !

Source de documentation pour la QoS 3750 : http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml

Benoit

Network engineer at CNS Communications. CCIE #47705, focused on R&S, Data Center, SD-WAN & Automation.

More Posts - Website

Follow Me:
TwitterLinkedIn

, , , , , , , , , , , ,

17 Comments

  1. Alex Jafri 10 mars 2011

    Très bons tests et bonne analyse des résultats.
    Bien joué.

  2. Allan 5 mai 2011

    Bonjour, votre sujet sur la QoS est très intéressant; c’est pourquoi je voulais vous demandez comment vous avez fait pour mesurer les taux d’entrées et de sorties des flux vidéos audios etc…?

    Et aussi, avez-vous configuré la partie input et output de la QoS et si oui comment et où avez-vous réparti les différents flux?

    Merci d’avance pour votre réponse.

  3. Benoit 5 mai 2011

    Bonjour Allan,

    Les taux d’entrée et de sortie ont été mesurés avec un injecteur de trafic de type Spirent (http://www.spirent.com/Solutions-Directory/Spirent-TestCenter.aspx). Il injecte des flux précis, et nous permet de savoir ce qui sort du Switch, au paquet prêt.

    J’ai effectivement configuré les parties input/output de la QoS, comme décrit ci-dessus.

  4. Allan 6 mai 2011

    Bonjour,

    Je vous remercie pour le site, cela va être d’une grande aide.

    Cordialement.

  5. Julien 8 mai 2011

    Bonjour,

    Merci pour cet article fort intéressant.
    J’ai essayé d’appliquer la pmap pour matcher le trafic entrant sur une interface Vlan plutôt qu’une interface physique et cela ne fonctionne pas (le trafic n’est pas tagué avec le DSCP défini dans la pmap)

    Avez-vous une idée à tout hasard ?

    Merci d’avance.

  6. Benoit 11 mai 2011

    Bonjour Julien,
    Effectivement, cela ne peut fonctionner car chez Cisco, les paquets ne “remontent” pas jusqu’à l’interface VLAN. Votre PMAP ne match donc pas les paquets entrants et le Switch ne les tague pas.
    Il est obligatoire d’appliquer votre Policy-map à une interface physique, et non virtuelle.

  7. Vincent 7 juillet 2011

    Bonjour,

    super post qui m’a bien éclairé sur la mise en place de la QOS.
    Néanmoins, au niveau des tests de performance, je n’ai pas compris si les commandes étaient cumulées ou non.
    Exemple : lorsqu’on met en place le “srr-queue bandwith” le “priority-queue out” est-il activé ?
    Un show run int gi0/3 à chaque étape m’aurait aidé à optimiser mon paramétrage comme vous avez su le faire.
    Ensuite, j’ai encore un peu de difficulté à appréhender l’interco avec plusieurs switchs ; auriez-vous des pistes ?
    Je répète, c’est vraiment un très bon article, c’est juste que je début en QOS…

    Merci pour vos réponses.

    Vincent

  8. Benoit 8 juillet 2011

    Bonjour Vincent,
    Pour ta première question “les commandes sont elles cumulables”: non.
    srr-queue et priority-queue out ne sont pas cumulables car la dernière va définir une priorité stricte pour la voix.
    Le show run n’aurait rien apporté de plus pour la QoS car il n’y à pas plus de commandes à entrer pour que le Switch réagisse comme dans l’article.
    Que veux-tu savoir pour l’interconnexion entre tes Switchs?

    Merci pour le compliment sur l’article !
    Benoit.

  9. Vincent 12 juillet 2011

    Bonjour,

    merci pour tes réponses Benoît.
    Je n’avais pas compris que le priority-queue était uniquement pour la voix… j’ai bien fait de prendre cet exemple.

    Pour l’interconnexion des switchs c’est au niveau du paramétrage des ports entrée ; sortie.
    Si on prend l’exemple de la voix :
    au niveau matériel j’ai deux swichs A et B reliés par fibre (A Gi0/1 & B Gi0/1) et un téléphone sur chaque TA et TB connectés sur les fa0/1.
    L’IPBX serait quant à lui connecté sur le switch A, port fa0/2.
    Comment devrais-je paramétrer mes ports gi ? Puisque je vais avoir aussi bien du trafic en entrée qu’en sortie à prioriser…

    J’espère avoir bien posé mon problème. Si ce n’est pas le cas, je peux t’envoyer un schéma.

  10. meryem 21 mars 2012

    bonjour
    je veut savoir est ce que c’est possible une fois qu’on dépasse la bande passante permise on passera par le payement pour augmenter la bande

  11. verif 5 juin 2012

    Bonjour, est ce possible de créer deux vlan Voice(dédiés à la voix sur IP) dans un même site, je veux dire est qu’il existe des switch qui peuvent gérer deux vlan différents dédiés à la VoIP, et y a t il un intérêt particulier à faire celà.
    Merci

  12. Valentin 19 février 2014

    Bonjour, je trouve ce poste très intéressant, j’aurais simplement voulu savoir si le fonctionnement est le même avec des switch cisco 2960 ?

    Merci d’avance.

  13. Benoit 19 février 2014

    Bonjour, merci pour le commentaire. Le 2960 semble avoit le même nombre de queues que le 3750 (2 en entrée et 3 en sorties) et la majorité de ce qui est dit dans cet article doit être vrai pour le 2960. Tu peux trouver le détail ici : http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_55_se/configuration/guide/scg_2960/swqos.html#wp1284809 .

  14. Valentin 21 février 2014

    Merci beaucoup pour ta réponse, je me suis empressé de configurer mes switches. J’aurais cependant une question concernant les “cos” (dans le ssr-queue map), je n’arrive pas à comprendre leurs utilités.

  15. Jerome 16 novembre 2014

    Bonsoir,
    Très bon article et très clair.
    Il est tout à fait possible d’appliquer des policy-map sur des SVI.
    !
    Int vlan 300
    Description voice vlan
    No ip address
    Service policy-map input voice-vlan
    !
    Int fa 0/1
    Switchport mode access
    Switchport access vlan xx
    Switchport voice vlan 300
    mls qos vlan-based
    !

  16. niekam 27 octobre 2016

    bonjour. ce sujet est très intéressant mais je suis un peu perdu parce que je suis pas encore expert CISCO mais j’aspire à l’être. le vocabulaire (shaping, sharing, sheduling …) me perd un peu. y’a t’il des sites qui peuvent m’expliquer cela de façon basique????? Merci

  17. Benoit 27 octobre 2016

    Pour le shaping/policing, voici un lien intéressant: http://packetlife.net/blog/2008/jul/30/policing-versus-shaping/
    Je note qu’il pourrait être intéressant que je fasse des articles d’explication de ces termes ;)

Comments are Disabled