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).