iBGP: Synchronizing the Internet - page 2
Peering, Backbones, Stubs, Mangles of Meshes
Thankfully these terms are actually intuitive. A confederation is simply a separate internal AS. The idea is to break up the internal AS into smaller parts and tie them together with the external BGP. Each internal group will still have a full mesh, but that can be as fine-grained as you’d like. Using confederations is a configuration hassle, so most people opt for the alternative: reflectors. A route reflector is an iBGP router that will readvertise routes to other iBGP routers. This works by creating clusters of iBGP routers, and connecting them with a reflector.
A reflector will not send every route either; instead it only sends the best paths to its peers. When using a route reflector, there is a problem of convergence. Recall that “convergence” means that every router in the network has the same information, or more precisely, they all have a consistent view of the topology.
Synchronization is an important concept in BGP, especially when you’re a transit AS that ships traffic between peers. Let’s say we have two routers connected to separate AS peers, and we also have a multi-hop iBGP setup. So we have two routers (routers A and B) speaking EBGP with other AS’s, and iBGP between themselves, but indirectly. If a route for our peer on the other side of router A gets advertised into the iBGP mesh, and subsequently router B advertises it to its peer, a blackhole could happen. Why? Because it’s likely that the peer on the other side of B will want to immediately start sending traffic to the peer on the other side of A, but our iBGP may not have converged yet. Some of the interior iBGP routers may not know the way to the AS on the other side of A.