www.ndc.nu RMON Remote MONitoring

RMON Remote MONitoring

Highlights

More comprehensive network fault diagnosis, planning, and performance tuning functionality.

Seamless multivendor interoperability between SNMP management stations and monitoring agents.

The Remote Network Monitoring Management Information Base (RMON MIB) defines the next generation of network monitoring with more comprehensive network fault diagnosis, planning, and performance tuning features than any current monitoring solution. It uses SNMP and its standard MIB design to provide multivendor interoperability between monitoring products and management stations, allowing users to mix and match network monitors and management stations from different vendors.
The RMON MIB enhances the features of typical remote monitoring agents with several new features, such as:

additional packet error counters;
more flexible historical trend graphing and statistical analysis;
an Ethernet level traffic matrix;
more comprehensive alarms;
more powerful filtering to capture and analyze individual packets.

RMON MIB software agents can be located on a variety of devices: Network interconnects such as bridges, routers, or hubs; dedicated or non-dedicated hosts; or customized platforms specifically designed as network management instruments. An organization may employ many devices with RMON MIB agents, one or more per network segment or wide area link, to manage its enterprise network. Each solution may offer different portions of the RMON MIB with unique price and performance characteristics.

RMON MIB Benefits

Comprehensive Monitoring: RMON MIB agents are a comprehensive and independent view of network performance. RMON MIB agents enhance and complement the management information available from typical hubs, bridges, or hosts. Depending upon implementation, the RMON MIB agent may be located on one of these devices to enhance its management information.
Multivendor Interoperability: RMON MIB remote monitoring agents can be easily integrated into the environment of most SNMP management consoles, allowing the user to mix and match vendor products.
Extended Management: Many devices, especially older or non-IP products, do not include network management agents and cannot communicate with SNMP consoles except through echo packets. RMON MIB agents monitor every network device and are often the only way to determine the performance of such unmanageable devices.
Proxy Management: Many SNMP management stations periodically send echo packets to check the status of each device. this large number of echo packets may impact the performance of the network and the SNMP console. The proxy management capability of an RMON MIB remote monitor is especially useful when the remote network is connected over a wide area link where periodic polls of devices would consume an unacceptably large percentage of bandwidth.
Extensibility: The creators of the RMON MIB planned for its future growth by designing its format for easy extensibility to other types of local area networks (such as Token Ring and FDDI) and wide area networks. this extensibility protects the investment in RMON MIB management products and speeds the development of new monitoring standards.
Multiple Management Stations: Because an organization may have several management stations and there can be multiple individuals managing a single network, the remote monitoring agent must often deal with several management stations concurrently. Using the RMON MIB each management station identifies the resources it is using in the agent, allowing other managers to reallocate the remaining resources for timely tasks.
Superior Performance: The RMON MIB structures data to deliver optimal performance in the interaction between the SNMP management station and RMON MIB agent. This improved performance results in faster presentations of agent data on the enterprise manager and less SNMP traffic on the network.

An understanding of this performance improvement requires an understanding of the operation of SNMP. Each row in a table of MIB values must include an index, or a value which uniquely identifies the row. For example, the RMON MIB host table includes traffic statistics for each host on the network and this table is indexed by the MAC address of each host. When the management station does not know the index value, as in the case when several MAC addresses have been discovered for the first time, the management station is limited to serial queries using the SNMP GetNext command to retrieve host information one address at a time. The RMON MIB specifies that row indexes in many tables start with the integer one and increase sequentially. Since the management station can usually predict the range of desired indexes, a single SNMP packet can include not just one but many data requests - improving speed and efficiency.

RMON MIB Features

The RMON MIB was developed by a working group of the Internet Engineering Task Force (IETF). The working group included leading SNMP management station and monitoring agent vendors and editorial support from Carnegie-Mellon University. After final approval as a Proposed Standard the RMON MIB will be placed in the Management portion of the Internet MIB with other standard MIBs. The RMON MIB is organized into nine groups; compliance with the RMON MIB standard does not require every MIB group, but does require support for every object within a selected group (RFC 1213). Each group can be enabled or disabled as desired in order to dedicate a number of RMON MIB agents to different purposes; one to tracing, one to maintaining a large host table, etc. Thus, customers of RMON MIB agents need to carefully determine the features they desire and seek to verify the existence of those features in actual products. An understanding of these groups will be fundamental to the user of an RMON MIB-compliant product.

Segment Statistics

The Statistics group provides segment-level Ethernet statistics. These statistics are 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. A real-time packet size distribution is also provided.
The number of collisions detected by the agent depends upon the capability of its internal or externally attached transceiver. Most agents will utilize external transceivers (sometimes failed media access units, or MAUs) supplied by the user. In these cases, the characteristics of the MAU are very important for an accurate count of collisions. The MAU should be receiver-based, meaning that it can detect all collisions on the segment. Transmit-based MAUs can detect collisions only when transmitting. Since network monitoring agents transmit very rarely, a transmit-based MAU would hide most of the collisions on the segment from view of the agent. Most MAUs made in the last 2 or 3 years are receiver-based and will provide the user an accurate count of all collisions. Check with your manufacturer for details.
The RMON MIB includes error counters for five different types of packets: Undersizes, fragments, CRC/Alignment errors, jabbers, and oversizes. These counters were defined to provide useful network management information beyond that provided by typical interface cards. For example, industry standard cards will provide only two separate counts of CRC and alignment errors which the card receives, and will not count well formed packets that are either too small or two large. These Undersize and Oversize packets are counted by the RMON MIB agent because they usually indicate communication software configuration problems in the transmitting station. Such packets will usually not be passed from the receiving card driver, resulting in failed transmissions.


           < 64 Bytes     64-1518 Bytes     >1518 Bytes
Good Pkts  Undersize      Good Packets      Oversize
Bad CRC(s) Fragment       CRC or Alnmt Err  Jabber



[Figure: The five RMON MIB categories for error packets.]

History

The History group provides historical views of the statistics provided in the Statistics group, with the exception of packet size distribution which is provided only on a real-time basis. The History group features user-defined sample intervals and bucket counters for complete customization of trend analysis.
The RMON MIB recommends two trend analyses. The first recommendation is for 50 buckets (or samples) of 30 second sample intervals, for a total time interval of 25 minutes. the second recommendation ifs for 50 buckets of 30 minute intervals, for a total time interval of 25 minutes. The second recommendation is for 50 buckets of 30 minute intervals, for a total time interval of 25 hours. Of course, users can modify either of these or add additional historical time interval studies; the total number of such studies is limited only by the resources of the specific agent. The sample interval can range from 1 second to 1 hour, creating the opportunity for long historical studies. Node traffic statistics from the Hosts group or user-defined packet match counters are not available for historical analysis in the standard RMON MIB.

Host Table

A host table is a standard feature of most current monitoring devices. The RMON MIB specifies a host table which includes node traffic statistics: Packets sent and received, octets sent and received, as well as broadcasts, multicasts, and error packets sent. In the host table, the classification "error sent" is the combination of undersizes, fragments, CRC/Alignment errors, jabbers, and oversizes sent by each node. In addition, the RMON MIB includes a host time table which shows the relative order 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 rather than the entire host table. this index entry improves performance and reduces necessary SNMP traffic on the network.

Host Top N

The Top N group extends the host table by providing sorted host statistics, such as the top 20 nodes sending packets or an ordered list of all nodes according to the errors they sent over the last 24 hours. Both the data selected and the duration of the study is 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 and a study begun, only the selected statics are maintained in the Host Top N counters, other statistics over the same time intervals are not available for later study. This extensive processing performed remotely in the RMON MIB agent reduces SNMP traffic on the network and the processing load on the management station, which would otherwise need to use SNMP to get the entire host table and sort it locally.

Traffic Matrix

The RMON MIB includes a traffic matrix at the Ethernet MAC 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.

Alarms

The Alarms group provides a versatile general mechanism for setting thresholds and sampling intervals to generate events on any counter or integer maintained by the agent, such as 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, and both can indicate network faults. For example, crossing a high threshold can indicate network performance problems; crossing a low threshold may point out the failure of a network backup scheduled to occur at midnight.
Thresholds can be established on both the absolute value of a statistic or its delta value, in order to be notified of rapid spikes or drops in a monitored value. Notice on the above graph that 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

The Filters group features a generic filter engine which activates all packet capture functions and events. Judging by the number of other groups which depend upon the Filters group, it is indeed critical to many of the advanced functions of an RMON MIB agent.
The filter engine fills the packet capture buffer with packets that match filters installed by the user. Any individual packet match filter can serve as a start or stop trace trigger. The contents of the trace buffer are controlled by any combination of user-selected filters. the conditions within a single filter can be combined in either boolean "and" or "not", multiple filters are combined with the boolean "or" function. Users can choose to capture packets that are valid or invalid, or are one of the five error packet types. With the proper protocol decoding capability at the management station, this sophisticated filtering will essentially provide distributed protocol analysis to supplement the use dispatched 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 long or the umbrella manager using an SNMP trap. Although these counters are not available to the History group for trending, a management station may trend these counters through regular polling of the monitor.

Packet Capture

Of course, the Packet Capture group depends upon the Filter group. The Packet Capture group includes the capability for users to create a multiple number of capture buffers and to control whether the trace buffers will wrap 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 upon the monitor to collect the trace without further manager intervention. The RMON MIB includes configurable capture slice sizes to store either the first few bytes of a packet where the various protocol headers are located or, at the limit, to store the entire packet. the default slice setting specified by the RMON MIB is the first 100 octets.

Events

Finally, the Events group provides the capability for users to create entries in the monitor log and/or SNMP traps from the agent to the management station on any event of the user's choice. Events can originate from a crossed threshold on any integer or counter or from any packet match count. Vendors may add other notification capability to include administrative events from the agent, such as a power failure or reset.
The log includes the time of day for each event and a description of the event written by the vendor of the monitor. The log wraps when full so events may be lost if not uploaded to the management station periodically. The rate which the log fills depends upon 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 a multiple number of management stations that each match the single community name destination specified for the trap. An RMON MIB agent will support each of the five traps required by the MIB II, RFC 1213: 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.

Product Availability

While one of the primary purposes of the RMON MIB is to standardize the basic features of distributed network monitoring products and insure interoperability, it will certainly not eliminate product differentiation. Each RMON MIB vendor will seek to provide unique solutions based on memory and CPU resources available in monitoring devices, value-added features above and beyond the standard, quality management applications, price, customer service and support, and availability.

Network Design & Control