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? Thanks, EDIT : scheme :
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  DJey10 edited 23 Feb '17, 01:38 |
One Answer:
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  Philst edited 05 Mar '17, 18:29 I think it's not that packets have not been captured at the beginning, because on 36000 packets, JUST those from one subnet have these errors, and any from other subnets. (27 Feb '17, 07:20) DJey10 I can see the failure on 2 subnets in your trace. (27 Feb '17, 07:46) Christian_R If it is your local capture mechanism not keeping up, then you will only get packets dropped when the flow volume gets high enough. The other connections in your trace file don't have much volume. So the reason you only see drops for those subnets is probably that those subnets generate the most volume. The packets that are reported "missing" really are missing in the capture file - so you need to be verifying your capture mechanisms. (28 Feb '17, 23:40) Philst Just to doubly clarify. Those packets are missing from the trace file but were not missing on the wire. The client and server saw them. Your "problem" is not in your real network, it is between the wire and your capture PC. (28 Feb '17, 23:44) Philst Sorry but I've a file of 900k packets (500 Mo) and there are a lot of traffic coming from multiple sources. And 99% of the error are from the same subnet. They are experiencing lots of network issues regarding the speed of the network and I hoped it could be the cause. (14 Mar '17, 01:35) DJey10 |
Can you post a capture file, e.g. at Cloudshark? If you need to sanitize it first, check out this blog post:
https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/
Ok I do it tomorrow
I've added a scheme and the capture