Re: a modern-day SNMP use
Am 24.10.2008 um 20:14 schrieb Peter Dambier: David W. Hankins wrote: On Thu, Oct 23, 2008 at 09:41:49AM -0700, Randy Presuhn wrote: All very good reasons why doing blind, single-variable MIB walks makes no sense. Are there any commercial products that do this routinely? I'm not aware of any. Adding to David, IASON originally did a lot with SNMP, because of catalysts :) We used Open Source snmpwalk because that was the easiest way to go. When we added boxes and MIBs we got into trouble and out of memory. As David observed, SNMP used to be slow and consumed a lot of cpu on both the monitor and the monitored boxes. We dropped SNMP finally when we moved away from the catalysts. IASON never went commercial but is in the Open Source now and still very pre beta. hello peter and karin if you add me [ 1 ] to your developer list on sourceforge [ 2 ] with the right privileges i would like to add the documentation from iason [ 3 ] to your sourceforge site and commit the latest source, i´ve learned a bit in the past days about CVN and i would like to assist in my spare time. ;) greetings from cologne to Moerlenbach Marc [ 1 ] https://sourceforge.net/users/manthey08/ [ 2 ] https://sourceforge.net/projects/iason/ [ 3 ] http://iason.site.voila.fr/Iason/ -- In a world without walls or fences, who needs Windows and Gates? Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 Köln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :[EMAIL PROTECTED] blog : http://www.let.de ipv6 http://stattfernsehen.com xing : https://www.xing.com/profile/Marc_Manthey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
a modern-day SNMP use
On Thu, Oct 23, 2008 at 09:41:49AM -0700, Randy Presuhn wrote: All very good reasons why doing blind, single-variable MIB walks makes no sense. Are there any commercial products that do this routinely? I'm not aware of any. This is a tangential issue, so I wanted to reply separately, and later. I worked for a backbone company a few years ago, I started there around the turn of the most recent century, which used SNMP for billing-related data. When I started, I would say their system was a nightmare (and they knew it). Customers were even in the know, and would routinely dispute their bills knowing full well the'd get free net. The short answer to your question, is that there exists today at least one monitoring package, albeit not commercially nor even freely available to the public (it is a private tool), which autodetects all the interfaces and other monitorable variables on every router in that backbone's network. The only thing it knows about what it is going to monitor, in advance, is the hostnames and community string(s) of the devices it seeks to monitor. It does this autodetect run once every 30 minutes, or when it restarts or reconfigs, feeding the results of that search into a table of 'monitored OIDs', which expire out of the table after 90 minutes (or if it gets an SNMP error indicating future queries would not be fruitful). If any device's sysUpTime.0 decreases (sysUpTime was put at the top of every SNMP GET packet), it alone is re- autoconfigured. I would call that 'routine', but again this is fairly subjective. The monitored OID dataset would be queried once every 30 seconds (except the Catalysts, due to the limitation I mentioned earlier, would take 35 seconds to run a single polling run, so they ran every 60 to give them a breather...they phased the cats out over time). This unusually low polling interval was selected somewhat arbitrarily; Because we can. The router polling run would only take 3 seconds (we had around 300 of them, I seem to recall). It turned out to have some advantages; 300 seconds is a long time to wait to see changes in traffic graphs if you tweak BGP. Collecting 10 datapoints to make one billing datapoint meant we would generally not lose anything if we missed a datapoint or even two. Because we couldn't count on wide implementation of SNMPv2c among our monitored devices, we used an initial SNMPv1 query against every device for the sysObjectID (and a couple other things), and then assigned one of several handlers that worked around quirks and optimized the process for that particular breed of router or switch. Both the autodection and polling strategies employed a technique we found by benchmarking the routers and switches we used; we filled an SNMP packet with as many variables as possible; so that the reply packet would approach, but not exceed, 64KB, a UDP fragment. It turns out that if you compared the time it took 50 SNMP packets transmitted in parallel to be replied to, to the time it took a single SNMP packet with 50 variables that had to be fragmented, the faster approach was the single, fragmented, packet. We used a fine-tuned number of variables for each system, again keyed by sysObjectID. Sensing the remote system's available UDP buffer (again keying this off of sysObjectID), we would queue multiple such monster SNMP packets, guaranteeing that at all times throughout a single polling run, the remote system had an SNMP packet in its buffer to reply to, and in in the air in both directions, even with retransmissions. More information on the subject of autodetection... On some of the handlers, we were able to capitalize on iterating a series of GETs for every ifIndex from 0 up to ifCount-1 (usually on ifName.*, but sometimes ifDescr.*, and even other times (those damn Catalysts) on their enterprise-mib ifAlias.*, and then queuing additional ifCount,ifCount+1,... GETs to the tail upon every reception of an error (indicating a gap in ifIndex, which happens on hot swaps). Successful replies indicated the interface existed, an entry was created, and we'd start querying the actual data we wanted from other tables. This tail-inserting strategy meant there was a continuous flow of valid configuration information from the remote end, something neither GETNEXT nor GETBULK can supply. But for example, there were switch implementations which used ifIndex values that were contrived to survive reboots (a feature desired by people who used the manually-configured SNMP software of the day), which meant the ifIndex space was sparsely populated. There was more than just the one MIB we wanted to monitor as well; anyone with routers wants to know what their environmental monitoring is saying...and are the fans running? We are speaking of course of the fabulous area of enterprise-specific MIBs. For most of these, we were able to enter in (in sourcecode) a set of manual extra variables to monitor (ex: 7200s had exactly 3 temperature sensors and
Re: a modern-day SNMP use
David W. Hankins wrote: On Thu, Oct 23, 2008 at 09:41:49AM -0700, Randy Presuhn wrote: All very good reasons why doing blind, single-variable MIB walks makes no sense. Are there any commercial products that do this routinely? I'm not aware of any. Adding to David, IASON originally did a lot with SNMP, because of catalysts :) We used Open Source snmpwalk because that was the easiest way to go. When we added boxes and MIBs we got into trouble and out of memory. As David observed, SNMP used to be slow and consumed a lot of cpu on both the monitor and the monitored boxes. We dropped SNMP finally when we moved away from the catalysts. IASON never went commercial but is in the Open Source now and still very pre beta. Kind Regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: a modern-day SNMP use
Hi - From: David W. Hankins [EMAIL PROTECTED] To: ietf@ietf.org Sent: Friday, October 24, 2008 9:26 AM Subject: a modern-day SNMP use ... The short answer to your question, is that there exists today at least one monitoring package, albeit not commercially nor even freely available to the public (it is a private tool), which autodetects all the interfaces and other monitorable variables on every router in that backbone's network. The only thing it knows about what it is going to monitor, in advance, is the hostnames and community string(s) of the devices it seeks to monitor. It does this autodetect run once every 30 minutes, or when it restarts or reconfigs, feeding the results of that search into a table of 'monitored OIDs', which expire out of the table after 90 minutes (or if it gets an SNMP error indicating future queries would not be fruitful). If any device's sysUpTime.0 decreases (sysUpTime was put at the top of every SNMP GET packet), it alone is re- autoconfigured. I would call that 'routine', but again this is fairly subjective. Doing this does *not* require blind MIB walks. One can discover the set of supported MIBs (from a set of MIBs one knows how to manage - there's little point in discovering a MIB one does not know how to manage) with a relatively small number of GetNext requests, where the number of probes needed ends up being (favorably) proportional to the number of MIBs actually supported by the device. Interfaces can be discovered even more economically, thanks to GetBulk and the non-locality you complained about in an earlier message. ... Because we couldn't count on wide implementation of SNMPv2c among our monitored devices, we used an initial SNMPv1 query against every device for the sysObjectID (and a couple other things), and then assigned one of several handlers that worked around quirks and optimized the process for that particular breed of router or switch. Both the autodection and polling strategies employed a technique we found by benchmarking the routers and switches we used; we filled an SNMP packet with as many variables as possible; so that the reply packet would approach, but not exceed, 64KB, a UDP fragment. It turns out that if you compared the time it took 50 SNMP packets transmitted in parallel to be replied to, to the time it took a single SNMP packet with 50 variables that had to be fragmented, the faster approach was the single, fragmented, packet. We used a fine-tuned number of variables for each system, again keyed by sysObjectID. None of this is surprising, and is consistent with what other products do. ... On some of the handlers, we were able to capitalize on iterating a series of GETs for every ifIndex from 0 up to ifCount-1 (usually on ifName.*, but sometimes ifDescr.*, and even other times (those damn Catalysts) on their enterprise-mib ifAlias.*, and then queuing additional ifCount,ifCount+1,... GETs to the tail upon every reception of an error (indicating a gap in ifIndex, which happens on hot swaps). Successful replies indicated the interface existed, an entry was created, and we'd start querying the actual data we wanted from other tables. This tail-inserting strategy meant there was a continuous flow of valid configuration information from the remote end, something neither GETNEXT nor GETBULK can supply. ... ??? You'd end up with far fewer exchanges using GetBulk. GetNext would never require more exchanges, and under some circumstances (sparse ifIndex allocation, for example, as you mentioned below, or access control limitations) would require fewer. The approach you describe sounds like a lot of clever for no net gain. But the net of all this is that, as ugly as it is, SNMP can be used efficiently and effectively, and we shouldn't confuse shortcomings of some tools with shortcomings of the protocol or data models. They have enough real ones of their own; we don't need to fret about imaginary ones and spend time knocking down strawmen. Some of this discussion reminds me of early claims that CMIP was spectacularly inefficient. Turns out that protocol can be implemented with roughly the same code size and effort as SNMP, and is quite cheap to parse and encode; the inefficiency folks were so worried about was a quirk of an early, freely-available implementation, not something inherent in the protocol. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
