[j-nsp] RSVP signaled LSPs across LACP bundles

Adam Vitkovsky Adam.Vitkovsky at gamma.co.uk
Mon Jul 20 04:02:56 EDT 2015


Hi Daniel,

You can give it a shot with the adaptive load balancing algo as if it sees that one of the links in LAG is running at nearly full capacity it should try shuffle the streams around to get better load distribution however I believe the algo is not clever enough to determine the BW of a particular stream (might even be impossible) so it's like: shuffle streams 1 to 8 so that one of the 10GE links is not over-utilized -but you don't know which stream is the 10GE one  

Or you can disable LACP and use 4 separate IP/MPLS links and have RSVP to dictate which LSPs are going to use which 10GE link 
-by setting up automatic bandwidth allocations for your LSPs and instruct l2circuit to use one of the LSPs and tune setup and hold priorities. This way you could get sort of a call admission control per 10GE link.
 
adam
> -----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf
> Of Daniel Rohan
> Sent: 17 July 2015 23:49
> To: juniper-nsp
> Subject: [j-nsp] RSVP signaled LSPs across LACP bundles
> 
> Hi all,
> 
> Quick question for those who might have run across this.
> 
> I have a 4x10Gb backbone based on Juniper MX routers. The 10Gb interfaces
> are LAG'd with LACP using the default layer4 hash. It works wonderfully
> under normal conditions.
> 
> I'm using RSVP to signal dedicated LSPs for a bunch of
> pseudowires/l2circuits across our network.  The bandwidth for a few of
> these pseudowires is as high as 10Gbps.
> 
> When one of the 10Gb LSPs starts to get close to 9.4 or 9.5 Gbps of
> utilization, we start to see other customer traffic drop, RTT latency
> increase etc. The 10Gb flow starts to drop packets as well.
> 
> The cause appears to be obvious: the 10G flow is getting hashed onto one of
> my four links in the LACP bundle, and there it stays (it's a single TCP
> session). Any other customer traffic that is unlucky enough to be hashed
> onto that link contends with that mammoth flow and everyone loses.
> 
> I'm trying to find a way to work around this and looking for ideas.
> Per-packet spray hashing is not an option. Would adaptive load balancing
> help? Something else? I'm trying to avoid the scenario where I have to
> dedicate specific 10Gb links just for these bursty psuedowires in order to
> protect other traffic. That seems regressive, although the remainder of
> this customer traffic *would* handily fit on a 30Gb LACP bundle.
> 
> -Dan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list