I'm not entirely sure, but it looks to me like 192.168.129.4 is sending ICMP packets to 192.168.131.195 (which is the ATD's mgmt IP), which is telling the ATD to redirect ping packets to somewhere else which is failing a chksum?.

2 Answers

First off network interface statistics, these have to do with layer 1 being the physical connection. Bad cabling and connectors can cause these kind of problems. Unmatched interfaces as well.

Then the packet checksums, these have to do with layer 4 being the transport layer. Outgoing packets get captured before they arrive at the network card, of which the better ones are known to take on the task of checksum calculation. So when packets arrive at the capture interface these have not been calculated, hence most likely incorrect.

Then the ICMP reported errors. These packets have the first 28 bytes of the initiating packet as payload, which has more often than not an incomplete transport layer. The transport layer dissector doesn't like that and throws out an error indication.

Comments

Thanks for your answer Jaap. I'm not exactly new in networking LOL. I understand the errors are being reported on L1. My question is really, would these packets in the pcap show in these lines in the stats?

Total CRC Errors Rcvd : 4663
Total Other Errors Rcvd : 570632

The customer wants to know what's causing them. We have changed cables, ports and even the switch that is connected to the management port, set the negotiation, but these errors still show up and increasing over time. It's a bit of a mystery to me what else can cause those stats to increase. I would say it's a problem elsewhere in his network but I'm just trying to eliminate things and pin it down if I can. Everything seems to be working OK , he just wants to know if there is a fault in the device before ...(more)

Errors reported at the physical layer are flagged by the hardware. These cause the descriptors related to that frame to be flagged as error'ed, This is what's collected and reported by the network driver, and thus shows up in these statistics. These frames are dropped, there's no reason to push these flawed frames into the network stack, hence don't show up in a capture file. The protocols running over this network link are then responsible for recovering of the failed frame transmission.

I guess the "bad checksums" in the output lines are for the quoted TCP following the ICMP header. Those quotes are usually truncated, so calculating a checksum for TCP will not work. I may be wrong, but it's a little hard to say without a pcap...

So I would ignore these CRC errors if they are for the quoted TCP protocol.