topic I would like to follow up and in Wireless

Still having issues with AP primary/secondary controller option

Steven Shelton — Mon, 05 Jul 2021 09:31:14 GMT

Customer has two primary controllers each in HA SSO, each using v7.6.130.0, FUS 1.9.0.0; the AP population is a mixture of mostly 3502, 3602 and 1142. Both WLC's management interfaces are in the same vlan and the mobility communication is up. AP fallback is enabled on both WLC.

Over the weekend the upgrade to 7.6.130.0 was completed and the first AP tested with primary controller defined worked on the first attempt. Every successive reboot of the AP always worked. This did not work previously when the WLC was on v7.6.100.0.

L2 client roaming between APs joined to different controllers also worked great.

While the roaming test was being carried out, a few APs not involved with the testing migrated over to the new controller. This wouldn't be a problem but there are about 15 APs that must reside only one controller. As luck would have it, 5 of the APs which migrated to the new controller are APs which must stay on the other controller. Setting their primary controller had no affect. Each time these 5 APs were reset they ignored the primary controller setting and joined the new controller. These were 4 1142 and 1 3502.

What am I missing? I have checked and double checked the configuration, read and reread the documentation. I am working as a contractor and this is starting to look very bad for me if this problem can not be solved.

Thank you for your assistance.

>Customer has two primary

Mark Elsen — Mon, 16 Feb 2015 13:54:41 GMT

>Customer has two primary controllers each in HA SSO

Do you mean four controllers in total or one HA SSO pair ?

>...about 15 APs that must reside only one controller

What what's the use/sense of having primary/secondary controller(s) then ?

>...APs which must stay on the other controller.

Same question applies....

Two pairs of HA SSO

Steven Shelton — Mon, 16 Feb 2015 14:41:42 GMT

Two pairs of HA SSO controllers, a total of four physical 5508 platforms

It's a customer requirement at this point to have 15 APs only join one controller. Anyway, that is not irrelevant to the issue.

The relevant issue is why do some APs ignore their primary controller definition?

Is this a bad design, to expect to manually load balance the AP population by defining the primary/secondary controller in the AP high availability configuration? This is a currently a customer requirement. My suggestion was DNS or opt 43 to load balance APs.

Setting the high availability

Scott Fella — Mon, 16 Feb 2015 15:13:17 GMT

Setting the high availability on the access points is how it is suppose to be setup. Option 43 and or DNS is for new access points and that doesn't do any load balancing. If your access points ignore what you define, then you have something wrong. I would check the high availability and make sure the hostname is correct as it is case sensitive. With fallback enabled, the AP is allowed to move to the assigned controller defined in the high availability section.

-Scott

It's simple to verify the

Steven Shelton — Mon, 16 Feb 2015 23:17:49 GMT

It's simple to verify the capitalization of the device name by using show sysinfo. This environment places all network infrastructure in a sub domain. Since the device name is all caps, I use all caps for the FQDN.

Since upgrading to 7.6.130.0 we have success directing APs to the new controller while the other controller has <500 APs. This never worked before.

Now, we have no success with directing APs back to the other controller when they voluntarily join the new controller. This is the same behavior prior to upgrade.

Is there a debug command that could reveal the issue?

I would like to follow up and

Steven Shelton — Fri, 20 Feb 2015 19:32:57 GMT

I would like to follow up and share the resolution to this problem.

After upgrading to 7.6.130.0 and finally determining that one of the test APs was actually bad, we were able to move forward. Since removing the bad AP from the test, we now have the ability to direct APs to a specific controller at will.

In the testing, we found that using just the system name worked in all test cases. This was confusing since using the FQDN worked for some APs but not all. This issue is why I started this discussion. Nobody homed in on that detail, so I hope this will help someone in the future.

Both the primary controllers are in the same management vlan, we only used the system name.

Good luck to all!