No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Troubleshooting PPPoE User Login Failures

This document describes how to troubleshoot login failures of PPPoE users.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Troubleshooting PPPoE User Login Failures

Troubleshooting PPPoE User Login Failures

Introduction

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

Understanding the PPPoE User Login Process

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

PPPoE Negotiation

In PPPoE negotiation, a device assigns a session ID for PPPoE user access, uniquely identifying a PPPoE virtual link between the user and the device. The PPPoE negotiation process is as follows:

  1. A user broadcasts a PPPoE Active Discovery Initiation (PADI) packet indicating the service that the user is requesting.
  2. Upon receiving the PADI packet, all access concentrators (NE40Es, in the context of this document) on the Ethernet network compare the requested service against the services they offer. Then, the NE40Es that can provide the requested service reply with a PPPoE Active Discovery Offer (PADO) packet.
  3. The user may receive more than one PADO packet. The user looks through the received PADO packets and chooses one that meets specified conditions. The user then sends a PPPoE Active Discovery Request (PADR) packet indicating the requested service to the selected NE40E.
  4. After receiving the PADR packet, the selected NE40E prepares to begin a PPP session. It generates a unique session ID for the PPPoE session and replies to the user with a PPPoE Active Discovery Session-confirmation (PADS) packet carrying the session ID. If no errors occur during the sending and receiving of the PADS packet, the NE40E and the user enter the PPP Session stage.
Figure 1-1 PPPoE negotiation process

PPP Negotiation

PPP negotiation includes LCP negotiation, PAP or CHAP authentication, and NCP negotiation. The PPP negotiation process is as follows:

  1. During LCP negotiation, the maximum receive unit (MRU), negotiation timeout period, and LCP link dead duration are negotiated.
  2. Either PAP or CHAP authentication is performed:
    • PAP uses a two-way handshake to verify the identity of the peer on a P2P link. It transmits a username and password pair in plaintext, and therefore is applicable to environments with low security requirements.
    • CHAP uses a three-way handshake to verify the identity of the peer. It transmits usernames but not passwords, so it is more secure than PAP.
  3. NCP negotiates network-layer parameters in PPP packets through IP Control Protocol (IPCP) or IPv6 Control Protocol (IPv6CP). IPCP is the most widely used protocol. PPPoE users mainly use IPCP to obtain IP addresses or IP address segments for network access.
Figure 1-2 PPP negotiation

Network Structures

There are two options for PPPoE network structure, depending on the start and end points of PPPoE sessions.

  • Figure 1-3shows the first option. A PPP session is set up between the CPE and NE40E. All hosts transmit data through the same PPP session. The CPE, located inside an enterprise or company, functions as a PPPoE client. The NE40E functions as a PPPoE server. No PPPoE client dial-up software needs to be installed on the hosts. The hosts, which are users in an enterprise or company, share one account.
Figure 1-3 PPPoE networking 1

  • Figure 1-4 shows the second option. A PPP session is established between each host and the carrier device (NE40E). Each host is a PPPoE client, and the NE40E is a PPPoE server. Each host has an account for access control and accounting. Each host must have the PPPoE client dialup software installed to function as a PPPoE client. This network structure is suitable for campuses and residential areas.
Figure 1-4 PPPoE networking 2

Troubleshooting Flowchart

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.

Figure 1-5 Flowchart for troubleshooting PPPoE user login failures

Troubleshooting Procedure

  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.

Troubleshooting Summary

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.

Related Information

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

Translation
Download
Updated: 2019-08-31

Document ID: EDOC1100092120

Views: 417

Downloads: 22

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next