Re: Please decipher this snmp debug:

jkeeffe · ‎05-09-2007

This is on a 7206 router with code c7200-ik9s-mz.123-16.bin, and the following debugs:

debug snmp packets

debug snmp requests

May 9 07:55:55.625: SNMP: Packet received via UDP from 164.72.43.30 on GigabitEthernet0/2

May 9 07:55:55.625: SNMP: Get request, reqid 162922, errstat 0, erridx 0

sysUpTime.0 = NULL TYPE/VALUE

ifEntry.16.13 = NULL TYPE/VALUE

ifEntry.10.13 = NULL TYPE/VALUE

May 9 07:55:55.629: SNMP: Response, reqid 162922, errstat 0, erridx 0

sysUpTime.0 = 414177138

ifEntry.16.13 = 1237389811

ifEntry.10.13 = 1104426301

May 9 07:55:55.633: SNMP: Packet sent via UDP to 164.72.43.30

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 164.72.47.134 failed, returning (noSuchName) There is no such variable name in this MIB. The requested OIDs were:

system.sysUpTime.0

ifOutOctets.6

ifInOctets.6

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.

Joe Clarke · ‎05-09-2007

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.

jkeeffe · ‎05-09-2007

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 164.72.43.30 on GigabitEthernet0/2

May 9 08:50:55.926: SNMP: Get request, reqid 164320, errstat 0, erridx 0

sysUpTime.0 = NULL TYPE/VALUE

ifEntry.16.6 = NULL TYPE/VALUE

ifEntry.10.6 = NULL TYPE/VALUE

May 9 08:50:55.930: SNMP: Response, reqid 164320, errstat 2, erridx 2

sysUpTime.0 = NULL TYPE/VALUE

ifEntry.16.6 = NULL TYPE/VALUE

ifEntry.10.6 = NULL TYPE/VALUE

May 9 08:50:55.930: SNMP: Packet sent via UDP to 164.72.43.30

May 9 08:50:55.974: SNMP: Packet received via UDP from 164.72.43.30 on GigabitEthernet0/2

May 9 08:50:55.974: SNMP: Get request, reqid 164322, errstat 0, erridx 0

sysUpTime.0 = NULL TYPE/VALUE

ifEntry.16.7 = NULL TYPE/VALUE

ifEntry.10.7 = NULL TYPE/VALUE

May 9 08:50:55.978: SNMP: Response, reqid 164322, errstat 2, erridx 2

sysUpTime.0 = NULL TYPE/VALUE

ifEntry.16.7 = NULL TYPE/VALUE

ifEntry.10.7 = NULL TYPE/VALUE

May 9 08:50:55.978: SNMP: Packet sent via UDP to 164.72.43.30

ifIndex 6 & 7 are serial interfaces on the router bundled into a PPP Multilink interface as shown here - if I read the output below correctly:

ENG-7206-QMOE#sh int summary

*: interface is up

IHQ: pkts in input hold queue IQD: pkts dropped from input queue

OHQ: pkts in output hold queue OQD: pkts dropped from output queue

RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)

TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)

TRTL: throttle count

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

------------------------------------------------------------------------

* GigabitEthernet0/1 0 0 0 14872 10000 20 12000 21 0

* GigabitEthernet0/1.10 - - - - - - - - -

GigabitEthernet0/1.110 - - - - - - - - -

* GigabitEthernet0/2 0 0 0 0 13000 23 12000 23 0

GigabitEthernet0/3 0 0 0 0 0 0 0 0 0

* Serial5/0:0 0 0 0 0 0 0 0 0 0

* Serial5/1:0 0 0 0 0 0 0 0 0 0

MFR1 0 0 0 0 0 0 0 0 0

* Multilink1 0 0 0 0 0 0 0 0 0

* Loopback0 0 0 0 0 0 0 0 0 0

ENG-7206-QMOE#sh ppp multilink

Multilink1, bundle name is VoIP-2621-MDF

Bundle up for 6w5d, 1/255 load

Receive buffer limit 24384 bytes, frag timeout 1000 ms

0/0 fragments/bytes in reassembly list

0 lost fragments, 69293 reordered

0/0 discarded fragments/bytes, 0 lost received

0x848C49 received sequence, 0x83D296 sent sequence

Member links: 2 active, 0 inactive (max not set, min not set)

Se5/0:0, since 6w5d, 3840 weight, 1496 frag size

Se5/1:0, since 6w5d, 3840 weight, 1496 frag size

Since ifIndex 6 & 7 DO exist on this router, why do you think the router responds back with 'errstat 2' for these interfaces?

Joe Clarke · ‎05-09-2007

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.

Martin Ermel · ‎05-09-2007

Hi Jim,

You wrote: 'ifIndex 6 & 7 are serial interfaces on the router bundled into a PPP Multilink interface as shown here - if I read the output below correctly:

ENG-7206-QMOE#sh int summary

[...]'

but in the output that follows, the ifindices are not contained and it is not correct to just count the interfaces from top to down in a 'show' output of the router.

You should query the router to get the correct correlation between ifindex and interfaces as discribed here:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080157626.shtml

jkeeffe · ‎05-10-2007

You've given me lots of food for thought and some reading to do. Thanks!

Martin Ermel · ‎05-09-2007

Hi Jim,

You wrote: 'ifIndex 6 & 7 are serial interfaces on the router bundled into a PPP Multilink interface as shown here - if I read the output below correctly:

ENG-7206-QMOE#sh int summary

[...]'

but in the output that follows, the ifindices are not contained and it is not correct to just count the interfaces from top to down in a 'show' output of the router.

You should query the router to get the correct correlation between ifindex and interfaces as discribed here:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080157626.shtml