Este tema describe los tipos de objeto definidos en SNMP v1 y v2.
Puede ubicar la información de objeto que se describe en las siguientes secciones si selecciona un módulo en la vista Módulos MIB y después busca ifIndex en el campo Búsqueda de la vista Árbol OID. Pulse el objeto ifIndex en la jerarquía Árbol OID para ver información del objeto e información de convención textual en la vista Detalles.
El IDENTIFICADOR DE OBJETO está definido en SNMP v1 y es el bloque de compilación principal del árbol MIB. Los identificadores de objeto son parecidos al título de un capítulo: no contienen datos reales pero le dan una idea del tipo de contenido que transmiten sus descendientes.
El TIPO DE OBJETO está definido en SNMP v1 y se utiliza como contenedor para almacenar información sobre el dispositivo gestionado o algún valor medido en el dispositivo.
La CONVENCIÓN TEXTUAL (TC) es una definición de un tipo de objeto y no un objeto propiamente dicho. En la vista Módulos MIB, puede seleccionar Convenciones textuales en la lista Vista para ver las convenciones textuales analizadas que se visualizan en el árbol MIB. Seleccione un nombre de TC en el árbol MIB para visualizar su definición en la vista Detalles.
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "El suceso BGP Established se genera cuando BGP FSM
entra en estado ESTABLECIDO". ::= 1 La sección ENTERPRISE define qué objeto es el padre de la interrupción. No obstante, es posible definir un objeto de árbol MIB con bgp como padre y que se defina como hijo número 1. De hecho, bgpVersion está definido como { bgp 1} en el módulo RFC1269-MIB. Por tanto, es imposible añadir una interrupción v1 en el árbol MIB como hoja utilizando ENTERPRISE como padre.
SNMP v2 cambia la definición para TRAP-TYPE a NOTIFICATION-TYPE y especifica que esta nueva interrupción v2 se define como otros objetos MIB, con un número de padre e hijo que hacen que éste sea sólo un problema para las interrupciones v1. RFC1155 La sección 4.1 define que el uso de cero (0) como número de hijo no es válido, y se reserva para un uso futuro. SNMP v2 hace uso de ese cero permitiendo a los proveedores añadir sus interrupciones v1 a una MIB v2, añadiendo un cero al nombre de empresa y, a continuación, añadiendo el número de interrupción después del cero. Por tanto, bajo v2 es adecuado definir un identificador de objeto con un cero como hijo de la empresa y luego añadir las interrupciones v1 como hijos de ese cero.
Esta convención ha hecho que los autores de MIB cometan otro error común. La sección 4 de RFC1155 establece lo siguiente:
"Una definición de tipo de objeto consta de cinco campos: OBJETO: ------- Un nombre textual, llamado DESCRIPTOR DE OBJETO, para el tipo de objeto, junto con el correspondiente IDENTIFICADOR DE OBJETO. Sintaxis: La sintaxis abstracta para el tipo de objeto. Esto debe resolverse en una instancia del tipo ASN.1 ObjectSyntax (definida a continuación). Definición: Una descripción textual de la semántica del tipo de objeto. Las implementaciones deben asegurarse de que su instancia del objeto cumpla esta definición, ya que la MIB está prevista para utilizarse en entornos de varios proveedores. Por ello, resulta de suma importancia que los objetos tengan un significado consistente en todas las máquinas. Acceso: Uno de sólo lectura, lectura-grabación, sólo grabación o no accesible. Estado: Uno de obligatorio, opcional u obsoleto. Los memorandos futuros también pueden especificar otros campos para los objetos que definen."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs,
adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute
interval threshold reached." ::= { adslAtucTraps 0 1 } A los objetos que se transmiten con la interrupción v1 o la notificación v2 se les conoce como varbinds. Los varbinds contienen información adicional sobre el suceso del que se informa. En una interrupción v1, los varbinds se listan en la sección VARIABLES y en una notificación v2 los varbinds se listan en la sección OBJETOS. Tienen el mismo uso en todas las versiones de SNMP. El orden en el que aparecen las variables en la lista es importante porque el PDU (paquete SNMP) codifica los valores asociados en el mismo orden en el que están listados en la MIB.
Por ejemplo, en la sección OBJETOS se han especificado los tres varbinds siguientes: ifIndex, ifAdminStatus, e ifOperStatus. Por lo tanto, ifIndex es el primer varbind que se codifica, ifAdminStatus es el segundo, e ifOperStatus se codifica en tercer lugar. Al comprobar el IF-MIB vemos que el tipo de objeto ifIndex se ha definido como InterfaceIndex. Dado que este no es un tipo primitivo ASN.1 para SNMP, debe ser una convención textual. Al buscar en las convenciones textuales, vemos que InterfaceIndex en realidad se resuelve en un Integer32 (entero de 32 bits). Por lo tanto, cuando el PDU llega a MIB Manager, el primer varbind será un entero. Para determinar lo que significa ese entero, MIB Manager debe referirse al módulo IF-MIB, buscar ifIndex y leer la información de objeto asociada. Al comprobar el segundo varbind, vemos un tipo entero enumerado:
SYNTAX INTEGER { arriba(1), -- preparado para pasar paquetes abajo(2),
probando (3) -- en alguna modalidad de prueba}Cuando el varbind se descodifica del paquete SNMP, su valor será un entero, cuyo valor se deberá interpretar basándose en los artículos en esta lista enumerada. Cuando MIB Manager se utilice para crear un archivo de reglas, creará una tabla de búsqueda para enlazar automáticamente el entero enumerado con su representación textual. El tercer varbind también es un tipo enumerado con los mismos valores. Por lo tanto, si ifAdminStatus es 1 (arriba) e ifOperStatus es 2 (abajo), sabemos por qué se generó el suceso y podemos intentar determinar la causa de esta parada.
Los varbinds se presentan al usuario en un archivo de reglas como $1, $2, $3, etc. Cada número representa un número varbind. MIB Manager crea elementos según los elementos varbind y los utiliza para establecer variables en la tabla de detalles. Por ejemplo, los elementos que se utilizan en la tabla de detalles pueden ser $ifIndex = $1, que será un entero, $ifAdminStatus = $2, que será algo así como superior a (1), y $ifOperStatus = $3, que será algo así como inferior a (3). Cualquier cambio que se haga a los valores del objeto se define automáticamente en el archivo de reglas, utilizando las convenciones definidas por Netcool Knowledge Library (NCKL).
Las tablas son el equivalente de una matriz multidimensional con filas y columnas de datos. El objeto de tabla se define como una SEQUENCE OF un objeto de entrada. A continuación, el objeto de entrada se define como una SEQUENCE de objetos OBJECT-TYPE. De vez en cuando, un proveedor diseña un sistema no habitual, por ejemplo el direccionador Cisco 10k. Este dispositivo mantiene una tabla interna de condiciones de alarma y genera una interrupción o notificación cuando se modifica la tabla. Entonces, debe emitir una solicitud GET de SNMP en el contenido de la tabla para determinar el estado actual de las alarmas activas en el dispositivo. Esto hace que sea un poco más difícil para el gestor de SNMP obtener las alarmas, pero no imposible, si el administrador tiene las herramientas adecuadas.
Un octeto es una construcción de datos de ocho bits (comúnmente conocido como byte). Un OCTET STRING, es una matriz de bytes (o una serie de bytes). El término OCTET STRING no significa que todos los bytes de la serie sean alfanuméricos. También pueden ser caracteres binarios y se utilizan como máscaras de bits.