[c-nsp] Nightmare for load balancing of L2VPN traffic on CRS (traffic from ME3600)

[Alexandre Snarskii]

On Wed, Apr 15, 2015 at 10:50:14PM +0200, Daniel Verlouw wrote:
> > right, both trio and asr9k can do lag/ecmp balancing based on payload
> > inspection to some degree, but it's complicated and hacky.
> 
> getting offtopic, but wondering what you mean with complicated and
> hacky about the load balancing algo on Trio?
> Trio hash includes;
> - upto 5 labels
> - ipv4/v6 payload contents (and yes, it checks the packet' length to
> avoid the "4" or "6" DMAC issue)

... and no, it does not revert back to ethernet parsing when DMAC starts
with 4x: or 6x: and length does not match :(
Run into this issue yesterday, PW with single DMAC 6x:... was not 
balanced across aggregated ports at LSR at all. JunOS: 11.4R9.

On the other hand, this issue is rare enough to be happy with load-balancing
in most cases. 

> - for ethernet pw it can skip upto 2 vlans and still include its
> ipv4/v6 payload (if any)
> 
> For our traffic mix (ymmv), this results in near-perfect load
> balancing for PWs, without FAT.
> My take on it is that FAT is a hack to cope with ASIC designs that
> can't do proper deep inspection.
> 
> (granted, other JNPR platforms can't do the fancy Trio tricks).

DPC-based MX'es can do load-balancing based on MPLS payload too: 

snar at RT> show configuration forwarding-options hash-key 
family mpls {
    label-1;
    label-2;
    payload {
        ether-pseudowire;
        ip;
    }
}