03-10-2009 10:43 AM - edited 07-03-2021 05:17 PM
A rogue containment policy is being initiated against my organization's APs and I do not have the tools/knowledge necessary to track down its point of origin. What tools or steps are required to identify who is containing an AP?
Thanks
03-17-2009 02:27 PM
If that is true, then our system is indeed containing its own APs for the MAC address listed is that of one it manages.
leolaohoo mentioned a firmware bug in the controller could be causing this in a previous post. It sounds as though I need to take this issue to TAC.
03-17-2009 02:51 PM
I don't remember what firmware or the bug ID but the early versions of firmwares (4.x and 5.0.x) would say something like "... potential Honeypot AP ..." and if you look at the MAC address of this AP, it's actually another one of your LAP.
Regarding your Rogue AP, can you go to Monitor -> Rogues -> Malicious APs and base on the MAC Address see if you have the Rogue AP is in the list. If the Rogue AP is in the list, then your WLC will automatically contain it when the Rogue AP starts transmitting. You have the option to remove the AP from the list.
03-17-2009 07:52 PM
I will try to get hold of you tomorrow at work. I suspect what you are seeing might be a man in the middle attack.
03-30-2009 08:00 AM
Hi Dennis,
I would like to know if you had found out the reason for the containment.
Actually we have the same issue.
*Mar 26 09:44:42.498: %LWAPP-1-AP_CONTAINED: spam_lrad.c:21271 AP AP3 is being contained on slot 0
*Mar 26 09:43:24.676: %LWAPP-1-AP_CONTAINED: spam_lrad.c:21271 AP AP30 is being contained on slot 0
*Mar 26 09:41:30.437: %LWAPP-1-AP_CONTAINED: spam_lrad.c:21271 AP AP30 is being contained on slot 0
Thanks
Martin
03-18-2009 06:12 AM
William,
I don't know if you've tracked this down to being a bug or not. But earlier this year I was getting the same alerts from one of my sites, intermittent, off and on etc. It plagued us for a few months. Long story short, required a site visit. I went on site and using AirMagnet Laptop Anyalizer was able to trace the deauth frames to one of our Neighbors who it turns out had recently installed CUWN and was containing our AP. They had 2 or 3 AP's participating in the containment. When a AP is containing you it will spoof your AP's MAC so that it looks like the Deauth frames are being sent by your own infrastructure.
03-30-2009 03:30 AM
Hello,
we have exact the same problem.
Our LWAPs are being contained.
There are two other Access Point vendors in the environment, one Cisco autonomous AP and one AVM Home Office AP. Both are not able to contain other access points.
Do you have got a solution for your problem?
thanks
Martin
03-30-2009 08:59 AM
At this point the containment has ceased, but the cause has not yet been determined. The intermittent nature of the issue is making it very difficult to troubleshoot.
Cisco TAC has yet to respond to my inquiry.
03-30-2009 03:18 PM
Hi Martin,
Make sure Auto-Contain Rogue AP is not enabled.
Can you verify that your WLC is not manually containing your own AP?
04-09-2010 08:32 AM
I currently have this weird issue too
I have no idea why. It started yesterday and continued today. I know that some people are in that area playing around with some Zigbee RFID tags, but I don't think that should make a problem?
Here from the controller logfile:
wism-1250-2: *Apr 09 14:40:03.582: %LWAPP-1-AP_CONTAINED: spam_lrad.c:25558 AP 1200b-6106-1 is being contained on slot 0
Containment is after around 1 minute over (WCS sends two mails, one with containment and one with CLEAR). I don't know if the users have some issues because of this, so far only one complained, but that could also be because he's using an Apple and not a stadard client.
The controller logfile doesn't show a "resolve" of the containment.
Auto containment of rogues is disabled on the controller.
Any ideas? Or did you ever receive an answer from your tac case?
Thanks,
Patrick
04-09-2010 03:51 PM
What firmware is your WLC? I know that in the 5.X firmwares would report that your own AP is a rogue AP or a honeypot AP. This is ok because we disabled (by default) auto-contain of rogue APs. How about you?
04-11-2010 11:39 PM
Oh I somehow forgot to mention the release. It's software version 6.0.188.0.
04-12-2010 01:49 AM
We have 17 Access Points in our environment and 2 SSIDs.
As we disabled 10 APs the containment stopped but at the moment we enabled the APs the containment started again.
A few weeks ago we updated the WLC to 6.0.188. and it seems that the containment doesn't happen. Actually all 17 APs are enabled.
The old software was 5.1.
Do you have a dense AP environment?
04-12-2010 01:57 AM
It is a dense setup, but not there where it's happening. I have there only like 2 accesspoints in a wide area with walls between them.
But I do have some RFID tags and scanners there (or actually the company there has) which are also sending in the 2,4GHz range. They do use their own protocoll, so the Accesspoints only see them as noise.
12-13-2011 12:05 PM
I've been seeing this same problem with one of our APs. The AP is managed on a 5505 WLAN Controller running software version 7.0.116.0.
Message: ASBN-WLC7: *spamApTask1: Dec 13 13:48:08.641: %LWAPP-1-AP_CONTAINED: spam_lrad.c:27637 AP SFONW-Quad-D is being contained on slot 0
On the WLAN Controller [ASBN-WLC7]
Security
Wireless Protection Policy
Rogue Policy
General
RLDP - disabled
None of Auto Contain option enabled.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide