Troubleshooting PPPoE User Login Failures

This document describes how to troubleshoot failures in logging in to an NE40E in typical PPPoE user access scenarios.

The PPPoE user login process involves two stages: PPPoE negotiation and PPP negotiation. PPP negotiation includes:

• Link Control Protocol (LCP) negotiation
• Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) authentication
• Network Control Protocol (NCP) negotiation

If a user login attempt fails, check the failure cause first. Then, examine the PPPoE access configuration based on the failure cause and determine the phase that caused the user login failure. Figure 1-5shows the details of the process.

1. Run the display aaa online-fail-record command to check user login failure records.

   <HUAWEI> display aaa online-fail-record username test@huawei  
    -------------------------------------------------------------------  
    User name          : test@huawei  
    User MAC           : 00e0-fc12-3456  
    User access type : PPPoE  
    User interface     : Atm4/0/2  
    User Pe Vlan       : 99  
    User Ce Vlan       : 99  
    User IP address : -  
    User ID            : 233  
    User authen state  : Authened  
    User acct state : AcctIdle  
    User author state  : AuthorIdle  
    User login time : 2009-09-04 15:14:14  
      Online fail reason : PPP with authentication fail  
    ------------------------------------------------------------------- 

   The Online fail reason field displays the cause of the user login failure. You can roughly locate the fault based on the cause to facilitate troubleshooting. The following table lists common causes of PPPoE user login failures.

   Table 1-1 Common causes of PPPoE user login failures

   Cause Reported in Failure Record	Description
   PPP with authentication fail	PPP user authentication failed.
   IP address alloc fail	IP address assignment failed.
   IP address conflict	An IP address conflict occurred.
   mac address conflict	A MAC address conflict occurred.
   Start accounting fail	Accounting failed to start.
   Domain or user access limit	The number of access users in a domain or the number of users using the same accounting exceeded the limit.
   Port access limit	The number of users accessing an interface exceeded the limit.
   PPP negotiate fail	PPP negotiation failed.
   Send authentication request fail	An authentication request failed to be sent.
   RADIUS authentication reject	RADIUS authentication was denied.
   RADIUS authentication send fail	A RADIUS authentication request failed to be sent.
   Local authentication reject	Local authentication was denied.
   Local authentication no user	A local user failed to be found.
   Local Authentication user type not match	The account type of a local user did not match the account type in the local authentication database.
   Local Authentication user block	The local account was not activated.

   • If a user's login failure record is returned, check the associated configuration based on the login failure cause displayed in the Online fail reason field. If the fault cannot be preliminarily located, go to step 3.
   • If a user's login failure record is not returned, the user did not request to go online. This indicates that the PPPoE link failed to be set up. In this case, go to step 2.
2. Check that the user is not blocked.

   Run the display ppp [ slot slot-number ] chasten-user [ [ mac-address mac-address ] | [ option105 [ circuit-idcircuit-id ] [ remote-id remote-id ] ] ] command in the system view to check whether the user is blocked.

   Using a MAC address of 00-e0-fc-12-34-56 as an example, the possible outputs are as follows:

   • If the user is blocked, the following information will be displayed. In this case, dial up again later in accordance with the displayed information.

     <HUAWEI> system-view 
     [~HUAWEI] display ppp slot  
      ------------------GLOBAL PPP CHASTEN USERS SLOT 1 ---------------------  
     (1):MAC 00e0-fc12-3456 Option105(circuitid:123 remoteid:abcde) will be free after 55s (online-fail)    
     ------------------PPPOE VLAN CHASTENUSERS SLOT 1 --------------------- 
     No User is blocked

   • If the user is not blocked, the following information will be displayed. In this case, go to step 3.

     <HUAWEI> system-view 
     [~HUAWEI] display ppp slot   
     ------------------GLOBAL PPP CHASTEN USERS SLOT 1 ---------------------         
      00-e0-fc-12-34-56 is not block                                                     
     ------------------PPPOE VLAN CHASTENUSERS SLOT 1 ---------------------         
      00-e0-fc-12-34-56 is not block                                                 

3. Check service tracing information.

   Run the trace enable command to enable service tracing and run the trace access-user command to create service tracing objects. Then, run the terminal debugging and terminal monitor commands to enable debugging information display on the NE40E. Simulate a user attempting to go online. After the user login process is complete, check the service tracing information.

   • If the NE40E receives no PADI or PADR packet, check whether the following conditions are met:
     • The Layer 2 network is reachable.
     • The interface status is normal.
     • The access type is Layer 2 subscriber access.
     • PPP authentication is configured on the NE40E.
     • A virtual template (VT) is bound to the interface.
   • If no service tracing information is displayed, the user has not sent any packets to the NE40E. In this case, go to step 5.
   • If the NE40E receives PADI and PADR packets, run the display access-user mac-address [ mac-address ] command to check whether a user with the specified MAC address has gone online.
     • If no MAC address conflict occurs, PPPoE negotiation is successful, but PPP negotiation may have failed. In this case, go to step 4.
     • If a MAC address conflict occurs, a user with the specified MAC address has gone online through the interface. Check whether an online user in another VLAN can be logged out. If the user can be logged out, log out the user. Then, dail up again for login.
4. Check that the NE40E is working properly.

   If no service tracing information is displayed, ensure that the following conditions are met:

   • Devices are correctly connected at the physical layer.
   • The Layer 2 network is correctly configured.

     If the fault persists, go to step 5.

5. Check that LCP negotiation is successful.

   Run the debugging ppp lcp packet interface command to enable debugging of LCP PPP packets. Check the Config-Nak or Config-Reject packets to locate the options that were rejected or failed to be identified. Common causes are as follows:

   1. Some PPPoE clients do not implement PPP in compliance with PPP standards. Specifically, after such a PPPoE client sends a Config-Request packet and the NE40E responds with a Config-Nak or Config-Reject packet, the client fails to modify attribute values or add/delete attributes in the Config-Request packet. In this case, modify the associated negotiation attributes to be consistent between devices.
   2. CHAP authentication is configured on the NE40E, but the client supports only PAP authentication. As a result, LCP negotiation fails, causing a user login failure. In this case, modify the authentication protocols to be consistent between devices.

   If the user still fails to go online after LCP negotiation succeeds, go to step 6.

6. Check that user authentication is successful.

   Run the debugging ppp chap packet interface or debugging ppp pap packet interface command to enable debugging of CHAP or PAP packets and check whether the NE40E responds with a success message after receiving a response packet.

   • If a success message is returned, the authentication is successful. In this case, go to step 7.
   • If no success message is returned, check whether the username and domain carried in the user login request are the same as those on the NE40E or the remote authentication server configured on the NE40E.
     • If the configurations are the same, go to step 9.
     • If the configurations are different, modify them to be consistent.
7. Check whether NCP negotiation is successful.

   In PPPoE stages, NCP generally negotiates only IP addresses. If NCP negotiation fails, address negotiation fails.

   Check IP address assignment:

   • If IP addresses are assigned locally:

     Run the display this command in the domain view to check whether the involved address pool is bound to the domain. Run the display ip pool name command to check whether the address pool has any idle IP addresses.

     If the address pool is delivered by the RADIUS server, the Framed-Pool attribute (RADIUS attribute 88) must be delivered in the correct format. If the delivered character string contains an at sign (@) or a number sign (#), only the part before either of the two signs is used as the address pool name. The specified address pool needs to have been configured on the NE40E.

   • If IP addresses are assigned by a RADIUS server:

     Check whether the value of the Framed-IP-Address attribute (RADIUS attribute 88) in RADIUS authentication response packets is correct.

     If IP addresses on a network segment from 224.0.0.0/8 to 255.0.0.0/8the value of the Framed-IP-Address attribute is one of the following, the delivered IP addresses are considered invalid and are discarded:

     • 0
     • 0XFFFFFFFE or 0XFFFFFFFF
     • IP addresses on the network segment 127.0.0.0/8
     • IP addresses on a network segment from 224.0.0.0/8 to 255.0.0.0/8

     If the RADIUS server does not deliver the Framed-IP-Address attribute, IP addresses are assigned from a local address pool bound to the domain.

   • If the NE40E functions as a DHCP client to apply for IP addresses from a DHCP server and IP addresses fail to be assigned, check whether the following conditions are met:
     • The DHCP server group is properly configured on the NE40E and bound to an address pool.
     • The NE40E and the DHCP server are reachable to each other.
     • The DHCP server works properly.
     • IP addresses assigned by the DHCP server are valid.
     • The assigned IP addresses are within the range of the NE40E's address pool.
     • The mask is the same as the mask that is configured for the address pool on the NE40E.
     • Whether the assigned IP addresses conflict with those of online users.
8. Locate the accounting fault.

   If user login failure still occurs after IP addresses are properly assigned, the problem may be that accounting has failed. The most common accounting failure is the accounting start failure.

   The NE40E does not support local accounting. The accounting modes that the NE40E supports are RADIUS accounting, HWTACACS accounting, and none accounting. If none accounting is used, accounting failures will not occur.

   NOTE:

   If RADIUS or HWTACAS accounting fails, the NE40E saves newly generated CDRs locally. After the accounting server recovers, the NE40E sends the locally saved CDRs to the accounting server. If the local CDR pool is full but the accounting server has not recovered, newly generated CDRs are lost.

9. If the fault persists, contact Huawei technical support.

A PPPoE user login failure may be caused by a fault in the authentication domain, IP address pool, VLAN, RADIUS server, binding between a VT and an interface, or authentication protocol. If the fault cannot be preliminarily located, go through the PPPoE negotiation and PPP negotiation stages to determine the stage in which the fault occurred. Then, take corresponding troubleshooting measures to locate the fault.

For more information about PPPoE access, see NE40E V800R011C00SPC200 Product Documentation 01.