摘要

  • LACNIC在2026年5月27日发布的研究称，数据来自RRC15与RRC24，取“2026年3月对应的全部更新”；紧接着又说，Python流程在“48小时期间”汇总了超过22.22亿条BGP消息。
  • 稳定性表给出的精确总数是2,222,981,835条BGP消息。IPv4与IPv6表分别列出159,964,848和693,016,987次更新，合计852,981,835，差额恰为1,370,000,000。
  • 另外两组数字可以完全对上：两种地址族的前缀数相加为1,436,539，四类ASN数量相加为86,398。因此，未对上的一组更像是尚未公开的口径或处理阶段，而不能直接叫作算术错误。
  • LACNIC应为该次分析发布一张版本化对账凭证，连接观测与处理时钟、采集器同伴、MRT文件、软件版本、计数定义、中间结果和最终表格，同时明确两处RIS视角不等于地区普查。

先看能够闭合的两笔账

LACNIC这篇关于“嘈杂BGP说话者”的文章提供了一套直观分类：低于中位数为稳定，从中位数到均值为躁动，从均值到一百倍中位数为嘈杂，更高则为关键。分类是否适合每一种运维情形可以讨论，但它至少留下了可检查的数字。

第一笔账是前缀。表中IPv4为1,146,937，IPv6为289,602，两者相加正好得到总表里的1,436,539个唯一前缀。第二笔账是ASN：43,199个稳定、41,650个躁动、1,530个嘈杂、19个关键，正好得到86,398个唯一ASN。

第三笔账没有闭合。IPv4“总更新数”为159,964,848，IPv6为693,016,987，相加是852,981,835。稳定性总表却写着2,222,981,835条BGP消息，前者比后者少1,370,000,000。

这个差额不能自动证明谁算错了。表头一个写“BGP messages”，一个写“updates”。前者可能是解析或筛选前的消息/记录总量，后者可能只保留能归入地址族的UPDATE，也可能按前缀动作而非封装消息计数。撤回、空更新、多协议字段、重复观测和异常记录都可能改变中间数量。公开文章没有给出转换表，所以读者既不能判错，也不能复算。

“三月”和“48小时”需要两只时钟

文章明确写出RRC24位于蒙得维的亚、RRC15位于圣保罗，并称取用了2026年3月对应的全部更新。下一段列出Python 3、mrtparser、pandas、NumPy和Matplotlib，又说这些工具在48小时期间完成了超过22.22亿条BGP消息的汇总与分类。

“48小时”可能是程序运行时间，也可能是观测窗口；可能是三月内选出的两天，或者把两个采集器的时段组合起来。“三月全部更新”也可能只是搜索空间，真正入样的数据还经过筛选。LACNIC的英语、西班牙语和巴西葡萄牙语页面都没有把这两个表述接起来。

这不是文字洁癖。整月样本会经历周末、维护、故障和采集同伴变化；两天样本也能很好地发现极端值，却不能承担同一种时间代表性。若48小时只是计算耗时，它与网络发生了什么更是两回事。方法说明只需分别写清UTC观测起止与处理起止，歧义便可消失。

同样的边界应当套在“0.02%的说话者造成大部分不稳定”这一结论上。19除以86,398确实约等于0.02%。这证明表内比例一致，却不证明这19个ASN跨时段、跨采集同伴始终处在同一等级。这里的“关键”是特定样本和阈值下的统计状态，不是永久身份。

公开原始档案不等于公开运行清单

RIPE RIS已经提供了难得的开放基础。其文档说明，数据按路由采集器保存，一个采集器从各同伴收到的内容合并进共同文件；路径采用rrcXX/YYYY.MM/TYPE.YYYYMMDD.HHmm.gz形式。路由表快照通常每八小时生成，更新文件每五分钟生成。RRC15与RRC24的2026年3月目录确实显示了分开的bview与updates文件。

但档案目录只是一排书架，不是一次分析的借阅单。它没有说明研究究竟下载了哪些文件、是否遇到不完整对象或解析失败、哪些同伴在窗口内可用、bview是否只用于初始化状态，或者是否参与任何总数。

两个观察点也不能被合并成“整个拉美与加勒比互联网”。RIPE NCC把RRC15列在圣保罗PTTMetro-SP，把RRC24列为位于蒙得维的亚的LACNIC多跳采集器。它们看到的是各自同伴群体传来的路由信息。这个视角很有价值，却不等同于LACNIC全体会员、地区全部路由器、流量、用户、故障或损失。

“消息”不是天然稳定的计量单位

RFC 4271区分OPEN、UPDATE、KEEPALIVE与NOTIFICATION等BGP消息。RFC 6396又区分路由表转储、BGP4MP消息和BGP4MP状态变化等MRT记录。RIS Live还把同伴状态元数据作为可识别类型提供出来。

这些标准不能替LACNIC回答“实际算了什么”，却说明了为什么必须回答。一个UPDATE可以同时携带多个共享属性的前缀，可以包含公告、撤回和多协议可达信息。解析后，原始记录数、BGP消息数、UPDATE数、前缀动作数以及“同伴—前缀—ASN”观测数都可能合理地不同。

地址族归类也需要决定。一个同时涉及两种地址族的消息算一次还是两次？没有任何条目通过过滤的UPDATE是否保留？多起源路由、AS_SET或畸形路径归给谁？“唯一前缀”是在两个采集器和整段时间上去重，还是在更早阶段按同伴分别计数？文章用每个ASN的更新数与所公告前缀数计算churn rate，这些规则实际构成了分子与分母。

一张对账凭证应写什么

第一部分是双时钟：UTC观测开始和结束，另列处理开始和结束。明确48小时究竟属于数据还是算力，也明确“三月”是完整样本、候选范围还是某个版本标签。

第二部分是输入清单：RRC15和RRC24的精确MRT文件名、哈希、字节数、聚合后的同伴群体快照、缺口与错误。bview若只用于恢复初始状态，也应与进入消息总数的文件分开。

第三部分是计数词典：MRT记录、BGP消息、UPDATE、公告、撤回、NLRI条目、前缀出现次数与唯一前缀分别定义。每道过滤都有前后计数；IPv4/IPv6、多协议、空消息、重复、解析异常、多起源与ASN归属都有版本号。

第四部分才是结果对接。从接收的原始记录，到成功解析的消息、保留的UPDATE、按地址族归类的动作，再到churn总体，每个表格指向一个阶段。如果22.23亿与8.53亿本就属于不同集合，对账单应当把那13.7亿标成什么、为何退出或留在何处写明白。

最后是软件与更正身份：Python、mrtparser及数据包版本，代码提交，配置哈希，运行ID，发布日期与修订历史。修复解析器不应悄悄抹去旧结果，而应产生一份可追溯的新版本。

可复算性也保护被观察者

原文列举软件缺陷、错误配置、设备问题、断电或攻击等一般原因。但它没有证明19个关键ASN分别发生了什么。高更新量也不能独自证明恶意、客户受损或本可避免的运维过失。

有了谱系凭证，运营商才能判断自己的ASN是被一个还是多个同伴看到，是短暂事件还是贯穿窗口，是网络行为改变还是观察点改变。独立研究者也能换一个时间段或同伴集合，检查集中度是否仍然存在。LACNIC若发现处理规则需要修订，也能只修订那一环，而不让整个研究被误读为失实。

因此，最稳妥的结论并不夸张：LACNIC发布了有价值的大规模测量，其中两处数字连接清楚，第三处连接缺席。下一步不是再加一张图，而是把原始观测如何变成公开结论的路径保存下来。

来源