next up previous contents index
Next: D Sockets BSD et Up: C Protocoles applicatifs Previous: XI Courrier électronique   Contents   Index

Subsections

XII Instrumentalisation de réseaux avec SNMP

1 Nécessité d'un outil

La majeure partie des activités informatiques dépendent du bon fonctionnement des réseaux et des services associés. Leurs nombres et leur complexité ne cessent de s'accroître, mais bien souvent le personnel responsable de l'évolution et du bon fonctionnement de l'ensemble ne voit pas ses effectifs humains évoluer dans le même sens, du moins aussi rapidement que le parc de machines à administrer !

Or, le bon fonctionnement d'un grand réseau ne peut dépendre pour seule composante que de l'effort intellectuel d'individus ou de groupe d'individus, fussent-ils compétents et dévoués. Il faut des outils !

1.1 Problématique de l'ISO

L'ISO, s'est penché sur la question et a segmenté le problème de la gestion technique de réseau en cinq points :

La gestion des pannes
(Fault management) Il s'agit de détecter les pannes, de les localiser et d'y remédier en minimisant l'impact de la perte de fonctionnalité sur le reste du système d'information.

La panne n'est pas une erreur, mais un grand nombre d'erreurs peuvent conduire à déclarer une panne. Par exemple la croissance anormale du nombre de collisions sur un réseau, l'engorgement d'un disque...

La comptabilisation de l'usage des ressources
(Accounting management) Il s'agit d'archiver et de mettre en ordre tous les compteurs générés par les applicatifs et les couches réseaux afin de pouvoir tirer un enseignement de l'usage des ressources.

L'aspect confidentiel de ces données doit être pris en compte.

La gestion des configurations
(Configuration and name management) Il s'agit de la mise en \oeuvre et de la configuration de tous les équipements qui inter-agissent sur le réseau.

L'audit des performances
(Performance management) Il s'agit d'avoir une approche quantitative sur le fonctionnement du réseau afin de pouvoir répondre à des questions aussi basiques que :

  1. Quel est le niveau actuel d'utilisation ?
  2. Il y a t-il un (des) trafic(s) excessif(s) ?
  3. Le débit nominal est-il réduit à une valeur inacceptable ?
  4. Où sont les goulots d'étranglement ?
  5. Quelle est l'évolution du temps de réponse ?

La gestion de la sécurité
(Security management) Il s'agit de maintenir cohérent et effectif l'ensemble des protections sur les autorisations d'accès et données sensibles collectées.

Les logs (syslog) sont un point important de la gestion de la sécurité.

En conclusion, les buts d'une gestion technique efficace d'un réseau sont multiples : il s'agit d'offrir aux usagers un service de qualité, de permettre les évolutions du système d'information en y incluant de nouvelles fonctionnalités, d'optimiser l'usage des ressources et de minimiser les coûts d'exploitation ou d'investissement.

1.2 Système de gestion de réseau

Un système de gestion de réseau (Network Management System) est une collection d'outils pour la surveillance et le contrôle afin de permettre à un opérateur d'effectuer la plupart des opérations de gestion depuis un interface le plus simple et ergonomique possible !

C'est un ensemble de logiciels (Network Management Entity) associés éventuellement à des matériels spécifiques, qui sont déployés sur tous les composants du système d'information.

Un NMS est donc conçu pour donner une image unifiée du réseau, quelle que soit son étendue et son hétérogénéité. Le logiciel utilisé pour visualiser l'image du réseau est un NMA (Network Management Application).

Un NME :

  • Collecte des données sur l'activité réseau
  • Conserve ces données dans une base
  • Répond aux requêtes du NMA, notamment sur les points suivants :
    1. Transmission des données collectées
    2. Changement d'un paramètre de configuration
    3. Fourniture de statut de composants logiciels ou matériels
    4. Génération de tests
  • Envoi des messages d'alerte (trap) en cas de détection d'évênements exceptionnels.

Au moins un n\oeud du réseau est désigné comme étant le manager, et supportant le NMA. Cette architecture n'est pas nécessairement centralisé, la supervision du réseau peut s'effectuer par secteurs.


1.3 SNMP -- Simple Network Management Protocol

SNMP est un terme un peu générique qui désigne à la fois un protocole réseau applicatif bien précis, une collection de spécifications pour le management de réseau et la définition de structures de données ainsi que leurs concepts associés.

SNMP est né en 1988 de la nécessité de disposer d'un outil de supervision du réseau dès lors que celui-ci comporte un grand nombre d'hôtes qui inter-agissent, stations, serveurs, éléments de routage ou de commutation ou encore boites noires. Leur nombre grandissant sur les LANs (des machines en clusters par exemples) implique d'avoir un outil qui permette `` d'expliquer '' le réseau. Ce besoin est moins évident quand tout va bien, mais il suffit parfois d'un simple petit grain de sable... Dans ces moments là, disposer d'un outil qui délivre une information de synthèse est indispensable !

Les logs, au sens de syslog (paragraphe 3.2 page [*]) , même concentrés, filtrés, et triés ne délivrent une information parfois trop verbeuse et en tout cas structurée différemment selon les applications ou les noyaux. Les évênements réseaux y sont le plus souvent absents, sauf dans le cas très particulier de démons qui surveillent le réseau, arpwatchXII1 en est un exemple. Le tri par niveau de criticité ne retire rien ou presque au fait que c'est une information brute qu'il faut filtrer pour en extraire l'information pertinente.

L'architecture d'un réseau géré avec SNMP comporte essentiellement deux entités : le manager et l'agent, ou encore le client et le serveur. Le client (manager) interroge le serveur pour récolter de l'information ou configurer une valeur, le serveur (agent) est capable de prévenir le client en cas d'évênements exceptionnels (traps).

Enfin, n'importe quelle machine munie d'une stack IP est susceptible de supporter SNMP, depuis le calepin électronique, en passant par la borne wifi et jusqu'au mainframe.

En quelques mots, SNMP permet :

  • De cartographier le réseau
  • De fournir un panel très complet de résultats de mesures pour chaque hôte
  • De mesurer en temps réel la consommation de ressources d'une application
  • De signaler les dysfonctionnements
  • De changer certains paramètres réseaux de fonctionnement

Avantages :

  • Protocole est simple et facile d'utilisation
  • Permet une gestion centralisée d'un parc
  • Dispose d'un modèle extensible
  • Est indépendant de l'architecture matérielle

\includegraphics{fig.snmp.01.ps} figure XII.01 -- Agent et Manager dans une relation de type client-serveur

1.4 Historique du protocole SNMP

Avant 1987/1988 il n'y a rien d'autre qu'ICMP pour recevoir de l'info entres routeurs et hôtes. Le couple (echo request,echo reply) est le plus utilisé pour maintenir un état des machines accessibles.

Le point de départ est SGMP (`` Simple Gateway Monitoring Protocol '' RFC 1028 de novembre 1987) mais trop orienté sur la gestion des routeurs. Du coté de l'OSI d'autres tentatives avec CMIS et CMIP (`` Common Management Information Service & Protocol '')

SNMP est sorti en 1988, comme une version améliorée de SGMP. Les RFCs fondatrices sont les 1155, 1156 et 1157 conservées actuellement au rang d'historiques bien que tous les équipements soient théoriquement encore compatibles SNMPv1 (même s'ils répondent à un niveau de version SNMP plus récent, c'est à dire 2 ou 3).

1.5 Vocabulaire et architecture

Un système d'exploitation peut être vu comme une vaste collection de compteurs et d'horloges auxquels SNMP nous permet d'accéder à distance pour les lire et les modifier (certaines, sous réserve d'y avoir accès).

Afin que les agents et les managers soient inter-opérables les variables sont collectionnées selon une représentation arborescente très structurée et standardisée, ce sont les MIBs (`` Management Information Base ''). On les retrouve partout où SNMP est supporté. Ainsi, une même information se nomme de la même manière quelle que soit l'implémentation de SNMP et indépendamment de sa valeur qui est fonction du contexte. C'est donc très commode pour automatiser les traitements (scripts de collecte et de surveillance...) dans un réseau qui est hétérogène la plupart du temps !

Les feuilles de cet arbre sont les variables et on y accède en connaissant le chemin à priori depuis la racine, un peu à la manière d'un système de fichiers, sauf qu'ici les chemins sont codifiés à l'avance.

Actuellement c'est la MIB-2 qui est la plus répandue (RFC 1213), elle répond parfaitement aux besoins élementaires. Si un appareil ou un système a des besoins spécifiques il est toujours possible d'ajouter des branches au tronc commun, un embranchement est prévu pour cela, on parle alors d'une extension `` vendor ''.

Tous les vendeurs d'hôtes réseaux prévoient des MIBs pour leurs équipements (`` mibs vendors '' donc), dès lors qu'ils sont accessibles via ip (routeurs, commutateurs, ponts, hôtes, imprimantes, boites noires diverses) même si celle-ci n'est pas montrée à l'utilisateur final. Telle borne wifi d'un célèbre constructeur informatique `` à la pomme '', utilise SNMP pour se configurer mais l'utilisateur ne le voit pas, c'est masqué par un interface utilisateur convivial.

La figure XII.01 présente la relation entre les deux entités logicielles qui dans le cas de SNMP se nomment :

Agent SNMP, ou NME (le serveur)

C'est un logiciel qui s'exécute sur l'appareil que l'on souhaite administrer à distance. Il répond aux requêtes du gestionnaire, et génère des alarmes (traps) si besoin est. La configuration d'un agent est en général assez simple (par rapport à celle d'un logiciel Manager).

Manager NMA (le client)

C'est le logiciel qui s'exécute sur la station d'administration. Sa configuration est forcémement plus délicate que celle de l'agent parcequ'il nécessite une adaptation au réseau local qui est toujours un cas particulier. Il existe de nombreux logiciels HP OpenView, SUN Net Manager , IBM Netview, Spectrum, ISM OpenMaster, SNMPc....

L'Open Source n'est pas en reste et sans être aussi complet, l'outil `` tkined '' est déjà très satisfaisant pour l'essentiel des besoins (voir la recopie d'écran page [*]).

Sonde RMON (alternative de serveur)

La figure 01 est en fait incomplète dans le cadre d'une architecture de supervision globale de réseau : si chaque agent sur chaque hôte peut répondre individuellement sur les évênements réseau le concernant, il manque un maillon plus global qui fasse la supervision du réseau en lui-même, le véritable `` networking management ''. Cet élément existe, c'est ce qu'on appelle une sonde RMON, ou encore `` Remote Monitoring ''.

C'est une entité logicielle, comme un agent SNMP. Elle s'appuie sur une extension de la MIB de base. On la trouve principalement sur les éléments de commutation ou de routage, là où se concentre le trafic réseau, mais on peut la trouver sur un hôte également, par exemple sur un serveur critique.

L'Open Source nous en fournit un très bel exemple avec le logiciel ntopXII2.

La représentation des données dans les variables n'est pas laissée au hasard des besoins des développeurs mais est structurée selon une spécification appellé SMI `` Structure of Management Information '', définie par la RFC 1155, qui dit par exemple qu'un entier positif va de 0 à 232-1. Pour être indépendant du formalisme local de la plateforme (problématique de la couche 6 OSI).


1.6 Différentes versions

Enfin cet échange de données prend place dans un protocol réseau qui est défini par les RFC 1155 à 1157, nommé `` Simple Network Management Procotol '' (version 1).

Beaucoup de travail dans les rfc depuis...

Actuellement il y a 3 versions de SNMP, v1, v2c et v3. La v1 est supportée pour des raison `` historiques '', la v2 est la plus couramment supportée par les appareillages. Elle pose quelques soucis que tente de régler la v3 (notamment la sécurisation de l'authentification).

La première version souffrait d'un certain nombre de lacunes au niveau du protocole et de la sécurité que la deuxième version (SNMPv2c `` Community-based SNMPv2 '') définie par les RFC 1901 à 1908, tente de combler. Rien n'est malheureusement fait coté sécurité dans cette deuxième version mais des améliorations sont apportées aux mibs standards et au protocole.

Plus récemment un nouveau cadre de travail a été développé, qui s'affranchit complètement de la notion de `` communauté '', obstacle à l'usage de SNMP en écriture, et qui introduit des améliorations significatives de la sécurité (RFC 3411 à 3418).

L'inertie des habitudes retarde son déploiement généralisé, ainsi que la nécessité de continuer à gérer des appareils ne le supportant pas (encore).

1.6.1 Trois composantes pour SNMP

D'après la RFC 1213 (MIB II) le cadre de travail de SNMP repose sur trois composantes :

SMI
définit les types d'objets utilisés dans les mibs. C'est une sorte de méta modèle de données. Par exemple pour définir une adresse physique (MAC)
    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.

La MIB
décrit une collection structurée des ressources à gérer. Une ressource à gérer est représentée par un objet.

Le protocole SNMP
qui régit le contenu des dialogues clients/serveurs c'est à dire l'interrogation des données structurées par la MIB.

1.6.2 Conclusion

le protocole SNMP est simple dans sa conception ce qui permet son déploiement sur de très nombreux appareils hétérogènes mis en réseau.

En pratique la situation est moins simple du fait de la coexistence de 3 versions des MIB non toutes supportées par tous les hôtes du réseau.

La configuration de la station d'administration demande du temps, une connaissance très approfondie de la topologie du réseau à administrer, et beaucoup de compétences techniques. C'est un travail à haute valeur ajoutée !

2 SMI -- Structure of Management Information

La RFC 1155 fondatrice pose le cadre de travail à l'intérieur duquel on peut bâtir les MIBs. En effet, la SMI précises les types de données et les ressources qui peuvent être spécifiées dans une MIB.

Les données ont été prévues simples, le tableau (par exemple pour représenter un ensemble de connexions tcp tcpConnTable) et la liste (les éléments d'un quintuplet tcp tcpConnEntry) sont les formes les plus complexes prévues.

Ces structures de données sont remplies avec les 5 types suivants :

networkaddress
Il s'agit d'une zone pouvant contenir une adresse réseau, avec comme format possible IpAddress (ipv4 32 bits).

counter
C'est un compteur qui prend sa valeur maxi à 232 - 1 (on reconnait un entier 32 bits non signé) et qui ne peut pas être décrémenté. Quand il atteind sa valeur maxi il repasse à 0.

gauge
C'est un compteur, qui a la même valeur maximale que le précédent mais qui au contraire peut être décrémenté. Par contre il ne repasse pas automatiquement à 0 en cas de valeur maximale atteinte.

timeticks
Le nombre de secondes écoulées depuis epoch, c'est à dire le 1er janvier 1970.

opaque
C'est un flux d'octets banalisés qui permet d'encoder tout ce qui ne relève pas des types précédents, une sorte de fourre-tout en quelque sorte...

Toutes les ressources auxquelles on souhaite accéder décrites dans un document qui est une MIB.

3 MIB -- Management Information Base

Les MIBs sont des fichiers au format ascii qui décrivent dans le détail chacune des ressources à quantifier. Ces ressources sont des éléments simples (scalaire ou tableaux à deux dimensions). Chaque unité de description se nomme un `` objet '' (sans aucun rapport avec la programmation du même nom). Une MIB est une collection structurée de tous ces objets. Un même objet est accessible de la même manière partout sur le réseau.

Le propos d'une MIB peut être celui de respecter un standard ouvert, décrit alors par une RFC et distribué librement, ou d'être spécifique pour un type particulier d'appareil et de constructeur (`` mibs vendor ''). Sa diffusion est alors à l'initiative de son auteur.

Le contenu d'une MIB est toujours décrit à l'aide d'un langage formel nommé ASN.1XII3 utilisé généralement pour définir des structures de données applicatives complexes (couche 6 du modèle de l'OSI) et qui est indépendant de tout langage de programmation.

Un extrait de la MIB II (RFC 1213) concernant le début de la description de l'objet tcpConnTable, à savoir la table des connexions tcp, celle là même que l'on peut observer avec la commande netstat -p tcp.

% latex2html id marker 25493
\framebox[13cm][l]{
\parbox[l]{13cm}{
\begin{cen...
...{\hspace{1em}Extrait de la MIB II concernant l'OID {\tt tcpConnTable}}}
\par
}
}

Ce petit exemple montre que l'identification d'un objet repose sur cinq champs :

  1. Le nom de l'objet, tcpConnTable qui balise le début de la définition
  2. (SYNTAX) La syntaxe d'usage. Ici une liste d'objets tcpConnEntry. On y reconnaîtra sans peine les éléments du quintuplet vus en cours TCP.
  3. (ACCESS) L'accès (lecture, écriture, lecture-écriture, pas accessible). Ici On ne peut ni lire ni écrire dans cet objet.
  4. (STATUS) L'état de l'objet, valeur à prendre dans obligatoire (MANDATORY), obsolète ou optionnel.
  5. (DESCRIPTION) Un texte qui décrit ce que représente l'objet.

Les lignes qui débutent par un `` - '' sont des commentaires.

Enfin on peut remarquer que ce bloc de texte se termine par ::= { tcp 13 } qui signifie que cet objet est le treizième fils de l'objet père tcp.

Tous les objets de toutes les MIBs (propriétaires ou non) sont organisés dans un seul arbre, donc avec une seule racine commune. Pour identifier un objet dans cet ensemble, on parle de son OID.

3.1 OID -- Objet Identifier

Le nommage des objets utilise une représentation arborescente dont la racine est figée mais qui est extensible à volonté. Le nommage d'un objet passe par la définition (en ASN.1) d'un `` Objet IDentifier '' ou OID, qui peut s'apparenter au `` path '' d'un fichier.

Ce chemin peut s'exprimer de manière symbolique, par exemple .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 ou encore dans une représentation numérique absolument équivalente .1.3.6.1.2.1.1.1 En pratique on pourra le plus fréquemment faire référence seulement à sysDescr.0XII4. La racine de l'arbre est à gauche, contrairement, par exemple, au système de nommage du DNS qui place la racine à droite.

En effet un OID est une séquence d'entiers, parcours dans l'arbre de la racine jusqu'à la feuille terminale. Chaque noeud traversé est étiquetté par un nombre et un bref texte descriptif. Bien entendu l'unicité de l'étiquettage à un niveau donné de l'arbre est primordial pour son bon fonctionnement.

La racine n'est pas nommée, d'où le point (.) à gauche des deux écritures qui précèdent.

À ce jour deux entités se partagent les trois noeuds du premier niveau de l'arbre : l'ISOXII5 et le CCITTXII6, le troisième noeud s'explique par une entité mixte des deux et nommée `` joint-iso-ccitt ''.

\includegraphics{fig.snmp.02.ps} figure XII.02 -- La racine de l'arbre des OIDs

Sous le noeud de l'iso un sous arbre est prévu pour d'autres organisations, l'une d'elle est le département de la défense US (dod). La RFC 1155 pose le fait qu'un sous arbre du dod est alloué à l'IAB (Internet Activity Board), sans doute une trace des origines militaires de la pile Arpa.

Et voila pourquoi les OIDs standards sont placés sous le noeud nommé mib-2(1) et que le préfixe le plus commun est .1.3.6.1.2.1, indices des noeuds pères traversés à partir de la racine !

Directory(1)
Réservé pour l'OSI

mgmt(2)
L'administration de ce sous arbre est délégué à l'IANAXII7 et est donc régit par des RFCs !

Experimental(3)
Utilisé pour identifier des objets utilisés pour des déploiements expérimentaux sur l'Internet. Délégué à l'IANA.

Private(4)
Comme son nom l'indique ce sous arbre est celui des délégations privées. Le sous arbre enterprise(1) permet aux entreprises d'y placer leurs MIBs, après s'être enregistrées auprès de l'IANA.

...

3.2 Types de données élémentaires

Le type des objets utilisés dans les MIBs est limité à un sous ensemble des types disponibles dans ASN.1, mais suffisant pour exprimer les compteurs, les tables et les identificateurs que l'on trouve dans la mémoire d'un système d'exploitation.

INTEGER
De nombreux compteurs du système d'exploitation utilisent un tel type, comme par exemple ceux des statistiques extraites du noyau par la commande netstat -s -p ip.

OCTETS STRINGS
Pour définir une chaîne de caractères comme une suite de 0 ou plus octets de 8 bits.

NULL
Pour dire qu'il n'y a pas de valeur.

OBJECT IDENTIFIER
Pour définir les objets (OID).

SEQUENCE
Se rapproche de la notion de structure du langage C, autrement dit pour grouper plusieurs types dans un seul.

SEQUENCE-OF
Introduit la notion de vecteur.

Bien que ces types de données puissent ressembler à ceux de tel ou tel langage de programmation, leur représentation interne diffère très certainement puisqu'elle respecte les `` Basic Encoding RulesXII8 '', ou BER, afin d'être abolument portables sur tout type de plateforme. BER est une méthode d'encodage des valeurs pour tous les types définis par ASN.1, sous forme d'une chaîne d'octets et basée sur l'usage d'un triplet de valeurs (type, longueur, valeur) ou TLV.

Ainsi par exemple les chaînes de caractères ne sont pas terminées par un caractère null (Ascii 0) comme dans le langage C mais sont encodées directement avec leur longueur.

4 La MIB-2

la mib standard la plus courante est la MIB-2 définie dans la RFC 1213, c'est un sur-ensemble de la mib d'origine (MIB-I) définie dans la RFC 1156. Cette mib regroupe les compteurs les plus courants associés à une pile Arpa et d'autres comme ceux associés à la technologie Token-Ring, FDDI, Microsoft Lan Manager, DECnet, pour information.

La racine du sous-arbre concernée est clairement mgmt, c'est à dire .1.3.6.1.2 et le noeud concerné est mib-2(1) qui est l'OID défini ligne 15.

Puis viennent les 10 sous arbres décrits plus avant dans cette mib :

system(1)
Le groupe system fournit des informations d'ordre général sur le system lui-même, comme l'e-mail d'un contact, la valeur de l'`` uptime '' ou encore la location physique de l'appareil.

interfaces(2)
Le groupe interfaces regroupe toutes les informations sur les interfaces physiques ou virtuels présents, leur type, le fabricant, leur caractéristiques et enfin les statistiques d'usage.

at(3)
Ce groupe est une seule table de correspondances entre les adresses physiques et logiques. Pour une pile Arpa il s'agit de la table des adresses physique(MAC), telle qu'elle peut être extraite par la commande arp -an.

ip(4)
Le groupe ip contient toutes informations relatives à ce protocole (adresse, netmask), notamment la table de routage et tous les compteurs auxquels on peut accéder à l'aide de netstat -s -p ip.

icmp(5)
Le groupe icmp contient toutes les informations relatives à ce protocole. Le compteur du nombre d'`` echo request '' est par exemple accessible, tout comme il peut l'être avec un netstat -s -p icmp. Tous les messages sont associés à deux compteurs.

tcp(6)
Le groupe tcp contient toutes les informations relatives à ce protocole, par exemple celles que l'on peut obtenir à l'aide d'un netstat -s -p tcp plus d'autres comme la liste des connexions en cours avec leur état.

udp(7)
Le groupe udp regroupe toutes les informations relative à ce protocole (netstat -s p -udp). Gère également la liste des applications utilisant ce protocole.

egp(8)
Le groupe egp regroupe les informations relatives au protocole de routage `` Exterior Gateway Protocol ''.

transmission(10)
Le groupe transmission regroupe des interfaces déjà définies dans le Interfaces(2). mais selon d'autres critères, comme par exemple les protocoles supportés.

snmp(11)
Ce groupe donne des informations sur l'implémentation et l'exécution de SNMP lui-même, c'est à dire le nombre de message entrants, sortants, la répartition du type de requêtes reçues, émises.

Voici un extrait du début de cette mib :

% latex2html id marker 25763
\framebox[13cm][l]{
\parbox[l]{13cm}{
\begin{cen...
...mberline{\Roman{chapter}.02}{\hspace{1em}Extrait du d\'{e}but de la MIB-2}}
}
}

5 Protocole SNMP

le protocole SNMP est du type client/serveur classique. Un vocabulaire spécifique : le serveur est nommé `` Agent SNMP '' alors que le client est un `` Manager '' ou encore `` Network Management Software '' (NMS).

Le serveur (agent) écoute les requêtes du client (manager) sur le port 161 (UDP) et peut lui envoyer des messages d'exception (trap) sur son port 162.

Le choix du transport UDP est justifié par le trafic de petits datagrammes (la RFC 1157 `` An implementation of this protocol need not accept messages whose length exceeds 484 octets ''. Les besoins ont évolué mais ce choix initial perdure. Aux parties applicatives la tâche de faire le travail d'une couche de transport si besoin est (gestion d'un `` time-out '' et de la reémission des datagrammes manquants).

Le client (manager), interroge à son rythme les agents sur leur port 161 et écoute sur le port 162 (UDP) les éventuels messages d'exceptions envoyés par ces mêmes agents. Il faut noter que le protocole permet non seulement la lecture de variables mais aussi leur modification, ce qui pose des problèmes d'authentification et de confidentialité, non résolus avec SNMPv1 et SNMPv2. En effet, ce qui fait office de mécanisme d'authentification est une chaîne de caractères qui circule `` en clair '' sur le réseau, c'est la fameuse `` communauté '' dont la valeur par défaut sur les équipement est traditionnellement `` public ''.

La plupart du temps on se borne donc à l'aspect `` read only '' du protocole et seulement pour des échanges sur des réseaux qui devraient être protégés, par exemple cantonnés sur un vlan d'administration sur lequel ne circule aucun trafic applicatif inutile et surtout auquel aucun utilisateur standard n'accède.

\includegraphics{fig.snmp.03.ps} figure XII.03 -- Des agents et un Manager

5.1 Communauté

La communauté SNMP est une relation entre un agent et les stations d'administration qui l'interrogent. Cette unique chaîne de caractères définit à la fois l'authentification et le contrôle d'accès.

Il peut y avoir autant de communautés que d'agents, c'est au manager d'en conserver la liste.

Chaque message d'une station d'administration vers un agent comporte le nom de la communauté et donc permet à l'agent d'authentifier la source de la requête. Ce mode d'authentification n'est bien sûr plus adapté aux contraintes de sécurité qu'impose l'exploitation moderne des réseaux.

Le minimum pour exploiter malgré tout SNMPv2 est d'avoir au moins trois communautés différentes : une pour la lecture (GET), une pour l'écriture (SET) et une troisième pour les traps.


5.2 PDUs

Que ce soit pour des requêtes, des réponses aux requêtes, ou l'envoi d'un trap, SNMPv2 s'appuie sur un message dont le format est décrit succintement dans la figure 04 :

\includegraphics{fig.snmp.04.ps} figure XII.04 -- Format des messages SNMP

La partie standard de l'en-tête, comporte deux champs :

Version
Il s'agit de la version du protocole, 1, 2 ou 3.
Communauté
Une chaîne d'octets qui identifie la communauté, `` public '' par défaut...

Ensuite le message est composé d'une partie dont la longueur et le contenu sont assez variables, selon les opérations. C'est ce qu'on appelle le PDU (`` Protocol Data Unit ''). Il y en a sept possibles. En effet, le protocole de base (SNMPv1) prévoit cinq types de requêtes :

GetRequest
C'est une question du manager à l'agent. Une liste de couples (variable,valeur) est fournie. Les valeurs sont positionnées à unSpecified.

GetNextRequest
Cette requête est assez voisine de la précédente à ceci près que l'OID exact de la variable est déterminé en prenant le plus proche dans l'ordre lexicographique (d'ou le sens de `` next '').

SetRequest
C'est une demande du manager à l'agent pour positionner une certaine valeur à chacune des variables listées.

GetResponse
C'est la réponse à toutes les requêtes Get/Set qui précèdent.

Trap
Envoyé depuis l'agent vers le manager, associé à une liste de couples (variable,valeur). Il n'y a pas de réponse à un trap.

Auquels SNMPv2 en ajoute deux autres :

GetBulkRequest
Pour récupérer des données de grande taille, c'est à dire des morceaux complets de l'arbre. Les deux champs non repeaters et max repetitions servent alors à paramètrer les limites de ce transfert, dans la limite de la taille d'un message.

InformRequest
Sert à la communication entre managers. Une station d'administration envoie des données vers une autre station qui centralise les informations contenues dans la MIB `` manager to manager ''. Le message a le même format qu'un Get. Ce type de message est une sorte de mécanisme de traps entre managers (configuration d'alarmes, ensemble d'évênements choisis).

Ainsi le champ PDU type peut-il prendre l'une de ces sept valeurs et conduire à autant de PDUs différents, en taille et en signification.

Chaque champ de l'en-tête SNMP à une taille variable, selon l'implémentation des OIDs de la MIB.

PDU type
Valeur à prendre dans la liste get-request, get-next-request, get-bulk-request, response, set-request, inform-request, snmpv2-trap.

RequestID
C'est un numéro de requête, la réponse doit porter le même numéro que celui de la requête.

Error-status
Une valeur non nulle indique une erreur pendant le traitement de la requête.

Error-index
Quand error-status n'est pas nul, ce champ identifie le numéro d'ordre du couple (variable,valeur) qui pose problème. Le premier a 1 comme index.

(variable,valeur)
Il s'agit de couple, la variable est un OID et la valeur est celle associée à l'OID.


5.3 SNMPv3

6 L'outil NET-SNMP

D'abord nommé UCD-SNMP au début des années 1990 à l'université de Carnegie-Mellon, le projet s'est transformé en NET-SNMP au début des annéees 2000 et est maintenant la base de nombreux outils open-source ou non. Sa fiabilité est telle qu'un OS industriel tel que Solaris 10XII9n'hésite pas à le placer dans son `` core OS '' :

#solaris10$ /usr/sfw/sbin/snmpd -version 

NET-SNMP version:  5.0.9
Web:               http://www.net-snmp.org/
Email:             net-snmp-coders@lists.sourceforge.net

L'outil net-snmp est d'abord un outil d'administrateur système donc est essentiellement composé de commandes à taper dans un shell. Il existe d'autres approches plus graphiques, nous donnerons quelques pistes dans le paragraphe suivant.

Commandes pour interroger un agent :

snmpget, snmpgetnext, snmpwalk snmptable,snmpdelta

Commande pour positionner une valeur :

snmpset

Un daemon pour recevoir les notifications :

snmptrapd

Un agent :

snmpd

Nous allons mettre en \oeuvre quelques exemples d'usage de ces outils avec certains des OIDs de la MIB-2. On suppose que la machine localhost est accessible avec public comme valeur pour la communauté d'accès en mode lecture seule.


6.1 snmptranslate

Dans sa forme la plus simple cette commande prend un OID et affiche la valeur textuelle correspondante. Prenons le cas de l'uptime c'est à dire au sens de SNMP le nombre de centièmes de seconde écoulées depuis que la partie réseau a été initialisée. Son nom textuel est SNMPv2-MIB::sysUpTime.

$ snmptranslate -On SNMPv2-MIB::sysUpTime
.1.3.6.1.2.1.1.3

$ snmptranslate -Of SNMPv2-MIB::sysUpTime.0
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance

On peut également utiliser une expression régulière :

$ snmptranslate -TB sys.*Time
SNMPv2-MIB::sysORUpTime
SNMPv2-MIB::sysUpTime
DISMAN-EVENT-MIB::sysUpTimeInstance
HOST-RESOURCES-MIB::hrSystemUptime

Mais aussi l'utiliser pour obtenir plus d'information sur l'OID :

$ snmptranslate -On -Td SNMPv2-MIB::sysUpTime
.1.3.6.1.2.1.1.3
sysUpTime OBJECT-TYPE
  -- FROM	SNMPv2-MIB, RFC1213-MIB
  SYNTAX	TimeTicks
  MAX-ACCESS	read-only
  STATUS	current
  DESCRIPTION	"The time (in hundredths of a second) since the
            network management portion of the system was last
            re-initialized."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 3 }

$ snmptranslate -IR -Tp SNMPv2-MIB::system   
+--system(1)
   |
   +-- -R-- String    sysDescr(1)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -R-- ObjID     sysObjectID(2)
   +-- -R-- TimeTicks sysUpTime(3)
   |  |
   |  +--sysUpTimeInstance(0)
   |
   +-- -RW- String    sysContact(4)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -RW- String    sysName(5)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -RW- String    sysLocation(6)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -R-- INTEGER   sysServices(7)
   |        Range: 0..127
   +-- -R-- TimeTicks sysORLastChange(8)
   |        Textual Convention: TimeStamp
   |
   +--sysORTable(9)
      |
      +--sysOREntry(1)
         |  Index: sysORIndex
         |
         +-- ---- INTEGER   sysORIndex(1)
         |        Range: 1..2147483647
         +-- -R-- ObjID     sysORID(2)
         +-- -R-- String    sysORDescr(3)
         |        Textual Convention: DisplayString
         |        Size: 0..255
         +-- -R-- TimeTicks sysORUpTime(4)
                  Textual Convention: TimeStamp

Le lecteur curieux d'en savoir plus pourra essayer la commande snmptranslate -IR -Tp ! L'extrait suivant de la MIB montre le début de la description du groupe system.

% latex2html id marker 26029
\framebox[13cm][l]{
\parbox[l]{13cm}{
\begin{cen...
...ace{1em}Extrait de la MIB-2 concernant le d\'{e}but du goupe \lq\lq ~system~''}}
}
}


6.2 snmpget

Cette commande correspond à l'opération la plus élémentaire du protocole SNMP, aller chercher l'information relative à un OID précis sur un agent.

$ snmpget -v 2c -c public localhost SysUpTimeInstance  
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (33310293) 3 days, 20:31:42.93

$ snmpget -v 2c -c public localhost SNMPv2-MIB::sysLocation    
SNMPv2-MIB::sysLocation = No Such Instance currently exists at this OID

Une erreur courante avec cette commande est d'oublier l'index (`` instance subidentifier '') de la donnée demandée. Le cas le plus courant est pour les données de type scalaire, il n'y a qu'une seule valeur alors il ne semble pas nécessaire de préciser un index. Cet index est toujours un simple zéro (0) comme l'exemple ci-dessous le montre.

$ snmpget -v 2c -c public localhost SNMPv2-MIB::sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: S110

Ce point de détail technique s'avère vite lassant, c'est pourquoi on utilise plus fréquemment la commande suivante...


6.3 snmpgetnext

$ snmpgetnext -v 2c -c public localhost SNMPv2-MIB::sysUpTime.0  
SNMPv2-MIB::sysContact.0 = STRING: Francois Laissus

La commande renvoie la valeur associée à l'OID (ou aux OIDs) suivant, ainsi on a l'impression que l'exemple ci-dessus est difficilement utilisable en pratique ! En fait il n'en est rien et l'exemple suivant devrait dissiper cette fausse impression :

$ snmpgetnext -v 2c -c public localhost SNMPv2-MIB::sysUpTime  
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (34853433) 4 days, 0:48:54.33

Un usage très employé de cette commande est de l'utiliser avec une OID incomplète, par exemple sans l'index (`` instance subidentifier '') et l'agent en détermine la prochaîne instance complète associée à sa valeur. C'est une sorte de mécanisme rudimentaire de complétion.

6.4 snmpwalk

Cette commande effectue des requête de type get-next pour explorer toute l'arborescence des sous-arbres liés à un OID. Par exemple :

$ snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.5   
IP-MIB::icmpInMsgs.0 = Counter32: 205413
IP-MIB::icmpInErrors.0 = Counter32: 0
IP-MIB::icmpInDestUnreachs.0 = Counter32: 205039
IP-MIB::icmpInTimeExcds.0 = Counter32: 43
IP-MIB::icmpInParmProbs.0 = Counter32: 0
IP-MIB::icmpInSrcQuenchs.0 = Counter32: 0
IP-MIB::icmpInRedirects.0 = Counter32: 0
IP-MIB::icmpOutDestUnreachs.0 = Counter32: 203947
...

Permet d'accéder d'un seul coup à toutes les compteurs relatifs à SNMP (la sortie a été tronquée). Le lecteur pourra essayer l'OID 1.3.6 en argument...


6.5 snmptable

Comme son nom le suggère, cette commande est plutôt utilisée pour manipuler des tables. Ici il s'agit de la liste des interfaces et de leurs compteurs associés.

$ snmptable -v 2c -c public -Os -Cw 80 localhost ifTable   
SNMP table: ifTable

 ifIndex ifDescr           ifType ifMtu    ifSpeed  ifPhysAddress ifAdminStatus
       1     em0   ethernetCsmacd  1500 1000000000 0:6:5b:f:5a:31            up
       2     em1   ethernetCsmacd  1500 1000000000 0:6:5b:f:5a:32          down
       3     lo0 softwareLoopback 16384          0                           up

SNMP table ifTable, part 2
 ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts ifInDiscards
           up 0:0:00:00.00 2318958978    2767895021              2            0
         down 0:0:00:00.00          0             0              0            0
           up 0:0:00:00.00   90441064        717640              0            0

SNMP table ifTable, part 3
 ifInErrors ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts
          0                 0  2137908126     2767886776               0
          0                 0           0              0               0
          0                 0    90441687         717644               0

SNMP table ifTable, part 4
 ifOutDiscards ifOutErrors ifOutQLen ifSpecific
             0           0         ?          ?
             0           0         ?          ?
             0           0         ?          ?


6.6 snmpset

Pour changer la valeur d'une donnée, donc déconseillé en SNMPv2.

6.7 Approche graphique

Ce premier exemple graphique montre un outil open-source nommé mbrowseXII10simple et bien commode pour interroger n'importe quel agent à partir d'un interface graphique assez intuitif.

\includegraphics{mbrowse.eps} figure XII.05 -- Exemple d'interrogation d'un agent avec l'outil mbrowse

Dans un deuxième exemple, il s'agit d'extraire le contenu de la table ifTable, comme nous avons pu le faire précédemment avec snmptable, ce coup-ci avec la commande snmpwalk, puis de traiter graphiquement le résultat.

$ snmpwalk -c public -v2c gw ifTable
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2   
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifDescr.1 = STRING: fxp0
IF-MIB::ifDescr.2 = STRING: plip0
IF-MIB::ifDescr.3 = STRING: lo0
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: para(34)
IF-MIB::ifType.3 = INTEGER: softwareLoopback(24)
IF-MIB::ifMtu.1 = INTEGER: 1500
IF-MIB::ifMtu.2 = INTEGER: 1500
IF-MIB::ifMtu.3 = INTEGER: 16384
IF-MIB::ifSpeed.1 = Gauge32: 100000000
IF-MIB::ifSpeed.2 = Gauge32: 0
IF-MIB::ifSpeed.3 = Gauge32: 0
IF-MIB::ifPhysAddress.1 = STRING: 0:2:b3:3d:22:5
IF-MIB::ifPhysAddress.2 = STRING:
IF-MIB::ifPhysAddress.3 = STRING:
...
IF-MIB::ifInOctets.1 = Counter32: 29017357
...
IF-MIB::ifOutOctets.1 = Counter32: 3117625
...

Où l'on s'apperçoit que cette machine a trois interfaces, nommées respectivement fxp0, plip0 et lo0. On voit également que le mtu de l'interface de loopback (lo0) est de 16384 octets et que l'interface fxp0 est le seul qui travaille réellement au vu des compteurs qui lui sont associés, 29017357 octets en entrée et 3117625 en sortie, depuis que la machine est en route (voir sysUpTime).

Bien entendu cette approche manuelle est trop lourde pour être utilisée telle que pour surveiller un réseau ! Il est indispensable d'utiliser des outils capables de faire la synthèse de tous ces compteurs, par exemple pour les présenter sous forme graphique. L'outil mrtgXII11est capable de produire très simplement un tel graphique avec jusqu'à une année d'historique pour n'importe quel interface :

\includegraphics{mrtg.eps} figure XII.06 -- Synthèse graphique des compteurs ifInOctets et ifOutOctets sur 24h

Il existe d'autres MIBs, notamment applicatives comme celle définie par la RFC 1611 qui concerne le serveur de noms et celle définie par la RFC 2790 qui concernes les ressources de l'hôte lui-même (espace disque, charge...) et que l'on peut surveiller également avec l'outil mrtg. Il est ainsi aisé de faire des graphiques d'usage de la mémoire, des disques, de la charge de la machine, etc...

La page précédente est un exemple d'écran de surveillance d'un réseau aujourd'hui complètement démantelé, et obtenu à l'aide de l'outil open-source tkined !

7 Glossaire des acronymes SNMP

Agent
C'est le logiciel embarqué dans l'hôte réseau, quel qu'il soit. Il fonctionne en mode serveur et est à l'écoute en UDP sur le port 161 (snmp) Il est également susceptible d'envoyer des `` traps '' vers le port 162 du ou des manager(s).

ASN1
`` Abstract Syntax Notation One '' est une norme internationale XII12 dont la vocation première est la spécification de données utilisées dans les protocoles de communication.

BER
`` Basic Encoding Rules '' Méthode d'encodage des valeurs pour tous les types définis dans ASN.1.

Manager
Le logiciel de supervision. Il interroge les agents dans une relation de type client - serveur dont il assume la partie cliente. Le manager est destinataire des `` traps '', qu'il réceptionne en UDP sur le port 162 (snmptrap).

MIB
`` Management Information Base ''. C'est la description de tous les composants logiciels ou matériels surveillés par l'agent. Chaque composant est désigné par son OID. La MIB est écrite à l'aide du langage ASN.1 et selon une SMI bien précise. C'est un arbre, dont les n\oeu ds et les feuilles sont repérés de manière unique par un chiffre.

NMA
`` Network Management Application ''. Est une autre manière, non spécifique à SNMP, de désigner le manager.

NME
`` Network Management Entity ''. Est une autre manière, non spécifique à SNMP, de désigner l'agent.

NMS
`` Network Management Software ''. Synonyme de NMA.

OID
`` Object IDentifier ''. C'est la désignation unique d'un objet dans la structure en arbre de la MIB.

PDU
`` Protocol Data Unit ''. Il s'agit des paquets réseau, structurés selon le détail du protocol applicatif SNMP.

RMON
`` Remote Network Monitoring ''. Il s'agit d'un agent particulier dont l'objet est la surveillance du réseau lui même et non un hôte en particulier. On désigne souvent ces agents sous la terminologie de sonde RMON.

SMI
`` Structure of Management Information ''. C'est la description du contenu et du formatage des données d'une MIB.

SNMP
`` Simple Network Management Protocol ''. C'est le nom du protocole réseau qui sert à interroger les agents/sondes RMON.

Trap
C'est un message d'exception envoyé depuis l'agent vers le port 162 du (des) manager(s).

8 Liens & Bibliographie

Quelques RFCs minimales et en nombre non exhaustif !

RFC 1115, 1156, 1157, 1213, 1901 à 1908, 3411 à 3418

Des urls :

Quelques ouvrages de référence :

  • William Stalling -- `` SNMPv1, SNMPv2, SNMPv3 and RMON 1 and 2 '' (third Edition) -- Addison-Wesley 1999.

  • Douglas R. Mauro and Kevin J. Schmidt -- `` Essential SNMP '' -- O'Reilly 2001.

  • W. Richard Stevens -- `` TCP/IP Illustrated, Volume 1 - The protocols '' -- Addison-Wesley


next up previous contents index
Next: D Sockets BSD et Up: C Protocoles applicatifs Previous: XI Courrier électronique   Contents   Index
Fran├žois Laissus 2009-02-27