The previous six parts built an Aruba network from the management layer down to the user role. This final part covers what happens in the air — how Aruba chooses channels and power, how it steers clients, how to protect the RF environment — and then gives a structured troubleshooting method with the commands that solve most problems. It ends with a look at how AOS 10 rearranges the same concepts.
Aruba Wireless series — seven posts from architecture to troubleshooting.
- Part 1: Architecture, Product Families and Operating Systems
- Part 2: Mobility Conductor, Mobility Controllers and the Configuration Hierarchy
- Part 3: Access Points — Boot, Discovery, Provisioning and Forwarding Modes
- Part 4: Building WLANs with Profiles — 802.1X, PSK, WPA3 and Guest SSIDs
- Part 5: User Roles, the Policy Enforcement Firewall, AAA and ClearPass
- Part 6: Controller Clustering, Redundancy, Roaming and Live Upgrade
- Part 7: RF Management (ARM, AirMatch, ClientMatch) and Troubleshooting (this post)
From ARM to AirMatch
Adaptive Radio Management (ARM) was Aruba’s original radio resource management. Each AP periodically scans off-channel, measures noise, interference and neighbouring APs, and picks its own channel and transmit power. ARM is distributed, which makes it robust and simple — it is still what Instant APs use — but each AP only sees its own neighbourhood. One AP’s change can trigger its neighbours to change, and the network can settle into a plan that is locally reasonable but globally poor.
AirMatch, introduced with AOS 8, moves the decision to the Mobility Conductor. APs keep scanning and report what they hear to their controllers, which forward it to the Conductor. AirMatch then solves channel, channel width and EIRP for every radio at once, treating the network as a single optimization problem.
- Scheduled optimization — a full new plan is computed from the previous 24 hours of data and deployed once a day, by default in the early morning, so channel changes do not disrupt users during the working day. A new plan is only deployed if it is meaningfully better than the current one.
- Event-driven changes — some events cannot wait until tomorrow: radar on a DFS channel (the AP must leave immediately by regulation), severe interference or noise. These trigger an immediate local change for the affected radio.
- Channel width — AirMatch picks per-radio channel width within the limits allowed by the radio profile and regulatory domain, narrowing channels where the density of APs requires it.
- Power — EIRP is chosen within the minimum and maximum set in the radio profile, aiming for even coverage and similar power between neighbouring APs (which also improves roaming).
In AOS 8 the ARM profile still exists and controls scanning behaviour, but channel and power assignments belong to AirMatch. The current solution, the improvement the last run achieved, and the history of channel changes are visible in the Conductor’s RF dashboard; on each controller, show ap active and show ap radio-summary show the channel and EIRP each radio is using right now.
Radio Profiles
Radio profiles set the limits AirMatch works within, per band, per AP group:
rf dot11a-radio-profile HQ-5G
eirp-min 12
eirp-max 18
spectrum-monitoring ! hybrid AP: analyse spectrum while serving clients
!
rf dot11g-radio-profile HQ-2G
eirp-min 6
eirp-max 12
!
ap-group HQ-Building1
dot11a-radio-profile HQ-5G
dot11g-radio-profile HQ-2GThe 2.4 GHz maximum is usually set several dB below the 5 GHz maximum. This keeps 2.4 GHz cells smaller than 5 GHz cells, so dual-band clients see a stronger 5 GHz signal and prefer it.
Regulatory Domain Profile
The regulatory domain profile sets the country (which determines legal channels and power) and the subset of channels AirMatch may use:
ap regulatory-domain-profile HQ-REG
country-code US
valid-11g-channel 1
valid-11g-channel 6
valid-11g-channel 11
valid-11a-channel 36
valid-11a-channel 40
valid-11a-channel 44
valid-11a-channel 48
valid-11a-channel 149
valid-11a-channel 153
valid-11a-channel 157
valid-11a-channel 161
valid-11a-40mhz-channel-pair 36-40
valid-11a-40mhz-channel-pair 44-48
valid-11a-40mhz-channel-pair 149-153
valid-11a-40mhz-channel-pair 157-161
!
ap-group HQ-Building1
regulatory-domain-profile HQ-REGChannel Planning Choices
| Decision | Guidance |
|---|---|
| 2.4 GHz channels | Only 1, 6 and 11 (in the US), 20 MHz only. In dense deployments, disable 2.4 GHz on some APs to reduce co-channel interference. |
| 5 GHz width | 20 MHz for very dense spaces (auditoriums, stadiums), 40 MHz for typical enterprise, 80 MHz only where AP density is low and the channel count allows it. |
| DFS channels | Using them roughly doubles the 5 GHz channels available. Exclude them only where radar is frequent (near airports, weather radar, harbours) or where clients do not support them. |
| 6 GHz | Plenty of spectrum: 80 MHz is typical and 160 MHz realistic. WPA3 or Enhanced Open only (Part 4). |
| Basic rates | Raise the minimum (Part 4); it shrinks the cell and reduces beacon airtime more than any other single setting. |
No RRM algorithm fixes bad AP placement. AirMatch works best on a network designed from a predictive or on-site survey for the coverage and capacity required, with APs mounted where the survey put them.
ClientMatch
Clients, not APs, decide when to roam, and many make poor decisions: a laptop stays associated to the AP where it connected in the morning even after it moves to the other end of the building (a sticky client), or a dual-band phone uses 2.4 GHz because it heard that band first. ClientMatch corrects this using measurements rather than guesses.
Every AP that hears a client’s probe requests reports the client’s signal strength. These reports are combined into a virtual beacon report — a per-client view of how well every nearby AP hears that client. In AOS 8 this view is built centrally on the Conductor, so ClientMatch can compare APs attached to different controllers. When the report shows a clearly better option, ClientMatch steers the client:
- Sticky clients — the client’s signal at its current AP has fallen below a threshold and another AP hears it better by a margin.
- Band steering — a dual-band (or tri-band) client on 2.4 GHz that would be well served on 5 GHz or 6 GHz.
- Load balancing — a radio is heavily loaded and a neighbouring radio could serve some of its clients nearly as well.
- MU-MIMO steering — grouping MU-MIMO-capable clients on radios where they can be served together.
The preferred mechanism is an 802.11v BSS Transition Management request, which asks the client to move. Clients that do not support 802.11v are deauthenticated and briefly refused by the old AP, so that they reassociate to the target. Steering is rate-limited per client to avoid ping-ponging. ClientMatch is enabled by default; when a specific device type behaves badly when steered (some medical and industrial devices do), it can be excluded rather than disabling ClientMatch for everyone.
Spectrum Analysis
Wi-Fi radios hear Wi-Fi; they do not identify the non-Wi-Fi sources that often cause the worst problems. Aruba’s spectrum analysis uses the AP radio as a spectrum analyzer and classifies interferers: microwave ovens, Bluetooth, cordless phones, video bridges, wireless cameras, jammers. It can run on a dedicated Spectrum Monitor AP, on a hybrid AP that keeps serving clients, or on the dedicated scanning radio of newer APs. The spectrum dashboard shows real-time FFT, swept spectrogram, duty cycle and the list of classified devices — the evidence needed to find the microwave oven in the break room that wipes out channel 11 every lunchtime.
Wireless Intrusion Detection and Prevention (RFProtect)
With the RFProtect licence, APs and air monitors continuously classify every AP and client they hear:
| Classification | Meaning |
|---|---|
| Valid | One of the network’s own APs (or explicitly marked valid) |
| Interfering / neighbour | Someone else’s AP, not connected to the corporate network — the normal case in any office building |
| Suspected rogue | Some evidence of a connection to the corporate wired network |
| Rogue | An unauthorized AP confirmed to be on the corporate wired network — a backdoor |
Rogue detection works by correlating the wireless MAC addresses an AP is heard with against MAC addresses seen on the wired side (for example, by APs listening to their wired segment). IDS profiles also detect attacks such as deauthentication floods, impersonation (a fake AP broadcasting the corporate SSID), and misconfigured clients.
Containment — attacking a rogue AP over the air with deauthentication frames so clients cannot use it — is possible, but it must be used carefully: containing a neighbour’s legitimate AP is illegal in many jurisdictions, and regulators have fined organizations for blocking personal hotspots. Most policies contain only confirmed rogues connected to the corporate network, and prefer wired containment (shutting the switch port) where possible.
(HQ-MC1) #show wms rogue-ap-list
(HQ-MC1) #show ap monitor ap-list ap-name HQ-B1-F2-AP07 ! every AP this AP hears, with classificationA Layered Troubleshooting Method
Users report every problem as “the Wi-Fi is broken”. Most of those problems are not RF problems at all, and the fastest way to find out is to go layer by layer, confirming each before moving up:
Before any of the layers, gather three facts: who (username or MAC address), where (building, floor, room, AP name if known) and when (a time to correlate with logs). A MAC address and a time make every command below useful.
Layer 1 — RF
(HQ-MC1) #show ap active ! APs up, channel and EIRP per radio, client counts
(HQ-MC1) #show ap radio-summary ! utilisation and noise per radio
(HQ-MC1) #show ap debug radio-stats ap-name HQ-B1-F2-AP07 radio 1 ! retries, channel busy, noise floor
(HQ-MC1) #show ap debug client-table ap-name HQ-B1-F2-AP07 ! per-client signal, data rate, retries
(HQ-MC1) #show ap bss-table ap-name HQ-B1-F2-AP07 ! which SSIDs are actually broadcastLook for: high channel utilisation, a noise floor well above about −90 dBm, high retry rates, clients connected at low data rates or weak signal (sticky clients), and SSIDs missing from the BSS table.
Layer 2 — Association
(HQ-MC1) #show ap association client-mac 3c:22:fb:11:22:33
(HQ-MC1) #show ap remote debug mgmt-frames ap-name HQ-B1-F2-AP07 client-mac 3c:22:fb:11:22:33The management-frame trace shows probe, authentication and association requests and responses with status and reason codes. A client that is rejected at association is often hitting a capability mismatch — for example, a WPA2-only client on a WPA3-only SSID, a client that does not support PMF where PMF is required, or a client excluded by a deny list.
Layer 3 — Authentication
(HQ-MC1) #show auth-tracebuf mac 3c:22:fb:11:22:33 count 60
(HQ-MC1) #show aaa authentication-server radius statistics
(HQ-MC1) #aaa test-server mschapv2 CPPM1 testuser TestPass123The auth trace buffer is the most useful command on the platform for 802.1X. It shows each EAP and RADIUS message with a timestamp. Requests with no response mean the RADIUS server is unreachable or does not know this controller as a client; an Access-Reject means the server refused (check its own logs, such as ClearPass Access Tracker, for the reason); a client that stops responding mid-exchange usually does not trust the server’s certificate.
Layer 4 — IP and DHCP
(HQ-MC1) #show user-table | include 3c:22:fb:11:22:33 ! IP address, role, VLAN
(HQ-MC1) #show vlan ! is the user VLAN present and on the uplink?
(HQ-MC1) #show datapath session table 0.0.0.0 ! look for DHCP flows from clients without an IPA user who authenticated but has no IP address (or a 169.254.x.x address) has a VLAN problem — the VLAN is missing on the controller uplink or the upstream trunk — a missing DHCP relay on the gateway, an exhausted scope, or a role ACL that does not permit DHCP.
Layer 5 — Role and Firewall
(HQ-MC1) #show user ip 10.20.0.55 ! role, how it was derived, VLAN, AP
(HQ-MC1) #show rights employee ! what that role allows
(HQ-MC1) #show datapath session table 10.20.0.55 ! live flows and their actions while the user retriesIf the role is wrong, the problem is role derivation (Part 5). If the role is right but an application fails, the session table shows which flows are denied, and therefore which ACL line needs to change.
Layer 6 — Roaming and Applications
Drops while moving usually mean full re-authentication on every roam (check whether the auth trace shows an EAP exchange at each roam), sticky clients, or coverage gaps between APs. Choppy voice calls point at RF (retries, interference), QoS marking (check that voice flows are prioritised in the role), or off-channel scanning during calls (the disable-scanning ACL action from Part 5).
Logging and Debugging
! Detailed logs for one client only — safe in production
(HQ-MC1) (config) #logging level debugging user-debug 3c:22:fb:11:22:33
(HQ-MC1) #show log user-debug 50
(HQ-MC1) (config) #no logging level debugging user-debug 3c:22:fb:11:22:33
(HQ-MC1) #show log system 100
(HQ-MC1) #show log errorlog 50
(HQ-MC1) #show ap debug system-status ap-name HQ-B1-F2-AP07 ! AP reboot reasons and power state
(HQ-MC1) #tar logs tech-support ! bundle logs for TACPer-client user-debug logging is the right way to get detail without the controller-wide debug logging that can overload a production controller. Remember to switch it off afterwards.
Packet Captures
When logs are not enough, captures settle the question. Aruba APs can capture over the air and stream the frames to a laptop running Wireshark, which decodes Aruba’s encapsulation (Aruba ERM), started from the WebUI or the AP packet-capture commands. The controller can also capture its own datapath traffic. A capture taken next to the client with a laptop in monitor mode remains the gold standard for proving what a client actually did — and that the problem is the client driver, which it often is.
On the Conductor
(MCR-1) [mynode] #show switches ! all MDs up and synchronized?
(MCR-1) [mynode] #show configuration pending ! changes that were never committed
(MCR-1) [mynode] #show license-usage ! pool exhaustion → unlicensed APs
(MCR-1) [mynode] #show configuration effective detail /md/USA/HQ ! which node a setting came fromHow AOS 10 Changes the Picture
Everything in this series applies to AOS 8. AOS 10, managed from Aruba Central, keeps most of the concepts but moves them around:
| Concept | AOS 8 | AOS 10 |
|---|---|---|
| Management plane | Mobility Conductor, hierarchical nodes | Aruba Central groups, sites, templates and APIs |
| Controller | Required in the data path for tunnelled WLANs | Gateway, optional; only for tunnelled or mixed WLANs |
| Where 802.11 is decrypted | Controller (tunnel mode) or AP | Always the AP |
| Role enforcement | Controller PEF (AP in bridge mode) | AP for bridged WLANs, gateway for tunnelled WLANs |
| Clustering | Controller cluster: AAC/S-AAC, UAC/S-UAC | Gateway cluster: device designated gateway (DDG) and user designated gateway (UDG), with standbys |
| AirMatch, ClientMatch | On the Conductor | In Central |
| Licensing | AP/PEF/RFP pools on the Conductor | Per-device Foundation / Advanced subscriptions |
| Upgrades | Live Upgrade orchestrated by the Conductor | Live upgrades orchestrated by Central |
The role model, profile thinking, forwarding-mode trade-offs, ClearPass integration, RF principles and the layered troubleshooting method all carry over directly. An engineer fluent in AOS 8 needs to learn Central’s workflow, not a new way of thinking about Wi-Fi.
Where to Go From Here
- Lab it. A virtual Conductor, two virtual controllers in a cluster, one real AP, a RADIUS server and a DHCP server reproduce almost everything in this series (Part 1 lists the pieces).
- Read the official guides. HPE Aruba Networking’s AOS 8 user guide, CLI reference and Validated Solution Guides (VSGs) for campus design are detailed and freely available.
- Certification. HPE Aruba Networking’s campus-access certification track (historically ACMA and ACMP for mobility) follows the same structure as this series and is a good way to put the knowledge under pressure.
- Revisit the fundamentals. RF behaviour, 802.11 frame exchanges and security handshakes underlie every Aruba feature — the earlier posts on this site, starting with WLAN Fundamentals, cover them.
Exercises
1. Users in a lecture hall complain about slow Wi-Fi at the start of every class. show ap radio-summary shows 5 GHz radios at 85–90% channel utilisation with 80 MHz channels and nearly every AP on overlapping channels. What changes should be made?
Show answer
The hall is dense, so 80 MHz channels leave too few non-overlapping channels and co-channel interference consumes the airtime. Restrict this area’s radio profile to 20 or 40 MHz so AirMatch can give neighbouring APs separate channels, include DFS channels if possible, raise the minimum basic rate, keep the number of SSIDs low, and consider disabling 2.4 GHz on some radios. Verify after the next AirMatch run.
2. A barcode scanner model disconnects several times an hour. The auth trace shows no failures, but the management-frame trace shows the AP sending deauthentication frames shortly before each disconnect. What is a likely cause and a targeted fix?
Show answer
ClientMatch is likely steering the scanners (sticky-client or load-balancing moves), and since they do not support 802.11v, it does so by deauthentication. Some industrial clients handle this badly. Exclude that device type from ClientMatch steering (rather than disabling ClientMatch for everyone), and check RF coverage so the scanners do not end up in steering situations in the first place.
3. Every lunchtime, users near the break room lose 2.4 GHz connectivity for a few minutes, while 5 GHz users are fine. Which Aruba feature identifies the cause, and what is it most likely to find?
Show answer
Spectrum analysis (a hybrid AP, spectrum monitor, or the scanning radio near the break room). It will most likely classify a microwave oven, which radiates around 2.45 GHz with a high duty cycle while running. Fixes include steering clients to 5 GHz, moving the AP or the microwave, and keeping 2.4 GHz radios near the break room on channels farther from the oven’s energy.
4. A user reports that “the Wi-Fi doesn’t work”. In order, list the questions and commands needed to locate the problem.
Show answer
Gather who (MAC address), where (AP or location) and when. Then: is the client in show user-table? If not, check association (show ap association, management-frame trace) and authentication (show auth-tracebuf mac). If it is there, does it have an IP address in the right VLAN? If not, check VLANs and DHCP. If it has an IP address, is the role correct (show user ip, show rights)? If the role is correct, which flows are denied (show datapath session table)? If everything is correct, look at RF quality for that client (show ap debug client-table) and at roaming behaviour.
5. The security team wants every unknown AP in the building automatically contained. Why is this a bad policy, and what is a better one?
Show answer
Most unknown APs are neighbours or personal hotspots, not threats, and attacking them over the air is illegal in many jurisdictions. Contain only APs classified as rogue (confirmed on the corporate wired network), preferably by shutting the switch port, and alert on, rather than contain, interfering APs and impersonation attempts.
Summary
AirMatch computes a network-wide RF plan on the Mobility Conductor and deploys it once a day, with event-driven changes for radar and severe interference. Radio and regulatory-domain profiles set its limits: EIRP ranges, allowed channels and widths. ClientMatch builds a per-client view of every AP’s signal and steers sticky, single-band and overloaded clients, using 802.11v where clients support it. Spectrum analysis identifies non-Wi-Fi interference, and RFProtect classifies and, where appropriate, contains rogues. Troubleshooting works best layer by layer — RF, association, authentication, IP, role, roaming — with the auth trace buffer, user table, session table and per-client debug logging as the main tools. AOS 10 moves management to Central and decryption to the AP, but the concepts carry over.
That completes the series. From architecture in Part 1 to troubleshooting here, it covers the full AOS 8 stack: Conductor, controllers, APs, WLANs, roles, clusters and RF.