AP-303H using Spanning Tree and Loop Protect

The Aruba hospitality line of access points are great for both hotel and dorm installations.  They provide RF close to their clients as well as offer wired ports for devices that need to be plugged in.  One of the common problems with this deployment is that end users loop up the network by either plugging in a small hub with two ports uplinked to the AP or just plugging two of the AP ports into each other.  In the later versions of AOS 8 Aruba has added the ability to configure loop protect which will mitigate this issue.  Here are the profiles that need to be created and modified:

AP System Profile:

Spanning Tree needs to be enabled on the AP System Profile.



AP Wired Port Profile:

There are a few nerd knobs inside the AP wired port profile that need to be enabled: Spanning Tree, Portfast, and Loop Protect Enable. If you are plugging in game consoles make sure you enable Portfast or they will stop trying the DHCP process before the port transitions to STP forwarding.  Storm Control Broadcast is another knob that enables the AP to shut down an ethernet port when a loop is detected. I haven’t enabled this knob in production yet so I didn’t enable it in this scenario.



Wired AP Profile:

The Wired AP profile controls what the end user experience will be when a device is plugged into one of the AP ethernet ports.  In my scenario I have the ports configured as trusted (no authentication) and Access VLAN 111 (untagged).



That is all of the configuration required.  The rest of this post will be validation that the system is configured and working as expected.

When troubleshooting I usually work in the CLI.  When working with AOS 8 and clustering, the first step when troubleshooting AP issues is to determine which controller in the cluster is the AP Anchor Controller for the AP that you are working with.  The easiest way to get that is by running “show ap radio-database” from the Mobility Master:


The output gives you a list of all of the active APs in the system as well as Group, type, and Switch IP (AP Anchor Controller).

In this example I’m using AP-303H-1 as my test AP. In the output for that AP it shows the switch IP address is  If you don’t know which controller that is “show switches debug” will provide a list of all of the controllers managed by this Mobility Master:


The anchor controller for AP-303H-1 is 7008_03.  An easy way to gain access to the console of that controller is to use the “mdconnect” command from the node path of that controller.  Here is an example:


A quick way to verify that you are on the console of the correct MD is to issue the “show ap active” command and verify that your AP is in the list:


To verify your AP group configuration use the “show ap group” command:


This output will show the profiles that are associated to the AP group.  Next we need to validate our configuration settings for the system profile, Wired AP profile, and AP Port Profiles:

“show ap system-profile”show_ap_system_profile

output continued:


“show ap wired-port-profile”


“show ap wired-ap-profile”


The two debug commands used to troubleshot the interface status are “show ap debug spanning-tree ap-name” and “show ap debug port status ap-name”. 


Here are examples of these commands with nothing plugged into eth1 or eth2:

(7008_03) [MDC] #show ap debug spanning-tree ap-name AP-303H-1


(7008_03) [MDC] #show ap debug port status ap-name AP-303H-1


The next step is to plug in a single laptop into eth1.

Here is the output of these commands with a single device plugged into eth1:

(7008_03) [MDC] #show ap debug spanning-tree ap-name AP-303H-1


(7008_03) [MDC] #show ap debug port status ap-name AP-303H-1


As you can see in the output, port 1 is in Forwarding mode.

Finally, let’s try to blow things up by plugging in a cable directly between eth1 and eth2 causing a loop.

Here is the output when we plug eth1 directly into eth2:

(7008_03) [MDC] #show ap debug spanning-tree ap-name AP-303H-1


(7008_03) [MDC] #show ap debug port status ap-name AP-303H-1


Ports 1 and 2 are STP disabled once the loop is detected.  The Loop-Protect flag is triggered on eth2.

To see the AP debug output issue “show ap debug log ap-name” command:



To clear the loop protect status on a port issue the “clear ap port” command:


I hope this post will help prevent users from looping up your network!


Clearpass Certificate Download to AOS-Switch



I learned this week that the FQDN of the Clearpass server should be used in the RADIUS Server configuration options.  I have updated this post to include that change.

Downloadable user roles are a great feature on Aruba controllers, switches, and even IAPs.  They allow Clearpass to be the true policy definition point for both the Aruba wired and wireless networks and allows the policy to be modified in a single location. The hardest part of the configuration was uploading the Clearpass certificate to each switch. The latest code release (16.08) eliminates this pain point.  The switch can now automatically download the certificate from Clearpass by modifying a single line of configuration.   Here is a breakdown of the process.

My lab switch already contained the needed certs so the first step to test the new feature was to delete all of the existing CA certs.  This can be accomplished using the “crypto pki zeroize” command.


Next I decided to default my switch configuration to make sure I was starting the configuration from scratch.


Once the switch rebooted I validated that the switch no longer had the certificate from my lab Clearpass server:


Basic switch configuration commands were added to ensure time is synchronized to make sure my certificates will be valid and also make any troubleshooting easier:

hostname <hostname>

ntp server <server ip>

time daylight-time-rule continental-us-and-canada

time timezone -240

password manager user-name <username> plaintext <password

The switch will need to be configured with a Clearpass user account to gain access to the certs and downloadable user roles.  I used a read-only account in my lab:


The final configuration step is to add the Clearpass server as a RADIUS server on the switch:

radius-server host <CPPM FQDN> clearpass

radius-server cppm identity <CPPM user> key <password>

radius-server host <CPPM FQDN> key <shared secret>

radius-server host <CPPM FQDN> dyn-authorization

radius-server host <CPPM FQDN> time-window plus-or-minus-time-window

radius-server host <CPPM FQDN> time-window 30

This configuration should look very familiar compared to previous code versions.  The only configuration that has changed is that I added “clearpass” to the end of the first command to indicate that this RADIUS server will be a Clearpass server. That is the command that triggers the auto-certificate download.

Here is my test switch configuration:

Once the RADIUS server configuration has been added you can check the switch security logs to see if the switch has checked in with the Clearpass server and received the server certificate.  I enabled security logging using the “debug security” command.  Here is the output of show log -r

To validate which certificates have been downloaded use the “show crypto pki ta-profile” command:


My lab Clearpass server is using a certificate from Comodo.

As you can see this process is much simpler than having to manually upload the certificate to every switch.  This process will also help eliminate extra steps when trying to utilize zero touch provisioning to roll out your switch infrastructure.

Upgrade Code on a HPE Provision Switch

I’m currently having to dig into the HPE Provision line of switches.  Here are a few notes to document the process of upgrading the code on a HPE 2920.


Step 1 – Validate current code version using show version command:


Step 2 – Copy new code to flash using copy tftp flash command:


Once the file transfer is complete the system will validate the new code:


Step 3 – Verify the system is configured to boot of the partition with the new code installed using the show flash command:


Step 4 – Reboot the switch using the reboot command (make sure to save changes if needed)

Clearpass – Ports needed between CPPM and Active Directory

UDP 88 – Kerberos Auth

TCP 464 – Kerberos Password

UDP/TCP 135 – Domain Controller



UDP 53 – DNS

TCP 3268 – Global Catalog

TCP/UDP 3269 – Global Catalog over SSL

Clearpass – Ports Needed between Two CPPM servers

TCP 5432 – Database Replication


UDP 123 – NTP

TCP 80 – Change Status

Clearpass – Ports Needed between Client and CPPM server



TCP 6658 – OnGuard Agent

UDP 1812/1813 – RADIUS



UDP 161/162 – SNMP

UDP 5999 AirGroup RADIUS CoA

Where is the SSID that I just configured?

I was playing in my lab today and ran into an issue where my Aruba access point would not advertise my newly created SSID on my local controller. I started digging around and first noticed my AP was up but  was flagged inactive:


Next I checked to see if that access point was advertising a bss:


The next step was to check and see if I had any profile errors:


And there is the problem.  I configured my VLAN on my master controllers but forgot about the locals.  As soon as I added VLAN 100 to my local I could see  and connect to my SSID:


The point of this story is to not get in a hurry when configuring your controllers and make sure your networking config is solid on your local controllers.