Lab: a provider core — OSPF underneath, iBGP on top
The two-layer design every service provider uses, small enough to hold in your head.
A provider core runs two routing protocols and they do different jobs. This lab is the smallest honest version of that.
The design
- OSPF carries only the infrastructure: the links between routers and
- iBGP carries the customer routes, peered loopback to loopback, which
R1(config)# router bgp 65000
R1(config-router)# neighbor 10.255.0.2 remote-as 65000
R1(config-router)# neighbor 10.255.0.2 update-source Loopback0
Do this
- Bring OSPF up on the core links and the loopbacks. Confirm every router can
- Peer iBGP between loopbacks, with
update-source. - Advertise a customer prefix at one edge and see it at the other.
The point
update-source Loopback0 is the line that makes this design work. A BGP
session sourced from a physical interface dies when that interface does; one
sourced from a loopback survives as long as any path exists, because
OSPF will find another. That is the entire reason for the two layers.
Try breaking it
- Omit
update-sourceand then shut the link the session happens to be using. - Shut a core link with the session sourced from the loopback and watch BGP
- Remove the loopback from OSPF and watch the iBGP session fail to establish
Join the discussion
Replies, likes and bookmarks live in the community half, which needs a free account. This lab opens in the browser — no install, no plugin.
Open this in the communityEverything publishedHow this works