[j-nsp] BGP full mesh or route reflector

[Saku Ytti]

On Wed, 21 Jan 2026 at 09:30, James Bensley via juniper-nsp
<juniper-nsp at puck.nether.net> wrote:

> Also considering some other factors; I have worked on networks handling emergency call routing, air traffic control, and other sensitive traffic. With a full iBGP mesh, convergence is at it's quickest (depending on the update groups); interface goes on router A, it informs router B directly, immediately. With RRs, a withdraw is processed as fast as your slowest RR because all RRs need to withdraw the route before the PE finally drops the route. On the current network I work, due to the large geographical scale (and exhausting the number of ORR groups our vendor supports) we have multiple RR groups peered together, and with millions of paths, convergence won't be fast.

If rapid convergence is relevant, then you really should already have
backup paths at least in RIB, ideally in FIB as well. Your route
invalidation should not depend on BGP either, it could depend on IGP
next-hop being invalidated. But if you don't want quick invalidation,
for example you don't want to expose eBGP CE next-hop in IGP, you can
always during convergence have the old egress PE stitch it to new
egress PE, so while ingress PEs are using old and new as convergence
progresses both cases are going to end up at new egress PE in atomic
convergence event, either directly or by tramboning through oldPE.

You can definitely configure RR poorly and end up having some
downsides to full-mesh.

But full-mesh has other downsides than scale, it is also fragile, you
lose any one session and you have an outage. And your initial
convergence is much longer without RR.

-- 
  ++ytti