Previous | Table of Contents | Next |
SNMPs 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 managers 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 agents 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 agents 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 HPs 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 managers SNMP process. The agents message contains the community name (public) and the Request ID (1840) that correlate with the managers 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 isnt 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:
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 managers 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.
Previous | Table of Contents | Next |