What does AirMatch tune for each radio when it deploys a plan?

Correct: b. AirMatch's job is purely RF: it assigns each radio a channel, a channel width, and an EIRP value. SSID/VLAN/security live in the WLAN profile — that's the next lesson, not AirMatch.

You must manually pin AP-FL2-N03 radio0 to channel 36 for a temporary survey, but you don't want AirMatch overwriting it tonight. What's the cleanest action?

Correct: c. airmatch ap freeze deploys and locks the chosen channel/EIRP on that one radio regardless of AirMatch state, until explicitly unfrozen. Disabling AirMatch network-wide (a) is a sledgehammer; 0% threshold (b) makes AirMatch more aggressive everywhere — the opposite of what you want.

A new high-density lecture hall has 40 clients per AP and constant contention. Which combination most directly improves capacity?

Correct: b. High density = smaller cells (lower EIRP, more re-use) plus active load balancing. Max EIRP (a) makes contention worse; forcing 2.4 GHz (c) is the slowest band; disabling ClientMatch (d) re-creates sticky/imbalanced clients.

An engineer raises the AirMatch quality threshold from 8% to 16% on a noisy, interference-heavy warehouse. Weeks later, RF is still poor and AirMatch rarely deploys a plan. Why?

Correct: a. Conservative (high) threshold suits already-clean networks where you want stability. A noisy warehouse needs frequent re-optimisation, so it wants a LOWER (more aggressive) threshold. The engineer applied the right knob in the wrong direction.

Clients on a 5 GHz radio drop for ~2 seconds at irregular times every afternoon near an airport. show ap arm history shows "Radar detected" entries. AirMatch deploy time is unchanged at 5 AM. What's the correct conclusion?

Correct: d. Irregular timing + explicit radar reasons + 5 AM AirMatch untouched all point to DFS radar events near the airport. The targeted fix is curating the DFS channel list, not touching AirMatch or ClientMatch.

A consultant proposes: "Disable AirMatch and ClientMatch entirely, hard-set every channel and crank EIRP to max — simpler to manage." Evaluate this for a 300-AP modern campus.

Correct: a. At 300 APs the proposal undoes everything these engines exist for: max EIRP overlaps cells, static channels can't dodge DFS radar or new interferers, and removing ClientMatch brings back sticky, imbalanced clients. Manual RF at scale is brittle — coordination scales, brute force does not.

Aruba RF Optimization — AirMatch, ARM & ClientMatch

Q: Which statement best captures how AirMatch differs from ARM?

Correct: b. AirMatch = centralized planner, global view, 24-hr cycle, deploy ~5 AM. ARM = older reactive engine, each radio acts on its own local view. Neither steers clients — that's ClientMatch.

Q: When ClientMatch decides to move a client, how does it actually force the re-association?

Correct: c. The temporary, targeted blacklist (default ~10 s) leaves only the desired radio available, so a standard client naturally re-associates there. No driver, no permanent ban, no EIRP change. Standards-based 802.11.

Q: A dual-band-capable client associates on 2.4 GHz and its health is poor. In what band order does ClientMatch try to steer it?

Correct: a. ClientMatch prefers the cleanest, widest band first: 6 GHz, then 5 GHz, and only stays on crowded 2.4 GHz if neither higher band is viable for that client. (6 GHz only applies to Wi-Fi 6E/7-capable clients.)

Q: You see an AP change channel at 14:02 with reason "Radar detected". Which engine/feature caused this, and is it expected?

Correct: d. The mid-afternoon timing and the explicit "Radar detected" reason point to DFS. By regulation the AP must leave the DFS channel within seconds. It's expected behaviour — fix it by curating the DFS channel list, not by blaming AirMatch.

Start here — the wrong answer everyone gives

Ask a fresh L1 engineer "how do you fix slow Wi-Fi?" and the reflex answer is: "turn the AP power up to max." It feels right — more power, more reach, more bars. In reality this is the single most common way to ruin an Aruba deployment.

Crank every AP to maximum EIRP and every cell overlaps every other cell. Now two APs on the same channel hear each other, take turns transmitting, and your throughput halves. Clients also "stick" to a far, loud AP instead of roaming to the near one. The right answer is the opposite of brute force — it is coordination, and Aruba ships three engines to do it for you.

Field scenario · Priya at a Bengaluru enterprise

Priya, an L1 at a 200-AP campus, gets a 4 PM ticket: "Wi-Fi slow on the 3rd floor." She bumps the nearest AP from 12 dBm to 24 dBm EIRP. By 5 PM the whole floor is worse — co-channel interference spiked. Lesson: power is a system property, not a per-AP dial. Aruba's RF engines exist precisely so humans stop guessing.

Figure 1 — Division of labour. AirMatch and ARM shape the radio environment; ClientMatch decides which radio each device should live on.

Foundation tiles — tap to flip

📡

AirMatch

tap to flip

Centralized RF planner. Collects 24 hrs of network-wide data, runs a solver, deploys one coordinated channel + bandwidth + EIRP plan (default 5 AM).

⚡

ARM

tap to flip

Adaptive Radio Management — the older reactive engine. Each radio scans the air and can change channel/power on its own, with only a local view.

🧲

Sticky client

tap to flip

A device that clings to a far AP with weak signal instead of roaming to a near one. Low RSSI, low data rate, drags down everyone on that radio.

🚫

DFS

tap to flip

Dynamic Frequency Selection — on certain 5 GHz channels APs must vacate within seconds if radar is detected. A surprise source of channel changes & brief drops.

Warm-up · before we start (not graded)

Quick gut check — which engine actually moves a client device from one radio to another?

a) AirMatch b) ARM c) ClientMatch d) DFS

Answer: c — ClientMatch. AirMatch and ARM tune the radios (channel/power). ClientMatch is the only one that nudges the actual client device to a better radio or band. Keep this split in mind for the whole lesson.

Warm-up · before we start (not graded)

By default, when does AirMatch deploy its new channel/EIRP plan?

a) Instantly, the moment it detects interference b) Once a day, around 5 AM, after a 24-hour collection cycle c) Every 5 minutes d) Only when an admin clicks "optimize now"

Answer: b. AirMatch is a planner, not a firefighter. It collects ~24 hours of RF data, runs its solver, then deploys one coordinated plan — by default at 5 AM (configurable). Instant reactions are ARM's job.

Warm-up · before we start (not graded)

Setting every AP to maximum EIRP usually makes Wi-Fi…

a) Faster everywhere — more power is always better b) Worse — overlapping cells cause co-channel interference and sticky clients c) Unchanged — EIRP doesn't affect cell size d) More secure

Answer: b. Big cells overlap, same-channel APs contend for airtime, and clients stick to loud-but-far APs. That's why AirMatch deliberately tunes EIRP down in dense areas. Coordination beats brute force.

① AirMatch — the network-wide RF planner

AirMatch is the modern engine. It takes a global view: it gathers RF statistics from every radio in the network for ~24 hours, feeds them to a solver in the conductor (ArubaOS 8) or in Aruba Central (ArubaOS 10), and then computes one coordinated plan — channel, channel width and EIRP for each radio — that it deploys network-wide, by default at 5 AM.

New to RF? Think of AirMatch as a music festival sound engineer. Instead of every band cranking their amp to 11, one engineer balances all the stages overnight so no two acts drown each other out. AirMatch does that for Wi-Fi channels and power — once a night, for the whole campus.

Practitioner view: AirMatch only deploys a new plan if the predicted improvement clears the quality threshold (0%=aggressive, 16%=conservative, 8% default = Balanced). On AOS 10 this lives at the GLOBAL level in Central. Use show airmatch optimization to see the proposed plan before it deploys.

Architect view: AirMatch is a constrained optimisation problem — minimise co-channel interference subject to regulatory domain, DFS availability, AP feasibility and channel-width policy. Because it solves the whole graph centrally, it avoids the local-minima oscillation that pure per-AP ARM can fall into. Trade-off: it is not real-time, so you still need ARM-style reaction for sudden events.

Figure 2 — AirMatch is a gated planner: it only ships a new plan when the predicted gain beats your quality threshold.

▶ Watch AirMatch run a cycle

Click Play. Each stage lights up as the cycle advances from data collection to the 5 AM deploy.

① COLLECT 200 radios report channel busy, noise, neighbour RSSI all day → conductor / Central

▼

② SOLVE Solver computes per-radio plan: e.g. AP 10.20.4.11 radio0 → channel 36, width 80 MHz, EIRP 15 dBm

▼

③ GATE Predicted interference drop = 11%. Quality threshold = 8%. 11% ≥ 8% → plan approved

▼

④ FEASIBILITY Check each radio's regulatory domain + DFS state. Channel 100 (DFS) skipped on the AP that saw radar yesterday.

▼

⑤ DEPLOY 05:00 Plan pushed to all radios in one coordinated window. Channels + EIRP updated

▼

⑥ STEADY Network now balanced. ARM handles any sudden event until tomorrow's cycle.

Press Play to step through a full AirMatch cycle. Each press of Next advances one stage.

CLI — see the proposed plan before it deploys (AOS 8 conductor)

(MM) [mynode] #show airmatch optimization radio-type 5ghz

Expected output (trimmed)

AP Name        Radio MAC          Curr-Ch  New-Ch  Curr-EIRP  New-EIRP
-------------  -----------------  -------  ------  ---------  --------
AP-FL3-N12     a8:bd:27:11:40:00  149      36      24         15
AP-FL3-N14     a8:bd:27:11:42:10  149      44      24         18
Quality improvement: 11.4%   Threshold: 8%   Action: DEPLOY @ 05:00

Pause & predict

Your campus RF is rock-solid and you keep getting tiny 2–3% nightly channel changes that briefly drop a few clients at 5 AM. What single AirMatch setting calms this down?

Raise the quality threshold from 8% toward 16% (more conservative). Now AirMatch only deploys when it predicts a big win, so small churny changes are discarded. On an already-clean network, conservative is correct — you trade a little theoretical optimality for stability.

Quick check · Q1 of 10

Which statement best captures how AirMatch differs from ARM?

a) AirMatch is a per-AP real-time engine; ARM is the cloud planner b) AirMatch computes one coordinated network-wide plan on a 24-hr cycle; ARM reacts locally per radio in real time c) They are the same feature with different names d) AirMatch only steers clients; ARM only tunes power

Correct: b. AirMatch = centralized planner, global view, 24-hr cycle, deploy ~5 AM. ARM = older reactive engine, each radio acts on its own local view. Neither steers clients — that's ClientMatch.

② ClientMatch — steering the device, not the radio

AirMatch and ARM fix the radios. But a perfectly tuned network still suffers if a phone refuses to leave a far AP. That's a sticky client, and ClientMatch is the engine that fixes it.

ClientMatch watches every client's RSSI and capabilities using probe requests and data frames. It does three jobs: sticky-client steering (move a weak client to a nearer AP), band steering (push a dual-band client off crowded 2.4 GHz toward 6 GHz, then 5 GHz), and load balancing (spread clients across APs by load and SNR).

Field scenario · Rahul at TCS, Pune campus

Rahul walks from a meeting room to his desk. His laptop stays glued to the conference-room AP at -78 dBm instead of jumping to the desk AP at -52 dBm three metres away. Video calls stutter. ClientMatch spots the falling RSSI, blacklists the laptop on every nearby radio except the desk AP for 10 seconds, and the laptop re-associates to the strong one. No driver, no ticket, no Rahul noticing.

Figure 3 — ClientMatch's band-steer ladder (6 → 5 → 2.4 GHz) and the 10-second per-radio blacklist that forces the move.

▶ Watch a sticky client get steered

Rahul's laptop is stuck on a far AP. Follow how ClientMatch moves it.

① BASELINE Laptop aa:bb:cc:11:22:33 on AP-Conf at RSSI -78 dBm, 6 Mbps. Desk AP heard at -52 dBm.

▼

② DETECT ClientMatch flags it: RSSI below the sticky threshold while a much better AP is in range.

▼

③ TARGET Best radio chosen = AP-Desk 5 GHz (or 6 GHz if client-capable & healthy).

▼

④ BLACKLIST 10s Every radio except AP-Desk 5 GHz blacklists the client for ~10 s.

▼

⑤ RE-ASSOC Client probes, finds only AP-Desk 5 GHz available, re-associates there. RSSI -52 dBm.

▼

⑥ RESULT Data rate jumps from 6 Mbps to ~400+ Mbps. Blacklist clears. Rahul never noticed.

Watch how ClientMatch uses a temporary blacklist on the OTHER radios — not a forced kick — to guide a standard client.

Pause & predict

A vendor claims their IoT sensors "can't be steered" because they have a cheap chipset. Will ClientMatch still work on them?

Mostly yes — but not guaranteed. ClientMatch uses standard 802.11 messaging, so it needs no special driver. The blacklist trick works on almost any client. BUT some stubborn/legacy devices probe slowly or ignore steering hints; for those you tune the steering aggressiveness or, worst case, pin them to a band. Steering is a nudge, not a hard kick — design for the 95%, handle the 5% by exception.

Quick check · Q2 of 10

When ClientMatch decides to move a client, how does it actually force the re-association?

a) It permanently bans the client from all other APs b) It installs a steering driver on the client c) Every radio except the chosen target blacklists the client for a short window (~10 s) so it re-associates to the target d) It raises the target AP's EIRP to maximum

Correct: c. The temporary, targeted blacklist (default ~10 s) leaves only the desired radio available, so a standard client naturally re-associates there. No driver, no permanent ban, no EIRP change. Standards-based 802.11.

Pause & predict

Two APs in an open hall both hear 30 clients each, but one AP is on a clean channel and the other on a congested one. Which ClientMatch job spreads this out, and what does it balance on?

Load balancing — ClientMatch spreads clients across APs based on each AP's client load and the client's SNR. It won't blindly shove a client onto a far, weak AP just to even the numbers; a move only happens when the target radio is actually good enough for that client. Balance by load, gated by signal quality.

Quick check · Q3 of 10

A dual-band-capable client associates on 2.4 GHz and its health is poor. In what band order does ClientMatch try to steer it?

a) 6 GHz first, then 5 GHz, keeping 2.4 GHz as last resort b) Always straight to 2.4 GHz c) Randomly d) 5 GHz first, then back to 2.4 GHz, never 6 GHz

Correct: a. ClientMatch prefers the cleanest, widest band first: 6 GHz, then 5 GHz, and only stays on crowded 2.4 GHz if neither higher band is viable for that client. (6 GHz only applies to Wi-Fi 6E/7-capable clients.)

③ Troubleshoot — "the APs keep changing channel!"

This is the ticket every wireless engineer eventually gets. Clients drop for a few seconds, then recover, repeatedly. There are three usual suspects — work them in order.

Figure 4 — Channel-change drops have three different root causes. Identify which, then apply the matching fix.

Field scenario · Sneha at a hospital network

Sneha sees 5 GHz APs near the radiology wing change channel several times an afternoon — never at 5 AM. That timing rules out AirMatch. It's DFS radar detection: weather/airport radar pulses on DFS channels force the legally-mandated vacate. Her fix isn't "disable DFS" — it's removing the specific affected DFS channels from the valid-channel list so AirMatch never assigns them in that wing.

CLI — confirm what changed an AP's channel and when

(MM) [mynode] #show ap arm history ap-name AP-FL3-N12

Expected output (trimmed)

Time         Old-Ch  New-Ch  Reason
-----------  ------  ------  -----------------------
14:02:11     100     36      Radar detected (DFS)
14:48:30     36      36      No change
05:00:02     36      44      AirMatch plan deploy

The #1 RF mistake — "max power = best Wi-Fi"

Symptom you see: after you raise EIRP, throughput drops, clients stick, and roaming gets worse — the opposite of what you expected. Cause: larger cells overlap, same-channel APs contend for airtime, and clients cling to the loud-but-far AP. Let AirMatch tune EIRP down in dense areas; smaller cells = more capacity. Power is a system property, not a per-AP dial.

Mistake #2 — leaving every DFS channel enabled in a radar-heavy site

Symptom you see: seemingly random multi-second drops on 5 GHz, no pattern at 5 AM. Cause: APs are assigned DFS channels that catch radar and must vacate. Trim the specific noisy DFS channels from the valid-channel list rather than disabling DFS wholesale (you'd lose a lot of clean spectrum).

Three pro tips that separate L1 from L2

1. Don't fight AirMatch with manual channels — if you must pin a radio, use airmatch ap freeze so AirMatch leaves it alone (and unfreeze later). 2. On a clean, stable campus push the quality threshold up toward conservative — stability beats theoretical perfection. 3. RF tuning is only half the job: keep AP firmware patched. The Instant On CVE-2025-37103 hardcoded-credential flaw (CVSS 9.8) shows a perfectly-tuned but unpatched AP is still a liability.

Quick check · Q4 of 10

You see an AP change channel at 14:02 with reason "Radar detected". Which engine/feature caused this, and is it expected?

a) AirMatch — and it's a bug b) ClientMatch — it steered the AP c) A client manually changed the AP's channel d) DFS radar detection — expected and legally required; the AP must vacate the channel

Correct: d. The mid-afternoon timing and the explicit "Radar detected" reason point to DFS. By regulation the AP must leave the DFS channel within seconds. It's expected behaviour — fix it by curating the DFS channel list, not by blaming AirMatch.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from HPE Aruba TechDocs + Airheads community Q&A. For complex prod issues, paste your show airmatch event + show ap arm history output into chat.techclick.in.

🧠 Lock it in — explain it in your own words

In 2–3 sentences, explain to a teammate the single-line difference between AirMatch, ARM and ClientMatch. Typing it from memory is what moves it into long-term recall.

Teach-a-friend challenge: message one colleague the sentence "max EIRP makes Wi-Fi worse, not better — here's why" and see if they can explain it back. Teaching is the fastest test of your own understanding.

⏰ Remember this in 7 days

Want a 3-question recall nudge in a week? Drop your email — we'll send one short spaced-repetition quiz on AirMatch / ARM / ClientMatch. No spam, unsubscribe anytime.

📖 Glossary

AirMatch: Centralized RF planner; computes a network-wide channel/width/EIRP plan on a 24-hr cycle, deploys ~5 AM.
ARM: Adaptive Radio Management — older reactive engine; each radio scans and can change channel/power on its own local view.
ClientMatch: Per-client steering engine; band steering, sticky-client mitigation, and AP load balancing.
EIRP: Effective Isotropic Radiated Power (dBm) — actual radiated power; controls cell size.
RSSI: Received Signal Strength Indicator — how strongly the AP hears the client (negative dBm; closer to 0 = stronger).
DFS: Dynamic Frequency Selection — APs on certain 5 GHz channels must vacate within seconds when radar is detected.
Quality threshold: Minimum predicted improvement before AirMatch deploys a new plan; 0% aggressive → 16% conservative, 8% default.
Sticky client: A device clinging to a far AP with weak signal instead of roaming to a closer/better radio.

📚 Sources

HPE Aruba Networking TechDocs — AirMatch (ArubaOS 10, WLAN & SD-Branch). arubanetworking.hpe.com/techdocs/aos/aos10/services/airmatch/
HPE Aruba Networking TechDocs — ClientMatch (ArubaOS 10). arubanetworking.hpe.com/techdocs/aos/aos10/services/clientmatch/
HPE Aruba Networking TechDocs — Configuring AirMatch & airmatch ap freeze (CLI Bank, AOS 8.x); show airmatch debug feasibility.
Aruba Airheads Community — "AIRMATCH AOS10 in Aruba Central" + EMEA Airheads deck "What does AirMatch do differently?"
HPE Security Advisory — CVE-2025-37103 (Instant On hardcoded credentials, CVSS 9.8) & Dec-2025 advisory CVE-2025-37165 / 37166 (fixed 3.3.2.0).
HPE / Aruba — ACMA (HPE6-A42) Exam Reference Guide & ACMP (HPE6-A71) study guide: ARM Overview, AirMatch, ClientMatch, DFS, TPC, regulatory domains.

What's next?

Now that the air is clean, we build the WLAN on top of it — how an SSID actually becomes a Virtual AP, how AAA profiles authenticate users, WPA3 encryption, and how user roles enforce who-gets-what once a client is on.

Next · Aruba WLAN & SSID Design — VAPs, AAA, WPA3 & Roles → ← All lessons

Aruba RF Optimization — AirMatch, ARM & ClientMatch, Watched Live

By the end, you will be able to

Pick an engine — jump straight to it

Big Picture

AirMatch

ClientMatch

Troubleshoot

Start here — the wrong answer everyone gives

Foundation tiles — tap to flip

① AirMatch — the network-wide RF planner

▶ Watch AirMatch run a cycle

② ClientMatch — steering the device, not the radio

▶ Watch a sticky client get steered

③ Troubleshoot — "the APs keep changing channel!"

🤖 Ask the AI Tutor

📝 Wrap-up — six more

🧠 Lock it in — explain it in your own words

⏰ Remember this in 7 days

📖 Glossary

📚 Sources

What's next?