Migrating to an RR design later would seem to add RR, full mesh to it, then one by one start moving routers to RR-client connections, til complete
Aaron > On Dec 5, 2025, at 4:07 PM, Johan Borch via juniper-nsp > <[email protected]> wrote: > > Thanks, this is a quite small network at the moment. Three edge routers > (with full tables) and a bunch (9) PE routers (these will be able to handle > full table). I guess my only option right now is to run RR on my three edge > routers, not sure if that is a good idea. > > A bunch of virtual RRs sound like a good solution. But we can't add more > cost at the moment, is it hard to migrate towards a RR design at a later > stage? > > Johan > >> On Fri, Dec 5, 2025 at 3:39 PM Saku Ytti <[email protected]> wrote: >> >> I would generally recommend RR on anything more than 2 router setup. >> >> RR gives redundancy on the signalling path, one iBGP flap doesn't >> cause an outage. >> >> With ORR and ADDPATH you're not really losing anything. >> >>> On Fri, 5 Dec 2025 at 14:36, Johan Borch via juniper-nsp >>> <[email protected]> wrote: >>> >>> Hi! >>> >>> In an SR/MP-BGP underlay, will it have a significant impact on device >>> performance if we use a full iBGP mesh instead of route reflectors or >> other >>> drawbacks? Let’s say we will end up with around 100 PE routers. These >>> routers will not carry an excessive number of prefixes (no full tables). >>> We can ignore the configuration part as configuration is auto-generated. >>> >>> Br >>> Johan >>> _______________________________________________ >>> juniper-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> >> -- >> ++ytti >> > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
