On 23 November 2016 at 18:30, Alexandre Snarskii <[email protected]> wrote:
Hey, >> > https://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf > > Small correction: Juniper does check if packet starting with '4x:' is indeed > ipv4 packet and falls back to 'outer' ethernet + mpls hash if this check > fails. > As a result, all eompls traffic to such address will be forwarded to the > single link of aggregate interface and may cause congestion on this link > despite there are plenty capacity on other links, but at least this does > not lead to heavy reordering.. MPLS gives transit no ability to determine what it is carrying. Juniper (Trio) seeks to IPv4 'total length' field, and if that contains same value as packet bytes read from wire, it is determined that we actually saw IPv4. This does not mean there won't be reordering, it means that in first nibble you need to be have ^4 (i.e. DMAC needs to start with 4 _AND_ your last 8 bits from OUI and first 8 bits from the local side of MAC matches your packet length, by accident, it'll reorder. One could debate that such added heuristic is even more harmful, while it will fail less often, when it _DOES_ fail, what is your probability of getting the problem solved? How will customer know to blame you, how will you know to blame your core, how will your vendor know to blame balancing? I can only imagine how strange the troublecase would be. I know that Huawei (Solar) in addition checks IPv4 checksum, but again, is that useful? Cisco checks nothing but the first checksum. Now some people on the list propose control-word. This does not fix the problem in Juniper, it does fix the problem in Cisco (EZChip), because Cisco does not have platforms which inspect inside pseudowires. Juniper by default inspects inside pseudowires. Granted, you need 'zero-control-word' toggle, which is available in 16.1 to allow it to skip control-word (in some cases) to find actual IP payload inside pseudowire. But even absence of 'zero-control-word', you can still mistakenly think you're seeing XEROX DMAC, and if eType, ipVer and ipLen happen to be 'correct', you're again balancing incorrectly, this time problem will be even more confusing, as it will affect even fewer subset of clients, as some of these leaks in the IP SADDR area. There is extremely low probability that you'll see this ever, but if you do see it, I don't think you're ever going to be able to solve it. To have deterministic behaviour _AND_ balancing, you'll need: a) be dumb, don't try to find IP inside pseudowires set forwarding-options enhanced-hash-key family mpls no-ether-pseudowire b) on ingressPE, look for hash keys, and put hash result in MPLS label set groups DEFAULT protocols l2circuit neighbor <*> interface <*> flow-label-receive set groups DEFAULT protocols l2circuit neighbor <*> interface <*> flow-label-transmit c) have 100% of pseudowires with control-word, so that ^4 and ^6 allow us to know it's IP, and that we can dig inside the packet in transit for hash keys -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
