Re: [j-nsp] Hardware configuration for cRPD as RR
Saku Ytti via juniper-nsp <[email protected]>
| Newsgroups | gmane.network.nsp.juniper |
|---|---|
| Message-ID | <CAAeewD8vgXJ-As61u80hQhSv=js379wmVNZdL-8mRyp1jUNT0A@mail.gmail.com> |
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 <[email protected]> wrote: > > Why not both add-path + ORR? > -- > > Thomas Scott > Sr. Network Engineer > +1-480-241-7422 > [email protected] > > > On Fri, Dec 8, 2023 at 11:57 AM Saku Ytti via juniper-nsp <[email protected]> wrote: >> >> On Fri, 8 Dec 2023 at 18:42, Vincent Bernat via juniper-nsp >> <[email protected]> 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 [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