Hello there, dear Community members!
This post refers to the access authentication troubleshooting as part of the All About Switches section. Please read below for more details.
1 Access Authentication Troubleshooting Overview
The process of going online includes two stages: authentication and access. The RADIUS protocol is most commonly used for authentication, and the 802.1x, Portal, and MAC address authentications are commonly used authentication methods. Combining authentication technologies with different LAN access technologies can implement user authentication and authorization, thus controlling access rights of access users.
When a switch functions as an access device, it uses domain to manage users. When a user requests to access the network, the switch identifies the domain of the user, determines the authentication, authorization, and accounting (AAA) information of the user based on the domain, and then modifies the network access rights according to the authentication and authorization results.
When an authentication failure occurs, the switch first determines the access type of the user. In 802.1x authentication, the user needs to enter the user name and password on the 802.1x client. In Portal authentication, the user needs to enter the authentication website address in the browser. In MAC address authentication, the user does not need to perform any operation.
After the access type is determined, perform the checks in the following sequence:
1. Check whether the authentication domain is correctly configured.
2. Check whether the AAA is correctly configured.
3. Check whether the access configuration is correct.
![]()
l In wireless access scenario, before handling the failure to go online, check whether the AP failed to go online or whether the STA failed to associate with the AP.
l In wireless access scenario, if the user still cannot go online after the 802.1x authentication is successful (the access device has sent an EAP Success packet to the client), check whether key negotiation failed.
2 802.1x Authentication Troubleshooting
An 802.1x authentication failure is possibly caused by the incorrect configurations of authentication domain, AAA, and 802.1x access. Table 2-1 lists the symptoms, reasons, and solutions of common 802.1x authentication failures.
Table 2-1 802.1x fault symptoms, reasons, and solutions
Symptom | Reason | Solution |
The test-aaa command fails to be executed (only for RADIUS authentication). | The user name or password is incorrect. | See "Running the test-aaa Command" in 2.2.1 Checking the Configuration When Server Authentication Is Used. |
Service between the switch and RADIUS server is interrupted. | ||
User authentication fails and the server does not receive authentication packets. | 802.1x authentication is not enabled on the switch. | See steps 1, 3, 4, and 5 in 2.3 Checking the 802.1x Authentication Configuration. |
When the authentication point is at the aggregation layer, the access switch does not transparently transmit 802.1x authentication packets. | ||
In the wireless scenario, the security policy (encryption mode) in the IPSec profile is incorrectly configured. | ||
The 802.1x client is incorrectly configured. | ||
The authentication domain on the switch is incorrectly configured. | See "An incorrect domain is used by a user, causing an authentication failure." in 2.1 Checking Whether the Authentication Domain Is Correctly Configured. | |
User authentication fails, but the server received authentication packets. | The authorization information is incorrectly configured on the switch or server. | See "Checking Whether the Authorization Configuration Is Correct" in 2.2.1 Checking the Configuration When Server Authentication Is Used. |
The 802.1x authentication protocol is incorrectly configured on the switch. | See step 1 in 2.3 Checking the 802.1x Authentication Configuration. | |
The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server. | See "The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server." in 2.1 Checking Whether the Authentication Domain Is Correctly Configured. |
2.1 Checking Whether the Authentication Domain Is Correctly Configured
Overview
A domain is a group of users. The access device performs authentication, authorization, and accounting for users based on domains. Each access user belongs to a domain.
The authentication, authorization, and accounting schemes are bound to a domain on the access device, and these schemes are applied to the users in this domain.
The domain of a user depends on the priorities of effective domains.
In V200R009C00 and later versions:
Priorities of forcible domain, default domain, and user domain are as follows: forcible domain with authentication mode specified in the authentication profile > forcible domain in the authentication profile > user domain > default domain with authentication mode specified in the authentication profile > default domain in the authentication profile > global default domain.
In the versions earlier than V200R009C00:
Priorities of forcible domain, default domain, and user domain are as follows: forcible domain with authentication mode specified on an interface > forcible domain on an interface > global forcible domain > user domain > default domain with authentication mode specified on an interface > default domain on an interface > global default domain.
Common Issues
l An incorrect domain is used by a user, causing an authentication failure. For example, the default domain is incorrectly configured or the user is not authenticated in the expected domain (the administrator may not be familiar with domain priorities).
l The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server. For example, one user name format contains the domain name, and another one does not contain the domain name.
Checking the Configurations
l An incorrect domain is used by a user.
In V200R009C00 and later versions:
Check the domain in the authentication profile, global domain, and user domain, and determine the authentication domain of the user according to the domain priorities.
Run the following command to check the domain configuration in the authentication profile:
[HUAWEI-authen-profile-p1] display this
#
authentication-profile name p1
mac-access-profile m1
access-domain huawei2 mac-authen force
access-domain huawei
access-domain huawei1 force
#
return
In the preceding example, the default domain in authentication profile p1 is huawei, the forcible domain is huawei1, and the forcible domain with MAC address authentication specified is huawei2. For MAC address authentication users, the domain huawei2 has the highest priority.
Run the access-domain domain-name [ dot1x | mac-authen | portal ] * [ force ] command in the authentication profile view to change the default or forcible domain.
Run the domain domain-name command in the system view to change the global default domain.
In the versions earlier than V200R009C00:
Check the domain on the interface, global domain, and user domain, and then determine the authentication domain of the user according to the domain priorities.
Run the following command to check the domain configuration on the interface:
[HUAWEI-GigabitEthernet1/0/1] display this
#
interface GigabitEthernet1/0/1
domain name huawei1 force
domain name huawei
domain name huawei2 mac-authen force
authentication mac-authen
#
return
In the preceding example, the default domain on interface GE1/0/1 is huawei, the forcible domain is huawei1, and the forcible domain with MAC address authentication specified is huawei2. For MAC address authentication users, the domain huawei2 has the highest priority.
Run the domain name domain-name [ dot1x | mac-authen | portal ] [ force ] command in the interface view to change the default or forcible domain.
Run the domain domain-name force command in the system view to change the default or forcible domain.
l The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server.
The user name formats configured on the RADIUS server and in the packets sent from the switch must both include domain name or neither includes domain name.
User name format in the packets sent from the switch to RADIUS server:
<HUAWEI> display radius-server configuration template shiva
---------------------------------------------------------------
Server-template-name : shiva
Protocol-version : standard
Traffic-unit : B
Shared-secret-key : %#%#fhJH$w{-{6lGe%%#%#
Timeout-interval(in second) : 5
Retransmission : 2
EndPacketSendTime : 0
Dead time(in minute) : 5
Domain-included : YES
NAS-IP-Address : 0.0.0.0
...
Domain-included: indicates whether the user name in packets includes the domain name.
YES: indicates that the user name includes the domain name.
NO: indicates that the user name does not include the domain name.
Original: The device does not modify the user name entered by the user.
Run the radius-server user-name command in the RADIUS template view to modify the user name format in the packets sent from the switch to RADIUS server.
Run the domain-name-delimiter command in the AAA view to change the domain name delimiter to @.
2.2 Checking the AAA Configuration
2.2.1 Checking the Configuration When Server Authentication Is Used
When an HWTACACS server is used to authenticate users, the test-aaa command is not supported. Different from RADIUS authentication, HWTACAS authentication is separated from HWTACAS authorization. Both authentication and authorization schemes must be configured on the switch. Otherwise, authorization cannot be performed after authentication is successful.
Running the test-aaa Command
The test-aaa command tests reachability of the RADIUS server. The switch sends an authentication request packet to the RADIUS server. If the server returns an authentication success packet, the switch and RADIUS server can communicate with each other. If the server does not return a packet or returns an authentication reject packet, the switch and RADIUS server cannot communicate with each other.
Fault symptom:
The following error messages may be displayed after the test-aaa command is run:
l If a timeout message is displayed, the switch and RADIUS server cannot communicate with each other.
Command and message:
[HUAWEI] test-aaa test test@123 radius-template policy
Error: Account test time out.
l If the message prompts an incorrect user name or password, the user name or password check fails and the RADIUS server returns a reject packet.
Command and message:
[HUAWEI] test-aaa test test@123 radius-template policy
Error: User name or password is wrong.
Timeout:
1. Check whether the switch can ping the RADIUS server.
2. Check whether the RADIUS server process can start.
When a controller functions as a RADIUS server, check whether the RADIUS server can start:
Choose Start > All Programs > Huawei > Agile Controller > Server Startup Config. Check whether the RadiusServer and AuthServer components are in running state. If not, click Start.
![]()
3. Check whether the configurations in the RADIUS server template and on the RADIUS server are consistent. The criteria are as follows:
− The IP address of the switch must be added to the RADIUS server. Otherwise, the server cannot identify the switch.
By default, the source IP address in the RADIUS packets sent from the switch to server is the IP address of the interface connected to the server. You can also set the source ip-address parameter in the radius-server authentication command to set the source IP address.
[HUAWEI-radius-policy] radius-server authentication 172.16.1.1 1812 source ip-address 10.8.8.7
− The authentication listening port number on the RADIUS server must be the same as that on the switch.
Generally, the authentication port number is 1812 and accounting port number is 1813.
When the controller functions as a RADIUS server, run the netstat -nao | findstr 1812 and netstat -nao | findstr 1813 commands on the server to check whether the port is occupied by other services.
− The shared keys on the switch and RADIUS server must be the same.
The shared keys are displayed in cipher text on the switch and RADIUS server, which does not facilitate comparison. You can reset them to ensure their consistency.
Configure a RADIUS server template on the switch:
[HUAWEI] radius-server template policy
[HUAWEI-radius-policy] radius-server authentication 172.16.1.1 1812 //Configure the IP address and port number for the authentication server.
[HUAWEI-radius-policy] radius-server accounting 172.16.1.1 1813 //Configure the IP address and port number for the accounting server.
[HUAWEI-radius-policy] radius-server shared-key cipher Admin@123 //Configure the shared key.
4. When a relay is configured, the shared key on the RADIUS relay agent must be the same as the shared key on the RADIUS server.
Incorrect user name or password:
1. Check whether the user name and password used in test-aaa are added to the RADIUS server.
2. Run the test-aaa command and check whether the user name in the authentication request packet sent from the switch to RADIUS server is the same as the user name configured on the server.
Note:
![]()
l Run the radius-server user-name command to set the user name format in the packets sent from the switch to RADIUS server.
radius-server user-name domain-included: The user name includes a domain name.
radius-server user-name original: The switch does not modify the user name entered by the user.
undo radius-server user-name domain-included: The user name does not include a domain name.
The default format is original.
l To change the domain name delimiter, run the domain-name-delimiter command. The default delimiter is @.
3. Some RADIUS server will check the RADIUS authentication request packets sent by the test-aaa command. The authentication request packets sent by the test-aaa command do not include MAC addresses, so the check fails and a reject message is returned. In this situation, user authentication is not affected even though the test-aaa command fails.
Checking Whether the Authorization Configuration Is Correct
Fault symptom:
l The authorized VLAN does not take effect or the client does not obtain an IP address from a new VLAN.
l Authorized ACL does not take effect.
l Authorized UCL group does not take effect.
Possible causes:
l When a server performs authorization:
− If the authorization information on the switch and server is inconsistent, authorization fails.
− Check whether the authorization attributes are carried.
l When local authorization is used: Local authorization information is incorrect.
Troubleshooting procedure:
1. Check whether authorization is successful.
Authorization information is displayed in user entries, so you can view user entries (by running the display access-user user-id/mac-address/ip-address command) to know whether authorization is successful.
2. When an HWTACAS server performs authorization, check whether an authorization scheme is configured.
− Check whether the authorization scheme is bound to an authentication domain.
[HUAWEI-aaa-domain-a] display this
#
domain a
authentication-scheme s1
authorization-scheme s1
hwtacacs-server t1
#
− Check whether the authorization method is correct.
[HUAWEI-aaa-author-s1] display this
#
authorization-scheme s1
authorization-mode hwtacacs
#
return
3. When a server performs authorization:
a. Check whether the authorization information on the switch is the same as that on the server.
The ACL (number and description) and VLANs authorized by the server must exist on the switch.
If the ACL (number and description) and VLANs authorized by the server do not exist on the switch, the switch will fail to check authorization information. By default, a switch allows users to go online if authorization information check fails. In this situation, authorization delivered by the server does not take effect.
![]()
To control whether the switch allows users to go online if authorization information check fails, run the authorization-info check-fail policy { online | offline } command.
b. Check whether authorization attributes are carried.
Capture packets on the server to check whether authorization attributes are carried.
n Attributes required in VLAN authorization:
![]()
l When the server authorizes VLAN, three standard attributes (64, 65, and 81) need to be carried.
l When the server authorizes voice VLAN, besides the preceding three attributes, Huawei property attributes 26-33 need to be delivered.
|
|
|
64 | Tunnel-Type | The value 13 indicates a VLAN protocol. |
65 | Tunnel-Medium-Type | This field has a fixed value of 6, indicating the Ethernet type. |
81 | Tunnel-Private-Group-ID | This field indicates the VLAN ID. |
26-33 | HW-Voice-Vlan | This is the voice VLAN authorization flag. The value 1 indicates that the authorized VLAN is a voice VLAN. This field is used together with VLAN authorization attributes. |
n Attributes required in ACL authorization:
![]()
l In ACL authorization, standard attribute 11 or Huawei property attributes 26-82 are used. The specific attributes depend on which attributes used by the server to carry ACL authorization information.
l When ACL is authorized using standard attribute 11, only ACL 3000-3999 (wired users) or 3000-3031 (wireless users) can be carried.
l When direct forwarding mode is used, Huawei property attributes 26-82 are not supported for wireless users.
Attribute No. | Attribute Name | Description |
11 | Filter-Id | ACL ID for a user or user group. A RADIUS packet can carry only one of the ACL ID and user group name. |
26-82 | HW-Data-Filter | When a user goes online, RADIUS delivers ACL rules using this attribute. |
4. When local authorization is used, check whether the local authorization information is correct.
The following are the configurations of VLAN and ACL authorization:
− VLAN authorization after authentication is successful:
Unified mode: Bind a user VLAN to a service scheme, and bind the service scheme to a domain to implement local VLAN authorization.
Common mode: Bind a user VLAN to a user group, and bind the user group to a domain to implement local VLAN authorization.
− ACL authorization before authentication is successful:
Unified mode: Bind an ACL ID or UCL group to a service scheme, and bind the service scheme to a domain to implement local ACL authorization.
Common mode: Bind an ACL ID to a user group, and bind the user group to a domain to implement local ACL authorization.
![]()
Run the user-group group_name enable command to enable the user group globally.
− VLAN authorization before authentication:
Common mode: Configure the guest-vlan/ critical-vlan/ restrict-vlan functions to implement VLAN authorization in different scenarios.
Unified mode: Run the authentication event command to perform pre-connection authorization in different scenarios.
− ACL authorization before authentication:
Unified mode: Run the authentication event command to perform pre-connection authorization in different scenarios.
5. Collect the following information and contact technical support personnel:
− Fault symptom
− Switch model, version, patch, networking, and configuration
− Packet capture information on the server side
− Collect trace and debugging information on the switch. For details, see "Collecting Access Authentication Information" in Appendix.
More Information
l If a terminal uses Portal authentication or combined authentication (including Portal authentication), the switch cannot authorize a VLAN to the terminal.
l To make VLAN authorization effective, the interface link type and access mode must meet the following requirements:
− When the link type is tagged and hybrid, VLAN authorization is not supported.
− When the link type is untagged and hybrid, there is no requirement on the user access mode (set by the authentication mode command).
− When the link type is access or trunk, the user access mode must be multi-share.
l If a terminal obtains an IP address through DHCP, you need to manually trigger DHCP to allocate IP address again after VLAN authorization is successful or authorized VLAN is changed.
l The server IP address is denied by the authorize ACL, causing an accounting failure. The switch disconnects the user when accounting fails to start.
l Some cards do not support UCL authorization. For details, see the specification list.
Checking Whether the Accounting Configuration Is Correct
The accounting service of most RADIUS servers (for example, Agile Controller) differs from the real accounting function. They obtain users' online and offline time from accounting packets exchanged between the RADIUS server and access control device, and forcibly disconnect users by sending accounting packets. They aim at managing online users using the RADIUS accounting function to control the online duration of users.
Common issues:
l Basic accounting configuration is incorrect.
l Real-time accounting intervals set on the switch and server are different, which causes users to go offline regularly.
Troubleshooting procedure:
l Check whether the basic accounting configuration is correct.
− Check whether an accounting profile is bound to the authentication domain.
[HUAWEI-aaa-domain-a] display this
#
domain a
authentication-scheme radius
accounting-scheme account1
radius-server default
#
− Check whether the accounting method is correct.
[HUAWEI-aaa-accounting-account1] display this
#
accounting-scheme account1
accounting-mode radius
#
return
![]()
accounting-mode radius//If the authentication method is RADIUS, accounting method must be RADIUS.
accounting-mode hwtacacs//If the authentication method is HWTACACS, accounting method must be HWTACACS.
− Check whether the accounting profile has been created.
<HUAWEI> display accounting-scheme
-----------------------------------------------------------
Accounting-scheme-name Accounting-method
-----------------------------------------------------------
default None
radius-1 RADIUS
tacas-1 HWTACACS
-----------------------------------------------------------
Total of accounting-scheme: 3
l Check whether the real-time accounting intervals set on the switch and server are the same.
The server and switch need to compare the online user lists periodically. If the accounting interval is not set or different accounting intervals are set on the switch and server, the end with a shorter interval may disconnect a user while the end with a longer interval is checking the online user list. In this situation, users are disconnected regularly.
A shorter real-time accounting interval requires higher performance of the switch and RADIUS server. Set the real-time accounting interval based on the user quantity.
Number of Users | Recommended Accounting Interval |
1-99 | 3 min |
100-499 | 6 min |
500-999 | 12 min |
≥ 1000 | ≥ 15 min |
− Check the real-time accounting interval on the switch:
[HUAWEI-aaa-accounting-account1] display this
#
accounting-scheme account1
accounting-mode radius
accounting realtime 15
#
return
Run the accounting realtime command in the accounting scheme view to change the accounting interval.
− Check the real-time accounting interval on the server.
For example, on the Agile Controller, choose Resource > Device > Device Management.
![]()
2.2.2 Checking the Configuration When Local Authentication Is Used
Common Issues
l Local user access type is incorrectly set.
l The local user level is incorrectly set.
Incorrect Local User Access Type
Troubleshooting procedure:
1. Check whether the local user access type is incorrect.
Run the following command:
<HUAWEI> display local-user
---------------------------------------------------------------
User-name State AuthMask AdminLevel
---------------------------------------------------------------
user-a A - 0
user-c A W 0
---------------------------------------------------------------
Total 2 user(s)
AuthMask indicates the local user access type:
− The value X indicates 802.1x authentication.
− The value W indicates Portal authentication.
2. Run the local-user user-name service-type { 8021x | web } command in the AAA view to change the local user access type.
− 8021x indicates 802.1x user access.
− web indicates Portal user access.
![]()
When AAA local authentication is applied to MAC address authentication users, the switch does not check local user access type.
Local User Level Is Incorrect
The system grants users different access permissions based on their roles so that the users can only access specified devices. User levels correspond to the command levels. Users can use only the commands at the same or lower level than their own levels. By default, there are four command levels 0 to 3 and 16 user levels 0 to 15. The following table lists the relationship between command levels and user levels.
Command Level | Description | User Level |
Visit level (level-0) | Debugging commands, commands used to access external systems | Level 0-15 |
Monitoring level (level-1) | System maintenance commands | Level 1-15 |
Configuration level (level-2) | Service configuration commands | Level 2-15 |
Management level (level-3) | System basic operation commands, system support module commands | Level 3-15 |
Fault symptom:
l After a local user or administrator logs in to the switch, the switch cannot be operated and commands cannot be executed.
l After the switch is upgraded, local users cannot operate the switch and commands cannot be executed.
Possible causes:
The default user level is 0, and is not changed.
Troubleshooting procedure:
1. Run the following command to check whether the user level is correct:
<HUAWEI> display local-user
---------------------------------------------------------------
User-name State AuthMask AdminLevel
---------------------------------------------------------------
user-a A - 0
user-c A W 0
---------------------------------------------------------------
Total 2 user(s)
AdminLevel indicates the user level.
2. Use any of the following methods to change the local user level. The priorities are in a descending order:
a. To set the local user level, run the local-user privilege level command.
b. To set the administrator level in a domain, run the admin-user privilege level command.
c. To set the user level in the VTY interface view, run the user privilege command.
![]()
l When a remote RADIUS server provides authentication, the user level is delivered using Huawei property No. 29 attribute HW-Exec-Privilege.
l When the remote RADIUS server and local authentication are configured, the local user level is used only when the remote authentication server does not respond. If the remote authentication server responds to authentication requests but does not deliver user levels, the configured local user level does not take effect.
2.3 Checking the 802.1x Authentication Configuration
Common Issues
l 802.1x authentication errors include:
− 802.1x authentication is not enabled on interfaces.
− 802.1x authentication is incorrectly configured.
− 802.1x authentication conflicts with other configuration.
l The authorization information on the RADIUS server is different from the authorization information on the switch.
l When the authentication point is at the aggregation layer, the access switch does not transparently transmit 802.1x authentication packets.
l In the wireless scenario, the security policy (encryption mode) in the IPSec profile is incorrectly configured.
l The 802.1x client is incorrectly configured.
Troubleshooting Procedure
Step 1 Check whether 802.1x authentication is correctly configured.
1. Check whether 802.1x authentication is enabled on the interface.
Switch of V200R009C00 or a later version:
802.1x authentication takes effect on an interface only after an authentication profile is bound to the interface and an 802.1x authentication profile is bound to the authentication profile.
a. Check whether an authentication profile is bound to the interface.
![]()
In wireless access scenario, check whether an authentication profile is bound to the VAP profile.
Run the following command to check the configuration on the interface:
[HUAWEI-GigabitEthernet1/0/12] display this
#
interface GigabitEthernet1/0/12
port link-type trunk
port trunk allow-pass vlan 2 to 4094
authentication-profile dot1x_authen_profile
#
b. Check whether an 802.1x authentication profile is bound to the authentication profile.
Run the following command to check the configuration in the authentication profile:
[HUAWEI-authen-profile-dot1x_authen_profile] display this
#
authentication-profile name dot1x_authen_profile
dot1x-access-profile d1
#
Switch of a version earlier than V200R009C00:
Check whether 802.1x authentication is enabled on the interface.
[HUAWEI-GigabitEthernet1/0/1]display this
#
interface GigabitEthernet1/0/1
authentication dot1x
#
return
2. Check whether 802.1x authentication is correctly configured.
802.1x authentication includes EAP relay (configured by eap) and EAP termination (configured by chap and pap). The authentication method configured on the switch must be supported by both server and terminals; otherwise, the authentication will fail.
![]()
l EAP relay mode is supported only when RADIUS authentication is used, and local authentication supports only EAP termination.
l Mobile phones do not support EAP termination, so the 802.1x + local authentication are not supported by mobile phones. Laptops support EAP termination only after the third-party client software is installed.
Switch of V200R009C00 or a later version:
Run the following command to check the authentication method used by the 802.1x authentication profile:
<HUAWEI> display dot1x-access-profile configuration name d1
Profile Name : d1
Authentication method : EAP
Port control : authorized-force
Re-authen : Enable
Client-no-response authorize : -
Trigger condition : arp
Unicast trigger : Enable
Trigger dhcp-bind : Enable
Handshake : Disable
Handshake packet-type : request-identity
Max retry value : 2
Reauthen Period : 3600s
Client Timeout : 5s
Handshake Period : 60s
Eth-trunk handshake period : 120s
Bound authentication profile : -
Run the dot1x authentication-method { chap | pap | eap } command in the 802.1x authentication profile to change the 802.1x authentication method.
Switch of a version earlier than V200R009C00:
Run the following command to check the 802.1x authentication method:
<HUAWEI> display dot1x
Global 802.1x is Enabled
Authentication method is CHAP
Max users: 32768
Current users: 0 ...
GigabitEthernet1/8/0/15 status: DOWN 802.1x protocol is Enabled
Authentication mode is multi-authen
Authentication method is CHAP
Reauthentication is disabled ...
The configuration on interfaces has a higher priority than global configuration.
Run the dot1x authentication-method { chap | pap | eap } command in the system or interface view to change the 802.1x authentication method.
3. Check whether there is a configuration that conflicts with 802.1x authentication.
After the following functions are configured on an interface, 802.1x authentication cannot be configured:
Command | Function |
mac-limit | Sets the maximum number of MAC addresses that can be learned by an interface. |
mac-address learning disable | Disables MAC address learning on an interface. |
port link-type dot1q-tunnel | Sets the link type of an interface to QinQ. |
port vlan-mapping vlan map-vlan port vlan-mapping vlan inner-vlan | Configures VLAN mapping on an interface. |
port vlan-stacking | Configures selective QinQ. |
port-security enable | Configures port security. |
mac-vlan enable | Enables MAC address-based VLAN allocation on an interface. |
ip-subnet-vlan enable | Enables IP subnet-based VLAN allocation on an interface. |
Step 2 Check whether the authorization information configured on the RADIUS server and switch is correct.
For the method and procedure, see "Checking Whether the Authorization Configuration Is Correct" in 2.2.1 Checking the Configuration When Server Authentication Is Used.
Step 3 Check whether EAP relay is configured on an access-layer switch (applicable to the scenario where authentication device is located at the aggregation layer).
Run the following command to check whether EAP relay is configured. If no information is displayed, EAP relay is not configured.
display l2protocol-tunnel group-mac user-defined-protocol 802.1x
Configure EAP relay on the access device as follows:
1. Run the l2protocol-tunnel user-defined-protocol 802.1x protocol-mac 0180-c200-0003 group-mac 0100-0000-0002 command in the system view to define Layer 2 transparent transmission of EAP packets.
2. Run the l2protocol-tunnel user-defined-protocol 802.1x enable command on the downlink interface connected to users and uplink interface connected to the switch to enable Layer 2 transparent transmission.
Step 4 Check whether the security policy is correctly configured on a security profile (applicable to wireless access scenario).
The following are recommended security policies for different authentication methods:
l External Portal authentication, internal Portal authentication, MAC address authentication: open authentication
l 802.1x authentication: WPA/WPA2-802.1x
Run the following command to check the security policy and encryption method used in the security policy profile:
<HUAWEI> display security-profile name default
------------------------------------------------------------
Security policy : Open system
Encryption : -
...
Run the security { wpa | wpa2 | wpa-wpa2 } dot1x { aes | tkip | aes-tkip } command in the security profile view to modify the security policy applied to 802.1x users.
Step 5 Check whether the parameters of 802.1x client are correctly set.
For details, see 7.2 Configuring the 802.1x Clients in Operating Systems in Appendix.
Step 6 Collect the following information and contact technical support personnel:
Generally, the trace function can meet requirement. Use the following commands only when service traffic volume is small.
Command | Function |
debugging dot1x all | Enables 802.1x authentication debugging. |
debugging cm all | Enables UCM module debugging. |
debugging aaa all | Enables AAA module debugging to display user authentication domain information. |
debugging radius all | Displays authentication information exchanged between users and RADIUS module. |
----End
3 Portal Authentication Troubleshooting
3.1 Portal Authentication Page Cannot Be Displayed
When Portal authentication pages cannot be displayed, check whether the terminal can access the Portal server (http://Portal server-IP:8080/portal) using an IP address to ensure the connectivity between the terminal and Portal server.
3.1.1 Terminal Can Access the Portal Server Using an IP Address
Possible Causes
If the terminal can access the Portal server (http://Portal server-IP:8080/portal) using an IP address, the connectivity between the terminal and Portal server is normal. In this situation, the possible causes of Portal authentication page push failure are:
l The Portal authentication function is disabled on the switch.
l The URL address of the Portal authentication page is incorrect, so the switch/AC cannot redirect HTTP requests to the Portal server.
l The IP address of the page accessed by the terminal is configured as authentication-free resource.
l The browser of the terminal uses the HTTPS protocol, but HTTPS redirection is not enabled on the switch.
l The DNS settings on the switch or terminal are incorrect.
Troubleshooting Roadmap
In the following figure, access http://x.x.x.x (x.x.x.x is the authentication domain address) on the terminal to check whether the Portal authentication page can be displayed. Determine whether the switch configuration is incorrect.
![]()
The switch checks terminal's HTTP traffic to push Portal pages. When a terminal accesses http://x.x.x.x in the browser, the HTTP traffic sent by the terminal passes through the access control device, causing the device to push the Portal authentication page. Because the URL is in the format http://x.x.x.x but not http://www.example.com, the fault is not caused by a DNS resolution error.
l Address cannot be accessed: The access control device is incorrectly configured. Check the switch configuration.
l Address can be accessed: The HTTP traffic from the terminal can trigger the push of the Portal authentication page. The fault may be caused by a DNS resolution error.
![]()
Troubleshooting Procedure
URL address cannot be accessed:
Step 1 Check whether Portal authentication is enabled on the switch.
Switch of V200R009C00 or a later version:
Portal authentication can be enabled on an interface only when an authentication profile is bound to an authentication interface, a Portal authentication profile is bound to the authentication profile, and a Portal server template is bound to the Portal authentication profile.
l Run the following command to check whether an authentication profile is bound to the interface:
[HUAWEI-Vlanif10] display this
#
interface Vlanif103
ip address 172.16.2.2 255.255.255.0
authentication-profile p1
#
l Run the following command to check whether a Portal authentication profile is bound to the authentication profile:
[HUAWEI-authen-profile-p1] display this
#
authentication-profile name p1
portal-access-profile web1
#
l Run the following command to check whether a Portal server template is bound to the Portal authentication profile:
[105-S5720HI-portal-acces-profile-web1] display this
#
portal-access-profile name web1
web-auth-server portal_huawei layer3
#
Switch of a version earlier than V200R009C00:
Portal authentication must be enabled on an interface and bound to a Portal server template.
[HUAWEI-GigabitEthernet1/0/1] display this
#
interface GigabitEthernet1/0/1
authentication portal
web-auth-server s1 direct
#
return
Step 2 Check whether the URL address of the Portal authentication page is correct.
Access the URL of the Portal authentication page from the browser on terminal. If the Portal authentication page is normally displayed, the configuration is correct.
If the Portal authentication page cannot be displayed, perform the following steps:
Check whether the URL address configured in the web server template is correct.
[107-S7712]display web-auth-server configuration
...
URL : http://192.168.1.1:8080/portal URL Template :
...
If an URL template is bound to a web server template, check whether the URL address configured in the URL template is correct.
<HUAWEI> display url-template name huawei
...
URL :
1. http://192.168.1.1:8080/portal
...
For example, when an Agile Controller functions as a Portal server, the URL address must be in the following formats:
l http://Agile Controller IP address:8080/portal
l http://Agile Controller domain name:8080/portal
![]()
If the URL address of the Portal authentication page is a domain name, perform Step 3.
Step 3 Collect the following information and contact technical support personnel:
l Terminal type, browser type and version, and Portal server type
l Switch configuration and networking
l Packet capture information on the terminal side and server side
l Debugging information on AP in wireless scenario
Command | Function |
debugging portal all | Enables Portal module debugging. |
----End
URL address can be accessed:
When a terminal accesses the authentication domain using a domain name (http://www.example.com).
l If the address can be accessed, perform Step 1 and Step 2.
l If the address cannot be accessed, perform Step 3.
Step 1 Check whether the IP address of the page accessed by the terminal is configured as authentication-free resource.
If so, the switch does not perform redirection.
Run the following command to check whether the IP address is authentication-free:
[HUAWEI-free-rule-default_free_rule] display this
#
free-rule-template name default_free_rule
free-rule 1 destination ip 10.72.55.101 mask 255.255.255.255
#
return
Step 2 Check whether the terminal uses the HTTPS protocol.
When a terminal accesses websites using the HTTPS protocol, the switch does not perform redirection by default. You need to enable HTTPS redirection for Portal authentication.
[HUAWEI] portal https-redirect enable
Step 3 Check whether DNS settings on the switch or terminal are correct.
If the authentication page can be displayed when the Portal server IP address is entered, but the page cannot be displayed when the domain name is entered, check whether the DNS settings on the switch or terminal are correct.
l Check whether the DNS address configured on the terminal is correct.
Check the DNS address setting on a terminal, for example, a terminal running Microsoft Windows 7. Choose Control Plane > Network and Internet > Network and Sharing Center, and click Local Area Connection. Then click Detail.
![]()
If a terminal obtains an IP address using DHCP, DNS will be configured automatically. If the terminal accesses the network using a static IP address, you need to configure DNS manually.
l Check whether the DNS address is added to the authentication-free rule.
Run the following command to display authentication-free rules:
[HUAWEI-free-rule-default_free_rule] display this
#
free-rule-template name default_free_rule
free-rule 1 destination ip 10.72.55.10 mask 255.255.255.255
#
return
Add the DNS address 10.72.55.1 to the authentication-free rule.
[HUAWEI] free-rule-template name default_free_rule
[HUAWEI-free-rule-default_free_rule]free-rule 2 destination ip 10.98.48.39 mask 255.255.255.255
l If the DNS server address has been added to the authentication-free rule but the DNS server cannot be pinged, contact the DNS server technical support personnel.
Step 4 Collect the following information and contact technical support personnel:
l Terminal type, browser type and version, and Portal server type
l Switch configuration and networking
l Packet capture information on the terminal side and server side
l Debugging information on AP in wireless scenario
Command | Function |
debugging portal all | Enables Portal module debugging. |
----End
3.1.2 Terminal Cannot Access the Portal Server Using an IP Address
Possible Causes
If the terminal cannot access the Portal server (http://Portal server-IP:8080/portal) using an IP address, the connectivity between the terminal and Portal server is abnormal. In this situation, the possible causes of Portal authentication page push failure are:
l The link fault, route fault, or gateway configuration error exists between the terminal and Portal server.
l The process of Portal server is not started.
l The proxy is configured in the browser on the terminal.
Troubleshooting Roadmap
In the following figure, perform a ping operation between the terminal and Portal server to test the network connectivity.
l Ping fails: A link fault, route fault, or gateway configuration error exists between the terminal and Portal server.
l Ping is successful: There is a reachable route between the terminal and Portal server.
![]()
Troubleshooting Procedure
The terminal cannot ping the Portal server:
Step 1 Check whether a link fault, route fault, or gateway configuration error exists between the terminal and Portal server.
----End
The terminal can successfully ping the Portal server:
Step 1 Check whether the Portal server process can start.
Enter the IP address of the Portal server. If the authentication page still cannot be displayed, check whether the Portal server process is started.
When a controller functions as a Portal server, check whether the Portal server can start:
Choose Start > All Programs > Huawei > Agile Controller > Server Startup Config. Check whether the PortalServer component is in running state. If not, click Start.
![]()
Step 2 Check whether proxy is configured for the browser.
If the proxy is enabled on the browser, the proxy server will change the route, causing a communication failure between the terminal and Portal server. Consequently the terminal cannot access the Portal authentication page.
Disable proxy on the browser, for example, in IE8:
Choose Tool > Internet Options > Connection and click LAN Settings. Disable proxy on the LAN Settings page.
![]()
Step 3 Collect the following information and contact technical support personnel:
l Terminal type, browser type and version, and Portal server type
l Switch configuration and networking
l Packet capture information on the terminal side and server side
l Debugging information on AP in wireless scenario
Command | Function |
debugging portal all | Enables Portal module debugging. |
----End
3.2 Portal Authentication Page Can Be Displayed But Authentication Fails
A Portal authentication failure is possibly caused by the incorrect configurations of authentication domain, AAA, and Portal access. Table 3-1 lists the symptoms, reasons, and solutions of common Portal authentication failures.
Table 3-1 Portal fault symptoms, reasons, and solutions
Symptom | Reason | Solution |
The test-aaa command fails to be executed (only for RADIUS authentication). | The user name or password is incorrect. | See "Running the test-aaa Command" in 2.2.1 Checking the Configuration When Server Authentication Is Used. |
Service between the switch and RADIUS server is interrupted. | ||
User authentication fails and the server does not receive authentication packets. | The authentication domain on the switch is incorrectly configured. | See "An incorrect domain is used by a user, causing an authentication failure." in 2.1 Checking Whether the Authentication Domain Is Correctly Configured. |
The Portal server template configurations on the switch and Portal server are different. | See 3.2.3 Checking the Portal Authentication Configuration. | |
User authentication fails, but the server received authentication packets. | The authorization information is incorrectly configured on the switch or server. | See "Checking Whether the Authorization Configuration Is Correct" in 2.2.1 Checking the Configuration When Server Authentication Is Used. |
The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server. | See "The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server." in 2.1 Checking Whether the Authentication Domain Is Correctly Configured. |
3.2.1 Checking the Authentication Domain Configuration
For the method and procedure, see 2.1 Checking Whether the Authentication Domain Is Correctly Configured.
3.2.2 Checking the AAA Configuration
For the method and procedure, see 2.2 Checking the AAA Configuration.
3.2.3 Checking the Portal Authentication Configuration
Possible Causes
The Portal server template configurations on the switch and Portal server are different.
Troubleshooting Procedure
Step 1 Check whether the Portal server template configurations on the switch and Portal server are different.
l Check whether the switch IP address added to the Portal server is correct.
By default, the source IP address in the packets sent from the switch to Portal server is the IP address of the interface connected to the Portal server (view the source IP address by checking the route to the Portal server address). Alternatively, you can run the source-ip command in the Portal server template view to set the source IP address.
l Check whether the Portal server address is correctly configured using the server-ip command in the Portal server template view.
l Check whether the terminal IP address segment is within the terminal IP address list on the Portal server.
If the IP address is not within the terminal IP address list, the Portal server will not send a Portal authentication request to the switch after receiving a request from the terminal. In this situation, terminal authentication fails.
l Check whether the port number used by the switch is the same as the port number configured on the Portal server.
The default port number is 2000. To set the port number, run the web-auth-server listening-port port-number command in the Portal server template view.
l Check whether the port number used by the Portal server is the same as the portal server configured on the switch.
The default port number is 50100. To set the port number, run the port port-number [ all ] command in the Portal server template view.
l Check whether the shared keys are consistent.
The shared keys are displayed in cipher text on the switch and Portal server, which does not facilitate comparison. You can reset them to ensure their consistency.
Step 2 Collect the following information and contact technical support personnel:
l Problem symptom and initial troubleshooting result
l Reason why the user fails to go online and why the user is disconnected
− Unexpected user disconnection records
[HUAWEI-diagnose] display aaa abnormal-offline-record mac-address 148f-c661-b424
− Records of failure to go online
[HUAWEI-diagnose] display aaa online-fail-record mac-address 148f-c661-b424
− User disconnection records
[HUAWEI-diagnose] display aaa offline-record mac-address 148f-c661-b424
l Switch configuration and networking
l Packet capture information on the terminal side and server side
l Trace or debugging information
Generally, the trace function can meet requirement. Use the following commands only when service traffic volume is small.
Command | Function |
debugging portal all | Enables Portal module debugging. |
debugging web all | Enables web authentication module debugging. |
debugging cm all | Enables UCM module debugging. |
debugging aaa all | Enables AAA module debugging to display user authentication domain information. |
debugging radius all | Displays authentication information exchanged between users and RADIUS module. |
debugging tm all | Enables TM module debugging. |
----End
4 MAC Address Authentication Troubleshooting
A MAC authentication failure is possibly caused by the incorrect configurations of authentication domain, AAA, and MAC address access. Table 4-1 lists the symptoms, reasons, and solutions of common MAC authentication failures.
Table 4-1 MAC authentication fault symptoms, reasons, and solutions
Symptom | Reason | Solution |
The test-aaa command fails to be executed (only for RADIUS authentication). | The user name or password is incorrect. | See "Running the test-aaa Command" in 2.2.1 Checking the Configuration When Server Authentication Is Used. |
Service between the switch and RADIUS server is interrupted. | ||
User authentication fails and the server does not receive authentication packets. | MAC address authentication is not enabled on the switch. | See Step 1 in 4.3 Checking the MAC Authentication Configuration. |
The authentication domain on the switch is incorrectly configured. | See "An incorrect domain is used by a user, causing an authentication failure." in 2.1 Checking Whether the Authentication Domain Is Correctly Configured. | |
User authentication fails, but the server received authentication packets. | The authorization information is incorrectly configured on the switch or server. | See "Checking Whether the Authorization Configuration Is Correct" in 2.2.1 Checking the Configuration When Server Authentication Is Used. |
The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server. | See "The user name format in the packets sent from the switch to RADIUS server is different from the user name format configured on the RADIUS server." in 2.1 Checking Whether the Authentication Domain Is Correctly Configured. | |
The user name format in MAC address authentication is different from that configured on the server. | See Step 2 in 4.3 Checking the MAC Authentication Configuration. |
4.1 Checking the Authentication Domain Configuration
For the method and procedure, see 2.1 Checking Whether the Authentication Domain Is Correctly Configured.
4.2 Checking the AAA Configuration
For the method and procedure, see 2.2 Checking the AAA Configuration.
4.3 Checking the MAC Authentication Configuration
Common Issues
l MAC authentication is not enabled on interfaces.
l The user name format in MAC address authentication is different from that configured on the server.
l MAC authentication conflicts with other configuration.
Troubleshooting Procedure
Step 1 Check whether MAC authentication is enabled on the interface.
Switch of V200R009C00 or a later version:
MAC authentication takes effect on an interface only after an authentication profile is bound to the interface and a MAC authentication profile is bound to the authentication profile.
1. Check whether an authentication profile is bound to the interface.
![]()
In wireless access scenario, check whether an authentication profile is bound to the VAP profile.
Run the following command to check the configuration on the interface:
[HUAWEI-GigabitEthernet1/0/12] display this
#
interface GigabitEthernet1/0/12
port link-type trunk
port trunk allow-pass vlan 2 to 4094
authentication-profile mac_authen_profile
#
2. Check whether a MAC authentication profile is bound to the authentication profile.
Run the following command to check the configuration in the authentication profile:
[HUAWEI-authen-profile-mac_authen_profile] display this
#
authentication-profile name mac_authen_profile
mac-access-profile m1
#
Switch of a version earlier than V200R009C00:
Check whether MAC address authentication is enabled on the interface.
[HUAWEI-GigabitEthernet1/0/1] display this
#
interface GigabitEthernet1/0/1
authentication mac
#
return
Step 2 Check whether the user name format in MAC address authentication is the same as that configured on the server.
1. Check the user name format for MAC address authentication configured on the server.
For example, on the Agile Controller, choose Resource > User > User Management. On the User tab page, click View Account.
![]()
2. Check the user name format for MAC address authentication configured on the switch.
Run the following command to check the user name format for MAC address authentication:
[HUAWEI] display mac-access-profile configuration name m1
Profile Name : m1
Username format : fixed username: a
Password type : cipher
Fixed password : %^%#`2ML)8skyH9-y_Atgh@,c\VY"rXYATw:t)Q;MeNF%^%#
Re-authen : Enable
Trigger condition : arp dhcp nd dhcpv6
Offline dhcp-release : Enable
Re-authen dhcp-renew : Enable
Reauthen Period : 1800s
Bound authentication profile : -
Username format indicates user name format used by MAC address authentication users, including fixed user name, MAC address format, and DHCP Option.
MAC address format includes:
− xxxx-xxxx-xxxx: Each group contains four bits and groups are separated by -. The parameter is with-hyphen.
− xx-xx-xx-xx-xx-xx: Each group contains two bits and groups are separated by -. The parameter is with-hyphen normal.
− xxxxxxxxxxxx: No delimiter is used. The parameter is without-hyphen.
The uppercase parameter indicates that the letters in MAC address are case sensitive.
To modify the user name format for MAC address authentication, run the following command in the MAC authentication profile view:
mac-authen username { fixed username [ password cipher password ] | macaddress [ format { with-hyphen [ normal ] | without-hyphen } [ uppercase ] [ password cipher password ] ] | dhcp-option option-code { circuit-id | remote-id } password cipher password }
Step 3 Check whether there is a configuration that conflicts with MAC address authentication.
After the following functions are configured on an interface, MAC address authentication cannot be configured:
Command | Function |
mac-limit | Sets the maximum number of MAC addresses that can be learned by an interface. |
mac-address learning disable | Disables MAC address learning on an interface. |
port link-type dot1q-tunnel | Sets the link type of an interface to QinQ. |
port vlan-mapping vlan map-vlan port vlan-mapping vlan inner-vlan | Configures VLAN mapping on an interface. |
port vlan-stacking | Configures selective QinQ. |
port-security enable | Configures port security. |
mac-vlan enable | Enables MAC address-based VLAN allocation on an interface. |
ip-subnet-vlan enable | Enables IP subnet-based VLAN allocation on an interface. |
----End
5 User Authentication Troubleshooting Cases
5.1 Authenticated Terminals Cannot Ping a Server
Fault Symptom
A terminal is authenticated, but cannot ping the server.
Possible Causes
After the terminal is authenticated, the ACL authorized to the terminal rejects the server's IP address.
Troubleshooting Procedure
Configure the authorized ACL to permit the server's IP address.
5.2 Users Are Forcibly Disconnected
Fault Symptom
After a terminal passes authentication (not Layer 3 Portal authentication), it is disconnected after a while.
Possible Causes
l The VLAN to which the terminal belongs does not have a VLANIF interface or VLANIF interface address configured. The switch uses the default source IP address (0.0.0.0 or 255.255.2555.255) to send ARP detection packets. Some terminals do not respond to the ARP detection packets with default source IP address. The switch does not receive responses from terminals, so it disconnects the terminals.
l The interval at which the terminal replies to the switch is longer than the ARP detection interval of the switch, so the switch does not receive the response from the terminal. As a result, the switch disconnects the terminal.
Troubleshooting Procedure
Step 1 When the terminal does not respond to the ARP detection packet with the default source IP address, perform the following operation:
Run the access-user arp-detect vlan vlan-id ip-address ip-address mac-address mac-address command to specify the VLAN ID, source IP address, and source MAC address of ARP detection packets.
You are advised to configure the source IP address and source MAC address of ARP detection packets to the user gateway's IP address and MAC address.
Step 2 When the response interval of the terminal is too long, perform the following operation:
Run the authentication timer handshake-period handshake-period command to increase the response interval. If the terminal does not respond to ARP detection packets immediately, the switch can identify the gratuitous ARP packet sent by the terminal. The interval for sending gratuitous ARP packets is not fixed, so increasing the detection interval makes the switch detect the packets more easily.
----End
5.3 802.1x Authentication Troubleshooting Cases
5.3.1 802.1x Users Are Repeatedly Authenticated
Fault Symptom
802.1x users are repeatedly authenticated.
Possible Causes
Reauthentication interval is too short.
Troubleshooting Procedure
In the 802.1x authentication profile view, run either of the following commands:
dot1x timer reauthenticate-period reauthenticate-period-value: increases the reauthentication interval.
undo dot1x timer reauthenticate-period: disables reauthentication.
![]()
Generally, the default reauthentication interval is recommended. If many ACL rules need to be delivered during user authorization, to improve the device processing performance, you are advised to disable reauthentication or increase the reauthentication interval.
5.3.2 After a Network Cable Is Removed and Installed, 802.1x Authentication Fails
Fault Symptom
After a network cable is removed and installed, the authenticated users cannot pass 802.1x authentication.
Possible Causes
After the network cable is removed and installed, the switch considers the STP port Down and discards the EAPOL-Start packet a terminal sent for the first time. Then the EAPOL-Start packet is not sent, causing an 802.1x authentication failure.
Troubleshooting Procedure
Run the dot1x unicast-trigger command to enable unicast packets to trigger 802.1x authentication. When the switch receives an ARP or DHCP request packet from a terminal, it sends a unicast packet to the terminal to trigger authentication.
![]()
In the versions earlier than V200R001, authentication can be triggered by only DHCP packets, but the function is disabled by default.
In V200R002 and V200R003, authentication can be triggered by ARP and DHCP packets, but the function is disabled by default.
In V200R005 and later versions, authentication can be triggered by ARP and DHCP packets, and the function is enabled by default.
5.4 Portal Authentication Troubleshooting Cases
5.4.1 The Portal Server Backup Function Is Invalid
Fault Symptom
Two Portal servers work in active/standby mode. The active/standby Portal servers are also configured in the Portal server template. When the active Portal server is Down, the switch still sends authentication requests to the active Portal server, but not the standby Portal server.
Possible Causes
The Portal server detection is enabled on the switch, but heartbeat is not enabled on the Portal servers. The switch does not receive a heartbeat packet within the detection interval, so it considers the active and standby Portal servers Down. However, the switch still sends authentication requests to the active Portal server.
Troubleshooting Procedure
The Portal server detection function must be enabled on both active and standby Portal servers and the heartbeat function must be enabled on the Portal servers.
Step 1 Check whether Portal server detection is enabled on the switch.
Run the following command to view the Portal server status.
<HUAWEI> display server-detect state web-auth-server abc
Web-auth-server : abc
Total-servers : 4
Live-servers : 1
Critical-num : 0
Status : Normal
Ip-address Status
192.168.2.1 UP
192.168.2.2 DOWN
Run the following command. The Detect field displays the Portal server detection status.
<HUAWEI> display web-auth-server configuration
Listening port : 2000
Portal : version 1, version 2
Include reply message : enabled
------------------------------------------------------------------
Web-auth-server Name : huawei
IP-address :
Shared-key :
Source-IP : -
Port / PortFlag : 50100 / NO
URL : https://192.168.2.10:8443/webauth
URL Template :
Redirection : Enable
Sync : Disable
Sync Seconds : 300
Sync Max-times : 3
Detect : Enable
Detect Seconds : 60
Detect Max-times : 3
Detect Critical-num : 0
Detect Action :
VPN Instance :
Bound Portal profile :
------------------------------------------------------------------
l Enable the Portal server function on the switch.
<HUAWEI> system-view
[HUAWEI] web-auth-server abc
[HUAWEI-web-auth-server-abc] server-detect action log
Step 2 Check whether the heartbeat function is enabled on the Portal servers.
For example, on the Agile Controller, choose Resource > Device > Device Management. Select Enable heartbeat between access device and Portal server on the Add Device page.
![]()
----End
5.4.2 Unauthenticated Portal Users Can Access Network
Fault Symptom
Network access rights are configured for Portal users who fail to be authenticated.
Possible Causes
The Portal survival and Portal server detection functions are enabled on the switch, but heartbeat is not enabled on the Portal servers. The switch does not receive a heartbeat packet within the detection interval, so it considers the active and standby Portal servers Down. The terminal then enters the survival channel to obtain network access rights.
![]()
The Portal survival function requires that the Portal server detection function be enabled on the switch and the heartbeat function be enabled on the Portal servers.
Troubleshooting Procedure
Step 1 Check whether Portal server detection is enabled on the switch.
Run the following command to view the Portal server status.
<HUAWEI> display server-detect state web-auth-server abc
Web-auth-server : abc
Total-servers : 4
Live-servers : 1
Critical-num : 0
Status : Normal
Ip-address Status
192.168.2.1 UP
192.168.2.2 DOWN
Run the following command. The Detect field displays the Portal server detection status.
<HUAWEI> display web-auth-server configuration
Listening port : 2000
Portal : version 1, version 2
Include reply message : enabled
------------------------------------------------------------------
Web-auth-server Name : huawei
IP-address :
Shared-key :
Source-IP : -
Port / PortFlag : 50100 / NO
URL : https://192.168.2.10:8443/webauth
URL Template :
Redirection : Enable
Sync : Disable
Sync Seconds : 300
Sync Max-times : 3
Detect : Enable
Detect Seconds : 60
Detect Max-times : 3
Detect Critical-num : 0
Detect Action :
VPN Instance :
Bound Portal profile :
------------------------------------------------------------------
l Enable the Portal server function on the switch.
<HUAWEI> system-view
[HUAWEI] web-auth-server abc
[HUAWEI-web-auth-server-abc] server-detect action log
Step 2 Check whether the heartbeat function is enabled on the Portal servers.
For example, on the Agile Controller, choose Resource > Device > Device Management. Select Enable heartbeat between access device and Portal server on the Add Device page.
![]()
Step 3 Check the Portal survival right configured on the switch.
<HUAWEI> display portal-access-profile configuration name p1
Profile name : p1
Portal timer offline-detect length: 300
Service-scheme name : s1
Ucl-group name : -
Re-auth : Disable
Network IP Num : 1
Network IP List : 10.1.1.0 255.255.255.0
Web-auth-server Name : abc
Layer : Layer two portal
Bound authentication profile : p1
When the Service-scheme name and Ucl-group name fields display -, survival right is not configured.
To configure the Portal survival right, run the authentication event portal-server-down action authorize { service-scheme service-scheme-name | ucl-group ucl-group-name } command in the Portal authentication profile view.
The network resources that terminals can access in survival state must be pre-defined using the UCL group or service scheme.
----End
5.4.3 A Switch Fails to Connect to a Third-Party Portal Server
Fault Symptom
A switch fails to connect to a third-party Portal server.
Possible Causes
l The switch IP address added to the Portal server is incorrect.
l The shared keys used by the switch and Portal server are different.
l The terminal IP address segment is not within the terminal IP address list on the Portal server.
l The Portal server is configured to send a Request-info packet before authentication is successful.
l The third-party Portal server does not support Huawei Portal protocol.
![]()
Most vendors in China support the Portal protocol, but most vendors outside China do not support it.
Troubleshooting Procedure
l Check whether the switch IP address added to the Portal server is correct.
By default, the source IP address in the packets sent from the switch to Portal server is the IP address of the interface connected to the Portal server (view the source IP address by checking the route to the Portal server address). Alternatively, you can run the source-ip command in the Portal server template view to set the source IP address.
For example, check the access device IP address on the Agile Controller. Choose Resource > Device > Device Management and view the access device IP address on the View Device page.
![]()
l Check whether the shared keys used by the switch and Portal server are the same.
The shared keys are displayed in cipher text on the switch and Portal server, which does not facilitate comparison. You can reset them to ensure their consistency.
To modify the shared key on the switch, run the shared-key cipher key-string command in the Portal server template view.
l Check whether the terminal IP address segment is within the terminal IP address list on the Portal server.
If not, the Portal server does not send a Portal authentication request to the switch after receiving the authentication request from the terminal, and the terminal cannot be authenticated.
For example, on the Agile Controller, choose Resource > Device > Device Management and view the terminal IP address list on the View Device page.
![]()
l Check whether the Portal server is configured to send a Request-info packet before authentication.
The switch can respond to the Request-info packet only after authentication is successful. If a Request-info packet is captured before authentication, modify the configuration on the Portal server.
l Check whether the third-party Portal server supports Huawei Portal protocol.
Confirm with the vendor of the Portal server whether the Portal server supports Huawei Portal protocol. If not, they cannot be connected.
5.4.4 An iOS Terminal Is Automatically Disconnected from the Network After Enabling Wi-Fi
Fault Symptom
This fault occurs on iOS devices but not Android devices. Android devices with Wi-Fi enabled can normally pass Portal authentication and access the WLAN. However, the iOS devices are automatically disconnected.
Possible Causes
The iOS provides the Captive Network Assistant (CNA) function. An iOS device enabled with CNA will automatically connect to a specific website to test the Internet connection after associating with a Wi-Fi hotspot. If the Internet connection fails, a non-Portal authentication page is displayed on the iOS device, asking the end user to enter the account and password for identity authentication. If the user selects Cancel, the iOS device automatically disconnects from Wi-Fi hotspot, so Portal authentication cannot be performed and the user cannot access the network resources in pre-authentication domain.
Troubleshooting Procedure
Configure CNA bypass on the switch so that the switch permits the Internet connection test website used by the iOS devices. Then the iOS devices will not disconnect from Wi-Fi before passing Portal authentication.
[HUAWEI] portal captive-bypass enable
5.5 MAC Address Authentication Troubleshooting Cases
5.5.1 During MAC Address Authentication, a Switch Fails to Connect to a Cisco Server
Fault Symptom
A switch with MAC address authentication configured fails to connect to a Cisco server.
Possible Causes
l The Cisco server requires that the authentication request packets carry RADIUS attribute value 10, but the default value sent by Huawei switch is 2.
l In MAC address authentication, the Huawei switch supports user formats xxxxxxxxxxxx, xxxx-xxxx-xxxx, and xx-xx-xx-xx-xx-xx, Cisco ACS supports only xx-xx-xx-xx-xx-xx, and Cisco ISE supports only xx:xx:xx:xx:xx:xx.
Troubleshooting Procedure
l Run the radius-attribute set command on Huawei switch to change the RADIUS attribute value to 10.
[HUAWEI] radius-server template temp1
[HUAWEI-radius-temp1] radius-attribute set service-type 10
l Add a MAC address authentication user to the Cisco server as a common user.
![]()
If the password check fails, disable password complexity check.
6 FAQ
6.1 Is the NAC Common Mode Applicable to Wireless Users?
Only the unified mode is applicable to wireless users.
6.2 Why 802.1x Authentication and MAC Address Authentication Does Not Take Effect After Being Enabled and the Configuration Is Displayed in the Configuration File?
When ACL resources are used up, 802.1x authentication and MAC address authentication do not take effect.
The following log is recorded if ACL resources are insufficient:
DOT1X/4/ADD_ACL_FAILED:Add ACL failed because of no enough ACL resources.
To view the log, run the display logfile buffer command in the diagnostic view.
7 Appendix
7.1 Collecting Access Authentication Information
If a user fails to go online or offline, or is disconnected unexpectedly, perform the following operations to collect information.
l Run the following command in the diagnostic view to collect information about users going online and offline:
− display aaa offline-record
− display aaa abnormal-offline-record
− display aaa online-fail-record
![]()
The preceding information is dynamically updated. The command displays the latest information. The complete information about going online and offline is recorded in logs.
l Configure service diagnosis to locate the problems during user access.
− Enable service diagnosis.
i. Run the system-view command to enter the system view.
ii. Run the trace enable command to enable service diagnosis.
iii. Run the trace object command to create a diagnostic object.
− Check the configuration of service diagnostic object.
Run the display trace object command to view the configuration of service diagnostic object.
![]()
Service diagnosis affects system performance. Therefore, enable it only when fault locating is required. After locating faults, immediately run the undo trace enable command to disable service diagnosis.
l Run the following command in the user view to collect debugging information:
a. Run the terminal debugging and terminal monitor commands in the user view to enable debugging.
b. Run the following command in the user view to collect debugging information.
n debugging dot1x all
n debugging portal all
n debugging web all
n debugging cm all
n debugging tm all
n debugging sam all
n debugging aaa all
n debugging radius all
n debugging dhcp all
![]()
The dot1x/portal/web are access modules, cm is the core control module, tm/sam is the authorization module, and aaa/radius is the authentication module. Enable the debugging for the modules involved in fault locating. If address allocation is abnormal, enable debugging for the DHCP module. Debugging information includes details about user authentication and disconnection process, and applies to all users.
l Run the following commands in the diagnostic view to collect statistics in NAC modules:
− display tm statistics message
− display tm variable
− display sam message statistics slot-id
− display web statistics [ info | message | packet ]
− display cm statistics { message | user [ detail ] | backup | error | queue }
− display cm cidlist { normal | expand | nac | access-slot slot-id user }
− display cm variable
− display radius statistics { error | message | packet }
− display aaa statistics
![]()
The preceding commands display user behavior. You also need to collect logs on the switch and RADIUS server.
l Check entries related to NAC.
− display access-user: displays user entries.
− display access-user-num: displays number of VAPs.
− display cm item (diagnostic view): displays CM entries.
− display sam cib (diagnostic view): displays SAM entries.
− display web item (diagnostic view): displays temporary web entries.
− display dot1x variable temp-user-tbl (diagnostic view): displays temporary dot1x entries.
− display aaa resource (diagnostic view): displays AAA entries.
l Check eSAP assertions in the diagnostic view.
display srv error-info [ lpu lpu-id | error-id | verbose ] *
l Check the tasks in queue in the diagnostic view.
display message-queue
![]()
The queues related to NAC include AAA, RDSQ, UcmQ, UsaQ, PQ, EapQ, TmQ, WEBQ, BTRC, and PPP. The queues related to DHCP include DHCP and AmQu.
l Collect all diagnostic information.
display diagnostic-information
![]()
To save the diagnostic information in to a txt file, run the display diagnostic-information xx.txt command.
l Collect logs.
save logfile and save diag-logfile (diagnostic view)
![]()
l The log file is in *.log or *.dblg format. When the size of a log file exceeds 8 MB, the system compresses the log file and names the log file saving date.log.zip or saving date.dblg.zip.
l To view the log related to a user with the specified MAC address, run the display logfile flash:/logfile/log.log | include xxxx-xxxx-xxxx command.
7.2 Configuring the 802.1x Clients in Operating Systems
7.2.1 Configuring Wireless 802.1x Authentication
7.2.1.1 Microsoft Windows XP
This section describes how to configure 802.1x authentication parameters on a terminal running the Windows XP operating system before the first wireless 802.1x authentication for the terminal.
Prerequisites
l Windows XP x86 SP1 does not support wireless 802.1x authentication. If a terminal is running this version, upgrade it to Windows XP x86 SP2 or a later version and install the patch WindowsXP-KB918997.
l Choose Start > Settings > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wlan AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
Step 1 Choose Start > Control Panel > Network and Internet Connections > Network Connections.
Step 2 Right-click the WLAN connection and choose Properties.
Step 3 In the dialog box that is displayed, add a WLAN and set the SSID, encryption mode, and authentication mode based on the WLAN parameters provided by the administrator.
![]()
![]()
Step 4 Click the Authentication tab and select PEAP for EAP.
![]()
Step 5 Click Properties and deselect Validate server certificate.
![]()
Step 6 Click Configure and deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
Step 7 When the confirm dialog box is displayed, enter the user name and password for authentication.
----End
7.2.1.2 Microsoft Windows 7
This section describes how to configure 802.1x authentication parameters on a terminal running the Windows 7 operating system before the first wireless 802.1x authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wlan AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
Step 1 Choose Start > Control Panel.
Step 2 On Control Panel, choose Network and Internet > Manage Wireless Networks. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
Step 3 Click Add.
Step 4 Click Manually create a network profile. Set Network name to employee, Security type to WPA2-Enterprise, Encryption type to TKIP, and select Start this connection automatically.
![]()
Step 5 Click Next.
Step 6 Click Change connection settings.
Step 7 Click the Security tab, select Microsoft: Protected EAP (PEAP) from the drop-down list below Choose a network authentication method, and click Settings.
![]()
Step 8 Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
Step 9 Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
Step 10 Click OK to return to the page in Step 7, and then click Advanced settings.
Step 11 Select User or computer authentication from the drop-down list below Specify authentication mode.
![]()
Step 12 Click OK.
Step 13 When the confirm dialog box is displayed, enter the user name and password for authentication.
----End
7.2.1.3 Microsoft Windows 8
This section describes how to configure 802.1x authentication parameters on a terminal running the Windows 8 operating system before the first wireless 802.1x authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wlan AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
Step 1 Choose Start > Control Panel.
Step 2 Click Network and Sharing Center on Control Panel.
Step 3 Click Set up a new connection or network.
![]()
Step 4 In the dialog box that is displayed, double-click Manually connect to a wireless network.
Step 5 Enter a network name, set Security type and Encryption type, click Start this connection automatically, and click Next.
![]()
Step 6 Click Next, and click Change connection settings.
Step 7 On the Security tab page, click Advanced settings.
![]()
Step 8 On the 802.1X settings tab page, select User or computer authentication from the drop-down list below Specify authentication mode, and click OK.
![]()
Step 9 Select Microsoft: Protected EAP (PEAP) from the drop-down list below Choose a network authentication method, and click Settings.
![]()
Step 10 Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
Step 11 Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
Step 12 Double-click the SSID to start 802.1x authentication.
----End
7.2.1.4 iOS
This section describes how to configure 802.1x authentication parameters on a terminal running the iOS operating system before the first wireless 802.1x authentication for the terminal.
Procedure
Step 1 Touch Settings.
Step 2 Touch Wi-Fi.
Step 3 Turn Wi-Fi on to enable the terminal to discover available wireless networks
Step 4 Touch the wireless SSID that requires 802.1X authentication from the SSID list.
Step 5 Enter the user name and password, and then click Join.
The Certificate dialog box is displayed, asking you whether to accept the RADIUS certificate.
Step 6 Click Accept to complete the authentication.
----End
7.2.1.5 Android
This section describes how to configure 802.1X authentication parameters on a terminal running the Android operating system before the first wireless 802.1X authentication for the terminal.
Procedure
Step 1 Touch Settings.
Step 2 Touch Wireless and Networks.
Step 3 Touch WLAN and WLAN Settings. (WLAN is displayed as Wi-Fi on some mobile phones.)
The WLAN Settings page is displayed.
Step 4 Touch the wireless SSID that requires 802.1X authentication from the SSID list.
Step 5 Set the access mode.
l Set EAP method to PEAP.
l Set Phase 2 authentication to MSCHAPV2.
l Set Identity to the user name used for 802.1X authentication.
l Set Password to the password used for 802.1X authentication.
Step 6 Click Connect.
After the authentication succeeds, the Wi-Fi status changes to connected.
----End
7.2.2 Configuring Wired 802.1x Authentication
7.2.2.1 Microsoft Windows XP
This section describes how to configure 802.1x authentication parameters on a terminal running the Windows XP operating system before the first wired 802.1x authentication for the terminal.
Prerequisites
Choose Start > Settings > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wired AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
Step 1 Choose Start > Control Panel > Network and Internet Connections > Network Connections.
Step 2 Right-click the local connection and choose Properties.
Step 3 Click the Authentication tab.
Step 4 Select Enable IEEE 802.1X authentication, set the network authentication method to PEAP, select Cache user information for subsequent connections to this network, and click Settings.
![]()
Step 5 Deselect Validate server certificate, and click Configure.
![]()
Step 6 Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
Step 7 When the confirm dialog box is displayed, enter the user name and password for authentication.
----End
7.2.2.2 Microsoft Windows 7
This section describes how to configure 802.1x authentication parameters on a terminal running the Windows 7 operating system before the first wired 802.1x authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wired AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
Step 1 Choose Start > Control Panel.
Step 2 On Control Panel, choose Network and Internet > Manage Wireless Networks. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
Step 3 Right-click the local connection and choose Properties.
Step 4 Click the Authentication tab.
Step 5 Select Enable IEEE 802.1X authentication, set the network authentication method to PEAP, and click Settings.
![]()
Step 6 Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
Step 7 Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
Step 8 When the confirm dialog box is displayed, enter the user name and password for authentication.
----End
7.2.2.3 Microsoft Windows 8
This section describes how to configure 802.1x authentication parameters on a terminal running the Windows 8 operating system before the first wired 802.1x authentication for the terminal.
Prerequisites
Choose Start > Control Panel, click Administrative Tools and Services, and verify that the Extensible Authentication Protocol and Wired AutoConfig settings are as follows: Startup Type is Automatic and Status is Started.
Procedure
Step 1 Choose Start > Control Panel.
Step 2 On Control Panel, choose Network and Internet > Manage Wireless Networks. (Network and Internet is displayed when you select Category from the View by list on Control Panel.)
Step 3 Right-click the local connection and choose Properties.
Step 4 Click the Authentication tab, select Enable IEEE 802.1X authentication, set the network authentication method to PEAP, and click Settings.
![]()
Step 5 Deselect Validate server certificate, select Secured password (EAP-MSCHAP v2) from the drop-down list below Select Authentication Method, and click Configure.
![]()
Step 6 Deselect Automatically use my Windows logon name and password (and domain if any), and then click OK.
![]()
![]()
If the operating system uses an AD domain account for login and the AD domain account and password are also used for 802.1X authentication, select Automatically use my Windows logon name and password (and domain if any).
----End
This is what I want to talk about/share with you today, thank you!