☰

如何解决远程互联网路由问题？

tag-icon • tag-icon internet routing traceroute packet-loss
如何解决远程互联网路由问题？

（这可能在 serverfault 上更适合回答，但从技术上讲这与服务器无关，因此欢迎提出建议......）

我们刚刚换了办公室。我们住在马萨诸塞州的剑桥，有一台康卡斯特商务级有线调制解调器。每隔几天，在一天的大部分时间里，我们都会遇到无法访问某些网站（但不是全部）的问题 - 例如 Slashdot。碰巧的是，我住在离办公室三英里的地方，家里也有一台康卡斯特商务级有线调制解调器。从办公室，我可以通过 ssh 连接到家里的服务器，尽管我使用了一些相同的路由器 - 并且全部相同的一般 POP - 我在家里没有遇到这些问题。

15 年前，我知道如何排除故障，并致电 NOC 解决问题。如今，有了负载平衡器和虚拟 IP，我却束手无策。我尝试使用下面的跟踪路由联系 Savvis，他们说“不是我们”。我将它们发送给 Slashdot，当然没有回复 - 但无论如何，这不仅仅是 Savvis 的问题，也不仅仅是 Slashdot 的问题。

我们在 ping Google 的 8.8.8.8 时偶尔也会发现 10-30% 的数据包丢失；我不知道问题是否同时发生，而且我目前还没有任何失败的跟踪路由，但成功的跟踪路由会111eighthave.ny.ibone.comcast.net直接转到 Google 而不会到达 Savvis。

从办公室进行的跟踪路由失败：

~% traceroute slashdot.org
traceroute to slashdot.org (216.34.181.45), 64 hops max, 52 byte packets
 1  * * *
 2  te-7-1-ur01.cambridge.ma.boston.comcast.net (68.87.36.241)  10.628 ms  7.029 ms  14.147 ms
 3  be-51-ar01.needham.ma.boston.comcast.net (68.85.162.157)  10.648 ms  13.714 ms  13.754 ms
 4  pos-2-1-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.95.29)  20.171 ms  18.774 ms  17.866 ms
 5  pos-1-6-0-0-pe01.111eighthave.ny.ibone.comcast.net (68.86.87.110)  20.177 ms  18.549 ms  18.130 ms
 6  er2-tengig3-3.newyork.savvis.net (208.173.138.13)  20.854 ms  19.490 ms  16.720 ms
 7  cr1-tengig-0-8-3-0.newyork.savvis.net (204.70.198.13)  15.856 ms  20.863 ms  16.717 ms
 8  cr2-tengig-0-0-2-0.chicago.savvis.net (204.70.196.242)  59.632 ms  47.147 ms  52.665 ms
 9  hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net (204.70.195.122)  40.771 ms  55.918 ms  39.418 ms
10  das4-v3044.ch3.savvis.net (64.37.207.206)  45.907 ms  45.159 ms  46.643 ms
11  64.27.160.198 (64.27.160.198)  42.509 ms  39.425 ms  67.412 ms
12  * * *
13  * * *
14  * * *
15  * * *

从家里成功跟踪路由：

~% traceroute slashdot.org
traceroute to slashdot.org (216.34.181.45), 64 hops max, 52 byte packets
 1  73.164.80.1 (73.164.80.1)  10.194 ms  13.718 ms  9.876 ms
 2  te-7-4-ur01.cambridge.ma.boston.comcast.net (68.85.160.17)  9.680 ms  6.937 ms  9.150 ms
 3  be-51-ar01.needham.ma.boston.comcast.net (68.85.162.157)  8.392 ms  7.986 ms  8.621 ms
 4  pos-2-2-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.93.185)  16.350 ms  18.983 ms  19.961 ms
 5  pos-1-4-0-0-pe01.111eighthave.ny.ibone.comcast.net (68.86.86.194)  17.208 ms  16.946 ms  20.909 ms
 6  er2-tengig3-3.newyork.savvis.net (208.173.138.13)  16.934 ms  18.493 ms  23.790 ms
 7  cr2-tengig-0-15-4-0.newyork.savvis.net (204.70.198.17)  26.530 ms  16.009 ms  14.924 ms
 8  cr2-pos-0-7-3-0.chicago.savvis.net (204.70.192.109)  40.031 ms  39.496 ms  39.807 ms
 9  hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net (204.70.195.122)  41.065 ms  45.294 ms  41.091 ms
10  das3-v3039.ch3.savvis.net (64.37.207.186)  47.867 ms  40.606 ms  40.157 ms
11  64.27.160.194 (64.27.160.194)  50.774 ms  56.097 ms  51.147 ms
12  slashdot.org (216.34.181.45)  39.788 ms  41.741 ms  39.871 ms

答案1

  1. 需要注意的是：icmp-tests（traceroute|ping）不是总是准确且正确 - 您可能已成功与端点建立 TCP 连接，但某些跳数（包括目的地）的 ICMP 响应已被过滤，并且您无法检测（简单）- 是超时还是抑制了回显答复
  2. 相同的身体的对你来说，源位置并不意味着相同的网络（我看不到办公室 IP，但我认为它必须在 68.87.3？网络的某个地方，但家庭网络是 73.164.80。）和相同的 AS（自治系统），它们是路由的基础（如果我以最简单的形式写它并删除 NOC 详细信息）
  3. 为了排除故障，您可以检查 icmp-tcp 连接（如您之前所做的一样，但最好同时检查 2 种类型），了解（最好）目标的 AS、良好来源的 AS 和不良来源的 AS，然后将票据发送至 support@ smth。 靠近“检测到您负责的区域的 AS Y 到 AS X 的连接问题，而您的 AS Z 没有显示相同类型的问题”。如果良好来源和不良来源的 AS 相同，则只需网络就足够了。
  4. “这不是我们的错”不是对 NOC 的回答!!! 你可以阅读 SLA 以获取法律工具，或者只是要求（如果可以的话）向管理层或沿途邻居“升级问题”

高血压

相关内容