Hi - > From: "David W. Hankins" <David_Hankins@xxxxxxx> > To: <ietf@xxxxxxxx> > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf