Table of Contents Table of Contents... 1-1 1.1 802.1x Overview... 1-1 1.1.1 Architecture of 802.1x... 1-1 1.1.2 Operation of 802.1x... 1-3 1.1.3 EAP Encapsulation over LANs... 1-4 1.1.4 EAP Encapsulation over RADIUS... 1-6 1.1.5 Authentication Process of 802.1x... 1-6 1.1.6 802.1x Timers... 1-10 1.1.7 Implementation of 802.1x in the Devices... 1-10 1.1.8 Features Working Together with 802.1x... 1-10 1.2 Configuring 802.1x... 1-12 1.2.1 Configuration Prerequisites... 1-12 1.2.2 Configuration Procedure... 1-12 1.3 Configuring a Guest VLAN... 1-14 1.3.1 Configuration Prerequisites... 1-14 1.3.2 Configuration Procedure... 1-15 1.4 Displaying and Maintaining 802.1x... 1-15 1.5 802.1x Configuration Example... 1-15 1.6 Guest VLAN Configuration Example... 1-18 i
When configuring 802.1x, go to these sections for information you are interested in: 802.1x Overview Configuring 802.1x Configuring a Guest VLAN Displaying and Maintaining 802.1x 802.1x Configuration Example Guest VLAN Configuration Example 1.1 802.1x Overview The 802.1x protocol was proposed by IEEE802 LAN/WAN committee for security problems on wireless LANs (WLAN). Currently, it is widely used on Ethernet as a common port access control mechanism. As a port-based network access control protocol, 802.1x authenticates and controls accessing devices at the level of port. A device connected to an 802.1x-enabled port of an access control device can access the resources on the LAN only after passing authentication. To get more information about 802.1x, go to these topics: Architecture of 802.1x Operation of 802.1x EAP Encapsulation over LANs EAP Encapsulation over RADIUS Authentication Process of 802.1x 802.1x Timers Implementation of 802.1x in the Devices Features Working Together with 802.1x 1.1.1 Architecture of 802.1x 802.1x operates in the typical client/server model and defines three entities: supplicant system, authenticator system, and authentication server system, as shown in Figure 1-1. 1-1
Figure 1-1 Architecture of 802.1x Supplicant system: A system at one end of the LAN segment, which is authenticated by the system at the other end. A supplicant system is usually a user-end device and initiates 802.1x authentication through 802.1x client software supporting the EAP over LANs (EAPOL) protocol. Authenticator system: A system at one end of the LAN segment, which authenticates the system at the other end. An authenticator system is usually an 802.1x-enabled network device and provides ports (physical or logical) for supplicants to access the LAN. Authentication server system: The system providing authentication, authorization, and accounting services for the authenticator system. Generally, a Remote Authentication Dial-In User Service (RADIUS) server acts as the authentication server system. It stores such user information as username, password and other parameters like user VLAN, committed access rate (CAR), priority, and access control lists (ACLs). The above systems involve three basic concepts: PAE, Controlled port, Control direction. I. PAE Port access entity (PAE) refers to the entity on a given port of a device that performs the 802.1x algorithm and protocol operations. A PAE may be one of the following two types: Authenticator PAE: It uses the authentication server to authenticate a supplicant trying to access the LAN and puts the controlled port in the state of authorized or unauthorized according to the authentication result. In authorized state, the controlled port allows all packets to pass through it and the supplicant connected to this port can access network resources. In unauthorized state, the controlled port allows only EAPOL packets to pass through it and the supplicant connected to this port cannot access network resources. 1-2
Supplicant PAE: It responds to the authentication request of the authenticator PAE and provides authentication information. The supplicant PAE can also send authentication requests and logoff requests to the authenticator. II. Controlled port An authenticator provides ports for supplicants to access the LAN. Each of the ports can be regarded as two logical ports: a controlled port and an uncontrolled port. The uncontrolled port is always open in both the inbound and outbound directions to allow EAPOL protocol frames to pass, guaranteeing that the supplicant can always send and receive authentication frames. The controlled port is open to allow normal traffic to pass only when it is in the authorized state. The controlled port and uncontrolled port are two logical ports of the same port. Any frames arriving at the port are visible to both of them. III. Control direction In the unauthorized state, the controlled port can be set to deny traffic to and from the supplicant or just the traffic from the supplicant. Note: Currently, the S9500 series supports only denying the traffic from the supplicant. 1.1.2 Operation of 802.1x The 802.1x authentication system employs the extensible authentication protocol (EAP) to support authentication information exchange between the supplicant PAE, authenticator PAE, and authentication server. Figure 1-2 Operation of 802.1x Between the supplicant PAE and authenticator PAE, EAP protocol packets are encapsulated using EAPOL and transferred over the LAN. Between the authenticator PAE and authentication server, EAP protocol packets can be handled in two modes: EAP relay and EAP termination. In EAP relay mode, EAP protocol packets are encapsulated using the EAP attributes of RADIUS and then relayed to the RADIUS server. In EAP termination mode, EAP protocol packets are terminated at the authenticator PAE, repackaged in the password 1-3
authentication protocol (PAP) or challenge handshake authentication protocol (CHAP) attributes of RADIUS packets, and then transferred to the RADIUS server. After a user passes the authentication, the authentication server passes information about the user to the authenticator, which controls the status of the controlled port according to the instruction of the authentication server. 1.1.3 EAP Encapsulation over LANs I. EAPOL frame format EAPOL, defined by 802.1x, is intended to carry EAP protocol packets between supplicants and authenticators over LANs. Figure 1-3 shows the EAPOL frame format. Figure 1-3 EAPOL frame format PAE Ethernet type: Protocol type. It takes the value 0x888E. Protocol version: Version of the EAPOL protocol supported by the EAPOL frame sender. Type: Type of the packet. The following types are defined: Type EAP-Packet (a value of 0x00), frame for carrying authentication information. EAPOL-Start (a value of 0x01), frame for initiating authentication. EAPOL-Logoff (a value of 0x02), frame for logoff request. EAPOL-Key (a value of 0x03), frame for carrying key information. Description A frame of the type of EAP-Packet is repackaged and transferred over RADIUS to get through complex networks to reach the authentication server. A frame of the type of EAPOL-Start, EAPOL-Logoff, or EAPOL-Key exists between a supplicant and an authenticator. 1-4
Type EAPOL-Encapsulated-ASF-Alert (a value of 0x04), frame for carrying alerting information compliant to Alert Standard Forum (ASF). Description A frame of the type of EAPOL-Encapsulated-ASF-Alert carries network management-related information (for example, various warning messages) and is terminated at the authenticator. Length: Length of the data, that is, length of the Packet body field, in bytes. If the value of this field is 0, no subsequent data field is present. Packet body: The format of this field varies with the value of the Type field. II. EAP Packet Format An EAPOL frame of the type of EAP-Packet carries an EAP packet in its Packet body field. The format of the EAP packet is shown in Figure 1-4. Figure 1-4 EAP packet format Code: Type of the EAP packet, which can be Request, Response, Success, or Failure. Identifier: Allows matching of responses with requests. Length: Length of the EAP packet, including the Code, Identifier, Length, and Data fields, in bytes. Data: This field is zero or more bytes and its format is determined by the Code field. An EAP packet of the type of Success or Failure has no Data field, and has a length of 4. The Data field in an EAP packet of the type of Request or Response is in the format shown in Figure 1-5. Figure 1-5 Format of the Data field in an EAP request/response packet Type: EAP authentication type. A value of 1 represents Identity, indicating that the packet is for querying the identity of the supplicant. A value of 4 represents MD5 Challenge, which corresponds closely to the PPP CHAP protocol. 1-5
1.1.4 EAP Encapsulation over RADIUS Two attributes of RADIUS are intended for supporting EAP authentication: EAP-Message and Message-Authenticator. For information about RADIUS packet format, refer to AAA RADIUS HWTACACS Configuration in the Security Volume. I. EAP-Message The EAP-Message attribute is used to encapsulate EAP packets. Figure 1-6 shows its encapsulation format. The value of the Type field is 79. The String field can be up to 253 bytes. If the EAP packet is longer than 253 bytes, it can be fragmented and encapsulated into multiple EAP-Message attributes. Figure 1-6 Encapsulation format of the EAP-Message attribute II. Message-Authenticator Figure 1-7 shows the encapsulation format of the Message-Authenticator attribute. This attribute is used to prevent access requests from being snooped during EAP or CHAP authentication. It must be included in any packet with the EAP-Message attribute; otherwise, the packet will be considered invalid and get discarded. Figure 1-7 Encapsulation format of the Message-Authenticator attribute 1.1.5 Authentication Process of 802.1x 802.1x authentication can be initiated by either a supplicant or the authenticator system. A user initiates authentication by launching the 802.1x client software to send an EAPOL-Start frame to the authenticator system, while the authenticator system sends an EAP-Request/Identity packet to an unauthenticated user when detecting that the user is trying to login. An 802.1x authenticator system communicates with a remotely located RADIUS server in two modes: EAP relay and EAP termination. The following description takes the first case as an example to show the 802.1x authentication process. 1-6
I. EAP relay EAP relay is an IEEE 802.1x standard mode. In this mode, EAP packets are carried in an upper layer protocol, such as RADIUS, so that they can go through complex networks and reach the authentication server. Generally, EAP relay requires that the RADIUS server support the EAP attributes of EAP-Message and Message-Authenticator, which are used to encapsulate EAP packets and protect RADIUS packets carrying the EAP-Message attribute respectively. See Figure 1-8 for the message exchange procedure. Client Device Server EAPOL EAPOR EAPOL-Start EAP-Request / Identity EAP-Response / Identity EAP-Request / MD5 challenge EAP-Response / MD5 challenge EAP-Success RADIUS Access-Request (EAP-Response / Identity) RADIUS Access-Challenge (EAP-Request / MD5 challenge) RADIUS Access-Request (EAP-Response / MD5 challenge) RADIUS Access-Accept (EAP-Success) Port authorized Handshake request [ EAP-Request / Identity ] Handshake response [ EAP-Response / Identity ] Handshake timer... EAPOL-Logoff Port unauthorized Figure 1-8 Message exchange in EAP relay mode 1) When a user launches the 802.1x client software and enters the registered username and password, the 802.1x client software generates an EAPOL-Start frame and sends it to the device to initiate an authentication process. 2) Upon receiving the EAPOL-Start frame, the device responds with an EAP-Request/Identity packet for the username of the client. 1-7
3) When the client receives the EAP-Request/Identity packet, it encapsulates the username in an EAP-Response/Identity packet and sends the packet to the device. 4) Upon receiving the EAP-Response/Identity packet, the device relays the packet in a RADIUS Access-Request packet to the authentication server. 5) When receiving the RADIUS Access-Request packet, the authentication server compares the identify information against its user information table to obtain the corresponding password information. Then, it encrypts the password information using a randomly generated challenge, and sends the challenge information through a RADIUS Access-Challenge packet to the device. 6) After receiving the RADIUS Access-Challenge packet, the device relays the contained EAP-Request/MD5 Challenge packet to the client. 7) When receiving the EAP-Request/MD5 Challenge packet, the client uses the offered challenge to encrypt the password part (this process is not reversible), creates an EAP-Response/MD5 Challenge packet, and then sends the packet to the device. 8) After receiving the EAP-Response/MD5 Challenge packet, the device relays the packet in a RADIUS Access-Request packet to the authentication server. 9) When receiving the RADIUS Access-Request packet, the authentication server compares the password information encapsulated in the packet with that generated by itself. If the two are identical, the authentication server considers the user valid and sends to the device a RADIUS Access-Accept packet. 10) Upon receiving the RADIUS Access-Accept packet, the device opens the port to grant the access request of the client. After the client gets online, the device periodically sends handshake requests to the client to check whether the client is still online. By default, if two consecutive handshake attempts end up with failure, the device concludes that the client has gone offline and performs the necessary operations, guaranteeing that the device always knows when a client goes offline. 11) The client can also sends an EAPOL-Logoff frame to the device to log off unsolicitedly. In this case, the device changes the status of the port from authorized to unauthorized and sends an EAP-Failure frame to the client. Note: In EAP relay mode, a client must use the same authentication method as that of the RADIUS server. On the device, however, you only need to execute the dot1x authentication-method eap command to enable EAP relay. 1-8
II. EAP termination In EAP termination mode, EAP packets are terminated at the device and then repackaged into the PAP or CHAP attributes of RADIUS and transferred to the RADIUS server for authentication, authorization, and accounting. See Figure 1-9 for the message exchange procedure. Client Device Server EAPOL EAPOR EAPOL-Start EAP-Request / Identity EAP-Response / Identity EAP-Request / MD5 challenge EAP-Response / MD5 challenge RADIUS Access-Request (CHAP-Response / MD5 challenge) RADIUS Access-Accept (CHAP-Success) EAP-Success Port authorized Handshake request [ EAP-Request / Identity ] Handshake response [ EAP-Response / Identity ] Handshake timer... EAPOL-Logoff Port unauthorized Figure 1-9 Message exchange in EAP termination mode Different from the authentication process in EAP relay mode, it is the device that generates the random challenge for encrypting the user password information in EAP termination authentication process. Consequently, the device sends the challenge together with the username and encrypted password information from the client to the authentication server for authentication. 1-9
1.1.6 802.1x Timers Several timers are used in the 802.1x authentication process to guarantee that the supplicants, the authenticators, and the RADIUS server interact with each other in a reasonable manner. The following are the major 802.1x timers: Username request timeout timer (tx-period): Once an authenticator sends an EAP-Request/Identity frame to a supplicant, it starts this timer. If this timer expires but it receives no response from the supplicant, it retransmits the request. In addition, to be compatible with supplicants that do not send EAPOL-Start requests unsolicitedly, the S9500 series multicasts EAP-Request/Identity frame periodically to detect the supplicants, with the multicast interval defined by tx-period. Supplicant timeout timer (supp-timeout): Once an authenticator sends an EAP-Request/MD5 Challenge frame to a supplicant, it starts this timer. If this timer expires but it receives no response from the supplicant, it retransmits the request. Server timeout timer (server-timeout): Once an authenticator sends a RADIUS Access-Request packet to the authentication server, it starts this timer. If this timer expires but it receives no response from the server, it retransmits the request. Handshake timer (handshake-period): After a supplicant passes authentication, the authenticator sends to the supplicant handshake requests at this interval to check whether the supplicant is online. If the authenticator receives no response after sending the allowed maximum number of handshake requests, it considers that the supplicant is offline. Quiet timer (quiet-period): When a supplicant fails the authentication, the authenticator refuses further authentication requests from the supplicant in this period of time. 1.1.7 Implementation of 802.1x in the Devices The devices extend and optimize the mechanism that the 802.1x protocol specifies by: Allowing multiple users to access network services through the same physical port. Supporting two authentication methods: portbased and macbased. With the portbased method, after the first user of a port passes authentication, all other users of the port can access the network without authentication, and when the first user goes offline, all other users get offline at the same time. With the macbased method, each user of a port must be authenticated separately, and when an authenticated user goes offline, no other users are affected. 1.1.8 Features Working Together with 802.1x I. VLAN Assigning After an 802.1x user passes the authentication, the server will send an authorization message to the switch. If the authorization message includes the assigned VLAN 1-10
information, the switch adds the port that the user uses for 802.1x authentication to the assigned VLAN. The assigned VLAN neither changes nor affects the configuration of a port. However, since the assigned VLAN has higher priority than the VLAN configured for the port, it is the assigned VLAN that takes effect after a user passes authentication. After the user goes offline, the port returns to the VLAN configured for it. For details about VLAN configuration, refer to VLAN Configuration in the Access Volume. Note: If the port link type is Access, the authentication server will assign a VLAN successfully. If the port link type is Hybrid or Trunk, the authentication server will fail to assign a VLAN. II. Guest VLAN The guest VLAN feature allows unauthenticated users to access some special resources. A guest VLAN is the default VLAN that a supplicant can access without authentication. After passing 802.1x authentication, the supplicant can access other network resources. A user of the guest VLAN can perform operations such as downloading and upgrading the authentication client software. If a supplicant does not have the required authentication client software or the version of the client software is lower, the supplicant will fail the authentication and the port that the supplicant uses to access the authenticator will be added into the guest VLAN. If a device with 802.1x enabled and the guest VLAN correctly configured sends an EAP-Request/Identity packet for the allowed maximum number of times but gets no response, it adds the port into the guest VLAN. When a supplicant added into the guest VLAN initiates another authentication process, if the authentication is not successful, the supplicant stays in the guest VLAN; otherwise, two cases may occur: The authentication server assigns a VLAN: The port leaves the guest VLAN and joins the assigned VLAN. If the supplicant goes offline, the port returns to its original VLAN, that is, the VLAN to which it is configured to belong and it belongs before joining the guest VLAN. The authentication server does not assign any VLAN: The port leaves the guest VLAN and returns to its original VLAN. If the supplicant goes offline, the port just stays in its original VLAN. 1-11
1.2 Configuring 802.1x 1.2.1 Configuration Prerequisites 802.1x provides a user identity authentication scheme. However, 802.1x cannot implement the authentication scheme solely by itself and RADIUS or local authentication must be configured to work with 802.1x. Before configuring 802.1x, do the following: Configure the ISP domain that the 802.1x users belong to and the AAA scheme (local authentication scheme or RADIUS scheme) to be used. For remote RADIUS authentication, configure the username and password information on the RADIUS server and perform the RADIUS client-related configurations on the authenticator. For local authentication, configure the username and password information on the authenticator and set the service type to lan-access. For details about these configuration tasks, refer to AAA RADIUS HWTACACS Configuration in the Security Volume. 1.2.2 Configuration Procedure Follow these steps to configure 802.1x: To do Use the command Remarks Enter system view system-view Enable 802.1x globally Enable 802.1x for one or more ports Set the port access control mode for specified or all ports Set the port access control method for specified or all ports Enable detection and control of users logging in through proxies globally dot1x dot1x interface interface-list interface interface-type interface-number dot1x dot1x port-control { authorized-force auto unauthorized-force } [ interface interface-list ] dot1x port-method { macbased portbased } [ interface interface-list ] dot1x supp-proxy-check { logoff trap } Required Disabled by default Required Disabled for any port by default Optional auto by default Optional macbased by default Optional Disabled by default 1-12
To do Use the command Remarks Set the maximum number of users to be supported simultaneously for specified or all ports Set the 802.1x authentication method Set the maximum number of attempts to send an authentication request to a supplicant Set timers Enable the quiet-period timer Enter Ethernet interface view Enable detection and control of users logging in through proxies for the port Enable online user handshake dot1x max-user user-number [ interface interface-list ] dot1x authentication-method { chap eap pap } dot1x retry max-retry-value dot1x timer { handshake-period handshake-period-value quiet-period quiet-period-value server-timeout server-timeout-value supp-timeout supp-timeout-value tx-period tx-period-value } dot1x quiet-period interface interface-type interface-number dot1x supp-proxy-check { logoff trap } dot1x handshake Optional 1024 by default Optional CHAP by default Optional 2 by default Optional The defaults are as follows: 15 seconds for the handshake timer, 60 seconds for the quiet timer, 30 seconds for the username request timeout timer, 30 seconds for the supplicant timeout timer, and 100 seconds for the server timeout timer. Optional Disabled by default Optional Disabled by default Optional Enabled by default Note that: 802.1x must be enabled both globally in system view and for the intended ports in system view or Ethernet interface view. Otherwise, it does not function. Generally, it is unnecessary to change 802.1x timers unless in some special or extreme network environments. For example, if you have a poor network status, you can change the supplicant timeout timer to a bigger value; if your network is 1-13
facing a high risk of attacks, you can change the quiet timer to a bigger value, and, if network status permitting, you can change this timer to a smaller value to improve the response speed to user authentication requests. Besides, you can adjust the server timeout timer to adapt to the server s performance. The 802.1x proxy detection function must be enabled both globally in system view and for intended ports in system view or Ethernet interface view. Otherwise, it does not function. The 802.1x proxy detection function depends on the online user handshake function. Be sure to enable handshake before enabling proxy detection and to disable proxy detection before disabling handshake. You can neither add an 802.1x-enabled port into an aggregation group nor enable 802.1x on a port being a member of an aggregation group. In EAP relay authentication mode, the authenticator encapsulates the 802.1x user information in the EAP attributes of RADIUS packets and sends the packets to the RADIUS server for authentication. In this case, you can configure the user-name-format command but it does not take effect. For information about the user-name-format command, refer to AAA RADIUS HWTACACS Commands in the Security Volume. The 802.1x user authentication method configured on the switch must be consistent with that configured on the authentication server. Currently, the S9500 series routing switches do not support 802.1x re-authentication, that is, online users authentication requests will not be processed. If the username of a supplicant contains the version number or one or more blank spaces, you can neither retrieve information nor disconnect the supplicant by using the username. However, you can use items such as IP address and connection index number to do so. 1.3 Configuring a Guest VLAN 1.3.1 Configuration Prerequisites Enable 802.1x Set the port access control method to portbased for the port Set the port access control mode to auto for the port Set the port link type to access. Create the VLAN to be specified as the guest VLAN 1-14
1.3.2 Configuration Procedure Follow these steps to configure Guest VLAN: To do Use the command Remarks Enter system view system-view Configure the guest VLAN for specified or all ports dot1x guest-vlan vlan-id [ interface interface-list ] Or in Ethernet interface view interface interface-type interface-number dot1x guest-vlan vlan-id Required By default, a port is configured with no guest VLAN. Note: A super VLAN cannot be set as the guest VLAN. Similarly, a guest VLAN cannot be set as the super VLAN. For information about super VLAN, refer to VLAN Configuration in the Access Volume. The guest VLAN function does not apply to non-access ports. Configurations in system view are effective to all ports while configurations in interface view are effective to the current port only. 1.4 Displaying and Maintaining 802.1x To do Use the command Remarks Display 802.1x session information, statistics, or configuration information of specified or all ports Clear 802.1x statistics display dot1x [ sessions statistics ] [ interface interface-list ] reset dot1x statistics [ interface interface-list ] Available in any view Available in user view 1.5 802.1x Configuration Example I. Network requirements As shown in Figure 1-10, a host is connected to port Ethernet 3/1/1 on the switch. The access control method of macbased is required on each port to control supplicants. All supplicants belong to default domain aabbcc.net, which can accommodate up to 30 users. RADIUS authentication is performed at first, and then local 1-15
authentication when no response from the RADIUS server is received. If the RADIUS accounting fails, the authenticator gets users offline. A server group with two RADIUS servers is connected to the switch. The IP addresses of the servers are 10.11.1.1 and 10.11.1.2 respectively. Use the former as the primary authentication/secondary accounting server, and the latter as the secondary authentication/primary accounting server. Set the shared key for the switch to exchange packets with the authentication server as name, and that for the switch to exchange packets with the accounting server as money. Specify the switch to try up to five times at an interval of 5 seconds in transmitting a packet to the RADIUS server until it receives a response from the server, and to send real time accounting packets to the accounting server every 15 minutes. Specify the switch to remove the domain name from the username before passing the username to the RADIUS server. Set the username of the 802.1x user as localuser and the password as localpassword and specify to use simple text mode. Enable the idle cut function to get the user offline whenever the user remains idle for over 20 minutes. II. Network diagram Figure 1-10 Network diagram for 802.1x configuration III. Configuration procedure Note: The following configuration procedure covers most AAA/RADIUS configuration commands for the authenticator, while configuration on the supplicant and RADIUS server are omitted. For information about AAA/RADIUS configuration commands, refer to AAA RADIUS HWTACACS Configuration in the Security Volume. # Add local access user localuser, enable the idle cut function, and set the idle cut interval. 1-16
<Sysname> system-view [Sysname] local-user localuser [Sysname-luser-localuser] service-type lan-access [Sysname-luser-localuser] password simple localpassword [Sysname-luser-localuser] attribute idle-cut 20 [Sysname-luser-localuser] quit # Create RADIUS scheme radius1 and enter its view. [Sysname] radius scheme radius1 # Configure the IP addresses of the primary authentication and accounting RADIUS servers. [Sysname-radius-radius1] primary authentication 10.11.1.1 [Sysname-radius-radius1] primary accounting 10.11.1.2 # Configure the IP addresses of the secondary authentication and accounting RADIUS servers. [Sysname-radius-radius1] secondary authentication 10.11.1.2 [Sysname-radius-radius1] secondary accounting 10.11.1.1 # Specify the shared key for the switch to exchange packets with the authentication server. [Sysname-radius-radius1] key authentication name # Specify the shared key for the switch to exchange packets with the accounting server. [Sysname-radius-radius1] key accounting money # Set the interval for the switch to retransmit packets to the RADIUS server and the maximum number of transmission attempts. [Sysname-radius-radius1] timer response-timeout 5 [Sysname-radius-radius1] retry 5 # Set the interval for the switch to send real time accounting packets to the RADIUS server. [Sysname-radius-radius1] timer realtime-accounting 15 # Specify the switch to remove the domain name of any username before passing the username to the RADIUS server. [Sysname-radius-radius1] user-name-format without-domain [Sysname-radius-radius1] quit # Create user domain aabbcc.net and enter its view. [Sysname] domain aabbcc.net [Sysname-isp-aabbcc.net] quit # Set user domain aabbcc.net as the default user domain. [Sysname] domain default enable aabbcc.net 1-17
[Sysname] domain aabbcc.net # Set radius1 as the RADIUS scheme for users of the domain and specify to use local authentication as the secondary scheme. [Sysname-isp-aabbcc.net] authentication lan-access radius-scheme radius1 local [Sysname-isp-aabbcc.net] authorization lan-access radius-scheme radius1 local [Sysname-isp-aabbcc.net] accounting lan-access radius-scheme radius1 local # Set the maximum number of users for the domain as 30. [Sysname-isp-aabbcc.net] access-limit enable 30 # Enable the idle cut function and set the idle cut interval. [Sysname-isp-aabbcc.net] idle-cut enable 20 [Sysname-isp-aabbcc.net] quit # Enable 802.1x globally. [Sysname] dot1x # Enable 802.1x for port Ethernet 3/1/1. [Sysname] interface ethernet 3/1/1 [Sysname-Ethernet3/1/1] dot1x [Sysname-Ethernet3/1/1] quit # Set the port access control method. (Optional. The default answers the requirement.) [Sysname] dot1x port-method macbased interface ethernet 3/1/1 1.6 Guest VLAN Configuration Example I. Network requirements As shown in Figure 1-11: A host is connected to port Ethernet 1/1/3 of the switch and must pass 802.1x authentication to access the Internet. The authentication server run RADIUS and is in VLAN 2. The update server, which is in VLAN 10, is for client software download and upgrade. Port Ethernet 1/1/8 of the switch, which is in VLAN 5, is for accessing the Internet. As shown in Figure 1-12: On port Ethernet 1/1/3, enable 802.1x and set VLAN 10 as the guest VLAN. As shown in Figure 1-13: Authenticated supplicants are assigned to VLAN 5 and permitted to access the Internet. 1-18
II. Network diagrams Figure 1-11 Network diagram for guest VLAN configuration Update server Authenticator server VLAN 10 VLAN 10 Eth1/1/5 VLAN 2 GuestVlan 10 Eth1/1/3 Switch VLAN 5 Eth1/1/8 Internet Supplicant Figure 1-12 Network diagram with VLAN 10 as the guest VLAN 1-19
Figure 1-13 Network diagram when the supplicant passes authentication III. Configuration procedure # Configure RADIUS scheme 2000. <Sysname> system-view [Sysname] radius scheme 2000 [Sysname-radius-2000] primary authentication 10.11.1.1 1812 [Sysname-radius-2000] primary accounting 10.11.1.1 1813 [Sysname-radius-2000] key authentication nec [Sysname-radius-2000] key accounting nec [Sysname-radius-2000] user-name-format without-domain [Sysname-radius-2000] quit # Configure domain system and specify to use RADIUS scheme 2000 for users of the domain. [Sysname] domain system [Sysname-isp-system] authentication lan-access radius-scheme 2000 [Sysname-isp-system] authorization lan-access radius-scheme 2000 [Sysname-isp-system] accounting lan-access radius-scheme 2000 [Sysname-isp-system] quit # Enable 802.1x globally. [Sysname] dot1x # Enable 802.1x for port Ethernet 1/1/3. [Sysname] interface ethernet 1/1/3 [Sysname-ethernet1/1/3] dot1x # Set the port access control method to portbased. 1-20
[Sysname-ethernet1/1/3] dot1x port-method portbased # Set the port access control mode to auto. [Sysname-ethernet1/1/3] dot1x port-control auto # Set the port link type to access. [Sysname-ethernet1/1/3] quit/3] port link-type access [Sysname-ethernet1/1/3] quit # Create VLAN 10. [Sysname] vlan 10 [Sysname-vlan10] quit # Specify port Ethernet 1/1/3 to use VLAN 10 as its guest VLAN. [Sysname] dot1x guest-vlan 10 interface ethernet1/1/3 You can use the display current-configuration or display interface ethernet1/1/3 command to view your configuration. You can also use the display vlan 10 command in the following cases to verify whether the configured guest VLAN functions: When no users log in. When a user fails the authentication. When a user goes offline. 1-21