EAPOL Explained: How 802.1X Traffic Moves Over the Wire

What EAPOL Is and What It Is Not

EAPOL — Extensible Authentication Protocol over LAN — is the Layer 2 encapsulation method defined in IEEE 802.1X for carrying EAP messages between the supplicant (endpoint) and the authenticator (switch). EAPOL frames never leave the local network segment. They are not routable and are not forwarded by standard Layer 3 devices.

This matters operationally: when authentication fails, the EAPOL exchange is always local. If you're troubleshooting from a remote workstation, you cannot capture EAPOL frames in transit between the endpoint and the switch. You need to either run a packet capture on the endpoint itself, use SPAN to mirror the port traffic, or rely on switch-side debug commands.

EAPOL does not carry user data. It exists solely for the authentication exchange. Once the port transitions to authorized, EAPOL may still be used periodically for re-authentication, but data traffic moves on normal Ethernet without any EAPOL encapsulation.

EAPOL Frame Structure

An EAPOL frame is an Ethernet frame with a specific structure:

Ethernet Header:

Destination MAC: 01:80:c2:00:00:03 (PAE group address, when supplicant initiates) or the unicast MAC of the authenticator (in responses)
Source MAC: Sender's MAC address
EtherType: 0x888E — this is the identifier for EAPOL traffic

EAPOL Header (immediately after EtherType):

Protocol Version (1 byte): 1, 2, or 3 depending on 802.1X version
Packet Type (1 byte): Identifies the EAPOL frame type (see below)
Packet Body Length (2 bytes): Length of the body that follows

EAPOL Body:

Present for types that carry EAP payloads; absent (length = 0) for EAPOL-Start and EAPOL-Logoff

The destination MAC 01:80:c2:00:00:03 is a well-known IEEE reserved multicast address for the Port Access Entity (PAE). Switches do not forward this multicast — they process it locally. This is why EAPOL is inherently link-local.

EAPOL Packet Types

The EAPOL Packet Type field identifies what kind of EAPOL message this is. There are six defined types:

Type 0x00 — EAP-Packet

The most common type. Carries a full EAP message (Request, Response, Success, or Failure) in the body. Most of the back-and-forth during authentication consists of EAPOL frames of this type carrying EAP-Request and EAP-Response messages.

Type 0x01 — EAPOL-Start

Sent by the supplicant to announce its presence and request authentication. The body length is zero — no payload. The destination is the PAE multicast 01:80:c2:00:00:03.

The authenticator can also trigger authentication without waiting for EAPOL-Start, by sending an EAP-Request/Identity after link comes up. In IOS XE, the authentication port-control auto command causes the switch to send an initial EAP-Request/Identity when the link comes up, without waiting for EAPOL-Start.

Type 0x02 — EAPOL-Logoff

Sent by the supplicant when it wants to terminate the authenticated session. This moves the port back to the unauthorized state. The body length is zero.

In practice, EAPOL-Logoff is often not sent when a user simply unplugs or shuts down. The switch detects link-down and clears the session. EAPOL-Logoff is more relevant in scenarios where the device stays physically connected but the user wants to end the authenticated session (uncommon on wired ports).

Type 0x03 — EAPOL-Key

Used for key derivation in MACsec (IEEE 802.1AE) scenarios where 802.1X is used to negotiate encryption keys. Not commonly encountered in standard NAC deployments without MACsec. If you see EAPOL-Key frames in a capture on a port not configured for MACsec, investigate — it may indicate a misconfigured supplicant or an unexpected MACsec negotiation.

Type 0x04 — EAPOL-Encapsulated-ASF-Alert

Used for Alert Standard Forum (ASF) remote management alerts. Rarely seen in enterprise 802.1X deployments. Mostly a theoretical concern.

Type 0x05 — EAPOL-MKA (MACsec Key Agreement)

Carries MACsec Key Agreement (MKA) PDUs. Relevant only in MACsec deployments. Like EAPOL-Key, not commonly seen in standard NAC-only configurations.

For troubleshooting standard 802.1X, you will primarily see Type 0x00 (EAP-Packet), Type 0x01 (EAPOL-Start), and occasionally Type 0x02 (EAPOL-Logoff).

The Complete EAPOL Exchange for PEAP Authentication

The following sequence shows the full EAPOL exchange for a Windows 11 endpoint authenticating with PEAP-MSCHAPv2 to ISE 3.2 through a Catalyst 9300. Each step is an EAPOL frame on the wire between endpoint and switch, unless noted as a RADIUS exchange (which happens between the switch and ISE, not on the access port).

Step 1: [Endpoint → Switch] EAPOL-Start (Type 0x01)
        Dst: 01:80:c2:00:00:03
        Src: a4:b2:3c:de:45:67
        EtherType: 0x888E
        EAPOL Type: 0x01 (EAPOL-Start)
        Body Length: 0

Step 2: [Switch → Endpoint] EAPOL EAP-Packet: EAP-Request/Identity (Type 0x00)
        Dst: a4:b2:3c:de:45:67
        Src: [Switch MAC]
        EAPOL Type: 0x00 (EAP-Packet)
        EAP Code: 1 (Request)
        EAP Type: 1 (Identity)
        EAP ID: 0x01

Step 3: [Endpoint → Switch] EAPOL EAP-Packet: EAP-Response/Identity (Type 0x00)
        EAPOL Type: 0x00 (EAP-Packet)
        EAP Code: 2 (Response)
        EAP Type: 1 (Identity)
        EAP ID: 0x01
        Identity: "anonymous@corp.com"  ← outer/anonymous identity

--- Switch encapsulates EAP into RADIUS Access-Request, sends to ISE ---

Step 4: [Switch → Endpoint] EAPOL EAP-Packet: EAP-Request/PEAP (Type 0x00)
        EAP Code: 1 (Request)
        EAP Type: 25 (PEAP)
        PEAP Flags: Start bit set
        EAP ID: 0x02

--- PEAP Phase 1: TLS Handshake (multiple round trips) ---

Step 5: [Endpoint → Switch] EAPOL EAP-Packet: EAP-Response/PEAP TLS Client Hello
Step 6: [Switch → Endpoint] EAPOL EAP-Packet: EAP-Request/PEAP TLS Server Hello + Certificate
Step 7: [Endpoint → Switch] EAPOL EAP-Packet: EAP-Response/PEAP TLS Client Key Exchange + Change Cipher Spec
Step 8: [Switch → Endpoint] EAPOL EAP-Packet: EAP-Request/PEAP TLS Change Cipher Spec + Finished

--- TLS Tunnel established. Phase 2 begins inside the tunnel. ---

Step 9:  [Switch → Endpoint] EAPOL EAP-Packet: PEAP inner EAP-Request/Identity
Step 10: [Endpoint → Switch] EAPOL EAP-Packet: PEAP inner EAP-Response/Identity (real username: CORP\jsmith)
Step 11: [Switch → Endpoint] EAPOL EAP-Packet: PEAP inner EAP-Request/MSCHAPv2 Challenge
Step 12: [Endpoint → Switch] EAPOL EAP-Packet: PEAP inner EAP-Response/MSCHAPv2 Response
Step 13: [Switch → Endpoint] EAPOL EAP-Packet: PEAP inner EAP-Request/MSCHAPv2 Success

--- ISE returns RADIUS Access-Accept with VLAN and policy attributes ---

Step 14: [Switch → Endpoint] EAPOL EAP-Packet: EAP-Success (Code 3)
         EAP Code: 3 (Success)
         EAP ID: [last ID]
         Body Length: 0

Port transitions to AUTHORIZED state. VLAN 10 applied.

The exact number of EAPOL frames during the TLS handshake (Steps 5-8) varies by TLS version and cipher suite. TLS 1.2 requires more round trips than TLS 1.3. Large certificates or certificate chains may require EAP fragmentation — the EAP payload is too large for a single frame and must be fragmented across multiple EAPOL frames using the fragment bit in the PEAP header.

EAP Fragmentation

EAP runs over Ethernet, which has an MTU of 1500 bytes. However, EAP is also limited by the RADIUS maximum attribute size — RADIUS EAP-Message attributes are capped at 253 bytes each, and a RADIUS packet can carry multiple EAP-Message attributes. ISE and IOS XE handle EAP fragmentation automatically.

The PEAP header includes a Length field and a More Fragments bit. When a large TLS record (like a server certificate) must be sent, it's split across multiple EAP-Packet frames with the More Fragments bit set. The receiver sends an empty EAP-Response to acknowledge each fragment, and the sender continues with the next fragment.

If you see many small EAPOL frames during what appears to be a TLS handshake in a capture, this is EAP fragmentation — not a problem. However, if you see fragmentation stall (many identical acknowledgment frames with no progress), it may indicate an MTU mismatch or a RADIUS packet size issue between the switch and ISE.

On IOS XE 17.9.x, the RADIUS attribute radius-server attribute 26 cisco 39 controls EAP chunking behavior. The default RADIUS packet size can be adjusted with ip radius source-interface and related commands if fragmentation issues arise.

Viewing EAPOL Activity on the Catalyst 9300

The primary tool for watching EAPOL in real time on IOS XE is debug dot1x all. This is a verbose debug — enable it only during troubleshooting and disable it immediately after.

SW1# debug dot1x all
Dot1x debugging is on

*Mar 19 14:23:01.442: %DOT1X-5-RX_EAPOL: Gi1/0/1 EAPOL packet received.
  type=0x1, version=1, len=0
*Mar 19 14:23:01.443: %DOT1X-5-TX_EAPOL: Gi1/0/1 Sending EAP Request Id 0x01
*Mar 19 14:23:01.512: %DOT1X-5-RX_EAPOL: Gi1/0/1 EAPOL packet received.
  type=0x0, version=2, len=18
*Mar 19 14:23:01.513: %DOT1X-5-AUTH_SUCC: Gi1/0/1 Supplicant a4b2.3cde.4567
  authenticated by Auth Manager
*Mar 19 14:23:01.516: %AUTHMGR-5-SUCCESS: Authorization succeeded for client
  (a4b2.3cde.4567) on Interface Gi1/0/1 AuditSessionID 0A00630A0000001F2B8C3A00

The debug output shows:

RX_EAPOL type=0x1 — received EAPOL-Start from the endpoint
TX_EAPOL Sending EAP Request Id — switch sent EAP-Request/Identity
RX_EAPOL type=0x0 — received EAP-Response (the subsequent EAP exchange continues)
AUTH_SUCC — authentication completed successfully

Disable the debug immediately after capturing what you need:

SW1# no debug dot1x all

For a less disruptive view, show dot1x statistics interface GigabitEthernet1/0/1 shows frame counts:

SW1# show dot1x statistics interface GigabitEthernet1/0/1

Dot1x Statistics for GigabitEthernet1/0/1
--------------------------------------------
RxVersion         = 2
LastRxSrcMAC      = a4b2.3cde.4567
RxTotal           = 14
RxStart           = 1
RxLogoff          = 0
RxResp            = 11
RxRespID          = 1
RxReq             = 0
RxInvalid         = 0
RxLenErr          = 0
RxTotal           = 14
TxStart           = 0
TxLogoff          = 0
TxResp            = 0
TxReq             = 13
TxReqID           = 1
TxInvalid         = 0
TxLenErr          = 0
TxTotal           = 14

This shows 14 received EAPOL frames (1 EAPOL-Start, 11 EAP responses, 1 Identity response) and 14 transmitted (1 Identity request, 12 EAP requests). Frame counts consistent with a successful PEAP exchange.

EAPOL and the Pre-Authentication State

In the unauthorized state, the switch port only passes EAPOL frames. All other Ethernet frames are dropped (in Closed mode) or restricted to pre-auth ACL-permitted traffic (in Low-Impact mode). This is enforced at the hardware level in the Catalyst 9300's ASICs.

The EAPOL-only filtering is what allows the switch to accept the authentication exchange without giving the endpoint any network access. The port is "open" at the physical layer but "closed" at the forwarding layer.

After the EAPOL exchange completes and the port authorizes, the endpoint's MAC is installed in the CAM table with full forwarding capability. EAPOL continues to be processed if re-authentication is triggered, but it no longer blocks other traffic.

What Happens When EAPOL Is Missing

If a device with no 802.1X supplicant is plugged in:

The switch sends EAPOL-Request/Identity (if dot1x pae authenticator is configured on the port)
No EAPOL-Response arrives
The switch retransmits EAPOL-Request/Identity up to dot1x max-reauth-req times (default 2, with dot1x timeout tx-period interval, default 30 seconds)
After timeout, if MAB is configured, the switch initiates MAC Authentication Bypass
If no MAB, the port stays unauthorized

The timer behavior means a non-802.1X device without MAB configured takes approximately 60-90 seconds to give up. During a phased deployment, this causes complaints about slow port activation. Tuning dot1x timeout tx-period (e.g., to 10 seconds) reduces this delay at the cost of more EAPOL retransmissions from legitimate supplicants in noisy environments.

Troubleshooting EAPOL Issues

Symptom: EAPOL-Start frames sent but no response from switch

Cause: The port is not configured for 802.1X (dot1x pae authenticator missing, or authentication port-control is set to force-authorized)
Fix: Verify port configuration with show dot1x interface GigabitEthernet1/0/x. Ensure authentication port-control auto and dot1x pae authenticator are present.

Symptom: EAP-Request/Identity sent but endpoint does not respond

Cause: Supplicant service not running on the endpoint (Windows Wired AutoConfig service stopped or disabled), supplicant not configured for the port, or endpoint has 802.1X disabled on this adapter
Fix: On Windows, verify Wired AutoConfig (dot3svc) is running (Get-Service dot3svc in PowerShell). Check adapter authentication settings. On the switch, show dot1x statistics interface will show RxTotal increasing only if EAPOL frames are being received.

Symptom: EAP exchange begins but stalls mid-handshake (TLS fragmentation issue)

Cause: Large certificates causing EAP fragmentation, with the switch or endpoint dropping or mis-ordering fragments; or RADIUS EAP-Message attribute handling issue between switch and ISE
Fix: Capture EAPOL on the endpoint with Wireshark (filter: eap). Identify where the exchange stalls. Check ISE certificate chain length — long chains fragment heavily. Consider reducing certificate chain size (don't send full chain, only the leaf and intermediate). Verify ip radius source-interface is configured on the switch.

What's Next: Article 5: Understanding RADIUS in 802.1X Authentication — how RADIUS carries EAP between the authenticator and authentication server, the RADIUS packet types and attributes used in 802.1X, and how ISE returns VLAN and policy data inside RADIUS Access-Accept messages.