What's New in LAN Management

Gilbert Held

Most readers are more than likely familiar with the mnemonics SNMP and RMON, long considered the dynamic duo of LAN management. Although the Simple Network Management Protocol (SNMP) and Remote Monitoring (RMON) provide the tools to monitor a variety of devices to include the performance of T1 circuits and Frame Relay services, the primary focus for the use of SNMP and RMON is in the area of supporting LAN management. Concerning this area of support, within the past few years a significant effort of various working groups within the Internet Engineering Task Force (IETF) and other organizations resulted in the development of a new remote monitoring standard referred to as RMON Version 2 as well as a considerable amount of effort toward the promulgation of the SNMPv3 standard, which is designed to address many of the shortcomings of existing standards. Because an appreciation of the benefits of RMON Version 2 and SNMPv3 is better understood by a review of existing and initial standards, let's turn our attention to SNMPv1 and the initial RMON standard. Doing so will provide us with a foundation to note the improvements provided and planned for by succeeding versions of device and facility management technology.

SNMP

SNMP is a client-server technology that enables predefined types of management information to be collected from different types of networking devices. There are three key components associated with SNMP, a management platform, agent, and database referred to as a Management Information Base (MIB). Figure 1 illustrates the relationship of the three components.

In examining Figure 1, note that the management platform issues commands to one or more agents to extract predefined information from one or more MIBs maintained by the agent. To do so, the management platform must specify two metrics - the address of the agent and the address of an object in the MIB. The first address is normally an IP address, since SNMP was designed to operate within the TCP/IP protocol stack, which uses IP addressing to route data from source to destination. The second address represents the global identifier of the desired object in the MIB.

Global identifiers represent a standardized mechanism for defining predefined objects. Some global identifiers are universally defined, while others represent extensions via enterprises that enable different organizations to include academia, government, and commercial firms to define the location of objects. To facilitate reference to a series of related objects, such objects are commonly included within a relevant group name. For example, the IP group represents a universally defined group, which includes objects that provide incoming and outgoing traffic statistics, certain error counts, and similar Internet protocol-related information.

The get and response commands shown in Figure 1 represent two of five SNMPv1 commands. In actuality, the more formal names for those commands are get-request and get-response.

Although SNMPv1 is currently by far the most popular version of the protocol in use, it has a number of key constraints. Some of those constraints include the lack of encryption and authentication, and the inability to support inter-management station communications. The first two constraints can be easily noted from an examination of Figure 2, which illustrates a portion of the configuration process of a management station required to access an RMON probe.

In this example, the person configuring the management station is in the process of entering the IP address of an RMON probe. Note the default SNMP get and set community entries are shown as the strings public. Under SNMPv1, security or perhaps a more appropriate term of password control is effected through the use of community names. To retrieve information from an agent an SNMP get message must include a community name that matches the community name configured on the destination agent. Similarly, the issuance of an SNMP set command must include a community name that will also be matched against the community name configured for the agent. If the community name in the command matches the agent's pre-configured community name and the command is legal, the command is exercised. Otherwise, the command is rejected.

Figure 3 illustrates the configuration of an SNMP probe or agent. Note that although the well-known defaults of public are used for get and set commands, a different name was assigned to the trap community. A trap command works in reverse to get and set commands. That is, an agent can be configured to transmit alert messages via the use of trap commands to a management station upon the occurrence of different predefined conditions, such as network utilization reaching a certain level. To do so, the agent's trap community name must match the trap community name assigned to a specific management station to which the agent will issue traps.

Although a community name can be any set of octets that provides an extremely large number of possible combinations for a hacker to try, there are two deficiencies with what is essentially an "in-the-clear" password transmission scheme used by SNMPv1. First, like ftp passwords, SNMPv1 community names are transmitted in the clear. This means that many persons with a $49.95 decoder or a more expensive protocol analyzer can learn the community name.

A second problem concerns the lack of authentication. Once a community name is learned, any station with the capability to issue SNMP commands could conceivably issue a set command and reboot your enterprise router or perform some other operation. Because of this security risk, many equipment manufacturers do not include support for the SNMP set command, which further restricts the capability of SNMPv1.

The Evolution of SNMP

In addition to lacking authentication and encryption, SNMPv1 has several other shortcomings. These shortcomings include the inability of one management station to communicate with another, poor error handling, and inefficiency in retrieving objects from tables in an MIB. Although it was the intention of IETF to address each of these shortcomings in SNMPv2, the good intentions of many members of the working group were overshadowed by differences in opinion concerning the complexity of the standard and the manner in which to implement security. This resulted in SNMPv2's primarily being restricted to improvements that provided a more efficient error handling capability, the addition of a get-bulk command to provide a more efficient mechanism for retrieving objects stored in tabular form, and the addition of an inform-request command, which enables one manager to communicate with another. SNMPv2 is commonly referred to as SNMPv2c, with the lower case c used to identify the fact that security involves the use of community names. Although SNMPv2 provided significant improvements over the prior network management protocol with respect to transmitting management information between management stations, enhanced error handling, and the use of 64-bit counters to support modern high-speed network statistics gathering, it still lacks security.

Concerning security, two competing proposals evolved, referred to as SNMPv2 and SNMPv2*. After a considerable period of time during which proponents of each proposal continued to maintain divergent views, the IETF formed a working group that essentially took the best elements of each proposal and layered it upon the work of the SNMPv2 working group. The resulting effort is SNMPv3, the specifications of which were published in January, 1998 as a Proposed Standard in a set of five RFCs (RFC 2271 through RFC 2275). In October, 1998 SNMPv3 specifications were submitted as Draft Standards and are expected to be finalized during 1999.

SNMPv3 is more complex than earlier versions as it includes provisions to support SNMPv2 and SNMPv1 message processing. Thus, an SNMPv3 management station should be capable of supporting legacy SNMP agents as well as more modern agents that will support encryption and authentication. When the latter occurs, it could become feasible to manage LANs via an organization's Internet connection without having to go to the expense of constructing tunnels through the Internet. Now that we have an appreciation for the state of SNMP, let's turn our attention to RMON.

RMON's Evolution

SNMP is a polling protocol that, with the exception of the trap command, requires the management station to query an agent to retrieve objects. When the management station is located on the same segment as the agent, periodic polling of the agent by the management station does not result in a significant impact on the bandwidth of the segment. This is because the bandwidth of a LAN segment is in the Mbps range, while the quantity of data transferred is relatively small. However, when the management platform is located on a different segment from the agent and the two segments are connected by a relatively low-speed WAN connection, the effect of periodic polling would be much more pronounced. Due to this, the Remote Network Monitoring Management Information Base (RMON MIB) was published as RFC 1271 in 1991.

RFC 1271 defines a large number of variables required to monitor an Ethernet LAN. That RFC was followed by one that added Token-Ring data to RMON. Manufacturers quickly developed RMON probes. An RMON probe is a bit of hardware, which functions as a remote agent with a particular MIB and which gathers statistics that can be retrieved by a local or remote management station.

Similar to SNMP MIBs, RMON MIBs are organized into groups. For example, the original RMON MIB contained nine groups. Those groups can be further categorized by the basic function of each group. For example, there are four groups that provide traffic and error statistics - statistics, history, host, and hostTop N. The original RMON series of MIBs represents objects associated with data link layer operations. Although the resulting objects can provide significant amounts of valuable information concerning the operation of a remote network, they have serious restrictions. Those restrictions are primarily a result of the initial version of RMON's inability to look further into LAN frames to provide information concerning higher layer operations. For example, the inability to examine network layer traffic results in the inability of RMON to provide information concerning the distribution of IP, IPX, and other network layer traffic. Such information could be quite valuable when attempting to ascertain the cause of network bottlenecks. Similarly, the inability of the initial version of RMON to look higher up the protocol stack made it impossible to perform certain analysis tasks.

Another key limitation of the initial version of RMON concerns the number of probes you may need to monitor network traffic, the placement of these probes, and the effort required in an attempt to determine inter-network traffic flow. If your organization operates two or more LANs connected by a WAN under the first version of RMON, you would have to place a probe on each segment and manually examine traffic flow to each router's MAC address. Then you would have to correlate the traffic to determine the inter-network traffic flow. Even though most routers support the installation of an RMON module that replaces the necessity for installing a separate RMON module on each link, you would still need either probes or modules on each LAN and have to manually compute internetwork traffic.

Recognizing the preceding problems resulted in the publication of RFC 2021 for RMON Version 2. Because RMON Version 2 extends monitoring above the data link layer, it becomes a relatively simple process to examine the flow of data from one LAN address to another. Additionally, because WAN links usually saturate far faster than LANs, you might wish to consider placing RMON version 2 probes or compatible router modules selectively throughout a network instead of locating them on each LAN segment. Because RMON version 2 is capable of examining traffic flows between networks, you have more flexibility with respect to their location.

Figure 4 illustrates the distribution of packets flowing on a remote network. Note that this packet distribution is based on the network application and would not be possible to determine if you were using equipment supporting the original version of RMON. Thus, in addition to providing a higher degree of network monitoring flexibility, the use of RMON2-compatible hardware and software lets you obtain detailed information concerning the distribution of traffic based on applications. This information can be of considerable assistance in determining when and how to modify existing network structures, since proper planning often precludes poor performance.

Conclusion

By the end of this year, we can expect SNMPv3 products that will be compatible with previously purchased SNMPv1 and SNMPv2 devices to reach the market. In the interim, because of the backward compatibility of SNMPv3 to prior versions of the standard, you should consider installing upgradable management stations and RMON probes as needed, rather than waiting for the latest version of a product.

Concerning RMON, over the past few years the development of software-based RMON products and advances in PC technology have permitted the economical deployment of management tools over the purchase of more expensive probes. For example, for approximately $500, you can purchase RMON software that runs on a PC platform. For another $750, you can purchase a 300 MHz system with an Ethernet adapter card, resulting in a cost of $1250 for a "do it yourself" probe. Because most RMON software simply stores statistics in memory, you can skimp on your hard drive and can even use a 14-inch monitor that will more than likely be rarely used since you will use a management station to converse with your probe. With the cost of PCs rapidly falling while their level of performance increases, there is literally no excuse for small and medium-sized organizations to say that it's too costly to monitor their networks.

About the Author

Gilbert Held is an award-winning author and lecturer. He is the author of over 40 books and 250 technical articles. Some of Gil's recent books include Working with Network Based Images, High Speed LAN Switching, and LAN Management with SNMP and RMON, all published by John Wiley & Sons of New York and Chichester, England. Gil can be reached via email at 235-8068@mcimail.com.