R f :2007/II2/Sujet N 16
A-U :2007-2008
Minist re de lEnseignement Sup rieur,de la
Recherche Scientique et de le Technologie
Universit Manouba
cole Nationale des Sciences de LInformatique
Rapport de Stage dImmersion en Entreprise
R alis par
Amri Rahma
Ben Yahia Nesrine
Sujet
Conception et r alisation dune application web-based
pour la supervision des r seaux
Nom du responsable : Mr. Slim JARRAYA
Encadr par : Mr. Riadh BEN NEJI
Organisme :
Adresse : Kasba
T l : 71 901 717 Fax : 71 900 777
Courrier : ..........
Signature de lencadrant
Mr. Riadh BEN NEJI
2
Remerciements
Nos remerciements les plus chaleureux vont particuli rement aux gens qui, sans
leur aide inestimable, ce stage naurait jamais t men bien.
Nous tenons remercier tout dabord nos familles qui nous ont fournis le soutien
moral et nancier.
Notre reconnaissance sadresse essentiellement notre encadrant M r.RiadhBenN eji
pour ses conseils pr cieux qui nous ont guid s tout au long de ce stage et qui nous ont
aid s norm ment accomplir ce travail et surtout pour sa grande disponibilit .
Nous remercions pareillement tous les membres de jury davoir accepter de juger
notre travail.
Finalement, nous sommes reconnaissantes tous nos coll gues qui nous ont tou-
jours soutenu pendant la r alisation de notre travail.
3
Table des mati res
Introduction G n rale
1 Pr sentation g n rale
Introduction . . . . . . . . . . . . . .
1.1 Pr sentation de lorganisme .
.
.
1.1.1 Pr sentation g n rale . .
.
.
.
.
.
.
.
.
.
.
.
.
1.1.2 Domaines dactivit nationales .
1.1.3 Activit s internationales .
1.2 Contexte et probl matique . .
1.3 Organisation du rapport . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Etude Th orique
Introduction . . . . . . . . . . . . . .
.
2.1 Mod lisation de la gestion de r seaux .
2.2 Le protocole SNMP . . . . . . .
.
.
.
.
.
.
.
.
.
2.2.1 Pr sentation . . . . . . .
.
2.2.2
Fonctionnement . . . . . .
2.2.2.1
Les agents . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.2.2.2
Les syst mes de management de r seaux .
2.2.3 Les services SNMP . . .
.
2.3 La MIB . . . . . . . . . . . . . . .
2.3.1 Pr sentation . . . . . . .
.
2.3.2
Structure de la MIB . . . .
2.3.3 La MIB-II
. . . . . . . .
.
3 Etudes pr alables
3.1 Etude de lexistant
. . . . . . .
3.1.1 MRTG . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
1
2
2
2
2
3
3
3
4
5
5
5
6
6
7
7
7
8
9
9
9
11
13
13
13
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Publicité
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATI RES
3.1.2 Cacti
. . . . . . . . . . .
3.1.3 Nagios . . . . . . . . . .
3.2 Critique de lexistant . . . . . .
4 Sp cication
Introduction . . . . . . . . . . . . . .
4.1 Objectif
. . . . . . . . . . . . .
4.2 Sp cication des besoins . . .
.
.
.
.
.
.
4.2.1 Les besoins fonctionnels .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.2.2 Les besoins non fonctionnels .
4.3 Diagrammes USE-CASE . . .
.
4.3.1 USE-CASE niveau z ro .
.
.
4.3.2 USE-CASE niveau rafn .
4.4 Diagrammes de s quence
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.4.1 Lajout dun nouveau enregistrement
4.4.2 Consultation des informations .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Conception
Introduction . . . . . . . . . . . . . .
5.1 Choix de la technologie JSP .
.
5.2 Architecture g n rale de lapplication .
.
5.3 Architecture g n rale des classes java de lapplication .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.3.1 Le paquet SN M P . . .
5.3.2 Le paquet appl
. . . . .
5.4 Diagramme de classes . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.4.1 Diagramme de classes du paquet appl .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.4.2 Description des principales classes du paquet appl
5.4.2.1
La classe SNMPSample .
5.4.2.2
La classe ConnexionBD .
5.4.2.3
la classe Thread .
.
.
.
.
.
.
.
.
5.5 Structure de la base de donn es utilis e .
la classe InOutGraph .
5.4.2.4
.
6 R alisation
Introduction . . . . . . . . . . . . . .
.
6.1 Environnement mat riel et logiciel
.
.
6.1.1 Environnement mat riel .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Publicité
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ii
13
14
14
15
15
15
15
15
16
17
17
18
19
19
19
22
22
22
23
24
24
25
25
25
27
27
27
27
27
27
29
29
29
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATI RES
6.1.2 Environnement logiciel
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.1.3 Choix de la biblioth que graphique JFreeChart .
6.2 Description des fonctionnalit s de lapplication .
.
.
.
.
.
.
.
.
6.2.1 Pr sentation de la page daccueil de lapplication .
6.2.2 Gestion de lacc s aux informations .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.2.3 Gestion des quipements r seaux et des comptes utilisateurs
6.2.4.2
6.2.4.1
6.2.4 Pages g n r es au cours de la supervision .
La page Summary .
La page Capacity .
.
La page Performance .
La page Trafc Analysis
La page Info . .
6.3 Chronogramme . . . . . . . . .
6.2.4.3
6.2.4.4
6.2.4.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Publicité
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
30
31
31
31
33
34
36
36
37
38
40
41
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Table des gures
2.1 Exemple dune architecture SNMP .
.
.
.
.
2.2 Les syst mes de management de r seaux .
2.3 Exemple d change SNMP . . .
2.4 Larbre des objets de la MIB . .
2.5 Description ASN.1 de ifDescr .
.
.
.
.
.
.
.
.
.
.
.
.
2.6 Les principales branches de la MIB II .
4.1 Use Case niveau z ro . . . . . .
4.2 Use Case niveau z ro . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.3 Diagramme de s quence de Lajout dun nouveau enregistrement .
4.4 Diagramme de s quence de Consultation des informations .
5.1 Architecture JSP . . . . . . . . .
.
.
.
.
.
5.2 Architecture g n rale de lapplication .
.
.
.
.
.
.
.
.
.
.
5.3 Architecture globale des classes java d velopp es
5.4 Diagramme de classes du paquet appl
6.1 Loutil SNMP Getif
. . . . . . .
.
.
.
.
.
.
6.2 Page daccueil du Network Supervisor .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.3
Identication des utilisateurs de Network Supervisor .
6.4 Ajout dun nouveau compte utilisateur
.
6.5 Ajout dun nouveau quipement r seau .
6.6 Contenu de la page Summary .
6.7 Contenu de la page Capacity .
.
.
.
.
6.8 Contenu de la page Performance .
6.9 Contenu de la page Trafc Analysis
6.10 Contenu de la page Info . . . .
6.11 Chronogramme de travail
. . .
.
.
.
.
12 D nition SMI dun type simple .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Publicité
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
8
9
10
10
11
17
18
20
21
23
24
25
26
30
32
33
34
35
36
37
39
40
41
42
ii
TABLE DES FIGURES
v
13 D nition SMI dun nouveau type .
14 D nition SMI dune macro . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
iii
Introduction G n rale
Les r seaux sont de partout lheure actuelle. Ils sont devenus indispensables au
bon fonctionnement g n ral de nombreuses entreprises et administrations. Tout pro-
bl me ou panne peut avoir de lourdes cons quences aussi bien nanci res quorgani-
sationnelles.
La supervision des r seaux est alors n cessaire et indispensable. Elle permet entre autre
davoir une vue globale du fonctionnement et probl mes pouvant survenir sur un r -
seau mais aussi davoir des indicateurs sur la performance de son architecture.
Comme dans lexercice de son activit , ladministrateur du r seau doit souvent g rer
des quipements h t rog nes (station de travail, serveur, routeur, commutateur,switch..)
il est n cessaire de sappuyer sur des standards. Le protocole SNMP (Simple Network
Management Protocol) est actuellement le standard de fait dans le domaine de ladmi-
nistration des r seaux informatiques. Il sest impos au m me titre que les r seaux IP.
Cest sur ce m me protocole et sur les bases de donn es quil permet de le manipu-
ler dites MIB que porte notre stage. Il sagit particuli rement de d velopper une appli-
cation web pour la supervision des r seaux capable de d crire les diff rents param tres
relatifs l tat du r seau en exploitant les extensions apport es la MIB standard.
Ce stage consiste tout dabord faire une tude th orique des diff rents concepts
relatifs ladministration des r seaux ainsi quune tude de quelques solutions pr -
sentes au march . Ensuite, faire une conception d taill e des diff rents composants
de lapplication. Enn, la r alisation dune interface logicielle qui permet la supervi-
sion des quipements r seaux.
1
Chapitre 1
Pr sentation g n rale
Introduction
Dans ce premier chapitre, nous commen ons par pr senter bri vement lorganisme
daccueil au sein duquel nous avons effectu le stage relatif au pr sent projet. La suite
du chapitre est consacr e pr senter la probl matique du notre application.
1.1 Pr sentation de lorganisme
1.1.1 Pr sentation g n rale
En 17 avril 1995 fut la promulgation de la loi N 36 portant cr ation de lofce natio-
nal des t l communications, d nomm TUNISIE TELECOM. Cest la premi re soci t
tunisienne de t l communication au capital de 875 millions deuros et dont le chiffre
daffaire est de lordre de 750 millions deuros (2004). TUNISIE TELECOM, est le seul
fournisseur de la plupart des services de base (t l phonie xe, t lex, satellites xes,
lignes lou es). Elle partage le march de la t l phonie mobile en Tunisie avec lentre-
prise Egyptienne Orascom Telecom Tunisie (OTT). Louverture de 35 pourcent de son
capital a eu lieu n 2005 au prot de TeCom Dig (Duba ) pour un montant de 3,05 mil-
liards DT ce qui d passe lensemble des recettes de privatisations encaiss es par lEtat
tunisien depuis 1987. Gr ce des performances techniques qui ne sont plus d mon-
trer, TUNISIE TELECOM pr sente d j une densit t l phonique de 42 pourcent. Son
action se nourrit de plusieurs valeurs fondatrices :
Orientation client : 6 centres dassistance la client le de la t l phonie xe, mobile
et data et plus de 70 agences commerciales au service de la client le.
2
CHAPITRE 1. PR SENTATION G N RALE
3
Professionnalisme : Un effectif de 8000 agents hautement quali s et 65000 hommes
jour de formation .
1.1.2 Domaines dactivit nationales
En tant quop rateur historique, TUNISIE TELECOM est charg de :
Linstallation, lentretien et lexploitation des r seaux publiques de t l communi-
cations.
Loffre de tous les services publiques ou priv s de t l communications corres-
pondant aux divers besoins caract re social et conomique.
La promotion des nouveaux services de t l communications.
La contribution au d veloppement des tudes et recherches scientiques li es au
secteur des t l communications.
La participation leffort national denseignement sup rieur en mati re de t l -
communications.
Lapplication des conventions et trait s des organisations internationales et r gio-
nales sp cialis es dans le domaine des t l communications.
La promotion de la coop ration tous les niveaux dans tous les domaines des
t l communications.
1.1.3 Activit s internationales
Depuis sa cr ation TUNISIE TELECOM sest orient vers lexportation de son sa-
voir faire pour le d veloppement des r seaux et de nouveaux services dans les march s
mergents. TUNISIE TELECOM a mis en place, exploite et commercialise le premier
r seau GSM en Mauritanie (MATTEL). Elle a conclu une convention de coop ration
technique avec Djibouti T l com pour le d veloppement de ses r seaux de T l com-
munications. Une participation active aux grands projets mondiaux de t l communi-
cation travers des partenariats tels que Thuraya, Rascom, SEA-ME-WE4... etc
1.2 Contexte et probl matique
TUNISIE TELECOM, comme beaucoup dautres entreprises, est caract ris e par
une infrastructure tr s riche en mat riels informatiques. Vu son orientation t l com-
munication, les quipements r seaux repr sentent la majorit de son infrastructure in-
formatique, do la n cessit du suivi et supervision de ses r seaux. An dassurer
PRESENTATION
4
cette t che, la soci t a besoin dun outil de contr le de ses diff rents quipements et
ceci en temps r el. Cest dans ce cadre que se situe notre travail. En effet nous allons
concevoir et impl menter une application web assurant cette t che.
1.3 Organisation du rapport
Ce rapport est organis comme suit : apr s avoir consacr le premier chapitre la
pr sentation de lorganisme daccueil, dans le second nous pr sentons la base th o-
rique de notre stage. Une tude de lexistant sera faite tout au long du troisi me cha-
pitre. Le quatri me sera consacr la sp cication des besoins fonctionnels et non fonc-
tionnels et la pr sentation des diff rents cas dutilisation. Dans le cinqui me chapitre,
nous exposons la conception de notre application. Enn, nous illustrons les d tails de
sa r alisation.
Conclusion
Dans ce chapitre introductif, nous avons commenc par pr senter lorganisme dac-
cueil de notre projet. Dans le chapitre suivant, nous allons tudier le processus de su-
pervision des r seaux et ses diff rents concepts.
Chapitre 2
Etude Th orique
Introduction
De part leur continuelle volution, les r seaux se complexient, avec des domaines
dapplications et services toujours plus nombreux (t l phonie, Internet, r seaux lo-
caux, . . .), des supports qui se diversient (Ethernet, ATM, Wireless, X25, . . .), et une
forte h t rog n it des l ments connecter. De plus, lexigence de lutilisation se fait
croissante, en terme de s curit , abilit , performance...
Pour r pondre ces besoins, en 1989, SNMP fut standardis pour ladministration des
r seaux TCP/IP.
Ce chapitre a pour objectif de pr senter lapproche de gestion de r seau SNMP. Dans
un premier temps, nous pr senterons le mod le dune gestion de r seau. Ensuite nous
en tudierons les diff rents composants.
2.1 Mod lisation de la gestion de r seaux
An d tablir une architecture compl te dadministration de r seau, quatre aspects
doivent tre mod lis s :
Mod lisation de linformation : cest le choix dun langage commun de descrip-
tion des ressources administr es, exprim es sous la forme dobjets g r s.
Mod lisation de la communication : cest le choix dun protocole de communica-
tion entre les diff rents l ments qui puisse v hiculer les valeurs des objets g r s.
Mod lisation de lorganisation : d termine le r le de chaque l ment entrant
dans le cadre de la gestion. Ici, cest la d nition des agents et gestionnaires. Un
5
CHAPITRE 2. ETUDE TH ORIQUE
6
exemple dorganisation est pr sent sur la gure 2.1. Chaque ressource admi-
nistrer ( quipement mat riel ou logiciel) ex cute un agent SNMP qui maintient
une base de donn es, la MIB (Management Information Base), relative son h te,
l tat du r seau... Un gestionnaire SNMP peut lire et/ou crire dans la MIB main-
tenue via le protocole SNMP.
Mod lisation des fonctions : en termes de crit res de fonctionnalit de la gestion
de r seaux, les besoins recens s par les utilisateurs sont assez vari s. Certains
accordent un fort int r t lautomatisation de la gestion alors que dautres se
concentrent sur laspect s curit .
FIG. 2.1 Exemple dune architecture SNMP
2.2 Le protocole SNMP
2.2.1 Pr sentation
SNMP (Simple Network Management Protocol) est le protocole de gestion de r -
seaux propos par lIETF (Internet Engineering Task Force) et d ni par la RFC 1157. Il
est actuellement le protocole le plus utilis pour la gestion des quipements de r seaux
informatiques. Il est aussi utilis pour la gestion distance des applications : les bases
de donn es, les serveurs, les logiciels, etc...
Chaque machine, que ce soit sous Windows ou sous Linux poss de de nombreuses in-
formations capitales pour ladministrateur r seaux. Nous retrouvons des informations
CHAPITRE 2. ETUDE TH ORIQUE
7
comme la quantit de RAM utilis , lutilisation du CPU, lespace disque et encore bien
dautre indicateurs. SNMP, protocole de niveau application, va permettre de remonter
ces informations ladministrateur de fa on centralis pour pouvoir r agir au plus vite
aux pannes ventuelles.
2.2.2 Fonctionnement
2.2.2.1 Les agents
Sur une machine superviser, pour que SNMP envoie les informations que lon
souhaite il faut quun agent soit install sur celle-ci. Cet agent coute sur le port 161 et
attend que le serveur lui envoie des requ tes pour lui r pondre.
Lagent pourra aussi envoyer des alertes lui m me si ladministrateur la congur . Par
exemple pour surveiller loccupation CPU ladministrateur d nira une valeur critique
pour laquelle une alerte doit lui tre mise.
Pour nir lagent pourra aussi agir sur lenvironnement local, accomplir des actions,
agir comme proxy pour r cup rer de linformation sur des mat riels h t rog nes.
2.2.2.2 Les syst mes de management de r seaux
G n ralement, ladministrateur poss de un outil permettant de centraliser ce que
lui retournent ses agents. Et cest donc cet outil qui va interroger les quipements du
r seau. Il va donc pouvoir g rer un r seau entier gr ce cela.
Un exemple de syst me de management de r seaux est donn par la FIG 2.2 .
CHAPITRE 2. ETUDE TH ORIQUE
8
FIG. 2.2 Les syst mes de management de r seaux
2.2.3 Les services SNMP
Les services SNMP sont des requ tes de lecture ou d criture dans un objet g r , ou
la signalisation de loccurrence dun v nement. Il existe 4 types de requ tes SNMP :
get-request : Le Manager SNMP demande une information un agent SNMP.
get-next-request : Le Manager SNMP demande linformation suivante lagent
SNMP.
set-request : Le Manager SNMP met jour une information sur un agent SNMP.
trap : Lagent SNMP envoie une alerte au Manager.
Pour chaque envoi de message, une r ponse est retourn e lexception de la com-
mande trap. Les r ponses sont du type suivant :
get-response : Linformation a bien t transmise.
NoSuchObject : Aucune variable na t trouv e.
NoAccess : Les droits dacc s ne sont pas bons.
NoWritable : La variable ne peut tre crite.
La FIG 2.3 r capitule les changes pouvant tre effectu s entre un agent et le manage.
CHAPITRE 2. ETUDE TH ORIQUE
9
FIG. 2.3 Exemple d change SNMP
2.3 La MIB
2.3.1 Pr sentation
Pour que SNMP fonctionne, il est n cessaire quun protocole d change soit d nit.
Il y a aussi une standardisation des informations que ce protocole peut transporter.
Cest un protocole Internet, il doit tre utilisable sur des plates-formes h t rog nes
(mat riel comme syst me dexploitation).
Cest pour cette raison que lon parlera de MIB (Management Information Base).En
effet, la MIB est une base de donn es qui permet de stocker les objets g r s usit s dans
le cadre de la gestion de r seau et qui sont maintenues par lagent. Cest cette base
laquelle on va demander les informations.
2.3.2 Structure de la MIB
La structure de la MIB est hi rarchique : les informations sont regroup es en arbre.
Larchitecture mise en oeuvre pour identier chaque l ment est une structure arbo-
rescente nomm e arbre denregistrement.
Ainsi, les objets g r s sont repr sent s par les feuilles de larbre et sont d crits par la
macro OBJECT-TYPE en ASN.1. Les noeuds (ou groupes) permettent d tablir la hi -
rarchie de larbre et sont d crit par le type OBJECT-IDENTIFIER.
Chaque l ment (noeud et feuille) de la MIB est muni dun nombre entier qui constitue
son identiant. On peut ainsi r f rencer de mani re unique chaque objet par la concat -
nation des identiants de ses anc tres et du sien formant ainsi lOID (Object identier)
de linformation. LOID se pr sente alors comme une suite de chiffres s par s par des
points, qui identie linformation de fa on unique, et chaque OID correspond un
CHAPITRE 2. ETUDE TH ORIQUE
10
FIG. 2.4 Larbre des objets de la MIB
nom, indiqu dans le document qui d crit la MIB. Par exemple, 1.3.6.1.2.1.2.2.1.2 est
lOID ifDescr qui est la cha ne de caract res d crivant une interface r seau (comme
eth0 sur Linux ou Ethernet0 sur un routeur Cisco).
Les MIB sont d crites en utilisant ASN.1. Par exemple, ifDescr est d crite par :
FIG. 2.5 Description ASN.1 de ifDescr
CHAPITRE 2. ETUDE TH ORIQUE
11
La MIB est une base de donn e tr s vaste qui permet de stocker divers cat gories din-
formations.
On y trouve notamment le groupe mib-2, utile ladministration r seau standard, mais
aussi le groupe private qui permet aux constructeurs d l ments administrables de sto-
cker des informations propri taires.
2.3.3 La MIB-II
Comme le montre la gure 2.4, la MIB-II est r f renc e par lidentiant 1.3.6.1.2.1.
Cest lune des MIB les plus connues, d crite dans le RFC 1213, et qui est mise en oeuvre
dans quasiment tous les quipements TCP/IP. Elle stocke toutes les informations g -
n riques inh rentes la gestion de r seau. Elle compte dix groupes :
FIG. 2.6 Les principales branches de la MIB II
Les informations offertes par la MIB-II sont r parties sur les diff rents groupes
comme suit :
le groupe system : fournit des informations g n rales relatives l ment admi-
nistr .
DESCRIPTION GENERALE
12
le groupe interfaces : fournit des informations sur les interfaces physiques im-
plant es dans l quipement.
...