跨境 BGP 路由劫持、AS-Path 污染与多线路出口优化的可观测性排查

跨境链路的故障单里，真正由物理层中断引起的比例远低于直觉。多数“访问变慢”“出口漂移”“丢包集中在某一段”的工单，最终落到同一个位置：BGP 决策过程在某个 AS 边界上选了一条与工程预期不同的路径。这条路径在控制平面完全合法，转发平面也正常工作，只是它绕了 8000 公里，或者它把流量送进了一个只有 100G 上行、却承载了 400G 需求的转接商。

排查这类问题需要把控制平面和转发平面分开看。控制平面回答“为什么选这条路”，转发平面回答“这条路实际跑成什么样”。两个平面之间的偏差，才是跨境 BGP 问题最难定位的部分。下面按协议机制、故障分类、取证手段、可观测性工具链的顺序展开，所有结论都对应可复现的命令与字段。

BGP-4 决策过程与跨境选路的真实约束

决策顺序决定了什么可以被优化

BGP-4 的路径选择不是单一度量，而是一串严格的比较序列。RFC 4271 定义的顺序在工程实现里被各厂商微调，但主干一致：

1. 最高 Weight（Cisco 私有，本地有效，不传递）
2. 最高 Local Preference（默认 100，IBGP 内传播）
3. 本地始发优先（network 命令或 redistribute 注入）
4. 最短 AS-Path
5. 最低 Origin 类型（IGP < EGP < Incomplete）
6. 最低 MED（Multi-Exit Discriminator，默认仅在相邻 AS 间比较）
7. EBGP 优先于 IBGP
8. 最低 IGP 到 NEXT_HOP 的度量
9. 最老的路由（部分实现）
10. 最低 Router ID
11. 最低 Cluster List 长度
12. 最低邻居地址

跨境场景里，前四项基本决定了 90% 的结果。Local Preference 是本地策略，跨境运营商无法影响；真正跨 AS 谈判的杠杆只有 AS-Path 长度和 MED。这解释了一个常见现象：客户在两家 Tier-1 之间做双线接入，期望按带宽比例分流，实际却 90% 流量走其中一家。原因通常是另一家的通告里 AS-Path 多了一跳，或者对端没有接受 MED 比较（MED 默认只在同一相邻 AS 的多条路径间比较，跨 AS 不生效，除非显式配置 bgp always-compare-med）。

AS-Path 长度是一个被严重高估的度量

AS-Path 长度统计的是 AS 号个数，不是跳数，不是延迟，不是带宽。一个经过 3 个 AS 的路径可能穿越太平洋两次，一个经过 5 个 AS 的路径可能全程在同一个城域网内。用 AS-Path 长度近似“路径质量”在跨境场景里会系统性出错。

更关键的是 AS-Path 可以被“加长”来人为降权。这叫 AS-Path prepending，是合法的流量工程手段。运营商在备用链路上 prepend 自己的 AS 号 3 到 5 次，让对端优先选主链路。问题在于 prepend 是粗粒度的：它对所有目的地生效，无法区分“从欧洲来的流量”和“从南美来的流量”。当一家运营商对某前缀 prepend 了 4 次，而另一家没有 prepend，全球所有观察点都会把流量导向未 prepend 的那家，后者的容量可能根本撑不住。

## 典型的 prepend 观察：同一前缀在不同 Looking Glass 上的 AS-Path
## 观察点 A (Frankfurt)
64500 1299 3356 15169
## 观察点 B (Singapore)
64500 1299 3356 3356 3356 15169
## 观察点 C (Los Angeles)
64500 1299 3356 15169

上面这组数据里，观察点 B 看到的路径被 prepend 了两次。如果 B 所在区域是主要用户来源，说明该区域的入向流量被刻意压低，或者上游在 B 方向做了策略性降权。两种解释需要不同的处置，前者是主动设计，后者是配置事故。

MED 的跨 AS 局限

MED 的设计意图是让一个 AS 告诉相邻 AS“从哪个入口进来更好”。RFC 4271 明确规定 MED 默认只在来自同一相邻 AS 的多条路径间比较。跨境多线场景里，客户的两条上行来自不同 Tier-1，MED 根本不参与比较，Local Preference 和 AS-Path 长度才是决定因素。很多“MED 配置了但不生效”的工单，根因就在这里。

要跨 AS 比较 MED，需要在接收侧配置 bgp always-compare-med，但这会引入环路风险和次优路径，生产环境慎用。更稳妥的做法是在自己的边界路由器上用 route-map 基于 community 打 Local Preference，把上游的意图翻译成本地可控的优先级。

跨境路由故障的三类形态

路由泄露：合法通告的错误传播

路由泄露（route leak）指一个 AS 把从某个上游学到的路由，错误地通告给了另一个上游或对等体。这违反了 valley-free 转发原则：商业关系里，流量应该从客户流向提供商，或在对等体之间平级流动，不应该出现“从提供商学到、再通告给另一个提供商”的情况。

泄露的后果是流量被吸入一个本不该承载它的 AS。2019 年某欧洲运营商的一次泄露导致全球大量前缀被导向其网络，部分区域延迟上升 300ms 以上，持续数小时。泄露的路由在控制平面完全合法，RPKI 校验也可能通过（因为源 AS 正确），只有 AS-Path 的拓扑语义能暴露异常。

识别泄露的关键是看 AS-Path 里是否出现了不该出现的 AS 关系序列。比如一个 Tier-3 客户的 AS 号出现在两个 Tier-1 之间，或者一个已知的单归属 AS 突然出现在多条互不相关的路径中间。

路径伪造与前缀劫持

前缀劫持指某个 AS 通告了不属于它的前缀。经典案例是 2008 年巴基斯坦电信对 YouTube 前缀的通告，导致全球流量被导向巴基斯坦，最终因容量不足而全网不可达。更隐蔽的变种是子前缀劫持：通告一个更具体的前缀（/24 对 /16），由于 BGP 的最长匹配原则，更具体的前缀总是优先，即使它的 AS-Path 更长。

AS-Path 伪造是另一层。攻击者可以在通告里插入受害者的 AS 号，让路径看起来像是经过受害者网络。这会污染下游所有观察点的路由表，且难以通过简单的源验证发现。RPKI 的 ROA 只能验证“这个 AS 是否有权通告这个前缀”，无法验证“AS-Path 里的中间 AS 是否真实经过”。

## 前缀劫持的转发平面表现：traceroute 在某跳后进入异常 AS
## 正常路径
 4  10.0.0.1      1.2 ms
 5  203.0.113.9   8.4 ms   AS 64500
 6  198.51.100.1  12.1 ms  AS 1299
 7  192.0.2.33    145.7 ms AS 15169
## 劫持后
 4  10.0.0.1      1.2 ms
 5  203.0.113.9   8.4 ms   AS 64500
 6  198.51.100.1  12.1 ms  AS 1299
 7  198.18.0.1    312.4 ms AS 65001   <- 异常 AS，延迟突增
 8  192.0.2.33    318.9 ms AS 15169

次优路由与跨洋环路

次优路由不涉及恶意，纯粹是策略组合的副作用。典型场景：流量从亚洲出口，本应走太平洋直达美西，但因为某条路径的 Local Preference 更高，被导向欧洲，再从欧洲跨大西洋到美东，最后回美西。物理距离翻倍，延迟从 120ms 涨到 280ms。

跨洋环路的识别依赖逐跳 AS 解析。单纯看 traceroute 的 IP 和延迟不够，必须把每一跳映射到 AS 号，再结合地理信息判断路径是否绕行。一个实用判据是：如果路径里连续出现两个分属不同大洲的 Tier-1 AS，且中间没有合理的落地，基本可以判定为绕行。

控制平面取证：Looking Glass 与路由表分析

Looking Glass 的正确用法

Looking Glass 是运营商公开的路由查询接口，返回指定观察点对某前缀的 BGP 表项。用法上有几个要点。

第一，选多个地理分散的观察点。单一观察点只能反映局部视图，跨境问题往往只在特定区域出现。至少取三个：用户主要来源地、目标落地地、以及一个中立第三方。

第二，看 AS-Path 的完整序列，不只看长度。序列里的 AS 关系能揭示泄露和伪造。一个健康的路径，AS 序列应该符合商业关系链：客户 AS 在前，转接商在中，目标 AS 在后，中间不应出现平级对等体之间的来回跳转。

第三，对比不同时间点的快照。BGP 是收敛协议，一次策略变更的影响会在几分钟到几十分钟内扩散到全球。如果某前缀的 AS-Path 在短时间内发生结构性变化，说明上游做了策略调整或发生了故障切换。

## 通过 ConnProof 采集多出口的 DNS 解析结果，比对不同出口看到的权威服务器
connproof dns example.com --verbose --format json
connproof dns example.com --ipv4 --timeout 5 --verbose

DNS 解析结果本身不直接反映 BGP，但不同出口解析到不同 CDN 节点，能间接暴露出口的地理位置和运营商归属。当某出口的解析结果突然指向一个远端节点，往往意味着该出口的 BGP 路径发生了变化，把 DNS 查询送到了一个不同的 anycast 实例。

路由表分析的关键字段

拿到 BGP 表项后，重点看四个字段：AS-Path、Origin、MED、以及 Next Hop 的可达性。

Origin 字段有三个取值：IGP（0）、EGP（1）、Incomplete（2）。跨境场景里，如果一条路径的 Origin 是 Incomplete，通常意味着该前缀是通过 redistribute 注入的，来源可能是直连或静态路由，这类路径的稳定性往往不如 IGP 始发的路径。

MED 字段只在同一相邻 AS 的多条路径间有意义，前文已述。Next Hop 的可达性则决定了路径是否真正可用：一条 AS-Path 再短，如果 Next Hop 不可达，路径会被标记为 invalid，不参与转发。

RPKI 与 IRR 的交叉验证

RPKI 通过 ROA（Route Origin Authorization）验证前缀与源 AS 的绑定关系。查询某前缀的 ROA 状态，可以快速排除源伪造。但 RPKI 不验证 AS-Path 中间节点，所以对路径伪造无效。

IRR（Internet Routing Registry）记录的是运营商自愿登记的路由策略对象，包括 route 对象和 aut-num 对象。IRR 数据质量参差不齐，很多历史记录未更新，但作为交叉参考仍有价值。当 RPKI 显示 valid 而实际路径异常时，IRR 里的策略描述能帮助判断该 AS 的预期通告行为。

转发平面取证：MTR 与逐跳 AS 解析

MTR 的局限与正确解读

MTR 结合了 traceroute 和 ping，能给出每一跳的丢包率和延迟分布。跨境排查里，MTR 最常见的误读是把中间跳的丢包当成故障。

中间跳丢包率高但末端不丢包，说明该跳的路由器对 ICMP 做了限速（control plane policing），这是正常配置，不代表转发故障。真正需要关注的是：从某一跳开始，后续所有跳都出现丢包，且末端也丢包。这才是转发路径上的实际问题。

MTR 的另一个局限是 ECMP。现代骨干网普遍部署等价多路径，同一对源目的之间的不同探测包可能走不同路径。MTR 显示的“路径”是多条路径的混合，逐跳延迟的抖动可能来自路径切换而非链路质量。要缓解这个问题，可以固定源端口或用 Paris traceroute 技术，但多数现成工具不支持。

## MTR 报告里需要区分的两种丢包模式
## 模式 A：中间跳丢包，末端正常（正常，ICMP 限速）
 5  203.0.113.9   0.0%   8.4 ms
 6  198.51.100.1  40.0%  12.1 ms   <- 限速，不转发故障
 7  192.0.2.33    0.0%   145.7 ms
## 模式 B：从某跳起持续丢包，末端也丢（真实故障）
 5  203.0.113.9   0.0%   8.4 ms
 6  198.51.100.1  35.0%  12.1 ms
 7  192.0.2.33    38.0%  145.7 ms  <- 持续丢包
 8  192.0.2.34    40.0%  146.2 ms

逐跳 AS 号映射

traceroute 输出的是 IP，排查跨境问题需要把 IP 映射到 AS 号。方法有三种：查 whois、查 IRR、用 BGP 表反查。whois 最快但可能过时，IRR 次之，BGP 表最准但需要本地有完整视图。

映射完成后，把 AS 序列画出来，对照商业关系判断路径是否合理。一个实用的检查清单：

• 路径里是否出现了两个互为对等体的 Tier-1（说明流量在两个骨干间来回）？
• 是否出现了已知的泄露源 AS？
• 源 AS 到目标 AS 之间，AS 数量是否显著多于历史基线？
• 每一跳的延迟增量是否与地理距离匹配（跨太平洋单程约 50-70ms，跨大西洋约 35-45ms）？

延迟增量与距离不匹配是绕行的强信号。比如某跳延迟从 12ms 跳到 145ms，增量 133ms，对应约 13000 公里的光纤路径，如果两端 AS 实际地理距离只有 3000 公里，说明路径绕了远路。

用 ConnProof 做多出口延迟指纹比对

单点 traceroute 只能看到一条路径。多出口比对才能定位“哪个出口的路径变差了”。ConnProof 的 diagnose 和 tcp 子命令可以对多个出口节点执行延迟测量，把结果横向对比。

## 对多个出口节点执行诊断，比对 TCP 握手延迟
connproof diagnose example.com --port 443 --timeout 5 --verbose
connproof tcp example.com --port 443 --ipv4 --timeout 3 --verbose
connproof tcp example.com --port 443 --ipv6 --timeout 3 --verbose

## TLS 握手耗时单独测量，排除 TCP 层干扰
connproof tls example.com --port 443 --timeout 5 --verbose --format json

## 整体健康检查，确认本地网络栈无异常
connproof doctor --verbose

延迟指纹比对的逻辑是：如果多个出口对同一目标的 TCP 握手延迟差异超过 50ms，且差异稳定复现，说明这些出口的 BGP 路径不同，且至少有一个是次优的。进一步用 tls 子命令测量 TLS 握手耗时，可以区分“网络层延迟”和“应用层处理延迟”。TLS 握手包含多次往返，对路径延迟敏感，但对中间设备的处理能力也敏感，两者需要分开看。

比对时要注意基线。跨境链路的正常延迟有物理下限：中国到美西约 130-150ms，到欧洲约 180-220ms，到新加坡约 40-60ms。低于下限说明测量有问题（可能是 CDN 就近响应），高于下限 50% 以上说明路径异常。

多线路出口优化的可观测性设计

出口漂移的检测

出口漂移指同一会话的流量在不同时间走了不同出口。这会导致源 IP 变化，进而触发目标端的会话失效、风控拦截或 CDN 缓存击穿。检测方法是持续采样出口 IP，比对变化。

## 周期性采集出口 IP，比对是否漂移
connproof diagnose ifconfig.me --port 80 --timeout 5 --verbose
connproof diagnose api.ipify.org --port 443 --timeout 5 --verbose

出口漂移的根因通常是 BGP 路径变化或本地策略路由切换。前者由上游触发，后者由本地配置触发。区分方法是看漂移是否伴随延迟突变：如果出口 IP 变了且延迟也变了，大概率是 BGP 路径切换；如果 IP 变了但延迟稳定，可能是本地策略路由或 NAT 池轮转。

站内 会话中出口线路发生变化 一文记录了这类故障的典型表现和处置流程，可以作为排查的参照。

线路类型对 BGP 行为的约束

不同线路类型的 BGP 行为差异很大。IEPL 和 IPLC 是点对点专线，不经过公网 BGP，路径固定，延迟稳定，不存在路由劫持问题，但成本高、灵活性差。普通公网出口走 BGP，路径动态，成本低，但受上游策略影响。

选择线路类型时，需要把“可观测性需求”作为输入。如果业务对延迟抖动敏感（比如实时音视频），专线的确定性比公网的灵活性更重要。如果业务对成本敏感且能容忍路径变化，公网加多线冗余更合适。站内 IEPL 与 IPLC 专线区别 详细对比了两类专线的技术差异，线路类型自测指南 给出了自助判定线路类型的方法。

多出口的延迟指纹基线

建立基线是优化的前提。对每个出口，定期采样到关键目标（主要用户区域、主要云服务商、主要 CDN）的 TCP 握手延迟和 TLS 握手延迟，形成时间序列。基线建立后，异常检测就变成简单的阈值比较。

基线的采样频率需要权衡。太高会增加探测流量，太低会漏掉短时故障。跨境链路的典型故障持续时间从几分钟到几小时不等，5 分钟一次的采样能覆盖多数场景。采样点要分散在不同时间段，避免只采到低谷时段的乐观数据。

延迟指纹的维度包括：TCP 握手 RTT、TLS 握手总耗时、DNS 解析耗时、以及到目标的首字节时间。四个维度组合起来，能区分网络层问题、传输层问题、应用层问题。

工程实践中的权衡与失败边界

可观测性的成本

全量采集 BGP 表和逐跳延迟的成本很高。一个完整的 BGP 视图有近百万条前缀，逐跳探测每个前缀的延迟不现实。实际做法是分层采样：核心前缀全量监控，长尾前缀抽样监控。核心前缀的选择依据是业务流量占比，通常前 100 个前缀覆盖 80% 以上的流量。

探测流量的成本也要考虑。主动探测会产生额外的网络流量，跨境链路的流量成本不低。探测频率和探测点数量需要根据预算调整。被动观测（分析现有流量的 RTT 分布）成本低但覆盖不全，主动探测覆盖全但有成本，两者结合是常见方案。

策略调整的副作用

BGP 策略调整的影响范围往往超出预期。一次 Local Preference 修改可能影响所有经过该路由器的流量，一次 prepend 可能改变全球多个区域的选路。调整前需要在测试环境验证，调整后需要持续观测收敛过程。

收敛时间取决于前缀数量和网络规模。全球范围的 BGP 收敛通常需要几分钟到几十分钟。在收敛期间，不同观察点看到的路由不一致，流量可能走临时路径。这个窗口期是故障高发期，需要重点监控。

无法解决的问题

有些跨境路由问题是无法通过本地手段解决的。上游运营商的策略由他们控制，客户只能通过合同或对等互联谈判影响。路径伪造和恶意劫持需要全球层面的 RPKI 部署和 BGPsec 推广才能根治，当前阶段只能检测和缓解。

承认这些边界很重要。排查的目标不是“消除所有异常”，而是“快速识别异常、评估影响、选择可行的缓解手段”。多数情况下，缓解手段是切换出口、调整本地优先级、或联系上游。彻底修复依赖整个生态的演进。

排查流程的收敛

把上述手段串成一个可执行的流程：

1. 症状确认。用 ConnProof 的 diagnose 和 tcp 子命令测量多出口延迟，确认异常是全局的还是特定出口的。
2. 控制平面取证。用 Looking Glass 查目标前缀在多个观察点的 AS-Path，比对历史基线，识别泄露、伪造或绕行。
3. 转发平面取证。用 MTR 逐跳测量，映射 AS 号，对照地理距离判断路径合理性。
4. 交叉验证。RPKI 查源验证，IRR 查策略描述，DNS 解析结果辅助判断出口归属。
5. 处置。根据根因选择切换出口、调整本地策略、或联系上游。处置后重复步骤 1 确认效果。

这个流程的核心是把控制平面和转发平面的证据对齐。单看任何一个平面都会得出片面结论。控制平面说路径正常但转发平面延迟异常，说明问题在路径之外的环节（比如中间设备的队列或限速）；转发平面正常但控制平面显示路径变化，说明变化尚未影响转发或影响被掩盖。

跨境 BGP 排查的难点不在工具，在证据的组织。工具输出的原始数据需要被翻译成“哪个 AS 在什么位置做了什么决策”，这个翻译过程依赖对协议语义和商业关系的理解。工具能加速取证，判断仍然依赖工程师。