La génération de trafic réseau est essentielle pour évaluer les performances du réseau du campus de l’université de Souk-Ahras. Cette étude documente et émule le réseau afin d’identifier les problèmes de débit et de perte de paquets, garantissant ainsi une infrastructure robuste.
Chapitre 6
Génération, contrôle et analyse du trafic de test
Introduction
L’analyse comparative d’une simulation d’un réseau est un élément crucial pour assurer son succès lors de sa mise en réel. Cela inclut les tests de résistance et la génération du trafic sur le réseau simulé, qui nous aide à identifier les zones potentiellement défectueuses ou vulnérables, par exemple les baisses de connexion et la perte de paquets. Comme nous le savons, le trafic réseau est essentiel pour notre université, car il détermine la manière dont les données circulent et avec quelle efficacité nos applications interagissent.
Dans le cadre de notre travail, il serait bien d’avoir un générateur qui peut générer du trafic pour pouvoir créer de la congestion du réseau.
IPerf3
IPerf3 est un outil de ligne de commande utilisé pour diagnostiquer les problèmes de vitesse du réseau en mesurant le débit réseau maximal qu’un serveur peut gère. Il peut servir aussi a évalué des paramètres tels que la bande passante, le délai, la taille de la fenêtre et la perte de paquets [16].
Les analyseurs du trafic réseau
Dès que l’on dispose d’une vue formelle des modèles TCP/IP, une activité d’observation du trafic réseau permet de s’initier à des pratiques plus avancées grâce à un analyseur de paquets. Un analyseur de trafic de réseau;également appelé analyseur de protocole ou analyseur de paquets. L’analyseur de trafic est un outil essentiel pour comprendre les mécanismes de fonctionnement des protocoles de communication sur le réseau. L’analyseur de paquets est capable de décoder, sauvegarder, traiter, analyser et présenter la capture. On trouve l’analyseur Wireshark qui constitue un logiciel incontournable en la matière.
Wireshark
Wireshark est un analyseur de paquets réseau. il peut capturer le trafic de nombreux types de supports réseau différents, notamment Ethernet, LAN sans fil, Bluetooth, USB, etc, et présenter les paquets avec autant de détails que possible (Voir Figure 6.1). Wireshark est disponible gratuitement, est open source et est l’un des meilleurs analyseurs de paquets disponibles aujourd’hui [12].
FIGURE 6.1 Interface du Wireshark
Contrôle du trafic
Puisque on a un débit donneur de 100 Mbit/sec de l’Algérie Télécom, on vas limité la bande passante entre le serveur Algérie Télécom et le routeur d’accès de l’université à 100 Mbps sur l’émulateur GNS3, sans cette limite, on peux atteindre jusqu’à 350 Mbps. En utilisant les commandes suivantes :
- Côté Algérie Télécom
- Côté univ41-Getway
Génération du trafic
En tant qu’utilisateurs , la vitesse et l’efficacité jouent un grand dans nos recherche. Il est peu probable qu’un étudiant reste dans les parages s’il rencontre un retard important de son côté ou si une page ne répond pas.
Maintenant, avec la génération de trafic réseau et par l’utilisation du GNS3 , nous pouvons imiter le trafic réseau réel. GNS3 simulent le stress ou la charge pour déterminer ce que le réseau peut gérer. En faisant cela, nous a donner une compréhension claire sur performances des appareils testés et de ce que se passe réellement dans notre réseau.
- Alors pour exécuter des tests de performances sur GNS3, la commande iperf3 est celle qui s’occupe d’indiquer la bande passante maximale, la perte et d’autres paramètres.
Pour cela on vas démarrer notre simulateur GNS3, ouvrir le console des noeuds de testeur(1,2,3,4) et effectuant la suite des lignes suivantes :
Première étape c’est d’avoir les adresses ip des testeurs :
Après avoir une adresse ip pour chacun des testeur, on vas assurer que le serveur titulaire de l’adresse ip 193.194.69.188 est accessible, vérifier combien de temps il faut aux paquets pour passer du serveur vers chacun des autres testeurs. Notamment cet teste ce fait par la commande ping :
Arrivant maintenant a notre objectif c’est la commande iperf3. Le premier paramètre a renseigné est le mode de fonctionnement : mode client (-c) ou en mode serveur (-s).
Pour cela , le mode serveur vas être :
Lançant maintenant un test iperf3 vers le serveur Web et le serveur Algérie Télécom, Exécutant un serveur distinct de chaque hôte du testeur( 1,2,3,4) par la commande :
Pour chacun des noeuds testeurs on a obtenus les résultats suivants dans des moment différents :
— Testeur 1
| Exécution d’un test iperf3 vers le serveur Web | |
|---|---|
 | |
| Exécution d’un test iperf3 vers le serveur Algérie Télécom | |
 | |
— Testeur 2
| Exécution d’un test Iperf3 vers le serveur Web | |
|---|---|
 | |
| Exécution d’un test iperf3 vers le serveur Algérie Télécom | |
 | |
— Testeur 3
| Exécution d’un test iperf3 vers le serveur Web | |
|---|---|
 | |
| Exécution d’un test iperf3 vers le serveur Algérie Télécom | |
 | |
- Testeur 4
| Exécution d’un test iperf3 vers le serveur Web | |
|---|---|
 | |
| Exécution d’un test iperf3 vers le serveur Algérie Télécom | |
 | |
Remarque a retiré pour les résultats des 4 testes :
- Pour un débit donneur de 100 Mbit/sec une grande perte au niveau des 3 premiers testes pour que ces bandes passantes varient ente 15.7 Mbit/sec de façons minimal et de 17.9 pour un débit maximal.Et cela induire des ambiguïtés.
- Les meilleurs débits sont obtenus par testeur 4 car c’est le plus proche des serveurs. En particulier, son débit vers le serveur Algérie Télécom est proche de la limite de la ligne. La différence entre 92.2 mbps et la limite 100mbps de la ligne s’explique par le fait que la première est calculé en utilisant les données dans la couche application, et ne compte pas donc les entêtes des protocoles transport (TCP), réseau (IP) et lien de données (Ethernet). Tandis que, la deuxième (100 mbps) est exprimé par l’opérateur Algérie Télécom au niveau Ethernet uniquement.
— Le débit de tester4 vers le serveur Web (306 Mbit/sec) est uniquement limité par la capacité de la machine sur lequel tourne l’émulateur. En particulier, la vitesse du processeur.
- En général, pour un débit de 45Mbit/sec contient 4000 paquet transmis. Dans le cas de testeur 4 on a un débit de 91.8 Mbit/sec veut dire a peux prés plus que 8000 paquet où 1528 parmi eux sont perdus cela prouve que c’est une grande quantité de perte de paquets. Ceci, à son tour, a un impact sur le débit.
Ensuite, on vas exécuter tous les tests ensemble. Nous devrons les programmer pour qu’ils démarrent en même temps en utilisant la commande linux « at ».
Nous avons installé la commande ’at’ dans les 4 nœuds de test. Pour le testeur 1 la figure 6.2 montre comment l’utiliser pour planifier des tests iperf3 parallèles.
FIGURE 6.2 Planification du iperf3 avec la commande ’at’
D’autre part, a coté serveur, le serveur ne gère pas plusieurs clients soit Algérie Télécom soit le serveur Beta. La solution consiste à démarrer le serveur iperf3 sur quatre port différent. Répétez ensuite les tests parallèles des clients en utilisant sur chaque client l’un des ports.
La suites de testes suivantes montre les débits en réception, en émission ainsi la vitesse de transfert de la connexion à un instant T pour les quatre clients vers les deux serveurs tester auparavant.
— Testeur 1
| Planification de tests iperf3 parallèles vers le serveur Web | |
|---|---|
 | |
| Planification de tests iperf3 parallèles vers le serveur Algerie Télécom | |
 | |
- Testeur 2
| Planification de tests iperf3 parallèles vers le serveur Web | |
|---|---|
 | |
| Planification de tests iperf3 parallèles vers le serveur Algérie Télécom | |
 | |
— Testeur 3
| Planification de tests iperf3 parallèles vers le serveur Web | |
|---|---|
 | |
| Planification de tests iperf3 parallèles vers le serveur Algérie Télécom | |
 | |
— Testeur 4
| Planification de tests iperf parallèles vers le serveur Web | |
|---|---|
 | |
| Planification de tests iperf parallèles vers le serveur Algérie Télécom | |
 | |
— Les résultats obtenus au niveau des quatre clients tester d’une façons parallèle vers le serveur Web et vers le serveur Algérie Télécom sont inférieur au débit annoncé (100Mbit/sec) avec un pourcentage de 95% ce qui est un débit très lents et faible, dans lequel le débit compris entre 3.96 Mbit/sec et 6.52 Mbit/sec pour les trois client(1,2,3).
— Leurs trafic (testeur1 à 3) passe d’abord par la pile des protocoles des noeuds Cisco internes, c-à-d le firewall ASA, le core-switch qui est un switch multi- couche, et éventuellement un deuxième switch multicouche (pour testeur2 et 3). Par conséquence, leurs trafics passe d’abord par deux piles de protocoles Cisco, dont l’implémentation est destiné vers une architecture processeur MIPS, qui est émulé par une machine virtuelle QEMU/KVM. Ceci réduit considérablement la vitesse de forwarding de ces noeuds ce qui engendre une perte des paquets iperf3, d’où les faibles débit.
- Par contre le teste 4 est toujours remarquable au niveau de son débit dans lequel est considérée comme bon, estimé par 79.3 Mbit/sec avec une petite perte, et cela pose une interrogation.
— Car son trafic dans l’émulateur vers le serveur Web passe directement par la pile TCP/IP/Ethernet de la machine hôte (serveur HP simul) puisque tous les noeuds impliqués sont des conteneurs docker. Son trafic vers le serveur Algérie Télécom passe notamment par un seul noeud Cisco, qui émule le routeur 2801, mais est limité par le lien extérieur plutôt que par ce noeud.
Cela est dû à une limite dans le lien qui relie l’université à Algérie Télécom. Ce qui génère une perte de paquets ver le serveur Algérie Télécom.
- Ajoutant à ceci, le noeud ASA qui joue le rôle de firewall + NAT exécute des tâches supplémentaires en plus de forwarder les paquets. Il s’agit de la translation des adresses Intranet privées vers une adresse publique et l’inspection des paquets pour sécuriser l’Intranet. Ces tâches émulées ralentissent davantage le trafic passant par ce noeud.
- Les inconvénients de l’émulation qui causent une perte de vitesse n’existent pas dans le réseau réel. Toutefois, ces inconvénients sont balancées par d’autres avantages de l’émulation comme la possibilités de réaliser des tests sur la topologie actuelle sans perturber le fonctionnement du réseau réel, et surtout la possibilité de modifier et tester la topologie et la configuration du réseau pour l’améliorer avant de la reporter sur le réseau réel.
Chapitre 7
Conclusion et perspectives
Comme en développement d’applications, l’architecture de systèmes et réseaux, même simple, nécessite de réaliser des tests avant le lancement ou obtenir le meilleur résultat. Le travail que nous avons accompli a pour principal objectif de tester l’architecture du réseau de l’université. Cette bonne pratique est indispensable pour vous détecter et éviter de nombreuses erreurs qui viendraient gâcher le quotidien des utilisateurs universitaires. Et cela c’est ce à quoi nous sommes arrivés :
- une limitation entre le lien qui relie l’université et Algérie Télécom c’est celle responsable sur la perte des paquets.
- l’émulation cause une perte de vitesse ce qui n’existe pas dans le réseau réel.
Cependant, ces inconvénients sont contrebalancés par d’autres avantages du projet, Nous avons réussi à installer GNS3, la topologies a été construite avec succès en implémentant différentes composants, afin de simuler l’interconnexion des différentes plate-formes surtout la possibilité de les modifier et les tester pour les améliorer sans perturber le fonctionnement du réseau réel.
La réalisation de ce projet a été bénéfique et fructueuse pour nous dans le sens où elle nous a permis d’apporter, mais aussi d’approfondir et d’acquérir de nouvelles connaissances qui seront utiles et déterministes pour nous à l’avenir de notre université.
Pour améliorer la réalisation du travail actuel nécessite une liste de perspectives afin de découvrir comment exploiter au mieux notre étude présenter :
- tels que l’élimination des processus redondants sur plusieurs serveurs et on les remplace par une seule méthode de contrôle pour l’ensemble réseau, signifie bénéficier d’un contrôle centralisé du réseau qui contiendra un seul serveur, L’une de ces solutions consiste à réaliser des prototypes et à les simuler aussi en mode virtuel par le logiciel Mininet.
- il faut aussi faire plus de test sur le serveur web, notamment avec curl, simulant la charge et le comportement des applications de centaine de clients HTTP / HTTPS et FTP / FTPS, chacun avec sa propre adresse IP source. L’outil est utile pour le chargement des performances de divers services d’application, pour tester les serveurs Web et la génération de trafic, Afin de simuler des clients dans l’intranet et des clients extérieurs).