[j-nsp] RSVP signaled LSPs across LACP bundles

[Mark Tinka]

On 20/Jul/15 10:02, Adam Vitkovsky wrote:
> 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.

Of course, last resort (which is less-than-desirable) is to go 100Gbps.

I find myself in somewhat of a similar situation regarding some PoP's
where we have 4x 10Gbps backbone LAG's in each direction. I have an
RSVP-signaled Martini EoMPLS pw that is pushing more traffic over one
member of the LAG than the rest, and no amount of (adaptive) hashing
will help. I'm considering moving to 100Gbps core backbones for this PoP
once it gets to be an issue. No amount of adding more members to the LAG
will help.

In all fairness, 4x 10Gbps LAG's is the highest we shall go before we
move that circuit to 100Gbps native.

Mark.