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...