I am having trouble with a SNMP walk on Cisco routers which have ISDN
primary rate interfaces installed.
If I do user the following:
$s walk x "ifIndex ifDescr ifType ifMtu ifSpeed ifPhysAddress \
ifAdminStatus ifOperStatus ifLastChange ifInOctets \
ifInUcastPkts ifInNUcastPkts ifInDiscards ifInErrors \
ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts \
ifOutDiscards ifOutErrors ifOutQLen ifSpecific" {
...
..
}
The walk fails when it gets to the primary rate interface because the
Cisco software return 'noSuchName' for some of its OIDs in the interface
group (ie. ifMtu and lots of others). The walk stops at this point, thus
not displaying the rest of the installed interfaces.
If I do a walk through the interfaces group:
$s walk x interfaces { puts $x }
The walk operates correctly, but it skips the primary rate interface on
the OIDs it doesn't implement. This is no good because a walk which would
take only 40 packets for 20 interface indexes takes close to 1000 packets!
Therefore creating quite a lot more network traffic and the walk takes soooo
long to do when going over multiple long distance/delayed 64K ISDN hops.
I had a look at scotty's walk code and it says:
/*
* noSuchName errors mark the end of a SNMPv1 MIB view and hence
* they are no real errors. So we ignore them here.
*/
So it seems that a walk ends the first time it gets any OID that returns
noSuchName. Sounds good to me because all the OIDs in the MIB-II interface
group have a STATUS of mandatory.
But...
I tried reporting this as a bug to Cisco but so far have been told that the
Cisco software is OK because of RFC1573 section 3.2.3:
Extract of RFC1573:
Also note that a media-specific MIB may mandate that a particular
ifTable counter does not apply and that its value must always be 0,
signifying that the applicable event can not and does not occur for
that type of interface; for example, ifInMulticastPkts and
ifOutMulticastPkts on an interface type which has no multicast
capability. In other circumstances, an agent must not always return
0 for any counter just because its implementation is incapable of
detecting occurrences of the particular event; instead, it must
return a noSuchName/noSuchObject error/exception when queried for the
counter, even if this prevents the implementation from complying with
the relevant MODULE-COMPLIANCE macro.
I still believe the Cisco software is wrong because RFC1213 is still
current (as far as I can see from doing a big grep though all RFCs for
'Obsolete') as it states a STATUS of mandatory.
I think the routers should return a 0 value instead of noSuchName.
Can anyone help me on this matter ?
Paul Koch.
----------------------------------------------------------------------------
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.