QoS

La QoS (Quality Of Service) a pour but d'optimiser les ressources réseau : bandwidth, delay, jitter, packet loss pour les applications qui en ont le plus besoin (typiquement : la voix). Le concept, c'est donc de détecter les paquets de voix et de les faire passer avant les autres, considérés comme moins urgents.

• leaky bucket, algorithme du seau troué : il s'agit d'un seau percé. les flux (burst) arrrivent dans le seau qui les écoule à la vitesse du CIR (=du trou). La capacité de burst Bc (= le tampon) est la taille du seau. Le trafic qui dépasse (Be, exceed brust) est la plus part du temps droppé.

• token bucket, algorithme du seau à jeton : le seau à jeton démarre plein ; un jeton c'est un crédit de trafic, chaque paquet transmis consomme des jetons ; les jetons se régénèrent au rythme du CIR normalement. Quand il n'y a plus de jetons dans le seau, le trafic est “exceeded” (et souvent droppé).

Cet algorithme conserve les bursts (à la différence du lissage du shaping) mais permet d'écrêter tout le trafic excédant.

• Best effort c'est le comportement par défaut d'un routeur, sur lequel est basé Internet ; 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 ; c'est un traitement routeur par routeur sans pré-signalisation que l'on nomme PHB (Per Hop Behaviour)
  • pas de garantie absolue de service
  • scalable en utilisant un petit nombre de classes de trafic

• 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, il exite 2 variantes : VoIP et Enterprise (cf plus bas). L'autoQoS utilise :
  • NBAR, CEF et le champ DSCP pour la classification
  • LLQ et WRR
  • shaping, FRTS
  • la compression d'entêtes (cRTP)
  • la fragmentation de paquets (LFI)
• Cisco SDM QoS Wizard : assistant graphique (via HTTP) de configuration de la QoS

• processing delay : temps de traitement d'un paquet par le routeur, à partir du moment ou il est reçu sur l'interface “ingress” (d'entrée) jusqu'au moment ou il est déposé dans la file d'attente de l'interface egress (interface de sortie)
• queuing delay : temps passé par un paquet dans la file d'attente d'une interface “out”
• serialisation delay : temps mis par le routeur pour émettre un paquet sur le lien ; cela dépend de la bande passante de ce dernier
• propagation delay : temps mis par un paquet pour traverser un lien ; cela dépend donc du média (ex : les transmissions satellite ont un temps de propagation beaucoup plus grand que de la fibre optique)
• transmission delay : pour moi c'est le même que le temps de sérialisation (à vérifier)
• end-to-end delay : temps que met un paquet de bout en bout (du début de la sérialisation de la machine émettrice à la fin de la réception du paquet chez le récepteur)

Voici les 3 grandes étapes de la mise en place de la QoS dans un réseau :

• Identifier le trafic qui transite par le réseau, et spécifier ses besoins en ressources réseau (bandwidth, delay, jitter, packet loss).
• Grouper les flux qui nécessitent les mêmes besoins dans une même classe
• Définir la politique de QoS qui rejoint les besoins des différentes classes de trafic

On peut différencier les paquets en fonctions des paramètres suivants :

• interface d'entrée
• IP precedence
• DSCP
• IP source ou destination
• application (ports tcp et udp)

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

• champ COS (3 bits) en Ethernet (802.1q/p ou ISL)
• champ EXP de l'entête MPLS
• champ DSCP d'IP
• IP precedence
• bit DE (Discard Eligible) en Frame Relay

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 : 111 et 110).

• 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 on ne drop pas (logique !), les 2 bits valent “1”) ; donc la valeur la plus faible est la meilleure. 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, 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 valeurs 7 et 6 sont réservées (comme pour PHB).

TODO : insérer la table d'équivalence entre notation DSCP et CS.

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 au moins une (OU).

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

Dans le cas de VPN, les entêtes IPs sont modifiées donc la classification peut être écrasée. Cisco utilise la fonction qos pre-clasify (ou QoS for VPNs) pour gérer ce problème.

• Apply the policy to the tunnel interface without qos pre-classify when you want to classify packets based on the pretunnel header.
• Apply the policy to the physical interface without qos pre-classify when you want to classify packets based on the post-tunnel header.
• Apply the policy to a physical interface and enable qos pre-classify when you want to classify packets based on the pretunnel header.

Cette fonctionnalité est appelée QoS for Virtual Private Networks (VPNs) par Cisco ; certaines versions d'IOS un peu anciennes ne l'implémentent pas. En outre, cette commande est disponible uniquement sur les interfaces tunnel, virtual template interfaces, et sur les crypto map.

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 peu consommateur de CPU : “premier arrivé, premier sorti”. Il n'y a pas de classification, donc pas de QoS.
• PQ (Priority Queuing : on vide en premier toute la file de plus haute priorité ⇒ peut créer une situation de famine (starving) des autres files, moins prioritaires, qui ne se videront pas tant que les files plus prioritaires sont encore remplies.
• RR (Round Robin) : méthode de partage équitable entre chaque file (on pioche un paquet dans chaque file à tour de rôle)
• 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 de l'entête des paquets.
• CBWFQ (Class-Based WFQ) : c'est la version personnalisable du WFQ : on définit des classes associées à une bande passante qui joue aussi le rôle de priorité (= CQ + WFQ). Le WFQ chez Cisco utilise du CBWRED pour chaque file d'attente.
• LLQ (Low Latency Queuing) = du CBWFQ avec une file spéciale (prioritaire) pour limiter la latence (PQ), pour la voix par exemple. Cela définit une file qui est vidée en priorité avant toutes les autres. (= CBWFQ + 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 mode 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 faire attention 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
• c'est la méthode de queuing par défaut chez Cisco pour les interfaces série et les liaisons E1 et inférieures (< 2048 Kbps)

Le WFQ priorise les flux qui ont un petit finish time càd les paquets qui mettent le moins de temps à être émis sur le lien. Cela prend en compte la taille du paquet (+ vite émis qu'un gros) ainsi que le remplissage de sa file (on privilégie les files les moins remplies quand on doit déterminer quel paquet dropper si le HQO (nombre max de paquets) est atteind, quitte a dropper un paquet déjà empilé dans une autre file plus longue).

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

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 en amont 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 maximum (j'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.

Chez Cisco, par défaut, on ne peut pas dépasser 75% de réservation pour toutes les files, les 25% restant étant gardé pour le routage, les entêtes de niveau 2, etc…

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 anticipés permettent :

• d'anticiper la congestion totale
• de faire réagir les sources consommatrices de BW qui utilisent TCP afin qu'elle baissent leur débit.
• on jette des paquets aléatoirement = cela touche en moyenne plus les sources les plus consommatrices de bande passante
• cela permet en outre de désynchroniser les flux TCP afin de ne pas avoir de pics de débit simultanés (TCP global synchro) qui amènent les congestions

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

3 types de “drop” en RED : no drop, random drop et tail drop (ou full drop).

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.

ou trafic conditioner ; il s'agit de mécanismes de régulation de trafic.

Policing VS Shaping

GTS : Generic Traffic Shaping
CIR Commited Information Rate = mean rate, ou débit souscrit
CAR Committed Access Rate
Bc conform burst
Be excess burst
pir Peak Information Rate
conform-action : action lorsque le débit est inférieur au Bc
exceed-action : action lorsque le débit est compris entre Bc et Bc+Be
violate-action : action lorsque le débit est supérieur à Bc+Be

Cisco recommends the following values for the normal and extended burst parameters:
normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds
extended burst = 2 * normal burst

Le shaping c'est du lissage de trafic = étalement des bursts qui dépassent le CIR (Commited Information Rate, c'est-à-dire le débit souscrit d'une liaison louée) en remplissant un tampon (c'est peu conseillé pour les liaisons rapides car le tampon saturerait immédiatement). Ce tampon se vide lorsque la liaison est libre, c'est le concept du leaky bucket (seau troué).

• bufferisation jusqu'au remplissage du buffer alloué
• réduit les réémissions TCP en évitant le drop systématique de l'EIR (Excess Information Rate = le trafic excédant le CIR)
• applicable uniquement sur une interface “out” (en sortie de l'interface)
• pas de marking (marquage des paquets)

Il existe 2 manières de mettre en place du shaping :

• directement sur une interface

S'applique sur tout le trafic sortant de l'interface :

int xxx
 traffic-shape rate CIR [Bc [Be [buffer limit]]]

ou en utilisant une ACL pour sélectionner le trafic sur lequel s'appliquera le shaping :

int xxx
 traffic-shape groupe ACL CIR [Bc [Be]]

• ou passer par une class-map (sélection du trafic concerné) et une policy-map (définition de l'action à appliquer sur le trafic) ; puis l'appliquer sur une ou des interface(s)

class-map match-all toto_class-map
 description class-map all traffic
 match any
!
policy-map toto_policy-map
 class toto_class-map
  ! envoyer Bc par intervalle
  shape average CIR Bc Be
  ! envoyer Bc+Be par intervalle
  shape peak CIR Bc Be
!
int xxx
 service-policy {input|output} toto_policy-map

Le policing est l'écrêtement du trafic qui dépasse le CIR.

• on peut définir différentes actions (drop, mark + transmit)
• s'applique sur une interface en “in” ou en “out”

Le policing utilise le concept du token bucket (seau à jetons) = les jetons se régénèrent à la vitesse du CIR = Bc / Tc

• Policing and Shaping Overview chez cisco
• Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting chez cisco

Mécanismes :

• compression d'entêtes (non négocié = il faut l'activer des 2 cotés du lien ptp sinon les paquets ne peuvent pas être lus)

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

• compression de payload (négocié par ppp = il faut l'activer des 2 cotés pour activer la compression ; si elle n'est activée que d'un coté elle n'est pas “enabled”).

int se0/1/0
 compress [lzs | mppc | prediction | stac]

sh compress details
 Serial0/1/0
       Compression not active
       uncompressed bytes xmt/rcv 775/2114690
       compressed bytes   xmt/rcv 635/1334934
       Compressed bytes sent:       635 bytes   0 Kbits/sec  ratio: 1.220
       Compressed bytes recv:   1334934 bytes   36 Kbits/sec  ratio: 1.584
       1  min avg ratio xmt/rcv 0.000/0.000
       5  min avg ratio xmt/rcv 0.088/0.865
       10 min avg ratio xmt/rcv 0.088/0.865
       no bufs xmt 0 no bufs rcv 0
       resyncs 80

• fragmentation (LFI Link Fragmentation and Interleaving) (/!\ les paquets voix doivent rester + petits que les fragments de data pour rester prioritaire en cas de WFQ). On fragmente pour ne pas retarder les paquets voix quand un gros paquet met du temps à être sérialisé. On fragmente donc le gros paquet, et si un paquet voix arrive, il passera entre 2 fragments (entrelacement).

int se0/1/0
 ppp multilink group 1
int multilink 1
 shut
 ppp multilink fragment delay 10
 ppp multilink interleave
 no shut

Le but pour que cela soit efficace est d'avoir un “fragment delay” de 10 à 15 ms maximum.

Ces mécanismes sont consommateurs de ressources CPU ; aussi on les utilise surtout sur des interfaces à 64 Kbps ou moins.

La VAD (Voice Activity Detection) est un système de détection de blancs dans une conversation en VoIP. Cela permet de ne pas transmettre ces données inutiles, et donc de sauvegarder de la bande passante sur le réseau. Il permet de sauver 35% de la bande passante en moyenne (atteint pour un lien qui transmet 24 appels), mais cela dépend du fond sonore, du type d'appel (appel classique, conference-call = one-way, streaming).

Le CoPP ou Control Plane Policing est un mécanisme censé protéger un routeur des attaques de type DoS en définissant des règles de priorité en cas de forte charge. Il protège le control plane (flux faisant fonctionner le réseau, comme les protocoles de routage OSPF ou BGP) et le management plane (flux d'administration : SSH, SNMP, etc…) en dépriorisant (mince, ce mot n'existe pas - mais vous devinez le sens ;) le service plane (services réseau comme les flux VPN par exemple) et le data plane (tous les autres flux = flux utilisateurs).

L'exemple ci-dessous permet, en cas de surcharge du routeur, de dropper tous les paquets sauf les paquets telnet initiés dans le LAN 192.168.0.0 /24.

access-list 110 deny tcp 192.168.0.0 0.0.0.255 any eq telnet
access-list 110 deny tcp any eq telnet 192.168.0.0 0.0.0.255
access-list 110 permit any any

class-map match-all telnet-class
 match access-group 110

policy-map control-plane-in
 class telnet-class
  drop

control-plane
 service-policy input control-plane-in

Il existe 2 types d'autoQoS : VoIP et Enterprise. VoIP implémente un modèle statique pour la voix alors qu'Enterprise passe par une période de découverte (écoute passive) des flux afin d'affiner des classes en fonction du trafic réel de l'interface (avec NBAR). AutoQoS Enterprise permet de créer jusqu'à 10 classes de trafic.

L'AutoQoS Enterprise met en place les méthodes de QoS suivantes : LLQ, cRTP et LFI.

• CEF doit être activé sur cette interface
• aucune service-policy ne doit être configurée sur l'interface
• bien préciser le paramètre bandwidth sur l'interface car l'autoQoS se base là-dessus (ainsi que sur le type d'interface)

• dans un réseau FR, l'autoQos ne peut pas être configurée
  • si un DLCI est déjà configuré sur une sous-interface
  • si une class-map est assignée au DLCI

• activer la découverte des protocoles sur une interface

auto discovery qos

• attendre quelques temps (dans l'idéal, plusieurs jours) pour la découverte de trafic soit pertinente, puis activer l'auto QoS sur l'interface (penser aussi à désactiver le découverte de trafic qui n'est plus utile et consomme des ressources) :

auto qos

Vérifications :

show auto qos [interface se0/1/0]
show auto discovery qos [interface se0/1/0]

show mls qos interface se0/1/0
show mls qos maps

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 (cela signifit que NBAR ne reconnaitra plu le HTTP sur le port standard (80) !) ; pour en rajouter un, on l'ajoute à la suite :

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

Pour charger un PLDM :

(config)#ip nbar pldm <nom du pldm>