[j-nsp] BGP full mesh or route reflector

[Aaron1]

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 <juniper-nsp at puck.nether.net> 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 <saku at ytti.fi> 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
>>> <juniper-nsp at puck.nether.net> 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 juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>> 
>> 
>> --
>>  ++ytti
>> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp