On 8 March 2018 at 21:45, Erdal Rasid <[email protected]> wrote: > Now this works great in the majority scenarios, because hey let's be honest, > MAC addresses for the longest time started with 00-0...... > > This fools the system to believe that the inner packet is IP, while it is an > Ether header in reality. > > Bottom line is that if your DMAC starts with a 4 or 6 you have a situation. > > <> > Solution > Use the MPLS control word.
Now you have a new problem: if you do have Ethernet payload directly after the MPLS stack, with a MAC address that starts with a 4 or 6 and you add the control-world to put a 0 there, you actual Ethernet payload is now offset by 4 bytes (the control-world is usually 0x00 0x00 0x00 0x00 unless you're using sequence numbers). The information that was going to be used to has against (the Ethernet SRC/DST or IP SRC/DST or TCP/UDP port numbers) are miss-aligned by 4 bytes and your hashing is now unpredictable. It seems the most optimal solution here is FAT (flow labels) or entropy labels (if your devices support either of them). This issue has been discussed at length: https://mailarchive.ietf.org/arch/msg/pals/ZTpJ_NEL5j6gv11NnwDW8guDDGQ https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ Cheers, James. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
