![]() ![]() RMON2: To the Network Layer and Beyond! |
|
Navigating Some Black Holes
One major RMON vendor notably absent from this lineup is Frontier Technologies Corp., which has frequently referred to itself the past couple of years as "your RMON2 headquarters." Despite our extended testing period and our meetings with company officials throughout the year, Frontier refused to send us a product. It cited many reasons, and though a lack of RMON2 compatibility was not among them, we have no way of knowing for sure if this, in fact, was the primary obstacle. Note that Frontier hasn't participated in any public interoperability testing.
We also were disappointed that HP did not submit its NetMetrix product, which won our Editor's Choice award in our last RMON review. But we appreciated HP's up-front explanation: The vendor informed us that t he NetMetrix management software would not be RMON2-ready until sometime later this year. The company did send us an RMON2-compatible probe, and we used it for our interoperability testing with the management software from the other participating vendors. The HP probe proved to be more interoperable than any of the others we tested. Because RMON2 is likely to find a niche on your server networks, where Fast Ethernet no doubt links your routers and switches, we were curious about how well the vendors supported Fast Ethernet. Although no standard exists for Fast Ethernet, we always suspected that management applications would find it fairly simple to identify the speed of the interfaces and adjust their calculations by a factor of 10. Bay, SolCom and 3Com delivered Fast Ethernet probes. When we tested the four vendors' management applications against the three probes, we found that the applications experienced very little difficulty figuring out if an interface was Fast Ethernet. The one exception was Techni cally Elite's MeterWare, but as soon as we informed the company of the problems we encountered with some of the probes, it immediately began working on a fix. We also tested interoperability between each probe and management application, and though problems exist, we were encouraged to see that many of the applications worked just fine when we mixed them with other vendors' probes (see "How We Tested Interoperability," page 66). No standard is perfect and interpretation issues will always exist. As we were finishing our testing, most of the vendors involved were getting ready for another round of testing with Interworking Labs, which will give them ample opportunity to work out some of the more difficult interoperability issues. If you want to gain a good understanding of traffic patterns and application usage on your network--without sending around an army of highly paid network engineers with analyzers--the time is right to consider investing in RMON2 technology. Too Much of a Good Thing? We quickly found out that RMON2 provides a tremendous amount of data. This is generally a good thing for anyone involved in managing large networks. For example, an RMON2 probe can collect the common Ethernet statistics associated with every network-layer conversation. In addition, it can monitor identifiable protocols in the network layer and above. This protocol information also can be associated with every network-layer conversation, making it possible to answer lots of questions about traffic patterns on a network. For instance, you may want to know which protocols are taking up bandwidth, or which networks or users are making the most use of your servers. In the case of TCP/IP, the applications in use are easily identified. When we used probes to look at our Internet traffic, we unearthed the percentage of Web, e-mail, Usenet news and telnet traffic between our network and the Internet. We also identified our most popular network sites, as well as what our users were looking at. The Technically Elit e and SolCom products did a decent job of displaying the available data, but their value was limited on medium-to-large-sized networks. When we attempted to look at the top Web sites accessed from a particular subnet, we were only able to see individual conversations. In contrast, 3Com's Traffix aggregated the data into visual traffic patterns, letting us see the top sites accessed by the entire subnet or by our entire Class B network. It also made it easy for us to group networks and servers by department and examine these patterns by time of day. Bay's Optivity Analysis 8.0 software provided useful graphical views of traffic patterns, but was unable to archive data. And though Bay's NetReporter application included a more advanced report scheduler than that found in either the Technically Elite or SolCom products, it paled in comparison to Traffix, since it could not archive data and was not nearly as interoperable. Given the tremendous amount of data that can be collected in an RMON2 probe, you are not likely to see much of it implemented in hubs or switches very soon. In fact, though we were not able to systematically test performance this time around, we did notice that the probes had difficulty handling high traffic levels on busy 100-Mbps networks.
|
![]() |
![]() |
|
For the Side Bar on
Other FeaturesThis Issue
|
















