The 802.1x standard defines a client-server-based access control and authentication protocol that prevents unauthorized clients from connecting to a LAN through publicly accessible ports unless they are properly authenticated. The authentication server authenticates each client connected to a switch port before making available any services offered by the device or the LAN.

Note	TACACS is not supported with 802.1x authentication.

Until the client is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL), Cisco Discovery Protocol, and Spanning Tree Protocol (STP) traffic through the port to which the client is connected. After authentication is successful, normal traffic can pass through the port.

The following table below the maximum number of each client session supported:

To configure IEEE 802.1X port-based authentication, you must enable authentication, authorization, and accounting (AAA) and specify the authentication method list. A method list describes the sequence and authentication method to be queried to authenticate a user.

The AAA process begins with authentication. When 802.1x port-based authentication is enabled and the client supports 802.1x-compliant client software, these events occur:

• If the client identity is valid and the 802.1x authentication succeeds, the device grants the client access to the network.

• If 802.1x authentication times out while waiting for an EAPOL message exchange and MAC authentication bypass is enabled, the device can use the client MAC address for authorization. If the client MAC address is valid and the authorization succeeds, the device grants the client access to the network. If the client MAC address is invalid and the authorization fails, the device assigns the client to a guest VLAN that provides limited services if a guest VLAN is configured.

• If the device gets an invalid identity from an 802.1x-capable client and a restricted VLAN is specified, the device can assign the client to a restricted VLAN that provides limited services.

• If the RADIUS authentication server is unavailable (down) and inaccessible authentication bypass is enabled, the device grants the client access to the network by putting the port in the critical-authentication state in the RADIUS-configured or the user-specified access VLAN.

  Note	Inaccessible authentication bypass is also referred to as critical authentication or the AAA fail policy.

If Multi Domain Authentication (MDA) is enabled on a port, this flow can be used with some exceptions that are applicable to voice authorization.

The device re-authenticates a client when one of these situations occurs:

• Periodic re-authentication is enabled, and the re-authentication timer expires.

  You can configure the re-authentication timer to use a device-specific value or to be based on values from the RADIUS server.

  After 802.1x authentication using a RADIUS server is configured, the device uses timers based on the Session-Timeout RADIUS attribute (Attribute[27]) and the Termination-Action RADIUS attribute (Attribute [29]).

  The Session-Timeout RADIUS attribute (Attribute[27]) specifies the time after which re-authentication occurs.

  The Termination-Action RADIUS attribute (Attribute [29]) specifies the action to take during re-authentication. The actions are Initialize and ReAuthenticate. When the Initialize action is set (the attribute value is DEFAULT), the 802.1x session ends, and connectivity is lost during re-authentication. When the ReAuthenticate action is set (the attribute value is RADIUS-Request), the session is not affected during re-authentication.

• You manually re-authenticate the client by entering the dot1x re-authenticate interface interface-id privileged EXEC command.

During 802.1x authentication, the device or the client can initiate authentication. If you enable authentication on a port by using the authentication port-control auto interface configuration command, the device initiates authentication when the link state changes from down to up or periodically as long as the port remains up and unauthenticated. The device sends an EAP-request/identity frame to the client to request its identity. Upon receipt of the frame, the client responds with an EAP-response/identity frame.

However, if during bootup, the client does not receive an EAP-request/identity frame from the device, the client can initiate authentication by sending an EAPOL-start frame, which prompts the device to request the client’s identity.

Note

If 802.1x authentication is not enabled or supported on the network access device, any EAPOL frames from the client are dropped. If the client does not receive an EAP-request/identity frame after three attempts to start authentication, the client sends frames as if the port is in the authorized state. A port in the authorized state effectively means that the client has been successfully authenticated.

When the client supplies its identity, the device begins its role as the intermediary, passing EAP frames between the client and the authentication server until authentication succeeds or fails. If the authentication succeeds, the port becomes authorized. If the authentication fails, authentication can be retried, the port might be assigned to a VLAN that provides limited services, or network access is not granted.

The specific exchange of EAP frames depends on the authentication method being used.

If 802.1x authentication times out while waiting for an EAPOL message exchange and MAC authentication bypass is enabled, the device can authorize the client when the device detects an Ethernet packet from the client. The device uses the MAC address of the client as its identity and includes this information in the RADIUS-access/request frame that is sent to the RADIUS server. After the server sends the device the RADIUS-access/accept frame (authorization is successful), the port becomes authorized. If authorization fails and a guest VLAN is specified, the device assigns the port to the guest VLAN. If the device detects an EAPOL packet while waiting for an Ethernet packet, the device stops the MAC authentication bypass process and starts 802.1x authentication.

Note	You can only set any as the source in the ACL.

Note	For any ACL that is configured for multiple-host mode, the source portion of statement must be any. (For example, permit icmp any host 10.10.1.1 .)

Note	Using role-based ACLs as filter-ID is not recommended.

You must specify any in the source ports of any defined ACL. Otherwise, the ACL cannot be applied and authorization fails. Single host is the only exception to support backward compatibility.

More than one host can be authenticated on MDA-enabled and multiauth ports. The ACL policy applied for one host does not effect the traffic of another host. If only one host is authenticated on a multi-host port, and the other hosts gain network access without authentication, the ACL policy for the first host can be applied to the other connected hosts by specifying any in the source address.

During 802.1x authentication, depending on the switch port state, the switch can grant a client access to the network. The port starts in the unauthorized state. While in this state, the port that is not configured as a voice VLAN port disallows all ingress and egress traffic except for 802.1x authentication, Cisco Discovery Protocol, and STP packets. When a client is successfully authenticated, the port changes to the authorized state, allowing all traffic for the client to flow normally. If the port is configured as a voice VLAN port, the port allows VoIP traffic and 802.1x protocol packets before the client is successfully authenticated.

Note	Cisco Discovery Protocol bypass is not supported and may cause a port to go into err-disabled state.

If a client that does not support 802.1x authentication connects to an unauthorized 802.1x port, the switch requests the client’s identity. In this situation, the client does not respond to the request, the port remains in the unauthorized state, and the client is not granted access to the network.

In contrast, when an 802.1x-enabled client connects to a port that is not running the 802.1x standard, the client initiates the authentication process by sending the EAPOL-start frame. When no response is received, the client sends the request for a fixed number of times. Because no response is received, the client begins sending frames as if the port is in the authorized state.

You control the port authorization state by using the authentication port-control interface configuration command and these keywords:

• force-authorized : Disables 802.1x authentication and causes the port to change to the authorized state without any authentication exchange required. The port sends and receives normal traffic without 802.1x-based authentication of the client. This is the default setting.

• force-unauthorized : Causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the port.

• auto : Enables 802.1x authentication and causes the port to begin in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. The authentication 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.

You can configure an 802.1x port for single-host or for multiple-hosts mode. In single-host mode, only one client can be connected to the 802.1x-enabled port. The device detects the client by sending an EAPOL frame when the port link state changes to the up state. If a client leaves or is replaced with another client, the device changes the port link state to down, and the port returns to the unauthorized state.

In multiple-hosts mode, you can attach multiple hosts to a single 802.1x-enabled port. In this mode, only one of the attached clients must be authorized for all clients to be granted network access. If the port becomes unauthorized (re-authentication fails or an EAPOL-logoff message is received), the device denies network access to all of the attached clients.

In this topology, the wireless access point is responsible for authenticating the clients attached to it, and it also acts as a client to the device.

Note	For all host modes, the line protocol stays up before authorization when port-based authentication is configured.

The device supports multidomain authentication (MDA), which allows both a data device and a voice device, such as an IP Phone (Cisco or non-Cisco), to connect to the same device port.

Cisco Catalyst 1000 Series Switches do no support the Multiple Authentication Per User VLAN Assignment feature. It is not possible to assign multiple VLANs, or one VLAN per user, in the data domain. Segmentation between devices to be authenticated and authorized using 802.1x/MAB on a single port can be achieved by defining a single data VLAN and a single voice VLAN. VLAN assignment will follow the conditions described in this section.

Multiple-authentication (multi-auth) mode allows multiple authenticated clients on the data VLAN and voice VLAN. Each host is individually authenticated. There is no limit to the number of data or voice device that can be authenticated on a multi-auth port.

If a hub or access point is connected to an 802.1x-enabled port, each connected client must be authenticated. For non-802.1x devices, you can use MAC authentication bypass or web authentication as the per-host authentication fallback method to authenticate different hosts with different methods on a single port.

Note	When a port is in multiple-authentication mode, the authentication-failed VLAN features do not activate.

You can assign a RADIUS-server-supplied VLAN in multi-auth mode, under the following conditions:

• The host is the first host authorized on the port, and the RADIUS server supplies VLAN information

• Subsequent hosts are authorized with a VLAN that matches the operational VLAN.

• A host is authorized on the port with no VLAN assignment, and subsequent hosts either have no VLAN assignment, or their VLAN information matches the operational VLAN.

• The first host authorized on the port has a group VLAN assignment, and subsequent hosts either have no VLAN assignment, or their group VLAN matches the group VLAN on the port. Subsequent hosts must use the same VLAN from the VLAN group as the first host. If a VLAN list is used, all hosts are subject to the conditions specified in the VLAN list.

• After a VLAN is assigned to a host on the port, subsequent hosts must have matching VLAN information or be denied access to the port.

• You cannot configure a guest VLAN or an auth-fail VLAN in multi-auth mode.

• The behavior of the critical-auth VLAN is not changed for multi-auth mode. When a host tries to authenticate and the server is not reachable, all authorized hosts are reinitialized in the configured VLAN.

When a MAC address is authenticated on one switch port, that address is not allowed on another authentication manager-enabled port of the switch. If the switch detects that same MAC address on another authentication manager-enabled port, the address is not allowed.

There are situations where a MAC address might need to move from one port to another on the same switch. For example, when there is another device (for example a hub or an IP phone) between an authenticated host and a switch port, you might want to disconnect the host from the device and connect it directly to another port on the same switch.

You can globally enable MAC move so the device is re-authenticated on the new port. When a host moves to a second port, the session on the first port is deleted, and the host is re-authenticated on the new port. MAC move is supported on all host modes. (The authenticated host can move to any port on the switch, no matter which host mode is enabled on the that port.) When a MAC address moves from one port to another, the switch terminates the authenticated session on the original port and initiates a new authentication sequence on the new port. The MAC move feature applies to both voice and data hosts.

Note	In open authentication mode, a MAC address is immediately moved from the original port to the new port, with no requirement for authorization on the new port.

The MAC Replace feature can be configured to address the violation that occurs when a host attempts to connect to a port where another host was previously authenticated.

Note	This feature does not apply to ports in multi-auth mode, because violations are not triggered in that mode. It does not apply to ports in multiple host mode, because in that mode, only the first host requires authentication.

If you configure the authentication violation interface configuration command with the replace keyword, the authentication process on a port in multidomain mode is:

• A new MAC address is received on a port with an existing authenticated MAC address.

• The authentication manager replaces the MAC address of the current data host on the port with the new MAC address.

• The authentication manager initiates the authentication process for the new MAC address.

• If the authentication manager determines that the new host is a voice host, the original voice host is removed.

If a port is in open authentication mode, any new MAC address is immediately added to the MAC address table.

The 802.1x standard defines how users are authorized and authenticated for network access but does not keep track of network usage. 802.1x accounting is disabled by default. You can enable 802.1x accounting to monitor this activity on 802.1x-enabled ports:

• User successfully authenticates.

• User logs off.

• Link-down occurs.

• Re-authentication successfully occurs.

• Re-authentication fails.

The device does not log 802.1x accounting information. Instead, it sends this information to the RADIUS server, which must be configured to log accounting messages.

RADIUS security servers are identified by their hostname or IP address, hostname and specific UDP port numbers, or IP address and specific UDP port numbers. The combination of the IP address and UDP port number creates a unique identifier, which enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, authentication—the second host entry configured acts as the fail-over backup to the first one. The RADIUS host entries are tried in the order that they were configured.

These are the 802.1x authentication configuration guidelines:

• When 802.1x authentication is enabled, ports are authenticated before any other Layer 2 or Layer 3 features are enabled.

• If the VLAN to which an 802.1x-enabled port is assigned changes, this change is transparent and does not affect the device. For example, this change occurs if a port is assigned to a RADIUS server-assigned VLAN and is then assigned to a different VLAN after re-authentication.

  If the VLAN to which an 802.1x port is assigned to shut down, disabled, or removed, the port becomes unauthorized. For example, the port is unauthorized after the access VLAN to which a port is assigned shuts down or is removed.

• The 802.1x protocol is supported on Layer 2 static-access ports, voice VLAN ports, and Layer 3 routed ports, but it is not supported on these port types:

  • Dynamic ports: A port in dynamic mode can negotiate with its neighbor to become a trunk port. If you try to enable 802.1x authentication on a dynamic port, an error message appears, and 802.1x authentication is not enabled. If you try to change the mode of an 802.1x-enabled port to dynamic, an error message appears, and the port mode is not changed.

  • EtherChannel port: Do not configure a port that is an active or a not-yet-active member of an EtherChannel as an 802.1x port. If you try to enable 802.1x authentication on an EtherChannel port, an error message appears, and 802.1x authentication is not enabled.

  • Switched Port Analyzer (SPAN) destination ports: You can enable 802.1x authentication on a port that is a SPAN destination port. However, 802.1x authentication is disabled until the port is removed as a SPAN destination port. You can enable 802.1x authentication on a SPAN source port.

• Before globally enabling 802.1x authentication on a device by entering the dot1x system-auth-control global configuration command, remove the EtherChannel configuration from the interfaces on which 802.1x authentication and EtherChannel are configured.

You can use flexible authentication ordering to configure the order of methods that a port uses to authenticate a new host. The IEEE 802.1X Flexible Authentication feature supports three authentication methods:

• dot1X: IEEE 802.1X authentication is a Layer 2 authentication method.

• mab: MAC authentication bypass is a Layer 2 authentication method.

• webauth: Web authentication is a Layer 3 authentication method.

Using these features, you can control which ports use which authentication methods, and you can control the failover sequencing of methods on those ports. For example, MAC authentication bypass and 802.1x can be the primary or secondary authentication methods, and web authentication can be the fallback method if either or both of those authentication attempts fail.

The IEEE 802.1X Flexible Authentication feature supports the following host modes:

• multi-auth: Multi-authentication allows one authentication on a voice VLAN and multiple authentications on the data VLAN.

• multi-domain: Multidomain authentication allows two authentications, one on the voice VLAN and one on the data VLAN.

You can configure a guest VLAN for each 802.1x port on the device to provide limited services to clients, such as downloading the 802.1x client. These clients might be upgrading their system for 802.1x authentication, and some hosts, such as Windows 98 systems, might not be IEEE 802.1x-capable.

When you enable a guest VLAN on an 802.1x port, the device assigns clients to a guest VLAN when the device does not receive a response to its EAP request/identity frame or when EAPOL packets are not sent by the client.

The device maintains the EAPOL packet history. If an EAPOL packet is detected on the interface during the lifetime of the link, the device determines that the device connected to that interface is an IEEE 802.1x-capable supplicant, and the interface does not change to the guest VLAN state. EAPOL history is cleared if the interface link status goes down. If no EAPOL packet is detected on the interface, the interface changes to the guest VLAN state.

If the device is trying to authorize an 802.1x-capable voice device and the AAA server is unavailable, the authorization attempt fails, but the detection of the EAPOL packet is saved in the EAPOL history. When the AAA server becomes available, the device authorizes the voice device. However, the device no longer allows other devices access to the guest VLAN. To prevent this situation, use one of these command sequences:

• Enter the authentication event no-response action authorize vlan vlan-id interface configuration command to allow access to the guest VLAN.

• Enter the shutdown interface configuration command followed by the no shutdown interface configuration command to restart the port.

If devices send EAPOL packets to the device during the lifetime of the link, the device no longer allows clients that fail authentication access to the guest VLAN.

Note	If an EAPOL packet is detected after the interface has changed to the guest VLAN, the interface reverts to an unauthorized state, and 802.1x authentication restarts.

Any number of 802.1x-incapable clients are allowed access when the device port is moved to the guest VLAN. If an 802.1x-capable client joins the same port on which the guest VLAN is configured, the port is put into the unauthorized state in the user-configured access VLAN, and authentication is restarted.

Guest VLANs are supported on 802.1x ports in single host, multiple host, multi-auth and multi-domain modes.

The device supports MAC authentication bypass. When MAC authentication bypass is enabled on an 802.1x port, the device can authorize clients based on the client MAC address when IEEE 802.1x authentication times out while waiting for an EAPOL message exchange. After detecting a client on an 802.1x port, the device waits for an Ethernet packet from the client. The device sends the authentication server a RADIUS-access/request frame with a username and password based on the MAC address. If authorization succeeds, the device grants the client access to the network. If authorization fails, the device assigns the port to the guest VLAN if one is specified.

You can configure a restricted VLAN (also referred to as an authentication failed VLAN) for each IEEE 802.1x port on a device to provide limited services to clients that cannot access the guest VLAN. These clients are 802.1x-compliant and cannot access another VLAN because they fail the authentication process. A restricted VLAN allows users without valid credentials in an authentication server (typically, visitors to an enterprise) to access a limited set of services. The administrator can control the services available to the restricted VLAN.

Note	You can configure a VLAN to be both the guest VLAN and the restricted VLAN if you want to provide the same services to both types of users.

Without this feature, the client attempts and fails authentication indefinitely, and the device port remains in the spanning-tree blocking state. With this feature, you can configure the device port to be in the restricted VLAN after a specified number of authentication attempts (the default value is 3 attempts).

The authenticator counts the failed authentication attempts for the client. When this count exceeds the configured maximum number of authentication attempts, the port moves to the restricted VLAN. The failed attempt count increments when the RADIUS server replies with either an EAP failure or an empty response without an EAP packet. When the port moves into the restricted VLAN, the failed attempt counter resets.

Users who fail authentication remain in the restricted VLAN until the next re-authentication attempt. A port in the restricted VLAN tries to re-authenticate at configured intervals (the default is 60 seconds). If re-authentication fails, the port remains in the restricted VLAN. If re-authentication is successful, the port moves either to the configured VLAN or to a VLAN sent by the RADIUS server. You can disable re-authentication. If you do this, the only way to restart the authentication process is for the port to receive a link down or EAP logoff event. We recommend that you keep re-authentication enabled if a client might connect through a hub. When a client disconnects from the hub, the port might not receive the link down or EAP logoff event.

After a port moves to the restricted VLAN, a simulated EAP success message is sent to the client. This prevents clients from indefinitely attempting authentication. Some clients (for example, devices running Windows XP) cannot implement DHCP without EAP success.

Restricted VLANs are supported on 802.1x ports in all host modes and on Layer 2 ports.

Other security port features such as dynamic ARP Inspection, DHCP snooping, and IP source guard can be configured independently on a restricted VLAN.

You can configure an auth fail VLAN for each 802.1X port on a device to provide limited services to clients that cannot access the guest VLAN. These clients are 802.1X-compliant and cannot access another VLAN because they fail the authentication process. An auth fail VLAN allows users without valid credentials in an authentication server (typically, visitors to an enterprise) to access a limited set of services. The administrator can control the services available to the auth fail VLAN.

Note	You can configure a VLAN to be both the guest VLAN and the auth fail VLAN if you want to provide the same services to both types of users.

Without this feature, the client attempts and fails authentication indefinitely, and the device port remains in the spanning-tree blocking state. With this feature, you can configure the device port to be in the auth fail VLAN after a specified number of authentication attempts (the default value is 3 attempts).

The authenticator counts the failed authentication attempts for the client. When this count exceeds the configured maximum number of authentication attempts, the port moves to the auth fail VLAN. The failed attempt count increments when the RADIUS server replies with either an EAP failure or an empty response without an EAP packet. When the port moves into the auth fail VLAN, the failed attempt counter resets.

Users who fail authentication remain in the auth fail VLAN until the next re-authentication attempt. A port in the auth fail VLAN tries to re-authenticate at configured intervals (the default is 60 seconds). If re-authentication fails, the port remains in the auth fail VLAN. If re-authentication is successful, the port moves either to the configured VLAN or to a VLAN sent by the RADIUS server. You can disable re-authentication. If you do this, the only way to restart the authentication process is for the port to receive a link down or EAP logoff event. It is recommended that you keep re-authentication enabled if a client might connect through a hub. When a client disconnects from the hub, the port might not receive the link down or EAP logoff event.

After a port moves to the auth fail VLAN, a simulated EAP success message is sent to the client. This prevents clients from indefinitely attempting authentication.

As a prerequisite, the device must be connected to a Cisco secure Access Control System (ACS) and RADIUS authentication, authorization, and accounting (AAA) must be configured for Web authentication. If appropriate, you must enable ACL download.

Open1x authentication allows a device access to a port before that device is authenticated. When open authentication is configured, a new host can pass traffic according to the access control list (ACL) defined on the port. After the host is authenticated, the policies configured on the RADIUS server are applied to that host.

You can configure open authentication with these scenarios:

• Single-host mode with open authentication: Only one user is allowed network access before and after authentication.

• MDA mode with open authentication: Only one user in the voice domain and one user in the data domain are allowed.

• Multiple-hosts mode with open authentication: Any host can access the network.

• Multiple-authentication mode with open authentication: Similar to MDA, except multiple hosts can be authenticated.

  Note	If open authentication is configured, it takes precedence over other authentication controls. This means that if you use the authentication open interface configuration command, the port will grant access to the host irrespective of the authentication port-control interface configuration command.

The Limiting Login feature helps network administrators to limit the login attempt of users to a network. When a user fails to successfully login to a network within a configurable number of attempts within a configurable time limit, this user can be blocked. This feature is enabled only for local users and not for remote users. You need to configure the aaa authentication rejected command in global configuration mode to enable this feature.

Use the inaccessible authentication bypass feature, also referred to as critical authentication or the AAA fail policy, when the device cannot reach the configured RADIUS servers and new hosts cannot be authenticated. You can configure the device to connect those hosts to critical ports.

When a new host tries to connect to the critical port, that host is moved to a user-specified access VLAN, the critical VLAN. The administrator gives limited authentication to the hosts.

When the device tries to authenticate a host connected to a critical port, the device checks the status of the configured RADIUS server. If a server is available, the device can authenticate the host. However, if all the RADIUS servers are unavailable, the device grants network access to the host and puts the port in the critical-authentication state, which is a special case of the authentication state.

Note

If critical authentication is configured on interface, then vlan used for critical authorization (critical vlan) should be active on the device. If the critical vlan is inactive (or) down, critical authentication session will keep trying to enable the inactive VLAN and fail repeatedly. This can lead to large amount of memory holding.

The following are configuration guidelines for VLAN assignment, guest VLAN, restricted VLAN, and inaccessible authentication bypass:

• When 802.1x authentication is enabled on a port, you cannot configure a port VLAN that is equal to a voice VLAN.

• The 802.1x authentication with VLAN assignment feature is not supported on trunk ports, or dynamic ports.

• You can configure any VLAN except a voice VLAN as an 802.1x guest VLAN. The guest VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.

• After you configure a guest VLAN for an 802.1x port to which a DHCP client is connected, you might need to get a host IP address from a DHCP server. You can change the settings for restarting the 802.1x authentication process on the device before the DHCP process on the client times out and tries to get a host IP address from the DHCP server. Decrease the settings for the 802.1x authentication process (authentication timer inactivity and authentication timer reauthentication interface configuration commands). The amount to decrease the settings depends on the connected 802.1x client type.

• When configuring the inaccessible authentication bypass feature, follow these guidelines:

  • The feature is supported on 802.1x port in single-host mode and multihosts mode.

  • You can configure the inaccessible authentication bypass feature and the restricted VLAN on an 802.1x port. If the device tries to re-authenticate a critical port in a restricted VLAN and all the RADIUS servers are unavailable, the device changes the port state to the critical authentication state and remains in the restricted VLAN.

• You can configure any VLAN except a voice VLAN as an 802.1x restricted VLAN. The restricted VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.

You can configure the device to authorize clients based on the client MAC address by using the MAC authentication bypass feature. For example, you can enable this feature on IEEE 802.1x ports connected to devices such as printers.

If IEEE 802.1x authentication times out while waiting for an EAPOL response from the client, the device tries to authorize the client by using MAC authentication bypass.

When the MAC authentication bypass feature is enabled on an IEEE 802.1x port, the device uses the MAC address as the client identity. The authentication server has a database of client MAC addresses that are allowed network access. After detecting a client on an IEEE 802.1x port, the device waits for an Ethernet packet from the client. The device sends the authentication server a RADIUS-access/request frame with a username and password based on the MAC address. If authorization succeeds, the device grants the client access to the network. If authorization fails, the device assigns the port to the guest VLAN if one is configured. This process works for most client devices; however, it does not work for clients that use an alternate MAC address format. You can configure how MAB authentication is performed for clients with MAC addresses that deviate from the standard format or where the RADIUS configuration requires the user name and password to differ.

If an EAPOL packet is detected on the interface during the lifetime of the link, the device determines that the device connected to that interface is an 802.1x-capable supplicant and uses 802.1x authentication (not MAC authentication bypass) to authorize the interface. EAPOL history is cleared if the interface link status goes down.

If the device already authorized a port by using MAC authentication bypass and detects an IEEE 802.1x supplicant, the device does not unauthorize the client connected to the port. When re-authentication occurs, the device uses the authentication or re-authentication methods configured on the port, if the previous session ended because the Termination-Action RADIUS attribute value is DEFAULT.

Clients that were authorized with MAC authentication bypass can be re-authenticated. The re-authentication process is the same as that for clients that were authenticated with IEEE 802.1x. During re-authentication, the port remains in the previously assigned VLAN. If re-authentication is successful, the device keeps the port in the same VLAN. If re-authentication fails, the device assigns the port to the guest VLAN, if one is configured.

If re-authentication is based on the Session-Timeout RADIUS attribute (Attribute[27]) and the Termination-Action RADIUS attribute (Attribute [29]) and if the Termination-Action RADIUS attribute (Attribute [29]) action is Initialize (the attribute value is DEFAULT), the MAC authentication bypass session ends, and connectivity is lost during re-authentication. If MAC authentication bypass is enabled and the IEEE 802.1x authentication times out, the device uses the MAC authentication bypass feature to initiate re-authorization. For more information about these AV pairs, see RFC 3580, “IEEE 802.1X Remote Authentication Dial In User Service (RADIUS).”

MAC authentication bypass interacts with the features:

• IEEE 802.1x authentication: You can enable MAC authentication bypass only if 802.1x authentication is enabled on the port .

• Guest VLAN: If a client has an invalid MAC address identity, the device assigns the client to a guest VLAN if one is configured.

• Restricted VLAN: This feature is not supported when the client connected to an IEEE 802.lx port is authenticated with MAC authentication bypass.

• Port security

• Voice VLAN

A voice VLAN port is a special access port associated with two VLAN identifiers:

• VVID to carry voice traffic to and from the IP phone. The VVID is used to configure the IP phone connected to the port.

• PVID to carry the data traffic to and from the workstation connected to the device through the IP phone. The PVID is the native VLAN of the port.

The IP phone uses the VVID for its voice traffic, regardless of the authorization state of the port. This allows the phone to work independently of IEEE 802.1x authentication.

In single-host mode, only the IP phone is allowed on the voice VLAN. In multiple-hosts mode, additional clients can send traffic on the voice VLAN after a supplicant is authenticated on the PVID. When multiple-hosts mode is enabled, the supplicant authentication affects both the PVID and the VVID.

A voice VLAN port becomes active when there is a link, and the device MAC address appears after the first Cisco Discovery Protocol message from the IP phone. Cisco IP phones do not relay Cisco Discovery Protocol messages from other devices. As a result, if several IP phones are connected in series, the device recognizes only the one directly connected to it. When IEEE 802.1x authentication is enabled on a voice VLAN port, the device drops packets from unrecognized IP phones more than one hop away.

When IEEE 802.1x authentication is enabled on a device port, you can configure an access port VLAN that is also a voice VLAN.

When IP phones are connected to an 802.1x-enabled device port that is in single host mode, the device grants the phones network access without authenticating them. We recommend that you use multidomain authentication (MDA) on the port to authenticate both a data device and a voice device, such as an IP phone

Note	If you enable IEEE 802.1x authentication on an access port on which a voice VLAN is configured and to which a Cisco IP Phone is connected, the Cisco IP phone loses connectivity to the device for up to 30 seconds.

IEEE 802.1x enforces a single MAC address per port (or per VLAN when MDA is configured for IP telephony), port security is redundant and in some cases may interfere with expected IEEE 802.1x operations.

We do not recommend enabling port security when IEEE 802.1x is enabled.

To configure IEEE 802.1X port-based authentication, you must enable authentication, authorization, and accounting (AAA) and specify the authentication method list. A method list describes the sequence and authentication method to be queried to authenticate a user.

The AAA process begins with authentication. When 802.1x port-based authentication is enabled and the client supports 802.1x-compliant client software, these events occur:

• If the client identity is valid and the 802.1x authentication succeeds, the device grants the client access to the network.

• If 802.1x authentication times out while waiting for an EAPOL message exchange and MAC authentication bypass is enabled, the device can use the client MAC address for authorization. If the client MAC address is valid and the authorization succeeds, the device grants the client access to the network. If the client MAC address is invalid and the authorization fails, the device assigns the client to a guest VLAN that provides limited services if a guest VLAN is configured.

• If the device gets an invalid identity from an 802.1x-capable client and a restricted VLAN is specified, the device can assign the client to a restricted VLAN that provides limited services.

• If the RADIUS authentication server is unavailable (down) and inaccessible authentication bypass is enabled, the device grants the client access to the network by putting the port in the critical-authentication state in the RADIUS-configured or the user-specified access VLAN.

  Note	Inaccessible authentication bypass is also referred to as critical authentication or the AAA fail policy.

If Multi Domain Authentication (MDA) is enabled on a port, this flow can be used with some exceptions that are applicable to voice authorization.

The device re-authenticates a client when one of these situations occurs:

• Periodic re-authentication is enabled, and the re-authentication timer expires.

  You can configure the re-authentication timer to use a device-specific value or to be based on values from the RADIUS server.

  After 802.1x authentication using a RADIUS server is configured, the device uses timers based on the Session-Timeout RADIUS attribute (Attribute[27]) and the Termination-Action RADIUS attribute (Attribute [29]).

  The Session-Timeout RADIUS attribute (Attribute[27]) specifies the time after which re-authentication occurs.

  The Termination-Action RADIUS attribute (Attribute [29]) specifies the action to take during re-authentication. The actions are Initialize and ReAuthenticate. When the Initialize action is set (the attribute value is DEFAULT), the 802.1x session ends, and connectivity is lost during re-authentication. When the ReAuthenticate action is set (the attribute value is RADIUS-Request), the session is not affected during re-authentication.

• You manually re-authenticate the client by entering the dot1x re-authenticate interface interface-id privileged EXEC command.

During 802.1x authentication, the device or the client can initiate authentication. If you enable authentication on a port by using the authentication port-control auto interface configuration command, the device initiates authentication when the link state changes from down to up or periodically as long as the port remains up and unauthenticated. The device sends an EAP-request/identity frame to the client to request its identity. Upon receipt of the frame, the client responds with an EAP-response/identity frame.

However, if during bootup, the client does not receive an EAP-request/identity frame from the device, the client can initiate authentication by sending an EAPOL-start frame, which prompts the device to request the client’s identity.

Note

If 802.1x authentication is not enabled or supported on the network access device, any EAPOL frames from the client are dropped. If the client does not receive an EAP-request/identity frame after three attempts to start authentication, the client sends frames as if the port is in the authorized state. A port in the authorized state effectively means that the client has been successfully authenticated.

When the client supplies its identity, the device begins its role as the intermediary, passing EAP frames between the client and the authentication server until authentication succeeds or fails. If the authentication succeeds, the port becomes authorized. If the authentication fails, authentication can be retried, the port might be assigned to a VLAN that provides limited services, or network access is not granted.

The specific exchange of EAP frames depends on the authentication method being used.

If 802.1x authentication times out while waiting for an EAPOL message exchange and MAC authentication bypass is enabled, the device can authorize the client when the device detects an Ethernet packet from the client. The device uses the MAC address of the client as its identity and includes this information in the RADIUS-access/request frame that is sent to the RADIUS server. After the server sends the device the RADIUS-access/accept frame (authorization is successful), the port becomes authorized. If authorization fails and a guest VLAN is specified, the device assigns the port to the guest VLAN. If the device detects an EAPOL packet while waiting for an Ethernet packet, the device stops the MAC authentication bypass process and starts 802.1x authentication.

You can configure 802.1x user distribution to load-balance users with the same group name across multiple different VLANs.

The VLANs are either supplied by the RADIUS server or configured through the device CLI under a VLAN group name.

• Configure the RADIUS server to send more than one VLAN name for a user. The multiple VLAN names can be sent as part of the response to the user. The 802.1x user distribution tracks all the users in a particular VLAN and achieves load balancing by moving the authorized user to the least populated VLAN.

• Configure the RADIUS server to send a VLAN group name for a user. The VLAN group name can be sent as part of the response to the user. You can search for the selected VLAN group name among the VLAN group names that you configured by using the device CLI. If the VLAN group name is found, the corresponding VLANs under this VLAN group name are searched to find the least populated VLAN. Load balancing is achieved by moving the corresponding authorized user to that VLAN.

  Note	The RADIUS server can send the VLAN information in any combination of VLAN IDs, VLAN names, or VLAN groups.

• Confirm that at least one VLAN is mapped to the VLAN group.

• You can map more than one VLAN to a VLAN group.

• You can modify the VLAN group by adding or deleting a VLAN.

• When you clear an existing VLAN from the VLAN group name, none of the authenticated ports in the VLAN are cleared, but the mappings are removed from the existing VLAN group.

• If you clear the last VLAN from the VLAN group name, the VLAN group is cleared.

• You can clear a VLAN group even when the active VLANs are mapped to the group. When you clear a VLAN group, none of the ports or users that are in the authenticated state in any VLAN within the group are cleared, but the VLAN mappings to the VLAN group are cleared.

Note	You can only set any as the source in the ACL.

Note	For any ACL that is configured for multiple-host mode, the source portion of statement must be any. (For example, permit icmp any host 10.10.1.1 .)

Note	Using role-based ACLs as filter-ID is not recommended.

You must specify any in the source ports of any defined ACL. Otherwise, the ACL cannot be applied and authorization fails. Single host is the only exception to support backward compatibility.

More than one host can be authenticated on MDA-enabled and multiauth ports. The ACL policy applied for one host does not effect the traffic of another host. If only one host is authenticated on a multi-host port, and the other hosts gain network access without authentication, the ACL policy for the first host can be applied to the other connected hosts by specifying any in the source address.

Use the Voice-Aware 802.1x security feature to configure the device to disable only the VLAN on which a security violation occurs, whether it is a data or voice VLAN. Prior to this feature, when an attempt to authenticate the data client caused a security violation, the entire port shut down, resulting in a complete loss of connectivity.

Use this feature in IP phone deployments where a PC is connected to the IP phone. A security violation found on the data VLAN results in the shutdown of only the data VLAN. The traffic on the voice VLAN flows through the device without interruption.