Ask Your Question
0

Lots of TCP retransmission and TCP ACKed unseen segment Windows Server 2019

asked 2021-09-16 08:17:10 +0000

mvang gravatar image

updated 2021-09-16 08:18:07 +0000

grahamb gravatar image

Hi everyone,

We are experiencing performance issues (slow access on websites) between Windows Server 2016 and 2019. On Windows Server 2016, everything is smooth and we have normal TCP packets between web server and database server (iBMI AS400).

632 14.100  192.168.158.20  192.168.158.24  TCP 60      8471 → 49706 [PSH, ACK] Seq=396128345 Ack=1570466466 Win=8192 Len=0

634 14.100  192.168.158.24  192.168.158.20  TCP 94      49706 → 8471 [PSH, ACK] Seq=1570466466 Ack=396128385 Win=8208 Len=40

633 14.100  192.168.158.20  192.168.158.24  TCP 94      8471 → 49706 [PSH, ACK] Seq=396128345 Ack=1570466466 Win=8192 Len=40

635 14.101  192.168.158.20  192.168.158.24  TCP 60      8471 → 49706 [PSH, ACK] Seq=396128385 Ack=1570466506 Win=8192 Len=0

On the contrary, on Windows Server 2019, web server response time are real slow and we have a lot of TCP Retransmission and TCP ACKed unseen segment packets :

8779    37.174  192.168.158.70  192.168.158.20  TCP 557     [TCP Retransmission] 49971 → 8471 [PSH, ACK] Seq=3932858070 Ack=2649144259 Win=8208 Len=503

8780    37.174  192.168.158.20  192.168.158.70  TCP 60      [TCP ACKed unseen segment] 8471 → 49971 [PSH, ACK] Seq=2649144259 Ack=3932858573 Win=8192 Len=0

8781    37.174  192.168.158.20  192.168.158.70  TCP 596     8471 → 49971 [PSH, ACK] Seq=2649144259 Ack=3932858573 Win=8192 Len=542

8782    37.175  192.168.158.70  192.168.158.20  TCP 180     49971 → 8471 [PSH, ACK] Seq=3932858573 Ack=2649144801 Win=8212 Len=126

8783    37.205  192.168.158.70  192.168.158.20  TCP 302     [TCP Retransmission] 49971 → 8471 [PSH, ACK] Seq=3932858573 Ack=2649144801 Win=8212 Len=248

8784    37.206  192.168.158.20  192.168.158.70  TCP 60      [TCP ACKed unseen segment] 8471 → 49971 [PSH, ACK] Seq=2649144801 Ack=3932858821 Win=8192 Len=0

Any clues about what can cause those problems ?

Thank you.

Best regards, Maxime.

edit retag flag offensive close merge delete

Comments

Were the captures done on the servers or LAN? If this was on the servers, move your capture points to the LAN. The 2019 server capture shows that the frame 8783 is a TCP timeout retransmission of 8782. Frame 8784 is TCP ACK of 8783 (3932858573+248). What we don't know, is what happen with frame 8782 on the LAN and servers.

BigFatCat gravatar imageBigFatCat ( 2021-09-17 03:11:49 +0000 )edit

Thank you for your answer, the captures were done on the servers. But what i don't understand are the differences between Windows Server 2016 frames and Windows Server 2019. Both on same SAN, host and using same network switch.

I have noticed i have to capture from another server in the LAN and not from the 2019 one but is it normal that i have so many TCP retransmission and TCP ACKed unseen segment ? The capture just shows few messages, in 20 min i have hundreds or more of those packets.

Best regards

mvang gravatar imagemvang ( 2021-09-17 07:07:23 +0000 )edit

2 Answers

Sort by » oldest newest most voted
0

answered 2024-07-04 11:43:38 +0000

mmanzanelli gravatar image

updated 2024-07-04 11:48:22 +0000

Hello i had have the same problem with win2019, win2022 and IBMi, much retransmissions. I have solved it working with this

Get-NetTCPSetting

Specifically touching that

set-NetTCPSetting -DelayedAckTimeout 150 -SettingName Datacenter

after you touch this you must restart the netadapter

Get-NetAdapter | Restart-NetAdapter

I hope this helps.

edit flag offensive delete link more
0

answered 2021-09-17 10:43:11 +0000

BigFatCat gravatar image

A brief breakdown of the server 2019 capture.

  1. Frame 8782, 192.168.158.70 sent a TCP packet with data to 192.168.158.20, seq 3932858573
  2. Frame 8783, 25ms later, 192.168.158.70 sent a TCP packet with data to 192.168.158.20, seq 3932858573.
  3. Frame 8784, 1ms later, 192.168.158.20, sent a ACK for frame 8783. It is for frame 8783, not 8784, because the ACK is 3932858821.
    The 192.168.158.20 device responded to frame 8783 in 1ms. The issue is to identify why there wasn't a response to 8782 from 192.168.158.20.

Start with the following: 1. Capture at 192.168.158.70 device, to determine all the packets from 192.168.158.20 made it. If the packets are missing, then TAP the LAN side to determine why the packets are missing. You want to determine why packets from 192.168.158.20 to 192.168.158.70 are missing.

  1. If captures shows that 192.168.158.70 received the packets, then verify that 192.168.158.20 sent a response.
  2. If 192.168.158.70 is not responding, then troubleshoot that issue.
  3. If 192.168.158.70 is responding, then TAP the LAN side to determine why the packets are missing. You want to determine why packets from 192.168.158.70 to 192.168.158.20 are missing.

I hope this helps.

edit flag offensive delete link more

Your Answer

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

Add Answer

Question Tools

2 followers

Stats

Asked: 2021-09-16 08:16:25 +0000

Seen: 1,667 times

Last updated: Jul 04