Switch-Side 802.1X Configuration

Objective

In this lesson you will configure 802.1X on Catalyst switches: enable system-wide 802.1X, point the switch at a RADIUS server, configure per-port authentication host-modes, and tune 802.1X timers. This matters in production because switches act as the gateway that enforces network access — incorrect switch-side configuration prevents endpoints from authenticating, causes long connectivity delays, or allows unauthorized devices. A real-world scenario: a corporate office uses 802.1X with EAP-TLS for user device authentication and MAC Authentication Bypass (MAB) for printers; the switch must be configured to forward EAP messages to the RADIUS server reliably and to handle large client certificates without timing out.

Quick Recap

This lesson continues from Lesson 1's topology (switch connecting APs/WLC and a RADIUS server). No new devices or IPs are added in this lesson — we focus only on switch-side configuration and verification. Recall the wireless/EAP flow concepts from the reference: WLC/AP forward EAP messages to RADIUS; EAP Packet ID and RADIUS Identifier consistency is critical for session correlation; fragmentation may be required for large certificates (EAP-TLS).

ASCII topology (same as Lesson 1 — IPs intentionally omitted here as no new IPs are introduced):

Switch (Catalyst) ----- CAPWAP ---- AP/WLC ----- RADIUS Server | | |-- Wired ports for endpoints

Tip: The switch is the authenticator in 802.1X terminology — the AP/WLC or switch forwards EAP messages to the RADIUS server. The behavior you configure on the switch determines how and when EAP messages are relayed.

Key Concepts (theory + practical implications)

• 802.1X roles: The switch is the authenticator; the endpoint is the supplicant; the RADIUS server is the authentication server. The switch forwards EAP frames (EAPoL) to the RADIUS server encapsulated in RADIUS Access-Request messages. In production, the switch isolates unauthenticated endpoints at Layer 2 until authentication succeeds.
• EAP-TLS fragmentation: Client certificates can be large (often 2,200–8,000 bytes). If the EAP message exceeds transport limits, fragmentation happens. The switch must correctly relay fragmented EAP packets to avoid failed authentications. In wireless scenarios, CAPWAP and WLC/AP also retain EAP Packet ID consistency while forwarding.
• EAP Packet ID / RADIUS Identifier consistency: The RADIUS server assigns an EAP Packet ID for each EAP message; that ID is kept throughout the exchange. The RADIUS Identifier remains consistent for one transaction. This consistency is how the switch and RADIUS correlate requests and responses — mismatches cause session failures.
• Host modes: Switch ports can be configured for single-host, multi-host, or multi-auth modes. For example, multi-auth permits multiple authenticated MACs on one port (useful for desktop + IP phone scenarios); single-host restricts to one MAC (useful for endpoint security).
• Timers: 802.1X timers (transmit period, server-timeout, quiet-period, reauthenticate interval) control retries and reauthentication cadence. Misconfigured timers can cause long waits for users or excessive RADIUS traffic.

Step-by-step configuration

Step 1: Prepare AAA and RADIUS server configuration

What we are doing: Enable AAA, configure a RADIUS server entry, and set 802.1X to use the RADIUS group for authentication. This step tells the switch where to send Access-Request messages and which authentication method to use.

configure terminal
aaa new-model
radius-server host 10.10.10.10 auth-port 1812 key Lab@123
aaa authentication dot1x default group radius
exit

What just happened:

• aaa new-model enables the AAA subsystem. Without AAA, the switch cannot use RADIUS for 802.1X.
• radius-server host 10.10.10.10 auth-port 1812 key Lab@123 creates the RADIUS server entry with shared secret Lab@123 (used to authenticate RADIUS packets).
• aaa authentication dot1x default group radius instructs the switch to use the configured RADIUS server group for 802.1X authentication decisions.

Real-world note: Use secure, unique shared secrets and consider using IPsec or management-plane protections between switch and RADIUS in production.

Verify:

show running-config | section aaa
radius-server host 10.10.10.10 auth-port 1812 key Lab@123
aaa new-model
aaa authentication dot1x default group radius

Expected output (complete):

!--- Output begins
aaa new-model
!
radius-server host 10.10.10.10 auth-port 1812 key Lab@123
!
aaa authentication dot1x default group radius
!--- Output ends

Step 2: Enable 802.1X globally on the switch

What we are doing: Turn on the 802.1X system service so per-interface 802.1X commands will take effect. Without enabling globally, per-port authentication commands are ignored.

configure terminal
dot1x system-auth-control
exit

What just happened:
dot1x system-auth-control enables 802.1X operation on the switch. The switch will now process per-interface 802.1X settings and generate EAPoL traffic for connected supplicants. The switch will also forward EAP messages to the RADIUS server per the AAA configuration.

Real-world note: Always enable 802.1X during a maintenance window in production — enabling globally can immediately change access behavior.

Verify:

show dot1x all

Expected output (sample):

!--- Output begins
Dot1X System Status: Enabled
System auth-control: enabled
Number of authentications: 0
Number of supplicants: 0
Timeouts: tx-period 30 sec, reauth-period 3600 sec, quiet-period 60 sec, server-timeout 30 sec
!--- Output ends

Step 3: Configure per-interface 802.1X settings (host-mode, port-control, MAC bypass)

What we are doing: Configure a user-facing access port to require 802.1X authentication, set the host-mode to multi-auth (allow multiple authenticated devices), enable MAB as fallback for non-802.1X devices, and enable periodic/reauthentication timers. This step defines how the switch treats connected endpoints.

configure terminal
interface GigabitEthernet1/0/5
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 authentication host-mode multi-auth
 authentication port-control auto
 authentication periodic
 authentication timer reauthenticate 3600
 mab
 exit

What just happened:

• switchport mode access and switchport access vlan 10 make the port an access port in VLAN 10 — unauthenticated traffic is kept in the unauthorized VLAN until access is granted.
• spanning-tree portfast reduces STP convergence delay for end-host ports.
• authentication host-mode multi-auth allows multiple endpoints on the same port to be authenticated independently (useful for desktops behind a switch or IP phone scenarios).
• authentication port-control auto places the port in unauthorized state and waits for EAP authentication to succeed.
• authentication periodic and authentication timer reauthenticate 3600 enable periodic reauthentication every 3600 seconds (1 hour).
• mab enables MAC Authentication Bypass — if the supplicant does not speak 802.1X, the switch will attempt to authenticate the host by MAC address against RADIUS.

Real-world note: Choose host-mode based on port function. Use single-host for locked-down desktops, multi-auth for ports with phones + PCs, and be careful with MAB as it authenticates by MAC (less secure than 802.1X).

Verify:

show running-config interface GigabitEthernet1/0/5

Expected output (complete):

!--- Output begins
interface GigabitEthernet1/0/5
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 authentication host-mode multi-auth
 authentication port-control auto
 authentication periodic
 authentication timer reauthenticate 3600
 mab
!--- Output ends

Step 4: Tune 802.1X timers to accommodate large EAP-TLS certificates

What we are doing: Increase EAP timeout values to account for large EAP-TLS certificate exchanges and potential fragmentation. This reduces false timeouts during certificate transfer phases (Phase 3 and Phase 4 of EAP-TLS). The reference notes certificates can be 2,200–8,000 bytes; longer transfers may be required.

configure terminal
dot1x timeout tx-period 30
dot1x timeout server-timeout 60
dot1x timeout quiet-period 60
exit

What just happened:

• dot1x timeout tx-period 30 sets the wait between retransmissions of EAP packets to 30 seconds.
• dot1x timeout server-timeout 60 increases the time the switch waits for a RADIUS reply before treating the server as non-responsive.
• dot1x timeout quiet-period 60 sets the period the authenticator will suppress further authentication attempts after a server failure.
  These longer timers allow the EAP-TLS handshake and certificate fragmentation to complete, preventing spurious failures.

Real-world note: Increasing timers helps with large certificates or congested links but raises the time a malicious device may remain in an intermediate state; tune conservatively.

Verify:

show dot1x timeout

Expected output (complete):

!--- Output begins
EAPOL retransmit tx-period: 30 seconds
Server timeout: 60 seconds
Quiet period: 60 seconds
Reauthenticate period (per port default): 3600 seconds
!--- Output ends

Step 5: Verify authentication sessions and observe EAP/RADIUS identifiers

What we are doing: Use operational show commands to observe active authentication sessions and confirm that EAP packet IDs and RADIUS identifiers are flowing as expected. Verifying at this stage ensures the switch is correctly forwarding EAPoL to RADIUS and handling replies.

show authentication sessions interface GigabitEthernet1/0/5 detail
show radius statistics

What just happened:

• show authentication sessions ... detail displays session state, whether the port is in unauthorized vs authorized state, the method (dot1x or mab), and timers. It provides insight into whether the client completed EAP-TLS phases.
• show radius statistics (or equivalent on the platform) shows RADIUS requests/replies counts and retransmits; useful to detect timeouts or mismatches with RADIUS Identifiers.

Real-world note: If you see repeated retries with no Access-Accept, check RADIUS logs and confirm EAP packet ID/RADIUS Identifier consistency between switch and RADIUS server (refer to packet captures if needed).

Verify (sample outputs):

show authentication sessions interface GigabitEthernet1/0/5 detail

Expected output (complete, sample):

!--- Output begins
Interface: GigabitEthernet1/0/5
 MAC Address: 0011.2233.4455
 Session ID: 0x00000001
 Method: dot1x
 Domain: default
 State: AUTHORIZED
 VLAN: 10
 Reauth time left: 3595 seconds
 Last authentication type: EAP-TLS
 Server: 10.10.10.10
 EAP packet id last seen: 31
 RADIUS identifier last seen: 143
!--- Output ends

show radius statistics

Expected output (complete, sample):

!--- Output begins
RADIUS Server 10.10.10.10
 Auth Requests Sent: 12
 Auth Replies Received: 12
 Auth Timeouts: 0
 Accounting Requests Sent: 0
 Accounting Replies Received: 0
 Last Auth Request ID: 143
!--- Output ends

Verification Checklist

• Check 1: Global 802.1X is enabled — verify with show dot1x all and confirm "System auth-control: enabled".
• Check 2: Per-port 802.1X is configured and in expected state — verify with show authentication sessions interface GigabitEthernet1/0/5 detail and confirm "State: AUTHORIZED" after successful auth.
• Check 3: RADIUS communication successful and identifiers consistent — verify with show radius statistics and compare RADIUS identifier in authentication session output to RADIUS logs/pcap.

Common Mistakes

Symptom	Cause	Fix
Port remains in "UNAUTHORIZED" indefinitely	dot1x system-auth-control not enabled or AAA not configured	Enable dot1x system-auth-control and ensure aaa authentication dot1x points to RADIUS
Authentication times out during EAP-TLS (large certs)	Default tx-period/server-timeout too short for certificate fragmentation	Increase dot1x timeout tx-period and dot1x timeout server-timeout to accommodate fragmentation
Multiple devices on a single port are blocked after first device authenticates	Port is in single-host mode	Change to authentication host-mode multi-auth or multi-domain as appropriate
Devices authenticate via MAB unexpectedly	MAB enabled and MAC addresses present in RADIUS	Disable mab where not required or remove MAC entries from RADIUS
RADIUS replies not correlated to requests (failed sessions)	RADIUS Identifier/EAP Packet ID mismatch due to intermediary device mishandling	Capture packets on switch and RADIUS to confirm identifier consistency; ensure intermediate devices do not rewrite identifiers

Key Takeaways

• The switch is the 802.1X authenticator; it must be pointed to a RADIUS server via AAA and dot1x system-auth-control enabled to function. Remember: without AAA + dot1x global enable, per-port settings are inert.
• Large EAP-TLS certificates require attention to timers and possible fragmentation. Increase tx-period and server-timeout to avoid premature timeouts in production.
• Host modes control port behavior for multiple endpoints: choose single-host, multi-auth, or multi-domain according to port usage (desktop, phone+PC, or data/voice separation).
• Always verify both the local switch session state and RADIUS statistics. Pay attention to EAP Packet IDs and RADIUS Identifiers — consistency across the transaction is how the authenticator and server match requests and replies.

Important: In production, coordinate changes with RADIUS administrators, use packet captures when troubleshooting EAP-TLS failures, and gradually roll out 802.1X to avoid widespread access interruptions.

---

If you want, in Lesson 3 we will capture and analyse EAP/RADIUS packets (pcap examples) to identify EAP Packet ID and RADIUS Identifier mismatches and address fragmentation issues in detail.