PPPoE Client Configuration
Most broadband ISP connections — ADSL, VDSL, and fibre services delivered over an Ethernet handoff — use PPPoE (Point-to-Point Protocol over Ethernet) to authenticate each subscriber session before granting internet access. PPP provides the username/password authentication layer (CHAP or PAP) and IP address assignment that plain Ethernet lacks; the Ethernet encapsulation carries PPP frames across the ISP's access network to the BRAS (Broadband Remote Access Server). A Cisco IOS router acting as a PPPoE client must create a virtual dialer interface that holds the PPP session, bind it to the physical Ethernet port facing the modem, authenticate with the ISP credentials, and obtain a WAN IP address — either statically assigned or negotiated via IPCP.
Understanding PPPoE builds directly on PPP concepts. For the broader WAN context see WAN Technologies. For the NAT/PAT configuration that almost always follows a PPPoE setup to share the single WAN IP with inside hosts, see Dynamic NAT & PAT Configuration and for diagnosing NAT problems see Troubleshooting NAT/PAT Issues. For securing management access to the router once the WAN is live, see SSH Configuration.
1. PPPoE Architecture — Core Concepts
How PPPoE Works End-to-End
PPPoE operates in two distinct phases before any IP traffic flows. Understanding these phases explains every command in the configuration and every field in the verification output:
Phase 1 — PPPoE Discovery (Layer 2 — Ethernet frames)
──────────────────────────────────────────────────────
Client router sends PADI (PPPoE Active Discovery Initiation)
│ broadcast — "Is there a PPPoE Access Concentrator?"
▼
ISP BRAS responds PADO (PPPoE Active Discovery Offer)
│ "Yes, I am AC 'ISP-BRAS-1', session ID pending"
▼
Client sends PADR (PPPoE Active Discovery Request)
│ "I want to connect to AC 'ISP-BRAS-1'"
▼
ISP sends PADS (PPPoE Active Discovery Session-confirmation)
│ "Session ID = 0x0042 — discovery complete"
▼
Session tunnel established at Layer 2
Phase 2 — PPP Negotiation (inside the PPPoE tunnel)
──────────────────────────────────────────────────────
LCP (Link Control Protocol) — negotiate MTU, auth method (CHAP/PAP)
│
▼
Authentication — CHAP 3-way challenge or PAP username/password
│ ISP RADIUS server validates credentials
▼
NCP / IPCP (IP Control Protocol) — negotiate IP address assignment
│ Router receives WAN IP from ISP (ip address negotiated)
▼
PPPoE session UP — IP traffic can flow
PPPoE Key Terminology
| Term | Definition | IOS Relevance |
|---|---|---|
| BRAS | Broadband Remote Access Server — the ISP device that terminates PPPoE sessions and authenticates subscribers | The peer your router connects to; also called an Access Concentrator (AC) |
| Dialer interface | A virtual interface on the Cisco router that holds the PPP session — it receives the negotiated IP address and carries all routed traffic | interface Dialer1 — configured with IP, authentication, and PPPoE pool membership |
| Dial pool | A numbered pool that links a physical Ethernet port to one or more dialer interfaces | pppoe-client dial-pool-number 1 on the physical port; dialer pool 1 on the dialer interface |
| CHAP | Challenge Handshake Authentication Protocol — the ISP sends a challenge; the router responds with an MD5 hash of the password. More secure than PAP; password never sent in plaintext | ppp chap hostname and ppp chap password |
| PAP | Password Authentication Protocol — the router sends username and password in plaintext. Less secure; use only when ISP requires it | ppp pap sent-username and ppp pap password |
| ip address negotiated | The router obtains its WAN IP from the ISP via IPCP (IP Control Protocol) during PPP negotiation rather than using a static address | Most common broadband scenario — ISP assigns a dynamic WAN IP per session |
| MTU / MRU | PPPoE adds an 8-byte header to each Ethernet frame, reducing the effective payload MTU from 1500 to 1492 bytes | ip mtu 1492 and ip tcp adjust-mss 1452 on the dialer — critical to prevent fragmentation |
PPPoE Interface Roles
| Interface | Role | IP Address | Key Commands |
|---|---|---|---|
| GigabitEthernet0/0 (physical) | Physical Ethernet port connected to DSL modem or ISP CPE — carries PPPoE Ethernet frames | No IP address — PPPoE operates at Layer 2 on this interface | no ip address, pppoe-client dial-pool-number 1, no shutdown |
| Dialer1 (virtual) | Virtual PPP interface — holds the session, IP address, authentication credentials, and routing context | Negotiated from ISP via IPCP (ip address negotiated) or static |
encapsulation ppp, dialer pool 1, ip address negotiated, ppp chap |
2. Lab Topology & Scenario
192.168.10.0/24 (LAN)
[PC1: 192.168.10.10]
[PC2: 192.168.10.11]
│
Gi0/1 (LAN)
192.168.10.1/24
│
NetsTuts_R1 (Cisco IOS PPPoE Client)
│
Gi0/0 (WAN — no IP, PPPoE enabled)
│ Ethernet — PPPoE frames
DSL Modem / ISP CPE
│
ISP BRAS / Access Concentrator
WAN IP assigned: 203.0.113.45/30 (example)
ISP Gateway: 203.0.113.46
ISP PPPoE Credentials:
Username: [email protected]
Password: P@ssw0rd!
Auth: CHAP (primary), PAP (fallback)
Objectives:
1. Configure Gi0/0 as the PPPoE-enabled physical port
2. Create Dialer1 with CHAP credentials and negotiated IP
3. Configure NAT overload so LAN hosts share the WAN IP
4. Add a floating default route via the dialer
5. Verify with show pppoe session and show ip interface dialer1
3. Step 1 — Configure the Physical WAN Interface
The physical Ethernet interface that faces the ISP modem carries raw PPPoE Ethernet frames. It must have no IP address — all IP configuration lives on the dialer interface. It must be up and bound to a dial pool so the PPPoE discovery process can initiate:
NetsTuts_R1>en NetsTuts_R1#conf t Enter configuration commands, one per line. End with CNTL/Z. ! ── Physical WAN port — no IP, bound to dial pool 1 ────── NetsTuts_R1(config)#interface GigabitEthernet0/0 NetsTuts_R1(config-if)#description ISP-Modem-Uplink NetsTuts_R1(config-if)#no ip address NetsTuts_R1(config-if)#pppoe-client dial-pool-number 1 NetsTuts_R1(config-if)#no shutdown NetsTuts_R1(config-if)#exit
pppoe-client dial-pool-number 1 is the link between the
physical port and the dialer interface. It tells IOS to initiate
PPPoE discovery frames out of Gi0/0 and to hand the resulting session
to whichever dialer interface is a member of dial pool 1. The physical
interface must be no shutdown for the modem link to be
active — without this the PPPoE PADI broadcast is never sent and
discovery never starts. The description is optional but valuable for
identifying the port in show interfaces output.
4. Step 2 — Configure the Dialer Interface
The dialer interface is where the PPP session, authentication
credentials, IP address negotiation, and MTU settings all live.
It is the interface IOS uses for routing — default routes point
to Dialer1, NAT is applied to it, and it appears in
show ip interface brief with the WAN IP once the
session is established:
! ── Dialer interface — virtual PPP endpoint ────────────── NetsTuts_R1(config)#interface Dialer1 NetsTuts_R1(config-if)#description PPPoE-WAN-Session NetsTuts_R1(config-if)#encapsulation ppp NetsTuts_R1(config-if)#dialer pool 1 NetsTuts_R1(config-if)#ip address negotiated NetsTuts_R1(config-if)#ip mtu 1492 NetsTuts_R1(config-if)#ip tcp adjust-mss 1452 NetsTuts_R1(config-if)#ip nat outside NetsTuts_R1(config-if)#no shutdown NetsTuts_R1(config-if)#exit
Each command has a specific role.
encapsulation ppp
sets the interface to use PPP framing inside the PPPoE tunnel.
dialer pool 1 joins this virtual interface to pool 1,
which Gi0/0 also references — this is the binding that connects
the physical and virtual sides. ip address negotiated
tells IPCP to request an IP from the ISP rather than using a
static address. ip mtu 1492 reduces the IP MTU from
the Ethernet default of 1500 to 1492 to account for the 8-byte
PPPoE header — without this, packets at exactly 1500 bytes are
fragmented or silently dropped, causing intermittent large-packet
failures. ip tcp adjust-mss 1452 clamps the TCP
Maximum Segment Size in SYN packets so that TCP connections
never negotiate a segment size that would produce fragments — this
is the recommended companion to ip mtu 1492.
5. Step 3 — Configure CHAP and PAP Authentication
ISP authentication credentials are configured on the dialer interface. CHAP is preferred — the password is never sent in plaintext. PAP sends credentials in cleartext and should only be used when the ISP explicitly requires it. Many ISPs accept both; configure CHAP first with PAP as a fallback:
CHAP Authentication (Preferred)
NetsTuts_R1(config)#interface Dialer1 NetsTuts_R1(config-if)#ppp authentication chap callin NetsTuts_R1(config-if)#ppp chap hostname [email protected] NetsTuts_R1(config-if)#ppp chap password 0 P@ssw0rd! NetsTuts_R1(config-if)#exit
ppp authentication chap callin instructs the router
to authenticate using CHAP only when calling in (initiating
the connection as a client). Without callin, IOS also
tries to challenge the ISP for its credentials — which ISPs never
support and which causes the session to fail. The keyword
callin is essential for client-side PPPoE.
ppp chap hostname sets the identity the router presents
in CHAP — this is typically the ISP-issued username (often in
email format). The 0 before the password means it
is stored in plaintext in the config; use 7 to indicate
a type-7 encrypted password, or use the
service password-encryption global command to encrypt
all plaintext passwords automatically.
PAP Authentication (Fallback or ISP-Required)
NetsTuts_R1(config)#interface Dialer1 NetsTuts_R1(config-if)#ppp authentication pap callin NetsTuts_R1(config-if)#ppp pap sent-username [email protected] password 0 P@ssw0rd! NetsTuts_R1(config-if)#exit
PAP credentials are configured with a single command:
ppp pap sent-username [username] password [password].
Unlike CHAP where the hostname and password are separate commands,
PAP combines both on one line. The word sent in the
command name reflects that PAP works by the client sending
credentials to the server in plaintext — there is no challenge/response
mechanism. Use PAP only when the ISP explicitly requires it or
when CHAP authentication consistently fails despite correct credentials.
CHAP + PAP Both Enabled (Negotiated)
NetsTuts_R1(config)#interface Dialer1 NetsTuts_R1(config-if)#ppp authentication chap pap callin NetsTuts_R1(config-if)#ppp chap hostname [email protected] NetsTuts_R1(config-if)#ppp chap password 0 P@ssw0rd! NetsTuts_R1(config-if)#ppp pap sent-username [email protected] password 0 P@ssw0rd! NetsTuts_R1(config-if)#exit
Listing both protocols —
ppp authentication chap pap callin
— tells the router to try CHAP first and fall back to PAP if the ISP
does not support or offer CHAP. The order matters: list the preferred
protocol first. Both credential sets must be configured. This is the
most flexible approach when the ISP's authentication requirements are
uncertain during initial deployment.
6. Step 4 — Default Route and NAT Configuration
The PPPoE dialer interface typically carries a single WAN IP address shared by all inside hosts via NAT overload (PAT). The default route must point to the dialer interface rather than a specific next-hop IP because the WAN IP and gateway are dynamic — assigned fresh each time the PPPoE session comes up:
Default Route via Dialer Interface
! ── Default route via the dialer — not via a specific IP ─ NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 Dialer1 ! ── Optional: make it a floating static (AD 254) to allow ! ── a backup route with lower AD to take over if needed NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 Dialer1 254
Pointing the default route to the dialer interface rather than a
next-hop IP address is the correct approach for PPPoE. When the
session is negotiated, IOS installs a host route for the peer's
IP (/32) automatically — there is no need to specify it as a
next-hop. A route to
Dialer1 works even when the
WAN IP changes between sessions (dynamic ISP assignment). The
optional administrative distance of 254 creates a floating static
that only becomes active when no lower-AD route exists — useful
when a secondary WAN link provides backup connectivity. For details
on floating static routes see
Floating Static Routes.
LAN Interface
! ── LAN interface ──────────────────────────────────────── NetsTuts_R1(config)#interface GigabitEthernet0/1 NetsTuts_R1(config-if)#description LAN NetsTuts_R1(config-if)#ip address 192.168.10.1 255.255.255.0 NetsTuts_R1(config-if)#ip nat inside NetsTuts_R1(config-if)#no shutdown NetsTuts_R1(config-if)#exit
NAT Overload (PAT) on the Dialer Interface
! ── ACL defining which inside hosts to translate ───────── NetsTuts_R1(config)#access-list 1 permit 192.168.10.0 0.0.0.255 ! ── PAT using the dialer interface's negotiated IP ─────── NetsTuts_R1(config)#ip nat inside source list 1 interface Dialer1 overload NetsTuts_R1(config)#end NetsTuts_R1#wr Building configuration... [OK]
NAT overload references
interface Dialer1 rather than
a static IP address. This is essential because the WAN IP is dynamic
— when the ISP assigns a new IP on session reconnect, NAT
automatically uses whatever IP is currently on Dialer1 without
requiring a configuration change. The ACL permits the entire LAN
subnet for translation. The ip nat inside label on
Gi0/1 and ip nat outside on Dialer1 (configured in
Step 2) complete the inside/outside boundary. For a full NAT
troubleshooting reference see
Troubleshooting NAT/PAT Issues.
7. Complete Configuration Summary — show running-config
! ═══════════════════════════════════════════════════════════ ! NetsTuts_R1 — Complete PPPoE Client Configuration ! ═══════════════════════════════════════════════════════════ ! hostname NetsTuts_R1 ! ! ── Global password encryption ──────────────────────────── service password-encryption ! ! ── NAT ACL ─────────────────────────────────────────────── access-list 1 permit 192.168.10.0 0.0.0.255 ! ! ── Physical WAN port ───────────────────────────────────── interface GigabitEthernet0/0 description ISP-Modem-Uplink no ip address pppoe-client dial-pool-number 1 no shutdown ! ! ── LAN port ────────────────────────────────────────────── interface GigabitEthernet0/1 description LAN ip address 192.168.10.1 255.255.255.0 ip nat inside no shutdown ! ! ── PPPoE virtual dialer ────────────────────────────────── interface Dialer1 description PPPoE-WAN-Session encapsulation ppp dialer pool 1 ip address negotiated ip mtu 1492 ip tcp adjust-mss 1452 ip nat outside ppp authentication chap pap callin ppp chap hostname [email protected] ppp chap password 7 <encrypted> ppp pap sent-username [email protected] password 7 <encrypted> no shutdown ! ! ── Default route via dialer ────────────────────────────── ip route 0.0.0.0 0.0.0.0 Dialer1 ! ! ── PAT using dynamic dialer IP ─────────────────────────── ip nat inside source list 1 interface Dialer1 overload ! end
After entering
service password-encryption, all
plaintext type-0 passwords in the configuration are converted to
type-7 obfuscated strings — these appear as the encrypted
placeholders shown above. Type-7 is reversible and not truly secure,
but it prevents casual shoulder-surfing of the config. The complete
configuration represents the minimum viable PPPoE client setup:
physical port binding, dialer session parameters, CHAP/PAP credentials,
MTU adjustment, NAT, and default routing.
8. Verification
show pppoe session
NetsTuts_R1#show pppoe session
1 client session
Uniq ID PPPoE RemMAC Port VT VA State
------- ----- ------- ---- -- -- -----
1 0x0042 00:1a:2b:3c:4d:01 Gi0/0 Di1 Vi1 UP
This is the primary PPPoE health command. Each row is one active
session. Key fields: Uniq ID is the local session
identifier; PPPoE (0x0042) is the Session ID
assigned by the ISP BRAS during the PADS discovery message —
a non-zero value confirms discovery completed successfully.
RemMAC is the MAC address of the ISP BRAS/modem.
Port confirms which physical interface carries
the session (Gi0/0). VT is the Virtual Template
(Di1 = Dialer1). VA is the Virtual Access interface
IOS creates internally for each PPPoE session.
State: UP confirms the PPP session is fully
established — LCP, authentication, and IPCP all completed
successfully.
show ip interface Dialer1
NetsTuts_R1#show ip interface Dialer1 Dialer1 is up, line protocol is up Internet address is 203.0.113.45/32 Broadcast address is 255.255.255.255 MTU is 1492 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is disabled ... IP NAT: outside ...
"Dialer1 is up, line protocol is up" confirms the
PPPoE session and PPP negotiation are fully complete. The internet
address shows the IP assigned by the ISP via IPCP — note the /32
prefix length, which is normal for PPP point-to-point links. The
MTU of 1492 bytes confirms the
ip mtu 1492 command
was applied correctly. "IP NAT: outside" confirms
the NAT outside label is set on the dialer — required for PAT
to work. If the interface is up but the protocol is down, the
PPP negotiation failed — check authentication credentials and
the show pppoe session output for the session state.
show ip interface brief
NetsTuts_R1#show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 unassigned YES unset up up GigabitEthernet0/1 192.168.10.1 YES manual up up Dialer1 203.0.113.45 YES IPCP up up Virtual-Access1 203.0.113.45 YES IPCP up up
The Method column is the definitive IPCP indicator:
IPCP confirms the IP address was negotiated from the
ISP via PPP's IP Control Protocol rather than being manually
configured. GigabitEthernet0/0 correctly shows
unassigned — it carries PPPoE frames at Layer 2 and
has no IP. Virtual-Access1 is an IOS-internal clone
of the dialer that carries the actual PPP session — it shares
the same IP as Dialer1 and is normal to see.
show pppoe session detail
NetsTuts_R1#show pppoe session detail
1 client session
Uniq ID PPPoE RemMAC Port VT VA State
------- ----- ------- ---- -- -- -----
1 0x0042 00:1a:2b:3c:4d:01 Gi0/0 Di1 Vi1 UP
Local MAC: 00:aa:bb:cc:dd:ee (GigabitEthernet0/0)
Remote MAC: 00:1a:2b:3c:4d:01
PPPoE Session ID: 0x0042
Interface: GigabitEthernet0/0
Virtual Template: 1
Virtual Access: Virtual-Access1
Negotiated IP: 203.0.113.45
Peer IP: 203.0.113.46
CHAP Authentication: Passed
Username: [email protected]
The detail output adds several fields not visible in the standard
summary. CHAP Authentication: Passed explicitly
confirms the ISP accepted the credentials — the single most useful
line when troubleshooting authentication failures. The
Peer IP (203.0.113.46) is the ISP gateway —
this is the address IOS installs as a /32 host route automatically
when the session comes up. Negotiated IP confirms
what IPCP assigned. If authentication shows
Failed,
the session ID will be 0x0000 and the state will be something other
than UP.
show ip route — Verify Default Route and Peer Route
NetsTuts_R1#show ip route
Codes: C - connected, S - static, ...
203.0.113.44/30 is variably subnetted
C 203.0.113.45/32 is directly connected, Dialer1
203.0.113.46/32 is directly connected, Dialer1
192.168.10.0/24 is variably subnetted
C 192.168.10.0/24 is directly connected, GigabitEthernet0/1
S* 0.0.0.0/0 [1/0] via 0.0.0.0, Dialer1
Three routes confirm a healthy PPPoE session. The /32 route for
203.0.113.45 is the router's own WAN IP (connected, Dialer1).
The /32 route for 203.0.113.46 is the ISP peer — IOS automatically
installs this as a connected route when IPCP completes. The
S* 0.0.0.0/0 default route via Dialer1 is the manually
configured default. The via 0.0.0.0 is normal for
interface-based static routes — it means "exit via Dialer1 regardless
of next-hop IP." Traffic to any destination not in the routing table
will be forwarded through the PPPoE session.
Verify NAT and End-to-End Connectivity
! ── Test from router ───────────────────────────────────── NetsTuts_R1#ping 8.8.8.8 source GigabitEthernet0/1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 18/21/25 ms ! ── Verify translation created ─────────────────────────── NetsTuts_R1#show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 203.0.113.45:1 192.168.10.1:1 8.8.8.8:1 8.8.8.8:1 ! ── Confirm NAT statistics healthy ────────────────────── NetsTuts_R1#show ip nat statistics Total active translations: 1 (0 static, 1 dynamic; 1 extended) Outside interfaces: Dialer1 Inside interfaces: GigabitEthernet0/1 Hits: 5 Misses: 0
Verification Command Summary
| Command | What It Shows | Primary Use |
|---|---|---|
show pppoe session |
Active PPPoE sessions — session ID, state, physical port, virtual interface | First check — is the PPPoE session UP? Is discovery complete (non-zero session ID)? |
show pppoe session detail |
Full session detail — authentication result, negotiated IP, peer IP, MAC addresses | Confirm CHAP/PAP passed; get ISP peer IP for routing verification |
show ip interface Dialer1 |
Dialer interface state, IP address, MTU, NAT label | Confirm interface is up/up, IP was assigned via IPCP, MTU is 1492 |
show ip interface brief |
All interfaces — IP address and Method (IPCP confirms PPPoE assignment) | Quick glance — is Dialer1 up with an IP? Is Gi0/0 correctly unassigned? |
show ip route |
Routing table — default route via Dialer1, peer /32 route installed | Confirm default route and ISP peer route are present after session establishment |
show ip nat translations |
Active NAT/PAT translations for inside hosts | Verify NAT is working — translations appear when LAN hosts send traffic |
debug ppp negotiation |
Real-time PPP LCP and IPCP negotiation events | Deep diagnosis — see exactly which PPP phase is failing and why |
debug ppp authentication |
Real-time CHAP challenge/response or PAP send events and results | Confirm authentication packets are sent and ISP response; diagnose credential faults |
9. Troubleshooting PPPoE Client Issues
| Problem | Symptom | Cause | Fix |
|---|---|---|---|
| No PPPoE session | show pppoe session shows no sessions; Dialer1 is down/down |
Physical port not up; pppoe-client dial-pool-number missing on Gi0/0; modem not passing PPPoE frames; dialer pool number mismatch between Gi0/0 and Dialer1 |
Confirm show interfaces Gi0/0 shows up/up. Verify pppoe-client dial-pool-number 1 on Gi0/0 and dialer pool 1 on Dialer1 — numbers must match. Check modem/CPE is powered and in bridge mode |
| Session stuck — discovery complete but PPP fails | Session ID is non-zero but state is not UP; Dialer1 is up/down | LCP negotiation failed — MTU mismatch, authentication rejected, or IPCP failure | Run debug ppp negotiation to see which PPP phase fails. Most likely is authentication — run debug ppp authentication to see CHAP/PAP exchange results |
| Authentication failure | show pppoe session detail shows CHAP: Failed or PAP: Failed; session resets repeatedly |
Wrong username or password; hostname in ppp chap hostname does not match what ISP expects; missing callin keyword causes router to challenge ISP back |
Verify credentials with ISP. Ensure ppp authentication chap callin — the callin keyword is mandatory for client-side operation. Try PAP if CHAP fails consistently. Run debug ppp authentication to see exact failure reason |
| Session UP but no IP address | Dialer1 is up/up but IP is unassigned or 0.0.0.0; no IPCP in show ip interface brief |
IPCP negotiation failed — ISP is not offering an address; ip address negotiated missing from Dialer1; or a static IP was incorrectly configured |
Confirm ip address negotiated is on Dialer1 (not a static IP). Run debug ppp negotiation and look for IPCP-related messages. Contact ISP to confirm dynamic IP assignment is enabled for your account |
| Large packets fail / websites load partially | Small pings succeed; large file transfers fail or hang; some HTTPS sites unreachable | ip mtu 1492 or ip tcp adjust-mss 1452 missing — packets at 1500 bytes hit the PPPoE 8-byte overhead limit and are fragmented or dropped |
Add ip mtu 1492 and ip tcp adjust-mss 1452 to Dialer1. Test with ping 8.8.8.8 size 1472 df-bit — a successful ping with DF-bit and size 1472 confirms the MTU is correct |
| Session UP but no internet from LAN hosts | Router can ping internet; LAN PCs cannot; show ip nat statistics shows misses |
NAT misconfiguration — ip nat inside missing on LAN interface, ip nat outside missing on Dialer1, ACL does not match LAN subnet, or NAT rule not referencing Dialer1 |
Verify show ip nat statistics — confirm inside/outside interfaces. Check access-list 1 permits the correct LAN subnet. Confirm NAT rule references interface Dialer1 not a static IP. See Troubleshooting NAT/PAT Issues |
| Session drops and reconnects intermittently | Internet works for minutes then drops; show pppoe session shows session ID incrementing (new session each reconnect) |
Physical layer issue on the DSL/Ethernet connection; ISP-side idle timeout; modem stability problem | Check show interfaces Gi0/0 for input errors and line protocol flaps. Add ppp lcp echo-interval 30 and ppp lcp echo-failure 5 on Dialer1 to detect drops faster. Contact ISP if modem line statistics show excessive errors |
Key Points & Exam Tips
- PPPoE uses a two-phase process: discovery (PADI → PADO → PADR → PADS) establishes the Ethernet tunnel at Layer 2; PPP negotiation (LCP → authentication → IPCP) runs inside the tunnel to authenticate and assign an IP address.
- The physical Ethernet interface facing the modem must have no IP address — it carries PPPoE frames at Layer 2. All IP configuration lives on the Dialer interface.
- The dial pool number must match on both sides:
pppoe-client dial-pool-number 1on the physical interface anddialer pool 1on the Dialer interface. A mismatch means no session is initiated. ppp authentication chap callin— thecallinkeyword is mandatory for client operation. Without it, the router challenges the ISP for its credentials, which fails every time.- CHAP never sends the password in plaintext — it uses a three-way challenge/response with MD5 hashing. PAP sends credentials in cleartext. Always prefer CHAP when the ISP supports it.
ip mtu 1492is required because PPPoE adds an 8-byte header to every Ethernet frame, reducing the effective IP payload from 1500 to 1492 bytes. Always pair it withip tcp adjust-mss 1452to clamp TCP MSS and prevent fragmentation of large TCP segments.ip address negotiatedon the Dialer interface tells IPCP to request a dynamic WAN IP from the ISP. The routing table confirms success with a /32 connected route on Dialer1 and the ISP peer /32 route.- NAT overload should reference
interface Dialer1rather than a static IP — this ensures NAT always uses the current WAN IP even when the ISP reassigns it on each session reconnect. - The default route must point to
Dialer1(not a specific IP) for the same reason — the ISP gateway IP is dynamic and installed automatically as a /32 connected route by IPCP. - On the CCNA exam: know the two-phase PPPoE process, the role of the Dialer interface vs the physical interface, the MTU/MSS adjustment requirement (1492/1452), the
callinkeyword for CHAP, and the key output fields inshow pppoe session.
Next Steps: With the PPPoE WAN session established,
configure NAT overload so LAN hosts can share the WAN IP — see
Dynamic NAT & PAT Configuration.
For diagnosing any NAT problems that follow, see
Troubleshooting NAT/PAT Issues.
To add a backup WAN link that activates only when the PPPoE session fails,
see Floating Static Routes.
For securing the router's management plane now that it is internet-facing,
see SSH Configuration and
Login Security and
Brute-Force Protection.