I can't afford wasting time figuring out whether the feature is broken per se or due to use in logical-system and there's the problem of missing features as you mentioned, so all in all, can't really use logical-systems in virtual or physical lab. I find the only limiting factor in large builds to be the system memory. CPU wise the VMs are still rock solid even if "load average" is ~4-5. And for simulation purposes you don't need to be concerned with speed. -hence no need to worry about the VT support, these router VMs will happily run in pure QEMU.
adam > -----Original Message----- > From: Chris Burton [mailto:chris.bur...@speakeasy.net] > Sent: Sunday, December 03, 2017 6:37 AM > To: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley) > > For better or worse I do remember those days, though I was referring to > recent hardware switches/bridges (should have clarified that). To my > knowledge that only applies to things like the STP protocols, but I could be > wrong, again would need to read through the specifications again to be sure > as that is not a use case I have needed thus far. > > Scaling the vMX for testing/lab/PoC deployments can be challenging, but I > have been able to get large topologies off of a single older model dual Xeon > E5-2670 server using logical systems, total of seven vMX instances and 84 > routers using the aforementioned logical systems, at that point I run into > thermal limits because of the VFP CPU usage (even in lite-mode, which only > appears to be related to the number of interfaces rather than the packet > processing, which seems to be the same in lite and performance modes > hence the CPU usage). Some months back I tried to see how large of a > topology I could build with five servers I had access to, I was able to get to > seven vMX instances per server with > 12 logical systems per vMX instance which gave me a 420 router topology > using the trial license, so you can scale a lab/PoC setup quite nicely. Only > downside to using logical systems is they do not support everything that a > non-LS would support, the biggest missing feature in my case being EVPN. > > Another item I have been testing is the vQFX which has much less CPU > demand since the interfaces are bound to the VCP instead of the VFP, but I > have run into many other issues with that and have not tested it as > thoroughly, it is also just a alpha/beta release from Juniper at the moment. > > -C > > > On 12/02/2017 03:40 AM, adamv0...@netconsultings.com wrote: > > Hey, > > > >> local link and not forwarded by the soft bridge by default (I do not know > of > >> any hardware bridges that allow you to disabled this restriction, if you > know > >> of any I would be interested. > >> > > My understanding is that Carrier-Ethernet grade switches/routers should > allow you to peer/drop/tunnel/forward L2 protocols. > > If you're in be business long enough you may remember migrations from > leased-lines to frame-relay and then from FR to MPLS and then from L3VPNs > to L2VPNs to complete the circle. > > These L2 services especially the point-to-point ones, that's where > customers pretty much expect the same properties as they used to have in > leased-lines or FR services, basically just a pipe where MTU is not an issue > and can transport anything from L2 up so they can run their own MPLS/DC > networks over these pipes. > > > >> Out of curiosity what is your use case that you need to use LACP to > >> communicate with VMs? > >> > > Large scale ISP network simulations (for proof of concept testing of various > designs/migrations/etc). > > This allows me to verify my designs, how the technology works on selected > code versions -if there are any bugs, interworking between vendors. > > And there are the provisioning and network monitoring systems, new SDN > approaches that can be tested in this virtual environment, you name it. > > Since it's all virtual one can simulate complete networks rather than scaled > down slices used in physical labs, so I can see the effects of topology-based > route-reflection in terms of routes distribution, the effects of node or link > failures on traffic-engineering and possible congestion as a result across the > whole backbone all in 1:1 scale, but the important point is to make the > simulated control-plane as close to reality as possible hence the need for > LACP. > > > > Speaking of scale, the fact that the VFP is always at 100% CPU is not > > helping > -reminds me of the good old Dynamips -but at least there you could fix it > with an idle value. > > Having hundreds of these VNFs running is not very green. > > > > > > adam > > > > > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp