802.1X on Cisco Switches: Step-by-Step Configuration Guide

802.1X is port-based network access control: a switch port stays shut to data traffic until the device behind it proves who it is to a RADIUS server. This article walks the switch-side configuration - the authenticator role - with real output from a Catalyst switch on IOS XE 17.18, and clears up the two commands people most often mix up (MAB versus guest VLAN). For the full end-to-end build with a live RADIUS server and a real supplicant taking a port from unauthorized to authorized, see the lab linked at the end.

If you want the bigger picture first, the 802.1X complete guide covers the architecture this article plugs into.

The Three Roles

802.1X has three parts. The supplicant is the client (a laptop, a phone) running software that speaks EAP over LAN. The authenticator is the switch: it relays EAP between the supplicant and the server and controls whether the port forwards traffic. The authentication server is RADIUS (Cisco ISE, or FreeRADIUS in a lab), which holds the credentials and makes the accept or reject decision. The switch never decides who is allowed on - it enforces what RADIUS tells it.

AAA and RADIUS Setup

Enable AAA, define the RADIUS server, and point 802.1X authentication and authorization at it:

Switch(config)# aaa new-model
Switch(config)# aaa authentication dot1x default group radius
Switch(config)# aaa authorization network default group radius
Switch(config)# radius server RAD1
Switch(config-radius-server)# address ipv4 10.10.99.20 auth-port 1812 acct-port 1813
Switch(config-radius-server)# key LabRadius123
Switch(config)# ip radius source-interface Vlan1

Confirm what landed:

Switch# show running-config aaa
aaa authentication dot1x default group radius
aaa authorization network default group radius
radius server RAD1
 address ipv4 10.10.99.20 auth-port 1812 acct-port 1813
 key LabRadius123
aaa new-model
aaa session-id common
ip radius source-interface Vlan1

The ip radius source-interface line matters more than it looks: RADIUS replies come back to whatever source address the switch used, and your server's client definition must match that address or every request is silently ignored.

Enable 802.1X Globally

Switch(config)# dot1x system-auth-control

Verify the global state:

Switch# show dot1x
Sysauthcontrol                 Enabled
Dot1x Protocol Version               3

Configure the Access Port

Put the port into automatic authorization and give it the authenticator role:

Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# switchport mode access
Switch(config-if)# authentication port-control auto
Switch(config-if)# dot1x pae authenticator
Switch(config-if)# dot1x timeout tx-period 10
Switch(config-if)# spanning-tree portfast

port-control auto is the key setting: the port starts unauthorized and only opens after a successful authentication. The two other modes, force-authorized (always open, effectively 802.1X off) and force-unauthorized (always shut), are rarely what you want on a user port. Verify the port role:

Switch# show dot1x interface GigabitEthernet1/0/1 details
Dot1x Info for GigabitEthernet1/0/1
--------------------------------------------
PAE                       = AUTHENTICATOR
QuietPeriod               = 60
ServerTimeout             = 0
SuppTimeout               = 30
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 10

Dot1x Authenticator Client List Empty

Before any supplicant authenticates, the port sits unauthorized - which is exactly what you want a secured port to do at rest:

Switch# show dot1x all summary
Interface                PAE     Client          Status
Gi1/0/1                  AUTH    none            UNAUTHORIZED

MAB and Guest VLAN Are Not the Same Thing

This is the point most guides get wrong, so be precise. Both handle a device that cannot do 802.1X, but they are different features with different commands.

MAC Authentication Bypass (MAB) falls back to authenticating the device by its MAC address against RADIUS. The switch takes the source MAC, sends it to the server as the username and password, and RADIUS decides. It is a single interface command:

Switch(config-if)# mab

Guest VLAN is different: it drops a device that never responds to 802.1X at all (no supplicant, no EAPOL) into a restricted VLAN. There is no authentication - the switch just gives up waiting and parks the port:

Switch(config-if)# authentication event no-response action authorize vlan 100

The distinction matters operationally. MAB still consults RADIUS, so you keep central control and logging over which MACs are allowed. Guest VLAN consults nobody - anything that stays silent lands in VLAN 100. Older guides that present authentication event no-response action authorize vlan 100 as "MAB configuration" are wrong; that line is the guest-VLAN fallback. If you want MAC-based fallback with RADIUS in the loop, the command is mab.

Troubleshooting

When authentication fails, the first question is always whether the switch can even reach RADIUS. Check the server state and the request counters:

Switch# show aaa servers | include host|State|Authen: request|Response: accept|Response: reject

Rising timeouts with zero accept and zero reject means your requests are not reaching the server, or its replies are not getting back - a routing, source-interface, ACL, or shared-secret-mismatch problem, not a credentials problem. Accepts and rejects mean RADIUS is answering and the issue is on the identity side (wrong password, missing user, or a policy that denies the device). You can prove the RADIUS path independently of any supplicant with:

Switch# test aaa group radius <username> <password> new-code

A clean "User successfully authenticated" here means the switch-to-server path and the credentials are both good, and any remaining problem is with the supplicant or the port.

Build the Full Chain Yourself

The commands above are the authenticator half. The exercise only comes alive when a real RADIUS server and a real supplicant are in the loop and you watch a port move from UNAUTHORIZED to Authorized. Building the whole 802.1X chain with FreeRADIUS covers the full build - server, switch, and a live supplicant - with every command and every block of output captured from real gear, including the authorized-session output and the debug trace of a successful EAP exchange.

Key Takeaways

• The switch is the authenticator; it enforces what RADIUS decides and never makes the access decision itself.
• authentication port-control auto plus dot1x pae authenticator is the core of a secured port; it starts UNAUTHORIZED until a supplicant passes.
• mab falls back to MAC authentication against RADIUS; the guest-VLAN command authentication event no-response action authorize vlan is a different feature that consults nobody.
• Use show aaa servers and test aaa group radius to isolate a reachability problem from a credentials problem before you blame the supplicant.