Re: SNMP traps and ifTable

Juergen Schoenwaelder (schoenw@data)
Tue, 27 Sep 94 19:37:51 +0100

Hi!

Rob> However I have problems pulling off tables such as ifTable
Rob> when selected with the new browser. If I select
Rob> MIB2.interfaces.ifTable it says "not response after 5
Rob> retries".

Rob> If I use the old browser and select
Rob> mgmt.mib-2.interfaces.ifTable and then do a "walk" the MIB
Rob> values come back fine! Most of the other tables in the new
Rob> browser work however. Is this a bug or do I have a config
Rob> problem?

There is no config problem you have to worry about. scotty-1.1 uses a
proc SnmpShowTable (library.tcl) which blindly tries to show all rows
of a table. Foreach row, a getnext request is used to retrieve the
SNMP objects. The ifTable has 22 variables in a row and this breaks
the message size on most agent implementations. The solution is to
break `long' getnext requests into a number of smaller once. I have no
idea what criteria to recognize `long' requests would be easy to
implement and will work with most agents/tables. (I do not want to
find the message size using a trial and error approach.) All ideas
very welcome.

Rob> Now one other question. Is it possible for tkined/scotty to
Rob> receive SNMP traps?

Of course, traps must be dealt with. There is a bit coding overhead
since V1 and V2 traps are quite different and since more than one
scotty process might be interested to receive traps and the SNMP trap
port 162 needs special privileges, but we just started hacking on it.

Juergen