Vous êtes sur la page 1sur 137

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE

UNIVERSITE DE SOUSSE

‫المعهد العالي لإلعالمية وتقنيات االتصال بحمام سوسة‬

INSTITUT SUPERIEUR D’INFORMATIQUE

ET DES TECHNOLOGIES DE COMMUNICATION – HAMMAM SOUSSE


Département Télécoms

MEMOIRE DE PROJET DE FIN D’ETUDES

Présenté en vue de l’obtention du Diplôme National d’Ingénieur

Spécialité : Téléinformatique

Mise en place d'une solution de supervision et de


localisation des boucles Métro Ethernet

Réalisée par :
Hanadi Kammoun
Encadrée par :
Mme. Sonia Mili
M. Ahmed Kamel Mrad
Société d’accueil :

Tunisie Télécom
Année Universitaire 2016 - 2017
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITE DE SOUSSE

‫المعهد العالي لإلعالمية و تقنيات االتصال بحمام سوسة‬

INSTITUT SUPERIEUR D’INFORMATIQUE

ET DES TECHNOLOGIES DE COMMUNICATION – HAMMAM SOUSSE

Département Télécoms

MEMOIRE DE PROJET DE FIN D’ETUDES

Présenté en vue de l’obtention du Diplôme National d’Ingénieur


Spécialité : Téléinformatique

Mise en place d'une solution de supervision et de


localisation des boucles Métro Ethernet

Réalisée par :

Hanadi Kammoun

Encadreur : M. Ahmed Kamel Mrad Date :………………………Signature :…………….

Encadreur : Mme. Sonia Mili Date :………………………Signature :…………….

Année Universitaire 2016 - 2017


Dédicaces
Je dédie ce modeste travail
A mes parents
Pour leurs considérables sacrifices qu'ils m'ont offerts tout au
long de mes études pour me parvenir à ce niveau.
A ma sœur et mon frère
Pour avoir été toujours à mes côtés avec leur amour et leur
soutien.
A ma famille et à mes chers amis
Qui n'ont jamais cessé de m'encourager à aller plus loin.

Hanadi Kammoun
R emerciements
Nul doute que personne n'est né avec le savoir, il doit ainsi toujours quelque chose à
quelqu'un, c'est pour cette raison que nous tenons à remercier :

Madame Nesrine Kammoun, qui nous a accueilli au sein de Tunisie Télécom et nous
a permi de participer à ce projet.

Nos vifs remerciements s'adressent à notre encadrant dans l'entreprise, Monsieur


Ahmed Kamel Mrad, chef de subdivision gestion des réseaux Agrégation et Edge à Tunisie
Télécom, pour sa disponibilité, ses remarques judicieuses, sa sympathie et son amitié. Qu'il
trouve, l'expression de notre vive reconnaissance, notre sincère gratitude et le témoignage de
notre profond respect.

Nous tenons à remercier tout particulièrement Madame Sonia Mili, notre encadreur
qui est malgré les occupations et le responsabilités qu'elle assume, elle a toujours eu le temps
pour nous écouter, nous conseiller et nous fournir la documentation nécessaire durant notre
période de stage.

Enfin, nous adressons nos remerciements aux membres du jury pour l’intérêt qu’ils ont
porté à notre recherche en acceptant d’examiner notre travail et à tous nos enseignants pour le
temps et l'effort qu'ils nous ont consacré durant toutes nos années d'études à l'ISITCOM .
Table des matières
Introduction générale .................................................................................................................. 1
Chapitre 1 : Cadre général du projet ..................................................................................... 4
Introduction ................................................................................................................................ 4
I. L'Entreprise d'accueil ......................................................................................................... 4
I.1 Tunisie Telecom .......................................................................................................... 4
I.2 Service ......................................................................................................................... 5
I.3 Organigramme de Tunisie Telecom ........................................................................... 5
II. Architecture actuelle .......................................................................................................... 6
III. Etude de l'existant............................................................................................................ 7
IV. Critique de l’existant ....................................................................................................... 9
V. Solution proposée ............................................................................................................... 9
VI. Objectifs de la solution .................................................................................................. 10
VII. Architecture du réseau à superviser .............................................................................. 10
VIII. Motivation ................................................................................................................. 11
IX. Méthodologie de travail adoptée ................................................................................... 12
X. Planification du déroulement du projet ............................................................................ 13
Conclusion ................................................................................................................................ 14
Chapitre 2 : Etat de l’art ....................................................................................................... 14
Introduction .............................................................................................................................. 14
I. Présentation du Métro Ethernet ........................................................................................ 14
I.1 Définition du réseau Métro Ethernet ......................................................................... 14
I.2 Architecture de base des réseaux Métro Ethernet ..................................................... 15
I.3 Topologies ................................................................................................................. 16
I.3.1 En étoile.............................................................................................................. 16
I.3.2 En anneau ........................................................................................................... 16
I.4 Les équipements utilisés ........................................................................................... 17
I.4.1 Cisco ASR 9010 ................................................................................................. 17
I.4.2 Cisco ASR 9006 ................................................................................................. 18
I.4.3 Cisco ME-3800 .................................................................................................. 18
I.4.4 Support de Transmission : Fibre Optique Monomode ....................................... 18
I.5 Exemple de boucle Métro Ethernet .......................................................................... 19
I.6 Les services Metro Ethernet ...................................................................................... 19
I.7 MPLS ......................................................................................................................... 21
I.7.1 Définition de MPLS ........................................................................................... 21
I.7.2 Architecture MPLS ............................................................................................ 21
I.7.3 Fonctionnement MPLS ...................................................................................... 22
I.7.4 Commutation et distribution des labels .............................................................. 23
I.7.5 MPLS VPN ........................................................................................................ 24
II. Supervision du réseau Métro Ethernet ............................................................................. 25
II.1 Définition de la supervision des réseaux .................................................................. 25
II.2 Objectifs..................................................................................................................... 26
II.3 Environnement de gestion SNMP ............................................................................. 26
II.3.1 Modèle d'administration avec SNMP ................................................................. 26
II.3.2 La MIB et les OIDs ............................................................................................ 27
II.3.3 Les commandes de bases .................................................................................... 28
II.4 Etude comparative des solutions de supervision ....................................................... 28
II.4.1 Solution libre ou payante .................................................................................... 29
II.4.2 Les Solutions libres ............................................................................................ 29
II.4.3 Choix d'outils de supervision ............................................................................. 32
Conclusion ................................................................................................................................ 34
Chapitre 3 : Analyse et spécification des besoins ................................................................ 36
Introduction .............................................................................................................................. 36
I. Spécification des besoins de la solution .......................................................................... 36
I.1 Spécification des besoins fonctionnels ........................................................................... 36
I.2 Spécification des besoins non fonctionnels .................................................................. 37
II. La modélisation UML ...................................................................................................... 37
III. Présentation des acteurs ................................................................................................ 38
IV. Diagramme de cas d'utilisation ..................................................................................... 38
IV.1 Diagramme de cas d'utilisation général ................................................................ 38
IV.2 Diagramme de cas d'utilisation détaillé ..................................................................... 39
IV.2.1 Diagramme de cas d'utilisation de l'administrateur ............................................. 39
IV.2.2 Description textuelle des cas d'utilisation ............................................................ 41
IV.2.3 Diagramme de cas d'utilisation de superviseur .................................................... 44
IV.2.4 Description textuelle des cas d'utilisation ............................................................. 45
Conclusion ................................................................................................................................ 50
Chapitre 4 : Conception ........................................................................................................ 52
Introduction .............................................................................................................................. 52
I. Conception de l'architecture de la solution ...................................................................... 52
II. Diagramme de déploiement ............................................................................................. 53
III. Diagramme d'activité..................................................................................................... 54
III.1 Diagramme d’activité « s’authentifier » ................................................................ 54
III.2 Diagramme d’activité « Ajouter superviseur» ....................................................... 55
III.3 Diagramme d’activité «Modifier superviseur» ...................................................... 56
III.4 Diagramme d’activité «Générer les rapports» .......................................................... 56
III.5 Diagramme d’activité «Consulter les indicateurs de performance» ........................... 57
III.6 Diagramme d’activité «Consulter l'espace de localisation des routeurs à
superviser» ........................................................................................................................... 57
IV. Diagramme de séquence ................................................................................................ 58
IV.1 Diagramme de séquence de cas d'utilisation «S'authentifier» ............................. 58
IV.2 Diagramme de séquence de cas d'utilisation rapport «Générer le rapport » ......... 58
IV.3 Diagramme de séquence de cas d'utilisation «Consulter l'état du routeur» ........... 59
VI.4 Diagramme de séquence du cas d'utilisation «Ajouter routeur dans la région» .... 60
VI. Diagramme de classe ..................................................................................................... 61
VII. Diagramme de navigation ............................................................................................. 63
Conclusion ................................................................................................................................ 64
Chapitre 5 : Réalisation ......................................................................................................... 66
Introduction .............................................................................................................................. 66
I. Environnement de travail ............................................................................................... 66
I.1 Environnement logiciel.............................................................................................. 66
I.2 Les choix techniques ................................................................................................. 68
I.2.1 Choix de l’architecture Client-serveur ............................................................... 68
I.2.2 Choix de langage de programmation ................................................................. 69
I.3 Protocole et format de données ................................................................................. 69
I.3.1 Protocole de communication .............................................................................. 69
I.3.2 Format de données communiquées .................................................................... 69
I.4 Environnement matériel ............................................................................................ 70
II. Mise en place d'un réseau Métro Ethernet ....................................................................... 70
II.1 Plan d'adressage ......................................................................................................... 71
II.2 Configuration des interfaces ...................................................................................... 72
II.3 Configuration des protocoles de routage OSPF ..................................................... 72
II.4 Configuration du MPLS ............................................................................................ 73
II.5 Test et vérification ..................................................................................................... 73
II.5.1 Vérification de routage OSPF ............................................................................ 74
II.5.2 Vérification MPLS ............................................................................................. 74
II.5.3 Test de connectivité ............................................................................................ 75
III. Mise en place d’une solution de supervision ................................................................ 76
III.1 Mise en place de l'outil EyesOfNetwork ............................................................... 76
III.2 Connexion entre EyesOfNetwork et L'architecture ME ........................................ 77
III.3 Configuration SNMP.................................................................................................. 79
III.3.1 Configuration des agents SNMP .......................................................................... 79
III.3.2 Configuration des paramètres SNMP dans EyesOfNetwork ............................... 79
III.4 Configuration d'EyesOf Network ................................................................................ 80
III.4.1 Configuration de Nagios ...................................................................................... 80
III.4.2 Supervision avec Nagios ...................................................................................... 84
III.4.3 Configuration NagVis .......................................................................................... 87
III.4.4 Configuration de Cacti ..................................................................................... 88
III.4.5 Configuration de Weathermap ............................................................................ 90
IV. Localisation et supervision du Métro Ethernet d’Ariana sous Android ........................ 91
IV.1 Localisation de boucle Metro-Ethernet ....................................................................... 91
IV.1.1 L‘outil de géolocalisation sous Android : Google Maps ..................................... 91
IV.2 MySQL et PHP avec Google Maps ............................................................................ 91
IV.3 Description des interfaces de l’application ................................................................. 92
IV.3.1 Authentification ................................................................................................... 92
IV.3.2 Espace administrateur .......................................................................................... 93
IV.3.3 Espace superviseur .............................................................................................. 100
Conclusion .............................................................................................................................. 102
Conclusion générale ............................................................................................................... 103
Bibliographie .......................................................................................................................... 105
Annexe A : Mise en place de l'architecture Métro Ethernet .................................................. 107
Annexe B : Mise en place d'EyesOfNetwork ......................................................................... 110
Annexe C : Plateforme Android ............................................................................................. 118

Liste des figures


Figure 1: Logo de Tunisie Telecom ........................................................................................... 4
Figure 2:Organigramme de Tunisie Telecom ............................................................................ 6
Figure 3:Architecture réseau de Tunisie Télécom ..................................................................... 7
Figure 4: Cartographie du réseau Métro Ethernet « Tunis » ...................................................... 8
Figure 5: Architecture des boucles Metro-Ethernet « Ariana» Motivation ............................ 11
Figure 6: Architecture typique d'un réseau Métro-Ethernet ..................................................... 15
Figure 7 : Topologie en étoile d’un réseau ME ........................................................................ 16
Figure 8:Topologie en maillage d’un réseau ME ..................................................................... 17
Figure 9: Cisco ASR 9010 ....................................................................................................... 17
Figure 10:Cisco ASR 9006 ...................................................................................................... 18
Figure 11: Boucles Métro Ethernet Beja et Jandouba ............................................................. 19
Figure 12 : Réseaux locaux LAN aux ressources réseau ......................................................... 20
Figure 13: Les services L2VPN ............................................................................................... 20
Figure 14: Couche 2.5 MPLS ................................................................................................... 21
Figure 15:L'architecture MPLS ................................................................................................ 22
Figure 16: Les champs d'un label ............................................................................................. 23
Figure 17: Le principe de la commutation des labels............................................................... 24
Figure 18: Architecture MPLS_VPN ....................................................................................... 25
Figure 19: Architecture SNMP ................................................................................................ 27
Figure 20: Les requête SNMP .................................................................................................. 28
Figure 21: Les outils constituants EyesOfNetwork .................................................................. 32
Figure 22:Diagramme de cas d'utilisation général ................................................................... 39
Figure 23:Diagramme du cas d'utilisation de l'administrateur ................................................. 40
Figure 24: Cas d'utilisation «Gérer les superviseurs» .............................................................. 41
Figure 25: Cas d'utilisation «Gérer les routeurs» ..................................................................... 42
Figure 26: Cas d'utilisation «Configurer Weathermap» ........................................................... 43
Figure 27: Diagramme de cas d'utilisation du superviseur ...................................................... 45
Figure 28: Cas d'utilisation «Consulter les indicateur des performances»............................... 46
Figure 29: Cas d’utilisation «génère le rapport» ...................................................................... 47
Figure 30: Description de cas d'utilisation « Détecter les anomalies » .................................... 48
Figure 31:cas d’utilisation «Localiser les routeur à superviser» .............................................. 49
Figure 32: Cas d’utilisation «Consulter l'état du routeur localisé» .......................................... 50
Figure 33:Architecture de la solution proposée ....................................................................... 53
Figure 34: Diagramme de déploiement .................................................................................... 54
Figure 35: Diagramme d'activité s'authentifier ........................................................................ 55
Figure 36:Diagramme d’activité « Ajouter superviseur» ......................................................... 55
Figure 37: Diagramme d’activité «Modifier superviseur» ....................................................... 56
Figure 38: Diagramme d’activité «Gérer les rapport » ............................................................ 56
Figure 39: Diagramme d’activité «Consulter les indicateurs de performance» ....................... 57
Figure 40:Diagrammes d’activité «Localiser les routeur à superviser » .................................. 57
Figure 41 :Diagramme de séquence du cas d'utilisation «S'authentifier» .............................. 58
Figure 42: Diagramme de séquence du cas d'utilisation «Générer le rapport » ...................... 59
Figure 43: Diagramme de séquence du cas d'utilisation «Consulter l'état du routeur» .......... 59
Figure 44: Diagramme de séquence de cas d'utilisation «Ajouter routeur dans la région» ..... 60
Figure 45: Diagramme de classe .............................................................................................. 62
Figure 46: Diagramme de navigation de l'administrateur ........................................................ 63
Figure 47: Diagramme de navigation du superviseur .............................................................. 64
Figure 48: Architecture logicielle de la solution ...................................................................... 66
Figure 49: Architecture 3-tiers ................................................................................................. 68
Figure 50 : Maquette Métro Ethernet «Ariana» ....................................................................... 70
Figure 51: Résultat de la commande show ip ospf .................................................................. 74
Figure 52: Résultat de voisin MPLS ........................................................................................ 74
Figure 53: Résultat MPLS pour les réseaux connectés ........................................................... 75
Figure 54: Ping entre le nœud d’Enasser et Aouina ................................................................ 75
Figure 55: Interface d'authentification d'EyesOfNetwork ........................................................ 76
Figure 56: interface graphique d’EyesOfNetwork ................................................................... 77
Figure 57: Connexion entre routeur Enasser et Cloud d'EyesOfNetwork ............................... 77
Figure 58: Résultat de commande show ip route ..................................................................... 78
Figure 59: Topologie de supervision ........................................................................................ 79
Figure 60: Configuration SNMP .............................................................................................. 79
Figure 61: configuration SNMP dans EyesOfNetwork ............................................................ 80
Figure 62:Ajout d’Equipement................................................................................................. 80
Figure 63:Paramétrage pour superviser un hôte ....................................................................... 81
Figure 64: Paramétrage du l’Inheritance de l’hôte ................................................................... 81
Figure 65:Exporter les données vers Nagios ............................................................................ 81
Figure 66: Redémarrage de Nagios .......................................................................................... 82
Figure 67:Connexion à WinSCP .............................................................................................. 82
Figure 68: Répertoire de configuration de Nagios ................................................................... 83
Figure 69:l'ajout d'un commande ............................................................................................. 83
Figure 70: Ajout de service ...................................................................................................... 84
Figure 71: Les service ajoutés .................................................................................................. 84
Figure 72: Consultation des états des routeurs ......................................................................... 85
Figure 73: Etat des services ...................................................................................................... 85
Figure 74: Consultation des problèmes .................................................................................... 86
Figure 75:Rapport générique .................................................................................................... 86
Figure 76: Rapport de disponibilité .......................................................................................... 87
Figure 77: Supervision sous NagVis ........................................................................................ 88
Figure 78: Synchronisation de Cacti ........................................................................................ 88
Figure 79: les routeurs sous Cacti ............................................................................................ 89
Figure 80: Choix des interfaces à superviser ........................................................................... 89
Figure 81: Le trafic Inbound/Outbound par interface .............................................................. 90
Figure 82: Utilisation de process du routeur Enasser ............................................................... 90
Figure 83: Supervision de l'utilisation de la bande passante sous Weathermap ...................... 91
Figure 86: Interface d'authentification en cas d'erreur ............................................................. 92
Figure 84: Interface de chargement ouverture application....................................................... 92
Figure 85: Interface d'authentification ..................................................................................... 92
Figure 87: Présentation générale des interfaces de l'administrateur ........................................ 93
Figure 88:Interface d'ajout d'un superviseur Figure 89: Liste des
superviseurs .............................................................................................................................. 94
Figure 90: Les Interfaces de modification et de suppression d’un superviseur ....................... 95
Figure 91: Les différentes fonctionnalités de supervision de l'administrateur ......................... 96
Figure 93: L'espace de localisation de l'administrateur ............................................................ 97
Figure 92: les étapes de génération d’un rapport ..................................................................... 97
Figure 94: Changement du type de map ................................................................................... 98
Figure 95: Recherche d'un routeur dans la région .................................................................... 98
Figure 96: Les interfaces de gestion des routeurs dans la région ............................................. 99
Figure 97: Consultation d'état d'un nœud dans la région ....................................................... 100
Figure 98: Présentation des interfaces du superviseur ........................................................... 100
Figure 99: Interface de supervision de superviseur ................................................................ 101
Figure 100: Consultation des coordonnées GPS d’un routeur ............................................... 102
Liste des tableaux
Tableau 1: Comparaison des différentes méthodologies de développement ........................... 12
Tableau 2: Planification du déroulement du projet .................................................................. 14
Tableau 3: Tableau comparatif des outils de supervision ........................................................ 33
Tableau 4: Description textuelle du cas d'utilisation «S'authentifier» ..................................... 41
Tableau 5: Description textuelle du cas d'utilisation «Gérer les superviseurs» ....................... 42
Tableau 6:Description textuelle du cas d'utilisation «Gérer les routeurs» ............................... 43
Tableau 7: Description textuelle du cas d'utilisation «Configurer Weathermap».................... 44
Tableau 8: Description textuelle du cas d’utilisation «Vérifier les disponibilités des
équipements» ............................................................................................................................ 46
Tableau 9: Cas d'utilisation «Consulter les indicateur des performances» .............................. 47
Tableau 10: Description textuelle du cas d'utilisation «Génère des rapports» ....................... 48
Tableau 11: Description textuelle du cas d’utilisation «Détecter les anomalies » ................... 48
Tableau 12: Description textuelle du cas d’utilisation «Consulter l'espace de localisation des
routeurs à superviser»»............................................................................................................. 49
Tableau 13:Description textuelle du cas d’utilisation «Consulter l'état du routeur» ............... 50
Tableau 14: Plan d’adressage ................................................................................................... 71
Tableau 15: les adresses logiques ............................................................................................. 72
Liste des acronymes
A
ASR Aggregation Services Routers

B
BGP Broder Gateway Protocol
C
CE Customer Edge
CEF Cisco Express Forwarding
CO Centre de l'Operateur
CPU Central Processing Unit
D
DL Down Link

E
EON EyesOfNetwork
F
FEC Forward Equivalence Load
G
GPS Global Posotioning System
I
IP Internet Protocol
IPTV Internet Protocol TV
L
LDP Label Distribution Protocol
LSP Label Switching Path
LSR Label Switch Router
LER Label Edge Router
M
ME Métro Ethernet
MIB Mangement Information Base
MPLS Multi-Protocol Label Switching
MVC Model View Control
MEF MetroEthernet Forum
N
NMS Network Manager System
O
OID Object Identifier
OSI Open Systems Interconnection
OSPF Open Shortest Path First

P
P Provider
ProviderPE Provider Edge
PHP Hypertext Preprocessor
POP Point Of Presence
Q
QOS Quality Of Service
R
RRD Round Robin Database
RUP Rational Unified Process

S
SNMP Simple Network Protocol
SSH Secure Shell
SSL Secure Socket Layer
T
TCP Transmission Control Protocol
TTL Time To Live
U
UDP User Datagram Protocol
UML Unfied Modeling Language

V
VPN Virtual Private Network
VRF Virtual Routing and Forwarding
Introduction générale

Introduction générale

Aujourd'hui, nous assistons à une révolution dans le domaine informatique, et c’est en


grande partie grâce aux progrès continuels des outils de télécommunication, nous rappelons
qu’avant même pas une décennie le débit du réseau international (Internet) ne se mesurait
qu’en Kbit/s alors que maintenant on en est en Gbit/s voir même en Tbit/s. Par conséquent
l'explosion des demandes en services oblige les opérateurs télécoms à faire évoluer leur
architecture traditionnelle pour assurer le déploiement de nouveaux services à leurs abonnés.

Suite à ce progrès Tunisie Télécom est chargé à mettre à jour le Backbone national aux
nouvelles normes et d’y implanter le réseau Métro Ethernet afin d’offrir naturellement plus de
débit mais encore plus de sécurité et de services qui seront proposés aux clients.

La Technologie Métro Ethernet se présente comme une alternative crédible et


économique pour élargir le panel d'offres de services. Elle offre le coût, l’efficacité,
l’évolutivité et la gestion de qualité de service. Ces caractéristiques lui permettent d’être une
technologie d’accès, de plus en plus demandée, dans les réseaux de nouvelle génération pour
répondre aux nouvelles exigences dans le monde de télécommunication.

D’autre part, les opérateurs consacrent beaucoup de ressources pour assurer la


surveillance de leurs réseaux. Quand il s'agit de la qualité de service, l'angle le plus important
est celui de l'utilisateur final. Les applications et les services de surveillance donnent un
aperçu de bout en bout des performances du point de vue du client. Il est donc important, pour
un opérateur, de s’assurer du bon fonctionnement de son réseau. En effet, le besoin de
contrôler en temps réel les performances et l'état des équipements est devenu une haute
priorité pour les responsables des ressources informatiques. Ainsi la solution de supervision
permet à la fois de garder un œil sur l'état du réseau, surveiller les pannes et limiter les
déplacements de l’administrateur pour résoudre une panne.

Tunisie télécom se base essentiellement dans sa supervision du réseau sur l’outil Cacti
qui n’est pas assez riche dans les utilités qu’il offre. En cas d’une panne, l’équipement
responsable n’est pas directement repéré et il fallait analyser tous les équipements de la zone
pour repérer le lieu de la panne.

1
Introduction générale

Pour contourner ces limitations nous avons, d'abord considéré un outil de supervision open
source appelé EyesOfNetwork auquel nous avons ajouté d’autres fonctionnalités pour voir en
claire tous les équipements du réseau ainsi que leurs états.

En cas de dysfonctionnement, le système de supervision proposé permet d'envoyer des


messages sur la console de supervision. Mais si le dysfonctionnement se produit en dehors des
heures de travail, les superviseurs ne sont pas prévenus du dysfonctionnement. C'est pourquoi
il faut compléter notre solution par une application mobile.
C'est dans cette optique que se situe notre projet de fin d’études. Ce dernier comprend
trois phases de réalisation. Dans une première phase, Notre travail consiste à réaliser une
étude du réseau Métro Ethernet pour comprendre ses principes et son mode de
fonctionnement. Dans la deuxième partie, nous nous intéressons à la mise en place d’un outil
de gestion du réseau pour surveiller les services et détecter les éventuels dysfonctionnements
et pannes dans le réseau. Dans une troisième phase, nous avons opté pour une application
mobile assurant une mobilité pour les différents usagers afin de superviser et localiser les
boucles Métro Ethernet via un Smartphone.
Ce rapport est scindé en cinq chapitres :
Dans le premier chapitre, nous allons présenter le cadre du projet: la société d'accueil,
étude et critique de l'existant, les objectifs de la solution proposée et la méthodologie adoptée.

Dans le deuxième chapitre, nous allons introduire les concepts de base de réseau
Métro Ethernet, ainsi que les équipements utilisés et une étude sur les outils de supervision.

Le troisième chapitre est consacré à la spécification des besoins et la définition des


divers cas d’utilisation dont on a besoin.

La conception du projet de point vue architecture et modèle est développée dans le


quatrième chapitre.

Le dernier chapitre décrit la solution que nous avons proposé en commençant par
définir l'environnement de travail, la mise en place de la maquette Métro Ethernet, la mise en
place d’une solution de supervision des boucles Métro Ethernet et en finissant par exposer
quelques imprimes écrans de notre application mobile.

Les principales contributions, ainsi que le travail futur, seront résumés dans la
conclusion générale.

2
Chapitre 1 : Cadre général du projet

Chapitre1
Cadre général du projet

Présentation de l'organisme d'accueil

Etude et critique de l'existant

Solution Proposée et objectifs

Méthodologie adoptée

Planification du travail

3
Chapitre 1 : Cadre général du projet

Chapitre 1 : Cadre général du projet

Introduction
Dans ce premier chapitre, nous allons présenter le cadre général du projet à réaliser au
sein de Tunisie Telecom: nous allons donc introduire l'entreprise d'accueil, étudier le système
existant de gestion du réseau Métro Ethernet, critiquer l’existant en décrivant les
problématiques. Puis, nous définissons exhaustivement les objectifs à atteindre qui
constitueront une réponse aux problématiques énoncés. Enfin, nous allons exposer la
méthodologie de travail et la planification du déroulement du projet.

I. L'Entreprise d'accueil
I.1 Tunisie Telecom

Figure 1: Logo de Tunisie Telecom

Ce projet a été réalisé au sein de la direction exécutive du Backbone de Tunisie


Télécom.
L’office national des télécommunications [1], est créé suite à la promulgation de la loi
N°36 du 17 avril 1995. L’office a ensuite changé de statut juridique, en vertu du décret N°30
du 5 avril 2004, pour devenir une société anonyme dénommée « Tunisie Telecom ».
Depuis sa création, Tunisie Telecom œuvre à consolider l’infrastructure des télécoms en
Tunisie, à améliorer le taux de couverture et à renforcer sa compétitivité. Elle contribue
également activement à la promotion de l’usage des TIC et au développement des sociétés
innovantes dans le domaine des télécoms.

4
Chapitre 1 : Cadre général du projet

Tunisie Telecom compte dans ses rangs plus de 6 millions abonnés dans la téléphonie fixe
et mobile. Elle se compose de 24 directions régionales, de 80 Actels et points de vente et de
plus de 13 milles points de vente privés. Elle emploie plus de 8000 agents.

I.2 Service
En tant qu'opérateur historique, Tunisie Telecom [2] est chargée de:

 L'installation et l'exploitation des réseaux publics de télécommunication.


 La promotion des nouveaux services de télécommunication.
 Continuer d'investir dans son cœur de réseau afin de renforcer l'accès au très haut débit
fixe et mobile.
 Devenir un point de passage pour les services internationaux.
 La participation à l'effort national d'enseignement supérieure en matière de
télécommunication.
 La promotion de la coopération dans tous les domaines des télécommunications.

I.3 Organigramme de Tunisie Telecom


L'organigramme de Tunisie Telecom se présente sous forme d'un ensemble de
plusieurs directions centrales, à chacune d'elles est affecté un ensemble de tâches. (Voire
figure 2 prise du site office de TT).

Ce projet a été réalisé au sein de la direction exécutive du Backbone de Tunisie


Télécom. Cette direction est spécialisée dans la conception, la sécurisation, la supervision, la
mise en service et la gestion des réseaux informatiques qui sont nécessaires au
fonctionnement de différents services de la compagnie. De plus, elle prend en charge
l'administration, le contrôle, la maintenance et l'exploitation de l'infrastructure de l'Internet en
Tunisie à travers le Backbone IP_MPLS qui couvre tout le pays.

5
Chapitre 1 : Cadre général du projet

PDG

Direction centrale
Direction des Direction cabinet
DGA stratégie
affaires juridiques du président
corporate

Direction
Direction centrale
communication
contrôle Générale
corporate

Secrétariat Générale Direction des achats

Direction centrale Direction centrale Direction centrale


wholesale et commerciale et de finances Directions Direction centrale de Direction centrale
international marketing régionales ressources humaines de système
Direction
d’information
exécutive du
Backbone

Service de
Supervision

Figure 2:Organigramme de Tunisie Telecom

II. Architecture actuelle


Le réseau de Tunisie Télécom est composé de quatre couches principales, comme il
est présenté dans la figure 3 :

 Couche Core représente les différents routeurs du Core IP_MPLS.


 Couche Edge représente les différents routeurs reliant le Core IP_MPLS avec le réseau
IP.
 Couche agrégation représente les différents routeurs reliant la couche Edge du réseau
IP_MPLS avec le Métro Ethernet.
 Couche d'accès représente les différents éléments réseaux qui constituent le réseau
Métro Ethernet qu'on va superviser par la suite.

6
Chapitre 1 : Cadre général du projet

Figure 3:Architecture réseau de Tunisie Télécom

III. Etude de l'existant


Depuis l’année 2009, Tunisie Telecom a commencé à relier plusieurs grandes sociétés
avec des liaisons en fibre optique. L’opérateur historique a procédé aussi à l’installation de
boucles en Fibre Optique. Le réseau Métro Ethernet a été étendu, à partir de l’année 2009,
pour atteindre différentes localités des gouvernorats. Ces boucles permettent un accès à très
haut débit avec des Uplinks de 10Gb tout en assurant une disponibilité de service et une
redondance parfaite.

La topologie comporte :
- Une boucle principale
- Des boucles secondaires branchées sur une boucle principale
- Des ramifications et des liaisons point à point
L’infrastructure de fibre optique du réseau Tunisie Telecom pour la région de « Tunis »
est illustrée par la figure 4.

7
Chapitre 1 : Cadre général du projet

Figure 4: Cartographie du réseau Métro Ethernet « Tunis »

Actuellement, le réseau Métro Ethernet présente 80% du nombre total des


équipements actifs de l’opérateur.
La supervision des boucles Métro Ethernet se fait via un ordinateur et exige une
présence continue du superviseur. De plus, avec un très grand nombre de routeurs à gérer, les
superviseurs peuvent difficilement vérifier leurs disponibilités et la qualité des services
qu’ils offrent.

Les superviseurs de Tunisie Telecom utilisent l'outil de supervision Cacti ainsi que
d'autres plateformes de supervision dédiés pour chaque équipement (U2000 Huawei, Cisco
Prime) qui sont centralisés au niveau du centre opérationnel de supervision. L’outil Cacti
largement utilisé est un logiciel open source d'étude de performance des éléments du réseau. Il
permet de représenter graphiquement les divers états des périphériques et des équipements
réseau utilisant le protocole SNMP.

Toutes les cinq minutes, le poller de Cacti (Trigger qui va exécuter des requêtes d'une
façon régulière) envoi des requêtes SNMP et enregistre les résultats.

Les indicateurs de performance surveillés sont la charge du processeur (CPU) et le


trafic entrant et sortant pour chaque interface.

8
Chapitre 1 : Cadre général du projet

IV. Critique de l’existant


La méthode actuelle utilisée présente certaines anomalies:

L'absence d'une solution de supervision adéquate:


 En cas d'une panne et pour chercher la cause principale de dysfonctionnement et la
corriger, les superviseurs vérifient manuellement les différents états grâce à un
émulateur de terminal «Putty», qui permet d'établir une connexion directe avec les
équipements à superviser via les protocoles SSH ou Telnet. Ils peuvent par la suite
tester la connectivité (ping) entre les différents nœuds de boucle Métro Ethernet afin
de vérifier leurs disponibilités. Cette procédure va engendrer une perte de temps pour
localiser la panne.
 La solution existante n'affiche pas les résultats en temps réel, ce qui risque de retarder
le temps d’intervention pour résoudre les incidents.
L'absence d'une méthode de localisation des nœuds de la boucle:
 Absence d'un système de localisation des nœuds IP des boucles Métro Ethernet, ce
qui rend la tâche d'intervention immédiate des équipes techniques difficile et
principalement pour les sous-traitants chargés de la maintenance préventive et curative.

L'absence de mobilité:

 La supervision des équipements d'un réseau se fait via un ordinateur et exige la


présence continue du superviseur en vue de détecter les anomalies qui surviennent.
Ainsi le superviseur est amené à être vigilent dans la détection des pannes en continue.
Ceci ne peut pas être assuré faute de la nature humaine.
 Pour résoudre ces problèmes, on a besoin d'une supervision continue du réseau pour
intervenir rapidement dès l'avènement d'une panne en vue d'éviter les impacts de longue
durée. Ce qui nous conduit à concevoir une solution mobile qui permet de faciliter la
supervision des boucles Métro Ethernet ainsi que la localisation des nœuds.

V. Solution proposée
La solution adéquate pour résoudre ces problèmes est la mise en place d'une
application mobile de gestion du réseau Métro Ethernet de bout en bout de l'opérateur Tunisie
Telecom. Il s'agit d'une solution de supervision et de localisation des boucles Métro Ethernet
offrant une multitude de fonctionnalités.

9
Chapitre 1 : Cadre général du projet

Pour la partie supervision, la solution permet de :


 Fournir tous les indicateurs nécessaires pour une supervision simple et une
intervention en temps réel.
 Pouvoir détecter et interpréter en un simple coup d’œil les causes et les origines des
problèmes rencontrés afin de les fixer le plus rapidement possible.
Pour trouver l'emplacement réel des nœuds Métro, nous allons développer une
application de localisation des différents nœuds de la région étudiée sur Google Map, la
localisation a pour but de :
 Connaître les coordonnés GPS.
 Consulter la situation des nœuds.
 Mettre à jour la liste des nœuds dans la région par l'administrateur.
Notre solution a été implémentée en premier lieu sur un serveur, ainsi le superviseur
doit systématiquement être présent devant un desktop. Pour résoudre ce problème, nous avons
opté pour une application mobile assurant une mobilité pour les différents usagers afin de
superviser et localiser les boucles Métro Ethernet via un Smartphone.

VI. Objectifs de la solution


Les objectifs de l'élaboration de notre projet se présentent comme suit :

 Supervision aisée des boucles Métro Ethernet.


 Localiser les boucles Métro Ethernet.
 Faciliter l'accessibilité aux données utiles par les superviseurs.
 Avoir des résultats en temps réel.
 Offrir une meilleure qualité de services face à l’exigence des clients en agissant
rapidement en cas des pannes.

VII. Architecture du réseau à superviser


La figure 5 expose l'architecture adoptée pour notre application. Il s'agit de la supervision
des boucles Métro Ethernet de la région «Ariana». Elle est composée de :

- Une tête de boucle .


- Quatre boucles secondaires.
- Des ramifications.

10
Chapitre 1 : Cadre général du projet

Equipe Metro-Ethernet Equipe Metro-Ethernet Equipe Metro-Ethernet

Equipe Metro-Ethernet

ASR 9K

ASR 903
AF
BorjATouil
F

ME-3800
Tête de boucle 10.141.5.2 Geant
Phase 1 Raoued 10.141.5.3
ME-3800 10.141.5.1
Phase 2

BORJ LOUZIR
Jemaa Raoudha 10.141.6.2 RIADH EL ANDALOUS
ASR 9010 Ariana GHAZELA
10.141.6.1 10.141.1.1 10.141.1.2
SOUKRA 10.1.241.81
10.141.4.9

SOUKRA
Equipe Metro-Ethernet Equipe Metro-Ethernet Equipe Metro-Ethernet
10.141.4.2
ARIANA GHAZELA 903
10.141.2.7 10.141.1.5

CENTRE DE TRI ENKHILETTE PETITE ARIANA


10.141.4.8 ASR 9006 Ariana 10.141.1.4 10.141.1.3
10.1.241.82
AOUINA
10.141.4.7 Taieb Mhiri AF AF

10.141.4.5 Sidi Fradj


10.141.4.6
ENNASR I
MENZAH ENNASR II 10.141.3.1
10.141.2.8 10.141.2.9

EL MENZEH ENNASR II
10.141.2.2 10.141.2.4 JARDIN
ELMENZAH I
EL MANAR 10.141.3.3
10.141.2.3 JARDIN
Equipe Metro-Ethernet Equipe Metro-Ethernet Equipe Metro-Ethernet
ELMENZAH II Boucle secondaire
10.141.3.2
EL MENZEH 6 MANAR-2
10.141.2.5 10.141.2.6
Elaboré par Aymen Fakhfakh

Figure 5: Architecture des boucles Metro-Ethernet « Ariana» Motivation

VIII. Motivation
Le choix du projet de fin d'études est une étape délicate, puisqu'elle matérialise la
transaction entre l'environnement éducationnel et la vie professionnelle.
Plusieurs visions ont orienté notre choix :
 En premier lieu, notre projet fait la connexité entre nos atouts qui sont les réseaux
informatique et le développement logiciel.
 En second lieu, la création de nouveaux projets, en prenant en compte les différents
besoins de notre client.
 En troisième lieu, le projet nous permet d'approfondir encore plus nos connaissances
en matière informatique, en ayant l'occasion de travailler avec des technologies
innovantes telle que la technologie mobile (Androide), MySQL, etc.

11
Chapitre 1 : Cadre général du projet

IX. Méthodologie de travail adoptée


Devant le nombre des méthodes disponibles de méthodologies de travail (en cascade,
en V, 2TUP, RUP…), le choix parmi elles devient difficile. Il dépend à la fois de la culture
de l'entreprise, le type de projet, l'environnement de travail et le mode de développement.

Le tableau 1 contient un comparatif entre les principales méthodologies:

Tableau 1: Comparaison des différentes méthodologies de développement

Méthodologie Points forts Points faibles


Modèle en Cascade -Distingue clairement les phases du projet. -Approche séquentielle non
-Bien utilisé dans les petites industries. adopté à un grand projet.
-Facile à mener. -Le client ne reçoit pas les
résultats concrets pendant le
développement du projet.
-Non itératif.
RUP -Itératif -Très axé processus.
-Allocation d’une large place à la technologie - Coût de personnalisation
et à la gestion du risque. souvent élevé.
- Interaction des différents intervenants du
projet(les livrables, les plannings,…)
- Plusieurs itérations internes basées sur des
retours utilisateurs.

Agile -Rapide et fortement adaptative aux -Difficile à mettre en œuvre


changements de besoins. de façon spécifique.
-Découpage des projets en itérations.

Après cette étude comparative entre les différents processus de développement nous
avons opté pour le processus RUP (Rational Unified Process) [3] pour de raisons multiples
qui s'adaptent à la nature de notre projet :

 Le processus unifié est itératif et incrémental


L'itération est une répétition d'une séquence d'instruction ou d'une partie de programme un
nombre de fois fixé à l'avance, ou tant qu'une condition définie n'est pas remplie.

12
Chapitre 1 : Cadre général du projet

Ceci garanti que le modèle construit à chaque phase ou étape soit affiné et amélioré. Chaque
itération peut servir aussi à ajouter de nouveaux incréments.
 Centré sur l'architecture
Tout système complexe doit être décomposé en parties modulaires afin de garantir une
maintenance et une évolution facilitée. Les modèles spécifiés tout au long du processus de
développement vont contribuer à établir une architecture cohérente et solide. Cette
architecture doit être modélisée en UML et pas seulement documentée en texte.
 Piloté par les risques
On peut minimiser les risques d'échec du projet, en définissant des priorités pour chaque
fonctionnalité.
 Conduit par les cas d'utilisation
Le projet est mené en tenant compte des besoins et des exigences des utilisateurs.

La gestion d’un tel processus est organisée d’après les quatre phases suivantes:

 L'incubation : nous allons au cours de cette phase, introduire la portée du projet,


traduire une idée en une vision du produit fini et modéliser les principaux cas
d'utilisation.
 L'élaboration : nous allons spécifier les besoins en détail et concevoir l'architecture
du système sous la forme de vues des modèles de conception.
 La construction : la solution proposée est construite et testée
 La transition : la solution est testé au niveau système et utilisateur, corrigée et
déployée.

X. Planification du déroulement du projet


Le tableau suivant décrit le déroulement du projet pendant les 4 mois du stage en
précisant les principales phases de réalisation de notre projet:

13
Chapitre 1 : Cadre général du projet

Tableau 2: Planification du déroulement du projet


Mois Février Mars Avril Mai
Semaine S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
Documentation
sur Métro
Ethernet et la
supervision
Simulation du
Réseau Métro
Ethernet
Conception de la
solution
Mise en place
d’une outil du
supervision
Instalation de
l’environnement
de devolleppement
Mise en place
d’une application
mobile

Rédaction du
rapport

Conclusion
Au cours de ce chapitre, nous avons présenté l'entreprise dans laquelle nous avons
effectué notre projet de fin d'etude et nous avons défini les objectifs de notre solution
proposée. Nous avons aussi présenté la methodologie de travail adoptée et modèlisé la
planification du déroulement du projet.

14
Chapitre 2 : Etat de l'art

Chapitre 2
Etat de l'art

Présentation du Métro Ethernet


Supervision du réseau Métro Ethernet

13
Chapitre 2 : Etat de l'art

Chapitre 2 : Etat de l’art

Introduction
L'étude des concepts de base est une étape primaire importante de tout projet afin de
comprendre les notions de bases pour réussir la partie conception et réalisation. Cette phase se
déroule en deux parties: nous commençons par l'explication des notions de bases du réseau
Métro Ethernet : nous présentons à titre d'exemple l'architecture du réseau Métro, les
équipements utilisés et les services. Nous finissons par une étude de supervision : au cours de
cette partie, on va citer les logiciels Open Sources existants et faire une étude comparative
entre ces logiciels afin de décider quel outil de supervision va-t-on mettre en place.

I. Présentation du Métro Ethernet


I.1 Définition du réseau Métro Ethernet
Un Métro Ethernet «ME» [4], est un réseau informatique qui couvre une région
métropolitaine et qui est basé sur le standard Ethernet. Il est formé d’une ou plusieurs boucles
qui sont formées de plusieurs routeurs. Les routeurs formant les boucles sont directement
connectés l’un à l’autre par un câble de fibre optique via leur interface TenGiga-Ethernet et la

bande passante de chaque boucle sera de 10 Gbps. Ce réseau est couramment utilisé comme
une métropole d'accès au réseau pour connecter les abonnés et les entreprises à un vaste
réseau de services ou à l’Internet.

Le réseau métropolitain a été construit pour répondre aux besoins de fiabilité et de


disponibilité stricte de communication vocale. En parallèle, la technologie Ethernet a été
largement acceptée dans le déploiement des réseaux d’entreprises. Cette technologie se
caractérise par une simplicité, une facilité de maintenance et une très grande fiabilité. Elle
possède une capacité à incorporer de nouvelles technologies. Son faible coût d’installation et
de maintenance, est l’un des caractéristiques majeures qui ont poussé les opérateurs à
s’investir et étendre l’utilisation de cette technologie dans les réseaux MAN.

Dans ce contexte, l’alliance industrielle mondiale MEF (MetroEthernet Forum) [5]


s’est investit pour standardiser la technologie Métro Ethernet. Sa mission consiste à élaborer
les spécifications techniques et à mettre en place des accords afin de promouvoir
l’interopérabilité et le déploiement du réseau Ethernet de classe opérateur dans le mode entier.

14
Chapitre 2 : Etat de l'art

Métro Ethernet permet aux opérateurs non seulement de raccorder à haut débit leurs
clients mais aussi de diversifier leurs offres de services. Elle fournit une solution de
connexion multipoint. Le MEF travaille avec tous les acteurs et les fournisseurs dans la
définition des spécifications afin d'assurer la conformité des équipements.

I.2 Architecture de base des réseaux Métro Ethernet


La figure 6 expose l’architecture d’un réseau Métro Ethernet qui est constituée de
quatre couches [6]. Chaque couche est caractérisée par sa fonction et son emplacement
assurant ainsi la mise en œuvre, et offrant plus de souplesse à la maintenance.

Figure 6: Architecture typique d'un réseau Métro-Ethernet

- U-PE (User-Facing Provider Edge) : face à l’utilisateur, c’est le premier équipement


coté opérateur avec qui le client opère. Il est responsable de limiter le débit et les
services pour chaque client. Ces nœuds seront les interfaces sur lesquelles seront
reliées les différents nœuds d’accès.
- PE-AGG (Provider Edge Aggregation Device) : ce sont les équipements d’agrégation
coté opérateur. Ils sont responsables de l'agrégation efficace et du multiplexage du
trafic et de la commutation locale pour les services Ethernet. Ces nœuds d’agrégation
ont comme but d’acheminer tout le trafic émanant des nœuds de la boucle vers les PE
(Provider Edge) du Backbone.
- N-PE (Network-Facing Provider Edge) : coté opérateur, cet équipement joue le rôle
de point de délimitation entre les protocoles de couche 2 et 3.

15
Chapitre 2 : Etat de l'art

Généralement, il utilise le mécanisme de transport de données MPLS (MultiProtocol


Label Switching) ainsi que la gestion des réseaux locaux virtuels.
- P (Core Layer Node) : ce sont, principalement, les équipements de liaison au
Backbone.

I.3 Topologies
I.3.1 En étoile

C’est la topologie la moins chère, se basant sur une station centrale qui est
généralement un Cisco ASR où chaque équipement sera relié à elle. Cette topologie cause une
totale déconnexion au réseau lors d’une panne dans l’équipement central.

Avec le modèle de topologie en étoile, la bande passante dédiée à chaque nœud peut
évoluer, parce que la fibre est complètent dédiée au nœud. Le plan de protection peut être
réalisé via des mécanismes tels que l'agrégation de liens selon la norme 802.3ad. En effet,
avec l'agrégation de liens, deux fibres sont rassemblées dans un grand conduit qui se connecte
au central de l'operateur. Le trafic est équilibré entre les deux fibres, et si une fibre est
endommagée, l'autre absorbe la pleine charge. Ce scénario est illustré à la figure 7.

Figure 7 : Topologie en étoile d’un réseau ME

I.3.2 En anneau
C’est la topologie la plus utilisée et qui est aussi utilisée dans notre projet, offrant à la
fois une robustesse du réseau en proposant deux chemins et un coût raisonnable. Par
conséquent, de nombreux déploiements de fibre dans le Métro sont prévus dans les
configurations en anneau.

16
Chapitre 2 : Etat de l'art

Pour les fibres existantes posées dans une topologie en anneau, les anneaux Gigabit
Ethernet sont une série de liaisons point à point entre les commutateurs existants dans les
nœuds et le central de l’opérateur (CO), comme le montre la figure 8.

Figure 8:Topologie en maillage d’un réseau ME

I.4 Les équipements utilisés

Le choix des équipements sera limité à la gamme de produit Carrier Ethernet offert par
Cisco.

I.4.1 Cisco ASR 9010


Le Cisco ASR 9010 [7] fonctionne de manière totalement distribuée et il est chargé de
toutes les décisions et les actions de transfert de paquets qui se déroulent sur des slots
individuels. Il traite 440GE/slot et possède une mémoire de 12Go, il contient 10 slots et
accepte les ½ slot.

Figure 9: Cisco ASR 9010

17
Chapitre 2 : Etat de l'art

I.4.2 Cisco ASR 9006


Le Cisco ASR 9006 dispose de 4Go de mémoire et est très utilisé pour une utilisation
moyenne d’un réseau Metro Ethernet, il contient 6 slots.

Figure 10:Cisco ASR 9006

Les routeurs ASR 9010 et ASR 9006 sont parfaits pour les réseaux en utilisation
nationale. Ils offrent un Accès multiple en 10GE vers les boucles d’agrégation ainsi que vers
les nœuds Core/Edge IP et 1GE pour la collecte des équipements locaux, ils supportent les
accès optiques DWDM.

I.4.3 Cisco ME-3800


Le Cisco ME 3800 [8], est une plateforme d’agrégation qui est entièrement conçue
pour la partie mobile, commerciale et résidentielle du marché en fournissant des services
comme la voix et la vidéo. Avec une faible consommation de puissance et un service de
grande échelle, ce routeur est optimisé pour l’agrégation de faible densité et à distance de
points de présence des applications.

 Ces routeurs sont conçu pour supporter des milliers d’abonnés avec une bonne
qualité de service, ils sont capables d’évaluer jusqu’à 32 000 files d’attente par port.

I.4.4 Support de Transmission : Fibre Optique Monomode


La fibre optique [9], est un fil de verre transparent très fin qui conduit un signal
lumineux codé permettant de véhiculer une large quantité d'informations. Elle supporte un
réseau large bande par lequel peuvent transiter simultanément: la télévision, le téléphone, la
visioconférence ou le Web. En effet, la fibre optique permet de garantir un débit de
transmission très élevé, en émission qu'en réception.

18
Chapitre 2 : Etat de l'art

On distingue entre fibres multi modes et fibres monomodes. Dans notre projet on va
s'intéresser à la fibre Monomode. Le domaine des télécommunications utilise la fibre
monomode pour assurer les hauts débits dans des longues distances, vu qu’elle est plus
avancée technologiquement avec un diamètre plus fin (en général 9μm) où les pertes sont
donc minimes (moins de réflexion sur l’interface cœur/gaine).

I.5 Exemple de boucle Métro Ethernet

Dans la figure qui suit, nous présentons, à titre d’exemple, l’emplacement des
équipements dans les deux boucles Métro Ethernet de Béja et de Jendouba. Nous avons choisi
l’exemple de ces deux boucles car elles contiennent tous les types d’équipements utilisés à
l’échelle nationale.

Figure 11: Boucles Métro Ethernet Beja et Jandouba

I.6 Les services Metro Ethernet


Les services Métro Ethernet sont maintenant offerts par une large panoplie de
fournisseurs de services. En effet, il existe des milliers d'abonnés utilisant ces services
Ethernet. La liste suivante donne un résumé de certains des services de Métro:

 Connectivité Internet.
 VoIP, IPTV.
 LAN aux Ressources réseau [10]: pour les nouveaux réseaux de données dans
lesquelles la connectivité se fait via des liens Gigabit, le Métro Ethernet peut être transformé
en un réseau local à très haut débit qui offre des applications importantes en bande passante.

19
Chapitre 2 : Etat de l'art

Figure 12 : Réseaux locaux LAN aux ressources réseau

 Les services Ethernet L2VPN [10]: le réseau de transport se comporte comme un


commutateur Ethernet Lan2 qui permet une connectivité multipoint à multipoint entre les
différents sites clients. Le client peut profiter de l’exécution de son propre plan de contrôle
d’une façon transparente sur le réseau de l’opérateur. Les routeurs du client peuvent échanger
ainsi leurs propres protocoles de routage sans interférence avec le routage de l’opérateur, et
l’opérateur n’est pas obligé à soutenir l’adressage IP du client.

Figure 13: Les services L2VPN

20
Chapitre 2 : Etat de l'art

 La facilité d’utilisation : ces services Ethernet sont fournis par une norme ou un
standard, largement disponible, pratiquement tous les équipements du réseau et les hôtes se
connectent à travers l’Ethernet.

 La rentabilité : les services Ethernet peuvent réduire les dépenses en capital des
entreprises et prestataires de services vue que l'interface Ethernet elle-même est peu coûteuse
par rapport à d’autres technologies.

 La flexibilité : le Métro Ethernet permet de transporter les différents types de services


offerts par les prestataires et les opérateurs réseau (Data, Téléphonie IP, …)

I.7 MPLS
I.7.1 Définition de MPLS
MPLS [11] (Multi Protocol Label Switch) représente un ensemble de spécification
définies par l'IETF (Internet Engineering Taskforce). Il a pour objet d'accélérer et de mettre
en forme des flux de trafic réseau, dont le rôle principal est de combiner les concepts du
routage IP de niveau 3 et les mécanismes de la commutation de niveau 2 pour le transport de
données.
 Multi Protocol : MPLS est capable de supporter les différents protocoles de niveau
inférieur de l'architecture en couche du modèle OSI (ATM, Frame relay,..)
 Label Switching : se base sur une étiquette pour la commutation des paquets. Cette
étiquette (appelé aussi Label) est l’identifiant unique pour la commutation des paquets
dans le nuage IP_MPLS et il est attribuée aux paquets par l’équipement PE (Provider
Edge) lors de leur entrée dans l’infrastructure MPLS.

Figure 14: Couche 2.5 MPLS

I.7.2 Architecture MPLS


MPLS a été conçu pour transporter à la fois le trafic en mode circuit et le trafic
en mode paquet sur des circuits virtuels appelés LSP (Label Switched Path).

21
Chapitre 2 : Etat de l'art

L'architecture MPLS utilise des LSRs (label Switching Router) et des LERs (Label Edge
Router).
Un LSR est un routeur haut débit au cœur d'un réseau MPLS qui participe à
l'établissement des LSP dont les fonctions sont :
 L'échange des informations de routage
 L'échange des labels
 L'acheminement des paquets
Un LER est un élément à l'extrémité du réseau d'accès ou du réseau MPLS qui joue
un rôle fondamental dans l'assignation et la suppression des labels.
Les deux types de LER qui existent sont :
 Ingres LER : est un routeur qui gère le trafic entrant dans un réseau MPLS
 Egress LER : est un routeur qui gère le trafic sortant d'un réseau MPLS

Figure 15:L'architecture MPLS

I.7.3 Fonctionnement MPLS


Les paquets IP entrant sur le réseau MPLS sont associés à une FEC : Forwarding
Equivalent Class. En effet une FEC va définir comment elle sera acheminé à travers tous le
réseau MPLS. Le choix d’une FEC peut être fait selon plusieurs paramètres (adresse IP
source, destination et paramètre de QoS (débit, delai)).
Quand un paquet IP arrive à un Ingress LER, il sera associé à une FEC. Un protocol
de routage sera mis en œuvre pour découvrir un chemin jusqu'à l'Egress LER. Cette étape est
similaire au cas du routage IP classique, mais cette opération ne se réalise qu'une seule fois.
Ensuite, tous les paquets appartenant à la même FEC seront acheminés suivant ce chemin
qu'on appellera LSP. D’où, le principe de la séparation entre la fonction de routage et la
fonction de commutation.

22
Chapitre 2 : Etat de l'art

I.7.4 Commutation et distribution des labels

a. Définition de label
Une étiquette [12] identifie le chemin qu'un paquet doit suivre, c’est pourquoi
il est encapsulé dans une entête de niveau 2 et immédiatement suivi par le paquet de
niveau 3. Il est utilisé pour chercher les informations de routage (next hop, lien de
sortie, encapsulation,…).
L'entête du label possède 32 bit, soit 4 octets. Cet entête comporte 4 champs:

Figure 16: Les champs d'un label

 Le numéro de label

 CoS : Chaque paquet peut se voir attribuer une Class of service, afin de permettre un
certain ordonnancement de priorité pour des paquets ayant le même numéro de label.

 S : bottom of stack. Ce bit "S" est à 1 quand le dernier label de la pile est atteint. Il est
utilisé dans le cas de l'empilement des labels lors de la création des tunnels.

 TTL : Ce champ a le même rôle que le TTL de l’entête IP. Etant donné que l’entête IP
n’est pas analyseé par les LSR, la valeur du TTL est recopiée dans l’entête MPLS à
l’entrée du réseau par l’Ingress LER. Ensuite, à chaque commutation par un LSR, le
TTL est modifié. La valeur TTL de l’entête MPLS est ensuite recopiée dans l’entête IP
à la sortie du réseau MPLS par l’ Egress LER.

b. Commutation des labels


La commutation de label consiste à effectuer un acheminement de paquets à partir d'un
chemin établi préalablement et constitué d'une liste de labels. Les numéros de label sont créés
localement. Le choix du chemin entre la source et la destination est effectué sur le premier
routeur MPLS. En effet, pour que le LSR puisse commuter correctement les paquets,
l'Ingress LER affecte une étiquette appelée «Label pushing» L1 à ces paquets. Le LSR1 saura
en consultant sa table de commutation que tout paquet entrant ayant le label L1 appartient à la
FEC et donc doit être commuté sur une sortie S en lui attribuant un nouveau «Label
swapping» L2. Cette opération de commutation sera exécutée par tous les LSR du LSP
jusqu'à aboutir à l'Egress LER qui supprimera le «Label popping» et routera le paquet de
nouveau dans le monde extérieur IP.

23
Chapitre 2 : Etat de l'art

Parfois, il est recommandé d'effectuer l'opération de dépilement sur le dernier LSR du


LSP c'est-à-dire le LSR qui est juste avant le LER pour éviter de surcharger le LER
inutilement puisque les opérations de routage sont complexes et couteuses.

Figure 17: Le principe de la commutation des labels

c. Le Protocol LDP
Par définition LDP[11] est un protocole permettant d'apporter aux LSR les
informations d'association des labels dans un réseau MPLS. Il est utilisé pour associer les
labels aux FEC, ce qui crée des LSP. On note que les sessions LDP sont établies entre deux
éléments du réseau MPLS, qui ne sont pas nécessairement adjacents.

Ces éléments échangent les types suivants de messages LDP :

 Messages de découverte (messages Hello) : échangés en mode UDP, annoncent et


maintiennent la présence d’un LSR dans le réseau.
 Messages de session (mode TCP) : établissent, maintiennent et terminent les sessions
LDP
 Messages Label Request ou demande de label : est envoyé par le LSR amont pour
demander quel label il doit utiliser pour une FEC spécifique.
 Messages Label Mapping : message d’attribution de label à une FEC, peut être émis
en réponse au message Label Request ou spontanément après la découverte d’une
nouvelle FEC.

I.7.5 MPLS VPN


Dans le réseau MPLS VPN [13], une terminologie particulaire est employée pour
désigner les routeurs en fonction de leurs rôles. Les différentes nominations des routeurs dans
le sens sortant du Core MPLS vers l’extérieur sont illustrées dans la figure 18 et sont le
suivants :

24
Chapitre 2 : Etat de l'art

 Routeur P (Provider) : ces routeurs, composent le cœur du réseau MPLS. Ils n’ont
aucune connaissance de VPN. Ils se contentent d’acheminer les données à l’aide de la
commutation des labels.
 Routeur PE (Provider Edge) : ces routeurs se trouvent à la frontière du réseau et ils
sont reliés à des routeurs (CE)
 Routeur CE (Custmer Edge) : ces routeurs appartiennent aux clients et n’ont aucune
connaissance de VPN ou même de la notion de label.

MPLS VPN est une méthode d’interconnecter des sites géographiquement distants
d’une entreprise en reliant ses sites aux points de présences (POP) de l’opérateur les plus
proches et en mettant en place des VPN.

MPLS VPN permet d’isoler le trafic entre sites n’appartenant pas au même VPN grâce
à la notion de routeurs virtuel (VRF) et le protocole MP-BGP ( Multi-Protocol Border
Gateway Protocol), dédié à l’échange des routes VPN.

Figure 18: Architecture MPLS_VPN

II. Supervision du réseau Métro Ethernet


II.1 Définition de la supervision des réseaux
La supervision [14] des réseaux constitue à utiliser des ressources réseaux adaptées
dans le but d’obtenir des informations, en temps réel ou non, sur l’utilisation ou l’état des
réseaux afin d’assurer un niveau de service garanti et une bonne qualité. Ces informations
présentent des actions liées à des évènements qui peuvent être : un enregistrement dans un
log, un tracé graphique ou une alerte (mail, SMS, …).

25
Chapitre 2 : Etat de l'art

La mise en place d’une supervision réseau, a donc pour principale vocation de


collecter, à intervalles réguliers, les informations nécessaires sur l’état de l’infrastructure et
des entités qui y sont utilisés, de les analyser et de les rapporter.

II.2 Objectifs
Les objectifs d’une supervision de réseaux peuvent se résumer en trois points :
 Etre réactif en avertissant l’administrateur en cas de dysfonctionnement du système.
 Etre pro actif en anticipant les pannes possibles.
 Cibler le problème dès son apparition afin d’agir rapidement de la façon la plus
pertinente possible.

II.3 Environnement de gestion SNMP


Le protocole SNMP (Simple Network Management Protocol), est un protocole qui
assure la gestion des équipements du réseau et le diagnostique des problèmes survenus,
offrant par conséquence un grand nombre d’avantages que n’ont pas les autres protocoles :

 SNMP propose une interface de transaction commune à tous les équipements, et donc
elle est la plus homogène possible.
 SNMP permet aux administrateurs réseau de gérer les équipements du réseau et de
diagnostiquer les problèmes de réseau.
 Disposer d'une cartographie réseaux.
 Mesurer la consommation d'une application
SNMP offre plusieurs versions:
SNMP v1 : le plus utilisé dans les petits sites.
SNMP v2: pour du site important répartis géographiquement. La version SNMPv2 permet
surtout une augmentation de la sécurité dans les échanges SNMP et l'échange de certains
types de message d'administration entre gestionnaires de réseau.
SNMP v3 : encore plus sécurisé.

II.3.1 Modèle d'administration avec SNMP


L’architecture SNMP repose sur deux éléments principaux, l’agent et le manager,
comme le montre la figure 19.

L’agent [15] est un programme installé sur chacune des machines hôtes. Il enregistre
toutes les informations de supervision. Ces informations sont stockées dans une basse de
données appelée MIB (Management Information Base).

26
Chapitre 2 : Etat de l'art

Un agent peut être par exemple une station de travail, un serveur, un routeur ou un
Switch. Le manager, géré généralement par un NMS (Network Manager System), est une
entité distincte responsable sur la communication avec l'agent SNMP installé dans les
équipements réseau. Il assure le rôle de contrôle du réseau et la communication avec les
agents via le protocole SNMP.

Figure 19: Architecture SNMP

II.3.2 La MIB et les OIDs


La MIB [15] est une collection d'informations pour la gestion des éléments du réseau.
Le manager SNMP utilise cette base de données pour communiquer avec l’agent, demander
des renseignements précis et traduire l'information nécessaire pour le NMS.

La MIB comprend des objets identifiés par l'identificateur de nom de l'objet OID
(Object ID). Chaque identifiant est unique et désignant les caractéristiques spécifiques d'un
hôte géré. Un objet est une information que nous pouvons recueillir des informations sur un
périphérique réseau. Par exemple, un objet peut-être : l’état d’une interface, température d’un
équipement, le taux d’occupation de la CPU,…etc .

Chaque Object ID est organisé hiérarchiquement dans MIB sous forme d'arbre . Une
pièce d'identité typique de l'objet sera une liste d'entiers en pointillés. Par exemple OID pour
l’objet " InterfacGi1_2/0 " est .1.3.6.1.2.1.1.1.

27
Chapitre 2 : Etat de l'art

L'accès aux informations des MIBs est contrôlé par l’utilisation d'un nom de
communauté. Ce dernier doit être configuré dans le manager et l’agent pour assurer la
communication entre ces deux éléments. Le nom de communauté peut être configuré selon
trois types d'accès sur les variables de la MIB gérée par l'agent : pas d’accès, RO (Read-Only)
et RW (Read-Write).

II.3.3 Les commandes de bases


Le protocole SNMP est constitué de plusieurs commandes différentes (Figure 20)
parmi lesquelles:
Get-request : utilisé pour obtenir de l'agent les valeurs des objets.
Get-Next-request: ressemble à Get-request mais il permet de retirer la valeur de l'objet
suivant dans la MIB.
Set-request : utilisé pour affecter une valeur à un objet.
Get-response: retourne une réponse a Get-request, Get-Next-request et Set-request
Trap : c'est une notification envoyée par l'agent suite à un événement
Le port 161 est utilisé par l'agent pour recevoir les requêtes de la station de gestion et le port
162 est réservé pour la station de gestion pour recevoir les alertes des agents.

Figure 20: Les requête SNMP

II.4 Etude comparative des solutions de supervision


Aujourd’hui, il existe plusieurs plateformes de supervision. Certaines se contentent de
connaître à tout instant l’état des nœuds du réseau, d’autres permettent également de connaître
l’état des services sur ces nœuds et des nombreuses statistiques du réseau permettant une
analyse assez fine.

28
Chapitre 2 : Etat de l'art

II.4.1 Solution libre ou payante


Le marché de la supervision est découpé entre deux catégories : les offres payantes et
les offres du monde libre. Les premiers offrent des solutions assez complètes et faciles à
installer et configurer. Ce qui rend leurs offres attractives. Mais les produits payants
dépendent trop vis-à-vis de l’éditeur pour toute évolution ou toute mise à niveau et les
services qu’ils offrent sont presque les mêmes que ceux offerts par un produit open source,
également pour les grands réseaux (comme le réseau d’opérateur), ce genre de solution
présente un inconvénient majeur qui se présente dans le prix de leur licence. Cependant les
logiciels libres sont souvent Open Source. Il est donc possible de modifier et adapter l’outil
selon les besoins. C’est pour cette raison, nous allons se contenter d’étudier les solutions
libres.

II.4.2 Les Solutions libres


Ils existent une diversité de logiciel de supervision libre. Nous avons sélectionné les
quatre meilleurs outils de supervision basée sur une interface web. Ces outils sont les
suivants : Zabbix, Cacti, EyesOfNetwork et Nagios. Par la suite nous allons voir ces différents
outils, les comparer et voir celui qui est le meilleur afin de l'adapter en vue de développer une
solution pour notre projet.

a. Zabbix
Zabbix [16] est une solution de supervision open source qui permet de superviser des
réseaux, et de surveiller les états de différents services. Le serveur Zabbix peut être
décomposée en trois parties. D’abord, l’application est composée d’une partie donnée, avec
l’usage d’un serveur de base de données telle que MySQL permettant de stocker les
informations sur les paramètres des hôtes. Ensuite, il y a un serveur de traitement ( Zabbix
Server), gérant les différents outils de supervision et de surveillance. Et pour finir, l’interface
web pour configurer et administrer Zabbix.
C'est une solution complète : cartographie de réseaux, gestion poussée d'alarmes via
SMS, statistiques et reporting. Mais l'agent Zabbix communique par défaut en clair les
informations, d’où la nécessité de sécuriser ces données.

29
Chapitre 2 : Etat de l'art

b. Cacti
Cacti [17] est un logiciel de surveillance basé sur RRDtool permettant de surveiller
l’activité des hôtes à partir de graphiques quotidiens. Sa fonction première est de collecter des
informations. Il permet aussi de représenter graphiquement le statut des périphériques réseaux
en utilisant le protocole SNMP grâce à des scripts écrits en perl, en C, ou en PHP. Le
monitoring de Cacti est fondé sur la supervision réseau et la métrologie. Grâce à un système
de plugins très simple, on peut l’enrichir par de nombreuses fonctions telles que la gestion de
découverte du réseau.
Ce logiciel présente plusieurs avantages :
 Interface très claire.
 Configuration facile avec l'utilisation des templates pour les machines, les graphiques,
et la récupération des données. Tout se configure aisément et entièrement via
l'interface web.
 Performance : choix du moteur de récolte des données permettant d’opter pour la
performance ou la simplicité.
 Notoriété sur le web, présence d'une dizaine de plugins permettant d'étendre les
fonctionnalités.

Cependant on note le manque d’une gestion de panne et l'absence d'une cartographie


de réseau.

c. Nagios
Nagios [18] est un logiciel libre distribué sous licence GPL qui permet de superviser
un système d’information complet. Cet outil repose sur une plateforme de supervision,
fonctionnant sous Linux. Il centralise les informations récoltées périodiquement par le
fonctionnement modulaire dont il est caractérisé, ce qui le rend beaucoup plus attractif que
d’autres produits concurrents.
Les fonctionnalités de Nagios sont très nombreuses. Parmi les plus communes nous
pouvons citer les suivantes :
 La supervision des services réseaux, des hôtes et des ressources systèmes (CPU,
charge mémoire…)
 La détermination à distance et de manière automatique, grâce à ses plugins, l’état des
objets et des ressources nécessaires au bon fonctionnement du système.
 Représentation coloriée des états des services et hôtes définies.
 Génération de rapports.

30
Chapitre 2 : Etat de l'art

 Gestion des alertes.


 Surveillance des processus
 La supervision à distance peut utiliser SSH ou un tunnel SSL.
En revanche sa configuration peut se révéler complexe, il est besoin d’un autre outil
comme Cacti pour faciliter sa configuration. De plus, cet outil ne permet pas d’ajouter des
hosts via Web et pas de représentations graphiques.

e. EyesOfNetwork
EyesOfNetwork « EON » [16] est une solution complète de supervision, basée sur la
distribution GNU/Linux CentOS. Il est géré et administré via une interface web, qui est
accessible par tous les acteurs d’un système d’informations avec une vue correspondant au
métier de chacun. Toutes les informations sont stockées sur une base de données MySql ou
Berkeley.
EyesOfNetwork integre les outils suivants.
 Supervision réseau : Nagios et NagVis.
 Gestion des performances : Cacti et Weathermap.
 Interface de configuration : Interface web d’EON.
Avantages
 Permet de regrouper tous les outils de supervision dans une même distribution.
 Ajouter un gestionnaire de performance.
 Interface de configuration web.
 Permet de faciliter le déploiement des outils de supervision.
 Possibilité d’administrer ses périphériques via SSH/Telnet depuis son
Interface web.
 propose aux administrateurs de créer leur propre carte de supervision sur lequel
ils placent les différents indicateurs. Celle-ci grâce à l'outil NagVis.

 C'est une solution complète : gestion poussée d'alarmes via SMS ou Email, gestion
des utilisateurs, gestion de pannes, statistiques et reporting, cartographie de réseaux,
gestion des indicateurs de performances,…etc.
Inconvénients
 Une configuration en interface web qui ne supporte pas l’HTTPS
Architecture
L'architecture d'EyesOfNetwork, est présenté dans la figure 21.

31
Chapitre 2 : Etat de l'art

Figure 21: Les outils constituants EyesOfNetwork

Cet outil permet de superviser le réseau et ses équipements, les serveurs, les
périphériques et les applications, surveiller les systèmes d’information et assurer la
disponibilité des services. Il inclut un ensemble intégré d’applications répondant aux
différents besoins, on note à titre d’exemple Nagios, Cacti, Nagvis, Weathermap et Navigs.

II.4.3 Choix d'outils de supervision


Le tableau suivant compare les 4 solutions sélectionnées:

32
Chapitre 2 : Etat de l'art

Tableau 3: Tableau comparatif des outils de supervision

Outil Environnement Protocole Installation et Avantage Inconvénient


d'installation configuration
simple
Zabbix Linux HTTP,FTP, Oui - L'application a été testée avec succès avec 1000 - L'agent Zabbix communique par
SSH,IMAP équipements . défaut en clair les information.
-Réalisation de graphiques, cartes.

Cacti Linux SNMP, Non - Gestion des utilisateurs. -Pas de gestion de panne et absence
SMTP,ICMP - Plusieurs modes d'affichages et plusieurs d'une cartographie de réseau
possibilités de configuration. -Pas de gestion d'alarmes

Nagios Linux SNMP, Non -Une solution complète permettant le reporting, la -Configuration fastidieuse via
SMTP,POP3, gestion de panne et d'alarmes et gestion utilisateurs. beaucoup de fichiers.
NNTP,ICMP - Reconnu auprès des entreprises. - Interface non ergonomique et peu
intuitive.

EyesOfNetwork Linux(Centos) SNMP, Oui - Permet de regrouper tous les outils de Supervision - Une configuration en interface
SMTP,POP3, dans une même distribution Web qui ne supporte pas HTTPS.
NNTP,ICMP - Ajouter un gestionnaire de performance.
-Faciliter le déploiement des outils de supervision
- Gestion des utilisateurs.

33
Chapitre 2 : Etat de l'art

D'après cette étude comparative, on conclut que chaque outil de supervision est dédié
à un cas bien spécifique, par exemple Cacti est utilisé pour surveiller l’activité des hôtes à partir
de graphiques et Nagios pour la supervision des services réseaux (SMTP, http…). Dans notre
cas on a opté pour l'outil EyesOfNetwork qui constitue la solution idéale pour la supervision
de notre réseau Métro Ethernet puisque il inclut un ensemble intégré d’applications répondant
aux différents besoins, on note à titre d’exemple Nagios, Cacti, NagVis et Weathermap.
Cet outil permet de superviser le réseau et ses équipements, les serveurs, les périphériques, les
applications, surveiller les systèmes d’information et indiquer la disponibilité des services.
Une des particularités d’EyesOfNetwork est sa modularité. En effet, grâce à ses
plugins, EyesOfNetwork possède une architecture facilement adaptable à l’environnement.
Ces plugin peuvent être ajoutés, modifiés ou même personnalisés et permettent de spécifier
les tâches pour aboutir au résultat voulu. De plus EyesOfNetwork est une solution stable,
dispose d’une grande communauté de développeurs et est utilisé aussi bien dans les petites et
moyennes infrastructures que dans les grands parcs informatiques.

Conclusion
Dans ce chapitre, nous avons fait une présentation générale de l'ensemble de concepts
nécessaires pour la compréhension du projet: le réseau Métro Ethernet et la phase de
supervision de ce réseaux.
Nous commençons alors, dans le chapitre suivant, la phase de spécification des
besoins de notre projet.

34
Chapitre 3 : Analyse et spécification des besoins

Chapitre 3
Analyse et spécification des besoins

Spécification des besoins de la solution


La modélisation UML

35
Chapitre 3 : Analyse et spécification des besoins

Chapitre 3 : Analyse et spécification des besoins

Introduction
Cette phase de notre étude est très importante, puisque c’est la première étape du cycle
de développement du projet, au cours de laquelle on définit les fonctionnalités que
l'application devrait satisfaire. Nous dégagerons dans la première partie de ce chapitre les
différents besoins fonctionnels et non fonctionnels. Ensuite nous allons présenter dans la
deuxième partie les différents cas d’utilisation de notre système.

I. Spécification des besoins de la solution


I.1 Spécification des besoins fonctionnels
Les besoins fonctionnels représentent les exigences du futur système en termes de
fonctionnalités. Ils constituent une sorte de contrat ou promesse pour le comportement du
système généré. En effet notre solution doit répondre aux besoins fonctionnels suivants:

 Vérifier la disponibilité des boucles Métro Ethernet


La disponibilité consiste à suivre l'état des routeurs (UP ou Down), en fait, nous devons
montrer la disponibilité d'un équipement donné de façon très simplifiée.
 Mesure de performance et de qualité des équipements réseau Métro Ethernet
Pour suivre le bon fonctionnement du réseau Métro Ethernet et éviter la dégradation de la
qualité des services offerts, des indicateurs de performance seront indispensables pour la
gestion de ce réseau.
 Détecter les anomalies
Le but de notre application est de détecter les aléas, les incidents et les problèmes de
dysfonctionnement des services et des équipements afin d'aider les responsables à les traiter
le plus rapidement possible.
 Le reporting
Notre solution doit générer des rapports, des graphiques et des histogrammes assurant l'aide à
la décision et détaillant les états des services et des équipements considérés.
 La mobilité
On se propose de développer une plateforme mobile qui permet aux exploiteurs de gérer le
réseau, le superviser et suivre ses performances avec un accès facile via leurs Smartphones.

36
Chapitre 3 : Analyse et spécification des besoins
 Localisation des boucles Métro Ethernet
L’application doit contenir une interface de supervision qui contient la carte géographique du
réseau Métro Ethernet. Cette dernière, nous présente l’emplacement de chaque équipement
ainsi que son état.

I.2 Spécification des besoins non fonctionnels


Les besoins non fonctionnels sont des besoins qui ne concernent pas le comportement
du système mais déterminent des contraintes du système.
Notre système doit satisfaire les besoins non fonctionnels suivants:
 La sécurité des données
 On peut sécuriser les données en appliquant une stratégie d'identification,
d'authentification, d'autorisation et de contrôle de chaque tentative d'accès à ces
données. Dans notre application, l'accès aux informations personnelles n'est autorisé
qu'aux personnes propriétaires.
 L'ergonomie
 Les interfaces de l'application doivent être claires et faciles à manipuler et les données
doivent être lisibles.
 La fiabilité
 La solution doit fournir les informations demandées sans erreurs.
 La gestion de toutes les exceptions relative à l'interaction avec l'utilisateur.
 La flexibilité et l'évolutivité
 La solution doit permettre l’ajout des nouvelles technologies, de nouveaux
équipements ou d'autres indicateurs de performance.

II. La modélisation UML


UML est un langage de modélisation graphique qui est apparu dans le cadre de la «
conception orientée objet ». Nous avons choisi UML parce qu'il fournit les outils nécessaires
à la construction des modèles de notre système, à l'organisation du travail et à l'analyse et la
compréhension des représentations. En vu d’élaborer graphiquement les modèles de données
et les processus métiers ainsi que la liaison entre eux, nous utiliserons l’outil Power AMC.

37
Chapitre 3 : Analyse et spécification des besoins

III. Présentation des acteurs


Notre application interagit avec deux types d’acteurs à savoir l’administrateur et les
superviseurs.
 L’Administrateur
Cet acteur dispose du privilège d'administration: Il sera chargé d'assurer le contrôle, la
gestion et la sécurité de l'application. Il a comme rôle :
 Gestion des superviseurs.
 Gestion des équipements.
 Contrôle de l’espace de localisation des boucles Métro Ethernet à superviser.
Un administrateur peut en plus de sa tâche d’administration, effectuer toutes les tâches de
supervision.
 Le superviseur
Il est chargé d'assurer la supervision du réseau Métro Ethernet. Il a comme rôle :
 La supervision du réseau Métro Ethernet (ME):
 Vérification de la disponibilité des équipements.
 Vérification de l’état des services .
 Consultation du Weathermap.
 Gestion des indicateurs de performance .
 Génération des rapports.
 Détecter les anomalies
 Localisation des boucles Métro Ethernet à superviser :
 Rechercher le routeur à localiser sur une carte géographique
 Suivi de l’état du routeur localisé.

IV. Diagramme de cas d'utilisation


IV.1 Diagramme de cas d'utilisation général
Le diagramme de cas d'utilisation général, présenté dans la figure 22, résume les
fonctionnalités qui doivent être offertes par notre solution pour chaque acteur.

38
Chapitre 3 : Analyse et spécification des besoins

Superviseur Consulter l'espace du supervision

<<include>>

Consulter l'espace de <<include>>


localisation

Gérer les superviseurs


Administrateur

<<include>>
S'authentifier
<<include>>

Gérer l'epace de
supervision

<<include>>
Gérer l'espace de localisation

Figure 22:Diagramme de cas d'utilisation général

IV.2 Diagramme de cas d'utilisation détaillé


IV.2.1 Diagramme de cas d'utilisation de l'administrateur
Dans notre application, l'administrateur dispose des privilèges d’administration. Ces
privilèges consistent à :
 Gérer les superviseurs :
 Ajouter un superviseur.
 Modifier un superviseur.
 Supprimer un superviseur.
 Gérer l'espace de supervision :
 Gérer les routeurs
- Ajouter un routeur.
- Modifier un routeur.
- Supprimer un routeur.
 Configurer le Weathermap.

39
Chapitre 3 : Analyse et spécification des besoins
 Gérer l'espace de localisation.
 Gérer le routeur à superviser dans la région:
- Ajouter un routeur dans la région.
- Modifier un routeur dans la région.
- Supprimer un routeur dans la région.

Ajoutre un
superviseur

<extend> Modifier un
superviseur

<extend>
Gérer les sperviseurs

<extend> Supprimer un
superviseur

<include>

<include> S'authentifier

Administrateur
Gérer l'espace du Ajouter un
supervision <extend> routeur
<extend>

Gérer les routeues


<extend> <extend>
Modifier un
<extend> routeur

Configurer
Weathermap

Ajouter un Supprimer un
routeur dans la routeur
<extend> région

Gérer l'espace de
localisation
<include>
<extend>
Modifier un
routeur dans la
région
<extend>

Supprimer un
routeur dans la
région

Figure 23:Diagramme du cas d'utilisation de l'administrateur

40
Chapitre 3 : Analyse et spécification des besoins
IV.2.2 Description textuelle des cas d'utilisation

a. Cas d'utilisation «S'authentifier»


Tableau 4: Description textuelle du cas d'utilisation «S'authentifier»

Acteur Administrateur, Superviseur


Pré condition L'utilisateur doit être doit connaître son identifiant et
son mot de passe.
Scénario principal 1. L'utilisateur saisie son login et son mot de passe.
2. Le système vérifie les données saisies.
3. Le système autorise l'accès à l'application.
4. Le système affiche le profil correspondant à l'utilisateur.
Post condition Session ouverte
Exceptions -L'utilisateur n'a pas saisi les bons identifiants :
Le système renvoie un message d'erreur et signale à
l'utilisateur de retaper son login et son mot de passe.

b. Cas d'utilisation «Gérer les superviseurs»

Gérer les superviseurs <<include>>

<<extend>>

Adinistrateur
<<extend>> S'authentifier
<<extend>>

Ajouter un superviseur Modifier un superviseur

Supprimer un superviseur

Figure 24: Cas d'utilisation «Gérer les superviseurs»

41
Chapitre 3 : Analyse et spécification des besoins
Tableau 5: Description textuelle du cas d'utilisation «Gérer les superviseurs»

Acteur Administrateur
Pré condition Authentification de l'administrateur
Scénario principal L'administrateur gérer les superviseurs, il peut:
-Ajouter un superviseur.
-Modifier un superviseur.
-Supprimer un superviseur.
Post condition -Un superviseur est ajouté à la base de données.
-Les informations d'un superviseur sont modifiées
-Un superviseur est supprimé à la base de données.

Exceptions L'administrateur ne peut pas supprimer un superviseur qui


n'est pas enregistré dans la base.

c. Cas d'utilisation «Gérer les routeurs»

Ajouter un routeur Supprimer un routeur


Modifier un routeur

<<extend>>
<<extend>>
<<extend>>

Gérer les routeur

<<extend>>

<<Include>> S'authentifier
Gérer l'espace de
Contrôler l'espace du supervision
Adinistrateur supervision

Figure 25: Cas d'utilisation «Gérer les routeurs»

42
Chapitre 3 : Analyse et spécification des besoins
Tableau 6:Description textuelle du cas d'utilisation «Gérer les routeurs»

Acteur Administrateur
Pré condition -Authentification de l'administrateur.
-Activer le protocole SNMP sur le routeur à superviser.
Scénario principal L'administrateur gère les routeurs à superviser, il peut:
-Ajouter un routeur dans la plateforme de la supervision.
-Modifier un routeur dans la plateforme de la supervision.
-Supprimer un routeur dans la plateforme de la supervision.
Post condition -Un routeur est ajouté à EyesOfNetwork
-Un routeur est supprimé de EyesOfNetwork
Exceptions -L'administrateur ne peut pas supprimer un routeur qui
n'existe pas.
-L'administrateur ne peut pas gérer un routeur qui ne
contient pas la configuration SNMP.

d. Cas d'utilisation «Configurer Weathermap»


Weathermap nous permet de configurer des maps afin de mesurer l'utilisation de bande
passante de les liens réseaux. Il est utiliser pour nous montrer s'il existe une grande utilisation
sur le réseau.

<<include>
S'authentifier

<<extend>>
Gérer l'espace du
Administrateur supervision Configurer Weathermap

Figure 26: Cas d'utilisation «Configurer Weathermap»

43
Chapitre 3 : Analyse et spécification des besoins
Tableau 7: Description textuelle du cas d'utilisation «Configurer Weathermap»

Acteur Acteur Acteur Administrateur


Pré condition -Authentification de l'administrateur.
-Activer le protocole SNMP sur le routeur à superviser.
Scénario principal Pour configurer Weathermap, l'administrateur doit:
1. Cliquer sur le lien Weathermap
2. Ajouter un équipement avec Add Node
3. Ajouter un lien avec Add Link
Post condition L'utilisation de la bande passante est affichée sur la carte
Weathermap
Exception -Aucun résultat n'est affiché
- L'administrateur ne peut pas gérer un routeur qui ne contient
pas la configuration SNMP.

En plus des tâches d’administration, l’administrateur peut effectuer toutes les tâches
d’un superviseur. Ces tâches seront détaillées dans ce qui suit.

IV.2.3 Diagramme de cas d'utilisation de superviseur


Le superviseur est chargé d'assurer la supervision et la localisation des réseaux Métro
Ethernet. Il est responsable de :
 Consulter l'espace de supervision
 Vérifier la disponibilité des boucles des équipements.
 Vérifier les états des services des boucles Métro Ethernet.
 Consulter les indicateurs de performance
 Générer les rapports
 Consulter le Weathermap.
 Détecter les anomalies.
 Consulter l'espace de localisation des routeurs à superviser
 Consulter les cordonnées GPS de la boucle Métro Ethernet
 Rechercher un routeur dans la région.
 Consulter l'état du routeur dans la région à superviser.
 Agrandir la vue de la carte géographique de la région à superviser.
 Minimiser la vue de la carte géographique de la région à superviser.
 Changer le type de la carte

44
Chapitre 3 : Analyse et spécification des besoins

Choisir type de Choisir dimentions


Choisir ldes rapport de rapport
choisir des faits dimensions

<<extend>>
<<extend>>
<<extend>>
<<extend>>
Consulter les Génerer les rapports
indicateurs de
perfermance

<<extend>>
<<extend>>

Consulter l'espace de
Superviseur supervision

<<extend>>
Vérifier la
disponibilité des
équipements

<<extend>> <<extend>>
<<extend>>
Détecter les anomalies Consulter WeatherMap
Vérifier les états
des service
<<include>>

<<include>>

Consulter l'espace de localisation <<extend>> S'authentifier


Consulter l'état du
de routeur à superviser
routeur localiser
<<extend>>

<<extend>>
<<extend>>

<<extend>> rechercher le routeur à


<<extend>>
Agrandir la vue de localiser
la carte

Minimiser la vue Consulter les Changer la type de


de la carte cordonnées GPS la carte

Figure 27: Diagramme de cas d'utilisation du superviseur

IV.2.4 Description textuelle des cas d'utilisation


Dans ce qui suit, on détaillera les différents cas d’utilisation donnés dans la figure 27.

45
Chapitre 3 : Analyse et spécification des besoins

a. Cas d’utilisation «Vérifier la disponibilité des équipements»


L’utilisateur (le superviseur ou l'administrateur) peut consulter l’état des différents
routeurs configurés. L’état normal est l’état UP et on dit dans ce cas que le routeur est
disponible. Dans le cas contraire, le routeur est non disponible et un problème doit être résolu.
Les différents états d’une interface d’un routeur sont :

 Up : en fonctionnement.
 Down : éteint.
 Unreachable : inaccessible.

Tableau 8: Description textuelle du cas d’utilisation «Vérifier les disponibilités des


équipements»

Acteur Administrateur, Superviseur


Pré condition -Authentification de l'administrateur ou superviseur.
- Activer le protocole SNMP sur le routeur à superviser.
Scénario principal Pour consulter les états de différents routeurs, l'utilisateur
doit:
- Cliquer sur le lien Disponibilité.
Post condition Les résultats sont affichés
Exceptions -L'administrateur ne peut pas gérer un routeur qui ne
contient pas la configuration SNMP.

b. Cas d'utilisation «Consulter les indicateur des performances»


Les indicateurs de performance suivis sont la charge CPU et le trafic entrant et sortant
par interface.

Choisir des
choisir des faits dimentions

<extend> <extend>

Consulter l'espace de <extend> Consulter les indicateurs


supervision de perfermance
Superviseur

<include> S'authentifier

Figure 28: Cas d'utilisation «Consulter les indicateur des performances»

46
Chapitre 3 : Analyse et spécification des besoins
Tableau 9: Cas d'utilisation «Consulter les indicateur des performances»

Acteur Administrateur, Superviseur


Pré condition -Authentification de l'utilisateur.
-Activer le protocole SNMP sur le routeur à superviser.
Scénario principal Pour consulter les indicateurs de performance l'utilisateur
peut choisi:
-Une ou plusieurs dimensions (date, équipement, service...).
-Un ou plusieurs faits (CPU, Trafic).
Post condition Le graphe affiché indique :
-Le trafic entrant et le trafic sortant
- Le charge CPU
Exceptions -Les dimensions ou les indicateurs demandés ne sont pas
chargés dans la base de données.
-L'administrateur ne peut pas gérer un routeur qui ne
contient pas la configuration SNMP.

c. Cas d’utilisation «Génère des rapports»


Le superviseur ou l'administrateur peuvent choisir le type de rapport à générer. Il
existe deux types de rapport :

-Rapport de disponibilité: permet d’avoir la disponibilité hôte/service ou groupe


d’hôtes/services sur une période de temps donnée.

-Rapport générique: permet d’avoir la disponibilité d’un hôte ou d’un service sur une
période de temps donnée mais avec plus de clarté.

<<include>> S'authentifier

Choisir type
de rapport

<<extend>>
Consulter l'espace du supervision Générer des rapports
Superviseur
.
<<extend>>
<<extend>>

Choisir les
dimensions de
rapport

Figure 29: Cas d’utilisation «génère le rapport»

47
Chapitre 3 : Analyse et spécification des besoins
Tableau 10: Description textuelle du cas d'utilisation «Génère des rapports»

Acteur Administrateur, Superviseur


Pré condition Authentification de l'administrateur ou superviseur
Scénario principal Pour générer un rapports l'utilisateur doit :
1. Cliquer sur le lien rapport.
2. Choisir le type de rapport.
3. Choisir les dimensions(équipement ,période,..)
Post condition Affichage des rapports générer
Exceptions Aucun résultat n’est affiché.

d. Cas d’utilisation «Détecter les anomalies »


Le superviseur ou l'administrateur peut afficher les problèmes qui empêchent le bon
fonctionnement du système.

<<include>> S'authentifier

Consulter l'espace du supervision <<extend>> Détecter les


Superviseur
anomalies

Figure 30: Description de cas d'utilisation « Détecter les anomalies »

Tableau 11: Description textuelle du cas d’utilisation «Détecter les anomalies »

Acteur Administrateur, Superviseur


Pré condition Authentification de l'administrateur ou superviseur
Scénario principal Pour afficher les anomalies:
1. Le utilisateur choisit le menu «Affiche les anomalies» ;
2. Le système affiche les anomalies.
Post condition Les anomalies sont affichées
Exceptions Aucun résultat n’est affiché.

48
Chapitre 3 : Analyse et spécification des besoins
e. Cas d’utilisation «Consulter l'espace de localisation des routeurs à
superviser»

Superviseur
<<include>>
S'authentifier

Consulter l'espace de localisation


de routeur à superviser

<<extend>>
<<extend>>
<<extend>> <<extend>> <<extend>> <<extend>>

Agrandir la vue de
la carte
Consulter l'état du
Consulter les routeur localiser
Minimiser la vue cordonnées
Changer la
de la carte GPS
type de la
carte

rechercher le routeur à
localiser

Figure 31:cas d’utilisation «Localiser les routeur à superviser»

Tableau 12: Description textuelle du cas d’utilisation «Consulter l'espace de localisation des
routeurs à superviser»»

Acteur Administrateur, Superviseur


Pré condition -Authentification de l'administrateur ou superviseur

Scénario principal L'utilisateur localise les boucles Métro Ethernet, il peut:


1. Agrandir la vue de la carte.
2. Minimiser la vue de la carte.
3. Changer le type de la carte.
4. Cliquer sur marqueur pour consulter l'état de routeur
dans cette région.
5. Consulter les cordonnées GPS de chaque nœud.
Post condition Les résultats sont affichés
Exceptions -Aucun résultat n’est affiché.
- Le superviseur ne peut pas localiser un routeur qui n'est
pas enregistré dans la base.

49
Chapitre 3 : Analyse et spécification des besoins
f. Cas d’utilisation «Consulter l'état du routeur»
L’utilisateur (le superviseur ou l'administrateur) peut afficher l'état de chaque nœud
dans la région à superviser.

Consulter l'espace de
<extend> Consulter l'état du
localisation du routeur
à superviser routeur
Superviseur

<include>
S'authentifier

Figure 32: Cas d’utilisation «Consulter l'état du routeur localisé»

Tableau 13:Description textuelle du cas d’utilisation «Consulter l'état du routeur»

Acteur Administrateur, Superviseur


Pré condition Authentification de l'administrateur ou superviseur
Scénario principal Pour Consulter l'état du routeur localiser:
1. Cliquer sur le marquer où se localise le nœud.
2. Le système affiche l'état du routeur (Up/Down).
Post condition L'état du routeur est affiché
Exceptions Aucun résultat n’est affiché.

Conclusion
Dans ce chapitre, on a présenté notre solution proposée tout en citant les
fonctionnalités principales. Par la suite on a procédé à une identification des acteurs et on a
fait une analyse des besoins par le biais des diagrammes de cas d’utilisation pour mieux
comprendre le principe de fonctionnement de l’application. Dans le prochain chapitre, nous
allons présenter la conception de notre système.

50
Chapitre 4 : Conception

Chapitre 4
Conception

Conception de l'architecture de la solution


Diagramme de déploiement
Diagrammes d'activités
Diagrammes de séquences
Diagramme de classe

51
Chapitre 4 : Conception

Chapitre 4 : Conception

Introduction
Après la phase de spécification des besoins, on s’intéressera à la phase de conception.
Pour cela, on commencera par déterminer le diagramme de déploiement, le diagramme
d'activité et le diagramme de séquence. Ensuite, on définira le diagramme de classes et le
diagramme de navigation.

I. Conception de l'architecture de la solution

Notre projet consiste à réaliser une application qui supervise les équipements d’une
boucle Métro Ethernet. Cette application doit fournir deux types d'informations :

Information génériques : tel que les données des superviseurs, les positions géographiques
des routeurs. Nous pouvons donc, les stocker dans une base de données.

Information de supervision: qui seront fournit par la plateforme de supervision


EyesOfNetwork dont nous avons parlé auparavant.

Dans ces deux cas, l'utilisation des web service semble être primordiale.
Pour gérer ces informations, l'architecture que nous avons proposé pour notre
application est une architecture à quatre couches comme décrite par la figure 33 :

 Couche source : elle représente l’architecture Métro Ethernet contenant les


équipements utilisés (les routeurs dans notre cas)
 Couche de données : elle fournit à la couche serveur les données dont elle a besoin.
Elle contient les informations génériques traitées par l'administrateur.
 Couche serveur : son rôle principal est de récupérer les données depuis la couche
base de données.
 Couche présentation: elle correspond à la partie visible de notre application. Elle
permet de rendre l’information lisible, compréhensible et accessible à partir d’un
desktop ou bien un Smartphone.

52
Chapitre 4 : Conception

Couche de
Couche source données

Architecture Métro Ethernet Base de données

Requête SNMP Requête/Reponse

Couche serveur

Plateforme de supervision

http://Addresse du serveur HTTP JSON


HTTP
Couche
Présentation

Android Studio
Desktop

Figure 33:Architecture de la solution proposée

II. Diagramme de déploiement


Le diagramme de déploiement permet d'illustrer l'architecture physique du système et
de montrer la relation entre les différentes composantes de l'application et la disposition
organisationnelle.

53
Chapitre 4 : Conception

Client
Serveur web
HT T P

Android Web Service

HT T P SQL

Serveur de supervision Base de données

EyesOfNetwork
MySql

Requête
SNMP

Poste de travail

architecture Métro Ethernet

Figure 34: Diagramme de déploiement

III. Diagramme d'activité


Les diagrammes d'activités permettent de représenter graphiquement le comportement
d'une méthode ou le déroulement d'un cas d'utilisation. Plus précisément, ils illustrent la
description textuelle des cas d’utilisation. De plus, leur représentation sous forme
d'organigrammes les rend facilement intelligibles.

III.1 Diagramme d’activité « s’authentifier »


Pour accéder à notre application, l’utilisateur (administrateur ou superviseur) doit
s’authentifier en entrant son login et son mot de passe. Le processus d’authentification peut
être résumé dans le diagramme d’activité suivant :

54
Chapitre 4 : Conception

Figure 35: Diagramme d'activité s'authentifier

III.2 Diagramme d’activité « Ajouter superviseur»


Afin d'ajouter un superviseur, l'administrateur doit accéder au menu de gestion des
superviseurs où se trouve le formulaire d'ajoute de superviseur. Le processus d'ajout d'un
superviseur peut être résumé dans le diagramme d’activité suivant :

Figure 36:Diagramme d’activité « Ajouter superviseur»

55
Chapitre 4 : Conception
III.3 Diagramme d’activité «Modifier superviseur»
L'administrateur doit consulter la liste de superviseur et choisir un superviseur afin
de modifier ses coordonnées.

Figure 37: Diagramme d’activité «Modifier superviseur»

III.4 Diagramme d’activité «Générer les rapports»


Adminstrateur, Superviseur Application

Cliquer sur l'onglet Rapport


Afficher la menu du rapport

Choisir type du rapport

Demander la selection des dimensions

Sélectioner les dimensions

Afficher le rapport

Figure 38: Diagramme d’activité «Gérer les rapport »

56
Chapitre 4 : Conception
III.5 Diagramme d’activité «Consulter les indicateurs de
performance»
Adminstrateur, Superviseur Application

Cliquer sur l'ongle Cosultation des


indicateurs de perfermance
Affiher le menu indicateurs de
perfermance

Choisir fait
Choisir dimension

Afficher les graphes des indicateurs de


perfermance

Figure 39: Diagramme d’activité «Consulter les indicateurs de performance»

III.6 Diagramme d’activité «Consulter l'espace de localisation des


routeurs à superviser»
Dans notre application, la localisation a pour objectif d'aider le superviseur à connaitre
les coordonnées GPS du routeur et de consulter l'état des nœuds dans une carte géographique.
Le processus de localisation des routeurs peut être résumé dans le diagramme d’activité
suivant:

Figure 40:Diagrammes d’activité «Localiser les routeur à superviser »

57
Chapitre 4 : Conception

IV. Diagramme de séquence


Le diagramme de séquence décrit les interactions entre les différentes entités et les
différents acteurs dans le système dans un ordre chronologique. Il permet de représenter la
succession chronologique des opérations réalisées par un acteur et qui font passer d’un objet à
un autre pour représenter un scénario.

Dans cette partie, nous allons décrire les scénarios les plus importants ainsi que leurs
représentations par les diagrammes de séquence.

IV.1 Diagramme de séquence de cas d'utilisation «S'authentifier»


S'authentifier

Application

Utilisateur
Demande de connexion

Afficher l'interface d'authentification

Saisir login et mot de passe

Validation du login et mot de passe Vérification du login et mot de passe

alt Login et mot de passe valide

Afficher l'espace admnistrateur

ou

Afficher l'espace superviseur

Login et mot de passe non validés


Afficher le menu d'authentification

Figure 41 :Diagramme de séquence du cas d'utilisation «S'authentifier»

IV.2 Diagramme de séquence de cas d'utilisation rapport


«Générer le rapport »
L’accès aux données de supervision via Smartphone se fait par le biais d’un service
web permettant d'accéder à la plateforme de supervision EyesOfNetwork.

58
Chapitre 4 : Conception
Générer le rapport

Application android EyesOfNetwork

Utilisateur

S'authentifier

Vérification authentification

alt Login et mot de passe validés


Afficher l'espace de l'utilisateur
authentifié

Consulterle menu "Rapport" Accéder au serveur de supervision

Afficher le menu rapport

Choisir le type du rapport


Demander de séléctionner les dimensions
du rapport

Sélectionner les dimensions du rapport

Afficher le rapprt géneré

Condition
Afficher le menu d'authentification

Figure 42: Diagramme de séquence du cas d'utilisation «Générer le rapport »

IV.3 Diagramme de séquence de cas d'utilisation «Consulter


l'état du routeur»
Consulter l'état du routeur

Utilisateur Application android EyesOfNetwork

S'authentifier

Vérif_Authentification

alt Login et mot de passe validés


Afficher l'espace de l'utilisateur
authentifié

Consulter le menu de localisation

Afficher le menu de localisation

Sélectionner un routeur (marquer)


Acceder au serveur du supervion

Afficher l'état du routeur

Login et mot de passe non validés

Afficher le menu d'authentification

Figure 43: Diagramme de séquence du cas d'utilisation «Consulter l'état du routeur»

59
Chapitre 4 : Conception
VI.4 Diagramme de séquence du cas d'utilisation «Ajouter
routeur dans la région»
L'administrateur dispose du privilège d'administration. A ce titre il est
responsable de contrôler la région à superviser. Il peut par la suite :
 Ajouter une boucle Métro Ethernet
 Modifier une boucle Métro Ethernet
 Supprimer une boucle Métro Ethernet
La figure 44, représente le diagramme de séquence de cas d’utilisation «Ajouter
routeur dans la région» .
Ajouter routeur

Application android

Administrateur

S'authentifier

alt Login et mot de passe validés

Afficher l'espace de l'adminstrateur

Consulter lespace de localisation

Afficher l'espace de localisation

Acceder au menu " gérer routeur"


Afficher la formumaire d'ajout de routeur

Remplir le formulaire

Valider le saisie
Vérifier les champs

Ajouter routeur sur la carte

Login et mot de passe non validés


Afficher le menu d'authentification

Figure 44: Diagramme de séquence de cas d'utilisation «Ajouter routeur dans la région»

60
Chapitre 4 : Conception

VI. Diagramme de classe


Le diagramme de classe, représenté dans la figure suivante, introduit de manière
statique, les classes qui constituent le système de gestion du réseau métro Ethernet ainsi que
les relations existants entre elles. La définition d'une classe comprend impérativement les trois
éléments suivants:

Nom de la classe : description du modèle d'objet.

Attributs : présentation de l'état d'un objet par de variable.

Méthode : exécution des traitements sur les données membres des objets.

Les classes constituants notre application :

 Classe Utilisateur contenant les informations générales sur les utilisateurs de


l'application.
 Classe Administrateur contenant les informations relatives sur l'administrateur.
 Classe Superviseur contenant les informations relatives sur le superviseurs.
 Classe Profil contenant les profils des utilisateurs.
 Classe Espace correspondant à l'espace associée à chaque profil.
 Classe fonctionnalité contenant les différentes fonctions associées a chaque espace.
 Classe supervision contenant les différentes fonctions de supervision.
 Classe localisation contenant les différentes fonctions de localisation.
 Classe dimension contenant les différentes dimensions de mesure (Interface,
équipement, période).
 Classe Indicateurs contenant les différents indicateurs de performance (trafic, CPU).
 Classe Temps contenant les dimensions du temps.
 Classe Equipement contenant les informations de l'équipement.
 Classe Interface contenant les interfaces des routeurs.
 Classe Service contenant les différents services.
 Classe Marquer routeur contenant les différents informations de localisation du
routeur dans une carte géographique (longitude, latitude,..)

61
Chapitre 4 : Conception
Utilisateur
1..1 Espace Associer Profil
1..1 - Id-utilisateur : int
1..1
- id-espace : int - id-compte : int - Login : String
1..1 - Privilége : int - mdp : String
Posséde
1..1 - mail : char
Se compose - nom : String
- prenom : String

Fonctionnalité
- Id-fonctionnalité : int

Superviseur
Administrateur
- id-sup : int
- id_admin : int - login-sup : int
- login-admin : String

Supervision 1..1
1..1 1..1 1..1
Localisation - id-supervision : int gérer
- id-map : int
1..1 1..1
Se compose

1..1 Se compose
1..*
Se compose 1..*

Marquer routeur 1..1 Rapport


- id-routeur : int - id-rapport : int
ClassMap
- longitude : int
- latitude : int - id-Map : int
- nom-routeur : char gérer
1..1 1..1 Indicateur
Se compose
Service 1..* Se compose - cpu : Double
1..* - trafic entrant : Double
- id-service : int
1..* - trafic sortant : Double
- nom-serv : String
- Débit : Double
- type-serv : String

1..* gérer
1..* avoir 1..1
avoir Dimension
1..* - id-dim : int
1..*

Equipement
Temps
- id-equipement : int
- id_date : String - marque : String
- année : int - nom-equi : String
- mois : int Interface
- type-equi : char
- jour : int - id-interface : int
- heure : int - nom-interface : String
- minute : int

Figure 45: Diagramme de classe

62
Chapitre 4 : Conception

VII. Diagramme de navigation


Le diagramme de navigation représente les possibilités de navigation entre les
interfaces de l'application.

Le diagramme de navigation relatif au superviseur/administrateur est composé de


l'ensemble des actions qui permettent de se déplacer d'une page à une autre comme il est
illustré dans les figures suivantes:

Le cas de l'administrateur :

<Login et
mot de passe Authentification
érronés> <page>

<Login et mot de passe validées> Déconnéction


<action>

Gestion des superviseurs Espace Administrateur


<page>
<action>
Gestion de localisation

<action>
Espace de gestion des superviseurs Gestion de supervision
<action>

Espace de localisation
<page>
Ajouter superviseur
<page> Espace de supervision
<page>
gérer région
<action>

Liste de superviseurs
<action> Gestion des équipements
Ajouter routeur dans la région
<action> <page>

Supprimer un équipement
Ajouter un équipement <page>
<page> Liste de routeur de région
Liste de superviseur
<action>
<page>
Modifier un équipement
<page>

Liste des routeurs de région


selectionner superviseur <page>
<action>

Sélectionner routeur
<action>
Modifier /suprimer superviseur
<page>

Modifier / Supprimer un routeur


<page>

Figure 46: Diagramme de navigation de l'administrateur

63
Chapitre 4 : Conception
Le cas de superviseur :

<logine et
mot de passe Authentification
érronés> <page>

<Login et mot de passe validés>

Déconnéction
<action>
Espace superviseur
<page>

Consulter l'état du routeur


Onglet Supervision Onglet localisation <page>
<action> <action>

Espace de localisation
chercher routeur
<page> <action>

Espace de supervision
Vérifier les services <page>
Zoom Map Reduire Map
<action> changer type Map
<action>
<action>
Consulter Weathermap

Consulter les indicateur de


génrer le rapport Vérifier les disponibilité
perfermance <page>
<page> <page>
détecter les problémes
<page>

Figure 47: Diagramme de navigation du superviseur

Conclusion
Tout au long de ce chapitre, nous avons détaillé la conception de notre application à
travers le diagramme d'activité, le diagramme de séquence ainsi que le diagramme de classe
afin que la phase de réalisation et la mise en place de l'application soit plus souple et plus
aisée. Le chapitre suivant sera consacré à la réalisation et l'implémentation de notre solution.

64
Chapitre 5 : Réalisation

Chapitre 5
Réalisation

Environnement matériel et logiciel


Mise en place d'une maquette du réseau Métro Ethernet
Mise en place de l'outil du supervision EyesOfNetwork
Mise en place de l'application mobile

65
Chapitre 5 : Réalisation

Chapitre 5 : Réalisation

Introduction
Pour pouvoir mener à bien notre projet, il est nécessaire de choisir des technologies
permettant de simplifier sa réalisation. Pour celà, après avoir terminé la phase de conception,
nous allons aborder la partie implémentation. Nous commençons par exposer les choix
techniques utilisés et les langages adoptés, et présenter l’implémentation et les tests réalisés.

I. Environnement de travail
Pendant la phase de mise en œuvre de notre projet, nous allons exploiter un ensemble
d'outils et moyens techniques qui constituent l'environnement général de travail. On
s’intéressera ainsi aux matériels et logiciels qui sont utilisés pour la réalisation de notre
application.

I.1 Environnement logiciel


Durant la réalisation du notre projet, on s’est servi de l'environnement logiciel suivant:

Couche de
Couche source données

GNS3

Requête SNMP Requête/Reponse

Couche serveur

Plateforme de supervision

http://Addresse du serveur HTTP JSON


HTTP
Couche
Présentation

Android Studio
Desktop

Figure 48: Architecture logicielle de la solution

 GNS3:[20](Graphical Network Simulator) est un simulateur


d'équipements Cisco libre qui fonctionne sur de multiples plateformes. Il est capable
de faire fonctionner des routeurs Cisco virtuellement en les rendant totalement réels.

66
Chapitre 5 : Réalisation
Le contact avec le routeur se fait via une liaison console coté routeur et l’affichage est
avec l’outil Putty, les routeurs doivent avoir un système d’exploitation appelé IOS.

 EyesOfNetwork: (« EON ») est une solution de supervision


libre. La plus adéquate pour la supervision de notre architecture. Cet outil inclut un
ensemble intégré d’applications répondant aux différents besoins. on note à titre
d’exemple Nagios, Cacti, Nagvis, Weathermap. En plus, nous avons ajouté des
plugins pour offrir des services supplémentaires dont a besoin. EyesOfNetwork est
installée manuellement sur une machine virtuelle.

 VMware Workstation Pro: est un logiciel de virtualisation gratuit qui


permet d’exécuter plusieurs systèmes d’exploitation simultanément sur un même PC.

 WinSCP : [21] est un client permettant de se connecter à des serveurs


distants en toute sécurité. L'application est en mesure d'ouvrir des sessions SSH avec
les protocoles SFTP et SCP. L'ensemble des données qui transiteront sur le réseau
seront donc cryptées pour une sécurité maximale. Le but de ce programme dans notre
projet est de permettre la copie sécurisée de fichiers entre l'ordinateur local et la
machine virtuelle qui supporte EyesOfNetwork. Il permet également d’accéder aux
fichiers de configuration d’EON.

 WampServer : [22] est une plateforme de développement web sous


Windows pour des applications web dynamiques à l’aide du serveur Apache2, du
langage de scripts PHP et d’une base de données MySQL. Il possède également
PHPMyAdmin pour gérer plus facilement les bases de données.

 MySQL : [23] est un système de gestion de base de données


(SGBD). Il est distribué sous une licence GPL et propriétaire. Il fait partie des
logiciels de gestion de base de données les plus utilisés principalement pour les
applications web.

67
Chapitre 5 : Réalisation

 Android Studio : [24] Android Studio est l’environnement de


développement d’applications Android de Google basé sur la plateforme IntelliJ
IDEA. Il permet principalement d'éditer les fichiers JAVA et les fichiers de
configuration d'une application Android.

Les différentes étapes de la préparation de l’environnement de développement sous Android


sont illustrées dans l’annexe C.

I.2 Les choix techniques


I.2.1 Choix de l’architecture Client-serveur

Notre application, se base sur le modèle client-serveur et donc nous adopterons


l'architecture 3-tiers de la figure 49.

Le client : conteneur d'application et demandeur de ressources.

Le serveur d'application : son rôle principal est de gérer la communication entre le client
Android et le serveur de base de données.

Le serveur de base de données : il fournit au serveur d'application les données dont il a


besoin.

Si nous parlons de l'architecture 3-tiers de point de vue technologie :

 Le client correspond à plateforme Android


 Le serveur web correspond au PHP
 Le serveur de bases de données est le MySQL.

Figure 49: Architecture 3-tiers

68
Chapitre 5 : Réalisation
Pour se connecter à distance à une base de données MySQL via un appareil Android,
une solution est d’ajouter un service Web dans le milieu. Généralement MySQL est utilisé
avec PHP. Donc, on écrit des scripts PHP pour assurer la gestion de base de données et on
exécute ces scripts en utilisant le protocole HTTP du système Android. Les données seront
codées dans le format JSON pour pouvoir communiquer les données entre PHP et Android

I.2.2 Choix de langage de programmation

a. Java
Le langage de programmation Java est nécessaire pour le développement des
applications mobiles. Il s’agit d’un langage orienté objet utilisable sur différents système
d’exploitation.

b. PHP 5
PHP [25] (Hypertext Preprocessor) est un langage de programmation libre utilisé pour
générer des pages Web dynamiques via un serveur http. C'est un langage de script, en fait, le
code est enregistré sous forme de fichier texte est exécuté à la demande par un programme
chargé de l'interpréter.

I.3 Protocole et format de données


I.3.1 Protocole de communication
Dans notre projet, nous avons utilisé le protocole HTTP, afin de communiquer les
données entre la partie cliente mobile et le serveur web. Le HTTP est un protocole de
communication client-serveur. Il est utilisé pour échanger toute sorte de données entre le
client HTTP et le serveur HTTP. En général, nous utilisons la méthode Post pour envoyer des
données au programme situé à une URL spécifiée. Dans notre application la requête Post
envoyée à partir de l’application client vers le serveur est de la forme suivante :

http://192.168.1.67:8080/nomapplication?parametre=valeur.

I.3.2 Format de données communiquées

JSON [26] (JavaScript Object Notation) est un format léger d'échange de données. Le
principal avantage de l’utilisation de JSON, dans notre application:

 Simple à mettre en œuvre.


 Ses types de données sont connus et simples à décrire.

69
Chapitre 5 : Réalisation
Le principe est donc que le client Android appelle le script PHP qui va récupérer les
données à partir de la base de données MySQL. Ces données seront codées au format JSON
puis le serveur les envoie au client. Ensuite l’application analyse et affiche ces données
codées.

I.4 Environnement matériel


Pour la réalisation de ce projet, nous avons disposé d'un PC portable ayant les caractéristiques
suivantes:

 Nom : Lenovo
 Processeur : Intel® Core™2 Duo CPU 2.50 GHZ
 RAM: 4 Go
 Système: Windows 7 Professional

II. Mise en place d'un réseau Métro Ethernet


Dans cette partie, nous avons mis en place l’architecture Métro Ethernet «ME»
proposée par Tunisie Telecom sous GNS3. Par la suite, nous avons configuré les divers
équipements utilisées (Routage OSPF, Configuration MPLS,..) et nous avons fait tous tests
nécessaires pour garantir le bon fonctionnement de notre réseau.

Pour alléger la tâche de supervision, nous avons considéré une architecture Métro Ethernet
contenant deux boucles comme le montre la figure 50.

Figure 50 : Maquette Métro Ethernet «Ariana»

70
Chapitre 5 : Réalisation

Les routeurs utilisés sont de types Cisco 7200, ils offrent :


 Une interconnexion Gigabit Ethernet.
 Plusieurs versions d’IOS disponibles.
 Une mémoire FLASH supplémentaire.
 Une gestion MPLS.
Pour l’interconnexion entre les routeurs du réseau Metro Ethernet, nous avons utilisé
des câbles Giga-Ethernet.

II.1 Plan d'adressage


Lors de mise en place de notre réseau, il faut établir un plan d’adressage adéquat. Ce
dernier est présenté dans le tableau 14 :

Tableau 14: Plan d’adressage


Boucle Routeur Gi1/0 Gi2/0 Gi3/0 Masque
Ring 1 Sokra 10.241.1.2 10.241.1.5 - 255.255.255.252
Aouina 10.241.1.6 10.241.1.9 - 255.255.255.252
Taib-Mhiri 10.241.1.10 10.241.1.13 255.255.255.252
ASR1 Asr-Ariana-1 10.9.41.1 10.241.1.1 10.241.2.1 255.255.255.252
ASR2 Asr-Ariana-2 10.9.41.2 10.241.1.14 10.241.2.14 255.255.255.252
Ring 2 Gazela 10.241.2.2 10.241.2.5 - 255.255.255.252
Enasser 10.241.2.6 10.241.2.9 - 255.255.255.252
Elmanzah 10.241.2.10 10.241.2.13 - 255.255.255.252

Chaque équipement possède une adresse logique (Loopback) qui est une interface
virtuelle. L'avantage d'une interface Loopback est qu'elle est toujours active tant qu’au moins
une interface physique l'est aussi. Elle est considérée comme l'interface la plus stable du nœud
IP. Le plan d’adresse des adresses logiques est 10.141.X.Z tel que X est le numéro de Ring et
Z est le numéro de l’équipement. Ci-dessous les adresses logiques de tous les équipements de
la région.

71
Chapitre 5 : Réalisation

Tableau 15: les adresses logiques


Equipement Address Loopback
Ring 1
Sokra 10.141.1.1
Aouina 10.141.1.2
Sidi-Thabet 10.141.1.3
ASR
Asr-Ariana-1 10.1.241.81
Asr-Ariana-2 10.1.241.82
Ring 2
Gazela 10.141.2.1
Enasser 10.141.2.2
Elmanzah 10.141.2.3

II.2 Configuration des interfaces


En premier lieu nous allons commencer par créer une interface Loopback Lo0 à
chaque routeur. Pour créer cette interface on passe en mode configuration globale par la
commande conf t. Les commandes suivantes décrivent la procédure de configuration des
interfaces dans le routeur d'Enasser:

Enasser (config) #interface loopback


Enasser (config-if) # ip address 10.141.2.2 255.255.255.255.255
Enasser (config-if) # no shut

Puis, nous avons configuré les interfaces reliées avec les routeurs:

Enasser(config)# interface GigabitEthernet1/0


Enasser (config-if)# ip address 10.241.2.6 255.255.255.252
Enasser (config-if)# no shut
Enasser (config-if)# exit
Enasser(config)# interface GigabitEthernet2/0
Enasser (config-if)# ip address 10.241.2.9 255.255.255.252
Enasser (config-if)# no shut
Enasser (config-if)# exit

II.3 Configuration des protocoles de routage OSPF

Au niveau du réseau Métro Ethernet, le protocole de routage utilisé est l'OSPF, Le


choix du protocole OSPF est justifié principalement par les raisons suivantes:

72
Chapitre 5 : Réalisation
 Rapidité de convergence de ce protocole
 Réduction de la taille des tables de routage par segmentation en des
zones(Area).

La configuration d’OSPF inclue les étapes suivantes :


 Activation du processus OSPF
 Déclaration des réseaux qui appartiennent au processus déclaré
 Désignation de la zone d’administrative

L’exemple suivant décrit la procédure de configuration du protocole OSPF dans le


routeur Enasser. La même procédure est appliquée pour les autres routeurs de l'architecture
(Voir annexe A).
Enasser (config)#router ospf 1
Enasser config-router)# network 10.141.2.2 0.0.0.0 area 0
Enasser (config-router)# network 10.241.2.4 0.0.0.3 area 0
Enasser (config-router)# network 10.241.2.8 0.0.0.3 area 0

II.4 Configuration du MPLS


Jusqu’à présent, on a fait les configurations nécessaires et on s'est assuré que le réseau
de l’opérateur est bien interconnecté. Nous allons passer à l’étape suivante qui consiste à
activer l’utilisation du protocole MPLS dans les routeurs. MPLS, est une solution idéale pour
faciliter le routage des paquets IP en allégeant le charge du routeur par la commutation de
label ce qui garanti un traitement rapide. Mais, avant de configurer MPLS, il indispensable
d’activer le CEF. L’exemple suivant décrit les étapes de configuration du MPLS au niveau du
routeur Enasser.
Enasser (config )#mpls ip
Enasser (config )#ip cef
Enasser (config )mpls label protocol ldp
Enasser (config )int gi1/0
Enasser (config-if )mpls ip
Enasser (config-if )mpls label protocol ldp
Enasser (config-if )exit
Enasser (config )int gi2/0
Enasser (config-if ))mpls ip
Enasser (config-if )mpls label protocol ldp
Enasser (config-if )exit

II.5 Test et vérification

Pour vérifier le fonctionnement de notre architecture ME, il est impératif de faire des
tests afin de s’assurer du fonctionnement du réseau.

73
Chapitre 5 : Réalisation
II.5.1 Vérification de routage OSPF

On vérifie les routes données par le routage OSPF par la commande : show ip route
ospf 1 :

Figure 51: Résultat de la commande show ip ospf

II.5.2 Vérification MPLS

Pour vérifier l’activation de MPLS et consulter la liste des voisins d’un routeur, on
utilise la commande: show mpls ldp neighbors :

Figure 52: Résultat de voisin MPLS

En plus, on peut visualiser les routes existantes sous MPLS par la commande: show
mpls forwarding-table :

74
Chapitre 5 : Réalisation

Figure 53: Résultat MPLS pour les réseaux connectés

II.5.3 Test de connectivité

Pour tester le fonctionnement de notre maquette, nous avons lancé la commande Ping
entre le nœud d'Enasser et le nœud Aouina.(Voire figure 54).

Figure 54: Ping entre le nœud d’Enasser et Aouina

Le résultat de la commande ping montre bien que les deux sites sont bien
interconnectés.

75
Chapitre 5 : Réalisation

III. Mise en place d’une solution de supervision


Lors de l’installation du réseau, il faut suivre ses performances. Dans cette partie, nous
allons superviser la zone d’Ariana en utilisant l’outil de supervision EyesOfNetwork auquel
on ajoutera les fonctionnalités supplémentaires dont on a besoin.

III.1 Mise en place de l'outil EyesOfNetwork

EyesOfNetwork « EON » est une solution de supervision qui inclut un ensemble


intégré d’applications répondant à divers besoins (Nagios, Cacti, Nagvis, Weathermap).

Nous avons choisi d'utiliser la version 4.2 d’EyesOfNetwork qui est jusqu'à
maintenant la plus stable. EON est installée manuellement sur une machine virtuelle. A
l'installation il est recommandé d'utiliser une adresse IP fixe. (Les étapes d’installation
d’EyesOfNetwork sont illustrées dans l’annexe B).

Pour accéder à l’interface d’EyesOfNetwork, il suffit d’ouvrir un navigateur web et


écrire dans la barre de navigation « http://Addresse du serveur». Une page d’authentification
s’affiche demandant le nom de l’utilisateur ainsi que le mot de passe comme l’indique la
figure 55.

Figure 55: Interface d'authentification d'EyesOfNetwork

Une fois les données sont valides, l’utilisateur accède au menu. Dans cette interface
l’utilisateur peut gérer toutes les fonctionnalités de la plateforme de supervision. (Voire figure
56)

76
Chapitre 5 : Réalisation

Figure 56: interface graphique d’EyesOfNetwork

III.2 Connexion entre EyesOfNetwork et L'architecture ME


L’interconnexion entre EyesOfNetwork et l’architecture ME est décrite dans la
figure 57. Nous avons attribué l’adresse 192.168.112.129 à la carte réseau virtuelle du
Vmware. Celle-ci est accessible depuis notre ordinateur et depuis les routeurs sous GNS3 via
un Claud crée et connecté à un routeur d’extrémité (dans notre cas, c’est le routeur Enasser) .

Figure 57: Connexion entre routeur Enasser et Cloud d'EyesOfNetwork

Maintenant, on doit déclarer l'adresse ip du routeur Enasser comme étant un Gateway


dans l'interface CentOS de EyesOfNetwork afin d'interconnecter le deux sites on utilisant
cette commande :

#route add default gw 192.168.112.2 eth0

En tapant la commande route -n, on remarque que le Gateway est ajouté :

77
Chapitre 5 : Réalisation
Pour tester le fonctionnement, nous avons lancé la commande Ping entre
EyesOfNetwork et le routeur d'Enasser. Le résultat de la commande montre bien que deux
sites sont bien interconnectés:

Par la suite, on doit assurer la connexion entre EyesOfNetwork et le reste des


équipements du réseau ME, ce pour cela nous allons créer un route OSPF entre le routeur
d'Enasser et le Cloud de EyesOfNetwork :

Enasser (config)#router ospf 1


Enasser (config-router)# network 192.168.112.0 0.0.0.255 area 0

Pour voir les réseaux auquel le routeur Aouina, par exemple, peut accéder on utilise la
commande : show ip route:

Figure 58: Résultat de commande show ip route

 Notre architecture ME arrive à communiquer avec la machine virtuelle qui supporte


EyesOfNetwork. Le Ping est réussi entre les équipements de l'architecture et EyesOfNetwork.

78
Chapitre 5 : Réalisation
III.3 Configuration SNMP

L'outil de supervision EyesOfNetwork se base sur le protocole SNMP d’où il faut


l’activer sur les équipements de l'architecture ME qui représentent dans notre cas l'agent
SNMP connecté avec le manager SNMP(EyesOfNetwork).

Figure 59: Topologie de supervision

III.3.1 Configuration des agents SNMP

Cette partie décrit la configuration des agents pour activer l’accès vers l’outil de
supervision via le protocole SNMP. L'accès aux informations de la table MIB est contrôlé par
l’utilisation d'un nom de communauté. Ce dernier doit être configuré dans le manager et
l’agent pour assurer la communication entre ces deux éléments. La configuration SNMP se
fait par les commandes suivantes :

Figure 60: Configuration SNMP

III.3.2 Configuration des paramètres SNMP dans EyesOfNetwork

Pour que le manager SNMP soit capable de répondre aux requêtes SNMP, nous
devons assurer la configuration du protocole SNMP dans l’outil EyesOfNetwork. (Les
paramétrages de protocole SNMP dans EyesOfNetwork sont motionné dans l’annexe B).

La figure 61, montre l'ajoute du paramètre SNMP dans EyesOfNetwork

79
Chapitre 5 : Réalisation

Figure 61: configuration SNMP dans EyesOfNetwork

III.4 Configuration d'EyesOf Network

EyesOfNetwork intègre plusieurs outils de supervisons (Nagios, Cacti, NagVis,


Weathermap) qu’on va configurer.

III.4.1 Configuration de Nagios

Nagios est un système surveillance qui permet de superviser des services et des
équipements réseaux.

III.4.1.1 Ajouter un hôte


Pour que Nagios supervise les routeurs de la région Ariana. Nous commençons
d’abord par ajouter ces derniers, en suivant les étapes illustrées dans la figures 62 .

Figure 62:Ajout d’Equipement

Voici la page correspond à l'ajout d'un routeur :

80
Chapitre 5 : Réalisation

Figure 63:Paramétrage pour superviser un hôte

Une fois les champs remplis, on clique sur « Add host », la fenêtre suivante apparaît :

Figure 64: Paramétrage du l’Inheritance de l’hôte

Dans cette fenêtre, on clique sur « Inheritance » pour choisir un template à associer à
l’hôte, par exemple : printer, Windows, linux, Cisco, etc. Notre équipement est un routeur
Cisco donc on a lui associé le Template Cisco.

On clique ensuite sur «Tools» puis sur «Exporter»:

Figure 65:Exporter les données vers Nagios

81
Chapitre 5 : Réalisation
Et enfin sur «Restart» pour pouvoir charger la configuration dans Nagios:

Figure 66: Redémarrage de Nagios

III.4.1.2 Ajouter un nouveau service

Le Template Cisco qu'on a associé à notre routeur fourni les services suivants:

 Processeur
 Mémoire

Afin de fournir une supervision détaillée sur l'état de notre maquette, nous allons
ajouter un nouveau service pour vérifier l'état des interfaces : selon le nombre des interfaces
du routeur, chaque interface doit compter un service pour vérifier si cette interface est
démarrée ou éteinte. Ceci permet d'aider les superviseurs à détecter et interpréter en un simple
coup d’œil les causes et les origines des problèmes rencontrés, au lieu de vérifier
manuellement en tapant les commandes adéquates sur « Putty» via Telnet ou SSH. Pour le
faire on se connecte à EyesOfNetwork via WinSCP.

Figure 67:Connexion à WinSCP

82
Chapitre 5 : Réalisation
Puis dans le répertoire /srv/eyesofnetwork/nagios-3.5.1/etc/objects, nous trouvons les
fichiers de configuration des services (services.cfg) et commandes (commands.cfg), ces
fichiers sont ceux que nous allons modifier pour ajouter le service de vérification des
interfaces.

Figure 68: Répertoire de configuration de Nagios

Le fichier commande.cfg contient plusieurs commandes qui sont liées à des plugins
compatibles avec nos routeurs (Cisco 7200). Pour ajouter le service de vérification des
interfaces, nous avons téléchargé le plugin «check_snmp_int.pl» depuis:
http://exchange.nagios.org. Ensuite, nous allons l'ajouter aux autres plugins de Nagios via
WinSCP sous le répertoire : /srv/eyesofnetwork/nagios-3.5.1/plugins puis leur donner les
droits nécessaires (0775). Enfin, l’ajout de la commande relative au service désiré se fait
comme suite:

Figure 69:l'ajout d'un commande

Maintenant, on accède au fichier service.cfg pour ajouter le service.

83
Chapitre 5 : Réalisation

Figure 70: Ajout de service

La figure 71, montre les services ajoutés sur la plateforme d'EyesOfNetwork :

Figure 71: Les service ajoutés

III.4.2 Supervision avec Nagios

La supervision avec Nagios permet à la fois de garder un œil sur l'état du réseau,
anticiper les pannes et faciliter l’intervention en cas de panne. Donc, après avoir configuré les
équipements et ajouté le nouveau service, nous devons maintenant fournir une supervision
détaillé sur l'état du notre réseau.

 Vérification de la disponibilité des équipements

Pour consulter l’état de chaque routeur ajouté, nous allons sous l’interface graphique
d’EyesOfNetwork > Disponibilité > Vue équipements :

84
Chapitre 5 : Réalisation

Figure 72: Consultation des états des routeurs

Un routeur peut avoir les états suivants :


Up : en fonctionnement.
Down : éteint.
Unreachable : inaccessible.
 Supervision des services

Pour superviser les services, nous allons cliquer sur Disponibilité > vue services :

Figure 73: Etat des services

85
Chapitre 5 : Réalisation
 Détection des anomalies

Pour pouvoir détecter et interpréter les problèmes rencontrés afin de les fixer le
plus rapidement possible, on clique sur disponibilité, ensuite Vue Global >problème

Figure 74: Consultation des problèmes

 Génération des rapports


La génération des rapports permet au superviseur de visualiser la disponibilité de
chaque équipement sur une période de temps bien déterminée.
Le rapport de disponibilité peut être fournir sous forme générique pour une
visualisation plus claire. Le rapport de disponibilité et le rapport générique sont
donnés dans les figures 75 et 76.

Figure 75:Rapport générique

86
Chapitre 5 : Réalisation

Figure 76: Rapport de disponibilité

III.4.3 Configuration NagVis

NagVis [14] fournit une interface pour consulter l'état des équipements et des services
sur une carte. Il est utilisé pour apporter des fonctions de visualisations graphiques à Nagios
par la création des cartes de topologie de réseau depuis l'interface web d'EyesOfNetwork.
Ainsi par une simple consultation de la carte, nous pouvons savoir quels routeurs ou quels
services comprend un problème qui sera notifié par une alerte sonore et le déplacement du
curseur sur ce point.

Sur une carte que nous avons dessinée via Microsoft Office Visio, nous avons mis tous
les équipements de la région « Ariana » (Les étapes pour visualiser l’état des routeurs sous
NagVis sont détaillés dans l’annexe B). La figure 77 présente les différents routeurs de notre
architecture ainsi que leurs états correspondants. En effet, on peut consulter l’état de chaque
nœud en plaçant le curseur de la souris dessous.

87
Chapitre 5 : Réalisation

Figure 77: Supervision sous NagVis

III.4.4 Configuration de Cacti

Cacti permet de représenter graphiquement divers informations sur les périphériques


tels que : utilisation de bandes passantes, la charge CPU, le débit des interfaces réseau et la
qualité d'une liaison.

Maintenant, avant de passer à l’interface de Cacti, il faudrait avant transférer les


données liées à notre équipements sur Nagios vers Cacti, en cliquant sur l'onglet
« Synchronisation Cacti » à gauche sous le menu « Nagios », puis nous sélectionnons les
routeurs à transférer, enfin on clique sur Import.

Figure 78: Synchronisation de Cacti

Une fois la synchronisation terminée, nous accédons à Cacti. Pour voir les
équipements nous allons sur Devices:

88
Chapitre 5 : Réalisation

Figure 79: les routeurs sous Cacti

Après l'ajout de l'équipement, Cacti, à travers le protocol SNMP, permet de lister


toutes les interfaces des routeurs avec leurs adresses IP, vitesse, état, etc.

Nous sélectionnerons les interfaces qu'on souhaite superviser dans la figure suivante :

Figure 80: Choix des interfaces à superviser

Une fois qu’on a sélectionné les interfaces, on clique sur «Create ghraphe for this
host». Maintenant pour consulter les graphes, nous allons sous «Graphe Mangement» puis
choisir un graphe. Par exemple, afin d’avoir du trafic dans l'interface 1/0 du routeur Enasser,
nous avons fait 10000 ping sur ce routeur vers le routeur Gazela avec la commande ping
10.141.2.1 repeat 10000 timeout 1

La courbe du trafic est ainsi visualisée. L'échelle des mesures effectuées est 5 minutes
(pooling par défaut). Le trafic entrant est marqué en vert alors que le trafic sortant est marqué
en bleu.

89
Chapitre 5 : Réalisation

Figure 81: Le trafic Inbound/Outbound par interface

La figure suivante, correspond au pourcentage utilisé du process du nœud Enasser

Figure 82: Utilisation de process du routeur Enasser

III.4.5 Configuration de Weathermap

Weathermap [27] est un outil qui génère des maps graphiques pour mesurer les bandes
passantes des liens réseaux. Les maps vont nous montrer s’il existe une grande utilisation sur
notre réseau. Weathermap est disponible sous Cacti, pour le configurer on doit:

 Modifier la valeur de la bande passante à 50K pour voir le trafic qui est
généralement générer par des ping.
 Ajouter un équipement avec Add Node puis on le nomme et on lui attribue
une icône de routeur.
 Ajouter un lien avec Add Link par la suite on affecte le lien à une des
interfaces présente sous Cacti.

Après avoir configuré tous les équipements et les liens de la carte, il ne nous reste qu’à
attendre 5 minutes pour voir les résultats d’utilisation de la bande passante. Les différents
étapes de mise en place d’une carte sous Weathermap sont illustrées dans l’annexe B.
La figure suivante présente l’utilisation de la bande passante de notre réseau.

90
Chapitre 5 : Réalisation

Figure 83: Supervision de l'utilisation de la bande passante sous Weathermap

IV. Localisation et supervision du Métro Ethernet d’Ariana sous


Android
Parmi les objectifs fixés au début de notre projet, est de garantir la mobilité des
superviseurs du réseau. Ainsi, il est possible de superviser et de localiser les divers
équipements du réseau via des Smartphones.

Dans cette partie nous allons présenter les différentes interfaces de l’application
mobile développée en détaillant le principe de la localisation.

IV.1 Localisation de boucle Metro-Ethernet


IV.1.1 L‘outil de géolocalisation sous Android : Google Maps
Google Maps[28] est un service gratuit de cartographie en ligne créé par Google. Ce
service permet, à partir de l'échelle d'un pays, de pouvoir zoomer jusqu'à l'échelle d'une rue.

Pour ajouter la carte Google Maps à notre application et bénéficier des données
associées, il nous faut une clé API (Google Maps API Key V2). Celle-ci permet de localiser
tout type de données sur une carte (routière, satellite, mixte) à partir de ses coordonnées GPS.

IV.2 MySQL et PHP avec Google Maps


La base de données MySQL stocke les informations sur les points géographiques des
marqueurs, telles que son nom, son adresse et ses coordonnées géographiques. Lorsque notre
application Android s'exécute, elle se connecte au serveur web qui va récupérer les données
depuis la base de données MySQL en utilisant les services web. Ensuite les données seront
encodées au format JSON et envoyées au système Android. L'application va obtenir ces
données codées. Elle les analysera et les affichera sur la carte géographique de Google Maps.

91
Chapitre 5 : Réalisation
IV.3 Description des interfaces de l’application
Notre application offre plusieurs fonctionnalités que nous détaillerons dans ce qui suit.

IV.3.1 Authentification
Pour accéder à notre application, l'utilisateur doit s’authentifier afin d’assurer la
sécurité d’accès. On dispose de deux interfaces de supervision ; l’une pour l’administrateur et
l’autre pour les superviseurs. Ces interfaces sont présentées dans les figures 84 et 85.

Figure 84: Interface de chargement ouverture


application Figure 85: Interface d'authentification

Un message d’erreur sera affiché dans le cas où les informations d’authentification


n’existent pas dans la base de données.

Figure 86: Interface d'authentification en cas d'erreur

92
Chapitre 5 : Réalisation
Lors de l’authentification, l’utilisateur accède à l’espace administrateur (s’il s’agit d’un
administrateur) ou à l’espace superviseur (s’il s’agit d’un superviseur ordinaire).

IV.3.2 Espace administrateur


Après l'authentification, on accède directement à la page d'accueil qui affiche un
message de bienvenue à l’administrateur. Ce dernier choisi une action parmi les
fonctionnalités suivantes :

 Gérer les superviseurs


 Gérer l'espace de supervision
 Gérer l'espace de localisation
La figure ci-dessous décrit les différentes fonctionnalités dans l'espace de l'administrateur :

Accueil

Gestion des superviseurs Gestion de supervision Gestion de localisation


Figure 87: Présentation générale des interfaces de l'administrateur

93
Chapitre 5 : Réalisation
a. Interface de gestion de superviseur
Si l’administrateur choisi d’effectuer une «Gestion des superviseurs», alors le système
lui affiche l‘interface relative à la gestion de superviseurs où il peut :

 Ajouter un superviseur
 consulter la liste des superviseurs
Lorsque l’administrateur veut ajouter un superviseur, il doit remplir tous les champs
relatifs au superviseur et valider en cliquant sur l'ongle «Ajouter superviseur». Un exemple
est illustré dans la figure 88.

Figure 88:Interface d'ajout d'un superviseur Figure 89: Liste des superviseurs

Lors de l’ajout d’un ou plusieurs superviseurs, l’administrateur peut consulter la liste


totale des superviseurs. Un exemple est donné dans la figure 89. L’administrateur peut aussi
sélectionner un superviseur afin de modifier ses coordonnées ou le supprimer comme illustré
figure 90.

94
Chapitre 5 : Réalisation

Figure 90: Les Interfaces de modification et de suppression d’un superviseur

b. Interface de supervision de l'administrateur

L'onglet «Gestion de supervision» affiche l'espace de supervision de l'administrateur.


Cette interface permet de gérer toutes les fonctionnalités de la supervision. L’accès se fait par
le biais d’un service web permettant d'accéder à la plateforme de supervision EyesOfNetwork.
L’administrateur choisit une action parmi les différentes fonctionnalités présentées dans la
figure 91.

95
Chapitre 5 : Réalisation

Consulter Weathermap

Gérer les équipements

Vérifier la disponibilité

Consulter les indicateurs de Consulter les anomalies


Consulter les services performance

Figure 91: Les différentes fonctionnalités de supervision de l'administrateur

96
Chapitre 5 : Réalisation
Durant la phase de supervision, il est possible de générer des rapports sur le
fonctionnement d’un équipement pendant un intervalle de temps choisit. Les étapes
de génération d’un rapport sont mentionnées dans la figure 92.

Figure 92: les étapes de génération d’un rapport

c. Interface de localisation de l'administrateur

L'onglet «Gestion de localisation» affiche l'espace de localisation de l'administrateur.

Figure 93: L'espace de localisation de l'administrateur

97
Chapitre 5 : Réalisation
Il permet ainsi, d'afficher et de localiser la position des différents routeurs de la région
étudiée (dans notre cas, la région d’Ariana) sur la Google Map de l'application.
L'administrateur peut ainsi:

 Changer le type de Map:

Figure 94: Changement du type de map

 Chercher l'emplacement d’un routeur :


Dans la barre de recherche, l'administrateur écrit le nom de la région à
superviser, par la suite le système affiche un marker indiquant l'emplacement de la
routeur à localiser.

Figure 95: Recherche d'un routeur dans la région

98
Chapitre 5 : Réalisation
 Gérer les routeurs dans la région :
L'administrateur est responsable de gérer la région à superviser. Il peut alors :
- Ajouter un routeur dans la région.
- Modifier un routeur dans la région.
- Supprimer un routeur dans la région.

La figure 96 présente les interfaces nécessaires à l’administrateur pour gérer les routeurs:

Ajouter un routeur dans la région Afficher la liste des routeurs Modifier un routeur

Figure 96: Les interfaces de gestion des routeurs dans la région

 Consulter l’état d’un routeur dans une région :


L'objectif de la partie localisation est de permettre à l’équipe technique
d’intervention de localiser facilement et avec précision n’importe quel routeur
dans la région supervisée. Donc avec une simple clique sur le marqueur, Le
superviseur ou l’administrateur peut consulter le disponibilité de chaque
équipement dans la région.

99
Chapitre 5 : Réalisation

Figure 97: Consultation d'état d'un nœud dans la région

IV.3.3 Espace superviseur

Depuis l'espace superviseur, le superviseur choisit une action parmi les différentes
fonctionnalités mentionnées dans la figure 98.

Accueil

Espace de localisation
Espace de supervision du superviseur
du superviseur
Figure 98: Présentation des interfaces du superviseur

100
Chapitre 5 : Réalisation
a. Interface de supervision du superviseur

L’interface de supervision relative au superviseur est présentée par la figure 99. Elle
fournit aux superviseurs les indicateurs nécessaires pour une supervision simple et en temps
réel. Il peut:
 Visualiser les indicateurs de performance
 Vérifier la disponibilité des routeurs.
 Vérifier l’état des services des routeurs.
 Consulter le Weathermap.
 Détecter les anomalies.
 Générer des rapports

Figure 99: Interface de supervision de superviseur

b. Interface de Localisation de superviseur

En plus de la localisation et la visualisation de l'état du routeur, cette interface permet


au superviseur de consulter les coordonnées GPS d’un routeur si on clique sur l’onglet info.
(Voire figure 100)

101
Chapitre 5 : Réalisation

Ajouter un routeur dans la région Afficher la liste des routeurs Consulter les coordonnées GPS

Figure 100: Consultation des coordonnées GPS d’un routeur

Conclusion
Dans ce chapitre nous avons utilisé l’outil de supervision EyesOfNetwork pour
supervisé la région d’Ariana qui à été simulée sous GNS3.
L’outil EyesOfNetwork met à notre disposition plusieurs outils de supervision ce qui offre
une variété d’indicateurs et une supervision plus facile. Par ailleurs, nous avons ajoutés les
fonctionnalités manquantes dont on a besoin puisque EyesOfNetwork est un logiciel open
source. Ces outils sont :
 Nagios pour vérifier l’état des équipements.
 NagVis pour présenter les résultats de Nagios sous une carte.
 Cacti pour faire des courbes sur l’utilisation du processeur ainsi que du trafic
entrant et sortant sur les interfaces.
 Weathermap pour consulter en temps réel l’utilisation de la bande passante
sur toute la région.

102
Conclusion générale

Conclusion générale

L’objectif de notre projet est de proposer une solution de supervision la plus riche pour
faciliter la tâche de supervision, de localisation et d’intervention des superviseurs en cas de
panne. Une première version a été développée pour un usage bureautique. Cette version a été
enrichie par une application mobile pour assurer le suivi même si le superviseur est en
déplacement.

A l’issue de la réalisation de cet objectif, nous pouvons affirmer que notre projet nous
a été d’une grande utilité dans la mesure où il nous a permis de nous familiariser avec le
travail sur des nouvelles plateformes à savoir la plateforme de supervision EyesOfNetwork et
la plateforme Android. Nous avons pu travailler sur un outil de simulation de réseau(GNS 3)
qui possède de nombreuses fonctionnalités, cela a également permis de comprendre les étapes
de la mise en place d'une architecture réseau passant par les phases de configuration, de
connexion jusqu'à son aboutissement. Il nous a également permis de découvrir comment se
passe l’intégration d’une application sur un serveur web distant ainsi que l’utilisation du
langage JSON pour gérer la communication des données entre deux environnements
hétérogènes qui sont le client Android et le serveur de base de données.

Cette thématique a été abordée en commençant par une étude théorique de la


technologie Métro Ethernet. Nous avons commencé par présenter les concepts de base du
réseau Métro Ethernet à savoir son architecture, ses services et les équipements utilisés pour
sa mise en place. Par la suite, nous avons traité le concept de supervision des réseaux. Ceci
exige des solutions qui peuvent automatiquement détecter les problèmes de performance en
temps réel. Dans cet objectif et en se basant sur une étude comparative des solutions
disponibles sur le marché, nous avons choisi la solution de supervision EyesOfNetwork
assurant ainsi la surveillance des équipements Métro Ethernet dans le réseau de l’opérateur.

Au niveau de la réalisation, nous avons commencé par définir l'environnement de


travail. Ensuite, nous avons configuré une maquette du réseau Métro Ethernet. Puis, nous
avons supervisé la région Ariana qui à été simulée sous GNS3 avec différents outils
d'EyesOfNetwork : Nagios pour vérifier l’état des équipements, Nagvis pour présenter les
résultats de Nagios sous une carte, Cacti pour faire des courbes sur l’utilisation de la mémoire
ou du processeur ainsi que du trafic entrant et sortant sur les interfaces et Weathermap pour
consulter en temps réel l’utilisation de la bande passante sur toute la région.

103
Conclusion générale
Nous avons aussi ajouté d’autres fonctionnalités manquantes pour rendre la
supervision plus claire et plus conviviale. Dans une dernière partie, nous avons réalisé une
application mobile assurant une mobilité pour les différents usagers afin de superviser et
localiser les boucles Métro Ethernet via un Smartphone.

Tout au long de l’élaboration du projet, nous avons rencontré plusieurs difficultés tant
au niveau conceptuel qu’au niveau de la réalisation. Tout de même, nous avons réussi à les
surpasser pour présenter en fin de compte une application opérationnelle, cependant, quelques
améliorations restent envisageables selon les besoins futurs de l’entreprise. En effet l'accès à
la plateforme de supervision via un Smartphone nécessite qu'ils soient tous le deux dans le
même réseau Wifi de l'entreprise puisque la plateforme de la supervision n'est pas visible
depuis l'extérieure. En perspective, pour assurer l'accès distant, via n'importe quel réseau, à la
plateforme de supervision, une solution est de lui attribuer une adresse IP public. Cependant,
il faudra mettre en œuvre des outils de sécurité pour éviter les attaques au réseau de
l'entreprise.

104
Bibliographique

Bibliographie

[1] Tunisie Telecom, https://www.tunisietelecom.tn/Fr/A-Propos/Entreprise, consulter en


Février 2017.

[2] Document de référence de Tunisie Télécom.

[3] Processus RUP, http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/, consulter en


Février 2017.

[4] Sam Halabi, Metro Ethernet,Cisco Press, 2003.

[5] Abdul Kasim, Delivering Carrier Ethernet: Extending Ethernet Beyond the LAN, Mcgraw
Hill, 2007.

[6] Imen Abel Wahed, projet de fin d’étude diplôme national d’ingénieure «Etude et
migration de réseau de transport Tunisie Telecom vers Métro Ethernet et mise en place d’une
solution de supervision», page 10.

[7] Cisco, Cisco ASR 9000 Series Aggregation Services Routers Data Sheet.

[8] Routeur ME-3800, http://www.cisco.com/c/en/us/products/collateral/switches/me-3800x-


series-carrier-ethernet-switch-routers/data_sheet_c78-601950.html.

[9] Fibre optique, http://www.nerim.fr/faq/ultra-haut-debit, Consulter en Mars2017.

[10] Rapport de stage de fin d’étude, réalisé par Mazen Essmari «Mise à niveau des réseaux
de transmission», page 18.

[11] Thomas D.Nadeau, « MPLS Network Mangement : MIB, Tools, and Technique »
Elsevier Science, 2003.

[12] Rick Gallahers, « Building Multi protocole Label Switching », Syngress,2004.

[13]Jim Guichard, Ivan Pepelnjak,Jeff Apca, "MPLS and VPN" architecture, Volume2",
Cisco Press, 2003.

[14] Rapport de stage de fin d'étude: Mohsine Merzouk: Mise en place d'une solution de
supervision basée sur EyesOfNetwork, 2012-2013 page12.

[15] David NOUCHI ,http://d.nouchi.free.fr/SNMP/SNMP.htm ,consulté en Mars.

[16] Outil de supervision Zabbix, https://wiki.monitoring-fr.org/zabbix/start.

[17] Outil de supervision Cacti, http://www.o00o.org/monitoring/solutions.html.

[18] Rapport de projet de fin d’étude , Mise en place d’un système de supervision Open
source, Elaboré par Othman Souli.

105
Bibliographique
[19] Outil de supervision EyesOfNetwork, https://memo-linux.com/eyes-of-network-solution-
complete-de-supervision/ consulter en Février 2017.

[20] GNS3, https://www.gns3.com/, consulté en Février 2017.

[21] WinSCP, http://www.01net.com/telecharger/windows/Internet/ftp/fiches/31668.html,


consulté en Mars 2017.

[22] WamServer, www.wamserver.com, consulté en Mars 2017.

[23] MySql, http://www.prologue-solutions.tn/technologies/65-mysql.html, consulté en Mars


2017.

[24] Android studio, https://fr.wikipedia.org/wiki/Android_Studio, consulté en Mars 2017.

[25] http://glossaire.infowebmaster.fr/php/, Consulter en Mars 2017.

[26] http://www.json.org/json-fr.html, Consulter en Mars 2017.

[27] Rapport de stage de fin d’étude «Mise en place d’un réseau Metro Ethernet pour la prise
en charge de nouveaux services haut débit de Tunisie Télécom», page 54.

[28] Google map, http://www.memoireonline.com/03/12/5548/Rapport-de-stage-sur-le-projet-


Locate-my-car-google-map-android.html.

106
Annexes

Annexes

Annexe A : Mise en place de l'architecture Métro Ethernet


Dans cette annexe nous allons mettre la configuration des routeurs que nous avons mis en
place:

 Routeur Gazela

 Routeur Elmanzah
Annexes
 Routeur ASR-Ariana-1

 Routeur ASR-Ariana-2
Annexes
 Routeur Sokra

 Routeur Aouina
Annexes

Annexe B : Mise en place d'EyesOfNetwork

1. Installation de EyesOfNetwork

1.1 Pré-requis

Avant l'installation, il faut tout d'abord télécharger l'image ISO DVD de EON, disponible à
l'adresse suivante pour:

La version 64 bit : http://download.eyesofnetwork.com/EyesOfNetwork-4.2.0-x86_64-bin.iso

1.2 Installation

 Création d'une nouvelle machine virtuelle

Afin d'installer EyesOfNetwork, nous avons créé une machine virtuel sous VMware.
Avec les configuration suivantes:

 Mémoire vive : 2 GB
 Disque dure 40 GB
 Adaptateur réseaux : Vmnet 18

La figure suivante montre les paramètres des configurations :

Par la suite, nous allons appuyer sur entrée sur l'écran de boot, puis nous allons choisir la
langage et le type de clavier et enfin, l'interface d'installation démarrer

 Sélection du media de stockage :


Annexes

 Paramétrage réseau
Ici dans l'onglet Modifier: on choisit notre paramétrage IP(Il est recommandé
d'utiliser une adresse IP fixe dans notre l'adresse est 192.168.112.129):

On note, il sera toujours possible de le configurer après l'installation avec la


commande:

 Configuration de mot de passe

Après cette étape, nous avons choisi notre mot de passe root de serveur :
Annexes
 Installation des paquets

Nous allons choisir les paquets à installer qui sont rangés en deux catégorie :

 La catégorie supervision:

Base : installe le serveur EON

Option : contient les agents les plus utilisés par la communauté

 La catégorie production :

Gestion des incidents : installe GLPI

Inventaire : inventaire de arc et déploiement de logiciel à distance

Une fois les paquets choisis, EON s’installe pour une durée approximative de 20 minutes.

Et enfin, à la fin de l’installation nous arrivons sur la page de démarrage du serveur


EON qui nous renseigne l'adresse IP de notre serveur pour pouvoir le joindre à l’aide d’un
navigateur web.
Annexes

 Connexion au serveur

Lancer un navigateur web comme Mozilla Firefox et rentrer l’adresse IP du serveur dans la
barre d’adresse. Une page d’authentification s’affiche demandant le nom de l’utilisateur ainsi
que le mot de passe. Par défaut, l'identifiant et le mot de passe de connexion sont : admin

2. Configuration des paramètres SNMP

SNMP sous EyesOfNetwork


« EON » supervise les hôtes dont le nom de communauté SNMP est « EyesOfNetwork » :

SNMP sous Windows


Annexes
Afin d'activer le protocol SNMP, nous allons dans le panneau de
configuration>programmes>Activer ou désactiver des fonctionnalités Windows, Cocher
ensuite la case correspondant au Protocole SNMP, puis cliquer sur « ok ».

Par le suite on va renseigne la communauté de notre serveur « EON » , donc dans


Windows, ouvrir le panneau des services. Par la suite, aller dans l’onglet sécurité, ici où on va
renseigner la communauté que possède notre serveur de supervision et lui accorder les droits
en lecture et écriture. Nous allons aussi renseigner l’IP de notre serveur de supervision, ici
192.168.112.129

3. Configuration EyesOfNetwork
3.1 Configuration NagVis

Avant de configurer NagVis il faut Paramétrer notre serveur EON avec tous les actifs
que l’on souhaite voir sur la carte et faire un schéma réseau avec un outil comme Visio ou
une photo de nos équipements et l’enregistrer en png avec un nom sans espace.

Une fois sur la page de NagVis, on peut cliquer sur option puis sur Manage Backgroung pour
insérer notre image réseau.
Annexes

Nous avons donc la fenêtre suivant qui va apparaitre où nous allons choisi l'image
utilisée comme Background, puis on clique sur Upload

Une fois, l'image chargée dans notre serveur, nous allons créer la carte on clique sur
Option puis Manage Map

La fenêtre suivant apparait:


Annexes
Une fois la carte créé, nous pouvons ainsi placer les indicateur d'états sur notre carte.
Sous l'anglet Edit Map on peut choisir Add icon afin d'ajouter par exemple un routeur dans
notre carte ou Add line pour ajouter un service tel que service de vérification des interface

Enfin nous pouvant placer le curseurs de la souris pour voir les informations de
l'élément supervisé

3.2 Configuration Weathermap

Afin de paramétrer Weathermap on doit:

1. Modifier la valeur de la bande passante à 50K pour voir le trafic :


Annexes
2. Ajouter un équipement avec Add Node puis on le nomme et on lui attribue une icône de
routeur :

3. Ajouter un lien avec Add Link par la suite on affecte le lien à une des interfaces présente
sous Cacti:

Après avoir configuré tous les équipements et les liens de la carte, il ne nous reste qu’à
attendre 5 minutes pour voir les résultats d’utilisation de la bande passante:
Annexes

Annexe C : Plateforme Android

1. Prise en main de l’environnement Android


La première étape de notre travail avec l’environnement Android a été d’appréhender le SDK

 SDK Android

L’outil le plus important est le SDK Android. Il permet de télécharger tous les outils
indispensables au développement de notre application mobile. Grâce au gestionnaire de SDK,
nous pouvons également télécharger les différentes versions des Google APIs (APIs pour
intégrer des fonctionnalités liées aux services Google).

 Emulateur

Le SDK propose un émulateur Android. Il permet de lancer sur la machine du


développeur un terminal virtuel représentant à l’écran un téléphone Android. C’est bien
évidemment un outil indispensable pour le développement mobile. A chaque version
d’Android est associée une version de l’émulateur, permettant au développeur de voir
exactement à quoi ressemblera son application sur un matériel réel. Rappelons cependant que
l’émulateur ne propose pas toutes les fonctionnalités d’un vrai téléphone.

 Création d’interfaces sous Android

Sous Android, nous avons créé nos interfaces avec la méthode de fichier XML . En
effet la façon la plus simple de réaliser une interface est d’utiliser la méthode déclarative
XML via la création d’un fichier XML , afin de facilité leur modification en cas de besoin,
que nous placerons dans le dossier /res/layout de notre projet.
Annexes

2. Procédure d’accès à la Carte Google Maps


Avant de pouvoir insérer une carte Google Maps dans l'interface graphique, il faut que
nous obtenions une clé API. Pour obtenir cette clé, nous devons rendre sur Google
Developers Console afin de créer un nouveau projet.

La création d’un nouveau projet est très simple, sur l’écran d’accueil de la console Google
developers, il suffit de cliquer sur le bouton “Créer un projet”

Il nous faut maintenant l' identifiants afin de pouvoir l'utiliser dans notre application

Developper Console va maintenant nous présenter la clé API.


Annexes

Le clé créé, il faut activer l’API qui nous intéresse, ici celui de Google Maps Android API.

Une fois la clé API obtenue, il faut l'ajouter dans le fichier String.xml.
Résumé:
Ce travail a été réalisé dans le cadre d'un projet de fin d'études au sein de la société Tunisie
Télécom. Le projet consiste à proposer une solution de supervision la plus riche pour faciliter
la tâche de supervision, de localisation et d’intervention des superviseurs en cas de panne.
Une première version a été développée pour un usage bureautique. Cette version a été enrichie
par une application mobile pour assurer le suivi même si le superviseur est en déplacement.

Mots clés: Métro Ethernet, MPLS, EyesOfNetwork, Supervision, Localisation, Android,


Google Map

Abstract :
This work is conducted at the Tunisie Telecom company in order to obtain the engineering
degree . This project consists of developing a supervision solution in order to facilitate the
task of supervision, location and intervention in case of breakdown. A first version was
developed for office use. This version has been enriched by a mobile application to ensure
follow-up even if the supervisor is on the move.

Keywords: Metro Ethernet, MPLS, EyesOfNetwork, Supervision, Localization, Android,


Google Map

Vous aimerez peut-être aussi