RMON, the New SNMP Remote Monitoring Standard Nathan J. Muller

Transcription

1 RMON, the New SNMP Remote Monitoring Standard Nathan J. Muller Payoff The Remote Monitoring (RMON) Management Information Base (MIB) is a set of object definitions that extend the capabilities of the Simple Network Management Protocol (SNMP). RMON is not used to directly manage the devices on the network. Instead, probes equipped with RMON agents passively monitor data transmitted over LAN segments. The accumulated information is retrieved by the central management system using SNMP commands. Introduction RMON enhances the management and control capabilities ofsimple Network Management Protocol-compliant network management systems and LAN analyzers. Remote MONitoring equipped probes can view every packet and produce summary information on various types of packets, such as undersized packets, and events, such as packet collisions. The probes may also store information for further analysis by capturing packets according to predefined criteria set by the network manager or test technician. For example, the network manager might only be interested in examining NetWare packets to track down the source of an intermittent problem that occurs when opening files at a remote server. According to an established threshold, an alarm can be generated if there is more than one file-open error per 100 file opens. Packets that match the filter criteria are stored in the probe's memory, while those that do not match are discarded. At any time, the SNMP-based management console can query the RMON probe for this information so that detailed analysis can be performed. Once stored, a remote manager can play back the error history of any station to pinpoint where and why an error occurred. RMON agents are becoming available for a variety of products, including Network Interface Cards (NICs), the network modules of intelligent hubs, and the boards of bridges and routers. RMON has been so widely accepted by the vendor community that it will not be long before just about any device that is attached to the network regardless of media and is manageable with SNMP can be optionally equipped with RMON agent. Initially, RMON defined media-specific objects for Ethernet only. Media-specific objects for Token Ring have recently been added and those for the Fiber Distributed Data Interface (FDDI) are anticipated in the near future. The RMON Management Information Base is organized into optional object groups with the following associated variables: Statistics Group. Maintains low-level use and error statistics (e.g., number of packets sent, broadcasts, and collisions). History Group. Provides user-defined trend analysis based on information in the statistics group. Host Table Group. For each host, contains counters for broadcasts, multicasts, errored packets, bytes sent and received, and packets sent and received.

2 Host Top N Group. Contains sorted host statistics (e.g.,a complete table of activity for the busiest nodes communicating with each host. N indicates the number of nodes specified by the network manager. Alarms Group. Allows a sampling interval and alarm threshold to be set for any counter or integer recorded by the RMON agent. Filters Group. Provides a buffer for incoming packets and user-defined filters. Packet Capture Group. Allows buffers to be specified for packet capture, buffer sizing, and the conditions for starting and stopping packet capture. Events Group. Logs events (e.g., packet matches or values that rise or fall to userdefined thresholds). Traffic Matrix Group. Arranges use and error information in matrix form to permit the retrieval and comparison of information for any pair of network addresses. Compliance with the RMON MIB standard (Request for Comment 1213) requires that the vendor provide support for every object within a selected group. Each group is optional, so when selecting RMON MIBagents users should determine the features they require and verify that those features are included in actual products. What follows is a more detailed discussion of the features provided by each group. Statistics Group The Statistics Group provides segment-level statistics. For an Ethernet segment, for example, these statistics show packets, octets(or bytes), broadcasts, multicasts, and collisions on the local segment, as well as the number of occurrences of dropped packets by the agent. Each statistic is maintained in its own 32-bit cumulative counter. Real-time packet size distribution is also provided. The number of collisions detected by the agent depends on the capability of its internal or externally attached transceiver, or Media Access Unit. The Multistation Access Unit should be receiver-based, meaning that it can detect all collisions on the segment. The Remote MONitoring Management Information Base includes error counters for five different types of packets. For Ethernet, for example, the following types of errors are counted: Undersizes (runts). Ethernet packets of less than 64 bytes, which are usually caused by a collision on the network. A normal Ethernet packet is 1,518 bytes. Excessive runt packets may indicate that the transmitting station is not configured properly. Fragments. A packet whose total length is less than 64 bytes (excluding framing bits) and is not an integral number of octets in length or which has a bad frame check sequence. CRC and alignment errors. Cyclic redundancy check (CRC)is the last 32 bits of information contained in a packet or frame and is used for detecting transmission errors. When the Cyclic Redundancy Checking value of an incoming frame is not identical to the CRC value of an outgoing frame, a bit flop is said to occur, which generates a CRC error. This is usually caused by faulty cable, as when an impedance

3 mismatch occurs, causing a reflection on the cable, which in turn causes the bit flop. An alignment error is a packet that is not an integer number of bytes in length and is between 64 and 1,518 bytes in length (including the frame check sequence but excluding the framing bits) or which has a bad frame check sequence. An alignment error is most often caused by a frame collision on the network, although loose connections or noisy cable can also be the cause. Collisions. Data sent by a device on the network without regard for any other devices that may also be trying to transmit. When two or more devices try to transmit at the same time, a collision occurs, a situation that causes the signals to collide and the data to become garbled. Oversizes (giants). A packet that exceeds the maximum 1,518 bytes (excluding framing bits but including the frame check sequence), and which has a good frame check sequence. This type of packet can be caused by a node that is not configured properly. These counters provide useful network management information beyond that provided by typical network interface cards, for example. Industry-standard cards usually provide only two separate counts ofcrc and alignment errors, and will not count packets that are either too small or too large. These runt and giant packets are counted by the RMON MIB agent because they usually indicate configuration problems in the transmitting station. Such packets usually are not passed from the receiving card driver, resulting in failed transmissions. History Group With the exception of packet size distribution, which is provided only on a real-time basis, the History Group provides historical views of the statistics provided in the Statistics Group. The History Group responds to user-defined sampling intervals and bucket counters, allowing for the complete customization of trend analysis. The Remote MONitoring Management Information Base comes with two defaults for trend analysis. The first provides for 50 buckets (or samples) of 30-second sampling intervals over a period of 25 minutes. The second default provides for 50 buckets of 30- minute sampling intervals over a period of 25 hours. Users can modify either of these or add additional intervals to meet their specific historical analysis requirements. For example, the sampling interval can range from 1 second to 1 hour. Host Table Group A host table is a standard feature of most current monitoring devices. The Remote MONitoring Management Information Base specifies a host table that includes node traffic statistics: packets sent and received, octets sent and received, broadcasts, multicasts, and error packets sent. In the host table, the classification errors sent is the combination of undersizes, fragments, Cyclic Redundancy Checking and alignment errors, jabbers and oversizes sent by each node. The RMON MIB also includes a host timetable that shows the relative order in which each host was discovered by the agent. This data is not only useful for network management purposes, but also assists in uploading to the management station only those nodes of which it is not aware. This index entry improves performance and reduces unnecessary Simple Network Management Protocol traffic on the entwork.

4 Host Top N Group The Host Top N Group extends the host table by providing sorted host statistics (e.g., the top 10 nodes sending packets or an ordered list of all nodes according to the errors sent over the last 24hours). Both the data selected and the duration of the study are defined by the user at the network management station, and the number of studies is limited only by the resources of the monitoring device. When a set of statistics is selected for study, only the selected statistics are maintained in the Host Top N counters; other statistics over the same time intervals are not available for later study. This processing performed remotely in the Remote MONitoring Management Information Baseagent reduces Simple Network Management Protocol traffic on the network and the processing load on the management station. The station would otherwise need to use Simple Network Management Protocol to get the entire host table and sort it locally. Alarms Group The Alarms Group provides a general mechanism for setting thresholds and sampling intervals to generate events on any counter or integer maintained by the agent (e.g., segment statistics, node traffic statistics defined in the host table, or any user-defined packet match counter defined in the Filters Group). Both rising and falling thresholds may be set, because both can indicate network faults. For example, crossing a high threshold can indicate network performance problems; crossing a low threshold may signal the failure of a scheduled network backup. Thresholds can be established on both the absolute value of a statistic or its delta value, so the manager is notified of rapid spikes or drops in a monitored value. Rising and falling thresholds work together in an alternating fashion. After a rising threshold is crossed, another rising event is not generated until the matching falling threshold is crossed. Filters Group The Filters Group provides a generic filter engine that implements all packet capture functions and events. The filter engine fills the packet capture buffer with packets that match the user-specified filtering criteria. Any individual packet match filter can serve as a start or stop trace trigger. The conditions within a single filter can be combined using the boolean parameters and or not. Multiple filters are combined with the boolean or parameter. Users can choose to capture packets that are valid or invalid, or are one of the five error packet types (discussed previously). If the proper protocol decoding capability is in place at the management station, this filtering essentially provides distributed protocol analysis to supplement the use of technicians equipped with portable protocol analyzers. The monitor also maintains counters of each packet match for statistical analysis. Either an individual packet match, or a multiple number of packet matches through Alarms, can trigger an event to the log or the network management system using an Simple Network Management Protocol trap. Although these counters are not available to the History Group for trend analysis, a management station may request these counters through regular polling of the monitor so that trend analysis can be performed.

5 Packet Capture Group What packets are collected is dependent on the Filter Group. The Packet Capture Group allows users to create multiple capture buffers and to control whether the trace buffers will wrap (overwrite) when full or stop capturing. Depending on the agent, the user may expand or contract the size of the buffer to fit immediate needs for packet capturing without permanently committing memory that will not be needed later. The network manager can specify a packet match as a start trigger for a trace and depend on the monitor to collect the trace without further manager involvement. The Remote MONitoring Management Information Base includes configurable capture slice sizes to store either the first few bytes of a packet where the protocol header is located or to store the entire packet. The default slice setting specified by the RMON MIBis the first 100 octets. Events Group The Events Group is used to create entries in the monitor log or to create Simple Network Management Protocol traps, from the agent to the management station, on any specified event. An event can be a crossed threshold on any integer or counter or from any packet match count. Vendors may add other notification capabilities, including administrative events from the agent (e.g., a power failure or reset). The log includes the time of day for each event and a description of the event. The log wraps (overwrites) when full, so events may be lost if they are not uploaded to the management station periodically. The rate at which the log fills depends on the resources the monitor dedicates to the log and the number of notifications the user has sent to the log. Traps can be delivered by the agent to multiple management stations if each station matches the single community name destination specified for the trap. An Remote MONitoring Management Information Base agent will support each of the five traps required by SNMP: link up; link down; warm start; cold start; and authentication failure. Three additional traps are specified in the RMON MIB: rising threshold; falling threshold; and packet match. Traffic Matrix Group The Remote MONitoring Management Information Base includes a traffic matrix at the Media Access Control layer. A traffic matrix shows the amount of traffic and number of errors between pairs of nodes one source and one destination address per pair. For each pair, the RMON MIB maintains counters for the number of packets, number of octets, and error packets between the nodes. Users can sort this data either by source or destination address. Benefits of RMON RMON is typically offered as an optional expansion package to vendors' Simple Network Management Protocol-compliant network management systems, facilitating the gathering of information from network devices, which can be used for fault diagnosis, performance tuning, and network planning. Although the standard Management Information Base II is designed to provide real-time protocol management for devices that use the Exterior Gateway Protocol (EGP), Internet Protocol (IP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), and SNMP, the accumulation of historical performance data requires that

6 the network management station constantly poll every network device and store the data itself. In many cases, however, historical data is better gathered at the network device itself, and only retrieved occasionally by the network management station. This is exactly what the Remote MONitoring Management Information Baseis designed to do. It reduces network overhead caused by SNMP polling and reduces network management system processing overhead. RMON also can be used to provide proxy management, either intercepting SNMP requests for other agents, or acting as an agent for network devices that are not SNMP-compliant. In the case where multiple management stations are trying to manage a single agent, a proxy agent can shield the real agents from redundant requests, and can respond for them. Proxies also can send a single agent's trap to multiple management stations. Proxies can reduce the amount of SNMP traffic hitting the network, enhance Simple Network Management Protocol security and be used to manage proprietary network devices or devices such as MAC-level bridges, wiring hubs or modems that work below the network layer of the Open Systems Interconnection reference model. In-Band and Out-Of-Band Activities All monitoring and control interactions between agent modules and network management stations occur using Simple Network Management Protocol. The information collected by Remote MONitoring-compliant devices can be sent to the central management station in either of two ways: in-band through the data stream or out-of-band through an RS-232 serial link and modem. In-band transport protocol options include standard User Datagram Protocol/Internet Protocol (UDP/IP), and UDP/IP encapsulated within source-routed frames (which allows the SNMP traffic to pass through internetworks joined by sourcerouting bridges). In-band management can also be conducted over a Telnet session running over the LAN. Out-of-band management may be accomplished through modem connection to an RS-232 port, or by using the Serial Line Internet Protocol (SLIP) or the Point-to-Point Protocol (PPP) over router-based WAN c onnections when the network management system is remotely located. The modem connection can be used as a backup, allowing outof-band communications should in-band communications fail. Conclusion RMON provides the benefits of standardization, including multivendor support and potential commodity pricing. As the vendor community continues to offer Remote MONitoring-compliant products, users will be able to mix and match them and manage them from a single network management system. The RMON Management Information Base is a more flexible and economical solution to monitoring network performance than the proprietary systems currently on the market. Many of these vendors are expected to support Remote MONitoring, so products already purchased may only have to receive software upgrades to be of continued use. Author Biographies Nathan J. Muller Nathan J. Muller is an independent consultant in Huntsville, Alabama specializing in advanced technology marketing and education. With 22 years of industry experience, he

7 has written extensively on many aspects of computers and communications, having published seven books and over 500 articles. He has held numerous technical and marketing positions with such companies as Control Data Corporation, Planning Research Corporation, Cable & Wireless Communications, ITT Telecom, and General DataComm, Inc. He has an M.A. in Social and Organizational Behavior from George Washington University.