我一次跑了下面的traceroute，同时试图排除networking问题。
c:\>tracert linode.com -d Tracing route to linode.com [67.18.186.61] over a maximum of 30 hops: 1 <1 ms * <1 ms 10.43.51.252 2 1 ms <1 ms <1 ms 10.45.253.33 3 <1 ms <1 ms <1 ms 10.62.254.251 4 20 ms 23 ms 45 ms 192.118.32.52 5 47 ms 20 ms 85 ms 207.232.60.250 6 54 ms 24 ms 79 ms 212.143.8.69 7 7 ms 79 ms 11 ms 212.143.8.209 8 89 ms 110 ms 108 ms 212.143.12.75 9 143 ms 240 ms 94 ms 212.143.14.154 10 244 ms 179 ms 95 ms 10.50.1.1 11 176 ms 80 ms 190 ms 195.66.225.105 12 174 ms 164 ms 157 ms 70.87.255.217 13 187 ms 185 ms 186 ms 70.87.253.189 14 189 ms 194 ms 195 ms 70.87.253.18 15 187 ms 188 ms 190 ms 70.87.253.126 16 187 ms 185 ms 185 ms 70.87.254.78 17 186 ms 184 ms 187 ms 67.18.186.61 Trace complete. 前三个站点是本地路由器/网关; 忽略这些。
然而，我不确定第10步如何能把10.50.1.1作为目标呢？ 这不是一个不可路由的IP，不应该在任何地方从公共路由器find？
RFC1918地址（10 / 8,172.16 / 12和192.168 / 16）不应出现在全局路由表中，因为它们被devise为在“单一企业”中使用。 但是，即使跨越这些链路的stream量用于“可全局路由的”IP地址范围，在某种程度上，为您的核心内的点对点链路使用RFC1918地址也是有意义的，因为这节省了稍微稀缺的资源。
在跟踪路由中出现的原因是IP帧的TTL在与接口IP的接口上过期。 这样做的缺点是难以ping通接口，并在这个问题上做一些故障排除，但不能保证你应该能够做到这一点。
所以，我想说这可能有点不同寻常，但这当然不是闻所未闻的。
对我来说这似乎很奇怪。 在路由中间看到私有IP也是完全没有问题的，因为单个组织可以在其networking中使用私有IP。 但根据whois，212.143.14.154和195.66.225.105由两个不同的组织拥有。 但是，也许这两个组织之间有一个点对点，在这种情况下，可以使用私有IP。
术语不可路由不完全准确，因为它们可以路由。 但是， RFC1918所使用的术语应该只被单个“企业”使用。 这就是为什么我觉得这有点奇怪。
我看到它发生在一些瞻博networking路由器上。 他们有适当的公共IP地址分配，但路由器发送ICMP响应私人IP绑定到pipe理界面（不能从公共互联网访问）。
有可能是通过某人的内部networking，通过MPLS或类似的地方，他们正在使用内部IP。
我同意Cian的意见。 有时这些广域网跳线有一个回送专用IP地址。 出于某种原因，这是在tracert中返回的。 一个名为Wireshark的程序（非常好的免费软件）可以让你更深入的了解你的networking问题。
曼尼