This walks the same documented findings as the rest of the guide, just reached by symptom instead of by platform. Nothing here is a new claim — every stop links back to its full writeup and sources.

What this does and doesn't tell you

• Download/upload — real throughput to a nearby Cloudflare edge node, over HTTPS, from this browser tab. It reflects the whole path: Wi-Fi link, LAN, router, and the ISP uplink — not Wi-Fi in isolation. A slow result here doesn't by itself tell you which hop is the bottleneck.
• Idle latency/jitter — round-trip time and its variance to that same edge node, measured with the link otherwise quiet. High jitter with otherwise fine throughput is a classic sign of airtime contention or a congested channel, worth cross-checking against the QoS & voice/video section.
• Loaded latency (bufferbloat) — the same latency measurement, taken again while the download and upload tests are actively saturating the link. The gap between idle and loaded latency is a real, well-known diagnostic: a large jump means something in the path (often a consumer router's own buffer, sometimes the AP itself) is queuing packets under load rather than dropping or prioritizing them. This matters directly for voice/video and gaming, which degrade from added latency long before raw throughput becomes the problem.
• Connection detail (RTT, retransmits, packets lost) — these come from Cloudflare's own edge, reported back for the specific TCP connection this test used, via a Server-Timing response header their network stack sets. This is the server's measurement of that one connection, not a browser estimate layered on top — but it's one connection's data, not a long-run average, so treat a single bad reading as a prompt to re-run the test rather than a confirmed diagnosis.
• Not measured, and not measurable from any browser on any OS: RSSI, SNR, channel, channel width, PHY mode (802.11n/ac/ax/be), MCS index, spatial streams, or negotiated Tx rate. Browsers deliberately have no API for this — it's an OS/driver privacy boundary, not a limitation of this page specifically. This page does not estimate or infer any of those values from throughput, latency, or any other number above — too many non-Wi-Fi factors (server distance, TCP window scaling, ISP congestion) affect those same numbers for a correlation to mean anything.

Pulling your own connection details

To get the radio-level detail a speed test can't show (what this looks like on a Mac, as an example):

Pulling a packet capture or crash/support bundle from the network side

Live packet capture (Embedded Packet Capture)

monitor capture uplink interface <interface> both
! optional: filter to specific traffic first
ip access-list extended CAPFILTER
 permit ip host <src-ip> host <dst-ip>
monitor capture uplink access-list CAPFILTER
monitor capture uplink buffer circular size 50
monitor capture uplink start
monitor capture uplink stop
monitor capture uplink export ftp://<server>/capture.pcap
no monitor capture uplink   ! remove the capture definition once done

Full support/crash bundle (the "give TAC everything" command)

show tech-support wireless                      ! full wireless bundle (no arguments)
show tech-support wireless ap                   ! AP-specific subset
show tech-support wireless client [mac-address <mac>]
show tech-support wireless mobility              ! mobility-tunnel-specific subset
show tech-support wireless datapath

Actual crash/coredump artifacts

show ap crash-file                                              ! AP-side crash files
dir all | i crash                                                ! list crash files on the WLC
more bootflash:system-report*                                   ! view the auto-generated system report
copy bootflash:system-report-<timestamp>.tar.gz tftp:           ! copy it off-box

unconfirmed — request platform software trace archive last <N> {days|hours|minutes|seconds} target {bootflash:|flash:|...} is real and documented (IOS-XE 17.12.1+), but it archives platform/radioactive trace logs specifically, not a tech-support or crash bundle. Don't substitute it for show tech-support wireless when TAC asks for "the tech-support file" — it collects a different, narrower thing.

2.4 GHz — channels 1–14

5 GHz — UNII bands and DFS

inference — exact channel/DFS allocations vary by regulatory domain (Cisco's own domain codes: -A, -B, -E, -N, -Q, etc.) — the table above reflects current US (FCC) allocation. Always confirm against show controllers dot11Radio <n> | include Reg|Country or the AP's configured country code before assuming a channel is legal to use at a given site.

6 GHz — new band, new power-mode complexity

Verifying what's actually configured

show ap config general                              ! country code, regulatory domain
show controllers dot11Radio <n>                      ! per-radio channel, power, DFS state
show ap dot11 5ghz channel                           ! current 5GHz channel assignment
show ap dot11 6ghz summary                           ! 6GHz radio state, power mode

MU-MIMO vs. OFDMA — the distinction that actually matters operationally

inference — these are frequently conflated but solve different problems. MU-MIMO (introduced 11ac, improved in 11ax) lets the AP talk to multiple clients simultaneously using spatial separation — most valuable with few, high-throughput clients. OFDMA (new in 11ax/Wi-Fi 6) subdivides a channel into resource units so many clients can each get a small efficient slice at once — most valuable in high-density, many-small-packet environments (IoT, dense classrooms/stadiums). A dense-client-count problem is an OFDMA story; a few-clients-need-max-throughput problem is a MU-MIMO story — picking the wrong lever to tune for a given symptom wastes field time.

Why this uses nameplate class draw, not "typical" draw

IEEE 802.3 PoE class reference

documented — the gap between PSE output and PD-guaranteed wattage is the IEEE spec's own cable-loss reserve, not a vendor margin — standard Category 5e/6 cabling at 100m is accounted for in that delta. Longer runs on lower-category cable can still derate further; Cisco documents cable category/quality (not a shorter max length) as the lever at higher power classes.

Why this matters for a WLAN-side troubleshooting conversation

• A guest WLAN anchored to a DMZ controller should egress through that DMZ's own ASN/path, not accidentally fall back through the corporate path — this is a fast way to confirm which one is actually happening without digging through routing tables.
• If a client's traffic reports an ASN/network that doesn't match any expected egress point at all, that's a routing or NAT misconfiguration worth escalating, not a Wi-Fi symptom.
• inference — this reports the ASN of whatever IP Cloudflare's edge sees as your current source address, which is correct for confirming NAT/egress behavior, but it says nothing about Wi-Fi link quality or RF state — it's a routing-path tool, not a radio-layer one.

Data freshness

documented — the source file explicitly asks consumers "please don't download it more often than [weekly]," since it's regenerated on that cadence from IEEE's own registry. This tool respects that: the OUI list is fetched once and cached in this browser's local storage for 7 days before refetching, not re-fetched on every lookup.

The misconception to rule out first

Where AAA actually enters the picture

• An optional, off by default feature — "Authorize APs against MAC" — checks the AP's MAC/cert against a local DB or RADIUS before join.
• 802.1X AP-as-supplicant: a separate, often-confused mechanism that authenticates the AP's wired port to the switch, not the WLC.

The real, documented causes

Telling AAA-driven apart from cert/CAPWAP-driven

show ap join stats detail
show wireless stats ap discovery
show wireless stats ap join
show dtls connection          (AP-side)

show ap join stats detail returns a distinct reason string per cause — "Radius authorization of the AP has failed" reads very differently from "Certificate payload in join request contains invalid certificate."

Field takeaway inference

AAA sits in exactly one narrow, opt-in path, while cert, licensing, country, and version failures dominate the documented literature. If an AP won't join and nobody deliberately turned on AP authorization, chase the certificate or the license before you chase ISE.

9800-CL without Smart Licensing — a hard, enforced cap

show license status
show license summary

Licensed platforms over their purchased AP count

show license summary
show license status
show license air entities summary   ! per-AP license reporting detail

Field takeaway

No Cisco documentation gives a hard numeric join-blocking threshold for any platform except the 9800-CL's 50-AP no-license cap. Everywhere else, "over the license count" is a compliance finding to resolve, not a join failure to troubleshoot.

Stuck pre-join: a corrupted-image boot loop

verify signature failed for /bootpart/part1/ramfs_data_cisco.cpio.lzma
Image signature verification failure: -3

Joins fine, then reboots/rejoins repeatedly afterward

show ap crash                                              ! AP crash files stored on the WLC
dir all | i crash
show wireless stats ap history mac-address <mac>           ! last reboot type/reason
show wireless stats ap mac <radio-mac> join detailed        ! disconnect type/reason/count

show wireless loadbalance ap affinity mac <mac>
sh proc cpu platform | i wncd

Same switch or stack

Scattered across different, unrelated switches

show wireless loadbalance ap affinity wncd <0-7>   ! which APs share a wncd instance
sh proc cpu platform | i wncd                       ! per-process CPU

802.11r Fast Transition — what it actually does

Over-the-Air vs. Over-the-DS

• Over-the-Air: "The client communicates directly with the target AP using IEEE 802.11 authentication with the FT authentication algorithm."
• Over-the-DS: "The client communicates with the target AP through the current AP" — FT action frames are relayed via the current AP/controller.
• FT-SAE uses a new AKM OUI (00-0F-AC:9); the STA includes a Mobility Domain Element (MDE) and RSNE in the (re)association request, the AP echoes FTE/MDE/RSNE back, and the two sides run a Fast Transition 4-way handshake after SAE auth. A mismatched MDE returns STATUS_INVALID_MDE; an AKM mismatch returns STATUS_INVALID_AKMP.

Mobility Domain ID (MDID) — the roaming boundary FT actually uses

Configuration (CLI)

wlan <profile-name>
 shutdown
 security ft
 security wpa akm ft dot1x        ! or: ft psk | ft sae
 no shutdown

Disabling specific behavior: no security ft {adaptive | over-the-ds | reassociation-timeout <sec>}. FT-over-DS is enabled by default on WLAN creation — a WLAN can be "FT-capable" without anyone deliberately turning on the DS path.

Restrictions — the real failure modes, quoted directly

• "EAP LEAP method is not supported."
• "Traffic Specification (TSPEC) is not supported for 802.11r fast roaming. Therefore, RIC IE handling is not supported."
• "Legacy clients cannot associate with a WLAN that has 802.11r enabled if the driver of the supplicant…is old and not aware of the additional AKM suites in the IE." Workaround: run two SSIDs with the same name but different security settings (FT vs. non-FT) — or clients that are 802.11r-capable can still associate as plain 802.11i if both AKM types are enabled on the WLAN.
• "To avoid any Denial of Service (DoS) attack, each Cisco WLC allows a maximum of three Fast Transition handshakes with different APs."
• "FT-SAE Over-the-DS roam is not supported in FlexConnect local authentication mode." Cisco's general recommendation is Over-the-Air FT for FlexConnect deployments.
• "In Cisco Wave 2 APs, local switching local authentication with 802.11r is not supported."
• FlexConnect local-auth FT specifically: supports Over-the-Air roaming only (no Over-the-DS); supports adaptive 11r for Apple clients; supports both FT+802.1X and FT+PSK; up to 100 APs per PMK-sharing group by default (300 in high-scale mode), 1,000 PMK entries/AP. Pre-17.2.1, local-auth FlexConnect clients couldn't use FT at all — only centrally authenticated clients could.

OKC — the non-11r fast-roam alternative, for context

Opportunistic Key Caching caches one PMK per client across APs sharing a WLAN, "even when roaming between multiple APs," and "works with WPA2-EAP as a fast roaming technique." Client support splits by vendor: "Microsoft and some Android clients support OKC," while "Apple and few Android clients support 802.11r." OKC is on by default per WLAN (okc / no okc under the WLAN); disabling it disables it even for clients that could use it. If a mixed-client SSID shows some clients fast-roaming and others doing full reauth, this split is the first thing to check — not a controller defect.

Verification

show wireless client summary                         ! shows FT-SAE role
show wireless client mac-address <mac> detail        ! "Authentication Key Management : FT-SAE"
show wireless client mac-address <mac> mobility history
show wireless pmk-cache                               ! cache type "Dot11R"
show wlan name <profile>                              ! "FT SAE : [Enabled|Disabled]"
show wireless stats client detail | sec roam           ! 11r ft auth requests, PMKR0-Name mismatch counters
show flexconnect dot11R                                ! AP-side, FlexConnect FT cache entries

802.11k — Assisted Roaming (neighbor reports)

• Restriction: "This feature is supported only on 802.11n capable indoor access points."
• Single-band WLANs advertise up to 6 neighbors; dual-band up to 12.
• "You can configure assisted roaming only using the CLI" — beyond the WLAN-level enable checkboxes, there's no GUI path for the prediction/denial tuning parameters.
• Avoid two SSIDs sharing the exact same name — Cisco calls this out as a cause of roaming issues independent of 11k.

802.11k configuration (CLI)

! Global:
wireless assisted-roaming floor-bias <5-25 dBm>        ! default 15
wireless assisted-roaming prediction-minimum <count>   ! default 3
wireless assisted-roaming denial-maximum <1-10>        ! default 5

! Per-WLAN:
wlan <wlan-id>
 assisted-roaming neighbor-list     ! 11k neighbor list — ON by default at WLAN creation
 assisted-roaming dual-list         ! dual-band list — ON by default
 assisted-roaming prediction        ! prediction-list denial feature — OFF by default

Verification: show wlan id <wlan-id> shows the neighbor-list/dual-list/prediction state per WLAN.

802.11v — BSS Transition Management

802.11v configuration (CLI)

wlan <profile-name>
 shutdown
 bss-transition
 bss-transition disassociation-imminent   ! optional — forces the transition
 no shutdown

GUI equivalents (Configuration > Tags & Profiles > WLANs > Advanced): BSS Transition (the base enable), Dual Neighbor List (includes neighbors from the AP's other radio slot — 2.4/5 GHz — in the BTM response), BSS Max Idle Service / BSS Max Idle Protected (power-save idle timer; "Protected" requires authenticated frames to reset the counter), and Directed Multicast Service (converts a multicast stream to unicast for any DMS-capable client).

802.11v prerequisites and restrictions

• "Client needs to support 802.11v BSS Transition" — there's no fallback behavior for clients that don't; a BTM request to a non-supporting client is simply ignored.
• Explicitly called out for "Apple clients like Apple iPad, iPhone…that run on Apple iOS version 7 or later."
• "Supports local mode; also supports FlexConnect access points in central authentication modes only" — BTM on a FlexConnect AP doing local authentication is not supported.

gap — no dedicated show/verification command for BSS Transition Management state appears in the 9800 17.12 config guide chapter itself; the only confirmed check is reading the WLAN's configured BTM settings back via show wlan name <profile> / show run wlan, by analogy with how OKC and assisted-roaming settings are verified elsewhere in the same guide. Treat that command as a reasonable inference, not a cited one-to-one for this specific feature.

Field recommendation inference

If a client completes an FT roam, gets deleted seconds later with an AUTH_EXPIRED-style reason, retries FT and fails with Invalid PMKID, then recovers via full 802.1X — escalate the deletion timing, not the PMKID failure. The PMKID failure is downstream, not the trigger. (This pattern was originally observed on a WLAN with no CWA involved; if you hit it on a CWA WLAN, see the Identity Services Engine section for the open questions specific to that overlap.)

Deployment & PSN sizing

Sizing is session-based, not WLC-based

Hardware & placement gotchas

• ISE appliance hardware can't be upgraded after purchase — undersizing at buy time is permanent.
• SNS-3895 is PAN/MnT-only; using it as a PSN gives "no additional value" per Cisco.
• Only 2 MnT nodes are supported total — no horizontal MnT scaling.
• PAN auto-failover needs 3+ nodes; a health-check node per site if PANs split across data centers.
• Mismatched ISE versions between PAN and a joining node blocks registration outright.

9800-side pairing gotchas

• Mobility MAC defaults to chassis base MAC; in HA SSO pairs, set it manually or it changes on failover and silently breaks mobility tunnels.
• N+1 is not HA SSO — SSO is a same-chassis stateful pair, N+1 is AP site-tag failover to a separate standby. Different mechanisms, often conflated.
• On a Catalyst-Center-managed 9800, manual CLI changes get silently overwritten on the next provisioning sync.

Central Web Authentication (CWA)

Redirect ACL logic — the core mechanism

Correct ACL shape

ip access-list extended REDIRECT
 deny ip any host <ISE-IP>
 deny ip host <ISE-IP> any
 deny udp any any eq domain
 deny udp any eq domain any
 permit tcp any any eq 80

Deny traffic to ISE PSNs and DNS; permit the rest to redirect. Skip the DNS/ISE exemptions and you get a redirect loop.

The AireOS trap

FlexConnect caveat

For locally-switched APs, the controller swaps every permit/deny when pushing the ACL to the AP. The AP-local view (show ip access list) looks inverted relative to the WLC side — expected, not corruption.

Most common real failure

SANET_AUTHZ_FAILURE - Redirect ACL Failure
Failed attribute name REDIRECT

Verifying the redirect

show wireless client mac-address <mac> detail   (ACL under "Server Policies")
show ip access list                               (AP CLI, FlexConnect only)
debug wireless mac <mac> monitor-time <sec>

unconfirmed — show ip access-lists (plural, WLC-side) with hit counters for this specific flow is a standard IOS-XE command that almost certainly works, but no CWA-specific doc spells out this exact use.

CWA doesn't support PSN load balancing

Is combining 802.11r FT with CWA on one WLAN supported?

FT + CWA open documentation gaps — confirmed unresolved across two research passes

If you hit this combination in the field: a client completes an FT roam, gets deleted seconds later with an AUTH_EXPIRED-style reason, retries FT and fails with Invalid PMKID, then recovers via full 802.1X and lands in CWA — escalate the deletion timing, not the PMKID failure or the portal timeout. See the Roaming: Fast Transition section for the pure FT mechanics behind this pattern.

For symptoms that look random, hit different users unpredictably, and resist reproduction — work this list in order.

1. RADIUS/AAA health, WLC side

• Client exclusion when the server returns a VLAN/ACL name that doesn't exist locally.
• EAP timeout from dot1x timeout / retry windows — often client/driver-side, not server-side.
• debug wireless mac <addr> monitor-time <N> elevates one MAC to debug across every process.

2. ISE-side signals

• A node out of sync with the Primary Admin node delays Application Server init (normally 15–35 min).
• Self-signed/untrusted ISE certs show as "Alert (Level: Fatal, Description: Certificate Unknown)" in captures.
• Check per-node CPU/latency/memory before assuming a logic bug.

3. Infrastructure signals mistaken for wireless

• DHCP Required mismatch across foreign/anchor controllers → stale IP retained across a roam → NAK.
• Internal 9800 DHCP defaults to an infinite lease — can quietly exhaust the pool.
• VLAN/trunk or FlexConnect native-VLAN mismatch explains behavior that's fine at some sites, broken at others.

4. Standard correlation method

Controller:  RadioActive trace by client MAC + exact timestamp
AP:          AP-side client debug (bundle collector)
ISE:         Live Logs for the same MAC/timestamp

TAC's first ask is always the same: exact reproduction timestamp, client MAC/IP/username/session ID, and a trace captured live — continued logging overwrites debug buffers, so this can't be reconstructed after the fact.

The architecture inverts the usual model

Guest / web auth splash types

• Click-through — acknowledgment only, no credentials.
• Sign-on — via Meraki auth, RADIUS, LDAP, AD, or Google/Entra. With Sign-on + RADIUS, the client's credentials route through the Meraki Cloud Controller, which issues the Access-Request to the external server (e.g. ISE) — the cloud is in the auth path, not the local AP.

802.1X / MAB with ISE

The RADIUS test tool has a specific blind spot

Dashboard's built-in RADIUS test triggers an EAP-PEAP/MS-CHAPv2 exchange to confirm reachability and credentials. It fails for EAP-TLS every time, because the test has no client certificate to present — that failure means nothing about whether real EAP-TLS clients will work. Test those with an actual device.

Connectivity requirements & "unreachable" alerts

An "unreachable device" alert means the device was online and has stopped talking to the cloud — Dashboard's guided workflow: check the Meraki Status page, identify the upstream neighbor, packet capture, cable/LED/power check, local status page, support data bundle, reboot as last resort.

Live Tools — and the one that doesn't exist on MR

Monitor > Access Points > Tools: Ping (to client or AP), ARP table, Traceroute, Dashboard throughput test (AP↔dashboard only, not internet), blink LEDs, reboot, splash page test.

No internet access — AP itself vs. a specific client

DHCP failures — Bridge mode vs. NAT mode

Mixed Meraki + Catalyst 9800 fleets

inference — two assumptions that don't carry over between platforms: 9800 CLI diagnostics (show wireless client, CAPWAP state) have no Meraki equivalent at all — everything is Dashboard Live Tools or API; and CoA port convention isn't shared either, since MR explicitly uses 1700/3799 while 9800/IOS-XE configures its own CoA listener.

RAP, MAP, and the backhaul protocol

The join sequence has an extra step

On a 9800, Ethernet-connected MAPs get MAC-authorized during a normal CAPWAP join — same as any indoor AP. A wirelessly-joining MAP is only authorized once it secures an AWPP link to its parent. The backhaul link has to exist before controller authorization completes, which indoor wired-join APs never have to do.

Bridge Group Name — the most common connectivity cause

Limits and timers worth knowing cold

Why hop count matters more than it sounds like it should

Hop count isn't just added latency — it's a throughput multiplier against the whole backhaul. A client two hops out getting 5 Mbps can be consuming 40 Mbps of total backhaul capacity to deliver it. CAPWAP encapsulation itself costs up to 15% throughput on top of that.

Backhaul interference indoor troubleshooting doesn't prepare you for

• Weather radar occupies 5600–5650 MHz (channels 124/128) and triggers DFS "quiet"/"silent" mode — a mesh link that drops specifically on those channels isn't a config problem.
• Collocated mesh nodes need physical separation — 10 ft vertical or 100 ft horizontal — to avoid self-interference between the node's own radios.

Backhaul up with decent SNR, but link rate/throughput is still bad

How RF data becomes a location

inference — Cisco Spaces reads as CMX's cloud-hosted evolution: the 9800's own config chapter is titled "Cisco Spaces," but every command inside it still says cmx. Not a direct Cisco statement, but the naming is hard to read any other way.

Accuracy add-ons — and what they actually require

Turning on cloud Cisco Spaces from a 9800

nmsp cloud-services enable
! configure DNS resolution
crypto pki trustpool import         ! import Root CA certs
! optionally configure an HTTP proxy
! then register, and set:
nmsp cloud-services server url <url>
nmsp cloud-services server token <token>

For on-prem CMX instead: NMSP (TCP port 16113) must be open between the controller and the CMX appliance. show nmsp status verifies the connection either way.

Cisco Spaces licensing tiers

Cisco Spaces Connector

RMI and RP — the link that has to be right

Split-brain is a named, documented condition

Verification commands

show romvar                              ! exact HA config: CHASSIS_HA_REMOTE_IP,
                                          !   CHASSIS_HA_LOCAL_IP, CHASSIS_HA_IFNAME, CHASSIS_HA_IFMAC
show chassis                             ! chassis state (caveat below)
show redundancy                          ! active/standby box details
show redundancy switchover history       ! switchover count, reason, timestamp
show wireless stat redundancy summary    ! AP recovery duration (ms), SSO HA sync timer expired
test wireless redundancy packetdump start
test wireless redundancy rping

Device# show redundancy states
my state = 13 -ACTIVE
peer state = 8  -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 1
Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Manual Swact = enabled
Communications = Up

What a clean SSO actually preserves

What does not survive a switchover, documented explicitly: clients not yet in RUN state are removed, and purged entirely after 300 seconds if they haven't reconnected; NBAR flow state in local mode is lost; AVC flow context must be relearned; voice calls can't be recognized post-switchover because RTP/RTCP-based policy breaks; TCP sessions must re-establish; statistics tables aren't synchronized at all.

N+1 — a terminology gap, now resolved with sourced nuance

Documented failover logic: an AP always returns to its primary once that controller is available again. Tertiary is only used if both primary and secondary are down, and if secondary recovers while primary is still down, the AP stays on tertiary — there's no mid-outage fallback to secondary.

show ap filters all type priming
show ap filters active type priming
show wireless profile ap priming summary
show wireless profile ap priming all
show ap name <ap-name> config general | sec Priming   ! Priming Profile, Override, Source (MAC/FILTER/NONE)

That last command is the one that actually answers "why didn't this AP fail over as expected" — it shows whether the AP received the priming configuration at all.

Root causes Cisco documents

• Active and standby must run the same mode (Install or Bundle) and the same image version. Auto-upgrade exists specifically to handle "one of the redundancy port is upgraded to a newer version, and the other one is not upgraded at the same time."
• Mismatched wireless trustpoints — same name, different keys — prevent the trustpoint from coming up after SSO forms.
• Don't enable hyper-threading on HA VMs: "HA keepalives are lost, and a stack merge may occur."
• VM snapshots of HA hosts are unsupported and can crash the controller.

Exclusion categories and their fixed thresholds

Why this gets misdiagnosed as an active failure

Device# show wireless exclusionlist client mac 12da.4820.cce9 detail
Client State : Excluded
Client MAC Address : 12da.4820.cce9
Client IPv4 Address: 20.20.20.6
Exclusion Reason : IP address theft
AP Name: charlie2
Wireless LAN Name: mhe-ewlc
VLAN Id : 20

The failure pattern worth knowing by heart: fixed threshold → timed exclusion → client retries once the timer expires → same threshold trips again. From the outside this looks exactly like a continuous, unresolved auth failure. It is not currently failing — it's cycling through a timeout. inference, consistent with the documented mechanics above but not a named Cisco troubleshooting pattern in any single source found.

Rogue classification

show wireless wps rogue ap summary
show wireless wps rogue ap detailed <mac>
show wireless wps rogue ap {friendly|malicious|unclassified|custom} summary
show wireless wps rogue client summary
show wireless wps rogue adhoc summary
show wireless wps rogue containment summary
show wireless wps rogue rule summary

Containment has a documented exception and a hard restriction

The single error code that hides four different causes

Machine vs. user auth ordering (EAP chaining / TEAP)

Client-side certificate trust

The WLC-side signature for a client that never responds is unambiguous: DOT1X-5-FAIL with reason (Timeout), repeated Retrying (count 3) method dot1x, ending in CO_CLIENT_DELETE_REASON_CONNECT_TIMEOUT. Cisco's own remediation text for this exact scenario reads: "Ensure wireless client trust RADIUS' certificate" — stated as a client-side action item, not a server fix.

ISE's own error 5440 corroborates from the other side: "the endpoint supplicant does not complete the EAP authentication within the configured timeout," logged as "ISE sending 'Access-Challenge' but ISE didn't receive any response." ISE did its job; the client went silent. The same abandonment pattern — "Endpoint <MAC> abandoned EAP session <session-id> and started EAP session" — recurs as a named, numbered event across independent Cisco troubleshooting documents, not an ad hoc string.

Localizing the fault from the 9800 side

debug wireless mac <mac> monitor-time <seconds>      ! default 1800s
more bootflash:ra_trace_MAC_<mac>_*.log
show wireless client mac-address <mac> detail | inc Policy Profile
show logging profile wireless internal filter

Cisco's own distinction, stated directly: an EAP timeout (client never answers) is client-side; "ACL acl-sent-by-ise is missing in configuration for mac" or an EPM VLAN plug-in conflict — "the ACL/VLAN sent by the RADIUS server does not exist on 9800 WLC" — is server-side. That single line is the fastest way to know which team to involve before escalating.

Policy Manager State: Run
Last Policy Manager State : IP Learn Complete

The decision rule for not escalating prematurely

ISE's own 5440 troubleshooting methodology states it plainly: test the same NAD/PSN/policy against a known-good endpoint, and if only certain endpoints fail, "focus the investigation on the endpoint configuration or supplicant." Combined with the WLC-side timeout+deauth signature above, that's the documented basis for keeping an issue on the endpoint rather than routing it to the RADIUS/ISE team.

IGMP snooping doesn't stop at the controller

IGMPv1/MLDv1 snooping is fully supported; IGMPv2/v3 support is explicitly documented as "limited" — if the upstream switch doesn't recognize IGMPv3, hosts simply don't get traffic.

show wireless multicast
show wireless multicast group summary
show wireless multicast [source <src>] group <grp> vlan <vlanid>
show ip igmp snooping wireless mgid
show ip igmp snooping igmpv2-tracking
show wireless profile policy detail <policy-profile>    ! Multicast VLAN, Multicast Filter field

DTIM interval — a documented, hard recommendation

Multicast-to-unicast conversion — a real platform split

mDNS/Bonjour — cross-VLAN failure is by design

mDNS uses link-local multicast (224.0.0.251 / UDP 5353), which Cisco states plainly is "only forwarded to the local Layer 2 network." A printer or AirPlay device not discoverable across VLANs is expected behavior, not a defect — the 9800 mDNS Gateway exists specifically to bridge this via caching and service policies. mDNS AP (flood-and-learn, CAPWAP-tunneled) caps at 10 wired VLANs, supports Local/Monitor mode only, IPv4-only for wired providers, and stale wired cache entries can persist up to 4500 seconds.

show mdns-sd summary
show mdns-sd cache
show mdns-sd cache wired
show mdns-sd cache type {PTR|SRV|A-AAA|TXT}
show mdns-sd statistics
show mdns-sd ap

Metal policies, not classic AC names

show wireless client mac-address <mac> detail
show wireless client summary
show policy-map interface wireless <ap> input
show wireless profile policy detailed <name>    ! QBSS Load status
show dot11 qos                                    ! AP-side
show controllers dot11Radio 1 | begin EDCA         ! AP-side

Call Admission Control — a real documentation gap between platforms

The untrusted uplink problem, in two distinct forms

Cisco's documented 5-step verification: capture at the source, check every intermediate switch config, capture before and after each switch plus at the WLC and the destination, simulate the path, then cross-check against the 9800 best-practice document. Current trust-boundary commands on 9000-series: trust device <type>, auto qos trust {cos|dscp}, auto qos voip {cisco-phone|cisco-softphone|trust}, verified via show auto qos and show policy-map interface. An untrusted/mismatched peer causes both CoS and DSCP to reset to 0.

Troubleshooting order — stated plainly as a synthesis

Checking sync state

show ntp status          ! "Clock is synchronized, stratum 2, reference is 10.4.2.254"
show ntp associations    ! * = synced/configured, # = selected but unsynced
show clock detail

A clock divergence beyond roughly 4000 seconds from the reference is Cisco's own documented threshold for flagging a real problem.

Router> show clock detail
15:29:03.158 PST Tue Feb 25 2003
Time source is NTP

The one confirmed syslog tie-in

%PKI-3-CERTIFICATE_INVALID_EXPIRED: Certificate chain validation has
  failed. The certificate (SN: [chars]) has expired. Validity period
  ended on [chars]
  Recommended Action: Check the system clock to see if its set correctly

%PKI-3-CERTIFICATE_INVALID_NOT_YET_VALID: Certificate chain validation
  has failed. The certificate (SN: [chars]) is not yet valid
  Validity period starts on [chars]
  Recommended Action: Check the system clock to see if its set correctly

Shared NTP source — this one is directly documented

A correction worth flagging: APs are not necessarily a single point of failure

Two separate trust chains

unconfirmed — no Cisco document directly compares the CAPWAP (AP↔controller) and EAP-TLS (client↔ISE) PKI chains side by side. That they are architecturally separate and independently validated is correct X.509/CAPWAP theory, not something found stated in a single Cisco source.

ISSU requires a real HA pair — there's no standalone fallback

The process flow and what to monitor

Image syncs to standby → AP predownload (no service impact) → standby reloads to the new version first while the active continues serving on the old version, forming a temporary mixed-version SSO pair → switchover (the upgraded unit becomes active) → former active reloads to match → staggered AP rejoin cycle → install commit.

show issu state detail      ! primary monitor; shows state transitions and abort-timer countdown
show redundancy              ! Active/Standby roles, "Communications = Up", peer "STANDBY HOT"
show install summary         ! I/U/C/D package flags, abort-timer status
show chassis rmi
show ap image                ! AP predownload tracking

Rollback — default timer and real triggers

install commit                      ! persist the upgrade
install abort issu                   ! manual rollback — pre-commit only
install auto-abort-timer stop        ! disables the timer; still requires a manual commit later

Confirming a supported path before you start

ISSU is supported EM-to-EM within the same train, not more than three years apart, and within any release of the same EM. Not supported: cross-major-train moves (16.x→17.x, 17.x→18.x), SM-to-EM or EM-to-SM moves, special/engineering images, LDPE↔NPE moves, downgrades, and a hard break at 27.1.1 with no ISSU path into it from any prior release. There is no live show issu capability command — Cisco publishes a static compatibility matrix instead, which has to be checked as a lookup, not queried from the CLI. show issu state detail's system check only validates runtime readiness, not version-pair eligibility — passing that check does not mean the version pair is actually supported.

AP-side behavior — even "successful" ISSU involves a rejoin

What an AP gives up when it's underpowered

AP-side LED signature for underpower — confirmed, documented

Reading the switch-side power state — per port

show power inline detail
show platform software ilpower system 1
show environment all
show environment power

Key fields: Device Detected, Device Type, Connection Check, IEEE Class (Alt-A/B), discovery mechanism ("Ieee and Cisco"), Power Allocated vs. actual consumption, and fault counters — Absent, Over Current, Short Current, Invalid Signature, and critically, Power Denied. A nonzero Power Denied counter plus an operational state of "off" is the documented signature of a port that asked for power and didn't get it.

Reading the switch-side power state — the whole chassis/stack budget

show power inline                      ! per-module Available/Used/Remaining (Watts), Catalyst 9300
show power                             ! chassis-level System Power / Inline Power totals, Catalyst 9400
show env power switch [switch-number]  ! internal PSU status per stack member

Catalyst 9300 example fields: a module row reading 3 1310.0 660.0 650.0 under Available / Used / Remaining (Watts) headers. Catalyst 9400 chassis-level show power shows paired totals like System Power 3505 3505 and Inline Power 0 9295.

PSU redundancy mode — a direct tradeoff against usable PoE budget

Planning the budget before you rack anything

CDP/LLDP negotiation — the silent failure mode

The TAC troubleshooting split

Cabling: 100m max total run including patch panels, with cutoff power calculated as rated PD consumption plus worst-case cable power loss. UPOE requires Class D or better cabling; 802.3bt requires Category 5e or above. Cisco documents cable category/quality, not a shorter max length, as the lever at higher power classes. Diagnostics: show post, platform-specific DiagPoETest/TestPoE, debug ilpower event/controller/powerman.

Trunk vs. access port — what's actually documented for AP uplinks

802.1Q native VLAN — the documented mismatch symptom isn't what most engineers expect

Why the untagged VLAN matters for AP join specifically

When no client VLAN is explicitly configured for a policy profile, Cisco documents that "the AP native VLAN is used" — so an AP sitting on the wrong native/untagged VLAN doesn't throw a clean "wrong VLAN" error. It silently loses IP reachability to the controller, and the symptom shows up as a stuck or endlessly-retrying CAPWAP discovery, which is easy to misroute to an AAA/RADIUS investigation that was never going to find anything. Rule out the native VLAN before escalating a join failure as an authentication problem.

Verification commands — confirmed field names

show interfaces interface-id trunk      ! trunk config, allowed/active VLANs
show interfaces interface-id switchport ! Administrative Mode, Trunking Native Mode VLAN, Trunking VLANs Enabled
show vlan                               ! confirms the VLAN actually exists in the database

unverified — show vlan brief is standard IOS-XE syntax and almost certainly works, but wasn't quote-confirmed against a fetched Cisco page this pass; the three commands above are the ones with confirmed exact field names.

CDP/LLDP automatic VLAN assignment for APs — not documented, don't assume it

Mobility groups — still the live mechanism on IOS-XE, not an AireOS holdover

! Set the local group name and mobility MAC (do this before adding peers)
wireless mobility group name Mygroup
wireless mobility mac-address AAAA.BBBB.CCCC

! Add a peer controller to the group (9800-to-9800)
wireless mobility group member mac-address 001E.BD0C.5AFF ip 9.12.32.10 group test-group data-link-encryption

! 9800-to-AireOS peer (entered on the 9800 side)
wireless mobility group member mac-address 001E.BD0C.5AFF ip 9.12.32.10 group test-group

show wireless mobility summary          ! Mobility Group Name, MAC, Keepalive Interval/Count, Domain ID, per-peer status
show run | i mobility                   ! confirm the mobility MAC is actually saved in the running config

The documented symptom of a mismatched mobility group

Anchor vs. foreign — current 9800 terms and CLI

! FOREIGN controller (WLAN-based, non-wired guest)
wireless profile policy anchor-policy
 mobility anchor 10.88.173.105 priority 3
 no shutdown
wireless tag policy PT1
 wlan anchor-ssid policy anchor-policy

! ANCHOR controller (profile name must match the foreign side exactly)
wireless profile policy anchor-policy
 mobility anchor
 vlan 29
 no shutdown

Wired guest-LAN variant (same anchor/foreign split, different commands)

! FOREIGN side — wired VLAN is configured only here
guest-lan profile-name gstpro-1 1 wired-vlan 25
 no security web-auth              ! for open auth

! ANCHOR side — no wired-vlan parameter; VLAN comes from the policy profile
guest-lan profile-name testpro-2 1

documented restriction: "Ensure that the Anchor VLAN ID and the wired VLAN ID configured on the Foreign controller is not the same." Also capacity limits: "A maximum of five guest LANs are supported on the foreign controller," "A maximum of 2000 clients per foreign are supported," and "You can map only one wired VLAN to a guest LAN" / "only one guest LAN to one policy profile."

Verifying anchoring is actually happening

show wireless mobility summary
show wireless client summary                               ! on foreign: client shows up here
show wireless client mac-address <mac> detail                ! look for:
                                                             !   Mobility Role : Export Foreign
                                                             !   Mobility Roam Type : L3 Requested
show wireless config validate                               ! surfaces VLAN/guest-LAN mismatches directly, e.g.:
                                                             !   "Error in No record found for VLAN 9,
                                                             !    needed by Guest-LAN open-wired"

Separately documented and easy to misdiagnose as "anchoring doesn't work": if an AP physically moves between controllers that are mobility peers of each other, a client can "remain anchored" to the original controller. The documented fix is "remove the mobility peer configuration from that controller" — not to chase the anchor config itself.

The mobility tunnel — CAPWAP on IOS-XE, not EoIP

Mobility tunnels have two platform-specific restrictions worth knowing before troubleshooting a cert error: "Mobility tunnels do not support ECDSA-based certificates or ECDSA-based trustpoints," and 9800-CL peers using self-signed certs need an additional SSC hash validation step.

Tunnel health — verification and documented failure signatures

show wireless mobility summary                 ! Mobility Group Name, MAC, Keepalive Interval/Count,
                                                 !   Domain Identifier, per-peer IP/Public-IP/Group/Status/PMTU
show wireless mobility peer ip <peer-ip>         ! single-peer detail
show wireless mobility ap-list                  ! APs known to the mobility group
show wireless stats mobility                    ! event stats, handoff status (incl. "Group mismatch"),
                                                 !   export anchor/foreign counters, L2/L3 roam counts
show wireless stats mobility messages           ! per-message-type Tx/Rx counters
show wireless management trustpoint             ! cert hash, for peer validation issues
show crypto pki trustpoints

FlexConnect — local vs. central switching

Standalone mode — what happens when the WAN/controller link drops

FlexConnect ACLs, VLAN mapping, and the site-tag model

wireless profile flex Flex-profile-1
 acl-policy ACL1
 native-vlan-id 25
 vlan-name VLAN0169
  vlan-id 169
  acl ACL1

wireless tag site default-site-tag
 no local-site                     ! must be set before configuring flex-profile — this is what
                                    !   actually puts the AP in FlexConnect mode
 flex-profile rr-xyz-flex-profile
 ap-profile xyz-ap-profile

show wireless tag site summary
show ap tag summary
show ap name <ap-name> tag info

Split tunneling and DNS during web authentication

Field triage — common failure modes

The CLI isn't just "older" — it's a different shape

The config model itself is restructured, not just renamed

AireOS binds a WLAN directly to a VLAN interface, with AP Groups remapping that WLAN-to-VLAN binding per site. The 9800 decouples the same idea into five pieces: WLAN Profile (SSID/L2 security) + Policy Profile (VLAN/ACL/QoS) + Policy Tag (binds the two) + RF Tag + Site Tag + AP Join Profile. Changing any tag forces an AP rejoin — a side effect that surprises engineers used to AireOS's more direct model.

Debugging works completely differently

Mobility Express is not the same thing as the 9800's EWC

Primary AP election and failover

Election priority, in order: a pinned "User Defined Master" > "Next Preferred Master" > highest-capability hardware > lowest client load > lowest MAC address. Mechanism is VRRP under the hood. No consolidated ME-vs-full-WLC feature parity table exists on Cisco.com — that gap is confirmed, not just unresearched; don't assume one platform's feature set carries over to the other without checking the specific feature.

EOL dates and the IRCM migration path

Migration path runs through the Technology Migration Program toward 9800-40/9800-CL. For mixed-fleet transitions, IRCM (Inter-Release Controller Mobility) lets AireOS and 9800 roam together — always treated as L3 — over a Secure Mobility Tunnel (UDP 16666/16667), replacing the older unencrypted AireOS-only EoIP tunnel.

Web GUI won't load / management access blocked

Mobility groups — the legacy AireOS model

Rough command translation

debug client <mac>        →  debug platform condition feature wireless mac <mac>
                                  debug platform condition start
save config                 →  write memory
AP Groups                   →  Policy Tag + Site Tag + RF Tag (structural, not a rename)

unconfirmed — no Cisco source directly pairs show client detail against show wireless client mac-address detail as an equivalence. Treat that mapping as reliable general knowledge, not a cited one-to-one.

Observed pattern

1. Client completes an 802.11r FT roam successfully, reaches RUN state.
2. About three seconds later, the controller deletes the client with an AUTH_EXPIRED-family reason — despite the client having been fully associated.
3. About one second after that, the client retries FT and fails with Invalid PMKID — downstream of the deletion, not the cause.
4. Client recovers via a fresh full 802.1X association.
5. Client later stalls in CWA / WEBAUTH_REQUIRED and times out.

Why this is worth escalating