Présentation des valeurs d'index de table dans SNMP
Contenu
Introduction
En interrogeant des objets du protocole de gestion de réseau simple (SNMP), vous devez parfois connaître exactement l'élément interrogé. Afin de comprendre parfaitement cela, vous devez savoir comment corréler l'objet qui est interrogé avec ce que vous voulez interroger. Ce document couvre les principes fondamentaux de la méthode d'utilisation des index dans le SNMP pour grouper des objets en tables.
Conditions préalables
Conditions requises
Les lecteurs de ce document devraient avoir connaissance des sujets suivants :
-
Connaissances générales du protocole SNMP
-
Logiciel utilisé pour interroger les périphériques Cisco via SNMP
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
-
UCD SNMP version 4.2
-
Cisco Catalyst 5509 avec le logiciel Cisco IOS® version 5.5(7)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Mise en route de ifIndex
L'une des premières choses à apprendre, lorsque vous traitez de SNMP, est ifIndex. Il s'agit d'une clé primaire de tous les objets. Considérez que toutes les interfaces (physiques et logiques) sont décomposées et affectées d’une valeur. Cette valeur est attribuée lors du démarrage d'un périphérique et ne peut pas être modifiée. Si une information doit être interrogée pour cette interface particulière, elle doit utiliser cette valeur attribuée.
IfIndex est défini de la manière IF-MIB (RFC 1213 
) :
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface
or interface sub-layer in the managed system. It is
recommended that values are assigned contiguously
starting from 1. The value for each interface sub-
layer must remain constant at least from one re-
initialization of the entity's network management
system to the next re-initialization."
SYNTAX Integer32 (1..2147483647)
Pour chaque MIB, une façon rapide de savoir quel index organise une table consiste à consulter l'entrée de la table :
ifEntry OBJECT-TYPE
SYNTAX IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing management information applicable
to a particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
À partir d'une MIB et d'une entrée de table, vous pouvez déterminer comment la table est indexée. La section suivante fournit des exemples de ifIndex.
Objets d'interrogation
Interrogation d'objets basée sur ifIndex
Lorsque vous émettez la commande snmpwalk pour interroger un objet ifIndex (ifName) pour le port 7/4 sur le commutateur, vous obtenez cette sortie :
sj-cse-568: snmpwalk 172.16.99.60 public ifname ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.1 = sc0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.2 = sl0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.3 = VLAN-1 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.4 = VLAN-1002 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.5 = VLAN-1004 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.6 = VLAN-1005 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.7 = VLAN-1003 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.8 = 7/1 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.9 = 7/2 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.10 = 7/3 !--- This is the relevant line: ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.11 = 7/4 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.12 = 7/5 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.13 = 7/6 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.14 = 7/7 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.15 = 7/8 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.16 = 7/9 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.17 = 7/10 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.18 = 7/11 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.19 = 7/12 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.20 = ATM8/0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.22 = /A ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.23 = /B ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.24 = Nu0 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.25 = LEC/ATM8/0.10 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.532 = 3/1 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName.533 = 3/2 !--- Output suppressed.
Dans ce résultat d'un sondage de ifName (ifDescr sur les routeurs), notez qu'un numéro est attaché à chaque ligne, après ifName. Il s'agit du ifIndex affecté à l'interface réelle dans la même ligne. Cela signifie que la deuxième ligne du sondage, port 7/4, est affectée à un ifIndex de 11. Si vous souhaitez obtenir des informations sur le port 7/4 à partir d'un objet ifIndexed, utilisez un index de 11. Cela signifie l'ajout d'un .11 à la fin d'un identificateur d'objet MIB (OID), pour récupérer l'instance de cet objet qui correspond aux mêmes valeurs ifIndex.
Interrogation d'objets si la table n'est pas indexée par ifIndex ou est indexée croisée
Parfois, les tables ne sont pas indexées par ifIndex, par exemple avec BRIDGE-MIB. Ce résultat examine comment il est indexé :
dot1dBasePortEntry OBJECT-TYPE
SYNTAX Dot1dBasePortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of information for each port of the
bridge."
REFERENCE
"IEEE 802.1D-1990: Section 6.4.2, 6.6.1"
INDEX { dot1dBasePort }
::= { dot1dBasePortTable 1 }
Cette sortie montre que dot1dBasePortEntry est indexé par dot1dBasePort. Comment cela se traduit-il par ifIndex ? BRIDGE-MIB accède à un objet appelé dot1dBasePortIfIndex. L'objet est défini de la manière suivante :
dot1dBasePortIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of the instance of the ifIndex object,
defined in MIB-II, for the interface corresponding
to this port."
::= { dot1dBasePortEntry 2 }
Cette sortie montre comment corréler de BRIDGE-MIB à IF-MIB. L'exemple suivant montre comment tout s'intègre.
Remarque : BRIDGE-MIB est construit par vlan. Par conséquent, la communauté “ public@vlan-id ” doit être utilisée pour les environnements non vlan1.
Corrélation entre BRIDGE-MIB et IF-MIB
Lorsque vous lancez un snmpwalk sur le BRIDGE-MIB, vous obtenez l'exemple suivant de sortie pour un index. Utilisez dot1dBasePortIfIndex (.1.3.6.1.2.1.17.1.4.1.2) pour le mapper à ifIndex. Une fois que vous avez ifIndex, utilisez-le pour interroger d'autres objets basés sur ifIndex.
sj-cse-568: snmpwalk 172.16.99.60 public .1.3.6.1.2.1.17.1.4.1.2 17.1.4.1.2.203 = 671 17.1.4.1.2.204 = 672 17.1.4.1.2.205 = 673 17.1.4.1.2.206 = 674 17.1.4.1.2.207 = 675 17.1.4.1.2.208 = 676 17.1.4.1.2.209 = 677 17.1.4.1.2.210 = 678 17.1.4.1.2.211 = 679 17.1.4.1.2.212 = 680 17.1.4.1.2.213 = 681 17.1.4.1.2.214 = 682 17.1.4.1.2.215 = 683 17.1.4.1.2.216 = 684 17.1.4.1.2.257 = 581 17.1.4.1.2.385 = 8 17.1.4.1.2.386 = 9 17.1.4.1.2.387 = 10 17.1.4.1.2.388 = 11 17.1.4.1.2.389 = 12 17.1.4.1.2.390 = 13 17.1.4.1.2.391 = 14 17.1.4.1.2.392 = 15 17.1.4.1.2.393 = 16 17.1.4.1.2.394 = 17 17.1.4.1.2.395 = 18 17.1.4.1.2.396 = 19 17.1.4.1.2.449 = 22
La ligne de texte en gras (17.1.4.1.2.388 = 11) indique que .388 est un index. Comme vous avez interrogé l'objet dot1dBasePortIfIndex à partir de BRIDGE-MIB, .388 est le dot1dBasePortIfIndex. Le 11 de la ligne de sortie est en fait le ifIndex. Si vous collectez les informations de ce sondage et du sondage précédent, vous pouvez déterminer que le port 7/4 a un ifIndex de 11 et un dot1dBasePortIfIndex (Index pour BRIDGE-MIB) de .388.
Commentaires