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 awayR1(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 loopback0R1# 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 correctlyR1(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 BgpSecure2026R1# 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 disruptionR2(config)# router bgp 65120
R2(config-router)# neighbor 1.1.1.1 password WrongPassword999R1# 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 validatesKey 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.