Etude, Planification Et Gestion Des Réseaux Métro-ethernet (skhiri Ferid) 41c5f

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique ∗∗∗ ∗ ∗∗∗ Université de Carthage ∗∗∗ ∗ ∗∗∗ Institut National des Sciences Appliquées et de Technologie

Projet de Fin d’Etudes Pour l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et en Technologie

Filière : Réseaux Informatiques et Télécommunications

Sujet :

Etude, Planification et Gestion des réseaux Métro-Ethernet

Réalisé par : Ferid SKHIRI

Entreprise d’accueil :

Soutenu le 18/01/12

Responsable entreprise : Mr. Brahim TOUATI Responsable INSAT: Mme. Hedia KOCHKAR

Année Universitaire : 2011/2012

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique ∗∗∗ ∗ ∗∗∗ Université de Carthage ∗∗∗ ∗ ∗∗∗ Institut National des Sciences Appliquées et de Technologie

Projet de Fin d’Etudes Pour l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et en Technologie

Filière : Réseaux Informatiques et Télécommunications

Sujet :

Etude, Planification et Gestion des réseaux Métro-Ethernet Réalisé par : Ferid SKHIRI Entreprise d’accueil :

Soutenu le 18/01/12

Responsable à l’entreprise: Mr Brahim TOUATI

Cachet & Signature

Responsable à l’INSAT: Mme Hedia KOCHKAR

Signature

Année Universitaire : 2011/2012

i

Table des matières Table des Figures............................................................................................................. iv Table des Tableaux .......................................................................................................... v Introduction générale ..................................................................................................... 1 Chapitre I: Présentation Générale ................................................................................ 3 1.

Introduction ................................................................................................................. 4

2.

Présentation de l’organisme d’accueil ........................................................................ 4

3.

Présentation du projet et objectifs généraux ............................................................. 5

4.

Planification du déroulement du projet ...................................................................... 6

Chapitre II : Etat de l’art .................................................................................................. 7 1.

Introduction ................................................................................................................. 8

2.

Les réseaux Métro-Ethernet ....................................................................................... 8

3.

2.1.

Architecture générale........................................................................................... 8

2.2.

Topologie du réseau Métro-Ethernet .................................................................. 9

2.3.

Les composantes du réseau Métro-Ethernet..................................................... 10

2.4.

Le dimensionnement du réseau Métro-Ethernet .............................................. 11

2.5.

La mise en place d’un réseau Métro-Ethernet................................................... 11

2.5.1.

La planification de l’infrastructure.............................................................. 11

2.5.2.

L’étude des réseaux Métro-Ethernet.......................................................... 11

2.5.3.

L’établissement de l’infrastructure............................................................. 12

2.5.4.

La gestion de l’infrastructure ...................................................................... 12

2.5.5.

Les tests et la recette .................................................................................. 12

2.5.6.

Phases d’exploitation et de maintenance .................................................. 12

La gestion des réseaux Métro-Ethernet ................................................................... 17 3.1.

Le modèle de la gestion de réseau..................................................................... 17

3.2.

Architecture de gestion de réseau ..................................................................... 18

3.2.1.

Les Eléments de réseau et les agents ......................................................... 19

3.2.2.

Le Manager ................................................................................................. 19

3.2.3.

Les Protocoles de communication .............................................................. 19

3.2.4.

La structure des données de gestion(MIB) ................................................. 22

3.3.

Les outils de gestion de réseau .......................................................................... 23

3.3.1.

CiscoWorks Network Connectivity Monitor ............................................... 23

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

ii 3.3.2. 4.

Pourquoi un outil de gestion propriétaire .................................................. 24

Conclusion ................................................................................................................. 25

Chapitre III : Analyse et conception ............................................................................ 26 1.

Introduction ............................................................................................................... 27

2.

Méthodologie ............................................................................................................ 27

3.

Spécification des exigences ....................................................................................... 27 3.1.

Exigences fonctionnelles: ................................................................................... 27

3.2.

Exigences non fonctionnelles : ........................................................................... 28

3.3.

Spécification des exigences d’après les cas d’utilisation ................................... 28

3.3.1.

Identification des acteurs ........................................................................... 28

3.3.2.

Affinement du modèle de cas d’utilisation................................................. 31

3.4.

4.

Spécification détaillée des exigences ................................................................. 32

3.4.1.

Spécification détaillée de l’application « SNM Supervision »..................... 32

3.4.2.

Spécification détaillée de l’application « SNM Archivage » ....................... 34

Conception................................................................................................................. 36 4.1.

Identification des concepts du domaine ............................................................ 36

4.2.

Diagrammes de classes participantes ................................................................ 38

4.3.

Diagrammes d’activité........................................................................................ 42

5.

Structure de la base de données ............................................................................... 43

6.

Conclusion ................................................................................................................. 43

Chapitre IV : Réalisation................................................................................................ 44 1.

Introduction ............................................................................................................... 45

2.

Environnement de développement .......................................................................... 45

3.

4.

2.1.

Environnement Matériel .................................................................................... 45

2.2.

Environnement Logiciel ...................................................................................... 45

2.3.

Choix techniques ................................................................................................ 46

2.3.1.

Choix du langage ......................................................................................... 46

2.3.2.

Choix des outils de simulation .................................................................... 46

Environnement de gestion requis ............................................................................. 47 3.1.

Les classes d’équipements ................................................................................. 47

3.2.

La configuration des équipements ..................................................................... 47

Implémentation ......................................................................................................... 50 4.1.

Pratiques adoptées ............................................................................................ 50

4.2.

Déroulement de la phase d’implémentation ..................................................... 50

4.3.

Réalisation du module de supervision ............................................................... 51

4.3.1.

Le sous-module « Réception d’alertes »..................................................... 52

4.3.2.

Le sous-module « Notification par SMS » ................................................... 55

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

iii 4.4. 5.

Réalisation du module d’archivage .................................................................... 55

Conclusion ................................................................................................................. 56

Chapitre V : Mise en Œuvre et Tests ........................................................................... 57 1.

Introduction ............................................................................................................... 58

2.

Mise en œuvre ........................................................................................................... 58 2.1.

2.1.1.

Maintenir Les équipements du réseau ....................................................... 60

2.1.2.

Superviser l’état du réseau ......................................................................... 62

2.1.3.

Gérer les alarmes ........................................................................................ 62

2.1.4.

Gérer les performances .............................................................................. 65

2.2.

3.

4.

Mise en œuvre de l’application « SNM supervision » ....................................... 60

Mise en œuvre de l’application « SNM archivage » .......................................... 65

2.2.1.

L’initialisation de La BD des Liaisons optiques :.......................................... 65

2.2.2.

Rédiger un rapport ...................................................................................... 67

2.2.3.

Générer des statistiques ............................................................................. 67

Tests et validation...................................................................................................... 69 3.1.

Tests fonctionnels de l’application «SNM supervision» ................................... 70

3.2.

Test fonctionnel de l’application «SNM archivage» ......................................... 72

Conclusion ................................................................................................................. 73

Conclusion Générale ...................................................................................................... 74 Bibliographie ................................................................................................................... 76 Netographie ..................................................................................................................... 77 Glossaire ........................................................................................................................... 78 Annexes ............................................................................................................................ 79 Annexe A : Configuration d’agent SNMP sur un Switch Cisco........................................ 80 Annexe B: Présentation du logiciel Optisystem ............................................................. 82

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Table des Figures

Table des Figures Figure 1. Diagramme de planificaCon du projet ................................................................ 6 Figure 2. Le principe de hiérarchisaCon des réseaux d'infrastructure............................... 8 Figure 3. La topologie d'un réseau Métro-Ethernet........................................................... 9 Figure 4. Cartographie du réseau Metro-Ethernet « tunis »............................................. 9 Figure 5. Composantes du réseau Métro-Ethernet ......................................................... 10 Figure 6. Modèle à couches de la gesCon de réseaux ..................................................... 17 Figure 7. Architecture générale du la gesCon du réseau ................................................. 18 Figure 8. La gesCon du réseau avec SNMP....................................................................... 21 Figure 9. La trame SNMPv1/SNMPv2 ............................................................................... 22 Figure 10. Structure hiérarchique de la MIB II .................................................................. 22 Figure 11. Le logiciel Cisco Network Assistant ................................................................. 23 Figure 12. Les acteurs de l’application ............................................................................. 29 Figure 13. Les foncConnalités de l’applicaCon vues par le « Superviseur » .................... 29 Figure 14. Les foncConnalités de l’applicaCon vue par l’ « Intervenant » ....................... 30 Figure 15. Diagramme des cas d’uClisaCon exprimés par le « Superviseur » ................. 31 Figure 16. Diagramme des cas d’utilisation exprimés par l’ « Intervenant »................... 32 Figure 17. DSS plus complet de la gestion du réseau....................................................... 33 Figure 18. DSS nominal complété de la supervision du réseau ....................................... 34 Figure 19. DSS nominal complété de la rédaction d’un rapport ...................................... 35 Figure 20. Concepts et attributs liés à la supervision du réseau...................................... 37 Figure 21. Concepts et attributs liés à la gestion des rapports détaillés ......................... 38 Figure 22. D de “superviser le réseau » ....................................................................... 39 Figure 23. D de « Gérer les alarmes » .......................................................................... 40 Figure 24. D de « Rédiger un rapport » ........................................................................ 41 Figure 25. Diagramme d’acCvité « Recevoir les alarmes » .............................................. 42 Figure 26. Les sous-modules de supervision .................................................................... 51 Figure 27. La récepCon d’alertes ...................................................................................... 52 Figure 28. L’architecture du système d’envoi et de récepCon de SMS. .......................... 55 Figure 29. Les sous-modules d’archivage ......................................................................... 56 Figure 30. Le frame d’authenCficaCon ............................................................................. 58 Figure 31. Interface d’accueil ........................................................................................... 59 Figure 32. Les uClitaires de surveillance .......................................................................... 60 Figure 33. La créaCon d’une vue ...................................................................................... 62 Figure 34. La configuraCon des profils ............................................................................. 63 Figure 35. La configuraCon du profile Mail ...................................................................... 63 Figure 36. La récepCon des alarmes................................................................................. 64 Figure 37. Architecture de réseau Métro-Ethernet « tunis » sous Optisystem ............... 66 Figure 38. La dégradation de la puissance sous OptiSystem ........................................... 66 Figure 39. Le frame de rédacCon des rapports d’intervenCon ........................................ 67 Figure 40. La liste des intervenCons ................................................................................. 68 Figure 41. Frame des staCsCques..................................................................................... 68 Figure 42. OpCwave : l’interface de l'uClisateur graphique ............................................ 82

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

iv

Table des Tableaux

Table des Tableaux Tableau 1. ClassificaCon des interfaces opCques en foncCon des applicaCons .............. 11 Tableau 2. Les protocoles de gesCon de réseau .............................................................. 19 Tableau 3. La spécificaCon des besoins pour le « Superviseur » ..................................... 30 Tableau 4. La spécificaCon des besoins pour l’« Intervenant » ....................................... 30 Tableau 5. Les équipements réseaux identifiés pour la gestion ...................................... 47 Tableau 6. Les MIB compaCbles avec les agents à supervisés ......................................... 47 Tableau 7. Les informaCons à iniCaliser au niveau des agents ........................................ 48 Tableau 8. La configuraCon de l’adresse de la staCon de supervision ............................ 48 Tableau 9. Les Objets MIB pour la descripCon d’une interface ....................................... 49 Tableau 10. Les Objets MIB pour la surveillance de l’état des interfaces ........................ 49 Tableau 11. La classification selon les gravités des alertes .............................................. 50 Tableau 12. Liste des valeurs d’aGénuaCons du réseau de « tunis » .............................. 66 Tableau 13. Test du scénario « Ajouter d’un périphérique dans la base » ...................... 71 Tableau 14. Test du scénario « CréaCon d’une vue » ...................................................... 71 Tableau 15. Test du scénario « Exécuter le processus d’alerte » .................................... 72 Tableau 16. Test du scénario « Rédiger un rapport d’intervenCon » .............................. 73

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

v

Introduction générale

Introduction générale

_

es réseaux optiques ont connu un développement rapide ces dernières années. Ce développement est dû à l’augmentation de la demande en débit pour les applications nécessitant une grande bande ante afin d’accéder à

l’information le plus rapidement possible comme le Téléchargements, vidéos en streaming, visioconférences, images en haute-définition, etc. Le développement de ces réseaux ne s’effectue pas sans contrepartie. En effet, tant les activités des entreprises que les individus eux-mêmes sont de plus en plus dépendants de ces réseaux. Aussi il devient crucial que les services de communications du réseau soient disponibles en permanence. Les éventuels dysfonctionnements ou pannes doivent être détectés le plus rapidement possible et traités dans les meilleures délais. C’est en cette activité de surveillance du réseau et des services qu’il offre que consiste, précisément, la gestion de réseau. Dans le cadre de ce projet, l'effort a été porté sur le développement d’un outil de gestion qui serais capable non seulement de répondre aux fonctionnalités déjà cité, mais en plus d’assurer un lien direct entre la gestion des alarmes reçus, la circulation de l’information par différents moyens d’alerte s(mail, SMS), le traitement des alarmes de nature coupure de signal optique et le suivie des travaux de réparation répondant ainsi à deux exigences majeures exprimées par l’opérateur : •

La première est le faite de responsabilisé les techniciens qui interviennent pour exécuter les travaux de réparation à respecter les normes de qualité par l’archivage des noms et des résultats de mesures.

•

La deuxième est d’offrir des fonctionnalités

permettant

d’avoir une visibilité

journalière sur les dégradations de la qualité des câbles en fibre optique, cet information permettra aux services d’études de planifier à temps les éventuels redéploiements des câbles dans le réseau.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

1

Introduction générale Pour aboutir à nos objectifs, on a opté pour une architecture SNMP, étant donné que les équipements du réseau Métro-Ethernet objet de notre étude sont des Cisco Catalyst Switch, et au langage du développement java pour sa portabilité. Le rapport est structuré en 5 chapitres brièvement décrits comme suit :

Le chapitre I est une présentation générale du cadre du travail ainsi que les objectifs du projet.



Le chapitre II est une introduction aux concepts de base de la gestion dans les réseaux Métro-Ethernet ; il permet de comprendre les enjeux stratégiques de la gestion et de se familiariser avec ses activités.



Le chapitre III présente l’étude de conception d’une solution de gestion basée sur une spécification d’architectures de gestion efficace, ciblée vers des objectifs opérationnels prédéfinis.



Le chapitre VI décrit les étapes de réalisation de futur outil pour la gestion des réseaux.



Le chapitre V décrit une architecture de tests pour notre outil de gestion.



Enfin, nous avons retenu dans une conclusion générale les grandes lignes de ce qui, à notre sens, mérite une attention toute particulière de la part les opérateurs des réseaux.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

2

3

I Présentation Générale

Chapitre :

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Introduction

1. Introduction Ce travail s’inscrit dans le cadre de mon mémoire de projet de fin d’études à l’Institut National des Sciences Appliquées et de Technologie pour l’obtention du diplôme d’Ingénieur en Réseaux Informatique et Télécommunications. IL a été réalisé à l’agence de la SOTETEL de Tunis ce durant la période s’étalant du 01-09-2011 jusqu’au 30-12-2011. Voici une brève présentation de l’entreprise d’accueil au sein de laquelle le projet de fin d’études a été élaboré.

2. Présentation de l’organisme d’accueil La SOTETEL (Société Tunisienne d’Entreprises et de Télécommunication) est l’entreprise référence en Tunisie dans la mise en œuvre et la maintenance des réseaux privés et des réseaux publics de télécommunication. La SOTETEL a constamment joué un rôle prépondérant dans le déploiement de l’infrastructure de télécommunications en Tunisie en prenant part à presque tous les grands projets réalisés pour le compte de l’opérateur national « Tunisie Télécom ». Elle est également le partenaire privilégié des principaux équipementiers internationaux opérant en Tunisie. Les moyens humains et techniques dont dispose la société, sans cesse mis en adéquation avec les nouvelles technologies, lui ont permis d’acquérir une position dominante sur le marché des télécommunications. Sa présence tout au long de la chaine des télécommunications, depuis l’installation d’appareils téléphoniques jusqu’à la mise en œuvre des réseaux les plus évolués, lui confère un potentiel de développement et de croissance important, tant sur le plan national que sur le plan international, notamment dans les pays du Maghreb, du Moyen Orient et dans des pays de l’Afrique Subsaharienne. Ses acCvités couvrent 5 domaines principaux assurées par 5 départements qui sont : La communication d’entreprises, Les réseaux de lignes d’abonnés, Les transmissions, La commutation, Les réseaux mobiles.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

4

Présentation du projet et objectifs généraux

3. Présentation du projet et objectifs généraux Actuellement les réseaux Métro-Ethernet de Tunisie Télécom ne sont plus doté d’un système de gestion permettant la surveillance de l’état de ses infrastructures, ce qui rend la tâche supervision une tâche plus difficile. Cet handicape fait que les défauts de coupures des liens de connexions ne peuvent être détectées que lorsque les utilisateurs finaux réclame l’absence du service et l’indisponibilité d’accès au réseau. A ce niveau, on aura le lancement de processus de maintenance, une tâche complexe qui nécessite un temps plus important que l’opération de maintenance elle-même, puisque l’information sera en possession du service de la maintenance des câbles en fibre optique que par le billet de age des coups de téléphone entre plusieurs intervenants. Et par conséquence ; des retards pour le rétablissement des liaisons optiques, des incidences financières et juridiques du fait des perturbations des services offerts feront une charge supplémentaire à la société et nuiront à l’image de marque de Tunisie Télécom. Ce qu’on nous demande exactement est de développer

un système de gestion,

inexistant jusqu’à l’instant malgré que la phase de la mise en place du réseau MétroEthernet ait été achevée depuis plus de six mois, un outil qui soit adapté à l’organisation des services de Tunisie Télécom ; qui prend en considération la séparation entre les équipes de maintenance fibres et les équipes de maintenance équipements et qui répond bien aux spécifications préliminaires des utilisateurs souhaités, permettant:

La centralisation de la remontée des alarmes, provenant de chacun des sites à surveiller, vers la même unité de supervision.



Le déclenchement du processus d’intervention, suite à la réception une alarme critique, dans les meilleurs délais.



D’avoir une visibilité journalière sur la dégradation de la qualité des câbles en fibre optique, une information permettra aux services d’étude pour planifié des éventuels redéploiements dans le réseau.



La responsabilisation les techniciens qui interviennent pour exécuter les travaux de réparation tout en respectant les normes par l’archivage de leurs noms près des résultats des mesures déjà effectués.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

5

Planification du déroulement du projet

4. Planification du déroulement du projet Pour les besoins de notre projet nous avons réalisé une grande documentation pour parvenir à la définition des innovations pédagogiques et ce à cause de la grande quantité d’information dispersée pour parvenir à une définition générale pour notre application. Nous avons ensuite, grâce aux informations collectées de la documentation, nous avons pu établir une spécification en fonction du sujet du projet pour parvenir aux différentes exigences des utilisateurs. Des visites et des déplacements, vers les centres de télécommunications appartenant à Tunisie Télécom comme Gasba, Hached ainsi que du Belvédère, étant nécessaire pour bien éclairer les défaillances du système de gestion du réseau qui n’existe pas vraiment et qui se limite en une image statique du réseau en plus d’une console Telnet, d’autre part on a pu suivre les procédures d’interventions suivit lors des opérations de mise en place, de maintenance ainsi que de redéploiement des liaisons optiques. Au cours de la phase de conception nous avons due nous pencher sur les différents aspects conceptuels du système en ce qui concerne la conception des IHM de la partie présentation de l’application, la partie applicative du système et la couche des données pour la conception de la base des données de l’observatoire. Nous avons finalement réalisé une batterie de testes pour vérifier le comportement de l’application.

Figure 1. Diagramme de planification du projet

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

6

7

Chapitre

II Etat de l’art :

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Introduction

1. Introduction Les informations transmises sur les réseaux Métro-Ethernet sont, ou seront d'une importance vitale pour les sites raccordés. Le dysfonctionnement de ces réseaux peut conduire à des pertes d'exploitation et financières importantes. Lors de l'étude d'ingénierie, les structures retenues seront suffisamment évolutives pour permettre le d'applications de natures très différentes et l'extension aisée vers de nouveaux sites (prise en compte de plans d'urbanisme, évolution de la population, futurs services multimédias). L'implantation des sites techniques, des points de raccordement, des points de branchement, la redondance des liaisons, le nombre et la capacité des câbles utilisés donneront toute la souplesse nécessaire au réseau et permettront de garantir un taux de disponibilité important et une maintenance simplifiée. Dans un domaine en perpétuel progrès, un tel sujet ne peut en aucun cas être considéré comme définitivement traité.

2. Les réseaux Métro-Ethernet 2.1.

Architecture générale

Les réseaux Métro-Ethernet, souvent appelés réseaux métropolitains(Metropolitan Area Network), sont la base des boucles régionales, départementales ou locales. Ils réalisent l'interconnexion entre les réseaux longue distance(nationaux ou intercontinentaux) et les réseaux d'accès (également appelés réseaux de desserte) qui connectent les usagers au travers des nœuds d'accès [1].

Figure 2. Le principe de hiérarchisation des réseaux d'infrastructure Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

8

Les réseaux Métro-Ethernet Métro 2.2.

Topologie du réseau Métro-Ethernet Métro

Desservir une zone rurale par un câble optique est déjà un challenge, et il faudrait en amener deux par des chemins différents ! Au lieu de doubler les voies en étoile depuis un point d’accès aux réseaux opérés existants, la constitution d’une boucle permet cette sécurisation tout en minimisant inimisant les liaisons.

Figure 3. La topologie d'un réseau Métro-Ethernet

La topologie finale aboutit, du fait des structurations des matériels de routage et de sécurisation des réseaux, à une structure comportant :

une boucle principale ou anneau sécurisé,



des boucles secondaires branchées sur cet anneau,



et quelques ramifications non secourues.

L’infrastructure fibre du réseau Tunisie Telecom pour la région de « tunis » illustre cette architecture :

Figure 4.. Cartographie du réseau Metro-Ethernet « tunis »

Etude, Planification et Gestion des réseaux Métro-Ethernet Métro

2011/2012

9

Les réseaux Métro-Ethernet 2.3.

Les composantes du réseau Métro-Ethernet

Le schéma ci-dessous recense les différents composants d'un réseau Métro-Ethernet.

Figure 5. Composantes du réseau Métro-Ethernet

Le réseau Métro-Ethernet est constitué de: tronçons de câbles optiques : Ces tronçons sont généralement posés sous fourreaux. Pour des raisons techniques, liées au mode de fabrication et de pose, les tronçons de câble sont limités à une longueur de l'ordre de 4 à 6 km [2], boîtiers d'épissurage : ces boîtiers réalisent l'interconnexion de deux tronçons de câbles. Ils abritent les fibres optiques soudées deux à deux. Ces boîtiers sont généralement logés dans des chambres d'épissurage. Les portions ainsi réalisées interconnectent deux catégories de sites : les sites de régénération : Ceux-ci sont répartis le long du réseau et ont pour fonction d'abriter les équipements de télécommunication (répéteurs, amplificateurs, etc.…) qui régénèrent (remise en forme) le signal optique.

les sites de délivrance de service : les "points de présence opérateurs" : permettant d'interconnecter le réseau Métro-Ethernet aux différents réseaux nationaux.

les "points de desserte de services" : réalisent la frontière avec les réseaux d'accès locaux.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

10

Les réseaux Métro-Ethernet

Le dimensionnement du réseau Métro-Ethernet

2.4.

Le tableau ci-dessous présente les recommandations de L'UIT (Union internationale des télécommunications). Pour les systèmes de transmission utilisant la fibre G652. Les systèmes actuels déent largement ces niveaux de performances. Application

Intra-station

Inter-station Courte distance Longue distance 1310 1550 1310 1550

Longueur d’onde nominale (nm) 1310 de la source Distance (km) <2 - 15 - 40 - 80 Tableau 1. Classification des interfaces optiques en fonction des applications

Les systèmes longue distance développent un budget optique de 20 à 30 dB. Une fibre G652 ayant un affaiblissement moyen de 0,25 dB/km à 1550 nm, une staCon d’amplification optique sera nécessaire tous les 80 km.

La mise en place d’un réseau Métro-Ethernet

2.5.

On essai dans cette partie de décrire différentes phases de la mise en place d’une nouvelle infrastructure :

2.5.1. La planification de l’infrastructure La phase de planification doit permettre à l’opérateur de comprendre les besoins d'aménagement de l’infrastructure numérique en fonction non seulement des besoins des utilisateurs, mais aussi des souhaits des fournisseurs de services et, sur cette base, de déterminer l'infrastructure de télécommunication à établir.

2.5.2. L’étude des réseaux Métro-Ethernet Selon les éléments qui ressortiront de ces études, l’opérateur Tunisie Télécom déterminera son niveau d'intervention en fonction de l'existence, ou de la non-existence, d'un marché pertinent pour justifier un investissement de la part des fournisseurs de services. L'étude déterminera également les différentes options possibles en vue d’ : aider au choix du bon maître d’œuvre du déploiement du réseau, assurer le contrôle et le suivi de ce déploiement.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

11

Les réseaux Métro-Ethernet

2.5.3. L’établissement de l’infrastructure Parmi les choix qui doivent être faits par l’opérateur, quelle que soit la taille du territoire dont elle a la charge, le mode d'établissement de l'infrastructure de télécommunication est sans doute le plus structurant. Soit l’opérateur recourt à la Délégation de Service Public (DSP) pour trouver une entreprise comme Sotetel qui en assurera la construction et, éventuellement, la gestion, et généralement c’est le cas le plus courant, soit il décide d'établir il-même cette infrastructure [Net 1].

2.5.4. La gestion de l’infrastructure La gestion de l’infrastructure physique des réseaux Métro-Ethernet consiste à : 1) Assurer le suivi de tous les chantiers ouverts sur le campus, avec pour mission de préserver le maillage de fibres optiques existant, déployer de nouvelles connexions de bâtiments, conseiller les utilisateurs du réseau sur le mode de connexion le plus adapté pour eux, veiller au bon suivi des chantiers (risques de coupures de connectivité), 2) Archiver Les plans de génie civil(les chambres, l’itinéraire suivi par les câbles...), 3) Affecter des équipes de maintenance qui travaillent selon les besoins jour ou nuit, 4) Stockage d’une quantité de câbles Fibres Optiques de différents calibres.

2.5.5. Les tests et la recette Le but des tests est de démontrer que les différents composants constitutifs d'une liaison sont conformes aux spécifications, installés selon les règles de l’art et ne subissent pas de contraintes mécaniques dans leur environnement.

2.5.6. Phases d’exploitation et de maintenance Les missions d’exploitation et de maintenance des réseaux à haut débit sur fibre optique sont au cœur de l’organisation pour assister les différentes équipes qui interviennent sur le réseau (déploiement, commercialisation…). Le personnel d’exploitation et de maintenance est en relation directe avec l’opérateur pour la prise en compte des évolutions, la gestion des modifications, des interventions en maintenance curative et préventive et pour la gestion des travaux programmés.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

12

Les réseaux Métro-Ethernet 2.5.6.1.

Organisation

Pour assurer une exploitation et une maintenance de qualité, il est impératif de mettre en place une organisation structurée. Certaines tâches sont généralement réalisées par le gestionnaire du réseau, d’autres pourront être sous-traitées (maintenance de niveau 1). Les principales fonctions sont énumérées ci-dessous : Exploitation :

étude des circuits et calcul des bilans optiques,



étude des interconnexions,



édition des ordres de travaux,



suivi des mesures et contrôle des dossiers techniques,



suivi des mises en service,



élaboration ou contrôle des cahiers de recette fournis au service de suivi de l’opérateur,



élaboration des méthodes et procédures d’exploitation,



planification des travaux programmés,



édition et suivi de la documentation.

Maintenance :

élaboration des méthodes et procédures de maintenance,



réception des dérangements (centre d’appels),



coordination des interventions avec Sotetel,



édition ou suivi de la documentation (une tache réalisé d’une manière partielle).

2.5.6.2.

Le calcul du bilan optique

Le bilan opCque est calculé aux deux longueurs d’onde (1310 nm et 1550 nm). Il doit tenir compte de l’affaiblissement linéique de la fibre (typiquement 0,40 dB/km à 1310 nm et 0,25 dB/km à 1550 nm pour une fibre monomode G652), de la valeur moyenne des soudures par fusion (0,10 dB) et des valeurs des points de connexion (0,5 dB pour 2 fiches + 1 raccord). L’affaiblissement est un phénomène physique par lequel la puissance des signaux propagés sur un diminue. Lors de la propagation d'un signal sur fibre optique, la distance parcourue, les soudures, les connecteurs ou les irrégularités placées sur le parcours de la lumière sont, par exemple, des facteurs d'affaiblissement du signal. L'affaiblissement Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

13

Les réseaux Métro-Ethernet est mesuré en décibels (dBm).Il est aussi définit par la somme des pertes d'une ligne de transmission entre une source et un récepteur [3]. Dans une liaison opérationnelle le bilan de liaison doit vérifier l'équation (1): Po – S0 > bilan de liaison (dBm)

(1)

Avec : Po = la puissance de sortie de l'émetteur disponible dans la fibre (en dBm). S0 = seuil de sensibilité du récepteur en dBm. Po - S0 : représente la marge de fonctionnement et est aussi appelé Budget Optique. La sensibilité d'un récepteur optique indique la quantité de lumière nécessaire aux circuits du récepteur pour faire fonctionner l'équipement. Pour exemple, la sensibilité d'un récepteur classique peut varier de 30 dBm à 40 dBm. Le budget optique représente la différence entre la puissance de sortie et la sensibilité : Budget optique (dB) = puissance de sortie (dBm) - sensibilité (dBm)

(2)

Si on uClise un émeGeur à LED de 850 nm avec une puissance de sorCe de 18dBmet un récepteur avec une sensibilité de 30dBm, On obtient le budget optique suivant : Budget opCque = (18) - (30) = -12 dBm Le budget optique permettra de calculer la portée de la liaison. Pour calculer la portée d'une liaison fibre optique, il faudra déterminer le budget optique, puis déduire les pertes dues aux connecteurs, aux épissures, à la maintenance et à l'usure. En connaissant la valeur de l'atténuation du câble utilisé et la nouvelle valeur du budget optique, on pourra alors calculer la portée maximale de la liaison : Portée maxi (Km) = (budget optique-pertes-marge)/atténuation câble

(3)

On reprend le budget optique précédent de 12 dB et on prend en compte les paramètres suivants : •

perte connecteurs : 2 x 1,5 dB

•

perte épissure : 0,3 dB par épissure

•

marge : 3 dB

•

aGénuaCon du câble : 2,5 dB/km

Portée maxi = (12 – 3 - 0,3 - 3) / 2,5 = 2,28 km

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

14

Les réseaux Métro-Ethernet

2.5.6.3.

Les mesures du circuit optique

Afin de déterminer l'affaiblissement (ou l'atténuation) de la fibre optique plusieurs méthodes de mesures sont utilisées, dont notamment: Mesure par rétrodiffusion (backscattering technique) Méthode de mesure basée sur l'injection et la réception d'une impulsion lumineuse à une même extrémité de la fibre. Cette méthode s'appuie sur les pertes engendrées par la diffusion de Rayleigh. Elle permet de visualiser et caractériser l'ensemble des éléments constitutifs de la liaison optique (Cartographie) [3]. Mesure de perte par insertion Elle consiste à injecter, à l’aide d’une source lumineuse, stabilisée et calibrée, une puissance P1 à l’origine du lien et de mesurer le niveau de puissance P2 reçu à l’autre extrémité [3].Les pertes en dB de la liaison en test sont égales à : Pertes = 10 log (P1/P2) (4) Dans la pratique les récepteurs permettent d'effectuer directement ce calcul. L'affaiblissement est mesuré en dBm avec un radiomètre calibré, à 1310 nm et 1550 nm. Chaque circuit sera testé dans les deux sens. 2.5.6.4.

Les causes de défaillance

Les dérives des performances des s physiques peuvent être dues soit au vieillissement d’un composant, soit à l’amplification de défaut existant lors de la recette initiale mais n’ayant pas été décelé, soit à des modifications de l’environnement (chemin de câble, étanchéité, travaux divers…). Pour faire le point des diverses méthodes de suivi envisageables, il faut préalablement établir la liste des composants susceptibles de subir des dégradations entraînant un risque de panne.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

15

Les réseaux Métro-Ethernet Les câbles : Les éventuelles dégradations peuvent être dues : •

aux contraintes (mécanique, chimique, humidité),

•

à la détérioration de la gaine protectrice (rongeurs, travaux).

Les fibres : Hors environnement spécial (rayonnement magnétique nucléaire) la fibre optique ne voit que très peu ses paramètres intrinsèques évoluer au court du vieillissement. Les risques liés à la fibre sont en fait liés aux câbles (notamment au problème de pénétration d’humidité et contraintes mécaniques). Il est à noter que le point délicat de la fibre est sa propriété hygroscopique (absorption de l’eau) conduisant même sur quelques mètres à des dégradations irréversibles. Les épissures : Les épissures collées peuvent voir l’indice de réfraction de la colle différer de celui de la fibre (vieillissement). Les épissures soudées ne peuvent théoriquement pas subir de dégradation de vieillissement. Les risques proviennent de soudures défectueuses dès l’origine mais non détectées à la recette (Par exemple, parce que les épissures et connecteurs sont confondus sur le réflectogramme). Les connecteurs : Les pollutions au niveau des embouts de connecteurs peuvent être sources de dégradations ; il semble toutefois que les salissures concernent plutôt les connecteurs en attente que les connexions établies. Il est très important de respecter les règles d’obturation des raccords sur les connexions en attente.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

16

La gestion des réseaux Métro-Ethernet

3. La gestion des réseaux Métro-Ethernet Dans l’histoire des réseaux, la gestion a toujours été une discipline en retard sur les autres tâches à effectuer. Logiquement, un réseau est d’abord mis sur pied pour la transmission et la commutation d’informations. Lorsque le réseau devient complexe, le nombre de composantes s’accroît souvent exponentiellement, et l’opérateur tend à perdre la vue d’ensemble de son réseau. Il n’est dès lors plus possible d’exploiter rationnellement le réseau sans disposer d’un ensemble d’outils qui permettent de générer une vue synthétique de certains aspects du réseau, et de mettre en évidence d’éventuelles difficultés. 3.1.

Le modèle de la gestion de réseau

Il est possible de modéliser La gestion de réseau par un modèle à couches calqué sur le modèle OSI :

Figure 6. Modèle à couches de la gestion de réseaux

La gestion de réseau se répartit sur diverses couches de responsabilité, selon les objectifs que l’on désire atteindre [4]: Au niveau Gestion des nœuds : seuls sont considérés des éléments isolés, que l’on peut gérer aisément avec des outils comme « Ping »ou autres. Au niveau de la gestion du réseau : Cette tâche est beaucoup plus complexe, car elle demande de collecter des données en provenance de nombreuses sources (idéalement, tous les éléments de réseaux), et d’obtenir ainsi une vision d’ensemble du fonctionnement de notre réseau. Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

17

La gestion des réseaux Métro-Ethernet Au niveau de la gestion du service : on va isoler de cette vision d’ensemble les paramètres concernant un service particulier (comme par exemple, la téléphonie sur IP), pour déterminer quelle est l’influence de ce service particulier sur le réseau, et quelles sont les mesures à prendre pour développer / améliorer ce service. Au dernier niveau, les données en provenance des divers services sont comparées en termes essentiellement économiques, et la décision de développer ou de supprimer un service donné est prise. 3.2.

Architecture de gestion de réseau

Figure 7. Architecture générale du la gestion du réseau

L’architecture de la gesCon de réseau est tradiConnellement bâCe autour de 4 composantes : •

Des stations de gestion du réseau, appelés managers.

•

Des éléments de réseau communiquant avec les managers par le biais d’agents

•

Un protocole permettant la communication

•

De l’information de gestion circulant entre managers et agents Les tâches de gestion de réseau consistent essentiellement en une communication entre

les organes ayant une fonction exécutive dans la gestion de réseau (managers) et les organes constitutifs du réseau (éléments de réseau) par le biais de protocoles de communication appropriés.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

18

La gestion des réseaux Métro-Ethernet

3.2.1. Les Eléments de réseau et les agents L’élément de réseau correspond à un modèle standard, et comporte des données le représentant, et une interface permettant d’accéder à ces données. La modélisation de l’élément réel est générée par l’agent, qui donne de l’élément de réseau une image aussi réaliste que nécessaire pour les tâches de gestion de réseau. L’élément peut être de n’importe quel type, soit des routeurs, des erelles, des stations de travail, des serveurs de fichiers, des répéteurs, ou même des éléments plus atomiques, comme des unités de disques ou des imprimantes. L’agent constitue une représentation de l’élément de réseau. C’est cette représentation qui sera perçue par le gestionnaire de réseau, et non l’élément de réseau réel. Cette représentation doit de ce fait être suffisamment fidèle pour que les informations qu’elle donne soient représentatives de l’état réel de l’élément de réseau.

3.2.2. Le Manager Le gestionnaire (manager) est essentiellement une application résidant sur une station de travail, et communiquant avec les divers éléments de réseau gérés. La relation entre manager et agents est du type "client-serveur", où les rôles du client et du serveur seraient en quelque manière inversés : on a un seul client, qui est le manager, mais N serveurs, qui sont les agents.

3.2.3. Les Protocoles de communication 3.2.3.1.

Présentation des environnements de gestion

Nombreux sont les organisations qui se sont intéressées au problème de la gestion de réseau et de service. Il n’est pas possible de les énumérer toutes mais il est important de présenter celles qui ont eu le plus grand impact dans ce domaine [5]. Voici sous forme de tableau les principaux environnements de gestion sur le marché : Protocoles de gestion SNMP v1,v2,v3 TMN/CMIP Corba/OMA DCE/DME

Organismes et consortiums initiateurs IETF (Internet engineering task force) UIT-T et l’ISO OMG (Object management group) et TMF (Telecommunication management forum) OSF (Open software fundation) Tableau 2. Les protocoles de gestion de réseau

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

19

La gestion des réseaux Métro-Ethernet Les organismes de normalisation et les consortiums internationaux ont proposé plus d’une dizaine de solutions dont les plus populaires sont : SNMP: proposé par l’IETF en 1988 pour la gesCon des environnements T/IP. SNMP (Simple Network Management Protocol) est devenu le protocole de gestion de référence en raison du succès des protocoles de l’IETF (tels que IP, T). Cet environnement est actuellement le plus déployé et utilisé. TMN/CMIP: proposés respectivement par l’UIT-T et l’ISO. L’architecture TMN (Telecommunication management network) et le protocole CMIP (Common Management Information Protocol) constituent la norme dans le domaine de la gestion de réseau de télécommunication. CMIP présente une version améliorée de SNMP tandis que TMN introduit un cadre de travail pour planifier, installer, maintenir, utiliser et istrer un réseau de télécommunication et les services associés. La complexité de ces deux entités a été un frein à leur expansion dans les petits réseaux et ils sont quasi exclusivement utilisés dans les réseaux opérateurs. OMA: proposée par le consortium OMG (Object management group), cette architecture de gestion orientée objets distribués, dite OMA (Object management architecture) est basée sur Corba (Common Objet Request broker architecture) et se propose d’apporter une solution de gestion distribuée intégrant les différentes approches suscitées. DME: proposée par les fabricants de logiciels regroupés dans l’OSF (Open Software Fundation), cette architecture dite DME (Distributed Management Environnement) est orientée vers la gestion exclusive des postes Unix. Nous ne traiterons pas de ce modèle car il est très orienté poste Unix mais ne prend pas en compte la gestion des équipements réseaux. En pratique, l’environnement de gestion SNMP peut gérer tout équipement connecté au réseau qui dispose d’un processus, dénommé agent SNMP, capable d’exécuter les fonctions de surveillance. En plus, l’environnement de gestion SNMP est utilisé dans la majorité des cas avec l’architecture IP, en raison de la popularité des protocoles IP. 3.2.3.2.

Le protocole SNMP (Simple Network Management Protocol)

Le protocole SNMP est basé sur l'échange de messages entre l'élément réseau à surveiller et la station de gestion. La station de gestion est typiquement une station de travail qui affiche les informations importantes sur les éléments qu'elle surveille. Elle Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

20

La gestion des réseaux Métro-Ethernet exécute un logiciel client d'istration ou MC (Management client). Chaque élément du réseau participant à l'istration dispose d'un logiciel agent d'istration ou MA (Management agent). Techniquement, le logiciel agent est un logiciel serveur. Cet agent a pour rôle de répondre aux demandes d'information et de prendre les mesures correctives émanant de la station de gestion client. Il reçoit des messages qui consistent en des requêtes de lecture ou d'écriture des données sur l'appareil. L'élément du réseau ou nœud du réseau est vu comme un ensemble de variables qui peuvent être lues (supervision) ou modifiées (contrôle). L'agent traite les demandes et renvoie les réponses correspondantes en retour. Quand un problème sérieux est décelé ou qu'un événement important se produit, l'agent envoie spontanément un message de notification (trap) à une ou plusieurs stations de gestion. L'agent a la connaissance locale de la gestion de l'information et transcrit l'information dans une forme compatible avec SNMP. Un grand réseau dispose bien entendu de plusieurs istrateurs.

Figure 8. La gestion du réseau avec SNMP

Pour permettre l’hétérogénéité des éléments de réseau, la transmission d’informations de gestion est effectuée par le biais d’une syntaxe de transfert particulière, à laquelle chaque élément doit se plier.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

21

La gestion des réseaux Métro-Ethernet

Figure 9. La trame SNMPv1/SNMPv2



La version la plus uClisée est encore la version 1. Plusieurs versions 2 ont été proposées par des documents de travail, mais malheureusement, aucune d’entre elles n’a jamais été adoptée comme standard. La version 3 est actuellement en voie d’être adoptée. On place la valeur zéro dans le champ version pour SNMPv1, et la valeur 3 pour SNMPv3.



La communauté permet de créer des domaines d’istration. La communauté est décrite par une chaîne de caractères. Par défaut, la communauté est « PUBLIC ».



Le PDU(Packet Data Unit)

3.2.4. La structure des données de gestion(MIB) Il est intéressant de regrouper l'information sur la configuration, le statut (bon fonctionnement ou pas) et les statistiques internes (trafic entrant et sortant / erreurs observées) dans une base de données « logique ». Cette base de données logique utilisée pour la gestion de réseaux est appelée MIB (Management Information Base). Chaque élément réseau istré par SNMP contient une MIB, dont les variables vont être lues ou modifiées à l'aide d'un ensemble simple de messages émis par la station de gestion, selon les opérations SNMP.

Figure 10. Structure hiérarchique de la MIB II

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

22

La gestion des réseaux Métro-Ethernet Une MIB contient un certain nombre d'informations standard (MIB standard). On distingue aussi la MIB privée qui contient un certain nombre d'objets propres à un agent pour en exploiter les possibilités (MIB privée). Les grandes sociétés ont des MIB privées d'entreprises. Exemple : IBM : 1.3.6.1.4.1.2 ; DEC : 1.3.6.1.4.1.36 ; SUN : 1.3.6.1.4.1.42 ; CHIPCOM: 1.3.6.1.4.1.49. 3.3.

Les outils de gestion de réseau

Les outils de système d’istration de réseaux permettent de surveiller les performances du réseau. Ils affichent une représentation graphique des périphériques réseau. Si une défaillance survient, l’outil peut en localiser la source et déterminer si elle a été provoquée par une activité ou un logiciel malveillant, ou par un périphérique défectueux.

3.3.1. CiscoWorks Network Connectivity Monitor CiscoWorks

Network

Connectivity

Monitor

(NCM)

constitue

le

plus

récent

développement de la gamme de solutions de gestion CiscoWorks, conçues pour faire des réseaux Cisco les plus faciles à istrer et les plus disponibles du marché. Le logiciel Cisco Network Assistant est un outil orienté Web, pour les configurations rapides basées sur des profils prédéfinis. De plus, CiscoWorks LMS (LAN Management SoluCon) prend en charge la gamme Cisco Catalyst 3750-E pour une istration globale du réseau [6].

Figure 11. Le logiciel Cisco Network Assistant Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

23

La gestion des réseaux Métro-Ethernet Cisco Network Assistant offre des capacités de configuration et de gestion centralisée. Cisco Network Assistant utilise la technologie Cisco Smart ports pour simplifier aussi bien les déploiements que la maintenance courante. CiscoWorks LAN Management Solution (LMS) : une suite d’outils de gestion qui aide à la configuration, l’istration, la surveillance, et le dépannage des réseaux Cisco.

3.3.2. Pourquoi un outil de gestion propriétaire Dans cette dernière étape, l’objectif est de justifier le choix du développement d’un nouvel outil au lieu de proposer un outil de gestion du réseau Tunisie Télécom parmi une panoplie de plates-formes et qui soit compatible avec les besoins exprimés et avec les architectures technologiques mis en place. L’environnement technologique du réseau de Tunisie Télécom reposant entièrement sur IP, il est clair que le choix de l’environnement de gestion va se porter sur SNMP. En conséquence, les choix en matériels et logiciels viseront à er le système de gestion SNMP. Le développement d’un nouveau outil est due à: •

L’insuffisance des possibilités fonctionnelles demandé par les utilisateurs et celle offertes par cette plate-forme,

•

Du coût d’achat, de mise en place et de maintenance de cette dernière.

•

la capacité de cette plate-forme à offrir des outils complémentaires permettant de prendre en compte des besoins spécifiques, identifiés, en termes de remontée des alarmes, des performances, des fautes et des pannes d’interconnexion optique, de génération des rapports d’intervention, aussi bien en terme de gestion des statistiques sur l’état des lien optiques.

•

Le non compatibilité avec la répartition des taches au niveau des services ; service Exploitation sous la responsabilité de Tunisie Télécom et service Maintenance sous l’occupation de Sotetel.

•

…

De ce point de vue, le développement d’une nouvelle plate-forme est un bon choix sur les plans financière, techniques et organisationnels. À cette plate-forme, il serait nécessaire d’intégrer un outil de configuration pour la maintenance des routeurs Cisco.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

24

Conclusion

4. Conclusion Après avoir donné un aperçu sur la gestion réseau ainsi que sur le contexte général dans laquelle il s’inscrit, en guise d’étape suivante de ressortir les fonctionnalités que devra offrir le futur logiciel et ses différents cas d’utilisation et ce à travers les besoins exprimés par ses utilisateurs potentiels.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

25

26

Chapitre

III Analyse et conception :

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Introduction

1. Introduction La phase de spécifications et d’analyse des besoins est indéniablement l’une des phases les plus importantes en matière de développement de logiciels si ce n’est la plus importante. D’une part les fonctionnalités offertes par le future logiciel de gestion et de supervision des liaisons optiques sont tributaires des besoins exprimés par les utilisateurs et d’autre part c’est en quelque sorte « la feuille de route » à laquelle on doit se référer afin qu’il rende tangibles et concrètes les aspirations de ces derniers.

2. Méthodologie Le formalisme qu’on vient de suivre pour le développement de notre logiciel se situe à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et les méthodes agiles en vogue actuellement, telles que XP (eXtreme Programming), et Scrum. Il s’inspire également des bonnes pratiques prônées par les tenants de la modélisation agile (Agile Modeling). Dans un premier temps, les besoins vont être modélisés au moyen des cas d’utilisation UML. Ils seront représentés de façon plus concrète par une maquette d’IHM (Interface Homme-Machine) destinée à faire réagir les futurs utilisateurs, et avec l’apport des diagrammes de classes participantes, on peut aboutir à des diagrammes de conception à partir desquels on dérivera du code assez directement.

3. Spécification des exigences 3.1.

Exigences fonctionnelles:

Les besoins en matière de gestion de réseau exprimés par les futurs utilisateurs peuvent être classés comme suivant: La configuration des Switchs: Elle rassemble les fonctionnalités permettant à un utilisateur de configurer les éléments actifs du réseau ; comme l’activation de l’envoi des alarmes vers la station de gestion. La surveillance de l’état actuel du réseau: elle consiste à superviser le réseau MétroEthernet de la compagnie Tunisie Télécom à travers des vues cartographiques qui

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

27

Spécification des exigences permettent à l’istrateur réseau de visualiser les états de tous les équipements du réseau ainsi que les liaisons optiques entre eux. La gestion des alarmes: Elle consiste à mettre en œuvre les fonctionnalités qui permettront de faire rapidement remonter au niveau du réseau les pannes qui peuvent survenir au niveau des équipements et permettant l’interprétation de l’état courant des liaisons optiques du réseau. Le suivi de la qualité des liaisons optique: cela consiste à vérifier que les mesures faites sur les liaisons optiques de l’infrastructure restent toujours acceptable pour assurer le bon fonctionnement du réseau. 3.2.

Exigences non fonctionnelles :

Elles s’apparentent principalement aux critères ergonomiques de l’interface graphique du logiciel : La convivialité de l’interface graphique : elle est primordiale car elle représente le premier de l’utilisateur avec l’application et c’est par le biais de celle-ci qu’il en découvrira les fonctionnalités. Elle a trait entre autres au choix des couleurs, à la politique de disposition des différents composants graphiques… Eviter de solliciter fréquemment l’utilisateur pour faire une tâche particulière en ayant recours à certains composants au lieu d’autres à l’instar d’une liste déroulante à la place d’un champ pour l’écriture. Offrir la possibilité de retourner au menu principal de l’application à partir de n’importe quelle fenêtre de celle-ci. Les composants graphiques en général et les boutons en particulier devront être munis d’icônes qui en rappellent le plus fidèlement possible la fonction afin qu’elle soit facilement identifiée. 3.3.

Spécification des exigences d’après les cas d’utilisation

3.3.1. Identification des acteurs On distingue deux catégories d’utilisateurs potentiels du futur logiciel de gestion des réseaux Métro-Ethernets : 1. Les Superviseurs de réseaux qui ont un accès total à toutes les fonctionnalités proposées par l’application.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

28

Spécification des exigences 2. Les Intervenants qui disposent d’une multitude de fonctionnalités pour l’élaboration de leurs rapports d’intervention, ils ont accès sur seulement la partie consacrée aux modules d’archivage du logiciel.

Figure 12. Les acteurs de l’application

Pour chaque acteur identifié précédemment, il convient de rechercher les différentes intentions « métier » selon lesquelles il utilise le système. Les figures « Figure 12 » et « Figure 13 » résument les fonctionnalités attendues du futur logiciel respectivement par la première et la deuxième catégorie d’utilisateurs.

Figure 13. Les fonctionnalités de l’application vues par le « Superviseur »

D’après la Figure précédente, les fonctionnalités attendues, de la future application de gestion du réseau, par le« Superviseur » sont les suivantes : Activité Configurer les équipements du réseau Surveiller l’état du réseau

Besoin Rendre opérationnels les éléments actifs du réseau : • Connaitre IOS de Cisco pour (Cisco Catalyst 3750 ME). • Rendre active la gestion des équipements réseau. Visualisation de l’état des équipements distants. Surveillance des liens : • Créer et d’afficher la cartographie du réseau. • Mettre à jours la cartographie.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

29

Spécification des exigences Gérer les alarmes

Traitement des pannes équipements et des coupures des liens optiques : • Capturer les alarmes issues des équipements actifs. • Configurer les paramètres d’alertes que se soit par mail ou par SMS pour des besoins de Notification. • Configurer les seuils

Suivre la qualité des fibres

Assurer une disponibilité permanente des liens optiques du réseau : • L’établissement des statistiques sur l’évolution des caractéristiques des fibres. • La planification (Identifier les fibres les plus probables à être redéployés) Tableau 3. La spécification des besoins pour le « Superviseur »

Figure 14. Les fonctionnalités de l’application vue par l’ « Intervenant »

Cette figure présente les fonctionnalités attendues du futur système de gestion réseau par un utilisateur « Intervenant ». Activité Elaborer des rapports

Produire des statistiques

Besoin Responsabiliser les équipes de maintenance. Sauvegarder une trace sur les opérations d’intervention. • Traitement et sauvegarde des rapports de fin d’opérations de maintenances. • Exporter les sous formats portables. • Rendre la tache de circulation des rapports entre les services de maintenance et celui de gestion du réseau plus fluide. Visualisation de la progression des caractéristiques liens (atténuation totale, linéique) • Afficher les statistiques sur l’ensemble des liens du réseau (nbre de fois ou le lien a tombé en panne pendant une période T) Tableau 4. La spécification des besoins pour l’« Intervenant »

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

30

Spécification des exigences

3.3.2. Affinement du modèle de cas d’utilisation Le diagramme de cas d’utilisation des besoins exprimés par le « Superviseur » :

Figure 15. Diagramme des cas d’utilisation exprimés par le « Superviseur »

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

31

Spécification des exigences Le diagramme de cas d’utilisation des besoins exprimés par l’ « Intervenant » :

Figure 16. Diagramme des cas d’utilisation exprimés par l’ « Intervenant »

Nous avons identifié les acteurs et les cas d’utilisation. Nous allons maintenant er à les décrire de façon détaillée afin d’obtenir une expression précise des besoins avant d’attaquer la conception objet. 3.4.

Spécification détaillée des exigences

Nous allons représenter le DSS (Diagrammes de Séquence Système) d’un scénario représentatif de chacune des applications des cas d’utilisation décrits précédemment.

3.4.1. Spécification détaillée de l’application « SNM Supervision » Commençons par étudier les fonctions souhaitées avoir exprimées par le Superviseur en vers l’application de supervision. On va se limiter à étudier l’ensemble des cas d’utilisation suivants : •

Créer une vue de l’infrastructure.

•

Gérer les alarmes.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

32

Spécification des exigences « Créer une vue de l’infrastructure » Pour pouvoir créer des vues, le Superviseur aura l’accès à un espace réservé lui permettant de construire ses vue et les enregistrer.

Figure 17. DSS plus complet de la gestion du réseau

Rappelons que pour er à la supervision, le Superviseur doit maintenant s’authentifier s’il a est déjà un compte, ou bien créer un compte superviseur s’il ne l’était pas. Notez le symbole de l’état sur la ligne de vie du indiquant qu’il est devenu Superviseur dans tous les cas pour pouvoir exécuter la suite du cas d’utilisation (voir figure 16). Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

33

Spécification des exigences « Gérer Les alarmes » Nous allons ensuite décrire la supervision du réseau proprement dite, telque nous l’avions explicité dans la description textuelle. << system >> SotetelNetManager

<<system>> Agents

Superviseur

Lancer la supervision(vue)

Loop

trap() Enregistrement trap() TypeAlarme()

alt Alarme Critique

Alertes (sms, mail)

IncrémenterCompteurs()

Afficher_trap()

Figure 18. DSS nominal complété de la supervision du réseau

3.4.2. Spécification détaillée de l’application « SNM Archivage » « Rédiger un rapport » La rédaction des rapports est une tache visant l’archivage des traces de l’ensemble des interventions, la responsabilisation des intervenant ainsi que le suivi de l’état des liaisons optiques tout en conservant toujours une base de donnée locale mis à jours, ce qui explique l’exécution du processus d’alertes de type « UpSeuil » lors de la non conformité des valeurs saisies avec les marges acceptables définit par le superviseur. Le DSS, cherchant à mettre l’accent sur les différents messages qui circule entre l’Intervenant d’une part et l’application en tant que boite noire de l’autre part, est représenté sur la figure suivante :

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

34

Spécification des exigences

<< system >> SotetelNetManager

loop : 3 S'authentifier(nominal)

Intervenant

SNM archivage

alt Créer_nouveau_Rapport(date) Consulter_Rapport(date,liaison) loop Remplir_Formulaire() Saisir_Paramètres(value)

Sauvegarder_Rapport() alt

1: [Formulaire] Vérification

Rapport_sauvegardé() Rapport_incomplet

Seuil_déé(liaison)

1: [Att B_B>seuil]

« UpSeuil »

alt Envoyer_par_Mail(Rapport) 1: [Profil_Mail] Vérification

alt Rapport_envoyé() Rapport_non_envoyé Exporter_to_pdf(Rapport)

Figure 19. DSS nominal complété de la rédaction d’un rapport

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

35

Conception

4. Conception L’expression préliminaire des besoins donne lieu assez directement à une modélisation par les cas d’utilisation et à une maquette d’IHM. Il s’agit là de descriptions fonctionnelles qui vont nous servir en particulier pour les tests de recette à la fin du projet, mais aussi de point d’entrée pour la description dynamique des scénarios d’exécution du futur logiciel de gestion. 4.1.

Identification des concepts du domaine

Pour le cas d’utilisation « configurer le réseau », nous identifions les concepts fondamentaux : Vue, Liaison, Agent, Interfaces, Community. De même, pour le cas d’utilisation « Gérer les alarmes », nous identifions : Alarme , Agent, Liaison, Interface. Enfin, pour le cas d’utilisation « Elaborer les rapports d’interventions », nous identifions : Rapport, Intervention, Liaison, Intervenant. « Gérer les alarmes » Le superviseur devant une multitude de fonctions offerte, aura la possibilité de consulter les alertes les plus récentes, une alerte est décrite par

(agent, date_réception, sévérité,

description, etc.) On remarque bien que : L’attribut agent devrait plutôt être modélisé comme un concept : un agent est la représentation logique d’un routeur qui na pas seulement un nom, mais aussi un ensemble d’interfaces, soit (nom, type, ville, interfaces).

Interfaces est un vecteur d’interface qui peut être aussi modélisée comme un concept : une interface est décrite par (nom, addresse_IP_associée, état) Pour les interfaces avec un état « up » on peut parler aussi d’un lien physique dans notre cas c’est un lien optique qui est définit par (nom, type, longueur, atténuation_linéique,

atténuation_B_to_B), l’atténuation linéique est une caractéristique propre à la fibre dont on a parlé deuxième chapitre, alors que pour l’atténuation de Bout en Bout, c’est un attribut qui rassemble les valeurs d’atténuations mesurés; soit dans les sorites de contrôle périodiques, soit lors d’une intervention de maintenance. Donc Il s’agit bien d’un ensemble de concepts à part entières dans le domaine, au même titre qu’un agent comme indiqué sur la figure suivante: Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

36

Conception

Class Agent Class Alerte dateReception:date = null sévérité:String = "notification" message:String = null

est réçu par 1..*

0..*

nom:String = null type:String = null ville:String = null interfaces:tab[Interface] = tab[null] Ajouter(nom):return boolean Modifier(nom):return boolean Supprimer(nom):return boolean

getSévérité(message):return String

1..* 0..1 Class Laison nom:String = null type:String = "Fiber G652" longueur:Float = 0 atténuationB_B:Float = 0

Class Interface est conneté à 0..2

getRecentAtténuation(nom):return Float

0..1

nom:String = null addresseIP:IPaddress = "0.0.0.0 " etat:String = "down" isUp(nom):return boolean

Figure 20. Concepts et attributs liés à la supervision du réseau

« Elaborer des rapports » Le Rapport est bien un concept du domaine, car dans les opérations d’intervention habituelles, l’intervenant rédige également un rapport après avoir terminé l’opération de maintenance. Le Rapport est simplement le résumé et la fiche technique de l’opération en tout ses étapes. C’est un simple formulaire à remplir (dateDébutIntervention, DateFinIntervention,

fibre, Intervenant, atténuation_B_to_B, atténuation_Epaissure, Remarques), Une Intervention doit préciser son type que se soit une intervention de maintenance périodique ou une suite à un incident et dans ce deuxième cas il est important de donner la cause de l’incident dont on aura par la suite cette représentation :

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

37

Conception

Figure 21. Concepts et attributs liés à la gestion des rapports détaillés

4.2.

Diagrammes de classes participantes

Le point névralgique de notre démarche s’appelle le diagramme de classes participantes. Il s’agit de diagrammes de classes UML qui décrivent, cas d’utilisation par cas d’utilisation, les trois principales classes d’analyse (les dialogues, les contrôles, les entités) et leurs relations. Pour compléter ce travail d’identification, nous allons ajouter des attributs et des opérations dans les classes d’analyse, ainsi que des associations entre elles. Les entités ayant déjà été répertoriées dans la section traitant des concepts du domaine, nous allons donc ajouter les dialogues et les contrôles et réaliser les D correspondants. « Superviser le réseau » Le superviseur veut contrôler et superviser le réseau. Pour cela, il va pouvoir valider le réseau à superviser, ou modifier des informations erronées sur certains sites. Il doit également être en mesure de modifier l’organisation générale du réseau en créant de nouveaux nœuds, etc. Nous supposons que la maquette nous a montré trois écrans principaux : •

l’écran d’organisation du catalogue (dialogue OrganisationRéseau) à partir duquel on crée de nouveaux sites, de nouveaux champs de supervision, etc. ;

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

38

Conception •

l’écran de gestion des mises à jour (dialogue GestionMiseAJourRéseau) qui parcourt les informations modifiées automatiquement et valide le réseau ;

•

l’écran de gestion des infos détaillées d’un nœud (dialogue GestionDétailNœud) permettant de modifier le nom, le type, etc. d’un nœud particulier.

Les comportements correspondant à toutes ces fonctionnalités ont été découpés en deux classes contrôles afin de distinguer ce qui relève du niveau global du réseau (contrôle CtrRéseau) et ce qui concerne un nœud particulier (contrôle CtrNœud)..

Ensuite, nous avons fait figurer toutes les entités manipulées (sans les associations pour ne pas surcharger inutilement). Le diagramme global ainsi obtenu est montré sur la Figure 21.

Figure 22. D de “superviser le réseau »

Le CtrRéseauest relié au dialogue GestionDétailNœud, car c’est le contrôle global qui initialise l’écran de mise à jour. Celui-ci dialogue ensuite avec son contrôle particulier (CtrNœud).

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

39

Conception « Gérer les alarmes » Le superviseur veut être le plus rapidement possible au courant de tout changement d’état des liens optiques recherchés dans l’ensemble du réseau. Il veut également pouvoir consulter la fiche détaillée d’une liaison particulière avant de lancer la procédure d’intervention lorsqu’il s’agit d’une alerte critique. Nous supposons là encore que la maquette nous a montré deux écrans principaux : • l’écran de supervision; • l’écran de propriété liaison, qui permet d’accéder à la fiche détaillée d’une liaison particulière. Les comportements correspondant à ces fonctionnalités ont été séparés en deux classes contrôles afin de distinguer ce qui relève de la recherche au niveau global du réseau et ce qui concerne l’obtention d’informations détaillées sur une liaison particulière. Le diagramme ainsi obtenu est montré sur la Figure suivante.

Figure 23. D de « Gérer les alarmes »

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

40

Conception « Rédiger un rapport » Lorsque l’Intervenant termine l’opération de maintenance il a la possibilité d’enregistrer les détails de l’opération dans un forme d’un formulaire à remplir. Ensuite, il doit pouvoir l’enregistrer, en supprimer ou encore en modifier les paramètres avant de l’envoyer par mail, ou l’exporter sous forme PDF. Ici, il n’y a qu’un seul écran, avec un seul contrôle, comme indiqué sur la figure 23 << entité >> réseau région : String << entité >> Rapport dateRédaction : date Rédacteur : String

<< dialogue >> RédigerRapports dateRédaction : date dateDébutIntervention:date dateFinIntervention:date fibre : Liaison intervenant : Personne atténuationB_B : Float remarque : String Intervenant

<< contrôle >> CtrRapports sauvegarder_BD(): boolean envoyerParMail(): boolean exporterVersPDF(): boolean

sauvegarder_BD(): boolean envoyerParMail(): boolean exporterVersPDF(): boolean

<< entité >> Personne nom : String prenom : String fonction : String téléphone : String adrMail : String << entité >> Liaison nom : String type : String ville : String longueur : Float atténuation_Lin : tab[Float]

Figure 24. D de « Rédiger un rapport »

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

41

Conception 4.3.

Diagrammes d’activité

Nous allons étudier le casd’utilisation majeur de superviseur, la gestion des alarmes reçus, et précisément la réception des alarmes: « Recevoir les alarmes » Pour ce cas d’utilisation, nous réaliserons un diagramme d’activité représentant le déroulement dynamiques et les différentes phases.

Figure 25. Diagramme d’activité « Recevoir les alarmes »

Le Superviseur veut exécuter le plus rapidement possible un processus d’Alertes qui s’exécute dès la réception d’une alarme critique depuis un nœud du réseau. Il veut également pouvoir sauvegarder la description détaillée de ces alertes avant de se mettre à l’état d’écoute de nouveaux « Alarmes ». Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

42

Structure de la base de données

5. Structure de la base de données Avant de er à la présentation de la structure de la base de données, il est à noter que nous avons utilisé les fichiers « flat file database» comme base de stockage. Ce choix est en fait bien justifié. En effet, les bases par fichier diffèrent des bases relationnelles par plusieurs points importants. Tout d'abord, elles sont universelles : à partir du moment où l'on peut créer un fichier, on peut créer une base fichier, sans faire appel à un logiciel serveur. Ensuite, elles sont simples à mettre en place : pas de logiciel à installer ou de base à configurer. Enfin, elles prennent moins d'espace disque. Une base fichier est conçue autour d'une table unique par fichier, avec un enregistrement par ligne de texte.

6. Conclusion Dans ce chapitre nous avons présenté les étapes de développement de notre application. Nous avons commencé par dégager les fonctionnalités de base. Ensuite, nous avons détaillé la conception. Le chapitre suivant présentera la réalisation de cette application.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

43

44

Chapitre

IV

:

Réalisation

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Introduction

1. Introduction Apres avoir achevé l'étape de conception de l'application, nous entamons dans ce chapitre la partie réalisation. Nous allons commencer, tout d'abord, par le choix de l'environnement logiciel utilisé pour développer l'application, ensuite on montrera le chronogramme de la réalisation du projet. Enfin, on présentera le travail accompli tout au long de la période du stage.

2. Environnement de développement 2.1.

Environnement Matériel

On a développé notre application sur une machine virtuelle ayant ces performances : U = Intel core2duo 2.4 GHz. Ram = 1512 Mo. Capacité du disque dur = 40 Go. Carte réseau : VIA PCI 10/100Mb FAST ETHERNET. Protocole utilisé : UDP.

2.2.

Environnement Logiciel

Système d’exploitation : Windows XP service Pack2. Outil pour la conception :Edraw Max 5 Outil de gestion de projet : SprintToMeter Editeur : Microsof Word Version 2007. L’application se base sur les outils suivants : •

NetBeans: est un environnement de développement intégré (IDE) open source. Il est développé par Sun et se trouve sous licence CDDL (Common Development and Distribution License).

•

Java Development Kit (JDK) : est l'environnement dans lequel le code Java est compilé pour être transformé en byte code afin que la machine virtuelle Java (JVM) puisse l'interpréter.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

45

Environnement de développement

2.3.

Choix techniques

2.3.1. Choix du langage Java est un langage orienté objet développé par la société Sun. Il est muni d’une riche bibliothèque de classes couvrant tous les domaines d’applications existants et permettant ainsi de développer toute sorte de projets de manière rapide et efficace. Les caractéristiques du langage Java qui nous ont encouragés à le choisir sont les suivantes : il est robuste, portable et indépendant de l’architecture. java est un langage interprété (le code produit par le compilateur n’est pas du code machine c’est du byte code) orienté objet. il intègre des processus légers et dynamiques. Il permet le développement d’applications réparties et fourni des classes et paquetages de communication.

2.3.2. Choix des outils de simulation 2.3.2.1.

OptiSystem

Le logiciel Optisystem permet de simuler et d’analyser les systèmes de transmission optique. La diversité des systèmes simulés peut être étendue par la possibilité d’insérer des fonctions réalisées par l’utilisateur sous Matlab et qui peuvent être insérées aux systèmes simulés. Afin d’initialiser la base de donné de l’outil de gestion avec les valeurs de références de chacune des liaisons optiques, une ligne de transmission réaliste dont les caractéristiques en terme d’accumulation d’atténuation au cœur de la fibre se rapprochent de celles de la ligne expérimentale du laboratoire, a dans un premier temps été modélisée. Des modules d’émission et de réception ont tout d’abord été créés, avant d’y insérer la ligne de transmission [7]. 2.3.2.2.

GNS3 (Graphical Network Simulator 3) :

Dans le but de suivre au fur et à mesure le bon état des modules en phase de réalisation, il été indispensable de se référer à un simulateur graphique de réseaux capable de charger de véritables systèmes, comme l'IOS de Cisco ou JunOS de Juniper, permettant ainsi d'émuler entièrement des routeurs ou Switchs Cisco [Net 2]. GNS3 été notre choix pour des raisons techniques (disponibilité, adaptabilité...) et fonctionnelles (simplicité, performance…) [8]. Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

46

Environnement de gestion requis

3. Environnement de gestion requis 3.1.

Les classes d’équipements

Dans cette phase, l’objectif est d’identifier, d’une part, les capacités de gestion de ces équipements par rapport aux besoins de gestion exprimés dans la phase précédente et, d’autre part, la technologie de gestion de réseau qu’ils ent [Net 3] [9]. Équipement

Positionnements

Cisco Catalyst 3750 Metro Switch

Commutateur pour réseau fédérateur. Peut former un châssis virtuel.

CiscoCatalyst 4000 Switch

Caractéristiques

Technologies de gestion compatibles SNMP v1, v2C, v3, Configuration propriétaire Cisco

Commutateurs fixes de niveau 3 intégrant la technologie d’interconnexion de pile à 32 Gbits/s – 24 ou 48 ports 10/100BaseTet 2 ou 4 ports SFP – 24 ports Gigabit Ethernet et 4 ports SFP – 12ports SFP. Commutateur à forte Commutateurs de niveau 2 SNMP v1, v2C, v3, densité de et 3 modulaires - Jusqu’à Configuration port pour réseaux 240 ports propriétaire Cisco fédérateurs. 10/100BaseT ou 90 ports Gigabit Ethernet. Tableau 5. Les équipements réseaux identifiés pour la gestion

L’environnement technologique du réseau de la compagnie Tunisie Télécom reposant entièrement sur IP, il est clair que le choix de l’environnement de gestion va se porter sur SNMP. Équipements

MIB compatibles

Cisco Catalyst 3750 Metro Switch CiscoCatalyst

MIB1, MIB2, MIB privée Cisco, RMON( Statistics, history, alarms et events) MIB1, MIB2, MIB privée Cisco, RMON.

4000 Switch

Tableau 6. Les MIB compatibles avec les agents à supervisés

3.2.

La configuration des équipements

Tout d’abord, il est nécessaire d’activer les agents SNMP sur tous les éléments que l’on souhaite gérer dans ce réseau : les Switchs [Net 4]. Ensuite, il convient de configurer les équipements afin de mettre à jour un certain nombre d’informations utiles pour leur identification, localisation et maintenance telle que cela est décrit dans le deuxième chapitre concernant le protocole SNMP.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

47

Environnement de gestion requis Ces informations sont introduites grâce à des commandes de configuration spécifiques de l’OS des équipements [10]. Les informations qu’il est nécessaire d’initialiser sont les suivantes : Objet MIB II SysDescr

Sémantique Le nom, le type et la version du système géré (par exemple : switch-Marsa, Cisco3750, IOS11)

OID Mib-2.1.1

SysObjectID

Identification du type de l’objet géré en Mib-2.1.2 fonction de sa position dans l’arbre MIT.

Sys

Le nom et l’adresse de la personne responsable de la gestion de cet équipement (par exemple : Touati Brahim, bureau 46, Sotetel, Charguia II).

SysName

Nom de l’équipement géré (par Mib-2.1.5 exemple: switch-Marsa192.168.0.11)

SysLocation

Localisation physique de l’équipement Mib-2.1.6 (par exemple : région de tunis, bâtiment 1, étage 3, local technique 2)

SysServices

Le nom, le type et la version du système géré (par exemple : switch-Marsa, Cisco3750, IOS11.1)

Mib-2.1.4

Mib-2.1.7

Tableau 7. Les informations à initialiser au niveau des agents

Parmi les autres informations importantes à configurer dans les équipements réseau, il y a la spécification de l’adresse IP de la ou des stations d’istration. De manière identique à la configuration précédente, une commande spécifique de l’OS permet de fixer l’adresse de la station de supervision. Dans le cas de la compagnie Tunisie Télécom, on doit connaître l’adresse de la station de supervision et introduire cette adresse dans chacun des équipements actifs (voir Annexe A). Configuration

Stations

Adresse IP de la station d’istration

192.168.0.1

Adresse IP de la station de collecte des traps

192.168.0.1

Tableau 8. La configuration de l’adresse de la station de supervision

Il reste maintenant la récupération des informations permettant de constituer la carte topologique du réseau et de visualiser des informations sur le fonctionnement du réseau telles que le statut opérationnel des équipements, l’état opérationnel des interfaces, etc. La carte est capable de détecter automatiquement la topologie du réseau et de construire des cartes. Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

48

Environnement de gestion requis Les informations de base pour ce type de configuration sont résumées dans le tableau suivant : Objets MIB II

Sémantique

OID

ifPhysAddress

Adresse physique de l’interface

.1.3.6.1.2.1.2.2.1.6

ifType

Type de l’interface

.1.3.6.1.2.1.2.2.1.3

ifDesc

Description de l’interface

.1.3.6.1.2.1.2.2.1.2

ifStatus

Statut istratif d’une interface

.1.3.6.1.2.1.2.2.1.7

ifOperStatus

Statut opérationnel d’une interface

.1.3.6.1.2.1.2.2.1.8

Tableau 9. Les Objets MIB pour la description d’une interface

On va donc choisir dans le modèle d’informaCon de SNMP, MIB1 et MIB2, voire des MIB propriétaires des objets qui contiennent les informations relativement au statut des équipements, des interfaces, des lignes, etc. Dans le tableau suivant, voici quelques exemples d’objets qui permettent de vérifier l’état opérationnel des équipements des interfaces en entrée ou en sortie. Objet MIB II

Sémantique

OID

IfStatus

Statut istratif d’une interface.

.1.3.6.1.2.1.2.2.1.7

IfInDiscards

Nombre de paquets supprimés sur une interface.

.1.3.6.1.2.1.2.2.1.13

ifInErrors

Nombre de paquets reçus supprimés par une .1.3.6.1.2.1.2.2.1.14 interface pour cause d’erreurs.

ifOutDiscards

Nombre de paquets qui n’ont pu être transmis par .1.3.6.1.2.1.2.2.1.20 une interface pour cause d’erreurs.

Tableau 10. Les Objets MIB pour la surveillance de l’état des interfaces

Pour pouvoir surveiller ces équipements, il est nécessaire de réaliser une surveillance par scrutation ou polling des variables de la MIB des équipements qui auront été sélectionnées[11].La surveillance par polling va permettre de détecter tout changement dans le réseau et de générer immédiatement une alerte. Cette dernière doit être rendue visible à l’istrateur réseau sur la carte topologique (en mettant en rouge l’icône correspondant à l’équipement) et éventuellement émettre un message textuel ou sonore. Ces alertes peuvent être également envoyées sous forme d’un message électronique ou SMS à la personne appropriée. La sauvegarde de ces alarmes dans des fichiers de logs permet à l’istrateur de mieux comprendre le fonctionnement du réseau et d’identifier la source des erreurs.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

49

Implémentation On a proposé une configuration de l’application afin qu’elle puisse présenter les alarmes en fonction de leur gravité. Le tableau suivant donne un exemple de configuration : Fonctionnement

Source de la cause

Présentation Couleur Blanc

Normal Problème mineur au niveau d’un routeur Problème important au niveau d’un routeur sans conséquence sur le fonctionnement du réseau. Problème fatal au fonctionnement du réseau.

Avertissement sur taux de perte supérieur au seuil prédéfini Panne alimentation et basculement sur l’alimentation de secours.

Couleur verte

Panne d’une carte d’interface sur un port Faste Ethernet.

Couleur rouge clignotante Signal sonore

Couleur orange

Tableau 11. La classification selon les gravités des alertes

4. Implémentation 4.1. •

Pratiques adoptées

Privilégier une étude descendante : du particulier au général : Exemple dans le cas de la création d’une vue de l’infrastructure nous avons commencé par l’insertion des agents (nœud), l’attachement de ces agents par des liens optiques puis nous avons é à la définition de chaque nœud et chaque liaison à part.

•

Réfléchir à la structure des données la plus appropriée.

•

Initialiser les variables.

•

Travailler sous forme de procédures publiques utilisables dans toute la feuille.

•

Définir une interface utilisateur complète.

•

Utiliser des noms de variables (frame, , bouton …) significatifs.

4.2.

Déroulement de la phase d’implémentation

La phase de développement a consisté, en premier lieu, à la mise en place du module de réception des alertes « Traps » pour simuler le socle du processus de modélisation sur lequel va se baser le module de supervision et le module d’alerte. Ces deux derniers modules ont été développés en parallèle pour être enfin intégré et constituer le noyau de supervision de

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

50

Implémentation l’application modélisée. Par la suite, la mise en place du second module d’archivage ainsi que l’ensemble de sous module de gestion des rapports d’intervention. La phase de développement s’est achevée par la réalisation du module d’interfaçage qui assure l’interaction entre l’utilisateur et l’outil de gestion. Elle prend ainsi, en charge le recueil des paramètres nécessaires au lancement du processus de notification.

4.3.

Réalisation du module de supervision

La réalisation du module de supervision se présente comme la première étape à effectuer tel qu’il constitue le socle de base pour la réalisation de tous les autres modules. L’objectif clé de cette partie est de simuler le développement du processus de supervision. L’implémentation de ce module s’articule autour du développement de trois sous modules essentiels à savoir : •

Le module de réception des alarmes: ce module aura pour objet de recevoir les « Traps » envoyées par les nœuds du réseau et de les sauvegarder pour une éventuelle consultation.

•

Le module de gestion des alarmes : ce module aura pour objet de gérer l’historique des alertes et de conserver les informations sur le changement de l’état des liaisons du réseau.

•

Le module d’alerte de l’intervenant : dès la réception d’une alerte critique ce module s’occupe de la remontée de cette alerte vers l’intervenant correspondant.

Figure 26. Les sous-modules de supervision

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

51

Implémentation

do w n Li nk

Li nk

do w n

Link down

Lin kd ow n

4.3.1. Le sous-module « Réception d’alertes »

Figure 27. La réception d’alertes

Les Traps SNMP aussi appelé NoCficaCon en SNMP version 2 sont des messages envoyés par les agents SNMP intégrés dans les équipements, les systèmes d'exploitations, les applications vers un Manager SNMP pour l'informer d'un changement d'état, d'une anomalie etc. Sotetel Net Manager intègre un gesConnaire de Traps SNMP v1 et de NoCficaCon SNMP v2c. Pour simplifier nous uCliserons la terminologie Trap pour ces deux types. Un Trap est identifié par un numéro unique (OID - Object IDentifier) déclaré dans un système de nommage. Les Traps sont reçus dans le gestionnaire de Traps de SNM, une fenêtre liste des Traps les plus récents. Cette liste est limitée en longueur. Tous les Traps sont aussi sauvegardés dans des fichiers en format texte (txt)à raison de un fichier par 24 heures. L'historique de tous les Traps est ainsi sauvegardé. Un Trap dans le gestionnaire de Traps de SNM est constitué des champs suivants : Le nom de la community. la date et l'heure de réception du Trap, le nom et l'adresse IP de l'agent SNMP à l'origine de cette événement, l'identifiant de l'objet SNMP : en format texte s'il est présent dans les MIB, sinon au format numérique. le type de Trap : Authentication, LinkUp, LinkDown... Le numéro spécifique au Trap « Enterprise »

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

52

Implémentation

Les Traps présents dans le gestionnaire de Trap peuvent être acquitté individuellement ou par groupe. Un Trap acquitté est toujours visible dans la liste mais en grisé. Les Traps présents dans la liste peuvent être supprimé individuellement ou par groupe. Un Trap supprimé n'est plus visible dans la liste. Il n'est pas supprimé des fichiers d'historique.

Un double click sur un Trap permet d'accéder à une vue détaillée. Cette vue détaillée permet de visualiser chaque champ individuellement et aussi de lire le descriptif du Trap à la condition que celui-ci soit défini dans un fichier de MIB (le fichier de MIB est compilé sur SNM)

Chaque Trap dispose d'un compteur totalisateur. Ce compteur comptabilise le nombre de Trap reçus d'un type donné depuis la mise sous tension de l’application.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

53

Implémentation

Les Traps peuvent être filtrés et déclencher des actions. Un seul filtre peut déclencher plusieurs actions. Les filtres sont dans une liste, à réception d'un Trap tous les filtres qui satisfont leurs conditions sont traités et toutes leurs actions réalisées. Un Trap peut déclencher la création d'un événement d’alerte, Il est possible de préciser : Le numéro d'événement généré à la réception de ce Trap Le message associé à cet événement Le niveau de criticité de l'événement

Un filtre de Trap peut engendrer une action de type : •

Génération d’une alarme sonore (fichier wave)

•

Envoi d’un E-mail

•

Envoi d’un SMS

Les actions sont réalisées par des programmes qui ont besoin de paramètres envoyés dans l’en tète. Parmi les variables de paramètres disponibles on distingue : Le nom du Trap Le nom de host dans l'annuaire du Tunisie Télécom ayant généré ce Trap L'adresse IP du host à l'origine du Trap Le niveau de l'événement (criticité) La date et l'heure d'émission du Trap (créer par l'agent SNMP) La date et l'heure de réception de ce Trap par SNM Les 10 paramètres de messages

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

54

Implémentation

4.3.2. Le sous-module « Notification par SMS »

Modem GSM

Téléphone du superviseur

SMS

T

SMS

T SMS Gateway 111.111.111.111

Figure 28. L’architecture du système d’envoi et de réception de SMS.

SMS Gateway est une application puissante et flexible, qui nous a permit d'envoyer/recevoir des messages SMS vers des appareils mobiles avec notre station de gestion [Net 5]. L’envoi d’un SMS : si un message SMS doit être envoyé, il peut être inséré dans une table de base de données utilisée pour les messages sortants. Le SMS Gateway Server surveille cette table et remet le message. La réception des accusés : Le serveur met tout message SMS reçu dans une autre table de base de données utilisée pour les messages entrants. Les messages et les numéros de téléphone sont stockés dans des fichiers Excel et une macro Excel lance le processus d'envoi.

4.4.

Réalisation du module d’archivage

La deuxième étape de ce processus consiste à générer le modèle de gestion des rapports d’interventions en termes ; de l’édition des rapports, la sauvegarde des rapports, l’exportation des rapports, ainsi que la génération des statistiques qui se base sur l’ensemble des informations illustré dans l’ensemble des rapports déjà sauvegardés.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

55

Conclusion La figure ci-dessous illustre le principe adopté pour cette deuxième phase du processus de gestion de l’archive des interventions.

Figure 29. Les sous-modules d’archivage

5. Conclusion A travers ce chapitre, nous avons illustré la phase de réalisation de l’outil «Sotetel Net Manager ». Nous avons commencé par présenter l’environnement de travail, ensuite, nous avons détaillé les étapes d’implémentation des principaux modules développés. Le chapitre suivant intitulé « Mise en œuvre et tests» est consacré à l’évaluation de la recette finale du projet par la mise en œuvre et le test de l’application de supervision et de l’application d’archivage.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

56

57

Chapitre

V Mise en Œuvre et Tests :

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Introduction

1. Introduction Au niveau de ce dernier chapitre, nous présentons, dans un premier lieu, le résultat de la mise en œuvre de notre outil « Sotetel Net Manager ». Dans un second lieu, nous présentons les différentes méthodes existantes de validation et de vérification d’un logiciel dont nous adapterons une méthode pour valider et consolider la recette de notre projet.

2. Mise en œuvre À travers cette partie, nous allons illustrer la mise en ouvre de l’outil «Sotetel Net Manager». Nous procédons, tout d’abord, à la mise en œuvre de L’application « SNM supervision » qui a pour objet la supervision de l’état des liaisons « optiques » du réseau des paramètres nécessaires à l’initialisation du contexte de génération. Ensuite, Nous procédons à la mise en œuvre de l’application « SNM archivage ». Feuille d’authentification : Cette interface constitue la fenêtre d’accueil de notre application. A travers cette fenêtre l’utilisateur s’identifie pour utiliser l’application. Cette étape met en valeur l’aspect sécurité : nous vérifions la disponibilité du compte utilisateur et nous lui attribuons les droits et privilèges nécessaires.

Figure 30. Le frame d’authentification

Voila vous avez fini l'installation vous allez vous connectez sur l'interface d' pour la première fois (/) par défaut. La première page affichée est la page d’accueil qui présente un état des ressources réseau avec les valeurs des compteurs des alertes récentes.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

58

Mise en œuvre

Figure 31. Interface d’accueil

L’interface possède plusieurs onglets qui vont vous permettre d’effectuer toutes les actions possibles :

Mappages affiche les machines disponibles dans le réseau en cours



Alertes liste les alertes en cours



affiche l’interface d’istration à partir de laquelle on peu modifier tous les paramètres de l’application



Rapports permet de générer des rapports d’intervention personnalisés.



Statistiques permet de consulter les statistiques du réseau et d’envoyer des messages à l’istration en cas de problèmes. En fonction du frame sur lequel on se positionne, le menu à gauche change et affiche les

actions correspondantes.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

59

Mise en œuvre

2.1.

Mise en œuvre de l’application « SNM supervision »

2.1.1. Maintenir Les équipements du réseau

Figure 32. Les utilitaires de surveillance

L’utilitaire SNM ping (SNM Packet Internet Groper): Le superviseur peut utiliser l’outil SNM Ping d’Utilitaire de réseau (dans //Utilitaires) pour vérifier si l’application a bien établi une connexion IP avec l’équipement réseau distant. Une connexion IP est un préalable indispensable à l’ajout de l’équipement. Si dans Utilitaire de réseau, après avoir utilisé l'outil Ping, un message du type « 64 bytes from 10.0.1.2: icmp_seq=0 El=255 Gme=0.399 ms »s'affiche, la connexion IP avec le nœud du

réseau a réussi. •

Si dans Utilitaire de réseau, après avoir utilisé l'outil Ping, un message du type « Host is down »s'affiche, la connexion IP avec le nœud du réseau n'a pas été établie. Le

superviseur doit résoudre ce problème avant d’ajouter cet agent SNMP. L’utilitaire SNM JTA (SNM Java Telnet Accès) : L’outil SNM Java Telnet Accès est un client Telnet qui permet au superviseur de se connecter à un équipement distant sur lequel est exécutée une application serveur Telnet, puis d'exécuter des commandes à partir de la ligne de commande. Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

60

Mise en œuvre Pour établir une connexion à partir de SNM JTA, il convient de sélectionner une option de connexion. Une boîte de dialogue vous invite à entrer un nom d'hôte et un type de terminal. Le nom d'hôte est l'adresse IP ou le nom DNS de l'ordinateur distant. Le type de terminal décrit le mode d'émulation de terminal qui doit être utilisé par le client Telnet. La connexion Telnet n'exige aucun traitement de la part de la station de gestion émettrice qui se contente de transmettre à l’équipement IP distant les caractères tapés au clavier et d’afficher l’écran résultant sur le moniteur local. Les opérations de traitement et de stockage sont entièrement exécutées par l’ordinateur distant. L’utilitaire de gestion SNM Mib Browser : Le « SNM Mib Browser » est au centre d'une supervision proposant des fonctions SNMP riches. Il s'agit d'une arborescence organisée, où chaque branche, chaque feuille a un identifiant unique (OID), cette arborescence est représentative des MIBs SNMP compilées dans l'application. Il permet d'obtenir des informations sur les différentes propriétés spécifiques à un objet SNMP. Il est également possible de tester sur ses équipements répondant au protocole SNMP le contenu de variables. Le « SNM Mib Browser » est un point incontournable du cœur de l'application Sotetel Net Manager pour paramétrer le suivi dans le temps de variables SNMP ou configurer les évènements issus des Traps SNMP.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

61

Mise en œuvre

2.1.2. Superviser l’état du réseau La création d’une vue : Pour construire une vue de l’architecture, le superviseur devra accéder au « créer vue ».

Figure 33. La création d’une vue

En cliquant sur l’onglet « Mappages» ensuite sur l’onglet du « vue » puis importer le fichier « vue.snm » en cliquant sur le bouton «ouvrir ». Pour lancer la supervision de l’ensemble des liaisons de cette architecture il suffit de taper le bouton « superviser ce réseau »

2.1.3. Gérer les alarmes Configuration du profil SNMP: A partir du frame « » cliquez sur «profile SNMP » dans le «profile de notification». Ces profiles pourront être associés à différents périphériques.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

62

Mise en œuvre

Figure 34. La configuration des profils

Si vous ne l’avez pas encore fait SotetelNetManager va vous demander de configurer un serveur de messagerie électronique afin qu’il puisse envoyer des alertes par mail.

Figure 35. La configuration du profile Mail

entrez le nom ou l’adresse IP du serveur de messagerie entrez si nécessaire les informations d’authentification Entrez dans « Receiver» l’adresse qui recevra les alertes. Il est recommandé d’utiliser le bouton « send a Test Message » pour vérifier que la configuration fonctionne est que vous recevez bien les messages d’alerte.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

63

Mise en œuvre Vous pouvez choisir l’adresse du destinataire qui recevra les alertes pour les périphériques associés à ce profil de notification. Vous pouvez aussi modifier le contenu du message à l’aide des listes de variables disponibles. Cliquez sur OK une fois terminé. On va maintenant choisir dans quels cas un message d’alerte doit être émis. Si le périphérique n’a pas répondu à 1 test Quand l’interface ou le port du périphérique est arrêté Quand la coupure d’une liaison optique est interprétée Si une interruption SNMP critique est reçue Quand n’importe lequel des seuils de conformité des fibres a été déé Quand l’alarme est annulée La réception des alertes Maintenant l’application sera prête à recevoir les alertes, à identifier les sources et à exécuter les processus de notification mis en place. Ces alertes seront affichées sur le « récentes » du frame « Alarmes » sous forme d’un tableau comme le présente la figure suivante :

Figure 36. La réception des alarmes

Toutes les 30 secondes, le manager SNMP effectue un test pour vérifier si les agents répondent. Si ce teste échoue, une interruption d'avertissement signalant l'échec de la

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

64

Mise en œuvre pulsation du serveur SNMP associé à l’agent désigné sera ajouté dans la table des alertes récentes. Ce problème est généralement temporaire et provoqué par une surcharge du système. Si ceGe condiCon dure 5 cycles, une interruption critique s'affiche vous indiquant que l’agent ne répond pas. L’équipement est peut-être bloqué ou arrêté. Dans les deux cas, il est impossible d’interroger la MIB de cet agent. Si la pulsation revient, un message d'annulation d'interruption indiquant que la pulsation est restaurée s’ajoute à la table.

2.1.4. Gérer les performances Dés la détection de la présence d’un événement critique dans le réseau, l’application envoi automatiquement un mail d’alerte contenant les informations nécessaires à l’istrateur qu’ils le permettent d’identifier la source du panne. En outre, et pour assurer que l’information soit transmise vers l’istrateur dans les délais convenables, On aura envoi d’un « SMS » en parallèle contenant un résumé sur l’alerte reçue. S’il s’agit d’une panne technique, ou la liaison probable d’être corrompu d’une raison ou d’une autre, l’application notifie localement le superviseur avec des alertes que se soit sonores ou visuelles.

2.2.

Mise en œuvre de l’application « SNM archivage »

2.2.1. L’initialisation de La BD des Liaisons optiques : Dans le but de créer une fiche détaillée de chaque liaison optique, dès sa mise en place on sauvegarde les valeurs d’atténuation de bout en bout ainsi que l’atténuation linéique caractéristique de la ligne. Pour avoir une base de donnée référence qui soit le plus proche possible de celle archivée dans les papiers de l’entreprise, on a procédé a simuler le réseau sous OptiSystem dont on représente une partie de l’architecture sur la figure suivante:

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

65

Mise en œuvre

Figure 37. Architecture de réseau Métro-Ethernet Métro « tunis » sous Optisystem

Le signal, ant d’un nœud à un autre, subi une dégradation appelé atténuation de bout en bout

Figure 38. 38 La dégradation de la puissance sous OptiSystem

La simulation sous Optisystem nous a permit d’extraire la liste des valeurs d’atténuations totales mesurés sur chaque liaison optique, ces valeurs sont décrit dans le tableau suivant : Liaison

Atténuation en

Atténuation en

Longueur

( )

(dBm)

(Km)

Marsa---Gammart2

-

3.116

1.5

5

Gammart2---Gammart1

-

1.414

0.899

2

Gammart1---Sidi daoued

-

3.961

4.501

20

Sidi daoued---Marsa

-

3.116

1.5

5

Tableau 12.. Liste des valeurs d’atténuations du réseau de « tunis » Etude, Planification et Gestion des réseaux Métro-Ethernet Métro

2011/2012

66

Mise en œuvre Cette étape sera réalisée une fois pour tout dès la mise en place des liaisons optiques, pour introduire ces valeurs à l’application il suffit, après avoir créé la vue et la préparée pour la supervision, d’accéder au frame « Rapports » et de remplir la valeur (en dBm) devant chaque liaison En cliquant « Terminer » ces valeur seront sauvegardées dans la base de donnée de l’application et vous aurez la possibilité de les consulter à tout moment.

2.2.2. Rédiger un rapport Après toute opération d’intervention, et pour sauvegarder une trace de cette opération, l’intervenant aura accès à l’application, précisément « /Rapports ».

Figure 39. Le frame de rédaction des rapports d’intervention

2.2.3. Générer des statistiques La génération de statistiques est un module développé pour suivre le progrès et la variation des caractéristiques de chaque liaison optique installée. Il est important de noter que la qualité des statistiques permet d'aider l’istrateur à choisir le meilleur plan d'exécution et d’avoir une vision sur l’état des liaisons optiques après chaque opération de maintenance. Les informations sur les statistiques peuvent être extraites (pour être exploitées par un logiciel tiers tel qu'Excel par exemple).

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

67

Mise en œuvre

Figure 40. La liste des interventions

Tout d’abord l’intervenant est demandé de sélectionner la liaison optique, lorsqu’il appui sur le bouton « atténuation de bout en bout », les statistiques seront générées et la grille se rempli au fur et à mesure jusqu'à ce que la barre de progression s'arrête, par défaut il y aura affichage des dix derniers mesures effectuées.

Figure 41. Frame des statistiques

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

68

Tests et validation

3. Tests et validation Le test des logiciels représente la dernière phase du processus 2TUP « Two Track Unified Process ». C’est un métier à part entière tel que le testeur devra imaginer des scénarios plausibles pouvant mettre un logiciel en défaut ainsi qu’il devra imaginer de construire des bancs de tests permettant de vérifier les fonctionnalités et les contraintes [12]. Pour la phase de test on a, en réalité, réalisé des tests tout au long de la phase de codage qui nous ont permis au fur et à mesure de l’évolution de l’application de repérer des erreurs de fonctionnement. Malgré le désire de tester notre application sur l’architecture du Tunisie Télécom, il a été impossible d’y accéder pour une multitude de raisons raisonnables : 1) Pour des raisons de confidentialité ; il été difficile d’avoir les paramètres d’accès ( et ) d’un tel équipement. 2) Pour des raisons de sécurité ; tout changement de la configuration de n’importe quel élément du réseau gênera le fonctionnement nominal de l’ensemble de ce réseau. A l’aide du logiciel GNS3 on a pu tester notre applicaCon dans un environnement fortement réaliste, les résultats ont été positifs, et on a eu la possibilité d’apporter les modifications nécessaire pour mieux répondre aux demandes exprimées par les utilisateurs finaux. Et comme « «Le test est l’exécution ou l’évaluation d’un système ou d’un composant par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus » [12]. Et pour répondre à ces deux questions : - Est-ce que le logiciel réalise les fonctions attendues ? - Est-ce que le logiciel fonctionne correctement ? Pour pouvoir mieux cerner cette problématique, différents types de classifications des tests sont possibles, nous citons:

Tests de vérification et tests de validation: les tests de vérification ont pour objet de vérifier que l’on a bien fait le logiciel (absence de défauts) alors que les tests de validation consistent à vérifier que le logiciel répond bien aux besoins.



Tests fonctionnels et tests structurels : les tests fonctionnels prennent en compte les spécifications de l’objet à tester sans tenir compte de son implémentation (tests de type « boîte noire », « black-box testing »). Ils peuvent être employés pour la vérification comme pour la validation. Les tests structurels prennent en compte le

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

69

Tests et validation code source (« boîte blanche ») et ne sont généralement pas utilisés pour la validation. Pour la validation de ses différents produits, Sotetel adopte le test fonctionnel. De ce fait, elle nous a fourni un prototype de fiche de test qui nous a servi de base pour l’élaboration de nos propres fiches de test. Dans la section qui suit nous détaillons les différentes fiches élaborées pour la validation de l’application de supervision ainsi que l’application d’archivage.

3.1.

Tests fonctionnels de l’application «SNM supervision»

Cette partie est consacrée au test fonctionnel du la supervision réseau avec l’application SotetelNetManager, en particulier le test des processus de réception d’alertes et de notification de l’istrateur. Les tableaux ci-dessous illustrent les différents scénarios choisis en détaillant pour chacun les cas de tests retenus ainsi que les jeux de données utilisés pour chaque cas.

du test

attendus

Résultats Obtenus/ Observation

d’exécution

Résultats

Date

Description

Conformité

Critique

Action N°

Fiche de test du Scénario «l’ajout d’un périphérique dans la base »

1

Mettre l'application sur la station de gestion.

L'application est déployée sur la station de gestion avec succès.

oui

Cas de Test 1 : Déploiement de l'application

L'application tourne sur la station sans aucun problème.

17/12/2011

L'application se lance et le frame d'authentification de l'application apparait au niveau du navigateur.

17/12/2011

La page d'accueil de l'application apparait en plein écran.

17/12/2011

Lancer l’exécution de l'application.

Apparition du frame d’authentification de l’application.

3

Afficher le frame d’accueil après vérification des paramètres d’authentification.

Apparition de la page d'accueil de l'application SNM.

oui

2

oui

Cas de test 2 : Lancement de l'exécution de l'application

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

70

Tests et validation Vérifier le menu qui s'affiche au niveau de la page d'accueil s'il est conforme aux règles déjà définies.

Les éléments du menu s'affichent Correctement.

Les éléments du menu s'affichent Correctement.

17/12/2011

Le formulaire d’ajout d’agent s'affiche.

17/12/2011

oui

4

5

On clique sur le bouton « » puis sur « Ajouter un agent ».

6

On remplit les case du formulaire et on clique sur « sauvegarder »

L'apparition du formulaire de l’ajout d'une entré de la table en question.

oui

Cas de test 3 : L’ajout d’un agent

oui

Ajout d’agent Ajout d’agent avec succès 17/12/2011 dans la base de données et dans la table des agents Tableau 13. Test du scénario « Ajouter d’un périphérique dans la base »

du test

attendus

Résultats Obtenus/ Observation

d’exécution

Résultats

Date

Description

Conformité

Critique

Action N°

Fiche de test du Scénario «création d’une vue »

1

Accéder au frame « » puis au « Créer vue»,

Apparition du frame de création des vues avec des outils varier de design.

oui

Cas de test 1 : Accès au frame « créer vue »

Le frame de création des vue apparait avec tous les outils de design nécessaire

17/12/2011

Tous les nœuds sont insérer ainsi que les liaison entre eux avec succès.

17/12/2011

Cas de test 3 : La création d’une vue

Ajouter les périphériques ainsi que les liaisons qui construisent le réseau.

Vue créer avec succès. oui

2

Cas de test 4 : La sauvegarde de la vue

Exporter la topologie L’exportation se Le fichier de sauvegarde 17/12/2011 du réseau dans un fait avec succès. des infos sur la topologie ficher de sauvegarde courante est exporté avec pour une éventuelle succès. utilisation. Tableau 14. Test du scénario « Création d’une vue » oui

3

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

71

Tests et validation Fiche de test du Scénario «Exécuter le processus d’alerte»

du test

Observation

d’exécution

Résultats Obtenus/

Date

Résultats attendus Conformité

Critique

Action N°

Description

Cas de test 1 : Configuration du service de mailing

Accéder au frame « » puis au « Configuration», ensuite cliquer sur le bouton « profile mail ».

Configurer le service mailing est sauvegarde des paramètres par l’application

Configuration effectuée avec succès.

17/12/2011

Configuration effectuée avec succès.

17/12/2011

oui

1

2

cliquer sur le bouton « profile SMS ».

Configuration réussite du service SMS

oui

Cas de test 2 : Configuration du service SMS

Cas de test 3 : L’envoi du mail de notification

3

L’application détecte L’ reçoit bien le 17/12/2011 la coupure, affiche mail envoyé. une notification L’SMS est envoyé avec visuelle et envoi un succès mail et un SMS vers l’ Tableau 15. Test du scénario « Exécuter le processus d’alerte »

3.2.

oui

Enlever une liaison optique entre deux routeurs et accéder au frame « Alertes »

Test fonctionnel de l’application «SNM archivage»

Fiche de test du Scénario «Rédiger un rapport d’intervention »

du test

Observation

d’exécution

Résultats Obtenus/

Date

Résultats attendus Conformité

Critique

Action N°

Description

Cas de test 1 : Accès au de gestion des rapports

Accéder au frame « Rapports» puis au « Rédiger Rapport».

Afficher un formulaire à remplir. oui

1

Apparition du formulaire plein des cases à remplir, et des options pour la gestion.

17/12/2011

Cas de test 3 : Essai de sauvegarder un rapport manquant

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

72

Conclusion Appuyer sur « Sauvegarder à la BD » avant de terminer le remplissage de toutes les cases. Tableau 16.

L’application affiche un avertissement « Informations manquantes ».

L’avertissement est bien affiché.

17/12/2011

oui

2

Test du scénario « Rédiger un rapport d’intervention »

4. Conclusion Rappelons que l’objectif final de ce travail était d’automatiser l’activité de gestion des réseaux Métro-Ethernet de l’opérateur Tunisie Télécom. Nous avons réalisé une application interactive permettant de gérer les différents traitements de cette activité et de satisfaire les besoins des différents utilisateurs impliqués dans ce processus de gestion.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

73

Conclusion Générale

Conclusion Générale La gestion de réseaux est l’un des domaines les plus complexes auxquels l’on puisse se confronter; elle cumule la distribution, le modèle objet, le temps réel, le transactionnel, la gestion d’équipements complexes. C’est en conséquence une source de coût importante pour l’opérateur, qui se voit contraint d’investir des sommes significatives et des compétences critiques dans une fonction qui semble non immédiatement rentable. Néanmoins, le souhait exprimé ici concerne la compréhension de la nécessité de la fonction Gestion de Réseaux, et son intérêt pour l’entreprise qu’est l’opérateur; ce n’est qu’à travers de la gestion efficace que ce dernier sera en mesure d’offrir les services qui le différencieront de la concurrence, tels que des Réseaux Privés Virtuels. L’objectif premier de ce projet était de concevoir et de réaliser un nouveau outil de gestion des réseaux Métro-Ethernet entièrement paramétrable, permettant de superviser l’état et la qualité des liaisons optiques et d'exploiter directement les alarmes issues des équipements de routages en extrémités et de produire automatiquement des alertes qui seront envoyés par mail ou par SMS vers la bonne personne, A cet effet, la première étape de notre travail a consisté à l’étude de la supervision des réseaux ainsi que les différentes notions qu’elle apporte au monde d’istration réseaux. Nous avons pu à travers cette étude comprendre son architecture et ses concepts de base nous permettant ainsi de voir plus claire sur la façon de l’adapter pour la conception de l’architecture de l’outil de gestion. Pour pouvoir définir nos objectifs en termes d’opération fonctionnel à implémenter, nous avons eu recours à une analyse des besoins portant sur les caractéristiques de la future application. L’ébauche de cette étude nous a permis d’identifier la structure en couches (TMN : le réseau de gestion des télécommunications) d’une telle application ainsi que le contenu et la syntaxe des différents frames à implémenter au niveau de chaque couche. L’aboutissement de ces quatre mois de travail est le développement et la mise en œuvre d’une première version de l’outil « Sotetel Net Manager » prenant en charge la gestion des réseaux Métro-Ethernet en termes de : gestion des alarmes, suivit de la qualité des fibres, surveillance de l’état du réseau,…

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

74

Conclusion Générale Comme perspectives, nous envisageons de faire évoluer cet outil vers la prise en charge de la gestion de la qualité des services offertes, ainsi que d’offrir la possibilité à l’utilisateur de personnaliser les écrans de son application via un éditeur ergonomiques prévu à cet effet. Ce stage nous a été d’une grande opportunité tel qu’il nous a permis d’enrichir nos connaissances techniques surtout dans le domaine de l’istration et de l’ingénierie des réseaux optiques, il a contribué à l’enrichissement de nos relations humaines dans un cadre de professionnel où le savoir faire et la ion du domaine ne peuvent qu’être iré.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

75

Bibliographie

Bibliographie Bibliographie [1]

MARCON André, « conditions pour le développement numérique des territoires », 2009.

[2]

JACQUET Nicolas, DUCASS Alain, « Territoires numériques : guide de mise en place de réseaux fibre optique haut débit » page 117.

[3]

ZAHND Éri, Atelier Formation, C.R.E.D.O, « Mesure et recette d’un câblage optique », page 23.

[4]

JATON Markus, VENTURA Stefano, « Gestion de réseaux IP », page 12,13.

[5]

AGOULMINE Nazim, CHERKAOUI Omar, « Pratique de le gestion de réseau », 2003.

[6]

Cisco System, « Commutateurs Cisco Catalyst 3750-E », Fiche de produit, 2006, page 11.

[7]

Optical Communication Descriptions », 2002.

[8]

FILLOT Christophe, BERENGUIER Jean-Marc, « Dynamips - Un émulateur de routeur Cisco sur PC », page 2.

[9]

Cisco Systems, « Guide des solutions réseaux », page 3.

[10]

Corporate Headquarters , «Catalyst 3750 Switch, Sofware ConfiguraCon Guide Cisco IOS », May 2004, page 565.

[11]

NGUYEN ManhTuong, « Les protocoles pour la gestion des réseaux Informatiques », Juillet 2005.

[12]

YLIAN Saint-Hilaire, « snmpv3-modulaire : une méthodologie de conception et de mise en œuvre d’un protocole de gestion de réseau », 1998, page 39.

System

Design

Etude, Planification et Gestion des réseaux Métro-Ethernet

Software, « OptiSystem Lite Technical

2011/2012

76

Netographie

77

Netographie Netographie [Net 1]

[Net2]

[Net 3]

[Net 4]

[Net 5]

KAISS BEN HAMOUDA, hGp://www.sotetel.net/index.php?opCon=com_content&view=arCcle&id=50&Itemid=43 September 2011 Jeremy Cioara., hGp://www.gns3.net/documentaCon/, September 2011. Fabrice Deblock, hGp://www.journaldunet.com/soluCons/printer/040205_cisco.shtml, Date Article : Jeudi 5 février 2004 October 2011 Mohamed Oweiss HARIGA , http://www.technologuepro.com/reseaux/ConfigurationAgent-SNMP/Configuration-snmp-sur-switch-cisco.html, October 2011 OZEKI Informatics Ltd, hGp://www.ozekisms.com/index.php?owpn=584&infoe=javasms-sdk-sms-over-t-ip, November 2011.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Glossaire

Glossaire DSP

: Délégation de Service Public.

SNMP

: Simple Network Manager Protocol.

IETF

: Internet Engineering Task Force

UIT

: Union Internationale des Télécommunications

OSI

: Open Systems Interconnection

TMN

: Telecommunication management network.

CMIP

: Common management information protocol.

OMG

: Object management group.

OMA

: Object management architecture.

OSF

: Open Software Fundation.

DME

: Distributed Management Environnement.

MC

: Management client.

MA

: Management agent.

PDU

: Packet Data Unit.

MIB

: Management Information Base.

NMS

: Network Management System

UP

: Unified Process.

XP

: eXtreme Programming.

IHM

: Interface Homme-Machine.

DSS

: Diagrammes de Séquence Système.

D

: Diagrammes de classes participantes.

UDP

: Datagram Protocol. RFC 768.

IDE

: Integrated Development Environment

CDDL

: Common Development and Distribution License.

JDK

: Java Development Kit.

JVM

: machine virtuelle Java.

GNS3

: Graphical Network Simulator 3.

OID

: Object Identifier.

SMS

: Short Message Service

SUN

: Compagnie qui a développée le langage Java

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

78

79

Annexes

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

Annexes

Annexe A : Configuration d’agent SNMP sur un Switch Cisco SNMP signifie protocole simple de gestion de réseau. Il s'agit d'un protocole qui permet aux istrateurs réseau de gérer les équipements du réseau et de diagnostiquer les problèmes de réseau. •

Configuration par défaut de SNMP :

Dispositif SNMP community strings

SNMP TrapReceiver SNMP Traps

•

Arrangement de défaut • Read-Only : Public • Read-Write : Privé • Read-Write-all : Secret Aucun n'a configuré Aucun n'a permis

Configuration du SNMP à partir de la CLI (Command Line Interface) :

• Activation du protocole SNMP snmp enable • Configuration du manager avec un délais d’expiration snmp-server manager snmp-server manager session-Cmeout 10000 • Création d’une communauté publique snmp-server community sotetel ro • Création d’une communauté privée snmp-server community sotetel rw • Désactivation de l’agent SNMP No snmp-server • Configuration de l’extinction d’équipement snmp-server system-shutdown • Configuration d’une requête trap : snmp-server host host [traps | informs][version {1 | 2c | 3 [auth | noauth | priv]} ] community-string [udp-port port] [notification-type] snmp-server host 192.168.0.40 snmpv1 public • Configuration d’un nouvel utilisateur snmp-server name [groupname remote ip-address [udp-port port] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth- [priv des56 priv ]] [access access-list] Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

80

Annexes snmp-server onegroupone v1 •

Configuration et règles de filtrage

Il est possible d’affecter des règles de filtrage (Access-List) aux consultations SNMP. Ce filtrage offre un complément de sécurité car il permet d'autoriser une adresse IP ou un rang d'adresses IP à communiquer avec l'agent. access-list 1 permit 192.168.0.30 access-list 2 permit 192.168.0.31 snmp-server community sotetel RO 1 snmp-server community sotetel RW 2 Le paramètre « snmp-server » défini et active le serveur SNMP. Après validation de cette commande, les informations SNMP seront accessibles. •

La liste 1 définie les adresses IP ayant accès en lecture seule (Read Only - RO) aux informations diffusées sous le paramètre communauté « sotetel ».

•

La liste 2 définie les adresses IP ayant accès en lecture / Ecriture (Read/Write - RW) à ces mêmes informations.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

81

Annexes

Annexe B: Présentation du logiciel Optisystem Les systèmes de la communication optiques présentent une complexité dans leur modélisation et leur simulation. Le dessin et analyse de systèmes incluent des composants non linéaires et des sources non Gaussienne du bruit, ce qui ne facilite pas la tâche du concepteur. Optisystem vient résoudre ces problèmes tant par la simplicité de son utilisation que par la grande variété de sa bibliothèque de composants. OptiSysDesign est un paquet destiné à la simulation des communications optiques en mode simulation, ce logiciel innovateur permet la conception, le test et l´optimisation virtuelle des liaisons optiques de tous types.

Figure 42. Optiwave : l’interface de l'utilisateur graphique

Optiwave permet un contrôle de l'Interface de l'Utilisateur Graphiques indépendamment de la disposition des composants optiques et du netlist. Optiwave comprend aussi une bibliothèque étendue de composants actifs et ifs dont on peut facilement faire varier leurs paramètres physiques. Edition et simulation Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

82

Annexes Le paramétrage d´un composant Lors de la conception d´un lay-out, il suffit de glisser le composant de la bibliothèque vers le lay-out pour le placer. Optisystem permet aussi le paramétrage pour chaque composant définie dans le layout. En effet, un double-clic sur le composant, permet l´affichage de ses paramètres. Modification des paramètres globale du lay-out. Par contre, avant de lancer la simulation, le lay-out présente aussi des paramètres qu’on peut contrôler par un simple doubleclic dans le lay-out.

Démarrage de la simulation Pour lancer la simulation, il suffit de taper simultanément Ctrl+F5 ou bien en accèdent directement par le menu Fichier puis Calculate…

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

83

Annexes Affichage des résultats de la simulation Enfin, pour visualiser les diverses analyses, un double-clic au dessus de l´appareil de mesure pour afficher la simulaCon en 2D ou en 3D.

Optisystem est un logiciel très performant qui permet aussi de concevoir et de modéliserdes composants optiques ce qui a été le cas lors de ce projet.

Etude, Planification et Gestion des réseaux Métro-Ethernet

2011/2012

84

‫خالصة‬

‫أداة إدارة شبكات المترو إيثرنت‬

‫جعل الطلب المتزايد على تحقيق سالمة و إعتمادية وجاھزية الشبكات من مھمة اإلشراف وتتبع المعطيات من أوكد المھام‬ ‫التي يمكن أن تناط في عھدة مھندس الشبكات وفي ھذا اإلطار إھتم مشروع ختم الدروس الذي دارت اعماله في الشركة‬ ‫التونسية للمقاوالت السلكية والالسلكية بتطوير برمجية جديدة لتأمين مراقبة توصيالت األلياف البصرية لشبكات الميتروو‬ ‫ وعلى ھذا النحو كان البد من ھذه البرمجية أن تمكن المھندسين من متابعة سير عمل‬.‫إيثرنات التي تقع تحت مسؤوليتھا‬ ‫المعدات الشبكية )تقارير وتنبيھات عند الكشف عن المشاكل( وتساعد واضعي السياسات على اتخاذ الخيارات الصحيحة من‬ ْ ‫ وستساھم ھذه البرمجية التي أطلقنا عليھا إسم "سُوتِيتَال ن‬.(‫حيث التحكم )الحجم واالتجاھات‬ ‫َات َمن َِجرْ " في استبدال ما يقرب‬ .‫من جميع األدوات المستخدمة سابقا ألداء الوظائف المختلفة لإلشراف على شبكات المترو إيثرنت‬

،‫ االحصاءات‬،‫الرصد‬،" ‫ " آس آن آم بي‬، " ْ‫ " ْت َرابِس‬، ‫ الصيانة‬، ‫ والتخفيف‬، ‫ واأللياف البصرية‬، ‫ مترو إيثرنت‬: ‫المفاتيح‬ .‫ والتنبيھات‬،‫المقاييس‬ Outil de gestion des réseaux Métro-Ethernet

Résumé

La demande toujours plus importante en matière de fiabilité, de disponibilité et de sécurité a placé depuis maintenant plusieurs années la métrologie et la supervision au cœur du métier d’ingénieur réseau. Dans ce cadre, ce projet de fin d’étude effectué au sein de Sotetel se charge de développer une nouvelle plate-forme afin de superviser les liaisons optiques des réseaux Métro-Ethernet qu’il istre. Une bonne solution de supervision doit à ce titre permettre aux ingénieurs de veiller au bon fonctionnement des équipements au quotidien (rapports d’activité, alertes sur détection de problèmes) et aux décideurs de faire les bons choix en terme de pilotage (dimensionnement, évolutions).L’application SotetelNetManager, née de ce travail, permet de remplacer la quasi-totalité des outils précédemment utilisés afin de remplir les diverses fonctions de supervision des réseaux Métro-Ethernet. Mots-clés : Métro-Ethernet, fibre optique, atténuation, maintenance, traps, SNMP, surveillance, statistiques, métriques, alertes. Management tool for Metro-Ethernet networks

Abstract

The ever increasing demand for reliability, availability, and security has placed metrology and supervision in the heart of engineering network. In this context, the main theme of this work, conducted in Sotetel, is to develop a new platform for monitoring the optical links of MetroEthernet networks. A good monitoring solution must enable engineers to ensure the proper functioning of equipment on a daily basis (reports, alerts upon detection of problems) and policy makers to make the right choices in of control (size, trends) . SotetelNetManager application, born of this work, can replace almost all of the tools previously used to fulfill the various functions of supervision of Metro-Ethernet networks. Key Words: Metro-Ethernet, fiber optics, mitigation, maintenance, traps, SNMP, monitoring, statistics, metrics, alerts. Intitule et adresse complète de l’entreprise : Entreprise : Sotetel. Adresse : Rue des Entrepreneurs Charguia II. Tél. : 71.941.100 Fax : 71.941.513 Email : [email protected]