QoS sur Cisco 3750

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.

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:

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.

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.

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