11-13-2013 08:12 AM - edited 03-04-2019 09:34 PM
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
Solved! Go to Solution.
11-13-2013 08:24 AM
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
11-13-2013 08:24 AM
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
11-14-2013 04:09 AM
Many thanks.
I fixed the issue adding a DNS ptr record for customer IP.
Best Regards
Marco
11-15-2013 04:12 AM
Marco,
So good to know that the guess about issues with DNS and logging was the culprit
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide