摘要

  • 一个内部路由域向数据中心骨干网发布了大量前缀。每条路由都带有分配给该域的合法 BGP 社区值，并通过入口 route-map；随后，数据中心汇聚路由器收到整批路由，路由守护进程因内存耗尽而重启。
  • Daria Shantalova 的方案把三件事拆开：前缀是谁的、它能穿过哪道内部边界、生产中的路由状态是否仍符合预期。
  • RIPE 演讲称，几个月内几乎清除了所有已观察到的违规项；公开材料没有给出起始数量、剩余数量或带日期的变化序列。

门禁检查了徽章，却没查名单

Daria Shantalova 在 RIPE 93 分享的案例，最刺眼的细节不是路由带着坏标签，而是标签完全合法。一个相邻的内部路由域向连接数据中心的 Express Backbone 发布大量前缀。每条路由都带着分配给该域的 BGP community。入口 route-map 认出了这个值，于是放行。

路由随后沿内部 iBGP 网格传播。数据中心汇聚路由器接收了完整路由集，路由守护进程耗尽可用内存并重启。公开的摘要、文字记录和幻灯片没有列出前缀总数、受影响路由器数量或中断时长；但它们清楚说明了检查缺口：策略验证了 community 属于发送域，却没有验证每一个前缀是否有权从该域跨入骨干网。

community 可以说明来源域或传播范围。它本身不是一张通往所有边界的通行证。入口策略把“标签属于你”误当成“这些路由都获准进入”。

数量上限回答不了“哪条路由获准”

常用控制各自回答不同问题。maximum-prefix 问收到多少条路由；前缀许可列表问哪些路由可以进入；community 过滤问标签是否在认可范围内、是否应保留。它们可以一起工作，但彼此不能替代。RFC 7454 把前缀过滤、maximum-prefix 和 community 处理作为不同的 BGP 运维控制讨论；RFC 4271 定义 BGP 如何交换可达性信息并作出路由决策。

Shantalova 提出的第一层是身份：每个前缀使用一个 BGP ID community，标出来源域和允许的传播范围。缺失、错误、重复或冲突的 ID 都算违规。第二层是授权：内部 Route Registry 记录每个前缀应归属的来源域和 ID，再为每个域边界生成入站前缀过滤器。第三层是核对现实：持续收集生产 RIB，与注册表比较，发现未登记前缀、ID 缺失或不匹配、以及预期与实际状态的漂移，并触发监测和告警。

注册表记录“应该如此”，RIB 展示“现在如此”。只有持续对照两者，控制才有闭环；部署时导出一次配置，证明不了半年后仍按原意运行。

“几乎全部”少了一个分母

RIPE 摘要称，团队在几个月内清除了“几乎全部”已观察到的违规项，并称自动化执行可防止复发。幻灯片没有提供起始数量、准确的残留项、违规时间序列或受自动化覆盖的边界数量。若公布按日期划分的处理前后数据，并列出实际纳入的边界，读者才能分清变化来自集中清理还是持续执行。

操作上的结论不是再加一道过滤器，然后把工单标成完成。每个控制要有明确职责，边界要校验实际前缀，监控要把运行状态和注册意图持续比对。当合法标签被当成完整授权，路由系统可以毫无偏差地执行一次从未真正检查过的许可。

来源：RIPE 93 场次与摘要；官方文字记录；原始演讲幻灯片；RFC 4271；RFC 7454。