OSPF as the underlay for BGP
Most networks that run BGP also run an IGP, and they have different jobs:
| OSPF | BGP | |
|---|---|---|
| Carries | Loopbacks and internal links — hundreds of routes | Customer and internet prefixes — up to a full table |
| Optimises for | Fast convergence, shortest internal path | Policy, stability, scale |
| Trust model | Everyone in the area is trusted | Every neighbour is filtered |
| Loop prevention | Identical database + SPF | AS_PATH (eBGP), split horizon/RR attributes (iBGP) |
Three ways OSPF directly shapes your BGP:
- iBGP sessions run between loopbacks, and OSPF is what makes those loopbacks reachable. Lose OSPF and every iBGP session drops after its hold timer.
- BGP next hops are resolved through the IGP. A BGP path whose NEXT_HOP isn't in the routing table is invalid. That's why you either set
next-hop-selfon border routers or carry the external link subnets in OSPF (usually aspassiveinterfaces). - Best-path step 8 — lowest IGP metric to the next hop — is OSPF cost. When the BGP attributes tie, each router exits at the nearest edge ("hot-potato" routing). Changing an OSPF cost can move external traffic.
Never redistribute a full BGP table into OSPF. Every router would flood and run SPF over hundreds of thousands of external LSAs. The IGP carries infrastructure; BGP carries customers and the internet.
- OSPF carries the loopbacks. Inside AS 64500, OSPF advertises every router's loopback and every internal link. It carries nothing from the internet — the IGP stays small and fast.
- Both edges learn the same prefix. Each edge router learns 203.0.113.0/24 over eBGP with identical LOCAL_PREF, AS_PATH length, ORIGIN and MED.
- iBGP next hops are loopbacks. The edges advertise the prefix to R3 over iBGP with next-hop-self, so the BGP next hops are 10.255.0.1 and 10.255.0.2. R3 can only use these paths because OSPF gave it routes to those loopbacks.
- Hot potato: the IGP breaks the tie. Every BGP attribute ties, so R3 reaches step 8 of best-path: lowest IGP metric to the next hop. OSPF says Edge1 costs 10 and Edge2 costs 50 — traffic leaves via Edge1 and ISP A.
- OSPF changes, BGP follows. If the R3–Edge1 link fails, OSPF reconverges: Edge1 is now 150 away (50 to Edge2, plus 100 across), while Edge2 is still 50. R3's best path flips to Edge2 and ISP B without a single BGP UPDATE being sent.
Check your understanding
R3 receives 203.0.113.0/24 from Edge1 over iBGP with NEXT_HOP 10.255.0.1, but show bgp marks the path as inaccessible. What's wrong?
- Edge1's loopback isn't advertised into OSPF, so R3 has no route to the next hop
- Edge1 needs a higher LOCAL_PREF
- R3 needs an eBGP session to ISP A
- OSPF must redistribute 203.0.113.0/24