CCNA: WAN Technologies and PPP

May 26, 2026 37 min read Networking Deep Dives

ccnanetworkingwanppppppoesd-wanciscoios

Contents

Wide-area networking is where networking gets expensive fast. The moment traffic leaves your building and crosses provider infrastructure, you are paying for bandwidth, paying for availability guarantees, and paying engineers to keep the whole thing from falling apart at 2 AM. For the CCNA, WAN technologies represent one of those topic areas where conceptual knowledge and hands-on CLI fluency are both expected. You need to understand why different link types exist, what happens at Layer 2 across a serial connection, how PPP authentication works at a protocol level, and how the industry has been steadily migrating away from dedicated circuits toward software-defined overlays.

This post works through all of it — from copper demarc points and leased lines to PPP sublayer negotiation to the SD-WAN control plane. Configuration examples use real Cisco IOS syntax because that is what you will see on the exam and in production.

WAN Fundamentals: Roles, Boundaries, and the Last Mile

A WAN connects geographically separated networks, typically through infrastructure owned and operated by a service provider rather than the enterprise itself. The enterprise controls the equipment on its side; the provider controls everything in between.

The boundary between those two domains has a specific name and a specific physical location: the demarcation point, universally shortened to “demarc.” The demarc is where provider responsibility ends and customer responsibility begins. In a T1 installation this is typically a smart jack (network interface unit, or NIU) mounted on the wall near where the circuit enters the building. Provider equipment lives from that jack back to their central office; your equipment lives from that jack forward into your network.

Customer Premises Equipment (CPE) is any device on the customer side of the demarc. In a traditional WAN circuit this includes the router, the CSU/DSU (channel service unit/data service unit), and any switches or firewalls downstream of it. Some ISPs provision an integrated CPE device that combines the CSU/DSU and routing functions in a single box, which blurs the line somewhat — but the demarc still exists as a logical concept regardless.

Provider Edge (PE) is the carrier’s equipment that directly interfaces with customer circuits. When you are troubleshooting a WAN link, knowing whether you are looking at CPE or PE equipment matters enormously, because only your carrier can touch the PE side.

DTE and DCE describe the two ends of a serial connection. The Data Terminal Equipment (DTE) is the customer’s router — the device that generates and consumes data. The Data Communications Equipment (DCE) is the provider’s device that provides clocking for the circuit (in practice, the CSU/DSU or the smart jack). On a real T1, clocking comes from the provider network and is recovered by the CSU/DSU, then passed to the router. In a lab environment where you connect two routers back-to-back with a serial cable, one end of that cable is the DCE end and must be configured with the clock rate command, or neither side will synchronize:

Router(config)# interface serial 0/0/0
Router(config-if)# clock rate 64000

That command is only valid and only needed on the DCE side. The DTE receives clocking; it does not generate it. Forgetting this in a lab is one of the most common reasons a back-to-back serial link stays down.

The local loop (also called the last mile) is the physical connection between the demarc and the provider’s nearest facility, usually a central office (CO) for telco-based services or a cable headend for DOCSIS services. The local loop is the bottleneck that determines what link types are even available at a given location. Fiber-fed local loops support Ethernet hand-offs and MPLS connectivity. Copper loops support DSL and legacy T1. This is why “last mile” is a genuine engineering problem — you can have a 100 Gbps backbone, but if the last mile is a 50-year-old copper pair running ADSL, that is your ceiling.

Traditional WAN Link Types

Leased Lines: T1/E1 and T3/E3

A leased line is a dedicated point-to-point circuit between two locations, provisioned exclusively for a single customer. No sharing. The bandwidth is yours at all times and the latency is predictable because the path is fixed. This comes at a cost that is completely unrelated to actual data volume — you pay for the circuit whether you send one byte or run it at full capacity.

T1 is the North American standard: 24 DS0 channels, each 64 Kbps, time-division multiplexed (TDM) into a 1.544 Mbps aggregate. The framing formats are D4 (Super Frame) and ESF (Extended Super Frame); ESF is preferred on modern circuits because it provides embedded operations channel and CRC error monitoring. E1 is the European/international equivalent: 32 timeslots, 2.048 Mbps.

T3 aggregates 28 T1s into 44.736 Mbps. It requires a different physical layer (coaxial or fiber rather than twisted pair) and a different CSU/DSU. E3 runs at 34.368 Mbps.

The CSU/DSU sits between the router’s serial interface and the demarc. The CSU terminates the line signal and provides electrical isolation; the DSU handles framing and bit-timing conversion so the router’s serial interface sees a clean synchronous serial bit stream. On modern Cisco routers the CSU/DSU is typically integrated as a WAN interface card (WIC), so you may not see it as a separate physical box.

The default encapsulation on a Cisco serial interface is HDLC (High-Level Data Link Control) — but Cisco’s implementation of HDLC includes a proprietary Type field not present in the standard. This means Cisco HDLC only works between two Cisco routers. If you have a mixed-vendor point-to-point link, you change to PPP.

The show interfaces serial output tells you everything about the state of a serial link:

Router# show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up
  Hardware is WIC MBRD Serial
  Internet address is 10.0.0.1/30
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:04, output 00:00:04, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes)
  Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     1234 packets input, 98765 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1234 packets output, 98765 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets

The BW 1544 Kbit/sec line shows the configured bandwidth. Note carefully: the bandwidth command does not throttle or shape actual traffic. It is a routing metric value used by EIGRP and OSPF cost calculations. Setting bandwidth 768 on a T1 does not cap throughput at 768 Kbps — it just tells the routing protocol to treat the link as if it were slower. This is a real trap on exam questions.

When the line protocol is down but the interface itself shows up, the likely cause is a Layer 2 issue: encapsulation mismatch, keepalive failure, or the remote end being down. When the interface itself shows down, the problem is Layer 1: no signal, cabling, or CSU/DSU issue.

Frame Relay (Legacy but Exam-Relevant)

Frame Relay has been end-of-life for the better part of a decade, but it still appears on CCNA materials as a foundational concept, and understanding it helps you understand why MPLS exists. Frame Relay is a packet-switched WAN technology where multiple customers share the provider’s infrastructure through a switched virtual circuit model.

The key concepts:

DLCI (Data Link Connection Identifier) is a locally significant number that identifies a virtual circuit on a Frame Relay interface. Locally significant means DLCI 100 on your router refers to the PVC toward Branch A; DLCI 100 on your provider’s switch might mean something completely different. The provider maps DLCIs through their network.

PVC (Permanent Virtual Circuit) is a pre-configured virtual path between two endpoints. There is no signaling setup per connection like there is in ATM. The circuit is always “there” — the provider configures it, and it stays configured. An SVC (Switched Virtual Circuit) negotiates circuits on demand, but SVCs were rarely deployed.

LMI (Local Management Interface) is the signaling protocol between your router and the Frame Relay provider’s switch. LMI carries keepalives and provides status information about active DLCIs. Three LMI types exist: Cisco (proprietary), ANSI (T1.617 Annex D), and Q.933a (ITU). Cisco IOS autosenses LMI type by default.

The split horizon problem in hub-and-spoke Frame Relay topologies is important to understand. Split horizon is a distance-vector routing rule that prevents a route learned on an interface from being advertised back out that same interface. In a Frame Relay hub-and-spoke design, the hub router receives routing updates from all spokes on its single physical interface (even though there are multiple DLCIs). Split horizon prevents the hub from re-advertising spoke A’s routes to spoke B — because both learned routes and outgoing advertisements use the same physical interface. The solution is either point-to-point subinterfaces (which make each DLCI look like a separate interface, allowing split horizon to work correctly) or disabling split horizon (which is messy and not recommended for distance-vector protocols).

Frame Relay configuration:

Router(config)# interface serial 0/0/0
Router(config-if)# encapsulation frame-relay
Router(config-if)# no shutdown

! Point-to-point subinterface for one PVC
Router(config)# interface serial 0/0/0.100 point-to-point
Router(config-subif)# ip address 10.1.1.1 255.255.255.252
Router(config-subif)# frame-relay interface-dlci 100

MPLS: Labels Instead of Longest-Prefix Lookups

Multi-Protocol Label Switching is the dominant enterprise WAN technology for any organization that needs predictable performance, traffic engineering, or Layer 3 VPN connectivity across provider infrastructure. The core idea: instead of each router performing a full IP routing table lookup at every hop, the provider network switches based on short fixed-length labels.

The key roles:

LER (Label Edge Router) sits at the boundary between the provider’s MPLS network and the outside world. Ingress LERs impose (push) labels onto incoming packets. Egress LERs remove (pop) labels and forward based on the original IP header. Your PE router is a LER.

LSR (Label Switch Router) is any core provider router that switches based entirely on labels, swapping the incoming label for an outgoing label according to its Label Forwarding Information Base (LFIB). LSRs do not look at IP headers at all — they look only at the label. This is faster and more predictable than IP routing.

A Label Switched Path (LSP) is the sequence of LSRs from ingress to egress for a given FEC (Forwarding Equivalence Class). An FEC is essentially a group of packets that receive the same forwarding treatment — typically packets destined for a given IP prefix.

Why enterprises pay more for MPLS:

Traffic engineering is the key differentiator. With MPLS-TE, the provider can explicitly route LSPs to avoid congested paths, guarantee bandwidth, and provide deterministic failover. This matters for voice and video applications where you cannot tolerate jitter and packet loss spikes that occur during IP rerouting convergence.

MPLS also enables VPN services without requiring customer routers to maintain tunnels. The provider implements either:

L3VPN (MPLS/BGP VPN): The PE router participates in the customer’s routing protocol. VRFs (Virtual Routing and Forwarding instances) on the PE keep each customer’s routes separate. CE routers peer with the PE using OSPF, EIGRP, or eBGP. The customer does not see MPLS labels at all — from the CE’s perspective it looks like a regular IP network.
L2VPN / VPLS (Virtual Private LAN Service): The provider emulates a Layer 2 network across MPLS. CE devices connect as if they are on the same LAN. This gives customers full Layer 2 transparency, which is useful for protocols that don’t route well.

From a customer router perspective, MPLS connectivity looks like a regular Ethernet or serial hand-off with an IP address. The complexity lives inside the provider cloud, which is exactly how it should be.

Metro Ethernet: Carrier Ethernet Services

Metro Ethernet brings Ethernet technology to the WAN, typically within a metropolitan area. Instead of complex TDM framing or Frame Relay encapsulation, the hand-off to the customer is a standard Ethernet port (usually Fast or Gigabit). From an operational standpoint this is appealing — your router treats the WAN interface like any other Ethernet interface.

The MEF (Metro Ethernet Forum) defines service types:

Service Type	Description	Equivalent
E-Line	Point-to-point EVC between two UNIs	Virtual leased line
E-LAN	Multipoint-to-multipoint EVC	VPLS / mesh
E-Tree	Rooted multipoint (hub-and-spoke Ethernet)	Hub-and-spoke frame relay analog

UNI (User-to-Network Interface) is the physical handoff point — the Ethernet port where the provider’s service meets the customer’s router. EVC (Ethernet Virtual Connection) is the logical service instance. A single UNI port can carry multiple EVCs through 802.1Q VLAN tagging (CE-VLAN mapping), where the carrier maps customer VLAN tags to provider EVC instances using QinQ (802.1ad) or simple VLAN translation.

From the router’s configuration standpoint, Metro Ethernet connectivity is simpler than serial WAN. The WAN-facing interface typically gets encapsulation dot1q <vlan-id> on a subinterface if the carrier uses VLAN-tagged hand-offs, or a simple ip address if it is a flat Ethernet port:

Router(config)# interface GigabitEthernet0/0.100
Router(config-subif)# encapsulation dot1q 100
Router(config-subif)# ip address 198.51.100.1 255.255.255.252

Broadband WAN Technologies

DSL: Asymmetric and Very-High-Speed

Digital Subscriber Line technology carries broadband data over the same copper twisted-pair local loop used for voice telephony, by using frequency bands above the voice band (0–4 kHz). A DSLAM (DSL Access Multiplexer) at the provider’s central office aggregates DSL connections from many customers.

ADSL (Asymmetric DSL) provides faster download than upload — typically up to 8 Mbps downstream and 1 Mbps upstream in ADSL, and up to 24 Mbps/3.3 Mbps in ADSL2+. The asymmetry matches most residential usage patterns but creates a bottleneck for upload-heavy enterprise applications like video conferencing or cloud backups. Maximum ADSL range is roughly 5.5 km from the central office; beyond that, attenuation destroys signal quality.

VDSL (Very-High-Speed DSL) achieves speeds up to 52 Mbps downstream and 16 Mbps upstream (VDSL2 goes even higher) but only over very short loops, typically under 1.5 km. VDSL is practical only when the provider deploys fiber deep into the neighborhood and runs VDSL only for the final short copper segment — a design called FTTN (Fiber to the Node) or FTTC (Fiber to the Curb).

Distance is the fundamental constraint for all copper-based DSL. The longer the local loop, the worse the signal. There is no IOS command that fixes a 6 km copper loop.

Cable: DOCSIS and the Shared Medium

Cable internet uses the HFC (Hybrid Fiber-Coaxial) network originally built for cable television. DOCSIS (Data Over Cable Service Interface Specification) defines how data travels over coax. Current deployments are DOCSIS 3.0 (up to 1 Gbps aggregate with channel bonding) and DOCSIS 3.1 (up to 10 Gbps).

The critical characteristic from an enterprise networking standpoint is that the coaxial segment is a shared medium. Customers in the same neighborhood share bandwidth on the downstream and upstream channels. Contention during peak usage hours is real. This is acceptable for residential broadband; it is a meaningful reliability concern for enterprise WAN circuits where you need guaranteed bandwidth for VoIP or VPN traffic.

Upload asymmetry is even more pronounced with cable than with ADSL. DOCSIS traditionally allocated a large chunk of spectrum to downstream and a narrow band to upstream. DOCSIS 3.1 improves this, but cable remains a poor choice for upload-heavy workloads.

4G/5G Cellular WAN

Cellular LTE and 5G are increasingly deployed as enterprise WAN links, both as primary connectivity (for sites where fiber and cable are unavailable) and as secondary backup links. Cisco ISR routers and Meraki MX appliances support LTE WAN interfaces via pluggable modems (EM7455, EM9191, etc.).

The practical use cases are:

Temporary sites: Construction trailers, pop-up retail, events. No time or budget for circuit installation.
Primary WAN at remote sites: Locations where the only viable alternative is a fixed wireless or satellite link.
OOB (Out-of-Band) management: A cellular link used exclusively for management access and emergency failover, so you can reach the router even when the primary WAN is down.
SD-WAN transport path: Many SD-WAN deployments bond a broadband circuit with an LTE link, using the cellular link for failover and SLA enforcement.

5G mmWave offers very high throughput (multi-Gbps) but extremely limited range and poor penetration. Sub-6GHz 5G (NSA and SA) offers more realistic enterprise WAN speeds (100–900 Mbps) with better coverage. Latency on 4G LTE is typically 30–60 ms; 5G sub-6GHz can achieve sub-20ms. These are usable for most enterprise applications but are not MPLS.

PPP: Point-to-Point Protocol

Why PPP Exists

HDLC is the default encapsulation on Cisco serial interfaces, but Cisco’s HDLC is proprietary. The standard HDLC frame has no field to carry a Network Layer Protocol ID, so Cisco added one. That addition makes Cisco HDLC incompatible with every other vendor’s HDLC implementation.

PPP (Point-to-Point Protocol, defined in RFC 1661) solves this. It is vendor-neutral, supports multiple Network Layer protocols through NCPs, supports authentication, compression, multilink bonding, and error detection. Any two PPP-capable devices from any vendor can interoperate. This is why PPP is the right answer for any multi-vendor serial connection.

PPP Architecture: LCP and NCPs

PPP is structured in sublayers:

+-------------------------------+
|   Network Layer Protocols     |
|  (IP, IPv6, IPX, AppleTalk)   |
+-------------------------------+
|       NCP Layer               |
|  IPCP | IPv6CP | IPXCP | ...  |
+-------------------------------+
|       LCP Layer               |
|   Link Control Protocol       |
+-------------------------------+
|     Physical Layer (serial)   |
+-------------------------------+

LCP (Link Control Protocol) handles the data link layer. It establishes, configures, tests, and terminates the PPP connection. LCP negotiates:

MRU (Maximum Receive Unit) — equivalent to MTU
Authentication protocol to use (PAP or CHAP, if any)
Compression (if requested)
Magic number (used for loopback detection)
Link quality monitoring

NCP (Network Control Protocol) operates above LCP. There is a separate NCP for each Network Layer protocol. IPCP negotiates IP parameters over PPP — including IP address assignment (a client can get its IP from the server via IPCP, which is how ip address negotiated works on a dialer interface). IPv6CP handles IPv6 interface identifiers over PPP.

LCP Negotiation Phases

PPP link establishment follows a defined state machine. Understanding these phases matters for troubleshooting — debug ppp negotiation output maps directly to them.

  +--------+     LCP Configure-Request     +---------+
  |  DEAD  | ---------------------------> | ESTABLISH|
  +--------+                              +---------+
                                               |
                                    LCP Configure-Ack
                                               |
                                          +---------+
                              (optional)  |AUTHENTICATE|
                                          +---------+
                                               |
                                    PAP/CHAP exchange
                                               |
                                          +---------+
                                          | NETWORK |
                                          +---------+
                                               |
                                    NCP (IPCP) Configure-Ack
                                               |
                                          +---------+
                                          |  OPEN   |
                                          +---------+

Dead: No physical carrier or LCP not yet started.
Establish: LCP Configure-Request/Configure-Ack exchange. Both sides negotiate options. If a requested option is unacceptable, a Configure-Nak or Configure-Reject is sent.
Authenticate: If authentication was negotiated during Establish, PAP or CHAP exchange happens here. Authentication failure drops the link back to Dead.
Network: IPCP (and other NCPs) negotiate. IP addresses are confirmed or assigned.
Open: PPP is fully up. IP traffic flows.

A link that stalls in Establish typically has mismatched authentication configuration — one side wants CHAP, the other wants none. A link that completes LCP but fails in Authenticate has a username/password mismatch.

PAP: Two-Way Handshake

PAP (Password Authentication Protocol) is the simpler and weaker of the two PPP authentication methods. The process:

The calling router sends its username and password in a PAP Authenticate-Request packet.
The called router checks those credentials against its local database and responds with Authenticate-Ack (success) or Authenticate-Nak (failure).

The critical weakness: the username and password are sent in clear text. Anyone with a packet capture on the serial link can read them. Additionally, the password is sent only during initial link establishment — there is no ongoing verification that the other side is still who it claims to be.

Configuration on Router A (calling side):

Router-A(config)# username Router-B password cisco123
Router-A(config)# interface serial 0/0/0
Router-A(config-if)# encapsulation ppp
Router-A(config-if)# ppp authentication pap
Router-A(config-if)# ppp pap sent-username Router-A password cisco123

Configuration on Router B (called side):

Router-B(config)# username Router-A password cisco123
Router-B(config)# interface serial 0/0/0
Router-B(config-if)# encapsulation ppp
Router-B(config-if)# ppp authentication pap

Both routers need the other router’s username and password in their local user database (the username commands). The ppp pap sent-username command tells the calling router what credentials to send in the PAP request.

Debug output for a successful PAP exchange:

Router# debug ppp authentication
*Mar  1 00:01:02.143: Se0/0/0 PAP: O AUTH-REQ id 1 len 18 from "Router-A"
*Mar  1 00:01:02.187: Se0/0/0 PAP: I AUTH-ACK id 1 len 5

A failed PAP authentication looks like:

*Mar  1 00:01:02.143: Se0/0/0 PAP: O AUTH-REQ id 1 len 18 from "Router-A"
*Mar  1 00:01:02.187: Se0/0/0 PAP: I AUTH-NAK id 1 len 24 msg is "Authentication failure"

CHAP: Three-Way Handshake

CHAP (Challenge Handshake Authentication Protocol) addresses PAP’s weaknesses with a fundamentally different design. The password is never sent across the wire. Instead, both ends prove they know the shared secret by running an MD5 hash.

The three-step process:

Challenge: The authenticating router sends a challenge packet containing a random value and its hostname.
Response: The authenticating peer takes the challenge value, its own hostname, and the shared secret, hashes all three with MD5, and sends back the hash plus its hostname in a Response packet.
Accept/Reject: The authenticating router performs the same MD5 computation locally (using the peer’s hostname to look up the correct password in its username database). If the hashes match, it sends a Success packet. If not, it sends a Failure packet.

Because only the hash is transmitted — never the actual password — a captured CHAP exchange cannot be replayed (the challenge value changes each time) and does not expose the password. CHAP also periodically re-challenges during the session, providing ongoing verification.

The hostname matching requirement is important and frequently misunderstood. The username command on each router must use the other router’s hostname as the username. CHAP uses the hostname command value as the identity sent in challenge and response packets. If the hostname of Router A is HQ-RTR and the hostname of Router B is BRANCH1-RTR, then:

HQ-RTR(config)# hostname HQ-RTR
HQ-RTR(config)# username BRANCH1-RTR password secretpassword
HQ-RTR(config)# interface serial 0/0/0
HQ-RTR(config-if)# encapsulation ppp
HQ-RTR(config-if)# ppp authentication chap

BRANCH1-RTR(config)# hostname BRANCH1-RTR
BRANCH1-RTR(config)# username HQ-RTR password secretpassword
BRANCH1-RTR(config)# interface serial 0/0/0
BRANCH1-RTR(config-if)# encapsulation ppp
BRANCH1-RTR(config-if)# ppp authentication chap

The passwords must match on both sides. The username entries must use the peer’s hostname exactly as configured. Get either wrong and CHAP fails. This is the most common source of CHAP authentication failures in lab setups.

CHAP debug output for a successful exchange:

Router# debug ppp authentication
*Mar  1 00:02:11.211: Se0/0/0 CHAP: O CHALLENGE id 1 len 27 from "HQ-RTR"
*Mar  1 00:02:11.255: Se0/0/0 CHAP: I RESPONSE id 1 len 32 from "BRANCH1-RTR"
*Mar  1 00:02:11.259: Se0/0/0 CHAP: O SUCCESS id 1 len 4

A failed CHAP exchange (password mismatch):

*Mar  1 00:02:11.211: Se0/0/0 CHAP: O CHALLENGE id 1 len 27 from "HQ-RTR"
*Mar  1 00:02:11.255: Se0/0/0 CHAP: I RESPONSE id 1 len 32 from "BRANCH1-RTR"
*Mar  1 00:02:11.259: Se0/0/0 CHAP: O FAILURE id 1 len 26 msg is "MD5 compare failed"

The phrase “MD5 compare failed” in the debug output is the giveaway for a password mismatch. A username-not-found error looks different: CHAP: Unable to authenticate. Username BRANCH1-RTR not found.

Multilink PPP (MLP)

Multilink PPP allows multiple physical serial links to be bonded into a single logical interface, providing both increased bandwidth and some degree of redundancy. Traffic is fragmented and distributed across all member links, with sequence numbers used to reassemble fragments in order at the receiving end.

Router(config)# interface multilink 1
Router(config-if)# ip address 10.0.0.1 255.255.255.252
Router(config-if)# ppp multilink
Router(config-if)# ppp multilink group 1

Router(config)# interface serial 0/0/0
Router(config-if)# encapsulation ppp
Router(config-if)# ppp multilink group 1
Router(config-if)# no shutdown

Router(config)# interface serial 0/0/1
Router(config-if)# encapsulation ppp
Router(config-if)# ppp multilink group 1
Router(config-if)# no shutdown

MLP was useful in the T1 era when you needed more than 1.544 Mbps but could not justify a T3. With modern Ethernet WAN hand-offs and SD-WAN link bonding, MLP is rarely deployed today — but it remains relevant for CCNA because it illustrates the concept of link aggregation at Layer 2.

PPPoE: PPP Over Ethernet

Why PPPoE Exists

DSL providers face a specific operational problem: they need to authenticate individual subscribers, assign IP addresses, and account for per-session usage — but the physical infrastructure is Ethernet (or ATM-over-copper, but let’s focus on the Ethernet headend). Ethernet by itself has no authentication or session management.

PPPoE solves this by encapsulating PPP sessions inside Ethernet frames. Each subscriber gets an authenticated PPP session with its own IP address assigned by the ISP. PPPoE runs between the customer’s router (or residential gateway) and the ISP’s BRAS (Broadband Remote Access Server).

The overhead cost: PPPoE adds an 8-byte header on top of the standard Ethernet payload. This reduces the usable MTU from 1500 bytes to 1492 bytes. This is not negotiable — it is a structural consequence of the encapsulation.

PPPoE Discovery and Session Phases

PPPoE operates in two phases:

Discovery Phase — establishing which BRAS to connect to and assigning a session ID:

Client                                    BRAS
  |                                         |
  |-- PADI (PPPoE Active Discovery Init) -->|  (broadcast)
  |                                         |
  |<-- PADO (PPPoE Active Discovery Offer)--|  (unicast from BRAS)
  |                                         |
  |-- PADR (PPPoE Active Discovery Req) --> |  (unicast to chosen BRAS)
  |                                         |
  |<-- PADS (PPPoE Active Discovery Sess) --|  (session ID assigned)
  |                                         |

The PADI is broadcast on the local Ethernet segment. One or more BRAS devices respond with PADO. The client selects one BRAS and sends a PADR. The BRAS responds with PADS, which contains the session ID that will be used for all subsequent PPPoE frames. After PADS, LCP negotiation begins.

Session Phase — standard PPP (LCP, optional authentication, IPCP) runs inside PPPoE frames. The session ID from the discovery phase is included in every frame header so the BRAS can demultiplex sessions from thousands of subscribers.

PPPoE termination is signaled with a PADT (PPPoE Active Discovery Terminate) from either side.

IOS PPPoE Client Configuration

The PPPoE client on a Cisco router uses a dialer interface as a virtual PPP endpoint, bound to the physical Ethernet interface through a dial pool.

! Physical interface — no IP, PPPoE enabled
Router(config)# interface GigabitEthernet0/0
Router(config-if)# no ip address
Router(config-if)# pppoe enable group global
Router(config-if)# pppoe-client dial-pool-number 1
Router(config-if)# no shutdown

! Dialer interface — PPP session endpoint
Router(config)# interface Dialer1
Router(config-if)# mtu 1492
Router(config-if)# ip address negotiated
Router(config-if)# encapsulation ppp
Router(config-if)# dialer pool 1
Router(config-if)# ppp chap hostname isp-username@provider.net
Router(config-if)# ppp chap password 0 mypassword
Router(config-if)# ip tcp adjust-mss 1452
Router(config-if)# no shutdown

! Default route via the dialer (IP assigned dynamically by ISP)
Router(config)# ip route 0.0.0.0 0.0.0.0 Dialer1

A few things to unpack here. ip address negotiated tells IOS to get the IP address via IPCP rather than having a statically configured one — this is how residential and small-business DSL circuits work. dialer pool 1 ties this dialer interface to dial pool 1, which is what the physical GigabitEthernet interface references via pppoe-client dial-pool-number 1.

The mtu 1492 on the dialer interface accounts for the 8-byte PPPoE overhead. But MTU alone does not fix everything — hosts on the LAN will still try to send 1500-byte packets, which the router will need to fragment or drop (depending on the DF bit). The cleaner solution is ip tcp adjust-mss 1452. This command intercepts TCP SYN packets passing through the interface and rewrites the MSS field down to 1452. Here is why that number works:

1452  (TCP payload / MSS)
+  20  (TCP header)
+  20  (IP header)
+   8  (PPPoE header)
= 1500  (Ethernet MTU — exactly)

The MSS clamp ensures that TCP connections never try to send segments that will overflow the PPPoE MTU. Apply ip tcp adjust-mss 1452 on the LAN-facing interface of the router (not the dialer) so it catches packets as they arrive from the LAN before they traverse the PPPoE link.

Verification commands:

Router# show pppoe session
     1 client session

Uniq ID  PPPoE  RemMAC          Port                    VT  VA         State
           SID  LocMAC                                      VA-st
    N/A    123  aabb.cc00.0100  Gi0/0                   Di1  Vi1        UP

Router# show interface Dialer1
Dialer1 is up, line protocol is up (spoofing)
  Hardware is Unknown
  Internet address is 203.0.113.45/32
  MTU 1492 bytes, BW 0 Kbit/sec, DLY 0 usec
  Encapsulation PPP, LCP Open
  Open: IPCP, CDPCP

Router# show ppp all
Interface  Phase     IPCP     IPV6CP   Type       Peer Address    Peer Name
Di1        OPEN      OPEN     N/A      PPPoE      203.0.113.1     bras.provider.net

State should be UP. LCP Open. IPCP Open. If you see LCP Closed, the PPPoE discovery succeeded but LCP negotiation failed — check authentication settings. If show pppoe session shows no sessions, the PADI is either not reaching the BRAS or not getting a PADO response, which points to a Layer 2 problem on the Ethernet segment or an incorrect pppoe enable configuration.

SD-WAN: Software-Defined WAN

The Problem SD-WAN Solves

For years, enterprise WAN architecture was simple in concept if expensive in practice: lease MPLS circuits from a carrier, connect all sites, pay per-Mbps at MPLS prices, and enjoy predictable performance. As cloud adoption accelerated — Office 365, Salesforce, AWS, Azure — the model broke down. Enterprise traffic was no longer flowing site-to-site; it was flowing from branch offices directly to internet cloud services. Routing that traffic through headquarters and out the HQ internet link (the traditional hub-and-spoke MPLS model with centralized internet access) was creating latency and throughput problems that MPLS could not fix, because the issue was not the WAN fabric — it was the traffic pattern.

Meanwhile, MPLS remained expensive. A 100 Mbps MPLS circuit costs dramatically more than 100 Mbps of business-grade internet broadband. Enterprises started wanting to replace MPLS with broadband circuits, but broadband does not provide the QoS guarantees, SLAs, or private routing that MPLS provides.

SD-WAN bridges this gap. The core proposition:

Build encrypted overlay tunnels across any available transport — MPLS, broadband, LTE, anything.
Measure real-time performance (jitter, latency, packet loss) on each path.
Steer application traffic to the best-performing path dynamically, based on centrally defined policies.
Provide direct internet breakout at the branch for cloud-bound traffic, eliminating the hairpin through HQ.
Manage the entire WAN fabric from a single centralized dashboard rather than per-device CLI.

Cisco SD-WAN Architecture (Viptela / Catalyst SD-WAN)

Cisco’s SD-WAN platform (originally Viptela, acquired in 2017, now branded as Cisco Catalyst SD-WAN) separates WAN functions into four planes implemented by four components:

+----------------------------------------------------------+
|                   MANAGEMENT PLANE                       |
|                vManage (SD-WAN Manager)                  |
|         GUI, REST API, policy config, telemetry          |
+----------------------------------------------------------+
           |                          |
+---------------------+    +---------------------+
|   ORCHESTRATION     |    |    CONTROL PLANE     |
|   vBond (Validator) |    | vSmart (Controller)  |
| Auth, NAT traversal |    | OMP routing, policy  |
+---------------------+    +---------------------+
           |                          |
+----------------------------------------------------------+
|                     DATA PLANE                           |
|          cEdge routers (ISR/ASR/Catalyst 8000)           |
|          IPsec tunnels, BFD, application routing         |
+----------------------------------------------------------+

vManage (SD-WAN Manager) is the centralized management and orchestration system. All configuration, policy, and monitoring lives here. Operators interact with vManage through a web GUI or REST API. A change pushed through vManage propagates to all devices in the fabric automatically.

vBond (Validator) is the first point of contact for any new device. When a cEdge router boots and attempts to join the SD-WAN fabric, it connects to vBond first. vBond authenticates the device (using certificates and a whitelist in vManage), then provides the IP addresses of the vSmart controllers. vBond also facilitates NAT traversal — if cEdge devices are behind NAT, vBond helps them discover each other’s public addresses. Every new router must know its vBond address, typically provided via ZTP (zero-touch provisioning) or DHCP option 43.

vSmart (Controller) is the control plane. It distributes routing information and policy to all cEdge devices using OMP (Overlay Management Protocol), which is a proprietary protocol similar in concept to BGP. vSmart knows the topology of the entire SD-WAN fabric and tells each cEdge router which remote sites are reachable, via which transport paths, and what policy to apply to which traffic. Importantly, vSmart does not forward data plane traffic — it only controls the overlay routing.

cEdge (WAN Edge Router) is the device at each site that actually handles data plane forwarding. cEdge is a standard Cisco IOS XE router (ISR 1000, 4000, ASR 1000, Catalyst 8000) with the Cisco Catalyst SD-WAN feature set enabled. Between all cEdge devices, the data plane is an IPsec mesh — each site has encrypted tunnels to every other site. The original Viptela vEdge hardware has been end-of-sale since around 2020; cEdge on IOS XE is the current platform.

Overlay Fabric: IPsec Tunnels and BFD

Each cEdge establishes IPsec tunnels to remote cEdge devices across all available transports. If a branch has both an MPLS circuit and a broadband internet circuit, it will build IPsec tunnels over both paths. The MPLS path goes to the MPLS overlay; the internet path goes to the internet overlay.

BFD (Bidirectional Forwarding Detection) runs inside each IPsec tunnel between cEdge pairs. BFD sends small probe packets at configurable intervals (typically sub-second) and measures round-trip time, jitter, and loss for each probe. This real-time measurement data is what enables application-aware routing. If the MPLS path’s loss exceeds a threshold (say, 1%) or latency exceeds 150ms, SD-WAN automatically steers voice traffic away from that path and onto the broadband path — even if the broadband path has higher nominal latency, because a lossy path is worse for VoIP than a higher-latency-but-clean path.

Application-Aware Routing

Application-aware routing (AAR) is the feature that justifies the cost of SD-WAN for most enterprises. The platform uses NBAR2 deep packet inspection to classify traffic by application — Cisco Webex, Microsoft Teams, Salesforce, SAP, custom TCP port ranges, etc. — and then defines SLA thresholds per application class:

Policy: VoIP Traffic
  Preferred transport: MPLS
  SLA: latency < 150ms, jitter < 30ms, loss < 1%
  Fallback: if MPLS SLA fails for > 60s, failover to internet

Policy: Backup traffic
  Preferred transport: internet
  No SLA thresholds

When BFD reports that the MPLS path violates the VoIP SLA, vSmart pushes an updated forwarding policy to the affected cEdge routers and traffic shifts paths — automatically, in seconds, without any human intervention.

Zero-Touch Provisioning

ZTP allows a new branch cEdge to connect to the SD-WAN fabric without any manual configuration beyond plugging in the WAN cables. The process:

Factory-configured router ships to branch site.
Router boots, gets DHCP address on WAN interface.
Router contacts devicehelper.cisco.com (Cisco’s ZTP bootstrap server) with its serial number.
Bootstrap server directs router to the enterprise’s vBond address.
Router authenticates to vBond (using certificate pre-installed during staging).
vBond directs router to vManage and vSmart.
vManage pushes full configuration based on device serial number.

From a logistics standpoint, this means a branch office opens a box, plugs cables in, and the router configures itself. No network engineer on-site required. For enterprises with hundreds of branch locations, this is a significant operational cost reduction.

SD-WAN on the CCNA Exam

The CCNA exam (200-301) covers SD-WAN at a conceptual level. You will not be asked to configure vManage policies or debug vSmart OMP sessions. You are expected to understand the four planes and four components, know what ZTP means, understand application-aware routing as a concept, and know why enterprises adopt SD-WAN (MPLS cost reduction, cloud optimization, centralized management). Think of it as “you should understand the architecture and the business case, not the operational CLI.”

Topology: WAN Design With MPLS and PPPoE Backup

                     MPLS PROVIDER CLOUD
                    +-------------------+
                    |   PE-1     PE-2   |
                    |    |         |    |
HQ Site             |    |         |    |         Branch A
+-----------+       |    |         |    |       +-----------+
|           |       |    |         |    |       |           |
| HQ-RTR ---+--[CSU/DSU]-+         +-[CSU/DSU]--+ BR-A-RTR |
|  G0/0     | T1/MPLS                  T1/MPLS  |           |
|  10.0.0.1 |                                   |  10.2.2.1 |
|           |                                   |           |
|  G0/1 ---[LAN switch]                         +-----------+
|192.168.1.1|
|           |
|  G0/2 ----+----[DSL Modem]----[DSLAM]------ ISP BRAS
| (no IP)   |  PPPoE over ADSL              (203.0.113.1)
|  Di1      |
| 203.0.113.x (negotiated)                  Branch B
+-----------+                             +-----------+
                                          |           |
                    MPLS CLOUD -----------+ BR-B-RTR  |
                                          |  10.3.3.1 |
                                          +-----------+


HQ-RTR has:
  - Primary WAN: MPLS T1 (G0/0 via CSU/DSU) -> 10.0.0.1/30
  - Backup WAN:  PPPoE over ADSL (G0/2 -> Di1) -> IP negotiated
  - LAN:         192.168.1.0/24 on G0/1

In this design, the primary path between HQ and all branches uses MPLS with T1 hand-offs. The HQ router’s secondary WAN interface runs PPPoE over ADSL as a backup. Routing protocol (OSPF or EIGRP) runs over the MPLS layer. When the T1 goes down, a floating static default route via the Dialer1 interface takes over. MPLS routing handles branch-to-branch traffic; branch internet access either hairpins through HQ or uses local internet breakout depending on design.

Complete Configuration Examples

Serial Interface: HDLC to PPP

Default state (HDLC):

Router# show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up
  Encapsulation HDLC

Changing to PPP:

Router(config)# interface serial 0/0/0
Router(config-if)# encapsulation ppp

This change must be made on both ends simultaneously. Changing one end while the other is still HDLC will immediately drop the link — encapsulation mismatch causes the line protocol to go down even though the physical layer (carrier) is still present.

PPP with CHAP: Complete Both-Sides Configuration

! === Router HQ-RTR ===
HQ-RTR(config)# hostname HQ-RTR
HQ-RTR(config)# username BRANCH1 password Ch@pSecret99
HQ-RTR(config)# interface serial 0/0/0
HQ-RTR(config-if)# ip address 10.0.0.1 255.255.255.252
HQ-RTR(config-if)# encapsulation ppp
HQ-RTR(config-if)# ppp authentication chap
HQ-RTR(config-if)# bandwidth 1544
HQ-RTR(config-if)# no shutdown

! === Router BRANCH1 ===
BRANCH1(config)# hostname BRANCH1
BRANCH1(config)# username HQ-RTR password Ch@pSecret99
BRANCH1(config)# interface serial 0/0/0
BRANCH1(config-if)# ip address 10.0.0.2 255.255.255.252
BRANCH1(config-if)# encapsulation ppp
BRANCH1(config-if)# ppp authentication chap
BRANCH1(config-if)# bandwidth 1544
BRANCH1(config-if)# no shutdown

Note the bandwidth 1544 command. This tells OSPF and EIGRP the correct cost for this link. Without it, IOS defaults to reporting the bandwidth as whatever the hardware reports, which may not be accurate if you are using a sub-rate T1 or a lab serial cable.

PPPoE Client: Complete Configuration

! Physical Ethernet (WAN-facing, connects to DSL modem)
Router(config)# interface GigabitEthernet0/2
Router(config-if)# description DSL-Modem-WAN
Router(config-if)# no ip address
Router(config-if)# pppoe enable group global
Router(config-if)# pppoe-client dial-pool-number 1
Router(config-if)# no shutdown

! Dialer interface (virtual PPP session endpoint)
Router(config)# interface Dialer1
Router(config-if)# description PPPoE-DSL-Backup
Router(config-if)# mtu 1492
Router(config-if)# ip address negotiated
Router(config-if)# encapsulation ppp
Router(config-if)# dialer pool 1
Router(config-if)# ppp chap hostname subscriber@isp.net
Router(config-if)# ppp chap password 0 myISPpassword
Router(config-if)# no shutdown

! MSS clamping on LAN interface (catches LAN-originated traffic)
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip tcp adjust-mss 1452

! Floating static default route — higher AD than MPLS routes
! (AD 254 so it only activates when MPLS is gone)
Router(config)# ip route 0.0.0.0 0.0.0.0 Dialer1 254

The floating static route uses administrative distance 254, which is higher than any dynamic routing protocol. OSPF-learned routes (AD 110) and EIGRP-learned routes (AD 90) will be preferred. Only when those routes disappear — because the primary WAN is down — will this static route via Dialer1 be installed in the routing table.

Verification Commands

! PPP session state (serial)
Router# show ppp all
Interface  Phase     IPCP     IPV6CP   Type       Peer Address    Peer Name
Se0/0/0    OPEN      OPEN     N/A      Unknown    10.0.0.2        BRANCH1

! PPPoE session state
Router# show pppoe session
     1 client session
Uniq ID  PPPoE  RemMAC          Port      VT  VA         State
           SID  LocMAC                        VA-st
      1     43  001a.2b3c.4d5e  Gi0/2     Di1 Vi1        UP

! Serial interface detail
Router# show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up
  Encapsulation PPP, LCP Open
  Open: IPCP, CDPCP

! Debug PPP authentication (use carefully in production)
Router# debug ppp authentication
! Shows PAP/CHAP challenge, response, success/failure messages

! Debug PPP negotiation (verbose — shows every LCP option)
Router# debug ppp negotiation
! Shows Configure-Request, Configure-Ack, Configure-Nak for each option

Troubleshooting WAN Links

Troubleshooting WAN problems follows the same layered model as any other networking problem: confirm Layer 1 before blaming Layer 2.

Layer 1 Issues

No carrier / interface down:

Serial0/0/0 is down, line protocol is down

This means no electrical signal. Check: CSU/DSU loopback test, provider circuit status, cable from router to CSU/DSU, clock rate configured on DCE side in a lab environment. If the provider confirms the circuit is active but the router still shows down, suspect the CSU/DSU or the WIC module itself.

Keepalive failures:

Serial0/0/0 is up, line protocol is down

Physical layer is fine (carrier present), but Layer 2 is failing. On HDLC, this means the remote end is not responding to keepalive packets. This is the encapsulation mismatch signature — if one side is PPP and the other is HDLC, keepalives will fail because neither side can parse the other’s frames.

Clock rate (DCE side only):

In a lab with back-to-back serial cables, the DCE end must have clock rate configured. Use show controllers serial 0/0/0 to identify which end is DCE — it will say “DCE cable” in the output. The DTE side must not have clock rate configured (it receives clocking).

Router# show controllers serial 0/0/0
Interface Serial0/0/0
Hardware is GT96K
DCE V.35, clock rate 64000

Layer 2 Issues

Encapsulation mismatch:

One router is HDLC, the other is PPP. The show interfaces output on both routers will show line protocol is down. Fix: ensure both ends have the same encapsulation configured.

LCP not reaching Open state:

debug ppp negotiation will show Configure-Nak or Configure-Reject packets. Common reasons:

One side requires authentication, the other does not
Incompatible compression options
MRU mismatch beyond negotiable range

Authentication failure:

debug ppp authentication is the first tool. For CHAP, “MD5 compare failed” means the passwords do not match. “Username not found” means the username command is missing or the hostname does not match exactly (including case — IOS hostnames are case-sensitive in CHAP lookup). For PAP, AUTH-NAK means the remote router rejected the username/password.

PPPoE-Specific Issues

PADI timeout:

debug pppoe events will show PADI being sent with no PADO response. Causes: the DSL modem is not passing through PPPoE frames (some modems are in routing mode rather than bridge mode — the modem must be in bridge mode for router-terminated PPPoE), wrong VLAN on the Ethernet hand-off, or the ISP BRAS is unreachable.

MTU/MSS mismatch:

Symptoms: large file transfers hang or fail, but small requests (DNS, pings) work fine. This is the classic sign of PPPoE MTU problems. The TCP session SYN packets (small) succeed, but data transfer packets (large) hit the 1492 byte MTU wall and are dropped (especially if the DF bit is set). Fix: ip tcp adjust-mss 1452 on the LAN-facing interface. Verify with ping 8.8.8.8 size 1490 df-bit — if this fails while ping 8.8.8.8 size 1472 df-bit succeeds, you have an MTU problem.

PPPoE session stuck in Discovery phase:

Check show pppoe session — if it shows no sessions or a session stuck in PADO state, the BRAS is not responding to PADR. This can indicate authentication pre-checks failing on the BRAS side (ISP may block the session before LCP even starts if the service account is invalid) or a VLAN configuration issue.

Summary Reference Tables

WAN Technology Comparison

Technology	Bandwidth	Dedicated?	Typical Use	Cost
T1 Leased Line	1.544 Mbps	Yes	Legacy branch WAN	High per-Mbps
T3 Leased Line	44.736 Mbps	Yes	Legacy DC interconnect	Very high
Frame Relay	Up to ~45 Mbps	No (shared)	Legacy hub-and-spoke	Moderate
MPLS L3VPN	1 Mbps – 10 Gbps	Logical	Enterprise WAN backbone	High
Metro Ethernet	1 Mbps – 10 Gbps	Logical	Urban site interconnect	Moderate
ADSL	Up to 24 Mbps down	No	Residential, small site	Low
VDSL2	Up to 100 Mbps	No	Near-CO broadband	Low
Cable (DOCSIS)	Up to 1 Gbps	No (shared)	Residential, SOHO	Low
LTE WAN	10–150 Mbps	No	Backup, remote, temporary	Moderate
5G WAN	50 Mbps – 1 Gbps	No	Primary at remote sites	Moderate

PPP Authentication Comparison

Feature	PAP	CHAP
Handshake	Two-way	Three-way
Password transmitted	Plaintext	Never — MD5 hash only
Challenge/Response	No	Yes (random challenge)
Replay attack resistant	No	Yes (challenge changes each time)
Ongoing re-authentication	No	Yes (periodic re-challenge)
IOS command	`ppp authentication pap`	`ppp authentication chap`
Username lookup key	Peer sends its username	Peer sends its hostname
Password must match on both sides	Yes	Yes
Recommended for production	No	Yes

PPP Troubleshooting Quick Reference

Symptom	Likely Cause	Debug/Verify Command
Serial interface down/down	No carrier, cable fault, CSU/DSU	`show controllers serial`
Serial interface up/down	Encapsulation mismatch, keepalive failure	`show interfaces serial`
LCP not Open	Auth mismatch, option conflict	`debug ppp negotiation`
CHAP “MD5 compare failed”	Password mismatch	`debug ppp authentication`
CHAP “Username not found”	Missing/wrong `username` command or hostname mismatch	`show running-config`
PPPoE no session	Modem not in bridge mode, VLAN issue	`debug pppoe events`
PPPoE large transfers hang	MTU/MSS problem (1492 vs 1500)	`ping size df-bit`, check `ip tcp adjust-mss`

WAN technologies are not glamorous, but they are load-bearing. Serial interfaces, PPP authentication, and PPPoE client configuration represent the foundational knowledge that everything else — SD-WAN, site connectivity, internet edge design — builds upon. Spend time with the debug commands. Deliberately misconfigure a password and watch the CHAP failure message. Break the clock rate and watch the link die. Get comfortable reading show interfaces serial and parsing what each line tells you about the link’s health. The exam tests your ability to recognize these states, and production networks will eventually put you in front of a downed WAN circuit at a time when the business is waiting for you to fix it.