Ask Your Question
0

What's causing the performance issue with Citrix here?

asked 2019-05-07 06:53:25 +0000

dmayer gravatar image

updated 2019-05-07 09:33:06 +0000

Guy Harris gravatar image

I have a Client side Trace File with many "don`t fragment flag" = 0 in TCP Protocol coming from Client is this a problem? User having performance issue with Citrix

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted
1

answered 2019-05-08 07:49:28 +0000

SYN-bit gravatar image

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.

edit flag offensive delete link more

Comments

Hi, is the packet-loss from Client to Server or from Server to Client? in which Trace-File and what sequenz-number can I find it? thank you in advanced.

dmayer gravatar imagedmayer ( 2019-05-08 09:18:35 +0000 )edit

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.

SYN-bit gravatar imageSYN-bit ( 2019-05-08 13:44:32 +0000 )edit

do you mean those file "WS004013_00001_20190429095237"

dmayer gravatar imagedmayer ( 2019-05-08 15:42:22 +0000 )edit

Yes, I did. I edited my comment to point to the exact file :-)

SYN-bit gravatar imageSYN-bit ( 2019-05-08 16:05:43 +0000 )edit
0

answered 2019-05-07 07:06:50 +0000

updated 2019-05-07 07:16:39 +0000

"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.

edit flag offensive delete link more

Comments

will it be helpfully to upload Trace File?

dmayer gravatar imagedmayer ( 2019-05-07 07:17:08 +0000 )edit

will it be helpfully to upload Trace File?

Yes.

Guy Harris gravatar imageGuy Harris ( 2019-05-07 07:19:36 +0000 )edit

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.

Packet_vlad gravatar imagePacket_vlad ( 2019-05-07 07:21:17 +0000 )edit

I have Client and Server side Trace Files both have round about 44 MB how can I upload?

dmayer gravatar imagedmayer ( 2019-05-07 07:28:18 +0000 )edit

You may use any public file-sharing service.

Packet_vlad gravatar imagePacket_vlad ( 2019-05-07 08:10:37 +0000 )edit
0

answered 2019-05-07 07:19:12 +0000

Guy Harris gravatar image

updated 2019-05-07 07:20:04 +0000

"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.

edit flag offensive delete link more

Comments

There does not appear to be any IP fragmentation of TCP segments, so the "don't fragment" flag not being set is irrelevant here.

Guy Harris gravatar imageGuy Harris ( 2019-05-07 09:32:13 +0000 )edit

ok, thank you very much for your diagnostic. Have you detected any other issues in the Trace Files?

dmayer gravatar imagedmayer ( 2019-05-07 10:46:59 +0000 )edit

(!) 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:

  • There is no TCP 3-way handshake captured, whereas it contains some very useful info for diagnostics. So it's better to capture connection start process.
  • Please narrow capture time span and clarify what the issue looks like (is it constant, periodic etc.) or specify time when issue was observed.

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.

Packet_vlad gravatar imagePacket_vlad ( 2019-05-07 13:29:22 +0000 )edit

I have uploaded the Trace with the TCP-3-way handshake (WS004013_00001_20190429095237) please be informed that the capture output option was set to "create a new file after..." 1 hour.

dmayer gravatar imagedmayer ( 2019-05-07 14:20:30 +0000 )edit

you can filter out smb traffic it only affects Citrix Traffic TCP-Port 2598 or use Conversation Filter: (ip.addr eq 10.1.15.19 and ip.addr eq 172.16.59.31) and (tcp.port eq 49938 and tcp.port eq 2598)

dmayer gravatar imagedmayer ( 2019-05-07 14:53:17 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-05-07 06:53:25 +0000

Seen: 176 times

Last updated: May 08