Chapitre 5 

: Test et résultat d’implémentation

Chapitre 5 : Test et résultat d’implémentation

Dans ce chapitre on va créer une simulation en utilisant notre simulateur omnet++.

Cette simulation est basée sur deux grandes parties :

 Les différents modules pour la création de notre réseau.

 Le scénario déployé et observé après (client et serveur DHCP, dans notre cas)

1. Les étapes de simulation :

1.1. Configuration réseau de base :

Figure1: module Network Configurator Base

Pour notre simulation on utilise l’ipv4networkconfigurator :

Figure2 : sous module Ipv4Networkconfigurator

1
Chapitre 5 : Test et résultat d’implémentation

 Le configurateur passe par les étapes de configuration suivantes :

 Création d’un graphique représentant la topologie du réseau.

Le graphique aura un sommet pour chaque module qui a une propriété @networkNode
cela inclut :
 Les hôtes
 Les routeurs
 Les périphériques L2 comme les commutateurs, les points d'accès, les
concentrateurs Ethernet …
 Attribution des adresses IP à toutes les interfaces de tous les nœuds. Le processus
d'attribution prend en compte les adresses et masques de réseau déjà présents sur les
interfaces (éventuellement définis lors des étapes d'initialisation antérieures).
La configuration fournie au format XML (décrite ci-dessous).
La configuration peut spécifier des "modèles" pour l'adresse et le masque de réseau,
avec des parties qui sont fixes et des parties qui peuvent être choisies par le
configurateur (par exemple "10.0.x.x").
 Ajout des itinéraires manuels spécifiés dans la configuration.
 Ajout des routeurs statiques à toutes les tables de routage du réseau.
Le configurateur utilise l'algorithme de chemin le plus court pour trouver les routes
souhaitées entre toutes les paires de nœuds possibles. Les tables de routage résultantes
auront une entrée pour toutes les interfaces de destination du réseau.
 Ensuite, l’ipv4networkconfigurator optimise les tables de routage pour la taille.
Cette optimisation permet de configurer des réseaux plus grands avec une plus petite
empreinte mémoire et accélère la recherche de la table de routage.
La table de routage résultante peut être différente en ce qu'elle achemine les paquets
que la table de routage d'origine n'a pas fait.
 Enfin, il vide les résultats demandés de la configuration.
Il peut vider :
 La topologie du réseau.
 Les adresses IP attribuées.
 Les tables de routage et son propre format de configuration.

2
Chapitre 5 : Test et résultat d’implémentation

1.2. Ajout des Hôtes :

 Client
 Serveur

Figure3 : module StandardHost

 Configurations par défaut des hôtes :

« StandardHost » dans notre simulation a été conçu de sorte à ce qu’il contient les différentes
couches : application, réseau, physique+mac.

Figure4 : fichier. Ned du module standardHost

3
Chapitre 5 : Test et résultat d’implémentation

Figure5 : couche application

Figure6 : couche transport

Figure7 : couche réseau

4
Chapitre 5 : Test et résultat d’implémentation

Figure8 : couche physique + mac

 En plus de ces sous modules, il existe les sous modules suivants :

 "Battery" : un réseau de capteur est nécessairement modélisé par une batterie
au niveau de chaque capteur.
 "mobility" : Pour pouvoir définir la topologie du réseau ainsi pour connaître la
position de chaque capteur.

1.3. Fichier. NED :

Ce fichier explique les différents paquets et modules utilisée s.

Figure 9 : les paquets « DHCP » importés

5
Chapitre 5 : Test et résultat d’implémentation

Figure 10 : fichier. Ned de notre réseau

6
Chapitre 5 : Test et résultat d’implémentation

Figure 11 : fichier. ned graphique de notre réseau

1.4. Création du scénario et simulation :

Pour la création d’un scénario on utilise le module scénario manager.

Figure 12 : le scenarioManager

ScenarioManager permet de configurer et de contrôler les expériences de simulation. Vous

pouvez planifier certains événements pour qu'ils aient lieu à des moments spécifiés, comme la
modification de la valeur d'un paramètre, la modification du taux d'erreur binaire d'une
connexion, la suppression ou l'ajout de connexions, la suppression ou l'ajout de routes dans
une table de routage, etc., afin que vous puissiez observer le transitoire comportement.

Il exécute un script spécifié en XML. Il a quelques commandes intégrées, tandis que d'autres
commandes sont envoyées pour être exécutées par des modules simples donnés.

 Lancement de la simulation :

7
Chapitre 5 : Test et résultat d’implémentation

Figure 13 : observation du réseau simulé

 Observation du scénario déployé :

 Ce scénario montre comment DHCP fonctionne lorsqu'un client ou un serveur

redémarre.

 Le client démarre l'initialisation DHCP à 0,5 s et reçoit l'adresse IP

192.168.1.100 peu de temps après.

 Le client s'arrête à 60 s et redémarre à 70 s.

 Le comportement mis en œuvre dans DHCPClient est que le client se souvient

de sa dernière adresse IP attribuée après le redémarrage, et si l'adresse n'a pas
encore expiré, alors DHCP démarre dans l'état INIT-REBOOT et tente de
réattribuer cette ancienne adresse IP.

 Dans cet exemple :

8
Chapitre 5 : Test et résultat d’implémentation

L’ancien bail du client n'a pas encore expiré (la durée du bail Dans ce scénario est
de 150 s), ainsi le client le renouvellera avec succès.

Le serveur s'arrête à 80s et redémarre à 90s, et perd sa base de données de bail.

Lorsque le client atteint le délai d'expiration T1 à 145 s (T1 = 0,5 * bail Time), il
essaie de prolonger son bail actuel.

Cette demande sera rejetée par le serveur, car il ne connaît plus le client.

Après le refus, le client redémarre tout le processus DHCP et demande une

nouvelle adresse. Le serveur proposera la première adresse disponible de son pool,
qui est à nouveau 192.168.1.100 car il n'y a pas d'autres clients dans le réseau.

<scenario>
<at t = "60.0">
<shutdown module = "client" />
</at>
<at t = "70.0">
<module de démarrage = "client" />
</at>
<at t = "80.0">
<shutdown module = "serveur" />
</at>
<at t = "160.0">
<startup module = "serveur" />
</at>
</scenario>

9
Chapitre 5 : Test et résultat d’implémentation

Figure 14 : observation du scénario déployé

10