Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

snmp input queue full on c3750

Hi All,

I get this error below on a 3750 stack (running 12.2.46), and i can only make it disappear if i reboot the switch, but it comes back again after a while. before i reboot the switch, it does not respond to SNMP

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


I can see that others have had the same problem, but with another SW version. Does anyone know if it's a bug i the software?

Thanks,

Jesper

Everyone's tags (1)
17 REPLIES

Re: snmp input queue full on c3750

Hi All,

I get this error below on a 3750 stack (running 12.2.46), and i can only make it disappear if i reboot the switch, but it comes back again after a while. before i reboot the switch, it does not respond to SNMP

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


I can see that others have had the same problem, but with another SW version. Does anyone know if it's a bug i the software?

Thanks,

Jesper

Hi Jesper,

Genral recommendation for the above error is Use the command show snmp to see the number of packets dropped.

Stop any SNMP access to the device until the error condition is recovered.

Check out the below link about the error, hope this helps out your query !!

http://www.cisco.com/en/US/docs/ios/12_2sr/system/messages/sm2sr07.html

If helpful do rate the valauble post.

Regards

Ganesh.H

New Member

Re: snmp input queue full on c3750

You have posted a link to a page that says "This documentation has been moved." - now help in that

Cisco Employee

Re: snmp input queue full on c3750

Hi,


please find the details below:

Error Message    SNMP-3-INPUT_QFULL_ERR: Packet dropped due to input queue full 

Explanation: Snmp packet dropped due to input queue full error

Recommended Action :  Use the command show snmp to see the number of packets dropped. Stop any  SNMP access to the device until the error condition is recovered.

<http://www.cisco.com/en/US/docs/wireless/access_point/12.4_10b_JA/configuration/guide/scg12410b-appC-errormsg.html#wp1046060>

Possible short-term workaround could be to restart SNMP Engine. This will also serve us as test case. To restart the SNMP Engine, un-configure snmp
and reconfigure a community strings as below:
no snmp-server
snmp-server community RO 10
snmp-server community RW 11
snmp-server community RO 10

The rest of the SNMP configuration will not be lost. Of course you'll
need to replace "" with actual community strings.

To summarize, Action Plan:
===
show stacks 215
(wait 5 min)
show stacks 215
show processes cpu | inc SNMP
show running  | inc community
conf t
no snmp-server
do show processes cpu | inc SNMP
(copy/paste snmp-server community commands we obtained from running-config)
end

Now please verify if SNMP Agent on the device responds properly and if %SNMP-3-INPUT_QFULL_ERR aren't present
in the log.

Hope this helps!

Thank you!

Cheers!
DB

New Member

snmp input queue full on c3750

I just had the same problem on a WS-C4506-E. I restarted the SNMP engine as suggested. That seems to have fixed the problem.

New Member

snmp input queue full on c3750

Yes , this solutiuon works for a short time, but then the SNMP goes down again. I suspect that it has something to do with snmp from CiscoWorks. If I block SNMP from CiscoWorks in the firewall, then SNMP works fine. If I unblock the SNMP traffic, it goes down again after a shot time.

Rgds,

Jesper

New Member

snmp input queue full on c3750

I have same error on my 3750E 9-switch stack. I am running on 12.2.(53).SE2. Does anyone know which IOS version fix this problem?

Cisco Employee

I know this is an old thread,

I know this is an old thread, but it's the first that comes up in my google search, so I'm updating it to get the most attention.  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.

New Member

Hi Preston, 

Hi Preston, 

Any update on this - I seem to be experiencing this issue on my 3850 stack (Version 03.02.03.SE).

Thanks

Chris

VIP Purple

That's a very buggy version

That's a very buggy version your on , real early edition with a lot of known issues  , I would move to a safe harbour version that's available in the website  

Cisco Employee

Mark is right, but we don't

Mark is right, but we don't call it "safe harbour" anymore.  Rather, just "recommended release", which are those with a gold star on the download page.  The bug for 3850 is CSCuo12316, which hasn't been seen in 3.3 or later.  3.6 is the recommended release, currently, for this platform.

New Member

Thanks Mark/Preston - I'll

Thanks Mark/Preston - I'll look at upgrading the version :)

New Member

Hi Guys,

Hi Guys,

Quick question - can I upgrade from 3.2 to 3.6 or will I have to incrementally install updates? e.g. 3.2 > 3.3 > 3.6

Thanks

Cisco Employee

I don't know of any reason to

I don't know of any reason to do incremental updates for 3850, so I think you should be able to just upgrade straight to the new version.

New Member

Thanks :)

Thanks :)

New Member

Hi Preston

Hi Preston

I have exactly the same issue here as per this thread. Unfortunatley, we have version 03.06.04.E Which is still giving the same issue.

Is there a particular version of 3.6 we should be using?

Current set up is 4 x 3850 48P  in a stacked set up

Thanks in advance

New Member

Hi CDale,

Hi CDale,

I upgraded to  03.06.06E last week and it's resolved the issue (so far so good)

We only have a 2 switch stack ( 2 x 3850 48P) so my environment is slightly different.

Cisco Employee

This is exactly why I pushed

This is exactly why I pushed to have the error message be more specific.  There are many bugs that lead to this problem.  Off the top of my head, I don't know of another one for 3850, but if you open a TAC case they can lead you through the troubleshooting steps to isolate which bug.  If they ask you do perform a workaround (like restarting SNMP), beware that the problem will most likely come back later, so it's important that they use this opportunity, while the problem is happening, to collect the necessary information to pinpoint the bug.

38344
Views
20
Helpful
17
Replies
CreatePlease to create content