Plate-forme de mesures passives : choix et mise en place

3.1 Description de la plateforme de mesures passives

La première contrainte pour la mise en place d’une infrastructure de mesures, vient du fait qu’il s’agit d’un réseau opérationnel, qui doit continuer à fonctionner même en cas de problèmes au niveau des sondes installées. C’est pourquoi, nous avons opté pour les plates-formes de mesures passives consistant à regarder le trafic transitant par le réseau afin d’en déduire ses caractéristiques.

Chapitre3 : Mesures dans RNU

Étant donné que le paquet est l’entité élémentaire mesurable dans un réseau IP, toutes les métriques relatives aux paquets, flux ou sessions, peuvent être théoriquement mesurées, calculées ou dérivées à partir des traces de trafic microscopiques composées par tous les paquets traversant le

réseau. C’est pourquoi, nous avons opté pour une plate-forme de mesures passives de niveau paquet, permettant de collecter tous les paquets traversant un nœud du réseau et de leur ajouter les

estampilles associées à leur date de passage.

Il existe plusieurs techniques de capture de paquets traversant un réseau donné. Parmi lesquelles : 1. Installer un « splitter » sur le lien physique de façon à dévier et amplifier une partie du signal

transportant les données vers la sonde de mesure qui doit capter cette copie du trafic pour l’analyser. L’avantage principal de cette méthode est qu’elle est complètement transparente pour les équipements actifs tels que les commutateurs et les routeurs, c’est d’ailleurs pour cette raison que la plupart des compagnes de mesures passives citées dans le chapitre 1 l’ont adopté (en utilisant des splitter et des cartes DAG). Concernant les inconvénients, cette méthode est relativement coûteuse de plus elle ne peut être utilisée que par un opérateur qui construit lui-même ses liaisons et a ainsi un contrôle total sur elles, Or ceci n’est pas le cas du réseau RNU pour lequel toutes les liaisons sont louées à l’opérateur de télécommunications national ce qui limite considérablement les possibilités d’intervention sur les liens physiques.

2. Activer au niveau d’un équipement d’interconnexion (routeur ou pare-feu réseau), un module de collecte des flux transitant par ses interfaces: La plupart des constructeurs de matériel d’interconnexion proposent cette fonctionnalité et permettent d’utiliser un format standard pour l’enregistrement des traces collectées, IPFIX (IP Flow Information eXport). Toutefois l’expérience montre que l’influence de cette technique sur la performance des routeurs est non négligeable. De plus, elle ne produit que des mesures agrégées de niveau flux ce qui ne permet pas d’étudier les caractéristiques de trafic au niveau paquet.

3. Capter le trafic au niveau des commutateurs Ethernet en utilisant la technique de SPAN (Switched Port Analyzer). Cette technique permet de recopier sur un port donné tout le trafic destiné à (et/ou provenant de) un ou plusieurs autres ports. La sonde de mesure connectée au port SPAN peut ainsi surveiller le trafic provenant de n’importe quel port du commutateur sans perturber le fonctionnement du réseau.

C’est cette dernière technique, qui est adoptée pour la première plate-forme de mesures passives sur RNU. Elle a été installée pour collecter diverses traces de trafic sur RNU entre 2004 et 2006 ; elle est composée d’une machine de type PC sous Linux disposant d’un vecteur de disques SCSI de grande capacité et d’une carte réseau classique de type Ethernet 100 Mb/s connectée sur un port Ethernet d’un commutateur spécialement configuré, de façon que la sonde puisse recevoir une copie du trafic transitant par les interfaces Ethernet d’un ou de plusieurs routeurs de concentration de trafic.

Pour le logiciel, nous avons opté pour le système d’exploitation Linux, la librairie libre Libpcap (packet capture library) et les utilitaires Tcpdump [Tcpdump] et Ipsumdump [Ipsum]. Le choix de ces outils est motivé par le fait que Tcpdump est léger (puisqu’il est dépourvu d’interface graphique et qu’il n’effectue aucun traitement sur les paquets en dehors de l’ajout d’une estampille temporelle). De plus, la solution adoptée est nettement plus économique que les deux autres décrites plus haut. En effet, le coût de mise en place d’une telle solution peut être limité à 2000 dinars, alors que celui d’une solution à base de cartes DAG s’élève à au moins à une dizaine de milliers de dollars [Dag]. Pour assurer la fiabilité et la qualité des traces de mesures, nous avons pris certaines précautions lors de la mise en place de la sonde, en s’inspirant des travaux de Vern Paxon [Paxs97] et de l’équipe du projet WAND en Nouvelle-Zélande [Clea00, Mich01a et Mich01b]. Ainsi pour limiter le volume des données enregistrées, nous avons choisi de collecter uniquement 68 octets par trame Ethernet observée ce qui correspond à un compromis entre la taille minimale des entêtes Ethernet, IP et TCP (14+20+20=54octets) et la taille maximale de ces dernières (14+60+60=134 octets) ce qui permet, en l’absence d’options IP et TCP, de capturer 14 octets de données en plus de toutes les entêtes protocolaires.

Pour assurer une bonne précision de l’estampille temporelle, il est nécessaire qu’elle soit ajoutée au moment même de la réception du paquet par l’interface réseau. Or, ceci n’est pas possible avec des cartes réseaux classiques, contrairement aux cartes de capture spécialisées (telles que les cartes DAG). En effet, lorsqu’une carte réseau classique reçoit des paquets, elle génère une interruption pour demander au noyau du système d’exploitation d’enregistrer les entêtes, grâce à la bibliothèque Libpcap, et d’ajouter l’estampille en se basant sur la variable TSC¹. Comme le traitement de l’interruption générée par la carte réseau est dépendant de son pilote² et du système d’exploitation, l’ajout de l’estampille se trouve retardée ainsi plusieurs paquets peuvent être avoir la même valeur d’estampille surtout si le nombre de paquets reçus par la carte est important. D’après [Pasz02], la précision de l’estampille TSC ajoutée par Tcpdump est seulement de l’ordre de la milliseconde. Par ailleurs, l’enregistrement des entêtes de tous les paquets transitant au niveau d’un réseau nécessite d’avoir une puissance de calcul et une capacité de stockage importantes [Mich01b]. Dans le cas du réseau RNU, nous avons défini l’espace de stockage et le débit de collecte des paquets nécessaires pour garantir que la sonde arrive effectivement à traiter tous les paquets qui la traversent. Ces besoins sont calculés dans les conditions extrêmes d’utilisation du réseau correspondants à des rafales de petits paquets de 40 octets chacun. Dans ces conditions la plate-forme de mesures doit enregistrer, pour chaque paquet IP de 40 octets, 8 octets pour l’estampille, 14 octets pour l’entête

1

La variable TSC (timestamp counter) a une taille de 8 octets ce qui permet une résolution de 1ns.

2

Généralement une interruption est envoyée par la carte réseau pour demander la lecture des paquets reçus, lorsque le tampon de la carte réseau est plein ou après l’écoulement d’un certain timeout prédéfini.

Chapitre3 : Mesures dans RNU

Ethernet ainsi que les 40 octets correspondant à la taille du paquet à enregistrer ; ce qui correspond à 62 octets de données.

Pour le cas d’une liaison symétrique à 12 Mb/s³, le calcul montre que la plate-forme de mesures doit être capable de capter, de transférer vers la mémoire et ensuite vers le disque un débit maximal de 37,2 Mbits/s ce qui reste largement en dessous des performances d’un slot PCI standard 32 bits 66MHz (266 Moctets/s, soit 2128 Mbits/s) [Mich02b] sur lequel est connectée la carte réseau.

3.2 Description des traces collectées

Des traces de différentes durées ont été collectées entre mai 2004 et avril 2006 grâce à la sonde de mesures passives décrite plus haut (voir le Tableau 3.1 pour le détail des traces collectées).

Trace Période Lien Durée totale Taille [Goctets] Débit max [Mbits/s] Paquets [10⁶] T1 29 mai 2004 CCK-el Manar / ATI 24 h 8,6 12 129

T2 Du 10/08/04 au 17/08/04 CCK-el Manar / CCK-el Kasbah 7 jours 14,2 10 213 T3 Du 05/04/06 au 06/04/06

CCK-el Kasbah / ATI 24 h 25,4 50 284

T4 Du 07/04/06 au 08/04/06

CCK-el Kasbah / ATI 24 h 31,8 50 356

Tableau 3.1 : Traces collectées

Chaque trace est composée par plusieurs fichiers d’une heure chacun, et couvre ainsi une durée minimale de 24 heures. Toutes les traces sont bidirectionnelles, c’est à dire qu’elles contiennent le trafic des deux sens du lien surveillé. L’emplacement de la sonde de mesures a suivi l’évolution de l’architecture du réseau RNU et a permis de collecter le trafic au niveau de différents liens.

La trace T1, collectée alors que l’architecture du réseau RNU était centralisée (Figure 3.2), contient les entêtes de tous les paquets envoyés par tous les utilisateurs du RNU vers Internet et inversement. La trace T2, collectée alors que l’architecture du réseau RNU était celle de la Figure 3.3, contient tous les paquets traversant le lien inter-POPs CCK-el Manar et CCK-el Kasbah. La nature du trafic sur ce lien est fondamentalement différente du trafic de la première trace, puisqu’il est composé de connexions vers les serveurs hébergés au niveau de ces nœuds (essentiellement des serveurs web, mail et proxy), ainsi que du trafic d’accès à Internet des institutions universitaires de la région el Manar.

3

12 Mbits/s correspond à la capacité de la liaison entre CCK-el Manar et l’agence tunisienne d’Internet en 2004. Cette liaison transportait tout le trafic du réseau RNU vers Internet et inversement.

Enfin, les traces T3 et T4 collectées alors que le réseau RNU avait l’architecture actuelle (Figure 3.4), contiennent le trafic transporté par le lien reliant CCK-el Kasbah à l’Agence Tunisienne d’Internet (plus précisément les entêtes de tous les paquets envoyés par les utilisateurs du RNU vers Internet et inversement).