Les données décrites et transportées par ce protocole utilisent un nommage hiérarchique. Certaines branches sont normalisées et décrivent donc des mesures et des unités connues, d'autres branches sont maintenues par des entreprises pour leur besoins propre (CISCO, etc). L'ensemble du catalogue des informations gérables via SNMP s'appelle la MIB (Management Information Base).

Techniquement, le nommage d'une information précise dans la hiérachie d'une MIB se fait à l'aide d'une notation sous forme d'identifiants séparés par des points (un chemin hiérarchique), et qui commencent par un “1” (la racine, non utilisée). Cette notation numérique étant inutile pour les humains, sont maintenues des tables de correspondance textuelle pour nommer l'information.

Si par exemple on veut obtenir l'information standard SNMPv2-MIB::sysDescr.0, l'identifiant numérique peut être obtenu ainsi :

$ snmptranslate SNMPv2-MIB::sysDescr.0
.1.3.6.1.2.1.1.1.0

Chaque information est stockées sous forme de valeurs de type simples :

• Un entier: typiquement 32 bits signés (par défaut) ou non signé (type compteur) - SNMP v2 apporte les compteurs 64bits
• Les jauges: une valeur entière accompagnée de ses minima et maxima atteint depuis leur dernière réinitialisation
• Les adresses: au sens réseau (attention seulement 32bits pour SNMP v1)
• Les chaînes: pour une information textuelle
• Les temps: exprimés comme entiers en 100ème de secondes
• Les opaques: transportent une information spécifique à une application

SNMP v1 n'implémente pas de modèle de sécurité particulier, chaque implémentation d'agent pouvant fournir un sytème personnalisé à cet effet (accès par IP, etc).

SNMP v2 apporte une gestion des droits de type “rôle” qui est considérée très complexe et n'a quasiment jamais été utilisée.

SNMP v2c base l'authentification sur un mécanisme plus simple, la “communauté” (qui peut être pensée comme un “login”). On peut définir des ACLs assez simple en se basant sur l'IP de la console de mangament et la communauté utilisée.

SNMP v3 apporte des fonctions d'authentification et de cryptage avancées. Il n'est pas largement utilisé, SNMP étant majoritairement utilisé pour du monitoring non sensible (quantité de traffic réseau, etc).

En pratique on utilise très souvent le protocole 1 ou 2c, il suffit alors de préciser le nom de la commuanuté à chaque accès. Ce sera traditionnellement les options -v1 -cpublic ou -v2c -cpublic pour la plupart des outils en ligne de commande.

Pour demander une information précise, si l'on connaît sa référence MIB :

$ snmpget -v1 -cpublic myserv.net SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux myserv 2.4.33.3-8 #1 Thu Oct 12 23:29:43 CEST 2006 i586

Pour demander globalement le parcours (en profondeur) de l'arbre complet d'information renseigné par l'agent :

$ snmpwalk -v1 -cpublic myserv.net

$ snmpwalk -v1 -cpublic myserv.net HOST-RESOURCES-MIB::hrDeviceDescr
HOST-RESOURCES-MIB::hrDeviceDescr.768 = STRING: Intel(R) Celeron(R) CPU 2.66GHz
HOST-RESOURCES-MIB::hrDeviceDescr.1025 = STRING: network interface lo
HOST-RESOURCES-MIB::hrDeviceDescr.1027 = STRING: network interface eth0
HOST-RESOURCES-MIB::hrDeviceDescr.1028 = STRING: network interface eth1
HOST-RESOURCES-MIB::hrDeviceDescr.1568 = STRING: RAID disk (/dev/md0)
HOST-RESOURCES-MIB::hrDeviceDescr.1569 = STRING: RAID disk (/dev/md1)
HOST-RESOURCES-MIB::hrDeviceDescr.1570 = STRING: RAID disk (/dev/md2)

Dans le modèle classique client/serveur SNMP, l'outil de monitoring doit régulièrement consulter les agents pour relever les différentes mesures, les enregistrer et éventuellement les interpréter pour déclencher diverses alertes (disque plein, traffic trop important, etc).

SNMP prévoit un chemin inverse: un agent peut spontanément et immédiatement remonter une information sans qu'il soit sollicité (parce qu'il décide que c'est important), appelé trap (SNMP v1) ou notification (v2, v3).

Il faut alors que l'outil de monitoring soit équipé d'un outil pour recevoir ces notifications et réagir en conséquence. Il s'agit en pratique d'un serveur (snmptrapd) qui écoute sur le port voisin UDP 162.

Si la pose des agents sur les noeuds du réseau (serveurs, routeurs, switche, etc.) doit être une pratique assez automatique et continue, rassembler et gérer l'information générée par l'ensemble des équipements peu devenir une tâche complexe et surtout fournir trop d'information pour qu'elle soit facilement exploitable.

Il existe des outils traditionnels qui interrogent automatiquement et enregistrent les informations fournies par un ensemble de noeuds réseau à surveiller. La présentation est souvent synthétique et sous forme graphique, afin d'avoir une vue temporelle large de l'activité d'un réseau.

Si MRTG (Multi-Router Traffic Grapher) reste un outil très populaire, il tend à être remplacé par des outils de plus haut niveau et conviviaux comme Cacti.

L'installation, la configuration et la maintenance d'un outil de gestion tel que Cacti est une tâche aisée.