Resumen

  • Los atributos opcionales transitivos permiten que una extensión atraviese equipos que no conocen su semántica. Si un hablante acepta y vuelve a anunciar la ruta, conserva el atributo y pone Partial a 1; ningún AS posterior puede borrar esa huella.
  • Partial registra una custodia semántica incompleta. No autentica el origen, no identifica el salto ignorante, no valida el valor, no prueba soporte universal y tampoco expresa consentimiento con la política codificada.
  • RFC 7606 permite descartar un atributo o tratar sus rutas como retiradas sin derribar la sesión. Por eso hay que unir bytes recibidos y enviados, acción de error, resultado en RIB y paquetes, no limitarse al estado del vecino.

A las 02:10, un operador prueba un nuevo atributo de política entre dos sitios controlados. El borde de origen ejecuta la versión nueva; el tránsito intermedio no reconoce el código; el borde receptor acaba de actualizarse y sí sabe interpretarlo.

El UPDATE llega bien delimitado: flags, tipo, longitud, valor y un prefijo IPv4. El tránsito sabe dónde empieza y termina el objeto, pero carece del decodificador. Como Optional y Transitive están activos, acepta el camino, preserva los bytes, activa Partial y anuncia la ruta al receptor.

Allí cambia la autoridad. El receptor reconoce el tipo y aplica su gramática. El valor es inválido, de modo que la ruta se trata como retirada. TCP continúa, los KEEPALIVE siguen llegando y el tránsito conserva el prefijo. Solo desaparece el camino que necesitaba el cliente.

El caso es sintético; la frontera no. BGP se diseñó para que información futura pudiera cruzar nodos antiguos sin una actualización mundial coordinada. Esa extensibilidad implica que un router puede transportar correctamente una semántica que no puede examinar, y que una actualización posterior convierta un objeto antes opaco en una causa legítima de rechazo.

Cuatro bits hacen cuatro promesas distintas

Los cuatro bits altos de Attribute Flags no son adjetivos intercambiables. Optional separa una extensión de los atributos well-known que toda implementación debe reconocer. Transitive decide si un atributo opcional desconocido puede cruzar una frontera BGP. Partial indica que la información de un atributo opcional transitivo es incompleta. Extended Length solo elige si la longitud ocupa uno o dos octetos. Los cuatro bits bajos se envían a cero y se ignoran al recibirlos.

Un atributo well-known debe entenderse; lleva Transitive, pero Partial debe ser cero. Un atributo opcional no transitivo puede servir entre equipos compatibles, aunque un receptor que no lo conozca lo ignora en silencio y no lo propaga. Partial también es cero en ese caso.

La excepción útil es el opcional transitivo. RFC 4271 no espera que cada implementación conozca todas las extensiones. Una ruta con un atributo desconocido de esa clase debería aceptarse. Si se vuelve a anunciar, el atributo debe viajar con ella y Partial pasa a 1.

Es una promesa estrecha: custodia de bytes, no comprensión. El router conoce los límites, el código y los flags, pero no sabe si el valor está autorizado, es auténtico, cumple su sintaxis interna o será seguro para un decodificador futuro.

Extended Length tampoco certifica la estructura interior. Solo cambia el ancho del campo de longitud. Un objeto puede estar perfectamente enmarcado y ser semánticamente defectuoso. El nodo antiguo lo conserva precisamente porque no posee el código capaz de detectar el fallo.

Partial no es una puntuación de confianza

El nombre invita a leer “dañado”, “no verificado” o “poco fiable”. La definición es más exacta. Cuando un hablante que no entiende el atributo lo propaga, activa Partial. Si otro hablante lo reconoce y ya recibe Partial a 1, no puede volver a cero. También se activa cuando un hablante distinto del origen añade un nuevo atributo opcional transitivo.

La marca dice que no debe suponerse una cadena completa de custodia semántica desde el origen. No revela qué AS desconocía el tipo, no enumera quién lo comprendió, no informa de una modificación permitida ni prueba que el emisor tuviera autoridad para adjuntarlo.

Tampoco está autenticada. Partial es un bit dentro de un UPDATE y hereda la frontera de confianza de la sesión y de la operación. No sustituye validación de origen, política de relaciones, protección del transporte, procedencia de configuración ni evidencia del plano de datos.

Su valor reside en la modestia: conserva la admisión de que el objeto cruzó una frontera sin dueño semántico completo. Esa señal pide investigación y política acotada, no confianza automática ni bloqueo indiscriminado.

Una actualización mueve la frontera de reconocimiento

“Desconocido” depende de implementación, versión, familia y función habilitada. Los mismos bytes pueden ser opacos el martes y parsearse el miércoles.

Mientras el tipo es desconocido, el router puede conservarlo sin validar su interior. Cuando pasa a ser conocido, aplica las reglas específicas: flags, longitud, subestructuras, significado y acción de error. Un valor que circuló durante meses puede provocar attribute discard o treat-as-withdraw al alcanzar el primer decodificador, o cuando un nodo existente recibe una nueva versión.

Eso no demuestra necesariamente una regresión. La actualización quizá sea el primer componente capaz de detectar una malformación real. El tránsito antiguo tampoco incumplió la base. El incidente nace del despliegue desigual, la propagación opaca y una frontera semántica recién activada.

Por ello, una actualización debe inventariar previamente las rutas con atributos desconocidos: código, flags, longitud, hash del valor, vecino, AFI/SAFI, NLRI y estado de Partial. Después se comprueba qué códigos pasaron a reconocerse, qué validación se ejecutó, qué acción se tomó y qué rutas cambiaron.

Sin ese inventario, la pérdida se etiqueta como “fallo de software”. Con él se distingue un bug del parser, un rechazo correcto, una política de contención excesiva o un emisor que rompió el contrato del atributo.

Conservar la sesión no conserva el servicio

El modelo inicial de BGP-4 podía reiniciar toda una sesión por un atributo malformado, eliminando también rutas sanas. Los atributos opcionales transitivos agravaban el alcance: un nodo ignorante podía repartir un valor no validado a muchos receptores que sí lo entendían.

RFC 7606 acota varios fallos. Session reset sigue siendo la acción más fuerte. Treat-as-withdraw elimina del Adj-RIB-In las rutas del UPDATE defectuoso manteniendo la sesión. Attribute discard elimina el atributo y continúa procesando el anuncio.

No es una escala simple. Descartar el atributo puede ser más engañoso que retirar la ruta: la conectividad permanece, pero desaparece la semántica que debía influir en selección o instalación. Por eso el discard solo es apropiado cuando el atributo no afecta esas decisiones, salvo análisis específico.

Treat-as-withdraw hace visible el fallo como pérdida de ruta, pero puede ocultarlo a la monitorización centrada en sesiones. El vecino sigue Established, no expira el Hold Timer y circulan KEEPALIVE. Nada de eso prueba que el NLRI siga presente.

Si Optional o Transitive contradice la especificación de un atributo reconocido, RFC 7606 suele exigir treat-as-withdraw, salvo regla propia. Un MP_REACH_NLRI o MP_UNREACH_NLRI duplicado activa treat-as-withdraw para todas las rutas del UPDATE y conserva la sesión; para la mayoría de los demás atributos duplicados se descartan las apariciones posteriores. Si coinciden varios errores, manda la acción más fuerte.

“Compatible con RFC 7606” no basta. Hay que conocer la clasificación concreta, la regla del atributo y el conjunto final de rutas. Un equipo puede mantener correctamente la sesión y aun así causar una interrupción grave.

La red local conserva la autoridad de contención

La propagación por defecto protege la extensibilidad, pero no obliga a dejar que cada código desconocido atraviese toda frontera productiva. El operador puede exigir procedencia, coste y efecto aguas abajo antes de permitirlo.

La documentación actual de Juniper ofrece dos decisiones distintas: descartar atributos opcionales transitivos desconocidos manteniendo la ruta, o retirar las rutas que los llevan. Se pueden exceptuar códigos concretos y aplicar la regla globalmente, por grupo o por vecino. Las vistas de vecino muestran después los atributos eliminados y los que causaron retiradas.

Son controles locales, no leyes universales. Eliminar el atributo puede mantener paquetes mientras borra una semántica necesaria. Retirar todas las rutas con un código nuevo puede convertir una adopción gradual en una caída. Una excepción demasiado amplia restaura la exposición.

La pregunta correcta no es “¿permitir desconocidos?”, sino “¿qué código cruza qué relación y AFI/SAFI, con qué evidencia y qué acción ante la duda?”. Cliente, route server, reflector interno, peer y laboratorio merecen respuestas distintas.

Cisco NX-OS documenta la visibilidad necesaria: listar prefijos con atributos desconocidos o descartados y mostrar flags, tipo, longitud y valor en una ruta. Un contador global no distingue un experimento benigno de un objeto anómalo pegado a cientos de miles de prefijos.

Propagar es custodiar, no consentir

El router que conserva un atributo que no entiende no acepta su significado; cumple un contrato de transporte de información. Confundir ambas cosas produce conclusiones comerciales falsas.

Si el atributo expresa una clase de servicio, un AS de tránsito ignorante no queda obligado a prestar ese servicio, validar la elegibilidad o aceptar responsabilidad. Partial no convierte transporte en consentimiento. Cada red receptora mantiene su contrato y su política.

Lo mismo vale para seguridad. Desconocido no equivale a hostil y asignado por IANA no equivale a seguro. El registro estabiliza el código; no demuestra que el emisor siguiera la norma ni que el decodificador carezca de errores de recursos, parsing o lógica.

La soberanía práctica de los datos también existe aquí. Aunque la red ignore el significado privado, decide si los bytes entran en logs, cruzan tenants, salen del dominio, causan una acción o se conservan para investigación. Opaco no significa sin custodio.

La evidencia debe conservar hashes de los bytes recibidos y enviados, no solo texto CLI. Algunas vistas normalizan flags, abrevian valores u omiten atributos. El UPDATE original, junto con Adj-RIB pre y pospolítica, demuestra si el sistema preservó, cambió o eliminó el objeto.

El canario debe hacer observable la ignorancia

No se debe inventar un código al azar en la tabla pública. La prueba pertenece a un laboratorio, un acuerdo bilateral controlado o el procedimiento de la extensión real: pocos prefijos, código conocido, política reversible y sondas independientes.

Hay que registrar cuatro etapas: UPDATE de origen con bytes exactos; salto ignorante con Partial antes y después y anuncio de salida; salto conocedor con versión del decoder, validación, acción y Adj-RIB-In; plano de datos con ruta seleccionada, FIB y paquetes.

Conviene probar un valor válido, otro bien enmarcado pero semánticamente inválido y un control desconocido no transitivo. El primero produce el efecto documentado; el segundo, la acción de error; el tercero no cruza el salto ignorante. Así se prueba la clasificación y no solo la presencia.

Después hay que mover el tiempo: actualizar el salto antes ignorante y repetir el mismo UPDATE. Un resultado distinto puede ser correcto. Ese ensayo muestra el cambio esencial: reconocer el tipo desplaza la frontera de validación.

La reversión necesita dos palancas independientes. Una corrige o elimina el atributo en origen; otra contiene el tipo en la frontera sin reiniciar sesiones ajenas. Si alguna requiere publicar código de emergencia, la prueba no está lista.

La primacía del código en ejecución es literal en este caso. La norma aporta el mecanismo; la cadena desplegada decide si sobreviven los bytes y la ruta. La prueba es el UPDATE capturado, la transición durable de Partial, la acción real, el RIB y el paquete entregado.