方法论

BGP 采集器数据并不干净：做路由分析前先处理噪声

解释 route collector、MRT 更新、noisy routers 和测量偏差，给出适合博客测评使用的数据清洗思路。

2026/5/18 #BGP#Methodology#Routing#Data

公共 BGP 数据不是事实全貌

RIPE RIS、RouteViews 和各种 Looking Glass 是路由分析的基础，但它们看到的是观察点附近的 BGP 视角，不是全球统一真相。

同一个路由事件，在不同 collector 上可能出现不同时间、不同 AS Path、不同可见性。更麻烦的是，一些路由器会产生大量重复更新、撤销和属性变化，把数据集变得很吵。

什么是 noisy routers

在 BGP 更新流里，有些 peer 会贡献异常多的 updates。这些更新未必代表真实拓扑变化，可能只是会话抖动、策略刷新、MED/community 变化或设备行为导致的重复通告。

如果直接用原始更新数量判断“某条线路不稳定”，很容易把单个观察点的噪声误判为全球故障。

VPS 测评中的常见误区

  • 只用一个 Looking Glass 判断回程。
  • 只看一次 traceroute，把瞬时 ECMP 结果当固定路径。
  • 看到 AS Path 变长就断言绕路，但没有对比 RTT 和丢包。
  • 把 collector 的更新量当成用户侧质量。

这些做法可以作为线索，但不能单独作为结论。

国外研究给测评的提醒

APNIC 对 noisy routers 的讨论强调了一个事实：公共 BGP 数据规模很大，但里面包含大量重复、抖动和观察点偏差。对研究者来说，这意味着要清洗数据；对博客测评来说，意味着不要把“某个 collector 看到很多更新”直接翻译成“这家 VPS 网络很烂”。

RouteViews 和 RIPE RIS 都是宝贵数据源，但它们的位置和 peer 选择会影响结果。一个亚洲网络的路由变化，可能在欧洲 collector 上表现得很慢或不完整。相反，一个欧洲上游的策略变化，可能在亚洲用户侧几乎没有影响。

国外网络运维论坛里也常见类似建议：先确认用户侧问题，再用控制面数据解释问题。控制面告诉你 BGP 想怎么走，数据面告诉你包实际走得怎么样。两者不一致时，不能强行选一个相信。

如何减少误判

对一条路由变化，至少用三种证据交叉：

  1. 本机 traceroute/MTR。
  2. 至少两个公共 collector。
  3. 目标网络或上游 Looking Glass。

如果三个证据都指向同一个 AS Path 变化，可信度较高。如果只有单个 collector 看到异常，而用户侧没有任何丢包或延迟变化，应该标成“观察到控制面波动”，而不是直接写故障。

适合博客的轻量数据模型

不需要搭建完整 BGP 数据平台，也能做基本留档：

event_id:
observed_at:
prefix:
origin_as:
old_path:
new_path:
collectors:
data_plane_result:
impact:
confidence:

confidence 可以分为 Low、Medium、High。这样读者能知道结论的证据强度。

更稳妥的数据处理方式

建议把路由分析分成四层：

  1. 控制面：BGP collector、Looking Glass、RPKI、IRR。
  2. 数据面：traceroute、MTR、TCP ping、iperf3。
  3. 时间面：白天、晚高峰、凌晨至少三个窗口。
  4. 方向面：去程、回程、跨运营商方向分别记录。

对公共 BGP 数据，至少做三步过滤：

  • 去掉明显重复的 announcement/withdrawal 抖动。
  • 对比多个 collector，只保留多点可见的变化。
  • 把时间粒度拉到分钟级或更粗，避免被秒级抖动带偏。

一个简单记录模板

目标前缀：
观察时间：
本机 ASN / 接入运营商：
数据面路径：
控制面 AS Path：
RPKI 状态：
collector 数量：
异常说明：

结论

BGP 数据的价值在于解释“为什么路径会这样走”，不是替代用户侧实测。Portchannel1 后续测评会把公共 BGP 视图作为证据链的一部分，而不是只靠单点截图做判断。

参考来源