1

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.

Jacob
  • 443
  • 1
  • 9
  • 23

3 Answers3

5

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.

womble
  • 96,255
  • 29
  • 175
  • 230
  • Thank you for the response. I have been trying to get in touch with the remote site all day. – Jacob Mar 07 '12 at 23:34
1

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.
Zoredache
  • 130,897
  • 41
  • 276
  • 420
0

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.

kls
  • 379
  • 1
  • 6