我不知道如何深入我需要去这个问题，但目前我有一个站点到站点的VPN设置，我们有两个站点之间的主要连接问题。 我做了一个tracert，收到了一个奇怪的结果：
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 有没有人知道为什么请求超时了两次才find192.168.251.209？ 我们已经有了一年多的站点到站点的VPN，而且我们从来没有遇到过任何问题。 我从来没有一个理由去运行一个持续的ping来检查丢包情况，但是当我今天做丢包率大概是13％。 我可以ping其他VPN组和网站（google.com/shop.com）0％的数据包丢失。
在traceroute中间的非响应跳是完全合理的 – 这只是意味着不pipe怎样递减这些跳上的TTL都不希望（或不能）发回错误包。
为了诊断VPN的问题，您需要执行数据包捕获，更多跟踪路由和ping命令，并且对于所涉及的体系结构和设备有更好的了解，然后才能追踪问题。 如果你想在这里得到有效的帮助，你可能需要得到所有的信息，然后以适当的浓缩forms在这里提出一个问题。
有没有人知道为什么请求超时了两次才find192.168.251.209？
这可能是其中之一：
拥塞，设备故障，路由问题。
不知道如何数据包捕获将帮助虽然。 你会看到很多数据包没有到达另一端，正在被重新传输。 如果你不控制整个隧道的硬件，你应该联系你的SP寻求帮助。 如果这样做，开始查看该设备上的日志。
无响应的系统可能会超载，以至于无法响应跟踪路由，因为数据包很可能会被分配给CPU进行处理。