起初，我不能正确地命名我的问题，所以这将被调整
我最近经历了一个国际networking的差距。 意味着全球networking的某些部分不可用。
我能够find使用ping ， traceroute ， nmap工具哪里发生的差距和我的请求扔掉或丢弃。
最近差距的例子：
traceroute to 46.249.37.143 (46.249.37.143), 64 hops max, 52 byte packets 1 comtrend.home (10.0.0.1) 3.934 ms 0.860 ms 0.775 ms 2 88.103.200.48 (88.103.200.48) 24.264 ms 24.790 ms 23.823 ms 3 88.103.203.1 (88.103.203.1) 25.447 ms 25.848 ms 26.754 ms 4 194.228.190.1 (194.228.190.1) 34.816 ms 27.087 ms 27.312 ms 5 194.228.190.193 (194.228.190.193) 29.056 ms 27.352 ms 43.560 ms 6 ae0-0-grtprach1.red.telefonica-wholesale.net.7.16.84.in-addr.arpa (84.16.7.29) 25.538 ms 26.177 ms 25.337 ms 7 xe3-3-0-0-grtpartv1.red.telefonica-wholesale.net.121.142.94.in-addr.arpa (94.142.121.30) 45.752 ms xe-4-0-0-0-grtpartv2.red.telefonica-wholesale.net.121.142.94.in-addr.arpa (94.142.121.34) 104.951 ms 46.658 ms 8 xe7-0-0-0-grtparix1.red.telefonica-wholesale.net (84.16.14.162) 44.561 ms xe7-1-6-0-grtparix1.red.telefonica-wholesale.net (84.16.14.182) 48.202 ms xe0-3-0-0-grtpartv2.red.telefonica-wholesale.net (84.16.12.214) 47.801 ms 9 xe7-0-0-0-grtparix1.red.telefonica-wholesale.net (84.16.14.162) 44.551 ms cogent-0-0-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.50) 288.925 ms cogent-1-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.134) 158.111 ms 10 cogent-1-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.134) 198.061 ms cogent-7-3-0-grtparix1.red.telefonica-wholesale.net (213.140.52.210) 48.478 ms te0-4-0-4.mpd21.par01.atlas.cogentco.com (130.117.1.69) 48.574 ms 11 te0-4-0-4.mpd21.par01.atlas.cogentco.com (130.117.1.69) 50.303 ms te0-3-0-5.mpd21.ams03.atlas.cogentco.com (154.54.36.254) 55.350 ms te0-0-0-5.mpd21.ams03.atlas.cogentco.com (130.117.51.57) 56.176 ms 12 te0-1-0-5.mpd21.ams03.atlas.cogentco.com (130.117.51.61) 56.409 ms te0-2-0-5.mpd21.ams03.atlas.cogentco.com (130.117.51.65) 55.947 ms te7-7.mpd01.ams04.atlas.cogentco.com (130.117.50.226) 56.371 ms 13 149.11.38.30 (149.11.38.30) 57.218 ms te8-4.mpd01.ams04.atlas.cogentco.com (154.54.39.106) 55.703 ms 149.11.38.30 (149.11.38.30) 56.929 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * ^C
icmp_echo给了我请求超时，所以我追溯到46.249.37.143 （这是我的VPS）
这个最后的IP 149.11.38.30是149.11.38.30 （根据http://www.infobyip.com/ ）位于美国华盛顿特区。 这是否意味着，在华盛顿，他们阻止了这个networking节点的stream量，或者是什么？
traceroute自动执行的 请原谅我的语言能力，我不确定一切是否正确清楚。 询问有什么不清楚的地方。 谢谢
反向DNS收集IP的“所有者”真的不是要走的路。 反向表通常不会由IP提供者更新，并且在诊断方面没有太多提供。 （这在电子邮件世界中是不同的 – 因为通常会添加过滤规则来确定反向查找的有效性）。
要获得“大厦所有者”，您应该去归属权限。 RIPE只有5个地区互联网注册机构（RIR）中的1个。 AfriNIC，ARIN，APNIC，LACNIC是其中之一。 他们的WHOIS表格被支持为最新的，并为您提供官方所有者和一些联系信息。
对于更深入的调查，我喜欢ROBTEX（ http://www.robtex.com ）。 它向您显示拥有者（根据他们自己的数据库）以及其注册的对等体和AS号码（BGP所需的）。
对于停电检测来说，情况会变得更加棘手，因为“互联网”并不是每个人都认为的“大同质networking”。 你走向单一IP的路线取决于你的上游和所有的同行。 通常情况下，应该自动检测到中断，并使用“下一个可用的同行”，但是…
检测这种问题的最简单方法是使用“Looking Glasses”（例如http://www.bgp4.as/looking-glasses ）来查看是否唯一有问题将stream量路由到该目标networking。
那最后一个IP（149.11.38.30）实际上不在华盛顿特区。 提供商通常不会注册他们的骨干设备的每个IP，因为当他们移动链接等时，不需要注册它们。 另外，确定位置的许多常用技巧（请参阅使用该IP的用户使用亚马逊的地方）不适用于路由器 – 他们通常不会购买东西。
对于第一个ISP Telefonica来说，你必须对它进行一点解码。 我们从左到右，以第9跳为例。
xe-7-0-0-0-grtparix1.red.telefonica-wholesale.net
xe-7-0-0-0是接口名称，XE是指杜松子上的10千兆以太网，7-0-0-0是插槽和端口。
grtparix1是路由器名称“grt”和站点“parix1”的组合。 grt在这方面只是噪音，但是parix1暗示着这个路由器住在巴黎的一个大型互联网站点PARIX。
。红。 是西class牙语的networking，所以这是告诉你，这是客户/收入networking的一部分
和telefonica-wholesale.net是域名。
我们来试试另一个。
跳12：te0-1-0-5.mpd21.ams03.atlas.cogentco.com
te0-1-0-0-5又是十千兆位以太网（但也许不是一个杜松，因为它是te和xe'，插槽和端口名称
mpd21是特定的设备名称ams03是网站名称 – 猜测这是最有可能在阿姆斯特丹（来自AMS）和阿特拉斯是“骨干networking”子域名，“cogentco.com”是大型域名“
不幸的是，每个提供商都有不同的scheme，但是他们通常使用一些有用的代码scheme，通常是3或4个字母。 一些提供商使用机场代码，一些提供商自己组装。
为了找出什么是错误的，你需要比较一个工作的跟踪路由和一个非工作的路由路由。 我追溯到你所做的相同的IP，并在最后得到这个：
11 te2-1.mpd01.ams04.atlas.cogentco.com (130.117.49.10) 89.837 ms te1-7.mpd01.ams04.atlas.cogentco.com (154.54.36.134) 90.029 ms te4-1.mpd01.ams04.atlas.cogentco.com (130.117.2.66) 93.493 ms 12 149.11.38.30 (149.11.38.30) 94.595 ms 94.891 ms 94.903 ms 13 46.249.37.143 (46.249.37.143) 91.821 ms 90.328 ms 90.380 ms
在这种情况下，跟踪成功了，从上面的跟踪中我们可以看出，你们是在149.11.38.30之后结束的。 是149.11.38.30阻止stream量？ 也许。 或者，也许46.249.37.143无法发送数据包给你 – 无论是由于失败或由于configuration错误。 请记住，traceroute和ping必须双向进行，而且谁是错误的并不总是显而易见的，有时它会变得模糊。