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. 4.2.2.1. 4.2.3.

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 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 à SNMPv2. [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 Ip

Interfaces réseau et les données liées au trafic mesuré 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 Snmp

Informations au sujet des moyens de transmission et des protocoles d’accès aux interfaces de l’équipement 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 ROSESDUs. 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

Historique

Groupe

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

Stockage de Value

SNMPCollector 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


Demande la liste des groupes

Groupe

ConfigCollector

Base de 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 2

Panneau 1

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.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 “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 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

PFE_BEN_AMARA_Sahbi

Recommend Documents