Day 44 — Loopback Peering, update-source and eBGP Multihop

1. Opening

Directly connected eBGP is simple: each router normally peers to the adjacent interface address. Loopback peering improves endpoint stability but introduces two extra requirements—explicit source selection and enough IP and TTL reachability to reach a non-direct endpoint.

A session-engineering problem should be solved from the bottom up. Before modifying route policy, prove endpoint reachability, source address, TCP behavior, TTL/security controls, authentication and negotiated BGP parameters. An Established session is the result of all of those layers agreeing.

2. Concept and standards behavior

RFC 4271 runs BGP over TCP but does not prescribe Cisco update-source or ebgp-multihop CLI. Cisco uses those controls to select a stable source and permit eBGP sessions beyond the directly connected hop expectation. The underlay must carry routes to both loopbacks in both directions.

The engineering boundary matters: RFC behavior defines interoperable protocol rules, while dynamic-neighbor syntax, password configuration, peer templates and some security commands are implementation-specific. Exact syntax and feature support must therefore be verified on the actual IOS XE platform and release used in the lab or production network.

3. Scenario

EDGE-A AS65010 peers from Loopback0 192.0.2.10 to EDGE-B AS65020 Loopback0 192.0.2.20. Physical transit is 198.51.100.0/30. Static or IGP reachability to the loopbacks exists before BGP.

Success criteria

1. The intended TCP endpoints and source addresses are explicit.
2. BGP reaches Established without weakening unrelated security controls.
3. Negotiated capabilities match the required address families/features.
4. A negative test proves an unauthorized or incorrectly formed session fails.
5. Rollback returns the neighbor relationship to the captured baseline.

4. Topology diagram

A matching editable SVG and PNG are stored under media/diagrams/.

5. Prerequisites

• Cisco IOS XE 17.18.x documentation baseline.
• Documentation-safe IPv4 addressing only.
• Stable underlay reachability before BGP troubleshooting.
• Independent management access.
• Time synchronization and logging for authentication/failure analysis.
• Pre-change capture of neighbor state and relevant TCP/BGP diagnostics.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 neighbor 192.0.2.20 remote-as 65020
 neighbor 192.0.2.20 update-source Loopback0
 neighbor 192.0.2.20 ebgp-multihop 2
 !
 address-family ipv4
  neighbor 192.0.2.20 activate
 exit-address-family

Any authentication secret shown in a lab must be a non-production placeholder. Never copy a tutorial key into production.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors
show tcp brief all
show ip route
show logging

When the session does not reach Established, identify the last successful layer: IP reachability, TCP establishment, BGP OPEN exchange, capability negotiation, or post-OPEN KEEPALIVE.

8. Controlled modification

Move the eBGP endpoint from the physical address to Loopback0, preserving underlay routes. Verify TCP endpoints before and after the change.

Capture the expected state transition before changing configuration. If the modification is expected to reset the TCP session, state that explicitly and preserve logs.

9. Fault injection

Illustrative lab — not a real incident.

Remove the return route to 192.0.2.10/32 on EDGE-B while leaving forward reachability from EDGE-A intact. The failure demonstrates asymmetric endpoint reachability.

Inject only one fault at a time. A failed session is useful evidence only if the experiment can identify which layer rejected it.

10. Step-by-step troubleshooting

1. Confirm the configured neighbor address or dynamic range.
2. Confirm local and remote source addresses.
3. Verify a valid route exists to the remote endpoint.
4. Verify return-path reachability.
5. Inspect TCP state and port 179 behavior.
6. Validate TTL, multihop and GTSM assumptions.
7. Validate authentication configuration and key-selection state where used.
8. Inspect BGP FSM state.
9. Inspect OPEN message parameters and negotiated capabilities.
10. Read the NOTIFICATION/error evidence rather than repeatedly clearing the session.
11. Correct the smallest proven cause.
12. Re-run both positive and negative tests.

11. Root cause and correction

The cause is missing return reachability to the chosen BGP source, not an AS-number or route-map problem. Restore the underlay route and verify the TCP endpoints.

12. Post-fix verification

Confirm TCP stability, BGP Established state, expected AFI/SAFI activation, route exchange, absence of recurring NOTIFICATION messages, and intended rejection of the negative test.

13. Rollback

Restore the exact prior neighbor/session configuration. Authentication or TTL changes need a synchronized rollback plan on both peers. Roll back if the session cannot be restored within the approved change window, if another peer is affected, or if the security posture is weakened beyond the approved design.

14. Deep-dive engineering notes

Why loopbacks help

A loopback endpoint survives loss of one physical interface if another underlay path still reaches it. That can decouple session identity from a single link.

Why loopbacks add complexity

The remote router must route back to the exact source. update-source does not create that route. Likewise ebgp-multihop does not repair reachability; it changes the permitted TTL/hop behavior.

Failure modes to distinguish

Wrong neighbor address, wrong source interface, missing /32 route, missing return route, TTL too small, authentication bound to the wrong peer, and ACL/control-plane filtering can all produce superficially similar session failures.

Design discipline

Use the smallest multihop value compatible with the topology and pair it with GTSM where appropriate and supported rather than setting an arbitrarily large TTL.

15. Production lessons

• Treat transport, security and BGP negotiation as separate diagnostic layers.
• Never weaken authentication or TTL controls merely to force Established state.
• Feature support is platform/release specific; standards support does not guarantee identical CLI support.
• Capture negative tests as part of session acceptance.
• Document which side initiates, what source address is expected, and what capabilities are required.

16. Knowledge check

1. Why can successful IP reachability coexist with a failed BGP session?
2. Which evidence distinguishes TCP failure from an OPEN/capability failure?
3. Why is temporarily removing authentication a poor troubleshooting default?

Answers

1. Reachability proves only IP forwarding; TCP, TTL controls, authentication, FSM parameters and capabilities can still fail.
2. TCP state plus BGP neighbor/error/NOTIFICATION evidence.
3. It changes the security boundary and can hide the actual mismatch instead of proving it.

17. Sources

• RFC 4271 — BGP-4
• Cisco IOS XE 17.18.x — BGP configuration guide
• Cisco IOS XE 17.x — basic BGP network configuration