eBGP multihop and loopback peering

Why change a session that already works?

Our directly connected eBGP session uses R1 Gi0/0 192.0.2.2/30 and ISP A Gi0/0 192.0.2.1/30. R1 is company AS 64500; ISP A is AS 64501. That design is simple and often suitable. A different design may peer using loopback interfaces, which are software interfaces with stable addresses. This can help when several physical paths connect the same two routers.

In this isolated Cisco IOS XE 17.x-style exercise, we move the provider session to R1 Loopback0 10.255.0.1/32 and ISP A Loopback0 10.255.1.1/32. R1 may already have its loopback from the iBGP lesson. The company prefix remains 198.51.100.0/24 and the provider example remains 203.0.113.0/24. We change the session endpoints, not the destination prefixes.

The /32 mask identifies one endpoint address. The router IDs identify the BGP processes and are not the addresses to use in these neighbour statements. All public-looking addresses and AS numbers remain documentation values; the 10.x addresses are private lab addresses.

Three checks must succeed independently

1. IP reachability: each router needs a route to the remote loopback and a return route to its own loopback.
2. Source matching: the TCP source must match the neighbour address configured on the other router. Use update-source for the local loopback.
3. eBGP connected check and TTL: conventional IOS eBGP expects a neighbour on a directly connected subnet and normally sends with TTL 1. Loopback peer addresses are not on that connected /30, even though the routers share a cable.

TTL (time to live) limits the routers a session IP packet can cross. A forwarding router reduces it, and a packet whose TTL expires is discarded. It is separate from BGP's AS_PATH, which lists autonomous systems in an announcement. Raising a session TTL does not prepend AS numbers or change user-packet TTLs.

Reachability, source address, connected-neighbour checking and TTL are separate requirements. A successful ping checks only part of the session setup.

Build endpoint routes before changing BGP

Continue with the working first eBGP lab. Keep the existing physical /30, company LAN, ISP example Loopback10 and exact COMPANY-ONLY and ISPA-ONLY prefix lists. The following commands start in global configuration mode. The explicit host routes provide session reachability independently of BGP.

On R1, test ping 10.255.1.1 source Loopback0. On ISP A, test ping 10.255.0.1 source Loopback0. If either fails, inspect the host routes, link and any packet filters. Do not expect the future BGP session to learn the routes needed to establish itself.

Move the neighbour to the loopback

ebgp-multihop 2 permits this external loopback neighbour and sets an outgoing TTL of 2. This is sufficient for our adjacent-router example. It is not a general recommendation to use 2 for every topology: a session crossing additional transit routers needs a deliberately chosen adequate value.

Remove the old physical-address peer on both routers and add the new one. That resets the provider session and temporarily removes its ordinary learned paths. In this isolated lab we expect that interruption. An existing internal R1–R2 peer can remain configured; these commands do not remove it.

When is disable-connected-check enough?

For adjacent routers on a single shared link, IOS also supports neighbor ... disable-connected-check. It permits the non-connected loopback neighbour without raising TTL from its normal value of 1. Both routers still need loopback routes and matching update-source settings.

As an alternative exercise, replace the multihop line on each side with its peer-specific disable-connected-check line. Do not add this as a supposed cure for an actual multi-router path: the TTL would still need to reach the remote endpoint.

The trade-off is scope. Multihop allows a broader routed relationship than a directly connected session. Keep the intended TTL small enough for the known path, restrict TCP 179 to authorised endpoints and consider supported TTL-security designs separately. A high TTL is not authentication, and this lesson does not configure TTL security or BGP authentication.

Verify the endpoint before the advertised prefix

R1#show ip bgp neighbors 10.255.1.1
BGP neighbor is 10.255.1.1, remote AS 64501, external link
  BGP state = Established, up for 00:03:10
  ...
  Local host: 10.255.0.1, Local port: 49152
  Foreign host: 10.255.1.1, Foreign port: 179

Then check show ip bgp summary, show ip bgp 203.0.113.0 255.255.255.0 and show ip route 203.0.113.1. The next-hop field of an advertised prefix is a forwarding attribute; read the actual output rather than assuming it must equal the foreign-host TCP address. If R2 still receives provider routes through R1, retain the iBGP next-hop-self setting so R2 uses a reachable internal next hop.

A short troubleshooting lab

1. Record the established peer address and local host. Confirm the original 192.0.2.1 neighbour is gone and the new 10.255.1.1 neighbour is present.
2. On R1, remove the host route with no ip route 10.255.1.1 255.255.255.255 192.0.2.1. With no other route to that /32 in this lab, the peer becomes unreachable. Raising multihop TTL cannot repair it.
3. Restore the host route, verify the source-loopback ping, then confirm the session and provider prefix recover. If only the session fails, compare remote-as, update-source, connected-check or multihop settings and TCP filters on both sides.

Technical references: Cisco's iBGP/eBGP loopback peering examples and Cisco command reference for ebgp-multihop, disable-connected-check and update-source. Example commands and output are documentation-based; no running-router result is claimed.

Check your loopback peering decisions