[j-nsp] Hardware configuration for cRPD as RR

Saku Ytti saku at ytti.fi
Fri Dec 8 12:16:41 EST 2023


I tried to advocate for both, sorry if I was unclear.

ORR for good options, add-path for redundancy and/or ECMPability.

On Fri, 8 Dec 2023 at 19:13, Thomas Scott <tscott at digitalocean.com> wrote:
>
> Why not both add-path + ORR?
> --
>
> Thomas Scott
> Sr. Network Engineer
> +1-480-241-7422
> tscott at digitalocean.com
>
>
> On Fri, Dec 8, 2023 at 11:57 AM Saku Ytti via juniper-nsp <juniper-nsp at puck.nether.net> wrote:
>>
>> On Fri, 8 Dec 2023 at 18:42, Vincent Bernat via juniper-nsp
>> <juniper-nsp at puck.nether.net> wrote:
>>
>> > On 2023-12-07 15:21, Michael Hare via juniper-nsp wrote:
>> > > I recognize Saku's recommendation of rib sharding is a practical one at 20M routes, I'm curious if anyone is willing to admit to using it in production and on what version of JunOS.  I admit to have not played with this in the lab yet, we are much smaller [3.5M RIB] worst case at this point.
>> >
>> > About the scale, I said routes, but they are paths. We plan to use add
>> > path to ensure optimal routing (ORR could be another option, but it is
>> > less common).
>>
>> Given a sufficient count of path options, they're not really
>> alternatives, but you need both. Like you can't do add-path <max>, as
>> the clients won't scale. And you probably don't want only ORR, because
>> of the convergence cost of clients not having a backup option or the
>> lack of ECMP opportunity.
>>
>> --
>>   ++ytti
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti


More information about the juniper-nsp mailing list