When an endpoint cannot authenticate, the switch holds all the diagnostic evidence you need. The question is which commands expose that evidence and how to read the output without chasing red herrings. This article covers the full diagnostic toolkit available on a Cisco Catalyst 9300 running IOS XE 17.9.x, using Cisco ISE 3.2 as the RADIUS server.
Before running any debug, understand that debug dot1x and debug radius generate significant console output on a busy switch. Always redirect output to a buffer or a terminal monitor session, and limit debug to specific interfaces whenever the command syntax allows. In production, enable debugs during a maintenance window or on a test port unless the situation demands otherwise.
The Primary Diagnostic: show authentication sessions
show authentication sessions is the first command to run. It gives a table-level view of every port currently tracked by the 802.1X state machine.
SW1# show authentication sessions
Interface MAC Address Method Domain Status Session ID
Gi1/0/1 a4b1.c2d3.e4f5 dot1x DATA Auth 0A00630A0000001B
Gi1/0/2 001e.7a3b.9c12 mab DATA Auth 0A00630A0000001C
Gi1/0/3 0050.56b3.11aa dot1x DATA Unauthorized 0A00630A0000001D
Gi1/0/4 0000.0000.0000 N/A N/A No Auth N/A
Gi1/0/5 001e.7a3b.9c55 dot1x VOICE Auth 0A00630A0000001F
Column meanings:
- Interface — the physical port
- MAC Address — learned MAC of the endpoint. All-zeros means no supplicant has been detected.
- Method —
dot1x,mab, orwebauth - Domain —
DATAorVOICE(relevant in multi-domain auth mode — see Article 13: 802.1X Authentication Host Modes and Article 17: 802.1X with IP Phones) - Status —
Auth(authorized),Unauthorized,No Auth(no attempt made),Authz Failed - Session ID — used to correlate with ISE live logs; the hex string encodes the switch IP and a session counter
A port showing Unauthorized means authentication has been attempted and failed, or is still in progress. A port showing No Auth means the switch has not received any EAPOL frames and no MAB fallback has triggered yet.
Drilling Into a Single Port
SW1# show authentication sessions interface GigabitEthernet1/0/3 details
Interface: GigabitEthernet1/0/3
MAC Address: 0050.56b3.11aa
IPv6 Address: Unknown
IPv4 Address: Unknown
User-Name: host/CORP-PC-07.corp.local
Status: Unauthorized
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecured
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0A00630A0000001D
Acct Session ID: 0x00000022
Handle: 0xE3000013
Current Policy: POLICY_Gi1/0/3
Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
Server Policies:
Method status list:
Method State
dot1x Authc Failed
mab Authc Failed
This output tells you everything about the port's current state. Pay attention to:
- User-Name — this is the identity string sent to RADIUS. For EAP-TLS and PEAP, it is the machine or user principal name. If this field is blank, the supplicant is not sending credentials.
- Status: Unauthorized combined with dot1x: Authc Failed and mab: Authc Failed — both methods have been tried and rejected. The switch is not waiting; it has already made a determination.
- Server Policies — empty. This means ISE sent no authorization attributes (no VLAN, no dACL). Either ISE rejected the request or the switch never successfully reached ISE.
Reading the Method Status List
The method status list shows every method attempted in order. Common states:
| State | Meaning |
|---|---|
Running |
Currently attempting authentication |
Authc Success |
Credentials accepted by RADIUS |
Authc Failed |
RADIUS returned Access-Reject |
No Response |
Supplicant did not respond to EAP challenge |
Stopped |
Method was abandoned (e.g., timeout) |
If dot1x shows No Response and mab shows Authc Failed, the endpoint is not running a supplicant and its MAC is not in ISE's endpoint database. That is a different problem from dot1x: Authc Failed, which means the supplicant ran but credentials were wrong or the certificate was rejected.
show dot1x all
SW1# show dot1x all
Sysauthcontrol Enabled
Dot1x Protocol Version 3
Critical Recovery Delay 100
Critical EAPOL Disabled
Interface GigabitEthernet1/0/3
------------------------------------
Dot1x Info for GigabitEthernet1/0/3
-----------------------------------
PAE = AUTHENTICATOR
PortControl = AUTO
ControlDirection = Both
HostMode = MULTI_AUTH
ReAuthentication = Disabled
QuietPeriod = 60
ServerTimeout = 30
SuppTimeout = 30
ReAuthPeriod = 3600 (Locally configured)
ReAuthMax = 2
MaxReq = 2
TxPeriod = 30
RateLimitPeriod = 0
Use this command to verify that 802.1X is globally enabled (Sysauthcontrol: Enabled) and to confirm per-port timer values. If TxPeriod is at the default of 30 seconds and the switch has to send two EAP-Request/Identity frames before giving up, that is 60 seconds of delay before MAB fallback starts. In environments with non-supplicant devices, tuning TxPeriod down to 10 seconds dramatically reduces connectivity delays.
show ip access-lists and show authentication sessions (dACL Verification)
When ISE pushes a downloadable ACL, verifying that it applied correctly requires two commands in sequence.
SW1# show authentication sessions interface GigabitEthernet1/0/1 details | include Filter-Id|ACS
ACS ACL: xGENTLEMAN-ACL-12345678
SW1# show ip access-lists xGENTLEMAN-ACL-12345678
Extended IP access list xGENTLEMAN-ACL-12345678
10 permit tcp any any eq 80 (3412 matches)
20 permit tcp any any eq 443 (18903 matches)
30 deny ip any any (14 matches)
If the ACL name appears in the session details but the ACL itself does not exist, the switch received the attribute but failed to create the list — a known issue when the RADIUS attribute format is wrong. See Article 24: dACL Not Applying Correctly in 802.1X for the full diagnostic sequence.
debug dot1x all
Enable only after reviewing show output. On an access switch with 48 active ports, debug dot1x all is noisy. If possible, use:
SW1# debug dot1x all
Then unplug and replug the problematic endpoint to trigger a fresh authentication cycle. The output from a successful PEAP exchange looks like this:
*Mar 19 14:22:01.441: dot1x-ev(Gi1/0/3): New client 0050.56b3.11aa on interface
*Mar 19 14:22:01.442: dot1x-sm(Gi1/0/3): Posting EAPOL_START for 0050.56b3.11aa
*Mar 19 14:22:01.443: dot1x-ev(Gi1/0/3): Sending EAP-Request/Identity to 0050.56b3.11aa
*Mar 19 14:22:01.891: dot1x-ev(Gi1/0/3): Received EAP-Response/Identity from 0050.56b3.11aa
*Mar 19 14:22:01.892: dot1x-sm(Gi1/0/3): Posting RX_REQ for 0050.56b3.11aa
*Mar 19 14:22:01.893: dot1x-ev(Gi1/0/3): Sending RADIUS request for 0050.56b3.11aa
*Mar 19 14:22:02.105: dot1x-ev(Gi1/0/3): Received RADIUS Access-Challenge
*Mar 19 14:22:02.106: dot1x-ev(Gi1/0/3): Sending EAP-Request to 0050.56b3.11aa (PEAP)
*Mar 19 14:22:02.844: dot1x-ev(Gi1/0/3): Received EAP-Response from 0050.56b3.11aa
*Mar 19 14:22:03.211: dot1x-ev(Gi1/0/3): Received RADIUS Access-Accept
*Mar 19 14:22:03.212: dot1x-ev(Gi1/0/3): Authorization succeeded for 0050.56b3.11aa
*Mar 19 14:22:03.213: dot1x-sm(Gi1/0/3): Posting AUTHC_SUCCESS for 0050.56b3.11aa
A failed authentication ends with an Access-Reject:
*Mar 19 14:25:11.772: dot1x-ev(Gi1/0/3): Received RADIUS Access-Reject
*Mar 19 14:25:11.773: dot1x-sm(Gi1/0/3): Posting AUTHC_FAIL for 0050.56b3.11aa
*Mar 19 14:25:11.774: dot1x-ev(Gi1/0/3): Authentication failed for 0050.56b3.11aa
The key distinction: Access-Reject means ISE deliberately denied the request. If you see no RADIUS reply at all — only the initial send — the issue is network reachability between the switch and ISE, not a policy mismatch.
debug radius
debug radius shows the raw RADIUS exchange, including attribute values sent and received. This is essential when the authentication succeeds at the EAP level but VLAN assignment or dACL application fails.
SW1# debug radius
*Mar 19 14:30:05.112: RADIUS(0000001D): Send Access-Request to 10.0.0.10:1812 id 43
*Mar 19 14:30:05.113: RADIUS: authenticator 3F A1 2B 9C 4D 11 77 E2 ...
*Mar 19 14:30:05.113: RADIUS: User-Name [1] 25 "host/CORP-PC-07.corp.local"
*Mar 19 14:30:05.113: RADIUS: NAS-IP-Address [4] 6 10.0.99.1
*Mar 19 14:30:05.113: RADIUS: NAS-Port [5] 6 50003
*Mar 19 14:30:05.113: RADIUS: Called-Station-Id [30] 19 "10.0.99.1:Gi1/0/3"
*Mar 19 14:30:05.113: RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
*Mar 19 14:30:05.113: RADIUS: EAP-Message [79] 8 ...
*Mar 19 14:30:05.339: RADIUS(0000001D): Received from id 43 10.0.0.10:1812
*Mar 19 14:30:05.339: RADIUS: Access-Accept [2] ...
*Mar 19 14:30:05.339: RADIUS: Tunnel-Type [64] 6 VLAN [13]
*Mar 19 14:30:05.339: RADIUS: Tunnel-Medium-Type [65] 6 802 [6]
*Mar 19 14:30:05.339: RADIUS: Tunnel-Private-Group-ID [81] 4 "10"
*Mar 19 14:30:05.339: RADIUS: Class [25] 44 ...
When you see Access-Accept with Tunnel-Private-Group-ID: "10", the switch received the VLAN 10 assignment. If the port still ends up in the wrong VLAN, the issue is in how the switch applies the attribute, not what ISE sent. Check that authentication event fallback commands are not overriding the dynamic assignment.
If the debug shows no reply from 10.0.0.10, run show radius server-group all and ping 10.0.0.10 source vlan 99 to verify basic reachability. See Article 22: RADIUS Server Unreachable in 802.1X for the full reachability diagnostic.
debug aaa authentication and debug aaa authorization
When ISE accepts authentication but no policy attributes arrive, debug the AAA layer:
SW1# debug aaa authentication
SW1# debug aaa authorization
*Mar 19 14:35:02.441: AAA/BIND(0000001D): Bind i/f GigabitEthernet1/0/3
*Mar 19 14:35:02.442: AAA/AUTHEN/802.1X(0000001D): Method=ISE_SERVERS
*Mar 19 14:35:02.443: AAA/AUTHEN(0000001D): status = PASS
*Mar 19 14:35:02.444: AAA/AUTHOR/802.1X(0000001D): Method=ISE_SERVERS
*Mar 19 14:35:02.445: AAA/AUTHOR(0000001D): status = PASS
*Mar 19 14:35:02.445: AAA/AUTHOR/802.1X: Processing AV tunnel-type
*Mar 19 14:35:02.445: AAA/AUTHOR/802.1X: Processing AV tunnel-medium-type
*Mar 19 14:35:02.445: AAA/AUTHOR/802.1X: Processing AV tunnel-private-group-id = 10
If the AAA authorization debug shows status = PASS but no AV pairs follow, ISE's authorization rule matched a result profile that returns no VLAN. Navigate to ISE at Policy > Policy Sets > [Your Policy Set] > Authorization Rules and confirm the matched rule has an authorization profile with VLAN attributes populated.
show radius server-group and show radius statistics
SW1# show radius server-group all
Server group radius
Sharecount = 1 sg_unconfigured = FALSE
Type = standard
Deadtime(s) = 0
Server(10.0.0.10:1812,1813)
State=ACTIVE Dead time remaining(s)=0
Platform State=ACTIVE
SW1# show radius statistics
Auth. Rqst Sent: 14823
Auth. Rqst Timeouts: 12
Auth. Rqst Retransmit: 12
Auth. Rsp Received: 14811
Auth. Rsp Authenticat: 14811
A high ratio of timeouts to requests indicates intermittent reachability to ISE. Twelve timeouts out of nearly 15,000 requests is acceptable. Fifty timeouts in 200 requests indicates a connectivity or firewall problem.
Correlating with ISE Live Logs
Every session ID from show authentication sessions maps directly to an ISE live log entry. In ISE, navigate to Operations > RADIUS > Live Logs. Filter by NAS IP (10.0.99.1) or by endpoint MAC address. Click any log entry to expand the full authentication detail, including:
- Which policy set was matched
- Which authentication rule was evaluated
- Which authorization rule fired
- The exact attributes returned in the Access-Accept
The ISE live log also shows the failure reason in plain English — for example, "22040 Wrong password or invalid shared secret" or "15039 Rejected per authorization profile." Cross-referencing the switch debug output with the ISE live log gives you the complete picture of both sides of the exchange.
Troubleshooting
Symptom: show authentication sessions shows Status: Unauthorized, Method State: No Response
Cause: The supplicant is not responding to EAP-Request/Identity frames from the switch. This usually means the Windows 802.1X supplicant service (Wired AutoConfig) is not running, or the NIC is set to manually specify credentials and is waiting for user input on a machine-only boot.
Fix: On the Windows endpoint, verify the Wired AutoConfig service is set to Automatic and is running (services.msc). On the switch, check TxPeriod and MaxReq — if MaxReq is 2 and TxPeriod is 30, the switch waits 60 seconds before falling back to MAB. Reduce TxPeriod to 10 to accelerate fallback:
SW1(config-if)# dot1x timeout tx-period 10
Symptom: debug dot1x all shows EAP exchange completing, but debug radius shows Access-Reject
Cause: The EAP exchange succeeded at the transport layer, but ISE evaluated the identity against its policy and rejected it. Common reasons: the endpoint is not in the correct ISE identity group, the certificate is untrusted, the AD join is broken, or the authorization policy returned a Deny result.
Fix: In ISE, go to Operations > RADIUS > Live Logs, locate the failed session, and check the failure reason code. For certificate issues, verify the ISE trust store includes the root CA that signed the endpoint certificate (Administration > System > Certificates > Trusted Certificates). For AD lookup failures, check Administration > Identity Management > External Identity Sources > Active Directory > [Join Point] > Diagnostic.
Symptom: debug radius shows Access-Accept with correct VLAN attributes, but show authentication sessions shows wrong VLAN or no VLAN
Cause: The switch received the VLAN attribute but either an authentication event override command is forcing a different VLAN, or the port switchport access vlan command is statically set and a no switchport access vlan is needed to allow dynamic assignment. Alternatively, the authentication open command may be in use (Monitor Mode), and the port is placing traffic in the native VLAN regardless of what ISE returns.
Fix: Review the interface config with show running-config interface GigabitEthernet1/0/X. Remove any static switchport access vlan override. Confirm the auth event fallback VLANs are not intercepting the session. If authentication open is set (Monitor Mode), dynamic VLAN assignment does not redirect traffic — only the ACL is enforced. See Article 26: Monitor Mode vs Low-Impact Mode vs Closed Mode for a full explanation of how each mode handles VLAN assignment.
Symptom: show radius statistics shows high timeout count; ISE live logs show no corresponding request
Cause: RADIUS packets from the switch are not reaching ISE. The shared secret mismatch causes immediate reject (not timeout), so timeouts point to a network-level problem: ACL blocking UDP 1812/1813, wrong ISE IP configured on the switch, or ISE policy service node (PSN) is down.
Fix: Run ping 10.0.0.10 source vlan 99 from the switch. Verify the AAA server configuration matches the ISE PSN IP. In ISE, check Administration > Network Resources > Network Devices — confirm the switch's IP (10.0.99.1) is listed and the shared secret matches. Check any firewall or ACL between the management VLAN and ISE that might block UDP 1812 and 1813.
Turning Off Debugs
Always disable debugs when finished. A forgotten debug all on a production switch will eventually cause a CPU spike that impacts all users on the switch.
SW1# undebug all
Or selectively:
SW1# no debug dot1x all
SW1# no debug radius
SW1# no debug aaa authentication
SW1# no debug aaa authorization
Confirm with:
SW1# show debugging
The output should show no debugs active. If you used terminal monitor to see debug output in a remote SSH session, it does not automatically turn off when you disconnect — the debug processes continue until explicitly disabled.
What's Next: Article 26: Monitor Mode vs Low-Impact Mode vs Closed Mode: Choosing Your 802.1X Deployment Strategy — Understanding which deployment mode to use before you roll out 802.1X across production switches is the difference between a smooth rollout and a campus-wide outage. Article 26 covers all three modes with configuration examples and real-world tradeoffs.
