Wireless Access

Hi.

We have the need to have two seperate controller clusters running different versions of code.  One cluster will continue to run ArubaOS 6.3 to support legacy AP 65s for the next few months.  The other cluster will run ArubaOS 6.4 and newer to enable support for AP 205s.  We'll have to intermix APs on different controllers in a few buildings for the next few months as 6.4 does not support the AP 65s we need to keep due to a lack of manpower for a full swap out at this time.

Both controller sets have the same SSIDs configured with "vlan-mobility" enabled on all SSIDs and the same exact VLANs pushed to the controllers and same VLAN pool configuration bound to each SSID.

Basic testing with a handful of devices shows that VLAN is being preserved as devices roam between controller clusters.  The roaming itself on a 802.1X VLAN is sadly a little rocky with iPads but at least it preserves VLANs when the iPad gets around to reconnecting.  I'm a little nervous to go live with this however as I don't understand HOW VLAN is being preserved.

Is this simply a function of the client to VLAN hashing algorithm assigning the same VLAN on both clusters because they have the same VLAN pools configured and run the same code version?

If I bump one controller set to 6.4 and leave the other on 6.3 will this VLAN hashing change and break things?  

Should I be enabling IP mobility even though they have the same exact VLANs supplied to each controller set and SSID?

Thanks.

Please see the article here:  http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-does-VLAN-mobility-work/ta-p/179040 that explains what is done when VLAN mobility is enabled.  Make sure the mac address of your client appears in the bridge table (show datapath bridge table) on the target controller before testing.  Your experience being "rocky" could be attributed to a few things, like roaming from an AP65 to an 802.11ac AP.  You might want to get to the bottom of that before you deploy.

IP Mobility is typically for roaming between controllers that do not have access to the same client VLANs.  When the user roams to a "foreign" controller, a tunnel is created back to the original controller so that the user can maintain the same ip address.  That does not suit your current case here.

The client does appear in the bridge tables of the other controllers before roaming.  That part seems to be working.  The bridge table seems similar to a switch learning which MACs are on which port based on ARPs/DHCP broadcasts/etc right?  So no communication needs to happen between controller clusters to populate this table correct?

As for the rocky roaming I'm testing with an AP 65 in an area with different 802.11n and 802.11ac models.  The only roaming problems I've been noticing are the Apple devices seem very reluctant to connect to the AP 65 after being connected to an 802.11n 40mhz or 802.11ac.   Do you think knocking both 2.4GHz and 5GHz down to 20Mhz wide would help Apple devices?  

Thankfully there are almost no 40mhz+ capable APs in the affected buildings right now and we don't have much of a choice for the next couple of months anyway.

Thanks again for your great help! :-)

I would try 20 mhz channels to start, yes.

I'll give that a try.

Thanks again for your help!