摘要

  • 研究者在 SEACOM（AS37100）的 looking glass 查到 SingNet（AS3758）合法通告的 203.127.0.0/16，查不到 Innove Communications（AS17894）未经授权通告的 203.127.225.0/24；从同一网络发起的 traceroute 却经 TISparkle 等网络到达 AS17894 的跳点。
  • ROV 对收到的路由给出起源有效性判断，拒绝 Invalid 是各 AS 的本地策略。它不能替不执行相同策略的邻居决定下一跳。
  • BMP 可以保存被监控路由器的指定 BGP 视图，但看不到只进入别家路由器的通告，更不能单独证明数据包最终走向。

一条“不在表中”的路

在网络排障中，“Network not in table”通常是令人放心的答复。李琦等人的互联网草案附录保留了这样一条原始查询：SEACOM 的路由表中没有 203.127.225.0/24；覆盖它的 /16 则指向 SingNet，标为有效。前者是 Innove 的异常起源，按研究者描述，被 SEACOM 的 ROV 过滤。

可是，研究者从 SEACOM 发向 203.127.225.1 的 traceroute 经过 TISparkle（AS6762）、FLAG Telecom（AS15412）、Globe Telecom（AS4775），最后出现 Innove（AS17894）的跳点。草案据此指出：过滤器保护了 SEACOM 的本地控制平面，未能约束下一网络接受 /24 并为它转发。记录支持这一条被探测路径，不是所有用户流量的普查，也未证明目标应用成功应答。作者称可能是良性配置错误，已于 2025 年 2 月 10 日报告给 Globe，至 4 月 24 日仍有观察。草案属于个人提交的进行中研究，不是 IETF 认可的标准，不能据此推断恶意。

APNIC 对 62 届会议技术场次的报道记载，Nokia 的 Ritesh Mukherjee 把此案放在“好邻居”问题之下。他的演示文稿还讨论 Telegram 2026 年的异常起源及 Vodafone Idea 2021 年的大量路由通告。这些并非同一种故障，不能因为都与 BGP 有关，就把起源验证、路径验证、流量限制与可见性混作一项解决方案。

被拒的 /24 怎样再次出现

SingNet 的 /16 具有合法起源，Innove 的 /24 则是更具体、起源不符的通告。RFC 6811规定如何依据已验证的 ROA 数据把路由标为 Valid、Invalid 或 NotFound；对 Invalid 采取何种动作，由收到路由的网络自行配置。SEACOM 可以拒绝 /24，并沿着所选的 /16 路径把包送到 AS6762。一旦进入不拒绝该 /24 的 AS6762，后者可以按最长前缀匹配改选更窄的路径。这不是同一台路由器同时认定两条相反规则，而是两家网络先后作出的不同决定。

Telegram 的例子可以检验这一区分。BGPHorizon 对 2026 年 6 月 16 日路由记录的复核显示，91.108.4.0/22 在 07:17:27 UTC 出现 AS18101 起源，而通常授权起源是 AS62041；四个对等网络、五个收集器观察到相关事件，当天稍晚又出现更具体通告。这说明异常起源进入了部分公共观察点；不说明所有网络都接纳它，也不证明具体用户损失或发布通告者的政治动机。ROA 能提供起源不符的依据，执行拒绝仍落在每个 AS。Vodafone Idea 的 2021 年大量异常路由则提示另一控制面：会话级 maximum-prefix 可对数量激增设断路器，却无法凭数量判断单一 /24 是否正当。

监控点站在哪里

Mukherjee 建议在 Adj-RIB-In 使用 BMP，并展示 Nokia 的 RAVEN。RFC 7854允许路由器向采集端输出所选邻居的策略前、策略后收路由状态、初始快照和后续变化。如果异常通告实际抵达某个被监控的会话，策略前视图有机会留下它；策略后视图可与拒绝动作对照。但配置可只覆盖部分邻居，中间变化可能被压缩，源时间戳也可能缺失。即便 SEACOM 的本地采集完备，也不会凭空得到仅由 AS6762 收到的 /24。

更重要的是，BMP 是控制平面记录，不是 FIB 或数据包记录。要判断下一跳到底怎么转发，需要另一个观察点、邻居提供的收路由与选路证据，以及范围明确的主动路径测试。演示稿中的 RAVEN 输出明确标为示意；产品仓库列出能力，不等于其在涉事网络已部署或曾阻止事件。把“可能提供提示”写成“数秒内发现”，缺少可复核的实测链条。

这些工具的职责应各归其位。RFC 7454推荐按对等关系预期规模设置前缀上限，并留出增长余量；这是防止大量路由压垮会话的机制。ASPA 验证草案讨论提供者关系与路径，仍属进行中的规范工作，不能倒推 2025 年的转发已经受它保护。ROV 解决起源判断；跨邻居的观察与协调回答另一道题：拒绝后，包去了哪里？

证据范围

2025 年的关键查询与 traceroute 见李琦等人草案第 4 节及附录 A；APNIC 场次报道与演示稿说明会议主张；BGPHorizon提供独立的 Telegram 路由重建。RFC 6811、7854和7454限定技术机制。上述资料不能给出全网损失总量、主观意图、当下精确部署率或产品防护成效。