Resumen

  • FRRouting incluyó la corrección #22681 en las versiones 10.7.1, 10.6.2 y 10.5.5, publicadas el 25 de agosto de 2026, para tratar valores elevados de ancho de banda en una comunidad extendida BGP.
  • La codificación IEEE admite un acumulado mayor; el modo entero clásico conserva su techo. Las pruebas tampoco cubren por igual al emisor, al receptor y al sistema de reenvío.

El número de versión es una condición demasiado pobre para dar por aceptado un cambio de red. La corrección de ancho de banda de FRRouting ofrece un ejemplo concreto: dos aportaciones de 30 y 100 Gbit/s no tienen la misma representación acumulada correcta cuando el vecino utiliza un flotante IEEE que cuando espera un entero clásico.

Las notas de 10.7.1, 10.6.2 y 10.5.5 recogen el arreglo, con fecha de 25 de agosto. No anuncian que un puerto antes limitado físicamente a 34 Gbit/s alcance ahora su velocidad nominal. Describen un problema en la representación de la capacidad dentro de BGP, que puede tener consecuencias operativas sin equivaler a una medición de rendimiento.

La unidad explica el umbral

La solicitud de cambio #22681, incorporada el 28 de julio, identifica una reducción de anchura numérica. Aunque BGP guardaba internamente el ancho de banda en un entero sin signo de 64 bits, algunas funciones de codificación, decodificación o presentación lo estrechaban a 32 bits. Además, al sustituir el ancho de banda acumulado se imponía incondicionalmente el máximo de ese entero.

Ese máximo es 4.294.967.295 bytes por segundo, unos 34,36 Gbit/s. La cifra deja de ser misteriosa al recordar que el campo está expresado en bytes, no en bits. El formato IEEE que viaja por la red ocupa también 32 bits, pero es un número en coma flotante y tiene otro rango. El RFC 10005 fija esa representación de cuatro octetos. La corrección interna no convierte el protocolo en un formato de 64 bits ni suprime el redondeo de los flotantes.

El cambio mantiene el tope acumulado únicamente donde corresponde: en la codificación clásica de enteros sin procesar. Por eso «se ha eliminado el límite» sería una explicación incompleta. Se elimina una restricción indebida en un modo y se conserva una restricción necesaria en otro.

Qué exige realmente la prueba

Las modificaciones de las pruebas de regresión usan entradas de 30.000 y 100.000 Mbit/s desde dos vecinos BGP internos. La suma exacta es 16.250.000.000 bytes por segundo. Tras representar las entradas y su suma en precisión simple, se obtiene 16.249.999.360. Esa pequeña diferencia es un redondeo esperado, no el antiguo estrechamiento a entero.

La rama de codificación clásica espera 4.294.967.295 bytes por segundo: el techo permitido, en lugar del resultado truncado inferior que se comprobaba antes. Exigir el total equivalente a 130 Gbit/s en esta rama sería pedir al formato un valor que no puede representar.

El cálculo se ha comprobado de forma independiente para este artículo. No se ha ejecutado aquí la topología de FRRouting. Hay, además, una asimetría relevante en la evidencia: el caso IEEE comprueba la base de información de rutas del equipo receptor, el anuncio hacia un vecino BGP externo y la base de ese vecino. El caso de enteros verifica únicamente la representación de las rutas anunciadas en el emisor. No acredita la decodificación aguas abajo en ese modo.

Ninguna de esas comprobaciones mide cómo se instalaron los pesos en el plano de reenvío, cuánto tráfico cursó cada salida o qué experimentó una aplicación. Son pruebas concretas y útiles; convertirlas en una garantía de servicio ampliaría su alcance sin evidencia.

El acumulado es un punto de control propio

Según la documentación de multirruta ponderada, los valores de ancho de banda sirven para distribuir pesos entre caminos que ya cumplen las condiciones de multirruta. No alteran la selección del mejor camino. Tampoco añaden por sí solos caminos que antes no eran elegibles.

Cuando un equipo suma capacidad de varias rutas antes de anunciarla, puede cruzar un límite aunque cada aportación individual quede por debajo. Revisar solo las entradas deja sin revisar precisamente la salida acumulada. Y que el valor sea correcto no resuelve si el sistema de reenvío admite los pesos ni cómo el conjunto real de flujos se distribuye entre ellos.

FRRouting conserva una opción de compatibilidad por vecino para implementaciones que esperan el entero clásico. No hay base para recomendar retirarla de toda la red. Primero debe establecerse que el receptor entiende la otra representación. Algunas descripciones actuales de límites de comandos son, además, más estrechas que las entradas de estas pruebas fijadas a una revisión; no deben convertirse en una receta universal para todas las ramas.

La revisión de fuentes, cerrada el 8 de septiembre a las 12:40 UTC, no establece un número de clientes afectados, una interrupción de producción, una mejora de velocidad medida ni una lista exhaustiva de versiones vulnerables al defecto. Las tres notas citadas prueban la inclusión del arreglo en esas versiones, no la situación completa de las restantes.

El enfoque sigue la disciplina editorial de Lu Heng sobre la realidad frente a la promoción de una causa: separar el mecanismo comprobado de los resultados deseados. Es una aplicación del autor, no una valoración de FRRouting atribuida a Lu Heng. La conclusión práctica no promete más capacidad: exige una aceptación más precisa.