Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

Tue Dec 6 13:50:57 UTC 2016

On 6 December 2016 at 14:28, Job Snijders <job at instituut.net> wrote:
> Liberal translation below. The big take-away for operators is that
> service providers need to make it part of the MPLS Psuedo-wire
> troubleshooting procedure to ask the customer which MACs are involved
> and raise the red flag when a 4 or 6 is involved.

Expect also per-vendor behaviour on ethertype values, result from one
vendor: http://ytti.fi/ether_type.png

Granted these are not technically ethertypes at all, but 802.3 frame
length, still some other vendors don't care and pass each of these
transparently. Here we can observe blackholing and policing depending
on 802.3 frame length value.

The same vendor here experiences packet loss on pseudowires if
ethertype tells it's ipv4, ipv6, mpls, vlan and packet /does not/
contain said payload. Potentially because NPU time-cost increases too
much.

Vendor never really explained either behaviour.

Other behavioural differences is that some vendors don't accept bad
source addresses, like MCAST source address, some other vendors do.
Pseudowires behaviour is highly dependent on hardware and software
release in corner cases. It's easy to debate that bad MACs should be
dropped, but it's also easy to argue that perhaps you're testing
things, and you expect to get transparent pipe and you to test if your
SUT accepts bad MACs or not.

-- 
  ++ytti