摘要

  • BGP 通常把 AS_PATH 中出现本地 ASN 视作环路证据；allowas-in 改变接收方的裁决，as-override 则在裁决前改写证据。
  • 两种机制都可能服务于复用 ASN 的多站点网络，但它们不认证前缀，也不证明 FIB 与报文路径；Route Target 与 Site of Origin 不能混为一谈。
  • 合格的变更记录必须保存改写前后路径、实际邻居与地址族范围、出现次数、站点和前缀控制，并验证 Loc-RIB、FIB、双向报文和回退。

这次拒绝本来就是正确的

先看一个机制示例，而非真实事故。分支 A 与分支 B 位于同一服务中，两个站点都使用同一个客户 ASN。A 发布一个前缀，服务商把它送到 B；B 的路由器在 AS_PATH 里看到自己的 ASN，于是拒绝。会话正常，服务商也有路由，但 B 无法使用它。

这不是莫名其妙的互通故障，而是普通防环机制给出的正确结论。RFC 4271 要求 BGP speaker 把包含自身 ASN 的路由排除在决策过程之外，并明确表示，允许接收自身 ASN 的运行方式不在该规范范围内。路径传递的警告是：这条信息已经经过了你的路由域。RFC 4271

此时常见两个提议。其一，由客户路由器容许有限次数的自身 ASN，即 allowas-in 或 allow-own-as；其二，由服务商在向客户通告前，把路径中与客户 ASN 相同的项替换掉，即 as-override。

两者都可能让路由变绿，却不是同一个控制。前者保留 AS_PATH，改变接收者如何解释它；后者先改变 AS_PATH，使默认拒收条件不再触发。一个把例外权交给客户边界，一个把路径历史的保管责任交给服务商边界。

AS_PATH 是证据，不是签名

AS_PATH 支持防环和选路，却不是对物理转发经过的加密证明。RFC 4272 指出，speaker 主要核对的是自身 ASN，并不会验证路径上每次声称的跳转；错误或缩短的路径也可能改变选路并引发环路。恰恰因为它可变、由本地解释，AS_PATH 才是一项必须谨慎保管的运营证据。RFC 4272

allowas-in 改的是接收裁决。实际实现可能提供出现次数上限、仅 origin 适用、route-map、邻居组和地址族范围。FRRouting 文档列出了这些局部控制；RFC 7938 则在复用私有 ASN 的数据中心 Clos 语境中，把 allowas-in 描述为广泛存在但未标准化的功能。它们说明可以缩小范围，却没有给出跨厂商通用的“安全次数”。FRRouting BGP 文档，RFC 7938

as-override 改的是发送内容。FRRouting 与 Junos 都记录了把 AS_PATH 中等于 peer ASN 的项替换为本地或服务商 ASN 的行为。Junos 还说明，客户为了影响选路而重复 prepend 的 ASN 也会被替换。路径长度可能近似不变，但原先解释“这些位置由谁加入”的身份信息已经消失。FRRouting BGP 文档，Junos as-override

因此，变更后一张路由表截图不是充分证据。它只展示了已经经过关键决定的结果。审计应同时保留客户原始通告、服务商接收路径、改写前的预期出口、实际出口路径，以及远端客户最终接受的路径。缺少其中任何一段，后续就无法区分受控改写与意外丢失的路径历史。

成员资格、站点来源和前缀授权各司其职

VPN 环境里有几个容易混淆的控制。RFC 4364 中，Route Target 决定哪些 VPN 路由有资格被导入；Site of Origin 标识路由来自哪个站点，并用于阻止路由再次回送到该站点的 CE。前缀授权又回答另一件事：该客户或接入点是否有权发布这个前缀。RFC 4364

Route Target 不能替代被消耗的 self-AS 证据；它甚至可能把一条发生循环的路由准确送给所有被配置的成员。SoO 更接近站点环路问题，但只有相关接入点一致设置并执行时才有作用。它不认证客户，也不能证明所有回程都经过同一个强制点。

Cisco 当前 IOS XR 文档在其 L3VPN 工作流中直接提醒：AS override 会造成信息丢失并可能导致环路，因此在所述场景使用 SoO 作为补偿。这项证据应保持边界，不能推导成所有 override 都已有 SoO，也不能把一个场景的设计推广到任意拓扑。Cisco IOS XR BGP 文档

RFC 9835 的 attachment-circuit YANG 模型也把 as-override、allow-own-as、最大出现次数与 Site of Origin 分列为不同参数。数据模型不能保证各设备行为一致，但足以说明这不是一个“打开即可”的单项决策。RFC 9835

把一条路由沿两种例外分别追到底

先保存严格状态。记录 A 的 Adj-RIB-Out、服务商边缘的 Adj-RIB-In，以及远端边缘在向 B 导出前的路径。若使用 VPN，也记录 RD 与 RT，但不把它们写成来源证明。在 B 保存 rejected-route 视图和平台能够给出的 self-AS 拒收原因。

采用接收侧例外时，必须读取组继承后的有效政策，而非只抄一行配置：精确邻居、AFI/SAFI、容许次数、是否仅限 origin，以及 route-map 或前缀条件。另选一条不属于目标集合的对照路由，证明它仍会被拒收。真正的范围是设备最终执行的匹配结果。

采用发送侧改写时，要逐项比较出口前后的 AS_SEQUENCE，不能只看 origin。客户若多次 prepend，自身 ASN 的每个匹配项都可能被换掉。原始显示应保存到设备之外，因为改写后的通告无法自行还原已经丢失的身份。

然后分别验证补偿控制：前缀是否获授权，RT 是否只覆盖目标服务，SoO 是否在正确接入点被附加并在回送时阻断，是否存在并行接入、路由反射器或重分发点绕过检查。RFC 6368 对 ASN remapping 和 accept-own-AS 变通方法的讨论提醒我们，客户内部还在使用 BGP 时，影响不会停在一条 PE–CE 会话上。RFC 6368

路由获接收仍不等于业务可达。继续核对 Loc-RIB 选路、递归下一跳、FIB 或硬件条目，并在双向发送受控流量。设计不会制造生产环路的失败测试，观察是否出现意外重入、TTL 异常、接口计数重复增长或非预期路径。

RFC 7705 在 ASN 迁移语境给出一个有价值的警示：操作路径历史可能让路由器接受原本会被 self-AS 机制拒绝的路由。它不是 as-override 规范，却说明“路由出现了”绝不能成为唯一验收条件。RFC 7705

回退必须恢复防环证据

稳定终态可能是为各站点分配不同 ASN，并移除例外；也可能是长期保留严格收窄的接收许可；还可能是服务商改写配合经过验证的站点控制。选择取决于拓扑、运营边界与迁移成本，不能从一条厂商命令推导通用答案。

回退也不只是删除配置。预期的严格状态应重新拒绝带有本地 ASN 的 canary 路径，同时保留经过授权的站点间可达性；RIB、FIB 与报文均需回到设计状态。若变更记录说不清回退后恢复了哪项证据，它记录的只是动作，不是安全属性。