<html xmlns="http://www.w3.org/1999/xhtml">
<div name="messageBodySection">Bedankt voor het delen Robert!<br />
<br />
Vooral de laatste vier entries in de lijst zijn heel bijzonder. :-)</div>
<div name="messageSignatureSection"><br /></div>
<div name="messageReplySection"><br />
On 5 Dec 2016, 18:28 +0100, Robert Heuvel <RHeuvel@atom86.net>, wrote:<br />
<blockquote type="cite">Ola,<br />
<br />
Wij hebben hetzelfde probleem vastgesteld op een Arista 7150S-52 met EOS (transient MPLS traffic via Layer2).<br />
Arista EOS 4.16.9M heeft dit voor ons opgelost.<br />
<br />
MACs die niet getransporteerd werden:<br />
4X:XX:XX:XX:XX:XX<br />
6X:XX:XX:XX:XX:XX<br />
X4:XX:XX:XX:XX:XX<br />
X6:XX:XX:XX:XX:XX<br />
XX:XX:XB:XX:6X:XX<br />
XX:XX:XF:XX:4X:XX<br />
<br />
Misschien zijn er nog meer geweest, maar zijn nog niet gevonden…<br />
<br />
Dank gaat uit naar:<br />
Richard van Looijen van Flowmailer voor het vaststellen van het probleem.<br />
Edwin Kalle van 2hip voor het wijzen op onderstaande tread.<br />
En natuurlijk Job Snijders voor zijn mail van vrijdagavond, waardoor voor ons alles in 1 keer op zijn plaats viel en we de tussenliggende switch gingen bekijken…<br />
<br />
Mvg,<br />
Robert Heuvel<br />
atom86<br />
<br />
<br />
On 02/12/2016, 21:45, "NLNOG on behalf of Job Snijders" <nlnog-bounces@nlnog.net on behalf of job@instituut.net> wrote:<br />
<br />
Alloah,<br />
<br />
TL;DR: Cisco Nexus 92160 switches kunnen packets met bepaalde specifieke<br />
payloads niet forwarden. Er komt geen software fix, de ASIC is niet goed<br />
gedesigned.<br />
<br />
Stel je hebt twee routers aan elkaar geknoopt via een VLAN over zo'n<br />
Nexus 9000 switch, en je doet VPLS tussen deze routers, dan kan het zijn<br />
dat packets waarbij de payload een ethernet frame binnen die VPLS<br />
instance is, waarbij het destination MAC begint met een 4 of een 6,<br />
gedropped worden.<br />
<br />
Als je precies weet wat voor payloads je stuurt over deze switches dan<br />
kun je er wel omheen werken (in een enterprise omgeving bijvoorbeeld),<br />
maar als je als service provider VLANs van A naar B verkoopt dan weet je<br />
natuurlijk niet wat de klant over het circuit gaat sturen, en dan kan<br />
dit flink bijten.<br />
<br />
Met vriendelijke groeten,<br />
<br />
Job<br />
<br />
----- Forwarded message from Job Snijders <job@instituut.net> -----<br />
<br />
Date: Fri, 2 Dec 2016 15:32:13 +0100<br />
From: Job Snijders <job@instituut.net<br />
To: nanog@nanog.org<br />
Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS<br />
issue)<br />
<br />
Hi all,<br />
<br />
Ever since the IEEE started allocating OUIs (MAC address ranges) in a<br />
randomly distributed fashion rather then sequentially, the operator<br />
community has suffered enormously.<br />
<br />
Time after time issues pop up related to MAC addresses that start with a<br />
4 or a 6. I believe IEEE changed their strategy to attempt to<br />
purposefully higher the chance of collisions with MAC squatters, to<br />
encourage people to register and pay the fee.<br />
<br />
The forwarded email at the bottom is yet another example of a widely<br />
deployed, but fundamentally broken ASIC. The switch can't forward VPLS<br />
frames which contain a payload where the inner packet is destined to a<br />
MAC starting with a 4 or a 6. This is with the switch operating in pure<br />
layer-2 mode, it doesn't know what MPLS or VPLS even are. The switch is<br />
dropping packets on the floor, based on their _payload_. Try selling<br />
such circuits to customers "discounted layer-2 service, some flows might<br />
not be forwarded".<br />
<br />
Had IEEE continued the sequential OUI allocations, it probably would've<br />
taken many years before we ever reached MACs starting with a 4 or a 6,<br />
but instead, in 2012 the first linecards started rolling out of<br />
factories with MACs burned in which start with a 4 or a 6, and this took<br />
some vendors by surpise.<br />
<br />
There have been quite some issues, both in hardware and software:<br />
<br />
Brocade produced a 24x10GE linecard to the market in 2013/2014, with<br />
limited FIB scale, meant for a BGP-free MPLS core, but the card can't<br />
keep flows together on LACP bundles if the inner packets in a pseudowire<br />
were destined for a 4 or 6 MAC. The result: out of order delivery,<br />
hurting performance.<br />
<br />
Cisco ASR 9k's had a bug where if a payload started with a 6, it assumed<br />
it would be an IPv6 packet, compare the calculated packet-length with<br />
the packet-length in the packet and obviously fail because an ethernet<br />
packet is not an IPv6 packet. The result: packets dropped on the floor.<br />
(Fixed in 4.3(0.32)I)<br />
<br />
The Nexus 9000 issue described at the top of this mail. Brocade IronWare<br />
had an issue related to packet reordering for flows inside pseudowires,<br />
fixed in 2013/2014. There are probably many more examples out there in<br />
the wild, slowly driving operators insane.<br />
<br />
At this moment, some issues related to MACs starting with a 4 or a 6 can<br />
be mitigated if you enable Pseudowire Control-Word (RFC 4385) _AND_<br />
Flow-Aware Transport (RFC 6391). You need both to mitigate certain issues<br />
in multi-vendor networks (for instance if you have Cisco edge + Juniper<br />
core). But what to do when the ASIC won't forward the payload? As ISP<br />
you often don't control the payload.<br />
<br />
Unfortunatly, I don't think we've seen the end of this. The linecards<br />
bought in 2012 will trickle down to the grey/second-hand market about<br />
now, often without accompanying support contracts. In a world with<br />
increased complexity in our interconnectedness, and lack of visibility<br />
into the underlaying infrastructure (think remote peering, cloud<br />
connectivity, resellers reselling layer-2) it will hurt when some<br />
flows inexplicably fail to arrive.<br />
<br />
Dear IEEE, please pause assigning MAC addresses that start with a 4 or a<br />
6 for the next 6 years. Or at least, next time you change the policy,<br />
consult the operational community. This 4/6 MAC issue was well<br />
documented in BCP128 back in 2007. The control-word drafts mentioned<br />
that there would be dragons related to 4 and 6 back in 2004.<br />
<br />
Dear Vendors, take this issue more serious. Realise that for operators<br />
these issues are _extremely_ hard to debug, this is an expensive time<br />
sink. Some of these issues are only visible under very specific, rare<br />
circumstances, much like chasing phantoms. So take every vague report of<br />
"mysterious" packetloss, or packet reordering at face value and<br />
immediately dispatch smart people to delve into whether your software or<br />
hardware makes wrong assumptions based on encountering a 4 or a 6<br />
somewhere in the frame.<br />
<br />
And you, my fellow operators, please continue to publicly document these<br />
issues and possible workarounds.<br />
<br />
Kind regards,<br />
<br />
Job<br />
<br />
resources:<br />
<br />
c-nsp thread "Wierd MPLS/VPLS issue": https://puck.nether.net/pipermail/cisco-nsp/2016-December/thread.html<br />
https://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf<br />
BCP128: https://tools.ietf.org/html/bcp128<br />
<br />
----- Forwarded message from Simon Lockhart <simon@slimey.org> -----<br />
<br />
Date: Fri, 2 Dec 2016 11:44:21 +0000<br />
From: Simon Lockhart <simon@slimey.org<br />
To: cisco-nsp@puck.nether.net<br />
Subject: Re: [c-nsp] Wierd MPLS/VPLS issue<br />
<br />
On Wed Nov 23, 2016 at 12:01:20PM +0000, Simon Lockhart wrote:<br />
<blockquote type="cite">On Fri Nov 04, 2016 at 03:40:05PM +0000, Simon Lockhart wrote:<br />
<blockquote type="cite">To me, everything *looks* right, it's just that some VPLS traffic traversing<br />
the new link gets lost.<br /></blockquote>
<br />
For those who are interested...<br />
<br />
Well, I finally got to the bottom of this, and have pushed it to Cisco TAC<br />
for a fix...<br /></blockquote>
<br />
Cisco TAC finally accepted the issue. Bug CSCvc33783 has been logged.<br />
Nexus BU has investigated.<br />
<br />
Response is...<br />
<br />
"[...] unfortunately this is an ASIC limitation on the Nexus 9000<br />
switches and is therefore not fixable."<br />
<br />
If you want a Layer 2 switch that will forward all valid Ethernet<br />
frames, I'd suggest avoiding the Nexus 9000 range...<br />
<br />
Simon<br />
_______________________________________________<br />
cisco-nsp mailing list cisco-nsp@puck.nether.net<br />
https://puck.nether.net/mailman/listinfo/cisco-nsp<br />
archive at http://puck.nether.net/pipermail/cisco-nsp/<br />
<br />
----- End forwarded message -----<br />
<br />
----- End forwarded message -----<br />
_______________________________________________<br />
NLNOG mailing list<br />
NLNOG@nlnog.net<br />
http://mailman.nlnog.net/listinfo/nlnog<br />
<br />
<br />
_______________________________________________<br />
NLNOG mailing list<br />
NLNOG@nlnog.net<br />
http://mailman.nlnog.net/listinfo/nlnog<br /></blockquote>