Hands-On Lab: Configuring 802.1X Port-Based Authentication

This hands-on lab configures 802.1X on a switch port requiring RADIUS-based authentication before granting network access, verifying an unauthenticated device is blocked while a properly authenticated device is granted access to the assigned VLAN.

802.1X ConfigurationPort-Based AuthenticationRADIUS Supplicant Authenticator

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure 802.1X authentication on a switch port using RADIUS as the authentication server, verify an unauthenticated PC cannot pass traffic through the port, and confirm a PC with valid credentials is authenticated and granted network access.

Lab Purpose

Port security, discussed earlier in this series, restricts access based on MAC address alone — trivially bypassed by spoofing an authorized MAC. 802.1X requires genuine credential-based authentication before a port grants any network access at all, providing identity-based access control rather than the weaker MAC-based approach.

Lab Topology

Switch1 ---- Gi1/0/8 ---- PC-A (802.1X supplicant)

RADIUS server: 192.168.250.100
(switch acts as the 802.1X authenticator,
 mediating between supplicant and server)

Task 1: Configure AAA and RADIUS for 802.1X

Enable AAA, configure the RADIUS server, and create an authentication method list for 802.1X (dot1x).

Task 2: Enable 802.1X Globally and on the Port

Enable dot1x system-auth-control globally, then configure Gi1/0/8 to require 802.1X authentication.

Task 3: Verify the Port Blocks an Unauthenticated Device

Connect a PC without 802.1X supplicant software configured and confirm it cannot pass traffic.

Task 4: Configure Valid Credentials on the Supplicant

Configure PC-A's 802.1X supplicant with valid credentials matching an account on the RADIUS server.

Task 5: Verify Successful Authentication and Access

Confirm PC-A authenticates successfully and the port transitions to an authorized, forwarding state.

Solution and Verification

Switch1(config)# aaa new-model
Switch1(config)# radius server RADIUS-8021X
Switch1(config-radius-server)# address ipv4 192.168.250.100
Switch1(config-radius-server)# key Dot1xKey2026
Switch1(config)# aaa authentication dot1x default group radius

Switch1(config)# dot1x system-auth-control

Switch1(config)# interface gigabitethernet1/0/8
Switch1(config-if)# switchport mode access
Switch1(config-if)# authentication port-control auto
Switch1(config-if)# dot1x pae authenticator

-- PC-A connected without any 802.1X
-- supplicant configuration:

Switch1# show authentication sessions interface gigabitethernet1/0/8

Interface  MAC Address    Method  Status
Gi1/0/8    Unknown        N/A     Unauthorized
-- The port remains in Unauthorized state --
-- no traffic passes through except the
-- EAPOL frames needed for the 802.1X
-- exchange itself

PC-A> ping 192.168.250.1

Request timed out.
Success rate is 0 percent (0/5)
-- Confirms the unauthenticated PC genuinely
-- cannot pass any regular traffic

-- PC-A's 802.1X supplicant configured with:
Username: pca-user
Password: [matching RADIUS account]

Switch1# show authentication sessions interface gigabitethernet1/0/8

Interface  MAC Address       Method  Status
Gi1/0/8    00aa.bb00.9999    dot1x   Authz Success
-- The port transitioned to authorized once
-- valid credentials were presented and
-- confirmed by the RADIUS server

PC-A> ping 192.168.250.1

Reply from 192.168.250.1: bytes=32 time=1ms
!!!!!
Success rate is 100 percent (5/5)
-- Full network access granted following
-- successful 802.1X authentication

Key Takeaway

802.1X's authorized/unauthorized port states are fundamentally more restrictive than port security's MAC-based filtering, discussed earlier in this series — an 802.1X port passes essentially no traffic at all (aside from the EAPOL authentication exchange itself) until genuine credentials are verified by the RADIUS server, making credential theft or social engineering necessary to bypass it, unlike port security which can be defeated by simply cloning an authorized MAC address.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue