7.7 Incompatible Private Enterprise MIBs

SNMP’s popularity has encouraged numerous vendors to incorporate the protocol and its functions into their products. Unfortunately, any time more than one vendor gets involved in a system, incompatibilities can arise, as illustrated in this example (see Figure 7-7).

Figure 7-7  Incompatible private enterprise MIBs

The manager in this case is a Hewlett-Packard OpenView console, and the agent is a Novell file server running NetWare v3.11 with the TCP/IP and SNMP options. The manager requests the value of a specific object from the agent in Frame 1; the response is “no such name.” The details of the captured frames identify what happened (see Trace 7.7).

In the first IP datagram (Frame 1), the manager’s SNMP process includes Identification = 29913 to identify the message. Note that the HP manager assigned Source port = 4837 on its host and used the Destination port = 161, the standard SNMP port, for the agent’s host. Also note that the Community name = public. The SNMP GetRequest PDU has a Request ID = 1840, which is used to correlate this request with the agent’s response. The object in question is from the private enterprise tree {1.3.6.1.4.1} and is further identified as belonging to the Hewlett-Packard enterprise {1.3.6.1.4.1.11}. The specific object is {1.3.6.1.4.1.11.2.3.1.1.3.0} or {HP 2.3.1.1.3.0}, which identifies the CPU utilization. (Note that the network analyzer is programmed to identify the HP subtree {1.3.6.1.4.1.11}, but not the exact object. We know that this object is CPU utilization from looking into the details of HP’s private MIB.)

The agent responds in Frame 2. Note that the agent uses a different Identification (22662) for the IP datagram. This is not a problem, since IP processes of the manager and agent are independent. The agent correctly designates the Destination port (4837) within its UDP header, which sends the SNMP reply to the manager’s SNMP process. The agent’s message contains the community name (public) and the Request ID (1840) that correlate with the manager’s request. The last two fields provide a clue to the problem: the Error Status = 2 (no such name) and the Error Index = 1. These specify that the object name given in the GetRequest was unknown to the agent, and that the first object specified contained the error. When you consider that the HP manager was asking a Novell server for its CPU utilization, the confusion isn’t surprising. Thus, while both manager and agent support MIB-II, their private enterprise MIBs are incompatible. This is another example of systems that are standards based, yet incompatible.

Trace 7.7. Inconsistent private enterprise MIBs

Sniffer Network Analyzer data 5-Oct at 09:42:54, file PRVMIB2.ENC Pg 1
  --------------------------- Frame 1 ---------------------------
  DLC: ----- DLC Header -----
  DLC:
  DLC: Frame 1 arrived at 09:43:20.8073; Frame size is 87 (0057
  hex) bytes.
  DLC: Destination = Station H-P  133ADE
  DLC: Source   = Station H-P  17B65F
  DLC: Ethertype = 0800 (IP)
  DLC:
  IP:  ----- IP Header -----
  IP:
  IP:  Version = 4, header length = 20 bytes
  IP:  Type of service = 00
  IP:     000. .... = routine
  IP:     ...0 .... = normal delay
  IP:     .... 0... = normal throughput
  IP:     .... .0.. = normal reliability
  IP:  Total length = 73 bytes
  IP:  Identification = 29913
  IP:  Flags = 0X
  IP:  .0.. .... = may fragment
  IP:  ..0. .... = last fragment
  IP:  Fragment offset = 0 bytes
  IP:  Time to live = 30 seconds/hops
  IP:  Protocol = 17 (UDP)
  IP:  Header checksum = 2051 (correct)
  IP:  Source address = [128.79.3.115], Manager
  IP:  Destination address = [128.79.3.105], Agent
  IP:  No options
  IP:
  UDP: ----- UDP Header -----
  UDP:
  UDP: Source port = 4837 (SNMP)
  UDP: Destination port = 161
  UDP: Length = 53
  UDP: Checksum = CBCC (correct)
  UDP:
  SNMP: ----- Simple Network Management Protocol (Version 1) -----
  SNMP:
  SNMP: Version = 0
  SNMP: Community = public
  SNMP: Command = Get request
  SNMP: Request ID = 1840
  SNMP: Error status = 0 (No error)
  SNMP: Error index = 0
  SNMP:
  SNMP: Object = {1.3.6.1.4.1.11.2.3.1.1.3.0} (HP.2.3.1.1.3.0)
  SNMP: Value = NULL
  SNMP:

  --------------------------- Frame 2 ---------------------------
  DLC: ----- DLC Header -----
  DLC:
  DLC: Frame 2 arrived at 09:43:20.8093; Frame size is 88 (0058
  hex) bytes.
  DLC: Destination = Station H-P  17B65F
  DLC: Source   = Station H-P  133ADE
  DLC: Ethertype = 0800 (IP)
  DLC:
  IP:  ----- IP Header -----
  IP:
  IP:  Version = 4, header length = 20 bytes
  IP:  Type of service = 00
  IP:     000. .... = routine
  IP:     ...0 .... = normal delay
  IP:     .... 0... = normal throughput
  IP:     .... .0.. = normal reliability
  IP:  Total length = 73 bytes
  IP:  Identification = 22662
  IP:  Flags = 0X
  IP:  .0.. .... = may fragment
  IP:  ..0. .... = last fragment
  IP:  Fragment offset = 0 bytes
  IP:  Time to live = 128 seconds/hops
  IP:  Protocol = 17 (UDP)
  IP:  Header checksum = DAA3 (correct)
  IP:  Source address = [128.79.3.105], Agent
  IP:  Destination address = [128.79.3.115], Manager
  IP:  No options
  IP:
  UDP: ----- UDP Header -----
  UDP:
  UDP: Source port = 161 (SNMP)
  UDP: Destination port = 4837
  UDP: Length = 53
  UDP: No checksum
  UDP:
  SNMP: ----- Simple Network Management Protocol (Version 1) -----
  SNMP:
  SNMP: Version = 0
  SNMP: Community = public
  SNMP: Command = Get response
  SNMP: Request ID = 1840
  SNMP: Error status = 2 (No such name)
  SNMP: Error index = 1
  SNMP:
  SNMP: Object = {1.3.6.1.4.1.11.2.3.1.1.3.0} (HP.2.3.1.1.3.0)
  SNMP: Value = NULL
  SNMP:

7.8 Proper Handling of an Invalid Object Identifier (OID)

Chapters 2 and 3 discussed the ASN.1 encodings for objects within the SNMP MIBs. These encodings are based on a tree structure, and specific object identifiers (OIDs) locate the positions of objects on the tree. Since these OIDs are sequences of numbers, a mistake of just one digit renders the sequence invalid. This example shows how an agent responds to a manager’s mistake.

In this example, the manager wishes to obtain the value of the system description (see Figure 7-8 and Trace 7.8a). The first time the request is made (Frame 1), a correct response is returned (Frame 3). The second request (Frame 4) is unsuccessful (Frame 5). The details of the SNMP messages (Trace 7.8b) reveal that an invalid OID caused the problem.