1. Introduction

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.

Il est organisé comme suit :

  • le paragraphe 2 présente un bref historique de SNMP ;
  • le paragraphe 3 présente l'architecture globale d'une solution basée sur SNMP ;
  • le paragraphe 4 présente le protocole lui-même. Il s'intéresse aux différentes versions du protocole et aux différentes requêtes SNMP ;
  • le paragraphe 5 présente la MIB. À ce titre, il décrit les notions de MIB, d'OID et de syntaxe SMI ;
  • le paragraphe 6 présente les agents SNMP ;
  • le paragraphe 7 présente quelques solutions de superviseurs SNMP ;
  • le paragraphe 8 présente les outils indispensables dès lors que l'on utilise le protocole SNMP ;
  • et enfin, le chapitre 9 conclut ce document.

2. 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 ;
  • 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 SNMPv2u et 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
RFC Titre de la RFC Statut
RFC 1155 Structure and Identification of Management Information for TCP/IP-based Internets standard
RFC 1156 Management Information Base for network management of TCP/IP-based internets historique
RFC 1157 Simple Network Management Protocol (SNMP) historique
  • 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 1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) historique
RFC 1447 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 1451 Manager-to-Manager Management Information Base historique
RFC 1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework standard proposé, remplacé par RFC-1908
  • 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 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) (3416) standard, remplacé par RFC-3416
RFC 1906 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 2573 SNMP Applications standard, remplacé par RFC-3413
RFC 2574 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 Management Framework standard proposé
RFC 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks standard
RFC 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) standard
RFC 3413 Simple Network Management Protocol (SNMP) Applications standard
RFC 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) standard
RFC 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) standard
RFC 3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) standard
RFC 3417 Transport Mappings for the Simple Network Management Protocol (SNMP) standard
RFC 3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) standard

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

Architecture SNMP globale
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.

4. Le protocole SNMP

Avec SNMP, tout est ASN.1 (Abstract Syntax Number 1). ASN.1 est un standard international spécifiant une notation destinée à décrire des structures de données. La description en ASN.1 d'une structure de données a pour but d'obtenir une spécification de la structure qui est indépendante d'un encodage lié à un matériel particulier et sans ambiguïté. ASN.1 est similaire à un autre standard, XDR. Le protocole SNMP est spécifié dans les différentes RFC en ASN.1. Les trames transportées par le réseau sont aussi codées en ASN.1.

Les documents de référence pour tout ce qui concerne ASN.1 sont les documents édités par l'IETF :

  • ISO/IEC 8824-1, ITU-T Recommendation X.680, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation de novembre 2008 ;
  • ISO/IEC 8824-2, ITU-T Recommendation X.681, Information technology - Abstract Syntax Notation One (ASN.1): Information object specification de novembre 2008 ;
  • ISO/IEC 8824-3, ITU-T Recommendation X.682, Information technology - Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification de novembre 2008 ;
  • ISO/IEC 8825-1, ITU-T Recommendation X.690, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) de novembre 2008 ;
  • ISO/IEC 8825-2, ITU-T Recommendation X.691, Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) de novembre 2008 ;
  • ISO/IEC 8825-3, ITU-T Recommendation X.692, Information technology - ASN.1 encoding rules: Specification of Encoding Control Notation (ECN) de novembre 2008 ;
  • ISO/IEC 8825-4, ITU-T Recommendation X.693, Information technology - ASN.1 encoding rules: XML Encoding Rules (XER) de novembre 2008 ;
  • ISO/IEC 8825-5, ITU-T Recommendation X.694, Information technology - ASN.1 encoding rules: Mapping W3C XML schema definitions into ASN.1 de novembre 2008 ;
  • ISO/IEC 8825-6, ITU-T Recommendation X.695, Information technology - ASN.1 encoding rules: Registration and application of PER encoding instructions de novembre 2008.

Comme tous les documents normatifs, ceux-ci n'échappent pas à la règle et sont peu attractifs. Toutefois, pour tout problème de compréhension relatif à ASN.1, il faudra passer par ces documents.

Le protocole SNMP est un protocole réseau qui comporte différentes requêtes. Ces requêtes sont regroupées en 3 familles :

  • les messages du superviseur SNMP vers l'agent SNMP ;
  • les messages de l'agent SNMP vers le superviseur SNMP ;
  • les messages entre agents SNMP.

Le protocole SNMP est un protocole supporté par UDP. Traditionnellement, les ports suivants sont utilisés :

  • l'agent SNMP utilise le port UDP 161 pour recevoir les messages "Get Request", "Get Next Request" et "Set Request" ;
  • le superviseur SNMP utilise le port UDP 162 pour recevoir les messages "Trap", "Notification" et "Inform".

4.1. 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 ;

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

4.3. 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).

4.4. La sécurité SNMP V3

La sécurité apportée par la version 3 de SNMP repose sur les concepts suivants :

  • le modèle USM (User-based Security Model). Ce modèle est défini par le RFC 3414 ;
  • le modèle VACM (View-based Access Control Model). Ce modèle est défini par le RFC 3415.

Trois mécanismes sont utilisés par le modèle USM. Chacun de ces mécanismes a pour but d'empêcher les attaques suivantes :

  • l'authentification, qui permet d'empêcher la modification d'un paquet SNMPv3 en cours de route et de valider le mot de passe de la personne qui transmet la requête ;
  • le cryptage, qui permet d'empêcher la lecture des informations de gestions contenues dans un paquet SNMPv3 ;
  • l'estampillage du temps qui permet d'empêcher la réutilisation d'un paquet SNMPv3 valide a déjà transmis.

Le modèle VACM quant à lui, permet de contrôler l'accès aux variables de la MIB en restreignant leur accès en lecture ou en écriture pour un groupe d'utilisateurs ou pour un utilisateur spécifique.

5. La MIB

5.1. 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 :

La MIB
La MIB

La MIB est un arbre hiérarchisé très dense. Il existe plusieurs milliers d'OID dans la MIB. Il est par conséquent impossible de décrire tous ces OID dans un seul fichier 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.

Attention, toutes les MIB n'ont pas le statut de RFC. Typiquement, les MIB des équipementiers ne sont pas référencées au niveau des RFC.

Il y a une petite particularité à signaler dans l'arbre de la MIB, il s'agit de la branche "private enterprises" (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.

5.2. 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".

À titre d'exemple, dans la RFC 1212, on trouve les OID suivants :

Exemple de définition d'OID
Sélectionnez

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."
    ::= { system 4 }
 
sysName OBJECT-TYPE
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
            "An administratively-assigned name for this
            managed node.  By convention, this is the node's
            fully-qualified domain name."
    ::= { system 5 }
 
sysLocation OBJECT-TYPE
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
            "The physical location of this node (e.g.,
            `telephone closet, 3rd floor')."
    ::= { system 6 }

Un fichier MIB est écrit en utilisant une syntaxe particulière. Cette syntaxe s'appelle SMI (pour Structure of Management Information). Comme pour le protocole SNMP lui-même, SMI est basé sur ASN.1.

Il existe plusieurs versions de syntaxe SMI :

  • la syntaxe SMIv1 : cette syntaxe est apparue avec la version SNMPv1 et est définie par la RFC 1155 ;
  • la syntaxe SMIv2 : cette syntaxe est apparue avec la version SNMPv2 est définie par la RFC 2579. Cette syntaxe introduit une spécification des OID avec plus d'informations et surtout introduit de nouveaux types de données ;
  • la syntaxe SMI-NG : cette syntaxe est encore à l'étude. Le dernier draft de SMI-NG date du 19 septembre 2003.

La bibliothèque "libsmi" est une bibliothèque "open source" qui permet de gérer les fichiers MIB.

La difficulté de la syntaxe SMI est que toutes les RFC annoncent que SMI est un sous-ensemble de la grammaire ASN.1 mais il est impossible de trouver quel sous-ensemble. Ceci explique que différents éditeurs de logiciels de gestion des fichiers MIB aient leurs interprétations, forcément différentes, et qu'il peut subsister dans les différents fichiers MIB des petites incompatibilités

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é).
Exemple d'erreur de syntaxe SMI
Sélectionnez

-- -- Reference	: 
-- -- Version		: V1.00
  • 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.

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

7. Les superviseurs SNMP

Le rôle d'un superviseur SNMP est de :

  • présenter (si possible de manière graphique), une vue de l'infrastructure supervisée avec l'état des différents équipements qui la composent. Dans les grosses infrastructures, il est courant que le superviseur SNMP affiche son écran sur un mur d'images dans la salle de supervision ;
  • communiquer avec les différents agents SNMP pour récupérer régulièrement les différents états des équipements ;
  • réagir en conséquence lorsqu'une variable de la MIB sort des limites définies par l'opérateur (engorgement du réseau, taux de remplissage du disque dur...). L'opérateur ou l'administrateur de la supervision peuvent définir les actions à réaliser en cas de réaction automatique (envoi d'un mail par exemple). Le comportement le plus courant d'un superviseur SNMP sera de modifier la couleur de l'équipement en cause pour alerter visuellement l'opérateur ;
  • recevoir en temps réel les messages SNMP "Trap" ou "Inform" en provenance des équipements et modifier l'affichage général en conséquence pour refléter le nouvel état ;
  • prendre en compte l'évolution de l'infrastructure en permettant l'ajout de nouveaux équipements dans le périmètre de supervision.

La liste suivante est une liste (non exhaustive) de superviseurs SNMP :

  • HP OpenView (désormais Network Node Manager). C'est une solution payante, référence en matière de supervision réseau ;
  • Nagios (anciennement appelé Netsaint). C'est une application permettant la surveillance système et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes vont mal et quand ils vont mieux. C'est un logiciel libre sous licence GPL ;
  • Zabbix. C'est un logiciel open source créé par Alexei Vladishev qui permet de surveiller le statut de divers services réseau, serveurs et autres matériels réseau ;
  • Multi Router Traffic Grapher (MRTG). C'est un logiciel développé sous licence GNU/GPL à l'initiative de Tobi Oetiker. Ce logiciel permet de créer des graphiques sur le trafic réseau. Il utilise le protocole SNMP pour interroger des équipements réseau tels que des routeurs, des commutateurs, ou des serveurs, disposant d'une MIB ;
  • Centreon. C'est un logiciel de surveillance et de supervision réseau, fondé sur le moteur de récupération d'information libre Nagios.
  • Vigilo. C'est un logiciel de supervision capable de gérer des systèmes hétérogènes (autant réseau que serveurs) de grande taille grâce à une architecture répartie et modulaire construite autour de Nagios.
  • BMC ProactiveNet Performance Management (anciennement BMC Patrol). C'est une solution de supervision payante dont l'éditeur est BMC Software.
  • OpenNMS. OpenNMS est une plateforme de management et de supervision réseau développé dans le cadre du logiciel libre ou le modèle open source. Il dispose d'une communauté ainsi que d'une organisation offrant des services commerciaux, de formation et de soutien.
  • NerveCenter. NerveCenter est une plateforme de gestion de réseau qui permet aux responsables informatiques de facilement et rapidement détecter et corriger les problèmes qui affectent les réseaux distribués d'aujourd'hui.
  • NetView. NetView est une solution de gestion réseau distribué développée par IBM Tivoli.
  • WhatsUpGold. WhatsUpGold est une solution payante de supervision et de management réseau éditée par la société IPSWITCH.

Si vous connaissez d'autres superviseurs SNMP gratuits ou payants, qui auraient leur place dans ce paragraphe, n'hésitez par à les signaler : 28 commentaires

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

Si vous connaissez d'autres outils gratuits ou payants, qui auraient leur place dans ce paragraphe, n'hésitez par à les signaler dans le thread dédié à cet effet : 28 commentaires

9. Conclusions

Voilà, ce tour d'horizon du protocole SNMP est maintenant terminé et j'espère qu'il aura démystifié les différents éléments qui gravitent autour du protocole SNMP. Votre avis et vos suggestions sur ce tutoriel m'intéressent ! Alors, après votre lecture, n'hésitez pas : 28 commentaires

Je tiens à remercier Clément BEAUFILS et Antoun pour leurs conseils avisés lors de la relecture de ce document.