PPPoE Session Failures: PADI, PADO, PADR and the PPP Stage

PPPoE has two clearly separated stages, and the first diagnostic question is always which one failed. Discovery is a client-server exchange that establishes a session ID and the access concentrator's MAC address; the PPP session stage then runs LCP, authentication and NCP on top of it. This article walks the failure tree from the access concentrator's point of view, which is also the fastest way to debug it from the client side.

Stage 1 - Discovery

1. PADI - the client broadcasts a PPPoE Active Discovery Initiation, optionally naming a service.
2. PADO - every access concentrator that can serve the request replies with an offer. A concentrator that cannot serve the service must stay silent.
3. PADR - the client picks one offer and sends a request to that concentrator's unicast MAC.
4. PADS - the concentrator assigns a unique session ID. A rejection returns a PADS with a service-name error and session ID 0.

! Ethernet types to remember
0x8863  discovery stage
0x8864  PPP session stage

If no PADO arrives, the client retransmits PADI with a doubling interval. On the concentrator, if no PADI is received at all, the causes are narrow: the layer 2 path is broken, the interface is down, the access type is wrong, PPP authentication is not configured, or the virtual template is not bound to the interface.

Stage 2 - LCP Negotiation

debugging ppp lcp packet interface GigabitEthernet0/0/1
display ppp interface
display access-user mac-address 0000-0000-0001

LCP failures usually trace to option mismatch. Watch for Config-Nak or Config-Reject packets: some client implementations do not re-negotiate attributes correctly after a rejection, and others support only PAP while the concentrator insists on CHAP. The practical fix is to align negotiation attributes on both ends, not to disable authentication.

Stage 3 - Authentication

debugging ppp chap packet interface GigabitEthernet0/0/1
debugging ppp pap packet interface GigabitEthernet0/0/1
display aaa online-fail-record

Authentication failures show up as a rejected response after LCP succeeds. Check the username and domain against the local or RADIUS configuration, confirm the password, and look at online-fail-record, which on a BRAS gives the online-fail reason directly - the single most useful command in this workflow.

Stage 4 - NCP and Address Assignment

display this
display ip pool name POOL1
display ip pool name POOL1 used

NCP in PPPoE generally negotiates one thing: the IP address. If it fails, the pool is not bound to the domain, the pool has no free addresses, or the RADIUS-delivered Framed-Pool/Framed-IP attribute is malformed. Note that a Framed-Pool string containing @ or # is truncated at that character - a long-standing trap when the pool name is generated by a provisioning system.

Field Notes

• Duplicate MAC sessions: an existing online user with the same MAC blocks the new attempt; clear the stale session before dialling again.
• MTU: PPPoE adds 8 bytes, so the client interface MTU is normally 1492. Larger values cause fragmentation and stalled large transfers - see MTU mismatch troubleshooting.
• NAT and CGNAT on the client side: MSS clamping frequently required, as described in NAT/PAT overload configuration.
• Where PPPoE sits in a mixed firewall topology, the policy model is the same as any WAN edge - see VyOS firewall and NAT examples.

Where the Failure Lives: Client, Access Network or BRAS

PPPoE failures are reported by the subscriber as "the internet is down", but the conversation has to be narrowed before any command is useful. Each stage of the protocol has a different failure domain, and the stage the process died in tells you where to look:

• No PADI seen anywhere — the client, the CPE, or the Layer 2 path between them. The BRAS has nothing to do with it.
• PADI seen, no PADO sent — the BRAS or the access node: wrong interface, wrong access type, no authentication configured, virtual template unbound.
• PADS sent, PPP never starts — the virtual template, the session limit, or an MTU/MRU negotiation mismatch.
• LCP completes, authentication fails — credentials, domain, RADIUS reachability, or a protocol mismatch between PAP and CHAP.
• Authenticated, no address — the address pool, its binding to the domain, or the RADIUS-delivered Framed-Pool attribute.

This ordering is also the order in which you should clear faults. Skipping straight to RADIUS logs for what is actually a discovery failure is the most common way to waste an hour on a ten-minute problem.

Packet Capture: Reading the Discovery Exchange

Nothing beats seeing the four discovery packets go past. Capture on the client-facing interface or on a mirror port and filter on the two Ethernet types:

! Ethernet types to remember
0x8863  discovery stage
0x8864  PPP session stage

A healthy exchange looks like a broadcast PADI, one or more unicast PADOs from different concentrators, a unicast PADR to the chosen concentrator, and a PADS carrying the session ID. The interesting cases are the ones where a packet is missing or duplicated:

• PADI repeated with doubling timers, no PADO. The concentrator is not answering. Check that the interface is up and that PPPoE is enabled on the correct physical or virtual interface.
• Multiple PADO, no PADR. The client is receiving offers but not selecting one — usually a client-side problem, or a service-name mismatch where none of the offers carries the service the client asked for.
• PADS with session ID 0. The concentrator received the PADR and rejected the request; the PADS carries a service-name error rather than a session.
• PADI arriving from two MAC addresses for the same subscriber. Two CPEs (or a misconfigured bridging setup) fighting for the same account, which will produce a loop of duplicate MAC sessions.

Stage 1 in Depth: Discovery Failure Modes

If no PADI is received at all on the concentrator, the causes are narrow and all of them are local to the access side:

• Layer 2 path broken — the VLAN between the access node and the BRAS is not passing PPPoE frames, or a QinQ configuration is pushing the traffic into the wrong S-VLAN.
• Interface down — physica or logical, including a sub-interface that exists but has no link.
• Access type wrong — the interface is not configured as PPPoE; a mismatch between where PPPoE is enabled and where the subscriber actually arrives.
• PPP authentication not configured — PPPoE discovery proceeds but the BRAS is not willing to serve the service. This shows up as a conspicuously silent concentrator.
• Virtual template not bound — the highest-value check in this list, because the interface can be up, the VLAN correct, and authentication configured, and still nothing is served because no virtual template is attached to the interface.

On the client side, the mirror-image checks are whether PPPoE is enabled on the correct WAN interface, whether the service name in the client configuration matches something the concentrator offers, and whether the client is sending PADI on the right VLAN. Most consumer CPEs dial PPPoE untagged; a provider network expecting VLAN tagging requires the VLAN to be configured on the CPE, and the symptom is indistinguishable from a dead line until you look at the capture.

Stage 2 in Depth: LCP Options and Negotiation

LCP negotiates the link parameters before any authentication happens: MRU, authentication protocol, magic number, and option negotiation behaviour. Failures leave traces that are easy to read once you know what to look for.

debugging ppp lcp packet interface GigabitEthernet0/0/1
display ppp interface
display access-user mac-address 0000-0000-0001

• Config-Nak. The peer proposes a value we will not accept and we suggest another. A normal part of negotiation; only a repeating loop of Naks matters.
• Config-Reject. The peer does not support an option we sent. Some client implementations do not re-negotiate correctly after a rejection and simply retry the same rejected option forever.
• Authentication protocol mismatch. The client supports only PAP while the concentrator insists on CHAP, or the reverse. The correct fix is to align the negotiated protocol on both ends, not to disable authentication — disabling it leaves the subscriber account effectively open on the access network.
• MRU mismatch. A client proposing an MRU above what the path can carry produces a link that comes up and then stalls on the first large transfer.

The practical approach with a stubborn client is to align the attributes deliberately — set the authentication protocol explicitly rather than leaving it to negotiation — and confirm with a packet capture that the LCP exchange terminates in a Configure-Ack rather than a loop.

Stage 3 in Depth: Authentication Failure Record

debugging ppp chap packet interface GigabitEthernet0/0/1
debugging ppp pap packet interface GigabitEthernet0/0/1
display aaa online-fail-record

Authentication failure is easy to identify: LCP completes, then the exchange ends with a rejection rather than proceeding to NCP. Check the username and the domain suffix against the local or RADIUS configuration, confirm the password, and then read display aaa online-fail-record. On a BRAS this command gives the online-fail reason directly and is the single most useful command in the whole workflow — it names the reason instead of leaving you to infer it from packet counters.

Common reasons behind the record: the account is disabled or expired, the domain is not bound to an authentication scheme on the BRAS, the RADIUS server is unreachable and the local fallback has no matching user, or the password has been changed on the provisioning system and not on the subscriber's CPE. A useful discipline is to check the record before reading any packet capture at all — it saves the capture entirely in most cases.

Stage 4 in Depth: NCP and Pool Behaviour

display this
display ip pool name POOL1
display ip pool name POOL1 used

NCP in PPPoE generally negotiates one thing: the IP address. When it fails, the cause is almost always one of four things:

• The pool is not bound to the domain. The subscriber authenticates against a domain that has no address pool associated, so the BRAS has nothing to hand out.
• The pool is exhausted. display ip pool name POOL1 used names the state in one line. A pool that is fully allocated with stale sessions is worse than one that is empty, because the sessions look active.
• The RADIUS attribute is malformed. A Framed-Pool or Framed-IP attribute that the BRAS cannot parse is treated as no attribute at all, or as an error.
• Framed-Pool truncation. A pool name containing @ or # is truncated at that character. This is a long-standing trap when the pool name is generated by a provisioning system that assumes those characters are safe.

There is also a subtle case where NCP succeeds and the subscriber still has no connectivity: the address is assigned, but it is from the wrong pool with no route out, or the subscriber's CPE applies a smaller MTU than the negotiated one and breaks on large packets. That belongs to the client-side section below.

Client-Side Checks on the CPE

Half of the tickets originate at the CPE, and the credential check is the one people skip. A PPPoE client that keeps dialling and failing with an authentication error after a password change is the most common single fault on a residential access network.

• Credentials and domain suffix. Confirm that the CPE username includes the domain if the provider requires one.
• MTU. PPPoE adds 8 bytes of overhead, so the client interface MTU is normally 1492 rather than 1500. Larger values cause fragmentation and stalled large transfers — see MTU mismatch troubleshooting.
• MSS clamping. NAT and CGNAT on the client side frequently require MSS clamping so that TCP peers do not silently drop oversized segments, as described in NAT/PAT overload configuration.
• Duplicate sessions. An existing online user with the same MAC blocks the new attempt. Clear the stale session before dialling again, otherwise every retry fails for the same reason and the log fills with identical lines.
• Keepalive and dial-on-demand settings. Aggressive redial timers on the CPE can produce a stream of half-open sessions that exhaust the pool rather than the subscriber's patience.

Where PPPoE terminates at a firewall rather than a dedicated BRAS, the policy model is the same as any WAN edge, and the interface and zone design follows the same rules as VyOS firewall and NAT examples. Tunnel-based fallback designs have their own failure modes; the MTU and handshake problems there are catalogued in WireGuard MTU and handshake failures.

Worked Cases

• Case: PADI floods the log, no PADO ever sent. The virtual template was not bound to the subscriber interface. Binding it restored service without any credential or RADIUS change.
• Case: every subscriber in one village drops at once. Not a credentials problem — a misconfigured QinQ mapping sent the VLAN to the wrong S-VLAN. The tell was that failures started simultaneously rather than one subscriber at a time.
• Case: one subscriber loops on authentication. A password change on the provisioning system had not been reflected on the CPE. display aaa online-fail-record named the reason immediately.
• Case: sessions establish but large downloads stall. MTU left at 1500 on the client. Reducing to 1492 with MSS clamping fixed every site issue at once.
• Case: pool exhausted at peak. Stale sessions from a CPE that reconnects without releasing. Reducing the session timeout and fixing the client's redial behaviour reclaimed the addresses.

Quick Reference and FAQ

! Useful PPPoE and BRAS commands, in diagnostic order
display access-user mac-address 0000-0000-0001
debugging ppp lcp packet interface GigabitEthernet0/0/1
debugging ppp chap packet interface GigabitEthernet0/0/1
display aaa online-fail-record
display ip pool name POOL1 used
display ppp interface

• How long should discovery take? Sub-second on a healthy access network. A delay in the seconds range means retransmission, which means something is dropping the PADI or the PADO.
• Should I disable authentication to rule it out? No. Align the negotiated protocol on both ends instead; disabling authentication on an access network is a security change, not a diagnostic step.
• Why do some clients show an address but no traffic? Usually MTU or MSS. Check the negotiated MRU against the path MTU before suspecting the pool.
• Can one account have two simultaneous sessions? It depends on the BRAS configuration, but the default in most deployments is to reject the second attempt for the same MAC, which is why stale session handling matters.
• What is the fastest single command on a BRAS? display aaa online-fail-record. It names the failure instead of requiring you to infer it from a capture.

原文链接：https://support.huawei.com/enterprise/en/doc/EDOC1100280260/dad4ae69/troubleshooting-pppoe-user-login-failures