PFE BEN AMARA Sahbi

RAPPORT DE PROJET DE FIN D’ETUDES
Filière
Ingénieurs en Télécommunications
Option
Ingénierie des Réseaux
Développement d’un gestionnaire

de réseau pour le Backbone IP/MPLS
de Tunisie Télécom
Elaboré par :
Sabri Ben Amara
Encadré par :
M. Mounir Frikha M. Montassar Bachwerdiane
Année universitaire : 2004/2005

DEDICACE
A ma Mère
A mon Père
A ma Femme
A ma Fille
A mes Frères
A mes Sœurs
Remerciements
Remerciements
Je suis profondément reconnaissant à mes deux encadreurs Mr Mounir Frikha et Mr Montassar

Bachwerdiane pour m’avoir fait le grand honneur de diriger mon projet dans les meilleures
conditions, ainsi que pour leurs encadrements, leurs conseils et leurs disponibilités.
Je voudrais aussi témoigner ma reconnaissance à Monsieur Slim Jarraya directeur de la

Direction des Technologies de l’Information et des Réseaux à Tunisie telecom pour son aide et les
facilitées qu’il m’a offert au sein du Backbone IP/MPLS ainsi que pour tous les personnels de la
DTIR pour leurs collaborations.
Comme je n’y manquerais pas de remercier mes professeurs, membres ou Jury pour l’honneur
qu’ils ont fait en acceptant de faire partie de mon Jury.
I
Résumé
Résumé
Durant ce projet, nous nous sommes intéressés à trois points relatifs au Backbone IP/MPLS de
Tunisie Télécom. Le premier point concerne le problème de l’archivage des configurations des
différents routeurs. Pour remédier à ce problème, nous avons mis en place un processus de sauvegarde
périodique qui représente le premier module de notre application. Le deuxième point s’intéresse à
l’administration des équipements réseaux du Backbone. Le troisième point s’attache à la
restructuration du log généré par les routeurs sous forme d’événement à fin d’avoir une information
lisible et utile.
Mots clés : Backbone IP, SNMP, administration, génération d’événement.
II
Table des matières
Table des matières
REMERCIEMENTS................................................................................................................................................ I
RESUME ................................................................................................................................................................II
LISTE DES FIGURES............................................................................................................................................V
LISTE DES ACRONYMES ................................................................................................................................. VI
INTRODUCTION GENERALE ............................................................................................................................ 1
CHAPITRE 1 :PRESENTATION DU PROJET..................................................................................................... 2
INTRODUCTION .................................................................................................................................................. 2
1.1. PRESENTATION DE L’ORGANISME D’ACCUEIL............................................................................ 2
1.2. PROBLEMATIQUE................................................................................................................................. 3
1.3. OBJECTIFS DU PROJET ........................................................................................................................ 4
CONCLUSION....................................................................................................................................................... 4
CHAPITRE 2 : LA GESTION DE RESEAU ......................................................................................................... 5
U
INTRODUCTION .................................................................................................................................................. 5
2.1. BUT ET DOMAINE D’APPLICATION ................................................................................................. 5
2.2. FONCTIONNALITES.............................................................................................................................. 6
2.2.1. LA CUEILLETTE DES INFORMATIONS DE GESTION : .................................................................. 6
2.2.2. L’INTERPRETATION DES DONNEES................................................................................................. 7
2.2.3. LE CONTROLE DES EQUIPEMENTS .................................................................................................. 7
2.3. PRINCIPES DE LA GESTION DE RESEAU ......................................................................................... 7
2.4. SNMP ....................................................................................................................................................... 9
2.4.1. HISTORIQUE .......................................................................................................................................... 9
2.4.2. LES ENTITES .......................................................................................................................................... 9
2.4.3. LA MANAGEMENT INFORMATION BASE ..................................................................................... 10
2.4.3.1. DECLARATION DES OBJETS........................................................................................................ 12
2.4.3.2. ORGANISATION ET IDENTIFICATION DES OBJETS ET DES INSTANCES .......................... 13
2.4.4. LES OPERATIONS DE MANAGEMENT ........................................................................................... 14
2.4.5. COMPARAISON ENTRE SNMP V1, V2 ET V3 ................................................................................. 15
2.5. LE SERVICE CMIS ............................................................................................................................... 15
2.6. LE PROTOCOLE CMIP ........................................................................................................................ 16
2.7. LE PROTOCOLE CMOT ...................................................................................................................... 18
2.8. OUTILS D’ADMINISTRATION .......................................................................................................... 19
2.8.1. OUTILS LOCAUX ................................................................................................................................ 19
2.8.2. PLATES-FORMES D’ADMINISTRATION......................................................................................... 19
CONCLUSION..................................................................................................................................................... 20
CHAPITRE 3 : DESCRIPTION DE L’EXISTANT............................................................................................. 21
INTRODUCTION ................................................................................................................................................ 21
3.1. DESCRIPTION DU BACKBONE IP DE TUNISIE TELECOM.......................................................... 21
3.2. ARCHITECTURE IP/MPLS DU BACKBONE IP................................................................................ 22
III
Table des matières
CONCLUSION..................................................................................................................................................... 25
CHAPITRE 4 : CONCEPTION ET IMPLEMENTATION ................................................................................. 26
INTRODUCTION ................................................................................................................................................ 26
4.1. CONCEPTION ....................................................................................................................................... 26
4.1.1. BASE DES DONNEES .......................................................................................................................... 26
4.1.2. LES MODULES DE BASES ................................................................................................................. 30
4.1.3. LE MODULE SNMPV1COMMUNICATIONINTERFACE ................................................................ 30
4.1.4. LE MODULE SIMPLEGET .................................................................................................................. 31
4.1.5. LE MODULE SNMPCOLLECTOR ...................................................................................................... 32
4.1.6. LE MODULE CONFIGCOLLECTOR .................................................................................................. 34
4.2. IMPLEMENTATION............................................................................................................................. 37
4.2.1. OUTILS UTILISES................................................................................................................................ 37
4.2.1.1. LANGAGE DE PROGRAMMATION : JAVA ................................................................................ 37
4.2.1.2. ENVIRONNEMENT DE DEVELOPPEMENT : JBUILDER 2005 ................................................. 39
4.2.1.3. SYSTEME DE GESTION DE BASE DE DONNEES : ORACLE 9.2.0.......................................... 39
4.2.2. INTERFACES UTILISATEURS ........................................................................................................... 39
4.2.2.1. TTNETVIEW .................................................................................................................................... 39
4.2.3. TTNETLOCATOR................................................................................................................................. 53
CONCLUSION..................................................................................................................................................... 54
CONCLUSION ET PERSPECTIVES .................................................................................................................. 55
ANNEXE1: ATTESTATIONS DE FORMATIONS............................................................................................ 57
ANNEXE2: EXEMPLE DE MIB ......................................................................................................................... 59
IV
Liste des figures
Liste des figures
FIGURE 2-1: RELATIONS ENTRE MANAGER, AGENTS ET PROTOCOLE...................................................... 8

FIGURE 2-2: ARCHITECTURE SNMP ..................................................................................................... 10
FIGURE 2-3: STRUCTURE D’INDEXATION DES DONNEES DANS LA MIB-2 SNMP................................. 11
FIGURE 2-4: COMPOSITION DE CMISE ............................................................................................... 12
FIGURE 3-2 : OPTIMISATION DU ROUTEUR BGP INTER-PE................................................................... 25
FIGURE 4-1: STRUCTURE DE LA TABLE GROUPE ................................................................................... 26
FIGURE 4-2: STRUCTURE DE LA TABLE ROUTEUR ................................................................................. 27
FIGURE 4-3: STRUCTURE DE LA TABLE OID ......................................................................................... 28
FIGURE 4-4: STRUCTURE DE LA TABLE HISTORIQUE ............................................................................. 28
FIGURE 4-5: STRUCTURE DE LA TABLE HISTORIQUE ............................................................................. 28
FIGURE 4-6: STRUCTURE DE LA TABLE CLIENTS ................................................................................... 29
FIGURE 4-7: STRUCTURE DE LA CLASSE SNMPV1COMMUNICATIONINTERFACE................................. 31
FIGURE 4-8: STRUCTURE DE LA CLASSE SIMPLEGET ............................................................................ 32
FIGURE 4-9: SCHEMA DE FONCTIONNEMENT DU SNMPCOLLECTOR.................................................... 33
FIGURE 4-10: STRUCTURE DE LA CLASSE SNMPCOLLECTOR .............................................................. 34
FIGURE 4-11: SCHEMA DE FONCTIONNEMENT DU CONFIGCOLLECTOR ................................................ 36
FIGURE 4-12: STRUCTURE DE LA CLASSE CONFIGCOLLECTOR............................................................. 37
FIGURE 4-13: INTERFACE PRINCIPALE DE TTNETVIEW ........................................................................ 40
FIGURE 4-14: GROUPES ET ROUTEURS .................................................................................................. 41
FIGURE 4-15: INFORMATIONS SNMP CONCERNANT LES ROUTEURS CISCO ......................................... 42
FIGURE 4-16: INFORMATIONS SNMP CONCERNANT LES INTERFACES D’UN ROUTEUR CISCO ............. 43
FIGURE 4-17: STATISTIQUES CONCERNANT UN INTERFACE D’UN ROUTEUR CISCO .............................. 44
FIGURE 4-18: STATISTIQUES CONCERNANT UN ROUTEUR CISCO .......................................................... 45
FIGURE 4-19: GENERATION D’UN RAPPORT CONCERNANT UN INTERFACE D’UN ROUTEUR CISCO ...... 46
FIGURE 4-20: GENERATION DES EVENEMENTS ..................................................................................... 47
FIGURE 4-21: EXEMPLE D’EVENEMENTS CRITIQUES ............................................................................. 48
FIGURE 4-22: COMPOSITION DU MENU ‘’FILE’’ .................................................................................... 49
FIGURE 4-23: CREATION D’UN NOUVEAU GROUPE ............................................................................... 49
FIGURE 4-24: CREATION D’UN NOUVEAU ROUTEUR ............................................................................. 50
FIGURE 4-25: COMPOSITION DU MENU ‘’EDIT’’.................................................................................... 50
FIGURE 4-26: CONFIGURATION DES PROCESSUS ................................................................................... 51
FIGURE 4-27: CONFIGURATION DES OIDS ............................................................................................ 51
FIGURE 4-28: AJOUT D’UN OID ............................................................................................................ 52
FIGURE 4-29: AJOUT DE L’INFORMATION ‘’WHYRELOAD’’.................................................................. 52
FIGURE 4-30: MENU PROCESS DE TTNETVIEW .................................................................................... 52
FIGURE 4-31: INTERFACE DE CONFIGCOLLECTOR ................................................................................ 53
FIGURE 4-32: OPTIONS DE RECHERCHE DANS TTNETLOCATOR ........................................................... 53
FIGURE 4-33: INTERFACE DE L’APPLICATION TTNETLOCATOR ........................................................... 54
V
Liste des acronymes
Liste des acronymes
ASN : Abstract Syntax Notation

CEF : Cisco Express Forwarding
CMIP: Common Management Information Protocol
CMIS: Common management Information Service
FIB : Forwarding Information Base
FSI : Fournisseur de Services Internet
IETF : Internet Engineering Task Force
IGP : Interior Gateway Protocol
IP : Internet Protocol
LDP : Label Distribution Protocol
LPP : Lightweight Presentation Protocol
MIB : Management Information Base
M-BGP : Multi-Border Gateway Protocol
MPLS : Multi Protocole Label Switching
MTU : Maximum Transmission Unit
OSPF : Open Shortest Path First
PBR : Policy Based Routing
PE : Provider Edge
QoS : Quality Of Services
RFC : Request For Comment
SMI : Structure of Managed Information
SNMP : Simple Network Management Protocol
TDP : Tag Distribution Protocol
UDP : User Datagram Protocol
VPN : Virtual Private Network
VRF : VPN Routing and Forwarding
VI
Introduction générale
Les réseaux informatiques touchent de plus en plus notre vie courante. On compte sur
les services offerts par les réseaux pour assurer les transactions bancaires, les recherches web,
la téléconférence. Les services offerts par les réseaux sont donc rendus indispensables.
Pour s’assurer que les services rendus par les réseaux seraient convenables, il est
nécessaire de surveiller le réseau et d’agir quand une erreur se produit. Pour ce faire, il faut
obtenir les données de gestion des équipements de réseaux et, si nécessaire, contrôler ces
équipements.
Le projet que nous avons réalisé consiste à la mise en place d'une application capable
de gérer les équipements réseaux du Backbone IP/MPLS de Tunisie Télécom. A la fin de ce
projet nous serons en mesure de superviser la totalité du réseau Internet, de fournir des
statistiques utiles pour faire des prévisions, fournir la possibilité de la gestion des abonnées
Internet et à la fin générer des événements qui reflètent l’état de notre réseau.
Afin de comprendre la démarche que nous avons adopté pour mener ce projet à son
terme, le rapport se structure de la façon suivante :
Première partie : Présentation de la gestion de réseau,
Deuxième partie : Description de l’existant
Troisième partie : Conception et implémentation de notre application
1
Chapitre 1
Présentation du projet
Introduction
Dans le présent chapitre, nous allons essayer de présenter notre stage. Pour ce faire,
procédons à une présentation de l’organisme d’accueil, à savoir ‘Tunisie Télécom’. Par la
suite, nous dégageons la problématique pour aboutir aux objectifs spécifiques à notre projet.
1.1. Présentation de l’organisme d’accueil
Le 1er janvier 1996, l’office national des télécommunications (ONT) ou « TUNISIE

TELECOM » est entrée en activité en tant qu’opérateur de télécommunication doté de sa
propre autonomie et son propre réseau (sous la forme juridique d’établissement public a
caractère industriel et commercial).
Tunisie Télécom a pour mission d’assurer toutes les activités relatives au domaine des
télécommunications dont notamment :
- La coopération avec les organismes similaires et l’application des traites
internationales en matière de télécommunication.
- L’installation, le développement, l’entretien et l’exploitation des réseaux publics de
télécommunication et en particulier, les réseaux de téléphone et de transmission de
données.
- La promotion de nouveaux services de télécommunication à travers l’installation de
l’équipement technologique dans le domaine la contribution au développement aux
études et recherches scientifiques liées au secteur des télécommunications.
Direction des Technologies de l’information et des Réseaux
Cette direction est spécialisée dans la conception, la sécurisation, la mise en service et la

gestion des réseaux informatiques qui sont nécessaire au fonctionnement de différents
services de la compagnie, comme elle fournit l’accès à Internet aux différents sites de Tunisie
Télécom ainsi qu’elle prend en charge l’administration, le contrôle, la maintenance et
2
l’exploitation de l’infrastructure de l’Internet en Tunisie à travers le Backbone IP/MPLS qui

couvre tout le pays.
La DTIR comprend trois équipes :
- Equipe sécurité : sa mission est la sécurisation des réseaux informatiques en étudiant
les vulnérabilités et en installant des détecteurs d’intrusions, des firewalls, des sondes,
des analyseurs et des antivirus.
- Equipe de développement : développement et maintenance des applications utilisées
par la société et du site web de Tunisie Télécom.
- Equipe réseaux : installation, mise en services, maintenance et exploitations des
réseaux informatiques à savoir
o L’intranet de Tunisie Télécom : ce réseau interconnecte les différents sites de
Tunisie Télécom (Kasbah, Ouardia, Hasdurbal et Montplaisir) à travers des
connexion de type MAN (Metropolitan Area Network).
o Le Backbone : Réseau d’Internet National
o Le réseau GIS.
1.2. Problématique
Tunisie Télécom a migré vers une architecture IP/MPLS qui intègre la notion qualité de
service dans une politique qui vise l’amélioration des services offerts aux clients. Cette
migration a engendré la croissance du réseau en nombre de routeurs connectés et données
partagées. Pour maintenir ce réseau opérationnel et disponible, des techniques et des outils
avancés ont dû être inventés pour assurer son fonctionnement et son administration. Notre
projet rentre dans ce cadre et vise à remédier à quelques problèmes à savoir :
- Perte des fichiers de configuration des routeurs
- Difficulté de localisation d’un client
- Manque de suivis efficaces des états des routeurs (CPU, Température, états des
interfaces...)
- Pas d’historique…
Ces problèmes ont causé une mauvaise exploitation des ressources disponibles et une
grande perte de temps.
3
1.3. Objectifs du projet
L’objectif principal de ce projet et de parvenir à avoir une vision globale sur la totalité du
BackboneIP/MPLS de Tunisie Télécom. La solution proposée est spécialement utile pour
identifier tout dysfonctionnement dans le réseau et de faciliter la prévision de toute
amélioration.
Le projet consiste au développement d’une application de gestion du Backbone IP/MPLS.
Cette application va être capable de :
- Parcourir le Backbone et d’extraire les informations nécessaires à partir des différents

routeurs à fin d’avoir une documentation dynamique, ces informations seront stockées dans
une base de données qui sera exploitée pour localiser l’emplacement des abonnés (Nœud,
Routeur, Interface, adresse WAN,...) à fin de faciliter la maintenance des différentes liaisons
(Publinets, Lycées,...).
- Avoir des informations sur les états des routeurs (Température, Alimentation,
Processeurs, Etats des interfaces, Table de routage...)
- Sauvegarder les fichiers de configuration des routeurs à fin de les utiliser en cas de panne
ou de perte de config.
- Pouvoir effectuer une recherche pour la localisation des clients.
- Génération des statistiques sur le trafic
- Génération d’événements utiles
Conclusion
Après avoir présenté notre projet, nous entamons par la suite la partie qui permet la
présentation de certains concepts liés à notre domaine d’application.
4
Chapitre 3 : Description de l’existant
2. Chapitre 2
La gestion de réseau
Introduction
Devant l’évolution technologique et la mise en place de nouveaux services Tunisie Télécom a

été obligé d’élargir et de diversifier son réseau qui est devenu complexe. Par rapport à un tel
réseau le concept gestion de réseau est devenu une nécessité afin d’assurer l’administration et
pouvoir faire des prévisions.
2.1. But et domaine d’application

La notion de gestion s’applique essentiellement dans un contexte de réseau privé. L’idée
maîtresse de la supervision est de contrôler la bonne santé du réseau et des services informatiques
afin de mesurer la Qualité de Service (QoS). Cette notion de QoS n’est pas récente, mais elle est
devenue le point d’intérêt central des stratégies de développement d’entreprise. La situation
économique actuelle peu favorable exige des entreprises qu’elles contrôlent leurs dépenses. La
tendance n’est pas à l’investissement dans de nouvelles technologies, mais à l’optimisation et au
rendement de l’existant à moindre coût. De plus, l’évolution des méthodes de travail au sein
même de l’entreprise veut qu’une part de plus en plus importante de l’activité de celle-ci sollicite
les outils informatiques. Dans le cas des sociétés de services en informatique, c’est toute l’activité
des ingénieurs et dirigeants qui repose intégralement sur la bonne disponibilité des services
informatiques et réseaux. C’est dans cette volonté de contrôle que s’intègre la supervision de
réseaux.
L’objectif des administrateurs d’un système d’information est donc de pouvoir connaître en
permanence l’état du réseau, et d’être averti en temps réel des différents incidents pour réduire au
maximum les délais d’intervention et de coupure du service.
A présent, de nouveaux besoins se font sentir. Le premier besoin est de rompre la contrainte de
proximité de l’équipement à gérer. Avec les protocoles de gestion de réseau actuels, le réseau est
utilisé afin de permettre la gestion des équipements le composant. On se trouve donc dans le cas
5
d’une gestion du réseau par le réseau. Le second besoin concerne la dépendance humaine. La
complexité des réseaux s’accroissant, la tâche de gestion du réseau exige une telle masse
d’informations à traiter qu’elle dépasse la capacité de l’être humain. En effet, il faut remarquer
que chaque information individuelle sur un équipement ne peut être utilisée telle quelle, elle n’est
significative que dans le contexte du réseau global.
Les considérations énoncées ci-dessus permettent d’identifier les besoins de la gestion des
réseaux:
• S’adapter à toutes les tailles de réseaux.

• Gérer des équipements hétérogènes et possiblement complexes.
• Permettre les opérations de gestion à distance.
• Assister l’utilisateur en:
– Automatisant certaines tâches.
– Aidant l’utilisateur dans les tâches qui ne sont pas automatisées.
– Fournissant une vue adaptée du réseau selon les opérations à réaliser.
2.2. Fonctionnalités
Une bonne gestion de réseau permet l’utilisation optimale de toutes les ressources offertes par
le réseau. La gestion de réseau a trois fonctions : la cueillette des données de gestion,
l’interprétation et le contrôle.
2.2.1. La cueillette des informations de gestion :

Un logiciel qui fait de la gestion de réseau doit amasser toutes les informations de gestion dont
il a besoin. Ces informations parviennent de chacun des éléments du réseau. Pour les obtenir, une
étape de découverte des éléments de réseau est effectuée, puis les requêtes sont envoyées aux
éléments un à un pour en tirer les informations de gestion.
Ces informations de gestion comprennent toutes sortes d’informations reliées à un élément de
réseau : le type d’équipement, le nombre de paquets qui passent sur chaque port d’un routeur,
l’usager qui utilise une station de travail...
6
Pour effectuer cette tâche, une technique pour démasquer les éléments de réseaux est
nécessaire. Un protocole pour obtenir les informations de gestion est aussi nécessaire. SNMP est
un protocole qui permet de réaliser ces fonctionnalités. [H1]
2.2.2. L’interprétation des données

Une fois que l’on a les informations de gestion, il est important de les interpréter correctement.
Par exemple : 5000 paquets par seconde sur un port d’un routeur est peut-être normal ou peut-être
le signe d’une surcharge et d’une dégradation de la qualité du service offert. Même si on connaît
la charge exacte d’un routeur, cette information ne suffit pas pour prendre des décisions
pertinentes de gestion.
Les manufacturiers d’équipements offrent quelquefois des logiciels qui savent interpréter les
informations de gestion de leurs équipements de gestion. Toutefois, une interprétation
automatique complète et correcte de l’état d’un réseau et de ses équipements est difficile à
réaliser. L’intervention humaine est souvent requise pour interpréter les données ou pour placer
des bornes acceptables. [H1]
2.2.3. Le contrôle des équipements

Quand des informations de gestion sont obtenues et comprises, il est quelquefois nécessaire
d’agir. Il doit être possible de demander à un équipement, par exemple, de se réinitialiser, de
couper ou d’activer des services...
Pour ce faire, un protocole de gestion doit transmettre un ordre (requête) à l’équipement
approprié pour déclencher l’action. En raison de l’absence de sécurité par le passé, cette
fonctionnalité a rarement été utilisée. [H1]
2.3. Principes de la gestion de réseau

Les architectures de gestion de réseau sont classées dans la catégorie des systèmes
client/serveur. On peut donc identifier trois composants:
- La partie client, appelée manager, est l’entité qui va superviser les opérations de gestion. Elle
sert d’interface entre l’utilisateur et le serveur. Il peut y avoir, le cas échéant, plusieurs managers.
7
- La partie serveur, appelée agent représente un ou plusieurs équipements. Un agent sert

d’interface entre l’équipement et le manager. Il peut également servir d’interface entre plusieurs
autres agents et le manager. L’agent permet de fournir une vue abstraite de l’équipement et
masque ainsi les différences qui existent entre les équipements. Il y a bien entendu plusieurs
agents dans un réseau.
- Le protocole est le langage utilisé par le manager et l’agent pour communiquer (SNMP,
CMIS, CMIP, CMOT, …) Il est mis en oeuvre par le biais d’un réseau. Ce protocole permet au
manager d’interroger l’agent (dans le cas du monitoring) ou de lui demander de modifier l’état de
l’équipement (dans le cas de la configuration). Le protocole est également utilisé par l’agent afin
d’avertir le manager de l’occurrence d’événements.
Figure 2-1: Relations entre manager, agents et protocole
8
Dans le cadre de notre projet on a opté à l’utilisation du protocole SNMP qui offre une grande
panoplie de fonctionnalités
2.4. SNMP
2.4.1. Historique
L’activité de recherche et de standardisation au niveau de SNMP est menée sous l’égide
de l’IETF (Internet Engineering Task Force). La première version de SNMP a vu le jour en 1989.
La seconde version, appelée SNMP v2 a été standardisée en 1992 [RFC1905]. Cette version
apporte essentiellement des changements au niveau de la sécurité et de la confidentialité des
opérations de gestion. Suite à des problèmes apparus lors de la mise en opération de la seconde
version du protocole, ces aspects ont été classés obsolètes en 1996 lors d’un des meeting tri
annuel de l’IETF. Ce dernier rebondissement a eu pour effet, d’une part de renvoyer SNMP à son
état de 1989 et d’autre part, de déclencher les recherches sur SNMP v3. Les travaux se
poursuivent actuellement et petit à petit les différents éléments de l’architecture SNMP v3 sont
proposés à la communauté scientifique [RFC2274]. SNMP v3 (dans les aspects qui sont
actuellement définis) est en passe de devenir un standard car il est accepté par le working group
SNMP v3 en tant que proposed standard. A l’heure actuelle, SNMP v1 reste la version la plus
utilisée. De plus, les résultats obtenus avec SNMP v1 sont immédiatement applicables à SNMP-
v2. [H1]
2.4.2. Les entités

SNMP suit l’architecture client/serveur, le client étant le manager et le serveur l’agent.
Contrairement aux architectures client/serveur habituelles où un serveur interagit avec plusieurs
clients, SNMP est l’exemple d’un schéma inverse: un client, souvent unique, communique avec
plusieurs serveurs.
Il y a un agent par équipement à gérer. L’agent conserve une série de variables qui modélisent
l’équipement. Le manager, au travers de l’agent, consulte et/ou modifie les valeurs des variables
à l’aide d’opérations de management. Des changements d’état internes à l’équipement modifient
eux aussi les valeurs des variables. La manière dont l’agent doit être informé de ces changements
n’est pas spécifiée dans SNMP. L’ensemble des variables gérées est appelé MIB (Management
Information Base). Le manager interagit avec l’agent via un protocole de communication qui
9
spécifie la dynamique de la communication (mécanismes de question/réponse), ainsi que la

structure des messages échangés.
Figure 2-2: Architecture SNMP
2.4.3. La Management Information Base

La Management Information Base (MIB) contient les variables qui forment le modèle
informationnel de l’équipement. Les variables sont organisées sous une forme arborescente. Les
nœuds intermédiaires servent uniquement de points de rattachement pour les branches, ils ne
contiennent aucune valeur. Les feuilles par contre stockent des valeurs. La MIB doit être
considérée sous deux points de vue. [H2]
La première vision est une vision en terme de spécification du modèle informationnel c’est-à-
dire les variables qui existent, leur type et les relations entre ces variables. Il est important
d’insister sur le fait que, selon cette optique, la MIB ne contient aucune valeur, il s’agit
uniquement d’une spécification structurelle. Les nœuds de l’arbre sont appelés, dans ce cas,
objets. Comme on le verra ultérieurement, la distinction en faite entre objet et instance. Cette
distinction est la base de la philosophie orientée objet. Le parallèle ne peut cependant être mené
plus loin: les notions de classe, héritage et polymorphisme n’ont pas d’équivalent dans le modèle
informationnel SNMP. [H2]
Le second point de vue est celui de l’arborescence de valeurs. Les valeurs sont les instances
des objets cités ci-dessus. Pour une MIB ’déclaration’ (uniquement les objets) et son équivalent
’implantation’ (uniquement les instances), on a les règles suivantes:
A chaque instance correspond un et un seul objet dans la MIB ’déclaration’.
10
A chaque objet correspond zéro, une ou plusieurs instances. Remarquons que les premier et
dernier cas sont rares. Lorsqu’un objet n’à aucune instance, c’est qu’il est présent dans la MIB
pour des raisons historiques mais qu’il est marqué comme obsolète.
La MIB déclaration est quelque chose de statique: on ne peut pas rajouter d’objets pendant que
l’agent fonctionne. La MIB implantation est semi-dynamique: seuls certains types d’objets
supportent l’ajout d’instances. Les autres instances existent de manière prédéfinie. Nous
reviendrons sur ces aspects ultérieurement.
Figure 2-3: Structure d’indexation des données dans la MIB-2 SNMP
11
Nom de la MIB-2 SNMP Utilité

System Nom, emplacement et description de l’équipement (switch,
routeur)
Interfaces Interfaces réseau et les données liées au trafic mesuré
Ip Statistiques sur le trafic IP, table de routage, table ARP
Icmp Statistiques sur le trafic ICMP
Tcp Paramètres et statistiques du trafic TCP
Udp Paramètres et statistiques du trafic UDP
Egp Informations sur la mise en œuvre du protocole EGP

(External Gateway Protocol)
Transmission Informations au sujet des moyens de transmission et des

protocoles d’accès aux interfaces de l’équipement
Snmp Paramètres et statistiques du trafic SNMP
Tableau 1 : Informations principales de la MIB-2 SNMP
2.4.3.1. Déclaration des objets
La MIB déclaration est décrite à l’aide d’un langage spécifié dans un standard appelé
Structure of Managed Information (SMI). Pour SNMP v1, ce standard est le Request
For Comment 1155 [RFC1155]. Le langage utilise pour sa définition la syntaxe ASN.1. Chaque
objet qui y est déclaré inclut les informations
suivantes:
- Un nom.
- Un type: il s’agit soit d’un type simple: INTEGER, OCTET-STRING, NULL, soit d’un
type de construction: SEQUENCE-OF, SEQUENCE, soit d’un type spécifique:
NetworkAddress, IpAddress, Counter, Gauge, TimeTicks.
- Un modificateur d’accès: read-write, read-only, write-only, not-acessible.
- Un modificateur de statut: mandatory, optional, obsolete.
- Une description: il s’agit d’un texte en langage naturel, qui décrit l’utilité de l’objet.
12
L’objet snmpInPkts dans MIB II :

snmpInPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of Messages delivered to the
SNMP entity from the transport service."
::= { snmp 1 }
2.4.3.2. Organisation et identification des objets et des instances
Les objets et instances sont nommés par un identificateur que l’on appelle object identifier. Il
s’agit d’une suite de nombres séparés par des points. La dot notation fournit un chemin dans
l’arbre à partir de la racine. La racine est identifiée par le nombre ’1’. Le nombre suivant, c’est-à-
dire le second nombre dans la dot notation, identifie le numéro du fils de la racine. On procède
récursivement jusqu’à la fin de l’object identifier. A titre d’exemple, l’objet snmpInPkts possède
comme object identifier 1.3.6.1.2.1.11.1 Les cinq premiers identificateurs sont fixes car ils
correspondent à la racine de toute l’arborescence de management:
iso(1).org(3).dod(6).internet(1).mgmt(2)
Le sixième identificateur correspond à mib2(1) qui est la MIB permettant de gérer un stack
TCP/IP standard. L’objet snmpInPkts est le premier fils en partant de la gauche du groupe snmp
qui lui-même a l’identificateur 11. On utilise comme notation abrégée snmp(11).
L’object identifier d’une instance est construit sur base de l’object identifier de l’objet
correspondant. Suivant que l’instance appartienne à une table (un ensemble de lignes) ou soit une
instance isolée (appelée variable simple) le schéma de construction est différent.
Dans le cas des variables simples, on postfixe l’identificateur de l’objet par un numéro
d’instance. Les instances sont numérotées à partir de zéro. L’instance correspondant à l’objet
snmpInPkts sera donc identifiée par 1.3.6.1.2.1.11.1.0 Si une instance supplémentaire existe (ce
qui n’est pas le cas ici), elle porte l’identificateur 1.3.6.1.2.1.11.1.1 et ainsi de suite. L’accès à des
13
instances appartenant à des tables est plus complexe, car SNMP utilise le concept d’adressage
associatif.
2.4.4. Les opérations de management

La simplicité de SNMP est en partie due à la simplicité de ses opérations de gestion. Il y en a
quatre:
- GET : permet au manager de récupérer la valeur contenue dans une instance.
- SET : permet au manager d’assigner une valeur à une instance.
- GET-NEXT : permet à partir d’un point de l’arborescence de trouver l’instance la plus
proche.
- TRAP : permet à l’agent d’envoyer une notification spontanée au manager.
La distinction est faite entre une opération SNMP et une requête SNMP. Les relations entre
ces deux concepts sont les suivantes:
• Une requête SNMP contient plusieurs opérations.

• Toutes les opérations d’une requête doivent être du même type (ex: uniquement des
GET).
Si une des opérations de la requête échoue (ex: un SET sur un objet read-only), aucune
opération de la requête ne peut être réalisée. Ca n’est réellement intéressant que dans le cas des
opérations SET qui modifient la MIB. Cette propriété est appelée atomicité d’une requête et peut
être implantée comme suit. Le noyau de la méthode consiste à retenir dans une liste les objets
modifiés ainsi que leur valeur. Si une des opérations est source d’erreur, la liste des objets
modifiés est utilisée pour effectuer un “rollback” et restaurer le système dans l’état précédant le
traitement de la requête. Cette technique est relativement simple à implanter. D’autres techniques
du type “commit” peuvent également être utilisées.
Lors des différentes opérations, il peut survenir des erreurs. Les plus importantes sont les
suivantes:
• Non-respect du type d’une instance lors d’un SET. Ex: assigner un OCTET-STRING à une
instance de type INTEGER (erreur badValue).
14
• Non-respect de l’accès d’une instance lors d’un SET: Ex: assigner une valeur à une
instance read-only (erreur readOnly).
• GET-NEXT d’une instance non existante. Lorsqu’il n’y a plus d’instance après le point de
départ, le GET-NEXT renvoie une erreur (noSuchName).
• GET ou SET d’un nœud de la MIB qui n’est pas une instance (erreur noSuchName).
2.4.5. Comparaison entre SNMP v1, v2 et v3

SNMP en est actuellement à sa troisième version. Les deux premières versions sont
standardisées [RFC1157, RFC1905]. La troisième est en cours d’élaboration et un working group
(SNMP version 3) lui est dédiée au sein de l’IETF [RFC2274]. Il faut également citer l’activité
du working group Distributed Management qui examine les conséquences liées à l’utilisation de
plusieurs managers pour gérer un réseau.
Avant que les aspects relatifs à la sécurité ne soient rendus obsolètes, SNMP v2 différait de
SNMP v1 selon deux critères:
1. Le support pour sécuriser (authentification et confidentialité) les opérations a été renforcé.
SNMP v2 offre la notion de groupe défini comme étant un contexte d’exécution des opérations de
gestion. Ce contexte définit, entre autres, l’ensemble des objets qui peuvent être gérés, le
protocole de transport utilisé (ex: UDP) et la méthode d’authentification utilisée pour reconnaître
la légitimité d’une requête.
2. L’ajout d’une opération GET-BULK qui permet de rapatrier vers le manager des grandes
quantités de données en les répartissant sur plusieurs messages de réponse. A présent, l’opération
GET-BULK est la seule différence avec la première version du protocole. [H2]
2.5. Le service CMIS

CMIS est l'ensemble des fonctions communes de la gestion système permettant de réaliser le
transfert des opérations et des notifications de gestion. Il est offert par l'entité de service CMISE
de la couche application. L'élément CMISE se compose de quatre entités distinctes:
15
· cœur de CMISE, la machine protocolaire CMIPM (Common Management Information

Protocol Machine) qui met en oeuvre le protocole et gère les unités de données du protocole
CMIP;
· le fournisseur de service CMISE qui est chargé de recevoir les primitives CMISE et de
transmettre les unités de données de service correspondantes (Service Data Unit, SDU) à
CMIPM;
· l'utilisateur de service ROSE qui gère les requêtes faites à ROSE.
Elles permettent d'échanger les PDUs entre deux protocoles CMIP;
Enfin, un gestionnaire de d'entité qui gère les primitives non normalisées de communication avec
la fonction de contrôle d'association simple (SACF). L'entité CMISE distingue les six services
d'opérations (qu'elle peut traiter sans aucune connaissance du contenu, laquelle est laissée à
SMASE) et un service de notification, qui sont:
- M_CREATE pour demander la création d'un objet dans la MIB de l'agent (Mode confirmé);
- M_DELETE pour supprimer des objets dans la MIB de l'agent (Mode confirmé);
- M_ACTION pour demander l'exécution d'une action sur un ou plusieurs objets (confirmé ou
non);
- M_SET pour modifier les valeurs d'attributs d'objets (confirmé ou non);
- M_GET pour consulter les valeurs associées aux attributs d'objets (confirmé ou non);
- M_CANCEL_GET pour demander de ne pas recevoir les résultats d'un GET précédent
(Mode confirmé);
- M_EVENT_REPORT pour transmettre un rapport d'événement relatif à un objet (confirmé
ou non). [H4]
2.6. Le protocole CMIP

Pour présenter le protocole CMIP qui se base sur les états de fonctionnement de la machine
protocolaire CMIPM (CMIP Machine), il faut connaître la structure de CMISE (Figure 2.4) . Une
instance de ce dernier est composée d'une machine protocolaire CMIPM, d'un fournisseur de
service CMISE (CMISE-provider), d'un utilisateur de service ROSE (ROSE-user), d'un
gestionnaire et de trois SAPs, SAPcmise- smase, SAP-cmise-rose, SAP-cmise-sacf. La machine
CMIPM met en oeuvre les éléments de procédure du protocole CMIP et gère les unités de
protocole CMIP (CMIP-PDUs). CMISE-provider gère les primitives de service CMISE. Il reçoit
16
les primitives CMISE de requête et de réponse provenant du CMISE-user de SMASE et en

transmet les unités de service CMISE (CMISE-SDUs) à CMIPM. Il émet des primitives CMISE
d'indication et de confirmation à l'intention du CMISE-user de SMASE lorsque CMIPM lui
demande de transférer des CMISE-SDUs. ROSE-user gère les primitives de service ROSE. Il
reçoit des primitives ROSE d'indication provenant du ROSE-provider de ROSE et en transmet les
unités de service ROSE (ROSE-SDUs) à CMIPM. Il émet des primitives ROSE de requête à
l'intention du ROSE-provider de ROSE lorsque CMIPM lui demande de transférer des ROSE-
SDUs.
Le gestionnaire gère les primitives non normalisées d'interaction avec SACF (Single
Association Control Function) chargé de coordonner le travail des ASEs (Application Service
Element). SAP-cmise-smase représente le point d'accès aux services de CMISE. C'est l'une des
extrémités de la connexion qui relie SMASE à CMISE. Par cette connexion transitent les
primitives CMISE entre ces deux éléments. SAPcmise- rose représente le point d'accès aux
services de ROSE. Par cette connexion transitent les primitives ROSE entre ces deux éléments.
SAPcmise- sacf représente le point d'accès aux services non normalisés offerts par CMISE à la
fonction SACF.
Figure 2.4 : Composition de CMISE
17
Une machine protocolaire est décrite sous la forme d'un automate. Celui ci se présente comme
une boite noire sollicitée par des événements extérieurs, qui déclenche un traitement interne
spécifique pour chaque événement reçu en fonction de l'état dans lequel elle se trouvait au début
du traitement, il génère des événements sortants et change éventuellement d'état à la suite de
chaque traitement déclenché. La description du protocole CMIP par la norme [ISO 9596] permet
d'identifier six états de fonctionnement de CMIPM:
· IDLE: c'est l'état de repos de CMIPM. Dans cet état, le protocole est inactif;
· ASSOCIATED: c'est l'état de fonctionnement normal de CMIPM lorsque l'association
d'application est établie. Il est prêt à accepter des primitives CMISE;
· WCFESTA: CMIPM est en attente d'une confirmation d'établissement d'association que doit
rendre l'entité SMAE distante;
· WRPESTA: CMIPM est en attente d'une réponse d'établissement d'association que doit
rendre son utilisateur, c'est à dire SMASE;
· WCFTERM: CMIPM est en attente d'une confirmation de terminaison d'association que doit
rendre l'entité SMAE distante;
· WRPTERM: CMIPM est en attente d'une réponse de terminaison d'association que doit
rendre son utilisateur SMASE. [H4]
2.7. Le protocole CMOT

Le protocole CMOT est la migration du système de gestion de réseaux TCP/IP vers la
normalisation. Le groupe qui travaille sur CMOT (CMIP over TCP/IP) s'est intégré à l'OSI sous
le nom de OIM (OSI Internet Management). Son principal rôle est de produire un ensemble de
spécifications qui offrent les services CMIS et le protocole CMIP sur des réseaux de type
TCP/IP. L'architecture envisagée pour CMOT consiste à rajouter au-dessus des protocoles TCP et
UDP une couche présentation simplifiée LPP (Lightweight Presentation Protocol), les services
ACSE, ROSE, CMIP, et CMIS. Avec CMOT, la relation gestionnaire agent fonctionne en mode
connecté et la MIB est constituée d'un ensemble d'objets comme pour la gestion OSI. Cependant,
bien que la démarche semble fort intéressante, il n'y a pas à l'heure actuelle de véritable
implémentation de ce protocole sur les diverses plates-formes commerciales. [H4]
18
2.8. Outils d’administration

Les outils d’administration se répartissent en deux catégories :
- Les outils locaux d’administration
- Les plates-formes d’administration
2.8.1. Outils Locaux

La plupart des outils sont prévus pour travailler sur un modèle client/serveur, ce qui permet
des interventions à distance. Parmi ces outils, on distingue :
- Les outils de diagnostic tels que ping, traceroute, nslookup, …
- Les consoles d’administration de câblage
- Les moniteurs de réseau (LANalyzer de Novell, 3Com Networking Monitoring, …)
- Les analyseurs de protocoles (analyseurs de réseau) ; ce sont des outils matériels ou
logiciels qui permettent d’interpréter la charge utile des paquets, de capturer des données
transmises sans cryptage les testeurs de câblage pour le test de continuité et de
défaillance du câblage
- Les sondes insérées dans les réseaux pour surveiller le fonctionnement, détecter les
nœuds d’un segment, capturer du trafic depuis et vers des nœuds sélectionnés.
2.8.2. Plates-formes d’administration

Elles offrent des services de base et des outils qui donnent à l’utilisateur un environnement
homogène à partir duquel il lancera les applications dont il a besoin pour administrer le réseau.
On distingue :
- Les hyperviseurs qui sont des plates-formes complètes d’administration de réseau. Ils
offrent des services d’une administration propriétaire (Netview d’IBM, Openview de HP).
Les hyperviseurs offrent une vue d’ensemble du réseau (état des liens, d’un port d’un
routeur, d’une carte, …)
- Les plates-formes ou systèmes intégrés au système d’exploitation qui sont des ensembles
d’outils non seulement pour la gestion des utilisateurs, des ressources et de la sécurité, mais
aussi la supervision du fonctionnement général et tout particulièrement de la machine
serveur (charge du CPU, …). On peut citer entre autres systèmes intégrés Systemview
19
d’IBM, Sun Net Manager / Solstice Enterprise Manager, Spectrum, ISM – OpenMaster.
[H3]
Parmi les services de base offerts par les plates-formes, on peut noter :
- La découverte et la gestion de la topologie du réseau ; découverte automatique des
machines du réseau, et dessin de la topologie avec les interconnexions, les routeurs, …
- La gestion des ressources
- La gestion des événements
- Les fonctions de collecte d’informations et d’interrogation
Conclusion
Après avoir fait l’étude de ces différents concepts liés à la gestion des réseaux, nous allons
essayer par la suite de présenter la Backbone IP/MPLS de Tunisie Télécom qui représente le
réseau le plus étendu en Tunisie.
20
Chapitre 3
Description de l’existant
3.
Introduction
Dans ce chapitre nous allons présenter sommairement l’architecture déployée ainsi la variété
des équipements qui vont être géré par notre application à fin de s’arrêter sur le niveau de
complexité de la gestion d’un tel réseau.
3.1. Description du Backbone IP de Tunisie Télécom
Le Backbone IP national dont Tunisie Télécom s’occupe de son évolution ainsi que de sa
gestion est constitué principalement de 11 routeurs régionaux ou principaux éparpillés sur la
totalité du territoire tunisien. Ces routeurs sont caractérisés par leur bonne performance (les
gammes les plus répandues sont la gamme 7500 et 7200 de Cisco), ils assurent une couverture
maximale du pays, leur fonction principale est de permettre un routage fluide et efficace du trafic
transitant sur le Backbone.
Les clients ne sont pas connectés directement via les routeurs principaux mais c’est à la charge
des routeurs périphériques ainsi que les serveurs d’accès d’assurer l’interconnections des
différents types d’utilisateurs (RTC, LS, X25, FR, ADSL), plusieurs gamme de routeurs sont
utilisées tels que Cisco 3660,2600,36200 Max6000,Huwai .
Pour assurer la fiabilité du Backbone, une architecture redondante est mise en place pour
l’interconnexion des routeurs principaux. Un site doit être relié au moins à deux sites différents
pour assurer à la fois le basculement du trafic en cas de panne ainsi que le partage de charge en
cas de congestion.
Des routes statiques sont implémentées au niveau des routeurs périphériques pour permettre
d'acheminer le trafic aux clients finaux.
21
Le routage dynamique est implémenté au niveau des routeurs principaux pour calculer de
nouvelles routes, détecter des changements de topologie et pour s'échanger les mises à jour. Ce
type de routage est utilisé aussi au niveau des routeurs périphériques pour injecter les routes
statiques contenues dans les tables de routage des routeurs principaux.
Le protocole de routage utilisé au niveau du Backbone est l'OSPF (Open Shortest Path First)
qui est un protocole " link state" (qui dépend de l'état de la liaison) et qui utilise pour le calcul des
routes l'algorithme SPF (Shortest Path First). Les routeurs principaux sont groupés dans l’area 0
(area Backbone) les routeurs périphériques de chaque zone sont groupés dans une area spécifique
AreaX.
Le routage, que ce soit statique ou dynamique, ne répond pas au besoin car le routage du trafic
sortant des clients sur le Backbone se fait généralement à la source d’où la nécessité d’utilisés la
technique PBR (Policy Based Routing). Dans le cas du Backbone IP de Tunisie Télécom, la PBR
utilisée est basée sur le routage à la source qui permet dans la majorité des cas d'acheminer le
trafic provenant des abonnés Internet vers leurs FSIs puisque à partir de l'adresse source de
l'abonné le routeur va déterminer à quel FSI il appartient. L'inconvénient majeur de cette
politique c'est qu'elle est consommatrice de CPU.
3.2. Architecture IP/MPLS du Backbone IP
Le Backbone MPLS est constitué de routeurs Cores et de routeurs Edges. Les routeurs Edges
vont s’occuper de tout ce qui est services et les routeurs Cores ont la charge d’assurer seulement
la commutation des paquets. Le problème c’est qu'il y a des routeurs déjà opérationnels ne
supportent pas MPLS d’où il a fallu les placer derrière les routeurs Edge. Comme première étape
il faut acquérir l’acquisition de nouveaux routeurs pour assurer la fonctionnalité du Backbone
core est indispensable, la gamme 12000 de Cisco est fréquemment conseillée dans ce genre de
contexte.
Pour passer à MPLS quelques actions ont été réalisées :
- La vérification des versions des routeurs,

- L’activation de IP MPLS sur les interfaces du routeur,
22
- La spécification d’un protocole d’échange de label (LDP / TDP),

- Vérification du protocole de routage IGP,
- La définition des MTU sur les routeurs et les switchs.
CE
PE
PE
P P
CE
PE
P P
PE
PE
P P PE
PE
Figure 3.1: Architecture MPLS pour le Backbone IP
23
Les VRFs
La notion même de VPN implique l’isolation du trafic entre sites clients n’appartenant pas au
même VPN. Pour réaliser cette séparation, les routeurs PE ont la capacité de gérer plusieurs
tables de routage grâce à la notion de VRF (VPN Routing and Forwarding). Une VRF est
constituée d’une table de routage, d’une FIB (Forwarding Information Base) et d’une table CEF
spécifiques, indépendantes des autres VRF et de la table de routage globale. Chaque VRF est
désignée par un nom sur les routeurs PE. Les noms sont affectés localement, et n’ont aucune
signification vis-à-vis des autres routeurs. Chaque interface de PE reliée à un site client est
rattachée à une VRF particulière. Lors de la réception de paquets IP sur une interface client, le
routeur PE procède à un examen de la table de routage de la VRF à laquelle est rattachée
l’interface, et donc ne consulte pas sa table de routage globale. Cette possibilité d’utiliser
plusieurs tables de routage indépendantes permet de gérer un plan d’adressage par sites, même en
cas de recouvrement d’adresses entre VPN différents.
Pour l’échange des routes et des informations concernant les VRFs entre les routeurs PE,
plusieurs possibilités sont offertes :
- Un protocole de routage spécifique pour chaque VRF, mais avec l’augmentation du

nombre de VRF nous aurons un problème de scalabilité et un traitement supplémentaire
coté routeurs PE.
- Un seul protocole de routage dédié pour tous les VRFs, le problème c’est que le routeur
PE aura connaissance de touts les routes clients des différents VRFs.
- La solution la plus intéressante est l’utilisation du protocole M-BGP qui permet l’échange
des routes entre les routeurs PE seulement.
Optimisation du routage Inter-PE
Pour l’échange d’informations entre les extrémités des VRFs, des sessions BGP doivent être
établîtes. Normalement un Full-mesh est réalisé entre tous les routeurs PE, mais vue le grand
nombre de routeurs périphériques que dispose le Backbone, le fait d’appliquer un Full-mesh entre
ces différents routeurs va charger le réseau lors de la mise à jours de la table de routage. Pour
remédier à ça un Full-mesh est appliqué entre les routeurs Core et des routes reflector entre les
24
routeurs P et PE pour informer les routeurs PE des modifications apportées à la table de routage
et communiquer des informations sur les VPNs.
Figure 3-1 : Optimisation du routeur BGP inter-PE
Conclusion
Nous venons, au niveau de ce chapitre, de présenter l’architecture du Backbone IP/MPLS ainsi
que la politique de routage utilisée. La richesse en terme d’équipements et de technologie
déployée, rend la tâche de la mise en place d’une application pour la gestion du Backbone une
tâche assez complexe.
25
Chapitre 4 : Conception et implémentation
Chapitre 4
Conception et implémentation
4.
Introduction
La programmation orientée objet est une technique qui est à la base de tous les nouveaux
projets de développement de logiciels. La mise en oeuvre de logiciels réseau n’échappe pas à
cette tendance. Comme tous les autres projets logiciels, les logiciels réseaux peuvent profiter
des
avantages de l’orienté objet. Cette technique permet la construction d’un programme solide,
bien structuré, facile à visualiser et qui est facile à modifier et à maintenir.
Ce présent chapitre est consacré à détailler les mécanismes de fonctionnement de quelques
modules de TTNetView.
4.1. Conception
Après une étude détaillée de l’architecture du Backbone et une compréhension des MIBs
de plusieurs constructeurs (Cisco, Nortel, Luccent…), on a choisi de répartir le Backbone en
des groupes suivant la gamme des équipement et à chaque groupe on va affecter une
politique de polling SNMP.
4.1.1. Base des données
Pour la base de données de notre application, nous avons utilisé les tables suivantes :
• Table Groupe (Figure 4.1) qui va contenir la liste des différents groupes. Les champs de
cette table sont :
- NOM_GROUPE : Nom du groupe
- DESCRIPTION : Description du groupe
Figure 4-1: Structure de la table Groupe
26
• Table Routeur (Figure 4.2) qui va contenir la liste des routeurs du Backbone. Les champs
de cette table sont :
- IP_Routeur : Adresse IP du routeur
- Nom_Routeur : Nom du routeur
- Description_Routeur : détails concernant le routeur
- Niveau 1 : Mot de passe du premier niveau.
- Niveau 2 : utilisée pour entrer en communication avec des routeurs où le SSH est
activé.
- Nom_Groupe : à quel groupe appartient ce routeur.
- SNMP_Community : la communauté SNMP de ce routeur.
- CMD : commande pour avoir le fichier de configuration du routeur.
- Niveau 3 : Mot de passe pour passer au mode configuration.
Figure 4-2: Structure de la table Routeur
• Table OID (Figure 4.3) : défini les OID des informations SNMP à extraire concernant les
routeurs et les interfaces. Les principaux champs de cette table sont :
- OID : contient les OIDs des informations SNMP à extraire
- Name : les noms des variables SNMP
- Taille : la taille du résultat en nombre caractères, cette information est utilisée pour
mettre à jour la table historique.
- Stored : on va indiquer si cette information va être sauvegardée au niveau de
l’historique.
27
- Seuil : Pour la gestion des événements, si la valeur de l’information SNMP est

supérieure à ce seuil un événement est généré.
- Cible : Cette OID concerne un routeur ou un interface.
Figure 4-3: Structure de la table OID
Pour chaque groupe on va :

- Créer une table historique_Nom_Groupe (Figure 4.4) gardant l’historique sur les états de
différents routeurs.
Figure 4-4: Structure de la table historique
- Créer une table historique_int_Nom_Groupe (Figure 4.5) gardant l’historique sur les
interfaces de différents routeurs.
Figure 4-5: Structure de la table historique
- Créer un dossier portant le nom du groupe, dans lequel on va sauvegarder les fichiers de
configuration des routeurs de ce groupe.
28
Une table clients (Figure 4.6) sera créée pour contenir les différents clients (Publinets,
Lycée, Faculté, ...) qui sont connectés sur le Backbone. Les champs de cette table sont :
- IP_Routeur : adresse IP du routeur
- Nom_Routeur : Nom du routeur
- Index_int : index de l’interface
- Nom_int : nom de l’interface
- Description : Description de la liaison
- Ipaddress : Adresse IP de l’interface
- Netmask : Masque de sous réseau
- MTU : Taille maximale d’une trame qui peut passer par cette interface
- Bandwidth : Bande passante
- Routes : les routes qui passent par cette interface.
Figure 4.6
Figure 4-6: Structure de la table clients
Les tables concernant l’historique sont des tables dynamiques, une colonne sera ajoutée
chaque fois qu’on veut sauvegarder les traces d’une nouvelle variable SNMP concernant les
routeurs ou leurs interfaces. La nouvelle colonne va porter le nom de la nouvelle variable.
A chaque groupe, on va choisir les informations SNMP utiles à extraire de chaque routeur.
Par exemple pour un routeur de type Huawei, il n’est pas nécessaire d’avoir la valeur de la
charge se son CPU parce que sa MIB ne contient pas une telle valeur.
29
4.1.2. Les modules de bases
Parmi les modules importants du TTNetView, nous citons :

- SNMPv1CommunicationInterface.
- SimpleGet.
- SNMPCollector.
- ConfigCollector.
- TTNetLocator.
4.1.3. Le Module SNMPv1CommunicationInterface
Cette classe (Figure 4.7) implémente des méthodes pour la communication avec les entités
SNMP. La version SNMP utilisée est la version 1, puisque la plupart des routeurs du
Backbone supportent cette version. La communication se fait à travers le port UDP 161, le
port standard du protocole SNMP, en utilisant les sockets.
En utilisant la version 1 du protocole SNMP, les données ne seront pas cryptées. Le
constructeur de cette classe nécessite l’adresse IP d’un routeur et le nom de sa communauté
SNMP.
Les principales fonctions de cette classe :

- getMibEntry() (équivaut à l’opération Get du protocole SNMP) : permet au
manager de récupérer la valeur contenue dans une instance.
- getNextMibEntry() (équivaut à l’opération Get-Next du protocole SNMP) : permet
à partir d’un point de l’arborescence de trouver l’instance la plus proche.
- retrieveAllMIBInfo() : cette fonction retourne les valeurs de toutes les variables d’une
MIB.
- retrieveMIBTable() : retourne le résultat d’une variable SNMP sous la forme d’une
table, exemple : Table ARP.
- setMibEntry() (équivaut à l’opération Set du protocole SNMP) : permet au manager
d’assigner une valeur à une instance.
- closeConnection() : fermeture de la connexion entre le manager et le routeur.
30
Figure 4-7: Structure de la classe SNMPv1CommunicationInterface
4.1.4. Le module SimpleGet
Cette classe (Figure 4.8) étend la classe SNMPv1CommunicationInterface. Elle

implémente d’autres fonctions pour la gestion de la table de routage d’un routeur à fin
d’extraire les routes qui passent par chaque interface, cette fonction n’est pas
implémentée dans tous les gestionnaires du réseau d’aujourd’hui.
Les principales fonctions de cette classe :
- get_longueur_table_routage() : retourne le nombre total des routes contenues dans
la table de routage d’un routeur.
- get_Table_de_Routage() : avoir la table de routage d’un routeur, cette fonction est
consommatrice en ressources CPU, mais elle ne perturbe pas le fonctionnement du routeur.
31
Figure 4-8: Structure de la classe SimpleGet
4.1.5. Le module SNMPCollector
SNMPCollector est le processus qui a pour tâche de collecter les informations SNMP et de
les stocker dans la base de données à fin de garder un historique bien détaillé sur les états des
routeurs et leurs interfaces.
SNMPCollector commence par contacter la base de données pour avoir la liste des
différents groupes, puis pour chaque groupe, il extrait à partir de la table Routeur la liste des
routeurs formant ce groupe et, à partir des tables OID_Nom_Groupe et
OID_int_Nom_Groupe, les OIDs des variables SNMP à gérer ainsi leurs seuils. Ensuite,
SNMPCollector teste la connexion avec le routeur en envoyant des requêtes Ping, s’il y a une
réponse il va stocker les diverses informations SNMP concernant son état dans la table
Historique_Nom_Groupe et les informations concernant ses interfaces dans la table
Historique_int_Nom_Groupe. Chaque fois qu’une valeur d’une variable SNMP excède le
seuil indiqué par l’administrateur, il y aura une émission d’un événement vers un fichier log.
La figure suivante (Figure 4.9) résume le fonctionnement du ce processus.
32
Base de
Données
Demande la liste des groupes Groupe Historique
SNMPCollector
N groupes
Routeur OID
For 1 to N do
Routeurs appartenant à groupe i

SNMPCollector
K Routeurs
OIDs de groupe i
OIDs
For 1 to K do
SNMPCollector Stockage de Value
Get Value
Of OID
Backbone IP/MPLS
Send Value
(Value
>
Seuil) OR
( !Ping)
Log
Figure 4-9: Schéma de fonctionnement du SNMPCollector
33
Les principales fonctions de cette classe (Figure 4.10) :

- SNMPCollector() : le constructeur nécessite une adresse IP et le nom de la
communauté SNMP d’un routeur. Il vérifie s’il y a de nouveaux OID pour chaque groupe
pour mettre à jour les tables d’historique.
- get_Data() : Cette fonction est nécessaire pour la communication avec la base de
données à fin d’extraire les informations nécessaires (les OIDs, les seuils, …)
- Get_SNMP() : C’est le cœur de cette classe, elle est responsable de la gestion des
communications SNMP entre le manager et les routeurs.
- Send_Event() : pour la gestion des événements pour le log.
Figure 4-10: Structure de la classe SNMPCollector
4.1.6. Le module ConfigCollector
Le rôle de ConfigCollector est de sauvegarder les fichiers de configurations des routeurs et

d’extraire les informations sur les clients connectés sur le Backbone.
34
ConfigCollector commence par contacter la base de données pour avoir la liste des
différents groupes, puis pour chaque groupe, il extrait à partir de la table Routeur la liste des
routeurs formant ce groupe.
Ensuite, pour chacun, ConfigCollector teste la connexion en envoyant des requêtes Ping,
s’il y a une réponse, il va entrer en communication avec le routeur en utilisant le protocole
Telnet et lui envoyer la commande qui permet d’avoir son fichier de configuration, par
exemple :
- ‘’ show run ’’ pour les routeurs Cisco
- ‘’ display current-configuration ’’ pour les routeurs Huawei.
Ces fichiers de configuration seront stockés dans des dossiers portant les noms des
différents groupes. Pour les informations concernant les interfaces (Nom Interface,
description, adresse IP, Bande passante…) seront stockées dans la table clients pour être
utilisées pour la localisation d’un client. La figure suivante (Figure 4.11) résume le
fonctionnement du ce processus.
35
Base de
Demande la liste des groupes Groupe
ConfigCollector Données
Clients
N groupes
Routeur
For 1 to N do
Routeurs appartenant à groupe i

ConfigCollector
K Routeurs
For 1 to K do
ConfigCollector
Ping
Telnet
Ping Get Config Backbone IP/MPLS
Send Config
Save Config
Get Interfaces
Log
Figure 4-11: Schéma de fonctionnement du ConfigCollector
36
Les principales fonctions de cette classe (Figure 4.12) :

- Open_Connection() : cette fonction permet d’ouvrir une session Telnet sur un routeur.
- Ping() : teste la liaison avec un routeur.
- getConfig() : Avoir le fichier de configuration d’un routeur.
- saveConfig() : Enregistrement du fichier de configuration dans un fichier texte.
- getInterfaces() : Avoir les informations nécessaires concernant les interfaces d’un routeur.
Figure 4-12: Structure de la classe ConfigCollector
4.2. Implémentation
4.2.1. Outils utilisés
4.2.1.1. Langage de programmation : Java
Java est développé par une équipe de Sun Microsystems, est le dernier né des langages de
programmation par objet. Fondé notamment sur le principe d’indépendance du support
d’exécution, il permet de générer du pseudo-code (appelé couramment bytecode) interprété
par une machine virtuelle.
L’essor de Java a été largement catalysé et médiatisé par le développement de l’Internet et
du World Wide Web. Une des caractéristiques les plus connues du code Java est en effet de
37
pouvoir être téléchargé et exécuté par des navigateurs Web. L’impact est tel que l’on estime
aujourd’hui le nombre de développeurs Java à plus de 500 000 à travers le monde.
La mise en œuvre dans les réseaux privés d’entreprise des technologies de l’Internet que
constitue l’Intranet ouvre, grâce à Java, de nouvelles perspectives qui révolutionnent la
manière de concevoir les architectures Clients-Serveurs déployées jusqu’à aujourd’hui. Les
postes clients s’allègent et représentent des coûts d’administration moins importants. Les
serveurs hébergent non seulement les données de l’entreprise mais aussi les applications
écrites en Java, qui sont écrites une fois et une seule, quel que soit leur support final
d’exécution. Elles peuvent ainsi être mises à jour de manière centralisée.
Les librairies de classes Java spécialisées, qui intègrent en particulier l’interrogation des
bases de donnés, ainsi que l’apparition des Network Computers, font de Java une technologie
clé du déploiement de ce nouveau système d’information de l’entreprise, centré sur le réseau.
Java présente plusieurs avantages :
- Simplicité : Java réduit le nombre de structures de données utilisables au minimum et

élimine les zones de recouvrement. Pour le programmeur, la simplicité de Java s’exprime
aussi en grande partie par le fait qu’il est libéré de la gestion explicite des adresses
mémoire des objets qu’il manipule. Cette disposition évite les erreurs de programmation
les plus fréquentes et les plus délicates à corriger.
- Neutralité vis-à-vis des architectures matérielles et logicielles : Java utilise un double

mécanisme de compilation et d’interprétation. Ce mécanisme permet au code généré par le
compilateur Java, appelé bytecode, d’être indépendant des architectures matérielles et des
systèmes d’exploitation. Le bytecode Java est en effet chargé et interprété par une machine
virtuelle, qui est elle-même portée sur la plupart des systèmes d’exploitation du marché.
- Vers une nouvelle architecture Client-Serveur : La mise en oeuvre d’applications Java

dans un réseau d’entreprise permet, en s’appuyant sur les APIs d’extension telles que
JDBC ou JavaIDL, de déployer des applications client – serveur. On peut dès aujourd’hui
bâtir un véritable Intranet en s’appuyant sur les standards du Web. En intégrant les
possibilités de relier simplement les applications Java au système d’information de
l’entreprise, on est maintenant capable de déployer des applications distribuées qui héritent
naturellement des qualités intrinsèques de Java.
38
4.2.1.2. Environnement de développement : JBuilder 2005
L’environnement de développement choisi est Borland JBuilder 2005. Il offre une

multitude d'atouts pour conserver son titre de meilleur outil de développement Java disponible
sur le marché. Il intègre, dans une interface agréable, tous les concepts d'ingénierie moderne,
WebServices, XML, tests unitaires, refactoring, debuger HotSwap, conception d'EJB 1.1 et
2.0 , JSP/Servlet, optimisation avec OptimizeIt et outil pour UML.
4.2.1.3. Système de gestion de base de données : Oracle 9.2.0
Oracle est l’un des SGBD les plus forts dans le monde des bases de données, il présente
plusieurs avantages dont :
- Sécurité au niveau ligne.
- JVM inclue dans le moteur.
- Support SQLJ, niveau 0 et 1.
- Gestion cluster, haute disponibilité.
- Edition des plan d'exécution.
- Parallélisme pour insert et update.
- Backup et restore parallèles.
- Tables de résumé.
- Rôles définis par l'utilisateur.
- Gouverneur de ressources.
- Attribution de priorités.
Le choix d’Oracle est basé sur plusieurs raisons :
- Les tables concernant l’historique sont des tables géantes.
- L’accès à la base doit être rapide.
- La base doit supporter plusieurs connexions à la fois.
- Tunisie Télécom utilise Oracle dans ses applications.
4.2.2. Interfaces utilisateurs
4.2.2.1. TTNetView
L’interface principale (Figure 4.13) du TTNetView présente la console

d’administration du Backbone IP/MPLS. Elle donne une vue globale sur les états des routeurs
et leurs interfaces ainsi un contrôle continu sur les événements générés par les différents
processus (SNMPCollector, ConfigCollector)
39
Panneau 1 Panneau 2
Panneau 3 Panneau 4
Figure 4-13: Interface principale de TTNetView

L’interface principale se compose de 4 panneaux, le premier (Figure 4.14) comporte la
liste des différents groupes et la liste des routeurs de chaque groupe.
40
Groupe Cisco_12000
Routeurs de ce groupe
Figure 4-14: Groupes et Routeurs
A la sélection d’un groupe, le deuxième panneau (Figure 4.15) va contenir les informations
concernant les routeurs de ce groupe (CPU, Mémoire utilisée, Mémoire libre, Nombre
d’interfaces…).
Pour les routeurs Cisco, on a choisit d’avoir les informations suivantes:
- Informations générales :
- IP_Routeur : Adresse IP du routeur
- sysName : Nom du système
- ifNumber : Nombre total d’interfaces
- Informations concernant l’état du routeur :
- cpu5min : Pourcentage de la charge du CPU pendant les 5 dernières minutes
- memUsed : Mémoire utilisé en bits
- memFree : Mémoire libre en bits
- tempIn : Température à l’entrée en Fahrenheit
- tempOut : Température à la sortie
- Informations concernant le protocole IP :
- ipOutNoRoutes : Nombre de paquets IP perdus
41
- Informations concernant le protocole SNMP :

- SNMPBadCommunityName : Nombre de paquets SNMP qui ont un nom de
communauté erroné, si ce nombre dépasse quelques centaines, il y aura un risque
d’attaque.
- Informations concernant le protocole TCP :
- tcpOpen : le nombre de connexions TCO ouverts
- tcpInErrors : Nombre de paquets TCP qui présentent des erreurs à l’entrée.
- Informations concernant le protocole de routage BGP :
- bgpId : Identifiant du routeur pour le protocole de routage BGP
- Informations concernant le protocole de routage OSPF :
- ospf_enabled : représente le statut du protocole OSPF 1 : Activé ou 2 : Désactivé
- ospf_Version : Version du protocole OSPF activée au niveau du routeur.
- ospf_Id : Identifiant du routeur pour le protocole de routage OSPF
Figure 4-15: Informations SNMP concernant les routeurs Cisco
A la sélection d’un routeur, ce panneau (Figure 4.16) va contenir les informations concernant
ses interfaces.
Pour un routeur Cisco, on a choisit les informations suivantes :
- nom_int : Nom d’interface (exemple : Serial 1/2)

- Description : Nom de la liaison (exemple : LS with ATI)
- Ip_address : Adresse IP de cet interface
- Netmask : masque de sous réseau
- MTU : Taille maximale pour une trame qui peut passer par cette interface
- Admin_Status : Etat administratif de l’interface
42
- Oper_Status : Etat opérationnel de l’interface

- Inbits : Trafic en entrée en bits
- Inpackets : Trafic en entrée en paquets
- Outbits : Trafic à la sortie en bits
- Outpackets : Trafic à la sortie en paquets
- CRC : Nombre de paquets à l’entrée qui présentent une erreur au niveau du CRC
- Collisions : nombre de collisions détectées à la sortie de cette interface.
- inQueueDrop : nombre de paquets rejetés parce que la file d’attente à l’entrée
est saturée
- outQueueDrop : nombre de paquets rejetés parce que la file d’attente à la sortie
est saturée.
Figure 4-16: Informations SNMP concernant les interfaces d’un routeur Cisco
Le panneau 3 va contenir des statistiques concernant les OID où le champ

‘’Stored’’ de la table OID est égal à ‘’yes’’.
- Statistiques d’une interface (Figure 4.17):
Pour les routeurs Cisco, on a choisit de sauvegarder : Inbits, Inpackets, Outbits,

Outpackets, CRC, Collisions, inQueueDrops, OutQueueDrops.
43
Figure 4-17: Statistiques concernant un interface d’un routeur Cisco
- Statistiques d’un routeur (Figure 4.18) :
Pour les routeurs Cisco, on a choisit de sauvegarder : CPU5min, memUsed,

memFree, TempIn, TempOut.
44
Figure 4-18: Statistiques concernant un routeur Cisco
Dans la base de données, on garde l’historique même d’une année. A chaque

courbe générée, on peut soit :
- Sauvegarder le résultat sous la forme d’une image portant l’extension.jpg

- Imprimer cette image
- Générer un rapport sous la forme d’une page html (Figure 4.19), cette page va
contenir toutes les statistiques des différentes informations SNMP.
45
Figure 4-19: Génération d’un rapport Concernant un interface d’un routeur Cisco
46
Le quatrième panneau (Figure 4.20) va contenir le log de SNMPCollector et du

ConfigCollector. Chaque fois, q’une valeur d’un OID dépasse sa seuil, un événement
est généré sous la forme :
‘’ Date de génération d’événement + Heure de génération d’événement +

Routeur cible + Information SNMP + valeur ‘’
- La couleur blanche indique un événement concernant un interface

- La couleur bleue indique un événement concernant un routeur
- La couleur rouge indique un événement critique : un routeur inaccessible pour
lequel on ne peut pas avoir les informations SNMP (Figure
4.21).
Figure 4-20: Génération des événements
47
On n’a pas pu
avoir des
informations
sur les routeurs
193.95.52.108,
193.95.52.98,
193.95.52.2
La console
d’événements
nous indique
que ces
routeurs sont
injoignables
Indique l’état du
processus
SNMPCollector
Figure 4-21: Exemple d’événements critiques
48
A partir du menu ‘’File’’ (Figure 4.22) du TTNetView, on peut :
- Ajouter un groupe (Figure 4.23) ou un routeur (Figure 4.24)

- Supprimer un routeur ou un groupe
Figure 4-22: Composition du menu ‘’File’’
Figure 4-23: Création d’un nouveau groupe
49
Figure 4-24: Création d’un nouveau routeur
A partir du menu ‘’Edit’’ (Figure 4.25) du TTNetView, on peut :
- Configurer les processus SNMPCollector et ConfigCollector (Figure 4.26) : pour

SNMPCollector, on doit spécifier l’intervalle de temps qui sépare 2 sessions de
polling du réseau. Pour ConfigCollector on doit indiquer le jour du sauvegarde
des fichiers de configuration des routeurs, cette opération se lance toujours à
minuit lorsque le réseau n’est pas chargé.
Figure 4-25: Composition du menu ‘’Edit’’
50
Figure 4-26: Configuration des processus
- Configurer les OIDs des différents groupes concernant les interfaces ou les routeurs
(Figure 4.27) : On peut ajouter (Figure 4.28), supprimer ou modifier un OID.
Figure 4-27: Configuration des OIDs
51
Figure 4-28: Ajout d’un OID
A l’ajout d’un OID, une nouvelle information sera ajoutée (Figure 4.29) :
Figure 4-29: Ajout de l’information ‘’whyReload’’
A partir du menu Process (Figure 4.30), on peut lancer :
Figure 4-30: Menu Process de TTNetView

Le processus ConfigCollector (Figure 4.31) : Chaque fois que le processus
ConfigCollector passe par un routeur son adresse sera affichée dans une boîte de
dialogue.
52
Figure 4-31: Interface de ConfigCollector
L’application TTNet Locator
4.2.3. TTNetLocator
TTNetLoctor est utilisé pour la localisation d’un client dans le Backbone IP/MPLS. On
peut utiliser pour la recherche l’adresse du routeur, l’adresse IP de l’interface, la description
de l’interface ou la table de routage (Figure 4.32).
Figure 4-32: Options de recherche dans TTNetLocator
Le résultat de la recherche va contenir :

- Adresse IP du routeur.
- Nom du routeur.
- Nom d’interface.
- Description de l’interface.
- Adresse IP du client.
- Masque du réseau.
- MTU.
- Bande passante.
- Routes passantes par cette interface.
53
A la sélection d’un client, on va avoir des informations supplémentaires concernant ce

client, ce sont les informations SNMP concernant le groupe auquel appartient le routeur de ce
client (Figure 4.33).
Figure 4-33: Interface de l’application TTNetLocator
Conclusion
Nous venons, au niveau de ce chapitre, de présenter les principaux modules utilisés ainsi
que les interfaces utilisateurs. Plusieurs informations n’ont pas pu être divulguées faute de
confidentialité.
54
Conclusion et perspectives
Conclusion et perspectives
La gestion de réseaux est l’un des domaines les plus complexes auxquels l’on puisse se
confronter; elle cumule la distribution, le modèle objet, le temps réel, le transactionnel, la
gestion d’équipements complexes. C’est en conséquence une source de coût importante pour
l’opérateur, qui se voit contraint d’investir des sommes significatives et des compétences
critiques dans une fonction qui semble non immédiatement rentable.
Néanmoins, le souhait exprimé ici concerne la compréhension de la nécessité de la

fonction Gestion de Réseaux, et son intérêt pour l’entreprise; ce n’est qu’à travers de la
gestion efficace que ce dernier sera en mesure d’offrir les services qui le différencieront de la
concurrence.
L’objectif de ce projet était essentiellement de développer un gestionnaire de réseau pour

le Backbone IP/MPLS de Tunisie Télécom pour offrir aux utilisateurs une certaine qualité de
service et permettre une utilisation optimale des ressources disponibles.
Ce travail, qui ne consiste pas une fin en soi, pourrait être complété de plusieurs manières.
Des modules peuvent être ajoutés à savoir la découverte de la topologie du réseau ;
découverte automatique des machines du réseau, dessin de la topologie avec les
interconnexions.
55
Bibliographie
Bibliographie & Néographies
Bibliographie
Simple Network Management Protocol de Nicolas ADENIS-LAMARRE et Vincent
BEDRUNE
Understanding SNMP MIBs de David Perkins et Evan McGinnis
Néographies
[H1] http:\\www-igm.univ-mlv.fr/~dr/ XPOSE2002/vollerin/solGestion.htm
[H2] http:\\ www.f4dwu.net/download/memoire2.pdf
[H3] http:\\0ryck.free.fr/doc du site hackerz/Administration snmp.html
[H4] http://www-lor.int-evry.fr/~agirs/gestion-reseaux-v2.03.pdf
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
http://www.simpleweb.org/ietf/mibs/
http://www.commentçamarche.com
http://www.guill.net
http://www.faqs.org/rfcs/rfc1157.html
http://www.developpez.com
56
Annexes
Annexe1: Attestations de formations
57
Annexes
58
Annexes
Annexe2: Exemple de MIB
MIB II (RFC 1213) :
• Groupe “Système”
– Informations génériques de configuration
• Groupe “Interfaces”
– Informations concernant les interfaces :
– type, adresse, nombre d’octets in/out, statut,…
• Groupe “ARP”
– Liaison Adresse Physique – Adresse logique
• Groupe “IP”
– Informations sur le niveau IP: TTL, tables de
routage, nombre de paquets,…
• Groupe “ICMP”
– Informations statistiques sur les messages ICMP:
– Nombre de messages, de messages Echo, …
• Groupe “TCP”
– Informations sur les connexions TCP : connexions en cours, nombre de messages, de
circuits ouverts, TTL, …
• Groupe “UDP”, “EGP”,“SNMP”,
RFC1213-MIB
DEFINITIONS ::= BEGIN
IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge,
TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212;
-- MIB-II (same prefix as MIB-I)
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
59
Annexes
-- textual conventions
DisplayString ::=
OCTET STRING
-- This data type is used to model textual information taken
-- from the NVT ASCII character set. By convention, objects
-- with this syntax are declared as having
-- SIZE (0..255)
PhysAddress ::=
OCTET STRING
-- This data type is used to model media addresses. For many
-- types of media, this will be in a binary representation.
-- For example, an ethernet address would be represented as
-- a string of 6 octets.
-- groups in MIB-II
system OBJECT IDENTIFIER ::= { mib-2 1 }
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
at OBJECT IDENTIFIER ::= { mib-2 3 }
ip OBJECT IDENTIFIER ::= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }
-- historical (some say hysterical)
-- cmot OBJECT IDENTIFIER ::= { mib-2 9 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
-- the System group
-- Implementation of the System group is mandatory for all
-- systems. If an agent is not configured to have a value
-- for any of these variables, a string of length 0 is
-- returned.
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
60
Annexes
STATUS mandatory
DESCRIPTION
"A textual description of the entity. This value should include the full name and version
identification of the system's hardware type, software operating-system, and networking
software. It is mandatory that this only contain printable ASCII characters."
::= { system 1 }
sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the network management subsystem contained in
the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides
an easy and unambiguous means for determining `what kind of box' is being managed. For
example, if vendor `Flintstones, Inc.' was assigned the
subtree 1.3.6.1.4.1.4242, it could assign the
identifier 1.3.6.1.4.1.4242.1.1 to its `Fred
Router'."
::= { system 2 }
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The time (in hundredths of a second) since the network management portion of the system
was last re-initialized."
::= { system 3 }
sysContact OBJECT-TYPE
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person for this managed node, together with
information on how to contact this person."
61
Annexes
::= { system 4 }
sysName OBJECT-TYPE
………
-- the Interfaces group
-- Implementation of the Interfaces group is mandatory for
-- all systems.
ifNumber OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of network interfaces (regardless of their current state) present on this system."
::= { interfaces 1 }
-- the Interfaces table
-- The Interfaces table contains information on the entity's
-- interfaces. Each interface is thought of as being
-- attached to a `subnetwork'. Note that this term should
-- not be confused with `subnet' which refers to an
-- addressing partitioning scheme used in the Internet suite
-- of protocols.
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of interface entries. The number of entries is given by the value of ifNumber."
::= { interfaces 2 }
ifEntry OBJECT-TYPE
SYNTAX IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An interface entry containing objects at the subnetwork layer and below for a particular
62
Annexes
interface."
INDEX { ifIndex }
::= { ifTable 1 }
IfEntry ::=
SEQUENCE {
ifIndex INTEGER,
ifDescr DisplayString,
ifType INTEGER,
ifMtu INTEGER,
ifSpeed Gauge,
ifPhysAddress PhysAddress,
ifAdminStatus INTEGER,
ifOperStatus INTEGER,
ifLastChange TimeTicks,
ifInOctets Counter,
ifInUcastPkts Counter,
ifInNUcastPkts Counter,
ifInDiscards Counter,
ifInErrors Counter,
ifInUnknownProtos Counter,
ifOutOctets Counter,
ifOutUcastPkts Counter,
ifOutNUcastPkts Counter,
ifOutDiscards Counter,
ifOutErrors Counter,
ifOutQLen Gauge,
ifSpecific OBJECT IDENTIFIER
63

PFE BEN AMARA Sahbi

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PFE BEN AMARA Sahbi

Transféré par

Droits d'auteur :

Formats disponibles

RAPPORT DE PROJET DE FIN D’ETUDES

Ingénierie des Réseaux

Développement d’un gestionnaire

Sabri Ben Amara

M. Mounir Frikha M. Montassar Bachwerdiane

Année universitaire : 2004/2005

Je suis profondément reconnaissant à mes deux encadreurs Mr Mounir Frikha et Mr Montassar

Je voudrais aussi témoigner ma reconnaissance à Monsieur Slim Jarraya directeur de la

Mots clés : Backbone IP, SNMP, administration, génération d’événement.

Table des matières

Liste des figures

FIGURE 2-1: RELATIONS ENTRE MANAGER, AGENTS ET PROTOCOLE...................................................... 8

Liste des acronymes

ASN : Abstract Syntax Notation

Première partie : Présentation de la gestion de réseau,

Deuxième partie : Description de l’existant

Troisième partie : Conception et implémentation de notre application

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

Le 1er janvier 1996, l’office national des télécommunications (ONT) ou « TUNISIE

Direction des Technologies de l’information et des Réseaux

Cette direction est spécialisée dans la conception, la sécurisation, la mise en service et la

l’exploitation de l’infrastructure de l’Internet en Tunisie à travers le Backbone IP/MPLS qui

1.3. Objectifs du projet

- Parcourir le Backbone et d’extraire les informations nécessaires à partir des différents

Devant l’évolution technologique et la mise en place de nouveaux services Tunisie Télécom a

2.1. But et domaine d’application

• S’adapter à toutes les tailles de réseaux.

2.2.1. La cueillette des informations de gestion :

2.2.2. L’interprétation des données

2.2.3. Le contrôle des équipements

2.3. Principes de la gestion de réseau

- La partie serveur, appelée agent représente un ou plusieurs équipements. Un agent sert

Figure 2-1: Relations entre manager, agents et protocole

2.4.2. Les entités

spécifie la dynamique de la communication (mécanismes de question/réponse), ainsi que la

Figure 2-2: Architecture SNMP

2.4.3. La Management Information Base

Figure 2-3: Structure d’indexation des données dans la MIB-2 SNMP

Nom de la MIB-2 SNMP Utilité

Interfaces Interfaces réseau et les données liées au trafic mesuré

Ip Statistiques sur le trafic IP, table de routage, table ARP

Icmp Statistiques sur le trafic ICMP

Tcp Paramètres et statistiques du trafic TCP

Udp Paramètres et statistiques du trafic UDP

Egp Informations sur la mise en œuvre du protocole EGP

Transmission Informations au sujet des moyens de transmission et des

Snmp Paramètres et statistiques du trafic SNMP

Tableau 1 : Informations principales de la MIB-2 SNMP

2.4.3.1. Déclaration des objets

L’objet snmpInPkts dans MIB II :

2.4.3.2. Organisation et identification des objets et des instances

2.4.4. Les opérations de management

• Une requête SNMP contient plusieurs opérations.

2.4.5. Comparaison entre SNMP v1, v2 et v3

2.5. Le service CMIS

· cœur de CMISE, la machine protocolaire CMIPM (Common Management Information

2.6. Le protocole CMIP

les primitives CMISE de requête et de réponse provenant du CMISE-user de SMASE et en

Figure 2.4 : Composition de CMISE

2.7. Le protocole CMOT

2.8. Outils d’administration

2.8.1. Outils Locaux

2.8.2. Plates-formes d’administration