Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm not sure how in depth I need to go with this question, but currently I have a site-to-site VPN setup and we are having major connection issues between the two sites. I did a tracert and received an odd result:

    Tracing route to 192.168.251.209 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.5.1.254
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4   102 ms   101 ms   103 ms  192.168.251.209

Does anyone know why the request timed out twice before finding 192.168.251.209? We have had the site-to-site VPN up for over a year now, and we have never experienced any issues. I never had a reason to run a constant ping to check the packet loss before, but when I did today the packet loss is about 13%. I can ping other VPN groups and websites (google.com/shop.com) with 0% packet loss.

share|improve this question

3 Answers 3

up vote 5 down vote accepted

Non-responsive hops in the middle of a traceroute is perfectly reasonable -- it just means that whatever's decrementing the TTL on those hops doesn't want to (or can't) send you back an error packet.

To diagnose the problem with the VPN, you'll need to do packet captures, more traceroutes and pings, and have a much better idea about the architecture and devices involved before you'll have any hope of tracking down the problem. If you want to get effective help here, you'll probably need to get all that info and then put it in a question here in a suitably condensed form.

share|improve this answer
    
Thank you for the response. I have been trying to get in touch with the remote site all day. –  Jacob Mar 7 '12 at 23:34

Does anyone know why the request timed out twice before finding 192.168.251.209?

It is probably one of these:

  • The systems between are block ICMP or whatever protocol your implementation of traceroute is using.
  • The systems between you do not have a direct route to reply to your network.
share|improve this answer

Congestion, equipment failing, routing issues.

Not sure how a packet capture will help though. You will just see many packets don't arrive at the other side and are being retransmitted. If you don't control the hardware throughout the tunnel you should contact your SP for help. If you do, start looking at the logs on that equipment.

The non-responsive systems could be overloaded to the point that they are unable to respond to the traceroute as the packets would most likely be punted to the CPU for handling.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.