摘要

  • BGP Flow Specification 分发报文匹配条件和过滤动作；看见路由只能证明控制面状态，不能证明转发结果。
  • 外部规则通常依赖单播路由校验；最佳匹配单播路由改变时，规则必须重新校验。
  • 多条规则或多个动作可能重叠甚至冲突；IPv6 解析深度和硬件能力也可能阻止规则真正执行。
  • 缓解闭环必须把精确 NLRI 和动作与设备编程、计数器、报文样本、受害业务及误伤测量连接起来。

设想一个 DDoS 控制器针对某个目的地址和端口发布规则。几秒后，路由反射器和三台边缘设备的控制面都能看到它，事故看板转为绿色。然而，一条大流量入口仍在转发目标流量，因为其线卡无法编译高层协议匹配条件。BGP 证据是真实的，由此推导出的“过滤已生效”却是错误的。

这是一个不指向任何运营商或厂商的假设场景。它要区分的是分发指令与在报文上执行动作。

路由真正承载了什么

RFC 8955 把 Flow Specification 编码为 BGP NLRI 中的 n 元组。组件可以描述源和目的前缀、协议、端口、TCP 标志、报文长度、DSCP 与分片。报文只有同时满足规则中的全部组件才算匹配。因此，首要证据是解码后的逻辑交集，而不是看板给规则起的名字。

扩展团体属性携带动作，包括按字节或报文限速、采样、按 Route Target 重定向和流量标记。匹配规则的默认动作是按普通转发行为接受报文；速率为零通常表示丢弃。如果传播到设备上的规则缺少预期动作，它可以存在却不产生所需阻断。

同一股流量可能匹配多条规则。RFC 8955 规定了与 BGP 到达顺序无关的比较次序，但动作仍可能互相干扰或矛盾。冲突进入转发选择后，具体采用哪个动作由实现决定。于是控制面传播完全一致，各平台的本地结果仍可能不同。

校验依赖会变化的单播状态

在没有显式覆盖配置时，外部 Flow Specification 必须包含目的前缀；其发起者要与覆盖该前缀的最佳匹配单播路由发起者一致；而且不能影响来自另一个邻接 AS 的更具体单播路由。配置可以放宽目的前缀要求，所以校验策略本身也是证据。

最佳匹配单播路由能够独立变化。RFC 8955 要求变化后重新校验 FlowSpec。10:01 可用的规则可能在路径切换后变得不可用，即使采集器里仍保留原始公告。记录必须说明校验发生在哪一跳、依据哪一版单播状态。

RFC 8956 把该机制扩展到 IPv6，使用 AFI 2 与 SAFI 133 或 134，并加入 IPv6 特有组件。它沿用 RFC 8955 的校验，但要求目的前缀 offset 为零。文档还指出，异常或过长的 IPv6 扩展头链以及路由器硬件限制，可能让高层字段匹配无法执行。控制面接受不能消除这条硬件边界。

结果需要报文证据

RFC 8955 建议实现提供过滤报文头日志和每条规则的匹配计数器。这些不是装饰性指标，而是把已选规则连接到真实流量的桥梁。运维视图应逐台设备、VRF、接口和线卡记录规则是成功编译、被拒绝还是被近似处理，最终保留了哪个优先级和动作，以及计数器如何对应攻击样本。

随后还要独立测量到达受害端的流量、合法业务损失、重定向容量和撤销效果。丢弃计数上升可能只是匹配了错误的聚合；攻击下降也可能伴随过度误伤。单看 FlowSpec 路由无法判断这些结果。

来源