On Wed, 21 Jan 2026 at 09:30, James Bensley via juniper-nsp <[email protected]> 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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
