INTRODUCTION

---

Allons droit au but !

 

 

Type de flux et exigences

---

---

•  Données (HTTP, FTP)

Ses exigences sont uniques par application (supportent souvent le délai et la perte). Afin de mettre en œuvre une QOS de qualité, il faut bien analyser les applications.

 

•  Voix (VoIP)

Afin d’avoir une bonne qualité d’appel audio :

Delay = 150 ms max.
Jitter = 30 ms max.
Loss = 1% max.
Bandwidth = associé au codec utilisé, la signalisation est estimé à 150 b/s

Attention la voix s’accompagne de la signalisation donc il va falloir gérer les deux flux.

 

• Vidéo (Skype, Facetime, Streaming)

Afin d’avoir une bonne qualité d’appel vidéo :

Delay = 150 ms max.
Jitter = 30-50 ms
Loss = 0.1 – 1%
Bandwidth = irrégulière donc prévoir 20% supplémentaire à celle de base

 

Ok on a les critères… C’est cool !

Mais comment connaître les protocoles qui circulent sur mon réseau ?

 

 

Analyser sa situation – NBAR – PDLM

---

---

Ce n’est pas forcément facile d’analyser une situation déjà en place mais pour ça il existe la fonctionnalité Network Based Application Recognition NBAR.

-> Dépendant du CEF (a vérifier en début de sh run)
-> S’applique sur une interface
-> Fourni les statistiques de 128 protocoles (les plus utilisés) du trafic entrant et sortant (paquets, octets, bande passante moyenne sur 5 min.)

 

Syntaxe :

Mise en place de la fonctionnalité

R1(config-if)# ip nbar protocol-discovery                

Visualisation des statistiques

R1# show ip nbar protocol-discovery interface interface  

 

Tips:

Laisser le temps à votre fonctionnalité de récolter la quantité d’information nécessaire à son exploitation (bénéfique à une meilleure QOS).

Il se peut que votre trafic ne soit pas recensé par ces 128 protocoles (vision dans la case unknow lors de la commande de visualisation de la récolte par NBAR). La nature du fichier recensent les protocoles est Packet Description Language Module (PDLM). Il est possible de le mettre à jour (fichier à télécharger surwww.cisco.com).

R1# show ip nbar version 

R1# show ip nbar pdlm

 

Tips:

Seul un fichier PDLM de version supérieur à celui en place pourra le remplacer.

 

Maintenant que je sais quel vont être mes critères…

 

 

Classifier

---

---

Comme son nom l’indique nous allons classifier nos groupes dans des « class-map » que l’on peut comparer à des dossiers.

Les class-map sont les éléments moteurs de la QOS, nous allons en créer pour colorer nos flux, gérer la congestion ou encore prévenir celle-ci. Ces class-map seront remplies d’une ou plusieurs conditions (un peu comme une boucle de programme).

Nous pouvons dès le début de la commande indiquer si nous voulons que toutes les conditions soient réunies ou si une seule d’entre elles suffira.

Toutes les conditions présentes doivent être respectées:

Router(config)# class-map match-all name  

Une des conditions présentes doit être respectée:

Router(config)# class-map match-any  name 

 

En l’absence de match-all ou match-any l’équipement implémente automatiquement un match-all.

Création de la class-map C_fingerinthenet:

Router(config)# class-map C_fingerinthenet 

Mise en place d'un critère via la commande match:

Router(config-cmap)# match                 

 

Une fois le dossier créé (config-cmap)#, voyons les différents critères possibles :

• Access-group suit les conditions d’une access list ;
• Protocol  match directement les paquets transportant le protocole sélectionné ;
• Input-interface : tous les paquets provenant de cette interface ;
• Destination-MAC-address : tous les paquets ayant cette adresse en destination MAC ;
• Source MAC adress : tous les paquets ayant cette adresse en destination MAC ;
• Any : tous les paquets ;
• Class-map : vous pouvez imbriquer les class-map (attention au manque de lisibilité de la configuration) ;
• Différentes coloration : cos, ip dscp, ip précédence… (détaillé dans la section « marquer »).

Nous pouvons classifier les flux très précisément en impliquant plusieurs commandes match dans une class-map (une ACL et un autre match par exemple). Si vous ne vous souvenez plus trop des possibilités des ACL je vous invite à aller lire l’article Access-list.

 

Exemple de classification des flux http et https en provenance de notre serveur mac adresse F I N T :

Nous sommes obligés de créer une ACL pour le protocol HTTPS (ne fait pas parti des possibilités de la commande match protocol) :

Création de l'ACL HTTPS:

Router(config)# ip access-list extended HTTPS
Router(config-ext-nacl)# permit tcp host any any eq 443 
Autorise les paquets de n'importe quelle source IP
vers n'importe quelle destination IP utilisant le port 443

 

Première version avec deux class-map séparées:

Création de la class-map C_Serveur_HTTPS (match-all par défaut):

Router(config)# class-map C_Serveur_HTTPS  
Router(config-cmap)# match access-group name HTTPS
Router(config-cmap)# match source-MAC-adress F :I :N :T   
                     
utilisant le port 443 ET qui ont F:I:N:T comme adresse MAC source 

Création de la class-map C_Serveur_HTTP:
Router(config)# class-map C_Serveur_HTTP
Router(config-cmap)# match protocol http
Router(config-cmap)# match source-MAC-adress F :I :N :T
utilisant le protocol HTTP (port 80) ET qui ont F:I:N:T comme adresse MAC source

 

Deuxième version, pas la plus simple, mais montrant la possibilité d’imbrication :

Création de la class-map C_Prot_Serv:

Router(config)# class-map match-any C_Prot_Serv
Router(config-cmap)# match access-group name HTTPS
Router(config-cmap)# match protocol http

utilisant le port 443 OU utilisant le protocole HTTP (port 80)

Création de la class-map C_Serveur:

Router(config)# class-map C_Serveur 
Router(config-cmap)# match source-MAC-adress F :I :N :T 
Router(config-cmap)# match class-map C_Prot_Serv  
ont F:I:N:T comme adresse MAC source
ET qui remplissent les conditions de la C_Prot_Serv

 

Quelques règles sur le class-map avant de continuer :

-> Par défaut l’équipement applique un match-all
-> 256 class-map par équipement maximum
-> maximum 40 caractères pour le nom de class-map

 

 

Marquer

---

---

 

Notre volonté est de peindre les voitures provenant de notre serveur FINT et utilisant les protocoles HTTP et HTTPS. Nous avons appris à trier les voitures (classification), maintenant il faut choisir la bonne couleur.

Il faut créer une stratégie appelée « policy-map » dans laquelle on va :

– affecter les class-map (identifie les bonnes voitures) ;
– utiliser la commande set afin de choisir la peinture à appliquer.

Nous n’allons qu’aborder les policy-map, dans le but du marquage. Nous en reparlerons dans la « gestion de la congestion ».

 

Création de la stratégie fingerinthenet:

Router(config)# policy-map fingerthenet                   
Router(config-pmap)# class C_Serveur                 
Router(config-pmap-c)#
Implication de la class-map C_Serveur dans la stratégie

La stratégie est créée, nous avons sélectionné les voitures (class-map),

maintenant il va falloir choisir la couleur pour ces voitures.

 

 

Set

---

---

 

Qu’est-ce que la couleur ? C’est un changement d’état des bits de champs spécifiques faisant partie de l’en-tête de la couche 2 ou de la couche 3.

Le marquage peut être effectué dans différentes en-têtes de la couche 2 :

– cos : dans la trame 802.1Q sur 3 bits ;
– exp : dans la trame MPLS sur 3 bits ;
– de : dans la trame Frame Relay sur 1 bit ;
– clp : marquage dans la trame ATM sur 1 bit.

Ces marqueurs seront préservés dans leur propre réseau uniquement (à moins de mettre en place une « class-map » qui match leur coloration -critères des class-map un peu plus haut- !!!!

 

Nous allons nous attarder sur le marquage de la couche 3 :

– Ip précedence : les 3 bits de poids fort du champ Type Of Service (ToS) ;
– DSCP (Differentiated Service Code Point) : les 6 bits de poids fort du champ ToS.

 

A vous d’organiser votre marquage, mais j’ai quelques conseils :

– CS7 & CS6 : application sur les échanges des protocoles de routage ;
– Express Forwarding EF: application sur les flux de VOIP ;
– cohérence : vis à vis de la totalité de votre réseau.

On sait de quoi est composée la couleur, nous nous étions arrêtés dans la stratégie après avoir impliqué la class-map.

Exemple de modification du champ dscp: :

Router(config)# policy-map fingerthenet
Router(config-pmap)# class C_Serveur                      
Router (config-pmap-c)# set ip dscp cs4 (ou 32)

 

 

Application de la stratégie

---

---

On a choisi les voitures, la couleur et préparer nos ateliers de peintures. Nous devons mettre en place cette coloration au plus près des services, soit l’interface directement connectée à mon serveur.

Router(config)# interface fastEthernet 0/1
Router(config-if)# service-policy input fingerinthenet

 

On remarquera le input, cela signifie que tous les paquets entrant par cette interface seront examinés par la stratégie.

A partir de ce moment, les paquets traversant cette stratégie sont considérés comme des BEHAVIOR AGREGATE “BA”.

 

Afin de le vérifier :

Router# sh policy-map

 

 

Comme on peut le remarquer sur l’image, il va falloir installer des marquages à chaque entrée et au plus près de nos services.

 

 

 

BILAN

---

 

 

L’étape de classification et marquage est terminée mais ça ne change rien à la congestion existante… Ce n’était que la première étape ! Maintenant on peut :

• Gérer la congestion ;
• Faire de la prévention de congestion.

 

En espérant que vous avez apprécié cet article !

N’hésitez pas à me la faire savoir !!

 

FingerInTheNet