On trouve aisément des réponses dans le site de cisco Medianet Campus QoS Design 4.0 pour mettre en place la QoS dans le LAN. Une option élégante consiste à utiliser une fonction de « trust conditionnel ». On ne va prendre en compte le champ COS sur le VLAN voix que si l’on détecte un téléphone sur le port (via échange CDP). De son côté, cette commande pilote le téléphone pour remarquer tous les paquets venant du poste de travail avec un champ DSCP à 0. Je mets ci-dessous quelques exemples de configuration partiellement repris du CVD Medianet mentionné plus haut.
interface range GigabitEthernet 1/0/1-48 switchport access vlan 10 switchport voice vlan 110 spanning-tree portfast mls qos trust device cisco-phone ! L'interface va être configurée pour truster ce qui vient du téléphone CISCO mls qos trust cos ! Si un téléphone CISCO est branché alors on truste le COS service-policy input PER-PORT-MARKING ! Application de la policy en entrée sur le port (non détaillée)
On peut également utiliser une autre méthode sans utiliser la fonction de trust conditionnel: on applique notre service-policy non plus au niveau du port mais au niveau du VLAN, et on s’arrange pour ne prendre en compte les marquages éventuels que pour le VLAN voix. Attention quand on met en place la QoS par VLAN: bien s’assurer que le policing reste par port ET par VLAN (on veut tout de même s’assurer que les niveaux de trafic voix restent conformes à ceux attendus sur chaque port et non pas en global). Pour cela on va utiliser des « nested class-maps » ou class-maps imbriquées.
Activation de la QoS globalement sur le switch:
mls qos
Configuration de la QoS par VLAN:
interface range GigabitEthernet 1/0/1-48 switchport access vlan 100 switchport mode access switchport voice vlan 110 mls qos vlan-based interface Vlan100 service-policy input QOS_DATA_VLAN interface Vlan110 service-policy input QOS_VOICE_VLAN
Création des class-maps (on note les 2 niveaux qui seront imbriqués la première permet de repasser dans un mode par port ET par VLAN, l’autre pour matcher les flux générés par les téléphones):
class-map match-all access-ports-1 match input-interface GigabitEthernet1/0/1 - GigabitEthernet1/0/48 class-map match-all VOICE match dscp ef class-map match-all SIGNALING match dscp cs3
A ce stade dans le cas où on va stacker des équipements il faut faire autant de classes pour les ports d’accès que de chassis dans le stack. On pourra donc rajouter pour un 2nd châssis:
class-map match-all access-ports-2 match input-interface GigabitEthernet2/0/1 - GigabitEthernet2/0/48
Et enfin les policy-maps: pour le VLAN voix on va prendre en compte le champ DSCP, par contre sur le VLAN DATA on remarque bêtement tout à 0 (là aussi on voit les policy-maps imbriquées: la policy map au niveau du VLAN va appliquer des autres policy-maps qui feront le policing sur les différents flux). J’ai repris ci-dessous l’exemple avec 2 châssis dans le stack, il est alors nécessaire d’appeler toutes les class-maps listant les ports des différents modules du stack (access-ports-1 et access-ports-2 ici)
policy-map QOS_VOICE_VLAN class VOICE set dscp ef service-policy police_128k_vvlan class SIGNALING set dscp cs3 service-policy police_32k_vvlan class class-default set dscp default policy-map QOS_DATA_VLAN class class-default set dscp default policy-map police_32k_vvlan class access-ports-1 police 32000 8000 exceed-action drop class access-ports-2 police 32000 8000 exceed-action drop policy-map police_128k_vvlan class access-ports-1 police 128000 8000 exceed-action drop class access-ports-2 police 128000 8000 exceed-action drop
Communications unifiées, vidéo et voix sur poste de travail
Ca se corse: on a des flux voix sur le téléphone mais également des flux multimédia depuis le poste de travail. Comment arriver à traiter de manière homogène ces flux sans faire exploser les configurations des équipements? Rappelons-nous que le client souhaite une configuration homogène sur tous les ports d’accès.
Alors que faire? Premier reflex: on jette un coup d’oeil au CISCO Validated Designs (CVD) qui traitent du sujet:
Et là il faut admettre que cela pourrait être plus clair… On a une première question pour laquelle on n’a pas de réponse immédiate: « Faut-il se baser sur le DSCP envoyé par l’application ou non? ». La section « QoS » de la seconde référence n’est pas tout à fait a jour et ne tient pas compte des nouveautés sur CUPC (Cisco unified Personal Communicator) et des les évolutions de Windows:
- CUPC a maintenant évolué et il est possible depuis la version 8.5(5) de distinguer les ports UDP utilisés pour la voix et la vidéo
- Windows 7 remarque tous les paquets émis par l’application avec un DSCP à 0. Il est cependant possible sur l’OS de définir des règles statiques pour remarquer des flux spécifiques pour une application donnée avec le DSCP souhaité
Donc en se basant sur les ports UDP utilisés on va pouvoir faire la distinction vidéo/voix sur l’OS ou sur le switch pour marquer les paquets en fonction du type de flux. Alors quelle est la différence entre les 2 approches? Et bien quand un paquet arrive sur le switch, ce dernier ne peut pas être certain que l’application utilisée est réellement CUPC! Si la classification se fait sur le switch, on risque donc de mettre dans la classe « Voix – DSCP 46″ ou « Vidéo SD – DSCP 34″ du trafic non généré par l’application CUPC. Une chose est sûre: pour les 2 approches, on ne va pas accepter tout et n’importe quoi dans chaque classe: des policers nous permettront de protéger le réseau d’un trafic EF trop important. Seul l’usager qui utilisera une application non conforme sera impacté et les 2 solutions sont donc envisageables.
Option 1: on se base sur le DSCP entrant (ici on aura précédemment configuré l’OS du poste de travail pour faire le marquage approprié)
Je repars de la configuration précédente (ingress QoS par port ET par VLAN). J’ajoute simplement des règles sur le VLAN DATA pour faire la classification appropriée pour les flux voix et vidéo (flux multimédia et signaling). Je définis donc 3 nouvelles ACL et class-maps:
ip access-list extended QoS-DSCP-EF permit udp any any range 16384 24575 dscp 46 permit udp any range 16384 24575 any dscp 46 ip access-list extended QoS-DSCP-CS3 remark SCCP permit tcp any any range 2000 2002 dscp 24 permit tcp any range 2000 2002 any dscp 24 remark SIP permit tcp any any range 5060 5061 dscp 24 permit tcp any range 5060 5061 any dscp 24 ip access-list extended QoS-DSCP-AF41 permit udp any any range 24576 32767 dscp 34 permit udp any range 24576 32767 any dscp 34 permit udp any any 5445 dscp 34 permit udp any 5445 any dscp 34 class-map match-all VOICE match access-group name QoS-DSCP-EF class-map match-all SIGNALING match access-group name QoS-DSCP-CS3 class-map match-all VIDEO match access-group name QoS-DSCP-AF41
Je rajoute également mes nouveaux policers (flux voix sur le VLAN Data ainsi que flux vidéos). Je continue de donner un exemple avec un stack de 2 switchs de 48 ports GE chacun. Il est nécessaire de faire appel à des policers distincts car on peut tout à fait imaginer que 2 appels soient faits sur le même port du switch: l’un depuis le téléphone et l’autre depuis le poste de travail.
policy-map police_32k_dvlan class access-ports-1 police 32000 8000 exceed-action drop class access-ports-2 police 32000 8000 exceed-action drop policy-map police_128k_dvlan class access-ports-1 police 128000 8000 exceed-action drop class access-ports-2 police 128000 8000 exceed-action drop policy-map police_1M_dvlan class access-ports-1 police 1000000 31250 exceed-action drop class access-ports-2 police 1000000 31250 exceed-action drop policy-map police_1M_vvlan class access-ports-1 police 1000000 31250 exceed-action drop class access-ports-2 police 1000000 31250 exceed-action drop
Et j’appelle ces nouvelles class-maps dans mes policy-maps précédentes:
policy-map QOS_VOICE_VLAN class VOICE set dscp ef service-policy police_128k_vvlan class SIGNALING set dscp cs3 service-policy police_32k_vvlan class VIDEO set dscp af41 service-policy police_1M_vvlan class class-default set dscp default policy-map QOS_DATA_VLAN class VOICE set dscp ef service-policy police_128k_dvlan class SIGNALING set dscp cs3 service-policy police_32k_dvlan class VIDEO set dscp af41 service-policy police_1M_dvlan class class-default set dscp default
Option 2: on se base uniquement sur les ports UDP pour les flux venant du poste de travail
Ici la seule difficulté est que si l’on ne souhaite pas utiliser le champ DSCP venant du poste de travail, on veut quand même faire la classification des flux du VLAN voix en utilisant les infos fournies par le téléphone (c’est quand même plus simple!)
On peut donc définir nos classes de manière différenciées pour le VVLAN et le DVLAN, et on n’aura plus le champ DSCP dans les ACL définissant les flux sur le VLAN Data, en revanche on ne se basera que sur ce champ pour répertorier ce qui vient du téléphone:
ip access-list extended QoS-DSCP-EF permit udp any any range 16384 24575 permit udp any range 16384 24575 any ip access-list extended QoS-DSCP-CS3 remark SCCP permit tcp any any range 2000 2002 permit tcp any range 2000 2002 any remark SIP permit tcp any any range 5060 5061 permit tcp any range 5060 5061 any ip access-list extended QoS-DSCP-AF41 permit udp any any range 24576 32767 permit udp any range 24576 32767 any permit udp any any 5445 permit udp any 5445 any class-map match-all VOICE_VVLAN match dscp ef class-map match-all SIGNALING_VVLAN match dscp cs3 class-map match-all VIDEO_VVLAN match dscp af41 class-map match-all VOICE_DVLAN match access-group name QoS-DSCP-EF class-map match-all SIGNALING_DVLAN match access-group name QoS-DSCP-CS3 class-map match-all VIDEO_DVLAN match access-group name QoS-DSCP-AF41
Il reste à appeler les class-maps depuis les policy-maps appliquées sur les VLANs.
policy-map QOS_VOICE_VLAN class VOICE_VVLAN set dscp ef service-policy police_128k_vvlan class SIGNALING_VVLAN set dscp cs3 service-policy police_32k_vvlan class VIDEO_VVLAN set dscp af41 service-policy police_1M_vvlan class class-default set dscp default policy-map QOS_DATA_VLAN class VOICE_DVLAN set dscp ef service-policy police_128k_dvlan class SIGNALING_DVLAN set dscp cs3 service-policy police_32k_dvlan class VIDEO_DVLAN set dscp af41 service-policy police_1M_dvlan class class-default set dscp default
Envie de simplification ?
Ca tombe bien, « auto qos », qui existe depuis déjà quelque temps pour les flux téléphoniques a été adapté sur la gamme 3k pour la gestion de la vidéo en suivant les recommandations décrites dans leMedianet Campus QoS Design 4.0. En quelques lignes de commande on peut appliquer des règles basiques pour les différents cas de figure. Par exemple on pourrait dans le cas précédent gérer le problème en quelques lignes de commande. Tout d’abord on indique qu’on utilise auto qos pour la vidéo (par défaut auto qos fait la configuration sur un modèle de téléphonie sur IP simple)
auto qos srnd4
Puis sur les interfaces d’accès on indique qu’on souhaite une configuration pour un Soft-phone CISCO:
interface range GigabitEthernet 1/0/1-48 switchport access vlan 10 0 switchport voice vlan 110 auto qos voip cisco-softphone
