Re: [tkined] SNMP walk problems with Cisco primary rate ISDN interfaces

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Tue, 28 Oct 1997 22:45:54 +0100 (MET)

Paul Koch <pak@mns.com.au> said:

Paul> The walk fails when it gets to the primary rate interface
Paul> because the Cisco software return 'noSuchName' for some of its
Paul> OIDs in the interface group (ie. ifMtu and lots of
Paul> others). The walk stops at this point, thus not displaying the
Paul> rest of the installed interfaces.

No, I am pretty sure that the CISCO does not return noSuchName. It
returns the next instance in lexi order and this stops the walk. (See
below why this is the case.)

Paul> If I do a walk through the interfaces group:

Paul> $s walk x interfaces { puts $x }

Paul> The walk operates correctly, but it skips the primary rate
Paul> interface on the OIDs it doesn't implement. This is no good
Paul> because a walk which would take only 40 packets for 20
Paul> interface indexes takes close to 1000 packets! Therefore
Paul> creating quite a lot more network traffic and the walk takes
Paul> soooo long to do when going over multiple long
Paul> distance/delayed 64K ISDN hops.

Right. A nice example.

Paul> So it seems that a walk ends the first time it gets any OID
Paul> that returns noSuchName. Sounds good to me because all the
Paul> OIDs in the MIB-II interface group have a STATUS of mandatory.

The only case where you will get a noSuchName is when you reach the
end of the MIB. To understand why the walk terminates before you reach
the end of the table, you have to understand how the walk is
implemented.

A normal walk with one varbind does getnexts until the returned
instance is no longer in the MIB subtree specified by the walk
argument. If you walk over multiple varbinds, than the walk stops as
soon as one of the varbind leaves its subtree. Now, if you have a
"hole" in a table (that is a non-existing instance for a given object
type), then the getnext returns something which is not in the subtree
of this varbind and the walk stops.

Now the interesting question is whether this is good or bad. Lets me
first make clear that skipping objects that are not present instead of
returning 0 is absolutely correct. I am sure CISCO is doing it right.
The question now is whether the Tcl SNMP API should have better ways
to deal with holes in tables. I think yes, but it is not as simple as
it might look in the first place. The current walk command works fine
for tables without holes and it has the big advantage that the Tcl
programmer does not have to check whether she got what she asked for.

Changing the walk implementation to only stop the loop when all
varbinds are outside of their subtree would require to check in the
body whether you ot what you asked for and it would potentially
reorder the instances in the loop variable. This does not really make
sense.

The only solution I can think of is to have a special table command
option which does some re-ordering and probably also some tooBig error
handling to retrieve tables, probably fetching the table first before
giving control back to Tcl. Adding something like this is actually on
the TODO list for quite some time, but I never got to it. So you have
to roll your own solution in Tcl. Always remember: The Simple in SNMP
is for the agent side, not for the manager.

Paul> I still believe the Cisco software is wrong because RFC1213 is
Paul> still current (as far as I can see from doing a big grep
Paul> though all RFCs for 'Obsolete') as it states a STATUS of
Paul> mandatory.

The STATUS has nothing to do with getnext processing.

Paul> I think the routers should return a 0 value instead of noSuchName.

No, objects that do not exist do not exist. Returning 0 for something
that does not exist is a bad idea. It is the manager who has to do it
right.
Juergen

-- 
Juergen Schoenwaelder  schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, D-38106 Braunschweig, Germany.     (Tel. +49 531 / 391-3283)
--
!! 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 <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.