Mark- 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.
-Michael example: l2circuit { neighbor x.y.32.2 { interface ge-1/1/0.0 { virtual-circuit-id 3115; no-control-word; <--- ignore-mtu-mismatch; } > -----Original Message----- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Mark Tinka > Sent: Thursday, October 29, 2015 9:19 AM > To: Saku Ytti <s...@ytti.fi>; Cydon Satyr <cydonsa...@gmail.com> > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Limit on interfaces in bundle > > > > On 29/Oct/15 16:09, Saku Ytti wrote: > > > > > JunOS does have these days adaptive balancing, which essentially > > monitors if one link has higher utilisation than others, then proceeds > > to give smaller share of hash results to that interface. I don't know > > how well it works in practice. > > It works okay for IP traffic. > > But we've had issues with it working for Layer 2 traffic which is > carried in an EoMPLS pw. We had to workaround this by switching from > "adaptive" to "per-packet". I know what you're thinking - no, we have > not had any "per-packet"-related issues, as the downlink device to which > the traffic is being sent is local within the data centre. > > All the hashing features and algorithms that were present simply could > not handle hashing outbound Layer 2 traffic equally. Juniper seemed to > indicate some improvements for this in Junos 15, but 14.2 has been super > stable for us and we'd like to keep it that way. > > Mark. > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp