>
> 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.
I understand this now.
>
> 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.
So far I have only found Cisco boxes operate like this on MIB-II. I have
tried this with lots of 3Com/Bay/Retix hubs/bridges/switches/routers with
no problems. That is why I concluded that the Cisco boxes were doing it
wrong. I am still not convinced that Cisco do it right. If they were not
going to implement that interface table completely for this interface
type, then should they have left it out of the table and implemented it
in a enterprise specific MIB which would only contain the relevant OIDs
for this interface ? That would make more sense I would think.
> 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.
Hmm, I like the table idea. I wouldn't mind having a go at it if I had
time and some experience in the scotty code base.
> Always remember: The Simple in SNMP
> is for the agent side, not for the manager.
>
The more I use SNMP, the more I think it should be renamed because
sometimes I have a real hard time understanding the nitty gritty of
what is really going on. Especially the use of ASN.1!
By the way, I always have problems with loading various vendor MIBs into
scotty. I usually get lots of error messages, which can be sorted out
by loading the MIBs in the correct order. But some MIBs, like the ones
supplied by Microsoft for NT, seem to have syntax errors in them.
Sometimes I wonder if the MIBs were accually tested!
Scotty is a great tool. We run our NetSMART monitoring service on a 200MHz
Pentium Pro running FreeBSD 2.2.2. At one site, we use scotty to collect
ifInOctets, ifOutOctets, ifAdminStatus, ifOperStatus, ifInErrors and
ifOutErrors from 750 router/switch ports every 60 seconds. Depending on
the WAN network response time, it only takes 6-8 seconds to collect all
that data! With the current performance, we can monitor up to 10000 ports
from a single NetSMART box.
Paul.
----------------------------------------------------------------------------
Paul Koch
Director, Support and Development NetSMART Network Monitoring Services
Email: pak@mns.com.au Micro Network Services Pty Ltd
Web: http://www.mns.com.au Level 6, 360 Queens St,
Phone: +61 7 3229 4750 Brisbane, Queensland, Australia
Fax: +61 7 3229 4506
----------------------------------------------------------------------------
-- !! 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.