Cours d'introduction à TCP/IP

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éseau 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 œuvre et de la configuration de tous les équipements qui interagissent 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 :

• Quel est le niveau actuel d'utilisation ?
• Y a-t-il un (des) trafic(s) excessif(s) ?
• Le débit nominal est-il réduit à une valeur inacceptable ?
• Où sont les goulots d'étranglement ?
• 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.

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 une interface la 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, quelles que soient 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 :
  • transmission des données collectées ;
  • changement d'un paramètre de configuration ;
  • fourniture de statuts de composants logiciels ou matériels ;
  • génération de tests.
• Envoie des messages d'alerte (trap) en cas de détection d'événements exceptionnels :
  • transmission des données collectées ;
  • changement d'un paramètre de configuration ;
  • fourniture de statuts de composants logiciels ou matériels ;
  • génération de tests.

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

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 interagissent, stations, serveurs, éléments de routage ou de commutation ou encore boites noires. Leur nombre grandissant sur les LAN (des machines en clusters par exemple) 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), même concentrés, filtrés, et triés ne délivrent qu'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, arpwatch(154) 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 Wi-Fi 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éseau 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.

Avant 1987/1988 il n'y a rien d'autre qu'ICMP pour recevoir de l'info entre 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 côté 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 RFC 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).

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 interopérables, les variables sont collectionnées selon une représentation arborescente très structurée et standardisée, ce sont les MIB (« 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 élémentaires. 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éseau prévoient des MIB 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 Wi-Fi 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 une interface utilisateur conviviale.

La figure XI.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ément plus délicate que celle de l'agent parce qu'il nécessite une adaptation au réseau local qui est toujours un cas particulier. Il existe de nombreux logiciels HP Open- View, 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).

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 ntop(155).

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 appelée SMI « Structure of Management Information », définie par la RFC 1155, qui dit par exemple qu'un entier positif va de 0 à 2³² - 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 protocole 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 raisons « 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 « Communitybased SNMPv2 ») définie par les RFC 1901 à 1908 tente de combler. Rien n'est malheureusement fait côté sécurité dans cette deuxième version, mais des améliorations sont apportées aux MIB 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).

12-1-6-1. Trois composantes pour SNMP▲

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.

12-1-6-2. Conclusion▲

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.0(157). 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, parcourt dans l'arbre de la racine jusqu'à la feuille terminale. Chaque nœud traversé est étiqueté par un nombre et un bref texte descriptif. Bien entendu l'unicité de l'étiquetage à un niveau donné de l'arbre est primordiale 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 nœuds du premier niveau de l'arbre : l'ISO(158) et le CCITT(159), le troisième nœud s'explique par une entité mixte des deux et nommée « joint-iso-ccitt ».

Sous le nœud de l'ISO un sous-arbre est prévu pour d'autres organisations, l'une d'elles 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 voilà pourquoi les OID standards sont placés sous le nœud nommé mib-2(1) et que le préfixe le plus commun est .1.3.6.1.2.1, indices des nœuds 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ée à l'IANA(160) et est donc régit par des RFC !
• 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 MIB, après s'être enregistrées auprès de l'IANA.
• ...

Le type des objets utilisés dans les MIB 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, 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 Rules(161) », ou BER, afin d'être absolument 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.

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 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 succinctement dans la figure 04 :

La partie standard de l'entê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'où 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.

Auxquels 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 prendre l'une de ces sept valeurs et conduire à autant de PDU différents, en taille et en signification.

Chaque champ de l'entête SNMP a une taille variable, selon l'implémentation des OID 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.

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és 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.

-- the System group

-- Implementation of the System group is mandatory for all
-- systems. If an agent is not configured to have a value
-- for any of these variables, a string of length 0 is
-- returned.

sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the entity. This value
should include the full name and version
identification of the system's hardware type,
software operating-system, and networking
software. It is mandatory that this only contain
printable ASCII characters."
::= { system 1 }

sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the
network management subsystem contained in the
entity. This value is allocated within the SMI
enterprises subtree (1.3.6.1.4.1) and provides an
easy and unambiguous means for determining ?what
kind of box' is being managed. For example, if
vendor ?Flintstones, Inc.' was assigned the
subtree 1.3.6.1.4.1.4242, it could assign the
identifier 1.3.6.1.4.1.4242.1.1 to its ?Fred
Router'."
::= { system 2 }

sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The time (in hundredths of a second) since the
network management portion of the system was last
re-initialized."
::= { system 3 }

sysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person
for this managed node, together with information
on how to contact this person."
::= { system 4 }

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 OID) 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 prochaine instance complète associée à sa valeur. C'est une sorte de mécanisme rudimentaire de complétion.

Cette commande effectue des requêtes 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é mbrowse(163) simple et bien commode pour interroger n'importe quel agent à partir d'une interface graphique assez intuitive.

Où l'on s'aperç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 la seule 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 mrtg(164) est capable de produire très simplement un tel graphique avec jusqu'à une année d'historique pour n'importe quelle interface :

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

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.

Il existe d'autres MIB, 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 concerne 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 !