TP : Introduction à la qualité de service liée à la Toip 1

TP : Introduction à la qualité de service liée à la Toip 1 Résumé Ce document présente un exemple de travaux pratiques liés aux flux réseaux ainsi qu à la qualité de service dans le contexte de la téléphonie sur IP. La mesure des performances réseaux dans le domaine de la TOIP (délai de transit, gigue, perte de paquets..) est réalisée à l'aide d'outils professionnels. Afin d améliorer la QoS 2 perçue par les utilisateurs, nous verrons qu il est nécessaire de gérer le trafic, notamment via la priorisation des flux de Toip et la réservation de la bande passante nécessaire à ces derniers. mots clés : IP, RTP, SIP, Qos, Mos Objectifs : Mettre en évidence les paramètres liés à la QoS dans le domaine de la TOIP (Codec, performances réseaux, Mos) Mesurer les performances du réseau dans le domaine de la TOIP (délai de transit, gigue, perte de paquets..) Régler les files d'attentes (ordonnancement,.. filtres) des flux réseaux et mesurer ses effets (banc d'essai). 1. MESURES DES FLUX RÉSEAUX LIÉS À LA TOIP A- Téléphone SIP a) Communication Mettre en relation 2 téléphones SIP (e.g. Ekiga) et vérifier le bon fonctionnement b) Observations Rappeler les ports utilisés par les protocoles SIP et RTP avec Wireshark : c) Statistiques SIP avec Wireshark Enregistrer les trames lors de l'établissement d'une communication (appeler, communiquer pendant quelques secondes puis raccrocher) Relever alors les statistiques de la communication (Statistics -> SIP) Relever également l'appel tracé par Wireshark (Statistics -> VoIP Calls) Comment sont négociés les Codecs utilisés? Relever l'analyse du flux RTP (Statistics -> RTP-> Stream Analyse) Combien de paquets sont perdus? B- Dégradation du lien Les étapes ci-dessous sont à effectuer sur un des softphones sur votre configuration initiale composée de 2 postes (softphones). 1 Inspiré du TP de de Laurent DUVAL, Département Réseaux et Télécommunications La Roche/Yon. 2 QoS signifie «Quality of Service», aussi connue sous le nom de QdS en français «Qualité de service». La QoS peut s exprimer via des métriques : le délai, la gigue, la bande passante et le taux de perte de paquets.

Nous utiliserons le framework NetEm de la pile IP de linux pour modifier le délai et le taux de perte des flux. NetEm se manipule via l outil tc (traffic control) dont la commande vous est donnée ci-dessous. La première supprime toutes les précédentes règles appliquées au trafic sur l interface eth1. La seconde ajoute une règle qui spécifie que le trafic doit être redirigé vers netem et que ce dernier appliquera un délai de 400ms, une gigque de 50ms et que 0.03% des paquets seront jetés. Vous en savez assez pour l instant mais pour plus de détails, rendez vous sur le site de http://swik.net/netem/examples+of+use. tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1:0 netem delay 400ms 50ms loss 0.03% Pour chacune des expérimentations ci-dessous, vous relèverez votre perception de la qualité de la conversation et la noterez sur votre compte rendu. Vous utiliserez l échelle du MOS (Mean Opinion Score) vue au cours des précédents TPs. 1. Variation du délai : Avec un taux de perte à 0% et une gigue de 0ms, faites varier le délai avec des valeurs de 10ms, 50ms, 200ms, 500ms et 800ms. Déterminez notamment à partir de quelle valeur il ne vous paraît plus possible d avoir une conversation. 2. Variation du taux de perte : En fixant le délai à 0ms, vous ferez varier le taux de perte de 1%, 2%, 5%, 10% et 20%. Avez vous entendu le FEC se mettre en action? Si oui, à partir de quel moment? A partir de quel taux de perte il ne peut plus y avoir de conversation? 3. Variation de la gigue : En fixant le taux de perte à 0% et le délai à 100ms, faites varier la gigue de 10ms, 50ms, 100ms, 200ms et 500ms. A partir de quelle valeur il ne peut plus y avoir de conversation? Une fois terminé supprimez toutes les règles de votre gestionnaire tc via la commande tc qdisc del dev eth0 root. C- Analyse 1. Dans la section précédente vous avez observé que la qualité de la conversation varie en fonction de la valeur des métriques de QoS. Donnez pour chacune des métriques de QoS (taux de perte, gigue, délai) les valeurs seuils au delà desquelles la qualité de la conversation n est plus bonne (au sens du MOS). 2. Dans un réseau, qu elles sont les conditions qui amèneraient à ce que ces seuils soient franchis? 3. Quelles sont selon vous les mesures à prendre pour éviter que ces conditions soient présentes et donc pouvoir maintenir une bonne qualité de service à l utilisateur? 2. RÉGLAGES ET TESTS DE LA QOS A- Introduction à la QoS a Le modèle Intserv / RSVP: RSVP est un protocole de signalisation qui permet de réserver dynamiquement de la bande passante et de garantir un délai, ce qui le rend particulièrement efficace pour des applications comme la VoIP.

RSVP oblige les routeurs à maintenir des informations d'état pour chaque flot qui le traverse. Lorsque le nombre d'usagers augmente, le nombre d'états ainsi que les traitements à effectuer deviennent conséquent. Le trafic est d'autant plus saturé que ces états doivent être négociés et échangés entre routeurs ce qui génère d'avantage de surcharge. d) Le modèle DiffServ : Le modèle DiffServ propose de séparer le trafic par classes, contrairement à IntServ qui procède à une séparation par flux. La conséquence directe est que les routeurs DiffServ (appelés aussi routeurs DS-capable) traitent tous les paquets d'une classe donnée de la même manière, sans distinction d'émetteur ni de récepteur. Chaque classe est identifiée par une valeur codée dans l'en-tête IP champ TOS (Type Of Service). Cette classification doit se faire sur les routeurs de bordures (edge router) à l'entrée du réseau. Un politique de mise en file d'attente est appliquée aux différentes classe de services. Cela permet d'effectuer du traitement différencié entre ces classes e.g. priorisation, assurer un délai min, un débit min ( ). e) La qualité de service de bout-en-bout Intserv permet de reserver des ressources de bout en bout, entre la source et la destination ou sur une partie du réseau. Cependant, cela necessite que les routeurs soient capables de traiter les requètes IntServ et que la source soit autorisée à réserver des ressources. Par conséquent, lorsque l'ensemble des routeurs traversé n'appartient pas à la même entité, il n'est souvent pas possible d'utiliser IntServ de bout en bout. Il est par exemple quasi impossible d'utiliser IntServ de bout en bout sur l'internet. Il est alors nécessaire d'utiliser DiffServ sur les régions que la source ne maitrise pas et les régions DiffServ du réseau sont traitées comme des liens virtuels reliant les routeurs ou les terminaux IntServ. La visibilité de l'utilisateur est alors réduite à IntServ. Dans le modèle DiffServ, un contrat de QoS est négocié et le réseau s'engage à assurer la QoS demandée pour les flux tant que les sources respectent le profil de trafic accordé. C est via un ordonnancement spécifique des paquets servis par les routeurs, que ce contrat peut être respecté; la conformité du trafic est assurée par une régulation du trafic en bordure du domaine. f) Les éléments de QoS Chaque interface réseau d une machine linux ou d un routeur dispose d'un gestionnaire de mise en file d'attente d'entrée et de sortie.

Les gestionnaires d entrée et de sortie peuvent filtrer les flux afin de les orienter vers divers gestionnaires de files d'attente. L'ordonnanceur gère ces files selon la politique choisie pour les distribuer vers sur le lien de sortie. La politique par défaut est de type FIFO. g) Les éléments gestionnaires de file d attente Queuing disciplineqdisc ordonnanceur : FiFo, Prio, SFQ, CBQ,... Class class gestionnaire de files d'attente Filter filter classification par filtrage Queueing Discipline : Gestionnaire de mise en file d'attente. Un algorithme qui gère la file d'attente d'un périphérique, soit pour les données entrantes (ingress), soit pour les données sortantes (egress). Classless qdisc (pfifo_fast, tbf, red, sfq, pfifo, bfifo) : Gestionnaire de mise en file d'attente sans classes c.a.d. un gestionnaire de mise en file d'attente qui n'a pas de subdivisions internes configurables. Classful qdisc (prio, cbq, htb) : Gestionnaire de mise en file d'attente qui contient de multiples classes. Chacune de ces classes contient un gestionnaire de mise en file d'attente supplémentaire, qui peut encore être basé sur des classes, mais ce n'est pas obligatoire. Classes : Un gestionnaire de mise en file d'attente peut avoir beaucoup de classes, chacune d'elles étant interne au gestionnaire. Chacune de ces classes peut contenir un gestionnaire de mise en file d'attente réel. Classificateur (Classifier) : Chaque gestionnaire de mise en file d'attente basé sur des classes a besoin de déterminer vers quelles classes il doit envoyer un paquet. Ceci est réalisé en utilisant le classificateur. Filtre (Filter) : La classification peut être réalisée en utilisant des filtres. Un filtre est composé d'un certain nombre de conditions qui, si elles sont toutes vérifiées, satisfait le filtre.

Ordonnancement (Scheduling) : Un gestionnaire de mise en file d'attente peut, avec l'aide d'un classificateur, décider que des paquets doivent sortir plus tôt que d'autres. Ce processus est appelé ordonnancement (scheduling), et est réalisé par exemple par le gestionnaire pfifo_fast mentionné plus tôt. Mise en forme (Shaping) : Le processus qui consiste à retarder l'émission des paquets sortants pour avoir un trafic conforme à un débit maximum configuré. La mise en forme est réalisée sur egress. Familièrement, rejeter des paquets pour ralentir le trafic est également souvent appelé Mise en forme. Réglementation (Policing) : Retarder ou jeter des paquets dans le but d'avoir un trafic restant en dessous d'une bande passante configurée. Dans Linux, la réglementation ne peut que jeter un paquet, et non le retarder dans la mesure où il n'y a pas de << file d'attente d'entrée >> (ingress queue). h) Ordonnanceurs PFIFO_FAST : C est l ordonnanceur par défaut, "First In First Out". En réalité, il gère 3 files prédéfinies en mode PRIO en utilisant le champs ToS de l'entête IP comme critère. En simplifiant, le type Minimize Delai est le plus prioritaire, puis Maximize reliability (best effort ) et enfin Maximize throughout. Avec pfifo_fast, la priorité ne peut pas être redéfinie et elle ne dépend que du champs ToS. PRIO : permet de classer les flux selon leur priorité. Les paquets appartenant à un flux sont envoyés avant les paquets des flux de plus basse priorité. Tant que des paquets sont en attente dans ce flux, on ne considère pas les paquets des flux suivants. De plus, les paquets favorisés le sont de manière excessive, rien ne peut être envoyé dans une classe tant qu une classe de priorité plus haute a des paquets à émettre. SFQ : Le "Stochastic Fair Queuing" réparti aléatoirement les flots du trafic en plusieurs files d attente. Chaque file d attente est servie équitablement c.a.d. une même quantité de donnée est retirée de chacune des files et elles obtiennent une part égale de la bande passante disponible. La répartition des flots dans les différentes files d attentes est répétée fréquemment (selon une période appelée quantum). L objectif de SFQ est de fournir un service équitable pour chaque flot. Cependant, si il y a trop de flots qui transitent par cette interface, cela peut devenir trop complexe. La répartition aléatoire de SFQ permet d assurer que sur le moyen / long terme, le service sera équitable pour chaque flot sans pour autant nécessiter beaucoup de ressources du CPU. CBQ : Class Base Queuing est la plus intuitive et la plus utilisée. Elle crée des files d attente auxquelles sont attribuées une certaine bande passante. Elle permet de réaliser le traditionnel traffic shaping : le trafic est partagé en flux d importances prédéfinies, la classification étant effectuée grâce à des facteurs arbitraires. HTB: (Hierarchical Token Bucket) travaille juste comme CBQ, mais il n'a pas recourt à des calculs de temps d'inoccupation pour la mise en forme. A la place, c'est un Token Bucket Filter basé sur des classes, d'où son nom. CSS : Clark Shenker Shang sépare tout d abord les flux en deux catégories : Les services garantis : sont en temps réel borné avec une contrainte de délai au pire. Les services prédictifs : on donne juste par calcul, une borne pour le délai d acheminement. B- Implémentation Linux a Gestionnaires de file d'attente : racines, descripteurs, descendances et parents Chaque interface (e.g. eth*, wlan*..) a << un gestionnaire racine >> de sortie (egress root qdisc). Par défaut, le gestionnaire de mise en file d'attente est pfifo_fast. Chaque gestionnaire peut être repéré par un descripteur (handle), qui pourra être utilisé par les

prochaines déclarations de configuration pour se référer à ce gestionnaire. En plus du gestionnaire de sortie, une interface peut également avoir un gestionnaire d'entrée (ingress), qui réglemente le trafic entrant. Ces descripteurs sont constitués de deux parties : un nombre majeur et un nombre mineur. Il est habituel de nommer le gestionnaire racine 1:, ce qui est équivalent à 1:0. Le nombre mineur d'un gestionnaire de mise en file d'attente est toujours 0. 1:0 root qdisc 1:1 classe enfant / \ / \ 1:10 1:20 1:30 classes terminales 10: 20: 30: qdisc sfq tbf sfq Le principe est le suivant : 1. Définition d une architecture d ordonnancement sur le périphérique 2. Si l architecture comporte des classes, définitions des classes 3. Classification des paquets en flux. 4. Affectation des flux de paquets aux classes. L utilitaire tc permet de transmettre au noyau les paramètres que l on souhaite mettre en place. C est un utilitaire de la famille iproute2. La syntaxe utilisée par ce programme est : tc [ OPTIONS ] OBJECT { COMMAND help } avec OBJECT := { qdisc class filter } OPTIONS := { -s[tatistics] -d[etails] -r[aw] -b[atch] file } i) Queueing Discipline CBQ Reprenons les 4 points de la mise en place de la QoS dans notre gestionnaire de file d attente. L attribution d une architecture d ordonnancement au périphérique est la première étape nécessaire : tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000 mpu 64 On définit ici une architecture de type CBQ sur le périphérique eth0. bandwidth : La paramètre bandwidth est utilisé par les calculs effectués par l ordonnanceur et décrit la bande passante physique disponible sur le périphérique. handle : Il nomme la queueing discipline 10 : ; ceci permet ensuite de créer des flux nommés 10:xx. avpkt : Cette variable définit la taille moyenne des paquets associés à cette discipline. Elle est utilisée à des fins de calculs de bande passante. mpu : Taille minimum des paquets j) Class CBQ tc class add dev ppp0 parent 10:0 classid 10:1 cbq /

bandwidth 10Mbit rate 64Kbit weight 4 / allot 1514 prio 1 avpkt 200 isolated La commande précédente crée un flux de type CBQ. parent : On indique la parenté du flux avec le mot parent. Notez qu on conserve le paramètre bandwidth. rate : On spécifie la bande passante allouée à ce flux avec le mot clef rate. weight : Le mot clé optionnel weight est par défaut égal à rate et définit l importance relative des flux les uns par rapport aux autres. allot : Variable utilisée par les calculs, elle doit être égale au MTU. Pour qualifier le flux, on dispose de deux mots et de leur combinaison : bounded : Le flux est limité en bande passante, il n est pas possible de dépasser la bande passante indiquée. Cette notion n est clairement pas optimale puisque les ressources réseau ne sont pas utilisées à plein. Par exemple, si un seul flux est actif, il ne peut prendre toute la bande passante isolated : Le flux n autorise pas que l on emprunte de sa bande passante. bounded isolated : Le flux est limité en bande passante et ne partage pas la sienne. Pour créer un flux fils, on peut utiliser : tc class add dev ppp0 parent 10:1 classid 10:3 cbq / bandwidth 10Mbit rate 32Kbit / allot 1514 prio 1 maxburst 20 avpkt 200 isolated On spécifie en plus ici que le flux a la priorité la plus forte : prio : Ce mot clé permet de définir la priorité du flux, la priorité varie de 1 à 8. maxburst : Elle permet de spécifier le nombre de paquets maximum pouvant être envoyé en une rafale. Pour un réseau 10Mbit la valeur recommandée est 20. k) Qdisc TBF Le Token Bucket Filter (TBF) est un gestionnaire de mise en file d'attente simple. Il ne fait que laisser passer les paquets entrants avec un débit n'excédant pas une limite fixée administrativement. L'envoi de courtes rafales de données avec un débit dépassant cette limite est cependant possible. TBF est très précis, et peu gourmand du point de vue réseau et processeur. Pour rappel un seau à jeton consiste en un tampon (seau), constamment rempli par des éléments virtuels d'information appelés jetons, avec un débit spécifique (débit de jeton). Le paramètre le plus important du tampon est sa taille, qui correspond au nombre de jetons qu'il peut stocker. Chaque jeton entrant laisse sortir un paquet de données de la file d'attente de données et ce jeton est alors supprimé du seau. L'association de cet algorithme avec les deux flux de jetons et de données, nous conduit à trois scénarios possibles : Les données arrivent dans TBF avec un débit EGAL au débit des jetons entrants. Dans ce cas, chaque paquet entrant a son jeton correspondant et passe la file d'attente sans délai. Les données arrivent dans TBF avec un débit PLUS PETIT que le débit des jetons. Seule une partie des jetons est supprimée au moment où les paquets de données sortent de la file d'attente, de sorte que les jetons s'accumulent jusqu'à atteindre la taille du seau. Les jetons contenus dans le seau peuvent être utilisés pour

envoyer des données avec un débit supérieur au débit des jetons standard, si de courtes rafales de données arrivent. Les données arrivent dans TBF avec un débit PLUS GRAND que le débit des jetons. Ceci signifie que le seau sera bientôt dépourvu de jetons, ce qui provoque l'arrêt de TBF pendant un moment. Ceci s'appelle une situation de «dépassement de limite». Si les paquets continuent à arriver, la capacité de la file d attente sera dépassée et ils commenceront à être éliminés. Les paramètres sont le suivants: Limit : les nombre d'octets qui peuvent être mis en file d'attente en attendant la disponibilité de jetons. burst/buffer/maxburst : Taille du seau, en octets. C'est la quantité maximale, en octets, de jetons dont on disposera simultanément. En général, plus les débits de mise en forme sont importants, plus le tampon doit être grand. Mpu : Un paquet de taille nulle n'utilise pas une bande passante nulle. Pour ethernet, la taille minimale d'un paquet est de 64 octets. L'Unité Minimale de Paquet (Minimun Packet Unit) détermine le nombre minimal de jetons à utiliser pour un paquet. Rate : Le paramètre de la vitesse. Voir les remarques au-dessus à propos des limites! Peakrate : Si des jetons sont disponibles et que des paquets arrivent, ils sont immédiatement envoyés par défaut ; Cela peut ne pas vous convenir, spécialement si vous avez un grand seau. Le débit de crête (peak rate) peut être utilisé pour spécifier la vitesse à laquelle le seau est autorisé à se vider. Si tout se passe comme écrit dans les livres, ceci est réalisé en libérant un paquet, puis en attendant suffisamment longtemps, pour libérer le paquet suivant. Le temps d'attente est calculé de manière à obtenir un débit égal au débit de crête. Cependant, étant donné que la résolution du minuteur (timer) d'unix est de 10 ms et que les paquets ont une taille moyenne de 10 000 bits, nous sommes limités à un débit de crête de 1mbit/s! mtu/minburst} Le débit de crête de 1Mb/s ne sert pas à grand chose si votre débit habituel est supérieur à cette valeur. Un débit crête plus élevé peut être atteint en émettant davantage de paquets par top du minuteur. Un minburst de 3000 octets minburst autorise un débit de 3mbit/s en peakrate si les paquets sont de 1000 octets. Exemple : # tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540 l) Qdisc HTB Le qdisc HTB est similaire à TBF à l exception du faite qu il est classful. m) Les classificateurs et l option filter Pour pouvoir ranger les paquets par classe, il est nécessaire de pouvoir les classifier. L implémentation de la qualité de service sous linux comporte trois classificateurs. Classificateur fw (FireWall) via les règles de iptable

Les paquets sont affectés à une file suivant leur marquage par Netfilter. Par exemple : iptables t mangle A OUTPUT o eth0 p tcp j mark set mark 1 On appose ici la marque 1 au paquet sortant sur l interface eth0 et étant des paquets de type TCP. Ensuite on peut assigner à ces paquets une file : tc filter add dev eth0 parent 1:0 protocol ip handle 1 fw flowid 1:1 Classificateur u32 Le classificateur u32 permet de lire n importe quel champ de l entête IP et de classer les paquets dans les files suivant la valeur de ce paramètre. u32 supporte des raccourcis permettant par exemple d attendre facilement les entêtes spécifiques à TCP. Filtrage d une adresse IP source : la syntaxe est la suivante : tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.168.1.0/24 flowid 1:1 Cette règle associe au flux 1:1 tous les paquets provenant du réseau 192.168.1.0/24 en remplaçant 192.168.1.0/24 par une IP standard, on filtre uniquement sur cette IP. En substituant dst à src, on filtre sur la destination. Filtrage sur l entête TCP : La syntaxe est tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match tcp src 80 flowid 1:1 Filtrage sur un entête quelconque : paquets ACK la file 1 :10 tc filter add dev eth0 parent 1: protocol ip prio 12 u32 match ip protocol 6 0xff match u8 0x05 \ 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10 b Classificateur route L utilitaire route permet de numéroter les routes. Le classificateur route classe les paquets suivant le numéro de leur route. Il est nécessaire d utiliser ip qui permet de numéroter les routes en utilisant le mot clé realm : ip route add 192.168.1.0/24 via 192.168.1.1dev eth2 realm 15 On peut ensuite mettre les paquets empruntant cette route dans une classe : tc filter add dev eth2 parent 1:0 protocol ip prio 1 route to 15 classid 1:1 n) Visualisation des classes et filtres Pour visualiser les informations, il faut utiliser tc avec la commande ls : tc s d filter ls dev eth0 tc s d class ls dev eth0 Les options -s (resp. -d) permettent d afficher les statistiques (resp. les détails). o) Nettoyage des règles Pour enlever toutes les règles, il suffit de supprimer la discipline à la racine : tc qdisc del dev eth0 root C- Mise en Oeuvre a) Créer le script suivant : #!/bin/bash iptables t mangle F

iptables t mangle A OUTPUT o eth1 p tcp j MARK set mark 1 iptables t mangle A OUTPUT o eth1 p udp j MARK set mark 2 # iptables v t mangle L tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000 mpu 64 tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10MBit rate 2Mbit allot 1514 prio 1 maxburst 20 avpkt 200 bounded tc class add dev eth1 parent 10:0 classid 10:2 cbq bandwidth 10MBit rate 4Mbit allot 1514 prio 1 maxburst 20 avpkt 200 bounded tc filter add dev eth1 protocol ip handle 1 fw flowid 10:1 tc filter add dev eth1 protocol ip handle 2 fw flowid 10:2 b) Répondez aux questions 1. Quel type d'ordonnanceur est utilisé? 2. Représenter la hiérarchie des classes 3. A combien est limité la bande passante de la classe 10:1 4. Cette classe peut elle prendre plus de bande passante disponible? 5. Quelle commande (ligne) permet d'associer les paquets marqués "1" à la classe 10:1 6. Comment (via quels critères) iptables fait pour marquer les paquets 7. Compléter ce script pour afficher la configuration de la table mangle (iptables), les informations sur les files d'attente, les classes et les filtres de l'interface ethernet. c) Test & Mesures 1. En utilisant iperf, générez un flot TCP et un flot UDP avec un débit illimité pour TCP et un débit max de de 10mb/s pour UDP. Relevez quelle est la bande passante obtenu par chacun de ces flots. 2. Appliquer ce script. 3. Refaites les mesures de la question 1. 4. A l aide de wireshark, determinez la taille des paquets UDP et TCP qui sont envoyés par iperf. Ajustez la valeur de «avpkt» dans le script et renouvelez les mesures de la question 1. Que constatez vous? 5. Modifier le script et relever les graphs pour une bande passante totale de 1,4,10 et 30 Mbits/s. Des remarques? 6. Remettez la valeur initiale pour la bande passante. Supprimer le filtre concernant UDP. Refaites les mesures de la question 1. Que s est il produit? d) Qos en fonction du type de session Les transferts de fichiers sont souvent repérables par leur longueur, en effet ceux-ci sont de 500 à 1500 octets alors que les connexions interactives (ssh, telnet,..) sont entre 0 et 500 octets. 1. Proposer des règles de marquage pour distinguer ces 2 types de sessions et non pas une simple distinction tcp/udp.

e) Pour aller plus loin HTB Implémentez la même architecture avec HTB. Références http://snafu.freedom.org/linux2.2/iproute-notes.html Linux Advanced Routing and Traffic Control Howto http://www.linux-france.org/prj/inetdoc/telechargement/lartc.pdf Annexe : #!/bin/bash iptables t mangle F iptables t mangle A OUTPUT o eth2 j MARK set mark 3 iptables t mangle A OUTPUT o eth2 p tcp j MARK set mark 1 iptables t mangle A OUTPUT o eth2 p udp m length length 500:0xffff j MARK set mark 2 iptables v t mangle L tc qdisc del dev eth2 root tc qdisc add dev eth2 root handle 10: cbq bandwidth 20Mbit avpkt 1200 mpu 64 tc class add dev eth2 parent 10:0 classid 10:1 cbq bandwidth 20MBit rate 2Mbit allot 1514 prio 1 maxburst 20 avpkt 1200 bounded tc class add dev eth2 parent 10:0 classid 10:2 cbq bandwidth 20MBit rate 4Mbit allot 1514 prio 1 maxburst 20 avpkt 1200 bounded tc class add dev eth2 parent 10:0 classid 10:3 cbq bandwidth 20MBit rate 16Mbit allot 1514 prio 1 maxburst 20 avpkt 1200 tc qdisc add dev eth2 parent 10:3 handle 30: sfq tc filter add dev eth2 protocol ip handle 1 fw flowid 10:1 tc filter add dev eth2 protocol ip handle 2 fw flowid 10:2

tc filter add dev eth2 protocol ip handle 3 fw flowid 10:3 #tc filter add dev eth2 protocol ip handle 0 flowid 10:3 tc s class ls dev eth2 tc s filter ls dev eth2 tc qdisc ls dev eth2