RADIUS Debugging on the Switch

Objective

In this lesson you will learn how to configure RADIUS server entries and AAA methods on an access switch, enable the key debug streams to trace RADIUS/EAP exchanges, and interpret debug/log output to identify why 802.1X (EAP-TLS) authentications fail. This is essential in production because switches are the authenticator in wired access — when authentication fails you must be able to read RADIUS/802.1X traces to tell whether the problem is a shared-secret mismatch, a fragmentation/MTU issue, or an unreachable RADIUS server.

Quick Recap

Refer to the topology created in Lesson 1. This lesson uses the same devices and adds no new IP addresses except the RADIUS server that was previously defined:

ASCII topology (extracted subset relevant to RADIUS):

[ Supplicant (Laptop) ] ---wired--- [ Access Switch (S1) ] ---L2--- [ WLC / AP fabric ] 
                                               |
                                               | mgmt / control
                                               |
                                          [ RADIUS Server ]
                                          Interface: 192.168.189.28

• RADIUS server IP (exact from reference): 192.168.189.28

Important: The access switch acts as the authenticator; the supplicant is the client. RADIUS (on 192.168.189.28) is the authentication server.

Key Concepts (theory + practical behavior)

• RADIUS as backend for 802.1X: The switch forwards EAP messages between the supplicant and the RADIUS server encapsulated in RADIUS Access-Request/Access-Challenge/Access-Accept messages. In production, the switch does not terminate EAP-TLS; it tunnels EAP to the RADIUS server.
• RADIUS Identifier and EAP Packet ID consistency: The RADIUS Identifier is constant for a single RADIUS transaction; the RADIUS server assigns a new EAP Packet ID inside the Access-Challenge/Access-Request AVP and that EAP Packet ID remains the same as the message is forwarded between switch and supplicant. Example numbers seen in captures: RADIUS Identifier = 143, EAP Packet ID = 31.
• Fragmentation and MTU implications: EAP-TLS client certificates are large (avg 2,200–8,000 bytes). If the path (switch/WLC/router) adds encapsulation headers (tunneling), MTU can shrink, causing RADIUS/EAP fragments to be dropped. In production, this often manifests as timeouts or partial cert delivery.
• Common failure points: shared secret mismatch, RADIUS server unreachable (network ACLs), RADIUS MTU/fragmentation causing partial certificate delivery, or EAP timeout on the authenticator.
• Debugging principle: Enable targeted debug streams (RADIUS and 802.1X) on the switch, reproduce the failure, capture the debug output, and look for RADIUS identifiers, EAP Packet IDs, Access-Request/Access-Challenge pairs, and timeout/deletion messages.

Step-by-step configuration

Step 1: Configure the RADIUS server entry on the switch

What we are doing: We register the RADIUS server details on the switch so the switch can send Access-Request and accounting packets to the server. This must match the RADIUS server's configuration (address, ports, and shared secret).

configure terminal
radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123
exit
exit

What just happened:

• radius server J_ISE creates a named RADIUS server object.
• address ipv4 192.168.189.28 auth-port 1812 acct-port 1813 tells the switch where to send authentication and accounting packets.
• key Lab@123 sets the shared secret used to secure the RADIUS AVPs. If this value differs from the server, authentication requests will be rejected or silently dropped depending on the server. This is often the first cause of failures in production.

Real-world note: Use a consistent secret between authenticator and RADIUS server and rotate it using secure processes. In multi-vendor deployments, confirm the secret encoding (clear vs encrypted).

Verify:

show running-config | section radius server
radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123

Step 2: Create an AAA RADIUS server group and map dot1x authentication

What we are doing: We create a server group that references the named server and then map that group into the switch's AAA dot1x authentication method. This lets interface dot1x use the group rather than a single server name.

configure terminal
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
exit
aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group
exit

What just happened:

• aaa group server radius Cisco_Live_Radius_Group creates a group containing one or more RADIUS servers; this allows load-sharing or fallback if additional servers are added.
• server name J_ISE binds the earlier radius server object into the AAA group.
• aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group creates an authentication method list named Cisco_Live_AuthC which instructs the switch to consult the RADIUS group to process 802.1X authentication requests.

Real-world note: Use AAA groups when you have multiple RADIUS nodes (HA) — it simplifies failover and policy mapping.

Verify:

show running-config | section aaa
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group

Step 3: Enable focused debug streams for RADIUS and 802.1X

What we are doing: Turn on the switch debug output for RADIUS and 802.1X so we can trace the Access-Request/Access-Challenge conversation and the EAP packet IDs that travel inside those RADIUS AVPs.

terminal monitor
debug radius
debug dot1x all

What just happened:

• terminal monitor ensures syslog/debug output is visible on the current terminal session.
• debug radius prints RADIUS packet events (Access-Request, Access-Challenge, etc.).
• debug dot1x all prints 802.1X state machine transitions and forwarded EAP messages. These outputs will include RADIUS Identifier values and EAP Packet IDs, enabling you to correlate RADIUS messages to over-the-air or PCAP traces.

Real-world note: Debugging is CPU- and log-intensive—run it briefly on production devices during a maintenance window or on a maintenance console.

Verify: Reproduce the authentication attempt (have the supplicant start authentication) and then view the live debug; example extracted debug lines show identifier and packet ID consistency:

%RADIUS-4-ACCESS_REQ: Sending Access-Request to 192.168.189.28:1812, Identifier 143, User: 00-11-22-33-44-55
%DOT1X-5-EAP_FORWARD: Forwarding EAP (ID 31) in Access-Request (Identifier 143)
%RADIUS-5-REPLY: Received Access-Challenge from 192.168.189.28:1812, Identifier 143, EAP Packet ID 31
%DOT1X-5-EAP_RECEIVE: Received EAP (ID 31) from RADIUS, forwarding to supplicant

• RADIUS Identifier = 143 appears on both the Access-Request and Access-Challenge.
• EAP Packet ID = 31 is preserved inside the RADIUS AVP as the message is forwarded to the supplicant.

Step 4: Capture and interpret a failed authentication trace

What we are doing: Gather the debug/log output produced while the supplicant attempts authentication and analyze the common failure signatures (unreachable server, shared-secret mismatch, fragment/MTU issues).

show logging

What just happened:

• show logging lists the switch syslog buffer and debug messages. You should see RADIUS and dot1x debug lines; look for errors such as authentication timeouts or client deletes.

Expected example output (complete lines for a failure case):

Mar 25 10:36:24.340001454: %DOT1X-6-CLIENT_DELETE: MAC: ffff.ffff.ffff Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE
Mar 25 10:21:48.492605329: %DOT1X-6-CLIENT_DELETE: MAC: ffff.ffff.ffff Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_L2AUTH_CONNECT_TIMEOUT
Mar 25 13:12:07.061330322: %DOT1X-6-CLIENT_DELETE: MAC: ffff.ffff.ffff Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_AAA_SERVER_UNAVAILABLE
%RADIUS-5-TIMEOUT: No response from RADIUS server 192.168.189.28 for Access-Request Identifier 143

• CLIENT_EAP_TIMEOUT_FAILURE indicates the switch did not complete EAP exchange — commonly caused by missing fragments, MTU problems, or network loss.
• AAA_SERVER_UNAVAILABLE and No response from RADIUS server 192.168.189.28 indicate network reachability or server-side problems.

Real-world note: If you see EAP timeouts but RADIUS replies were received, suspect fragmentation/MTU; if no RADIUS replies are seen, suspect reachability or secret mismatches.

Step 5: Turn off debug and document findings

What we are doing: Disable debug to stop high-volume logging, and save the running configuration and logs for post-mortem.

undebug all
terminal no monitor
copy running-config startup-config

What just happened:

• undebug all stops all active debug streams.
• terminal no monitor prevents syslog from flooding your terminal.
• copy running-config startup-config preserves the RADIUS/AAA configuration for later use.

Real-world note: Always collect logs and configs after reproducing an issue; packet captures and debug logs are essential for vendor escalation if needed.

Verify:

show running-config
! (output should contain the radius and aaa sections previously configured)
radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group

Verification Checklist

• Check 1: RADIUS server entry present — run show running-config | section radius server and confirm address ipv4 192.168.189.28 auth-port 1812 acct-port 1813 and key Lab@123.
• Check 2: AAA method list mapped — run show running-config | section aaa and confirm aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group.
• Check 3: Debug trace shows RADIUS Identifier and EAP Packet ID consistency — reproduce auth and verify debug lines showing same RADIUS Identifier (e.g., 143) and EAP Packet ID (e.g., 31).
• Check 4: If authentication fails, verify type of failure in logs: CLIENT_EAP_TIMEOUT_FAILURE (fragment/MTU) vs AAA_SERVER_UNAVAILABLE (reachability).

Common Mistakes

Symptom	Cause	Fix
No RADIUS replies seen in debug	RADIUS server unreachable (routing/ACL issue) or RADIUS service down on 192.168.189.28	Verify network reachability (ping/traceroute from management plane), confirm RADIUS service is up on server, check ACLs/NAT
Authentication completes partially, then times out	Large EAP-TLS certificate fragments are being dropped due to MTU/tunnel headers	Investigate MTU on path, consider RADIUS MTU/jumbo configuration on network devices and ensure fragmentation support; capture PCAPs to confirm fragments
Repeated Access-Rejects or failure to proceed	Shared secret mismatch between switch and RADIUS server	Confirm key Lab@123 matches server; update to identical secret on both sides
Debug output too verbose or impacting CPU	Leaving debug enabled on production longer than necessary	Run debug briefly, collect logs, then undebug all; use maintenance window

Key Takeaways

• Always start troubleshooting by verifying the RADIUS server entry and AAA method list on the authenticator — mismatched IP/port/secret are the simplest causes.
• Use targeted debug streams (debug radius and debug dot1x) to trace the full flow: Access-Request -> Access-Challenge -> Access-Accept and observe RADIUS Identifier and EAP Packet ID consistency (e.g., Identifier 143, EAP Packet ID 31).
• EAP-TLS involves large payloads (certificates). If RADIUS replies are present but EAP times out, suspect MTU/fragmentation between authenticator and server.
• Always disable debug when finished and preserve logs/config for post-incident analysis. In production, perform debugging during a maintenance window to avoid service impact.

Tip: When you see same RADIUS Identifier on both Access-Request and Access-Challenge in debug and the EAP Packet ID is preserved (e.g., 31), you have strong evidence that the switch correctly forwarded the RADIUS AVP; the next step is to examine packet captures on the server and switch to find any missing fragments.

---

This lesson focused on enabling and interpreting switch-side RADIUS/802.1X debugging using the exact RADIUS IP (192.168.189.28) and AAA constructs previously defined. In the next lesson we'll focus on capturing the RADIUS/802.1X packets end-to-end (supplicant → switch → server) and analyzing fragmentation behavior.