Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)
job at instituut.net
Tue Dec 6 12:28:41 UTC 2016
On Fri, Dec 02, 2016 at 04:02:43PM +0000, Simon Lockhart wrote:
> On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote:
> > you'd think standard testing of traffic through the asic path
> > somewhere between 'let's design an asic!' and 'here's your board ms
> > customer!' would have found this sort of thing, no? or does testing
> > only use 1 mac address ever?
> Well, it's actually payload, rather than src/dst MAC used for
> forwarding, so there's quite a few more combinations to look for...
> 2^(8*9216) is quite a lot of different packets to test through the
> forwarding path... But, wait, that assumes every bit combination for
> 9216 byte packets, but the packet might be shorter than that... So
> multiply that by (9216-64).
> Anyone want to work out how many years that'd take to test, even at
Folks on NLNOG found another gem: http://mailman.nlnog.net/pipermail/nlnog/2016-December/002637.html
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.
We've observed a similar problem on the Arista 7150S-52 with EOS
188.8.131.52: issues with passing transient MPLS traffic through a layer-2
domain where the payload contains certain MACs.
Arista EOS 4.16.9M apparently contains a fix to address this problem.
MACs that didnt make it through the switch when running 184.108.40.206:
Maybe there are more combinations, but we didn't iterate through all
Big thank you to Richard van Looijen (Flowmailer) for finding this
issue, Edwin Kalle (2hip) for pointing us at this thread, and Job
Snijders, his email which prompted us to investigate the intermediate
More information about the NANOG