Header Only - DO NOT REMOVE - Extreme Networks

rf domain - controller managed and control vlan


Hello,

We have a rf-domain with 78 AP's. Right now that rf domain is controller managed. We would like to give it a vlan for control traffic where in our case it would be 1 since the AP's interface is vlan 1.

I heard that the max amount of AP's you can have in a rf domain and have a control vlan is 64. Is it possible to have both controller managed and a control vlan at the same time ? We tried that before and got reports that clients could not connect ( rf guns).

Just trying to find out what went wrong here.

Thanks,

21 replies

Userlevel 4
Daniel,

The answer is that it depends on the model of APs being used. With most recent AP models, that limit was raised to 128. And even more recently, if using the higher end model APs, the limit was raised again to 256.

What AP models do you have?
Chris,

They are a mix of 7522's and 7532's, most being 7522's. They seem to be somewhat newer so it looks like it should be more then 64 correct?
Userlevel 4
Yep, those would be rated for 128/RFDomain.
And to answer your other question, yes...you CAN have a mixture where the RFDomain Mgr is an AP and others use the controller (controller managed RFDomains)
Thanks for the quick answer Chris.
We tried to put one of our rf-domains in a control vlan instead of controller managed. We changed the control vlan to 1 since that is the vlan the AP interface is. After the change, clients could not connect to the wireless.

Checking a couple things, everything looked good. All AP's adopted, doing a "show mint nei on " shows only AP's in that rf-domain.

Any ideas on what to check?
Userlevel 4
Changing the RFDomain over to controller-Managed shouldn't have anything to do with a client's ability to associate. To be clear, are you saying that *NO* clients in this reconfigured RFDomain can then connect after the change?

Is the WLAN setup for PSK or .1X authentication?
What exactly are you seeing happening from the client's end when they attempt to connect?

To get a view on what the APs are doing, you can also use the Event History panel in the Diagnostics tab (under the Fault Management sub-tab) in the UI.
Select the Access Point(s) tab at the top, pick the RFDomain and one of the APs that you think the client is attempting to associate and then click on the 'Fetch Historical Events' down at the bottom right. Sort the Timestamp column and then start looking for a client Message indicating authentication/Association failures.
There were no issues with controller managed. The issues started when we changed the control vlan to 1.

WLAN's are setup for PSK. The clients see the SSID's, just cant connect. This was WLAN's for scan guns and computers\phones.

I will try and see what the AP's are doing.
Userlevel 4
Daniel, mis-read your previous statement.
I understand now that you moved the configuration away from being setup as controller managed TO having a control vlan setup....and that when it was configured as controller-managed, it was working.

Last comments still apply though. This change shouldn't have any affect on a client's ability to connect if the WLAN(s) are setup with PSK authentication.

I'm still wondering though, are the clients connecting but just not able to pass traffic....or can they simply not associate at all? Obviously, there's a BIG difference between those two situations, right? 🙂
Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.
Userlevel 4
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Hi Daniel,

Is it possible to paste the running config and changes you wish to commit?
Maybe from this something will become clear.
Tunneled WLAN?

Kind regards,
Tomasz
Userlevel 4
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Yeah, like I mentioned, unless this is some new very weird bug, there's a configuration option somewhere that is causing this.
But....with a PSK WLAN, clients should *still* be able to associate, no matter what. There might be a config that maybe prevents the client from being able to reach a backend server or something like that, but the clients should still be able to at least associate.
Userlevel 4
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

What if (I don't know here) MiNT is level 1 and now it should theoretically become level 2 for RFDM-to-controller communication, and a WLAN was tunneled (perhaps)?
Userlevel 4
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Under the covers, what's happening when you make this between controller-managed and not using it, is this:
- Going from non-controller-managed to controller managed: Within the RF-Domain, instead of an AP being elected to operate as the 'RFDomain Manager' for that RFDomain, the controller will take on that responsibility.
- Going from controller-managed to non-controller-managed, (in a Distributed architecture) the controller will no longer be the RFDomain manger for that RFDomain, and now one of the site's (RFDomain) APs will be elected to operate as the RFDomain manager.

Regardless, whoever the RFDomain manager is, that device simply takes on a couple of additional responsibilities. (E.g, collecting and aggregating stats to send to the controller, distributing firmware updates, assigning power/channel decisions to the RFDomain's APs if using SmartRF). None of these functions have anything to do with a client's ability to associate with an AP within that RFDomain.
Userlevel 4
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Tomasz:

Regarding that scenario:
If MiNT adoption to the controller is/was via level-1 MiNT link...and now it *should* be level-2, and the WLAN is configured as tunneled....

In that case, if the APs adoption was left as being adopted using level-1 MiNT, then no issue. Tunneled traffic over level-1 MiNT. Good to go.
If the AP adoptions were changed to level-2 adoptions and the WLAN was tunneled, then yes....this would break communications. The APs would have to be setup to tunnel traffic over level-2 MiNT links. It can be done, but has to be configured.

But....even still, it shouldn't stop a client from simply associating with an AP. Worse case, the client can associate, but cannot pass traffic through the AP. But they'd still be associated, right? That's what I'm trying to figure out here....are the clients *actually* associating or not.
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Yes, all WLAN's are tunneled.

Here is how the rf-domain is now. We just change the control vlan to 1 instead of controller managed.

rf-domain Ind-Exp
location Ind
timezone EST5EDT
country-code us
use smart-rf-policy "SMARTRF INDUSTRIAL"
layout area Outside
layout area Building-1
layout area Building-3
layout area Building-2
controller-managed

How an AP in that rf-domain is setup :

PrimaryControll#sh ip int brief on Ind-Exp-AP-66
-------------------------------------------------------------------------------
INTERFACE IP-ADDRESS/MASK TYPE STATUS PROTOCOL
-------------------------------------------------------------------------------
vlan1 10.160.11.81/24(DHCP) primary UP up
vlan1 169.254.165.16/16(ZEROCONF) secondary UP up
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

We could not get clients connected at all. This ranges from cell phones, laptops and scan guns. Once we change it back to controller managed, they automatically connect just fine.
Userlevel 4
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Daniel.....I don't want to sound like I'm unnecessarily splitting hairs here, but can you tell me how *YOU* define 'not able to connect' ?

I'm trying to figure out if this is an issue with clients successfully associating to APs but not able to pass traffic.... versus clients not able to associate with APs...period.
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Clients could not join a wireless network at all. My phone could not join the guest wireless network (could see the SSID just would not join) and the scan guns could not join their wireless network (connects automatically when the SSID is present).

Being in the same location and changing it back to controller managed, everything connected like it should.
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Clients could not join a wireless network at all. My phone could not join the guest wireless network (could see the SSID just would not join) and the scan guns could not join their wireless network (connects automatically when the SSID is present).

Being in the same location and changing it back to controller managed, everything connected like it should.
Userlevel 4
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Okay...if the clients are losing their ability to associate to the APs after making this simple change, then there's some sort of problem here that I don't understand. (bug?)
I'd recommend reaching out to GTAC in this case to discuss the issue.

If you want to try this again though, as I mentioned earlier, look at the Event History section on the controller to see what the APs are doing while the clients are attempting to connect. If the associations are actually being rejected, the logs shown there should shed light on WHY the rejections are occurring.
Daniel Starosciak wrote:

Yes, it is very strange. Clients could not connect at all. We made the change this weekend and were on site. The clients could not connect when the control vlan was 1 and when we changed it back to controller managed, they connected fine.

Yes, we will be trying this again and I will be looking at the event history. Thank you Chris.

Reply