CPU Receive Multicast Queue is full on Controller

[stokke]

Hi all.

I'm seeing the alert "CPU Receive Multicast Queue is full on Controller" on the WCS from one of my controllers. This is during peak hours and on a pretty busy WLC. I can't find any related lines in the logfiles.

Do you know of any good commands to try figuering out what is going on?

I'm currently running software version 7.0.220.0 on a WISMs.

[Scott Fella]

These have come up in the past... search this forum and you can find other post on it.  You are on a newer code, so I don't know why you would see those unless its a bug on that code.  You might want to open a Tac case to see what they say. Take a look at some of this post:

https://supportforums.cisco.com/thread/338786

[stokke]

Thanks Scott.

I've seen the other posts, but as you mention they are related to a older version of software.

I have moved my APs to another controller with even newer software 7.0.230.0 to see if I can see the same error there. If I do, I will probably file a TAC. Hopefully they will help me identify whats causing this and maybe tip me with some commands to do find it out.

I will try to keep this thread updated as I know anything else.

[Scott Fella]

Keep us posted to what Tac say's.

[stokke]

Hi again.

I've not been able to reproduce this error after an upgrade to 7.0.230.0. So it will probably be useless to try filing a TAC on this. But if I see this again I will file a TAC and update this discussion.

[jlhainy]

I have 2 Wism1 blades and 1 wism2 blade.  I have seen this error on one specific controller on one of the wism 1 blades but not the others.  All are running 7.0.116.  Now this one controller that is getting the message is also serviceing the most APs and has the most traffic on it.  Think lots of ARP requests.  That being the case, is it really possible that there is a slight issue and that balancing out APs would help fix the issue?

[Stephen Rodriguez]

that's possible. that error is pretty generic to any multicat/broadcast traffic.  So the more AP you have the more client traffic the WLC has to pass. 

HTH,
Steve

-----------------------------------------
Please remember to rate useful posts, and mark questions as answered

[jlhainy]

Also, its not like the alert automatically clears itself in a timely manner when the problem goes away.  So, it have have occured during peak times but is no longer an issue now, but the alert remains in WCS or NCS.  This is something I would like to know more about.  I have no complaints from users about wireless performance though, so even though it is a critical alert, it doesn't appear to be that critical.  If time allows, I may open a TAC case as well, just to learn more about this error and detailed steps of how to troubleshoot it.

[Craig Le-Butt]

HI

I've just started to get this error msg as well on 7.0.230 this week

We've got 18 WISM as it's only accuring on 1 controller. 

These where updated months ago.

All the controllers are configured the same (except for vlan, IP, group ect.)

The controllers have no more the 75 AP's attached to allow for redundancy.

I'd be very interested to see the outcome as we can't go direclt to TAC

cheers

[stokke]

Hi all.

A quick update from me as I was the one with the initial post on this problem.

I still don't see any errors from the controllers during normal operations. We still run 7.0.230.0. But we did see this message last time we did a reboot of several of the controllers. We did this reboot to test that APs did fall back to their primary controller after a controller reboot. Just as the controller came back online and the APs started to join, the error message appeared.

So I guess it is triggered by the amount of traffic generated as the APs and clients starts to stress out the controller. ARPs, Multicast messages related to Mobility Groups... I don't know.

We haven't gotten any user complaints that we can relate to this message, so currently we are pleased with the fact that this only happens during reboot.

As a little note I might mention that we are currently using "Interface Groups" on some of our WLANs. With a good amount of large VLANs/Interfaces in one "Interface Group", we see that there is a pretty large amount of ARPs from clients reaching the controller, APs and clients. This might be a trigger and we will try to turn on "Peer-to-peer-blocking". The documentation says that this might have an effect on ARP behavour.

[Saravanan Lakshmanan]

#make sure the vlan-s are pruned to the WLC to only what it needs from the R&S side, to shield the WLC from getting ARP,
CDP, IPmcast and so on from other unneeded vlans at trunk.

[Islam Sallaj]

Saravanan,

I am running 7.0.220 not 230, I can upgrade if that resolves the issue.  However I'm not sure if it will.  I have a WLAN that relies on large amounts of Multicast traffic (draeger health monitors). should we be doing something more to stop the queue from becoming full?  We can prun our vlans on that truck are you sure this will resolve the issue.  When you say "pruned to the WLC to only what is needs from the R&S" what does R&S stand for?  Just want to make sure nothing is lost in tanslation here.  This controller is a critical compontant to our patient safty infrastruction.

Thank you in advance.

Regards,

izzy

[Scott Fella]

R&S is route switch. Upgrading might help but read the post and see what code they are having this issue on.

Sent from Cisco Technical Support iPhone App

[Scott Fella]

There is a reference to another thread in this post. Here is what others did.

https://supportforums.cisco.com/message/1302003#1302003

Sent from Cisco Technical Support iPhone App