[j-nsp] [c-nsp] LACP between router VMs (James Bensley)

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Tue Dec 5 04:27:09 EST 2017


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.burton at speakeasy.net]
> Sent: Sunday, December 03, 2017 6:37 AM
> To: adamv0025 at netconsultings.com; juniper-nsp at 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, adamv0025 at 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
> >
> >
> >




More information about the juniper-nsp mailing list