But : optimiser les ressources : bandwidth, delay, jitter, packet loss pour les applications qui en ont le plus besoin (typiquement : de la voix). Le concept c'est donc de détecter les paquets de VoIP et de les faire passer avant les autres moins “urgents”.

• Best effort c'est le comportement par défaut ; il ne fournit pas de QoS
  • pas de garantie de service
  • pas de différenciation de service
• IntServ Integrated Services (RFC 1633) : permet de fournir de la QoS par réservation de ressource (~réservation de circuit / pour faire du CAC Call Admission Control) ; garantit l'arrivée des paquets
  • basé sur RSVP/CAC pour réserver les ressources
  • débit garanti
  • problème de scalabilité (ne passe pas l'échelle)
• DiffServ Differenciated Services (RFC 2474 et 2475) : Utilisation de classes de services (typiquement le champ TOS/DSCP du paquet IP) qui sont reconnues par les routeurs du réseau (pour faire du PQ)
  • pas de garantie absolue de service

• Legacy QoS CLI : peu pratique, configuration interface par interface
• MQC Modular QoS CLI : configuration modulaire, personnalisable (utilise des class-map et des policy-map)
• Cisco AutoQoS : simple à mettre en place car il s'agit d'un modèle pré-conçu pour la VoIP. Il utilise :
  • NBAR, CEF et champ DSCP pour la classification
  • LLQ et WRR
  • shaping, FRTS
  • compression d'entêtes (cRTP)
  • fragmentation des gros paquets (LFI ?)

Pour le mettre en place il faut activer le cef et préciser la bandwidth de l'interface

• Cisco SDM QoS Wizard : assistant graphique (via HTTP) de configuration de la QoS

Le marquage peut se faire à différentes couches OSI, dans différents chaps en fonction du protocole :

• champ COS en Ethernet (802.1q/p)
• champ EXP de l'entête MPLS
• champ DSCP d'IP
• IP precedence

L'IP precedence est l'ancienne utilisation du champ TOS d'IP : on n'utilisait que les 3 bits de poids fort (bits 7 à 5) ce qui faisait 6 classes (2 combinaisons étant réservées).

Le PHB (Per-Hop Behavior) est la nouvelle façon d'utiliser le champ TOS

EF PHB : Expedited Forwarding = low-delay service (VoIP) AF PHB : Assured Forwarding = guaranted bandwidth service default PHB : on fait du best-effort

C'est un champ de 8 bits codées ainsi :

• Les bits 1 et 0 sont réservés pour un usage futur donc on ne les fait pas apparaitre. C'est ce qui explique pourquoi on note toujours la valeur du champ TOS sur 6 bits.

• Le bit n°2 est toujours à 0

• Les bits 7 à 5 correspondent à

• Les bits de 4 à 3 définissent le pourcentage de chance de drop par classe (si on utilise AF ; car en EF les 2 bits valent “1”) ; donc la valeur la plus faible est la “mieux”. Les valeurs possibles sont 01 10 ou 11 (pas 00).

Une exception existe pour la valeur “001 000” qui code le trafic scavenger (less-than-best-effort, souvent du P2P).

Exemple : Si le champ TOS vaut 100010 (on omet les bits 1 et 0 car on ne s'en sert pas), le paquet correspond à de l'AF41 (on découpe ainsi : 100-01-0). Ces 6 bits peuvent se lire en décimal : “PHB AF41” correspond à “DSCP 34” (ces notations sont équivalentes).

Il existe une notation de classes “CS” (IPP), qui vaut xxx000 pour la compatibilité avec l'IP Precedence. Elle est donc codée sur 3 bits ; les valeures 7 et 6 sont réservées (comme pour PHB).

Reconnaissance et marquage du champ DSCP du trafic HTTP et FTP (modèle DiffServ avec MQC). Le concept est simple :

1. définition d'une classe de trafic (class-map) = on matche un trafic (dans notre cas on se sert d'ACLs dans les class-map)
2. définition d'une policy pour cette classe = ce qui va être fait à ce trafic (policy-map)
3. application de la policy sur une interface (service-policy)

access-list 101 permit cp any any eq ftp
access-list 101 permit cp any any eq ftp-data
access-list 102 permit cp any any eq www

class-map match-all match-ftp
 match access-group 101
class-map match-all match-www
 match access-group 102

policy-map mark-apps
 class match-ftp
  set dscp af11
 class match-www
  set dscp default

interface FastEthernet0/1
 service-policy input mark-apps

• En utilisant des ACLs on peut affiner le “match” dans les class-maps.
• dans une class-map on peut spécifier plusieurs paramètres “match”. Dans ce cas on doit choisir la condition ET (match-all) ou OU (match-any) pour indiquer si le trafic doit matcher chaque clause (ET) ou ou moins une (OU).

show class-map
show policy-map interface fa0/1

(congestion avoidance)

Il s'agit du mécanisme d'ordonnancement des files d'attentes.

• FIFO First In First Out, mécanisme par défaut, très simple : “premier arrivé, premier sorti”. Limité à 1000 paquets par défaut.
• PQ Priority Queuing : on vide en priorité la file de plus haute priorité ⇒ peut induire la famine (starving) des autres files, moins prioritaires, qui ne se vident pas tant que les files plus prioritaires sont remplies.
• RR Round Robin : méthode de partage équitable entre chaque file (on pioche un paquet dans chaque file à tour de rôle : ABCABCABC…)
• WRR Weighted RR : associe des priorités par file au RR = permet de donner plus de priorité à une file
• CQ Custom Queuing c'est l'implémentation Cisco du WRR
• WFQ (Weighted Fair-Queuing) : priorisation automatique, non modifiable de certains flux, basé sur un hash de certains champs d'entête des paquets

• CBWFQ (Class-Based WFQ) : c'est du WFQ personnalisable : on définit des classes associées à une bande passante qui joue aussi le rôle de priorité = CQ + WFQ
• LLQ (Low Latency Queuing) = du CBWFQ avec une file spéciale pour limité la latence (PQ) ; pour la voix par exemple. Cela définit une file qui est vidées en priorité avant les autres. (CBWFQ + CQ + PQ)

Les mécanismes de gestion de file d'attente software, qui servent à la QoS, ne sont utilisés que lorsque la file d'attente hardware de l'interface est pleine. Cette dernière est toujours en FIFO ; pour connaitre la taille du buffer hardware d'une interface (ici 128 max, et contient actuellement 0 paquet) :

show controller se0/1/0 | i tx_limited
 tx_limited = 0(128), errata19 count1 - 0, count2 - 0

Le buffer hardware peut être configuré avec la commande :

tx-ring-limit <taille>

Cependant il faut prendre garde car une mauvaise configuration de ce dernier peut annuler toute la politique de QoS (s'il est trop important ou pas assez).

• classification : en fonction de certains champs de l'entête des paquets IP ; puis calcul d'un checksum pour reconnaitre le flux
• drop policy : CDT (Congestive Discard Threshold) (nb de messages permis dans la queue) ; HQO (limite le nombre max de paquets dans toutes les files d'une interface)
• scheduling

Le WFQ priorise les flux qui ont un petit finish time càd les petits paquets qui sont transmis rapidement.

La mise en place est très simple mais n'est possible que sur une interface de moins de 2 Mbps.

fair-queue [CDT [conversation dynamic-queues [conversation reservable-queues]]]

Réglage de la HQO (le défaut est 1000) :

hold-queue <max-limit> out

show interface se0/1/0
show queue se0/1/0

On travaille sur des paquets déjà taggués et on leur applique une politique de gestion de file d'attente en fonction de leur marquage.

Les classes reconnues sont définies dans des class-map :

class-map match-any ef-traffic
 match  dscp ef
 match protocol icmp
class-map match-all af21-traffic
 match  dscp af21
class-map match-all af31-traffic
 match  dscp af31
class-map match-all af11-traffic
 match  dscp af11
class-map match-all cs1-traffic
 match  dscp cs1

On définit l'action dans une policy-map globale, dans laquelle on va définir :

• la file prioritaire (~VoIP, propre au LLQ, introduit par la commande priority)) pour la classe ef-traffic ; en limitant son débit à 168 Kbps max (on insère aussi l'ICMP pour faire des tests de ping)
• les files af31, af21, af11 et cs1 auront respectivement 40, 20, 13 et 2 % de la bande passante restante (remaining) du lien minimum
• le reste (class-default) aura 25% du reste de la bande passante. 2 paramètres sont également présents : l'activation du WFQ (uniquement possible sur la classe class-default) avec 1024 files maximum et une seuil de drop de 50 paquets par file.

L'unité pour toutes les files de CBWFQ (af-xy et défaut ici) doivent être la même partout. Elle peut être soit une valeur de débit (bandwidth), soit un pourcentage du débit de l'interface ((bandwidth percent) soit un pourcentage du débit restant (bandwidth remaining percent).

policy-map llq-policy
 class ef-traffic
  priority 168
 class af31-traffic
  bandwidth remaining percent 40
 class af21-traffic
  bandwidth remaining percent 20
 class af11-traffic
  bandwidth remaining percent 13
 class cs1-traffic
  bandwidth remaining percent 2
 class class-default
  fair-queue 1024
  queue-limit 50
  bandwidth remaining percent 25

On applique (en output) sur une interface, par exemple la se0/1/0 (toute la QoS précédemment configurée est basée sur le paramètre bandwidth 384 (384 Kbps) de l'interface) :

interface Serial0/1/0
 bandwidth 384
 service-policy output llq-policy

Cette interface ne doit pas être en WFQ sous peine de tomber sur le message Must remove fair-queue configuration first. ⇒ no fair-queue

⇒ la classification se fait en input et le queuing se fait en output.

show class-map
show policy-map interface fa0/1

La méthode consiste à droper des paquets dans les buffers d'interface (software) avant son remplissage complet (chez Cisco c'est implémenté dans le WFQ). Ces drops permettent de faire réagir les sources consommatrices de BW qui utilisent TCP afin qu'elle baissent leur débit. De plus comme on jette des paquets aléatoirement, cela touche en moyenne plus les sources consommatrices que les autres ; cela permet en outre de désynchroniser les flux TCP afin de ne pas avoir de pics de débit simultanés.

Les différentes gestions de file d'attente :

• RED Random Early Detection : en fonction du remplissage du buffer, on défini un %age de drop
• WRED Weighted RED = une file RED par type de paquet, avec des seuils différents

Pour mettre en place du (CB)(W)RED sur un type de classe, il faut passer la commande random-detect dans la rubrique class d'une policy-map (après avoir passé le paramètre bandwidth) :

policy-map pmap-test
 class match-http
  bandwidth percent 20
  random-detect dscp af11 32 36 10

Les paramètres ci-dessus sont facultatifs, mais s'ils sont précisés, ils affinent, dans l'ordre, le seuil min, le seuil max et le max-prod-denominator. Ce dernier chiffre est un dénominateur qui indique la pente de la droite de %age de drop entre les 2 seuils, min et max. Concrètement, un dénominateur de 10 comme au dessus indique un quotient de 1/10 soit 10%. Le taux de drop entre le seuil min et max est une droite qui part de 0% à 10 %. Puis, après le seuil max, on passe directement à 100% de drop.

shaping = étalement des bursts en remplissant un tampon (peu conseillé pour les liaisons rapides). Ce tampon se vide lorsque la liaison est libre. policying = écrêtement quand on dépasse le CIR (drop ou marquage des paquets en trop)

Le shaping s'appliquent sur une interface en “out” uniquement ; le policying s'applique sur une interface en “in” ou en “out”.

Notions de token bucket.

Mécanismes :

• compression d'entêtes

policy-map llq-policy
 class ef-traffic
  compression header ip rtp

• ou compression de payload

(config-if)#compress <algorithme>

• fragmentation (LFI Link Fragmentation and Interleaving) (/!\ les paquets voix doivent rester + petits que les fragments de data pour rester prioritaire en cas de WFQ)

• H.323
• RSVP (Ressource Reservation Protocol) : pour réserver les ressources d'un flux RTP (modèle IntServ)
• SCCP
• MGCP
• SIP

NBAR Network-Based Application Recognition permet l'identification des applications/protocoles d'un paquet sur la base de signatures (PDLM) et permet d'en faire de la classification et des statistiques. Il travaille au niveau 4 - 7 mais il ne saura pas reconnaitre du HTTP sur un autre port que le celui qu'on lui spécifie (80 par défaut). Cela veut dire qu'il se base sur le numéro de port pour savoir lire le protocole auquel il s'attend. Ce n'est pas un IPS qui se base sur des signatures applicative et qui peut détecter du HTTP sur un “non-standard port”.

PDLM Packet Description Language Module : bout de code pour reconnaitre un protocole

Pour activer NBAR sur une interface (le CEF doit être activé : #ip cef) :

(config-if)#ip nbar protocol-discovery

show ip nbar port-map
 port-map bgp                      udp 179
 port-map bgp                      tcp 179
 port-map citrix                   udp 1604
 [..]

Pour modifier un port d'un protocole connu :

(config)#ip nbar port-map http tcp 8080

Puis, pour voir les statistiques des protocoles {sur l'interface fa0/1} :

show ip nbar protocol-discovery {interface fa0/1}

Ce nouveau port remplace celui par défaut ; pour en rajouter un, on l'ajoute à la suite :

(config)#ip nbar port-map http tcp 80 8080