Aruba Troubleshooting & AIOps — Central Insights, UXI & Packet Capture

The wrong move that wastes your first hour

A user reports "internet down" on the Corp SSID. The reflex of most new engineers is to SSH into an AP and start reading show commands line by line, hunting for something red. Forty minutes later you've learned the AP is healthy — but you still don't know what the client experienced.

That's backwards. In an Aruba AIOps world, the platform has already watched the symptom happen. Your job is to read the diagnosis, then prove it — not to re-derive it from scratch. This lesson gives you four tools in the order you should reach for them.

The four tools, at a glance

① AI Insights — the network's doctor reads the chart

Aruba Central continuously pulls data from Wi-Fi, wired, SD-WAN gateways and user devices, then builds dynamic baselines automatically — so you don't hand-define service-level expectations. When a metric drifts outside its learned normal, Central posts an AI Insight card with the likely root cause and a recommended fix.

Every insight lands in one of three categories. Memorise these — they're the mental index you'll use for every ticket:

The killer feature is peer comparison. Central can anonymously compare your site to a class baseline — sites with similar configuration — so an insight reads "this site's roaming latency is 3× worse than peer sites," not just "latency is high." That turns a vague complaint into a measurable, defensible target.

② UXI — a sensor that pretends to be a user, then self-diagnoses

AI Insights tells you something drifted. User Experience Insight (UXI) proves it from the user's seat. UXI comes in two flavours, and picking the right one is a real interview question:

• Purpose-built sensor — a physical box you mount near where users sit. It actively associates to Wi-Fi, runs DHCP/DNS, and tests apps over Wi-Fi, Ethernet and WAN, 24×7. It can disconnect and reconnect deliberately because it's not a real person.
• Agent — software on a real end-user device. It gathers stats and runs synthetic app tests passively, but it does not test association or DHCP, because forcing a reconnect would disrupt the live user.

The magic is automated triage mode. When a UXI test fails, the sensor doesn't just log "failed" — it immediately runs a step-by-step set of tests to find why, from the user's perspective.

Notice the punchline in stage 5: because the sensor is on both Wi-Fi and Ethernet, triage re-runs the failing test on the wired path. If the wired test also fails, the fault isn't the wireless network — it's upstream (here, DNS). That single comparison saves you from blaming the Wi-Fi for a server problem.

③ Live packet capture — get the actual packets

Insights and UXI point you at the cause. Sometimes you need the raw frames to prove it — for a vendor case, an audit, or a stubborn intermittent bug. Aruba Central's Client Live Troubleshooting is the no-CLI way to do this.

You open a client in Clients, start Live Troubleshooting, and Central streams the client's live events. Enable targeted packet capture and, when the session ends, a Download PCAP link appears above the live events table — open it in Wireshark. Two version gates matter, and students copy these verbatim:

When you're on an AOS 8 controller and want frames straight off the air, the CLI gives you a targeted capture. Here's a copy-paste-accurate example for one client MAC:

(MC) #show ap debug client-table ap-name AP-Floor3-12
(MC) #pcap start ap-name AP-Floor3-12 radio 1 bssid 90:4c:81:aa:bb:cc filter mac a4:83:e7:11:22:33
(MC) #show ap packet-capture status
(MC) #pcap stop ap-name AP-Floor3-12 id 1

MAC               ESSID    Assoc_State  AP-name        Channel  SNR  Tx_Rate  Rx_Rate
a4:83:e7:11:22:33 Corp-WiFi associated  AP-Floor3-12   36/80    14   54M      72M
# SNR 14 dB is poor — client is far from this AP. Note it; we use it in section 4.

④ The sticky-client roaming fix — end to end

Now let's wire all four tools into one real ticket. A user at a desk near the edge of two cells reports "Wi-Fi slow at my seat, fine in the meeting room." Classic sticky client: the laptop is clinging to a far AP at low signal instead of roaming to the near one.

Roaming latency is the time for the client to associate on the To-AP, plus the time the To-AP takes to confirm the roam back to the From-AP. A sticky client never even tries to roam, so the AI Insight shows the client pinned to one AP at low SNR while a closer AP sits idle. ClientMatch (part of ARM) plus band steering and a sensible minimum-RSSI threshold nudge the client off the weak AP.

(MC) #show ap arm client-match summary
(MC) #show ap debug client-table ap-name AP-Floor3-12 | include a4:83:e7:11:22:33
(MC) #show rf arm-profile "Corp-ARM" | include 802.11k|min-rssi|client-match

Client-Match State: Enabled
MAC               Current-AP     Recommended-AP  SNR  Action
a4:83:e7:11:22:33 AP-Floor3-12   AP-Floor3-09    14   steer-pending
# ClientMatch sees a better AP (Floor3-09) and is steering the client toward it.