|
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
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
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
1er 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
m2 qu'elle exploite pour l'exportation de ses produits.
II.2. Historique La societe « Les Ciments
de Bizerte » a ete creee le 1er 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.
· 8d1M11G1assRFiDiRn :
- , 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.
+ 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.
|