Depending on the specific configuration and the result of the negotiation, you can look for duplex mismatches by having your network management platform report these types of errors from the switch port. The half-duplex side will see late collisions. With duplex mismatch, the full-duplex side will see runts, FCS errors, and CRC errors.

I’ve written before about auto-negotiation and prefer to use it because of its benefits with Gigabit and higher speed links. With more modern equipment, auto-negotiation works correctly, so the source that I most often see are IT departments that are still living in the past and setting speed/duplex manually and not getting it right in all cases. Old NICs that do not properly do auto-negotiation are one source. These are sources of errors at the physical layer.Īt the data link layer, duplex mismatch on Ethernet is probably the most common cause of packet errors. Any source of electronic noise could potentially cause bit errors, which result in packet errors. A bad NIC, perhaps containing a memory chip that has a stuck bit in its internal buffer, could be another source of packet errors. Packet errors can be caused by bad cabling or cables run near sources of EMI/RFI, such as high-voltage power lines or fluorescent lighting ballasts. Most people think of packet errors as a common reason for TCP to retransmit a segment and that’s correct. Several things can cause a retransmitted packet (technically, a TCP segment). See descriptions of TCP such as at Wikipedia for more information about how TCP works. Features like Selective ACK (SACK) and fast retransmit speed up the process.

If TCP doesn’t receive an ACK within 2*RTT (twice the smoothed Round Trip Time), it will retransmit the first previously sent and unacknowledged segment.

TCP guarantees data delivery by using an ACK mechanism to make sure that the data is received (note that a failure internal to the receiving system may corrupt the data after TCP hands it off to the kernel, but we’re not going to go there in this article). The few things I did find typically contained inaccuracies of some sort. But I haven’t seen anything much about the sources of TCP retransmissions. There is a fair amount of information on the web about TCP retransmissions and how TCP works. I look at servers and user workstations as well as looking for retransmisisons using packet capture tools. I’ve been doing a number of network assessments recently and one of the factors that I use to determine network health is the number of TCP retransmissions that occur.

Tcp retransmission wireshark