Prove Aruba is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. The laptop never associated. 802.1X rejected. The role is logon instead of contractor. The AP is Down on the managed device. ClearPass sent the wrong Enforcement Profile. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught the session: associate → authenticate → role → VLAN → role ACL → RF last. Here you learn the five tools you actually open, in order, when someone asks you to prove Aruba is working.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you reboot a healthy AP at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open the RF planner or the Enforcement Profile editor until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to Central. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the session and the handshake. Side B proves the role and the radio. Side C proves NAC when ClearPass is in the path. On a messy Sev-2, do them in this order until a field lights up.

Side A — Session + auth (Central or controller)

1. Prove the MAC has a session

   Classic Central: filter to the site, then Manage → Clients, List view. Search the username or MAC. Official columns include Client Name, Status, IP Address, VLAN, Connected To, AP Role, Gateway Role, Health. Quote Status. Connecting / Connected / Offline / Failed / Blocked are the documented values (Failed and Blocked are wireless-only). Source: All Clients Monitoring in List View; Clients (unified).

2. If you are on a controller, use the official table — not a screenshot

   show user-table (filter mac / authentication-method dot1x|mac). Official columns: Name, Role, Age(d:h:m), Auth, AP name. Empty table: confirm you are not on the Mobility Conductor, then show ap database switch <md-ip> to find the managed device that registered the AP. Source: CLI Bank — show user-table; show ap database.

3. If Status is Failed, read Failure Stage — do not reboot

   Click the client → Client Details → Failed Wireless Client Events. Official Failure Stage values: Association error, MAC authentication error, 802.1X authentication error, Key exchange error, DHCP error, Captive Portal error. Hover the stage for the error type. Controller twin: show auth-tracebuf mac <mac> and show auth-tracebuf failures. Source: Failed Wireless Client Events; Client Connectivity troubleshooting; CLI Bank — show auth-tracebuf.

4. If both 802.1X and MAC-auth ran, do not invent a second RADIUS

   Official Client Details note: when a client connects through 802.1X and MAC authentication, Central displays only the IP address of the server that performed 802.1X. Quote that server IP. Do not declare “MAC-auth has no server” from a blank MAC-auth IP.

Side B — Role + AP / controller health

1. Quote AP Role (and Gateway Role if a gateway is in the path)

   On the same Clients list, official columns are AP Role (“Role assigned by the AP”) and Gateway Role (“Role assigned by the Aruba Gateway”). Click the client for Overview. A Connected client with AP Role = logon or authenticated when you expected contractor is a role ticket, not an RF ticket. Source: All Clients; Wireless Client Details.

2. On the controller, quote Role + role-how

   show user-table field Role, then verbose for role-how. Code 6 means the HPE Aruba VSA landed — the name still has to match a local user-role. Codes 1 and 4 mean a default / AAA fallback. Do not blame ClearPass until role-how says the VSA actually arrived. Source: CLI Bank — show user-table.

3. If the floor is dark, prove AP status — not the client Health score

   Central Health Bar / Manage → Devices → Access Points → Online (or Offline) in List view. Controller: show ap database status down, optionally group <ap-group>. Official status values are up and down. Device Health on the operate dashboard is a pointer to that list. Client Health 0–100 (Poor / Fair / Good) is a different column — it is not AP Online. Source: The Health Bar; Monitoring with Central VSG; show ap database.

Path:            show user-table   /   show user-table mac aa:bb:cc:dd:ee:ff
Quote:           Name + Role + Auth + AP name
Then verbose:    role-how   (1–8, official derivation codes)
Auth filter:     authentication-method dot1x | mac | opensystem | psk | web
If empty:        show ap database switch <managed-device-ip>
AP health:       show ap database status down   (optional: group <ap-group>)

Side C — ClearPass Access Tracker (only if NAC is in the path)

1. Open Access Tracker, not the Enforcement Profile editor

   Path: Monitoring → Live Monitoring → Access Tracker. Official filters include Request ID, Source, Username, NAS IP Address, NAS Name, Service, Host MAC Address, Auth Type, Auth Method, Roles, Enforcement Profiles. Filter Username or Host MAC + the UTC window. Source: Live Monitoring: Access Tracker (ClearPass 6.11 / 6.10).

2. Read Login Status, then Service, then Enforcement Profiles

   Login Status is Accept, Reject, or Timeout. That is the RADIUS outcome. Then quote Service (which policy pipeline matched) and Enforcement Profiles (what was applied). Accept + the wrong profile is still a policy miss.

3. Open RADIUS Request Details → Output for the VSA

   Official session-details page: click the request, then the Output tab — attributes sent to the NAD. For an Aruba controller / AP / gateway, the VSG template is Aruba RADIUS Enforcement with Type Radius:Aruba, Name Aruba-User-Role (1). Letter case must match the NAD user-role. If Output has no Aruba-User-Role, the NAD will land a default (role-how 1 or 4). Source: Viewing Access Tracker Session Details; VSG Client Services Configuration.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

AEVD-01 — Prove the session (Client Status)

01:42 · P2. Priya on a hotel-adjacent campus SSID. Phone photo of Wi-Fi bars. L1 already booked a site survey and drafted an AP reboot for AP-LAB-17.

First tool: Manage → Clients, search her MAC. Controller: show user-table mac aa:bb:cc:dd:ee:ff on the managed device that owns the AP — not on the Conductor.

If Failed / Offline / no row: quote Status. There is no AP Role to hunt. Next is Failure Stage (AEVD-02) or AP health (AEVD-04) — not AirMatch.

If Connected: you proved the session. Now you are allowed to read AP Role, VLAN, and Connected To. Status is not the role.

AEVD-02 — Prove the handshake (auth logs)

02:05 · P2. After last night’s AAA profile push, Corp 802.1X fails for one laptop. Someone wants “disable 802.1X and use PSK until morning.”

First tool: Client Details → Failed Wireless Client Events. Filter that MAC. Controller: show auth-tracebuf mac aa:bb:cc:dd:ee:ff and show auth-tracebuf failures.

Proof field: Failure Stage = 802.1X authentication error (not Association, not DHCP). Hover for the error type. That stage is the ticket. If the stage is MAC authentication error, you are on a MAC-auth SSID / port — do not debug PEAP.

AEVD-03 — Prove the role (AP Role / Role + role-how)

02:20 · P2. finance.user is Connected on Corp. RSSI looks fine. File share 10.20.0.10 fails. L1 wants a channel walk.

First tool: Clients list AP Role (and Gateway Role if traffic hits a gateway). Controller: show user-table → Role, then verbose role-how.

Proof field: AP Role = authenticated, role-how = 6 (VSA) or 1 (AAA default). The factory taught: role is the enforcement word. If the role is already the intended contractor role, then read datapath (show datapath session) for the ACL hit. If the role is wrong, datapath will only confirm the wrong role is doing its job.

AEVD-04 — Prove the radio (AP / controller health)

02:40 · P1. Floor 4 lost Corp after 02:00. Clients list for that AP group is empty. L1 wants AirMatch disabled and every AP rebooted.

First tool: Manage → Devices → Access Points, or Health Bar → Access Points → Online. Controller: show ap database group <floor4-group> status down.

Proof field: AP status flipped to down on the managed device that should own those CAPs. Simultaneous 02:00 death of a whole group is almost never “everyone’s 802.1X cookie expired together.” If every AP is still up and clients are Failed, you are back on AEVD-02 — do not reboot Up APs.

AEVD-05 — Prove NAC (Access Tracker)

03:00 · P2. Contractor cannot reach staff VLAN. Central Status = Connected, AP Role = authenticated. Someone wants both ClearPass nodes restarted.

First tool: ClearPass Monitoring → Live Monitoring → Access Tracker. Filter Username / Host MAC + last 30 minutes.

Proof field: Login Status = Accept, Service = 802.1X Wireless, Enforcement Profiles = OWL_Authenticated, Output Aruba-User-Role (1) = authenticated. The NAD did what it was told. Fix the profile (or the service order that picked it). If Login Status = Reject, quote Alerts / Error Code — a node restart will not rewrite a reject policy. If there is no request, the NAS never sent RADIUS — that is Side A / AAA on the controller, not ClearPass.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• HPE Aruba TechDocs — Clients (unified) (Manage → Clients; Status Connecting / Connected / Offline / Failed / Blocked; AP Role; Gateway Role; Health; Authentication)
• HPE Aruba TechDocs — Client Status Changes
• HPE Aruba TechDocs — All Clients Monitoring in List View (Client Name, Status, IP Address, VLAN, Connected To, AP Role, Gateway Role, Health)
• HPE Aruba TechDocs — Client Details Wireless Overview (connection status; 802.1X + MAC shows the 802.1X server IP)
• HPE Aruba TechDocs — Dashboard for Wireless Clients (AP Role = role assigned by the AP)
• HPE Aruba TechDocs — Failed Wireless Client Events or Reasons (Failure Stage)
• HPE Aruba TechDocs — Client Connectivity (Failure Stage: Association, MAC authentication, 802.1X, Key exchange, DHCP, Captive Portal)
• HPE Aruba CLI Bank — show user-table (Role, Auth, role-how codes 1–8, authentication-method)
• HPE Aruba CLI Bank — show user-table (SD-Branch) (Name, Role, Age(d:h:m), Auth, AP name)
• HPE Aruba CLI Bank — show auth-tracebuf (802.1X trace; failures; mac)
• HPE Aruba CLI Bank — show ap database (status up|down, group, switch <managed-device-ip>)
• HPE Aruba CLI Bank — show datapath (session table after the role is proven)
• HPE Aruba TechDocs — The Health Bar (Manage → Devices → Access Points → Online)
• HPE Aruba VSG — Monitoring with Central (Device Health card)
• ClearPass 6.11 — Live Monitoring: Access Tracker (Request ID, Login Status, Enforcement Profiles)
• ClearPass 6.10 — Access Tracker filters (Username, NAS IP Address, Service, Host MAC Address, Auth Type, Roles, Enforcement Profiles)
• ClearPass 6.11 — Viewing Access Tracker Session Details (RADIUS Request Details → Output)
• HPE Aruba VSG — Client Services Configuration (Aruba RADIUS Enforcement; Radius:Aruba / Aruba-User-Role (1); case must match)
• HPE Aruba TechDocs — Configuring User Roles for IAP Clients (every client is associated with a user role)
• HPE Aruba TechDocs — New Central · Viewing Clients in List View (VLAN, Connected To = AP / Switch / Gateway name)

Related: Blog 1 · Aruba session factory · ClearPass policy pipeline · WLAN SSID and roles · Central Live Troubleshooting · HPE Aruba practice hub