Resumen

  • RFC 8654 permite anunciar recepción de mensajes hasta 65.535 octetos, salvo OPEN y KEEPALIVE; el emisor sólo usa esa capacidad después de recibirla del peer.
  • La promesa termina en esa sesión. Ante un vecino de 4.096 octetos sólo pueden descartarse atributos autorizados por RFC 7606; si aún no cabe, no se anuncia y una ruta previa debe retirarse.
  • La adopción segura uniforma iBGP antes de crear dependencia externa, mide tamaño codificado y recursos, y conserva una representación legacy para rollback.

El dashboard confirma capacidad 6 en el ingreso y muestra la ruta en la RIB. Sin embargo, otro border no puede exportarla a un peer antiguo. El conjunto de atributos supera el sobre histórico. Partir paquetes TCP no parte el significado del UPDATE, y eliminar semántica a ciegas tampoco es interoperabilidad.

RFC 4271 usa un campo Length de dos octetos, pero limita los mensajes a 19–4.096. RFC 8654 eleva el máximo negociado a 65.535 para mensajes extendidos. La capacidad de código 6 y longitud cero expresa una promesa concreta: este receptor puede procesar ese tamaño en esta sesión.

La dirección es esencial. Un speaker envía un Extended Message sólo si recibió la capacidad del vecino. RFC 5492 hace que el uso de capacidades sea bilateral y permite que una política local exija soporte. Una implementación capaz que no anunció la función no puede aceptar generosamente un mensaje grande; la configuración conserva autoridad.

OPEN y KEEPALIVE quedan fuera. RFC 9072 resuelve otro límite: amplía la longitud de Optional Parameters dentro de OPEN mediante el tipo 255 y un campo de dos octetos. Un OPEN con muchas capacidades no demuestra que los UPDATE posteriores admitan 65.535.

Espacio disponible no significa espacio gratuito

El máximo no es un objetivo de packing. ADD-PATH añade cuatro octetos por NLRI; cada Large Community contiene doce octetos; VPN y otras extensiones agregan atributos. Esos bytes pueden controlar exportación o distinguir paths, por lo que no son relleno prescindible.

Cuando los atributos caben, el emisor puede repartir prefijos entre varios UPDATE. Si el bloque de atributos ya supera 4.096, dividir NLRI no ayuda. TCP reensambla bytes, pero el receptor sigue validando un solo mensaje BGP con su longitud declarada.

En un egress legacy, RFC 8654 permite intentar una reducción usando únicamente attribute discard de RFC 7606. La categoría es estrecha: nunca se descarta así un atributo que afecte selección o instalación, y una policy local puede convertir un dato aparentemente neutro en decisivo.

Si el mensaje continúa grande, no sale. Si el prefijo estaba anunciado, se retira. La norma prefiere ausencia explícita a una ruta mutilada. Por eso una ruta puede existir en un border y faltar en otro, o un backup resultar inexportable justo durante failover.

La coherencia interna exige que todos los speakers iBGP relevantes anuncien la capacidad. Activarla externamente mientras route reflectors o bordes siguen mezclados crea una topología oculta de qué representación puede cruzar cada salto.

También crece la superficie de recursos

Aceptar 65.535 compromete buffers, colas, parser, validación, policy y logs. RFC 8654 advierte sobre agotamiento accidental o deliberado. Reformatear repetidamente un UPDATE grande para muchos peers legacy también consume CPU. La autenticidad del vecino no abarata datos válidos pero costosos.

FRRouting enumera RFC 8654 como implementada. BIRD 3.3.0 separa enable de require y documenta el máximo ampliado. Son afirmaciones útiles para iniciar pruebas, no evidencia de negociación, headroom ni propagación real.

La prueba se ata a una epoch de sesión: capacidades locales y recibidas, peer, AFI/SAFI y build; longitud exacta de entrada, atributos, NLRI y salida por vecino; luego outcome: repacking, discard, suppress, withdrawal, Bad Message Length o rechazo de policy.

Una captura detrás del ingreso no habla por el egress. Y un UPDATE recibido aún no prueba FIB ni paquetes: selección, resolución, programación y tráfico medido completan la cadena.