LogoفارسیFA

Hands-On Lab: PPP Authentication Using CHAP (Method 2 — ppp chap hostname/password)

This hands-on lab configures CHAP authentication using the alternative ppp chap hostname and ppp chap password interface commands rather than matching local usernames, a method that scales far better when a single router has many WAN links to different peers.

PPP CHAP HostnamePPP CHAP PasswordScalable CHAP Configuration

~3 min read · Updated Sep 12, 2026

Lab Objective

Configure CHAP authentication between two routers using the interface-level ppp chap hostname and ppp chap password commands instead of the local username database method covered in the previous lab, and verify the resulting authentication succeeds.

Lab Purpose

The matching-username method from the previous lab works well for a single point-to-point link, but becomes unwieldy on a router with dozens of serial interfaces, each needing a different username entry for a different peer. The ppp chap hostname and ppp chap password commands configure the identity presented on a per-interface basis, avoiding the need for a large, centrally managed username database entry per peer.

Lab Topology

R1 ---- Serial0/0/0 (DTE) ------ Serial0/0/0 (DCE) ---- R2

R1: 10.13.13.1/30
R2: 10.13.13.2/30

Both routers already run PPP encapsulation

Task 1: Configure Interface-Level CHAP Identity on R1

On R1's serial interface, configure a specific CHAP hostname and password to present during authentication, rather than relying on R1's actual system hostname.

Task 2: Configure Interface-Level CHAP Identity on R2

On R2's serial interface, configure a matching CHAP hostname and password that R1 will expect to receive.

Task 3: Enable CHAP Authentication

Enable CHAP authentication on both serial interfaces.

Task 4: Configure the Expected Username Entries

On each router, create a local username entry matching the CHAP hostname the OTHER router will present, with the shared password.

Task 5: Verify Authentication Succeeds

Confirm the link comes up and IP connectivity works.

Solution and Verification

R1(config)# username BranchB password SharedKey99
R1(config)# interface serial0/0/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp chap hostname BranchA
R1(config-if)# ppp chap password SharedKey99
R1(config-if)# ppp authentication chap

R2(config)# username BranchA password SharedKey99
R2(config)# interface serial0/0/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp chap hostname BranchB
R2(config-if)# ppp chap password SharedKey99
R2(config-if)# ppp authentication chap

R1# debug ppp authentication

PPP Serial0/0/0: CHAP challenge from BranchB
PPP Serial0/0/0: CHAP response received from BranchB
PPP Serial0/0/0: remote passed CHAP authentication

-- Notice the identity exchanged is "BranchB",
-- the configured CHAP hostname, rather than
-- R2's actual system hostname -- this is
-- exactly the flexibility this method provides

R1# show interfaces serial0/0/0

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

R1# ping 10.13.13.2

!!!!!
Success rate is 100 percent (5/5)

Key Takeaway

The ppp chap hostname command overrides what identity a specific interface presents during CHAP negotiation, decoupling it from the router's actual system hostname — this becomes essential on a hub router with many spoke connections, since it allows each individual interface to present a distinct identity matching whatever username entry that specific peer expects, without renaming the entire router.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Continue

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue
Previous ArticleNext Article