This topic describes the object types defined in SNMP v1 and v2.
You can locate the object information described in the following sections by selecting a module in the MIB Modules view and then searching for ifIndex in the Search field of the OID Tree view. Click on the ifIndex object in the OID Tree hierarchy to see object information and textual convention information in the Details view.
The OBJECT IDENTIFIER is defined by SNMP v1 and is the main building block of the MIB tree. Object identifiers are analogous to a chapter heading in a book - they contain no real data but do give you an idea of what kind of content is relayed by their descendents.
The OBJECT-TYPE is defined by SNMP v1 and is used as a container for storing information about the managed device, or some measured value on the device.
The TEXTUAL-CONVENTION (TC) is a definition of a type of object but is not an actual object. In the MIB Modules view, you can select Textual Conventions from the View list to see the parsed textual conventions displayed in the MIB tree. Select a TC name in the MIB tree to display its definition in the Details view.
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM
enters the ESTABLISHED state." ::= 1 The ENTERPRISE section defines which object is the parent of the trap. However, it is possible for a MIB tree object to be defined with bgp as the parent and it is defined as child number 1. In fact, bgpVersion is defined as { bgp 1} in the RFC1269-MIB module. Therefore, it is impossible to add a v1 trap to the MIB tree as a leaf using the ENTERPRISE as the parent.
SNMP v2 changes the definition for TRAP-TYPE to NOTIFICATION-TYPE and specifies that this new v2 trap be defined like other MIB objects, with a parent and child number making this only a problem for v1 traps. RFC1155 Section 4.1 defines that using zero (0) as a child number is invalid, and reserved for future use. SNMP v2 makes use of that zero by allowing vendors to add their v1 traps to a v2 MIB, by adding a zero to the enterprise name and then adding the trap number after the zero. Therefore, under v2 it is appropriate to define an object identifier with a zero as a child of the enterprise and then add the v1 traps as children of that zero.
This convention has caused another common mistake made by MIB authors. Section 4 of RFC1155 states the following:
"An object type definition consists of five fields: OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER. Syntax: The abstract syntax for the object type. This must resolve to an instance of the ASN.1 type ObjectSyntax (defined below). Definition: A textual description of the semantics of the object type. Implementations should ensure that their instance of the object fulfills this definition since this MIB is intended for use in multi-vendor environments. As such it is vital that objects have consistent meaning across all machines. Access: One of read-only, read-write, write-only, or not-accessible. Status: One of mandatory, optional, or obsolete. Future memos may also specify other fields for the objects which they define."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs,
adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute
interval threshold reached." ::= { adslAtucTraps 0 1 } Objects that are transmitted with the v1 trap or v2 notification are known as varbinds. Varbinds contain additional information about the reported event. In a v1 trap, the varbinds are itemized in the VARIABLES section and in a v2 notification the varbinds are listed in the OBJECTS section. They have the same use in all versions of SNMP. The order in which the varbinds appear in the list is important because the PDU (SNMP Packet) encodes the associated values in the same order in which they are listed in the MIB.
For example, in the OBJECTS section the following three varbinds have been specified: ifIndex, ifAdminStatus, and ifOperStatus. Therefore, ifIndex is the first varbind to be encoded, ifAdminStatus is the second, and ifOperStatus is encoded third. Checking the IF-MIB we find that the ifIndex object type is defined as InterfaceIndex. Since this is not a valid primitive ASN.1 type for SNMP, it must be a textual convention. Searching through the textual conventions, we find that InterfaceIndex actually resolves to an Integer32 (32 bit integer). Therefore, when the PDU arrives at MIB Manager, the first varbind will be an integer. To determine what that integer means, MIB Manager must reference the IF-MIB module, look up ifIndex, and read the associated object information. Checking the second varbind, we find an enumerated integer type:
SYNTAX INTEGER { up(1), -- ready to pass packets down(2),
testing(3) -- in some test mode }When the varbind is decoded from the SNMP packet, its value will be an integer, the value of which must be interpreted based on the items in this enumerated list. When MIB Manager is used to create a rules file, it will create a lookup table to automatically link the enumerated integer with its textual representation. The third varbind is also an enumerated type with the same values. Therefore, if the ifAdminStatus is 1 (up) and the ifOperStatus is 2 (down), we know why the event was generated and can proceed to attempt to determine the cause of this outage.
Varbinds are presented to the user in a rulesfile as $1, $2, $3, and so on, with each number representing a varbind number. MIB Manager creates elements based on the varbind elements and uses these to set variables in the details table. For example, the elements used in the details table might be $ifIndex = $1, which will be an integer, $ifAdminStatus = $2, which will be something like up (1), and $ifOperStatus = $3, which will be something like down (3). Any changes made to the object settings are automatically set in the rules file, using the conventions set by the Netcool Knowledge Library (NCKL).
Tables represent the equivalent of a multidimensional array with rows and columns of data. The table object is defined as a SEQUENCE OF an Entry object. The Entry object is then defined as a SEQUENCE of OBJECT-TYPE objects. Occasionally, a vendor designs an unusual system, for example the Cisco 10k router. This device maintains an internal table of alarm conditions and generates a trap or notification when the table changes. You must then issue an SNMP GET request on the contents of the table to determine the current status of the active alarms on the device. This makes obtaining the alarms by the SNMP manager a bit more difficult, but not impossible if the administrator has the tools to comply.
An octet is a data construct consisting of eight bits (commonly known as a byte). An OCTET STRING then, is an array of bytes (or a string of bytes). The term OCTET STRING does not imply that all of the bytes in the string are alphanumeric. They can also be binary characters and are used as bitmasks.