Taking an Enterprise View with RMON2
For those of you who have seen the term -- but don't know what it means -- RMON stands for Remote Network Monitoring MIB. Originally specified by the Internet Engineering Task Force (IETF) as a means to monitor and to do protocol analysis on Ethernet and Token Ring LANs, RMON has become one of the industry's most successful network management standards.
When deployed, RMON complies with the client/server model of computing. The client resides on the network management station and presents the RMON information to the user. The servers, in turn, are the monitoring devices that are distributed throughout the network. It's their job to collect and analyze the RMON information.
Typically, the server is referred to as a probe, which is an agent that does the actual network management work. RMON agents can be sprinkled throughout the network in several ways: as a standalone dedicated device or in an integrated fashion where the agent is incorporated into a switch or router.
The benefit of RMON's client/server architecture is related to load, both on the network and on the management station. When deployed and in operation, it is the agent inside the probe that is responsible for all the data collection and data processing. As a result, traffic on the network -- and load on the network management station -- is kept to a minimum.
Elegant technology aside, RMON's success is due to the network management capabilities it enables. With RMON probes deployed, network managers can monitor a LAN segment located in their home office or one located on the other side of the globe. Should a problem arise, RMON enables them to isolate and troubleshoot problems via its protocol analysis tools.
As good as it is, RMON could be improved. That is the idea behind RMON2. The difference between the two versions lies in the layers of the Open Systems Interconnection (OSI) reference model that can be monitored. The original RMON was restricted to the lower two layers of the protocol stack. As a result, it was restricted to information gathering on the MAC and physical layers. RMON2 takes over where its progenitor stops. The newer version can monitor traffic all the way up to the application layer. But note that the two versions of RMON are complementary -- RMON2 is not a replacement for RMON. To get coverage over the entire protocol stack, both RMON and RMON2 must be used.
Technology aside, what does RMON2 really deliver to the network manager? The difference between the two versions can be described in terms of "view or perspective." Limited to the lower two layers of the protocol stack, RMON constrained the network manager's view to activity occurring on a particular LAN segment. In contrast, RMON2 gives the network manager an entirely new perspective on applications as well as the enterprise network itself.
For example, RMON2 is aware of events occurring at the layer-3 networking level. Therefore, it can keep track of different protocols that might be in use in the enterprise. As a result, network managers now have a tool that can identify the protocols being used -- such as IPX or IP -- as well as the usage levels that are occurring for each. Since it can also monitor the application layer -- layer-7 in the protocol stack -- RMON2 can watch traffic on an end-to-end basis. It can track specific users who are accessing specific applications at specific sites: HTML users, for example, vs. Lotus Notes users.
The differences between RMON and RMON2 were finalized in 1997. Over the past few months an increasing number of network management applications have been announced with full RMON2 capability. Agents are now available for standalone dedicated probes as well as those integrated in switches and routers. RMON2 should give network managers a new view of their enterprise networks. --Sam Alunni is vice president of networking at Sterling Research (Sterling, Mass.). Contact him at [email protected].