Hi -
From: "David W. Hankins" <David_Hankins(_at_)isc(_dot_)org>
To: <ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf