On 29 October 2015 at 20:03, Michael Hare <michael.h...@wisc.edu> wrote:
Hey Michael, > re: EoMPLS pw balancing, do you have no-control-word configured? My > understanding [and experience] is that vc is sticky due to hashing based on > presence of control word. If control word is absent you can hash based on > normal IP/ethernet headers. As I recall negative of removing control word > has to do with drop optimizations during fragmentation. I am struggling with > same sort of thing for 10G backbone university san replication. In my case > it's because the traffic isn't well hashable even if it were native IP > [consistent flow tuple] and short of pressuring vendor to support multiflow > transfer, 40G/100G appears to be the only reasonable solution at this point. This is largely terrible idea. MPLS LSR does not know what is the payload that it is carrying, they can only use heuristics to guess it. Common way to guess is, if first nibble is 6, it's ipv6, if first nibble is 4 it's ipv4, otherwise it's ethernet. This strategy stopped working somewhere in 2009 or so, when IEEE decided to make stealing MAC addresses more awkward by stopping in-order allocation in favour of random allocation. Now you can have MAC address starting with 4, which would be incorrectly balanced as if it were IPv4, causing reordering. Reordering is almost same as packet loss on pretty much all shipping TCP stacks (reordering could be mostly harmless, if stack were tuned for that, but it would make them less efficient dealing with packet loss, now they are aggressively tuned to handle more typical case). If there is chance of ECMP in core, you want control-word. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp