There is packet-loss in your trace. Sometimes even a period of a few seconds in which there is no communication between this client and server. As I see you are using DSCP markings and you said that the problem only effects Citrix, could you check whether you might oversubscribe the queue reserved for Citrix (marked DSCP = 18, AF21)? Also please check with your MPLS provider whether their queue(s) for AF21 marked traffic might have drops.
There is packet loss in both directions. But I think I saw more loss from the client to the server that the other way around.
One instance of loss that had a significant duration can be found at frame #8008 of the file WS004013_00002_20190429100000. The data sent from 10.1.15.19 from frame #7990 onwards does not get an ACK until frame #8018, which is 2,1 seconds after frame #7990 was sent.
And by the fact that it did not send any DUP-ACK's or D-SACK messages, you can deduct that it did not receive any of the earlier packets and was just acknowledging the retransmission in frame #8017.
Too bad the server trace was not started yet at this point. It would have been nice to be able to confirm that from the server side.
"don`t fragment flag" itself can't be a reason for performance issues as it allows fragmentation, but doesn't require it.
You have to check if there is an actual fragmentation happening on the network (look for Fragmented IP Protocol caption or apply ip.flags.mf == 1 filter and check whether you observe any packets).
This is to be checked at the receiver side and may happen of you have some kind of tunneling on the path.
Uploading trace files is always helpful. In your case a trace from other side is more helpful, as client itself won't observe fragmented packets and we'll need to look for another 'signs'. Also it'd be helpful if you add any details about the network path - devices, technologies in use etc.
"don`t fragment flag" = 0 in TCP
That's not inherently an issue.
User having performance issue with Citrix
Are TCP segments getting fragmented at the IP layer?
If not, the segments not having having "don't fragment" being set isn't an issue, because fragmentation isn't being done.
If so, that could be an issue.
There does not appear to be any IP fragmentation of TCP segments, so the "don't fragment" flag not being set is irrelevant here.
(!) Please remove and re-do captures filtering out SMB (TCP port 445) because you've exposed seemingly sensitive SMB traffic in there containing scans (client-side capture).
As for other issues:
Now I see 1 strange thing: client is using small TCP segments of 536 Bytes segment length which could be a sign of MTU problems. But this needs to be checked further.
Asked: 2019-05-07 06:53:25 +0000
Seen: 1,484 times
Last updated: May 08 '19
