Network flooded with seemingly empty packets

Solution 1:

First, neither the number of frames nor the amount of data should as such significantly impact network connections even with just Fast Ethernet in place - 5,000 frames of 500 bytes amount to a bit less than 2,5 MB / second of data. They might trigger broadcast storm detection mechanisms on your swithes though, leading to broadcast frame drops of legitimate traffic - especially ARP requests - which could adversely impact IP connectivity (although typically not interrupt it completely, you are likely to see packet losses due to untimely ARP resolution).

The LLC frames in your submitted capture look weird. Neither the source address nor the multicast destination address look like valid, real-world addresses. Also, the LLC frame format violates the standard - NULL addresses are used in conjunction with a UI frame type - which should never happen:

The null address is only valid for use in the address fields of XID and TEST PDUs. The use of the null address (DSAP and SSAP) is specified in ISO/IEC 8802-2.

(Source: IEEE LLC tutorial)

I would suspect some device (presumably not a Xerox albeit the source address resolves to Xerox's MAC address space - I would expect them to know about and abide by basic rules) is violating the protocol. Try hunting it down by looking into your managed switches' FDB / address tables: start at an arbitrary managed switch, find the 00:00:03:20:00:00 address in the table which presumably would be associated with an upstream port to another switch, follow to the next switch repeating the procedure unless you find the address associated with an edge port (i.e. a port with a single connected host).

Solution 2:

When I look at the hexdump I notice that it is just the same sequence of four bytes repeating over and over. That sequence of four bytes is not valid data, and trying to decode it will not yield any useful information.

That repeating sequence covers both source and destination MAC address as well as the Ether type. This means neither source nor destination MAC address means anything, they have been corrupted. This is also not an LLC frame, it just happens that this sequence of bytes got decoded as LLC.

If you see something like that again, I'd first try to capture the traffic using more than one brand of Ethernet adapter to be sure those corrupt frames are truly being sent on the wire, and is not just an artifact introduced on the machine doing the capture.

If you have established this traffic is really being sent on the wire, then you'll have to start looking for what device is producing it. This looks like a low level problem at the physical layer beneath the MAC layer. You won't have MAC addresses to go by, so the only option for finding the source may be to look at flashing link status, and unplug wires until you find the one producing those packets.

It is not unlikely that the root cause was defective hardware.