
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<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 4.12.3.1 (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>

</div>

</body>

</html>