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. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
