Interoperability Report for RFC 1757 Andy Bierman RMONMIB WG Chair April 7, 1999 1.0) Introduction Interoperability documentation must be gathered to support the advancement of documents on the IETF standards track. This memo documents the agent and NMS implementations of the RMON MIB, and intends to demonstrate that RFC 1757 should be advanced from Draft Standard to Full Standard by the IESG. 1.1) Background The following email was sent by the WG Chair to the RMONMIB WG mailing list (rmonmib@cisco.com) on November 20, 1998: In accordance with section 5 of RFC 2438, I am requesting that parties which have implemented all or part of RMON MIB (RFC 1757) send an implementation report to the WG mailing list or a private email to me. The WG is attempting to advance RFC 1757 from Draft Standard to Internet Standard status. This implementation report should include the following information: - specify MIB objects implemented and/or not implemented - specify for each object whether the implementation is for agent, NMS, or both. - specify at least one product name and SW version that contains the implementation. This does not have to be a commercial implementation. - specify origin of the implementation(s), e.g. internal development or purchased engine code from XYZ corp. or a combination of both. - specify any independent product implementations that you believe your product(s) to interoperate with. Be specific as to agent vs. application, and which MIB objects are used. I will compile an interoperability report and forward it to the OPS Area Directors when the survey is completed. The survey will close in 6 weeks (on 1-1-99). [Actual survey close: 3-12-99] --------------------------------------------------------------- 2) Interoperability Summary The following charts show the MIB groups implemented and the multi-vendor interoperability for RFC 1757. These tables are derived from the detailed responses from each implementor. Table 1: Implementation Summary ------------------------------- MIB Group | V1 | V2 | V3 | V4 | V5 | V6 | V7 | V8 | V9 | -----------+----+----+----+----+----+----+----+----+----+ Stats | A | AM | AM | AM | Am | A | AM | M | AM | -----------+----+----+----+----+----+----+----+----+----+ History | A | AM | AM | AM | A | A | AM | | AM | -----------+----+----+----+----+----+----+----+----+----+ Alarm | AM | AM | AM | AM | A | A | AM | | AM | -----------+----+----+----+----+----+----+----+----+----+ Host | A | AM | AM | AM | A | A | AM | M | AM | -----------+----+----+----+----+----+----+----+----+----+ HostTopN | A | AM | AM | AM | A | A | AM | M | AM | -----------+----+----+----+----+----+----+----+----+----+ Matrix | A | AM | AM | AM | Am | A | AM | | AM | -----------+----+----+----+----+----+----+----+----+----+ Filter | A | AM | AM | AM | A | A | AM | | AM | -----------+----+----+----+----+----+----+----+----+----+ Capture | A | AM | AM | AM | A | A | AM | | AM | -----------+----+----+----+----+----+----+----+----+----+ Event | AM | AM | AM | AM | A | A | AM | | AM | -----------+----+----+----+----+----+----+----+----+----+ Key --- a = partial agent implementation A = full agent implementation m = partial manager application implementation M = full manager application implementation Vn = Vendor code, listed below ------------------------------ V1 = Cisco Systems V2 = SolCom V3 = HP V4 = Bay/Nortel Networks V5 = 3Com V6 = IBM V7 = Netscout V8 = INS V9 = Technically Elite Table 2: Interoperability Matrix -------------------------------- Mgr Apps ---> Agents | V | V1 | V2 | V3 | V4 | V5 | V6 | V7 | V8 | V9 | Other ----+----+----+----+----+----+----+----+----+----+------+ V1 | X | | | | | | X | | | | ----+----+----+----+----+----+----+----+----+----+------+ V2 | | X | X | X | X | | X | | X | X | ----+----+----+----+----+----+----+----+----+----+------+ V3 | | X | X | | X | | | | X | X | ----+----+----+----+----+----+----+----+----+----+------+ V4 | | X | | X | | | | | X | | ----+----+----+----+----+----+----+----+----+----+------+ V5 | | X | | | X | | | | | | ----+----+----+----+----+----+----+----+----+----+------+ V6 | | | | | | X | | | | | ----+----+----+----+----+----+----+----+----+----+------+ V7 | X | X | | | | | | X | | | ----+----+----+----+----+----+----+----+----+----+------+ V8 | | | | | | | | | | | ----+----+----+----+----+----+----+----+----+----+------+ V9 | | X | X | X | X | | | | X | X | ----+----+----+----+----+----+----+----+----+----+------+ Other | | X | | | X | | X | | | | ----+----+----+----+----+----+----+----+----+----+------+ Key --- X = interoperability reported Vn = Vendor code, listed below ------------------------------ V1 = Cisco Systems V2 = SolCom V3 = HP V4 = Bay/Nortel Networks V5 = 3Com V6 = IBM V7 = Netscout V8 = INS V9 = Technically Elite 3) Conclusions Based on the survey responses received, there is sufficient evidence to recommend to the IESG that RFC 1757 should be advanced from Draft Standard to Full Internet Standard status. This MIB has been deployed in commercial products by many venders, and has been proven useful over the years by the customers of these vendors. There are more implementations of part or all of this RFC than are documented in this implementation report, because no anonymous reports are included. In some cases of 'known implementations', th authors/owners of the implementation did not respond the survey at all. Originally, this MIB was intended for standalone probes with one or two 10 MBit Ethernet interfaces. Dataquest estimates that this market segment (ethernet probes) will reach $2 billion by the year 2000. The RMON MIB has also been deployed in many traditional networking devices, such as repeaters, routers, and switches. This market may eventually surpass and even replace the traditional probe market. Many sophisticated NMS applications have also been deployed which utilize the data provided by RMON agents. There are many types of RMON applications, because the RMON MIB contains so many different features. For example, a thresholding application may use the only RMON alarm and event groups, and a protocol debugging application may rely mostly on the filter and capture groups. There are also some 'RMON console" applications which provide configuration and integrated reporting functions for all the RMON groups. In the future, it is likely that RMON agent and NMS applications will utilize some or all of many different MIBs, such as the RMON MIB (RFC 1757), RMON-2 MIB (RFC 2021), High Capacity RMON (HC-RMON MIB), RMON Extensions for Switches (SMON-MIB), Entity MIB (RFC 2037), and Interfaces MIB (RFC 2233). RFC 1757 defines the core of this Remote Monitoring architecture. ========================= Appendix A) Interoperability Report Responses Responses are presented in the order received. They have been editing for formatting and brevity. A.1) Cisco Systems (abierman@cisco.com) - all (SNMP-enabled) IOS images support alarms & events in the agent - several other platforms support full RMON-1, including Catalyst 5000, c2500, as5200. - agent codebase is a mix of internal, Netscout, and SNMP Research code - interoperates with Netscout TrafficDirector mgmt app - alarms & events are used in some internal mgmt applications ========================= A.2) Solcom (peter@solcom.co.uk) - specify MIB objects implemented and/or not implemented SolCom Systems hace full implementation of all MIB objects in RFC 1757. - specify for each object whether the implementation is for agent, NMS, or both. SolCom have both agent and NMS implementations for the full MIB. - specify at least one product name and SW version that contains the implementation. This does not have to be a commercial implementation. We use generic names fro our Standalone Probes so the SolCom Ethernet and Token Ring and Multiport Ethernet and Token Ring Products have the 1757 support. We have two management applications RMON Utilities for Windows and UNIX which provide agent NMS support for the MIB. - specify origin of the implementation(s), e.g. internal development or purchased engine code from XYZ corp. or a combination of both. All our RMON Support is internally developed. - specify any independent product implementations that you believe your product(s) to interoperate with. Be specific as to agent vs. application, and which MIB objects are used. We fully interop on this MIB in both Master and Agent with HP, Technicallly Elite, 3 Com, Bay (Nortel) and Netscout. Our NMS works with Shomiti and we work with Reporting packages from Red Point, Apogee and Concord. ========================= A.3) HP (MARK_PHANEUF@HP-ColSprings-om1.om.hp.com) - specify MIB objects implemented and/or not implemented - specify for each All of the HP LanProbes fully implement RFC 1757. Our WAN and ATM probes implement the event, alarm and packet capture groups of RFC 1757. The HP NetMetrix NMS fully implements RFC 1757 -object whether the implementation is for agent, NMS, or both. The HP LanProbe, WanProbe and ATMProbes are of the 'agent' class. The HP NetMetrix application suite is of the 'NMS' class. - specify at least one product name and SW version that contains the implementation. This does not have to be a commercial implementation. For Probes: 4986B - Ethernet LanProbe 4987B - Ethernet LanProbe with AUI J3457A - Quad Ethernet LanProbe J3458A - Fast Ethernet LanProbe J3913A - T1 WanProbe J3914A - E1 WanProbe J3915A - V-Series WanProbe J3919A - OC-3 ATMProbe For NMS HP Openview NetMetrix/UX version 6.0 - specify origin of the implementation(s), e.g. internal development or purchased engine code from XYZ corp. or a combination of both. Internal development of RMON implementations - specify any independent product implementations that you believe your product(s) to interoperate with. Be specific as to agent vs. application, and which MIB objects are used. Concord Communications - "Network Heath" NMS RFC 1757 statistics and history ========================= A.4) Nortel Networks (manjiri@nortelnetworks.com) > - specify MIB objects implemented and/or not implemented 1757 Objects implemented: ALL > - specify for each object whether the implementation is > for agent, NMS, or both. Agents as well as NMS applications > - specify at least one product name and SW version that > contains the implementation. This does not have to be a > commercial implementation. Agents: All Network Management modules in the S5000 Chassis series have implemented all or some groups. These include the 5310, 5510, 5616, etc. modules. Optivity StackProbes and PocketProbes provides standalone RMON probe capability (all groups). Most other hubs, switches and routers support all or some of the groups. NMS: Optivity Analysis (UNIX) and Optivity AnalysisNT support all groups. > - specify origin of the implementation(s), e.g. internal development > or purchased engine code from XYZ corp. or a combination of > both. Internal development. > - specify any independent product implementations that you believe > your product(s) to interoperate with. Be specific as to agent > vs. application, and which MIB objects are used. At the IWL interoperability test in '97, we had no major interoperability issues with any of the NMS (this is in reference to 5616 NMM). ========================= A.5) 3Com (Ian_Partridge@3com.com) 3Com Network Management Hardware/Software Implementation Reports for RFC1757 RFC 1757, RMON MIB, Implementation Report Agents ------ The RMON agent for the RMON Probes listed below implements all groups/objects of RFC 1757: SuperStack II Enterprise Monitor Transcend Enterprise Monitor 540 Single Port Ethernet Transcend Enterprise Monitor 542 Dual Port Ethernet Transcend Enterprise Monitor 570 Single Port Token-Ring AXON Ethernet LANServant RMON Probe AXON Ethernet LANServant RMON Probe Analysis Server AXON FlexiProbe 6000 AXON LANServant FlexiProbe 2000D AXON LANServant FlexiProbe 2000S AXON Token-Ring LANServant RMON Probe AXON Token-Ring LANServant RMON Probe Analysis Server This agent, the latest version of which is 4.17, is an internal development of AXON Networks Inc. and later 3Com Corporation. NMS Applications ---------------- LANsentry --------- Transcend LANsentry Manager, an internal AXON Networks Inc. and 3Com Corporation development implements all groups/objects from RFC 1757. The current version of LANsentry/unix in the field is 5.2.0, which is part of Transcend Enterprise Manager/unix 4.2.2 The current version of LANsentry/windows in the field is 5.1, which is part of Transcend Enterprise Manager/NT 1.0 LANsentry is known to inter-operate with among others the following third party RMON probe agents: Hewlett Packard HP Ethernet LanProbe - SNMP 1.0 (B.02.00.00), (Boot ROM A.00.01 8M) HP Quad Ethernet LanProbe - SNMP 1.0 (A.00.00.1A), (Boot ROM A.00.02.02 64M) HP LAN Probe II Token-Ring agent A.01.02 SolCom 8Mb Single Port Ethernet RMON Probe - SNMP 1.0 (2.11) (Boot ROM V1.54 8M) Shomiti Systems Inc. 8-port, 256Mb, Fast Ethernet Voyager probe V1.0 Build 118 MODEL NUMBER: 1005, REVISION NUMBER: 1.1 TEC Ethermeter1000 RMON2 probe agent version 4.0.2.4 / 4.0.2.5 Traffix ------- Transcend Traffix Manager, an internal AXON Networks Inc. and 3Com Corporation development, which is now at version 2.0, implements the following objects from RFC 1757: etherStats index datasource dropevents octets pkts bcastpkts mcastpkts crcerrors undersizepkts oversizepkts frags jabbers collisions owner status matrixControl matrix SDPkts SDOctets Traffix is known to inter-operate with the following third party RMON probe agents: Hewlett Packard HP Ethernet LanProbe - SNMP 1.0 (B.02.00.00), (Boot ROM A.00.01 8M) HP Quad Ethernet LanProbe - SNMP 1.0 (A.00.00.1A), (Boot ROM A.00.02.02 64M) SolCom 8Mb Single Port Ethernet RMON Probe - SNMP 1.0 (2.11) (Boot ROM V1.54 8M) Shomiti Systems Inc. 8-port, 256Mb, Fast Ethernet Voyager probe V1.0 Build 118 MODEL NUMBER: 1005, REVISION NUMBER: 1.1 TEC Ethermeter1000 RMON2 probe agent version 4.0.2.4 / 4.0.2.5 (The later is preferred as it comes with all protocols in the protocol directory enabled by default.) The addition of User Defined Protocols with these agents does however fail. There are issues with memory allocation and the lack of the address map on other companies RMON probes. These however may have since been resolved since the last test. ========================= A.6) IBM (bmillard@us.ibm.com) The IBM 8239 (token ring hub) fully supports RFC1757 and RFC1513. Also, the IBM HTMAC (High-End Token Ring Mac Daughter Card for the 8260) fully supports RFC1757 and RFC1513. The code for both was purchased from 3COM (AXON part)-- with internal development done as well. =================== A.7) Netscout (anil@netscout.com) 1) We have implemented all objects in RFC 1757. 2) All the objects have been implemented in both the agent (NetScout Probe) and the manager (NetScout manager). 3) Product line name is NetScout. It is also sold as a private label by Cisco as SwitchProbe and TrafficDirector. The latest versions supporting this functionality are 4.2.0 and 5.2.0 for agent and manager respectively. 4) All development has been done internally. We have also OEMed our agent code to Cisco, Paradyne and many other vendors through Eplilogue/ISI. 5) NetScout agents have been officially certified to work with the following applications: Cisco Concord INS DeskTalk Apogee We also have (anecdotal) evidence that our product works with many other vendors like NAI, Optimal, CACI and many others. Most of these vendors do very little configuration (SNMP Sets) and make use of the stats, history, host and conversation groups of these two RFCs. 6) Our manager is known to work with most agent implementations (unofficially certified by our customers) including those from HP, Bay, Cisco, 3Com, Fore and TEC. 7) NetScout has also participated in all the RMON1/RMON2 interoperability tests conducted by outside organizations during the last 3 years. Any fixes required have been incorporated into the released version of NetScout. Anil Singhal ========================= A.8) INS (stevew@ins.com) INS EnterprisePRO supports: rfc1757: etherStatsTable hostTable hostTopNTable ========================= A.9) Technically Elite (rsdietz@tecelite.com) MIB Group P1 P2 P3 P4 P5 P6 ------------------------------------------------------------------ etherStatsTable Y Y Y Y Y Y historyControlTable Y Y Y Y Y Y etherHistoryTable Y Y Y Y Y Y alarmTable Y Y Y Y Y Y hostControlTable Y Y Y Y N/I Y hostTable Y Y Y Y N/I Y hostTimeTable Y Y Y Y N/I Y hostTopNControlTable Y Y Y Y N/I Y hostTopNTable Y Y Y Y N/I Y matrixControlTable Y Y Y Y N/I Y matrixSDTable Y Y Y Y N/I Y matrixDSTable Y Y Y Y N/I Y filterTable Y Y Y Y N/I Y channelTable Y Y Y Y N/I Y bufferControlTable Y Y Y Y N/I Y captureBufferTable Y Y Y Y N/I Y eventTable Y Y Y Y Y Y logTable Y Y Y Y Y Y Product Key: ------------ P1 = RMONplus (V 2.0) P2 = EtherMeter 1000 (V 5.2.0.2) P3 = MultiMeter 3000 (V 4.0.2.4) P4 = SwitchMeter 3300 (V 4.0.2.4) P5 = MeterWorks Lite (V 5.01) P6 = MeterWork Std (V 5.01)