AP Switching Between Controllers – Unexpected Behavior

[athan1234]

Hello, I’m wondering how it’s possible for an Access Point (AP) to initially register with one controller and then, after some time, switch to another controller.

//////////////////////////////////////////////////////////////////7

I'm also seeing this in the logs.

*Jun 18 00:39:06.006: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:39:15.237: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:39:25.511: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 3 AES-CCMP TSC replays
*Jun 18 00:39:56.301: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:40:09.647: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 6 AES-CCMP TSC replays
*Jun 18 00:41:48.188: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 5 AES-CCMP TSC replays
*Jun 18 00:41:54.360: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 9 AES-CCMP TSC replays
*Jun 18 00:42:00.828: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 8 AES-CCMP TSC replays
*Jun 18 00:42:07.005: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 4 AES-CCMP TSC replays
*Jun 18 00:42:13.172: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 5 AES-CCMP TSC replays
*Jun 18 00:42:20.363: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:42:31.658: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:42:51.901: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:42:59.096: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:43:05.251: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:43:31.943: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:43:46.325: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 4 AES-CCMP TSC replays
*Jun 18 00:43:58.595: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:45:02.000: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:46:02.835: %WIDS-4-SIG_ALARM: Attack is detected on Sig:Standard Id:3 Channel:6 Source MAC:001e.c01a.72f0
*Jun 18 00:46:10.022: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:46:24.385: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:46:40.832: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:46:51.110: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 3 AES-CCMP TSC replays
*Jun 18 00:47:28.060: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:47:50.649: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 3 AES-CCMP TSC replays
*Jun 18 00:48:05.295: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:48:11.450: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:48:28.901: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:48:46.342: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:49:13.028: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:49:23.293: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:49:34.590: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:50:06.151: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 2 AES-CCMP TSC replays
*Jun 18 00:50:27.700: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:50:45.155: %DOT11-4-CCMP_REPLAY: Client 1695.4143.5a30 had 1 AES-CCMP TSC replays
*Jun 18 00:51:02.600: %WIDS-6-SIG_ALARM_OFF: Attack is cleared on Sig:Standard Id:3 Channel:6

[Leo Laohoo]

---

@athan1234 wrote:
The controllers involved are a 4400 and a 5500

---

Da fuq?

The only firmware where 4400 and 5500 "intersects" is AireOS 4.X.X.X.  I do not believe 4400 can go 5.X.X.X.  

[athan1234]

Hi @Leo Laohoo  i can not understand to you . could you explain to me please

[Leo Laohoo]

If this is a 4400 controller, it is most probably running AireOS 4.X.X.X (or earlier).  And if the 5500 is running a similar firmware, then I can almost guarantee the APs have expired CAPWAP certificate that has long expired before 2020 (FN63942 - Cisco Wireless Lightweight Access Points and WLAN Controllers Fail to Create CAPWAP Connections Due to Certificate Expiration).

This means that the AP would not be able to join the secondary controller.  If the AP reboots, it will never be able to join a controller.  This is all because the CAPWAP certificate has long expired.

[Leo Laohoo]

---

@athan1234 wrote:
Hello, I’m wondering how it’s possible for an Access Point (AP) to initially register with one controller and then, after some time, switch to another controller.

---

Not going to happen. 

Why?  Because the certificates in the APs have long expired 15 years ago.  If the APs leave one controller it will not be able to join the other controller.

[athan1234]

 disabled the certificates and set the date on the controller. I have a screenshot from when it happened: I saw the AP registered on the 4400 controller, and 30 minutes later, it was registered on the 5500 controller. Since then, the AP has remained registered on the 5500

[athan1234]

it might be possible that when I disabled the WLAN ssid  on the 4400, roaming with the 5500 started working. We were having an issue because both controllers had the same SSID, and when an AP from the 5500 tried to roam, it had problems with the 4400. After I disabled the SSID on the 4400, I noticed the AP stayed connected to the 5500. So yes, it's possible. This machine are moving in the fabric 

[Rich R]

@athan1234 for some reason you deleted half your question? Anyway:
> My customer is asking about this behavior. The controllers involved are a 4400 and a 5500, located near each other. Both are on the
> same network range, but with different IP addresses.
> When I check the AP history, I can see that it first connected to the 4400 controller, and later it started connecting to the 5500.
> The only explanation I can think of is that the AP has the 4400 IP set as the primary and the 5500 as the secondary. However, when
> I check the AP configuration using the appropriate command, I only see the 5500 IP listed.

APs learn (discover) and remember WLC IP addresses from multiple sources and always keep the complete list for attempting to connect until you reset to factory default.  Even though it doesn't have the other WLC configured the AP could learn it from option 43, DNS, WLC mobility and broadcast discovery if they're on the same subnet or you have a helper address configured.  And it might have previously been configured for that WLC then you changed the config - it will still "remember" the old WLC IP unless you do factory default reset.  If it loses connection to primary WLC (for any reason) then it will try other known WLCs.  Since you must be running very old software there are going to be thousands of bugs (on both AP and WLC) which could cause disconnection and that's before you consider things which might interrupt connectivity on the network between AP and WLC.

[athan1234]

 hi @Rich R I’m trying to understand a behavior we’re seeing in our wireless network. The APs are not restarting, but we’re experiencing issues that might be related to client roaming. The clients are machines in motion, connecting to access points managed by both a 4400 and a 5500 controller. Both WLCs are on the same network range.

What we observed is that some machines were having connectivity problems. I noticed that both controllers were broadcasting the same SSID, which might be causing conflicts. To test this, I disabled the SSID on the 5500 controller. After doing that, I saw the APs that were previously connected to the 5500 start reconnecting to the 4400.

It seems like when a machine connects to an AP on the 4400, and then moves to an area covered by an AP on the 5500, the roaming doesn't work properly. But once I disabled the duplicate SSID on the 5500, things seemed to stabilize.

So my question is: Is it possible that having the same SSID configured on both WLCs, without proper mobility or synchronization, causes roaming or connection issues like this? Or is this behavior unexpected?Thanks in advance, and I hope I explained it clearly!

[Scott Fella]

Roaming between controllers requires a few things... mobility between the two controllers, the same code on the controllers (in case ap move from one to another), SSID's must be configured identical and mapped to the same network if possible.  You can search up "roaming between WLC's", "Cisco WLC intra controller roaming", etc. and do some reading on this.  You would be better off with a single controller so you don't have intra controller roaming.

I'm surprised your 4400 is still running, but what would you do when that dies?  Even the 5508... you really need to have a future plan just in case, because it will cost you money to replace the ap's for support.  

[Rich R]

> So my question is: Is it possible that having the same SSID configured on both WLCs, without proper mobility or synchronization, causes roaming or connection issues like this? YES
Or is this behavior unexpected? NO

As Scott has explained to support roaming between WLCs they must be configured correctly with mobility between them.
https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/107188-mobility-groups-faq.html
https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/m_configuring_mobility_groups.html

Both your WLCs are end of support and running end of support software.  Moreover with different software versions there are likely to be incompatibilities.  Definitely time to look at upgrades ...