Previous Table of Contents Next


Chapter 7
Case Studies in Implementing SNMP

So far, this book has described the technical details of SNMP. This chapter provides case studies from live networks that show how these concepts apply to the real world. These studies demonstrate actual internetwork management challenges and solutions. For consistency, all of the case studies were captured with a Network General Corp. Sniffer protocol analyzer.

7.1 Verifying Access Control with the Community Name

To warm you up to the idea of protocol analysis, let’s start with a problem that has a simple solution. As Section 4.3 discussed, the SNMP message consists of an authentication header and one of five SNMP PDUs. The authentication header contains the SNMP version number and the community name. The agent uses the community name as a password to validate the identity of the manager. If the community names of the manager and the agent are identical, message processing proceeds. If not, there is an authentication failure. Depending on the agent’s SNMP implementation, it will either discard the offending message, generate a trap, or both.

In the topology shown in Figure 7-1, the network administrator has set the community name of both the manager and the agent to “public,” a common default value. (Now is a good time to check the community name for your network devices and change this default value. Doing so will greatly increase the security on your internetwork!)


Figure 7-1   Verifying access with the community name

In frame 9 of Trace 7.1a, the manager requests the IP routing table {1.3.6.1.2.1.4.21} using a GetNextRequest. The manager requests values for the ipRouteDest, ipRouteNextHop, ipRouteType, and ipRouteIfIndex objects (Frame 9 of Trace 7.1b). The values of these objects are returned in Frames 10 through 54, and can be used to generate the following table:

IpRouteDest ipRouteIfIndex ipRouteNextHop ipRouteType

0.0.0.0 2 128.79.3.200 4
128.79.0.0 2 128.79.3.200 3
128.79.2.0 2 128.79.3.202 4
128.79.3.0 2 128.79.3.105 3
128.79.4.0 2 128.79.3.200 4
128.79.5.0 2 128.79.3.201 4
128.79.6.0 2 128.79.3.200 4
128.79.7.0 2 128.79.3.201 4
128.79.8.0 2 128.79.3.201 4
128.79.9.0 2 128.79.3.202 4
128.79.12.0 2 128.79.3.200 4
128.79.14.0 2 128.79.3.200 4
128.79.15.0 2 128.79.3.201 4
128.79.16.0 2 128.79.3.201 4
128.79.18.0 2 128.79.3.201 4
128.79.20.0 2 128.79.3.201 4
128.79.40.0 2 128.79.3.200 4
128.79.120.0 2 128.79.3.200 4
128.79.180.0 2 128.79.3.201 4
128.79.200.0 2 128.79.3.201 4

The ipRouteDest object contains the destination IP address for this route. The first entry is 0.0.0.0, indicating a default route. The ipRouteIfIndex identifies the local interface through which the next hop of this route may be reached. Each of these entries specifies interface number 2. The ipRouteNextHop is the IP address of the next hop of the route. The ipRouteType has one of four possible values: other (1), none of the following; invalid (2), an invalidated route; direct (3), a route to a directly connected subnetwork; and indirect (4), a route to a nonlocal (or remote) subnetwork. In the table, the second and fourth entries are direct; the remaining entries are destined for remote networks.

The GetNext operation stops in Frame 56 when the agent returns the lexicographical next object within the router’s table (see Trace 7.1c): the ipRouteProto {1.3.6.1.2.1.4.21.1.9} and the ipRouteMetric1 {1.3.6.1.2.1.4.21.1.3}.

As an experiment, the network administrator changed the agent console’s community name from “public” to “test.” Frames 59 to 63 of Trace 7.1a show the results. In Frames 59 to 60, the manager and agent confirm their communication path by using ICMP Echo and Echo Reply messages (these messages are often called the “PING” commands). Satisfied that the communication path is working, the manager issues a GetNext request for values of three objects in the Interfaces group. The agent does not respond, so the manager retransmits the request at 5 second intervals in Frames 62 and 63. This is a fruitless exercise because the community name on the agent has been changed. The agent will not respond until the new community name is validated.

This case study illustrates several issues. First, the community name provides some access security for the agents. Second, SNMP is communicated via connectionless transport, which does not guarantee reliable delivery. Therefore, when the message did not seem to be getting across the LAN, the manager retransmitted the message in Frames 62 and 63. In fact, the message did get across the LAN, but it was not accepted because of the invalid community name.

This case study also presents a third, more subtle lesson. Recall from Section 3.3.4 that the IP routing table (MIB-II, RFC 1213) was replaced with the IP forwarding table in RFC 1354. This example shows that a manager does not conform to the current MIB standards. However, because the manager and agent MIBs were both out of date, the communication succeeds. If the manager MIB had been updated and no longer supported the IP routing table, an error would have been returned in response to the first GetNext request.


Previous Table of Contents Next