TP - La QoS dans les réseaux IP

UE PRIP

Automne 2023

Préambule

Le concept de Qualité de Service ou QoS (Quality of Service) dans le domaine des réseaux recouvre «l’ensemble des mécanismes permettant de contrôler la gestion du trafic réseau afin d’assurer que le réseau satisfasse bien les besoins de service des applications».

Deux types de mécanismes peuvent être identifiés selon que l’on considère la QoS du point de vue global sur la totalité du réseau ou du point de vue particulier sur chaque équipement (routeur).

1. QoS du point de vue global  : les mécanismes mis en œuvre dans cette catégorie assurent le service souhaité sur l’ensemble du réseau. Les applications (ou leurs utilisateurs) ou les gestionnaires du réseau définissent des politiques de QoS et celles-ci sont traduites en demandes de réservation de ressources dans les nœuds du réseau. Des protocoles (RSVP, COPS) ou des mécanismes (DiffServ) permettent d’effectuer ces réservations. Ces aspects ne seront pas développés plus avant ici car ils sont traités en cours.
2. Les techniques fines de QoS : elles permettent la mise en œuvre effective de la QoS dans les routeurs. Une requête RSVP, par exemple, se traduira effectivement dans chaque routeur par l’utilisation d’une de ces techniques. Celles-ci peuvent être utilisées sur décision des administrateurs des routeurs, sans l’aide d’un mécanisme global. Ce sont quelques-unes de ces techniques que nous étudierons dans ce TP. Nous ne pourrons pas, hélas, tout étudier et ne testerons pas les techniques avec tous les protocoles.

D’une manière générale, comme l’illustre la figure 1, une politique de QoS sur un équipement réseau se résume à trois grandes questions :

• les files d’attente : combien et quelle taille ?
• l’entrée dans ces files d’attente : lorsqu’un paquet IP arrive sur un routeur, dans quelle file le ranger ? (notions de flux, de classes, etc.)
• la sortie de ces files d’attente : combien de paquets sont pris sur quelle file et à quel moment pour être envoyés sur l’interface de sortie ?

Chacune des quelques politiques de QoS de ce TP va répondre à sa manière à ces trois questions.

Note : Pour en savoir plus, je peux vous conseiller le wiki suivant, pas trop long, pertinent et bien rédigé : http://pteu.fr/doku.php?id=informatique:cisco:qos

1 Mise en place du réseau et paramétrages

Le réseau de test est architecturé comme le montre la figure 2.

Les machines terminales sont des PCs munis du système d’exploitation Linux. Le mot de passe administrateur vous sera donné en début de séance.

Configuration du réseau :

• Sur les machines 1 et 3 lancez minicom (ou gtkterm si vous aimez mieux), et appuyez sur la touche Entrée. Vous accédez ainsi aux commandes des routeurs. Après vous être authentifié (enable), vérifiez la configuration existante (show running-config). Ou si vous êtes pressés, tapez sh ip int br.
• Ouvrez une autre fenêtre terminal administrateur sur tous les PC (et donc également sur la machine 2) et positionnez-vous dans le répertoire /opt/TP/TPQoS. Vous trouverez notamment dans ces répertoires différents fichiers et scripts de configuration des machines et des routeurs. N’hésitez pas à faire preuve de curiosité et à regarder leur contenu. (À l’aide de la commande more ou less par exemple.)
• Vérifiez les configurations des trois PC. (ifconfig ou bien ip address show ; et route -n ou bien ip route show)
• Sur les machines 1 et 3, affichez le fichier configrouteur contenu dans le répertoire TPQoS.
• Vérifiez l’accessibilité de toutes les machines (ping) : 1 et 2 doivent pouvoir joindre 3.

2 Mécanisme par défaut

Lorsque aucune demande explicite de QoS n’est soumise à un routeur celui-ci utilise par défaut un mécanisme Fair Queueing sur ses interfaces.

Vous allez maintenant expérimenter ce mécanisme.

• Sur le routeur de gauche, vérifiez le politique associée à l’interface de «sortie» : show interface s0/0/0
• Placez-vous dans le répertoire TPQoS sur toutes les machines, dans toutes les fenêtres que vous ouvrez.
• Sur la machine 3, dans une fenêtre terminal, lancez le programme ./recepteurfluxUDP.
• Sur la machine 2 lancez le programme ./emetteurfluxUDP en donnant les paramètres nécessaires pour que ce flux soit envoyé vers le programme ./recepteurfluxUDP sur la machine 3. Ce flux sera notre charge réseau contre laquelle nous tenterons d’imposer d’autres flux en les priorisant.
• Vérifiez avec wireshark ou tcpdump que le flux arrive bien sur la machine 3. (Ne laissez pas wireshark capturer trop longtemps ce flux incessant, sinon le PC va finir pas swapper...)
• Sur la machine 3, dans une autre fenêtre lancez le programme ./recepteurUDP. Ce programme va recevoir des paquets UDP précédés par une annonce du nombre de paquets à recevoir. Il prendra alors l’heure système et la mémorisera. Il recevra ensuite les paquets annoncés. Ceux-ci se termineront par un paquet spécial contenant le mot «FIN» (acquitté par un paquet contenant le mot «OKFIN»). Le programme prendra alors à nouveau l’heure système. Il pourra ainsi calculer le débit du flux reçu en fonction du temps mis à recevoir les paquets. À noter qu’avec UDP, des paquets peuvent être rejetés s’il y a congestion dans le réseau (avec TCP aussi, mais TCP demande leur retransmission). Le programme nous indiquera le nombre de paquets reçus. La mesure de débit ne sera à considérer que pour un nombre de paquets reçus correspondant au nombre annoncé.
• Sur la machine 1, lancer le programme ./emetteurUDP en lui donnant comme arguments l’adresse et le port du récepteur ainsi que le nombre de messages à émettre, on choisira 20 pour cette valeur. (Il y a un dernier paramètre optionnel, precedence, nous l’utiliserons plus tard, ne mettez rien pour l’instant.)

• Faites les essais suivants en notant pour chacun le débit annoncé :

  • Machine 1 → machine 3 (emetteurUDP→recepteurUDP) en présence du flux de fond 2 → 3. Recommencez plusieurs fois en notant le débit annoncé par le récepteur.
  • Arrêtez le flux de fond 2 → 3, attendez quelques minutes, vous pouvez lancer wireshark sur la machine 3 pour vérifier que le flux 2 → 3 s’est bien arrêté. Relancez alors le flux 1 → 3 plusieurs fois en notant les débits.
  • Relancez le flux 2 → 3 et refaites les essais 1 → 3 en notant toujours les débits.

Question : Que constatez-vous ?
Vous remarquerez que nous n’avons pas encore paramétré la QoS.

3 Flow-Based Weighted Fair Queueing

Le Fair Queueing est un peu plus riche que cela. En fait, cette stratégie (historiquement ancrée dans la philosophie best effort et dans le monde IP) sait accorder plus de poids à certains flux par rapport à d’autres. On l’appelle alors Weighted Fair Queueing.

Deux concepts dans cette expression : fair queueing d’une part et weighted d’autre part, i.e. une notion de juste traitement de file d’attente et une notion de poids. Le fair queueing est un mécanisme assurant un traitement équitable à tous les flux en termes de nombres d’octets émis. Ainsi, par exemple, si dans la file 1 on a un paquet de 100 octets et dans la file 2 deux paquets de 50 octets alors on émettra un paquet de la file 1 et deux paquets de la file 2.

Le mécanisme WFQ mis en œuvre de base par Cisco repose sur l’utilisation du champ TOS de l’entête IP des paquets qui circulent, plus exactement les bits dits de précédence qui sont les trois bits de poids fort de l’octet TOS. Notez que cette information est transportée par les paquets eux-mêmes. Ce poids peut être attribué par l’émetteur, ou modifié par n’importe quel équipement IP sur le réseau. Mais regardons ce qu’il se passe lorsque le routeur doit traiter un paquet qui comporte une indication de précédence.

• Avec le programme emetteurUDP, jouez avec le dernier paramètre optionnel : precedence. Le programme placera cette valeur dans les 3 bits de poids fort du champ TOS, la fameuse précédence transportée dans les paquets IP eux-mêmes. Variez de 0 (pas de précédence, valeur classique par défaut), jusqu’à 7.
• Observez le débit obtenu.
• Est-ce que vous arrivez à deviner l’équation qui relie la valeur de précédence et le débit observé ? (Nous y reviendrons en section 10.)
• À l’aide de wireshark, retrouvez dans l’entête IP des paquets la précédence que vous avez positionnée. (Préalablement, configurez wireshark ainsi : dans le menu Edit / Preferences / Protocols / IPv4, retirez l’option Decode IPv4 TOS field as DiffServ field).
• Avec wireshark, regardez dans quel ordre arrivent les paquets entre nos deux flux. Voyez-vous un lien avec la valeur de la précédence ?

Note : Dans la terminologie Cisco, ce mécanisme porte le nom de Flow-Based Weighted Fair Queueing (par opposition au Class-Based Weighted Fair Queueing que l’on abordera ensuite). Généralement les termes fair queueing, weighted fair, weighted fair queueing, flow based weighted fair queueing, sont tous synonymes et désignent le mécanisme que l’on trouve par défaut sur les équipements IP (PC, routeurs, etc.).

4 Le mécanisme Fifo

Avec la commande de niveau interface enlevez le mode fair-queue sur l’interface série du routeur de gauche. Vérifier le résultat avec show interface s0/0/0. Pour cela, placez-vous dans la fenêtre gtkterm de la machine 1 :

Maintenant, refaites les essais précédents, sans flux de fond pour commencer puis lancez le flux de fond et recommencez.

Note : la commande show interface s0/0/0 affiche un certain nombre de compteurs que vous pouvez remettre à zéro avec clear counter s0/0/0 (ou clear counters).

Question : Que constatez-vous ?
Comment expliquez-vous le phénomène observé lorsqu’il y a du flux de fond ?

Notes concernant Cisco :

• La taille du FIFO se configure au niveau de l’interface avec la commande hold-queue n in |out (n en paquets ; par défaut 75 en in, 40 en out)
• Ne pas confondre la stratégie de QoS FIFO avec le buffer de sortie de l’interface (qui est également un FIFO), mais qui est plutôt d’ordre matériel. Ce dernier se configure avec la commande tx-ring-limit, pour indiquer la taille du buffer en nombre de particles (des tranches de 512 octets).
• Mais tout ceci est bien spécifique à Cisco. Si vous avez compris l’impact d’une stratégie FIFO sur la QoS, c’est le principal.

5 Class Based Queuing

5.1 Introduction

Avant de passer à l’action prenons le temps de quelques explications spécifiques à nos équipements.

Historiquement (jusqu’à l’IOS ¹ 15.0), Cisco proposait principalement les stratégies de QoS suivantes :

• Weigthed Fair Queuing : le grand classique dans le monde du Best Effort, tel que vu précédemment.
• Priority-Queuing : 4 files de priorité stricte (low normal medium high) ; le routeur fait sortir les paquets de la file de priorité supérieure avant de regarder la (les) file(s) de priorité inférieure ; on ne fait aucun calcul sur la bande passante consommée / disponible.
• Custom-Queuing : 16 files disponibles ; pour chacune on spécifie une quantité (en octet, 1500 par défaut, comme le MTU) indiquant la quantité de données à servir à chaque tour de round-robin ; autrement dit on alloue à chaque file une portion de la bande passante disponible, sans notion de priorité.

Ces stratégies étaient assez simples à comprendre. On a une séparation claire entre la notion de priorité d’une part (certains flux passent plus tôt, avant les autres), et la notion de bande passante d’autre part (certains flux ont droit à plus de place que d’autre sans forcément passer plus tôt). Par contre ces stratégies ne sont pas forcément pratiques à utiliser en condition réelle...

Dans le même temps (à partir d’IOS 12.0), Cisco a commencé à introduire une façon de paramétrer la QoS légèrement différente, appelée Class Based Queuing (CBQ). On retrouve un peu tous les mécanismes précédents, par contre ils sont organisés autour de la notion de classes de flux, un mécanisme un peu plus générique.

Les stratégies disponibles sont :

• Low Latency Queuing (LLQ) : on retrouve le principe de flux prioritaires sur d’autres. On peut déclarer qu’une classe (ou flux) a une priorité stricte sur la class-default (i.e. tous ses paquets sortent avant). On peut également paramétrer le flux LLQ, en lui spécifiant une portion de bande passante minimale garantie pour chacun. Plus précisément, il s’agit de l’algorithme du token-bucket. Si l’on n’est pas en situation de congestion (c’est-à-dire qu’il y a de la bande passante non consommée par d’autres flux) notre flux prioritaire peut dépasser cette valeur. Par contre, en cas de congestion, le flux aura ce minimum garantit mais ne pourra pas le dépasser (des paquets sont détruits). Notons que la stratégie LLQ est ainsi nommée car elle bénéficie d’une latence faible et constante grâce au token bucket (intéressant pour de la voix sur IP par exemple).

  Notez que dans la documentation Cisco on désigne parfois cette stratégie par priority policy.

• Class Based Weigthed Fair Queuing (CBWFQ) : c’est un peu un mélange entre les principes du Weigthed Fair Queuing et du Custom Queueing historique décrit plus haut. Bref, les différents flux sont caractérisés non pas par le TOS, mais par une classe au sens Cisco. Et à chacune de ces classes on va allouer une portion de bande passante, selon l’algorithme du Custom-Queuing.

  Notez que dans la documentation Cisco on désigne parfois cette stratégie par bandwidth policy (par opposition à priority policy).

  En général, on paramètre une politique de QoS, avec une seule classe LLQ pour le flux prioritaire, et on répartit le reste de la bande passante avec plusieurs flux CBWFQ.

• Et à l’intérieur des classes, s’il y a en fait plusieurs flux, ils sont par défaut en mode FIFO. Mais dans le cas du CBWFQ, on peut choisir de les différencier par du fair-queue (i.e. sur les bits de précédence du TOS).
• À cela s’ajoute les spécificités liées au Frame Relay, à DSCP, et à la stratégie du Weighted Random Early Detection (WRED) consistant à détruire aléatoirement certains paquets dans les flux qui approchent de la limite de congestion...
• Et pour finir il y a des calculs savants pour réattribuer la bande passante non consommée aux flux qui en auraient besoin.

Vous trouvez cela compliqué ? ² Attendez de voir quand on va le paramétrer...

La documentation Cisco (voir par exemple «Modular Quality of Service Command Line Interface» en annexe ??) résume cela en 3 étapes :

1. Définir des classes avec la commande class-map
2. Créer une politique de service en associant chaque classe de trafic avec une ou plusieurs politiques de QoS (en utilisant la commande policy-map)
3. Attacher la politique de service à l’interface réseau avec la commande service-policy

5.2 Configuration

Le principe de base est de définir des classes de flux. Lorsqu’un nouveau paquet arrive, il faut que le routeur devine dans quelle classe le ranger. Historiquement, on faisait ça directement avec des Access List (ACL), en se basant sur les champs TCP-IP traditionnels (adresse IP source destination, protocole de transport, numéro de port source destination)...

Cette notion de classe apporte plus de souplesse, plus de critères de classification. On peut même encapsuler des classes dans des classes ; on parlera alors de classes hiérarchiques. (Ça fait rêver non ?)

Les critères relèvent typiquement :

• de la couche 2 : numéro de l’interface réseau par laquelle le paquet est arrivé, adresse MAC source ou destination, type du protocole de couche 3 transporté, classe de service du tag 802.1p, l’identifiant DLCI de Frame Relay, etc. ;
• de la couche "2.5" : autrement dit des labels et autres paramètres MPLS ;
• des couches 3&4 : typiquement et majoritairement on trouve les bonnes vieilles ACL, mais on peut également filtrer sur la longueur du paquet, le champ DSCP ou la précédence du TOS, etc. ;
• de la couche 7 : Cisco fournit un module de reconnaissance applicative (basé visiblement sur les numéros de port traditionnels et les premiers paquets) capable de reconnaître quelques types de trafics : FTP, HTTP, RTP, Citrix, Gnutella, FasTrack, etc. On peut filtrer sur ces protocoles, et parfois sur certains champs dans ces protocoles...
• et pour finir on a la possibilité de filtrer sur un peu n’importe quel octet donné dans l’entête du paquet...

5.2.1 Configurer des Access Lists

En mode configuration définissez deux access-list que vous appellerez 101 et 102. La liste 101 concernera le flux de test (1 → 3), la liste 102 concernera le flux de fond (2 → 3). Repérez bien les numéros de port UDP que vous avez choisis.

La syntaxe peut être la suivante :
access-list

5.2.2 Configurer des class-maps

En vous aidant de l’annexe ??, configurez les class-map suivantes :

• Vous pourrez appeler la première flux13, et configurez-là pour qu’elle match l’ACL 101 définie précédemment (mot clef access-group).
• La seconde pourrait s’appeler flux23, et matcher l’ACL 102.

Vérifiez votre configuration avec show class-map.

Notez qu’il y a une dernière classe à notre disposition, la class-map default, dans laquelle atterrissent les paquets qui ne rentrent pas dans les autres classes.

Voila, nos classes de flux sont prêtes, nous allons pouvoir faire de la QoS dans quelques instants...

6 Le mécanisme Low Latency Queueing

Le mécanisme LLQ assure que le trafic «important» est transmis avant le trafic «d’importance moindre». Ce mécanisme a été pensé pour du trafic de type voix sur IP, c’est-à-dire du trafic qui requiert une faible latence, mais qui n’est pas forcément très gourmand en bande passante. Par conséquent, on s’arrange d’une part pour faire passer les paquets LLQ avant les autres, d’autre part on ne les stocke pas dans des longues files d’attente (et par conséquent on s’autorise volontiers à perdre des paquets LLQ, notamment dans le cas où l’on veut limiter la bande passante accordée à LLQ).

Créez une policy-map (que vous pourrez appeler ma_qos ), qui travaille sur la class flux13, en déclarant cette classe strictement prioritaire (mot clef priority, sans paramètre).

Ne précisez aucune autre classe.

Affectez cette politique de QoS à l’interface de sortie (i.e. l’interface série), pour traiter les paquets sortants. (En mode configuration d’interface : service-policy output ma_qos .

Vérifiez votre configuration avec show policy-map ou show policy-map inferface s0/0/0

• Lancez le flux de fond (2 → 3) s’il ne l’est pas déjà, puis le flux de test (1 → 3) et notez le débit. Vérifiez en faisant plusieurs essais.
• Modifiez votre policy-map ma_qos, et remplacez-la class flux13³ par la class flux23. À chaque fois n’oubliez pas de définir votre classe comme prioritaire (priority). Et refaites les mesures à chaque fois, bien évidemment.
• Que constatez-vous et comment pouvez-vous l’expliquer ?

7 Le mécanisme Class Based Weigthed Fair Queuing

Ce mécanisme est aussi qualifié de politique de QoS en bandwidth, par opposition à LLQ qui est une politique avec priority.

Nous allons procéder comme précédemment.

Reprenez votre policy-map ma_qos. Incluez-la class-map flux13 mais cette fois-ci, n’employez pas le mot-clef priority. (Si elle est déjà là, faites no priority).

Par contre, vous allez lui paramétrer une bandwidth percent 60.

Retirez les autres classes s’il y en a d’autres de présentes.

• Faites les mesures avec les flux.
• Modifiez votre policy-map ma_qos, et rajoutez-la class flux23 avec une bandwidth à 15%.
• Donnez une borne maximale au flux13 avec une règle du type shape average <rate> (choisissez un rate pertinent)
• Fixez également une limite de dépassement acceptable pour les burst : shape peak <rate>
• Vérifiez tout cela : show policy-map inferface s0/0/0
• Faites des mesures à chaque fois. Que constatez-vous ?
• Comment compareriez-vous LLQ et CBWFQ (les deux grandes fiertés de Cisco) ?

8 Utilisation conjointe de LLQ et CBWFQ

Ce type de configuration est, semble-t-il, assez courant dans les situations de convergence data-voip.

Tout d’abord on a un flux prioritaire en LLQ (typiquement les paquets de type VoIP, mais on peut y ajouter des paquets de signalisation divers, ICMP, les ACK TCP, etc., bref des paquets pas forcément très gros, plutôt sporadiques, mais qui peuvent être un peu bloquant pour les couches supérieures s’ils tardent à arriver). Et dans le même temps, on va répartir la bande passante restante entre les flux applicatifs, fichier, web, data, etc.

Concrètement, le flux prioritaire est paramétré avec une règle du type priority percent x , et les autres flux sont paramétrés avec des règles du type bandwidth remaining percent y .

Pour simplifier le travail des administrateurs réseau, Cisco propose en plus un mécanisme d’AutoQoS, avec un profil VoIP pré-configuré, et un profil Entreprise qui passe d’abord par une phase d’apprentissage.

Mais je vous propose de poursuivre plus avant les manipulations avec les stratégies qui suivent...

9 Policer du trafic entrant sur le routeur

Les différentes stratégies de QoS que nous avons vues précédemment consistaient à paramétrer les flux qui sortent du routeur. Or, dans notre banc de test, nous avons en entrée un flux qui est très agressif et qui sature rapidement les files d’attente de notre routeur (on l’a observé en section 4). (Pensez aux attaques de type déni de service.) Fondamentalement, ça ne sert pas à grand-chose qu’il rentre plus vite qu’il ne peut sortir.

Une façon de régler le problème consiste à borner le trafic en entrée du routeur. Cela s’appelle policer le trafic. (Attention, le trafic est écrêté et non pas lissé comme le fait de la QoS en bandwidth vue en 7).

Définissez une nouvelle policy-map que vous pourrez appeler mon_policer. Cette politique va travailler sur la classe flux23, que vous paramètrerez ainsi : police rate 60000 bps, puis en indiquant conform-action transmit et exceed-action drop

Ensuite, vous attacherez cette politique à l’interface par laquelle entre les paquets du PC2 (p.ex. FastEthernet 0/1, commande service-policy input .... Notez qu’il vous faudra au préalable retirer le mode fair-queue qui est par défaut sur l’interface.

• Est-ce que vous observez un changement dans les débits actuellement mesurés ?
• Retirez la politique ma_qos actuellement en cours sur l’interface de sortie Serial 0/0/0. On se retrouve alors dans le cas du FIFO simple.
• Refaites les mesures de la section 4. Qu’est-ce qui a changé (notamment sur le nombre de paquets reçus/perdus) ?

Notes : Une différence notable entre le policer et le shaping est que ce dernier gère d’une file d’attente pour absorber les pics de trafic, au lieu d’écrêter. La contrepartie est que ce mécanisme ne peut pas être configuré sur les entrées, et qu’il introduit de la latence.

La documentation de Cisco ⁴ nous explique que ces deux services sont implémentés selon le principe du tocken bucket.

Pour se conformer à un débit nominal paramétré (appelé CIR, pour Committed Information Rate), l’équipement considère une période de temps (appelée Tc, pour Committed Time, généralement 125ms, paramétrable, mais Cisco dit qu’il calcule tout seul la valeur optimale), au cours de laquelle il va transmettre sur un temps court, mais au débit physique de l’interface une certaine quantité de données (appelée Bc, pour Committed burst). On a alors la relation simple Bc = Tc×CIR. De plus, dans le cas du shaping qui gère des pics de débit, on s’autorise à transmettre en fait Bc+Be données (Be pour excess burst).

Autrement dit, Tc est le temps pendant lequel on remplit le seau à jetons, Bc est le nombre de jetons, et Bc+Be la capacité du seau. ⁵

10 Mécanisme Weighted Fair Queueing avancé...

Revenons sur le mécanisme du Weighted Fair Queueing (WFQ) vu à la section 3.

La notion de poids vient peser sur des flux et les rendre moins fair que d’autre (et donc les privilégier).

10.1 Calculs préliminaires

Nous disions donc que le mécanisme WFQ défini par Cisco repose sur l’utilisation du champ TOS de l’entête IP, plus exactement les bits dits de précédence qui sont les trois bits de poids fort de l’octet TOS.

Le routeur affecte un poids (weight) à chaque flux par assignation des bits de précédence de l’entête IP des paquets qui les portent. Les flux sont priorisés en fonction de ce poids. Le poids est calculé selon la formule : , n étant la valeur des bits de précédence (comprise entre 0 et 7). La valeur 4096 ou 32384 dépend de la version de l’IOS Cisco. Après s’être assuré que le mécanisme de QoS de l’interface n’est pas en simple FIFO, vous pouvez consulter cette valeur avec la commande : show queue interface . Cette commande indique, par flux (ou conversation) les informations suivantes : depth/weight/discard/tail/drop/interleave . ⁶

Avec cette méthode nous allons pouvoir affecter une partie de la bande passante aux flux que nous voulons. La méthode est la suivante : si nous affectons les précédences 1, 2, 3, 4, 5, 6, 7 respectivement à sept flux et la précédence 0 à vingt flux (arbitrairement 20 pour l’exemple) nous pourrons déterminer ce que nous pourrions appeler le total des précédences :

Chaque flux de précédence 1 à 7 prendra [(n + 1)∕total] parties de la bande passante, soit respectivement 2∕55, 3∕55, 4∕55, …, 8∕55 parties. Les 20 flux de précédence 0 prendront chacun 1∕55 de la bande passante.

Question : Si nous avons uniquement deux flux, dont un à la précédence 0 et un à la précédence n, quelle sera la part de bande passante pour chaque flux en fonction de n ? Faites le calcul pour chaque valeur possible de n en considérant une bande passante globale de 64 Kb/s.

Est-ce que vous retrouvez les chiffres mesurés au 3 ?

10.2 Application pratique sur Cisco

Nous reprenons nos deux flux maintenant bien connus.

• Affectation de précédence au flux 1 → 3. Une manière d’effectuer cela est de créer une route-map au niveau de configuration de base. Cette route-map portera un nom, par exemple rmap1, elle aura pour numéro de séquence 0. On lui fera correspondre l’access-list caractérisant le flux 1 → 3 (match ip address num ). On affectera à cette route-map la précédence 5 (set ip precedence 5).

  Notez que l’on peut également faire cela avec une policy-map (voir en annexe ??), mais on va changer un peu...

• Affectation de la route-map à une interface entrante par configuration de niveau interface avec la commande ip policy route-map nom . L’interface configurée sera bien évidemment celle recevant le flux à marquer.

  Bien évidemment, si vous avez choisi de procéder avec une policy-map, il faudra au contraire l’accrocher à l’interface avec service-policy input.

• Vérification que l’interface de sortie est bien en mode weighted fair. Si ce n’est pas le cas, soit retirer le service-policy en cours sur l’interface, et repositionner le WFQ traditionnel avec la commande d’interface fair-queue (le routeur va râler un peu que c’est deprecated, pas grave), ou autrement refaire une policy-map qui ne comporte rien d’autre que la class-default sur laquelle on aura positionné le fair-queue.
• Lancer le flux de fond sur la machine 2 si ce n’est déjà fait. Ce flux n’étant pas marqué spécialement aura la précédence 0. Lancer le flux de test sur la machine 1, vérifier à l’aide d’un analyseur sur la machine 3 qu’il est bien marqué dans le champ TOS (vérifier dans les options de l’analyseur que celui-ci n’est pas positionné pour interpréter DSCP-DiffServ sur le champ TOS : menu Editer Préférences Protocoles IP). Relever le débit et vérifier par le calcul si celui-ci ne diffère pas trop. La valeur affichée doit être du même ordre de grandeur que ce que nous donne le calcul.

11 Notes

11.1 QoS Hiérarchique

Les solutions modernes pour faire de la QoS offrent la possibilité de faire de la QoS hiérarchique. Il ne s’agit pas d’un nouvel algorithme, mais plutôt une façon d’utiliser les algorithmes connus, en les encapsulant les uns dans les autres.

L’idée de base est la suivante : à un niveau donné, on a une politique de QoS qui gère des paquets, et qui décide d’un faire sortir un à un instant donné. Mais ce paquet qui sort, il ne part pas sur le réseau, mais dans une autre stratégie de QoS qui englobe la première, et qui à son tour va décider du paquet qu’elle va faire sortir. Et ainsi de suite jusqu’à ce que le paquet sorte effectivement sur le réseau.

11.2 Et sur Linux...

Là pour le coup on peut dire que le monde du logiciel libre ne s’est pas contenté de réimplémenter quelque chose qui existait dans le domaine commercial, mais a bien été ici un précurseur dans le domaine. Linux proposait historiquement une première implémentation de la QoS qui faisait uniquement du shaping et qui était (d’après les experts) plutôt moche. La ré-implémentation de la QoS dans Linux a le mérite d’être claire, propre, et plutôt efficace (c’est tout en logiciel, même si l’on commence à voir des choses sur carte NetFPGA). Disons-le, au jour d’aujourd’hui les équipementiers "pro" sont encore un peu à la traîne... (imho)

Les quelques stratégies de QoS vues ici sont des classiques (elles existent depuis longtemps, et sont implémentées Cisco...). De nombreuses stratégies de QoS ont été implémentées sous Linux (voir le man tc, pour traffic control). Certaines ont un intérêt surtout académique, d’autres ont un intérêt plus pratique (voir le script wondershaper).