Showing results for 
Search instead for 
Did you mean: 

AP Impersonation on WLC

Has anyone seen the WLC reporting its own APs as impersonating APs? I checked the forum and found one conversation relating to this and my 802.11a is set to Country already. But I am see ing this on the B/G side. Any thoughts?

Rob Huffman
Hall of Fame Community Legend

Hi Joseph,

That is an interesting one isn't it! Do you have these AP's set up in an RF Group? If they are not I would think that this is expected behaviour. Have a look at the following;

Use the Access Point (AP) Impersonation Feature on the WCS

The AP Impersonation feature improves the detection of rogue APs that attempt to impersonate valid Cisco 1000 Series LAPs. This feature creates a radio frequency (RF) network group, and the Cisco 1000 Series LAPs in the same group distribute radio resource management (RRM) neighbor packets to each other. If a Cisco 1000 Series LAP hears packets from another Cisco 1000 Series LAP from which it has not received any RRM neighbor packets, then the Cisco 1000 Series LAP can assume that the new AP is impersonating a Cisco 1000 Series LAP and therefore reports it as a rogue AP.

I'm also curious what version of WLC you are running as there was a bug (CSCsb90622) that related to this type of problem.

Hope this helps!


Please remember to rate helpful posts....

Thanks Rob for the info.

The APs are in a RF group. The version of code I am running is The TAC Engineer I am talking with suggests upgrading the code to which fixes the bug you refer to. I'll do that and see if it resolves this issue.

It didn't for us. Not only do AP impersonation messages flood our message logs, but the controllers still see and label our own cisco antennae as rogues. Let me know how you guys make out?

This problem has persisted for us at more than one customer site since the summer of 2006 and has persisted with every revision up to and including (most recent at this time).

Have you opened up a case with Cisco TAC on this? If so, what is their response?

I believe that items like these will only get fixed if TAC gets enough pushback on them and understands that the problem is not specific to a particular installation site - which it is not.

A few observations:

I have not observed this when using the older 1010 series (AireSpace) access points.

I have seen this when using the AIR-LAP1131AG access points in both lightweight out-of-the-box as well as in autonomous-converted-to-LWAP. We also have lightweight out-of-the-box AIR-LAP1242AG access points at one of these installations.

It has also been observed in installations using AIR-AP1231's converted to LWAP.

We also see chronic AP Disassoc false alarms which (possibly) are somehow related to the other false alarm.

I suspect that in installations where there is a higher density of access points, where more access points will be detected by other access points (i.e.: multi-floor installations where RF coverage travels through the floor, academic environments with one AP per classroom to meet user density, etc.) that this problem may be more pronounced.

Also, I am wondering if the "virtual" MAC address assigned to each SSID broadcast by the each AP (where the radio MAC address is incremented for each SSID on the AP), if there ends up being an overflow of the AP's neighbor table (for example: 8 SSID = 8 MAC addresses * the number of adjacent APs can result in a fairly large table for each AP.

Or could there be problems with the system correlating virtual MAC addresses to the actual underlying AP?

- John

There's another thread bordering on this issue, where Rogue suppression is detected as a disassociation flood attack. Anyhow, one relevant bug is CSCse87066, which supposedly was fixed in but we're not entirely confident that the APs misinterpreting each other for rogue and disassociation flood purposes is actually solved yet. At least the alarm issue is still present for many people in the latest release, release notes nonwithstanding.

I am using and the issue is still present. I have asked our Cisco CE to find out if and when this will be fixed. This new code fixes the AP reboot issue, caused by the controllers not sending ARP's to the 6500.

I am using and the issue is still present. I have asked our Cisco CE to find out if and when this will be fixed. This new code fixes the AP reboot issue, caused by the controllers not sending ARP's to the 6500.

Cisco has two bugs that they have linked to the TAC cases that have been opened for the false "AP Impersonation" alarms:



I am not sure how pertinent they are to the specific TAC cases we have open, but I thought this might be worth posting here.

- John

Recognize Your Peers
Content for Community-Ad