May 9 07:55:55.633: SNMP: Packet sent via UDP to 22.214.171.124
I have an snmp monitoring program (NetIQ Vivinet Assessor) which is giving me an error message when it polls the 7206 router The error msg is:
CHR0411: An SNMP request to 126.96.36.199 failed, returning (noSuchName) There is no such variable name in this MIB. The requested OIDs were:
I can't get any clear indication why this error message is being generated, so I need some help with the debug output.
Does the debug show any problems with the snmp request? Is it returning the information from the MIBs the request is asking for? I don't see (noSuchName) anywhere in the debug so I don't know why Vivinet Assessor is complaining?
What do the numbers following the MIB enteries in the response mean?
These numbers change everyting Vivinet Assessor polls the router - which is every 5 minutes. Each poll gets responded to by the router with the same snmp response and Vivinet Assessor logs the same error everytime.
This debug is completely error-free. The key is the errstat and erridx numbers. A 0 for both indicates no error. If you were getting a noSuchName error, errstat would be 2, and erridx would point tot he varbind in which the error occurred. Of course, this debug doesn't reflect sysUpTime.0, ifOutOctets.6, and ifInOctets.6. Instead, it shows sysUpTime.0, ifOutOctets.13, and ifInOctets.13.
The numbers following the object names are the values. For sysUpTime, this is the number of 100ths of a second since the router last booted. For ifOutOctets, this is the number of output bytes on the interface corresponding to the ifIndex 13. For ifInOctets, this is the number of input bytes on the interface corresponding to the ifIndex 13.
My guess is that the reason you're seeing this error is that ifIndex 6 does not exist on this router.
OK - from your great explanation I understand how to read snmp better. So I went back to the debug output and low and behold I found the right entries and there are 'errstat 2' entries. I just didn't know what to look for before.
May 9 08:50:55.926: SNMP: Packet received via UDP from 188.8.131.52 on GigabitEthernet0/2
May 9 08:50:55.926: SNMP: Get request, reqid 164320, errstat 0, erridx 0
Probably because those objects are not instantiated on your router, and we employ a method called sparse tables to reduce the size of the MIB tree when objects do not need to be instantiated. All modern NMS applications should be able to handle sparse trees correctly. I have a feeling this NMS can handle it, and the noSuchName is not very problematic.
However, if you want to disable sparse tree, use the following config command:
no snmp-server sparse
That should get rid of the noSuchName errors provided you are not hitting an IOS bug.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...