On 6 December 2016 at 14:28, Job Snijders <job@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