跨国链路丢包总查不出来?一篇讲透 Traceroute / MTR 的实战指南(含 7 个真实场景)

跨国链路丢包到底丢在哪一跳?一篇讲透 Traceroute / MTR 的排查指南

面向后端、SRE、运维工程师。本文不讲概念拼凑,全部基于真实跨国链路排查场景,读完你应该能独立定位 90% 的跨境网络问题。

写在前面

做出海业务、海外服务器、CDN 回源、跨境 API 调用的同学,大概率被这类问题折磨过:

• 用户反馈"晚上 8 点后 App 卡得要死",白天又好好的;
• 香港机房 ping 新加坡延迟一切正常,但实际业务 HTTP 请求经常 502;
• 同一台境外服务器,电信用户正常、联通用户巨慢,换个时段又反过来;
• traceroute 打出来 30 跳,中间全是星号,看了等于没看。

这些问题背后其实都是同一个命题:链路上某一跳或某一段出了问题,但你没定位出来。

定位不出来的核心原因有两个:第一,大多数教程只告诉你"mtr 后面接个 IP",没讲清楚它的输出应该怎么"读";第二,跨国链路的特殊性(QoS 优先级、回程路由不对称、ICMP 限速)跟国内链路完全两码事,套国内经验会把人带沟里去。

这篇文章从协议原理出发,覆盖 traceroute / MTR 的工作机制、中国大陆到海外的真实线路类型(163 骨干 / CN2 GT / CN2 GIA / CMI / CUII)、以及 6 个实战场景下的判读套路。全文约 5000 字,不劝退新手,也不浪费老手时间。

---

一、Traceroute 和 MTR 到底在干什么

1.1 Traceroute 的原理:借 TTL 骗出中间跳

traceroute 的核心诡计其实就一条:IP 报文头有个字段叫 TTL(Time To Live),每经过一台路由器减一,减到 0 就被丢弃,同时路由器回一个 ICMP Time Exceeded 报文给源地址。

这个"被丢弃回通知"的特性就是整个工具的命门:

• traceroute 第一轮发 TTL=1 的探测包,走到第一跳路由器那儿被丢弃,第一跳路由器回个 Time Exceeded,你拿到第一跳的 IP;
• 第二轮发 TTL=2,第一跳减到 1 转发出去,第二跳减到 0 被丢弃,第二跳回 Time Exceeded,你拿到第二跳;
• 以此类推,直到 TTL 大到一口气走完全程,目标主机回 ICMP Echo Reply(ICMP 型)或 ICMP Port Unreachable(UDP 型),探测结束。

[源] ── TTL=1 ──▶ R1 (丢弃,回 TimeExceeded)
[源] ── TTL=2 ──▶ R1 ──▶ R2 (丢弃,回 TimeExceeded)
[源] ── TTL=3 ──▶ R1 ──▶ R2 ──▶ R3 (丢弃,回 TimeExceeded)
                      ...
[源] ── TTL=N ──▶ R1 ──▶ ... ──▶ Target (到达,回 EchoReply)

听着简单,坑在协议选择上。traceroute 有三种探测包形态:

协议	Linux 默认	Windows 默认	特点
UDP	✅ (端口 33434+)	❌	容易被运营商 QoS 限速或防火墙丢弃
ICMP	❌(需 -I)	✅ (tracert)	很多节点对 ICMP 限速,中间丢包夸张
TCP	❌(需 -T,需 root)	❌	伪装成正常业务流量,最能反映真实链路

重要结论:如果你在 Linux 上直接敲 traceroute baidu.com,出来的结果和 Windows tracert baidu.com 是两码事,因为前者用 UDP、后者用 ICMP,运营商对这两种协议的处理策略不一样。想得到贴近真实业务流量的链路,生产环境推荐用 TCP traceroute:

sudo traceroute -T -p 443 example.com   # 模拟 HTTPS 流量
sudo traceroute -T -p 80  example.com   # 模拟 HTTP 流量

1.2 MTR:连续打 Ping + Traceroute

traceroute 每一跳只探测 3 次,波动大的时候看不出问题。MTR(My Traceroute)做的事情就是对 traceroute 出来的每一跳持续发包 ping,累积统计丢包率和延迟分布。

一行典型的 mtr 输出:

 6. AS4134  202.97.35.101  0.0%  10  38.5  41.2  38.5  58.3  6.1

从左到右:跳数、ASN 归属、IP、丢包率(Loss%)、发送包数(Snt)、最近一次延迟(Last)、平均(Avg)、最小(Best)、最大(Wrst)、抖动(StDev)。

真正要看懂这行,只需要记住五个字段的组合含义:

• Loss% = 丢包率。不是看绝对值大小,而是看"后续跳 Loss 是否跟着涨"(见 1.3 节)。
• Avg vs Best 的差距。差距大说明"这跳路由器排队严重",多半是跨境链路晚高峰;差距小说明链路稳定。
• StDev = 抖动。StDev > Avg 的 30% 大概率视频/语音会出问题,实时业务敏感。
• Last。只是瞬时值,用来看"当前这一秒的感知",别拿它做判断。
• Snt。采样数太小(<20)时 Loss% 不可信。

1.3 新手最容易踩的坑:中间跳 100% 丢包不等于链路坏了

这是所有 MTR 教程都要画重点的经典误区:

Host                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1         0.0%   100    0.5    0.6   0.4   1.2   0.1
 2. 10.100.0.1          0.0%   100    1.8    2.0   1.7   3.0   0.3
 3. 202.97.35.50      100.0%   100    0.0    0.0   0.0   0.0   0.0   ← 全丢!
 4. 202.97.24.1         0.0%   100   38.2   39.1  37.5  45.2   1.5
 5. 129.250.2.26        0.0%   100   42.0   42.5  41.1  51.0   2.1

第 3 跳 100% 丢包,第 4 跳之后又完全正常 —— 这条链路有问题吗?没有。

原理:ICMP 是"管理面"协议,很多骨干路由器对自己产生的 ICMP Time Exceeded 回包做了严格限速甚至直接不回,但是它转发业务流量的能力完全不受影响。mtr 只是问它"你是谁?",它不理你;等 TTL 耗到下一跳,下一跳乐意回你,你就拿到正确数据了。

判断法则(请背下来):

只有"本跳 Loss 高 + 后续所有跳的 Loss 都不低于本跳"时,这一跳才真有问题。如果本跳 Loss 高、后续跳恢复正常,则只是该跳 ICMP 限速,忽略即可。

1.4 双向 MTR:别被单向数据误导

跨境场景下最大的隐形陷阱是回程路由不对称:你从北京到洛杉矶走的路径 A,数据从洛杉矶回到北京可能走完全不同的路径 B。

举个真实例子:某家美西机房去程是 CN2 GIA(优质),你从本地 MTR 过去看一切完美;但用户反馈还是慢 —— 原因是回程走了 163 骨干网的拥塞路径,你单向测不出来。

必须养成的习惯:排查跨境问题时同时提供双向 MTR。

• 去程:在本地(或国内机器)执行 mtr -rwbzc 100 <海外服务器IP>;
• 回程:SSH 到海外服务器,执行 mtr -rwbzc 100 <本地公网IP>。

参数含义:

• -r 报告模式(跑完退出,可以复制);
• -w 宽屏格式(不截断域名);
• -b 同时显示 IP 和反向 DNS;
• -z 显示 ASN(非常关键,后面讲);
• -c 100 发 100 个包采样(至少 100 才有统计意义)。

---

二、读懂跨境链路:中国大陆到海外的那些"路"

讲工具讲到这儿是通用知识,下面这部分是跨境特供。

2.1 电信的三条路:163、CN2 GT、CN2 GIA

这是出海业务的必备常识,用 mtr -z 打出来第一时间就要认出来:

线路	AS 号	节点 IP 特征	线路质量	典型价格
传统 163 骨干网	AS4134	202.97.x.x 开头	★★☆ (晚高峰拥堵)	便宜
CN2 GT	AS4809 (出口后)	进出国际出口前 202.97.x.x,之后 59.43.x.x	★★★★	中等
CN2 GIA	AS4809 全程	全程 59.43.x.x	★★★★★	贵(GT 的 2~3 倍)

识别套路:MTR 打出来,看进国际出口之前的那几跳走的是 202.97 还是 59.43。

• 全程 59.43 → CN2 GIA,出海首选;
• 国内 202.97、到香港/新加坡后变 59.43 → CN2 GT;
• 全程 202.97 → 传统 163。

示例:CN2 GIA 典型路由(去程美西)
 3. 59.43.187.9      (上海电信 CN2 入口)
 4. 59.43.130.201    (CN2 骨干)
 5. 59.43.130.169    (CN2 骨干,走海底光缆)
 6. 59.43.137.5      (美西 CN2 落地)
 7. 218.30.54.130    (目标机房)

示例:传统 163 典型路由(同一目的地)
 3. 202.97.35.50     (上海 163 出口)
 4. 202.97.91.18     (163 骨干)
 5. 202.97.90.66     (163 国际出口)  ← 晚高峰这儿堵
 6. 129.250.66.81    (NTT 美国)

2.2 联通和移动的"精品"线路

不止电信有优化线路,联通 CUII(AS10099)和移动 CMI(AS58453)也有各自的精品网:

• 联通 CUII A 网:AS10099,出口质量好于普通 AS4837,是联通出海的主选;
• 移动 CMI:AS58453,移动专属的国际精品线路,不少出海 VPS 选它避开 163 拥堵。

mtr -z 看到 AS10099 或 AS58453 连续出现,就是走了精品网。

2.3 晚高峰:20:00-24:00 的跨境地狱

国内跨境链路几乎都在晚高峰(UTC+8 晚 8 点到 0 点)出现拥堵 —— 原因很简单:国际出口带宽是固定的,但晚上在线人数是白天的 3~5 倍。

163 骨干网是重灾区:晚高峰 Ping 值经常从白天的 150ms 飙到 400ms+,伴随 10~30% 的丢包。这就是为啥很多跨境业务报警规则要写"排除每晚 20:00-24:00 的 163 节点异常"。

排查晚高峰问题的正确姿势:

1. 白天跑一次 MTR 作为基线(记录下来存档);
2. 晚上重跑 MTR,对比延迟和丢包是否显著上升;
3. 对比结果的"发生跃变"的跳,就是拥堵点。

如果跃变点是 202.97.x.x,说明走 163 碰上高峰,这是运营商级问题,用户侧无解,只能:

• 换更高等级的线路(163 → CN2 GT → CN2 GIA);
• 上 CDN / 加速服务绕过晚高峰拥堵段;
• 业务侧加重试 + 退避策略。

---

三、6 个真实场景 + 判读套路

讲理论到这里够了,下面是实战。每个场景给出"症状 → MTR 关键特征 → 定位结论 → 处置建议"。

场景 1:香港 VPS 突然慢了一周

症状:同事反映某香港 VPS 上的内部工具晚上打开要 10 秒+,白天正常。

MTR 关键特征(晚 21 点从上海联通测):

 5. AS9929 219.158.24.x    Loss 0%    Avg 8ms     ← 联通出口
 6. AS10099 ...             Loss 0%    Avg 40ms    ← CUII 出境
 7. AS9304 63.218.x.x       Loss 15%   Avg 180ms   ← 香港 HGC,跃变点!
 8. <target>                Loss 15%   Avg 180ms

定位:第 7 跳延迟突然从 40ms 飙到 180ms 并出现 15% 丢包,HGC(香港电讯盈科)出口拥堵,IDC 侧上游问题,不是你能修的。

处置:联系 IDC 确认上游状态,短期方案 —— 加个 CDN 前置分流,避开直连 HGC。

场景 2:美西服务器 SSH 时不时掉线

症状:SSH 进美西服务器,敲几条命令好,敲到第 5 分钟卡死,重连能上。

MTR 关键特征(-c 1000 跑 10 分钟):

                                 Loss%   Avg   StDev
 7. AS4134 202.97.90.66         0.5%   180.3   8.2    ← 平均稳定但抖动大
 8. AS3257 xe-0-0-0.chicago     0.2%   175.1   6.1
 9. AS3356 4.69.x.x             0.3%   176.8  42.7    ← 抖动爆炸!
10. target                     0.4%   178.0  45.3

定位:第 9 跳的 StDev 是均值的 24%,属于严重抖动。延迟均值看似正常,但抖动导致 TCP 重传,长连接场景下表现为周期性卡死。

处置:TCP 长连接强抖动敏感,可以:

• 应用层加 TCP keepalive(缩短间隔);
• 换 mosh 替代 ssh,mosh 用 UDP + SSP 协议,抗抖动能力比 TCP SSH 强几个档次;
• 中长期上 IPLC 专线,抖动能压到 5ms 以内。

场景 3:联通用户连新加坡全断,电信用户正常

症状:新加坡 VPS 上做 API 服务,联通出口用户全部 timeout,电信/移动正常。

MTR 关键特征(从联通测):

 2. AS4837 ...          0.0%
 3. 219.158.x.x         0.0%
 4. 219.158.x.x       100.0%       ← 从这跳起全部 100%!
 5. *                 100.0%
 6. *                 100.0%
 7. target            100.0%

定位:第 4 跳开始一路到底 100% 丢包,不是 ICMP 限速(ICMP 限速后续跳会恢复)。这是典型的运营商路由黑洞,联通到新加坡方向的某段路由失效。

处置:

1. 先确认电信、移动走同目标 IP 是否正常,如正常则 100% 是联通侧问题;
2. 拿着 MTR 截图工单报联通客服(一般 24~72 小时能动态调整路由);
3. 短期方案:起个香港中转机器做代理,绕开联通直连新加坡的坏路。

场景 4:传统的"整站打不开",但 ping 通

症状:用户说网站打不开,SRE 说 ping your-domain.com 完全正常,延迟丢包都没问题。

MTR 关键特征:ping 正常,但 traceroute -T -p 443 your-domain.com 在某一跳就断了。

定位:ICMP 和 TCP 443 走的是不同路径或被不同策略处理。典型可能是:

• 某个骨干节点对 HTTPS 做了 QoS 降级(晚高峰专属操作);
• 中间某台防火墙针对 TCP 443 做了策略限速;
• 目标服务器 443 端口的 SYN 被某一跳丢了,但 ICMP 探测包能过。

处置:永远不要只用 ICMP ping 判断"线路是否正常"。生产环境监控必须:

• tcping 443 代替 icmp ping;
• 定期用 TCP traceroute 做链路采样;
• 关注"业务流量等价的协议路径",而不是"ICMP 路径"。

场景 5:IPv6 路由 "假死"

症状:国内 IPv6 用户访问海外 IPv6 站点经常 timeout,切到 IPv4 就好。

MTR 关键特征(mtr -6 -z target):

 3. 2408:8026::xxxx     CMCC         0%      25ms
 4. 2001:252:0:100::1  HE            0%    280ms      ← 延迟跳变!
 5. 2001:470:0:x::1    HE            0%    285ms
 6. 2a00:1450:400c:x    Google       0%    320ms

定位:IPv6 路由经常绕远。这里国内 IPv6 没有直接到 Google 的优质路径,被牵引到 Hurricane Electric(AS6939 美国)兜一圈再回到 Google,额外增加 200ms+。

处置:目前国内 IPv6 国际互联依然不成熟,业务上:

• Happy Eyeballs 算法:AAAA 慢时自动 fallback 到 A 记录,现代浏览器自带;
• CDN 侧配置 IPv6 回源时选择有 6to4 优化的节点;
• 别用 IPv6 作为跨境业务的主链路,留作冗余即可。

场景 6:用户反馈"打游戏抖",工单里说"有丢包"

症状:游戏用户抱怨团战时卡顿,自己抓的 ping 截图丢包 5%,但业务方 ICMP 监控显示 0 丢包。

关键发现:游戏客户端一般用 UDP 通信,而用户和你监控用的都是 ICMP ping。UDP 和 ICMP 在骨干网的 QoS 优先级不同,UDP 经常被限速或丢包更严重。

处置:

• 生产监控必须加 UDP 丢包监测(mtr -u 可以用 UDP 探测,或自建 UDP echo 服务);
• 游戏类业务上 IPLC 或专线,UDP 大流量场景下普通国际出口不堪用;
• 客户端侧加 FEC(前向纠错)容错代码,抗 10% 以内的 UDP 丢包。

场景 7:CDN 回源慢,但用户访问正常

症状:站点挂 CDN,用户访问飞快,但 CDN 回源日志里 upstream_response_time 经常 >5s,导致源站被标记不健康、CDN 频繁回切。

特殊之处:回源路径 ≠ 用户访问路径。CDN 节点到你源站走的是 CDN 服务商自己的回源链路,可能在某个 IDC 内部网络段。

MTR 关键特征(从 CDN 厂商给的回源 IP 做 MTR 反测):

 1-5. CDN 厂商内网         0%      1-5ms
 6.   CDN 出口              0%      8ms
 7.   AS4134 202.97.x       2%      45ms    ← 进入 163
 8.   AS4134 202.97.x       8%      180ms   ← 晚高峰拥堵!
 9.   AS4134 202.97.x      15%      220ms
10.   源站 IDC 入口          15%     225ms

定位:CDN 回源走了 163 骨干网拥塞段,即使用户看起来快,源站层面承受的是完整的跨境延迟。

处置:

1. 跟 CDN 厂商沟通,申请"优质回源"或"回源加速"服务(CDN 侧会把回源流量引到 CN2 / IPLC);
2. 源站前加一层回源中转(在同区域开一台高质量线路的机器做反向代理);
3. 加大源站前的 CDN 缓存 TTL,降低回源频率(能治标)。

---

四、多节点对比:跨境排查的最佳实践

看到这里,你应该意识到一件事:单点 MTR 数据不足以下结论。

举个例子,你在上海测某个美西 IP 发现第 5 跳很慢,你推断"线路有问题"。但换个视角:

• 从北京测同一个 IP:第 5 跳完全正常 —— 说明问题可能只是上海出口局部异常;
• 从广州测:第 5 跳也慢 —— 说明是整个华东/华南出口有问题;
• 从东京测:第 5 跳不存在(因为路径不同) —— 说明这是国内段问题,不是目标服务器本身问题。

这就是为什么专业的网络排查会选择多节点同时探测,一台电脑拉出的 MTR,信息量远远不够判断跨境链路问题的真正根源。

写到这里不得不提一下 —— 我自己排查跨境链路时会常用 BiuPing 这类多节点诊断工具:它在国内三网 + 香港/新加坡/日本/美西等地部署了节点,一次请求可以拿到多个地理位置、多个运营商的 MTR 结果,IPv4 / IPv6 双栈都支持。对比国内 itdog,最大的区别是它能做 traceroute6 和 tcping6,上面讲的场景 5(IPv6 假死)在它上面是少见的能直接还原的工具。主要的使用场景是:

• 你不在全国各地有机器,但需要"模拟"多个来源 IP 对同一个目标做连通性测试;
• 排查"某地区用户打不开"类投诉,跑一次多节点 MTR 直接定位运营商段;
• 做海外服务器上线前的链路基线,所有节点的延迟/丢包存档,上线后出问题有对比。

类似的工具还有 itdog、17ce、boce 等,各有侧重,按需组合用就好。

---

五、MTR 结果怎么展示给运营商 / 上游工单才高效

排查出来问题、要上游动手的场景不少。说出你的诉求不如直接甩数据。工单正文大致按这个模板组织:

模板:

【问题】从 <本地位置> 访问 <目标 IP:端口> 异常,表现 <延迟/丢包/TCP握手失败>。

【基线(正常时段)】
- 测试时间: YYYY-MM-DD HH:MM(UTC+8)
- 工具: mtr -rwbzc 100 -T -p <port>
- 关键指标: 平均延迟 XX ms, 丢包率 0%, 抖动 XX ms
- 完整数据: [贴完整 MTR]

【现状(问题时段)】
- 测试时间: YYYY-MM-DD HH:MM(UTC+8)
- 工具: 同上
- 关键指标: 平均延迟 XX ms, 丢包率 XX%, 抖动 XX ms
- 完整数据: [贴完整 MTR]

【双向数据】
- 去程: [本地 → 目标] 完整 MTR
- 回程: [目标 → 本地] 完整 MTR

【诊断】
- 跃变发生在第 X 跳: AS<xxxx> <IP> (<城市>)
- 该跳之前: XX ms, 之后: XX ms
- 怀疑: <具体原因,如晚高峰 163 出口拥塞>

【期望】
- 上游确认 <具体节点> 状态
- 预计解决时间

重点:

1. 基线 + 现状两份数据缺一不可,不然对方只会回你"我这边测试正常";
2. 双向 MTR 必须同时提供,不然对方只会让你测另一个方向;
3. 明确指出跃变跳和 ASN,别让对方猜你看的是哪跳;
4. 给出期望的 action,不要只抱怨不提诉求。

---

六、常用命令速查

留给未来的自己:

# 跨境业务排查三件套
mtr -rwbzc 100 -T -p 443 <target>     # 模拟 HTTPS 流量,最贴近真实业务
mtr -rwbzc 100 -T -p 80  <target>     # 模拟 HTTP 流量
mtr -rwbzc 100 -I         <target>    # ICMP 探测,快速判断骨干情况

# 回程测试(SSH 到目标服务器执行)
mtr -rwbzc 100 -T -p 443 <your_public_ip>

# IPv6 链路
mtr -6 -rwbzc 100 -T -p 443 <target_aaaa>

# 只看 ASN 不看 IP 归属(快速识别运营商)
mtr -rzc 50 <target>

# 用 TCP traceroute (nmap 风格) 精确探测端口连通性
sudo nmap --traceroute -Pn -p 443 <target>

# 连续 ping 指定端口(判断 TCP 连通性)
tcping -c 100 <target> 443

---

七、常见问题 FAQ

Q1:为什么 tracert 在 Windows 跑几十秒还看不到结果?

Windows tracert 默认每跳等 3 秒 × 3 次 = 9 秒,遇到 ICMP 限速严重的骨干跳会全超时,30 跳就是 4~5 分钟。加 -w 500 参数把等待降到 500ms,速度会快很多。

Q2:mtr 的 Avg 延迟和 ping 的延迟为什么对不上?

一般有两个原因:(1) mtr 默认 ICMP,ping 也是 ICMP,两者应该对得上;不对的话看是不是 mtr -u 用了 UDP。(2) mtr 的 Avg 是统计均值,ping 看的是瞬时值,短时间抖动会导致两者偏差。看 mtr 的 Best 值,应该接近 ping 的最小值。

Q3:看到 * * * 怎么办?

分两种情况:(1) 中间某跳 * * *、后续跳正常 → 该跳不回 ICMP,忽略;(2) 从某跳开始一直 * * * 到目标 → 真的有问题,要么目标防火墙阻断 ICMP,要么中间链路断了。对付第二种,换 -T -p 443 用 TCP 探测,很多情况下能穿透 ICMP 阻断。

Q4:traceroute 和 mtr 在容器/K8s 里能用吗?

需要 NET_RAW capability,k8s 里默认关闭。给 Pod 加 securityContext.capabilities.add: ["NET_RAW"] 就行。生产集群一般不允许,建议在 DaemonSet 里部署专门的 network-diagnostic Pod,或者 SSH 到 Node 上直接跑。

Q5:云服务商之间的 MTR 和自己 IDC 的不一样?

是的,AWS / GCP / 阿里云有各自的骨干网,跨云连接会走云商之间的 Peering。比如阿里云到 AWS 新加坡经常走 "阿里云骨干 → 香港 POP → AWS Peering → AWS Singapore",这跟从自建 IDC 出去的路径完全不同。排查"为什么我在 AWS 上访问阿里云 OSS 慢",首先要排除的就是跨云 Peering 问题。

Q6:MTR 结果可以自动分析吗?

可以写脚本做基础分析:解析 MTR 输出,找出 Loss > 阈值 + 后续跳不恢复 的跳、StDev / Avg > 30% 的抖动跳、Avg 突增 > 50ms 的跃变跳。但最终还是需要人工结合 ASN、地理位置、线路类型做判断。目前业界没有完全成熟的自动化工具,人工排查仍然是主流。

---

写在最后

网络排查没有银弹,只有"看得懂现象 + 知道工具局限 + 多节点对比"三件套。

一个经验法则是:当你不确定某个结论时,换一个协议/位置/时间再测一遍。90% 的时候,单一数据源下的"异常"在多维对比后会显露出它的真实本质:是中间某跳的 ICMP 限速?是回程路由不对称?是晚高峰运营商 QoS?还是真的链路故障?

希望这篇文章能帮你在下一次"用户说网站打不开但 ping 一切正常"的工单里少走点弯路。

如果觉得有用,欢迎点赞收藏;有其他跨境排查的坑想聊,评论区见。

---

参考资料:

• IETF RFC 792 - Internet Control Message Protocol
• IETF RFC 1393 - Traceroute Using an IP Option
• Cisco CCIE - Troubleshooting Cross-Border Links
• 中国电信 CN2 网络白皮书