Développement D Un Gestionnaire de Réseaux Pour IP-MPLS - BEN - AMARA - Sahbi - 2005

RAPPORT DE PROJET DE FIN DETUDES
Filire
Ingnieurs en Tlcommunications
Option
Ingnierie des Rseaux
Dveloppement dun gestionnaire de rseau pour le Backbone IP/MPLS de Tunisie Tlcom

Elabor par :
Sabri Ben Amara

Encadr par :
M. Mounir Frikha
M. Montassar Bachwerdiane
Anne universitaire : 2004/2005
DEDICACE
A ma Mre A mon Pre A ma Femme A ma Fille A mes Frres A mes Surs
Remerciements
Remerciements
Je suis profondment reconnaissant mes deux encadreurs Mr Mounir Frikha et Mr Montassar Bachwerdiane pour mavoir fait le grand honneur de diriger mon projet dans les meilleures conditions, ainsi que pour leurs encadrements, leurs conseils et leurs disponibilits. Je voudrais aussi tmoigner ma reconnaissance Monsieur Slim Jarraya directeur de la Direction des Technologies de lInformation et des Rseaux Tunisie telecom pour son aide et les facilites quil ma offert au sein du Backbone IP/MPLS ainsi que pour tous les personnels de la DTIR pour leurs collaborations. Comme je ny manquerais pas de remercier mes professeurs, membres ou Jury pour lhonneur quils ont fait en acceptant de faire partie de mon Jury.
Rsum
Rsum
Durant ce projet, nous nous sommes intresss trois points relatifs au Backbone IP/MPLS de Tunisie Tlcom. Le premier point concerne le problme de larchivage des configurations des diffrents routeurs. Pour remdier ce problme, nous avons mis en place un processus de sauvegarde priodique qui reprsente le premier module de notre application. Le deuxime point sintresse ladministration des quipements rseaux du Backbone. Le troisime point sattache la restructuration du log gnr par les routeurs sous forme dvnement fin davoir une information lisible et utile.
Mots cls : Backbone IP, SNMP, administration, gnration dvnement.
II
Table des matires
Table des matires

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. 1.2. 1.3. PRESENTATION DE LORGANISME DACCUEIL............................................................................ 2 PROBLEMATIQUE................................................................................................................................. 3 OBJECTIFS DU PROJET ........................................................................................................................ 4
CONCLUSION....................................................................................................................................................... 4 CHAPITRE 2 : LA GESTION DE RESEAU ......................................................................................................... 5

U
INTRODUCTION .................................................................................................................................................. 5 2.1. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.3. 2.4. 2.4.1. 2.4.2. 2.4.3. 2.4.3.1. 2.4.3.2. 2.4.4. 2.4.5. 2.5. 2.6. 2.7. 2.8. 2.8.1. 2.8.2. BUT ET DOMAINE DAPPLICATION ................................................................................................. 5 FONCTIONNALITES.............................................................................................................................. 6 LA CUEILLETTE DES INFORMATIONS DE GESTION : .................................................................. 6 LINTERPRETATION DES DONNEES................................................................................................. 7 LE CONTROLE DES EQUIPEMENTS .................................................................................................. 7 PRINCIPES DE LA GESTION DE RESEAU ......................................................................................... 7 SNMP ....................................................................................................................................................... 9 HISTORIQUE .......................................................................................................................................... 9 LES ENTITES .......................................................................................................................................... 9 LA MANAGEMENT INFORMATION BASE ..................................................................................... 10 DECLARATION DES OBJETS........................................................................................................ 12 ORGANISATION ET IDENTIFICATION DES OBJETS ET DES INSTANCES .......................... 13 LES OPERATIONS DE MANAGEMENT ........................................................................................... 14 COMPARAISON ENTRE SNMP V1, V2 ET V3 ................................................................................. 15 LE SERVICE CMIS ............................................................................................................................... 15 LE PROTOCOLE CMIP ........................................................................................................................ 16 LE PROTOCOLE CMOT ...................................................................................................................... 18 OUTILS DADMINISTRATION .......................................................................................................... 19 OUTILS LOCAUX ................................................................................................................................ 19 PLATES-FORMES DADMINISTRATION......................................................................................... 19
CONCLUSION..................................................................................................................................................... 20 CHAPITRE 3 : DESCRIPTION DE LEXISTANT............................................................................................. 21 INTRODUCTION ................................................................................................................................................ 21 3.1. 3.2. DESCRIPTION DU BACKBONE IP DE TUNISIE TELECOM.......................................................... 21 ARCHITECTURE IP/MPLS DU BACKBONE IP................................................................................ 22
III
Table des matires
CONCLUSION..................................................................................................................................................... 25 CHAPITRE 4 : CONCEPTION ET IMPLEMENTATION ................................................................................. 26 INTRODUCTION ................................................................................................................................................ 26 4.1. 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. 4.1.6. 4.2. 4.2.1. 4.2.1.1. 4.2.1.2. 4.2.1.3. 4.2.2. 4.2.2.1. 4.2.3. CONCEPTION ....................................................................................................................................... 26 BASE DES DONNEES .......................................................................................................................... 26 LES MODULES DE BASES ................................................................................................................. 30 LE MODULE SNMPV1COMMUNICATIONINTERFACE ................................................................ 30 LE MODULE SIMPLEGET .................................................................................................................. 31 LE MODULE SNMPCOLLECTOR ...................................................................................................... 32 LE MODULE CONFIGCOLLECTOR .................................................................................................. 34 IMPLEMENTATION............................................................................................................................. 37 OUTILS UTILISES................................................................................................................................ 37 LANGAGE DE PROGRAMMATION : JAVA ................................................................................ 37 ENVIRONNEMENT DE DEVELOPPEMENT : JBUILDER 2005 ................................................. 39 SYSTEME DE GESTION DE BASE DE DONNEES : ORACLE 9.2.0.......................................... 39 INTERFACES UTILISATEURS ........................................................................................................... 39 TTNETVIEW .................................................................................................................................... 39 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 DINDEXATION 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 DUN ROUTEUR CISCO ............. 43 FIGURE 4-17: STATISTIQUES CONCERNANT UN INTERFACE DUN ROUTEUR CISCO .............................. 44 FIGURE 4-18: STATISTIQUES CONCERNANT UN ROUTEUR CISCO .......................................................... 45 FIGURE 4-19: GENERATION DUN RAPPORT CONCERNANT UN INTERFACE DUN ROUTEUR CISCO ...... 46 FIGURE 4-20: GENERATION DES EVENEMENTS ..................................................................................... 47 FIGURE 4-21: EXEMPLE DEVENEMENTS CRITIQUES ............................................................................. 48 FIGURE 4-22: COMPOSITION DU MENU FILE .................................................................................... 49 FIGURE 4-23: CREATION DUN NOUVEAU GROUPE ............................................................................... 49 FIGURE 4-24: CREATION DUN 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 DUN OID ............................................................................................................ 52 FIGURE 4-29: AJOUT DE LINFORMATION 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 LAPPLICATION TTNETLOCATOR ........................................................... 54
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 gnrale
Introduction gnrale
Les rseaux informatiques touchent de plus en plus notre vie courante. On compte sur les services offerts par les rseaux pour assurer les transactions bancaires, les recherches web, la tlconfrence. Les services offerts par les rseaux sont donc rendus indispensables. Pour sassurer que les services rendus par les rseaux seraient convenables, il est ncessaire de surveiller le rseau et dagir quand une erreur se produit. Pour ce faire, il faut obtenir les donnes de gestion des quipements de rseaux et, si ncessaire, contrler ces quipements. Le projet que nous avons ralis consiste la mise en place d'une application capable de grer les quipements rseaux du Backbone IP/MPLS de Tunisie Tlcom. A la fin de ce projet nous serons en mesure de superviser la totalit du rseau Internet, de fournir des statistiques utiles pour faire des prvisions, fournir la possibilit de la gestion des abonnes Internet et la fin gnrer des vnements qui refltent ltat de notre rseau. Afin de comprendre la dmarche que nous avons adopt pour mener ce projet son terme, le rapport se structure de la faon suivante : Premire partie : Prsentation de la gestion de rseau, Deuxime partie : Description de lexistant Troisime partie : Conception et implmentation de notre application
Introduction gnrale
Chapitre 1 Prsentation du projet
Introduction
Dans le prsent chapitre, nous allons essayer de prsenter notre stage. Pour ce faire, procdons une prsentation de lorganisme daccueil, savoir Tunisie Tlcom. Par la suite, nous dgageons la problmatique pour aboutir aux objectifs spcifiques notre projet.
1.1.
Prsentation de lorganisme daccueil
Le 1er janvier 1996, loffice national des tlcommunications (ONT) ou TUNISIE TELECOM est entre en activit en tant quoprateur de tlcommunication dot de sa propre autonomie et son propre rseau (sous la forme juridique dtablissement public a caractre industriel et commercial). Tunisie Tlcom a pour mission dassurer toutes les activits relatives au domaine des tlcommunications dont notamment : La coopration avec les organismes similaires et lapplication des traites internationales en matire de tlcommunication. Linstallation, le dveloppement, lentretien et lexploitation des rseaux publics de tlcommunication et en particulier, les rseaux de tlphone et de transmission de donnes. La promotion de nouveaux services de tlcommunication travers linstallation de lquipement technologique dans le domaine la contribution au dveloppement aux tudes et recherches scientifiques lies au secteur des tlcommunications.
Direction des Technologies de linformation et des Rseaux
Cette direction est spcialise dans la conception, la scurisation, la mise en service et la gestion des rseaux informatiques qui sont ncessaire au fonctionnement de diffrents
services de la compagnie, comme elle fournit laccs Internet aux diffrents sites de Tunisie Tlcom ainsi quelle prend en charge ladministration, le contrle, la maintenance et
Introduction gnrale
lexploitation de linfrastructure de lInternet en Tunisie travers le Backbone IP/MPLS qui couvre tout le pays. La DTIR comprend trois quipes : Equipe scurit : sa mission est la scurisation des rseaux informatiques en tudiant les vulnrabilits et en installant des dtecteurs dintrusions, des firewalls, des sondes, des analyseurs et des antivirus. Equipe de dveloppement : dveloppement et maintenance des applications utilises par la socit et du site web de Tunisie Tlcom. Equipe rseaux : installation, mise en services, maintenance et exploitations des rseaux informatiques savoir o Lintranet de Tunisie Tlcom : ce rseau interconnecte les diffrents sites de Tunisie Tlcom (Kasbah, Ouardia, Hasdurbal et Montplaisir) travers des connexion de type MAN (Metropolitan Area Network). o Le Backbone : Rseau dInternet National o Le rseau GIS.
1.2.
Problmatique
Tunisie Tlcom a migr vers une architecture IP/MPLS qui intgre la notion qualit de service dans une politique qui vise lamlioration des services offerts aux clients. Cette migration a engendr la croissance du rseau en nombre de routeurs connects et donnes partages. Pour maintenir ce rseau oprationnel et disponible, des techniques et des outils avancs ont d tre invents pour assurer son fonctionnement et son administration. Notre projet rentre dans ce cadre et vise remdier quelques problmes savoir : Perte des fichiers de configuration des routeurs Difficult de localisation dun client Manque de suivis efficaces des tats des routeurs (CPU, Temprature, tats des interfaces...) Pas dhistorique
Ces problmes ont caus une mauvaise exploitation des ressources disponibles et une grande perte de temps.
Introduction gnrale
1.3.
Objectifs du projet
Lobjectif principal de ce projet et de parvenir avoir une vision globale sur la totalit du BackboneIP/MPLS de Tunisie Tlcom. La solution propose est spcialement utile pour identifier tout dysfonctionnement dans le rseau et de faciliter la prvision de toute amlioration. Le projet consiste au dveloppement dune application de gestion du Backbone IP/MPLS. Cette application va tre capable de :
- Parcourir le Backbone et dextraire les informations ncessaires partir des diffrents routeurs fin davoir une documentation dynamique, ces informations seront stockes dans une base de donnes qui sera exploite pour localiser lemplacement des abonns (Nud, Routeur, Interface, adresse WAN,...) fin de faciliter la maintenance des diffrentes liaisons (Publinets, Lyces,...).
- Avoir des informations sur les tats des routeurs (Temprature, 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. - Gnration des statistiques sur le trafic - Gnration dvnements utiles
Conclusion
Aprs avoir prsent notre projet, nous entamons par la suite la partie qui permet la prsentation de certains concepts lis notre domaine dapplication.
Chapitre 3 : Description de lexistant
2.
Chapitre 2 La gestion de rseau
Introduction
Devant lvolution technologique et la mise en place de nouveaux services Tunisie Tlcom a t oblig dlargir et de diversifier son rseau qui est devenu complexe. Par rapport un tel rseau le concept gestion de rseau est devenu une ncessit afin dassurer ladministration et pouvoir faire des prvisions.
2.1.
But et domaine dapplication
La notion de gestion sapplique essentiellement dans un contexte de rseau priv. Lide matresse de la supervision est de contrler la bonne sant du rseau et des services informatiques afin de mesurer la Qualit de Service (QoS). Cette notion de QoS nest pas rcente, mais elle est devenue le point dintrt central des stratgies de dveloppement dentreprise. La situation conomique actuelle peu favorable exige des entreprises quelles contrlent leurs dpenses. La tendance nest pas linvestissement dans de nouvelles technologies, mais loptimisation et au rendement de lexistant moindre cot. De plus, lvolution des mthodes de travail au sein mme de lentreprise veut quune part de plus en plus importante de lactivit de celle-ci sollicite les outils informatiques. Dans le cas des socits de services en informatique, cest toute lactivit des ingnieurs et dirigeants qui repose intgralement sur la bonne disponibilit des services informatiques et rseaux. Cest dans cette volont de contrle que sintgre la supervision de rseaux.
Lobjectif des administrateurs dun systme dinformation est donc de pouvoir connatre en permanence ltat du rseau, et dtre averti en temps rel des diffrents incidents pour rduire au maximum les dlais dintervention et de coupure du service.
A prsent, de nouveaux besoins se font sentir. Le premier besoin est de rompre la contrainte de proximit de lquipement grer. Avec les protocoles de gestion de rseau actuels, le rseau est utilis afin de permettre la gestion des quipements le composant. On se trouve donc dans le cas
dune gestion du rseau par le rseau. Le second besoin concerne la dpendance humaine. La complexit des rseaux saccroissant, la tche de gestion du rseau exige une telle masse dinformations traiter quelle dpasse la capacit de ltre humain. En effet, il faut remarquer que chaque information individuelle sur un quipement ne peut tre utilise telle quelle, elle nest significative que dans le contexte du rseau global. Les considrations nonces ci-dessus permettent didentifier les besoins de la gestion des rseaux: Sadapter toutes les tailles de rseaux. Grer des quipements htrognes et possiblement complexes. Permettre les oprations de gestion distance. Assister lutilisateur en: Automatisant certaines tches. Aidant lutilisateur dans les tches qui ne sont pas automatises. Fournissant une vue adapte du rseau selon les oprations raliser.
2.2.
Fonctionnalits
Une bonne gestion de rseau permet lutilisation optimale de toutes les ressources offertes par le rseau. La gestion de rseau a trois fonctions : la cueillette des donnes de gestion, linterprtation et le contrle.
2.2.1. La cueillette des informations de gestion :

Un logiciel qui fait de la gestion de rseau doit amasser toutes les informations de gestion dont il a besoin. Ces informations parviennent de chacun des lments du rseau. Pour les obtenir, une tape de dcouverte des lments de rseau est effectue, puis les requtes sont envoyes aux lments un un pour en tirer les informations de gestion. Ces informations de gestion comprennent toutes sortes dinformations relies un lment de rseau : le type dquipement, le nombre de paquets qui passent sur chaque port dun routeur, lusager qui utilise une station de travail...
Pour effectuer cette tche, une technique pour dmasquer les lments de rseaux est ncessaire. Un protocole pour obtenir les informations de gestion est aussi ncessaire. SNMP est un protocole qui permet de raliser ces fonctionnalits. [H1]
2.2.2. Linterprtation des donnes

Une fois que lon a les informations de gestion, il est important de les interprter correctement. Par exemple : 5000 paquets par seconde sur un port dun routeur est peut-tre normal ou peut-tre le signe dune surcharge et dune dgradation de la qualit du service offert. Mme si on connat la charge exacte dun routeur, cette information ne suffit pas pour prendre des dcisions pertinentes de gestion. Les manufacturiers dquipements offrent quelquefois des logiciels qui savent interprter les informations de gestion de leurs quipements de gestion. Toutefois, une interprtation automatique complte et correcte de ltat dun rseau et de ses quipements est difficile raliser. Lintervention humaine est souvent requise pour interprter les donnes ou pour placer des bornes acceptables. [H1]
2.2.3. Le contrle des quipements

Quand des informations de gestion sont obtenues et comprises, il est quelquefois ncessaire dagir. Il doit tre possible de demander un quipement, par exemple, de se rinitialiser, de couper ou dactiver des services... Pour ce faire, un protocole de gestion doit transmettre un ordre (requte) lquipement appropri pour dclencher laction. En raison de labsence de scurit par le pass, cette fonctionnalit a rarement t utilise. [H1]
2.3.
Principes de la gestion de rseau
Les architectures de gestion de rseau sont classes dans la catgorie des systmes client/serveur. On peut donc identifier trois composants:
- La partie client, appele manager, est lentit qui va superviser les oprations de gestion. Elle sert dinterface entre lutilisateur et le serveur. Il peut y avoir, le cas chant, plusieurs managers.
- La partie serveur, appele agent reprsente un ou plusieurs quipements. Un agent sert dinterface entre lquipement et le manager. Il peut galement servir dinterface entre plusieurs autres agents et le manager. Lagent permet de fournir une vue abstraite de lquipement et masque ainsi les diffrences qui existent entre les quipements. Il y a bien entendu plusieurs agents dans un rseau. - Le protocole est le langage utilis par le manager et lagent pour communiquer (SNMP, CMIS, CMIP, CMOT, ) Il est mis en oeuvre par le biais dun rseau. Ce protocole permet au manager dinterroger lagent (dans le cas du monitoring) ou de lui demander de modifier ltat de lquipement (dans le cas de la configuration). Le protocole est galement utilis par lagent afin davertir le manager de loccurrence dvnements.
Figure 2-1: Relations entre manager, agents et protocole
Dans le cadre de notre projet on a opt lutilisation du protocole SNMP qui offre une grande panoplie de fonctionnalits
2.4.
SNMP
2.4.1. Historique
Lactivit de recherche et de standardisation au niveau de SNMP est mene sous lgide de lIETF (Internet Engineering Task Force). La premire version de SNMP a vu le jour en 1989. La seconde version, appele SNMP v2 a t standardise en 1992 [RFC1905]. Cette version apporte essentiellement des changements au niveau de la scurit et de la confidentialit des oprations de gestion. Suite des problmes apparus lors de la mise en opration de la seconde version du protocole, ces aspects ont t classs obsoltes en 1996 lors dun des meeting tri annuel de lIETF. Ce dernier rebondissement a eu pour effet, dune part de renvoyer SNMP son tat de 1989 et dautre part, de dclencher les recherches sur SNMP v3. Les travaux se poursuivent actuellement et petit petit les diffrents lments de larchitecture SNMP v3 sont proposs la communaut scientifique [RFC2274]. SNMP v3 (dans les aspects qui sont actuellement dfinis) est en passe de devenir un standard car il est accept par le working group SNMP v3 en tant que proposed standard. A lheure actuelle, SNMP v1 reste la version la plus utilise. De plus, les rsultats obtenus avec SNMP v1 sont immdiatement applicables SNMPv2. [H1]
2.4.2. Les entits

SNMP suit larchitecture client/serveur, le client tant le manager et le serveur lagent. Contrairement aux architectures client/serveur habituelles o un serveur interagit avec plusieurs clients, SNMP est lexemple dun schma inverse: un client, souvent unique, communique avec plusieurs serveurs. Il y a un agent par quipement grer. Lagent conserve une srie de variables qui modlisent lquipement. Le manager, au travers de lagent, consulte et/ou modifie les valeurs des variables laide doprations de management. Des changements dtat internes lquipement modifient eux aussi les valeurs des variables. La manire dont lagent doit tre inform de ces changements nest pas spcifie dans SNMP. Lensemble des variables gres est appel MIB (Management Information Base). Le manager interagit avec lagent via un protocole de communication qui
spcifie la dynamique de la communication (mcanismes de question/rponse), ainsi que la structure des messages changs.
Figure 2-2: Architecture SNMP
2.4.3. La Management Information Base

La Management Information Base (MIB) contient les variables qui forment le modle informationnel de lquipement. Les variables sont organises sous une forme arborescente. Les nuds intermdiaires 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 considre sous deux points de vue. [H2] La premire vision est une vision en terme de spcification du modle informationnel cest-dire les variables qui existent, leur type et les relations entre ces variables. Il est important dinsister sur le fait que, selon cette optique, la MIB ne contient aucune valeur, il sagit uniquement dune spcification structurelle. Les nuds de larbre sont appels, dans ce cas, objets. Comme on le verra ultrieurement, la distinction en faite entre objet et instance. Cette distinction est la base de la philosophie oriente objet. Le parallle ne peut cependant tre men plus loin: les notions de classe, hritage et polymorphisme nont pas dquivalent dans le modle informationnel SNMP. [H2] Le second point de vue est celui de larborescence de valeurs. Les valeurs sont les instances des objets cits ci-dessus. Pour une MIB dclaration (uniquement les objets) et son quivalent implantation (uniquement les instances), on a les rgles suivantes: A chaque instance correspond un et un seul objet dans la MIB dclaration.
10
A chaque objet correspond zro, une ou plusieurs instances. Remarquons que les premier et dernier cas sont rares. Lorsquun objet n aucune instance, cest quil est prsent dans la MIB pour des raisons historiques mais quil est marqu comme obsolte.
La MIB dclaration est quelque chose de statique: on ne peut pas rajouter dobjets pendant que lagent fonctionne. La MIB implantation est semi-dynamique: seuls certains types dobjets supportent lajout dinstances. Les autres instances existent de manire prdfinie. Nous reviendrons sur ces aspects ultrieurement.
Figure 2-3: Structure dindexation des donnes dans la MIB-2 SNMP
11
Nom de la MIB-2 SNMP System
Utilit Nom, emplacement et description de lquipement (switch, routeur) Interfaces rseau et les donnes lies au trafic mesur Statistiques sur le trafic IP, table de routage, table ARP Statistiques sur le trafic ICMP Paramtres et statistiques du trafic TCP Paramtres et statistiques du trafic UDP Informations sur la mise en uvre du protocole EGP (External Gateway Protocol) Informations au sujet des moyens de transmission et des protocoles daccs aux interfaces de lquipement Paramtres et statistiques du trafic SNMP
Interfaces Ip Icmp Tcp Udp Egp Transmission Snmp
Tableau 1 : Informations principales de la MIB-2 SNMP
2.4.3.1. Dclaration des objets La MIB dclaration est dcrite laide dun langage spcifi 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 dfinition la syntaxe ASN.1. Chaque objet qui y est dclar inclut les informations suivantes: Un nom. Un type: il sagit soit dun type simple: INTEGER, OCTET-STRING, NULL, soit dun type de construction: SEQUENCE-OF, SEQUENCE, soit dun type spcifique: NetworkAddress, IpAddress, Counter, Gauge, TimeTicks. Un modificateur daccs: read-write, read-only, write-only, not-acessible. Un modificateur de statut: mandatory, optional, obsolete. Une description: il sagit dun texte en langage naturel, qui dcrit lutilit de lobjet.
12
Lobjet 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 nomms par un identificateur que lon appelle object identifier. Il sagit dune suite de nombres spars par des points. La dot notation fournit un chemin dans larbre partir de la racine. La racine est identifie par le nombre 1. Le nombre suivant, cest-dire le second nombre dans la dot notation, identifie le numro du fils de la racine. On procde rcursivement jusqu la fin de lobject identifier. A titre dexemple, lobjet snmpInPkts possde comme object identifier 1.3.6.1.2.1.11.1 Les cinq premiers identificateurs sont fixes car ils correspondent la racine de toute larborescence de management:
iso(1).org(3).dod(6).internet(1).mgmt(2)
Le sixime identificateur correspond mib2(1) qui est la MIB permettant de grer un stack TCP/IP standard. Lobjet snmpInPkts est le premier fils en partant de la gauche du groupe snmp qui lui-mme a lidentificateur 11. On utilise comme notation abrge snmp(11). Lobject identifier dune instance est construit sur base de lobject identifier de lobjet correspondant. Suivant que linstance appartienne une table (un ensemble de lignes) ou soit une instance isole (appele variable simple) le schma de construction est diffrent. Dans le cas des variables simples, on postfixe lidentificateur de lobjet par un numro dinstance. Les instances sont numrotes partir de zro. Linstance correspondant lobjet snmpInPkts sera donc identifie par 1.3.6.1.2.1.11.1.0 Si une instance supplmentaire existe (ce qui nest pas le cas ici), elle porte lidentificateur 1.3.6.1.2.1.11.1.1 et ainsi de suite. Laccs des
13
instances appartenant des tables est plus complexe, car SNMP utilise le concept dadressage associatif.
2.4.4. Les oprations de management

La simplicit de SNMP est en partie due la simplicit de ses oprations de gestion. Il y en a quatre: GET : permet au manager de rcuprer la valeur contenue dans une instance. SET : permet au manager dassigner une valeur une instance. GET-NEXT : permet partir dun point de larborescence de trouver linstance la plus proche. TRAP : permet lagent denvoyer une notification spontane au manager.
La distinction est faite entre une opration SNMP et une requte SNMP. Les relations entre ces deux concepts sont les suivantes:
Une requte SNMP contient plusieurs oprations. Toutes les oprations dune requte doivent tre du mme type (ex: uniquement des GET).
Si une des oprations de la requte choue (ex: un SET sur un objet read-only), aucune opration de la requte ne peut tre ralise. Ca nest rellement intressant que dans le cas des oprations SET qui modifient la MIB. Cette proprit est appele atomicit dune requte et peut tre implante comme suit. Le noyau de la mthode consiste retenir dans une liste les objets modifis ainsi que leur valeur. Si une des oprations est source derreur, la liste des objets modifis est utilise pour effectuer un rollback et restaurer le systme dans ltat prcdant le traitement de la requte. Cette technique est relativement simple implanter. Dautres techniques du type commit peuvent galement tre utilises.
Lors des diffrentes oprations, il peut survenir des erreurs. Les plus importantes sont les suivantes: Non-respect du type dune instance lors dun SET. Ex: assigner un OCTET-STRING une instance de type INTEGER (erreur badValue).
14
Non-respect de laccs dune instance lors dun SET: Ex: assigner une valeur une instance read-only (erreur readOnly).
GET-NEXT dune instance non existante. Lorsquil ny a plus dinstance aprs le point de dpart, le GET-NEXT renvoie une erreur (noSuchName).
GET ou SET dun nud de la MIB qui nest pas une instance (erreur noSuchName).
2.4.5. Comparaison entre SNMP v1, v2 et v3

SNMP en est actuellement sa troisime version. Les deux premires versions sont standardises [RFC1157, RFC1905]. La troisime est en cours dlaboration et un working group (SNMP version 3) lui est ddie au sein de lIETF [RFC2274]. Il faut galement citer lactivit du working group Distributed Management qui examine les consquences lies lutilisation de plusieurs managers pour grer un rseau. Avant que les aspects relatifs la scurit ne soient rendus obsoltes, SNMP v2 diffrait de SNMP v1 selon deux critres: 1. Le support pour scuriser (authentification et confidentialit) les oprations a t renforc. SNMP v2 offre la notion de groupe dfini comme tant un contexte dexcution des oprations de gestion. Ce contexte dfinit, entre autres, lensemble des objets qui peuvent tre grs, le protocole de transport utilis (ex: UDP) et la mthode dauthentification utilise pour reconnatre la lgitimit dune requte. 2. Lajout dune opration GET-BULK qui permet de rapatrier vers le manager des grandes quantits de donnes en les rpartissant sur plusieurs messages de rponse. A prsent, lopration GET-BULK est la seule diffrence avec la premire version du protocole. [H2]
2.5.
Le service CMIS
CMIS est l'ensemble des fonctions communes de la gestion systme permettant de raliser le transfert des oprations et des notifications de gestion. Il est offert par l'entit de service CMISE de la couche application. L'lment CMISE se compose de quatre entits distinctes:
15
cur de CMISE, la machine protocolaire CMIPM (Common Management Information Protocol Machine) qui met en oeuvre le protocole et gre les units de donnes du protocole CMIP; le fournisseur de service CMISE qui est charg de recevoir les primitives CMISE et de transmettre les units de donnes de service correspondantes (Service Data Unit, SDU) CMIPM; l'utilisateur de service ROSE qui gre les requtes faites ROSE. Elles permettent d'changer les PDUs entre deux protocoles CMIP; Enfin, un gestionnaire de d'entit qui gre les primitives non normalises de communication avec la fonction de contrle d'association simple (SACF). L'entit CMISE distingue les six services d'oprations (qu'elle peut traiter sans aucune connaissance du contenu, laquelle est laisse SMASE) et un service de notification, qui sont: - M_CREATE pour demander la cration 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'excution 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 associes aux attributs d'objets (confirm ou non); - M_CANCEL_GET pour demander de ne pas recevoir les rsultats d'un GET prcdent (Mode confirm); - M_EVENT_REPORT pour transmettre un rapport d'vnement relatif un objet (confirm ou non). [H4]
2.6.
Le protocole CMIP
Pour prsenter le protocole CMIP qui se base sur les tats de fonctionnement de la machine protocolaire CMIPM (CMIP Machine), il faut connatre la structure de CMISE (Figure 2.4) . Une instance de ce dernier est compose 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 lments de procdure du protocole CMIP et gre les units de protocole CMIP (CMIP-PDUs). CMISE-provider gre les primitives de service CMISE. Il reoit
16
les primitives CMISE de requte et de rponse provenant du CMISE-user de SMASE et en transmet les units 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 transfrer des CMISE-SDUs. ROSE-user gre les primitives de service ROSE. Il reoit des primitives ROSE d'indication provenant du ROSE-provider de ROSE et en transmet les units de service ROSE (ROSE-SDUs) CMIPM. Il met des primitives ROSE de requte l'intention du ROSE-provider de ROSE lorsque CMIPM lui demande de transfrer des ROSESDUs. Le gestionnaire gre les primitives non normalises d'interaction avec SACF (Single Association Control Function) charg de coordonner le travail des ASEs (Application Service Element). SAP-cmise-smase reprsente le point d'accs aux services de CMISE. C'est l'une des extrmits de la connexion qui relie SMASE CMISE. Par cette connexion transitent les primitives CMISE entre ces deux lments. SAPcmise- rose reprsente le point d'accs aux services de ROSE. Par cette connexion transitent les primitives ROSE entre ces deux lments. SAPcmise- sacf reprsente le point d'accs aux services non normaliss offerts par CMISE la fonction SACF.
Figure 2.4 : Composition de CMISE
17
Une machine protocolaire est dcrite sous la forme d'un automate. Celui ci se prsente comme une boite noire sollicite par des vnements extrieurs, qui dclenche un traitement interne spcifique pour chaque vnement reu en fonction de l'tat dans lequel elle se trouvait au dbut du traitement, il gnre des vnements sortants et change ventuellement d'tat la suite de chaque traitement dclench. 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 prt 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 rponse 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 rponse de terminaison d'association que doit rendre son utilisateur SMASE. [H4]
2.7.
Le protocole CMOT
Le protocole CMOT est la migration du systme de gestion de rseaux TCP/IP vers la normalisation. Le groupe qui travaille sur CMOT (CMIP over TCP/IP) s'est intgr l'OSI sous le nom de OIM (OSI Internet Management). Son principal rle est de produire un ensemble de spcifications qui offrent les services CMIS et le protocole CMIP sur des rseaux de type TCP/IP. L'architecture envisage pour CMOT consiste rajouter au-dessus des protocoles TCP et UDP une couche prsentation simplifie 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 constitue d'un ensemble d'objets comme pour la gestion OSI. Cependant, bien que la dmarche semble fort intressante, il n'y a pas l'heure actuelle de vritable implmentation de ce protocole sur les diverses plates-formes commerciales. [H4]
18
2.8.
Outils dadministration
Les outils dadministration se rpartissent en deux catgories : Les outils locaux dadministration Les plates-formes dadministration
2.8.1. Outils Locaux

La plupart des outils sont prvus pour travailler sur un modle client/serveur, ce qui permet des interventions distance. Parmi ces outils, on distingue : Les outils de diagnostic tels que ping, traceroute, nslookup, Les consoles dadministration de cblage Les moniteurs de rseau (LANalyzer de Novell, 3Com Networking Monitoring, ) Les analyseurs de protocoles (analyseurs de rseau) ; ce sont des outils matriels ou logiciels qui permettent dinterprter la charge utile des paquets, de capturer des donnes transmises sans cryptage les testeurs de cblage pour le test de continuit et de dfaillance du cblage Les sondes insres dans les rseaux pour surveiller le fonctionnement, dtecter les nuds dun segment, capturer du trafic depuis et vers des nuds slectionns.
2.8.2. Plates-formes dadministration

Elles offrent des services de base et des outils qui donnent lutilisateur un environnement homogne partir duquel il lancera les applications dont il a besoin pour administrer le rseau. On distingue : - Les hyperviseurs qui sont des plates-formes compltes dadministration de rseau. Ils offrent des services dune administration propritaire (Netview dIBM, Openview de HP). Les hyperviseurs offrent une vue densemble du rseau (tat des liens, dun port dun routeur, dune carte, ) - Les plates-formes ou systmes intgrs au systme dexploitation qui sont des ensembles doutils non seulement pour la gestion des utilisateurs, des ressources et de la scurit, mais aussi la supervision du fonctionnement gnral et tout particulirement de la machine serveur (charge du CPU, ). On peut citer entre autres systmes intgrs Systemview
19
dIBM, Sun Net Manager / Solstice Enterprise Manager, Spectrum, ISM OpenMaster. [H3] Parmi les services de base offerts par les plates-formes, on peut noter : - La dcouverte et la gestion de la topologie du rseau ; dcouverte automatique des machines du rseau, et dessin de la topologie avec les interconnexions, les routeurs, - La gestion des ressources - La gestion des vnements - Les fonctions de collecte dinformations et dinterrogation
Conclusion
Aprs avoir fait ltude de ces diffrents concepts lis la gestion des rseaux, nous allons essayer par la suite de prsenter la Backbone IP/MPLS de Tunisie Tlcom qui reprsente le rseau le plus tendu en Tunisie.
20
Chapitre 3 Description de lexistant 3. Introduction

Dans ce chapitre nous allons prsenter sommairement larchitecture dploye ainsi la varit des quipements qui vont tre gr par notre application fin de sarrter sur le niveau de complexit de la gestion dun tel rseau.
3.1.
Description du Backbone IP de Tunisie Tlcom
Le Backbone IP national dont Tunisie Tlcom soccupe de son volution ainsi que de sa gestion est constitu principalement de 11 routeurs rgionaux ou principaux parpills sur la totalit du territoire tunisien. Ces routeurs sont caractriss par leur bonne performance (les gammes les plus rpandues 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 connects directement via les routeurs principaux mais cest la charge des routeurs priphriques ainsi que les serveurs daccs dassurer linterconnections des diffrents types dutilisateurs (RTC, LS, X25, FR, ADSL), plusieurs gamme de routeurs sont utilises tels que Cisco 3660,2600,36200 Max6000,Huwai . Pour assurer la fiabilit du Backbone, une architecture redondante est mise en place pour linterconnexion des routeurs principaux. Un site doit tre reli au moins deux sites diffrents 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 implmentes au niveau des routeurs priphriques pour permettre d'acheminer le trafic aux clients finaux.
21
Le routage dynamique est implment au niveau des routeurs principaux pour calculer de nouvelles routes, dtecter des changements de topologie et pour s'changer les mises jour. Ce type de routage est utilis aussi au niveau des routeurs priphriques 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 dpend de l'tat de la liaison) et qui utilise pour le calcul des routes l'algorithme SPF (Shortest Path First). Les routeurs principaux sont groups dans larea 0 (area Backbone) les routeurs priphriques de chaque zone sont groups dans une area spcifique AreaX. Le routage, que ce soit statique ou dynamique, ne rpond pas au besoin car le routage du trafic sortant des clients sur le Backbone se fait gnralement la source do la ncessit dutiliss la technique PBR (Policy Based Routing). Dans le cas du Backbone IP de Tunisie Tlcom, la PBR utilise est base sur le routage la source qui permet dans la majorit des cas d'acheminer le trafic provenant des abonns Internet vers leurs FSIs puisque partir de l'adresse source de l'abonn le routeur va dterminer quel FSI il appartient. L'inconvnient 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 soccuper de tout ce qui est services et les routeurs Cores ont la charge dassurer seulement la commutation des paquets. Le problme cest qu'il y a des routeurs dj oprationnels ne supportent pas MPLS do il a fallu les placer derrire les routeurs Edge. Comme premire tape il faut acqurir lacquisition de nouveaux routeurs pour assurer la fonctionnalit du Backbone core est indispensable, la gamme 12000 de Cisco est frquemment conseille dans ce genre de contexte. Pour passer MPLS quelques actions ont t ralises : La vrification des versions des routeurs, Lactivation de IP MPLS sur les interfaces du routeur,
22
La spcification dun protocole dchange de label (LDP / TDP), Vrification du protocole de routage IGP, La dfinition des MTU sur les routeurs et les switchs.
CE
PE
PE P P
CE
PE
P PE
P PE
P PE
PE
Figure 3.1: Architecture MPLS pour le Backbone IP
23
Les VRFs La notion mme de VPN implique lisolation du trafic entre sites clients nappartenant pas au mme VPN. Pour raliser cette sparation, les routeurs PE ont la capacit de grer plusieurs tables de routage grce la notion de VRF (VPN Routing and Forwarding). Une VRF est constitue dune table de routage, dune FIB (Forwarding Information Base) et dune table CEF spcifiques, indpendantes des autres VRF et de la table de routage globale. Chaque VRF est dsigne par un nom sur les routeurs PE. Les noms sont affects localement, et nont aucune signification vis--vis des autres routeurs. Chaque interface de PE relie un site client est rattache une VRF particulire. Lors de la rception de paquets IP sur une interface client, le routeur PE procde un examen de la table de routage de la VRF laquelle est rattache linterface, et donc ne consulte pas sa table de routage globale. Cette possibilit dutiliser plusieurs tables de routage indpendantes permet de grer un plan dadressage par sites, mme en cas de recouvrement dadresses entre VPN diffrents. Pour lchange des routes et des informations concernant les VRFs entre les routeurs PE, plusieurs possibilits sont offertes : Un protocole de routage spcifique pour chaque VRF, mais avec laugmentation du nombre de VRF nous aurons un problme de scalabilit et un traitement supplmentaire cot routeurs PE. Un seul protocole de routage ddi pour tous les VRFs, le problme cest que le routeur PE aura connaissance de touts les routes clients des diffrents VRFs. La solution la plus intressante est lutilisation du protocole M-BGP qui permet lchange des routes entre les routeurs PE seulement. Optimisation du routage Inter-PE Pour lchange dinformations entre les extrmits des VRFs, des sessions BGP doivent tre tabltes. Normalement un Full-mesh est ralis entre tous les routeurs PE, mais vue le grand nombre de routeurs priphriques que dispose le Backbone, le fait dappliquer un Full-mesh entre ces diffrents routeurs va charger le rseau lors de la mise jours de la table de routage. Pour remdier 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 apportes 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 prsenter larchitecture du Backbone IP/MPLS ainsi que la politique de routage utilise. La richesse en terme dquipements et de technologie dploye, rend la tche de la mise en place dune application pour la gestion du Backbone une tche assez complexe.
25
Chapitre 4 : Conception et implmentation
Chapitre 4 Conception et implmentation 4. Introduction

La programmation oriente objet est une technique qui est la base de tous les nouveaux projets de dveloppement de logiciels. La mise en oeuvre de logiciels rseau nchappe pas cette tendance. Comme tous les autres projets logiciels, les logiciels rseaux peuvent profiter des avantages de lorient objet. Cette technique permet la construction dun programme solide, bien structur, facile visualiser et qui est facile modifier et maintenir. Ce prsent chapitre est consacr dtailler les mcanismes de fonctionnement de quelques modules de TTNetView.
4.1.
Conception
Aprs une tude dtaille de larchitecture du Backbone et une comprhension des MIBs de plusieurs constructeurs (Cisco, Nortel, Luccent), on a choisi de rpartir 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 donnes

Pour la base de donnes de notre application, nous avons utilis les tables suivantes : Table Groupe (Figure 4.1) qui va contenir la liste des diffrents 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 : dtails concernant le routeur Niveau 1 : Mot de passe du premier niveau.
- Niveau 2 : utilise 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) : dfini 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 rsultat en nombre caractres, cette information est utilise pour jour la table historique.
mettre -
Stored : on va indiquer si cette information va tre sauvegarde au niveau de
lhistorique.
27
Seuil : Pour la gestion des vnements, si la valeur de linformation SNMP est
suprieure ce seuil un vnement est gnr. Cible : Cette OID concerne un routeur ou un interface.
Figure 4-3: Structure de la table OID
Pour chaque groupe on va : - Crer une table historique_Nom_Groupe (Figure 4.4) gardant lhistorique sur les tats de diffrents routeurs.
Figure 4-4: Structure de la table historique
- Crer une table historique_int_Nom_Groupe (Figure 4.5) gardant lhistorique sur les interfaces de diffrents routeurs.
Figure 4-5: Structure de la table historique
Crer 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 cre pour contenir les diffrents clients (Publinets, Lyce, Facult, ...) qui sont connects sur le Backbone. Les champs de cette table sont : IP_Routeur : adresse IP du routeur Nom_Routeur : Nom du routeur Index_int : index de linterface Nom_int : nom de linterface Description : Description de la liaison Ipaddress : Adresse IP de linterface Netmask : Masque de sous rseau MTU : Taille maximale dune 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 lhistorique sont des tables dynamiques, une colonne sera ajoute chaque fois quon veut sauvegarder les traces dune 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 nest pas ncessaire davoir 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) implmente des mthodes pour la communication avec les entits SNMP. La version SNMP utilise 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 donnes ne seront pas cryptes. Le
constructeur de cette classe ncessite ladresse IP dun routeur et le nom de sa communaut SNMP.
Les principales fonctions de cette classe : - getMibEntry() (quivaut lopration Get du protocole SNMP) : permet au
manager de rcuprer la valeur contenue dans une instance. - getNextMibEntry() (quivaut lopration Get-Next du protocole SNMP) : permet
partir dun point de larborescence de trouver linstance la plus proche. - retrieveAllMIBInfo() : cette fonction retourne les valeurs de toutes les variables dune MIB. - retrieveMIBTable() : retourne le rsultat dune variable SNMP sous la forme dune table, exemple : Table ARP. - setMibEntry() (quivaut lopration Set du protocole SNMP) : permet au manager dassigner 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 implmente dautres fonctions pour la gestion de la table de routage dun routeur fin dextraire les routes qui passent par chaque interface, cette fonction nest pas implmente dans tous les gestionnaires du rseau daujourdhui. Les principales fonctions de cette classe :
get_longueur_table_routage() : retourne le nombre total des routes contenues dans la table de routage dun routeur. get_Table_de_Routage() : avoir la table de routage dun 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 tche de collecter les informations SNMP et de les stocker dans la base de donnes fin de garder un historique bien dtaill sur les tats des routeurs et leurs interfaces. SNMPCollector commence par contacter la base de donnes pour avoir la liste des diffrents 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 grer ainsi leurs seuils. Ensuite, SNMPCollector teste la connexion avec le routeur en envoyant des requtes Ping, sil y a une rponse 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 quune valeur dune variable SNMP excde le seuil indiqu par ladministrateur, il y aura une mission dun vnement vers un fichier log. La figure suivante (Figure 4.9) rsume le fonctionnement du ce processus.
32
Base de Donnes
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
Get Value Of OID
Stockage de Value
Backbone IP/MPLS
Send Value
(Value > Seuil) OR ( !Ping)
Log
Figure 4-9: Schma de fonctionnement du SNMPCollector
33
Les principales fonctions de cette classe (Figure 4.10) : - SNMPCollector() : le constructeur ncessite une adresse IP et le nom de la communaut SNMP dun routeur. Il vrifie sil y a de nouveaux OID pour chaque groupe pour mettre jour les tables dhistorique. - get_Data() : Cette fonction est ncessaire pour la communication avec la base de donnes fin dextraire les informations ncessaires (les OIDs, les seuils, ) - Get_SNMP() : Cest le cur de cette classe, elle est responsable de la gestion des communications SNMP entre le manager et les routeurs. - Send_Event() : pour la gestion des vnements pour le log.
Figure 4-10: Structure de la classe SNMPCollector
4.1.6. Le module ConfigCollector

Le rle de ConfigCollector est de sauvegarder les fichiers de configurations des routeurs et dextraire les informations sur les clients connects sur le Backbone. 34
ConfigCollector commence par contacter la base de donnes pour avoir la liste des diffrents 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 requtes Ping, sil y a une rponse, il va entrer en communication avec le routeur en utilisant le protocole Telnet et lui envoyer la commande qui permet davoir son fichier de configuration, par exemple : show run pour les routeurs Cisco display current-configuration pour les routeurs Huawei. Ces fichiers de configuration seront stocks dans des dossiers portant les noms des diffrents groupes. Pour les informations concernant les interfaces (Nom Interface,
description, adresse IP, Bande passante) seront stockes dans la table clients pour tre utilises pour la localisation dun client. fonctionnement du ce processus. La figure suivante (Figure 4.11) rsume le
35
Demande la liste des groupes
Groupe
ConfigCollector
N groupes Routeur
Base de Donnes
Clients
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: Schma de fonctionnement du ConfigCollector
36
Les principales fonctions de cette classe (Figure 4.12) : - Open_Connection() : cette fonction permet douvrir une session Telnet sur un routeur. - Ping() : teste la liaison avec un routeur. - getConfig() : Avoir le fichier de configuration dun routeur. - saveConfig() : Enregistrement du fichier de configuration dans un fichier texte. - getInterfaces() : Avoir les informations ncessaires concernant les interfaces dun routeur.
Figure 4-12: Structure de la classe ConfigCollector
4.2.
Implmentation
4.2.1. Outils utiliss

4.2.1.1. Langage de programmation : Java Java est dvelopp par une quipe de Sun Microsystems, est le dernier n des langages de programmation par objet. Fond notamment sur le principe dindpendance du support dexcution, il permet de gnrer du pseudo-code (appel couramment bytecode) interprt par une machine virtuelle. Lessor de Java a t largement catalys et mdiatis par le dveloppement de lInternet et du World Wide Web. Une des caractristiques les plus connues du code Java est en effet de
37
pouvoir tre tlcharg et excut par des navigateurs Web. Limpact est tel que lon estime aujourdhui le nombre de dveloppeurs Java plus de 500 000 travers le monde. La mise en uvre dans les rseaux privs dentreprise des technologies de lInternet que constitue lIntranet ouvre, grce Java, de nouvelles perspectives qui rvolutionnent la manire de concevoir les architectures Clients-Serveurs dployes jusqu aujourdhui. Les postes clients sallgent et reprsentent des cots dadministration moins importants. Les serveurs hbergent non seulement les donnes de lentreprise mais aussi les applications crites en Java, qui sont crites une fois et une seule, quel que soit leur support final dexcution. Elles peuvent ainsi tre mises jour de manire centralise. Les librairies de classes Java spcialises, qui intgrent en particulier linterrogation des bases de donns, ainsi que lapparition des Network Computers, font de Java une technologie cl du dploiement de ce nouveau systme dinformation de lentreprise, centr sur le rseau. Java prsente plusieurs avantages :
- Simplicit : Java rduit le nombre de structures de donnes utilisables au minimum et limine les zones de recouvrement. Pour le programmeur, la simplicit de Java sexprime aussi en grande partie par le fait quil est libr de la gestion explicite des adresses mmoire des objets quil manipule. Cette disposition vite les erreurs de programmation les plus frquentes et les plus dlicates corriger.
- Neutralit vis--vis des architectures matrielles et logicielles : Java utilise un double mcanisme de compilation et dinterprtation. Ce mcanisme permet au code gnr par le compilateur Java, appel bytecode, dtre indpendant des architectures matrielles et des systmes dexploitation. Le bytecode Java est en effet charg et interprt par une machine virtuelle, qui est elle-mme porte sur la plupart des systmes dexploitation du march.
- Vers une nouvelle architecture Client-Serveur : La mise en oeuvre dapplications Java dans un rseau dentreprise permet, en sappuyant sur les APIs dextension telles que JDBC ou JavaIDL, de dployer des applications client serveur. On peut ds aujourdhui btir un vritable Intranet en sappuyant sur les standards du Web. En intgrant les possibilits de relier simplement les applications Java au systme dinformation de lentreprise, on est maintenant capable de dployer des applications distribues qui hritent naturellement des qualits intrinsques de Java.
38
4.2.1.2. Environnement de dveloppement : JBuilder 2005 Lenvironnement de dveloppement choisi est Borland JBuilder 2005. Il offre une
multitude d'atouts pour conserver son titre de meilleur outil de dveloppement Java disponible sur le march. Il intgre, dans une interface agrable, tous les concepts d'ingnierie 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. Systme de gestion de base de donnes : Oracle 9.2.0 Oracle est lun des SGBD les plus forts dans le monde des bases de donnes, il prsente plusieurs avantages dont : - Scurit au niveau ligne. - JVM inclue dans le moteur. - Support SQLJ, niveau 0 et 1. - Gestion cluster, haute disponibilit. - Edition des plan d'excution. - Paralllisme pour insert et update. - Backup et restore parallles. - Tables de rsum. - Rles dfinis par l'utilisateur. - Gouverneur de ressources. - Attribution de priorits. Le choix dOracle est bas sur plusieurs raisons : Les tables concernant lhistorique sont des tables gantes. Laccs la base doit tre rapide. La base doit supporter plusieurs connexions la fois. Tunisie Tlcom utilise Oracle dans ses applications.
4.2.2. Interfaces utilisateurs

4.2.2.1. TTNetView Linterface principale (Figure 4.13) du TTNetView prsente la console
dadministration du Backbone IP/MPLS. Elle donne une vue globale sur les tats des routeurs et leurs interfaces ainsi un contrle continu sur les vnements gnrs par les diffrents processus (SNMPCollector, ConfigCollector) 39
Panneau 1
Panneau 2
Panneau 3
Figure 4-13: Interface principale de TTNetView
Panneau 4
Linterface principale se compose de 4 panneaux, le premier (Figure 4.14) comporte la liste des diffrents 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 slection dun groupe, le deuxime panneau (Figure 4.15) va contenir les informations concernant les routeurs de ce groupe (CPU, Mmoire utilise, Mmoire libre, Nombre dinterfaces). Pour les routeurs Cisco, on a choisit davoir les informations suivantes:
- Informations gnrales : - IP_Routeur : Adresse IP du routeur - sysName : Nom du systme - ifNumber : Nombre total dinterfaces - Informations concernant ltat du routeur : - cpu5min : Pourcentage de la charge du CPU pendant les 5 dernires minutes - memUsed : Mmoire utilis en bits - memFree : Mmoire libre en bits - tempIn : Temprature lentre en Fahrenheit - tempOut : Temprature 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 dpasse quelques centaines, il y aura un risque dattaque. - Informations concernant le protocole TCP : - tcpOpen : le nombre de connexions TCO ouverts - tcpInErrors : Nombre de paquets TCP qui prsentent des erreurs lentre. - 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 : reprsente le statut du protocole OSPF 1 : Activ ou 2 : Dsactiv - ospf_Version : Version du protocole OSPF active 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 slection dun 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 dinterface (exemple : Serial 1/2) - Description : Nom de la liaison (exemple : LS with ATI) - Ip_address : Adresse IP de cet interface - Netmask : masque de sous rseau - MTU : Taille maximale pour une trame qui peut passer par cette interface - Admin_Status : Etat administratif de linterface
42
- Oper_Status : Etat oprationnel de linterface - Inbits : Trafic en entre en bits - Inpackets : Trafic en entre en paquets - Outbits : Trafic la sortie en bits - Outpackets : Trafic la sortie en paquets - CRC : Nombre de paquets lentre qui prsentent une erreur au niveau du CRC - Collisions : nombre de collisions dtectes la sortie de cette interface. - inQueueDrop : nombre de paquets rejets parce que la file dattente lentre est sature - outQueueDrop : nombre de paquets rejets parce que la file dattente la sortie est sature.
Figure 4-16: Informations SNMP concernant les interfaces dun routeur Cisco
Le panneau 3 va contenir des statistiques concernant les OID o le champ Stored de la table OID est gal yes. - Statistiques dune 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 dun routeur Cisco
Statistiques dun 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 donnes, on garde lhistorique mme dune anne. A chaque courbe gnre, on peut soit : - Sauvegarder le rsultat sous la forme dune image portant lextension.jpg - Imprimer cette image - Gnrer un rapport sous la forme dune page html (Figure 4.19), cette page va contenir toutes les statistiques des diffrentes informations SNMP.
45
Figure 4-19: Gnration dun rapport Concernant un interface dun routeur Cisco
46
Le quatrime panneau (Figure 4.20) va contenir le log de SNMPCollector et du ConfigCollector. Chaque fois, qune valeur dun OID dpasse sa seuil, un vnement est gnr sous la forme : Date de gnration dvnement + Heure de gnration dvnement +
Routeur cible + Information SNMP + valeur La couleur blanche indique un vnement concernant un interface La couleur bleue indique un vnement concernant un routeur La couleur rouge indique un vnement critique : un routeur inaccessible pour lequel on ne peut pas avoir les informations SNMP (Figure 4.21).
Figure 4-20: Gnration des vnements
47
On na pas pu avoir des informations sur les routeurs 193.95.52.108, 193.95.52.98, 193.95.52.2 La console dvnements nous indique que ces routeurs sont injoignables
Indique ltat du processus SNMPCollector
Figure 4-21: Exemple dvnements 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: Cration dun nouveau groupe
49
Figure 4-24: Cration dun 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 spcifier lintervalle de temps qui spare 2 sessions de polling du rseau. Pour ConfigCollector on doit indiquer le jour du sauvegarde des fichiers de configuration des routeurs, cette opration se lance toujours minuit lorsque le rseau nest pas charg.
Figure 4-25: Composition du menu Edit
50
Figure 4-26: Configuration des processus
- Configurer les OIDs des diffrents 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 dun OID
A lajout dun OID, une nouvelle information sera ajoute (Figure 4.29) :
Figure 4-29: Ajout de linformation 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 affiche dans une bote de dialogue. 52
Figure 4-31: Interface de ConfigCollector
Lapplication TTNet Locator
4.2.3. TTNetLocator
TTNetLoctor est utilis pour la localisation dun client dans le Backbone IP/MPLS. On peut utiliser pour la recherche ladresse du routeur, ladresse IP de linterface, la description de linterface ou la table de routage (Figure 4.32).
Figure 4-32: Options de recherche dans TTNetLocator
Le rsultat de la recherche va contenir : Adresse IP du routeur. Nom du routeur. Nom dinterface. Description de linterface. Adresse IP du client. Masque du rseau. MTU. Bande passante. Routes passantes par cette interface.
53
A la slection dun client, on va avoir des informations supplmentaires 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 lapplication TTNetLocator
Conclusion
Nous venons, au niveau de ce chapitre, de prsenter les principaux modules utiliss ainsi que les interfaces utilisateurs. Plusieurs informations nont pas pu tre divulgues faute de confidentialit.
54
Conclusion et perspectives
Conclusion et perspectives
La gestion de rseaux est lun des domaines les plus complexes auxquels lon puisse se confronter; elle cumule la distribution, le modle objet, le temps rel, le transactionnel, la gestion dquipements complexes. Cest en consquence une source de cot importante pour loprateur, qui se voit contraint dinvestir des sommes significatives et des comptences critiques dans une fonction qui semble non immdiatement rentable.
Nanmoins, le souhait exprim ici concerne la comprhension de la ncessit de la fonction Gestion de Rseaux, et son intrt pour lentreprise; ce nest qu travers de la gestion efficace que ce dernier sera en mesure doffrir les services qui le diffrencieront de la concurrence. Lobjectif de ce projet tait essentiellement de dvelopper un gestionnaire de rseau pour le Backbone IP/MPLS de Tunisie Tlcom 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 complt de plusieurs manires. Des modules peuvent tre ajouts savoir la dcouverte de la topologie du rseau ; dcouverte automatique des machines du rseau, dessin de la topologie avec les interconnexions.
55
Bibliographie
Bibliographie & Nographies
Bibliographie
Simple Network Management Protocol de Nicolas ADENIS-LAMARRE et Vincent BEDRUNE Understanding SNMP MIBs de David Perkins et Evan McGinnis
Nographies
[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.commentamarche.com http://www.guill.net http://www.faqs.org/rfcs/rfc1157.html http://www.faqs.org/rfcs/rfc1155.html http://www.faqs.org/rfcs/rfc1213.html http://www.developpez.com
56
Annexes
Annexe1: Attestations de formations
57
Annexes
58
Annexes
Annexe2: Exemple de MIB

MIB II (RFC 1213) : Groupe Systme Informations gnriques de configuration Groupe Interfaces Informations concernant les interfaces : type, adresse, nombre doctets 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 SYNTAX DisplayString (SIZE (0..255)) 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 SYNTAX DisplayString (SIZE (0..255)) -- 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

Développement D Un Gestionnaire de Réseaux Pour IP-MPLS - BEN - AMARA - Sahbi - 2005

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

Développement D Un Gestionnaire de Réseaux Pour IP-MPLS - BEN - AMARA - Sahbi - 2005

Transféré par

Droits d'auteur :

Formats disponibles

RAPPORT DE PROJET DE FIN DETUDES

Ingnierie des Rseaux

Dveloppement dun gestionnaire de rseau pour le Backbone IP/MPLS de Tunisie Tlcom

Sabri Ben Amara

Anne universitaire : 2004/2005

A ma Mre A mon Pre A ma Femme A ma Fille A mes Frres A mes Surs

Mots cls : Backbone IP, SNMP, administration, gnration dvnement.

Table des matires

Table des matires

Table des matires

Liste des figures

Liste des figures

Liste des acronymes

Liste des acronymes

Chapitre 1 Prsentation du projet

Prsentation de lorganisme daccueil

Direction des Technologies de linformation et des Rseaux

Chapitre 3 : Description de lexistant

Chapitre 2 La gestion de rseau

But et domaine dapplication

Chapitre 3 : Description de lexistant

2.2.1. La cueillette des informations de gestion :

Chapitre 3 : Description de lexistant

2.2.2. Linterprtation des donnes

2.2.3. Le contrle des quipements

Principes de la gestion de rseau

Chapitre 3 : Description de lexistant

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

Chapitre 3 : Description de lexistant

2.4.2. Les entits

Chapitre 3 : Description de lexistant

Figure 2-2: Architecture SNMP

2.4.3. La Management Information Base

Chapitre 3 : Description de lexistant

Figure 2-3: Structure dindexation des donnes dans la MIB-2 SNMP

Chapitre 3 : Description de lexistant

Nom de la MIB-2 SNMP System

Interfaces Ip Icmp Tcp Udp Egp Transmission Snmp

Tableau 1 : Informations principales de la MIB-2 SNMP

Chapitre 3 : Description de lexistant

Chapitre 3 : Description de lexistant

2.4.4. Les oprations de management

Chapitre 3 : Description de lexistant

2.4.5. Comparaison entre SNMP v1, v2 et v3

Chapitre 3 : Description de lexistant

Chapitre 3 : Description de lexistant

Figure 2.4 : Composition de CMISE

Chapitre 3 : Description de lexistant

Chapitre 3 : Description de lexistant

2.8.1. Outils Locaux

2.8.2. Plates-formes dadministration

Chapitre 3 : Description de lexistant

Chapitre 3 : Description de lexistant

Chapitre 3 Description de lexistant 3. Introduction

Description du Backbone IP de Tunisie Tlcom

Chapitre 3 : Description de lexistant

Architecture IP/MPLS du Backbone IP

Chapitre 3 : Description de lexistant

Figure 3.1: Architecture MPLS pour le Backbone IP

Chapitre 3 : Description de lexistant

Chapitre 3 : Description de lexistant

Figure 3-1 : Optimisation du routeur BGP inter-PE

Chapitre 4 : Conception et implmentation