HTTP/2 302 date: Mon, 14 Jul 2025 05:08:08 GMT content-type: text/html content-length: 143 location: https://get.ietf.org/implementation-report/report-rfc2571-2575.txt cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 expires: Thu, 01 Jan 1970 00:00:01 GMT vary: Accept-Encoding server: cloudflare cf-ray: 95ee80237c9ac169-BLR alt-svc: h3=":443"; ma=86400 HTTP/2 200 date: Mon, 14 Jul 2025 05:08:09 GMT content-type: text/plain etag: W/"75312a97126443219c15e84078049ccb" vary: Accept-Encoding server: cloudflare cf-ray: 95ee8023bdd54e3d-BLR content-encoding: gzip alt-svc: h3=":443"; ma=86400 Deployment Report for RFCs 2571-2575 RFCs2571-2575 have been updated in internet drafts, and have been through working group last call. Executive Summary: SNMPv3 has been made available via proxy agents in a number of products that are widely recognized as having the leading market shares for SNMP management applications. These include HP OpenView, and Aprisma's Spectrum management platforms. A number of market-leading interworking equipment vendors have had SNMPv3 incorporated into their firmware for years, most notably Cisco. SNMPv3 has been widely available in the leading SNMP toolkits, such as SNMP Research, Wind River, Net-SNMP, and the libsmi tools from the University of Braunschweig. Each of these products offer tri-lingual stacks, including SNMPv1, SNMPv2C, and SNMPv3 support. Unfortunately few customers of these products have chosen to file deployment reports. We have the following reports of deployment: ------------------------------------------------------------------------- @Home has deployed SNMPv3 in its cable modem network, following the DOCSIS 1.1 standard. This is by far the largest deployment reported. We have had no reports of scalability problems. Manager implementations were from Objective Systems' NetExpert, SNMP Research's BRASS toolkit, and UC Davis UNIX. Agent implementations were from cisco systems and some cable modem vendors. @Home's SNMPv3 manager implementations are backwards interoperable with pre-SNMPv3 agent implementations. Operationally, that matters to lots of folks. No interoperability problems were discovered for the tested and used features. This report is unofficial, and was provided by Ran Atkinson. ------------------------------------------------------------------------- OSI NetExpert supports SNMPv3 (and has for a while) and NetExpert is pretty common in service providers. A fair number of ISPs have both HPOV and NetExpert from what I have seen. This report was provided by Ran Atkinson. ------------------------------------------------------------------------- Tom Lehman presented a report from CAIRN. They are attempting to do more effective monitoring with SNMPv3. Today they mainly use web servers with ssl to go to ssl servers which run scripts to collect and manipulate information. The current versions of the scripts use RSH to collect the information, they would like to modify the scripts to use SNMPv3. Tom presented a slide with a CAIRN diagram which gives a better illustrations of this deployment (the slide will be submitted for inclusion in the IETF proceedings). The CAIRN web site is: www.cairn.net. The contact person for this deployment is: Jaroslav Flidr SNMP Research has deployed SNMPv3 on nearly every host and device on our network (the exceptions being ancient hardware, and the router discussed later in this paragraph). While our largest use is as a testbed for our agent and management products, we do use SNMPv2/3 as a monitoring tool, and increasingly as a configuration tool. We currently only have one core device that does not do SNMPv3, and that is the gateway router supplied by our ISP. The software is available, but SNMPv2c is adequate for both SNMP Research's and Genuity's monitoring requirements on this device. SNMP Research has experienced demand for SNMPv3 products from a wide variety of end user customers. As expected, most of the demand for SNMPv3 in end user products comes from customers with an interest in or concern about security. These include banking and finance-related industries, government, government contractors, Internet service providers, and application service providers. ------------------------------------------------------------------------- Wes Hardaker (hardaker@tislabs.com) presented the results of the Net-SNMP survey that he ran. They were attempting to get information on what people are using SNMP for and which version of SNMP is being used. Some of the results that were thought to be of particular interest to the WG were that some folks are using v2c or v3 without using v1 and that v2c is in wide use but v3 has not yet been used quite as widely. He also found that the range of the number of hosts per site was much broader for v1 sites than for v3 sites. When asked why they didn't use v3, many people stated that it was because it isn't available on the equipment they use. At least some of these folks would seem to be confused since the equipment that they indicated they managed does support v3. Lastly, Wes also asked what else the respondents wanted in v3. A number of them were content with v3 as it currently exists while others did have some additional desires. The leading desires on the list seemed to be ! bulk transfer (mostly with some sort of filtering at the agent side). Some other confused folks were asking for security. For more information from this survey can be seen at https://www.netsnmp.org/report In another section of the meeting, a participant stated that SNMPv3 was not being considered at his company due to a lack of integration with RADIUS and the lack of easy centrally controlled management. Approximate number of net-snmp downloads: 18,000 Does your company use snmp to manage their network: yes=50, no=15 Does your company produce SNMP related software: yes=33, no=32 Does your company use SNMPv1: yes=33, no=11 Does your company use SNMPv2c: yes=49, no=14 Does your company use SNMPv3: yes=14, no=44 How many SNMP enabled hosts are you using: very wide range, average around 1000-10000 or so. How many SNMPv3 enabled hosts/systems/boxes are you using? results: 0, 1, 2, 3, 7, 10, 20, 50, 80, 100, 500, 850, >1000 If not using SNMPv3, why? (some of) Results: 20 not supported on (at least some of) the hardware/software in use (note that a fair number of these were HPOV based, because they hadn't bought the extension (or weren't aware of it)) (many notes said some boxes do, some don't and they need ALL to support it before switching) 7 in process of switching now 5 no time to make the switch 4 customers not asking for it or it's not needed 3 only need monitoring 3 it's complexity makes it hard 3 not needed in an otherwise secure environment (local lan) 3 don't know enough about it 2 Not enough memory in current shipping products 1 not a standard MG-SOFT has a full implementation of the current SNMPv3 RFCs. Interoperability tests with implementations of other major SNMPv3 vendors were conducted from late 1998 and sucessfully concluded in May 1999, when 257x RFCs were published. The MG-SOFT's SNMPv3 engine is mostly marketed as a part of MG-SOFT network management software (MIB Browser Pro., Net Inspector, SNMP MIB Query Manager, Trap Ringer Pro, etc) and as a SNMPv3 SDK (and therefore used as a part of SNMPv3 agent or manager applications built by MG-SOFT's customers who purchased the SNMPv3 SDK). As of today, MG-SOFT has thousands of users who have licensed SNMPv3 products in ar least one of the above two forms - a brief list of major MG-SOFT's cutomers is given on our web page at https://www.mg-soft.com/profile.html According to the feedback that we receive from our customers, MG-SOFT's SNMPv3 products are used for the following 3 main purposes: (1) managing or monitoring SNMPv3 devices deployed at customer's site, (2) debugging and interoperability testing of other SNMPv3 implementations that customers are developing and (3) as a base for third party SNMPv3 management applications, based on MG-SOFT's WinSNMPv3 API. Marconi implements SNMPv3 on FOREthought, the software supporting our ATM Switches. I would estimate that there are several thousand switches that have been shipped with, or upgraded to, the versions that support SNMPv3. Brian Rosen brian.rosen@marconi.com ------------------------------------------------------------------------- SNMPv3 Deployment at NAI Labs Prior to SNMPv3 Deployment at NAI Labs, management and monitoring of the servers and network devices of our internal network was a very decentralized affair. We turned to SNMPv3 as a secure method of centrally monitoring and managing our network. Although it did have some pitfalls, generally our experience with SNMPv3 deployment was a positive one. Software We used a mix of commercial and freely-available software for our SNMP deployment. This included a commercial SNMP management software package, a commercial SNMPv3 add-on for the management software, and an open-source SNMP agent. In addition, we upgraded the software for our ethernet switch to support SNMPv3; this software was provided by the switch manufacturer. SNMP management software: HP OpenView Network Node Manager 6.01 for Solaris/Sparc SNMPv3 add-on: SNMP Research SNMP Security Pack 15.2.1.9 SNMP agent: UCD-SNMP version 4.2.1 Switch software: Cisco Catalyst 5000 Supervisor software version 5.5(9) Install and Configuration One of the first steps in deploying SNMP was to install the required software. This included the management software and SNMP agent software. This was generally not difficult, and very well-outlined in the software documentation. The next step was to configure the software. At first glance, it seemed that this would not be very difficult; because all the software used the same SNMPv3 access control model, the access control of different products was configured in much the same way. For each SNMPv3 device, we added users, groups, and MIB views for those groups. However, much of the time spent configuring SNMPv3 was invested in investigating the bugs and other nuances of the individual SNMP software packages. The software products that we used had varying levels of documentation, and also varying levels of bugs. In particular, the SNMPv3 add-on for our SNMP management software was particularly buggy and not as well documented as we thought it was needed. Problems such as segmentation faults and undocumented configuration options were much too common. With some trial and error, however, the packages were eventually configured correctly. Operation Once the software was configured and working properly, all of the SNMPv3 products worked very well together. The only interoperability problem occurred when attempting to use SHA authentication between our SNMP management station and our servers (although MD5 authentication worked fine). It is unclear whether the problem was caused by a bug in the SNMPv3 add-on to the management software, a bug in the agent software on the servers, or a configuration error. Otherwise, there were no interoperability problems to speak of. Communication between the management station and the switch and servers was authenticated and encrypted (the encryption was verified to be working using a sniffer), and the security functionality of SNMPv3 was generally very transparent. Our SNMPv3 deployment did not test much of the access-control functionality of SNMPv3, however. Because we have a small group of people who administer the entire network, there was no need to assign different MIB views to different user names. We did not test the functionality or practicality of maintaining multiple users using SNMPv3. Conclusion Using SNMPv3, we are now able to securely monitor and manage our network infrastructure. We can remotely monitor the servers on the network, receiving warnings about, among other things, disk space levels and load averages. SNMPv3 support on the switch means that we now have a plethora of data previously unavailable to us, including network segment traffic levels, port status, and switch configuration data. All of this allows us to look at the big picture of what is happening on our network, which was not possible without SNMP. ------------------------------------------------------------------------- We have an email report that the US Army is moving forward with deploying SNMP v3, particularly on all of its battlefield systems. The report contained no details. Since this report was not filed by the US Army, I tried to confirm this information, but was unable to find independent confirmation of this information. ------------------------------------------------------------------------- >From Jeff Case of SNMP Research: I believe that there is sufficient deployment to address all standardization issues with regard to these documents. I can happily confirm that there is a plugin on the market for what is widely regarded as today's top snmp-based management station, HP OpenView Network Node Manager (NNM). This plug-in enables the NNM product to send and receive requests and notifications trilingually, i.e., with full support for SNMPv1, SNMPv2c, and SNMPv3, communicating with a variety of nodes in the networks via this mix of versions. If the management station is talking to an older node, it speaks using an older version of the protocol; if it is talking to a node that supports snmpv3, it can use snmpv3 to conduct the transaction -- and is configurable by the user to elect which version(s) and what securityLevel(s) to use. For more information about this product, which has been available for a couple of years, please see https://ovweb3.external.hp.com/solcat/products/display.cfm?id=665 Similar adapters are available for use with any generic management station. The HP-specific product is selling "ok" ... not great, not terrible, but "ok" partially because we cannot get the kind of marketing support from hp that we would like to have. The snmpv3 adapter for NNM is popular among those end-user customers who are sensitive to security issues, such as government, finance, and the cable television industries It enjoys a disproportionately high level of interest among international customers when compared to their domestic U.S. counterparts. ------------------------------------------------------------------------- Summary: This report shows that RFCs2571-2575 have been deployed in networks large and small. With the primarily typographical and editorial corrections made in the internets drafts which went through working group last call, it is the consensus of the working group that these documents should be advanced to full standard, and that SNMPv3 meets the requirements with respect to deployment experience for advancement to full Internet Standard status. SNMPv3 co-chairs Dave Harrington and Russ Mundy