system
interfaces
at
)
at
group is depreciated
in MIB II: this info is moved into each network protocol group.
IP
ICMP
TCP
& UDP
groups
[1] MIB II (rfc1213) replaced the original (rfc 1155/6) MIB specification in 1991
ipForwarding
ipDefaultTTL
ipInReceives
ipForwDatagrams
ipInDiscards
There are also several tables associated with the IP subsystem:
ipAddrTable
ipRoutingTable
ipRouteEntry
type.
get
get-next
set
trap
It also defines the reply operation:
get-response
SNMP (normally) uses the low-overhead, connectionless UDP protocol for transmission of requests and responses.
An SNMP message contains, along with data describing the SNMP commands or responses, a community name identifying that the sender is a member of an identified community, or group of managed nodes. This allows a trivial level of authentication, since the community name almost always defaults to "public".
If the particular information is not a column in a table (ie, it is a scalar), then the OBJECT IDENTIFER is given a suffix of zero, thus:orsystem.sysDescr.0Thus to retrieve the instance information specified above, we could use:1.3.6.1.2.1.1.1.0orget (system.sysDescr.0)get (1.3.6.1.2.1.1.1.0)
For example, in the{ interfaces }
group, the first data type is a scalar, thus:This is the number of interfaces a device has, regardless of their status. The MIB then defines:ifNumber ::= { interfaces 1 }andifTable ::= SEQUENCE OF ifEntryAs an example, to retrieve information about (for example) the operational status of interface number 3, where multiple interfaces are in use, we could use:ifEntry ::= SEQUENCE { ifIndex ::= INTEGER, ... ifOperStatus::= INTEGER, ...etc }get (interfaces.ifTable.ifEntry.ifOperStatus.3)
should return the lexicographically next instance in the MIB, thus:get-next (system.sysDescr.0)
The operand of get-next need not be an instance specifier: it can be any OBJECT IDENTIFIER. Hence the call:sysObjectID.0
returns the next instance, thus:get-next (system.sysDescr)
sysDescr.0
get-next
can also take multiple operands, thus it is
possible to use it to obtain multiple columns within a single row of a table
of information in a single operation, eg:
This is considered to be very useful, hence the terminology powerful get-nextget-next (ipRouteDest, ipRouteIfindex)
The data field of the SNMP message contains the SNMP PDU. For example, an SNMP get-request PDU is defined as follows:SNMP-Message ::= SEQUENCE { version INTEGER { version-1 (0)}, community OCTET STRING, data ANY }
GetRequest-PDU ::= [0] IMPLICIT SEQUENCE { request-id RequestID, -- 4 byte integer to match requests and responses error-status ErrorStatus, error-index ErrorIndex, -- both single byte integers, = 0 in requests, error status in responses variable-bindings VarBindList -- list of desired object identifiers as name/value pairs
sysDescr (1.3.6.1.2.1.1.1)
[1] Thanks to Comer for this example.30 29 02 01 00 SEQUENCE len=41 INTEGER len=1 vers=0 04 06 70 75 62 6C 69 63 string len=6 p u b l i c A0 1C 02 04 05 AE 56 02 getReq len=28 INTEGER len=4 -req ID- 02 01 00 02 01 00 INTEGER len=1 status INTEGER len=1 index 30 0E 30 0C 06 08 SEQUENCE len=14 SEQUENCE len=12 OID len=8 2B 06 01 02 01 01 01 00 1.3 . 6 . 1 . 2 . 1 . 1 . 1 . 0 05 00 NULL len=0
More complex software systems permit regular monitoring of many variables. These have been developed into a variety of Network Operations Console software packages. Some examples include:snmpget 149.144.21.254 public system.sysDescr.0 snmpget 149.144.21.254 public interfaces.ifTable.ifEntry.ifOperStatus.3 snmpgetnext 149.144.21.254 public system
tkined
nocol
{ internet SNMPv2(6) }
Nevertheless, SNMPv2 has been widely criticised for its higher complexity, overhead, incompability with older MIBs, etc, etc.