rf domain - controller managed and control vlan
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎11-02-2018 11:21 AM
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,
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 21
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎11-05-2018 01:52 PM
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.
- 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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎11-05-2018 01:52 PM
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)?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎11-05-2018 01:52 PM
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.
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎11-05-2018 01:52 PM
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
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎11-05-2018 01:36 PM
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? 
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? 
