IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Cours d'introduction à TCP/IP


précédentsommairesuivant

12. Instrumentalisation de réseaux avec SNMP

12-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 !

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

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

12-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 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.
Image non disponible
figure XI.01 - Agent et Manager dans une relation de type client-serveur

12-1-4. Historique du protocole SNMP

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

12-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 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 à 232 - 1. Pour être indépendant du formalisme local de la plateforme (problématique de la couche 6 OSI).

12-1-6. Différentes versions

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

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 MIB. C'est une sorte de métamodèle de données. Par exemple pour définir une adresse physique (MAC)

 
Sélectionnez
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.

12-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 trois 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 !

12-2. SMI - Structure of Management Information

La RFC 1155 fondatrice pose le cadre de travail à l'intérieur duquel on peut bâtir les MIB. En effet, la SMI précise 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 atteint 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 sont décrites dans un document qui est une MIB.

12-3. MIB - Management Information Base

Les MIB sont des fichiers au format ASCII qui décrivent dans le détail chacune des ressources à quantifier. Ces ressources sont des éléments simples (scalaires 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.1(156) 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.

 
Sélectionnez
-- the TCP Connection table

-- The TCP connection table contains information about this
-- entity's existing TCP connections.

tcpConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table containing TCP connection-specific
information."
::= { tcp 13 }

tcpConnEntry OBJECT-TYPE
SYNTAX TcpConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a particular current TCP
connection. An object of this type is transient,
in that it ceases to exist when (or soon after)
the connection makes the transition to the CLOSED
state."
INDEX { tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort }
::= { tcpConnTable 1 }

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

  • Le nom de l'objet tcpConnTable qui balise le début de la définition ;
  • (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 ;
  • (ACCESS) L'accès (lecture, écriture, lecture-écriture, pas accessible). Ici on ne peut ni lire ni écrire dans cet objet ;
  • (STATUS) L'état de l'objet, valeur à prendre dans obligatoire (MANDATORY), obsolète ou optionnel ;
  • (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 MIB (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.

12-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.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 ».

Image non disponible
figure XI.02 - La racine de l'arbre des OID

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

12-3-2. Types de données élémentaires

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.

12-4. La MIB-2

La MIB standard la plus courante est la MIB-2 définie dans la RFC 1213, c'est un surensemble 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 nœud 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 système 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 virtuelles présents, leur type, le fabricant, leurs 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 physiques (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 relatives à 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, 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 messages entrants, sortants, la répartition du type de requêtes reçues, émises.

Voici un extrait du début de cette MIB :

 
Sélectionnez
RFC1213-MIB DEFINITIONS ::= BEGIN

IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge,
TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212;

-- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in [14];

-- MIB-II (same prefix as MIB-I)

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

-- textual conventions

DisplayString ::=
OCTET STRING
-- This data type is used to model textual information taken
-- from the NVT ASCII character set. By convention, objects
-- with this syntax are declared as having

--
-- SIZE (0..255)

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.

-- groups in MIB-II

system OBJECT IDENTIFIER ::= { mib-2 1 }

interfaces OBJECT IDENTIFIER ::= { mib-2 2 }

at OBJECT IDENTIFIER ::= { mib-2 3 }

IP OBJECT IDENTIFIER ::= { mib-2 4 }

icmp OBJECT IDENTIFIER ::= { mib-2 5 }

tcp OBJECT IDENTIFIER ::= { mib-2 6 }

udp OBJECT IDENTIFIER ::= { mib-2 7 }

egp OBJECT IDENTIFIER ::= { mib-2 8 }

-- historical (some say hysterical)
-- cmot OBJECT IDENTIFIER ::= { mib-2 9 }

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

snmp OBJECT IDENTIFIER ::= { mib-2 11 }

12-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 est de faire le travail d'une couche de transport si besoin est (gestion d'un « time-out » et de la réé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 équipements 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.

Image non disponible
figure XI.03 - Des agents et un Manager

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

12-5-2. PDU

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 :

Image non disponible
figure XI.04 - Format des messages SNMP

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.

12-5-3. SNMPv3

12-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ées 2000 et est maintenant la base de nombreux outils open source ou non. Sa fiabilité est telle qu'un OS industriel tel que Solaris 10(162) n'hésite pas à le placer dans son « core OS » :

 
Sélectionnez
#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 œuvre quelques exemples d'usage de ces outils avec certains des OID 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.

12-6-1. s nmptranslate

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.

 
Sélectionnez
$ 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 :

 
Sélectionnez
$ 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 :

 
Sélectionnez
$ 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.

 
Sélectionnez
-- 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 }

12-6-2. s nmpget

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.

 
Sélectionnez
$ 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.

 
Sélectionnez
$ 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...

12-6-3. s nmpgetnext

 
Sélectionnez
$ 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 :

 
Sélectionnez
$ 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.

12-6-4. s nmpwalk

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

 
Sélectionnez
$ 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...

12-6-5. s nmptable

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.

 
Sélectionnez
$ 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 ? ?

12-6-6. s nmpset

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

12-6-7. Approche graphique

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.

Image non disponible
figure XI.05 - Exemple d'interrogation d'un agent avec l'outil mbrowse

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 :

 
Sélectionnez
$ 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.

Image non disponible
figure XI.06 - Synthèse graphique des compteurs ifInOctets et ifOutOctets sur 24h

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.

Image non disponible
figure XI.07

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 !

12-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 (165) 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œuds 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 protocole 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).

12-8. Liens & bibliographie

Quelques RFC minimales et en nombre non exhaustif !

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

Des URL :

  • Pour ASN.1 :
    • http://www.asn1.org/ ;
    • http://asn1.elibel.tm.fr/ ;
    • http://www.itu.int/ITU-T/asn1/.
  • Pour SNMP lui-même :
    • http://www.snmplink.org/ ;
    • http://www.faqs.org/faqs/snmp-faq/part1/index.html ;
    • http://www.faqs.org/faqs/snmp-faq/part2/index.html ;
    • http://www.net-snmp.org/wiki/index.php/Tutorials ;
    • http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNMP.
  • Quelques outils en vrac :
    • Net-Snmp http://net-snmp.sourceforge.net/ ;
    • Mrtg http://oss.œtiker.ch/mrtg/ ;
    • Scotty http://wwwhome.cs.utwente.nl/~schœnw/scotty/ ;
    • Mbrowse http://www.kill-9.org/mbrowse/.

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.

précédentsommairesuivant
Site officiel http://www-nrg.ee.lbl.gov/
http://www.ntop.org/
développé et standardisé par le CCITT (X.208) et l'ISO (ISO 8824)
Notez la présence du « 0 » en fin de chaîne qui ne fait pas partie du nommage, mais est un artifice à l'interrogation pour indiquer qu'il s'agit d'une feuille de l'arbre et non par exemple la base d'un tableau
International Organization for Standardisation
International Telegraph and Telephone Consultative Committee
Internet Assigned Numbers Authority
développé et standardisé par le CCITT (X.209) et l'ISO (ISO 8825)
http://www.sun.com
http://www.kill-9.org/mbrowse/
http://oss.œtiker.ch/mrtg/
http ://asn1.elibel.tm.fr/fr/

Copyright © 2009 François Laissus. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.