


Pinging with 1460 without fragmentation to the destination server which has 1280 MSS value is responding fine data that remote server responds with has same data length size – “data.len>1460” filter applied shows that ICMP data of 1460 is transmittable both ways.

I have noticed that the Maximum Segment Size MSS of the destination server – Redlion box is “1280” and the source server is “1460”. So obviously, in both success and failure cases we will see this kind of messages. But in our case the packet retransmissions and failing communication are resetting the RPC port communication and thus these messages are seen. TCP RST couldn’t be considered as the issue normally because this happens after every session closure. This is not the case when I tried to capture traffic between the other sources. TCP “RST” (RESET), “Spurious Retransmissions” (Source Retransmitted the packet even though the DEST ACK assuming the DEST hasn’t ACK) are noticed in high numbers. I’ve analysed the network connection between these servers in question and noticed that there are a lot of packet retransmissions happening. Same is the case when browsing the FTP/HTTP site hosted on the Red Lion box via IE from my machines. There are a lot of packet retransmissions happening just before the FTP application failing with error – BTW, I am using Filezilla client to transfer data to the FTP Box. But if this same Red Lion device is moved and connected to a different network that’s having Cisco Catalyst switches, this Device is working fine. Other than Red Lion device, I was able to route traffic as desired and can reach data transfer rates at 250 MB/s. STP is configured properly and running A-okay. These 3064’s are connected to the 3048 Switches directly – no firewalls. Red Lion – FTP/HTTP device has been attached to 3048 model. Our Hyper-V clusters are connected to Cisco 3064 Switches in HA model 2 Nic cables pulled from each VM Host to 2 3064 Switches for HA. This setup has no Firewalls only Cisco Nexus Switches 3064 & 3048 Models – that’s 3 3064’s models connected in a HA model. Our production FTP server is a Red Lion device See here sitting in our manufacturing site, whereas our source servers are hosted on Hyper-V clusters. I have been haunted by this weird TCP spurious retransmissions and TCP DUP ACK issue since past 1 month – It almost started/I’ve noticed on November last week.
