Re: [tkined] High volume SNMP poller

From: Szokoli Gabor (
Date: Tue Feb 15 2000 - 16:49:32 MET

On Tue, 15 Feb 2000, Juergen Schoenwaelder wrote:

> >>>>> Szokoli Gabor writes:
> Szokoli> Well, the web works from as far away from Hawaii as Hungary
> Szokoli> ... :-) Not real fast, though. And the papers do not seem to
> Szokoli> be published yet :-)
> I guess you have to order the proceedings to get the paper. Anyway,
> the paper I am talking about is in session 12 and titled "Efficient
> Instrumentation of Management Information Models with SNMP". It
> discussed some optimizations one can implement to optimize SNMP
> polling operations. You may want to contact the authors
> <> and <> and ask them
> to send you a pre-print. (But don't tell them I told you to do
> that. ;-)
Nay, I'll even hack into the list archive to destroy all evidence.
And, I beleive I need a lot more experience before bothering them.
Actualy, I feel pretty aquard creating all this buzz here already.

> Szokoli> How does scotty integrate with such extensions?
> I hope that "package require TclX" is all you need to do to get things
> working (after installing TclX on your system).
Khmm, I keep forgetting this, I always think of an extension as a separate

> Szokoli> There goes my hands-on-Tnm project... No, mine still has a
> Szokoli> feature, it can get sysUpTime with every row :-)
> OK, I will not put that into the C code today - just to keep you and
> your code happy. ;-)
For tomorrow: it's a separate option, the list of variables to be included
in each getnext.

> Szokoli> Does the 3.0.0 walk work for columns from different sized
> Szokoli> tables?
> No. I think the loop terminates as soon as one varbind leaves the
> subtree defined by the arguments. The walk function is not a gettable
> which I would expect should handle these cases.
Ha! I repeate, HA!
Go ahead, copy my timestamp feature, you'll never beat this :-)
Mine carries on, until all variables wonder out of range.
Thus the result is a list of various length lists of {OID type value}

> Szokoli> What other errors should a walk be prepared to handle? Right
> Szokoli> now my only idea is end of MIB, but I have little experince
> Szokoli> with SNMP so far.
> You can get tooBig, genErr and noSuchName (SNMPv1) or tooBig, genErr
> and endOfMibView exceptions (SNMPv2c/SNMPv3). Some broken agents may
> send you other errors as well. ;-)
well, I did it with only SNMPv1 in mind. I guess noSuchName means endOfMib
in the case of an snmpNext (allright, except for the first one) or a hole
in a cisco mib :-), and I shoud escalate tooBig and genErr, right?

> Szokoli> I do not have the FAQ at hand, so I should not ask, but, I
> Szokoli> didn't get this packing/unpackig part...
> Instance identifier contain lots of information that you do not need
> to retrieve via getnext/getbulk. The bad news is that it is usually
> hard to unpack this information from the instance identifier,
> especially if you have complex things like multiple variable length
> strings. 3.0.0 therefore has commands that do the packing/unpacking of
> data into/from instance identifiers for you. An example:
[example snipped]
Neat, I hope this 3.0.0 gets official soon...

> Szokoli> What happens with tkined, when scotty goes 3.0.0? I'm
> Szokoli> worried about the tools already written for it. (Anyway, is
> Szokoli> there an archive of such tools submitted by all the happy
> Szokoli> users?)
> I usually do not touch tkined except for some bug fixed. Tkined is
> therefor very stable and scripts should run fine, except of the Tnm
> API changes which of course requires to adjust some things here and
> there.
like :s/mib successor/mib children/g as I've learned today :-)
Is the set of scripts distributed with it the only set of tool available?

Thank you for your attention


!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <>.
!! See for more information.

This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 15:27:35 MET