Imagine a hospital where anyone in a white coat can walk into any room. That's a network without 802.1X — any device that plugs in gets access. 802.1X is the bouncer that checks ID (credentials or certificate) before letting a device onto the network. For CCNA 200-301, this is a core troubleshooting scenario under exam objective 5.4: 'Troubleshoot 802.1X authentication failing.' In real networks, a broken 802.1X deployment means guests get full access or authenticated users get locked out — both are security incidents waiting to happen.
Jump to a section
Think of 802.1X as airport security. The supplicant is you (the passenger) with your boarding pass and ID. The authenticator is the TSA agent at the checkpoint who scans your ID and checks your boarding pass. The authentication server (RADIUS) is the airline's database that confirms your booking and identity. Initially, the checkpoint lane is blocked by a turnstile (the port is unauthorized). You approach and hand over your ID (EAPOL-Start). The agent scans it and sends your info to a computer (RADIUS Access-Request). The computer checks the database (RADIUS server compares credentials). If valid, the computer sends back an 'Access-Accept' message. The agent then unlocks the turnstile, and you proceed to your gate (port becomes authorized). If your ID is fake or your flight is cancelled, the computer sends 'Access-Reject', and the agent keeps the turnstile locked — you're stuck. In networking, the turnstile is a switch port that starts in an 'unauthorized' state, blocking all traffic except EAPOL. The agent (authenticator) doesn't make the decision; it just relays messages between you and the computer. If the computer is down (RADIUS server unreachable), the agent might have a fallback rule: let everyone through (critical auth) or keep everyone locked (default deny). A common failure: you swipe your boarding pass but the agent's scanner is broken — that's a misconfigured RADIUS shared secret. Another: you have a valid ticket but the computer says you don't — that's a bad username or certificate mismatch. The analogy breaks down slightly because in 802.1X the authenticator doesn't actually see the credentials (they're encrypted), but the relay function is identical.
What is 802.1X and Why Does It Exist?
802.1X is a port-based network access control (PNAC) standard defined by IEEE. It prevents unauthorized devices from gaining access to a LAN by authenticating each device before allowing any data traffic. On a Cisco switch, a port configured for 802.1X starts in an unauthorized state — only Extensible Authentication Protocol over LAN (EAPOL) frames are permitted. Once the device (supplicant) successfully authenticates with a RADIUS server, the port transitions to authorized and normal traffic flows.
The Three Roles
Supplicant: The client device (e.g., laptop with a 802.1X supplicant like Windows' native or a third-party client). It initiates authentication by sending EAPOL-Start or responds to an Identity Request.
Authenticator: The network device (switch or wireless access point) that enforces port control. It relays EAP messages between supplicant and RADIUS server. It does NOT make the final decision.
Authentication Server (AS): Typically a RADIUS server (Cisco ISE, FreeRADIUS, Microsoft NPS). It validates credentials and tells the authenticator whether to authorize the port.
Step-by-Step Packet Flow
Port Initial State: The switch port is in the unauthorized state. It blocks all traffic except EAPOL. The switch may send an EAP-Request/Identity frame periodically (default: 30 seconds) to detect a supplicant.
Supplicant Initiates: The supplicant sends an EAPOL-Start frame (multicast MAC 01:80:C2:00:00:03) to the switch. If the switch doesn't respond, the supplicant may retry after a timeout (typically 30 seconds).
Identity Exchange: The switch replies with EAP-Request/Identity. The supplicant responds with EAP-Response/Identity (containing the username).
RADIUS Communication: The switch encapsulates the EAP-Response in a RADIUS Access-Request packet (using the shared secret to create an MD5 hash of the password field). The RADIUS server receives it and may challenge the supplicant (e.g., EAP-MD5, PEAP, EAP-TLS).
EAP Method Negotiation: For PEAP, the server sends an EAP-Request with a TLS start flag. The supplicant and server establish a TLS tunnel. Inside the tunnel, the server requests identity again (inner identity) and validates credentials.
Authentication Decision: The RADIUS server sends RADIUS Access-Accept (with attributes like VLAN assignment or ACL name) or Access-Reject. The switch receives it and sets the port to authorized (or keeps it unauthorized).
Port Authorized: The switch opens the port. The supplicant can now send normal traffic. The switch may start a re-authentication timer (default: 3600 seconds) after which the process repeats.
Key Timers and Defaults
tx-period: 30 seconds. Time between EAP-Request/Identity retransmissions if no response.
supp-timeout: 30 seconds. Time the switch waits for a response from the supplicant before retransmitting.
server-timeout: 30 seconds. Time the switch waits for a RADIUS response.
re-authperiod: 3600 seconds (1 hour). Interval for re-authentication.
quiet-period: 60 seconds. Time the switch waits after a failed authentication before trying again.
max-req: 2. Number of times the switch retransmits an EAP request to the supplicant.
IOS CLI Verification Commands
show authentication sessions interface GigabitEthernet0/1Example output:
Interface: GigabitEthernet0/1
MAC Address: aaaa.bbbb.cccc
IP Address: 192.168.1.10
Status: Authz Success
Domain: DATA
Oper host mode: single-host
Oper control dir: both
Session timeout: N/A
Common Session ID: 0A0B0C0D0000001A12345678
Acct Session ID: 0x00000001
Handle: 0x00000001
Current Policy: default
Local Policies:
VLAN: 100
ACS ACL: xACSACLx-IP-permit_all-12345678
Server Policies:
VLAN: 100
ACS ACL: xACSACLx-IP-permit_all-12345678
Method status list:
Method: dot1x
State: Authz Successshow dot1x allSysauthcontrol Enabled
Dot1x Protocol Version 3
Max Auth req 2
Reauthperiod 3600
Quiet Period 60
Tx Period 30
Supplicant Timeout 30
Server Timeout 30debug dot1x allUse with caution in production. Shows EAPOL frame exchange.
Interaction with Related Protocols
RADIUS: 802.1X relies on RADIUS for authentication and authorization. RADIUS attributes like Tunnel-Private-Group-ID (VLAN) or Filter-Id (ACL) are passed from server to switch.
MAB (MAC Authentication Bypass): If the device does not support 802.1X (e.g., printer), the switch can fall back to MAB, which uses the MAC address as the credential.
VLAN Assignment: The RADIUS server can return a VLAN ID that the switch dynamically assigns to the port after authentication.
Guest VLAN: A special VLAN for unauthenticated devices (e.g., internet-only access). Configured with authentication event fail retry 3 action authorize vlan <vlan-id>.
Critical Auth: If RADIUS servers are unreachable, the switch can place the port in a critical VLAN or keep it unauthorized.
Common Failure Points
Supplicant not responding: Check if the client has 802.1X enabled. Windows: netsh lan show interfaces. Linux: wpa_supplicant.
RADIUS server unreachable: Use test aaa group radius <username> <password> or debug radius authentication.
Shared secret mismatch: RADIUS server logs show 'Invalid Signature' or 'Discarding packet'.
Certificate issues: For EAP-TLS/PEAP, the server certificate must be trusted by the supplicant. Check expiry and CA chain.
VLAN mismatch: The RADIUS-assigned VLAN must exist on the switch and be allowed on the trunk.
Port security conflict: If port security is enabled, it may block the MAC after authentication.
Verify Port Authentication State
Begin by checking the current authentication state on the switch port. Use `show authentication sessions interface <interface>` or `show dot1x interface <interface>`. Look for the 'Status' field. If it shows 'Authz Success', the port is authorized. If 'Authz Failed', the authentication was rejected. If 'Authz Pending', the process is ongoing. Also check the 'Method status list' to see which method (dot1x, mab) is in what state. For example: ``` show authentication sessions interface GigabitEthernet0/1 ``` If the status is 'Authz Failed', note the failure reason (e.g., 'No response from supplicant', 'RADIUS server unreachable'). If the status is 'Not Running', 802.1X may be disabled globally or on the interface. Verify with `show dot1x all` to see if 'Sysauthcontrol' is enabled.
Check RADIUS Server Reachability
If the port is in 'Authz Pending' or 'Authz Failed' with a RADIUS timeout, test connectivity to the RADIUS server. Use `ping <radius-server-ip>` from the switch. Then test AAA with `test aaa group radius <username> <password> new-code`. This sends a test authentication request. The output shows 'Success' or 'Failed'. Also check RADIUS server logs. Common issues: IP reachability, UDP ports 1812 (authentication) and 1813 (accounting) blocked, or shared secret mismatch. Use `debug radius authentication` to see packets, but be careful in production. Example: ``` debug radius authentication ``` Look for 'Invalid Signature' errors, which indicate a shared secret mismatch.
Examine Supplicant Configuration
If the switch and RADIUS server are fine, the problem may be on the client. On Windows, run `netsh lan show interfaces` to see if 802.1X is enabled. Check the service 'Wired AutoConfig' (dot3svc) is running. On Linux, check `wpa_supplicant` configuration. Ensure the client has the correct EAP method (PEAP, EAP-TLS, EAP-MD5) and credentials. Also verify the client trusts the RADIUS server's certificate for TLS-based methods. A common mistake: the client sends EAPOL-Start but the switch doesn't respond because the port is in 'unauthorized' state and only accepts EAPOL. If the client sends normal traffic first, it may be dropped. Use a packet capture on the client to see if EAPOL frames are being sent and received.
Validate Switch 802.1X Configuration
Review the global and interface 802.1X configuration. Global: `dot1x system-auth-control` must be enabled. Interface: `authentication port-control auto` sets the port to 802.1X. `dot1x pae authenticator` is needed for the switch to act as authenticator. Check for conflicting commands: `switchport mode access` is required; `switchport mode trunk` will cause issues unless `dot1x` is configured for trunk ports (rare). Also verify that the RADIUS server group is correctly defined. Use: ``` show running-config | section radius show running-config interface GigabitEthernet0/1 ``` Look for `aaa authentication dot1x default group radius` and `aaa authorization network default group radius`. If missing, authentication will fail.
Analyze RADIUS Server Logs and Attributes
RADIUS server logs provide the definitive reason for rejection. Common reasons: invalid username/password, certificate validation failure, or the server sends an Access-Reject due to policy. Also check the attributes returned. If the server sends a VLAN ID that doesn't exist on the switch, the port may go into a 'failed' state. Use `show authentication sessions interface <interface> details` to see the VLAN assigned. The RADIUS server may also send a downloadable ACL (dACL) — ensure the switch can parse it. On Cisco ISE, check 'Live Logs' for the authentication attempt. Look at the 'Failure Reason' field. Example: '22056 Authentication failed due to invalid credentials'.
Isolate with Fallback Methods
If 802.1X is failing, test with MAB (MAC Authentication Bypass) as a fallback. Configure `authentication order dot1x mab` on the interface. If MAB succeeds, the issue is with the supplicant or EAP method. If MAB also fails, the problem is likely RADIUS connectivity or server policy. Also consider configuring a guest VLAN for unauthenticated devices. Use `authentication event fail retry 3 action authorize vlan <guest-vlan>`. This allows devices that fail authentication to get limited access. To test, you can temporarily set `authentication port-control auto` and see if the port authorizes after a failed attempt. Use `show authentication sessions` to see the VLAN after failure.
In a typical enterprise, 802.1X is deployed on all wired access ports to enforce network access control. For example, a company with 10,000 employees uses Cisco ISE as the RADIUS server. Each switch port is configured with authentication port-control auto and dot1x pae authenticator. The RADIUS server assigns VLANs based on user role: employees get VLAN 10, contractors get VLAN 20, and guests get VLAN 30. A common problem: a new employee's laptop fails authentication because the IT department forgot to add the user to the Active Directory group that ISE queries. The port stays unauthorized, and the user calls the help desk. The network engineer logs into the switch, runs show authentication sessions interface Gi1/0/1, sees 'Authz Failed', then checks ISE logs and finds 'User not found in identity store'. After adding the user, the port authorizes.
Another scenario: a printer that doesn't support 802.1X. The engineer configures MAB as a fallback: authentication order dot1x mab. The printer's MAC is added to the RADIUS server's MAC address database. When the printer connects, it doesn't send EAPOL, so after a timeout the switch tries MAB, sends the MAC as the username/password, and the server authenticates it. If the MAC is not in the database, the printer ends up in the guest VLAN, which may not have the necessary print server access. The engineer then adds the MAC and re-authenticates.
A third scenario: a large-scale deployment with hundreds of switches. A misconfigured RADIUS shared secret on one switch causes all users on that switch to fail authentication. The engineer uses debug radius authentication on the switch and sees 'Invalid Signature' errors. The fix is to update the shared secret on both the switch and the RADIUS server. Performance considerations: each authentication takes about 1-2 seconds. With thousands of devices booting up simultaneously (e.g., after a power outage), the RADIUS server may be overwhelmed. Engineers often configure radius-server dead-criteria to mark servers as dead faster and use multiple RADIUS servers. Misconfiguration can lead to a complete network outage if the critical auth fallback is not set correctly — for example, if RADIUS servers are unreachable and the switch is configured to deny all access, no one can connect.
On the CCNA 200-301 exam, objective 5.4 expects you to troubleshoot 802.1X authentication failures. Cisco tests your ability to identify the root cause from a given scenario and choose the correct corrective action. Expect scenario-based questions where you see a switch configuration snippet and a RADIUS server log entry. You must determine why authentication failed.
Common Wrong Answers and Why Candidates Choose Them:
1. 'The supplicant is not sending EAPOL-Start.' While this is a possible cause, exam scenarios often show that the supplicant is configured correctly. Candidates jump to this because it's the first step, but the real issue might be a RADIUS timeout or shared secret mismatch. Always check RADIUS first.
2. 'The switch port is in trunk mode.' Yes, 802.1X is designed for access ports, but the exam may show a port configured as trunk with dot1x enabled — that actually works if properly configured. The more likely issue is that switchport mode access is missing.
3. 'The RADIUS server is down.' Candidates often assume server failure, but the exam may show that the server is reachable via ping but the shared secret is wrong. Use test aaa to differentiate.
4. 'The port is in errdisable state.' While errdisable can occur (e.g., due to port security violation), 802.1X failure alone does not cause errdisable. The port stays in 'unauthorized' state.
Specific Values and Commands on the Exam:
- Default tx-period = 30 seconds.
- Default quiet-period = 60 seconds.
- show authentication sessions interface is the go-to command.
- debug dot1x all and debug radius authentication are used for advanced troubleshooting.
Decision Rule for Scenario Questions: 1. Check the authentication status on the switch (show authentication sessions). 2. If 'Authz Failed', check RADIUS logs or test AAA. 3. If 'Authz Pending', check timers and supplicant. 4. If 'Not Running', check global and interface configuration.
Eliminate answers that blame the supplicant when RADIUS logs show 'Invalid Signature' or when the switch shows 'RADIUS server unreachable'.
802.1X uses three roles: supplicant (client), authenticator (switch), and authentication server (RADIUS).
Default timers: tx-period 30s, quiet-period 60s, re-authperiod 3600s, server-timeout 30s.
Use 'show authentication sessions interface' to see authorization status and method states.
Use 'test aaa group radius username password new-code' to test RADIUS authentication from the switch.
A shared secret mismatch causes 'Invalid Signature' errors in debug radius output.
MAB is a fallback method that uses the MAC address as credentials for non-802.1X devices.
Guest VLAN and critical auth provide limited access when authentication fails or RADIUS is unreachable.
These come up on the exam all the time. Here's how to tell them apart.
802.1X
Uses EAPOL frames for authentication.
Can use various EAP methods (PEAP, EAP-TLS, EAP-MD5).
Provides user-based authentication (credentials).
Requires supplicant software on the client.
More secure because credentials are not sent in clear (except EAP-MD5).
MAB (MAC Authentication Bypass)
Uses the source MAC address as the credential.
No EAP method; simple RADIUS request with MAC as username and password.
Provides device-based authentication (MAC address).
No supplicant required; works with any device.
Less secure because MAC addresses can be spoofed.
Mistake
802.1X requires the supplicant to send an EAPOL-Start frame to begin authentication.
Correct
The switch can initiate authentication by sending an EAP-Request/Identity frame (if the switch is configured to do so). The supplicant can also send EAPOL-Start, but it's not mandatory.
Candidates often memorize the EAPOL-Start as the first step, but the switch can be the initiator.
Mistake
The authenticator (switch) makes the final authentication decision.
Correct
The authenticator only relays EAP messages. The RADIUS server makes the final decision (Access-Accept or Access-Reject). The switch enforces the decision.
The term 'authenticator' suggests it authenticates, but it actually only controls port state based on server response.
Mistake
If the RADIUS server is unreachable, the switch keeps the port in the unauthorized state by default.
Correct
By default, if no RADIUS server is reachable, the switch will fail the authentication and the port remains unauthorized. However, 'critical auth' can be configured to allow access in such scenarios.
Candidates may think the switch has a default 'fail open' behavior, but the default is 'fail closed'.
Mistake
802.1X only works on access ports, not trunk ports.
Correct
802.1X can be configured on trunk ports, but it is more complex and less common. The CCNA focuses on access ports.
Many CCNA materials only show access port configuration, leading to this misconception.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
802.1X uses EAPOL frames to authenticate a user or device with credentials (username/password or certificate). It requires a supplicant on the client. MAB (MAC Authentication Bypass) uses the device's MAC address as the credential and does not require a supplicant. MAB is typically used for devices like printers that do not support 802.1X. Both rely on a RADIUS server for the authentication decision. On the exam, remember that MAB is less secure because MAC addresses can be spoofed. You can configure both methods on the same port with a fallback order: `authentication order dot1x mab`.
To configure a guest VLAN, use the command `authentication event fail retry 3 action authorize vlan <vlan-id>` on the interface. This means that after 3 failed authentication attempts, the switch will place the port in the specified guest VLAN, granting limited access. You also need to create the VLAN and ensure the switch can route traffic appropriately. The guest VLAN is often used to provide internet-only access to visitors. On the exam, know that the default number of retries is 3 and that the guest VLAN must be configured on the switch.
This command shows the authentication state of a specific interface. Key fields: 'Status' (Authz Success, Authz Failed, Authz Pending), 'Domain' (DATA or VOICE), 'Oper host mode' (single-host or multi-host), and 'Method status list' (which authentication methods are in what state). It also shows the VLAN assigned by the RADIUS server and any applied ACL. This is the primary command for troubleshooting 802.1X on Cisco switches.
This error indicates that the switch sent an EAP-Request/Identity frame but the client did not respond. Possible causes: (1) The client does not have 802.1X enabled (e.g., Windows Wired AutoConfig service is stopped). (2) The client is not configured with the correct EAP method. (3) There is a layer 1 issue (cable, NIC). (4) The client is using a different authentication protocol (e.g., it's trying to use EAP over RADIUS directly). To fix, check the client's 802.1X settings and ensure the service is running. Use a packet capture to see if EAPOL frames are being sent.
Yes, 802.1X can be configured on a trunk port, but it is more complex. On a trunk, the switch must authenticate the device before allowing any VLAN traffic. This is less common and typically used for specialized scenarios like authenticating a switch or IP phone. For CCNA, focus on access ports. If you see a trunk port in a troubleshooting scenario, check if the port is configured as an access port — misconfiguration is a common exam trap.
By default, if the RADIUS server is unreachable, the switch will fail the authentication and the port remains in the unauthorized state. This is called 'fail closed'. To change this, you can configure 'critical authentication' with the `authentication critical` command, which allows the port to become authorized even if the server is down (often placing the device in a critical VLAN). On the exam, know that the default is fail closed, and that critical auth must be explicitly configured.
Use the command `test aaa group radius <username> <password> new-code`. This sends a test authentication request to the configured RADIUS server. The output shows 'Success' if authentication passes, or 'Failed' with a reason. You can also use `test aaa group radius <username> <password> legacy` for older servers. This command is invaluable for isolating whether the problem is with the RADIUS server or the supplicant.
You've just covered Troubleshoot: 802.1X Authentication Failing — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?