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 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...
L'aspect confidentiel de ces données doit être pris en compte.
Les logs (syslog) sont un point important de
la gestion de la sécurité.
uvre et de la configuration de
tous les équipements qui inter-agissent sur le réseau.
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 :
Au moins un nud 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 ![[*]](crossref.png)
) , 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 :
Avantages :
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 :
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).
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
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).
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 :
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.
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 :
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
}
}](img126.png)
Ce petit exemple montre que l'identification d'un objet repose sur cinq champs :
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.
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 ''.
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 !
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.
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.
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 :
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}}
}
}](img128.png)
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.
figure XII.03 -- Des agents et un Manager
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.
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 :
figure XII.04 -- Format des messages SNMP
La partie standard de l'en-tête, comporte deux champs :
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 :
Auquels SNMPv2 en ajoute deux autres :
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.
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 :
Un daemon pour recevoir les notifications :
Un agent :
Nous allons mettre en uvre 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.
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~''}}
}
}](img131.png)
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...
$ 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...
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 ? ?
Pour changer la valeur d'une donnée, donc déconseillé en SNMPv2.
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.
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 :
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
u ds
et les feuilles sont repérés de manière unique par un chiffre.
Quelques RFCs minimales et en nombre non exhaustif !
Des urls :
| http://www.asn1.org/ |
| http://asn1.elibel.tm.fr/ |
| http://www.itu.int/ITU-T/asn1/ |
| Net-Snmp | http://net-snmp.sourceforge.net/ |
| Mrtg | http://oss.oetiker.ch/mrtg/ |
| Scotty | http://wwwhome.cs.utwente.nl/~schoenw/scotty/ |
| Mbrowse | http://www.kill-9.org/mbrowse/ |
Quelques ouvrages de référence :
Next: D Sockets BSD et
Up: C Protocoles applicatifs
Previous: XI Courrier électronique
Contents
Index
François Laissus
2009-02-27