Product bug: unknown unicast traffic storms from thunderbolt displays

Question

Hi All -
Periodically, a random Thunderbolt display will launch a wire rate unknown unicast traffic storm into our LAN and only stop when unplugged from the network. This typically leads to unicast flooding or at least massive trunk congestion (we now use Cisco's storm-control and block (unknown) unicast).
In any given event the transmitted frames are all the same and appear to be random data from memory. They make no sense as traffic: they have garbage MAC addresses and hence the "unknown unicast traffic storm".
We have very roughly 100 and about 1% malfunction this way once a week. We don't think it's the MBP behind the display because we switched to Thunderbolt ethernet adapters (directly on the MPBs) and have not seen an incident for over 7 weeks.
Here is a LogicMonitor record; the trailing edge of the event was when we unplugged the display.
Here's what a packet capture looks like from the outage:
Here is trace data from a different event.
The destination MAC address is an ASCII string that spells out "vertcp". Although Wireshark identifies the frame type as LLC in the first example, we believe this to be a coincidence; it's a random 436-byte piece of firmware memory. A safe conclusion is that both the LLC tag and the completely invalid ethertype in the first event is just random. Nothing in the captured frames makes sense because they aren't ethernet frames, they are random data passed to the driver due to a bug.
Thanks
Branden

Answer 1

We have experienced the same issue with increasing frequency as more Thunderbolt displays are introduced into our environment in the last year.  On a gigabit port, the display has no problem generating 800mbit/s or more of traffic (~500kpps) - which is then flooded to every port in the same VLAN (~400 user ports in our case).  For 100mbit/s users, this essentially floods them off the network.
Here is a detail I don't see mentioned above -- this happens even when a laptop/computer is not connected to the display.  The first case we had of this happening was with a display that had no thunderbolt parent device attached.  Shutting down the switchport and no-shutting it (bouncing the link on the display) resolves this until the next time it happens.
It looks like whatever crap resides in various buffers is used to construct the resulting Ethernet frames.  I did not perform a packet capture this time, but the last time it happened the entire Ethernet header was null bytes with the body being mostly-null but the same random-looking noise in the rest of the frame.  The frame was interpreted by Wireshark and others as a type of Fiber Channel, but I think that was just the default case that matched many of the null characteristics.  The exact same frame was reflected in each packet sent (as opposed to each frame being different/randomized from the predecessor)