Hi James On Wed, Mar 13, 2019 at 09:29:13AM +0000, James Bensley wrote:
> The ingress PE probably only has the same source and destination MACs > to hash on to generate the FAT label. This means that in the scenario > that your customer is using MPLS the required level of entropy isn't > available to the ingress PE to generate a range of FAT labels. This would be the case yea. The customer in this case is rolling MX on both ends with a /31 used on both ends of the PW and using it as "backbone p2p" link, so src and dst MACs visible to the PE will always be the same. But the feature problem here is that anytime EtherType is not IP, entropy isn't generated for FAT-PW as it won't see the payload IP headers after ENET? If the customer turns off MPLS or IGP shortcuts and switches to pure IP forwarding, problem would go away. > > Thanks! I figured as much. It seems like ASR9K only creates entropy for > > pure IP traffic as passenger traffic entering the PW. MPLS run over PW by > > client user seems to break load balancing completely. > > That is not strictly true. ASR9K can pull entropy from Ethernet > headers entering the pseudowire; I think the problem in your case is > that it's always the same src/dst. Yea, but ENET headers don't do any good for me. I can't expect passenger traffic to be load balanced between various MACs, it's like expecting a LAG interface to generate decent balance on a two-router p2p link relying on src/dst MACs as entropy. > > > In the meantime, we'll just have to replace the LAG with 100GE to make > > this problem go away. > > If that is easy for you to do then that will definately fix this > problem (for now, untill you add a 2nd 100G link :) ). > Alas, yea.. life is full of compromises lol. I think it's a design compromise that when we're providing 10GE PWs as atomic units, transport links just need to be higher than what passenger atomic units are, to let even rudimentary (L2CKT label only hash) load balancing to work. Same logic we've had with ASR920 in the metro -- not providing bigger than 1GE PWs on those devices being fed with 10GE uplinks. If someone needs a 100G point-to-point, for now it'll have to be optical transport, or we'll have to look at alternate packet transport designs. Right now, business case wise, it makes more sense (and cleaner) to provide optical transport for 100G waves than oversubscribe the packet network -- but only works in the metro where we have fiber/optical footprint. James _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
