Zusammenfassung

  • FRRouting führt den Fix #22681 in den am 25. August 2026 veröffentlichten Versionen 10.7.1, 10.6.2 und 10.5.5 auf. Er betrifft große Werte in der BGP-Link-Bandwidth-Extended-Community.
  • Die Korrektur beseitigt unpassende Verengungen und eine bedingungslose Begrenzung, nicht sämtliche Grenzen jedes Formats. Auch die Prüftiefe der IEEE- und Ganzzahltests unterscheidet sich.

Ein Grenzwert, der nach einem Update unverändert erscheint, muss kein Beleg für dessen Scheitern sein. Bei FRRouting kann ein kumulierter Bandbreitenwert weiterhin bei ungefähr 34,36 Gbit/s enden, obwohl der dafür relevante Fix korrekt arbeitet. Entscheidend ist, ob der Nachbar einen IEEE-Gleitkommawert oder das klassische rohe Ganzzahlformat erwartet.

Die offiziellen Hinweise zu 10.7.1, 10.6.2 und 10.5.5 nennen alle die Korrektur #22681. Die drei Versionen erschienen am 25. August. Die Aussage betrifft eine numerische Darstellung in BGP. Sie belegt weder ein physisches 34-Gbit/s-Limit von Ports noch einen gemessenen Durchsatzgewinn durch das Update.

Gleiche Bitzahl, anderer Zahlenbereich

Der am 28. Juli übernommene Pull Request 22681 beschreibt eine interne Verengung: BGP hielt Bandbreite bereits als vorzeichenlose 64-Bit-Ganzzahl, während Hilfsfunktionen beim Kodieren, Dekodieren oder Anzeigen auf 32 Bit reduzierten. Beim Ersetzen der kumulierten Bandbreite wurde zudem ohne Rücksicht auf das Encoding der Höchstwert einer vorzeichenlosen 32-Bit-Ganzzahl angewandt.

Die Einheit macht den ungewöhnlichen Schwellenwert verständlich. 4.294.967.295 Byte pro Sekunde entsprechen rund 34,36 Gbit/s. Das IEEE-Format auf der Leitung hat ebenfalls 32 Bit, ist aber eine Gleitkommazahl mit anderem Wertebereich. RFC 10005 legt diese vier Oktette und die Einheit Byte pro Sekunde fest.

Der Fix erweitert die betreffenden internen Operationen und beschränkt das kumulative Limit auf den klassischen Ganzzahlmodus. Daraus entsteht kein neues 64-Bit-Drahtformat. Die normale Rundung von Gleitkommazahlen bleibt ebenfalls erhalten. „Bandbreitenlimit entfernt“ wäre deshalb eine zu grobe Zusammenfassung einer bedingten Korrektur.

Was bei 30 plus 100 herauskommen soll

Die geänderten Regressionstests speisen 30.000 und 100.000 Mbit/s über zwei interne BGP-Nachbarn ein. Exakt addiert sind das 16.250.000.000 Byte pro Sekunde. Werden Eingaben und Summe entsprechend in einfacher Gleitkommagenauigkeit dargestellt, ergibt sich 16.249.999.360. Diese kleine Abweichung ist erwartete Rundung, nicht der frühere Ganzzahlfehler.

Im klassischen Ganzzahlzweig lautet die Erwartung dagegen 4.294.967.295 Byte pro Sekunde. Der aktualisierte Test fordert diesen Höchstwert anstelle eines niedrigeren abgeschnittenen Ergebnisses. Eine Abnahme, die in beiden Modi den vollen Gegenwert von 130 Gbit/s verlangt, würde das korrigierte Verhalten falsch bewerten.

Die Zahlen wurden für diesen Beitrag unabhängig nachgerechnet. Die FRRouting-Testtopologie wurde hier nicht ausgeführt. Die Untersuchung des Testcodes zeigt seine Prüfaussagen; sie ersetzt keinen eigenen Routerversuch.

Auch die Beobachtungspunkte sind ungleich. Der IEEE-Test kontrolliert die Routing-Informationsbasis des empfangenden Routers, dessen Ankündigung an einen externen BGP-Nachbarn und die Routing-Informationsbasis dieses Nachbarn. Der Test für das rohe Ganzzahlformat prüft lediglich die Darstellung der angekündigten Routen beim Sender. Er weist die Dekodierung auf der Gegenseite nicht nach. Beide Tests lassen Hardware-Weiterleitungsgewichte, reale Verkehrsanteile und Anwendungsdurchsatz offen.

Die Summe braucht einen eigenen Prüfpunkt

Laut FRRouting-Dokumentation zur gewichteten Mehrwegeweiterleitung beeinflussen Bandbreitenverhältnisse die Gewichte zwischen bereits für Multipath geeigneten Pfaden. Das Attribut ändert nicht die Best-Path-Auswahl und macht zuvor ungeeignete Pfade nicht automatisch geeignet. Ob die Weiterleitung die Gewichte umsetzen kann und wie sich reale Flows verteilen, muss separat beobachtet werden.

Bei kumulativen Ankündigungen genügt es nicht, jeden Eingang einzeln zu kontrollieren. Mehrere Werte unterhalb eines Ganzzahllimits können zusammen darüber liegen. Gerade die Ausgabe nach der Addition kann daher der Ort sein, an dem das Wartungsupdate wirksam wird.

Für ältere Gegenstellen gibt es weiter eine nachbarspezifische Option zum Abschalten der IEEE-Kodierung. Der Fix begründet keine pauschale Empfehlung, diese Option überall zu entfernen. Zuerst muss die Gegenstelle das andere Format korrekt verstehen. Einige benachbarte Angaben zu Befehlsgrenzen in der aktuellen Dokumentation sind außerdem enger als die Eingaben der auf eine Revision festgelegten Tests. Daraus darf kein gemeinsames Konfigurationsrezept für sämtliche Wartungszweige abgeleitet werden.

Die bis 8. September, 12:40 UTC, ausgewerteten Quellen nennen keine Zahl betroffener Kunden, keinen Produktionsausfall, keinen gemessenen Geschwindigkeitszuwachs und keine vollständige Matrix betroffener Versionen. Die drei Release-Hinweise belegen die Aufnahme des Fixes in diese Versionen, nicht den Status aller anderen.

Die Trennung von Mechanismus und unbelegtem Nutzen folgt dem redaktionellen Grundsatz aus Lu Hengs Essay über Realität statt Interessenwerbung. Dies ist die Anwendung des Autors, keine FRRouting-Bewertung durch Lu Heng. Für die Abnahme ergibt sich eine konkrete Forderung: Modus, erwarteter Wert und Beobachtung beim Empfänger gehören neben die Versionsnummer.