Setting up a Dev environment on Ubuntu 20.04 for Cisco DevNet Associate Courseware

Warning: This post is going to be a little different. If you read the title you may be asking the question, why the heck is an Aruba guy posting about Cisco DevNet?!  That is a very solid question.  I’ve made a personal goal to dive deeper into automation, programmability, and using APIs.  These are all subjects that I’m not very strong on, so I recognized the need to start at the bottom and work my way up through each technology. The Cisco DevNet Associate program appears to be the most structured way of doing that.  I learn best consuming videos, taking notes, reading, and finally doing.  This program appears to offer the materials as well as a roadmap to guide you through the journey.  The end goal is to use the skills I gain through the training program and apply them to Aruba infrastructure.  I’m going to document my journey here in hopes that I can help someone that is on the same path. Another warning: As I said before, I’m a noob with this stuff so please point out any mistakes that you see. I’m humbly going through a journey and will accept any suggestions or corrections along the way. Just be nice….

While I’m waiting for my book I wanted to get a head start and get a VM setup to use as my development environment. I don’t want to take a chance in screwing up my laptop so I figured it would be best to load up a VM.  Another personal goal for 2021 is to improve my Linux skills so I figured I would use Ubuntu as my dev environment to push me further out of my comfort zone.  Don’t laugh too hard if I do something stupid.

OS Setup:

The first step is to create a new Ubuntu 20.04 machine in VMWare Fusion. I’m not going to cover the details on how to do this so use Google.  The first thing you want to do with any new OS install is to get the latest patches.  To do this for Ubuntu, open a terminal window and run the following:

“sudo apt update && sudo apt upgrade”

You will be prompted for your root password as well as confirmation to update software.

Python Installation and Configuration:

Python appears to be one of the key components in the DevNet program.  It should already be installed but to verify type “python3” into a terminal.   This will drop you into the Python Interactive Prompt:

This output also displays the current version of Python running on this machine. To quit the Python Interactive Prompt just type “quit” or Ctrl-D.  You can also validate the version running on your machine using the command “python3 –version”.

In order to create an isolated instance of Python to mess around with packages and modules I setup a Python virtual environment. To use virtual environments, you will have to install venv:

“sudo apt install python3-venv”

To create the virtual environment run the following:

“python3 -m venv <environment-name>”

An example is “python3 -m venv test-env”.  This will create a directory structure in your current working directory with a set of directories for the Python interpreter and libraries that is isolated from the main Python Instance on your machine.

To activate the newly created environment run the following:

“source <environment-name> /bin/activate”

To use my example: “source test-env/bin/activate”

If you take a look at the command prompt you will notice that it changed and shows what virtual environment you are using. This will allow you to install, remove, or upgrade packages inside of this environment without effecting other Python environments.  In other words, this may keep you from screwing something up.

To get out of the virtual environment type “deactivate”.  You will be returned back to your system prompt.

IDE Installation and Configuration:

To write python code we will need some type of IDE.  Atom is an open-source text editor that can be used as an IDE to write or modify Python code. Unfortunately, Atom can’t be installed using apt but it can easily be installed using snap.  Snap bundles up the application and all of its dependents into a single compressed file for easy installation.  Snap should already be installed but if not run “sudo apt install snapd”. To install the Atom snap bundle run:

“sudo snap install atom –classic”

After the installation is complete you can launch Atom using the “atom” command or by opening it in the GUI under applications.

The Cisco DevNet courseware also recommends Microsoft Visual Code.  It can be installed using snap as well: 

“sudo snap install code –classic”

Once the install is complete you can launch Visual Studio Code using the “code” command or by opening it in the GUI under applications.  Visual Studio Code supports a number of languages including Python.  To load the Python extension inside Visual Studio click View -> Extensions and search for Python.  Install Python from Microsoft which should be the top option.

Interfacing with APIs:

Postman is an application that is used to quickly interface with APIs.  It can be installed using snap as well:

“sudo snap install postman”

Once the install is complete you can launch Postman using the “postman” command or by opening it in the GUI under applications.  If you want to test it out, I recommend using the API for  You get to learn about APIs while learning some awesome dad jokes.

You will need to add to the URL line then select Headers, add Accept as a Key and application/json as the value.  Click send and let the fun begin. 

Version Control:

The last tool we need to install for now is Git which is an open-source distributed version control system.  This is one area that I don’t know anything so I’m excited to learn. Git can be installed using apt:

“sudo apt install git”

To verify the version:

“git –version”

I’m sure there are additional tools that I’m not aware of yet but this should allow me to get started with the DevNet coursework. Let me know what I’m missing.

Aruba AirSlice – IAP Configuration and Troubleshooting

In my first post on Aruba AirSlice I provided a quick introduction of what Air Slice is and what it can be used to accomplish.  If you want a quick review check out the link:

Now for the fun stuff, let’s jump into the configuration.  Here is a quick review of what Zoom traffic looks like between a wireless client and the Zoom cloud service. In the Wireshark capture below you can see the Zoom traffic leaving my Surface laptop ( tagged as DSCP class selector 5 which is the highest DSCP value.  The traffic coming from the Zoom cloud service is coming in as Class 0 or Default:

This is expected behavior as the traffic coming down from the cloud doesn’t have any QoS markings. To see this in action you can take a look at how your APs are processing the WMM queues using the IAP command “show ap debug radio-stats | include WMM.”

In this output there are three clients connected to this AP that are participating in a Zoom call with audio and video enabled.  Most of the traffic transmitted from the AP to the clients is hitting the Tx BE (Best Effort) queue due to its DSCP tagging. This is not optimal. If you compare this to the Rx queues you notice that the client is sending traffic up using the Rx VI and VO queues much more frequently. Now let’s allow the IAP DPI engine to identify the Zoom traffic and apply policy automatically to improve how this traffic is processed downlink from the AP to the wireless client.

The first step is to enable AirSlice. This post will walk through the IAP configuration using Central via GUI configuration.  To enable AirSlice browse to your Group -> Devices -> Config and make sure you are showing the Advanced Configuration options.  Next browse to the Services Tab -> AppRF -> and Set Deep Packet Inspection to All, enable Application Monitoring, and enable AirSlice Policy. 

If you are configuring the IAP directly you need to run the following commands at the config# prompt or make the same GUI configurations that I did for Central in the local IAP GUI:

To enable DPI: “dpi”

To enable AirSlice-Policy: “airslice-policy”

To enable Telemetry: “application-monitoring”

If you just want to just prioritize the built-in application list then you are set.  AirSlice also has the ability to prioritize custom applications but I will save that for another day.

Now if we take a look at the WMM buckets we will see the Tx VI bucket being used for certain traffic as opposed to sending almost everything over the BE bucket. Just to be clear, AirSlice is an internal DPI function and does not modify any QoS DSCP markings. It simply takes the AirSlice identified traffic and elevates those flows up to the VI or VO queue based on how it is marked by DPI.

We also need to check to make sure the proper hardware queues are being used.  The command “show ap debug radio-stats <radio #> | include TID” will show which hardware queues are being used to transmit. Remember that Radio 0 is 5GHz and Radio 1 is 2.4 GHz:

If the AP is identifying and tagging AirSlice capable applications properly then you should see an increase in the TID5 “0” queue which is the farthest left queue for TID-5.

There are a few other commands that you need to be aware of when troubleshooting.  The first command is “show app-monitoring list.” This command shows the applications that are supported by AirSlice as well as each application’s DPI and Inner AppIDs. You will need to reference this table when looking at the dpi datapath output:

Next we need to dig into the AP’s datapath. The command “show datapath session dpi” provides key insights on how the traffic is being processed by the DPI engine.  After a flow is identified, supported applications will be tagged with an InnerAppID. If this isn’t happening then AirSlice will not be able to prioritize the traffic flows. Here is a capture of all of the possible flags as well as a sample from a client using zoom:

The key flags are App and InnerAppID.

The most important component of AirSlice is the amount of telemetry that it adds to help monitor and troubleshoot supported applications.  The command “show ap debug airslice client-stats <client-mac> <DPI AppID>” will show you key details of the traffic flow including delay, jitter, and packet loss. Don’t make the same mistake as me and try to use the Inner AppID. You have to use the DPI ID. If you try to use the AppID the output won’t show any data.  For instance, Zoom would be DPI AppID 2928.  Remember to use the command “show app-monitoring list” as reference.

The telemetry data is collected every 10 seconds and sent to Central every 5 minutes. I have noticed a delay in telemetry data showing up initially after enabling AirSlice so just be patient. The data will get there. To view the telemetry data in Central, browse to the client that you would like to look at, Select Applications, and then select the particular application to see details.  AirSlice enabled applications are highlighted with a green star.  This telemetry data is only available at the client level and will not show at the Group or Site level hierarchies. 

In this example I wanted to look at the application telemetry for Zoom.  When you click the + sign beside the application it will expand out to show Usage, Loss, Latency, and Jitter. 

Next time a user complains about a Zoom session you will be able to dig into the details and user experience for that particular user and see if the WiFi was the problem. Hopefully it wasn’t….. Just remember, it’s always DNS.

Reach out if you have any questions: @chadteal or @acmxguy on Twitter.

Aruba Air Slice Introduction

With all of my free time lately (ha) I’ve decided to do a deep dive on some 802.11ax features and enhancements.  Aruba has implemented a software enhancement named Air Slice that takes advantage of a number of 802.11ax features to provide flow classification and prioritization for a predefined set of applications. This allows the APs to prioritize Air Slice applications over non-Air Slice applications downstream towards wireless clients.

The first question we have to ask is why do we need this?  WMM has four access categories: voice, video, best effort, and background.  The struggle with this is that a number of applications either don’t mark their traffic properly or somehow everything is marked to the same access category (typically voice). I think there is a saying that if everyone gets priority, then no one has priority.  This brings back memories of when I was able to travel to customer sites and had to queue up to get on a Delta plane at ATL.  How is half of the plane Sky Priority? Back to Air Slice.  Do we as network professionals trust application developers to mark their traffic properly? Here are a few captures from a Zoom session.  These two clients are connected to the same access point and you can see two different behaviors:

This client is properly tagging traffic as either CS5 or CS7 leaving the device depending on what it is sending.  The return traffic from the Zoom service is not tagged:

This client is not applying tagging on the traffic leaving the device and the return traffic from the Zoom service is not tagged. Same network, same OS, same Zoom version. Hmm….

The result of this behavior is that the traffic leaving the wired network destined for a wireless client will be dropped in the BE category. If you really want to dig in and characterize the traffic on your network take a look at the output of the following commands:

IAP:  “show ap debug radio-stats | include WMM

Controller: “show ap debug radio-stats ap-name <name> radio <radio #> advanced | include WMM”

Here is an example from an IAP in my home lab.  The Tx WMM (BE) queue shows that a large majority of packets are being transmitted from the AP using the BE access category.  The Rx numbers are the reverse and show how the clients are tagging their traffic destined for the wired network:

With the craziness that has been 2020 most of us are working from home sitting on some type of web conferencing or collaboration application all day.  These applications are latency and bandwidth sensitive.  Aruba is taking advantage of some features that we know and love including the Policy Enforcement Firewall and the layer 7 Deep Packet Inspection engine to identify these applications and utilize new 802.11ax features such as Orthogonal Frequency Division Multiple Access (OFDMA) and Target Wake Time (TWT) to optimize available RF resources to meet these real time application requirements. 

Air Slice is supported on both IAP and controller-based deployments using 8.7 software but is restricted to certain access point models. As of 8.7.1 the AP-535 and AP-555 are the two AP models that support this feature.  I can’t comment on futures but hopefully the other 802.11ax AP models will be supported “soon.”  The current list of applications supported today are WiFi-Calling, Zoom, Office 365, Skype for Business, GotoMeeting, Slack, AWS, Dropbox, and Github. There is also support for creating custom application markings for up to 5 custom applications using session ACLs. 

Now for the details.  There are three phases that a packet will pass through as it goes from the wired network to a wireless client.  The first phase is where the packet will hit the DPI and UCC engines which classifies the packet into different application flows.  In controller-based deployments this happens inside the controller. For Instant-based deployments this processing happens on the individual AP that the client is associated. Phase two is handled by the Flow Queue Manager (FQM) which has added four additional queues per access category for additional granularity in traffic marking. Each of these new queues are assigned a different priority which allows applications to be prioritized differently even inside a particular WMM access category. The FQM is also responsible for handling drain control which determines how many packets from each queue will be added to a PLCP Protocol Data Unit. The final phase is where the traffic scheduler will figure out the most efficient way of transmitting the data.  Both ax and legacy clients are supported by Air Slice but are handled differently based on client capabilities. 802.11ax clients will be able to take advantage of OFDMA and TWT scheduling while legacy clients will be handled using single-user transmissions.

This post is getting a little long so I’ll save the configuration for next time. Reach out if you have any questions: @chadteal or @acmxguy on Twitter.

Aruba Central with IAP 8.7.1 – MPSK Local with role assignment

This will be an update to a previous post that I did on MPSK local without using CPPM:

Aruba has added the ability to assign MPSK local keys to specific roles based on the MPSK that is used by a client. One example is a pre-shared key network that has multiple vendors connecting to a single SSID. Using MPSK-Local with roles, each vendor will have a unique pre-shared key to connect to a single SSID while also allowing each vendor to be assigned a specific role based on their unique pre-shared key. Instant 8.7.1 adds the ability to assign roles based on pre-shared key in the MPSK-local policy. Let’s jump into the configuration. In this example I will use Central GUI Configuration but this can be configured via Central Templates or locally on the IAP as well.

Step 1: Select the Central Group that you want to use for this configuration. Select Devices – > Access Points -> Config. Select Show Advanced:

Step 2: Create any new roles that you want to tie to an MPSK local key – Security -> Roles

Step 2a: Name the role – Click OK

Step 2b: Modify the ACL as needed – Make sure you click Save Settings at the bottom of the screen when you are finished editing.

Step 3: Create MPSK Local Profile – Security -> MPSK Local

Step 3a: Name the MPSK Local Profile

Step 3b: Create MPSK Local Key to Role Mappings – Make sure to click ok and Save Settings once you are finished editing.

Step 3c: Create additional MPSK local key to role mappings – You must use unique names and PSKs for each MPSK local entry.

Step 4: Create a WLAN and set Security Key Management = MPSK Local and select the MPSK local profile that you created:

This is what your clients should look like. My iPad is getting role1 based on using the key for role1 and my MBP is getting role2 based on using the key for role2.

Reach out if you have any questions. @chadteal or @acmxguy on Twitter

Airgroup – Centralized Mode Overview


This post is a continuation of my first Airgroup Overview post:

Airgroup Introduction

The first Airgroup mode I want to dive into is Centralized mode as it is the most common and recommended deployment mode when using a Mobility Master architecture.  The only exception to this recommendation is to use Distributed mode when the bandwidth is low between the Mobility Master and Managed Devices.  A single Mobility Master can support a mixture of Managed Devices running in both centralized and distributed mode but an MD can only run in a single operating mode at any given time.

In centralized mode the Mobility Master is responsible for processing all of the Airgroup information that is forwarded up from the Managed Device using OpenFlow. The Mobility Master is the single point to troubleshoot and validate Airgroup in a centralized deployment. You will have to navigate the hierarchy to run the various show commands in the proper context. When Clearpass is used for device registration the Mobility Master makes the RADIUS request for discovery authorization.   As you can see the Mobility Master has a lot of things to handle when dealing with Airgroup so it is important to understand scaling when deploying this feature.  I don’t want to include scaling numbers in this post as they may become stall but make sure you reference the latest Airgroup Deployment Guide or the User Guide for the AOS version that you are running for the latest scaling numbers.  The following command is your friend and should be used to validate the number of mDNS packets that are being received by the Mobility Master:

“show airgroup internal-state statistics”

You will need to look at the Packet Arrival Statistics to determine the resources needed.  Depending on the number of mDNS devices you are trying to support it may be necessary to scale up your hardware resources on your Virtual Mobility Masters.  A great command to use for verification in virtual environments is “show switchinfo” to validate the VM guys are actually giving you the CPU and memory resources that you requested.

Before we dig into configuring centralized mode I want to point out some inconsistencies in configuration depending on the AOS version you are running.  In Pre-8.2 releases there was only the concept of centralized mode.  The reason I want to call this out is depending on when Airgroup was originally setup in your environment it may or may not be optimally configured.  Pre-8.2 configuration did not use the concept of profiles and could only be applied at the /mm hierarchy.  There could still be remnants of this old configuration in your environment. The easiest way to validate is to see if there are any Airgroup Domains configured in your Airgroup Profile or if there is any configuration at the /mm hierarchy. If there are you probably need to clean this up.  Disclaimer:  Make sure you know what you are doing and don’t rely on just this post to clean this up.  I also want to call out the fact that the documentation is not the most clear when it comes to Airgroup configuration.  It’s not as complicated as it seems when you first read through the docs.

I’ll save the actual configuration for the next post. Stay tuned…..








MPSK on Aruba Instant without CPPM

Aruba finally introduced the ability to use multiple Pre-Shared Keys for both controller based and IAP back in AOS 8.4.  This allowed support for device-specific or group specific Pre-Shared keys to be used on a single SSID.  The only caveat in the initial implementation is that Clearpass Policy Manager 6.8 is required to handle the device registration and enforcement for MPSK.  Keep in mind that the purpose of this feature is to provide a secure workflow to connect headless/IOT devices to the wireless network.  It isn’t designed to replace 802.1X for devices that are capable. If you want to argue this hit me up on twitter…

Fast forward to today and Aruba has added the ability to have local MPSK on Instant APs locally.  The first question is why did Aruba choose to implement the local MPSK feature? I’m not a PLM so I have no idea but my first guess would be because a customer asked.  I personally like the granularity in profile creation and enforcement in Clearpass but I can see the need for a simplified workflow.  Now let’s dig into the details.

Let’s start with the caveats.  There are a few limitations in using MPSK local.  The first is that this only works on IAP. The second limitation on local mode is that it is limited to 24 PSKs per SSID.  If you need more than this you probably need CPPM anyway.  The third limitation is that it currently only works with WPA2.

Now that we know the limitations let’s dig into how this actually works.  In a traditional WPA2-PSK network a device will perform its initial association to a WLAN and then start the 4-way handshake process.  After the client device derives the PTK it will send the second message which is protected by a MIC.  If the client and AP hash match then the process will continue and eventually result in a successful 4-way handshake.   If the hash does not match then the 4-way handshake will fail. You can see this in the auth-trace-buf on the AP:

IAP-515# show ap debug auth-trace-buf

Auth Trace Buffer



Jun 24 10:18:37  station-up             *  34:42:62:53:c4:ef  9c:8c:d8:12:60:b1  –  –    wpa2 psk aes

Jun 24 10:18:37  wpa2-key1             <-  34:42:62:53:c4:ef  9c:8c:d8:12:60:b1  –  117

Jun 24 10:18:37  wpa2-key2             ->  34:42:62:53:c4:ef  9c:8c:d8:12:60:b1  –  117  mic failure


If you see a client failing on wpa2-key2 it is more than likely an invalid PSK entered on the client device.

To support multiple PSKs on a single SSID the AP will expand the 4-way handshake to allow the MIC to be checked against all of the passphrases in the MPSK-profile pool for a particular SSID.  If the calculated MIC matches one in the pool it will continue the keying process and will be allowed onto the network.

Hopefully that explains the backend process. Now we can dig into the actual configuration.  Local-MPSK is not an option offered in the WLAN setup wizard.  You will need to use the CLI.

The first step is to create a MPSK-local profile.

 “wlan mpsk-local <profile name”


IAP-515 (config) # wlan mpsk-local MPSK-profile


Next you need to add the PSK passphrases to the profile (up to 24 unique passphrases):

“mpsk-local-passphrase <key-name> <passphrase>”


IAP-515 (MPSK-local “MPSK-profile”) # mpsk-local-passphrase vendor1 aruba123


Once the MPSK profile is created you can create your WLAN:

“wlan ssid-profile <SSID_name>”


Then set the opmode to mpsk-local:

“opmode mpsk-local”


Next you will assign the MPSK profile to the SSID:

“mpsk-local <mpsk_profile_name>”


The final step is to apply a default role for the SSID that you are creating and allow some type of access.  Remember that by default roles are set to deny all traffic. Speaking from experience I had the deny all profile in my test bed and couldn’t figure out why my client couldn’t get an IP. We are all idiots occasionally.

“wlan access-rule <role_name>

“rule any any match any any any permit”


Here is an example of my configuration:

IAP-515 (MPSK-local “MPSK-profile”) # mpsk-local-passphrase vendor1 aruba123

IAP-515 (MPSK-local “MPSK-profile”) # exit

IAP-515 (config) # wlan ssid-profile mpsk-local

IAP-515 (SSID Profile “mpsk-local”) # opmode mpsk-local

IAP-515 (SSID Profile “mpsk-local”) # mpsk-local MPSK-profile

IAP-515 (SSID Profile “mpsk-local”) #exit

IAP-515 (config) # wlan access-rule mpsk-local

IAP-515 (Access Rule “mpsk-local”) # rule any any match any any any permit

IAP-515 (Access Rule “mpsk-local”) #


Don’t forget to commit your changes using “commit apply”


Once you get a device to associate you can validate that it is using a PSK from the MPSK-profile by looking at the AP auth-trace-buf:

IAP-515# show ap debug auth-trace-buf

Auth Trace Buffer


Jun 24 11:06:34  station-up             *  34:42:62:53:c4:ef  9c:8c:d8:12:60:b0  –  –    wpa2 psk aes

Jun 24 11:06:34  wpa2-key1             <-  34:42:62:53:c4:ef  9c:8c:d8:12:60:b0  –  117

Jun 24 11:06:34  wpa2-key1             <-  34:42:62:53:c4:ef  9c:8c:d8:12:60:b0  –  117

Jun 24 11:06:35  wpa2-key2             ->  34:42:62:53:c4:ef  9c:8c:d8:12:60:b0  –  117  pass:vendor1

Jun 24 11:06:35  wpa2-key3             <-  34:42:62:53:c4:ef  9c:8c:d8:12:60:b0  –  151

Jun 24 11:06:35  wpa2-key4             ->  34:42:62:53:c4:ef  9c:8c:d8:12:60:b0  –  95


The debug output will display the name of the PSK being used by a particular MAC address. In my example the PSK key is vendor1


I hope this helps someone.  Reach out if you have any questions: @acmxguy on Twitter.

Aruba Instant – AP boot image upgrade


I had a co-worker brick an IAP  (I’ve also done this a few times) and asked if there was a way to recover from a corrupted AP image.  Since the IAP will not fully boot we needed a way to replace the corrupted image via the AP boot menu options.  These commands aren’t well documented so I figured I would post this to hopefully help out others that face the same issue.

The first step is to reboot the AP and break the boot cycle.  You will need to press any key when prompted:

APBoot (build 55373)
Built: 2016-06-09 at 11:36:40

Model: AP-32x
DRAM: 491 MB
SF: Detected MX25U3235F with page size 64 kB, total 4 MB
Flash: 4 MB
NAND: 132 MiB
PCIE0: link up
PCIE1: link up
dev fn venID devID class rev MBAR0 MBAR1 MBAR2 MBAR3
00 00 168c 0040 00002 00 00000004 00000000 00000000 00000000
dev fn venID devID class rev MBAR0 MBAR1 MBAR2 MBAR3
00 00 168c 0040 00002 00 00000004 00000000 00000000 00000000
Power: 802.3af POE
In: serial
Out: serial
Err: serial
Net: eth0, eth1
Radio: qca9990#0, qca9990#1
Reset: warm
FIPS: passed

Hit <Enter> to stop autoboot: 0

There are a number of options in the apboot menu:

apboot> ?

?              – alias for ‘help’

boot           – boot the OS image

clear          – clear the OS image or other information

dhcp           – invoke DHCP client to obtain IP/boot params

factory_reset  – reset to factory defaults

help           – print online help

mfginfo        – show manufacturing info

osinfo         – show the OS image version(s)

ping           – send ICMP ECHO_REQUEST to network host

printenv       – print environment variables

purgeenv       – restore default environment variables

reset          – Perform RESET of the CPU

saveenv        – save environment variables to persistent storage

setenv         – set environment variables

tftpboot       – boot image via network using TFTP protocol

upgrade        – upgrade the APBoot or OS image

version        – display version


In this post I’m going to concentrate on the OS related commands.  The first thing we did was clear the corrupt os using the “clear os” command:


apboot> clear os

512 bytes written to volume aos0

Next we validated that partition0 is clear using the “osinfo” command:

apboot> osinfo

Partition 0 does not contain a valid OS image

Partition 1 does not contain a valid OS image


The next step is to get network connectivity. If the network has DHCP available simply type the “dhcp” command:

apboot> dhcp

eth0: link up, speed 1 Gb/s, full duplex

DHCP broadcast 1

DHCP IP address:

DHCP subnet mask:

DHCP def gateway:

DHCP DNS server:

DHCP DNS domain:


If DHCP is not available you will need to assign a static IP.  Here is a sample of that configuration:

apboot> setenv ipaddr
apboot> setenv netmask
apboot> setenv gatewayip

Now that we are on the network we need to provide the address of the TFTP server.  This is accomplished using the “serverip” command:

apboot> setenv serverip <TFTP server IP>

Ensure that a valid IAP image is in the TFTP directory of your server.  Make sure you use the correct image for the AP model that you are trying to upgrade.  In my example I’m upgrading an IAP-325.

Upgrade the OS using the “upgrade os” command:

apboot> upgrade os ArubaInstant_Hercules_8.3.0.6_69128

eth0: link up, speed 1 Gb/s, full duplex

Using eth0 device

TFTP from server; our IP address is; sending through gateway

Filename ‘ArubaInstant_Hercules_8.3.0.6_69128’.

Load address: 0x44000000

Loading: #################################################################





Bytes transferred = 15293120 (e95ac0 hex)

Image is signed; verifying checksum… passed

Signer Cert OK

Policy Cert OK

RSA signature verified.

15293120 bytes written to volume aos0

Verifying flash…

Upgrade successful.


Validate the image using the “osinfo” command:

apboot> osinfo

Partition 0:

image type: 0

machine type: 40

size: 15293120


build string: ArubaOS version for Hercules (p4build@pr-hpn-build07) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #69128 SMP Thu Feb 14 08:35:24 UTC 2019

flags: Instant preserve

oem: aruba


Image is signed; verifying checksum… passed

Signer Cert OK

Policy Cert OK

RSA signature verified.

Validate the IAP boot partition is set to the correct partition using “printenv” command.  Look for the os_partition variable:

apboot> printenv


If the partition is not correct, set the os_partition using the “set_env” command:

apboot> setenv os_partition 0


Make sure you save your settings:

apboot> save


Now your IAP is ready to be reloaded using the “reset” command or just power cycle the AP. The IAP should boot with the newly upgraded image.


Hope this helps.

Viewing Aruba AP Environment Variables Remotely

If you are working with AOS 8 and want to be able to troubleshoot AP radio or connectivity issues remotely I highly recommend enabling telnet to your access points in the AP System Profile.  While I admit enabling telnet sounds like we are working in the early 2000s, the reward is worth the risk. If I get dispatched to come work on your network I would much rather enable telnet than hang off a ladder while connected to a 1 foot long Serial over USB cable….. don’t get me started on the console cables. 🙂

To enable telnet you just need to set a console password and check the telnet button under the Advanced Options in the AP System Profile that is used by your AP group. Please practice good password hygiene and don’t use your domain admin account password. Remember, this is telnet….


If you prefer CLI:

ap system-profile “Lab_AP_System_Profile”
ap-console-password <enter_password_here>

Now that you have access to your AP remotely you can telnet to the IP.  If you don’t know the AP’s IP Address just check the AP database.  Once connected you will be prompted for a password.  Enter the password that you set in the AP System Profile.  To gain full access to the CLI you will need to enter: Esc+Ctrl+K.  There is no help commands so you will need to know what you are trying to look for. To gain access to the current environment settings on an AP enter the command “reflash -j”  Don’t worry, this command sounds terrifying but only prints the output of the current environment variables of the AP:

~ # reflash -j
bootargs=console=ttyS0,9600n8 rdinit=/sbin/init ubi.mtd=pdata ubi.mtd=aos
bootcmd=boot ap
~ #

I find the ability to gain access to the console of the APs has helped me when monkeying with cluster profiles.  Its much easier to reboot an AP directly from telnet verses having to track down switch ports and cycling power if an AP gets stuck.

I hope this helps someone out.






Airgroup Introduction

A few weeks ago I polled some friends to see which Aruba topics would be of interest for me to write up for blog posts.  I was not surprised to see that Airgroup was the subject that was requested the most.  I have a love/hate relationship with this feature so I’ll use this as an opportunity to dig deeper into the technology and hopefully help some others out on their journey.  This will be a multi-part post as it contains too much detail for a single post.

To get this started we need to define what Airgroup is and why we need it.  The official description of Airgroup is that it is an enterprise class gateway for Zero-Configuration-Networking for Bonjour (AirPlay, etc) Digital Living Network Alliance (DLNA), and Simple Service Discovery Protocol (SSDP). I laugh when I read that description as it basically means that the service is trying to rig up applications designed for home networks to work in an enterprise network. That is part of the reason the feature gets beat up all the time but I’ll will discuss that later.

To provide some background on the underlying technology we need to dig into the history of Zero Configuration Networking (Zeroconf). Zeroconf is not a new technology.  The working group was established all the way back in 1999. The most popular zeroconf technology is Apple’s implementation known as Bonjour.  The primary goal of zeroconf was to provide simple connectivity services for applications that are not dependent on networking technologies like DHCP or DNS.  Zeroconf is made up of services and service discovery.  mDNS (Multicast DNS) is one of the zeroconf services used to resolve hostnames to IP addresses without using name servers. To resolve the hostname a client will send an IP multicast query asking for the host to identify itself and its services offered.  The device will send a multicast response with its services and IP address.  This works great in small environments such as a home network but does not scale in enterprise networks.

If you want to take a look at mDNS queries or responses on your network take an air capture and apply a display filter of “udp.port==5353”.  I’ll dig into the details of the discovery process  and resource records in a later post. Here is a sample of a query response on my lab network.


Airgroup attempts to allow certain zeroconf services to be used across L3 network boundaries while also providing the ability to only give access to services that the client device has rights to use.  For this to work in an Aruba controller environment all of the mDNS/SSDP packets need to terminate on the MDs (managed devices/controller) or access points.  This means that the MDs need access to all of the client VLANs where the zeroconf devices are used. We will dig into this later as well. The MD will act as a unicast querier and responder on behalf of the clients which will allow the services to work across multiple networks.

The most common use cases in Airgroup are the ability to share zeroconf devices between VLANs, user-role sharing, location based sharing, and device registration work flows. The basic VLAN and user-role use cases can be implemented with just Aruba AOS devices (controller based or IAP) while device registration workflows require Clearpass Policy manager.

To complete the Airgroup introduction I’ll mention that there are four different deployment methods:  IAP based, MD distributed mode, MD centralized mode, and MD centralized mode with islands. These methods work in a few different ways depending on how the infrastructure is deployed (Mobility Master managed, Master Controller Mode, or Standalone).  I’ll dig into each of the different methods in my next post.

Don’t worry…. the details and best practices are coming soon.

Aruba AP-555 Tri-Radio Mode

The Aruba AP-555 is the flagship 802.11ax access point.  It offers a new feature for Aruba known as Tri-Radio support.  This means that the radio architecture supports the standard 8*8:8 SS 5GHz radio + 4*4:4SS 2.4 GHz radio while also offering the option to split the 5 GHz radio into dual 4*4:4 SS 5GHz radios without degrading performance.  The 2.4 GHz radio will be available in both deployment scenarios. By default the AP-555 operates in dual radio mode which means that the 5GHz radio is configured for 8*8:8 SS.

To provide for proper filtering and channel isolation in Split 5Ghz Mode Radio 0 will operate only on channels 36 to 64.  Radio 2 will operate only on channels 100 to 165. This is similar to the AP-345 Dual 5GHz deployment.

There are three modes that are available for Tri-Radio.  One mode allows both 5GHz radios to provide wireless access for clients.  The second mode allows one radio to provide wireless access while the second radio acts as an AirMontior or SpectrumMonitor. The third mode allows both radios to act as AirMonitors or SpectrumMonitors.

One key concern with the AP-555 is the need for a lot of power.  Worst case the AP can draw up to 38.2W.  To operate without restrictions the AP-555 needs 802.3bt power or two 802.3at power connections.  The AP will run with restrictions on a single 802.3at connection but Tri-mode is not a supported option when running on lower power.

Now let’s get to the fun part which his actually configuring the AP:

I currently have the AP-555 plugged into an Aruba 3810M-40G-8SR-PoE+-1-slot Switch using a single SmartRate uplink.  To validate the current status of the AP run “show ap debug system-status ap-name <ap-name>”

Check the Power Status:

Power Status

Power Supply                : POE-AT

LLDP Power                  : Successfully negotiated at 25.1W

Current Operational State   : 1 ETH port disabled; USB power disabled; 5GHz radio: 4×4 (Overridden by LLDP)

Eth0 HW POE status          : POE AF, LLDP power: 25.1W

Eth1 HW POE status          : NONE, LLDP power: 0.0W

POE Mode                    : Shared

With 803.3at power the 5 GHz radio will only support 4×4.  Since I don’t have an 802.3bt capable switch I will use a second uplink only for additional power.  To support the second uplink I need to configure LACP on the switch.

ArubaOS Switch:

trunk <port1>-<port2> trk<#> lacp

example:  trunk 1/4-1/5 trk1 lacp

If you are using a Mobility Master with multiple L2 connected Managed Devices you do not need to configure the Access Points for LACP. It will be handled automatically.  I’ll work on a post later outlining the LACP implementation with clustering.

Now with two uplinks if I check the Power Status I should not have any restrictions:

show ap debug system-status ap-name <ap-name>

Power Status

Power Supply                : POE-BT

LLDP Power                  : Successfully negotiated at 39.2W

Current Operational State   : No restrictions (Overridden by LLDP)

Eth0 HW POE status          : POE AF, LLDP power: 25.5W

Eth1 HW POE status          : POE AF, LLDP power: 25.5W

POE Mode                    : Shared

Current Radio Status with a Tri-Mode Disabled (default)

“show ap active”

Role             Radio 0 Band Ch/EIRP/MaxEIRP/Clients


AP-555 - split 5G disabled.png

Notice Radio 2 has no configuration.

In AOS 8.6 there is a new configuration option to enable Tri-Radio support in the AP System Profile. I have an AP group specifically for my 555 so I will enable Tri-Radio for that AP System Profile:

Split-5G Option

Note:  In some of the documentation it states that enabling Split-5GHz  Mode will reboot the AP. I did not experience this in my testing.

Once Split-5GHz mode is enabled the 5GHz radio is broken into two 4×4:4 radios.  A new flag (t) was introduced in the show ap active table to quick identify APs that have Tri-Mode enabled.

Tri Mode Flag.png

Now the AP shows all three radios enabled and servicing clients:

show ap active:

AP-555 - split 5G enabled.png

I’m currently working on follow up posts to outline the effects of Tri-Radio on Mesh, AirMatch, and SSID use on particular APs.  They will be posted shortly.