very low TCP RTOs

asked 2020-03-23 17:54:17 +0000

Axel.F
3 ●2 ●3

updated 2020-03-23 18:02:21 +0000

Hi there, i'm new to the wireshark community and looking for some help.

Since a few weeks, users in my company are complaining about slow SSH connections to linux servers. They work from a distant network ( MPLS or VPN). The whole infrastructure (servers & switching) is in a datacenter, carried by some Nexus 5000 and Nexus 2000 with multiples Vlans. The routing is managed by an old fortigate F1240B, which has not been updated since v5.0

After capturing some traffic, I see that I get a huge amount of TCP retransmission, and not only for SSH connections. Looking deep into the tcp frames, I see that the initial RTO is between 1 and 5 µS which looks very low.

Are such RTO normal ? If no, what can cause this and how can I solve this problem ?

Any help would be appreciated. I searched hours on the web but could find any answers..

As I understand, RTOs are defined by TCP and not applications or OS ?

edit retag flag offensive close merge delete

Comments

If you can anonymize a capture with something like TraceWrangler or one of the tools here, post it to a public file sharing site like Google, Onedrive, S3,... then update your question with a link to the file.

Chuckc ( 2020-03-23 18:48:21 +0000 )edit

Please find the capture here :

http://dl.free.fr/getfile.pl?file=/kR...

Axel.F ( 2020-03-24 08:18:38 +0000 )edit

add a comment

answered 2020-03-24 10:07:51 +0000

SYN-bit

18543 ●9 ●345 ●255 https://SYN-b.it

I took a look at a few retransmissions in your capture. They are not retransmissions, but they are duplicate packets. Duplicate packets mess up the TCP analysis engine of Wireshark.

You can tell that they are duplicates instead of retransmissions by looking at the ip.id field of the packets. A true retransmission is a new IP packet, so it would have a new ip.id. The retransmissions have the same ip.id as the original packet, that means somehow they are either duplicated on the network or duplicated during the capturing process.

As the ip.ttl and the mac addresses of the first packet is different from the first "retransmission" you seem to be capturing before and after a routing hop, which also messes with Wireshark's TCP analysis engine.

So, please make sure you capture all packets only once.

edit flag offensive delete link

Comments

I did the capture directly from the firewall, and converted it to pcap file. This is maybe the reason of duplicates, as the FW is also the router.

In other words, it means my problem has nothing to do with low RTOs :/

BTW, how is it possible that on duplicate packets the RTO is different ?

Thanks for your analysis !

Axel.F ( 2020-03-24 12:34:14 +0000 )edit

(I converted your "answer" to a "comment" to keep the logic of this site intact)

What do you mean with the RTO on duplicate packets? RTO stands for "Retransmission Timeout" and it is the timer that is used to trigger a retransmission when no ACK has been received. As there are no retransmissions in your trace, what do you mean by RTO?

Or do you use the term RTO for the round trip time (RTT) between data and it's acknowledgement? In which case the answer is that the RTT calculation done by Wireshark is also messed up by duplicate packets.

SYN-bit ( 2020-03-24 12:40:51 +0000 )edit

Yeah, I'm talking about retransmission timeouts. I understand that there are no retransmissions in my capture but duplicates as you explained. So, if I understand, 2 captures of the same packet (aka duplicate packet) will show the same info, but the RTO is different. (ie packet 15 & 16 in the capture) I don't get this

Axel.F ( 2020-03-24 13:11:23 +0000 )edit

Now I see what you mean, Wireshark calculates an RTO for you (had not seen that before, wondering if that is new in 3.2). Since Wireshark does not recognize the duplicates, it thinks these are retransmissions of frame 14 and calculate the RTO based on that. But since they are not retransmissions, the calculated RTO also do not make sense and should not be looked at :-)

SYN-bit ( 2020-03-24 13:52:45 +0000 )edit

Thanks for you explanations, its clear for me now ;)

Axel.F ( 2020-03-26 09:25:01 +0000 )edit

see more comments

very low TCP RTOs

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

very low TCP RTOs edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

very low TCP RTOs