10-12
Catalyst 2960 and 2960-S Switch Software Configuration Guide
OL-8603-09
Chapter 10 Configuring IEEE 802.1x Port-Based Authentication
Understanding IEEE 802.1x Port-Based Authentication
• auto—enables 802.1x authentication and causes the port to begin i n the unauthorized state, allowing
only EAPOL frames to be sent and received through the port. The aut hentication process begins
when the link state of the port changes from down to up or when an EAPOL-start frame is received.
The switch requests the identity of the client and begins relaying authentication messages between
the client and the authentication server. Each client attempting to access the network is uniquely
identified by the switch by using the client MAC address.
If the client is successfully authenticated (receives an Accept frame from the authentication server), the
port state changes to authorized, and all frames from the authenticated client are allowed through the
port. If the authentication fails, the port remains in the unauthorized state, but authentication can be
retried. If the authentication server cannot be reached, the switch can resend the request. If no response
is received from the server after the specified number of attempts, authentication fails, and network
access is not granted.
When a client logs off, it sends an EAPOL-logoff message, causing the switch port to change to the
unauthorized state.
If the link state of a port changes from up to down, or if an EAPOL-logoff frame is received, the port
returns to the unauthorized state.
802.1x Authentication and Switch Stacks
If a switch is added to or removed from a switch stack, 802.1x authentication is not affected as long as
the IP connectivity between the RADIUS server and the stack remains intact. This statement also applies
if the stack master is removed from the switch stack. Note that if the stack master fails, a stack member
becomes the new stack master by using the election process described in Chapter 7, “Managing Switch
Stacks,” and the 802.1x authentication process continues as usual.
If IP connectivity to the RADIUS server is interrupted because the switch that was connected to the
server is removed or fails, these events occur:
• Ports that are already authenticated and that do not have periodic re-authentication enabled remain
in the authenticated state. Communication with the RADIUS server is not required.
• Ports that are already authenticated and that have periodic re-authentication enabled (with the dot1x
re-authentication global configuration command) fail the authentication process when the
re-authentication occurs. Ports return to the unauthenticated state during the re-authentication
process. Communication with the RADIUS server is required.
For an ongoing authentication, the authentication fails immediately because there is no server
connectivity.
If the switch that failed comes up and rejoins the switch stack, the authentications might or might not
fail depending on the boot-up time and whether the connectivity to the RADIUS server is re-established
by the time the authentication is attempted.
To avoid loss of connectivity to the RADIUS server, you should ensure that there is a redundant
connection to it. For example, you can have a redundant connection to the stack master and another to a
stack member, and if the stack master fails, the switch stack still has connectivity to the RADIUS server.