[j-nsp] SNMP interface index change after upgrade to 9.2

[Simon Leinen]

Richard A Steenbergen writes:
> Any software which relies on static ifIndex mappings between polling
> cycles is fundamentally flawed, period, end of discussion. There is
> absolutely no excuse for this, it is beyond trivial to map data by
> ifDescr, and the SNMP spec even tells you that ifIndex is not to be
> used for this kind of thing.

I totally agree up to this point.  However...

> I really don't understand why people still can't figure out how to do
> this.

...doing MIB table indexing/object naming right in general is hard.
It is easy as long as you restrict yourself to the interfaces table,
or only allow things within the same table (e.g. ifDescr, ifName for
interfaces) as names.

Beyond that, it gets complicated pretty quickly.  For example,
wouldn't it be nice if you could specify interfaces by IPv4 address or
subnet, or by VLAN name/number in a measurement tool? Now the tool
would have to do a multi-step mapping using another table.  I don't
know about Juniper, but Cisco has these great sensor MIBs for stuff
such as transceiver monitoring - those use the ENTITY-MIB as the basis
for indexing, and that's also complex to use.  I hear that Juniper has
SNMP access to per-filter entry statistics - how's the indexing done
for that? You'd want to be able to specify "the counter corresponding
to number of bytes matched for the line that matches IPv6 TCP-port 08
traffic in the inbound ACL on interface <FOO>", that continues to work
even as the ACL is modified.

> Here is an example of a very compact poller which does efficient
> retrieval using snmp bulk walk. All you need is php and the netsnmp
> lib, it's just a wrapper to a very simple C implementation which is
> 100x more efficient that the utter crap you'll find in mrtg, rtg,
> etc.

Thanks for the kind words, RAS, that is mostly my code (-: btw. I'm
moving my Perl SNMP library to http://code.google.com/p/snmp-session/)

While I don't necessarily disagree that the code is crap (e.g. missing
SNMPv3 support, bad support for use with asynchronous event loops), I
cannot let it stand uncommented that it is 100x less efficient than
yours/Net-SNMP's.  It is true that the Perl code is written in pure
Perl and without much regard for efficiency in the construction and
deconstruction of SNMP PDUs - in particular, lot of garbage and
overhead is created as it assembles/disassembles everything using
small Perl strings.  So if the CPU load of the SNMP work (as opposed
to storage and other processing) gives you problems on the manager
(client) side, then I'm sorry about that.

On the other hand, my code has some features that makes it easier on
the SNMP agents, i.e. underpowered router CPUs (OK, your Junipers may
be less underpowered than my stupid Ciscos, but still).  In
particular, it has a much nicer interface to walking tables (map_table
/ snmpmaptable) than most other libraries.  I'll also note that there
have never been any known buffer overflow bugs or memory leaks with my
library.

> You can easily use this to interface with any number of tools like
> rrdtool, sql, etc.

> http://www.e-gerbil.net/ras/snmp-php

Your code has to let the router walk the entire interfaces table once
for each column OID in $oidlist; using my library, you could walk all
the columns of a table in parallel.  That's not only less management
traffic and less processing load for the router, but you can also
start acting on entire table rows as you go (and maybe break the loop
early when you have found what you're looking for).

Best regards,
-- 
Simon.