Wireless Access

Reply
Occasional Contributor I
Posts: 7
Registered: ‎06-27-2012

WLAN Client Roaming and VLAN Mobility Question

Howdy,

 


I have received reports and then confirmed the following particular events happen across a large campus with mulitple campus buildings:

 

campus high level design:

  • Two M3s running 6.1.3.5 in local mode (1 active 1 redundant for all of the campus buildings)
  • Two dedicated wlan services switch - provides distribution layer; trunks all WLAN VLANs to both M3s
  • AP135s are deployed
  • Each campus building has multiple floors each with a per floor AP group and VAP profile (using per floor VLAN design)
  • All APs in the campus (~450) connect to the same controller and VLAN Mobility is enabled (not using Mobile IP)

 

Situation:

  • Roaming between buildings where no adjacent cell coverage is available
  • Client shuts off WLAN adapter and then renables the adapter

 

Problem:

Client always retains IP address that was received during initial 802.1x authentication and IP DHCP Address offer.

We have waited at this point in testing up to 10 minutes (it is desirable for the client to not retain the IP address when they roam out of a RF cell provided by campus APs or if the client shuts off adapter)

 

What conditions exist for the maintaining of original VLAN/IP? Is this session based?

Are there timers that can be adjusted?

 

Thanks,

 

Matt

 

Frequent Contributor II
Posts: 128
Registered: ‎03-13-2008

Re: WLAN Client Roaming and VLAN Mobility Question

Can you explain the goal you are trying to accomplish with having a vlan/Ap-group per floor?

 

What you are experiencing is normal function of the controller. The user is not out of the client table when they shut off there wireless and move from building to building (check: show user-table).

 

The testing of waiting 10 minutes should have just about gotten you there. I have seen user age out of the user-table in 8-15 minutes.

Or

You could clear the user out of the client table: turn off wireless on the host, delete the user out of the user-table(aaa user delete <mac>), move to a different building and reconnect. I bet this will have an outcome like you would expect. But why is still my question? I think you are creating a lot of management overhead for yourself with your design.


Do you get any RF bleed between floors?

 

I have a few ideas on how to work with vlans/ap groups per floor but would like to hear the use case.

 

Controller setup are you running master/master (active/standby) or master/local (active/active, active/standby).  

David Dipert
Occasional Contributor I
Posts: 7
Registered: ‎06-27-2012

Re: WLAN Client Roaming and VLAN Mobility Question

We are using per floor AP Group with dedicated VLANs. Due to specific company policy we are utilizing this method as VLAN pooling was not an option at the time we implemented the service for each building.

 

Sounds like the issue is the user client table but this leads me to ask, how does Aruba or the industry recommend managing a setup like the one that i have described?

 

With Cisco, we ran this method for years and the as a user disconnected (coverage hole or turned off their adapter) the ip address received upon the next association to a different AP group would change.

 

As for the mgmt overhead, from your POV and i can guess many other engineers POV, this may not be optimal. From our POV this method has served a great purpose due to unique policies...that should not surprise most engineers that do not have the ability to make certain changes to policy or have unique restrictions!

 

The use case is that we wish to keep each group of building users on whichever VLAN that they have available per building. It is ok to have the user start on one floor with one subnet, then move to another floor with the same subnet. It is not desirable to maintain an IP Address when moving to a different campus building.

 

A high level view for your knowledge:


Bldg X1 & Bldg X7 provide the campus a high speed backbone - all buildings connect via L3 to these two sites for campus and WAN connections

 

Bldg X1-X12 have distribution switches that connect IDF to APs and the uplink to the Bldg X1/X7 high speed backbone switches

 

Bldg X1/X7

Contain the Dedicated WLAN Controller / User network Network Distribution Switches - these connect to one controller each via L2 port-channels/trunks

 

Data Center Y1 contains pair of masters

Frequent Contributor II
Posts: 128
Registered: ‎03-13-2008

Re: WLAN Client Roaming and VLAN Mobility Question

There is a time value that user are left in the user-table. It under SSID advanced “station ageout time” this is how long users will stay in the table. You need to be very careful with this timer. If you set it to short then users will re-authenticate more often and could cause you some issues with roaming from ape to ap even in the same building. 

The other option would be to use Clearpass. Which you could use ap-group as a key  to hand out vlans by location. You could also force users to de-auth if they aren’t in the right vlan by location.

 

I’m jumping way ahead hear as I don’t even know how your network authenticates. How are you authenticating users?

 

David Dipert
Occasional Contributor I
Posts: 7
Registered: ‎06-27-2012

Re: WLAN Client Roaming and VLAN Mobility Question

802.1x authentication

 

Given that the AP groups per Building Floor separate the Access Points by floor and in conjunction with using per VLAN profiles and VLAN mobility, we then may just have to either adjust timers or ??

 

Thanks for the replies btw - Aruba troubleshooting and FAQ/research is still new for me and i appreciate your time spent thus far!

 

Matt

Frequent Contributor II
Posts: 128
Registered: ‎03-13-2008

Re: WLAN Client Roaming and VLAN Mobility Question

[ Edited ]

You can adjust timers, which isn't going to cost any money just time to test. I would keep the timer as close to default as I can. 

 

 

Could also use ClearPass Policy Manager (CPPM), other radius server might have the ability to do this also but  not sure, you could use the ap-group as part of the your authentications service which would allow you to de-authenticate users if they carried over the wrong van.  If you were going to do this I would however not do vlans per floor, I would do vlan(s) per building, which wouldn't move users around if they roamed from an AP on floor 1 to AP on floor 2 but never left floor 1.

 

 

David Dipert
Guru Elite
Posts: 21,261
Registered: ‎03-29-2007

Re: WLAN Client Roaming and VLAN Mobility Question


matthew.mckenna@capitalone.com wrote:

We are using per floor AP Group with dedicated VLANs. Due to specific company policy we are utilizing this method as VLAN pooling was not an option at the time we implemented the service for each building.

 

Sounds like the issue is the user client table but this leads me to ask, how does Aruba or the industry recommend managing a setup like the one that i have described?

 

With Cisco, we ran this method for years and the as a user disconnected (coverage hole or turned off their adapter) the ip address received upon the next association to a different AP group would change.

 

As for the mgmt overhead, from your POV and i can guess many other engineers POV, this may not be optimal. From our POV this method has served a great purpose due to unique policies...that should not surprise most engineers that do not have the ability to make certain changes to policy or have unique restrictions!

 

The use case is that we wish to keep each group of building users on whichever VLAN that they have available per building. It is ok to have the user start on one floor with one subnet, then move to another floor with the same subnet. It is not desirable to maintain an IP Address when moving to a different campus building.

 

A high level view for your knowledge:


Bldg X1 & Bldg X7 provide the campus a high speed backbone - all buildings connect via L3 to these two sites for campus and WAN connections

 

Bldg X1-X12 have distribution switches that connect IDF to APs and the uplink to the Bldg X1/X7 high speed backbone switches

 

Bldg X1/X7

Contain the Dedicated WLAN Controller / User network Network Distribution Switches - these connect to one controller each via L2 port-channels/trunks

 

Data Center Y1 contains pair of masters


 

matthew.mckenna,

 

The issue with per floor Virtual APs, VLANs is that sometimes a user will associate to the floor above or below, even while moving horizontally, creating quite a few roaming events.  You want to minimize that, because roaming, even fast roaming interrupts client traffic.  In addition, if a client roams to the same ESSID (WLAN Name) it assumes that it is on the same subnet, so if the VLAN switches behind the scenes, the client cannot pass traffic because it assumes it is on the same layer2 network that it started on.

 

In the most general sense, if you have a fiber-based campus WLAN and all access points are connected to that network, you could deploy a  single /22 or a /21 just for secured WLAN clients as a single VLAN.  This is possible, because by default, all traffic is tunneled back to the controller.  That would isolate all secure wireless users on the campus and you would have a single choke point, the layer 3 switch connected to the WLAN controller.  Having a single large VLAN will also save you ip addressing space, because you would have much less slack than having a /24 per floor that not everybody uses.

 

Your wired network would simply be your  two controllers connected to a management VLAN that all of your access points could reach, as well as that single VLAN for clients, trunked to your layer 3 switch.  Upon failover, the access points could just fail to the second controller and your clients could retain their ip addressing, and they would be on that single VLAN, where you expected them.

 

Again, I am generalizing your situation, but there are advantages to leveraging the centralized approach that might simplify things.  Since you are an Aruba customer, even though devices are in the same VLAN, you can apply different firewall policies to them, so that they are given selective access to the network, even if they share the same ip address range.  How much of this you want to take advantage of, is up to you because only you know what your policies are...

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Search Airheads
Showing results for 
Search instead for 
Did you mean: