Conception d'un outil d'administration réseaux

	République Tunisienne Ministère de l'Enseignement Supérieur, de la Recherche Scientifique et de la Technologie --
Faculté de sciences de Bizerte	Université de Carthage	Departement informatique

Code :

Mémoire de Mastère

Pour l'obtention d'un mastère professionnel en technologie des réseaux des
télécommunications

Option : S

Intitule :

CONCEPTION ET MISE EN PLACE D'UN

OUTIL D'ADMINISTRATION RESEAUX

Réalisé par:

Zayani WALID 7 7 7 77 7 7 7 7

Ma iz OTHME^.

Au sein de
Société de ciment de Bizerte

Encadré par :
Mme. SAFA KAABI (FSB)

Dédicaces

Je dédie ce Mémoire à ma chère famille : mon père MOHAMED pour son effort et son
soutien et ma mère BEYA, pour les sacrifices pendant mes longues années d'études.

Je témoigne ma reconnaissance pour leurs encouragements.
A mes frères, et ma chère soeur SONIA.

A mes amis qui contribuent a l'achèvement de ce projet, pour leurs soutiens moraux et leurs
encouragements illimites.

Qu'ils trouvent l'expression de ma s'incère gratitude.

Dédicaces

Je dédie ce modeste travail
Au symbole de douceur, de tendresse, d'amour et d'affection
A mes parents spécialement : ma chère CHRIFA et mon père Mahmoud

A ceux qui m'ont aidé, et m'ont crée le milieu favorable
A mes frères HABIB et HAITHEM
~ ma soeur SAMEH et LAMIA
A tous ceux que j'aime, tous ceux qui m'aiment
Qui m'ont tant encouragé tout au long de mes études
Que dieu les protège

OTHMEN

REMERCIEMENTS

Au terme de ce travail nous voulons remercier infiniment toutes les personnes qui nous aident, de prés ou de loin, à la réalisation et l'aboutissement de ce travail.

C'est avec un grand plaisir que nous réserverons ces lignes en termes de gratitude et de profonde reconnaissance envers tous les enseignants de la Faculté des sciences de Bizerte en particulier, tous les enseignants du Mastère Professionnel en technologie des Réseaux des Télécommunications, et spécialement, notre encadreur Madame Kaabi Safa pour son soutien moral, ses précieux conseils et ses encouragements pour effectuer ce travail, sana oublier Messieurs les membres de jury pour l'honneur qu'ils nous ont fait de bien vouloir juger notre travail.

Nous remercions aussi le personnel du Cimenterie de Bizerte (SCB) spécialement, nos encadreur Madame Ben Issa Salima pour la confiance, le soutien moral et l'aide précieuse et efficace qu'ils nous ont prodigue depuis notre intégration a la société.

Walid et Othmen

Sommaire

Liste des figures

Introduction générale

Les réseaux informatiques, éléments essentiels des technologies actuelles des transmissions des données entre sites éloignés, leur traitement et leur restitution, touchent de plus en plus notre vie courant. On compte sur les services offerts par les réseaux pour transactions bancaire, les recherches web, la téléconférence, etc. ces services sont de ce fait devenus indispensable. Pour s'assurer que les services rendus par les réseaux soient convenable, il est nécessaire de surveiller et d'agir quand une erreur se produit. Pour ce faire, il faut obtenir les données de gestion des équipements des réseaux et, si nécessaire, contrôler ces équipements d'où l'utilité de recourir aux outils de supervision des réseaux.

Ce projet a été réalisé dans le cadre de la mise en place d'un outil d'administration réseau de

Ciment de Bizerte. Il consiste à concevoir et mise en place un système de supervision réseaux qui permettent a la fois de collecter des données sur les routeurs, les serveurs et les commutateurs, afficher une cartographie de réseaux, et notifier en cas de panne d'un équipement.

Il existe déjà un grand nombre d'outil et des plates-formes sur le marche conçus pour l'administration de grands réseaux locaux et distants. Ils sont prévus pour gérer un grand nombre d'équipement et supportent le protocole standard d'administration réseau SNMP (Simple Network Management Protocol).

Cependant la majorité des outils d'administration existant sont des systèmes propriétaires, limites du point de vue portabilité sans oublier aussi leurs couts très élèves.

Pour remédier a ces problèmes, les responsables informatiques de ciment de Bizerte m'ont

propose de réaliser un outil d'observation et de contrôle réseau qui s'adapte avec la topologie a du réseau existant et avec les applications qui tournent sur ce réseau.

Le présent document est structure en quatre chapitres.

Dans le premier chapitre nous décrivons le cadre de notre projet. Tout d'abord nous présentons l'organisme d'accueil et l'architecture du réseau de cette entreprise. Ensuite, nous traitons le sujet de travail à réaliser ainsi que ses différentes étapes.

Dans le second chapitre nous présentons les spécifications de notre solution. Le troisième chapitre est consacre a l'étude conceptuelle de cette application.

Le quatrième chapitre décrit l'implémentation et les testes de notre application.

Nous conclusion ce document en présentant les avantages apportés par l'application réalisée.

Le protocole SNMP est décrit dans l'annexe de ce document.

Chapitre 1 :

CONTEXTE GENERAL DU PROJET

Chapitre 1 : CONTEXTE GENERAL DU PROJET

Introduction

Ce chapitre represente une mise dans le contexte du projet de fin d'etude intitule conception et
realisation d'une application d'administration réseau en java ^[1] base sur le protocole SNMP

[2].

La première partie se focalise sur le cadre du projet à travers une presentation de l'organisme d'accueil.

La deuxième et la troisième partie, une definition du travail demande et de la problematique qu'il doit résoudre.

I. CADRE ET CONTEXTE DU PROJET

II.1. Organisme d'accueil Les Ciments de Bizerte (CB) est une societe anonyme qui opère dans le secteur des

liants depuis plus de cinquante ans. Elle a ete creee le 1^er novembre 1950, elle a obtenu l'autorisation d'exercice le 21 Mars 1951 et a commencé la production en 1953 dans une region appelee BAIE de SABRA, situee à 2.5 km de Bizerte.

Actuellement, la societe dispose de 7 fronts d'extraction de matière nécessaire à la production. Comme elle est dotée d'un canal d'accès maritime s'étalant sur 8000 m² qu'elle exploite pour l'exportation de ses produits.

II.2. Historique La societe « Les Ciments de Bizerte » a ete creee le 1^er novembre 1950. Son origine etait

« LES CIMENTS PORTLAND a». La production n'est commencée qu'en 1953.

En 1961, la société a procédé au développement de l'activité négoce. Elle a pris son autonomie en 1963. Et après l'émanation de sa nationalisation en 1976, la société a vécu une énorme extension de ses activités, le financement de cette phase d'extension a été réalisé par des apports nouveaux en ressources permanentes. Elle a été certifiée pour une durée de vie de 99 ans.

L'effectif global moyen est de 495 personnes, dont 43% de maîtrises et 37% d'exécution et 20% de cadres (janvier 2007).

« Les Ciments de Bizerte » a un historique riche au niveau de développement technique et social qui peut être résumé comme suit :

1950 : Création de la société.

1953 : Démarrage de la ligne (I) de cuisson (500 tonnes/jour). 1963 : Avoir un personnel à 100% tunisien.

1976 : Démarrage des travaux d'extension de l'usine.

1979 : Démarrage de la nouvelle ligne (II) de cuisson (2000 tonnes /jour).

1990 : Année record de production de clinker (975 000 tonnes /jour).

2000 : Certification ISO 9002.

2002 : Titularisation de tous les occasionnels de la société.

2002 : Augmentation du capital de la société de 20000 DT pour atteindre 34780280 DT. 2003 : Mémorisation de la cinquantaine de la société.

2005 : Début des études de mise à niveau par la réalisation des travaux de mise en état de l'usine par un investissement dépassant les 20 milliards.

2006 : Début des études de la deuxième étape du plan de mise à niveau de la société. 2008 : Certification ISO14000.

La production annuelle de ciment au « CB » correspond à peu près 21% de la production nationale, alors que sa capacité ne représente que 16.63% de la capacité de pays Comme toute entreprise.

II.3. Organisation

Les Ciments de Bizerte possède un organigramme spécifique à son patrimoine humain et

administratif se basant sur une gradation hiérarchique et dont l'aspect est le suivant :

- Figure 1 : Organigramme des ciments de Bizerte -

En interprétant cet organigramme, nous constatons que six directions sont supervisées hiérarchiquement par le Président Directeur Général. Parmi ces six on cite la direction technique centrale qui dérive en trois autres directions : direction de la qualité, direction d'exploitation et direction des études et réalisation.

En interprétant cet organigramme, nous constatons que six directions sont supervisées hiérarchiquement par le Président Directeur Général. Parmi ces six on cite la direction informatique.

II.4. Architecture du réseau de la société

Le réseau informatique de la SCB dispose d'une architecture ouverte en protocole et en topologie. Il est basé sur la famille des protocoles TCP/IP.

Nous avons visité les différents sites que relie le réseau afin d'observer l'installation et différencier les divers composants du réseau.

Le réseau de la SCB relie 3 sites à savoir :

· L'administration de ville : ou se trouve le répartiteur central. Un réseau Ethernet formé de 2 Switch montés en cascade de ports de 10 Mbits/s, reliant les postes de l'administration à ceux de l'usine à travers un routeur Cisco. Ce routeur est relié en sortie à 2 modems, l'un pour la liaison Frame Relay, l'autre pour la ligne spécialisée en back up. On trouve aussi 2 firewalls et un boitier accélérateur dont on parlera plus tard.

· L'usine : Le répartiteur contient 2 routeurs, 2 modems (FR et LS) et un Switch relié à un sous répartiteur situé dans le magasin. Dans chaque département on trouve une armoire de brassage (Switch, brins de brassage, routeur) qui assure la connexion avec ce sous répartiteur .La connexion et en fibre optique.

· La direction générale de Tunis : Le répartiteur contient un Switch, un firewall, un routeur et un modem FR. Une liaison en Frame Relay relie la direction générale à l'administration de ville.

La figure suivante schématise le réseau de la SCB :

- Figure 2 : Le réseau de la SCB-

II. TRAVAIL DEMANDE

Le département informatique de la société CIMENT de Bizerte souhaiterait superviser ses réseaux via une interface graphique sécurisée. N'importe qui ne doit pas pouvoir accéder à cette interface, elle devra donc ~tre protégée par un mot de passe. L'interface devra comporter une cartographie du réseau, présentant les différents équipements(les serveurs, les routeurs et les commutateurs). Cette cartographie devra explicitement décrire l'état des ces équipements. Permettre d'identifier l'état des ports des commutateurs sur ces mêmes machine serait un plus.

Des renseignements supplémentaires sur les différentes machines (charge CPU, espace disque, mémoire disponible, etc.) pourront être renseignés. Enfin, lorsque des problèmes surviendront, l'administrateur devra ~tre notifié par un courriel dont le contenu indiquera le service et/ou la machine défectueuse.

III. ANNALYSE DE L'EXISTANT ET PROBLEMATIQUE

A Cimenterie de Bizerte les administrateurs réseau utilisent pour gérer le réseau quelques applications comme Nagios (anciennement appelé Netsaint) est une application permettant la surveillance système et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes ont des dysfonctionnements et quand ils repassent en fonctionnement normal. C'est un logiciel libre sous licence GPL mais:

n Son interface complexe et pas très intuitive

n Son configuration fastidieuse, nombre important de fichiers de configuration

n Son configuration de bout en bout.

Et donc le but de ce projet est de trouver une solution optimale et facile a utiliser spécialement pour la gestion des serveurs, routeurs , commutateurs et le monitoring de ses équipements en premier lieu, offrir la possibilité de devenir proactif face aux problèmes rencontres en un second lieu, et finalement et le plus important, de pouvoir détecter et interpréter en un simple coup d'oeil les causes et origines des problèmes rencontres afin de les fixer le plus rapidement possible.

Pour cela on va concevoir et mise en place un outil d'administration réseau.

Se souciant de sa réputation et concerné par la satisfaction et le confort de ses clients, la société veut à tout prix éviter la confrontation à des clients mécontents d'où éviter le risque de les perdre, et ce en travaillant à offrir une meilleure qualité de services à ses clients en anticipant les pannes et en évitant les arrêts de longue durée gênant les services qui peuvent causer de lourdes conséquences aussi bien financières qu'organisationnelles.

Conclusion :

Dans ce chapitre nous avons situé le projet dans son cadre. Dans le chapitre suivant, nous passons à l'étude du système qu'on va réaliser.

Chapitre 2 :

Spécification des besoins

CHAPITRE II: Spécification des besoins

Introduction :

Dans ce chapitre, nous allons présenter les spécifications de notre solution d'administration réseau. Nous commencerons par le principe général d'administration en suite et nous terminerons par l'identification des besoins

IV. Principe général d'administration

Sur le point de l'administration, un système de réseau informatique se compose d'un ensemble d'objets qu'un système d'administration surveille et contrôle. Chaque objet est géré localement par un processus appelé agent qui transmet régulièrement ou sur sollicitation les informations de gestion relatives à son état et aux événements qui le concernent au système

d'administration.

Le système d'administration comprend un processus (manager ou gérant) qui peut accéder aux informations de gestion de la MIB locale via un protocole d'administration qui le met en relation avec les divers agents.

Le principe se repose donc sur les échanges :

· D'une part, entre une base d'informations appelée MIB (Management Information Base) et l'ensemble des éléments administrés (objets) ;

· D'autre part, entre les éléments administrés et le système d'administration.

- Figure 3 : processus agent/gérant-

V. Architecture d'administration

L'architecture classique d'administration la plus utilisée est le modèle Gérant/ Agent (Manager/Agent).comme nous l'avons montré dans le principe d'administration. Le système est composé d'une entité d'administration et des entités de gestion (NME) qui sont géré par cette entité et un protocole pour la gestion

Chaque entité dans le réseau a un Agent pour l'opération de gestion, une base de données stockées dans MIB et assume les travaux ci-dessous :

· Collecter des informations statistiques concernant à la communication, les opérations de réseau.

· Stocker les informations localement dans les MIBs.

· Répondre les commands de l'entité de contrôle de réseau, inclus : Transmet des informations statistiques à l'entité d'administration de réseau, modifie les paramètres, donne des informations d'état...

VI. Identification des besoins

Les besoins d'utilisation de l'application sont repartis en besoins fonctionnels et en besoins non fonctionnels.

Les besoins fonctionnels

Les besoins fonctionnels incluent le module gestion de l'application, module de supervision des équipements, module de gestion des faute, module de gestion de la performance et en fin module de générations des rapports et journalisations (historique).

II.5. Module de gestion d'application

Le module de gestion d'application est forme par deux sous modules principaux qui sont :

- Authentification aupres de l'interface : ce module permet à l'administrateur de sécurité de ce connecté à l'interface en introduisant le login et son mot de passe. Ce module va chercher dans la base des données le login et le mot de passe entres, s'il ya correspondance alors ouverture de session de sinon un message d'erreur afficher.

- Gestion d'utilisateurs : Ce module permet d'ajouter, modifier et _supprimer d'un autre administrateur.

Remarque : Impossible de supprimer un administrateur si le seul qui existe dans la base.

II.6. Module de supervisions des équipements

Ce module est formé par trois sous modules principaux qui sont :

- Gestions des équipements : Ce module permet d'ajouter ou supprimer un équipement (routeur, serveur ou commutateur) pour superviser l'ajout se fait simplement d'ajout l'adresse de l'équipement dans la base des données et la même pour la suppression.

- Contrôle des équipements : Ce module permet de contrôler si les équipements sont en marche ou non (UP, DOWN) et collecter les informations de chaque équipement en utilisant le protocole SNMP.

- Scanner les ports d'équipements : Ce module permet de scanner les ports de chaque équipement en entrant son adresse. Il y a deux choix de scan scan d'un seul port précis ou d'une plage des ports.

II.7. Module de gestion des fautes

Ce domaine recouvre la détection, l'isolement et la correction des pannes survenant sur un équipement. L'action curative qui en découle peut être faite à distance (si l'équipement répond) ou par un contact humain qui agira sur l'équipement. Un historique des évènements est également disponible

-Figure 4 : Gestion des fautes-

Type de panne

Les pannes peuvent ~tre d'origine interne, à caractère permanent (composant en pannes) ou externes (goulets d'étranglement, trafic intense, etc.), Cette dernière est plus difficile à détecter, car elle est à caractère aléatoire.

La gestion de faute couvre l'ensemble des fonctionnalités suivantes :

· La détection des fautes : elle comprend la préparation de rapports d'incidents de fonctionnement, la gestion de compteurs ou des seuils d'alarme, le filtrage d'événements par filtrage en amont des informations, l'affichage des dysfonctionnements.

· La localisation : on y procède au moyen de rapports d'alarme, de mesures et de tests.

· La réparation : elle consiste à prendre les mesures correctives (réaffectation de ressources, routages, limitation du trafic par filtrage, maintenance), ou encore à rétablir le service (tests de fonctionnement, gestion de systèmes de secours, etc.).

· L'enregistrement des historiques d'incidents et statistiques : la gestion des fautes ne peut se limiter à ces actions ponctuelles, nécessaires mais insuffisantes pour donner le service attendu. C'est la raison pour laquelle elle comporte aussi, d'une part, l'enregistrement d'historiques d'incidents et la compilation de statistiques qui peuvent porter sur la probabilité des pannes, leur durée, les délais de réparation et, d'autre part,

un rôle d'interface avec les usagers qui consiste à les informer des problèmes réseau et à leur donner la possibilité de signaler eux-mêmes des incidents telle que :

· La déconnexion d'un câble ;

· Une mauvaise configuration d'un équipement ;

· Une interface défectueuse d'un routeur ;

· La réinitialisation accidentelle

II.8. Module de gestion de la performance

Ce domaine comprend la collecte des données et l'analyse statistique permettant la création de tableaux de bord. Ce domaine est essentiellement lié à l'évolution du réseau (permet de planifier les changements à apporter afin d'améliorer les performances du réseau).

-Figure 5 : Gestion de Performance-

L'objectif est d'établir des statistiques à partir des paramètres du réseau.

· Débit.

· Temps de réponse.

· Taux d'erreur.

· Temps d'établissement des connexions

Elle fournit des fonctions qui permettent à des fins de planification des ressources du réseau : - De recueillir des données statistiques (taux d'erreurs, temps de transit, débit, etc.) ;

- De maintenir et analyser des journaux sur l'historique de l'état du système (événements). Les informations obtenues serviront à l'analyse et à la planification du réseau. On peut diviser cette partie en deux : l'une traitant de la gestion de la performance en temps réel et l'autre en temps différé. Pour gérer la performance d'un réseau en temps réel, il faut mettre en place la fonction suivante :

· Enregistrements des mesures de performance : cela passe par l'établissement et la mise à jour des critères et des conditions de mesure, la gestion de la collecte d'informations, le filtrage, la compilation de statistiques, l'adoption de mesures à la demande ou encore la gestion des fichiers de collecte.

II.9. Module de générations des rapports et journalisations (historique).

Notre application permet de générer des rapports de chaque équipement qui décrit tous ses informations et aussi génère des rapports des pannes.

Et permet d'enregistrer chaque trace d'administrateur dans un historique.

Les besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système mais plutôt identifient des contraintes internes et externes du système.

Les principaux besoins non fonctionnels de notre application ce résument dans les points suivants :

n Le code doit être clair pour permettre des futures évolutions ou améliorations ;

n L'ergonomie : l'application offre une interface conviviale et facile à utiliser ;

n La sécurité : l'application doit respecter la confidentialité des données ;

· Garantir l'intégrité et la cohérence des données à chaque mise à jour et à chaque insertion.

Conclusion :

Ce chapitre nous a permis de présenter le principe général d'administration réseau et d'identifier les besoins fonctionnels et non fonctionnels de notre système. Le chapitre suivant sera consacré à spécification et la conception de l'outil d'administration réseau.

Chapitre 3 : Conception

Chapitre 3 : Conception

Introduction :

Dans ce chapitre, nous allons modéliser notre application en utilisant un langage de modélisation objet qui est UML. La conception de notre application se base sur les diagrammes des cas d'utilisation(les acteurs, procédures d'administrateur), les diagrammes de classes et les diagrammes de séquences

VII. Présentation d'UML

UML (Unified Modeling Language), se définit comme un langage de modélisation graphique et textuel destiné à comprendre et à définir des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. UML modélise l'ensemble des données et des traitements en élaborant des différents diagrammes. En clair, il ne faut pas designer UML en tant que méthode mais plutôt comme une boite d'outils qui sert à améliorer les méthodes de travail.

VIII. Identification des cas d'utilisation :

Le travail effectué au sein de cette partie permet d'identifier les acteurs mis en jeu et de visualiser les scénarios de cas d'utilisation de notre application qui permettent de bien superviser une machine.

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un système.

Identification des acteurs

- Acteur : Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié.

Les acteurs qui interagissent avec cette application sont les suivants :

- Administrateur : désigne la personne responsable de la politique de sécurité et de son application par la surveillance et l'administration.

-le système (moniteur) : désigne l'entité qui s'occupe du contrôle d'une entité, de la détection des pannes et de l'envoi des notifications à et l'administrateur.

Scénario des cas d'utilisation :

Représente un ensemble des séquences d'actions qui sont réalisées par les acteurs et qui produisent un résultat observable intéressant pour un acteur particulier.

II.10. Cas d'utilisation « Gestion des comptes » :

- Figure 6 : Cas d'utilisation « Gestion des comptes » --

Seul l'administrateur réseau (super administrateur) peut créer, modifier, ajouter, et supprimer un compte et un mot de passe. Les comptes et les mots passe valides sont initialisées et enregistrées par l'administrateur réseau (super administrateur).

II.11. Cas d'utilisation « Gestion du système » :

- Figure 7 : Cas d'utilisation « Gestion du système » -

Le figure 2 nous permet de savoir les différents droit de l'administrateur réseau : l'administrateur réseau doit s'authentifier pour qu'il puisse consulter la liste des routeurs (ouvert ou fermée) ,des serveurs (ouvert ou fermée) et des commutateurs (ouvert ou fermée)disponible dans l'architecture réseau il peut aussi scanner les différents ports (ouvert ou fermée) et de consulter la performance du réseau (débit, vitesse «...)

La gestion des alertes et des notifications, et la production des rapports sont présenté par notre moniteur réseau.

IX. Diagrammes de séquences

Les diagrammes des séquences documentent les interactions à mettre en °oeuvre entre les classes pour réaliser un résultat, tel qu'un cas d'utilisation. UML étant conçu pour la programmation orientée objet, ces communications entre les classes sont reconnues comme des messages. Le diagramme des séquences énumère des objets horizontalement, et le temps verticalement. Il modélise l'exécution des différents messages en fonction du temps.

Chaque diagramme de séquence doit comprendre :

n Les acteurs intervenants dans la séquence de messages

n Une note contenant la description de la séquence représentée (idéalement le cas d'utilisation représentée)

n Les messages envoyés entre les entités (ou sur eux-mêmes) avec les paramètres pertinents

n Les lignes de vie des entités doivent montrer la création et la destruction lorsque pertinent.

n Les entités logicielles doivent avoir la bonne représentation UML : instance, instance nommée ou classe.

Le diagramme de séquences se base sur les concepts suivants :

Objet: description d'un objet du monde réel (instance de classe). Il peut ~tre une personne ou une chose.

Message : Les messages indiquent les communications entre les objets.

n Message réflexif : un objet peut envoyer à lui-même : c'est un message réflexif. Période d'activité d'objet : Dans certains cas, il représenté par la période pendant la quelle un objet est actif.

Diagramme de séquence « Authentification » : II.12. Description du scénario :

Le système affiche l'interface d'authentification.

L'utilisateur introduit un login et un mot de passe.

Le system vérifie le login et le mot de passe.

Si les données saisies sont correct le système affiche l'interface de l'application, sinon le système demande de répéter la saisie de login et mot de passe

- Figure 8 : Diagramme de séquence « Authentification » -- Diagramme de séquence « gestion des comptes » : II.13. Description du scénario :

Après l'authentification de l'utilisateur le système affiche l'interface pour l'ajout, suppression ou la modification des coordonnées d'un utilisateur

L'utilisateur introduit les nouvelles notifications (les coordonnées d'un nouvel
utilisateur ou la modification des coordonnées ou la suppression d'un utilisateur)

- Tout les notifications sont enregistrés dans la base de donné

- Figure 9 : Diagramme de séquence « gestion des comptes » - Diagramme de séquence « administration réseau)» : II.14. Description du scénario :

- L'utilisateur demande au système l'état de chaque équipement (routeur, serveur et commutateur)

- Le système scanne le réseau

- L'utilisateur peut avoir l'état de chaque équipement

- L'utilisateur demande au système l'état des ports

- Le système scanne le réseau

- L'utilisateur peut avoir l'état de chaque port

- L'utilisateur demande au système l'état de performance des équipements

Le système scanne le réseau

/ 'tMMatitMitt avoir l'état de performance des équipements

- Figure 10 : Diagramme de séquence « gestion des comptes » - Diagramme de séquence «cas des pannes » :

II.15. Description du scénario :

- L'utilisateur demande au système l'état de chaque équipement (routeur serveur et commutateur)

- Le système scanne le réseau

- En cas de panne le système produit un rapport d'erreur et envoi ses erreurs l'utilisateur via des mails ou des sms.

- Si pas d'erreur il affiche l'état des équipements.

- Figure 11 : Diagramme de séquence « gestion des comptes » -

X. Diagramme de classe

Définition

Un diagramme de classes est une collections de modélisations statiques (classes, SDINRIIIM...I, I1uiJP R(2411G'pn modèle.

· Association entre classes :

- Une association exprime une connexion sémantique bidirectionnelle entre deux classes.

- / IIIARFiDiRQUIt iW1nFi13le1Ga121KIGiLIUP P MG'REjNIN1R00Ge1FRCIERIDiRQ E sous forme de liens entre objets issus de classes associes.

· Cardinalité :

- 3 IIFisH O RRP HilG'insNIKFINTqDi SECIiFiSHXDWFILAiRQ

· Relation de dépendance :

5 HlAiRQLGPtiliMAiRcEXniGiEFFIiRn(11121RV GIRE\ROIFeIFTE0(1-1] P RGiLiFDiRI Ge E etCOP IIt GRQZRn GéSHZG, ESIPalFIMitMDIe P isIIIIIRur GI litlément dépendant).

· Association n-aire :

, Glrlit GPW IsARFiDiRQEqDi IIIiELSOs GIIGeE[ IFUAAes.

Note : De telles associations sont difficiles à déchiffrer et peuvent induire en erreur. Il vaut mieux limiter leur utilisation, en définissant de nouvelles catégories GpARFiDiRns.

· 8d1M11G¹assRFiDiRn :

- , CMCIit GVW FlIWITui110DiUMPiIDiRn IINEWinsNIKFIs G'aMIWFlIDAes.

Diagramme de classe

- Figure 12 : Diagramme de classe -

Explication du diagramme de classe

n Administrateur :

Attribut	Type		Signification	Login
String	Login de l'administrateur		Mot de passe
String	Mot de passe de l'administrateur

Méthode		Signification	Gérer les comptes ()
Ajouter, supprimer ou modifier des comptes administrateurs		Gérer les équipements ()
Ajouter ou supprimer un équipement (Routeur, serveur et Switch)		Gérer les notifications ()
Ajouter l'adresse mail de société pour recevoir les notifications.		Scanner les ports
Faire un balayage sur les ports d'équipement.		Configurer le service SNMP
Modifier la communauté et le port de service SNMP

n Système : Moniteur réseau :

Attribut	Type		Signification	Nom
String	Nom du système		Version
String	Version du système

Méthode		Signification	superviser les équipements ()
Controller les équipements		Afficher la cartographie ()
Dessiner la cartographie du réseau (UP, DOWN).		Collecter les informations ()
Collecte les informations à chaque équipement.		Générer des rapports ()
Génère des rapports pour chaque équipement.		Envoyer des alertes ()
Envoie des alertes (mail) en cas de panne.

n Equipements :

Attribut	Type		Signification	Adresse IP
String	Adresse IP d'équipement.		Nom
String	Nom d'équipement.

n Cartographie :

Attribut	Type		Signification
Routeur		Routeur		Représente le routeur sur la carte.
Serveur		Serveur		Représente le serveur sur la carte.
Commutateur		Commutateur		Représente le commutateur sur la carte.

· Mail :

Attribut	Type		Signification	Adresse mail
String	Correspond le mail de société.		Mot de passe
String	Correspond le mot de passe de compte mail.

Méthode		Signification	Recevoir les notifications
Enregistrer tous les notifications reçus.

· Rapports :

Attribut	Type		Signification	Nom
String	Nom du rapport généré.		Date
Date	Date de rapport publié.

· Historique :

Attribut	Type	Signification
Date	Date	Date d'historique.

Conclusion :

Dans ce chapitre nous avons décrit les principaux diagrammes, considères les plus importants et les plus adéquats a notre projet. Ces diagrammes sont choisis parmi les neuf diagrammes de conception UML.

Le chapitre suivant décrit les deux principales étapes de la réalisation, à savoir codage et les tests.

Chapitre 4 : Réalisation

Chapitre 4 : Réalisation

XI. Environnement du travail

II.16. Présentation

Nous décrivons dans ce chapitre l'environnement de travail requis qui est le développement d'une application réseau utilisant le protocole SNMP.

Pour qu'une application réseau puisse être mise en oeuvre, il est nécessaire que les composants réseaux qui interagissent avec l'application soient bien installes et bien configures.

En particulier le protocole SNMP qui doit être installe sur tous les postes clients. Les composants de l'environnement du travail sont :

- système d'exploitation : Windows.

- Protocoles : SNMP et UDP.

- Langage de programmation : JAVA.

II.17. Choix du protocole SNMP

Le protocole SNMP (Simple Network Mangement Protocol) est un protocole, comme son nom l'indique, qui permet d'assurer la gestion du réseau. Il permet également de contrôler un réseau à distance en interrogeant les stations qui en font partie sur leur état et configurer leur configuration, de faire des tests de sécurité et observer les différentes informations liées a l'émissions de données. Il peut même être utilise pour gérer les logiciels et bases de données liées a distance.

Le protocole SNMP est le protocole le plus adéquat a notre application, et le plus simple utiliser.

II.18. Choix de langage de programmation JAVA

Java est un langage de programmation informatique orienté objet créé par James Gosling et Patrick Naughton de Sun Microsystems. Mais c'est également un environnement d'exécution.

Java peut être séparée en deux parties. D'une part, votre programme écrit en langage Java et d'autre part, une machine virtuelle (JVM) qui va se charger de l'exécution de votre programme Java.

C'est cette plateforme qui garantit la portabilité de Java. Il suffit qu'un système ait une machine virtuelle Java pour que tout programme écrit en Java puisse fonctionner.

Avec le langage Java, vous pouvez développer, des applications Desktop, développer des applets pour vos sites web, développer des sites en JSP, des applications pour téléphone mobile. La première chose à faire est bien évidemment d'apprendre à faire des applications standalones simples.

XII. Implémentation

Introduction

Initialement nous avons utilise Netbeans 7.0.1 (Environnement de développement intégré

pour Java, Java EE, JavaFX et d'autres langages) pour simplifier de développer les interfaces de notre application.

Notre application fait appel à quinze bibliothèques .jar et contient également treize interfaces graphiques.

-Figure 13 : Bibliothèques utilisés java (.jar)-

Les Tests

? Fenêtre principale « Moniteur réseau 1.0.1 »

Conclusion

Dans ce chapitre nous avons décrit les principales images écrans de notre application. Ces images contiennent des testes réels effectues au sein de cimenterie de Bizerte.

Nous avons essaye de rendre nos programmes les plus claire possibles, pour permettre aux autre développeurs la mise à jour de cette application.

Conclusion générale

Il est largement reconnu que l'informatique support et vecteur des transmissions des connaissances joue un rôle très important dans le secteur de l'information.

A l'instar des autres facteurs de production, l'informatique est un variable facteur de progrès socio-économique au service de développement de toute notion. C'est pourquoi il est devenu imperatif majeur pour les payes en developpement de maitriser cet outil de savoir en gerant de façon optimale la production, la distribution et la consommation des connaissances pour ne pas parler du processus habituel de collecte, diffusion et traitement de l'information.

Le reseau informatique se situe dans cette optique et se veut rtre l'outil cohérent d'intégration et d'exploitation du patrimoine informationnel. Il devra ainsi transcender le cloisonnement entre administration publique, entreprises privees, universites, laboratoires de recherche, bibliothèques nationales, ... pour devenir un réseau automatise de coordination et d'échanges entre les diverses afin d'établir des complémentaires et de meilleurs synergies.

Le travail que nous avons realise a la compagnie de Ciment de Bizerte, presente dans ce rapport, consiste à developper un outil d'administration reseau, et effectue les objectifs, proposes par les specialites reseaux, qui sont les suivants :

· Exploitation du reseau (afficher la cartographie du reseau).

· Mesurer les performances et superviser les changements d'architecture du réseau.

· Detection des pannes.

· Notification (mail).

Pour concretiser ces objectifs nous avons adopte une demarche simple et claire.

Nous avons suivi les etapes de cette demarche en decrivant dans un premier lieu les besoins à satisfaire.

Pour la conception, nous avons la methode UML. Nous avons construis les trois principaux diagrammes à savoir : le diagramme de cas d'utilisation. Celui de classe, qui permet à la fois de mettre en evidence les besoins specifies et nous faciliter les taches de programmation.

A la dernier étape du projet, nous avons réalisé la majorité des objectifs souhaites en utilisant un langage puissant de programmation à savoir JAVA.

Enfin, nous avons réalisé une application (Client-serveur) permettant de superviser et contrôler le réseau de compagnie, mais ce dernier très couteux de point de vue temps de processeur, ce qui est une solution non optimale.

BIBLIOGRAPHIE

+ LIENS INTERNET:

[1]Tutoriel SNMP:

http://ram-0000.developpez.com/tutoriels/reseau/SNMP/

[2]Cours Administration Réseau : http://www.babafou.eu.org/ensta/b1-4/b1-4.pdf

[3]Site Expliquant Les MIBs SNMP : http://irp.nain-t.net/doku.php/215snmp:40_les_mibs

+ HELP :

J'ai utilise les MSDN de Netbeans 7.0.1, qui m'ont aide a la programmation en JEE.

ANNEXE

I. Présentation du protocole SNMP 49

II. Historique 49

III. Architecture globale 54

IV. Les messages SNMP 56

III.1. Les messages du superviseur SNMP vers l'agent SNMP 56

III.2. Les messages de l'agent SNMP vers le superviseur SNMP 56

III.3. Les messages entre agents SNMP 57

V. La MIB 57

IV.1. Vue générale 57

IV.2. Les fichiers MIB 60

VI. Les agents SNMP 61

VII. Les outils SNMP 61

Annexe : Le PROTOCOLE SNMP

XIII. Présentation du protocole SNMP

Devant la véritable explosion des réseaux (que ce soient des réseaux internes à l'entreprise ou bien l'Internet lui-même) et leur importance primordiale dans une infrastructure (une panne de réseau se traduit bien souvent par un arrêt du travail), les besoins de superviser et surtout de diagnostiquer rapidement les problèmes sont devenus des préoccupations majeures. De plus, la complexité des équipements réseau a rendu nécessaire une approche permettant de synthétiser ces informations.

Les protocoles utilisés avant SNMP (pour Simple Network Management Protocol) étaient les protocoles Telnet et FTP permettant de se connecter directement à la console de l'équipement. Le problème de ces protocoles était qu'ils n'offraient pas une vue synthétique de l'infrastructure et qu'ils ne séparaient pas suffisamment les deux métiers différents que sont la supervision et l'administration.

Le protocole SNMP a longtemps cohabité avec un autre protocole CMIP/CMIS qui est plutôt un protocole OSI, alors que SNMP est plutôt soutenu par l'IETF. Cette cohabitation ainsi que la volonté d'une convergence entre les deux protocoles font que certains standards ont été employés avec SNMP (ASN.1, encodage BER, utilisation des MIBs...).

Ce document a pour but de présenter le protocole de supervision réseau SNMP ainsi que les différents éléments qui le constituent.

XIV. Historique

Le protocole SNMP a commencé à émerger dans les années 1980 et a évolué en plusieurs versions.

· SNMPv1 : c'est la première version du protocole. La sécurité de cette version est minimale, car elle est basée sur la connaissance entre les parties d'une chaîne de caractères appelée "communauté".

· SNMPsec : le but de cette version est de combler une lacune de la version précédente SNMPv1, la sécurité. Cette version, désormais largement oubliée, a été peu implémentée.

·

RFC	Titre de la RFC	Statut
RFC 1155	Structure and Identification of Management Information for TCP/IP-based Internets	standard
RFC	Management Information Base for network	historique

SNMPv2p : beaucoup de recherches ont été entreprises pour mettre à jour le protocole SNMPv1. Il en résulte l'apparition de nouvelles requêtes protocolaires ainsi que de nouveaux types de données. La sécurité reste basée sur les groupes d'utilisateurs de SNMPsec.

· SNMPv2c : cette version du protocole est appelée "community string based SNMPv2". Elle améliore encore les requêtes protocolaires par rapport à SNMPv2p et utilise la sécurité par chaîne de caractères "communauté" de SNMPv1.

· SNMPv2u : cette version du protocole utilise les requêtes et les types de données définis par la version SNMPv2c, mais la sécurité est basée sur les usagers.

· SNMPv2* : cette version combine le meilleur de SNMPv2p et de SNMPv2u. Les documents de cette version n'ont jamais été officiellement publiés, il est toutefois possible de retrouver des copies de ces documents sur le site web de SNMP Research .

· SNMPv3 : cette version, supportant les "proxies", est une combinaison de la sécurité basée sur les usagers, les types et les opérations définis dans SNMPv2p. La sécurité est basée sur les versions SNMPv2uet SNMPv2*.

Actuellement, les versions les plus utilisées sont (par importance d'utilisation) : SNMPV1, SNMPV3 et SNMPV2c.

Le fait que la version 1 de SNMP perdure de nos jours s'explique par plusieurs facteurs :

· d'une part, les infrastructures déployées en version 1 ne sont plus modifiées sous prétexte que l'on ne modifie pas quelque chose qui fonctionne ;

· d'autre part, les nouvelles versions de SNMP ont été implémentées avec beaucoup de retard par les différents équipementiers. En effet, en parallèle avec SNMP, il existait un autre protocole appelé CMIP (CMOT Over TCP-IP), et les équipementiers ont été très attentistes pour savoir quel protocole allait réellement émerger ;

· et enfin, le protocole SNMPv1 est un protocole très simple qui demande peu de ressources lors de son implantation sur un petit équipement (une imprimante ou un hub par exemple).

Les tableaux suivants synthétisent les différentes versions et leurs RFC respectives :

· Version 1 - 1990

1156	management of TCP/IP-based internets			RFC
Simple Network Management Protocol (SNMP)	historique		1157

? Version 2c (classique) - 1993

RFC	Titre de la RFC		Statut	RFC 1441
Introduction to version 2 of the Internet- standard Network Management Framework	historique, proposé comme standard		RFC 1442
Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)	standard proposé, remplacé par RFC-1902		RFC 1443
Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)	standard proposé, remplacé par RFC-1903		RFC 1444
Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)	standard proposé, remplacé par RFC-1904		RFC 1445
Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)	historique		RFC
Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)	historique		1446
Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)	historique		RFC 1448
Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)	standard proposé, remplacé par RFC-1905		RFC 1449
Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)	standard proposé, remplacé par RFC-1906		RFC 1450
Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)	standard proposé, remplacé par RFC-1907		RFC
Manager-to-Manager Management	historique

1451	Information Base			RFC
Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework	standard proposé, remplacé par RFC-1908		1452

? Version 2 - 1996

RFC	Titre de la RFC		Statut	RFC 1901
Introduction to Community-based SNMPv2	historique, proposé comme expérimental		RFC 1902
Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)	standard, remplacé par RFC-2578		RFC 1903
Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)	standard, remplacé par RFC-2579		RFC 1904
Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)	standard, remplacé par RFC-2580		RFC
Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) (3416)	standard, remplacé par RFC-3416		1905
Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) (3417)	standard, remplacé par RFC-3417		RFC 1907
Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) (3418)	standard, remplacé par RFC-3418		RFC 1908
Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework (2576)	standard, remplacé par RFC-2576

? Version 3 - 1999

RFC	Titre de la RFC		Statut	RFC 2571
An Architecture for Describing SNMP Management Frameworks	standard, remplacé par RFC-3411		RFC 2572
Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)	standard, remplacé par RFC-3412		RFC
SNMP Applications	standard, remplacé par RFC-3413		2573
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)	standard, remplacé par RFC-3414		RFC 2575
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)	standard, remplacé par RFC-3415

· Versions 2 et 3 - 2000-2002

RFC	Titre de la RFC		Statut	RFC 2576
Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network ManagementFramework ^k	standard proposé		RFC 3411
An Architecture for Describing Simple Network ^kManagement Protocol (SNMP) Management Frameworks	standard d		RFC 3412
Message Processing and Dispatching for the ^SimpleNetwork Management Protocol (SNMP) )	standard		RFC 3413
Simple Network Management Protocol ^(SNMP) ^Applications	standard d		RFC
User-based Security Model (USM) for version 3 of ^fthe Simple Network Management Protocol (SNMPv3)	standard d		3414
View-based Access Control Model (VACM) for ^theSimple Network Management Protocol (SNMP) )	standard		RFC 3416
Version 2 of the Protocol Operations for the ^SimpleNetwork Management Protocol (SNMP) )	standard		RFC 3417
Transport Mappings for the SimpleNetwork ^kManagement Protocol (SNMP) )	standard		RFC 3418
Management Information Base (MIB) for the ^SimpleNetwork Management Protocol (SNMP) )	standard

XV. Architecture globale

Les buts du protocole SNMP sont de :

· connaître l'état global d'un équipement (actif, inactif, partiellement opérationnel...) ;

· gérer les évènements exceptionnels (perte d'un lien réseau, arrêt brutal d'un équipement...).

· analyser différents métriques afin d'anticiper les problèmes futurs (engorgement réseau...).

· agir sur certains éléments de la configuration des équipements.

Les différents éléments que l'on peut identifier avec le protocole SNMP sont synthétisés par le schéma ci-dessous.

- Figure 1 : Architecture SNMP globale -

· Les agents SNMP : ce sont les équipements (réseau ou serveur) qu'il faut superviser.

· Le superviseur SNMP : c'est une machine centrale à partir de laquelle un opérateur humain peut superviser en temps réel toute son infrastructure, diagnostiquer les problèmes et finalement faire intervenir un technicien pour les résoudre.

· Le protocole SNMP : c'est le protocole utilisé par les agents SNMP et leur superviseur pour communiquer entre eux.

· La MIB : ce sont les informations dynamiques instanciées par les différents agents SNMP et remontées en temps réel au superviseur.

· Les outils SNMP. Ce sont les différents utilitaires utilisés par le superviseur pour l'aider à diagnostiquer un problème. Ces différents outils sont aussi utilisés lors de la configuration du superviseur pour prendre en compte les spécificités de l'infrastructure.

XVI. Les messages SNMP

Les messages du superviseur SNMP vers l'agent SNMP
Les messages envoyés par le superviseur SNMP vers l'agent SNMP sont :

· Message "Get Request" : ce message permet au superviseur d'interroger un agent sur les valeurs d'un ou de plusieurs objets de la MIB.

· Message "Get Next Request" : ce message permet au superviseur d'interroger un agent pour obtenir la valeur de l'objet suivant dans l'arbre des objets de l'agent. Ce message permet de balayer des objets indexés de type tableau.

· Message "Get Bulk Request" : introduite avec la version 2 du protocole SNMP, ce message permet de mixer les messages "Get Request" et "Get Next Request" pour obtenir des blocs entiers de réponses de la part de l'agent.

· Message "Set Request" : ce message permet au superviseur de positionner ou modifier la valeur d'un objet dans l'agent.

Les messages de l'agent SNMP vers le superviseur SNMP Les messages envoyés par l'agent SNMP vers le superviseur SNMP sont :

· Message "Get Response" : ce message est utilisé par l'agent pour répondre aux messages "Get Request", "Get Next Request" et "Get Bulk Request" envoyés par le superviseur ;

· Message "Trap" : ce message est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent n'attend pas d'acquittement de la part du superviseur.

· Message "Notification" : introduit avec la version 2 du protocole SNMP, ce message est similaire au message "Trap". Il est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent n'attend pas d'acquittement de la part du manager.

· Message "Inform" : introduit avec la version 2 du protocole SNMP, ce message est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent attend un acquittement de la part du superviseur et il y aura une retransmission en cas de non réponse. Ce message peut aussi être utilisé pour un dialogue superviseur - superviseur.\

Les messages entre agents SNMP

Le seul message envoyé entre les agents SNMP est :

· Message "Report" : introduit avec la version 2 du protocole SNMP mais jamais implémenté, ce message permet aux différents agents de communiquer entre eux (principalement pour remonter des problèmes de traitement des messages SNMP).

XVII. La MIB [3]

II.19. Vue générale

Comme on a commencé à le voir dans le paragraphe précédent, SNMP définit deux choses, le protocole, c'est-à-dire la façon dont est transportée l'information et les informations dynamiques, fournies par les différents agents SNMP. Ces informations sont spécifiées dans ce que l'on appelle la MIB (Management Information Base).

La MIB est un ensemble structuré d'informations organisé sous la forme d'un arbre hiérarchisé de la même manière que l'arborescence des domaines Internet. Chaque information dans cette hiérarchie est identifiée par son OID (Object Identifier). Par exemple, l'objet ifDescr est identifié par son OID 1.3.6.1.2.1.2.2.1.2.

Comme on peut le voir dans l'exemple, un OID est une séquence de nombres séparés par le caractère "." (Point).

Le début de l'arborescence des OID défini dans les différentes RFC est le suivant :

- Figure 2 : La MIB

De même que pour le DNS, les différentes parties de la MIB sont définies dans différents fichiers MIB. Chaque fichier MIB a la responsabilité d'une branche particulière de la MIB. Ainsi, on trouve par exemple les fichiers MIB suivants :

· SNMP - SMI: RFC 1155 - Defines the Structure of Management Information (SMI).

· MIB-I : RFC 1156 - Historically used with CMOT , not to be used with SNMP ;

· SNMPv2-SMI : RFC 2578 - Structure of Management Information Version 2 (SMIv2).

· MIB-II: RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets.

· SNMPv2-MIB: RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP).

· TCP-MIB: RFC 4022 - Management Information Base for the Transmission Control Protocol (TCP).

· UDP-MIB: RFC 4113 - Management Information Base for the User Datagram Protocol (UDP).

· IP-MIB : RFC 4293 - Management Information Base for the Internet Protocol (IP) ;

· IF-MIB: RFC 2863 - The Interfaces Group MIB.

· ENTITY-MIB: RFC 4133 - Entity MIB (Version 3).

· ENTITY-STATE-MIB : RFC 4268 - Entity State MIB.

· ALARM-MIB : RFC 3877 - Alarm Management Information Base (MIB).

· FC-MGMT-MIB : RFC 4044 Fibre Channel Management MIB.

· FIBRE-CHANNEL-FE-MIB : RFC 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard.

· HPR-IP-MIB: RFC 2584 - Definitions of Managed Objects for APPN/HPR in IP Networks.

· et beaucoup d'autres MIB encore.

Il y a une petite particularité à signaler dans l'arbre de la MIB, il s'agit de la branche "private entreprises" (OID 1.3.6.1.4.1). Cette branche permet aux différentes entreprises de gérer leurs MIB spécifiques. Chaque entreprise se voit attribuer un OID unique et elles ont ensuite le droit de décrire leurs OID spécifiques en dessous de leur OID d'entreprise. La gestion de la

branche d'une entreprise est entièrement laissée à cette entreprise. Les différents OID d'entreprises sont alloués par l'IANA. On retrouve par exemple :

· Cisco avec un OID 1.3.6.1.4.1.9.

· HP avec 1.3.6.1.4.1.11.

· Novell avec 1.3.6.1.4.1.23.

· et beaucoup d'autres entreprises encore.

II.20. Les fichiers MIB

Comme on a pu le voir dans le paragraphe précédent, la MIB est organisée sous la forme d'un arbre hiérarchisé qui contient des informations et chaque portion de l'arbre est décrite par un fichier MIB particulier. Tâchons de voir maintenant ce qu'est un fichier MIB.

Tout d'abord, un fichier MIB est un fichier texte. Il contient la spécification de différents OID. Pour chaque OID, cette spécification comprend :

· un OID unique, dans l'arbre des OID. Par exemple 1.3.6.1.2.1.1.3.

· un nom générique. Par exemple sysUpTime ;

· une description de cet OID. Par exemple, "The time (in hundredths of a second) since the network management portion of the system was last re-initialized.".

· son type. Par exemple TimeTicks. Il existe différents types possibles de données qui permettent de couvrir tous les besoins ;

· son statut. Par exemple mandatory. Les différents statuts possibles sont "mandatory", "optional", "obsolete".

· son mode d'accès. Par exemple read-only. Les différents accès sont "read-only", "read-write", "write-only", "not-accessible".

Quelques difficultés courantes avec les MIB :

· Disponibilité du fichier MIB. S'il n'est pas nécessaire de disposer de la MIB d'un équipement pour le superviser, il est parfois difficile voire impossible de comprendre le rôle des OID de cet agent ou de deviner à la suite de quel événement va être envoyé un message "Trap" au superviseur. La seule référence reste le fichier MIB de l'équipement et ce fichier est parfois difficile à trouver.

· Erreur de syntaxe. Il est très courant de trouver des fichiers MIB comportant des erreurs de syntaxe. Le dernier exemple que j'ai vécu, est la ligne suivante tirée du fichier d'un équipementier réseau qui faisait planter le compilateur de MIB. Il y avait un double commentaire (le double caractère '-'), et la norme ASN.1 est très claire à ce

sujet : un commentaire commence avec le double caractère '-' et se termine à la fin de la ligne ou alors au double caractère '-' suivant présent sur la même ligne. En conclusion, il n'est pas exclu de trouver des erreurs de syntaxe dans un fichier MIB (même écrit par un équipementier réseau renommé). Complétude du fichier MIB. Parfois aussi, on trouve des MIB dont la description textuelle des OID est vide, ce qui n'aide pas beaucoup à leur compréhension. De même, il est souvent impossible de connaître de manière fiable la liste des OID (on parle des varbinds) portés par un message "Trap". Il faut alors avoir recours à un analyseur de protocole pour connaître cette liste.

XVIII. Les agents SNMP

Un agent SNMP est un logiciel implanté sur un équipement à superviser. Il s'agit souvent d'un équipement réseau (switch, hub, routeur...) mais on trouve aussi des agents sur des serveurs.

Le rôle d'un agent SNMP est :

· d'instancier les différentes variables de la MIB spécifiques à cet équipement ;

· de mettre à jour les valeurs dynamiques de ces différentes variables ;

· de recevoir les requêtes SNMP envoyées par le superviseur SNMP et d'y répondre ;

· d'envoyer les messages SNMP "Trap" ou "Inform" au superviseur SNMP pour le prévenir d'un événement exceptionnel sur l'équipement ;

· de gérer la sécurité des accès aux variables de la MIB conformément au modèle de sécurité mis en place.

Un agent SNMP ne connaît pas et n'a pas besoin de connaître son fichier MIB. Il sait quelles variables MIB il doit instancier, leur type et comment les mettre à jour. C'est soit codé en dur dans le code, soit cela fait partie d'un fichier de configuration annexe qui n'a rien à voir avec un fichier MIB.

XIX. Les outils SNMP

Lorsque l'on commence à s'intéresser au protocole SNMP, il est tôt ou tard nécessaire d'utiliser différents outils spécifiques pour déboguer son environnement SNMP :

? Ping : outil de test de la connectivité réseau.

· Traceroute : un autre outil de test de connectivité réseau qui affiche en plus la route empruntée ;

· La suite d'outils Net-SNMP. Il s'agit d'une collection de petits outils rigoureusement indispensables qui permettent d'envoyer ou de recevoir des requêtes SNMP. On trouve, entre autres, l'excellent outil "snmpwalk" qui permet d'interroger un équipement pour connaître tous les OID gérés par celui-ci. Ces outils ont été portés dans de nombreux environnements ;

· SnmpB. Il s'agit d'un outil qui permet de lire et d'afficher sous forme graphique un fichier MIB. De plus, il est doté de l'équivalent "snmpwalk" pour afficher les OID gérés par un équipement quelconque. Il est de plus capable de recevoir les trap SNMP.

· Wireshark : il s'agit d'un analyseur de protocoles très complet qui permet, entre autres, d'analyser très finement les trames protocolaires SNMP.

· Getif : il s'agit d'un outil graphique gratuit fonctionnant sous environnement Microsoft regroupant plusieurs outils d'aide à l'analyse des problèmes réseau (ping, traceroute, nslookup...). Il dispose aussi d'outils orientés SNMP.

· OidView : il s'agit d'un outil graphique payant fonctionnant sous environnement Microsoft. Il dispose des principaux outils SNMP et aussi d'un MIB Browser.

· iREASONING : il s'agit d'un éditeur de logiciels (avec donc des solutions payantes) qui dispose de beaucoup d'outils SNMP.

· SNMP4J : il s'agit d'une API et d'une librairie SNMP open source sous licence apache v2 pour environnement Java.

· Java SNMP Package : il s'agit d'une autre API et d'une librairie SNMP gratuite pour environnement Java. Il semble qu'elle soit un peu à l'abandon.

· libsmi : il s'agit d'une bibliothèque "open source" qui permet de gérer les fichiers MIB.

Résumé

Le présent travail s'inscrit dans le cadre du projet de fin d'études pour l'obtention du diplôme de Mastère Professionnel en Technologies des Réseaux des Télécommunications. L'objectif de ce projet est de concevoir et réaliser une application permettant d'administrer (superviser) le réseau. Ce projet a été effectue au sein de la Cimenterie de Bizerte (SCB).

Mots clé : SNMP, MIB, UML, JAVA.