ArubaOS and Controllers

Occasional Contributor II

Best Design Practices

I recently received M3's to upgrade my Sup II environment. While upgrading and playing around with the first M3, I was mulling over whether or not I should change some configuration of how the AP's connect to the controllers and how roles are given.

Currently, I have the controllers serve DHCP for the AP's. The AP's are private addressed and come straight back via VLAN to the Master and then to the controller. I am avoiding the dynamic AP assignment in this manner and I know which buildings are on which controller. I have a backup LMS specified. Am I losing anything in doing this?

Also, my users are assigned to roles per building in order to assign multiple VLANs. So I ended up with Employee-in-Bldg1-Role, Student-in-Bldg1-Role, Employee-in-Bldg2-Role, etc. As stated in a previous thread, my goal was to use one SSID for less confusion but then I had to inadvertently assign my users differently as I just specified. The only problem this creates is many VLANs. But I don't think there is too many as some of the subnets in the residence halls get really, really full.

Any comments? I'm open to suggestions.
Aruba Employee

Re: Best Design Practices

If you place APs in an AP VLAN the APs won’t see ARP entries of rogues being plugged into user vlans. The AP group is what tells the AP to go to which controller so most of the time I have my customers create a different AP group for each build or set of building creating logical groupings of APs. The other reason I like putting APs on any subnet is it is less work when you want to through out an AP quickly. If someone calls and says they have 100 people in an area you don’t have enough APs in you can simply walk out with another one and plug it in. Ding fries are done. If you need it to be in an AP vlan you will need to touch your LAN.

In the past I understood why people would want a subnet to equal a building but now with how Aruba (and others) add location to the AP and user, I don't see the advantage given the added complexity. For example when trouble shooting a client issue now you can ask username, mac address, or ip address to figure out location. This wasn’t possible to track down a user in the old wired world. Now once you have one of those things you can search for the user in Airwave or in the Aruba controller which will give you their location by a map or by what AP group they are in.
Occasional Contributor II

Re: Best Design Practices

The subnetting per building is simply because I could not accomplish roles in any other manner. I cannot create one flat vlan. I have too many users. The only way to VLAN pool is currently by SSID. This would result in students and employees and guests and labs and everything in the same vlan with the firewall policies through the roles for separation. Definitely not the end of the world, but it leaves me wondering about the security implications. I also am bereft of firewall rules that happen outside of Aruba if I vlan pool everything together. My other firewalls do not care about user roles and so my IP-based definitions here would not work. I am left again to wonder about vlan pooling inside a user role instead of using the SSID as a dividing line.

I am not limited in quickly setting up an AP. I have a DNS entry set and an AP in a regular VLAN can find it's way back to a controller with no issues. I plop it in a group and away it goes. The AP VLAN's are to simplify connectivity to and from the controller. Instead of involving L3, it's all L2 to the controller. I do realize that I lose the rogue detection inside of the subnet. But I do not think I want an AP living inside a student user subnet.

Does everyone else simply use multiple SSIDs to vlan pool per role?
Occasional Contributor II

Re: Best Design Practices


We use to place AP in the same subnet on the same VLAN. It's bring security and not L3 traffic to the controllers.

For the ARP of rogue AP, we configure switch port in trunk mode with the vlan AP as pvid. With this AM can see ARP of other AP and detect Rogue.
Frequent Contributor II

Re: Best Design Practices

I'm a little lost on exactly what you're trying to do but here's an idea. Create a virtual AP per building. This allows you to have different VLANs for each group based on the building the AP is in (and by extension, the user).

We have 40+ campuses in our district and each has it's own VLANs for wireless VoIP phones and data devices. We use the same SSIDs on all campuses for data devices. The user can move to any campuses/building because of the same SSID but gets an IP address based on which campus/building they are on.

We have anywhere from 2-9 VLANs for data depending on the campus. Since we have over 3300+ devices on each of 2 high schools, we need 9 VLANs to split up the broadcast domains.

Also, remember that an SSID is not the same as virtual AP. You can create an SSID, WIRELESS, and use it on every campus with different VLANs. Create virtual APs with names such as Bldg1-WIRELESS, Bldg2-WIRELESS, etc but the SSID it uses is always WIRELESS.

Also, I really don't buy into the 'VLAN for security' idea. I'm 100% for security (more than the vast majority) but think about this: exactly how does a student hurt the security of the faculty being on the same subnet? Encryption protects it all the way to the controller. Sniffing traffic on a switched network is not trivial. If it's that important it should be encrypted at the application layer anyway. If you are in a high security need environment then it is appropriate but in education... I don't think so. Just my $.02
Search Airheads
Showing results for 
Search instead for 
Did you mean: