Cisco France Blog

Cisco France Blog / Réseaux / QoS et communications unifiées, que faire ?

17 January 2012 Leave a Comment
Réseaux

QoS et communications unifiées, que faire ?

1 min read



<![CDATA[La question m'est venue récemment d'un client qui comme beaucoup d'autres est parti d'une téléphonie traditionnelle, où le réseau IP ne se souciait guère des flux voix; pour ensuite mettre en place de la téléphonie sur IP; avant d'arriver à des fonctionnalités voix/vidéo sur le poste de travail (communications unifiées). "Petite" contrainte: il y a plus de 100.000 ports d'accès sur le réseau donc hors de question d'avoir des configurations différentes sur les différents ports! Dans ce post je vais me cantonner a tout ce qui est classification et policing en entrée du réseau (je parlerai de tout ce qui est traitement en sortie un autre jour)…

Première étape: pas de VoIP

Pas besoin de trop se creuser trop la tête: on n’a pas de voix sur le réseau… 🙂

Seconde étape: téléphones IP

Ca se complique un petit peu. On trouve aisément des réponses dans le CVD Medianet Campus QoS Design 4.0 qui est la bible 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

Troisième étape: 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 le Medianet 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 100
 switchport voice vlan 110
 auto qos voip cisco-softphone

Bon à ce niveau là on simplifie peut-être un peu trop: on prendra soin de regarder toutes les lignes générées et de supprimer celles qui ne sont pas forcément utiles. Ce post est déjà suffisamment long, inutile d’en dire plus!

Références