Contents

802.1X overview· 1

About the 802.1X protocol 1

802.1X architecture· 1

Controlled/uncontrolled port and port authorization status· 1

Packet exchange methods· 2

Packet formats· 3

802.1X authentication procedures· 5

802.1X authentication initiation· 7

Access control methods· 8

802.1X VLAN manipulation· 8

Authorization VLAN·· 8

Guest VLAN·· 10

Auth-Fail VLAN·· 11

Critical VLAN·· 11

Configuring 802.1X· 13

Restrictions: Hardware compatibility with 802.1X· 13

802.1X tasks at a glance· 13

Prerequisites for 802.1X· 13

Enabling 802.1X· 13

Enabling EAP relay or EAP termination· 14

Setting the port authorization state· 15

Enabling port-based access control 15

Specifying a mandatory authentication domain on a port 15

Setting the 802.1X authentication timeout timers· 16

Setting the quiet timer 16

Configuring an 802.1X guest VLAN·· 17

Configuring an 802.1X Auth-Fail VLAN·· 17

Configuring an 802.1X critical VLAN·· 18

Configuring the authentication trigger feature· 18

Setting the maximum number of concurrent 802.1X users on a port 19

Setting the maximum number of authentication request attempts· 19

Configuring online user handshake· 20

Specifying supported domain name delimiters· 21

Display and maintenance commands for 802.1X· 21

802.1X authentication configuration examples· 22

Example: Configuring basic 802.1X authentication· 22

Example: Configuring 802.1X guest VLAN and authorization VLAN·· 24

 

802.1X overview

About the 802.1X protocol

802.1X is a port-based network access control protocol widely used on Ethernet networks. The protocol controls network access by authenticating the devices connected to 802.1X-enabled LAN ports.

802.1X architecture

802.1X operates in the client/server model. As shown in Figure 1, 802.1X authentication includes the following entities:

·          Client (supplicant)—A user terminal seeking access to the LAN. The terminal must have 802.1X software to authenticate to the access device.

·          Access device (authenticator)—Authenticates the client to control access to the LAN. In a typical 802.1X environment, the access device uses an authentication server to perform authentication.

·          Authentication server—Provides authentication services for the access device. The authentication server first authenticates 802.1X clients by using the data sent from the access device. Then, the server returns the authentication results to the access device to make access decisions. The authentication server is typically a RADIUS server. In a small LAN, you can use the access device as the authentication server.

Figure 1 802.1X architecture

 

Controlled/uncontrolled port and port authorization status

802.1X defines two logical ports for the network access port: controlled port and uncontrolled port. Any packet arriving at the network access port is visible to both logical ports.

·          Uncontrolled port—Is always open to receive and transmit authentication packets.

·          Controlled port—Filters packets depending on the port state.

?  Authorized state—The controlled port is in authorized state when the client has passed authentication. The port allows traffic to pass through.

?  Unauthorized state—The port is in unauthorized state when the client has failed authentication. The port controls traffic by using one of the following methods:

-      Performs bidirectional traffic control to deny traffic to and from the client.

-      Performs unidirectional traffic control to deny traffic from the client. The device supports only unidirectional traffic control.

Figure 2 Authorization state of a controlled port

 

Packet exchange methods

802.1X uses the Extensible Authentication Protocol (EAP) to transport authentication information for the client, the access device, and the authentication server. EAP is an authentication framework that uses the client/server model. The framework supports a variety of authentication methods, including MD5-Challenge, EAP-Transport Layer Security (EAP-TLS), and Protected EAP (PEAP).

802.1X defines EAP over LAN (EAPOL) for passing EAP packets between the client and the access device over a wired or wireless LAN. Between the access device and the authentication server, 802.1X delivers authentication information by either EAP relay or EAP termination.

EAP relay

EAP relay is defined in IEEE 802.1X. In this mode, the network device uses EAP over RADIUS (EAPOR) packets to send authentication information to the RADIUS server, as shown in Figure 3.

Figure 3 EAP relay

 

In EAP relay mode, the client must use the same authentication method as the RADIUS server. On the access device, you only need to use the dot1x authentication-method eap command to enable EAP relay.

EAP termination

As shown in Figure 4, the access device performs the following operations in EAP termination mode:

1.        Terminates the EAP packets received from the client.

2.        Encapsulates the client authentication information in standard RADIUS packets.

3.        Uses PAP or CHAP to authenticate to the RADIUS server.

Figure 4 EAP termination

 

Comparing EAP relay and EAP termination

Packet exchange method	Benefits	Limitations
EAP relay	·         Supports various EAP authentication methods. ·         The configuration and processing are simple on the access device.	The RADIUS server must support the EAP-Message and Message-Authenticator attributes, and the EAP authentication method used by the client.
EAP termination	Works with any RADIUS server that supports PAP or CHAP authentication.	·         Supports only the following EAP authentication methods: ?  MD5-Challenge EAP authentication. ?  The username and password EAP authentication initiated by an iNode 802.1X client. ·         The processing is complex on the access device.

 

Packet formats

EAP packet format

Figure 5 shows the EAP packet format.

Figure 5 EAP packet format

 

·          Code—Type of the EAP packet. Options include Request (1), Response (2), Success (3), or Failure (4).

·          Identifier—Used for matching Responses with Requests.

·          Length—Length (in bytes) of the EAP packet. The EAP packet length is the sum of the Code, Identifier, Length, and Data fields.

·          Data—Content of the EAP packet. This field appears only in a Request or Response EAP packet. The Data field contains the request type (or the response type) and the type data. Type 1 (Identity) and type 4 (MD5-Challenge) are two examples for the type field.

EAPOL packet format

Figure 6 shows the EAPOL packet format.

Figure 6 EAPOL packet format

 

·          PAE Ethernet type—Protocol type. It takes the value 0x888E for EAPOL.

·          Protocol version—The EAPOL protocol version used by the EAPOL packet sender.

·          Type—Type of the EAPOL packet. Table 1 lists the types of EAPOL packets supported by the 802.1X implementation of the device.

Table 1 Types of EAPOL packets

Value	Type	Description
0x00	EAP-Packet	The client and the access device uses EAP-Packets to transport authentication information.
0x01	EAPOL-Start	The client sends an EAPOL-Start message to initiate 802.1X authentication to the access device.
0x02	EAPOL-Logoff	The client sends an EAPOL-Logoff message to tell the access device that the client is logging off.

 

·          Length—Data length in bytes, or length of the Packet body. If packet type is EAPOL-Start or EAPOL-Logoff, this field is set to 0, and no Packet body field follows.

·          Packet body—Content of the packet. When the EAPOL packet type is EAP-Packet, the Packet body field contains an EAP packet.

EAP over RADIUS

RADIUS adds two attributes, EAP-Message and Message-Authenticator, for supporting EAP authentication. For the RADIUS packet format, see AAA configuration in BRAS Services Configuration Guide.

·          EAP-Message.

RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 7. The Type field takes 79, and the Value field can be up to 253 bytes. If an EAP packet is longer than 253 bytes, RADIUS encapsulates it in multiple EAP-Message attributes.

Figure 7 EAP-Message attribute format

 

·          Message-Authenticator.

As shown in Figure 8, RADIUS includes the Message-Authenticator attribute in all packets that have an EAP-Message attribute to check their integrity. The packet receiver drops the packet if the calculated packet integrity checksum is different from the Message-Authenticator attribute value. The Message-Authenticator prevents EAP authentication packets from being tampered with during EAP authentication.

Figure 8 Message-Authenticator attribute format

 

802.1X authentication procedures

802.1X authentication has two methods: EAP relay and EAP termination. You choose either mode depending on support of the RADIUS server for EAP packets and EAP authentication methods.

EAP relay

Figure 9 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that MD5-Challenge EAP authentication is used.

Figure 9 802.1X authentication procedure in EAP relay mode

 

The following steps describe the 802.1X authentication procedure:

1.        When a user launches the 802.1X client and enters a registered username and password, the 802.1X client sends an EAPOL-Start packet to the access device.

2.        The access device responds with an EAP-Request/Identity packet to ask for the client username.

3.        In response to the EAP-Request/Identity packet, the client sends the username in an EAP-Response/Identity packet to the access device.

4.        The access device relays the EAP-Response/Identity packet in a RADIUS Access-Request packet to the authentication server.

5.        The authentication server uses the identity information in the RADIUS Access-Request to search its user database. If a matching entry is found, the server uses a randomly generated challenge (EAP-Request/MD5-Challenge) to encrypt the password in the entry. Then, the server sends the challenge in a RADIUS Access-Challenge packet to the access device.

6.        The access device transmits the EAP-Request/MD5-Challenge packet to the client.

7.        The client uses the received challenge to encrypt the password, and sends the encrypted password in an EAP-Response/MD5-Challenge packet to the access device.

8.        The access device relays the EAP-Response/MD5-Challenge packet in a RADIUS Access-Request packet to the authentication server.

9.        The authentication server compares the received encrypted password with the encrypted password it generated at step 5. If the two passwords are identical, the server considers the client valid and sends a RADIUS Access-Accept packet to the access device.

10.     Upon receiving the RADIUS Access-Accept packet, the access device performs the following operations:

a.    Sends an EAP-Success packet to the client.

b.    Sets the controlled port in authorized state.

The client can access the network.

11.     After the client comes online, the access device periodically sends handshake requests to check whether the client is still online. By default, if two consecutive handshake attempts fail, the device logs off the client.

12.     Upon receiving a handshake request, the client returns a response. If the client fails to return a response after a number of consecutive handshake attempts (two by default), the access device logs off the client. This handshake mechanism enables timely release of the network resources used by 802.1X users that have abnormally gone offline.

13.     The client can also send an EAPOL-Logoff packet to ask the access device for a logoff.

14.     In response to the EAPOL-Logoff packet, the access device changes the status of the controlled port from authorized to unauthorized. Then, the access device sends an EAP-Failure packet to the client.

EAP termination

Figure 10 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that CHAP authentication is used.

Figure 10 802.1X authentication procedure in EAP termination mode

 

In EAP termination mode, the access device rather than the authentication server generates an MD5 challenge for password encryption. The access device then sends the MD5 challenge together with the username and encrypted password in a standard RADIUS packet to the RADIUS server.

802.1X authentication initiation

Both the 802.1X client and the access device can initiate 802.1X authentication.

802.1X client as the initiator

The client sends an EAPOL-Start packet to the access device to initiate 802.1X authentication. The destination MAC address of the packet is the IEEE 802.1X specified multicast address 01-80-C2-00-00-03 or the broadcast MAC address. If any intermediate device between the client and the authentication server does not support the multicast address, you must use an 802.1X client that can send broadcast EAPOL-Start packets. For example, you can use the iNode 802.1X client.

Access device as the initiator

If the client cannot send EAPOL-Start packets, configure the access device to initiate authentication. One example is the 802.1X client available with Windows XP.

The access device supports the following modes:

·          Multicast trigger mode—The access device multicasts EAP-Request/Identity packets to initiate 802.1X authentication at the identity request interval.

·          Unicast trigger mode—Upon receiving a frame from an unknown MAC address, the access device sends an EAP-Request/Identity packet out of the receiving port to the MAC address. The device retransmits the packet if no response has been received within the identity request timeout interval. This process continues until the maximum number of request attempts set by using the dot1x retry command is reached.

The username request timeout timer sets both the identity request interval for the multicast trigger and the identity request timeout interval for the unicast trigger.

Access control methods

The device implements port-based access control as defined in the 802.1X protocol. Once an 802.1X user passes authentication on a port, any subsequent user can access the network through the port without authentication. When the authenticated user logs off, all other users are logged off.

802.1X VLAN manipulation

Authorization VLAN

The authorization VLAN controls the access of an 802.1X user to authorized network resources. The device supports authorization VLANs assigned locally or by a remote server.

 

	IMPORTANT: Only remote servers can assign tagged authorization VLANs.

‌

Remote VLAN authorization

In remote VLAN authorization, you must configure an authorization VLAN for a user on the remote server. After the user authenticates to the server, the server assigns authorization VLAN information to the device. Then, the device assigns the user access port to the authorization VLAN as a tagged or untagged member.

The device supports assignment of the following authorization VLAN information by the remote server:

·          VLAN ID.

·          VLAN name, which must be the same as the VLAN description on the access device.

·          A string of VLAN IDs and VLAN names.

In the string, some VLANs are represented by their IDs, and some VLANs are represented by their names.

·          VLAN group name.

For more information about VLAN groups, see Layer 2—LAN Switching Configuration Guide.

·          VLAN ID with a suffix of t or u.

The t and u suffixes require the device to assign the access port to the VLAN as a tagged or untagged member, respectively. For example, 2u indicates assigning the port to VLAN 2 as an untagged member.

If a VLAN name or VLAN group name is assigned, the device converts the information into a VLAN ID before VLAN assignment.

 

	IMPORTANT: For a VLAN represented by its VLAN name to be assigned successfully, you must make sure the VLAN has been created on the device. To assign VLAN IDs with suffixes, make sure the user access port is a hybrid or trunk port that performs port-based access control.

‌

	IMPORTANT: To ensure a successful assignment, the authorization VLANs assigned by the remote server cannot be any of the following types: ·      Dynamically learned VLANs. ·      Reserved VLANs. ·      Super VLANs.

 

If the server assigns a group of VLANs, the access device selects a VLAN as described in Table 2.

Table 2 Authorization VLAN selection from a group of VLANs

VLAN information	Authorization VLAN selection
VLANs by IDs VLANs by names VLAN group name	The device selects the VLAN with the lowest ID from the VLAN group. All subsequent 802.1X users are assigned to that VLAN.
VLAN IDs with suffixes	1.       The device selects the leftmost VLAN ID without a suffix, or the leftmost VLAN ID suffixed by u as an untagged VLAN, whichever is more leftmost. 2.       The device assigns the untagged VLAN to the port as the PVID, and it assigns the remaining as tagged VLANs. If no untagged VLAN is assigned, the PVID of the port does not change. The port permits traffic from these tagged and untagged VLANs to pass through. For example, the authentication server sends the string 1u 2t 3 to the access device for a user. The device assigns VLAN 1 as an untagged VLAN and all remaining VLANs (including VLAN 3) as tagged VLANs. VLAN 1 becomes the PVID.

 

Local VLAN authorization

To perform local VLAN authorization for a user, specify the VLAN ID in the authorization attribute list of the local user account for that user. For each local user, you can specify only one authorization VLAN ID. The user access port is assigned to the VLAN as an untagged member.

 

	IMPORTANT: Local VLAN authorization does not support assignment of tagged VLANs.

‌

For more information about local user configuration, see AAA configuration in BRAS Services Configuration Guide.

Authorization VLAN manipulation on an 802.1X-enabled port

Table 3 describes how the access device handles VLANs (except for the VLANs specified with suffixes) on an 802.1X-enabled port.

Table 3 VLAN manipulation when authorization VLAN is configured

Port access control method

VLAN manipulation

Port-based

The device assigns the port to the first authenticated user's authorization VLAN. All subsequent 802.1X users can access the VLAN without authentication. If the authorization VLAN has the untagged attribute, the device assigns the port to the authorization VLAN as an untagged member and sets the VLAN as the PVID. If the authorization VLAN has the tagged attribute, the device assigns the port to the VLAN as a tagged member without changing the PVID. NOTE: The tagged attribute is supported only on trunk and hybrid ports.

 

IMPORTANT: ·      If the users are attached to a port whose link type is access, make sure the authorization VLAN assigned by the server has the untagged attribute. VLAN assignment will fail if the server issues a VLAN that has the tagged attribute. ·      When you assign VLANs to users attached to a trunk port or a hybrid port, make sure there is only one untagged VLAN. If a different untagged VLAN is assigned to a subsequent user, the user cannot pass authentication. ·      As a best practice to enhance network security, do not use the port hybrid vlan command to assign a hybrid port to an authorization VLAN as a tagged member.

 

Guest VLAN

The 802.1X guest VLAN on a port accommodates users that have not performed 802.1X authentication. Users in the guest VLAN can access a limited set of network resources, such as a software server, to download antivirus software and system patches. Once a user in the guest VLAN passes 802.1X authentication, it is removed from the guest VLAN and can access authorized network resources.

The access device handles VLANs on an 802.1X-enabled port  as shown in Table 4:

Table 4 VLAN manipulation when a guest VLAN is configured

Authentication status	VLAN manipulation
A user accesses the 802.1X-enabled port when the port is in auto state.	The device assigns the port to the 802.1X guest VLAN. All 802.1X users on this port can access only resources in the guest VLAN. The guest VLAN assignment varies by port link mode. For more information, see Table 3 in "Authorization VLAN."
A user in the 802.1X guest VLAN fails 802.1X authentication.	If an 802.1X Auth-Fail VLAN is available, the device assigns the port to the Auth-Fail VLAN. All users on this port can access only resources in the Auth-Fail VLAN. If no Auth-Fail VLAN is configured, the port is still in the 802.1X guest VLAN. All users on the port are in the guest VLAN. For information about the 802.1X Auth-Fail VLAN, see "Auth-Fail VLAN."
A user in the 802.1X guest VLAN passes 802.1X authentication.	The device removes the port from the 802.1X guest VLAN and assigns the port to the authorization VLAN of the user. If the authentication server does not assign an authorization VLAN, the initial port VLAN ID (PVID) of the port applies. The user and all subsequent 802.1X users are assigned to the initial port VLAN. After the user logs off, the port is assigned to the guest VLAN again. NOTE: The initial PVID of an 802.1X-enabled port refers to the PVID used by the port before the port is assigned to any 802.1X VLANs.

 

Auth-Fail VLAN

The 802.1X Auth-Fail VLAN on a port accommodates users that have failed 802.1X authentication because of the failure to comply with the organization security strategy. For example, the VLAN accommodates users that have entered a wrong password. Users in the Auth-Fail VLAN can access a limited set of network resources, such as a software server, to download antivirus software and system patches.

The access device handles VLANs on an 802.1X-enabled port  as shown in Table 5:

Table 5 VLAN manipulation when an Auth-Fail VLAN is configured

Authentication status	VLAN manipulation
A user accesses the port and fails 802.1X authentication.	The device assigns the port to the Auth-Fail VLAN. All 802.1X users on this port can access only resources in the Auth-Fail VLAN. The Auth-Fail VLAN assignment varies by port link mode. For more information, see Table 3 in "Authorization VLAN."
A user in the 802.1X Auth-Fail VLAN fails 802.1X authentication.	The port is still in the Auth-Fail VLAN, and all 802.1X users on this port are in this VLAN.
A user in the 802.1X Auth-Fail VLAN passes 802.1X authentication.	The device assigns the port to the authorization VLAN of the user, and it removes the port from the Auth-Fail VLAN. If the authentication server does not assign an authorization VLAN, the initial PVID of the port applies. The user and all subsequent 802.1X users are assigned to the initial PVID. After the user logs off, the port is assigned to the guest VLAN. If no guest VLAN is configured, the port is assigned to the initial PVID of the port.

 

Critical VLAN

The 802.1X critical VLAN on a port accommodates 802.1X users that have failed authentication because none of the RADIUS servers in their ISP domain are reachable. Users in the critical VLAN can access a limited set of network resources depending on the configuration.

The critical VLAN feature takes effect when 802.1X authentication is performed only through RADIUS servers. If an 802.1X user fails local authentication after RADIUS authentication, the user is not assigned to the critical VLAN. For more information about the authentication methods, see AAA configuration in BRAS Services Configuration Guide.

The access device handles VLANs on an 802.1X-enabled port  as shown in Table 6:

Table 6 VLAN manipulation when a critical VLAN is configured

Authentication status	VLAN manipulation
A user accesses the port and fails 802.1X authentication because all the RADIUS servers are unreachable.	The device assigns the port to the critical VLAN. The 802.1X user and all subsequent 802.1X users on this port can access only resources in the 802.1X critical VLAN. The critical VLAN assignment varies by port link mode. For more information, see Table 3 in "Authorization VLAN."
A user in the 802.1X critical VLAN fails authentication because all the RADIUS servers are unreachable.	The port is still in the critical VLAN.
A user in the 802.1X critical VLAN fails authentication for any reasons other than unreachable servers.	If an 802.1X Auth-Fail VLAN has been configured, the port is assigned to the Auth-Fail VLAN. If no 802.1X Auth-Fail VLAN is configured, the port is assigned to the initial PVID of the port.
A user in the 802.1X critical VLAN passes 802.1X authentication.	The device assigns the port to the authorization VLAN of the user, and it removes the port from the 802.1X critical VLAN. If the authentication server does not assign an authorization VLAN, the initial PVID of the port applies. The user and all subsequent 802.1X users are assigned to this port VLAN. After the user logs off, the port is assigned to the guest VLAN. If no 802.1X guest VLAN is configured, the initial PVID of the port is restored.
A user in the 802.1X guest VLAN fails authentication because all the RADIUS servers are unreachable.	The device assigns the port to the 802.1X critical VLAN, and all 802.1X users on this port are in this VLAN.
A user in the 802.1X Auth-Fail VLAN fails authentication because all the RADIUS servers are unreachable.	The port is still in the 802.1X Auth-Fail VLAN. All 802.1X users on this port can access only resources in the 802.1X Auth-Fail VLAN.

 

If the port is added to the critical VLAN because no RADIUS servers are reachable, the device performs the following operations after it detects a reachable RADIUS server:

1.        Removes the port from the critical VLAN.

2.        Sends a multicast EAP-Request/Identity message out of the port to trigger authentication.

 

Configuring 802.1X

Restrictions: Hardware compatibility with 802.1X

This feature is supported only on CSPEX (except CSPEX-1204 and CSPEX-1104-E) and CEPC cards.

802.1X tasks at a glance

To configure 802.1X authentication, perform the following tasks:

1.        Enabling 802.1X

2.        Configuring basic 802.1X features

?  Enabling EAP relay or EAP termination

?  Setting the port authorization state

?  Enabling port-based access control

?  (Optional.) Specifying a mandatory authentication domain on a port

?  (Optional.) Setting the 802.1X authentication timeout timers

?  (Optional.) Setting the quiet timer

3.        (Optional.) Configuring 802.1X VLAN assignment

?  Configuring an 802.1X guest VLAN

?  Configuring an 802.1X Auth-Fail VLAN

?  Configuring an 802.1X critical VLAN

4.        (Optional.) Configuring other 802.1X features

?  Configuring the authentication trigger feature

Perform this task when 802.1X clients cannot initiate authentication.

?  Setting the maximum number of concurrent 802.1X users on a port

?  Setting the maximum number of authentication request attempts

?  Configuring online user handshake

?  Specifying supported domain name delimiters

Prerequisites for 802.1X

Before you configure 802.1X, complete the following tasks:

·          Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users.

·          If RADIUS authentication is used, create user accounts on the RADIUS server.

·          If local authentication is used, create local user accounts on the access device and set the service type to lan-access.

Enabling 802.1X

Restrictions and guidelines

·          For 802.1X to take effect on a port, you must enable it both globally and on the port.

·          Do not enable 802.1X on a port that is in a link aggregation or service loopback group.

Procedure

1.        Enter system view.

system-view

2.        Enable 802.1X globally.

dot1x

By default, 802.1X is disabled globally.

3.        Enter Ethernet interface view.

interface interface-type interface-number

4.        Enable 802.1X on a port.

dot1x

By default, 802.1X is disabled on a port.

Enabling EAP relay or EAP termination

About EAP mode selection

Consider the following factors to select a proper EAP mode:

·          Support of the RADIUS server for EAP packets.

·          Authentication methods supported by the 802.1X client and the RADIUS server.

Restrictions and guidelines

·          If EAP relay mode is used, the user-name-format command configured in RADIUS scheme view does not take effect. The access device sends the authentication data from the client to the server without any modification. For more information about the user-name-format command, see AAA commands in BRAS Services Command Reference.

·          You can use both EAP termination and EAP relay in any of the following situations:

?  The client is using only MD5-Challenge EAP authentication. If EAP termination is used, you must enable CHAP authentication on the access device.

?  The client is an iNode 802.1X client and initiates only the username and password EAP authentication. If EAP termination is used, you can enable either PAP or CHAP authentication on the access device. However, for the purpose of security, you must use CHAP authentication on the access device.

·          To use EAP-TLS, PEAP, or any other EAP authentication methods, you must use EAP relay. When you make your decision, see "Comparing EAP relay and EAP termination" for help.

Procedure

1.        Enter system view.

system-view

2.        Configure EAP relay or EAP termination.

dot1x authentication-method { chap | eap | pap }

By default, the access device performs EAP termination and uses CHAP to communicate with the RADIUS server.

Setting the port authorization state

About port authorization states

The port authorization state determines whether the client is granted access to the network. You can control the following authorization states of a port:

·          Authorized—Places the port in the authorized state, enabling users on the port to access the network without authentication.

·          Unauthorized—Places the port in the unauthorized state, denying any access requests from users on the port.

·          Auto—Places the port initially in unauthorized state to allow only EAPOL packets to pass. After a user passes authentication, sets the port in the authorized state to allow access to the network. You can use this option in most scenarios.

Procedure

1.        Enter system view.

system-view

2.        Enter Ethernet interface view.

interface interface-type interface-number

3.        Set the port authorization state.

dot1x port-control { authorized-force | auto | unauthorized-force }

By default, the auto state applies.

Enabling port-based access control

About port-based access control

The 802.1X feature on the device supports only port-based access control. To use 802.1X, you must enable port-based access control.

Procedure

1.        Enter system view.

system-view

2.        Enter Ethernet interface view.

interface interface-type interface-number

3.        Enable port-based access control.

dot1x port-method portbased

By default, port-based access control is disabled.

Specifying a mandatory authentication domain on a port

About the mandatory authentication domain

You can place all 802.1X users in a mandatory authentication domain for authentication, authorization, and accounting on a port. No user can use an account in any other domain to access the network through the port. The implementation of a mandatory authentication domain enhances the flexibility of 802.1X access control deployment.

Procedure

1.        Enter system view.

system-view

2.        Enter Ethernet interface view.

interface interface-type interface-number

3.        Specify a mandatory 802.1X authentication domain on the port.

dot1x mandatory-domain domain-name

By default, no mandatory 802.1X authentication domain is specified.

Setting the 802.1X authentication timeout timers

About 802.1X authentication timeout timers

The network device uses the following 802.1X authentication timeout timers:

·          Client timeout timer—Starts when the access device sends an EAP-Request/MD5-Challenge packet to a client. If no response is received when this timer expires, the access device retransmits the request to the client.

·          Server timeout timer—Starts when the access device sends a RADIUS Access-Request packet to the authentication server. If no response is received when this timer expires, the 802.1X authentication fails.

Restrictions and guidelines

In most cases, the default settings are sufficient. You can edit the timers, depending on the network conditions.

·          In a low-speed network, increase the client timeout timer.

·          In a network with authentication servers of different performance, adjust the server timeout timer.

Procedure

1.        Enter system view.

system-view

2.        Set the client timeout timer.

dot1x timer supp-timeout supp-timeout-value

The default is 30 seconds.

3.        Set the server timeout timer.

dot1x timer server-timeout server-timeout-value

The default is 100 seconds.

Setting the quiet timer

About the quiet timer

The quiet timer enables the access device to wait a period of time before it can process any authentication request from a client that has failed an 802.1X authentication.

Restrictions and guidelines

You can edit the quiet timer, depending on the network conditions.

·          In a vulnerable network, set the quiet timer to a high value.

·          In a high-performance network with quick authentication response, set the quiet timer to a low value.

Procedure

1.        Enter system view.

system-view

2.        Enable the quiet timer.

dot1x quiet-period

By default, the timer is disabled.

3.        (Optional.) Set the quiet timer.

dot1x timer quiet-period quiet-period-value

The default is 60 seconds.

Configuring an 802.1X guest VLAN

Restrictions and guidelines

·          You can configure only one 802.1X guest VLAN on a port. The 802.1X guest VLANs on different ports can be different.

·          Assign different IDs to the PVID and the 802.1X guest VLAN on a port. The assignment makes sure the port can correctly process incoming VLAN-tagged traffic.

·          You cannot specify a VLAN as both a super VLAN and an 802.1X guest VLAN. For information about super VLANs, see VLAN configuration in Layer 2—LAN Switching Configuration Guide.

Prerequisites

Before you specify a VLAN as an 802.1X guest VLAN, you must create that VLAN.

Procedure

1.        Enter system view.

system-view

2.        Enter Ethernet interface view.

interface interface-type interface-number

3.        Configure the 802.1X guest VLAN on the port.

dot1x guest-vlan guest-vlan-id

By default, no 802.1X guest VLAN exists.

Configuring an 802.1X Auth-Fail VLAN

Restrictions and guidelines

·          Assign different IDs to the PVID and the 802.1X Auth-Fail VLAN on a port. The assignment makes sure the port can correctly process VLAN-tagged incoming traffic.

·          You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on different ports can be different.

·          You cannot specify a VLAN as both a super VLAN and an 802.1X Auth-Fail VLAN. For information about super VLANs, see VLAN configuration in Layer 2—LAN Switching Configuration Guide.

Prerequisites

Before you specify a VLAN as an 802.1X Auth-Fail VLAN, you must create that VLAN.

Procedure

1.        Enter system view.

system-view

2.        Enter Ethernet interface view.

interface interface-type interface-number

3.        Configure the 802.1X Auth-Fail VLAN on the port.

dot1x auth-fail vlan authfail-vlan-id

By default, no 802.1X Auth-Fail VLAN exists.

Configuring an 802.1X critical VLAN

Restrictions and guidelines

·          Assign different IDs to the PVID and the 802.1X critical VLAN on a port. The assignment makes sure the port can correctly process VLAN-tagged incoming traffic.

·          You can configure only one 802.1X critical VLAN on a port. The 802.1X critical VLANs on different ports can be different.

·          You cannot specify a VLAN as both a super VLAN and an 802.1X critical VLAN. For information about super VLANs, see VLAN configuration in Layer 2—LAN Switching Configuration Guide.

Prerequisites

Before you specify a VLAN as an 802.1X critical VLAN, you must create that VLAN.

Procedure

1.        Enter system view.

system-view

2.        Enter Ethernet interface view.

interface interface-type interface-number

3.        Configure the 802.1X critical VLAN on the port.

dot1x critical vlan critical-vlan-id

By default, no 802.1X critical VLAN exists.

Configuring the authentication trigger feature

About authentication triggers

The authentication trigger feature enables the access device to initiate 802.1X authentication when 802.1X clients cannot initiate authentication.

This feature provides the multicast trigger and unicast trigger (see 802.1X authentication initiation in "802.1X overview").

Restrictions and guidelines

·          Enable the multicast trigger on a port when the clients attached to the port cannot send EAPOL-Start packets to initiate 802.1X authentication.

·          Enable the unicast trigger on a port if only a few 802.1X clients are attached to the port and these clients cannot initiate authentication.

·          To avoid duplicate authentication packets, do not enable both triggers on a port.

·          As a best practice, do not use the unicast trigger on a port that performs port-based access control. If you do so, users on that port might fail to come online.

Procedure

1.        Enter system view.

system-view

2.        (Optional.) Set the username request timeout timer.

dot1x timer tx-period tx-period-value

The default is 30 seconds.

3.        Enter Ethernet interface view.

interface interface-type interface-number

4.        Enable an authentication trigger.

dot1x { multicast-trigger | unicast-trigger }

By default, the multicast trigger is enabled, and the unicast trigger is disabled.

Setting the maximum number of concurrent 802.1X users on a port

About setting the maximum number of concurrent 802.1X users on a port

Perform this task to prevent the system resources from being overused.

Procedure

1.        Enter system view.

system-view

2.        Enter Ethernet interface view.

interface interface-type interface-number

3.        Set the maximum number of concurrent 802.1X users on a port.

dot1x max-user max-number

The default is 4294967295.

Setting the maximum number of authentication request attempts

About authentication request retransmission

The access device retransmits an authentication request if it does not receive any responses to the request from the client within a period of time. To set the time, use the dot1x timer tx-period tx-period-value command or the dot1x timer supp-timeout supp-timeout-value command. The access device stops retransmitting the request if it has made the maximum number of request transmission attempts but still receives no response.

Procedure

1.        Enter system view.

system-view

2.        Set the maximum number of attempts for sending an authentication request.

dot1x retry retries

The default setting is 2.

Configuring online user handshake

About online user handshake

The online user handshake feature checks the connectivity status of online 802.1X users. The access device sends handshake requests (EAP-Request/Identity) to online users at the interval specified by the dot1x timer handshake-period command. If the device does not receive any EAP-Response/Identity packets from an online user after it has made the maximum handshake attempts, the device sets the user to offline state. To set the maximum handshake attempts, use the dot1x retry command.

Typically, the device does not reply to 802.1X clients' EAP-Response/Identity packets with EAP-Success packets. Some 802.1X clients will go offline if they do not receive the EAP-Success packets for handshake. To avoid this issue, enable the online user handshake reply feature.

If iNode clients are deployed, you can also enable the online user handshake security feature to check authentication information in the handshake packets from clients. This feature can prevent 802.1X users that use illegal client software from bypassing iNode security check, such as dual network interface cards (NICs) detection. If a user fails the handshake security checking, the device sets the user to the offline state.

Restrictions and guidelines

·          If the network has 802.1X clients that cannot exchange handshake packets with the access device, disable the online user handshake feature. This operation prevents the 802.1X connections from being incorrectly torn down.

·          To use the online user handshake security feature, make sure the online user handshake feature is enabled.

·          The online user handshake security feature takes effect only on the network where the iNode client and IMC server are used.

·          Enable the online user handshake reply feature only if 802.1X clients will go offline without receiving EAP-Success packets from the device.

Procedure

1.        Enter system view.

system-view

2.        (Optional.) Set the handshake timer.

dot1x timer handshake-period handshake-period-value

The default is 15 seconds.

3.        Enter Ethernet interface view.

interface interface-type interface-number

4.        Enable the online user handshake feature.

dot1x handshake

By default, the feature is disabled.

5.        (Optional.) Enable the online user handshake security feature.

dot1x handshake secure

By default, the feature is disabled.

6.        (Optional.) Enable the 802.1X online user handshake reply feature.

dot1x handshake reply enable

By default, the device does not reply to 802.1X clients' EAP-Response/Identity packets during the online handshake process.

Specifying supported domain name delimiters

About supported domain name delimiters

By default, the access device supports the at sign (@) as the delimiter. You can also configure the access device to accommodate 802.1X users that use other domain name delimiters. The configurable delimiters include the at sign (@), backslash (\), dot (.), and forward slash (/). Usernames that include domain names can use the format of username@domain-name, domain-name\username, username.domain-name, or username/domain-name.

If an 802.1X username string contains multiple configured delimiters, the rightmost delimiter is the domain name delimiter. For example, if you configure the backslash (\), dot (.), and forward slash (/) as delimiters, the domain name delimiter for the username string 121.123/22\@abc is the backslash (\). The username is @abc and the domain name is 121.123/22.

Restrictions and guidelines

If a username string contains none of the delimiters, the access device authenticates the user in the mandatory or default ISP domain.

If you configure the access device to send usernames with domain names to the RADIUS server, make sure the domain delimiter can be recognized by the RADIUS server. For username format configuration, see the user-name-format command in BRAS Services Command Reference.

Procedure

1.        Enter system view.

system-view

2.        Specify a set of domain name delimiters for 802.1X users.

dot1x domain-delimiter string

By default, only the at sign (@) delimiter is supported.

Display and maintenance commands for 802.1X

Execute display commands in any view and reset commands in user view.

 

Task	Command
Display 802.1X session information, statistics, or configuration information of specified or all ports.	display dot1x [ sessions | statistics ] [ interface interface-type interface-number ]
(In standalone mode.) Display online 802.1X user information.	display dot1x connection [ interface interface-type interface-number | slot slot-number | user-mac mac-address | user-name name-string ]
(In IRF mode.) Display online 802.1X user information.	display dot1x connection [ chassis chassis-number slot slot-number | interface interface-type interface-number | user-mac mac-address | user-name name-string ]
Clear 802.1X statistics.	reset dot1x statistics [ interface interface-type interface-number ]

 

802.1X authentication configuration examples

Example: Configuring basic 802.1X authentication

Network configuration

As shown in Figure 11, the access device performs 802.1X authentication for users that connect to GigabitEthernet 3/1/1. Implement port-based access control on the port, so the logoff of one authenticated user will log off all the other online 802.1X users on the port.

Use RADIUS servers to perform authentication, authorization, and accounting for the 802.1X users. If RADIUS authentication fails, perform local authentication on the access device.

Configure the RADIUS server at 10.1.1.1/24 as the primary authentication and accounting server, and the RADIUS server at 10.1.1.2/24 as the secondary authentication and accounting server. Assign all users to the ISP domain bbb.

Set the shared key to name for packets between the access device and the authentication server. Set the shared key to money for packets between the access device and the accounting server.

Figure 11 Network diagram

‌

Procedure

For information about the RADIUS commands used on the access device in this example, see BRAS Services Command Reference.

1.        Configure the RADIUS servers and add user accounts for the 802.1X users. Make sure the RADIUS servers can provide authentication, authorization, and accounting services. (Details not shown.)

2.        Assign an IP address to each interface on the access device. (Details not shown.)

3.        Configure user accounts for the 802.1X users on the access device:

# Add a local network access user with username localuser and password localpass in plaintext. (Make sure the username and password are the same as those configured on the RADIUS servers.)

<Device> system-view

[Device] local-user localuser class network

[Device-luser-network-localuser] password simple localpass

# Set the service type to lan-access.

[Device-luser-network-localuser] service-type lan-access

[Device-luser-network-localuser] quit

4.        Configure a RADIUS scheme on the access device:

# Create a RADIUS scheme named radius1 and enter RADIUS scheme view.

[Device] radius scheme radius1

# Specify the IP addresses of the primary authentication and accounting RADIUS servers.

[Device-radius-radius1] primary authentication 10.1.1.1

[Device-radius-radius1] primary accounting 10.1.1.1

# Configure the IP addresses of the secondary authentication and accounting RADIUS servers.

[Device-radius-radius1] secondary authentication 10.1.1.2

[Device-radius-radius1] secondary accounting 10.1.1.2

# Specify the shared key between the access device and the authentication server.

[Device-radius-radius1] key authentication simple name

# Specify the shared key between the access device and the accounting server.

[Device-radius-radius1] key accounting simple money

# Exclude the ISP domain names from the usernames sent to the RADIUS servers.

[Device-radius-radius1] user-name-format without-domain

[Device-radius-radius1] quit

 

	NOTE: The access device must use the same username format as the RADIUS server. If the RADIUS server includes the ISP domain name in the username, so must the access device.

 

5.        Configure the ISP domain on the access device:

# Create an ISP domain named bbb and enter ISP domain view.

[Device] domain name bbb

# Apply RADIUS scheme radius1 to the ISP domain, and specify local authentication as the secondary authentication method.

[Device-isp-bbb] authentication lan-access radius-scheme radius1 local

[Device-isp-bbb] authorization lan-access radius-scheme radius1 local

[Device-isp-bbb] accounting lan-access radius-scheme radius1 local

[Device-isp-bbb] quit

6.        Configure 802.1X on the access device:

# Enable 802.1X on GigabitEthernet 3/1/1.

[Device] interface gigabitethernet 3/1/1

[Device-GigabitEthernet3/1/1] dot1x

# Enable port-based access control on the port.

[Device-GigabitEthernet3/1/1] dot1x port-method portbased

# Specify ISP domain bbb as the mandatory domain.

[Device-GigabitEthernet3/1/1] dot1x mandatory-domain bbb

[Device-GigabitEthernet3/1/1] quit

# Enable 802.1X globally.

[Device] dot1x

7.        Configure the 802.1X client. If an iNode client is used, do not select the Carry version info option in the client configuration. (Details not shown.)

Verifying the configuration

# Verify the 802.1X configuration on GigabitEthernet 3/1/1.

[Device] display dot1x interface gigabitethernet 3/1/1

# Display the user connection information after an 802.1X user passes authentication.

[Device] display dot1x connection

Example: Configuring 802.1X guest VLAN and authorization VLAN

Network configuration

As shown in Figure 12, use RADIUS servers to perform authentication, authorization, and accounting for 802.1X users that connect to GigabitEthernet 3/1/2. Implement port-based access control on the port.

Configure VLAN 10 as the 802.1X guest VLAN on GigabitEthernet 3/1/2. The host and the update server are both in VLAN 10, and the host can access the update server and download the 802.1X client software.

After the host passes 802.1X authentication, the access device assigns the host to VLAN 5 where GigabitEthernet 3/1/3 is. The host can access the Internet.

Figure 12 Network diagram

‌

Procedure

For information about the RADIUS commands used on the access device in this example, see BRAS Services Command Reference.

1.        Configure the RADIUS server to provide authentication, authorization, and accounting services. Configure user accounts and authorization VLAN (VLAN 5 in this example) for the users. (Details not shown.)

2.        Create VLANs, and assign ports to the VLANs on the access device.

<Device> system-view

[Device] vlan 1

[Device-vlan1] port gigabitethernet 3/1/2

[Device-vlan1] quit

[Device] vlan 10

[Device-vlan10] port gigabitethernet 3/1/1

[Device-vlan10] quit

[Device] vlan 2

[Device-vlan2] port gigabitethernet 3/1/4

[Device-vlan2] quit

[Device] vlan 5

[Device-vlan5] port gigabitethernet 3/1/3

[Device-vlan5] quit

3.        Configure a RADIUS scheme on the access device:

# Create RADIUS scheme 2000 and enter RADIUS scheme view.

[Device] radius scheme 2000

# Specify the server at 10.11.1.1 as the primary authentication server, and set the authentication port to 1812.

[Device-radius-2000] primary authentication 10.11.1.1 1812

# Specify the server at 10.11.1.1 as the primary accounting server, and set the accounting port to 1813.

[Device-radius-2000] primary accounting 10.11.1.1 1813

# Set the shared key to abc in plain text for secure communication between the authentication server and the device.

[Device-radius-2000] key authentication simple abc

# Set the shared key to abc in plain text for secure communication between the accounting server and the device.

[Device-radius-2000] key accounting simple abc

# Exclude the ISP domain names from the usernames sent to the RADIUS server.

[Device-radius-2000] user-name-format without-domain

[Device-radius-2000] quit

4.        Configure an ISP domain on the access device:

# Create ISP domain bbb and enter ISP domain view.

[Device] domain name bbb

# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and accounting.

[Device-isp-bbb] authentication lan-access radius-scheme 2000

[Device-isp-bbb] authorization lan-access radius-scheme 2000

[Device-isp-bbb] accounting lan-access radius-scheme 2000

[Device-isp-bbb] quit

5.        Configure 802.1X on the access device:

# Enable 802.1X on GigabitEthernet 3/1/2.

[Device] interface gigabitethernet 3/1/2

[Device-GigabitEthernet3/1/2] dot1x

# Implement port-based access control on the port.

[Device-GigabitEthernet3/1/2] dot1x port-method portbased

# Set the port authorization mode to auto. By default, the port uses the auto mode.

[Device-GigabitEthernet3/1/2] dot1x port-control auto

# Specify VLAN 10 as the 802.1X guest VLAN on GigabitEthernet 3/1/2.

[Device-GigabitEthernet3/1/2] dot1x guest-vlan 10

[Device-GigabitEthernet3/1/2] quit

# Enable 802.1X globally.

[Device] dot1x

6.        Configure the 802.1X client. Make sure the 802.1X client can update its IP address after the access port is assigned to the guest VLAN or an authorization VLAN. (Details not shown.)

Verifying the configuration

# Verify the 802.1X guest VLAN configuration on GigabitEthernet 3/1/2.

[Device] display dot1x interface gigabitethernet 3/1/2

# Verify that GigabitEthernet 3/1/2 is assigned to VLAN 10 before any user passes authentication on the port.

[Device] display vlan 10

# After a user passes authentication, display information on GigabitEthernet 3/1/2. Verify that GigabitEthernet 3/1/2 is assigned to VLAN 5.

[Device] display interface gigabitethernet 3/1/2