802.1X Troubleshooting: From Supplicant to RADIUS Server

Introduction

A wireless user opens their laptop, expects seamless network access, and instead stares at a spinning connection icon that eventually times out. The helpdesk ticket reads: "Cannot connect to corporate Wi-Fi." Behind that simple complaint lies a chain of EAP exchanges, TLS handshakes, certificate validations, CAPWAP encapsulations, and RADIUS transactions -- any one of which can silently fail and bring the entire authentication process to a halt.

802.1X troubleshooting is one of the most demanding skills a network engineer can develop. The protocol spans three distinct components -- the supplicant (client device), the authenticator (wireless LAN controller or switch), and the authentication server (typically Cisco ISE) -- and a failure at any point in the chain produces symptoms that can be misleading. A certificate that is one byte too large for the path MTU, a mismatched RADIUS shared secret, or a stale EAP packet ID can all result in the same generic "authentication failed" message on the client side.

This article walks you through the entire 802.1X authentication flow, from the initial EAP identity exchange to the final RADIUS Access-Accept. You will learn how to read radioactive traces on the Catalyst 9800 WLC, understand EAP-TLS fragmentation behavior, verify CAPWAP path MTU settings, and systematically isolate whether a failure originates at the supplicant, the authenticator, or the RADIUS server. Every command, packet field, and troubleshooting technique in this guide is drawn from production lab environments so you can apply them directly in your own network.

If you are preparing for CCNP Security or working with Cisco ISE in production, the ISE 802.1X Lab Course on NHPREP provides hands-on practice with these exact scenarios.

What Is 802.1X and Why Does It Break?

802.1X is an IEEE standard for port-based network access control. It defines three roles in every authentication exchange:

Supplicant: The client device requesting network access. This is typically a laptop, phone, or IoT device running an 802.1X-capable software stack.
Authenticator: The network device that controls port access. In wireless environments, this is the Wireless LAN Controller (WLC). In wired environments, it is the access switch.
Authentication Server: The backend RADIUS server that validates credentials. Cisco ISE is the most common implementation in enterprise networks.

The protocol uses the Extensible Authentication Protocol (EAP) as its transport mechanism. EAP itself is a framework, not a single method. The actual authentication is performed by an EAP method running inside the EAP transport. Common EAP methods include:

EAP Method	Server Certificate	Client Certificate	Primary Use Case
LEAP	No	No	Legacy (deprecated)
EAP-FAST	Yes	No	Password-based with tunnel
PEAP	Yes	No	Password-based with TLS tunnel
EAP-TLS	Yes	Yes	Certificate-based mutual auth

EAP-TLS is the gold standard for enterprise wireless security because it requires both a server certificate and a client certificate, providing mutual authentication. However, this dual-certificate requirement also makes it the most complex method to troubleshoot, because certificates are large and introduce fragmentation challenges that other EAP methods avoid.

802.1X breaks for many reasons, but the most common fall into three categories: reachability issues between the authenticator and the RADIUS server, certificate problems on either side of the TLS handshake, and fragmentation failures caused by MTU mismatches along the data path.

How Does the EAP-TLS Authentication Flow Work?

Understanding the complete EAP-TLS flow is essential for effective 802.1X troubleshooting. Without knowing what is supposed to happen at each step, you cannot identify where things go wrong. The flow consists of four distinct phases.

Phase 1: Identity Exchange

The authentication begins when the authenticator sends an EAP-ID Request to the supplicant. This is a simple packet asking the client to identify itself. The EAP request packet uses Code 1 (Request) and Type 1 (Identity). The supplicant responds with an EAP-ID Response containing the client's identity (typically a username or machine name). The response packet uses Code 2 (Response).

At this stage, no fragmentation is required. The identity packets are small -- typically well under 1000 bytes. The authenticator wraps the EAP-ID Response into a RADIUS Access-Request and forwards it to the authentication server.

Pro Tip: During Phase 1, pay attention to the EAP Packet ID assigned by the RADIUS server. This ID remains consistent throughout the entire communication flow until the server initiates a new EAP message. For example, if the RADIUS server assigns EAP Packet ID 31, that same ID appears in the CAPWAP frame sent from the WLC to the AP and in the over-the-air (OTA) frame sent from the AP to the client.

Phase 2: Server Certificate Delivery

After receiving the identity, the RADIUS server begins the TLS handshake by sending the Server Hello, Server Certificate, Server Key Exchange, Certificate Request, and Server Hello Done messages. These are wrapped in EAP-Request packets inside RADIUS Access-Challenge messages.

This is where fragmentation first becomes necessary. Server certificates typically range from 2,200 to 8,000 bytes in size -- far too large to fit in a single EAP frame. ISE intelligently sends packets sized at 1,002 bytes to minimize the chances of further fragmentation within the network. The data is transmitted in multiple fragments, with ISE awaiting an empty EAP Response acknowledgment from the client before sending the next fragment.

This fragment-then-wait behavior is mandatory per the EAP specification: the authentication server MUST wait until it receives the EAP-Response before sending another fragment.

Phase 3: Client Certificate Delivery

Once the supplicant has received and validated the server certificate, it responds with its own Client Certificate, Client Key Exchange, and Certificate Verify messages. The same fragmentation rules apply in reverse: the supplicant MUST wait until it receives the EAP-Request before sending another fragment.

Client certificates are also large. In lab captures, client certificate payloads of 4,150 bytes are common. These must be fragmented to fit within the EAP frame size constraints.

Phase 4: Cipher Suite Negotiation and Completion

The final phase involves the TLS Change Cipher Spec and TLS Finished messages from both sides. Once the TLS tunnel is established successfully, the RADIUS server sends an Access-Accept message, and the authenticator sends an EAP-Success to the supplicant. The client then proceeds through the 4-way handshake (M1/M2/M3/M4) for key derivation and completes the association.

802.1X Troubleshooting: WLC Configuration Verification

Before diving into packet captures and debug traces, always verify that the WLC configuration is correct. A missing or misconfigured element in the WLC setup is the most common cause of 802.1X failures. The configuration involves five key steps on a Catalyst 9800 WLC.

Step 1: Configure the RADIUS Server

Define the ISE server with its IP address, authentication port, accounting port, and shared secret:

radius server LAB_ISE
  address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
  key Lab@123

The standard RADIUS ports are 1812 for authentication and 1813 for accounting. The shared secret must match exactly on both the WLC and ISE -- a single character mismatch will cause silent authentication failures with no helpful error messages.

Step 2: Configure the RADIUS Server Group

Group the RADIUS server(s) into a named server group:

aaa group server radius Lab_Radius_Group
  server name LAB_ISE

Server groups allow you to define multiple RADIUS servers for redundancy. During troubleshooting, verify that the correct server is listed in the group and that it is reachable from the WLC management interface.

Step 3: Configure the Authentication Method List

Create a dot1x authentication method list that references the server group:

aaa authentication dot1x Lab_AuthC group Lab_Radius_Group

This method list tells the WLC which RADIUS server group to use for 802.1X authentication requests. A common mistake is creating the method list but forgetting to apply it to the WLAN.

Step 4: Configure the WLAN with 802.1X

Create the WLAN and map the authentication method list:

wlan Lab_Dot1x 9 Lab_Dot1x
  radio policy dot11 24ghz
  radio policy dot11 5ghz
  security dot1x authentication-list Lab_AuthC

The WLAN definition includes the SSID name, WLAN ID, radio policies, and the critical security dot1x authentication-list command that ties 802.1X to this specific WLAN.

Step 5: Configure the Policy Profile and Policy Tag

The Policy Profile defines VLAN assignment and other post-authentication policies. The Policy Tag maps the WLAN to the Policy Profile:

wireless profile policy Lab_Policy_Profile
  description Lab_Policy_Profile
  vlan 282
  no shutdown

wireless tag policy Lab_Policy_Tag
  description Lab-PolicyTag
  wlan Lab_Dot1x policy Lab_Policy_Profile

Pro Tip: Always verify that the Policy Profile is in a no shutdown state. A shutdown Policy Profile will silently prevent any client from completing authentication, and the error messages on the client side will be unhelpful.

How to Read Radioactive Traces for 802.1X Troubleshooting

Radioactive traces are the most powerful troubleshooting tool on the Catalyst 9800 WLC. They provide per-client, detailed logging of every step in the authentication process. When a client fails to authenticate, the radioactive trace will contain a client delete reason that points you toward the root cause.

Three Critical Client Delete Reasons

The following client delete reasons appear in radioactive traces and each points to a different failure domain:

1. AAA Server Unavailable

2025/03/21 13:12:07.061330322 {wncd_x_R0-0}{1}: [client-orch-sm] [17707]: (note):
MAC: ffff.ffff.ffff Client delete initiated.
Reason: CO_CLIENT_DELETE_REASON_AAA_SERVER_UNAVAILABLE

This error means the WLC cannot reach the RADIUS server. Troubleshooting steps:

Verify the RADIUS server IP address and port configuration
Test IP reachability from the WLC to the RADIUS server using ping
Confirm the RADIUS shared secret matches on both sides
Check that ISE is running and the RADIUS service is enabled
Verify that no firewall or ACL is blocking UDP ports 1812/1813

2. EAP Timeout Failure

2025/03/25 10:36:24.340001454 {wncd_x_R0-0}{1}: [client-orch-sm] [15664]: (note):
MAC: ffff.ffff.ffff Client delete initiated.
Reason: CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE

This error indicates that the supplicant did not respond to an EAP request within the expected timeout. Common causes include:

The client's 802.1X supplicant is not configured or not running
The client does not have the required certificate installed (for EAP-TLS)
The client rejected the server certificate due to trust issues
A fragmentation problem prevented the complete EAP exchange

3. L2 Authentication Connect Timeout

2025/03/25 10:21:48.492605329 {wncd_x_R0-0}{1}: [client-orch-sm] [15664]: (note):
MAC: ffff.ffff.ffff Client delete initiated.
Reason: CO_CLIENT_DELETE_REASON_L2AUTH_CONNECT_TIMEOUT

This error means the Layer 2 authentication process timed out before completing. This can happen when the EAP-TLS handshake takes too long due to excessive fragmentation, slow RADIUS server responses, or high latency in the network path.

Pro Tip: When analyzing radioactive traces, always look for the MAC address of the failing client and filter the trace output for that specific address. The trace contains a wealth of information, but focusing on the client delete reason is the fastest path to root-cause identification.

Understanding EAP Packet IDs and RADIUS Identifiers

One of the most confusing aspects of 802.1X troubleshooting is keeping track of packet identifiers as they traverse the network. There are two distinct identifier systems at work, and understanding how they behave is critical for correlating packet captures taken at different points in the network.

EAP Packet ID Behavior

The EAP Packet ID is assigned by the RADIUS server when it sends an EAP message inside a RADIUS AVP (Attribute-Value Pair). Key behaviors:

The RADIUS server assigns a new EAP Packet ID for each EAP message it initiates
This EAP Packet ID remains consistent throughout the entire communication flow until the next EAP message is initiated by the RADIUS server
When the WLC forwards the EAP packet to the AP via CAPWAP, the same Packet ID is retained
When the AP forwards the EAP packet over the air to the client, the same Packet ID is retained

For example, if the RADIUS server assigns EAP Packet ID 31 in an Access-Challenge message, you will see Packet ID 31 in the WLC EPC (Embedded Packet Capture), in the CAPWAP tunnel, and in the OTA (Over-The-Air) capture. When the client responds with an EAP-Response, it uses the same Packet ID 31.

RADIUS Identifier Behavior

The RADIUS Identifier works differently. It is assigned by the WLC (the RADIUS client) and serves to match Access-Request messages with their corresponding Access-Challenge or Access-Accept responses. Key behaviors:

The RADIUS Identifier remains consistent within a single transaction (one Access-Request and its corresponding Access-Challenge)
The WLC assigns a new RADIUS Identifier for each new Access-Request it sends to the RADIUS server
The RADIUS server echoes back the same Identifier in its response

For example, if the WLC sends an Access-Request with RADIUS Identifier 143, the RADIUS server will respond with an Access-Challenge containing the same Identifier 143. For the next exchange, the WLC will assign a new Identifier (e.g., 144).

Why This Matters for 802.1X Troubleshooting

When you are capturing packets at multiple points -- on the WLC (EPC), at the AP, and over the air -- you need to correlate these captures to follow a single authentication session. The EAP Packet ID is your best correlation key because it stays consistent from the RADIUS server all the way to the client. The RADIUS Identifier, on the other hand, only appears in the RADIUS leg of the communication (between WLC and ISE) and changes with each transaction.

Identifier Type	Assigned By	Scope	Consistency
EAP Packet ID	RADIUS Server	End-to-end (server to client)	Same ID until server sends new EAP message
RADIUS Identifier	WLC	WLC to RADIUS server only	Same ID within one Access-Request/Challenge pair

802.1X Troubleshooting: Fragmentation and MTU Challenges

Fragmentation is the single most common cause of mysterious EAP-TLS failures. Certificates are large, network paths have MTU constraints, and CAPWAP encapsulation adds overhead. Understanding where and how fragmentation occurs is essential for resolving these issues.

Where Does Fragmentation Occur?

In a wireless 802.1X deployment, fragmentation can occur at multiple points:

EAP-level fragmentation: The RADIUS server fragments the server certificate into EAP-sized chunks (ISE uses 1,002-byte fragments). The client similarly fragments its certificate.
CAPWAP-level fragmentation: The AP encapsulates EAP frames inside CAPWAP tunnels. If the resulting CAPWAP packet exceeds the path MTU, the AP must fragment the CAPWAP payload.
IP-level fragmentation: If any device in the path between the AP and WLC has a lower MTU than expected, IP-level fragmentation occurs.

The Double Fragmentation Problem

During Phase 3 of the EAP-TLS exchange (client certificate delivery), the client sends its certificate to the AP in fragmented EAP frames. The AP then encapsulates each fragment in a CAPWAP header and sends it to the WLC. If the CAPWAP-encapsulated packet exceeds the CAPWAP path MTU, the AP must fragment it again at the CAPWAP level.

This creates a double fragmentation scenario:

First fragmentation: Performed by the client to exchange the certificate over the air
Second fragmentation: Performed by the AP to add the CAPWAP header and fit within the CAPWAP path MTU

Consider a real-world example from a lab capture: a client certificate of 4,150 bytes is fragmented by the client into multiple OTA frames. The AP receives these fragments, reassembles them at the EAP level, adds CAPWAP headers, and sends them to the WLC. If the CAPWAP path MTU is 1,485 bytes, the CAPWAP packets may be further fragmented at the IP level.

The packet sizes observed in lab captures illustrate this clearly:

Segment	Packet Sizes Observed
OTA (Client to AP)	1,482 bytes, 1,486 bytes, 1,486 bytes, 125 bytes
CAPWAP (AP to WLC)	1,492 bytes, 1,492 bytes, 1,492 bytes, 131 bytes
RADIUS (WLC to ISE)	1,414 bytes, 680 bytes

The WLC reassembles the CAPWAP fragments before constructing the RADIUS Access-Request to send to ISE.

Verifying CAPWAP Path MTU

The CAPWAP Path MTU is a critical value that determines whether CAPWAP-level fragmentation will occur. The AP negotiates a PMTU (Path Maximum Transmission Unit) that can be one of three values: 576, 1,005, or 1,485 bytes.

You can verify the current CAPWAP Path MTU from both the WLC and the AP:

From the WLC:

show ap name C9120AXI-1 config general

Look for the line:

CAPWAP Path MTU : 1485

From the AP:

show capwap client rcb

Key output fields:

OperationState : UP
Name           : C9120AXI-1
SwVer          : 17.15.3.28
MwarApMgrIp    : 192.168.182.17
MwarName       : c9800_40_new_1
ApMode         : Local
CAPWAP Path MTU : 1485

Pro Tip: If you see a CAPWAP Path MTU of 576, this is the minimum negotiated value and will cause excessive fragmentation. Investigate the network path between the AP and WLC for devices that are artificially lowering the MTU (such as tunnels or VPN concentrators in the path).

Useful Packet Capture Filters

When analyzing packet captures taken at the AP level, the double fragmentation can make it difficult to isolate the EAP frames you care about. Use a Wireshark display filter to find the relevant packets. A practical filter approach for AP-side captures is to filter on the EAP or EAPOL protocol combined with the client MAC address embedded in the data payload.

How to Systematically Isolate 802.1X Failures

When faced with an 802.1X authentication failure, a systematic approach saves hours of guesswork. Follow this layered troubleshooting methodology to isolate the failure domain.

Layer 1: RADIUS Server Reachability

Start with the most fundamental question: can the WLC reach the RADIUS server?

Verify the RADIUS server configuration on the WLC:

show running-config | section radius server

Confirm the server IP address (e.g., 192.168.189.28), authentication port (1812), and accounting port (1813) are correct
Test basic IP connectivity from the WLC to the RADIUS server
Check the RADIUS server group configuration:

show running-config | section aaa group server radius

Verify the method list is correctly configured:

show running-config | section aaa authentication dot1x

If the radioactive trace shows CO_CLIENT_DELETE_REASON_AAA_SERVER_UNAVAILABLE, the problem is almost certainly at this layer.

Layer 2: Supplicant Configuration

If the RADIUS server is reachable but clients are failing, move to the supplicant:

Verify the client has an 802.1X supplicant enabled and configured for the correct EAP method
For EAP-TLS, confirm the client has a valid client certificate installed
Verify the client trusts the CA that signed the RADIUS server's certificate
Check that the certificate has not expired on either side

If the radioactive trace shows CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE, the supplicant is not responding to EAP requests, often due to a certificate or configuration issue on the client.

Layer 3: Fragmentation and MTU

If the supplicant and RADIUS server are both configured correctly but authentication still fails, investigate fragmentation:

Check the CAPWAP Path MTU between the AP and WLC
Look for evidence of dropped fragments in AP-level packet captures
Verify that no firewall or network device in the path is dropping IP fragments
Consider the size of the certificates being exchanged -- larger certificates require more fragments and increase the risk of failure

If the radioactive trace shows CO_CLIENT_DELETE_REASON_L2AUTH_CONNECT_TIMEOUT, the authentication is timing out, which often indicates a fragmentation problem where fragments are being lost in transit.

Troubleshooting Decision Table

Symptom	Likely Cause	First Step
All clients fail on all SSIDs	RADIUS server down or unreachable	Check server reachability
All clients fail on one SSID	WLAN misconfiguration	Verify WLAN and method list
Some clients fail intermittently	Certificate or fragmentation issue	Check CAPWAP MTU and cert sizes
Clients fail after WLC upgrade	RADIUS MTU or EAP timer change	Compare running-config to backup
Clients connect then disconnect	Policy Profile issue	Check VLAN assignment and profile state

Certificate Lifecycle and 802.1X Troubleshooting

Certificates are at the heart of EAP-TLS authentication, and certificate problems are among the most common causes of 802.1X failures. Understanding the certificate lifecycle on both the server side and the client side is essential.

Server-Side Certificate Lifecycle

The RADIUS server (ISE) presents a server certificate to every client that attempts EAP-TLS authentication. This certificate must meet several requirements:

It must be signed by a CA that the supplicant trusts
It must not be expired
It must have the correct Extended Key Usage (EKU) attributes for server authentication
Its size directly impacts fragmentation behavior during Phase 2 of the EAP-TLS exchange

Server certificates typically range from 2,200 to 8,000 bytes. Larger certificates require more EAP fragments, increase the time required for the TLS handshake, and raise the probability of fragment loss.

Client-Side Certificate Lifecycle

For EAP-TLS, each client must possess a valid client certificate. The same requirements apply:

Signed by a CA trusted by ISE
Not expired
Correct EKU attributes for client authentication
Size affects fragmentation during Phase 3

In lab environments, client certificates with payloads of approximately 4,150 bytes are common. These must be fragmented for over-the-air delivery and then further fragmented during CAPWAP encapsulation.

Certificate Size and Fragmentation Risk

The relationship between certificate size and fragmentation risk is direct and measurable:

Certificate Size	EAP Fragments (at 1,002 bytes)	Fragmentation Risk
Less than 1,000 bytes	1 (no fragmentation)	Low
2,200 bytes	3 fragments	Moderate
4,150 bytes	5 fragments	Moderate-High
8,000 bytes	8 fragments	High

Each additional fragment is another opportunity for packet loss. In environments with high AP density, RF interference, or congested network paths, keeping certificate sizes as small as practical reduces authentication failures.

Packet Capture Strategy for 802.1X Troubleshooting

Effective 802.1X troubleshooting requires capturing packets at the right points in the network. There are three capture locations, each showing a different piece of the authentication puzzle.

Capture Point 1: WLC Embedded Packet Capture (EPC)

The WLC EPC captures RADIUS traffic between the WLC and the authentication server. This is where you see:

RADIUS Access-Request messages (sent by the WLC)
RADIUS Access-Challenge messages (sent by ISE)
RADIUS Access-Accept or Access-Reject messages
RADIUS Identifiers and EAP AVPs

Use the WLC EPC when you need to verify that RADIUS communication is happening correctly and that EAP messages are being properly encapsulated in RADIUS packets.

Capture Point 2: AP-Level Capture

The AP-level capture shows CAPWAP traffic between the AP and the WLC. This is where you see:

CAPWAP encapsulated EAP frames
CAPWAP fragmentation (if the CAPWAP Path MTU is exceeded)
IP-level fragmentation of CAPWAP packets

This capture point is critical for diagnosing double fragmentation scenarios. You can observe both the EAP-level fragmentation performed by the client and the CAPWAP-level fragmentation performed by the AP.

Capture Point 3: Over-The-Air (OTA) Capture

The OTA capture shows the raw 802.11 frames exchanged between the supplicant and the AP. This is where you see:

EAP-ID Request and Response frames
EAP-TLS handshake messages
EAP fragment acknowledgments (empty EAP responses)
The 4-way handshake (M1/M2/M3/M4) after successful authentication

OTA captures require a wireless adapter in monitor mode and a tool like Wireshark. They are the most difficult to collect but provide the most complete picture of the client-side authentication experience.

Correlating Multiple Captures

To follow a single authentication session across all three capture points:

Identify the client's MAC address
Use the EAP Packet ID as your correlation key -- it remains consistent from the RADIUS server through the WLC, across the CAPWAP tunnel, and over the air
Use the RADIUS Identifier to match Access-Request/Access-Challenge pairs in the WLC EPC
Look at timestamps to align events across captures

RADIUS MTU and Jumbo Frame Considerations

The Catalyst 9800 WLC provides controls for managing the RADIUS MTU, which determines the maximum size of RADIUS packets exchanged with the authentication server. This feature gives administrators the ability to control fragmentation behavior at the RADIUS protocol level.

Why RADIUS MTU Matters

When ISE sends a server certificate inside a RADIUS Access-Challenge, the EAP payload carrying the certificate can be large. The RADIUS protocol itself has mechanisms for handling large payloads through EAP fragmentation, but the underlying UDP packets must still fit within the network MTU.

If the RADIUS packets are too large for any link in the path between the WLC and ISE, they will be fragmented at the IP level or -- worse -- dropped entirely if a firewall blocks IP fragments. The RADIUS MTU feature allows you to control the maximum RADIUS packet size to prevent this scenario.

RADIUS Jumbo Frames

In environments where the network infrastructure between the WLC and ISE supports jumbo frames (MTU greater than 1,500 bytes), enabling RADIUS jumbo frames can reduce the number of RADIUS round trips required to complete the EAP-TLS exchange. Fewer round trips means faster authentication and lower latency for the end user.

However, jumbo frames must be supported end-to-end between the WLC and the RADIUS server. A single device in the path with a standard 1,500-byte MTU will cause fragmentation or packet drops that defeat the purpose of jumbo frames.

Pro Tip: Before enabling RADIUS jumbo frames, perform a path MTU discovery between the WLC management interface and the RADIUS server. Verify that every switch, router, and firewall in the path supports the jumbo frame size you intend to use.

Frequently Asked Questions

What is the most common cause of 802.1X authentication failures?

The most common cause is a reachability issue between the authenticator (WLC or switch) and the RADIUS server. This can be due to an incorrect server IP address, a mismatched shared secret, blocked UDP ports (1812/1813), or the RADIUS service not running on ISE. The radioactive trace on the Catalyst 9800 WLC will show CO_CLIENT_DELETE_REASON_AAA_SERVER_UNAVAILABLE when this occurs.

How do I determine whether the supplicant or the RADIUS server is causing the failure?

Check the radioactive trace for the client delete reason. If you see CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE, the supplicant is not responding to EAP requests, indicating a client-side problem (missing certificate, wrong EAP method, supplicant not running). If you see CO_CLIENT_DELETE_REASON_AAA_SERVER_UNAVAILABLE, the problem is on the RADIUS server side. If you see CO_CLIENT_DELETE_REASON_L2AUTH_CONNECT_TIMEOUT, the issue may be fragmentation-related.

Why does EAP-TLS require fragmentation while PEAP does not?

EAP-TLS requires both a server certificate and a client certificate to be exchanged during the TLS handshake. Certificates typically range from 2,200 to 8,000 bytes, which is far too large for a single EAP frame. PEAP only requires the server certificate (Phase 2), and the client authenticates with a username and password inside the TLS tunnel, so there is less data to exchange overall. However, PEAP can still experience fragmentation during server certificate delivery.

What CAPWAP Path MTU values are possible, and which is best?

The Access Point negotiates a CAPWAP Path MTU that can be one of three values: 576, 1,005, or 1,485 bytes. A value of 1,485 is optimal for most networks and minimizes CAPWAP-level fragmentation. A value of 576 indicates a severely constrained path and will cause excessive fragmentation that significantly slows down EAP-TLS authentication. You can verify the current CAPWAP Path MTU using show ap name <ap-name> config general on the WLC or show capwap client rcb on the AP.

How do I correlate packet captures taken at different points in the network?

Use the EAP Packet ID as your primary correlation key. This ID is assigned by the RADIUS server and remains consistent from the RADIUS Access-Challenge, through the WLC, across the CAPWAP tunnel to the AP, and over the air to the client. The RADIUS Identifier, by contrast, only appears in the RADIUS leg between the WLC and ISE and changes with each new Access-Request.

What is double fragmentation and when does it occur?

Double fragmentation occurs during Phase 3 of EAP-TLS (client certificate delivery) in wireless deployments. The client first fragments its certificate for over-the-air transmission. The AP then encapsulates each EAP fragment in a CAPWAP header, and if the resulting CAPWAP packet exceeds the CAPWAP Path MTU, the AP must fragment it again. This creates two layers of fragmentation: EAP-level fragmentation by the client and CAPWAP-level fragmentation by the AP. The WLC must reassemble all CAPWAP fragments before it can process the EAP message and forward it to the RADIUS server.

Conclusion

802.1X troubleshooting is a methodical process that requires understanding the full authentication chain from supplicant to RADIUS server. The key takeaways from this guide are:

Know the four phases of EAP-TLS: identity exchange, server certificate delivery, client certificate delivery, and cipher suite negotiation. Each phase has distinct characteristics and failure modes.
Use radioactive traces on the Catalyst 9800 WLC to quickly identify the failure domain. The three client delete reasons -- AAA Server Unavailable, EAP Timeout Failure, and L2Auth Connect Timeout -- each point to a different root cause.
Understand the identifier systems: EAP Packet IDs stay consistent end-to-end and are your best tool for correlating captures. RADIUS Identifiers are scoped to the WLC-to-ISE leg only.
Respect fragmentation: Certificates are large, CAPWAP adds overhead, and double fragmentation is real. Verify the CAPWAP Path MTU on every AP and investigate any AP showing a negotiated PMTU of 576.
Verify the basics first: Before reaching for packet captures, confirm the WLC configuration -- RADIUS server definition, server group, method list, WLAN security settings, and policy profile state.
Capture at the right points: WLC EPC for RADIUS traffic, AP captures for CAPWAP fragmentation, and OTA captures for the client-side experience.

Mastering these techniques transforms 802.1X troubleshooting from a frustrating guessing game into a structured diagnostic process. For hands-on practice with ISE and 802.1X in a lab environment, explore the ISE 802.1X Lab Course on NHPREP, where you can work through these exact scenarios with real equipment and build the confidence to resolve 802.1X issues in production networks.