If you mean the optional (for IPv4, but required for IPv6) UDP checksum, then that creates a 16-bit checksum that conceptually matches multiple combinations of datagrams that are larger than 16-bits. There is no guarantee that a UDP datagram that matches the checksum is error-free, but the odds of an error are very small. Many errors that would match the checksum would prevent the datagram from reaching its destination.
If the checksum indicates an error, then something is wrong somewhere, and it is almost always corruption in the datagram. Other possibilities include an incorrect or buggy checksum algorithm on the part of the sender or receiver.
If you mean a checksum in the application data, that further protects the data, but that is off-topic here.
There are also the possibilities that bits get flipped in RAM or on a disk drive. It does happen, but not very often.
See RFC 768, User Datagram Protocol:
Checksum is the 16-bit one's complement of the one's complement sum of
a pseudo header of information from the IP header, the UDP header, and
the data, padded with zero octets at the end (if necessary) to
make a multiple of two octets.
The pseudo header conceptually prefixed to the UDP header contains
the source address, the destination address, the protocol, and
the UDP length. This information gives protection against misrouted
datagrams. This checksum procedure is the same as is used in TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
If the computed checksum is zero, it is transmitted as all ones
(the equivalent in one's complement arithmetic). An all zero
transmitted checksum value means that the transmitter generated no
checksum (for debugging or for higher level protocols that don't
care).
Without looking at the packet-capture, network architecture etc. etc. it is a very hard question to answer. You can't really make a policy or anything that would drop frames (since they are routing at Layer 2 in the OSI model). However there are some things that could be going on:
Broadcast storm - There could be a switch that is uplinking to another switch that does not have STP enabled. This switch loop can cause broadcast packets to be re-transmitted down paths that have already seen the message.
LAN re-architecture (most probable) - This is a heavy stream oriented business. Having 4 /24s and a a /16 on the same router that interfaces with critical systems as an ISR (access router) is ill advised. I would recommend going with a more suited core router or a campus network design. This is the equivalent of getting a Honda Civic and wondering why you're loosing in a race with a Ferari. You are using an ISR router for something it isn't meant to do.
Best Answer
UDP itself has no mechanisms for neither flow control, nor congestion control, and no error correction. If the application's datastream needs any of these, then they must be implemented within the application.
However, UDP may have error detection: The UDP header has a 16bit checksum field, but it's use (with UDP-on-IPv4) is not mandatory (however it is mandatory with UDP on IPv6) and it may be all-zeros.
See https://stackoverflow.com/questions/14043680/how-to-enable-udp-checksums, but now we're digressing into upper layers and host related topics, and that is close to becoming off-topic here.