cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
769
Views
0
Helpful
3
Replies

Delay inTCP segments

Marco Fiocchi
Level 1
Level 1

I have a network with bgp multihoming where I provide internet connection to my customers. Router Cisco 7206VXR (NPE-G2) has 3 neighbor remote sessions.

One of my customers complains that one website is reachable in 6 seconds and with different connection can reach website in 2 seconds (no problems with different websites).

I tried to add a static route to reach website through all ways possible and I have always 6 seconds as result.

I tried with a different connection and I can reach website in 2 seconds.

Traceroutes show me that from this connection and my bgp session the hops to go at this website are the same (at the end of path).

ICMP reply from my connection is 25 ms and I can see website in 6 seconds, from different connection ICMP reply is 40 ms and I can see website in 2 seconds.

No policies to web server is applied and in my bgp router I don't use traffic policies.

I captured a wireshark traces http to this website and different website and I have the same flow with TCP segment of a reassembled PDU but I noticed that this website sent packets after 5 seconds after http get. Could be my router to do this delay?

What can I check?

Any suggestions?

Thank you in advance

Marco

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Marco,

I would suggest focusing first on the speed of the initial TCP SYN/SYN+ACK/ACK exchange as an indicator of how fast you can actually fully open the TCP session. If this open is done within a single second (and usually, it should be done in tens of milliseconds) then the TCP itself is not at fault, and consequently, the network connection itself is not incurring the delay. In such case, it would point towards an issue with the HTTP server itself - perhaps it is doing some kind of access check or some kind of logging and the source IP address of the "delayed" link can not be looked up in DNS back to the proper name, causing the delay.

Only if you performed some kind of TCP Intercept, deep packet inspection, or some kind of HTTP gateway, it could be you at fault. If, however, the TCP connection is fully established within a second then the network itself is not causing the issue, and it starts looking more like an application layer problem.

Best regards,

Peter

View solution in original post

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Hi Marco,

I would suggest focusing first on the speed of the initial TCP SYN/SYN+ACK/ACK exchange as an indicator of how fast you can actually fully open the TCP session. If this open is done within a single second (and usually, it should be done in tens of milliseconds) then the TCP itself is not at fault, and consequently, the network connection itself is not incurring the delay. In such case, it would point towards an issue with the HTTP server itself - perhaps it is doing some kind of access check or some kind of logging and the source IP address of the "delayed" link can not be looked up in DNS back to the proper name, causing the delay.

Only if you performed some kind of TCP Intercept, deep packet inspection, or some kind of HTTP gateway, it could be you at fault. If, however, the TCP connection is fully established within a second then the network itself is not causing the issue, and it starts looking more like an application layer problem.

Best regards,

Peter

Many thanks.

I fixed the issue adding a DNS ptr record for customer IP.

Best Regards

Marco

Marco,

So good to know that the guess about issues with DNS and logging was the culprit

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco