Syn and Immediate Out of Order
Have a customer who experiences random slowness and packet loss using a cloud application. The issues seems to be return traffic. Routes are good. They provided a capture which shows that the three way handshake never completes. A syn goes out from client, then there is an immediate out of order from client and then the client send an ack. TLS begins handshake begins, bytes in flight keeps climbing until it goes back to 0 and does the same process over again. I am puzzled.
There is zero traffic in this conversation that comes back from the server. It is all unidirectional from the client. I cannot upload a pic unfortunately.
Can you anonymize the capture and share it?
How was the capture made? On the client? Span port? TAP?
Sorry I didn't provide enough info. Yes I am told it was captured client side when the issues was happening but I know nothing about what type of device it is. I am wondering if the NIC is just getting bogged down. It is a little over 5 minute log capture and according to the capture properties the average bytes per second are below 1KB and pps are VERY low.
I anonymized and uploaded to my DropBox.
https://www.dropbox.com/s/91vbv6tej2a...
I think you will need to get the capture process resolved if you want to use it to diagnose the "random slowness and packet loss".
The frames marked as
TCP Out-Of-Orderare an exact copy of theSYNbefore it.There is a
Frameprotocol preference to have WiresharkGenerate an MD5 hash for each framewhich can be used to confirm they are identical.Here is a brief overview of Duplicate Packets and TCP Retransmissions . At about 2:52 is a description of layer 2 duplicate packets.
I added a packet ID column and confirm each SYN and OUT-OF-ORDER are identical. I have never seen this kind of behavior before although I do not examine captures all that often. Any idea why the client is still sending out an ACK without receiving the SYN-ACK?
I'm a picture guy so at this point I would ask the customer for a diagram showing the client, devices between it and the Internet, and where the capture is being done. Just because the SYN-ACK isn't in the capture doesn't mean the client didn't see it.
The one sided capture could be asymmetric routing as @Jaap mentioned and @Jasper describes here or it could be how the capture is configured. Double binary copies of the
SYNseems like a SPAN/TAP/switch config issue.Add on to comment above about enabling MD5: wiki Frame page now with screen shots.