Handbook of Local Area Networks, 1998 Edition:LAN Management Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next How RMON Works SNMP was designed to look at network devices. It was not designed to look at LAN segments in a holistic fashion. RMON, on the other hand, analyzes a LAN segment in terms of top packet producers and top error producers, among other functions. Also, unlike SNMP’s passive polling architecture, RMON provides interrupt-driven polling. The Open Systems Interconnection (OSI) world has long recognized the need to allow “smart” agents to report, on an exceptions-only basis, to a network management console. By setting thresholds (e.g., an error rate above 40% for a one-hour duration), RMON allows administrators to gauge the health of LAN segments and take proactive actions (e.g., disable an offending network interface card) before the LAN is disabled for all end users. RMON operates at level two (the data link level) of the International Standards Organization (ISO) OSI model — although filtering techniques can be used to view information at the network or third layer. RMON MIB and Ethernet Objects Interoperability The RFC 1271 standard established nine categories for the collection of internetwork statistics. These statistics can be used to set standards for interoperability among vendor products. In addition, the standard provides a means by which the data collected can be transported to a SMNP management console. This transport is accomplished by assigning the collection agents, or “probes,” unique IP addresses. The objects that the probes manage are given object identifiers (OIDs) according to the structure of management information depicted in Exhibit 7-1-4. For example, OID {1.3.6.1.2.1.16.1.1.1.13} identifies the object etherStatsCollisions. The RMON MIB collects variables in a compatible format with the SNMP MIB, but it examines a wider universe of variables than network-only MIBs. Many organizations have implemented distributed computing, but they have kept their network and systems administration centralized. IBM labels this structure “centributed computing,” and the RMON standard fits into this model well. Vendor implementations are, in the strict sense, RMON-compliant if they implement any of the nine categories. Many vendors have implemented all of the nine categories, and some vendors (such as Hewlett-Packard Co. and Armon Networking, Inc.) have sponsored interoperability testing (also known as the Aspen Agreement). THE NINE CATEGORIES OF THE RMON MIB (RFC 1271) These categories capture LAN-based statistics and provide filtering capabilities. The process flows like a state-based model (see Exhibit 7-1-4). Exhibit 7-1-4.  Overall Flow of RMON Statistics Group. The statistics group collects media-access specific statistics on the number of packets, broadcasts, bytes, errors, and collisions on a defined LAN segment for Ethernet and Token Ring. Each statistic can be further delineated into fragments (runts), frame alignment errors, and cyclic redundancy checking (CRC). The statistics and the host table groups, as depicted in Exhibit 7-1-4, are the two building blocks for RMON MIB. History Group. This category provides the capture function for statistics. It allows network administrators to collect segment statistics over a given period of time. Default sampling rates are provided. This category, combined with the statistics category, is essential for overall fault and performance management. Host Table. This category examines node-specific traffic statistics, such as: •  Packets sent and received. •  Broadcasts. •  Error packets sent. As new nodes are added to the LAN segment, this category collects, in default mode, statistics on the new clients. If the monitor finds itself short of buffer space, it will drop the row of data that pertains to the oldest (or first discovered) host on that LAN segment. The host table is essential for providing configuration and performance management information to the network and systems administrators. Host TopN. This category provides an SQL (structured query language)-like, ad hoc feature for RMON. It indicates the top five nodes that are: •  Sending data. •  Receiving data. •  Producing error packets. This feature is easily configurable and provides insight into unusual network activity. It is essential for collecting performance data and can be used in accounting reports for enterprises that maintain chargeback support to their clients. Traffic Matrix. The host table also feeds into the traffic matrix category. The traffic matrix category maps the number of packets and errors sent between any source and destination nodes. This information can also be integrated into overall performance and accounting reports. Alarms. This category provides the use of thresholds and sampling intervals on any counter maintained by the agent device. Based on the sophistication of the administrators, complex Boolean statements can be constructed to provide a fine degree of granularity in exception reporting. For example, both rising and falling counters may be maintained. An alarm could be set to report when error rates are less than 10% for an hour sampling period. By setting rising and falling thresholds, the number of trap commands is minimized, and network management traffic overhead is limited. SNMP cannot set complex Boolean counters on the variables that it samples. The alarm category is essential for developing a network baseline (the average performance of the network or particular LAN segments) and then gauging the health of the network over time. Filters. Filters allow packets to be matched, which then triggers packet capture events. Because many network problems are sporadic and difficult to isolate, this capability allows network administrators to sample traffic based on educated guesses and then decode them when the opportunity presents itself. In a simple context, this could mean isolating IPX packets. On a more complex level, it could mean isolating IPX packets between particular source and destination nodes that are greater than 1,000 bytes, but fewer than 2,000 bytes. Packet Capture. This group provides two capabilities: •  A buffer mechanism to segment captured packets or control what the trap does when the buffer is full. •  A trigger mechanism to automatically activate trace collection. Events. OSI-based management depends on events. Events enable the network manager to document network occurrences, such as exceeding a particular threshold, and time stamp the incident. This category of statistics collection allows the integration of SNMP-based trap messages. Unfortunately, there is not commonality of implementation among vendors of enterprise-specific traps. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.