iBGP: Synchronizing the Internet

Peering, Backbones, Stubs, Mangles of Meshes

Internal BGP is a mechanism to provide more information to your internal routers. Most of last week’s installment on Understanding BGP focused on a stub configuration, where a single router served all the BGP sessions for an autonomous system (AS). This time we’ll delve into the practical use of BGP: iBGP and what it takes to accomplish multihoming.

If you were to add a second BGP router and connect it to another peer, your network wouldn’t gain much until the IGP knew what to do. There are a few options here, and one is a grave mistake. You cannot simply redistribute all of the Internet routes into your IGP and hope for the best. It’s really fun to do, actually, because the OSPF process normally takes down the router. Also, you need to get the routes learned from one border router to another, but that information will be lost unless both border routers are speaking BGP.

The solution is to set up an internal BGP peering between all of your border routers. The conventional wisdom is that your network will consist of a core (or transit, or backbone, or whatever you’d like to call it) network where this iBGP runs, and a default route will be injected into the widely used IGP (OSPF or other). As long as the IGP gets packets into the backbone, the routers there will be able to choose the best exit strategy.

Backbone networks can be quite complex, and the AS_PATH provided in BGP isn’t robust enough to guarantee the absence of loops. This means that iBGP will not advertise any routes it learns from its peers, which seems to make it useless, right? Not quite: the limitation means that every iBGP router must peer with every other iBGP router. This is also referred to as a full mesh. This is also a big pain.