Re: [j-nsp] MX204 and IPv6 BGP announcements

On 2/6/24, 11:55 AM, "juniper-nsp on behalf of Mark Tinka via juniper-nsp" mailto:juniper-nsp-boun...@puck.nether.net> on behalf of juniper-nsp@puck.nether.net > wrote: > Typically, BGP will not originate a route to its neighbors unless it > already exists

Re: [j-nsp] MX204 and IPv6 BGP announcements

Thanks Mark for the quick reply. That was the validation I was looking for. The TAC tech was really unsure about what he was doing and I had to guide him through things, So this is very helpful. Thanks again. -Lee On Tue, Feb 6, 2024 at 8:54 AM Mark Tinka wrote: > > > On 2/6/24 18:48, Lee

Re: [j-nsp] Hardware configuration for cRPD as RR

On 2/6/24 18:53, Saku Ytti wrote: Not just opinion, fact. If you see everything, ORR does nothing but adds cost. You only need AddPath and ORR, when everything is too expensive, but you still need good choices. But even if you have resources to see all, you may not actually want to have a

Re: [j-nsp] MX204 and IPv6 BGP announcements

On 2/6/24 18:48, Lee Starnes via juniper-nsp wrote: Hello everyone, I was having difficulty in getting an announcement of a IPv6 /32 block using prefix-lists rather than redistribution of the IP addresses in from other protocols. We only have a couple /64 blocks in use at the moment but

Re: [j-nsp] Hardware configuration for cRPD as RR

On Tue, 6 Feb 2024 at 18:35, Mark Tinka wrote: > IME, when we got all available paths, ORR was irrelevant. > > But yes, at the cost of some control plane resources. Not just opinion, fact. If you see everything, ORR does nothing but adds cost. You only need AddPath and ORR, when everything is

[j-nsp] MX204 and IPv6 BGP announcements

Hello everyone, I was having difficulty in getting an announcement of a IPv6 /32 block using prefix-lists rather than redistribution of the IP addresses in from other protocols. We only have a couple /64 blocks in use at the moment but want to be able to announce the entire /32. In cisco, that

Re: [j-nsp] Hardware configuration for cRPD as RR

On 12/8/23 19:36, Jared Mauch via juniper-nsp wrote: I’ll also comment that many software suites don’t scale to 10’s or 100’s of million of paths Keep in mind paths != routes and many folks don’t always catch the difference between them. If you have a global network like 2914 (for

Re: [j-nsp] Hardware configuration for cRPD as RR

On 12/8/23 19:16, Saku Ytti via juniper-nsp wrote: I tried to advocate for both, sorry if I was unclear. ORR for good options, add-path for redundancy and/or ECMPability. IME, when we got all available paths, ORR was irrelevant. But yes, at the cost of some control plane resources.

Re: [j-nsp] Hardware configuration for cRPD as RR

On 12/8/23 18:57, Saku Ytti via juniper-nsp wrote: Given a sufficient count of path options, they're not really alternatives, but you need both. Like you can't do add-path , as the clients won't scale. And you probably don't want only ORR, because of the convergence cost of clients not

Re: [j-nsp] Hardware configuration for cRPD as RR

On 12/7/23 17:05, Saku Ytti via juniper-nsp wrote: If you have a low amount of duplicate RIB entries it might not be very useful, as final collation of unique entries will be more or less single threaded anyhow. But I believe anyone having a truly large RIB, like 20M, will have massive