> > 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 metal , or your own metal for vMX, or cRPD ( assuming said bug is not hardware dependent/related ). On Thu, Feb 8, 2024 at 10:21 AM Mark Tinka <mark@tinka.africa> wrote: > > > 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 played with required at least > > 5G RAM / 4 cores to even start the vRE and vPFEs up, plus you have to > > do a bunch of KVM tweaking and customization, along with NIC driver > > fun. All of that has to work right just to START the thing, even if > > you have no intent to use it for forwarding. You could have cRPD up in > > 20 minutes on even a crappy Linux host. vMX has a lot more overhead. > > Is the same true for VMware? > > I had a similar experience trying to get CSR1000v on KVM going back in > 2014 (and Junos vRR, as it were). Gave up and moved to CSR1000v on > VMware where it was all sweeter. Back then, vRR did not support > VMware... only KVM. > > On the other hand, if you are deploying one of these as an RR, hardware > resources are going to be the least of your worries. In other words, > some splurging is in order. I'd rather do that and be able to run a > solid software-only OS than be a test-bed for cRPD in such a use-case. > > Mark. > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
