How to Configure PPP (Point-to-Point Protocol) on Cisco Routers with Authentication

Abdul Wahab Junaid

3 years ago

How to Configure PPP (Point-to-Point Protocol) on Cisco Routers

PPP is one of those protocols that’s simple enough to configure in five minutes, yet rich enough to power everything from old-school dial-up links to modern serial WAN connections and even the control-plane handshake tucked inside PPPoE for broadband access. Understanding PPP thoroughly — the negotiation phases, authentication options, and multilink capability — pays off well beyond legacy WAN scenarios, since the same concepts resurface in DSL/broadband deployments and certain VPN technologies today.

This guide covers PPP fundamentals, full CLI configuration with both PAP and CHAP authentication, multilink PPP, and the troubleshooting steps that resolve the vast majority of PPP negotiation failures.

What PPP Provides Over HDLC

Cisco’s default serial encapsulation, HDLC, is simple but proprietary and lacks authentication or multi-protocol negotiation flexibility. PPP (Point-to-Point Protocol), an open IETF standard, adds:

LCP (Link Control Protocol) — negotiates link-level options: authentication method, MRU, magic numbers (loop detection), and compression
NCP (Network Control Protocol) — negotiates network-layer parameters per protocol (IPCP for IPv4, IPv6CP for IPv6)
Authentication — PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol)
Multilink PPP (MLPPP) — bundles multiple physical links into one logical PPP connection for increased bandwidth

PPP Negotiation Phases

Link establishment (LCP) — both ends agree on link parameters
Authentication phase (optional) — PAP or CHAP validates identity before network layer is allowed
Network layer protocol phase (NCP) — IPCP negotiates IP addressing details
Link termination — either side can tear down the session

Topology for This Guide

Two routers connected via a serial WAN link:

R1 (10.0.12.1/30) ---- Serial Link ---- R2 (10.0.12.2/30)

Step 1: Enable PPP Encapsulation

R1(config)# interface Serial0/0/0
R1(config-if)# encapsulation ppp
R1(config-if)# ip address 10.0.12.1 255.255.255.252

R2(config)# interface Serial0/0/0
R2(config-if)# encapsulation ppp
R2(config-if)# ip address 10.0.12.2 255.255.255.252

At this point, PPP will establish with no authentication — fine for a lab, not for production.

Step 2: Configure PAP Authentication (Simple, Less Secure)

PAP sends credentials in cleartext during a two-way handshake, so it’s generally discouraged for anything beyond legacy compatibility requirements. Here’s the configuration for completeness:

On R1 (authenticating R2):

R1(config)# username R2 password Cisco123
R1(config)# interface Serial0/0/0
R1(config-if)# ppp authentication pap

On R2 (sending credentials to R1):

R2(config)# interface Serial0/0/0
R2(config-if)# ppp pap sent-username R2 password Cisco123

Step 3: Configure CHAP Authentication (Recommended)

CHAP is preferred because it never sends the password itself over the link — instead, it uses a challenge/response exchange with an MD5 hash, so credentials aren’t exposed even to on-path observation.

On R1:

R1(config)# hostname R1
R1(config)# username R2 password Cisco123
R1(config)# interface Serial0/0/0
R1(config-if)# ppp authentication chap

On R2:

R2(config)# hostname R2
R2(config)# username R1 password Cisco123
R2(config-if)# ppp authentication chap

Critical detail: the username configured on each router must match the hostname of the remote router, and the password must be identical on both sides — CHAP authentication fails immediately if these don’t align exactly.

Step 4: Two-Way (Mutual) CHAP Authentication

The configuration above already provides mutual authentication by default in modern IOS, since both routers challenge each other. If you want to be explicit or troubleshoot one-way behavior, verify both directions independently using debug output (see the troubleshooting section).

Step 5: PPP Multilink (MLPPP) Configuration

If you have multiple serial links between the same two routers and want them to act as one logical, higher-bandwidth PPP connection:

R1(config)# interface Multilink1
R1(config-if)# ip address 10.0.12.1 255.255.255.252
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1

R1(config)# interface Serial0/0/0
R1(config-if)# no ip address
R1(config-if)# encapsulation ppp
R1(config-if)# ppp multilink group 1

R1(config)# interface Serial0/0/1
R1(config-if)# no ip address
R1(config-if)# encapsulation ppp
R1(config-if)# ppp multilink group 1

Repeat symmetrically on R2. The Multilink interface becomes the logical endpoint carrying the IP address and authentication configuration, while the physical serial interfaces are bound into the bundle.

Step 6: Verification

Check PPP/LCP negotiation state:

R1# show interfaces Serial0/0/0
Serial0/0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 10.0.12.1/30
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP, CDPCP

LCP Open combined with Open: IPCP confirms both the link and network layer negotiation completed successfully — this is exactly what you want to see.

Check CHAP-specific status:

R1# show interfaces Serial0/0/0 | include LCP|CHAP
  Encapsulation PPP, LCP Open

Verify the PPP session details with debugging (lab/maintenance window recommended):

R1# debug ppp authentication
*Mar  1 00:12:33.123: Se0/0/0 PPP: Using default call direction
*Mar  1 00:12:33.124: Se0/0/0 PPP: Authorization required
*Mar  1 00:12:33.126: Se0/0/0 CHAP: O CHALLENGE id 3 len 23 from "R1"
*Mar  1 00:12:33.140: Se0/0/0 CHAP: I RESPONSE id 3 len 23 from "R2"
*Mar  1 00:12:33.142: Se0/0/0 CHAP: O SUCCESS id 3 len 4

This confirms R1 successfully challenged R2 and validated its response.

Real-World Enterprise Scenario: Legacy Branch WAN with Redundant Serial Links

Consider a branch office still running two T1 serial circuits to headquarters for redundancy and aggregate bandwidth, prior to a planned migration to broadband/SD-WAN. Multilink PPP bundles both T1s into a single logical 3 Mbps connection, providing both increased throughput and automatic graceful degradation — if one T1 fails, the Multilink bundle continues operating at reduced capacity on the remaining link rather than dropping the entire connection. CHAP authentication is applied at the Multilink interface level so credential validation happens once for the logical bundle rather than needing separate authentication per physical member link.

Security Best Practices

Always prefer CHAP over PAP — PAP’s cleartext credential exchange is a real, avoidable risk on any link where interception is plausible
Store PPP usernames/passwords using encrypted service password settings (service password-encryption) at minimum, though this is weak obfuscation, not real encryption — treat sensitive WAN credentials with the same care as any other credential store
Where the underlying transport is untrusted (public networks, some legacy leased-line scenarios), layer IPsec on top of PPP for actual confidentiality, since PPP authentication verifies identity but doesn’t encrypt payload data
Avoid reusing the same CHAP username/password pair across many router pairs; unique credentials per link limit blast radius if one is compromised

Common Configuration Mistakes

CHAP username not matching the peer’s hostname exactly (case-sensitive) — the single most common cause of CHAP failures
Mismatched passwords between the two routers’ username entries — CHAP requires bit-for-bit identical passwords on both sides
Forgetting encapsulation ppp on one end while the other end has already changed from HDLC, causing the link to never come up at Layer 2
Configuring multilink group membership on physical interfaces but forgetting to remove IP addressing from them, causing IP conflicts with the Multilink interface
Assuming PAP is sufficient for anything beyond a legacy compatibility requirement

Troubleshooting Checklist

show interfaces <serial> — confirm LCP Open and NCP (IPCP) reached Open state
debug ppp negotiation — see LCP/NCP option negotiation in detail (lab/maintenance window only)
debug ppp authentication — confirm CHAP challenge/response or PAP exchange succeeds
Double-check username/hostname pairing and password match between routers
show ppp multilink — verify bundle membership and link status for MLPPP deployments

Performance Tuning

Adjust MTU/MRU if you observe fragmentation issues over PPP links carrying jumbo or non-standard frame sizes
For Multilink PPP, monitor per-member link utilization with show ppp multilink to confirm traffic is actually distributing across bundle members as expected
Enable PPP compression (compress predictor or compress mppc where supported) on bandwidth-constrained legacy serial links if CPU headroom allows, trading router processing for effective throughput gains

FAQs

What’s the difference between PAP and CHAP? PAP sends the username and password in cleartext during a simple two-way handshake; CHAP uses a challenge/response mechanism with MD5 hashing, so the actual password is never transmitted over the link.

Does PPP work over Ethernet? Not directly — PPP is designed for point-to-point serial-style links. PPPoE (PPP over Ethernet) encapsulates PPP frames within Ethernet for broadband access scenarios like DSL.

Is CHAP authentication mutual by default? Yes, when both sides are configured with ppp authentication chap and matching username/password entries, each router challenges the other independently.

What happens if CHAP usernames don’t match hostnames? Authentication fails — CHAP relies on the username matching the peer’s actual hostname to look up the correct password locally.

Summary

PPP’s real strength lies in its flexibility and built-in authentication, something legacy HDLC never offered. Getting it running correctly comes down to a few disciplined habits: always prefer CHAP over PAP, make sure usernames match hostnames exactly with identical passwords on both sides, and use show interfaces alongside debug ppp negotiation/debug ppp authentication whenever a link refuses to come up. Once you’re comfortable with these fundamentals, Multilink PPP is a natural next step for bonding multiple physical links into one resilient, higher-bandwidth logical connection.

References

Cisco: Configuring PPP
Cisco IOS Wide-Area Networking Configuration Guide: PPP Authentication