The RMON MIB is basically a MAC-level standard. Its visibility does not extend beyond the router port, meaning that it cannot see beyond individual LAN segments. As such, it does not provide visibility into conversations across the network or connectivity between the various network segments. Given the trends toward remote access and distributed workgroups, which generate a lot of intersegment traffic, visibility across the enterprise is an important capability to have.

RMON II extends the packet capture and decoding capabilities of the original RMON MIB to Layers 3 through 7 of the Open Systems Interconnection (OSI) reference model. This allows traffic to be monitored via network-layer addresses—which lets RMON “see” beyond the router to the internetwork—and distinguish between applications.

Analysis tools that support the network layer can sort traffic by protocol rather than just report on aggregate traffic. This means that network managers will be able to determine, for example, the percent of Internet Protocol (IP) versus Internet Packet Exchange (IPX) traffic traversing the network. In addition, these higher-level monitoring tools can map end-to-end traffic, giving network managers the ability to trace communications between two hosts—or nodes—even if the two are located on different LAN segments.

RMON II functions that will allow this level of visibility include:

  • Protocol directory table Provides a list of all the different protocols a RMON II probe can interpret.
  • Protocol distribution table Permits tracking of the number of bytes and packets on any given segment that have been sent from each of the protocols supported. This information is useful for displaying traffic types by percentage in graphical form.
  • Address mapping Permits identification of traffic-generating nodes, or hosts, by Ethernet or Token Ring address in addition to MAC address. It also discovers switch or hub ports to which the hosts are attached. This is helpful in node discovery and network topology applications for pinpointing the specific paths of network traffic.
  • Network-layer host table Permits tracking of bytes, packets, and errors by host according to individual networklayer protocol.
  • Network-layer matrix table Permits tracking, by networklayer address, of the number of packets sent between pairs of hosts.
  • Application-layer host table Permits tracking of bytes, packets, and errors by host and according to application.
  • Application-layer matrix table Permits tracking of conversations between pairs of hosts by application.
  • History group Permits filtering and storing of statistics according to user-defined parameters and time intervals.
  • Configuration group Defines standard configuration parameters for probes that includes such parameters as network address, serial line information, and SNMP trap destination information.

RMON II is focused more on helping network managers understand traffic flow for the purpose of capacity planning rather than for the purpose of physical troubleshooting. The capability to identify traffic levels and statistics by application has the potential to greatly reduce the time it takes to troubleshoot certain problems.

Without tools that can pinpoint which software application is responsible for gobbling up a disproportionate share of the available bandwidth, network managers can only guess. Often it is easier just to upgrade a server or a buy more bandwidth, which inflates operating costs and shrinks budgets.