WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception d'un outil d'administration réseaux

( Télécharger le fichier original )
par Walid Zayani
Université de Carthage Tunisie - Mastère professionnel en technologie des réseaux des télécommunications 2012
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

ANNEXE

I. Présentation du protocole SNMP 49

II. Historique 49

III. Architecture globale 54

IV. Les messages SNMP 56

III.1. Les messages du superviseur SNMP vers l'agent SNMP 56

III.2. Les messages de l'agent SNMP vers le superviseur SNMP 56

III.3. Les messages entre agents SNMP 57

V. La MIB 57

IV.1. Vue générale 57

IV.2. Les fichiers MIB 60

VI. Les agents SNMP 61

VII. Les outils SNMP 61

Annexe : Le PROTOCOLE SNMP

XIII. Présentation du protocole SNMP

Devant la véritable explosion des réseaux (que ce soient des réseaux internes à l'entreprise ou bien l'Internet lui-même) et leur importance primordiale dans une infrastructure (une panne de réseau se traduit bien souvent par un arrêt du travail), les besoins de superviser et surtout de diagnostiquer rapidement les problèmes sont devenus des préoccupations majeures. De plus, la complexité des équipements réseau a rendu nécessaire une approche permettant de synthétiser ces informations.

Les protocoles utilisés avant SNMP (pour Simple Network Management Protocol) étaient les protocoles Telnet et FTP permettant de se connecter directement à la console de l'équipement. Le problème de ces protocoles était qu'ils n'offraient pas une vue synthétique de l'infrastructure et qu'ils ne séparaient pas suffisamment les deux métiers différents que sont la supervision et l'administration.

Le protocole SNMP a longtemps cohabité avec un autre protocole CMIP/CMIS qui est plutôt un protocole OSI, alors que SNMP est plutôt soutenu par l'IETF. Cette cohabitation ainsi que la volonté d'une convergence entre les deux protocoles font que certains standards ont été employés avec SNMP (ASN.1, encodage BER, utilisation des MIBs...).

Ce document a pour but de présenter le protocole de supervision réseau SNMP ainsi que les différents éléments qui le constituent.

XIV. Historique

Le protocole SNMP a commencé à émerger dans les années 1980 et a évolué en plusieurs versions.

· SNMPv1 : c'est la première version du protocole. La sécurité de cette version est minimale, car elle est basée sur la connaissance entre les parties d'une chaîne de caractères appelée "communauté".

· SNMPsec : le but de cette version est de combler une lacune de la version précédente SNMPv1, la sécurité. Cette version, désormais largement oubliée, a été peu implémentée.

·

RFC

Titre de la RFC

Statut

RFC
1155

Structure and Identification of Management

Information for TCP/IP-based Internets

standard

RFC

Management Information Base for network

historique

SNMPv2p : beaucoup de recherches ont été entreprises pour mettre à jour le protocole SNMPv1. Il en résulte l'apparition de nouvelles requêtes protocolaires ainsi que de nouveaux types de données. La sécurité reste basée sur les groupes d'utilisateurs de SNMPsec.

· SNMPv2c : cette version du protocole est appelée "community string based SNMPv2". Elle améliore encore les requêtes protocolaires par rapport à SNMPv2p et utilise la sécurité par chaîne de caractères "communauté" de SNMPv1.

· SNMPv2u : cette version du protocole utilise les requêtes et les types de données définis par la version SNMPv2c, mais la sécurité est basée sur les usagers.

· SNMPv2* : cette version combine le meilleur de SNMPv2p et de SNMPv2u. Les documents de cette version n'ont jamais été officiellement publiés, il est toutefois possible de retrouver des copies de ces documents sur le site web de SNMP Research .

· SNMPv3 : cette version, supportant les "proxies", est une combinaison de la sécurité basée sur les usagers, les types et les opérations définis dans SNMPv2p. La sécurité est basée sur les versions SNMPv2uet SNMPv2*.

Actuellement, les versions les plus utilisées sont (par importance d'utilisation) : SNMPV1, SNMPV3 et SNMPV2c.

Le fait que la version 1 de SNMP perdure de nos jours s'explique par plusieurs facteurs :

· d'une part, les infrastructures déployées en version 1 ne sont plus modifiées sous prétexte que l'on ne modifie pas quelque chose qui fonctionne ;

· d'autre part, les nouvelles versions de SNMP ont été implémentées avec beaucoup de retard par les différents équipementiers. En effet, en parallèle avec SNMP, il existait un autre protocole appelé CMIP (CMOT Over TCP-IP), et les équipementiers ont été très attentistes pour savoir quel protocole allait réellement émerger ;

· et enfin, le protocole SNMPv1 est un protocole très simple qui demande peu de ressources lors de son implantation sur un petit équipement (une imprimante ou un hub par exemple).

Les tableaux suivants synthétisent les différentes versions et leurs RFC respectives :

· Version 1 - 1990

1156

management of TCP/IP-based internets

 

RFC

Simple Network Management Protocol (SNMP)

historique

1157

 

? Version 2c (classique) - 1993

RFC

Titre de la RFC

Statut

RFC
1441

Introduction to version 2 of the Internet- standard Network Management Framework

historique, proposé

comme standard

RFC
1442

Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)

standard proposé,

remplacé par RFC-1902

RFC
1443

Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)

standard proposé,

remplacé par RFC-1903

RFC
1444

Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)

standard proposé,

remplacé par RFC-1904

RFC
1445

Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)

historique

RFC

Security Protocols for version 2 of the

Simple Network Management Protocol
(SNMPv2)

historique

1446

 
 

Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)

historique

RFC
1448

Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)

standard proposé,

remplacé par RFC-1905

RFC
1449

Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)

standard proposé,

remplacé par RFC-1906

RFC
1450

Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)

standard proposé,

remplacé par RFC-1907

RFC

Manager-to-Manager Management

historique

 

1451

Information Base

 

RFC

Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework

standard proposé,

remplacé par RFC-1908

1452

 
 

? Version 2 - 1996

RFC

Titre de la RFC

Statut

RFC
1901

Introduction to Community-based SNMPv2

historique, proposé comme expérimental

RFC
1902

Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)

standard, remplacé par RFC-2578

RFC
1903

Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)

standard, remplacé par RFC-2579

RFC
1904

Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)

standard, remplacé par RFC-2580

RFC

Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) (3416)

standard, remplacé par RFC-3416

1905

 
 

Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) (3417)

standard, remplacé par RFC-3417

RFC
1907

Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) (3418)

standard, remplacé par RFC-3418

RFC
1908

Coexistence between Version 1 and

Version 2 of the Internet-standard Network Management Framework (2576)

standard, remplacé par RFC-2576

 

? Version 3 - 1999

RFC

Titre de la RFC

Statut

RFC
2571

An Architecture for Describing SNMP

Management Frameworks

standard, remplacé par RFC-3411

RFC
2572

Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

standard, remplacé par RFC-3412

RFC

SNMP Applications

standard, remplacé par RFC-3413

2573

 

User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

standard, remplacé par

RFC-3414

RFC
2575

View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

standard, remplacé par RFC-3415

 


· Versions 2 et 3 - 2000-2002

RFC

Titre de la RFC

Statut

RFC
2576

Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network ManagementFramework k

standard proposé

RFC
3411

An Architecture for Describing Simple Network kManagement Protocol (SNMP) Management Frameworks

standard

d

RFC
3412

Message Processing and Dispatching for the SimpleNetwork Management Protocol (SNMP)

)

standard

RFC
3413

Simple Network Management Protocol (SNMP)

Applications

standard d

RFC

User-based Security Model (USM) for version 3 of fthe Simple Network Management Protocol (SNMPv3)

standard

d

3414

 
 

View-based Access Control Model (VACM) for theSimple Network Management Protocol (SNMP)

)

standard

RFC
3416

Version 2 of the Protocol Operations for the SimpleNetwork Management Protocol (SNMP)

)

standard

RFC
3417

Transport Mappings for the SimpleNetwork kManagement Protocol (SNMP)

)

standard

RFC
3418

Management Information Base (MIB) for the SimpleNetwork Management Protocol (SNMP)

)

standard

 

XV. Architecture globale

Les buts du protocole SNMP sont de :

· connaître l'état global d'un équipement (actif, inactif, partiellement opérationnel...) ;

· gérer les évènements exceptionnels (perte d'un lien réseau, arrêt brutal d'un équipement...).

· analyser différents métriques afin d'anticiper les problèmes futurs (engorgement réseau...).

· agir sur certains éléments de la configuration des équipements.

Les différents éléments que l'on peut identifier avec le protocole SNMP sont synthétisés par le schéma ci-dessous.

- Figure 1 : Architecture SNMP globale -

· Les agents SNMP : ce sont les équipements (réseau ou serveur) qu'il faut superviser.

· Le superviseur SNMP : c'est une machine centrale à partir de laquelle un opérateur humain peut superviser en temps réel toute son infrastructure, diagnostiquer les problèmes et finalement faire intervenir un technicien pour les résoudre.

· Le protocole SNMP : c'est le protocole utilisé par les agents SNMP et leur superviseur pour communiquer entre eux.

· La MIB : ce sont les informations dynamiques instanciées par les différents agents SNMP et remontées en temps réel au superviseur.


· Les outils SNMP. Ce sont les différents utilitaires utilisés par le superviseur pour l'aider à diagnostiquer un problème. Ces différents outils sont aussi utilisés lors de la configuration du superviseur pour prendre en compte les spécificités de l'infrastructure.

XVI. Les messages SNMP

Les messages du superviseur SNMP vers l'agent SNMP
Les messages envoyés par le superviseur SNMP vers l'agent SNMP sont :

· Message "Get Request" : ce message permet au superviseur d'interroger un agent sur les valeurs d'un ou de plusieurs objets de la MIB.

· Message "Get Next Request" : ce message permet au superviseur d'interroger un agent pour obtenir la valeur de l'objet suivant dans l'arbre des objets de l'agent. Ce message permet de balayer des objets indexés de type tableau.

· Message "Get Bulk Request" : introduite avec la version 2 du protocole SNMP, ce message permet de mixer les messages "Get Request" et "Get Next Request" pour obtenir des blocs entiers de réponses de la part de l'agent.

· Message "Set Request" : ce message permet au superviseur de positionner ou modifier la valeur d'un objet dans l'agent.

Les messages de l'agent SNMP vers le superviseur SNMP Les messages envoyés par l'agent SNMP vers le superviseur SNMP sont :

· Message "Get Response" : ce message est utilisé par l'agent pour répondre aux messages "Get Request", "Get Next Request" et "Get Bulk Request" envoyés par le superviseur ;

· Message "Trap" : ce message est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent n'attend pas d'acquittement de la part du superviseur.

· Message "Notification" : introduit avec la version 2 du protocole SNMP, ce message est similaire au message "Trap". Il est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent n'attend pas d'acquittement de la part du manager.


· Message "Inform" : introduit avec la version 2 du protocole SNMP, ce message est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent attend un acquittement de la part du superviseur et il y aura une retransmission en cas de non réponse. Ce message peut aussi être utilisé pour un dialogue superviseur - superviseur.\

Les messages entre agents SNMP

Le seul message envoyé entre les agents SNMP est :


· Message "Report" : introduit avec la version 2 du protocole SNMP mais jamais implémenté, ce message permet aux différents agents de communiquer entre eux (principalement pour remonter des problèmes de traitement des messages SNMP).

XVII. La MIB [3]

II.19. Vue générale

Comme on a commencé à le voir dans le paragraphe précédent, SNMP définit deux choses, le protocole, c'est-à-dire la façon dont est transportée l'information et les informations dynamiques, fournies par les différents agents SNMP. Ces informations sont spécifiées dans ce que l'on appelle la MIB (Management Information Base).

La MIB est un ensemble structuré d'informations organisé sous la forme d'un arbre hiérarchisé de la même manière que l'arborescence des domaines Internet. Chaque information dans cette hiérarchie est identifiée par son OID (Object Identifier). Par exemple, l'objet ifDescr est identifié par son OID 1.3.6.1.2.1.2.2.1.2.

Comme on peut le voir dans l'exemple, un OID est une séquence de nombres séparés par le caractère "." (Point).

Le début de l'arborescence des OID défini dans les différentes RFC est le suivant :

- Figure 2 : La MIB

De même que pour le DNS, les différentes parties de la MIB sont définies dans différents fichiers MIB. Chaque fichier MIB a la responsabilité d'une branche particulière de la MIB. Ainsi, on trouve par exemple les fichiers MIB suivants :

· SNMP - SMI: RFC 1155 - Defines the Structure of Management Information (SMI).

· MIB-I : RFC 1156 - Historically used with CMOT , not to be used with SNMP ;

· SNMPv2-SMI : RFC 2578 - Structure of Management Information Version 2 (SMIv2).

· MIB-II: RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets.

· SNMPv2-MIB: RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP).

· TCP-MIB: RFC 4022 - Management Information Base for the Transmission Control Protocol (TCP).

· UDP-MIB: RFC 4113 - Management Information Base for the User Datagram Protocol (UDP).

· IP-MIB : RFC 4293 - Management Information Base for the Internet Protocol (IP) ;

· IF-MIB: RFC 2863 - The Interfaces Group MIB.

· ENTITY-MIB: RFC 4133 - Entity MIB (Version 3).

· ENTITY-STATE-MIB : RFC 4268 - Entity State MIB.

· ALARM-MIB : RFC 3877 - Alarm Management Information Base (MIB).

· FC-MGMT-MIB : RFC 4044 Fibre Channel Management MIB.

· FIBRE-CHANNEL-FE-MIB : RFC 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard.

· HPR-IP-MIB: RFC 2584 - Definitions of Managed Objects for APPN/HPR in IP Networks.

· et beaucoup d'autres MIB encore.

Il y a une petite particularité à signaler dans l'arbre de la MIB, il s'agit de la branche "private entreprises" (OID 1.3.6.1.4.1). Cette branche permet aux différentes entreprises de gérer leurs MIB spécifiques. Chaque entreprise se voit attribuer un OID unique et elles ont ensuite le droit de décrire leurs OID spécifiques en dessous de leur OID d'entreprise. La gestion de la

branche d'une entreprise est entièrement laissée à cette entreprise. Les différents OID d'entreprises sont alloués par l'IANA. On retrouve par exemple :

· Cisco avec un OID 1.3.6.1.4.1.9.

· HP avec 1.3.6.1.4.1.11.

· Novell avec 1.3.6.1.4.1.23.

· et beaucoup d'autres entreprises encore.

II.20. Les fichiers MIB

Comme on a pu le voir dans le paragraphe précédent, la MIB est organisée sous la forme d'un arbre hiérarchisé qui contient des informations et chaque portion de l'arbre est décrite par un fichier MIB particulier. Tâchons de voir maintenant ce qu'est un fichier MIB.

Tout d'abord, un fichier MIB est un fichier texte. Il contient la spécification de différents OID. Pour chaque OID, cette spécification comprend :

· un OID unique, dans l'arbre des OID. Par exemple 1.3.6.1.2.1.1.3.

· un nom générique. Par exemple sysUpTime ;

· une description de cet OID. Par exemple, "The time (in hundredths of a second) since the network management portion of the system was last re-initialized.".

· son type. Par exemple TimeTicks. Il existe différents types possibles de données qui permettent de couvrir tous les besoins ;

· son statut. Par exemple mandatory. Les différents statuts possibles sont "mandatory", "optional", "obsolete".

· son mode d'accès. Par exemple read-only. Les différents accès sont "read-only", "read-write", "write-only", "not-accessible".

Quelques difficultés courantes avec les MIB :

· Disponibilité du fichier MIB. S'il n'est pas nécessaire de disposer de la MIB d'un équipement pour le superviser, il est parfois difficile voire impossible de comprendre le rôle des OID de cet agent ou de deviner à la suite de quel événement va être envoyé un message "Trap" au superviseur. La seule référence reste le fichier MIB de l'équipement et ce fichier est parfois difficile à trouver.

· Erreur de syntaxe. Il est très courant de trouver des fichiers MIB comportant des erreurs de syntaxe. Le dernier exemple que j'ai vécu, est la ligne suivante tirée du fichier d'un équipementier réseau qui faisait planter le compilateur de MIB. Il y avait un double commentaire (le double caractère '-'), et la norme ASN.1 est très claire à ce

sujet : un commentaire commence avec le double caractère '-' et se termine à la fin de la ligne ou alors au double caractère '-' suivant présent sur la même ligne. En conclusion, il n'est pas exclu de trouver des erreurs de syntaxe dans un fichier MIB (même écrit par un équipementier réseau renommé). Complétude du fichier MIB. Parfois aussi, on trouve des MIB dont la description textuelle des OID est vide, ce qui n'aide pas beaucoup à leur compréhension. De même, il est souvent impossible de connaître de manière fiable la liste des OID (on parle des varbinds) portés par un message "Trap". Il faut alors avoir recours à un analyseur de protocole pour connaître cette liste.

XVIII. Les agents SNMP

Un agent SNMP est un logiciel implanté sur un équipement à superviser. Il s'agit souvent d'un équipement réseau (switch, hub, routeur...) mais on trouve aussi des agents sur des serveurs.

Le rôle d'un agent SNMP est :

· d'instancier les différentes variables de la MIB spécifiques à cet équipement ;

· de mettre à jour les valeurs dynamiques de ces différentes variables ;

· de recevoir les requêtes SNMP envoyées par le superviseur SNMP et d'y répondre ;

· d'envoyer les messages SNMP "Trap" ou "Inform" au superviseur SNMP pour le prévenir d'un événement exceptionnel sur l'équipement ;

· de gérer la sécurité des accès aux variables de la MIB conformément au modèle de sécurité mis en place.

Un agent SNMP ne connaît pas et n'a pas besoin de connaître son fichier MIB. Il sait quelles variables MIB il doit instancier, leur type et comment les mettre à jour. C'est soit codé en dur dans le code, soit cela fait partie d'un fichier de configuration annexe qui n'a rien à voir avec un fichier MIB.

XIX. Les outils SNMP

Lorsque l'on commence à s'intéresser au protocole SNMP, il est tôt ou tard nécessaire d'utiliser différents outils spécifiques pour déboguer son environnement SNMP :

? Ping : outil de test de la connectivité réseau.

· Traceroute : un autre outil de test de connectivité réseau qui affiche en plus la route empruntée ;


· La suite d'outils Net-SNMP. Il s'agit d'une collection de petits outils rigoureusement indispensables qui permettent d'envoyer ou de recevoir des requêtes SNMP. On trouve, entre autres, l'excellent outil "snmpwalk" qui permet d'interroger un équipement pour connaître tous les OID gérés par celui-ci. Ces outils ont été portés dans de nombreux environnements ;

· SnmpB. Il s'agit d'un outil qui permet de lire et d'afficher sous forme graphique un fichier MIB. De plus, il est doté de l'équivalent "snmpwalk" pour afficher les OID gérés par un équipement quelconque. Il est de plus capable de recevoir les trap SNMP.

· Wireshark : il s'agit d'un analyseur de protocoles très complet qui permet, entre autres, d'analyser très finement les trames protocolaires SNMP.

· Getif : il s'agit d'un outil graphique gratuit fonctionnant sous environnement Microsoft regroupant plusieurs outils d'aide à l'analyse des problèmes réseau (ping, traceroute, nslookup...). Il dispose aussi d'outils orientés SNMP.

· OidView : il s'agit d'un outil graphique payant fonctionnant sous environnement Microsoft. Il dispose des principaux outils SNMP et aussi d'un MIB Browser.

· iREASONING : il s'agit d'un éditeur de logiciels (avec donc des solutions payantes) qui dispose de beaucoup d'outils SNMP.

· SNMP4J : il s'agit d'une API et d'une librairie SNMP open source sous licence apache v2 pour environnement Java.

· Java SNMP Package : il s'agit d'une autre API et d'une librairie SNMP gratuite pour environnement Java. Il semble qu'elle soit un peu à l'abandon.

· libsmi : il s'agit d'une bibliothèque "open source" qui permet de gérer les fichiers MIB.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Nous voulons explorer la bonté contrée énorme où tout se tait"   Appolinaire