H3C S3100-52P Ethernet Switch Operation Manual-Release 1500(V1.02)

HomeSupportResource CenterSwitchesH3C S3100 Switch SeriesH3C S3100 Switch SeriesTechnical DocumentsConfigure & DeployConfiguration GuidesH3C S3100-52P Ethernet Switch Operation Manual-Release 1500(V1.02)
15-802.1x Operation
Title Size Download
15-802.1x Operation 305.71 KB

Chapter 1  802.1x Configuration

1.1  Introduction to 802.1x

The 802.1x protocol (802.1x for short) was developed by IEEE802 LAN/WAN committee to address security issues of wireless LANs. It was then used in Ethernet as a common access control mechanism for LAN ports to address mainly authentication and security problems.

802.1x is a port-based network access control protocol. It authenticates and controls devices requesting for access in terms of the ports of LAN access control devices. With the 802.1x protocol employed, a user-side device can access the LAN only when it passes the authentication. Those fail to pass the authentication are denied when accessing the LAN, as if they are disconnected from the LAN.

1.1.1  Architecture of 802.1x Authentication

802.1x adopts a client/server architecture with three entities: a supplicant system, an authenticator system, and an authentication server system, as shown in the following figure.

Figure 1-1 Architecture of 802.1x authentication

l           The supplicant system is an entity residing at one end of a LAN segment and is authenticated by the authenticator system connected to the other end of the LAN segment. The supplicant system is usually a user terminal device. An 802.1x authentication is triggered when a user launches client program on the supplicant system. Note that the client program must support the EAPoL (extensible authentication protocol over LANs).

l           The authenticator system is an entity residing at one end of a LAN segment. It authenticates the supplicant systems connecting to the other end of the LAN segment. The authenticator system is usually an 802.1x-supported network device (such as a H3Cseries switch). It provides the port (physical or logical) for the supplicant system to access the LAN.

l           The authentication server system is an entity that provides authentication service to the authenticator system. Normally in the form of a RADIUS server, the authentication server system serves to perform AAA (authentication, authorization, and accounting) services to users. It also stores user information, such as user name, password, the VLAN a user belongs to, priority, and the ACLs (access control list) applied.

The four basic concept related to the above three entities are PAE, controlled port and uncontrolled port, the valid direction of a controlled port and the way a port is controlled.

I. PAE

A PAE (port access entity) is responsible for implementing algorithms and performing protocol-related operations in the authentication mechanism.

The authenticator system PAE authenticates the supplicant systems when they log into the LAN and controls the authorizing state (on/off) of the controlled ports according to the authentication result.

The supplicant system PAE responds to the authentication requests received from the authenticator system and submits user authentication information to the authenticator system. It also sends authentication requests and disconnection requests to the authenticator system PAE.

II. Controlled port and uncontrolled port

The Authenticator system provides ports for supplicant systems to access a LAN. Logically, a port of this kind is divided into a controlled port and an uncontrolled port.

l           The uncontrolled port can always send and receive packets. It mainly serves to forward EAPoL packets to ensure that a supplicant system can send and receive authentication requests.

l           The controlled port can be used to pass service packets when it is in authorized state. It is blocked when not in authorized state. In this case, no packets can pass through it.

l           Controlled port and uncontrolled port are two properties of a port. Packets reaching a port are visible to both the controlled port and uncontrolled port of the port.

III. The valid direction of a controlled port

When a controlled port is in unauthorized state, you can configure it to be a unidirectional port, which sends packets to supplicant systems only.

By default, a controlled port is a unidirectional port.

IV. The way a port is controlled

A port of a H3Cseries switch can be controlled in the following two ways.

l           Port-based authentication. When a port is controlled in this way, all the supplicant systems connected to the port can access the network without being authenticated after one supplicant system among them passes the authentication. And when the authenticated supplicant system goes offline, the others are denied as well.

l           MAC address-based authentication. All supplicant systems connected to a port have to be authenticated individually in order to access the network. And when a supplicant system goes offline, the others are not affected.

1.1.2  The Mechanism of an 802.1x Authentication System

IEEE 802.1x authentication system uses extensible authentication protocol (EAP) to exchange information between supplicant systems and the authentication servers.

Figure 1-2 The mechanism of an 802.1x authentication system

l           EAP protocol packets transmitted between the supplicant system PAE and the authenticator system PAE are encapsulated as EAPoL packets.

l           EAP protocol packets transmitted between the authenticator system PAE and the RADIUS server can either be encapsulated as EAPoR (EAP over RADIUS) packets or be terminated at system PAEs. The system PAEs then communicate with RADIUS servers through PAP (password authentication protocol) or CHAP (challenge-handshake authentication protocol] protocol packets.

l           When a supplicant system passes the authentication, the authentication server passes the information about the supplicant system to the authenticator system. The authenticator system in turn determines the state (authorized or unauthorized) of the controlled port according to the instructions (accept or reject) received from the RADIUS server.

1.1.3  Encapsulation of EAPoL Messages

I. The format of an EAPoL packet

EAPoL is a packet encapsulation format defined in 802.1x. To enable EAP protocol packets to be transmitted between supplicant systems and authenticator systems through LANs, EAP protocol packets are encapsulated in EAPoL format. The following figure illustrates the structure of an EAPoL packet.

Figure 1-3 The format of an EAPoL packet

In an EAPoL packet:

l           The PAE Ethernet type field holds the protocol identifier. The identifier for 802.1x is 0x888E.

l           The Protocol version field holds the version of the protocol supported by the sender of the EAPoL packet.

l           The Type field can be one of the following:

00: Indicates that the packet is an EAP-packet, which carries authentication information.

01: Indicates that the packet is an EAPoL-start packet, which initiates the authentication.

02: Indicates that the packet is an EAPoL-logoff packet, which sends logging off requests.

03: Indicates that the packet is an EAPoL-key packet, which carries key information.

04: Indicates that the packet is an EAPoL-encapsulated-ASF-Alert packet, which is used to support the alerting messages of ASF (alerting standards forum).

l           The Length field indicates the size of the Packet body field. A value of 0 indicates that the Packet Body field does not exist.

l           The Packet body field differs with the Type field.

Note that EAPoL-Start, EAPoL-Logoff, and EAPoL-Key packets are only transmitted between the supplicant system and the authenticator system. EAP-packets are encapsulated by RADIUS protocol to allow them successfully reach the authentication servers. Network management-related information (such as alarming information) is encapsulated in EAPoL-Encapsulated-ASF-Alert packets, which are terminated by authenticator systems.

II. The format of an EAP packet

For an EAPoL packet with the value of the Type field being EAP-packet, its Packet body field is an EAP packet, whose format is illustrated in Figure 1-4.

Figure 1-4 The format of an EAP packet

In an EAP packet:

l           The Code field indicates the EAP packet type, which can be Request, Response, Success, or Failure.

l           The Identifier field is used to match a Response packets with the corresponding Request packet.

l           The Length field indicates the size of an EAP packet, which includes the Code, Identifier, Length, and Data fields.

l           The Data field differs with the Code field.

A Success or Failure packet does not contain the Data field, so the Length field of it is 4.

Figure 1-5 shows the format of the Data field of a Request packet or a Response packet.

Figure 1-5 The format of the Data field of a Request packet or a Response packet

l           The Type field indicates the EAP authentication type. A value of 1 indicates Identity and that the packet is used to query the identity of the peer. A value of 4 represents MD5-Challenge (similar to PPP CHAP) and indicates that the packet includes query information.

l           The Type Date field differs with types of Request and Response packets.

III. Newly added fields for EAP authentication

Two fields, EAP-message and Message-authenticator, are added to a RADIUS protocol packet for EAP authentication. (Refer to the Introduction to RADIUS protocol section in the AAA,RADIUS,HWTACACS and EAD Operation part for information about the format of a RADIUS protocol packet.)

The EAP-message field, whose format is shown in Figure 1-6, is used to encapsulate EAP packets. The maximum size of the string field is 253 bytes. EAP packets with their size larger than 253 bytes are fragmented and are encapsulated in multiple EAP-message fields. The type code of the EAP-message field is 79.

Figure 1-6 The format of an EAP-message field

The Message-authenticator field, whose format is shown in Figure 1-7, is used to prevent unauthorized interception to access requesting packets during authentications using CHAP, EAP, and so on. A packet with the EAP-message field must also have the Message-authenticator field. Otherwise, the packet is regarded as invalid and is discarded.

Figure 1-7 The format of an Message-authenticator field

1.1.4  802.1x Authentication Procedure

A H3C S3100-52P Ethernet switch can authenticate supplicant systems in EAP terminating mode or EAP relay mode.

I. EAP relay mode

This mode is defined in 802.1x. In this mode, EAP-packets are encapsulated in higher level protocol (such as EAPoR) packets to enable them to successfully reach the authentication server. Normally, this mode requires that the RADIUS server support the two newly-added fields: the EAP-message field (with a value of 79) and the Message-authenticator field (with a value of 80).

Four authentication ways, namely EAP-MD5, EAP-TLS (transport layer security), EAP-TTLS, and PEAP (protected extensible authentication protocol), are available in the EAP relay mode.

l           EAP-MD5 authenticates the supplicant system. The RADIUS server sends MD5 keys (contained in EAP-request/MD5 challenge packets) to the supplicant system, which in turn encrypts the passwords using the MD5 keys.

l           EAP-TLS authenticates both the supplicant system and the RADIUS server by checking their security licenses to prevent data from being stolen.

l           EAP-TTLS is a kind of extended EAP-TLS. EAP-TLS implements bidirectional authentication between the client and authentication server. EAP-TTLS transmit message using a tunnel established using TLS.

l           PEAP creates and uses TLS security channels to ensure data integrity and then performs new EAP negotiations to verify supplicant systems.

Figure 1-8 describes the basic EAP-MD5 authentication procedure.

Figure 1-8 802.1x authentication procedure (in EAP relay mode)

The detailed procedure is as follows.

l           A supplicant system launches an 802.1x client to initiate an access request by sending an EAPoL-start packet to the switch, with its user name and password provided. The 802.1x client program then forwards the packet to the switch to start the authentication process.

l           Upon receiving the authentication request packet, the switch sends an EAP-request/identity packet to ask the 802.1x client for the user name.

l           The 802.1x client responds by sending an EAP-response/identity packet to the switch with the user name contained in it. The switch then encapsulates the packet in a RADIUS Access-Request packet and forwards it to the RADIUS server.

l           Upon receiving the packet from the switch, the RADIUS server retrieves the user name from the packet, finds the corresponding password by matching the user name in its database, encrypts the password using a randomly-generated key, and sends the key to the switch through an RADIUS access-challenge packet. The switch then sends the key to the 802.1x client.

l           Upon receiving the key (encapsulated in an EAP-request/MD5 challenge packet) from the switch, the client program encrypts the password of the supplicant system with the key and sends the encrypted password (contained in an EAP-response/MD5 challenge packet) to the RADIUS server through the switch. (Normally, the encryption is irreversible.)

l           The RADIUS server compares the received encrypted password (contained in a RADIUS access-request packet) with the locally-encrypted password. If the two match, it will then send feedbacks (through a RADIUS access-accept packet and an EAP-success packet) to the switch to indicate that the supplicant system is authenticated.

l           The switch changes the state of the corresponding port to accepted state to allow the supplicant system to access the network.

l           The supplicant system can also terminate the authenticated state by sending EAPoL-Logoff packets to the switch. The switch then changes the port state from accepted to rejected.

 

&  Note:

In EAP relay mode, packets are not modified during transmission. Therefore if one of the four ways are used (that is, PEAP, EAP-TLS, EAP-TTLS or EAP-MD5) to authenticate, ensure that the authenticating ways used on the supplicant system and the RADIUS server are the same. However for the switch, you can simply enable the EAP relay mode by using the dot1x authentication-method eap command.

 

II. EAP terminating mode

In this mode, EAP packet transmission is terminated at authenticator systems and the EAP packets are converted to RADIUS packets. Authentication and accounting are carried out through RADIUS protocol.

In this mode, PAP or CHAP is employed between the switch and the RADIUS server. Figure 1-9 illustrates the authentication procedure (assuming that CHAP is employed between the switch and the RADIUS server).

Figure 1-9 802.1x authentication procedure (in EAP terminating mode)

The authentication procedure in EAP terminating mode is the same as that in the EAP relay mode except that the randomly-generated key in the EAP terminating mode is generated by the switch, and that it is the switch that sends the user name, the randomly-generated key, and the supplicant system-encrypted password to the RADIUS server for further authentication.

1.1.5  Timers Used in 802.1x

In 802.1 x authentication, the following timers are used to ensure that the supplicant system, the switch, and the RADIUS server interact in an orderly way.

l           Transmission timer (tx-period). This timer sets the tx-period and is triggered by the switch in two cases. The first case is when the client requests for authentication. The switch sends a unicast request/identity packet to a supplicant system and then triggers the transmission timer. The switch sends another request/identity packet to the supplicant system if it does not receive the reply packet from the supplicant system when this timer times out. The second case is when the switch authenticates the 802.1x client who cannot request for authentication actively. The switch sends multicast request/identity packets periodically through the port enabled with 802.1x function. In this case, this timer sets the interval to send the multicast request/identity packets.

l           Supplicant system timer (supp-timeout). This timer sets the supp-timeout period and is triggered by the switch after the switch sends a request/challenge packet to a supplicant system. The switch sends another request/challenge packet to the supplicant system if the switch does not receive the response from the supplicant system when this timer times out.

l           RADIUS server timer (server-timeout). This timer sets the server-timeout period. After sending an authentication request packet to the RADIUS server, a switch sends another authentication request packet if it does not receive the response from the RADIUS server when this timer times out.

l           Handshake timer (handshake-period). This timer sets the handshake-period and is triggered after a supplicant system passes the authentication. It sets the interval for a switch to send handshake request packets to online users. If you set the number of retries to N by using the dot1x retry command, an online user is considered offline when the switch does not receive response packets from it in a period N times of the handshake-period.

l           Quiet-period timer (quiet-period). This timer sets the quiet-period. When a supplicant system fails to pass the authentication, the switch quiets for the set period (set by the quiet-period timer) before it processes another authentication request re-initiated by the supplicant system.

l           Client version request timer (ver-period). This timer sets the version period and is triggered after a switch sends a version request packet. The switch sends another version request packet if it does receive version response packets from the supplicant system when the timer expires.

1.1.6  802.1x Implementation on an S3100-52P Ethernet Switch

In addition to the earlier mentioned 802.1x features, an S3100-52P Ethernet Switch is also capable of the following:

l           Checking supplicant systems for proxies, multiple network adapters, and so on (This function needs the cooperation of a CAMS server.)

l           Checking client version

l           The Guest VLAN function

I. Checking the supplicant system

An S3100-52P Ethernet Switch checks:

l           Supplicant systems logging on through proxies

l           Supplicant systems logging on through IE proxies

l           Whether or not a supplicant system logs in through more than one network adapters (that is, whether or not more than one network adapters are active in a supplicant system when the supplicant system logs in).

In response to any of the three cases, a switch can optionally take the following measures:

l           Disconnecting the supplicant system and sending Trap packets, which can be achieved by using the dot1x supp-proxy-check logoff command.

l           Sending Trap packets without disconnecting the supplicant system, which can be achieved by using the dot1x supp-proxy-check trap command.

This function needs the cooperation of 802.1x client and a CAMS server.

l           The 802.1x client needs to capable of detecting multiple network adapters, proxies, and IE proxies.

l           The CAMS server is configured to disable the use of multiple network adapters, proxies, or IE proxies.

By default, an 802.1x client program allows use of multiple network adapters, proxies, and IE proxies. In this case, if the CAMS server is configured to disable use of multiple network adapters, proxies, or IE proxies, it prompts the 802.1x client to disable use of multiple network adapters, proxies, or IE proxies through messages after the supplicant system passes the authentication.

 

&  Note:

l      The client-checking function needs the support of H3C’s 802.1x client program.

l      To implement the proxy detecting function, you need to enable the function on both the 802.1x client program and the CAMS server in addition to enabling the client version detecting function on the switch by using the dot1x version-check command.

 

II. Checking the client version

With the 802.1x client version-checking function enabled, a switch checks the version and validity of an 802.1x client to prevent unauthorized users or users with earlier versions of 802.1x client from logging in.

This function makes the switch to send version-requesting packets again if the 802.1x client fails to send version-reply packet to the switch when the version-checking timer times out.

 

&  Note:

l      The 802.1x client version-checking function needs the support of H3C’s 802.1x client program.

 

III. The Guest VLAN function

The Guest VLAN function enables supplicant systems that that are not authenticated to access network resources in a restrained way.

The Guest VLAN function enables supplicant systems that do not have 802.1x client installed to access specific network resources. It also enables supplicant systems that are not authenticated to upgrade their 802.1x client programs.

With this function enabled:

l           The switch multicasts trigger packets through all the 802.1x-enabled ports.

l           After the maximum number retries have been made and there are still ports that have not sent any response back, the switch will then add these ports to the Guest VLAN.

l           Users belonging to the Guest VLAN can access the resources of the Guest VLAN without being authenticated. But they need to be authenticated when accessing external resources.

Normally, the Guest VLAN function is coupled with the dynamic VLAN delivery function.

Refer to AAA&RADIUS&RADIUS&HWTACACS&EAD Operation Manual for detailed information about the dynamic VLAN delivery function.

1.2  802.1x Configuration

802.1x provides a solution for authenticating users. To implement this solution, you need to execute 802.1x-related commands. You also need to configure AAA schemes on switches and specify the authentication scheme (RADIUS authentication scheme or local authentication scheme).

Figure 1-10 802.1x configuration

l           802.1x users use domain names to associate with the ISP domains configured on switches

l           Configure the AAA scheme (a local authentication scheme or the RADIUS scheme) to be adopted in the ISP domain.

l           If you specify to adopt the RADIUS scheme, the supplicant systems are authenticated by a remote RADIUS server. In this case, you need to configure user names and passwords on the RADIUS server and perform RADIUS client-related configuration on the switches.

l           If you specify to adopt a local authentication scheme, you need to configure user names and passwords manually on the switches. Users can pass the authentication through 802.1x client if they provide the user names and passwords that match those configured on the switches.

l           You can also specify to adopt RADIUS authentication scheme, with a local authentication scheme as a backup. In this case, the local authentication scheme is adopted when the RADIUS server fails.

Refer to the AAA&RADIUS&RADIUS&HWTACACS&EAD Operation Manual for detailed information about AAA scheme configuration.

1.3  Basic 802.1x Configuration

To utilize 802.1x features, you need to perform basic 802.1x configuration.

1.3.1  Prerequisites

l           Configure ISP domain and the AAA scheme to be adopted. You can specify a RADIUS scheme or a local scheme.

l           Ensure that the service type is configured as lan-access (by using the service-type command) if local authentication scheme is adopted.

1.3.2  Configuring Basic 802.1x Functions

Table 1-1 Configure basic 802.1x functions

Operation

Command

Description

Enter system view

system-view

Enable 802.1x globally

dot1x

Required

By default, 802.1x is disabled globally.

Enable 802.1x for specified ports

Use the following command in system view:

dot1x [ interface interface-list ]

Required

By default, 802.1x is disabled on all ports.

Use the following command in port view:

dot1x

Set port access control mode for specified ports

dot1x port-control { authorized-force | unauthorized-force | auto } [ interface interface-list ]

Optional

By default, an 802.1x-enabled port operates in the auto mode.

Set port access method for specified ports

dot1x port-method { macbased | portbased } [ interface interface-list ]

Optional

The default port access method is MAC-address-based (that is, the macbased keyword is used by default).

Set authentication method for 802.1x users

dot1x authentication-method { chap | pap | eap }

Optional

By default, a switch performs CHAP authentication in EAP terminating mode.

 

  Caution:

l      802.1x-related configurations can all be performed in system view. Port access control mode and port access method can also be configured in port view.

l      If you perform a configuration in system view and do not specify the interface-list argument, the configuration applies to all ports. Configurations performed in Ethernet port view apply to the current Ethernet port only. In this case, the interface-list argument is not needed.

l      802.1x configurations take effect only after you enable 802.1x both globally and for specified ports.

l      When a device operates as an authentication server, its authentication method for 802.1x users cannot be configured as EAP.

 

1.4  Timer and Maximum User Number Configuration

Table 1-2 Configure 802.1x timers and the maximum number of users

Operation

Command

Description

Enter system view

system-view

Set the maximum number of concurrent on-line users for specified ports

In system view:

dot1x max-user user-number [ interface interface-list ]

Optional

By default, a port can accommodate up to 256 users at a time.

In port view:

dot1x max-user user-number

Set the maximum retry times to send request packets

dot1x retry max-retry-value

Optional

By default, the maximum retry times to send a request packet is 2. That is, the authenticator system sends a request packet to a supplicant system for up to two times by default.

Set 802.1x timers

dot1x timer { handshake-period handshake-period-value | quiet-period quiet-period-value | tx-period tx-period-value | supp-timeout supp-timeout-value | server-timeout server-timeout-value | ver-period ver-period-value }

Optional

The settings of 802.1x timers are as follows.

l      handshake-period-value: 15 seconds

l      quiet-period-value: 60 seconds

l      tx-period-value: 30 seconds

l      supp-timeout-value: 30 seconds

l      server-timeout-value: 100 seconds

l      ver-period-value: 30 seconds

Trigger the quiet-period timer

dot1x quiet-period

Optional

By default, the quiet-period timer is disabled.

 

&  Note:

l      As for the dot1x max-user command, if you execute it in system view without specifying the interface-list argument, the command applies to all ports. You can also use this command in port view. In this case, this command applies to the current port only and the interface-list argument is not needed.

l      As for the configuration of 802.1x timers, the default values are recommended.

 

1.5  Advanced 802.1x Configuration

Advanced 802.1x configurations, as listed below, are all optional.

l           Configuration concerning CAMS, including multiple network adapters detecting, proxy detecting, and so on.

l           Client version checking configuration

l           DHCP –triggered authentication

l           Guest VLAN configuration

1.5.1  Prerequisites

Basic 802.1x configuration is performed.

1.5.2  Configuring Proxy Checking

This function needs the cooperation of 802.1x client program and CAMS server, as listed below.

l           The 802.1x client needs to capable of detecting multiple network adapters, proxies, and IE proxies.

l           The CAMS server is configured to disable the use of multiple network adapters, proxies, or IE proxies.

By default, an 802.1x client program allows use of multiple network adapters, proxies, and IE proxies. In this case, if the CAMS server is configured to disable use of multiple network adapters, proxies, or IE proxies, it prompts the 802.1x client to disable use of multiple network adapters, proxies, or IE proxies through messages after the supplicant system passes the authentication.

Table 1-3 Configure proxy checking

Operation

Command

Description

Enter system view

system-view

Enable proxy checking function globally

dot1x supp-proxy-check { logoff | trap }

Required

By default, the 802.1x proxy checking function is globally disabled.

Enable proxy checking for a port/specified ports

In system view:

dot1x supp-proxy-check { logoff | trap } [ interface interface-list ]

Required

By default, the 802.1x proxy checking is disabled on a port.

In port view:

dot1x supp-proxy-check { logoff | trap }

 

&  Note:

l      The proxy checking function needs the cooperation of H3C's 802.1x client program.

l      The configuration listed in Table 1-3 takes effect only when it is performed on CAMS as well as on the switch. In addition, the client version checking function needs to be enabled on the switch too (by using the dot1x version-check command).

 

1.5.3  Configuring Client Version Checking

Table 1-4 Configure client version checking

Operation

Command

Description

Enter system view

system-view

Enable 802.1x client version checking

dot1x version-check [ interface interface-list ]

Required

By default, 802.1x client version checking is disabled on a port.

Set the maximum number of retires to send version checking request packets

dot1x retry-version-max max-retry-version-value

Optional

By default, the maximum number of retires to send version checking request packets is 3.

Set the client version checking period timer

dot1x timer ver-period ver-period-value

Optional

By default, the timer is set to 30 seconds.

 

&  Note:

As for the dot1x version-user command, if you execute it in system view without specifying the interface-list argument, the command applies to all ports. You can also execute this command in port view. In this case, this command applies to the current port only and the interface-list argument is not needed.

 

1.5.4  Enabling DHCP-triggered Authentication

After performing the following configuration, 802.1X allows running DHCP on access users, and users are authenticated when they apply for dynamic IP addresses through DHCP.

Table 1-5 Enable DHCP-triggered authentication

Operation

Command

Description

Enter system view

system-view

Enable DHCP-triggered authentication

dot1x dhcp-launch

Optional

By default, DHCP-triggered authentication is disabled.

 

1.5.5  Configuring Guest VLAN

Table 1-6 Configure Guest VLAN

Operation

Command

Description

Enter system view

system-view

Configure port access method

dot1x port-method portbased

Required

The default port access method is MAC-address-based. That is, the macbased keyword is used by default.

Enable the Guest VLAN function

dot1x guest-vlan vlan-id [ interface interface-list ]

Required

By default, the Guest VLAN function is disabled.

 

  Caution:

l      The Guest VLAN function is available only when the switch operates in the port-based authentication mode.

l      Only one Guest VLAN can be configured for each switch.

 

1.6  Displaying and Debugging 802.1x

After performing the above configurations, you can display and verify the 802.1x-related configuration by executing the display command in any view.

You can clear 802.1x-related statistics information by executing the reset command in user view.

Table 1-7 Display and debug 802.1x

Operation

Command

Description

Display the configuration, session, and statistics information about 802.1x

display dot1x [ sessions | statistics ] [ interface interface-list ]

This command can be executed in any view.

Clear 802.1x-related statistics information

reset dot1x statistics [ interface interface-list ]

Execute this command in user view.

 

1.7  Configuration Example

1.7.1  802.1x Configuration Example

I. Network requirements

l           Authenticate users on all ports to control their accesses to the Internet. The switch operates in MAC address-based access control mode.

l           All supplicant systems that pass the authentication belong to the default domain named “aabbcc.net”. The domain can accommodate up to 30 users. As for authentication, a supplicant system is authenticated locally if the RADIUS server fails. And as for accounting, a supplicant system is disconnected by force if the RADIUS server fails. The name of an authenticated supplicant system is not suffixed with the domain name. A connection is terminated if the total size of the data passes through it during a period of 20 minutes is less than 2,000 bytes.

l           The switch is connected to a server comprising of two RADIUS servers whose IP addresses are 10.11.1.1 and 10.11.1.2. The RADIUS server with an IP address of 10.11.1.1 operates as the primary authentication server and the secondary accounting server. The other operates as the secondary authentication server and primary accounting server. The password for the switch and the authentication RADIUS servers to exchange message is “name”. And the password for the switch and the accounting RADIUS servers to exchange message is “money”. The switch sends another packet to the RADIUS servers again if it sends a packet to the RADIUS server and does not receive response for 5 seconds, with the maximum number of retries of 5. And the switch sends a real-time accounting packet to the RADIUS servers once in every 15 minutes. A user name is sent to the RADIUS servers with the domain name truncated.

l           The user name and password for local 802.1x authentication are “localuser” and “localpass” (in plain text) respectively. The idle disconnecting function is enabled.

II. Network diagram

Figure 1-11 Network diagram for AAA configuration with 802.1x and RADIUS enabled

III. Configuration procedure

 

&  Note:

Following configuration covers the major AAA/RADIUS configuration commands. Refer to AAA,RADIUS,HWTACACS and EAD Operation Manual for the information about these commands. Configuration on the client and the RADIUS servers is omitted.

 

# Enable 802.1x globally.

<H3C> system-view

System View: return to User View with Ctrl+Z.

[H3C] dot1x

# Enable 802.1x for Ethernet1/0/1 port.

[H3C] dot1x interface Ethernet 1/0/1

# Set the access control method to be MAC-address-based (This operation can be omitted, as MAC-address-based is the default).

[H3C] dot1x port-method macbased interface Ethernet 1/0/1

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

[H3C] radius scheme radius1

# Assign IP addresses to the primary authentication and accounting RADIUS servers.

[H3C-radius-radius1] primary authentication 10.11.1.1

[H3C-radius-radius1] primary accounting 10.11.1.2

# Assign IP addresses to the secondary authentication and accounting RADIUS server.

[H3C-radius-radius1] secondary authentication 10.11.1.2

[H3C-radius-radius1] secondary accounting 10.11.1.1

# Set the password for the switch and the authentication RADIUS servers to exchange messages.

[H3C-radius-radius1] key authentication name

# Set the password for the switch and the accounting RADIUS servers to exchange messages.

[H3C-radius-radius1] key accounting money

# Set the interval and the number of the retries for the switch to send packets to the RADIUS servers.

[H3C-radius-radius1] timer 5

[H3C-radius-radius1] retry 5

# Set the timer for the switch to send real-time accounting packets to the RADIUS servers.

[H3C-radius-radius1] timer realtime-accounting 15

# Configure to send the user name to the RADIUS server with the domain name truncated.

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

[H3C-radius-radius1] quit

# Create the domain named “aabbcc.net” and enter its view.

[H3C] domain enable aabbcc.net

# Specify to adopt radius1 as the RADIUS scheme of the user domain. If RADIUS server is invalid, specify to adopt the local authentication scheme.

[H3C-isp-aabbcc.net] scheme radius-scheme radius1 local

# Specify the maximum number of users the user domain can accommodate to 30.

[H3C-isp-aabbcc.net] access-limit enable 30

# Enable the idle disconnecting function and set the related parameters.

[H3C-isp-aabbcc.net] idle-cut enable 20 2000

[H3C-isp-aabbcc.net] quit

# Set the default user domain to be “aabbcc.net”.

[H3C] domain default enable aabbcc.net

# Create a local access user account.

[H3C] local-user localuser

[H3C-luser-localuser] service-type lan-access

[H3C-luser-localuser] password simple localpass

 


Chapter 2  HABP Configuration

2.1  Introduction to HABP

With 802.1x enabled, a switch authenticates and then authorizes 802.1x-enabled ports. Packets can be forwarded only by authorized ports. For ports connected to the switch and are not authenticated and authorized by 802.1x, their received packets will be filtered. This means that users cannot manage the attached switches. Huawei authentication bypass protocol (HABP) is designed to address this problem.

An HABP packet carries the MAC addresses of the attached switches with it. It can bypass the 802.1x authentications when traveling between HABP-enabled switches, through which management devices can obtain the MAC addresses of the attached switches and thus the management of the attached switches is feasible.

HABP is implemented by HABP server and HABP client. Normally, an HABP server sends HABP request packets regularly to HABP clients to collect the MAC addresses of the attached switches. HABP clients respond to the HABP request packets and forward the HABP request packets to lower-level switches. HABP servers usually reside on management devices and HABP clients usually on attached switches.

For ease of switch management, it is recommended that you enable HABP for 802.1x-enabled switches.

2.2  HABP Server Configuration

With the HABP server launched, a management device sends HABP request packets regularly to the attached switches to collect their MAC addresses. You need also to configure the interval on the management device for an HABP server to send HABP request packets.

Table 2-1 Configure an HABP server

Operation

Command

Description

Enter system view

system-view

Enable HABP

habp enable

Required

HABP is enabled by default.

Configure the current switch to be an HABP server

habp server vlan vlan-id

Required

By default, a switch operates as an HABP client after you enable HABP on the switch. If you want to use the switch as a management switch, you need to configure the switch to be an HABP server.

Configure the interval to send HABP request packets.

habp timer interval

Optional

The default interval for an HABP server to send HABP request packets is 20 seconds.

 

2.3  HABP Client Configuration

HABP clients reside on switches attached to HABP servers. After you enable HABP for a switch, the switch operates as an HABP client by default. So you only need to enable HABP on a switch to make it an HABP client.

Table 2-2 Configure an HABP client

Operation

Command

Description

Enter system view

system-view

Enable HABP

habp enable

Optional

HABP is enabled by default. And a switch operates as an HABP client after you enable HABP for it.

 

2.4  Displaying HABP

After performing the above configuration, you can display and verify your HABP-related configuration by execute the display command in any view.

Table 2-3 Display HABP

Operation

Command

Description

Display HABP configuration and status

display habp

These commands can be executed in any view.

Display the MAC address table maintained by HABP

display habp table

Display statistics on HABP packets

display habp traffic