Contents

802.1X overview·· 1

About the 802.1X protocol 1

802.1X architecture· 1

Packet exchange methods· 1

Packet formats· 3

802.1X authentication procedures· 4

802.1X authentication initiation· 7

IPoE 802.1X authentication· 7

Periodic 802.1X reauthentication· 8

Configuring 802.1X·· 9

Restrictions and guidelines: 802.1X configuration· 9

802.1X tasks at a glance· 9

Prerequisites for 802.1X· 10

Enabling IPoE 802.1X authentication· 10

Enabling EAP relay or EAP termination· 10

Specifying a mandatory authentication domain on an interface· 11

Specifying supported domain name delimiters· 11

Setting the 802.1X authentication timeout timers· 12

Enabling periodic 802.1X reauthentication feature· 12

Setting the quiet timer 13

Setting the maximum number of concurrent 802.1X users on an interface· 13

Enabling 802.1X max user alarm on an interface· 14

Setting the maximum number of authentication request attempts· 14

Discarding duplicate 802.1X EAPOL-Start requests· 15

Configuring online user handshake· 15

Display and maintenance commands for 802.1X· 16

IPoE 802.1X authentication configuration examples· 17

 

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 users and devices connected to 802.1X-enabled LAN ports.

 

NOTE: 802.1X in a traditional wired network is a Layer 2 port-based network access control protocol. IPoE 802.1X authentication is a Layer 3 interface-based 802.1X feature that cooperates with IPoE access. This chapter describes Layer 3 interface-based 802.1X authentication.

 

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

 

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 2.

Figure 2 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 3, 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 3 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 4 shows the EAP packet format.

Figure 4 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 5 shows the EAPOL packet format.

Figure 5 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 "Configuring AAA."

·     EAP-Message

RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 6. 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 6 EAP-Message attribute format

 

·     Message-Authenticator

As shown in Figure 7, 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 7 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 8 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that MD5-Challenge EAP authentication is used.

Figure 8 IEEE 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 identify 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 9 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that CHAP authentication is used.

Figure 9 IEEE 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. The access device supports the unicast trigger mode. Upon receiving a packet from an unknown MAC address, the access device sends an EAP-Request/Identity packet out of the receiving interface 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.

IPoE 802.1X authentication

IPoE 802.1X authentication is a Layer 3 interface-based authentication method that must cooperate with IPoE access.

To enable IPoE 802.1X authentication on a Layer 3 interface, you must set the authentication method to 802.1X authentication for IPoE users on the interface.

IPoE 802.1X authentication supports DHCP users, IPv6 ND RS users, and static users. The authentication process includes two phases, including preauthentication and postauthentication.

When 802.1X authentication is not prioritized, an 802.1X user must perform IPoE preauthentication and 802.1X postauthentication to come online. When 802.1X authentication is prioritized, an 802.1X user only needs to perform one authentication on the 802.1X client. Select whether to prioritize 802.1X authentication as needed.

When 802.1X authentication is not prioritized, an IPoE user comes online in the following process:

·     In the preauthentication phase:

The  user access procedure in the preauthentication phase is the same as the user access procedure in the bind authentication mode. This phase does not involve 802.1X authentication. If the 802.1X client of the user has come online before the user enters the preauthentication phase, IPoE does not use the IPoE preauthentication domain to perform authentication for the user. Instead, it directly allows the user to come online in the post authentication domain based on the 802.1X authentication result. In this case, the recorded user information is the 802.1X user information, including the 802.1X username, authentication domain, and authorization attributes.

·     In the postauthentication phase:

After an IPoE user comes online in the preauthentication domain, the system determines the processing method in the postauthentication domain according to the authentication result of the 802.1X client as follows:

¡     If the 802.1X client of the user is already online, IPoE uses the 802.1X authentication result to have the user come online directly in the postauthentication domain. In this case, the recorded user information is the 802.1X user information, including the 802.1X username, authentication domain, and authorization attributes.

¡     If the 802.1X client of the user is not online, the IPoE user stays in the preauthentication phase. When the 802.1X client of the user comes online, the processing is the same as that in the previous list.

¡     When both 802.1X authentication and Web authentication are configured on an interface, the following rules apply:

-     If an IPoE user has come online in the postauthentication domain through Web authentication before the 802.1X client comes online, the device will force the user to return to the preauthentication domain from the postauthentication domain of Web authentication after the 802.1X client comes online, and then the user uses 802.1X authentication to come online in the postauthentication domain of 802.1X authentication.

-     After an IPoE user uses 802.1X authentication to come online in the postauthentication domain, the user cannot use Web authentication to come online in the postauthentication domain.

When 802.1X authentication is prioritized, the following rules apply when an IPoE user tries to come online in the preauthentication phase:

·     If the 802.1X client of the IPoE user is not online, the IPoE user will stay in the state before the preauthentication phase. After the 802.1X client of the user comes online, IPoE uses the 802.1X authentication result to have the user come online directly in the postauthentication domain. In this case, the recorded user information is the 802.1X user information, including the 802.1X username, authentication domain, and authorization attributes.

·     If the 802.1X client of the IPoE user is already online, IPoE uses the 802.1X authentication result to have the user come online directly in the postauthentication domain. In this case, the recorded user information is the 802.1X user information, including the 802.1X username, authentication domain, and authorization attributes.

·     If the 802.1X client of the IPoE user fails to pass authentication, the IPoE user continues to come online through the IPoE authentication process. In this case, the recorded user information is the IPoE user information, including the IPoE username, authentication domain, and authorization attributes.

For more information about IPoE, see "Configuring IPoE."

Periodic 802.1X reauthentication

Periodic 802.1X reauthentication tracks the connection status of online users and updates the authorization attributes assigned by the server. The reauthentication interval is user configurable.

The server-assigned session timeout timer (Session-Timeout attribute) and termination action (Termination-Action attribute) together can affect the periodic online user reauthentication feature. To display the server-assigned Session-Timeout and Termination-Action attributes, use the display dot1x connection command.

·     If the termination action is Default (logoff), periodic online user reauthentication on the device takes effect only when the periodic reauthentication timer is shorter than the session timeout timer.

·     If the termination action is Radius-request, the periodic online user reauthentication settings on the device do not take effect. The device reauthenticates the online 802.1X users after the session timeout timer expires.

If no session timeout timer is assigned by the server, whether the device performs periodic 802.1X reauthentication depends on the periodic reauthentication configuration on the device. Support for the assignment of Session-Timeout and Termination-Action attributes depends on the server model.

By default, the device logs off online 802.1X users if no server is reachable for 802.1X reauthentication. The keep-online feature keeps authenticated 802.1X users online when no server is reachable for 802.1X reauthentication.

Configuring 802.1X

Restrictions and guidelines: 802.1X configuration

For information about the cards that support this feature in standard or SDN WAN operating mode, see IPoE configuration in BRAS Services Configuration Guide.

When you configure 802.1X authentication, follow these restrictions and guidelines:

·     The 802.1X authentication configuration can take effect on an interface only when the interface operates in Layer 2 IPoE access mode.

·     On an interface, IPoE 802.1X authentication is mutually exclusive with Layer 3 IPoE access mode, IPoE interface-leased users, IPoE subnet-leased users, and IPoE L2VPN-leased users.

·     On an interface, you can configure both IPoE 802.1X authentication and IPoE Web authentication. IPoE 802.1X authentication is mutually exclusive with other IPoE authentication methods. When both 802.1X authentication and Web authentication are configured on an interface, a user can use only one of them to perform authentication and come online at a time. 802.1X authentication takes priority over Web authentication.

·     802.1X features in this chapter are supported only on the following interfaces:

¡     Layer 3 Ethernet interfaces.

¡     Layer 3 aggregate interfaces.

¡     Layer 3 Ethernet subinterfaces.

¡     Layer 3 aggregate subinterfaces.

·     If the final effective authentication method is none in the process of 802.1X authentication, the device directly responds to the 802.1X client with an authentication success packet. Whether the 802.1X user is successfully connected to the network is determined by the implementation of the 802.1X client itself.

802.1X tasks at a glance

To configure 802.1X authentication, perform the following tasks:

1.     Enabling IPoE 802.1X authentication

2.     Configuring basic 802.1X features

¡     Enabling EAP relay or EAP termination

¡     (Optional.) Specifying a mandatory authentication domain on an interface

¡     (Optional.) Specifying supported domain name delimiters

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

¡     (Optional.) Enabling periodic 802.1X reauthentication feature

¡     (Optional.) Setting the quiet timer

3.     (Optional.) Configuring other 802.1X features

¡     Setting the maximum number of concurrent 802.1X users on an interface

¡     Enabling 802.1X max user alarm on an interface

¡     Setting the maximum number of authentication request attempts

¡     Discarding duplicate 802.1X EAPOL-Start requests

¡     Configuring online user handshake

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 IPoE 802.1X authentication

Restrictions and guidelines

·     Do not enable IPoE 802.1X authentication on an interface that is in a link aggregation.

·     802.1X supports dual stacks. As a best practice, enable IPoE for both the IPv4 and IPv6 stacks when you configure Layer 2 access mode.

Procedure

For more information about the procedures for configuring IPoE 802.1X authentication, see see IPoE configuration in BRAS Services Configuration Guide.

Enabling EAP relay or EAP termination

About this task

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

·     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.

·     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 BRAS Services Command Reference.

·     EAP relay mode is not supported when the device performs local authentication.

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.

Specifying a mandatory authentication domain on an interface

About this task

You can place all 802.1X users in a mandatory authentication domain for authentication, authorization, and accounting on an interface. No user can use an account in any other domain to access the network through the interface. 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 interface view.

interface interface-type interface-number

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

dot1x mandatory-domain domain-name

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

Specifying supported domain name delimiters

About this task

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.

Setting the 802.1X authentication timeout timers

About this task

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

·     Username request timeout timer—Starts when the device sends an EAP-Request/Identity packet to a client. If the device does not receive a response before this timer expires, it retransmits the request.

·     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 username request timeout timer.

dot1x timer tx-period tx-period-value

The default is 30 seconds.

3.     Set the client timeout timer.

dot1x timer supp-timeout supp-timeout-value

The default is 30 seconds.

4.     Set the server timeout timer.

dot1x timer server-timeout server-timeout-value

The default is 100 seconds.

Enabling periodic 802.1X reauthentication feature

1.     Enter system view.

system-view

2.     (Optional.) Set the periodic reauthentication timer.

dot1x timer reauth-period reauth-period-value

The default is 3600 seconds.

3.     Enter interface view.

interface interface-type interface-number

4.     Enable periodic online user reauthentication.

dot1x re-authenticate

By default, periodic online user reauthentication is disabled.

5.     (Optional.) Enable the keep-online feature for 802.1X users.

dot1x re-authenticate { authentication-fail | server-unreachable } keep-online

By default, this feature is disabled. The device logs off online 802.1X users if no authentication server is reachable for 802.1X reauthentication or the reauthentication fails.

Setting the quiet timer

About this task

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.

To restrict the number of consecutive authentication failures allowed for a client within a time period, specify the fail-retry fail-retries and retry-period retry-period-value options. The device places a client in quiet state if the maximum number of consecutive authentication failures has been reached for the client within the specified retry timeout period. If the timer for the client timeout period expires before the maximum number of consecutive authentication failures is reached, the device recounts the number of authentication failures. However, if the client still fails authentication when the timer expires, the device places the client in quiet state.

If you do not specify the fail-retry fail-retries or retry-period retry-period-value option, the device places a user in quiet state after the user fails authentication for the first time. If you set the fail-retry fail-retries option to 1, the device also places a user in quiet state after the user fails authentication for the first time.

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 [ fail-retry fail-retries retry-period retry-period-value ]

The default is 60 seconds.

Setting the maximum number of concurrent 802.1X users on an interface

About this task

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

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Set the maximum number of concurrent 802.1X users on an interface.

dot1x max-user max-number

By default, an interface supports a maximum of 4294967295 concurrent 802.1X users.

Enabling 802.1X max user alarm on an interface

About this task

When the percentage of the number of the current online 802.1X users to the maximum number of 802.1X users on an interface reaches the alarm threshold, the device sends an alarm notification. When the percentage of the number of the current online 802.1X users to the maximum number of 802.1X users on an interface drops to the alarm clear threshold, the device sends an alarm clear notification. To set the maximum number of concurrent 802.1X users on an interface, use the  dot1x max-user command.

The device sends an alarm notification only when the alarm threshold is crossed for the first time. It does not send another alarm notification before the alarm is cleared.

Restrictions and guidelines

The alarm threshold must be greater than the alarm clear threshold.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Enable 802.1X max user alarm on the interface and set the alarm threshold and alarm clear threshold.

dot1x max-user-alarm high-threshold high-threshold clear-threshold clear-threshold

By default, 802.1X max user alarm is disabled on an interface.

Setting the maximum number of authentication request attempts

About this task

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. The time for an EAP-Request/Identity request is configured by using the dot1x timer tx-period command. To set the time for an EAP-Request/MD5 Challenge request, use 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.

Discarding duplicate 802.1X EAPOL-Start requests

About this task

During 802.1X authentication, the device might receive duplicate EAPOL-Start requests from an 802.1X user. By default, the device delivers the duplicate EAPOL-Start requests to the authentication server as long as they are legal. However, this mechanism might result in authentication failure if the authentication server cannot respond to duplicate EAPOL-Start requests. To resolve this issue, perform this task on the user access interface to discard duplicate EAPOL-Start requests.

Restrictions and guidelines

As a best practice, perform this task only if the server cannot respond to duplicate EAPOL-Start requests. Do not perform this task in other situations.

Procedure

1.     Enter system view.

system-view

2.     Enter interface view.

interface interface-type interface-number

3.     Discard duplicate EAPOL-Start requests on the interface.

dot1x duplicate-eapol-start discard

By default, the device does not discard duplicate EAPOL-Start requests on an interface if the requests are legal.

Configuring online user handshake

About this task

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 interface view.

interface interface-type interface-number

4.     Enable the online user handshake feature.

dot1x handshake

By default, the online user handshake 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.

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 interfaces.	display dot1x [ sessions | statistics ] [ interface interface-type interface-number ]
Display online 802.1X user information.	In standalone mode: display dot1x connection [ interface interface-type interface-number | slot slot-number | user-mac mac-address | user-name name-string ] In IRF mode: 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 ]

 

IPoE 802.1X authentication configuration examples

For information about the exmaple for configuring PoE 802.1X authentication, see IPoE configuration in BRAS Services Configuration Guide.