On Fri, 9 Feb 2024 at 17:50, Tom Beecher wrote:
> Completely fair, yes. My comments were mostly aimed at a vMX/cRPD comparison.
> I probably wasn't clear about that. Completely agree that it doesn't make
> much sense to move from an existing vRR to cRPD just because. For a
> greenfield thing
Juniper does not have a lot of guidelines on this. This is a bit
surprising to us too. I would have expect some guidelines about IRQ and
CPU pinning. It seems they think this does not matter much for a RR.
However, cRPD comes with better performance than vRR and therefore,
Juniper pushes to
>
> No one is saying that cRPD isn't the future, just that there are a lot
> of existing deployments with vRR, which are run with some success, and
> the entire stability of the network depends on it. Whereas cRPD is a
> newer entrant, and early on back when I tested it, it was very feature
>
On Thu, 8 Feb 2024 at 17:11, Tom Beecher via juniper-nsp
wrote:
> For any use cases that you want protocol interaction, but not substantive
> traffic forwarding capabilities , cRPD is by far the better option.
No one is saying that cRPD isn't the future, just that there are a lot
of existing
>
> Is the same true for VMware?
>
Never tried it there myself.
be able to run a
> solid software-only OS than be a test-bed for cRPD in such a use-case.
AFAIK, cRPD is part of the same build pipeline as 'full' JUNOS, so if
there's a bug in any given version, it will catch you on Juniper's
On 2/8/24 17:10, Tom Beecher wrote:
For any use cases that you want protocol interaction, but not
substantive traffic forwarding capabilities , cRPD is by far the
better option.
It can handle around 1M total RIB/FIB using around 2G RAM, right in
Docker or k8. The last version of vMX I
>
> I wouldn't consider cRPD for production. vRR (or vMX, if it's still a
> thing) seems to make more sense.
>
For any use cases that you want protocol interaction, but not substantive
traffic forwarding capabilities , cRPD is by far the better option.
It can handle around 1M total RIB/FIB using
On Thu, 8 Feb 2024 at 10:16, Mark Tinka wrote:
> Is the MX150 still a current product? My understanding is it's an x86
> platform running vMX.
No longer orderable.
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
On 2/8/24 09:56, Saku Ytti via juniper-nsp wrote:
Same concerns, I would just push it back and be a late adopter. Rock
existing vRR while supported, not pre-empt into cRPD because vendor
says that's the future. Let someone else work with the vendor to
ensure feature parity and indeed perhaps
On 2/8/24 09:56, Saku Ytti via juniper-nsp wrote:
Same concerns, I would just push it back and be a late adopter. Rock
existing vRR while supported, not pre-empt into cRPD because vendor
says that's the future. Let someone else work with the vendor to
ensure feature parity and indeed perhaps
On 2/8/24 09:50, Roger Wiklund via juniper-nsp wrote:
Hi
I'm curious, when moving from vRR to cRPD, how do you plan to manage/setup
the infrastructure that cRPD runs on?
I run cRPD on my laptop for nothing really useful apart from testing
configuration commands, e.t.c.
I wouldn't
On Thu, 8 Feb 2024 at 09:51, Roger Wiklund via juniper-nsp
wrote:
> I'm curious, when moving from vRR to cRPD, how do you plan to manage/setup
> the infrastructure that cRPD runs on?
Same concerns, I would just push it back and be a late adopter. Rock
existing vRR while supported, not pre-empt
Hi
I'm curious, when moving from vRR to cRPD, how do you plan to manage/setup
the infrastructure that cRPD runs on?
BMS with basic Docker or K8s? (kind of an appliance approach)
VM in hypervisor with the above?
Existing K8s cluster?
I can imagine that many networking teams would like an AIO
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
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
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
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.
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
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
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 example) you may be
peering with someone in 10-20 places
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 wrote:
>
> Why not both add-path + ORR?
> --
>
> Thomas Scott
> Sr. Network Engineer
> +1-480-241-7422
> tsc...@digitalocean.com
>
>
Why not both add-path + ORR?
--
Thomas Scott
Sr. Network Engineer
+1-480-241-7422
tsc...@digitalocean.com
On Fri, Dec 8, 2023 at 11:57 AM Saku Ytti via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> On Fri, 8 Dec 2023 at 18:42, Vincent Bernat via juniper-nsp
> wrote:
>
> > On 2023-12-07
On Fri, 8 Dec 2023 at 18:42, Vincent Bernat via juniper-nsp
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 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,
On Thu, 7 Dec 2023 at 16:22, 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
.
-Michael
> -Original Message-
> From: juniper-nsp On Behalf Of
> Saku Ytti via juniper-nsp
> Sent: Thursday, December 7, 2023 12:24 AM
> To: Thomas Scott
> Cc: Vincent Bernat ; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Hardware configuration for cRPD
From a RPD, not cRPD perspective.
- 64GB is certainly fine, you might be able to do with 32GB
- Unless RRs are physically next to clients, you want to bump default
16kB TCP window to maximum 64kB window, and probably ask account team
for window scaling support (unsure if this is true for cRPD, or
Also very curious in this regard.
Best Regards,
-Thomas Scott
On Wed, Dec 6, 2023 at 12:58 PM Vincent Bernat via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hey!
>
> cRPD documentation is quite terse about resource requirements:
>
>
Hey!
cRPD documentation is quite terse about resource requirements:
https://www.juniper.net/documentation/us/en/software/crpd/crpd-deployment/topics/concept/crpd-hardware-requirements.html
When used as a route reflector with about 20 million routes, what kind
of hardware should we use?
29 matches
Mail list logo
