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


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

Knowledge Base

Authentication to the PPPOE server failed after the PPPOE is established

Publication Date:  2019-07-22  |   Views:  1042  |   Downloads:  0  |   Author:  m84068533  |   Document ID:  EKB1001289214


Issue Description

Fault symptom: Customer needed to know why, on his working VDSL line, after the PPPOE Request message, sent by the AR169, has been answered by the Cxx server, the authentication is verified and the session should start up, but then it stops and everything starts over again.

Version information: V200R008C50SPC500
Networking overview:
Customer needed to test, with 2 AR169 routers, a fallback scenario between the fixed VDSL line and the 4G and he encountered an issue with the PPPOE over VDSL line.

Handling Process

1. Customer informed us that, after the VDSL line gets synchronized, the AR169 sends a PPPoE Request message that is being answered to, by the Cxx PPPOE server, but then the

authentication is verified by the Cxx Server and the PPPOE session stops and the whole PPPOE process starts over again.

Configuration on the AR169:

interface Dialer3
link-protocol ppp
ppp authentication-mode pap
ppp chap user test@xxx
ppp chap password
cipher XXXXX

ppp pap local-user XX@XXX password simple XXX
ppp ipcp dns admit-any
ppp ipcp dns request
tcp adjust-mss 1200
ip address ppp-negotiate
dialer user XXX@XX
dialer bundle 3
dialer-group 3

interface Ethernet0/0/0.6
pppoe-client dial-bundle-number 3

mtu 1472
description XXXX
dot1q termination vid 6
dot1q vrrp vid 6


2. In order to check the PPPOE process establishment and the PPPOE configuration from the AR169 device, we requested the following information from customer:

- the AR169 diagnostic information, when the VDSL line was connected;
- the output of the following commands, collected when PPPOE client tries to connect: “<Huawei> debugging ppp all” and “<Huawei> debugging pppoe-client all”;
- the same debugging information from the peer device, collected at the same time as that from the AR device;
- the VDSL logs, collected when the problem is reproduced;
- the configuration from the peer device.

3. After analyzing the debugging information, from the AR device, we could observe that the PPPOE was established and then, the PPPOE server sent a Terminate Request.  Therefore, we informed the customer that we would also need the configuration from the Cxx server,  that he didn’t provide at the beginning.
“Dec 21 2017 20:24:03.919.7+01:00 XXXX PPP/7/debug2:

PPP State Change:
Dialer3:0 PAP : SendRequest --> ClientSuccess
Dec 21 2017 20:24:03.919.8+01:00 XXXX PPP/7/debug2:
PPP Packet:
Dialer3:0 Input LCP(c021) Pkt, Len 8
State opened, code TermReq(05), id 4, len 4”
We also recommended customer to undo the PPPOE client configuration existing on the physical Ethernet0/0/0 interface, in order to make sure that there is only one PPPOE client having that MAC address, connected to the same PPPOE server – as the “pppoe-client dial-bundle-number 3” configuration already existed under sub-interface Ethernet0/0/0.6:
interface Ethernet0/0/0
undo pppoe-client dial-bundle-number 1

4. Customer removed the dialer configuration from the Ethernet 0/0/0, informed us that he was using a Cxx ASR1006 as PPPoE server and provided the configuration from this device. The PPPOE connection terminates on the following subinterface:

interface TenGigabitEthernet0/1/0.470

description XXXXX
encapsulation dot1Q 470
pppoe enable group casper-test
pppoe max-sessions 500
service-policy input AccessArea-QoS-in
service-policy output


bba-group pppoe casper-test
virtual-template 4

vendor-tag circuit-id service
vendor-tag remote-id service
sessions per-mac iwf limit 500
sessions per-vlan limit 1000
tag ppp-max-payload minimum 1500 maximum 4470
pado delay 20

interface Virtual-Template4

description XXXX

ip unnumbered Loopback8001
ip verify unicast source reachable-via rx
ip tcp adjust-mss 1452
ipv6 mtu 1280
no ipv6 nd prefix framed-ipv6-prefix
ipv6 nd other-config-flag
no ipv6 nd ra suppress
ipv6 dhcp server UNET rapid-commit
ipv6 verify unicast source reachable-via rx
no peer default ip address
ppp lcp echo mru verify
ppp authentication pap pppoa-unet
ppp authorization pppoa-unet
ppp accounting pppoa-unet
ppp ipcp dns X.X.32.32 X.X.32.33
ppp multilink
ppp multilink links maximum 4
5. After checking the configuration existing on the Cxx device, we can see that Cxx server will only accept and verify the authentication from PPPOE client, but should not start
the authentication towards the PPPO -client. The authentication process must be only initiated by the AR169 device towards the PPPOE server, that’s why, the “ppp authentication pap” should exist only on the server – the authenticator, not also on the client device. On the client device, is enough to configure the user details.
Therefore, our recommendation was, on the AR device, to undo the command “ppp authentication-mode pap” under interface Dialer3 and the solution worked for customer.


Advised customer to undo the command “ppp authentication-mode pap” under interface Dialer3 on the AR 169 device and the PPPOE connection worked correctly.