Future Network Considerations

Previous Table of Contents Next


Although RMON has worked miracles with many enterprise networks, it still has several issues surrounding its operation that need to be worked out. With the advent of high-performance switched internetworks, new RMON instrumentation solutions were required to counter the dramatically increased number of segments, and the development of Virtual LANs (VLANs) plus fast Ethernet inter-switched links. The two main drawbacks to RMON are:

  It only specifies monitoring and diagnostics for network traffic at the MAC layer (Data Link).
  Because the RMON-based probes view the traffic on the local LAN segment, they are not able to identify network hosts and sources beyond the router connection. To do so, a probe must have the capability of identifying traffic at the network layer that would provide statistics for all hosts accessing that segment, regardless of the location or connectivity of the network.


Notes:  
The downfall of RMON probes is that they need to be on each segment that you want to monitor. If, however, a device like a router is running RMON agent software, it too can be polled just like the probe.

This just goes to show that nothing answers 100% of the questions surrounding Enterprise networks.

RMON2

RMON2 overcomes these problems in several different ways. To begin with, by using RMON2-based probes, all RMON2 groups map into the major network-layer protocols such as IP, Novell’s IPX, OSI, AppleTalk, Banyan VINES, and DECnet, giving a complete start-to-finish view of all network traffic. Also, RMON2 includes the specifications for monitoring application-layer traffic. This enables the network managers to monitor network applications such as Lotus Notes, Telnet, and Microsoft Mail. This newly developed capability, to monitor application-layer traffic, enables network managers to be proactive in troubleshooting key application-layer traffic within the network. The RMON alarms, statistics, history, and host/conversation groups in the RMON MIB can now be utilized for troubleshooting and maintaining network functionality based upon application-layer traffic.

RMON2 adds the following key enhancements:

  Network layer host and matrix tables for monitoring layer 3 traffic by host, by conversations for various protocols, and for the standard RMON attributes such as utilization, packet rate, errors, and others
  Application layer host and matrix tables for monitoring layer 7 traffic by host, by conversations for various applications, and for the standard RMON attributes such as utilization, packet rate, and errors
  Network address mapping for aggregating the statistics by network address as well as MAC address for Ethernet and Token Ring networks
  Protocol Directory and Distribution groups for displaying selected protocols and their distribution for each LAN segment
  User-definable history, which now extends beyond RMON1 link-layer statistics to include RMON1, RMON2, MIB-I, or MIB-II statistics

The list that follows shows the various MIB groups found within RMON2 and what each brings to your network.

  Protocol Directory. Provides a table of protocols for the agent that will monitor and maintain statistics
  Protocol Distribution. Provides a table of statistics for each protocol in the directory
  Network Layer Host. Statistics for each network layer address on segment, ring, or port
  Network Layer Matrix. Provides traffic statistics for pairs of network layer addresses
  Application Layer Host. Provides statistics by application layer protocol for each network address
  Application Layer Matrix. Provides traffic statistics by application layer protocol for pairs of network layer addresses
  User Definable History. Extends history beyond the RMON1 link-layer statistics to include RMON, RMON2, MIB-I, or MIB-II statistics
  Address Mapping. Provides a list of MAC-to-network address bindings
  Configuration Group. Provides a list of agent capabilities and configuration

RMON Configuration Example

This section provides a brief example of how to configure RMON using Cisco’s IOS 11.1. It will detail the required IOS and provide a real life example for a 2500 series router.

Required Software

All IOS 11.1 or later software includes RMON alarms and events groups. In addition, full 9-group RMON support is available on the Ethernet port of 2500 series routers running the images detailed in Table 12-1.

Table 12-1 Images and feature sets for RMON
Image name Feature set

igs-im-l IP+RMON
igs-imn-l IP+IPX+RMON
igs-imnr-l IP+IPX+IBM+RMON
igs-imr-l IP+IBM+RMON
igs-jlm-l EN+CS+RMON
igs-jm-l EN+RMON

Basic Configuration

To enable full RMON support on an Ethernet interface of a 2500 series router, enter the following:

    interface Ethernet 0    rmon {native | promiscuous}    snmp-server community <community> RW    snmp-server host <ip address> <community> 

In native mode, RMON reports only on traffic through the router. In promiscuous mode, it reports on all traffic, including the traffic not destined for transmission through the router. Promiscuous mode is very CPU intensive. A performance hit of at least 20 percent per monitored Ethernet is not uncommon.

SNMP Read-Write access is necessary if you use an RMON console (such as Netscout).

The default size of the queue that holds the packets for analysis by RMON is 64 packets. To change the size of the RMON queue, type: rmon queuesize <size>

When you run in promiscuous mode, you will almost certainly have to increase the queuesize to prevent drops in the RMON input queue.

There is a hidden command to change the (default low) priority of the rmon process: rmon priority ( low | normal | high }


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net