%SNMP-SW1-3-INPUT_QFULL_ERR

[amit bhatnagar]

Hello ,

We have pair of 6500 in VSS running image 15.1(1)SY1. from last couple of days we are getting below alert in logs .

%SNMP-SW1-3-INPUT_QFULL_ERR: Packet dropped due to input queue full

We have below configration for snmp on the switch

snmp-server community abcd RO

snmp-server community efgh RO

I see drops when in show snmp as showed in below output

6509#sh snmp

Chassis:

23278017 SNMP packets input

    0 Bad SNMP version errors

    167 Unknown community name

    0 Illegal operation for community name supplied

    2 Encoding errors

    30920868 Number of requested variables

    0 Number of altered variables

    11272350 Get-request PDUs

    1682566 Get-next PDUs

    0 Set-request PDUs

    2469 Input queue packet drops (Maximum queue size 1000)

23275336 SNMP packets output

    0 Too big errors (Maximum packet size 1500)

    2441 No such name errors

    0 Bad values errors

    0 General errors

    23275336 Response PDUs

    0 Trap PDUs

SNMP logging: disabled

Please advise what is best way I can resolve it we have latest image I dont think its a bug , do I need to remove snmp configration or is there better way to resolve it .

Thanks for help

[Jose Solano · Accepted solution]

Hi,

These errors are sometimes seen when SNMP polling is set up to
devices in such a fashion that it gets bombarded by many SNMP requests
within a relatively short period of time.  Also, it possible that you have
multiple SNMP stations polling the devices, and these requests can coincide.
This will certainly cause CPU to spike up.  For processing SNMP packets the
switch needs to spend CPU cycles. If the devices are bombarded with SNMP
requests spiking CPU, this is expected behavior and is not a problem.

Under these circumstances, the best thing to do is to identify  the
offending NMS servers to see if they you can better manage the polling.

 

Are you experiencing high-cpu due to SNMP ENGINE that is coinciding with
these errors (show proc cpu | inc snmp)? 

If so you may to open a TAC case to identify the root cause, hope this helps.

[Preston Chilcote]

 After investigating lots of TAC cases for this error, it seems the root cause is almost never related to too many snmp polls.  The queue size is fixed at 1000 (it cannot be changed, even with the snmp queue-length command) which should be plenty for most cases.  The reason for the queue backing up is most commonly a specific OID, taking too long, which causes all subsequent snmp requests to backup on the queue.

There are ways for TAC to find the guilty OID, and there are workarounds, as discussed on the thread, but users should beware of blocking the guilty OID's, because it will prevent NMS stations from getting full data from the Cisco devices.  Restarting the snmp process is only a temporary measure, and the problem is expected to return eventually.

We are working on an enhancement, CSCuz93302, initially for catalyst 6500 that will make this error less vague and identify the SNMP that is taking too long to run.  That should allow users to solve these cases reliably through google searches.

[malcolm.price]

Hi Amit,

Did you ever get the issue resolved ?. I'd be keen to learn the outcome that's all,

Thanks :-)

[amit bhatnagar]

hello mate issue is resolved when we did reset of snmp it never came back

[malcolm.price]

Hi Amit,

Cheers for letting me know, we have a similar issue and have raised this with tac, we reset snmp and it was resolved until Cisco Prime re-run it's inventory. Then the issue re-occured. I think your hitting the bug, namely,

%SNMP-3-INPUT_QFULL_ERR when polling the CISCO-SWITCH-ENGINE-MIB

CSCul86573

Description

Symptom:A Cisco 6500 generates the error message when polling the CISCO-SWITCH-ENGINE-MIB:
"%SNMP-3-INPUT_QFULL_ERR: Packet dropped due to input queue full".Conditions:A supervisor 2t engine running 15.1(1)SY1 on cisco 6500 generates the error message " SNMP-3-INPUT_QFULL_ERR Packet dropped due to input queue full".
This issue has been found when the switch is added to Ciscoworks LMS and an inventory collection job runs. The job queries CISCO-SWITCH-ENGINE-MIB and the switch stops responding to the snmp and we can see SNMP-3-INPUT_QFULL_ERR Packet dropped due to input queue full in the logs of device.
Workaround:Do a warm restart of SNMP ENGINE to get device respond to snmp request.
OR
Create a snmp-server view blocking this portion of the mib tree or the CISCO-SWITCH-ENGINE-MIB.
ie:
snmp-server view cutdown iso included
snmp-server view cutdown 1.3.6.1.4.1.9.9.97 excludedApply the view to your community:no snmp-server community < your string here> RO
snmp-server community < your string here> view cutdown RO

I'll let you know what tac say..