Back to blog

Cisco / IOS  ·  Routing  ·  September 2026

Cisco IOS
PPPoE

PPPoE is how most DSL and a lot of fibre hands you a session. On IOS a Cisco router is the client — a dialer interface that authenticates and pulls an address — or the server, a bba-group and virtual-template acting as a small access concentrator. Either way the MTU maths decides if it works. The RouterOS twin is the MikroTik PPPoE server.

Cisco IOS PPPoE Dialer BBA-Group WAN

PPPoE runs a PPP session — with its authentication, address negotiation and accounting — over Ethernet. Most of the time a Cisco box is the client: it sits behind an ISP's DSL/fibre handoff, dials a session over a Dialer interface, does CHAP, and receives its WAN address. Less often it's the server, terminating client sessions with a bba-group and a virtual-template — the Cisco equivalent of the RouterOS PPPoE server.

The concept is identical on both ends; the config is two distinct recipes. And on both, the same 8-byte PPPoE overhead means an MTU of 1492 and an MSS clamp of 1452 — skip it and you get the maddening "small sites load, big downloads and some HTTPS hang" fault. This pairs with the dual-WAN failover and hardening posts.

Prerequisites

01

Client — A Dialer Interface Behind the ISP

The physical port just enables PPPoE and points at a dial pool; all the real config — address, auth, MTU — lives on a logical Dialer interface.

IOS — PPPoE client (CPE behind DSL/fibre)
# The physical WAN port: no IP, just bind it to a PPPoE dial pool.
R1(config)# interface GigabitEthernet0/0
R1(config-if)# no ip address
R1(config-if)# pppoe enable group global
R1(config-if)# pppoe-client dial-pool-number 1

# The logical Dialer holds the session config.
R1(config)# interface Dialer1
R1(config-if)# mtu 1492
R1(config-if)# ip address negotiated          # WAN IP from the ISP
R1(config-if)# ip tcp adjust-mss 1452        # clamp for the 8-byte overhead
R1(config-if)# encapsulation ppp
R1(config-if)# dialer pool 1
R1(config-if)# dialer-group 1
R1(config-if)# ppp authentication chap pap callin
R1(config-if)# ppp chap hostname user@isp
R1(config-if)# ppp chap password 0 ProviderSecret

# Default route out the dialer, and permit interesting traffic to bring it up.
R1(config)# ip route 0.0.0.0 0.0.0.0 Dialer1
R1(config)# dialer-list 1 protocol ip permit
⚠ Gotcha — ip nat Goes on the Dialer, Not the Physical Port

The WAN address lives on Dialer1, so that's your ip nat outside interface — not Gi0/0, which has no IP. New PPPoE configs frequently NAT to the wrong interface and nothing translates. Everything that references "the WAN" — NAT, ACLs, the default route, IP SLA tracking — points at the dialer.

02

Server — bba-group + Virtual-Template

To terminate sessions, a bba-group catches PPPoE on a port and clones a virtual-template per client — the template defines addressing and auth for every session.

IOS — PPPoE server (small access concentrator)
# The group ties the access port to a template to clone per session.
R1(config)# bba-group pppoe BBA-GRP
R1(config-bba-group)# virtual-template 1

# The template: unnumbered off a loopback, hand clients a pool address, CHAP.
R1(config)# interface Virtual-Template1
R1(config-if)# mtu 1492
R1(config-if)# ip unnumbered Loopback0
R1(config-if)# peer default ip address pool PPPOE-POOL
R1(config-if)# ppp authentication chap

# Bind the group to the client-facing port; define the pool + a subscriber.
R1(config)# interface GigabitEthernet0/1
R1(config-if)# pppoe enable group BBA-GRP
R1(config)# ip local pool PPPOE-POOL 10.60.0.10 10.60.0.254
R1(config)# username room101 password 0 SubscriberSecret
# For real subscriber counts, authenticate via AAA/RADIUS instead of local
# usernames — see the device-AAA post for the method-list pattern.

03

The 1492 / 1452 Rule

PPPoE's overhead is the single most common reason a "working" link half-works. Set the interface MTU to 1492 and clamp TCP MSS to 1452 on both ends — every time.

The symptom is unmistakable once you've seen it: ping works, DNS works, small web pages load, but large downloads stall and some HTTPS sites never render. That's Path-MTU discovery failing — the router sends 1500-byte packets that can't fit, and the ICMP that should signal it is filtered somewhere upstream. ip tcp adjust-mss 1452 on the dialer or virtual-template makes TCP negotiate a segment that fits from the start, sidestepping PMTUD entirely for the traffic that matters.

ValueWhy
MTU 14921500 Ethernet − 8 bytes PPPoE header.
ip tcp adjust-mss 14521492 − 40 (IP+TCP headers). Clamps TCP so it never needs PMTUD.
Symptom if skippedSmall pages load, big transfers & some HTTPS hang. "Internet is broken but ping works."

04

Verify Safe to Run

Confirm the session comes up, the dialer got an address, and — if it half-works — that the MSS clamp is doing its job.

IOS — session + address + MTU checks
R1# show pppoe session                   # state UP, the virtual-access iface
R1# show ip interface brief | include Dialer  # did Dialer1 get an IP?
R1# show interface Dialer1 | include MTU   # 1492
R1# show caller ip                        # server side: connected peers
R1# debug pppoe events                    # dial/auth trace (lab only)

Takeaways

  1. Client role: the physical port just pppoe-client dial-pool-number; the Dialer interface holds the address, auth and MTU.
  2. Point NAT/ACLs/default route at the Dialer, not the physical port — the WAN IP lives on the dialer.
  3. Server role: a bba-group binds a port to a virtual-template that's cloned per session for addressing and CHAP.
  4. MTU 1492, ip tcp adjust-mss 1452 on both ends — the non-negotiable fix for the "small works, big hangs" fault.
  5. Local usernames for a lab; AAA/RADIUS for real subscriber counts — the same method-list pattern as device admin.
  6. Verify with show pppoe session and confirm the dialer actually received an address.

A flaky PPPoE WAN that half-works?

Nine times in ten it's MTU, and the tenth is auth or the wrong NAT interface. I build and troubleshoot PPPoE edges on Cisco and MikroTik — clean sessions, correct MSS, and failover watching the link.

Book a Discovery Call →