我的 ISP 是一家国有企业，它从不同的中转提供商处购买带宽。每当它购买中转时，它只会通过新的中转 AS 宣布一个特定的前缀（大多数情况下是迄今为止未使用的前缀）。例如，如果它用完了带宽，它会从新的中转中购买带宽并通过它宣布一个新前缀，而相同的前缀不会通过继续为其提供带宽的旧中转宣布（或以最低指标宣布，因此很少使用这些路由）。我是一个商业客户，所以我有一个基于光纤的 ISP 链路，并给我一个很小的子网。
提供给我的子网是前缀的一部分，该前缀由中转的 AS 宣布，但似乎中转的 AS 不在我的国家/地区。因此，当我跟踪数据包时，当它们离开我的 ISP 的 AS 时，它们需要大约 275 毫秒才能到达位于美国（地球另一边）的中转提供商核心路由器。此外，对于上行流量，我的 ISP 使用在我国家/地区有业务的中转提供商（第 1 级）。但返回路径始终是通过位于美国的中转。
因此，平均延迟为 400 毫秒。我所在国家/地区其他 ISP 的所有其他用户都通过美国发现我的子网。甚至来自邻国（欧洲，距离更近）的流量也通过美国路径。使用 CDN 的站点也会解析到美国的 IP。
我已将此问题告知 ISP NOC，并要求他们提供本地中转（最好是一级中转提供商）公布的前缀的 IP 子网，我正在等待答复。我的问题是：这是一个严重的问题，我必须跟进才能解决吗？当我比较我国其他提供商的延迟时，在大多数情况下，它不到我 ISP 延迟的一半。为什么我的 ISP 不向其所有中转提供商公布其所有前缀，以便数据包可以采用高效且最近的路由来到达源自其网络内的前缀？
答案1
这是一个严重的问题吗？我必须跟进才能解决吗？
是的，本质上是您的提供商给您提供了糟糕的连接。所有客户都希望他们的流量首先在他们自己的大陆内路由。因此，如果您在印度，而典型的印度/欧洲客户必须跨越两次海洋才能访问您的服务器，那么这是一个大问题。
当我比较我所在国家/地区其他提供商的延迟时，大多数情况下，延迟不到我所在 ISP 延迟的一半。为什么我的 ISP 不向其所有中转提供商公布其所有前缀，以便数据包能够采用高效且最近的路由到达源自其网络内的前缀？
这通常归结为（选择一个或多个）：
- 他们没有检查上游是否向您所在大陆的其他 NAP 通告了您的前缀；也许他们有一个初级工程师负责处理他们的 BGP 策略，而这个工程师不知道在更改路由策略后需要检查什么
- 他们试图平衡流量以尽量降低成本（因为他们按 Mbps 支付传输费用）
- 上游（本例中为 C&W）决定更改自己的出站路由策略，而 VSNL 并不知道
编辑：
实际上，您的提供商似乎正在向至少两个不同的上游宣布超级网：AS 1273和AS 4755（VSNL）
route-views>sh ip bgp 117.240.120.0
BGP routing table entry for 117.240.112.0/20, version 1257325932
Paths: (35 available, best #26, table Default-IP-Routing-Table)
Not advertised to any peer
3277 3216 1273 9829 <------------------------------------------- C&W
194.85.102.33 from 194.85.102.33 (194.85.4.4)
Origin IGP, localpref 100, valid, external
Community: 1273:11840 3216:3000 3216:3001 3277:3216
6539 1273 9829
66.59.190.221 from 66.59.190.221 (66.59.190.221)
Origin IGP, localpref 100, valid, external
4436 1273 9829
69.31.111.244 from 69.31.111.244 (69.31.111.244)
Origin IGP, metric 186, localpref 100, valid, external
Community: 1273:11840 4436:31611
101 101 11164 22822 1273 9829
209.124.176.223 from 209.124.176.223 (209.124.176.223)
Origin IGP, localpref 100, valid, external
Community: 101:20100 101:20120 101:22100 11164:1170 11164:7790
Extended Community: RT:101:22100
3549 1299 1273 9829
208.51.134.254 from 208.51.134.254 (67.17.81.150)
Origin IGP, metric 1, localpref 100, valid, external
2828 6453 4755 9829 <------------------------------------------- VSNL
65.106.7.139 from 65.106.7.139 (66.239.189.139)
Origin IGP, metric 3, localpref 100, valid, external
16150 1299 1273 9829
217.75.96.60 from 217.75.96.60 (217.75.96.60)
Origin IGP, metric 0, localpref 100, valid, external
Community: 1299:20000 16150:63392 16150:65326
2914 1273 9829
129.250.0.11 from 129.250.0.11 (129.250.0.12)
Origin IGP, metric 37, localpref 100, valid, external
Community: 2914:420 2914:1005 2914:2000 2914:3000 65504:1273
1239 1273 9829
144.228.241.130 from 144.228.241.130 (144.228.241.130)
Origin IGP, localpref 100, valid, external
3333 1273 9829
193.0.0.56 from 193.0.0.56 (193.0.0.56)
Origin IGP, localpref 100, valid, external
route-views>
我从位于美国（德克萨斯州）的一台服务器进行追踪，跨越太平洋，AS 4755（VSNL）：
[mpenning@Bucksnort ~]$ sudo lft -A 117.240.120.67
Tracing _________________________________________________________________________
TTL LFT trace to 117.240.120.67:80/tcp
1 [ASxxxxx] REDACTED 0.4ms
2 [ASxxxxx] REDACTED 0.4ms
** [neglected] no reply packets received from TTL 3
4 [AS174] te0-1-0-7.ccr22.dfw01.atlas.cogentco.com (154.54.0.121) 0.7ms
** [neglected] no reply packets received from TTLs 5 through 6
7 [AS174] teleglobe.dfw03.atlas.cogentco.com (154.54.13.134) 0.9ms
8 [AS6453] if-2-2.tcore2.DT8-Dallas.as6453.net (66.110.56.6) 261.0ms
9 [AS6453] if-3-2.tcore1.LVW-LosAngeles.as6453.net (66.110.57.62) 262.0ms
10 [AS6453] if-2-2.tcore2.LVW-LosAngeles.as6453.net (66.110.59.2) 263.6ms
11 [ASN?] if-7-2.tcore2.SVW-Singapore.as6453.net (180.87.15.25) 267.2ms
12 [ASN?] if-5-2.tcore2.CXR-Chennai.as6453.net (180.87.15.70) 270.7ms
13 [ASN?] 180.87.37.46 272.8ms
** [neglected] no reply packets received from TTL 14
15 [AS4755] 59.163.206.158.static.chennai.vsnl.net.in (59.163.206.158) 295.7ms
16 [AS9829] 218.248.237.161 296.7ms
** [80/tcp failed] Try alternate options or use -V to see packets.
[mpenning@Bucksnort ~]$