Two ways to address a session
Why BGP sessions between loopbacks survive link failures and use parallel links, and what they need to work: an IGP or static routes, update-source, the eBGP connected check, and BFD. Every failure is reproduced on two real VyOS routers.
By the end you will be able to:
- Explain the trade-offs between BGP sessions on interface addresses and on loopbacks
- Show why an interface-address session blackholes traffic, then fails for good, when its link dies silently
- Build an iBGP session between loopbacks over OSPF, and show it surviving a link failure while using both links
- Build an eBGP session between loopbacks with static routes, and explain why disable-connected-check or ebgp-multihop is needed
- Use BFD so static routes notice a dead next hop within a second
- Choose loopback or interface peering for transit, IX, customer and internal sessions
Prerequisites: BGP Fundamentals, OSPF Fundamentals
Every BGP session runs over TCP between two IP addresses. You choose which ones, and there are two options:
- Interface addresses: the addresses on the link between the two routers, for example 192.0.2.0 and 192.0.2.1 on a /31. Simple, needs nothing else, and it's how most sessions with transit providers and IXs are built.
- Loopback addresses: a /32 on each router's loopback interface that isn't tied to any physical link. The session needs something else (an IGP or static routes) to tell each router how to reach the other's loopback, and the session is sourced from the loopback with
update-source.
The difference only shows when there's more than one path between the routers, or when something breaks. This lesson builds both on two VyOS routers joined by two parallel links, then breaks one link the way real links usually break: R2's end goes dead, but R1's interface stays up (think of a fault beyond a media converter, a patch panel or a switch in between).
| Interface addresses | Loopback addresses | |
|---|---|---|
| Survives the loss of one link | No: the session is tied to the link | Yes, while any path to the loopback remains |
| Uses parallel links | One session per link, or only one link | One session, traffic spread across every path (ECMP) |
| Needs | Nothing extra | An IGP or static routes to the loopbacks, and update-source |
| Identity | Changes if you renumber a link | One stable address per router: same as router ID, used in logs, filters and monitoring |
| Failure detection | Hold timer (up to 180 s by default), unless the router sees its own interface go down (eBGP only) | Whatever finds the loopback unreachable: the IGP's timers, or BFD |
Throughout the lab, R2 announces 203.0.113.0/24, and the question is always the same: can R1 still reach it?
- Session on link A's addresses. iBGP between 192.0.2.0 and 192.0.2.1. Link B is idle: nothing uses it.
- Link A breaks. R2's side of link A dies. R1's interface stays up, so for up to 180 seconds the session still looks established while traffic is lost. Then it drops, and can't come back over link B.
- Session between loopbacks. OSPF on both links makes each loopback reachable two ways. One session, and traffic to 203.0.113.0/24 uses both links.
- Link A breaks again. OSPF removes link A; the loopback is still reachable via link B, so the session stays up and traffic moves across.
- eBGP between loopbacks, with BFD. R2 becomes AS64501. Static routes over both links reach its loopback, BFD removes a link's static next hop within a second of it failing, and one eBGP session uses both circuits.
Check your understanding
What does a BGP session between loopbacks need that an interface-address session doesn't?
- A route to the peer's loopback, and update-source set to our own loopback
- A route reflector
- A different AS number on each loopback
- Nothing; loopbacks are always reachable