Réf :2007/II2/Sujet N˚16
A-U :2007-2008
Ministère de l’Enseignement Supérieur,de la Recherche Scientifique et de le Technologie Université Manouba École Nationale des Sciences de L’Informatique
Rapport de Stage d’Immersion en Entreprise
Réalisé par
Amri Rahma
Ben Yahia Nesrine
Sujet
Conception et réalisation d’une 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 l’encadrant
Mr. Riadh BEN NEJI
2
Remerciements
Nos remerciements les plus chaleureux vont particulièrement aux gens qui, sans
leur aide inestimable, ce stage n’aurait jamais été mené à bien.
Nous tenons à remercier tout d’abord nos familles qui nous ont fournis le soutien
moral et financier.
Notre reconnaissance s’adresse 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 d’avoir 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 l’organisme .
.
.
1.1.1 Présentation générale . .
.
.
.
.
.
.
.
.
.
.
.
.
1.1.2 Domaines d’activité 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 l’existant
. . . . . . .
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIÈRES
3.1.2 Cacti
. . . . . . . . . . .
3.1.3 Nagios . . . . . . . . . . 3.2 Critique de l’existant . . . . . .
4 Spécification
Introduction . . . . . . . . . . . . . . 4.1 Objectif . . . . . . . . . . . . . 4.2 Spécification 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 raffiné .
4.4 Diagrammes de séquence
. .
.
Publicité
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.4.1 L’ajout d’un 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 l’application . . 5.3 Architecture générale des classes java de l’application .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Publicité
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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 l’application .
.
.
.
.
.
.
.
.
6.2.1 Présentation de la page d’accueil de l’application .
6.2.2 Gestion de l’accès aux informations .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.2.3 Gestion des équipements réseaux et des comptes utilisateurs
6.2.4.1
6.2.4.2
6.2.4 Pages générées au cours de la supervision . La page Summary . La page Capacity . . La page Performance . La page Traffic Analysis La page Info . . 6.3 Chronogramme . . . . . . . . .
6.2.4.4
6.2.4.3
6.2.4.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
30
31
31
31
33
34
36
36
37
38
40
41
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Table des figures
2.1 Exemple d’une architecture SNMP .
.
.
.
.
2.2 Les systèmes de management de réseaux .
2.3 Exemple d’échange SNMP . . .
2.4 L’arbre 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 L’ajout d’un nouveau enregistrement .
4.4 Diagramme de séquence de Consultation des informations .
5.1 Architecture JSP . . . . . . . . .
.
.
.
.
.
5.2 Architecture générale de l’application .
.
.
.
.
.
.
.
.
.
.
5.3 Architecture globale des classes java développées
5.4 Diagramme de classes du paquet appl
6.1 L’outil SNMP Getif
. . . . . . .
.
.
.
.
.
.
6.2 Page d’accueil du Network Supervisor .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.3
Identification des utilisateurs de Network Supervisor .
6.4 Ajout d’un nouveau compte utilisateur
.
6.5 Ajout d’un 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 Traffic Analysis
6.10 Contenu de la page Info . . . .
6.11 Chronogramme de travail
. . .
.
.
.
.
12 Définition SMI d’un 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éfinition SMI d’un nouveau type .
14 Définition SMI d’une macro . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
iii
Introduction Générale
Les réseaux sont de partout à l’heure 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 financières qu’organi-
sationnelles.
La supervision des réseaux est alors nécessaire et indispensable. Elle permet entre autre
d’avoir une vue globale du fonctionnement et problèmes pouvant survenir sur un ré-
seau mais aussi d’avoir des indicateurs sur la performance de son architecture.
Comme dans l’exercice de son activité, l’administrateur 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 s’appuyer sur des standards. Le protocole SNMP (Simple Network
Management Protocol) est actuellement le standard de fait dans le domaine de l’admi-
nistration des réseaux informatiques. Il s’est imposé au même titre que les réseaux IP.
C’est sur ce même protocole et sur les bases de données qu’il permet de le manipu-
ler dites MIB que porte notre stage. Il s’agit 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 d’abord à faire une étude théorique des différents concepts
relatifs à l’administration des réseaux ainsi qu’une étude de quelques solutions pré-
sentes au marché. Ensuite, à faire une conception détaillée des différents composants
de l’application. Enfin, la réalisation d’une 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 l’organisme
d’accueil 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 l’organisme
1.1.1 Présentation générale
En 17 avril 1995 fut la promulgation de la loi N˚36 portant création de l’office natio-
nal des télécommunications, dénommé TUNISIE TELECOM. C’est la première société
tunisienne de télécommunication au capital de 875 millions d’euros et dont le chiffre
d’affaire est de l’ordre de 750 millions d’euros (2004). TUNISIE TELECOM, est le seul
fournisseur de la plupart des services de base (téléphonie fixe, télex, satellites fixes,
lignes louées). Elle partage le marché de la téléphonie mobile en Tunisie avec l’entre-
prise Egyptienne Orascom Telecom Tunisie (OTT). L’ouverture de 35 pourcent de son
capital a eu lieu fin 2005 au profit de TeCom Dig (Dubaï) pour un montant de 3,05 mil-
liards DT ce qui dépasse l’ensemble des recettes de privatisations encaissées par l’Etat
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 d’assistance à la clientèle de la téléphonie fixe, 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 qualifiés et 65000 hommes
jour de formation .
1.1.2 Domaines d’activité nationales
En tant qu’opérateur historique, TUNISIE TELECOM est chargé de :
– L’installation, l’entretien et l’exploitation des réseaux publiques de télécommuni-
cations.
– L’offre 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 scientifiques liées au
secteur des télécommunications.
– La participation à l’effort national d’enseignement supérieur en matière de télé-
communications.
– L’application 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 s’est orienté vers l’exportation 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 d’autres 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, d’où la nécessité du suivi et supervision de ses réseaux. Afin d’assurer
PRESENTATION
4
cette tâche, la société a besoin d’un outil de contrôle de ses différents équipements et
ceci en temps réel. C’est 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 l’organisme d’accueil, dans le second nous présentons la base théo-
rique de notre stage. Une étude de l’existant sera faite tout au long du troisième cha-
pitre. Le quatrième sera consacré à la spécification des besoins fonctionnels et non fonc-
tionnels et la présentation des différents cas d’utilisation. Dans le cinquième chapitre,
nous exposons la conception de notre application. Enfin, nous illustrons les détails de
sa réalisation.
Conclusion
Dans ce chapitre introductif, nous avons commencé par présenter l’organisme d’ac-
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 complexifient, avec des domaines
d’applications et services toujours plus nombreux (téléphonie, Internet, réseaux lo-
caux, . . .), des supports qui se diversifient (Ethernet, ATM, Wireless, X25, . . .), et une
forte hétérogénéité des éléments à connecter. De plus, l’exigence de l’utilisation se fait
croissante, en terme de sécurité, fiabilité, performance...
Pour répondre à ces besoins, en 1989, SNMP fut standardisé pour l’administration des
réseaux TCP/IP.
Ce chapitre a pour objectif de présenter l’approche de gestion de réseau SNMP. Dans
un premier temps, nous présenterons le modèle d’une gestion de réseau. Ensuite nous
en étudierons les différents composants.
2.1 Modélisation de la gestion de réseaux
Afin d’établir une architecture complète d’administration de réseau, quatre aspects
doivent être modélisés :
– Modélisation de l’information : c’est le choix d’un langage commun de descrip-
tion des ressources administrées, exprimées sous la forme d’objets gérés.
– Modélisation de la communication : c’est le choix d’un protocole de communica-
tion entre les différents éléments qui puisse véhiculer les valeurs des objets gérés.
– Modélisation de l’organisation : détermine le rôle de chaque élément entrant
dans le cadre de la gestion. Ici, c’est la définition des agents et gestionnaires. Un
5
CHAPITRE 2. ETUDE THÉORIQUE
6
exemple d’organisation est présenté sur la figure 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 à l’automatisation de la gestion alors que d’autres se
concentrent sur l’aspect sécurité.
FIG. 2.1 – Exemple d’une 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 l’IETF (Internet Engineering Task Force) et défini 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 l’administrateur réseaux. Nous retrouvons des informations
CHAPITRE 2. ETUDE THÉORIQUE
7
comme la quantité de RAM utilisé, l’utilisation du CPU, l’espace disque et encore bien
d’autre indicateurs. SNMP, protocole de niveau application, va permettre de remonter
ces informations à l’administrateur 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 l’on
souhaite il faut qu’un 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.
L’agent pourra aussi envoyer des alertes lui même si l’administrateur l’a configuré. Par
exemple pour surveiller l’occupation CPU l’administrateur définira une valeur critique
pour laquelle une alerte doit lui être émise.
Pour finir l’agent pourra aussi agir sur l’environnement local, accomplir des actions,
agir comme proxy pour récupérer de l’information sur des matériels hétérogènes.
2.2.2.2 Les systèmes de management de réseaux
Généralement, l’administrateur possède un outil permettant de centraliser ce que
lui retournent ses agents. Et c’est 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 l’occurrence d’un é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 l’information suivante à l’agent
SNMP.
– set-request : Le Manager SNMP met à jour une information sur un agent SNMP.
– trap : L’agent SNMP envoie une alerte au Manager.
Pour chaque envoi de message, une réponse est retournée à l’exception de la com- mande trap. Les réponses sont du type suivant :
– get-response : L’information a bien été transmise.
– NoSuchObject : Aucune variable n’a été trouvée.
– NoAccess : Les droits d’accè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 qu’un protocole d’échange soit définit.
Il y a aussi une standardisation des informations que ce protocole peut transporter.
C’est un protocole Internet, il doit être utilisable sur des plates-formes hétérogènes
(matériel comme système d’exploitation).
C’est pour cette raison que l’on 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 l’agent. C’est 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.
L’architecture mise en oeuvre pour identifier chaque élément est une structure arbo-
rescente nommée arbre d’enregistrement.
Ainsi, les objets gérés sont représentés par les feuilles de l’arbre et sont décrits par la
macro OBJECT-TYPE en ASN.1. Les noeuds (ou groupes) permettent d’établir la hié-
rarchie de l’arbre et sont décrit par le type OBJECT-IDENTIFIER.
Chaque élément (noeud et feuille) de la MIB est muni d’un nombre entier qui constitue
son identifiant. On peut ainsi référencer de manière unique chaque objet par la concaté-
nation des identifiants de ses ancêtres et du sien formant ainsi l’OID (Object identifier)
de l’information. L’OID se présente alors comme une suite de chiffres séparés par des
points, qui identifie l’information de façon unique, et à chaque OID correspond un
CHAPITRE 2. ETUDE THÉORIQUE
10
FIG. 2.4 – L’arbre 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
l’OID 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 d’in-
formations.
On y trouve notamment le groupe mib-2, utile à l’administration 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 figure 2.4, la MIB-II est référencée par l’identifiant 1.3.6.1.2.1.
C’est l’une 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.
– le groupe at : contient une simple table qui associe à chaque adresse physique
d’une interface implantée une adresse réseau IP.
– le groupe ip : fournit des informations concernant le protocole IP au noeud consi-
déré.
– le groupe icmp : fournit des informations sur ICMP, un protocole de messages
concernant le niveau IP.
– le groupe tcp : contient des informations concernant l’implémentation et le fonc-
tionnement de TCP.
– le groupe udp : contient des informations concernant l’implémentation et le fonc-
tionnement de UDP.
– le groupe egp : contient des informations concernant l’implémentation et le fonc-
tionnement de EGP (External Gateway Protocol ).
– le groupe transmission : fournit des informations relatives au médium de trans-
mission.
– le groupe snmp : contient des informations sur le protocole d’administration.
Conclusion
Dans ce chapitre, nous avons essayé de clarifier certaines notions fondamentales.
Avant d’entamer la partie spécification, nous allons consacrer le chapitre suivant à une
étude préalable de l’existant.
Chapitre 3
Etudes préalables
Introduction
Un enjeu majeur de tout logiciel de supervision est de répondre en permanence
et le plus tôt possible à tout panne ou fonctionnement anormal touchant le réseau en
question. Au niveau de cette partie nous allons faire une étude critique de quelques
solutions existantes au marché afin de mettre la main sur les différentes façons à travers
lesquelles cet enjeu a été traité.
3.1 Etude de l’existant
3.1.1 MRTG
MRTG est un outil pour surveiller la charge de la circulation des données qui tran-
sitent sur un réseau, un sous-réseau ou sur certaines machines via SNMP. Il produit
des pages HTML contenant des images qui fournissent une représentation visuelle du
trafic désiré.
MRTG est basé sur les langages Perl et C, il fonctionne sous UNIX et Windows NT. Son
succès a été très important et son successeur RRDTool qui est écrit par le même auteur
est maintenant utilisé dans de nombreux logiciel de monitoring.
3.1.2 Cacti
Cacti est un logiciel de supervision qui est un front-end (interface graphique) de
Publicité
RRDTool. Il est basé sur un serveur web avec