On 1/Dec/15 18:32, Adam Vitkovsky wrote:
> Well as I said many times LAGs are tricky :) > Therefore QOS on LAGs is tricky as well, > e.g. if you police the VLAN to 120M on a 4x10G LAG each link gets only 40M if > more than 40M worth of streams gets hashed on one link you get into trouble. > And it takes quite a fiddling to get Juniper LAGs failover/recover under 50ms. My problem with IOS XR is that you're better off using percentages on LAG's for policing, which is a problem if you have "odd" values that percentages can't account for. IOS XR, unlike Junos, applies absolute policer values wholesale on each member link in the LAG. Junos, as you describe, does the math and apportions the policer value against each member link the LAG as a function of how many they are. Yes, unequal load balancing can make this tricky, which is why we do per-packet load balancing on LAG ports, and this solves the problem as we get equal hashing for all traffic-types. Mark. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp