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

Chris Burton chris.burton at speakeasy.net
Sun Dec 3 01:36:30 EST 2017


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