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 100G?
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. ----------- Hi, We've observed a similar problem on the Arista 7150S-52 with EOS 4.12.3.1: 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 4.12.3.1: 4*:**:**:**:**:** 6*:**:**:**:**:** *4:**:**:**:**:** *6:**:**:**:**:** **:**:*B:**:6*:** **:**:*F:**:4*:** Maybe there are more combinations, but we didn't iterate through all possibilities. 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 switches. Kind regards, Robert