IBM Tivoli Netcool/OMNIbus version 8.1

Types d'objet MIB

Cette rubrique décrit les types d'objet définis dans SNMP v1 et v2.

Vous pouvez localiser les informations d'objet décrites dans les sections suivantes en sélectionnant un module dans la vue Modules MIB, puis en recherchant ifIndex dans la zone Recherche de la vue Arborescence d'ID objet. Cliquez sur l'objet ifIndex dans la hiérarchie de l'Arborescence d'ID objet pour afficher les informations sur l'objet et sur les conventions de texte dans la vue Détails.

OBJECT IDENTIFIER

OBJECT IDENTIFIER est défini par SNMP v1 et constitue le bloc de construction principal de l'arborescence MIB. Les identificateurs d'objet sont analogues à un en-tête de chapitre dans un manuel, ils ne contiennent pas de données réelles, mais ils indiquent quel type de contenu est relayé par leurs descendants.

OBJECT TYPE

OBJECT-TYPE est défini par SNMP v1 et est utilisé en tant que conteneur pour le stockage des informations sur le périphérique géré ou d'une valeur mesurée sur le périphérique.

TEXTUAL CONVENTION

TEXTUAL-CONVENTION (TC) est la définition d'un type d'objet et non un objet réel. Dans la vue Modules MIB, vous pouvez sélectionner Conventions textuelles dans la liste Vue afin d'afficher les conventions textuelles analysées, affichées dans l'arbre MIB. Sélectionnez un nom de TC dans l'arborescence MIB pour afficher sa définition dans la vue Détails.

SNMP v1 TRAP TYPE et SNMP v2 NOTIFICATION TYPE

SNMP v1 TRAP-TYPE et v2 NOTIFICATION-TYPE sont des mécanismes SNMP permettant de générer des événements autonomes vers le gestionnaire SNMP. Les interceptions SNMP dans v1 ne sont pas définies en tant qu'objets dans l'arborescence MIB. Un objet TRAP-TYPE ne possède pas de parent défini au format OBJECT IDENTIFIER. En revanche, une définition d'interception indique une entreprise pour laquelle une interception est définie. La phrase suivante est un objet TRAP-TYPE courant :

bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
 bgpPeerState } DESCRIPTION "L'événement BGP est généré lorsque BGP FSM 
passe à l'état ESTABLISHED." ::= 1

La section ENTERPRISE définit l'objet qui est le parent de l'interception. Toutefois, il est possible pour un objet de l'arborescence MIB d'être défini avec bgp en tant que parent, et d'être défini en tant qu'enfant numéro 1. En fait, bgpVersion est défini en tant que { bgp 1} dans le module RFC1269-MIB. Par conséquent, il est impossible d'ajouter une interception v1 à l'arborescence MIB en tant que feuille à l'aide d'ENTERPRISE en tant que parent.

SNMP v2 remplace la définition de TRAP-TYPE par NOTIFICATION-TYPE et indique que cette nouvelle interception v2 doit être définie comme d'autres objets MIB, avec un numéro de parent et d'enfant, ce qui pose un problème uniquement pour les interceptions v1. L'article RFC1155 4,1 définit que l'utilisation du zéro (0) en tant que numéro enfant n'est pas valide et qu'elle est réservée à un usage ultérieur. SNMP v2 utilise ce zéro en permettant aux fournisseurs d'ajouter leurs interceptions v1 à une MIB v2, en ajoutant un zéro au nom de l'entreprise, puis en ajoutant le numéro d'interception après le zéro. Par conséquent, en v2, il est opportun de définir un identificateur d'objet avec un zéro en tant qu'enfant de l'entreprise, puis d'ajouter les interceptions v1 en tant qu'enfants de ce zéro.

Cette convention a entraîné une autre erreur commune faite par les auteurs MIB. La section 4 de la norme RFC1155 déclare :

"Une définition de type d'objet est composée de cinq zones : OBJECT : ------- Nom textuel, appelé OBJECT DESCRIPTOR, pour le type d'objet, ainsi que ses identificateurs OBJECT IDENTIFIER correspondants. Syntaxe : Syntaxe abstraite pour le type d'objet. Elle doit être remplacée par une instance de la syntaxe ObjectSyntax de type ASN.1 (définie ci-dessous). Définition : description textuelle de la sémantique du type d'objet. Les implémentations doivent garantir que leur instance de l'objet répond à cette définition car cette MIB est conçue pour être utilisée dans des environnements multifournisseur. De ce fait, il est essentiel que les objets aient une signification cohérente sur l'ensemble des machines. Accès : l'un des types suivants : lecture seule, lecture-écriture, écriture uniquement ou non accessible. Etat : l'un des types suivants : obligatoire, facultatif ou obsolète. Les mémos ultérieurs peuvent également indiquer d'autres zones pour les objets qu'ils définissent."

Selon cette règle, tous les objets doivent avoir à la fois un nom d'objet et un numéro d'objet. Certains modules MIB du fournisseur, et même certains RFC, ont défini un type NOTIFICATION-TYPE avec un parent zéro, mais sans nom d'objet pour ce zéro. Dans l'exemple suivant, la définition d'objet n'est pas réellement correcte du point de vue syntaxique car il n'existe aucun nom d'objet défini pour le numéro d'enfant zéro de l'objet adslAtucTraps. MIB Manager reconnaît la préférence de certains auteurs MIB à utiliser des méthodes tel que des raccourcis et à autoriser l'ajout de l'objet sans nom d'objet. De plus, pour faciliter l'ajout de messages d'alerte v1 à l'arborescence MIB, MIB Manager ajoute automatiquement un objet zéro en tant qu'enfant de l'objet entreprise v1 (notez qu'une MIB v1 ne peut pas utiliser de zéro dans son OID), affecte cet objet zéro en tant que Traps où se trouve le nom de l'entreprise et ajoute le message d'alerte sous ce nouvel objet dans l'arborescence MIB. Par exemple, l'utilisation de bgp produirait les interceptions d'ancêtre suivantes : { bgp bgpTraps(0) 1 }).

adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Perte de trame, seuil d'intervalle de 15 minutes atteint." ::= { adslAtucTraps 0 1 }

Varbinds

Les objets transmis avec l'interception v1 ou la notification v2 sont appelés varbind. Les objets varbind contiennent des informations supplémentaires sur l'événement signalé. Dans une interception v1, les objets varbind sont détaillés dans la section VARIABLES et dans une notification v2, les objets varbind sont répertoriés dans la section OBJECTS. Ils ont la même utilisation dans toutes les versions de SNMP. L'ordre dans lequel les objets varbind apparaissent dans la liste est important car le PDU (paquet SNMP) code les valeurs associées dans l'ordre où elles sont répertoriées dans la MIB.

Par exemple, dans la section OBJECTS, les trois objets varbind suivants ont été spécifiés : ifIndex, ifAdminStatus et ifOperStatus. Par conséquent, ifIndex est le premier objet varbind à être codé, ifAdminStatus est le second et ifOperStatus est le troisième. Dans l'IF-MIB, nous observons que le type d'objet ifIndex est défini en tant qu'InterfaceIndex. Etant donné qu'il ne s'agit pas d'un type ASN.1 primitif pour SNMP, il doit s'agir d'une convention textuelle. Dans les conventions textuelles, nous observons qu'InterfaceIndex a pour résultat un entier Integer32 (entier sur 32 bits). Par conséquent, lorsque le PDU arrive au niveau de MIB Manager, le premier objet varbind est un entier. Pour déterminer la signification de cet entier, MIB Manager doit faire référence au module IF-MIB, rechercher ifIndex et lire les informations d'objet associées. Lorsque l'on vérifie le second objet varbind, nous trouvons un type entier énuméré :

SYNTAX INTEGER { up(1), -- ready to pass packets down(2), 
testing(3) -- in some test mode }

Lorsque l'objet varbind est décodé à partir du paquet SNMP, sa valeur est un entier dont la valeur doit être interprétée, en fonction des éléments de cette liste énumérée. Lorsque MIB Manager est utilisé pour créer un fichier de règles, il crée une table de recherche pour lier automatiquement l'entier énuméré à sa représentation textuelle. Le troisième objet varbind est également un type énuméré avec les mêmes valeurs. Par conséquent, si l'état ifAdminStatus est 1 (actif) et l'état ifOperStatus est 2 (inactif), nous savons pourquoi l'événement a été généré et nous pouvons tenter de déterminer la cause de cette indisponibilité.

Les objets varbind sont présentés à l'utilisateur dans un fichier de règles sous la forme $1, $2, $3, etc. dont chaque numéro représente un numéro d'objet varbind. MIB Manager crée des éléments basés sur les éléments varbind et utilise ces éléments pour définir des variables dans le tableau de détails. Par exemple, les éléments utilisés dans la table de détails peuvent être $ifIndex = $1, qui est un entier, $ifAdminStatus = $2, qui est un état de type actif (1) et $ifOperStatus = $3, qui est un état de type inactif (3). Toutes les modifications apportées aux paramètres de l'objet sont automatiquement définies dans le fichier de règles à l'aide des conventions définies par Netcool Knowledge Library (NCKL).

Tables

Les tables représentent l'équivalent d'un tableau multidimensionnel avec des lignes et des colonnes de données. L'objet table est défini par SEQUENCE OF d'un objet Entry. L'objet Entry est ensuite défini en tant que SEQUENCE d'objets OBJECT-TYPE. Parfois, un fournisseur conçoit un système inhabituel, par exemple le routeur Cisco 10k. Ce périphérique gère une table interne de conditions d'alarme et génère une interception ou une notification lorsque la table est modifiée. Vous devez alors émettre une requête SNMP GET sur le contenu de la table afin de déterminer l'état actuel de des alarmes actives sur le périphérique. Il est alors plus difficile pour le gestionnaire SNMP d'obtenir des alarmes mais cela reste possible si l'administrateur dispose des outils adéquats.

OCTET STRING

Un octet est une construction de données composée de huit bits (communément appelé octet). Une chaîne OCTET STRING est donc un tableau d'octets (ou chaîne d'octets). L'expression OCTET STRING n'implique pas que tous les octets de la chaîne soient des caractères alphanumériques. Il peut également s'agir de caractères binaires et ils peuvent être utilisés en tant que masques de bit.

Bibliothèque | Support |