Aruba Central, Switches, and VLANs

I recently ran into several issues while setting up a new Aruba Central account for a client and onboarding their new APs for the first time. Certain VLAN settings worked a bit differently than I had anticipated on the build/prep network I had created at work. This was to completely duplicate the client’s network for easy installation of the APs. Once shipped and delivered, they would be plug-and-play. However, since I was using an Aruba 2930f 48-port PoE and the client had all Cisco 2960x PoE switches, the VLAN’ing differences caused me a few headaches once they were moved from prep into production. Here’s how I was able to configure Aruba Central with these various VLAN setups.

VLAN Differences Between Aruba Central and Cisco Ports

The client has several locations throughout the US, tied together via MPLS and using several VLANs at each location. The APs were to be set up only on each location’s management VLAN and the only WLAN was a guest network completely segregated from the other networks for security reasons.

Within Aruba Central (AC) there are several areas to input your VLANs for the managed APs. Some are for the Ethernet interface itself and its profile, some are for the AP itself, some for the WLAN networks you create and some for the virtual controller (VC). There are native management VLAN settings, uplink VLAN settings for both the AP and the VC, VLANs that need to be set up for your WLAN needs, etc.

The AP group’s wired profile—which applies to the physical uplink port on the AP and what VLANs/networks it can use—is very Cisco-like and can be set as “Access” or “Trunk.” If set as a trunk, you give it your native VLAN and allowed VLANs just like a Cisco trunk port.

Depending upon how the port on your switch is set up is going to dictate how you populate the various VLAN settings within Aruba Central itself. For instance, in the above scenario I used a trunk port on the Cisco switches for each AP and set it to have a native VLAN as the management VLAN and allowed the management VLAN and the guest network VLAN. The port setup was similar to this example:

#switchport mode trunk

#switchport trunk native VLAN 10

#switchport trunk allowed VLAN 10,20

The default_wired_port_profile for the AP group was then set as follows, which works just fine with the switch port configuration above:

When Management Communication Breaks…

However, in the properties of the AP-505 access point pictured below, if we were to populate its “Uplink Management VLAN” by adding VLAN 10, it will break the AP’s communication with the management VLAN, and we will lose access to its management interface. We would then either need to reset it to factory defaults (after removing the below setting from Aruba Central and leaving the field blank) or temporarily change our switch port settings to regain management access. Either way, populating the APs uplink per below, while our switch port is set as it is in the above statement, breaks its management communication. The below setting tags the port and doesn’t work when the switchport has that VLAN as native. If it were only an allowed VLAN in the switch’s port configuration (tagged and not native) and we were using a different VLAN for management, then the below field could and should be populated with that tagged VLAN.

For me to get my scenario to work, this had to be left blank, which I found out the hard way after several factory resets.

Configuring Aruba Central Virtual Controller

The same scenario applies to the AP group’s virtual controller in Aruba Central. There are two areas to populate its VLANs (if necessary) as shown in the below picture. The first one, the “Virtual Controller VLAN”, can be populated with the switch port’s native VLAN used for management. But once again, if we populate the second area, the “Uplink Switch Native VLAN,” with the same native VLAN we are using for management, it will break the virtual controller’s uplink communication and the APs will not communicate with the VC, which causes reboot loops for all APs not hosting the VC. Since the description states “Native VLAN,” it’s easy to get confused and assume you can populate this with the switch ports native VLAN.

But again, this field tags the uplink traffic, and will break it if you use your switch ports native VLAN in the port’s trunk settings. This one is easier to fix if you configure it wrong. You will not lose the VC or AP management traffic, but considering the AP is still talking to Aruba Central, you can fix this in AC and then reboot the APs and they will then start communicating with the VC again.

One thing to note here. I had about 20 APs to prep overall. Some sites/groups only had one AP while others had multiple APs. I broke the virtual controller’s uplink traffic by populating the “Uplink switch native VLAN” field with my native management VLAN 10. It did not affect the groups with only one AP since nothing else needed to communicate with the VC. But for the groups with multiple APs, all APs constantly rebooted except for the one with the VC on it until I removed the VLAN from that field. If you only have one AP in each group, there will be no VC uplink traffic. Should you make the same mistake I did, you wouldn’t notice until you added more APs to that site.

Multiple VLANs Require Multiple Tests

In conclusion, it’s always best to do plenty of testing in a scenario where you will be using multiple VLANs for various WLAN SSIDs, your management network, and/or your uplink network. If you are configuring for a single, flat network then no need to configure any of this.

Or you may be using a different switch than a Cisco, such as an older HP that has no “trunk” ports per se but rather uses just tagged and untagged for their port settings. I was using an HP 2930f for my setup network and had my ports configured as follows:

vlan 10
name "management"
untagged 1-4
exit

vlan 20
name "guest"
tagged 1-4
exit

Final Thoughts

There was more to each VLAN configuration on the HP, but this was the basic port config. It had the same effect as the Cisco trunk mentioned above yet still operated a bit differently once the APs were installed at the client’s site and connected to a Cisco 2960x trunk port rather than an HP 2930f tagged/untagged port. So, I had to reconfigure some of the Aruba Central VLAN fields, either removing or adding the native VLAN, resetting the AP to factory defaults and rebooting it to pickup the new config from AC.

Be cautious when configuring your Aruba Central group with its various VLAN settings. Don’t trust if it states “Native VLAN” in the description. Test thoroughly before installing into production.

Have any questions about how to configure Aruba Central group with various VLAN setups? Please feel free to reach out to us with questions at any time!