Hi, I've done some research about the messages I wrote in the title. Nonetheless, I think my problem isn't due to some packets not captured by the switch or whatever like that.
I tell that because I get such messages for a particular subnet, while all other subnets (more than 10 others) don't have these errors. On 36000 packets (on a specific port, the citrix session reliability port 2598), just this subnet has these messages, and a lot. Furthermore they're experiencing lot of big slowdowns on Citrix.
Those errors are the only track I have for the moment, because the links aren't congested nor overloaded, that's sure. And our Citrix servers are well because this happens just for the subnet I told (one subnet is one different location in the city, connected with Fiber).
Can you tell me why I'd get those errors?
The captured has been taken on SW1, po1 (g1/2 & g1/3)
Here is a part of the capture (but the rest is similar) : https://www.cloudshark.org/captures/7e285749792d
The errors are all on the port 2598, with source/dest dest/source always citrix server and site 2 clients. The capture has been sanitized so you can't see that the IP are all from the same subnet but yes.
I've the same errors on the blue switch in site2.
asked 22 Feb '17, 07:24
edited 23 Feb '17, 01:38
You really do have several data packets missing from your capture - but they weren't missing from the original flow. Your capturing mechanism failed to capture them. Wireshark is telling you (correctly) about this.
There are ACKs to data packets that aren't seen in the trace. This means that the real receiver must really have received those data packets. They are missing from the trace but not missing from the real flow.
It could have been that your switch didn't mirror them (didn't forward them to your sniffer PC) or that your capturing PC couldn't keep up with the arrival rate of the mirrored packets.
See Jasper's very good article on the topic of ordinary NIC cards not keeping up. https://blog.packet-foo.com/2016/11/the-network-capture-playbook-part-3-network-cards/
Your Dup-ACK (packet #48) is interesting because it is actually a Selective ACK. Given that a normal ACK (#49) arrives just 12 microseconds later to acknowledge the data reported "missing" by the SACK, my guess is that at least one packet arrived at the receiver out-of-order but the overtaken packet arrived just 12 microseconds late.
Here's a TCP-Trace chart which shows the data packets advancing upwards - with clearly observable gaps. However, the ACK line also advances all the way upwards, fully acknowledging every data packet - even the missing ones.
answered 26 Feb '17, 03:06
edited 05 Mar '17, 18:29