[Pals] Fwd: MPLS transit heuristics

Stewart Bryant <stewart.bryant@gmail.com> Wed, 25 October 2017 15:55 UTC

References: <CAAeewD-o2HergukOn5K39s-TyHhzxRuRX0=jN8jc-Yz_5oP0pg@mail.gmail.com>
To: "pals@ietf.org" <pals@ietf.org>
Cc: Saku Ytti <saku@ytti.fi>, Job Snijders <job@instituut.net>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <3d3a966d-c2d0-6e35-880c-a1932fa18979@gmail.com>
Date: Wed, 25 Oct 2017 16:55:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAAeewD-o2HergukOn5K39s-TyHhzxRuRX0=jN8jc-Yz_5oP0pg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------962B3C65A034F88BC661BBCC"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/u7_LXi_75IxSgtiZAVKS4HIziwg>
Subject: [Pals] Fwd: MPLS transit heuristics
Precedence: list

Thanks to Ytti for pointing this out.

It seems that there are other implementations that also do deep heuristics.

- Stewart



-------- Forwarded Message --------
Subject: 	MPLS transit heuristics
Resent-Date: 	Wed, 25 Oct 2017 02:22:33 -0700 (PDT)
Resent-From: 	alias-bounces@ietf.org
Resent-To: 	stewart.bryant@gmail.com, agmalis@gmail.com, 
ibagdona.ietf@gmail.com
Date: 	Wed, 25 Oct 2017 12:22:25 +0300
From: 	Saku Ytti <saku@ytti.fi>
To: 	draft-ietf-pals-ethernet-cw@ietf.org
CC: 	Job Snijders <job@instituut.net>



Hey,

Just enabling CW does not stop transit from mis-guessing payload.
Complete solution requires


a) Enable CW
b) Disable payload heuristics in transit (only rely on labels)
c) Enable Entropy or FAT (ECMP/LAG is essentially non-optional today).


Why enabling just CW won't help, is that some platforms, like JunOS
will by default try to detect presence of CW and proceed with
heuristics with different offset if or not CW was detected.

This creates several problem, first if you have CW and non-CW traffic,
then non-CW traffic with XEROX DMAC will cause wrong offset for
heuristics, allowing transit to misidentify.

JunOS isn't just checking for first nibble, it'll need etherType,
ipVer and and ipLen to match. But as detecting CW doesn't actually
change the heuristics, just offset. There is 0 guarantee that we are
actually seeing IP packet when we think we are. It is highly probable
we guess right, but really convenient packet, and we will misidentify.
Because it'll need extremely convenient frame, it will happen very
very rarely, but when it does, no one will be able to troubleshoot it.
How can you attribute problem like this to core 'everything works
perfectly on every station before we added GRE tunnels to our
stations, but after we added GRE tunnels to our station, _one_ station
experiences packet loss', this is possible outcome in JunOS
implementation with or without CW, unless heuristics is also disabled.

ytti@r24.labxtx01.us.bb-re1# set forwarding-options enhanced-hash-key
family mpls ?
   no-ether-pseudowire  Omit IP payload over ethernet PW from the hash-key
   no-payload           Omit MPLS payload data from the hash key
https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html


http://ytti.fi/pseudohell.png

-- 
   ++ytti

[Pals] Fwd: MPLS transit heuristics Stewart Bryant