[j-nsp] RSVP signaled LSPs across LACP bundles

[Alexander Arseniev]

Hello,
In addition to what others said, You could use LB based on ip.id. To do 
that, You need to expose this flow as pure IPv4/IPv6 and do FBF with 
"flexible-offset" FW filters matching ip.id ranges:
https://www.juniper.net/techpubs/en_US/junos15.1/topics/concept/firewall-filter-flexible-match-conditions-overview.html 

The easiest place to do it is the PE as FBF for "family mpls" is not 
supported.
With ip.id being a monotonically increasing field for a given flow, You 
should see this fat flow "surging" on a given link and then "shifting" 
to another link during a shorter time interval (i.e.milliseconds), and 
looking as "load-sharing" on a longer time interval (i.e. seconds).
Just my thoughts.
Thanks
Alex

On 17/07/2015 23:49, Daniel Rohan wrote:
> 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