Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 215snmp:40_les_mibs [le 10/07/2010 à 13:17] – prof
+++ 215snmp:40_les_mibs [le 30/06/2018 à 15:42] (Version actuelle) – prof
@@ Ligne 22: / Ligne 22: @@
 Tout constructeur d'un matériel spécifique peut développer une MIB pour ce matériel, cette MIB devra prendre sa place dans l'arbre, sans piétiner celle des voisins, et c'est le rôle de l'IETF ou de l'IANA d'attribuer un point de branchement pour le matériel de ce constructeur.
-Une MIB ,'étant finalement qu'une branche, elle peut nécessiter l'usage de d'autres MIBS pour se rattacher à l'arbre. Prenons un exemple. HP peut développer une MIB générique à tous ses matériels qui viendrait se greffer sur la branche ''private.enterprise'', puis des MIBs spécifiques à chaque matériel qui viendraient elles-mêmes se développer dans la MIB générique de HP.
+Une MIB n'étant finalement qu'une branche, elle peut nécessiter l'usage de d'autres MIBS pour se rattacher à l'arbre. Prenons un exemple. HP peut développer une MIB générique à tous ses matériels qui viendrait se greffer sur la branche ''private.enterprise'', puis des MIBs spécifiques à chaque matériel qui viendraient elles-mêmes se développer dans la MIB générique de HP.
 ==== Illustration ====
 Sur l'arborescence en illustration, nous constatons que le sommet est représenté par un point originel, puisque chaque embranchement dispose d'un nom (iso, org, internet...) et aussi d'un numéro (1, 3, 6, 1...).
@@ Ligne 93: / Ligne 93: @@
 Un switch est tout de même un objet un peu particulier et ce que nous avons vu jusqu'ici va atteindre ses limites.
-Ainsi, au bout de la branche ''.1.3.6.1.2.1.17.1.2'', nous devons normalement trouver le nombre de ports dont dispose le switch (il faut être in initié pour le savoir). Le bout de la branche devant obligatoirement se terminer par un ''0'', nous l'avons remarqué lors des démonstrations précédentes, posons la question avec cette fois-ci un ''snmpget'', qui ne sait extraire qu'une seule information, et qui doit donc être obligatoirement posée en indiquant le bout de la branche :
+Ainsi, au bout de la branche ''.1.3.6.1.2.1.17.1.2'', nous devons normalement trouver le nombre de ports dont dispose le switch (il faut être un initié pour le savoir). Le bout de la branche devant obligatoirement se terminer par un ''0'', nous l'avons remarqué lors des démonstrations précédentes, posons la question avec cette fois-ci un ''snmpget'', qui ne sait extraire qu'une seule information, et qui doit donc être obligatoirement posée en indiquant le bout de la branche :
   $ snmpget -Of -c public -v 2c 172.16.252.2 .1.3.6.1.2.1.17.1.2.0
   .iso.org.dod.internet.mgmt.mib-2.17.1.2.0 = INTEGER: 50
@@ Ligne 109: / Ligne 109: @@
 autrement dit, il manque des pages dans le dictionnaire, ''snmpget'' sait traduire dans la suite ''.1.3.6.1.2.1.17.1.2.0'' la seule partie ''.1.3.6.1.2.1'' et pas la suite ''17.1.2'', c'est pourquoi cette suite reste numérique dans la réponse. La bonne nouvelle dans la mauvaise nouvelle, c'est qu'il reste possible d'interroger un agent SNMP sur une information, même si l'on ne dispose pas des pages manquantes relatives à la définition de cette information, du moment que l'on connait le chemin numérique pour y accéder.
-Nous allons tout de même demander à notre ''snmpget'' d'intégrer ces pages qui manquent (cette MIB) que nous avons récupérée grâce au paquet ''snmp-mibs-downloader'' que nous avons installé avec un ''aptitude install'' des familles et qui nous a mis tout ça dans ''/usr/share/mibs'' :
+Nous allons tout de même demander à notre ''snmpget'' d'intégrer ces pages qui manquent (cette MIB((appelée ''BRIDGE-MIB'' et définie dans la [[http://www.faqs.org/rfcs/rfc1493.html|rfc 1493]]))), que nous avons récupérée grâce au paquet ''snmp-mibs-downloader'' que nous avons installé avec un ''aptitude install'' des familles et qui nous a mis tout ça dans ''/usr/share/mibs'' :
 <html><pre class="code">
-snmpget <span class="bhly">-m /usr/share/mibs/ietf/BRIDGE-MIB</span> -Of -c public -v 2c 172.16.252.2 .1.3.6.1.2.1.17.1.2.0
+snmpget <span class="bhly">-m +/usr/share/mibs/ietf/BRIDGE-MIB</span> -Of -c public -v 2c 172.16.252.2 .1.3.6.1.2.1.17.1.2.0
 .iso.org.dod.internet.mgmt.mib-2.<span class="hly">dot1dBridge.dot1dBase.dot1dBaseNumPorts</span>.0 = INTEGER: 50 ports
 </pre></html>
@@ Ligne 132: / Ligne 132: @@
 il s'agit d'un switch DGS-3024, modèle notoirement proposé par D-LINK.
-  $ snmpget -m /usr/share/mibs/ietf/BRIDGE-MIB -On -c public -v 2c 172.16.252.4 .iso.org.dod.internet.mgmt.mib-2.dot1dBridge.dot1dBase.dot1dBaseNumPorts.0
+  $ snmpget -m +/usr/share/mibs/ietf/BRIDGE-MIB -On -c public -v 2c 172.16.252.4 .iso.org.dod.internet.mgmt.mib-2.dot1dBridge.dot1dBase.dot1dBaseNumPorts.0
   .1.3.6.1.2.1.17.1.2.0 = INTEGER: 24 ports
@@ Ligne 139: / Ligne 139: @@
 Ce petit exemple était destiné à démontrer que deux switchs de marque bien différente savent répondre à la même question, si l'information demandée est définie dans la BRIDGE-MIB.
-Bien sûr chaque constructeur va pouvoir apporter à ses équipements des particularités supplémentaires et spécifiques. Elles sont dans ce cas placées après le nœud ''enterprises''. Nous pourrons toujours obtenir ces données, mais sans les MIBs associées, il sera difficile, voir impossible de déterminer ce que ces données représentent.
+Bien sûr chaque constructeur va pouvoir apporter à ses équipements des particularités supplémentaires et spécifiques à sa marque et à son modèle. Elles sont dans ce cas placées après le nœud ''enterprises''. Nous pourrons toujours obtenir ces données, mais sans les MIBs associées, il sera difficile, voir impossible de déterminer ce que ces données représentent.
 Encore une fois, pourquoi se passer d'un peu d'humour ?
- ~$ snmpwalk -Of -c public -v 1 172.16.252.2 enterprises
+  ~$ snmpwalk -Of -c public -v 1 172.16.252.2 enterprises
 va nous donner :
@@ Ligne 166: / Ligne 166: @@
 Sans les MIBs qui vont avec, il sera quasiment impossible de savoir à quoi correspondent ces informations, car les MIBs, en plus de traduire les chemins numériques en texte, peuvent donner des indications supplémentaires sur la nature de l'information extraite.
+===== Mais encore... =====
+Les MIBs ne se contentent pas de fournir une traduction entre les modes numériques et textuels. Elles fournissent aussi quelques explications sur les paramètres qu'elles prennent en charge. La commande ''snmptranslate'' permet, une fois domestiquée, d'obtenir quelque documentation supplémentaire :
+<code>
+~$ snmptranslate -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
+</code>
+Nous obtenons, en art ASCII, une vue arborescente de la branche ''system''.
+Un peu de traduction pure et simple :
+<code>
+~$ snmptranslate -On SNMPv2-MIB::sysDescr
+.1.3.6.1.2.1.1.1
+~$ snmptranslate -Ot .1.3.6.1.2.1.1.1
+SNMPv2-MIB::sysDescr
+~$ snmptranslate -Of .1.3.6.1.2.1.1.1
+.iso.org.dod.internet.mgmt.mib-2.system.sysDescr
+</code>
+Et éventuellement quelques explications :
+<html><pre class="code">
+~$ snmptranslate -Ot <span class="hly">-Td</span> .1.3.6.1.2.1.1.1
+SNMPv2-MIB::sysDescr
+sysDescr OBJECT-TYPE
+  -- FROM	SNMPv2-MIB, RFC1213-MIB
+  -- TEXTUAL CONVENTION DisplayString
+  SYNTAX	OCTET STRING (0..255)
+  DISPLAY-HINT	"255a"
+  MAX-ACCESS	read-only
+  STATUS	current
+<span class="hly">  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."
+::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 1 }</span>
+</pre></html>
+Normalement, chaque bout de branche dispose d'une description. Ne vous attendez jamais à voir apparaitre autre chose que de l'anglais, bien entendu.
+<code>
+~$ snmptranslate -Ot -Td SNMPv2-MIB::sysORIndex
+SNMPv2-MIB::sysORIndex
+sysORIndex OBJECT-TYPE
+  -- FROM	SNMPv2-MIB
+  SYNTAX	INTEGER (1..2147483647)
+  MAX-ACCESS	not-accessible
+  STATUS	current
+  DESCRIPTION	"The auxiliary variable used for identifying instances
+            of the columnar objects in the sysORTable."
+::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) sysORTable(9) sysOREntry(1) 1 }
+</code>
+Notez également que ceci peut parfois tourner au jeu de piste.
+==== Interro surprise 1 ====
+Est-ce que ceci aurait des chances de fonctionner ?
+  ~$ snmptranslate -Ot -Td .1.3.6.1.2.1.17.1.2.0
+Et ceci :
+  ~$ snmptranslate -Ot -Td -m /usr/share/mibs/ietf/BRIDGE-MIB .1.3.6.1.2.1.17.1.2.0
+Vous trouverez les réponses à la fin de l'exposé.
+===== Et en mode graphique ? =====
+{{ :215snmp:capture-tkmib.png?300|TKmib}}
+Il existe un outil, ''TKmib'' qui, comme son nom l'indique, utilise TK et n'est donc pas des plus esthétiques. Ce genre d'outil, nommé « browser de MIBs » permet de faire de façon graphique, ce que l'on a vu avec ''nsmpwalk'', ''snmpget'' et ''snmptranslate''.
+Ce n'est pas très joli, mais ça fait le travail.