Why are some WLANs not tunneling traffic on all access points?

[Micah]

Hello everyone,

I have an RFS-4000 cluster managing a mix of 6532 and 6562 access points. I have 5 WLANs, all of which are enabled on all radios, and using the default profile for each access point type. All WLAN traffic is tunneled through the controller. The configuration is quite basic, and it has been up and running for several years, without any significant adjustments.

We had a UPS failure several months ago, and the primary controller, as well as about half of the access points lost power. After restoring power, we have two WLANs (out of five) that are acting funny. The main problem I am having is that sometimes, when clients are successfully associated on one of the affected WLANs, no traffic seems to be tunneled out to the rest of the network. DHCP fails immediately, and even when assigning a static IP address and DNS, the wireless client is unable to communicate with anything else on the network.

The thing that makes this particularly confusing is that other WLANs on the same access point function fine at the same time. And functionality on the affected WLAN can be rock solid when associating with a different access point. Given that the WLAN and AP policies are the same across the entire configuration, and all traffic is tunneled, I'm not understanding why the issue would only affect a subset of the WLANs on a subset of the APs.

My ability to perform trial and error troubleshooting is very limited, as I am not located at the site, and the facility operates 24/7. Therefore I'm trying to line up some specific ideas about thing I can investigate or try when I am able to schedule a maintenance window.

Has anyone else seen an issue like this before? Any thoughts on a good way to start investigating?

Thank you,
Micah

[Andrew_Webster]

Extreme has just written an article specifically dealing with licenses across clusters.
https://extremeportal.force.com/ExtrArticleDetail?n=000021938

[Micah]

Hi Doug, thank you for following up. I was able to repair the cluster over the weekend, but it doesn't seem to have helped with the main problem. My next step will be to upgrade the code to the latest version. It will probably take me several weeks to get another downtime window scheduled though.

[Doug]

Hello Micah,

Were you able to resolve this issue?

[Micah]

Andrew,

Thank you so much for your observations!

The two access points that were already offline were known (one is a spare). You pointed out the 18/19 issue just in time though, and I disabled one additional access point that is not needed right now, so I should be safe at 18 for the moment.

During my maintenance window this weekend, I should be able to bring the secondary online to re-sync the license status, and to adjust the ports on both controllers to use just one trunk interface. I will also schedule a time to do a code upgrade, but that will probably have to wait a while longer. The shouting match scenario you mentioned seems plausible. I believe we have seen that issue twice over 4 years. The first time a reboot resolved it.

I see the 'cluster handle-stp' line in the config, but it's not familiar to me. I am seeing some references to it online, but nothing explaining what it does. Would it be better if I disabled that, and just let the switches handle stp, especially after the controllers are only on a single interface each?

Many thanks,
Micah