Summary

  • FRRouting’s August 25 releases 10.7.1, 10.6.2 and 10.5.5 explicitly include a correction to link-bandwidth extended-community handling above roughly 34 Gbps.
  • The correction removes inappropriate narrowing and an unconditional ceiling, not the limits of every encoding. IEEE and legacy raw-integer tests have different expected values and different observation scope.

An upgrade test can fail by expecting too much consistency. Give FRRouting two advertised bandwidth inputs of 30 and 100 Gbps, and the right cumulative result still depends on the encoding used toward the next neighbour. A value close to 130 Gbps is appropriate in one mode. A ceiling near 34.36 Gbps remains deliberate in another.

That distinction is the operational substance of a fix listed in the official 10.7.1, 10.6.2 and 10.5.5 release notes, all dated August 25, 2026. It concerns the representation of bandwidth in a BGP extended community. It is not evidence that physical 100 Gbps ports had been capped at 34 Gbps, nor a measurement of recovered throughput.

A wide value passing through a narrow helper

Pull request 22681, merged on July 28, describes a mismatch inside the implementation. BGP bandwidth was held internally as a 64-bit unsigned integer, but helpers used in encoding, decoding or display narrowed it to 32 bits. The cumulative-bandwidth replacement path also imposed an unconditional unsigned-32-bit maximum.

Units explain the otherwise peculiar threshold. The field describes bytes per second. An unsigned 32-bit integer ends at 4,294,967,295; multiply by eight and the boundary is approximately 34.36 billion bits per second. The IEEE representation on the wire is also 32 bits, but it is floating point and has a different range. RFC 10005 specifies that four-octet floating-point representation. Widening internal helpers does not turn it into a 64-bit wire protocol or remove floating-point rounding.

The fix therefore does two related things: it preserves larger values through the relevant internal operations and restricts the cumulative ceiling to the classic raw-integer mode that needs it. That is more precise than saying it simply removes a bandwidth limit.

The same inputs, two legitimate answers

The changed regression tests make the difference concrete. Two internal BGP peers supply 30,000 Mbps and 100,000 Mbps. Their exact sum in bytes per second is 16,250,000,000. Reproducing the single-precision conversions used for the inputs and cumulative result gives 16,249,999,360. The small difference is ordinary float rounding, not the integer-narrowing defect reappearing.

For classic raw encoding, the intended result instead reaches the 4,294,967,295-byte-per-second ceiling. The updated test expects that cap, replacing a lower truncated result. A post-upgrade number at the old-looking boundary can thus be correct. It becomes meaningful evidence only when paired with the encoding mode and observation point.

Test branch Expected cumulative representation for these inputs
IEEE single-precision float 16,249,999,360 bytes per second after rounding
Classic raw unsigned integer 4,294,967,295 bytes per second, deliberately capped

These arithmetic results were independently recalculated for this article. The FRRouting topology was not run here. Reading a test establishes its assertions, not an independent router experiment.

The tests also establish different things. The IEEE case checks the receiving router’s routing information base, the value advertised to an external BGP peer, and that peer’s routing information base. The raw-mode case checks the advertiser’s advertised-route representation. It does not prove downstream decoding in that branch. Neither test establishes hardware forwarding weights, application throughput or an observed traffic split.

Why a maintenance change can matter without changing a cable

FRRouting’s weighted-multipath documentation explains the use of link-bandwidth ratios among paths already eligible for multipath forwarding. This attribute does not alter best-path selection or make otherwise ineligible paths eligible. The forwarding system’s ability to use the resulting weights, and the distribution of actual flows, remain separate questions.

Cumulative advertisements are particularly worth examining. Several individual inputs can each lie below an integer ceiling while their sum crosses it. Checking only the constituent values misses the export operation in which the correction matters.

Compatibility cannot be wished away. FRRouting retains a per-peer option for non-IEEE link-bandwidth encoding. Removing that option everywhere is not a supported conclusion from this fix; the receiving implementation must understand the bytes it receives. Some adjacent current command documentation also describes narrower configuration ranges than the pinned test fixtures use. Operators need the exact deployed build and supported command behaviour, not a universal recipe inferred from one test.

The reviewed sources, checked through September 8 at 12:40 UTC, supply no affected-customer count, production outage, measured speedup or complete affected-version matrix. The three release notes establish inclusion in those releases, not the status of every other branch.

The distinction follows the editorial discipline in Lu Heng’s essay on reality rather than advocacy: describe the operating mechanism without promoting an outcome the evidence has not established. This is the author’s application of that principle, not Lu Heng’s assessment of FRRouting. Here the practical outcome is a better acceptance specification: name the mode, expected value and receiving observation, rather than merely recording that the package version changed.