Wireless Access

Hi,

 

We are facing intermittent connectivity issue where client couldnt not connect to network via wifi for several minutes, but will recover on its own after a while. Based on user-debug logs, it seems the problem maybe related to roaming.

 

I would like to understand what happens if the client moves from one AP (lets call AP1) with Ap group 1 vlan 1 , to another area and associates to AP2 belonging to another ap-group2 vlan2. I can see in the debug that controller keeps the old client entry (old ip/mac) until it times out after 5-6 minutes. Also in the logs, i can only see the new IP assignment around 5 minutes after the logs say the cleint roamed to AP2.

 

My question is does the controller not process any dhcp related request and forwarding, for the new vlan until the old vlan entry clears out?

 

Or is the controller always processing dhcp request for new vlan, regardless if there is still user entry for old vlan? and instead should i be looking into the dhcp server lease/conflict timers as well and see if it is processing the reuqest.

 

i havent enabled dhcp logs in controller so i cant say for sure what is going on in dhcp level..

is the SSID the same for both groups?


#AirheadsMobile

SSID and controllers are the same.

Let my try to summarize and understand:

 

- You have one controller;

- Different AP groups in the same physical space (so clients can roam between AP's in different groups;

- You assigned to the same SSID in the different AP groups a different client VLAN;

- Mobility is disabled;

 

If that is the case, the behaviour you experience is perfectly matching your design. When clients roam from one AP to another AP on the same SSID, most clients assume they stay in the same network, so they will not even try to get a new IP address through DHCP. Exception sets the rule, as some clients do. But if a client does not get a new IP address, it will try and try and only after some time find out that there is no more IP connectivity and try to get a new IP.

 

Having said that; with controllers (tunneling traffic, central breakout) there is no need to set different VLANs on different AP groups. The best practice is to keep the same VLAN across the whole infrastructure or at least the parts of the infrastructure that are close enough to provide roaming.

 

Some admins use multiple VLANs because they learned that as a best-practice in wired networking to keep the broadcast domains at a controlled size. For (modern enterprise) wireless that is no longer an issue. Please check the Single VLAN Architecture document (http://community.arubanetworks.com/t5/Validated-Reference-Design/Single-VLAN-Architecture-for-WLAN/ta-p/257196) for a more in-depth view on this topic.

 

If you use Aruba Instant, and need to deploy multiple clusters (to keep the broadcast domain for the AP's on the wired itself controlled small, what a paradox ;-) you should configure L3 roaming to support clients moving across VLANs while roaming.

 

Did I read your question correct??

 

What is the underlying reason to disable mobility?

The current setup is

- its not really one physical space, we split these spaces according to functions , hence the differences in AP groups depending on location. however they all use the same SSID. this means moving from one location to another means the client will be assigned to a different vlan.

 

- we do have 2 controllers, but before i get into the details, regardless of our controller setup, what i would like to understand first is what is the expected behavior in a single controller setup, when one client roams from one AP on VLan1 to another AP on vlan2 (no mobility is enabled). This will mean the controller will still have user ip entry in his table for the previous vlan , even if the client is already assigned to vlan 2.

 

I want to know how the controller will behave  and if there is any process/behavior that is breaking the process of the client getting a new ip in new subnet?

 

I can't find any document yet that explains this in detail.

 

By default, if you disable mobility, your client will just be dropped in a different VLAN on a roam within the same SSD, and lose connectivity because it does not know it roamed to another VLAN.

 

So, again, best-practice (and heavily recommended) is to keep the same client VLAN for all clients in a SSID. If you want to make a difference based on location/function, use the role-based firewall and attach roles to functions. Switching VLANs while roaming is asking for troubles, not recommended, unlogical and not needed in 99.99% of all deployments. If you insist that there is a solid reason in your specific case to switch VLANs, and there is no alternative, you can check the Mobility section in the ArubaOS documentation: http://www.arubanetworks.com/techdocs/ArubaOS_6.4.4.x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/Mobility/Mobility.htm%3FTocPath%3DIP%2520Mobility%7C_____0 .

The client will not do a dhcp request, if the ssid is the same, as it doesn't see a network disconnect when it roams. this is not something controlled by the controller but by the client. The client will, I believe at half lease time, send a dhcp packet to renew the ip address and i would expect at this time get a new address in the new vlan.


#AirheadsMobile

I did a DHCP debug and actually after the client associated to the new AP, I can see DHCP DISCOVER and OFFER logs but they are still in the old (and wrong VLAN).

I think this means the client is indeed sending the DHCP discover request, but the controller is forwarding the dhcp request to server using the wrong vlan number. And then this results in the server offering the original ip (or even new ip) but still in the old vlan...

 

 

 

 

Please open a ticket with Aruba TAC as what you are doing seems to be non-standard and not following best-practices of keeping the VLAN the same everywhere in your mobility domain to provide seamless roaming.