摘要

  • FRRouting 的 10.7.1、10.6.2 和 10.5.5 发布说明均列入了 #22681 修复，处理链路带宽扩展团体在约 34 Gbps 以上的数值问题；三个版本发布于 2026 年 8 月 25 日。
  • 修复并不意味着所有编码模式都应输出同一个汇总值。IEEE 浮点模式保留较大的数值，旧式原始整数模式仍受 32 位无符号整数上限约束；路由表测试也不等于流量分担测试。

30 加 100，为什么不能只用 130 验收路由软件？FRRouting 的一组回归测试给出了一个具体答案：先要问这些数值用了什么单位，以什么方式编码，又在哪个环节被观察。

10.7.1、10.6.2 和 10.5.5 的 8 月 25 日发布说明都列出了 #22681。修复针对的是 BGP 链路带宽扩展团体的数值处理，而不是端口的物理传输能力。把发布说明中的“约 34 Gbps”理解为一张 100 Gbps 网卡此前只能跑到 34 Gbps，会把表示问题误写成吞吐量测量。

边界藏在字节单位里

合并请求 #22681 于 7 月 28 日合入。开发者说明，BGP 内部带宽采用较宽的整数表示，但部分编码、解码或显示辅助函数把数值收窄成 32 位无符号整数；累计带宽替换路径还曾无条件限制到这个整数类型的最大值。

这个最大值是每秒 4,294,967,295 字节。换算成十进制比特速率，约为 34.36 Gbps。问题不是“32 位装不下所有高带宽”：线路上的 IEEE 格式本来也是 32 位，却是浮点数，表示范围与同宽整数不同。RFC 10005 对四字节浮点带宽字段及字节每秒单位作出了规定。修复放宽内部数值处理，并没有把线路协议改成 64 位，也没有让浮点数获得任意整数的精确度。

更容易漏看的情况是累计值。单条路径的值没有越过边界，不代表几条路径相加后仍在边界内。对需要把下游带宽汇总后继续通告的设备，只检查各输入值可能遗漏真正发生变化的出口。

两种编码，两套预期

修改后的测试源码 使用 30,000 Mbps 与 100,000 Mbps 两个输入。对应的精确字节速率之和是 16,250,000,000 字节每秒。按测试涉及的单精度浮点往返计算，预期累计值为 16,249,999,360 字节每秒；这点舍入差异不应被当成原来的整数收窄缺陷。

旧式原始整数编码则不同。在这一模式下，修复后的累计值仍应限制为 4,294,967,295 字节每秒，而不是强行输出无法由该格式表达的和。测试把此前较低的截断结果改为这个上限。因此，看到约 34.36 Gbps 的通告，既不能脱离编码方式宣布修复失败，也不能仅凭它宣布系统正常。

这里的算术经过独立复算，但本文没有运行 FRRouting 测试拓扑。源码能证明测试要求检查哪些结果，不能充当本文亲测设备或客户网络的报告。

两套测试的观察范围也不对称。IEEE 模式的测试检查接收路由器的路由信息库、向外部 BGP 邻居通告的值，以及该邻居接收后的路由信息库。原始整数模式的相关测试只检查发送方的已通告路由表示，并没有验证下游接收解码。两者都没有据此证明硬件转发表的权重或真实业务流量比例。

一次维护更新可能改变分流，但不能据此承诺提速

FRRouting 的加权多路径说明 将链路带宽用于已经符合多路径条件的下一跳之间的权重分配；它不改变最佳路径选择，也不会自动让原本不合格的路径加入分担。权重最终能否被转发系统使用，流量怎样分布，是另外的验证问题。

该软件仍提供逐邻居的旧式编码兼容开关。不能因为浮点模式的数值范围较大，就把统一关闭兼容选项当成升级建议。邻居是否能正确解释线上字节，必须先被确认。当前文档附近的部分命令范围说明还比这组固定版本测试的输入范围窄，更不宜把测试参数复制成所有发行分支都支持的配置承诺。

截至 9 月 8 日 12:40 UTC，本次审阅的材料并未提供受影响客户数量、生产事故、测量提速或完整受影响版本矩阵。三个发布说明确认了修复纳入情况，不足以反向推断所有其他版本的状态。

本文采用 Lu Heng 在现实而非倡议一文中的编辑原则：把能够证实的运行机制与期望中的结果分开。这是本文的分析方法，不是 Lu Heng 对该修复的评价或背书。对使用加权多路径的数据中心而言，最有用的结论是具体的：升级验收必须写清编码模式、观察位置与预期数值，不能只勾选版本号。