Résumé

  • Les versions 10.7.1, 10.6.2 et 10.5.5 de FRRouting, publiées le 25 août 2026, incluent le correctif #22681 concernant les grandes valeurs de bande passante dans une communauté étendue BGP.
  • Le plafond de l’ancien encodage entier demeure intentionnel. La recette doit distinguer cet encodage du flottant IEEE, puis séparer les résultats de routage des performances de transfert.

Voir encore environ 34,36 Gbit/s après une mise à jour pourrait inquiéter un exploitant qui vient précisément d’installer un correctif annoncé au-delà de 34 Gbit/s. Ce serait pourtant un mauvais verdict si le voisin utilise l’ancien encodage entier. Dans ce cas, le plafond reste la bonne réponse ; c’est la manière de l’atteindre, et non sa disparition, qu’il faut vérifier.

Les notes officielles des versions 10.7.1, 10.6.2 et 10.5.5, datées du 25 août, mentionnent toutes le correctif #22681. Il porte sur le traitement de la bande passante dans une communauté étendue BGP. Rien dans ces notes ne mesure une limite physique des ports à 34 Gbit/s ni un gain de débit après installation.

Pourquoi ce nombre inhabituel ?

Le champ exprime des octets par seconde. Le plus grand entier non signé sur 32 bits, 4 294 967 295, correspond donc à environ 34,36 milliards de bits par seconde. La demande de fusion #22681, intégrée le 28 juillet, décrit des fonctions auxiliaires qui réduisaient à 32 bits une valeur détenue plus largement dans BGP. Elles intervenaient dans l’encodage, le décodage ou l’affichage. Le remplacement de la bande passante cumulée appliquait aussi ce maximum sans distinguer les modes.

Or le format IEEE sur le réseau est un flottant sur 32 bits. Même largeur, autre domaine de représentation : le plafond d’un entier de cette taille n’est pas le sien. Le RFC 10005 précise ce format sur quatre octets et son unité. Élargir les opérations internes ne crée ni un champ réseau sur 64 bits ni une transmission exacte de tous les entiers.

Le changement retire les rétrécissements inappropriés et réserve le plafonnement cumulatif au mode entier brut classique. Cette dernière condition compte autant que l’élargissement. Présenter le correctif comme la suppression de toute limite de bande passante serait inexact.

La recette doit garder les unités

Les tests modifiés fournissent deux entrées, 30 000 et 100 000 Mbit/s, par deux voisins BGP internes. Leur somme exacte vaut 16 250 000 000 octets par seconde. Après les conversions en simple précision des entrées et du total, le résultat attendu en IEEE est 16 249 999 360. Ce petit écart d’arrondi ne constitue pas le retour du défaut de réduction en entier.

Avec l’encodage entier brut, le test attend au contraire 4 294 967 295 octets par seconde. Cette saturation remplace un résultat tronqué plus faible. Attendre 130 Gbit/s dans les deux modes ferait échouer à tort une implémentation corrigée. Les calculs ont été revérifiés pour cet article ; la topologie FRRouting, elle, n’a pas été exécutée par l’auteur.

Les assertions ne portent pas non plus sur le même parcours. Le test IEEE examine la base d’informations de routage du routeur qui reçoit les deux entrées, ses annonces vers un voisin BGP externe, puis la base de ce voisin. Le test de l’encodage entier inspecte seulement la représentation des routes annoncées côté émetteur. Il ne démontre pas le décodage chez le destinataire. Aucun des deux ne prouve les poids installés dans le matériel ni la répartition réelle du trafic.

Cette précision évite de transformer un test utile en garantie excessive. Une somme peut franchir un plafond alors que chacun de ses termes reste inférieur : sur un équipement qui réannonce la capacité cumulée, contrôler uniquement les contributions individuelles laisse justement de côté l’opération sensible.

Une compatibilité qui reste locale

La documentation de FRRouting sur les chemins pondérés situe l’usage de ces valeurs parmi des chemins déjà admissibles au multipath. L’attribut ne change pas la sélection du meilleur chemin. Les rapports de bande passante servent à déterminer des poids ; leur prise en compte par le système de transfert et le comportement des flux doivent être observés séparément.

Un réglage par voisin maintient la compatibilité avec les implémentations utilisant l’entier brut. Le supprimer partout au nom de la correction serait une migration supplémentaire, sans preuve fournie ici que tous les voisins la supportent. Certaines limites de commande dans la documentation actuelle sont d’ailleurs plus étroites que les valeurs utilisées par ces tests figés. La version réellement déployée et les commandes qu’elle accepte restent indispensables à toute procédure.

Les sources examinées au 8 septembre, 12 h 40 UTC, ne donnent ni nombre de clients touchés, ni incident de production, ni accélération mesurée, ni inventaire complet des versions affectées. Les trois notes établissent l’inclusion du correctif dans ces versions, sans résoudre le cas de toutes les autres.

La démarche rejoint la discipline éditoriale de Lu Heng sur la réalité plutôt que le plaidoyer : expliquer ce qui fonctionne et jusqu’où va la preuve. Il s’agit de l’application de ce principe par l’auteur, pas d’un avis de Lu Heng sur FRRouting. Le résultat opérationnel est simple : une recette qui ne note que le numéro de version oublie une partie du comportement qu’elle prétend valider.