摘要

  • BGP PIC 让大量前缀共享层级化 next-hop 对象；合格故障发生后，只改少数 pathlist 或指针，就能避免逐前缀重写 FIB。
  • 快速切换依赖事先学到、选定并安装的备用路径。第二条 route、不同 BGP next hop 或 RIB 中的 backup 都不能单独证明故障域独立、硬件已编程、容量足够或触发正确。
  • 治理对象应覆盖整条预授权链：候选可见性、备用资格、shared fate、检测阈值、硬件层级、实际数据包与最终稳定收敛。

凌晨 2 点 14 分，一台 ingress PE 失去首选出口。监控墙上还有不少绿色，BGP 没有重新处理完所有 VPN routes，route reflector 也尚未把新状态传播完。然而，几十万前缀的流量已经从另一台 PE 离开。

值班室会先问：“为什么收敛这么快？”更重要的问题是：“这条路是谁在什么时候选的？”

答案可能是：事故发生很久以前。路由器已经收到候选路径，按政策把其中一条认定为备用，解析其 next hop，把它放进共享转发结构，并在硬件中准备好必要状态。检测器一旦宣布主依赖失效，forwarding plane 只需改变少数共享对象，而不必逐条更新几十万 destination entries。

这就是 BGP Prefix Independent Convergence，也就是 BGP PIC 的核心。名字很容易被读得过宽。它并不意味着 BGP 的每个收敛阶段都脱离规模。它只说明：在一类已覆盖的故障被检测后，若备用状态早已存在，本地转发切换的工作量可以不再随受影响 BGP 前缀数量线性增长。

截至本文发布时，IETF 的主要说明仍是 draft-ietf-rtgwg-bgp-pic-23。它是一份活跃工作组 Internet-Draft，预期状态为 Informational，仍属于 work in progress，不是 RFC，也没有定义新的线上 BGP 消息。它描述的是路由器内部架构：共享的层级 FIB、递归解析与预计算 backup 如何共同缩小故障时需要修改的对象数。

理解 PIC 要先忘掉功能按钮，观察 forwarding tree。扁平结构把完整转发信息复制到每条 prefix leaf。如果五十万条 BGP 路由都经同一出口解析，而这个出口改变，系统可能需要触碰五十万条 leaf。故障时的工作量与路由数相连。

层级结构让这些 leaf 指向同一个 BGP pathlist。Pathlist 再指向递归解析的 IGP next-hop 对象，最终落到 adjacency、label stack 或出接口。许多前缀重复使用同一分支。共同 next hop 失效时，FIB manager 改变相关分支或指针，所有依赖 leaf 一起继承新路径。

这好比不是改写五十万件包裹的地址，而是改变它们共同经过的一处分拣闸门。切闸仍需时间，硬件也有动作，但它不再为每件包裹重复做一次。

所以，“prefix independent”有清楚边界。Failure detection 仍会延迟；route reflector 仍可能隐藏候选；control plane 仍需撤销、选路和传播；line card 仍有编程速度；远端路由器仍按各自节奏收敛；回程仍可能中断；备用链路仍可能拥塞。PIC 去掉的是一个昂贵本地阶段中的前缀数量因子，不是所有故障成本。

速度的代价是预计算。保护路由器必须在主路径健康时，就拥有一条在政策上合法、可解析、在相关故障域上不同，并已装进 forwarding chain 的 alternate。故障时的决定，有一部分其实是过去的决定。

这会改变审计方式。普通故障后的选路可以现场解释：哪条 UPDATE 到达、哪个属性胜出、哪条 FIB entry 被写入。PIC 要求审计一项休眠意图。备用路径可能几周没有承载数据包，真正启用时，系统默认当初的拓扑、政策和资源判断仍然有效。

第一关是候选供给。活跃 draft 列出 ADD-PATH、best-external、diverse-path distribution，以及 VPN 中不同 Route Distinguisher 等可能来源。这些不是同一种保证，只是让保护节点有机会看到主路径之外的选择。

Route reflection 能直接破坏这项前提。Reflector 通常发送自己选出的路径，而不是所有已知路径。一台 ingress PE 即使硬件支持 PIC，也可能因为 alternate 从未穿过 reflector 而没有备用。ADD-PATH capability 也不够：方向、AFI/SAFI、发送策略、路径数量、进口政策和实际 Adj-RIB-In 共同决定候选是否到达。

证据必须落在执行切换的路由器。针对每个受保护 route family，展示它确实保留了满足 next-hop 与属性要求的 alternate。统计 reflector 上有多少 route，不能证明 failover 点拥有候选。

第二关是资格。Nokia 当前 SR Linux 文档把 Edge PIC backup candidate 定义为有效、可达，并使用不同于 primary 的 BGP next hop，再依据同一 BGP Decision Process 与 tie-break 选择最佳备用。这是一套明确实现规则，却不是物理独立证书。

两个 BGP next-hop 地址可以递归经过同一根光纤、同一 line card、同一 transport tunnel、同一机房供电或同一家上游。两台 egress PE 也可能共享同一服务节点。逻辑上不同的 alternate，完全可能被同一故障同时摧毁。

因此，fate separation 必须针对要防护的 failure class 声明。若防本地端口故障，另一接口可能足够；若防 line-card 故障，就不够。若防 egress PE 故障，同一 PE 上的第二路径没有意义。若防 provider 故障，连到同一家 provider 的两台设备未必有商业或物理独立性。

Core PIC 与 Edge PIC 在这里有分析价值。Core PIC 处理通往仍可达 BGP next hop 的内部路径故障。BGP next hop 可以保持不变，底层 IGP 或 transport resolution 改走其他路径，共享递归对象成为修复点。

Edge PIC 处理出口 next hop 或 edge dependency 丢失，切换到另一条预计算 BGP next hop，并可能同时改变 VPN label、tunnel 或服务路径。两者区别指明究竟哪一层应变化、哪一依赖必须独立。

产品不一定一致使用这些术语，支持范围也会随 address family、service、line card 与 software release 改变。一台设备上的 pic edge 命令，不能证明另一平台具有相同数据结构。活跃 draft 也明确指出，收益来自 forwarding-plane design，而不是 BGP wire protocol 改变。

检测器握有激活权。PIC 可以准备备用，却必须等某个组件宣布主依赖失效。物理 carrier、interface driver、IGP adjacency、BGP session 和 BFD 观察的对象不同，时间尺度也不同。

RFC 5880 给出了 BFD 的准确边界。Detection Time 由双方协商的发送间隔与 multiplier 分别计算，两个方向可以不同。监控面板只写一个“50 ms BFD”，可能掩盖实际协商值，也掩盖哪一端会先宣告故障。

快速检测不是免费的。拥塞、control-plane starvation、过滤或攻击都可能让合法 BFD 包消失。RFC 5880 警告，错误宣告 down 或 up 都可能造成严重 denial of service。激进 timer 的本质，是允许系统基于更少的缺失观察做更快的大规模转发决定。

检测还必须覆盖目标故障。本地接口能迅速发现直连光纤断开，却看不到数跳外的黑洞。Single-hop BFD 覆盖邻接，不一定证明远端 service path。Multi-hop BFD 测试端点可达，但它实际走的路径与被保护流量是否相同，需要具体实现证据。Detector 必须与共享 FIB 对象代表的 dependency 对齐。

IGP 内部也会隐藏故障。Summarization 有意减少跨 area 或 level 的细节。RFC 9929 定义 Unreachable Prefix Announcement，部分原因正是 summary 覆盖的 component prefix 失效时，summary 本身不会撤回；该 RFC 还明确提到 BGP PIC 等快速收敛用途。这不代表所有网络都必须部署 UPA，而是说明：决策点看不见的失效，预计算 repair 无法正确响应。

硬件层级是另一条硬边界。Draft 假设 FIB 能通过多层 indirection 做 recursive lookup。一些平台支持层数有限，只能在编程时 flatten 部分依赖，把解析结果复制进更多 leaf。

Flattening 可以减少每个 packet 的内存访问，却降低共享程度、增加 FIB 占用，并可能削弱 ECMP 或 PIC 特性，让某些故障重新出现逐前缀工作。只看 control-plane route 无法知道实际层级；ASIC 代际、line card、封装深度与软件版本才决定硬件内容。

混合设备网络因此特别危险。两台 router 可以展示同一 primary 和 backup，其中一台在几十毫秒内改共享对象，另一台要重写大量扁平 entries。服务级承诺必须按平台、route family 和封装组合实测，不能从最强 chassis 外推。

VPN label 与 encapsulation 还增加了必须同步的状态。备用 egress 可能需要另一 VPN label，transport 可能使用 LDP、segment routing 或其他 tunnel。Pathlist 已切到新 egress、label 却陈旧或错配，会得到一个“很快但错误”的结果。验证必须跟随每条备用路径实际采用的 label stack。

预计算状态会变老。备用安装时正确，之后可能因 import policy、route withdrawal、递归解析、label、部分 next-hop reachability 或硬件资源压力而失效。最危险的 stale state 不是明显消失，而是仍显示 ready。

运营者需要 age 与 revalidation 模型：记录 candidate 何时收到、资格何时重算、FIB 何时编程、由哪个 topology/policy epoch 支撑。相关政策、拓扑、软件或硬件事件发生后，重新验证 standby chain。“Backup present”只是状态观察，不是新鲜度证明。

容量同样属于授权。备用可以 loop-free 且可达，却没有能力承载受保护流量。许多 primary next hops 若共享一个 standby，一次故障会把巨大 aggregate 压到平时只承载少量流量的链路。多故障时，分别合格的 backups 还会在同一路径相撞。

预授权记录要写清负载假设与 failure set，验证整个 alternate path 的 headroom，而非只看第一跳。若存在商务限制，还要说明备用是否违反 transit、peering 或客户政策；BGP 认为 eligible，不等于合同允许使用。

RFC 5714 提供了正确时间模型。Fast reroute 在检测后调用 local repair path，随后分布式路由继续传播与收敛。Repair 在过渡期承载数据，稳定状态形成后，网络可能离开这条临时路径。

至少要分六个时钟：检测时间、事件通知、local FIB activation、首个成功 packet、control-plane convergence、最终 steady-state FIB。把它们合成一个“收敛时间”，就无法知道谁应对延迟负责，也无法证明数据真正送达。

六项都要量。给 detector event 与硬件 pathlist change 打时间戳；用足够密集的 data-plane probes 捕获丢包窗口；记录 repair 前、中、后的出接口、next hop 与 label stack；单独记录 BGP/IGP 稳定时间。漂亮的 control-plane log 不是数据包证据。

回程必须独立验证。本地 router 可能完美切换正向流量，远端仍把 reply 发往旧路径。Stateful firewall、NAT、service chain 或 load balancer 可能无法保留 session。端到端恢复是双向应用属性，不能与 PIC 本地激活画等号。

测试矩阵应包括：本地链路、远端 transport、egress PE、BGP session、BFD 延迟或误报、备用先撤回、健康期间政策改变、FIB 资源耗尽、line-card switchover，以及主路径恢复。每种场景都要预先说明哪个 detector 触发、哪个共享对象变化、哪个 backup/label 生效、允许多少丢包与重排、何时进入稳定状态。

False positive 与 false negative 同样危险。前者会把庞大前缀集合瞬间切到不可用路径，把一次错误检测放大。后者让服务看似有保护，实际 backup 未装进硬件、trigger 没绑到正确对象，或 line card 根本没有接纳 standby。

共享状态既是效率来源，也是错误倍增器。一个指针能救五十万 routes，也能让五十万 routes 一起走错。Blast radius 不是偶然副作用，而是优化能力的倒影。

所以，选择与认证应分开。Routing policy owner 定义候选资格；transport owner 证明物理与故障域独立；platform owner 证明真实硬件具有层级 FIB；service owner 验证容量与双向行为；独立 reviewer 决定是否从小批量扩大。

第一件生产 artefact 是 protection matrix。以 failure class 为行，route family、platform 和 service 为列；每个单元记录 primary dependency、候选来源、选定 backup、fate evidence、detector、协商阈值、hardware object、容量假设与 owner。

第二件是 dormant-state ledger。它列出代表性前缀实际编程的备用、所引用共享对象、最后验证时间与 topology/policy epoch，并标记只在 RIB 中存在、却不在硬件中的候选。

第三件是 timed forwarding trace。它把检测遥测、pathlist 或递归对象变化、实际 packet 路径串在一起，覆盖双向，也覆盖 repair 到 converged state 的最终切换。到这里，feature configuration 才成为运行证据。

恢复主路径与故障同样需要控制。主路径刚回来就立即切回，可能造成 reordering、oscillation 或第二次丢包。原依赖也许仍不稳定，事故期间政策也已变化。Hold-down、验证期或人工批准的 revert，可能比机械对称更安全。

Rollback 因而不是“关掉 PIC”。它是安全恢复原 protection policy、撤销或替换 standby object，并证明活流量回到预期 steady state。若拓扑已变，旧状态可能根本无法原样恢复。

Lu Heng 的 minimum initial specification 与这套架构相合。共同机制可以很窄：组织转发依赖，让已准备的 alternate 不必逐前缀重写即可启用。至于哪些 route family、平台、故障类别与 detector threshold 值得采用，应由各 operator 在本地决定。有价值的机制不需要升级成普遍命令。

Running-code primacy 则决定验收次序。配置说有 backup，RIB 说它 eligible，FIB 说层级已编程；只有 packet 才能证明故障后真正使用了哪一 adjacency、label 与 interface。证据离运行转发越远，主张的权威越弱。

Practical data sovereignty 也出现在这里。拥有 route-policy repository，如果无法检查专有硬件中的 standby state，只是象征控制。实际控制意味着能够查询、测试、设定有效期、替换与撤销预计算决定，并用独立观测验证结果。

BGP PIC 的力量在于把工作移出事故时刻。它只有同时把证据也提前，才可治理。备用路径不应等到主路径消失才第一次被看见；其来源、多样性、trigger、硬件实现、容量与失效时间都应事先明确。

真正的领导决策不是要不要购买“更快收敛”，而是组织是否愿意为大量流量预先授权一条休眠路径，以及是否有人能独立证明，警报真正响起时它仍然安全。

来源