Hands-On Lab: Configuring BGP Multihop and eBGP Authentication

Lab Objective

Configure an eBGP session between two routers' loopback addresses rather than their directly connected interfaces, enabling ebgp-multihop to allow the session across more than one router hop, then add MD5 authentication and verify a mismatched password prevents the session from establishing.

Lab Purpose

Every eBGP session covered earlier in this series used directly connected interface addresses, which by default limits eBGP to a TTL of 1 — appropriate for a direct link but insufficient when peering needs to occur between loopback addresses reachable only via an intermediate hop. Authentication, meanwhile, protects any BGP session — eBGP or iBGP — from a spoofed peer attempting to inject false routing information.

Lab Topology

R1 (AS 65110) ---- intermediate hop ---- R2 (AS 65120)

R1 Loopback0: 1.1.1.1/32
R2 Loopback0: 2.2.2.2/32
(reachable via static routes or an IGP,
already configured, requiring 2 hops)

Task 1: Attempt Standard eBGP Peering Between Loopbacks

Configure a neighbor statement using the loopback addresses without ebgp-multihop, and observe the session fail to establish.

Task 2: Enable eBGP Multihop

Configure ebgp-multihop on both routers with a TTL value sufficient for the actual hop count.

Task 3: Configure the Update-Source

Configure each router to source its BGP packets from its own loopback interface, required for loopback-based peering to work correctly.

Task 4: Verify the Session Establishes

Confirm the eBGP neighbor relationship reaches Established state.

Task 5: Add MD5 Authentication and Verify a Mismatch Fails

Configure matching MD5 passwords on both routers, confirm the session remains stable, then deliberately mismatch one side's password and observe the session fail.

Solution and Verification

R1(config)# router bgp 65110
R1(config-router)# neighbor 2.2.2.2 remote-as 65120

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   0       0        Idle
-- Stuck in Idle -- standard eBGP defaults
-- to a TTL of 1, which is insufficient to
-- reach a loopback two hops away

R1(config)# router bgp 65110
R1(config-router)# neighbor 2.2.2.2 ebgp-multihop 3
R1(config-router)# neighbor 2.2.2.2 update-source loopback0

R2(config)# router bgp 65120
R2(config-router)# neighbor 1.1.1.1 ebgp-multihop 3
R2(config-router)# neighbor 1.1.1.1 update-source loopback0

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   8       7        0
-- Established (numeric PfxRcd), confirming
-- the multihop session now works correctly

R1(config)# router bgp 65110
R1(config-router)# neighbor 2.2.2.2 password BgpSecure2026

R2(config)# router bgp 65120
R2(config-router)# neighbor 1.1.1.1 password BgpSecure2026

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   9       8        0
-- Still Established, matching passwords
-- caused no disruption

R2(config)# router bgp 65120
R2(config-router)# neighbor 1.1.1.1 password WrongPassword999

R1# show ip bgp summary

Neighbor    V   AS   MsgRcvd  MsgSent  State/PfxRcd
2.2.2.2     4   65120   0       0        Idle
-- The session drops entirely once passwords
-- mismatch -- TCP itself refuses the
-- connection since the MD5 signature on
-- incoming segments no longer validates

Key Takeaway

eBGP's default TTL of 1 is a deliberate security-adjacent default assuming direct connectivity, and ebgp-multihop combined with update-source is the standard pairing required whenever that assumption does not hold, such as loopback-based peering — MD5 authentication operates at the TCP layer underneath BGP itself, which is why a password mismatch prevents the underlying TCP session from forming at all rather than merely being rejected after BGP's own message exchange begins.