Resumen

  • RFC 7606 no reconstruye el significado de un atributo roto: decide qué porción del estado de enrutamiento debe retirarse para no confiar en él.
  • Established ya no basta como prueba de disponibilidad; todas las NLRI agrupadas en un UPDATE tratado como retirada pueden faltar en RIB, FIB y tráfico.

El vecino no cae. No aparece una alarma de sesión y la mayor parte de la tabla sigue presente. Sin embargo, un grupo concreto de destinos deja de ser alcanzable. El receptor encontró un atributo de ruta malformado y trató todas las NLRI incluidas en aquel UPDATE como retiradas.

La escena es ilustrativa, pero la distinción es normativa. La RFC 7606 revisó el modo en que BGP responde a errores de UPDATE para evitar que un solo atributo defectuoso obligue siempre a reiniciar una sesión completa. El beneficio es real: rutas válidas que llegaron por el mismo vecino pueden sobrevivir. El coste es una nueva clase de fallo parcial que no se ve en el estado del peer.

La RFC 4271 define los errores de UPDATE y sus subcódigos. Su tratamiento base se resume en RFC 7606 como session reset: enviar una NOTIFICATION, terminar la sesión y eliminar las rutas asociadas. Es una frontera fácil de observar y demasiado amplia cuando el receptor sí puede identificar el mensaje o atributo problemático.

La jerarquía decide cuánto estado se sacrifica

RFC 7606 ordena cuatro acciones por intensidad: reset de sesión, desactivación de AFI/SAFI, treat-as-withdraw y descarte de atributo.

El reset elimina toda la autoridad recibida de ese vecino. Sigue siendo necesario cuando el error impide localizar o analizar de forma segura las NLRI o cuando la especificación aplicable exige cerrar. No se puede retirar de manera precisa un conjunto de rutas que el parser no es capaz de delimitar.

La desactivación de AFI/SAFI mantiene una frontera de transporte pero suspende una familia. La RFC 4760 permite que, ante ciertos errores en MP_REACH_NLRI o MP_UNREACH_NLRI, el receptor borre las rutas de esa familia e ignore anuncios posteriores del mismo AFI/SAFI durante la sesión. No es una retirada de un mensaje: puede neutralizar toda la familia para ese peer.

Treat-as-withdraw convierte todas las rutas contenidas en el UPDATE defectuoso en retiradas y las quita de Adj-RIB-In. La unidad de contención es el mensaje. Si el emisor empaquetó varias NLRI con el mismo conjunto de atributos, todas quedan sujetas al mismo veredicto. El operador no puede atribuir la acción únicamente al prefijo que primero mostró síntomas.

El descarte de atributo elimina el atributo y continúa procesando el UPDATE. RFC 7606 solo admite esta respuesta cuando el atributo no interviene en selección ni instalación. Una política local puede cambiar esa condición: si una route-policy utiliza el atributo, descartarlo puede alterar el resultado aunque el algoritmo BGP base no lo consulte.

La jerarquía no es una reparación en cuatro niveles. Es una asignación de pérdida. Cada respuesta conserva algo —la sesión, otra familia, otras NLRI o el resto de los atributos— y renuncia a otra cosa que debe quedar identificada.

Lo que no puede analizarse no puede contenerse

Treat-as-withdraw requiere que el receptor pueda ubicar y decodificar por completo el campo NLRI correspondiente, incluidos MP_REACH_NLRI y MP_UNREACH_NLRI cuando proceda. Si una longitud corrupta impide encontrar el límite, el receptor no sabe qué rutas fingir que fueron retiradas. En ese punto siguen vigentes el reset de RFC 4271 o la desactivación de familia de RFC 4760.

Por eso un ajuste denominado “enhanced error handling” no promete que la sesión jamás caerá. El tipo exacto de corrupción manda. También explica por qué una organización no debería aceptar una frase genérica como “los UPDATE malformados se ignoran”: ignorar el mensaje no es lo mismo que retirar su estado.

BGP es incremental. Si se desecha silenciosamente un UPDATE nuevo, una ruta anterior que debía cambiar puede permanecer instalada. Treat-as-withdraw fuerza una pérdida explícita; el simple drop puede congelar una verdad antigua que ya no corresponde.

Cuando un UPDATE contiene varios errores, el receptor tampoco escoge la acción más cómoda. RFC 7606 obliga a aplicar la más fuerte de las prescritas. Un atributo descartable no compensa otra malformación que exige retirada o cierre.

Las reglas varían según el atributo. ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC y LOCAL_PREF usan treat-as-withdraw en los casos revisados por RFC 7606; ciertos errores de ATOMIC_AGGREGATE y AGGREGATOR usan descarte. Una segunda aparición de MP_REACH_NLRI o MP_UNREACH_NLRI conserva la respuesta de NOTIFICATION por lista malformada, mientras que duplicados posteriores de la mayoría de los demás atributos se eliminan después de la primera aparición.

Las extensiones posteriores hacen explícito su propio contrato. La RFC 8092 considera malformado un atributo Large Communities cuya longitud no sea un múltiplo no nulo de doce y ordena treat-as-withdraw; valores duplicados, por sí solos, se deduplican y no constituyen ese error. La RFC 7607 prohíbe AS 0 en campos determinados, pero remite a RFC 7606 o a la RFC 6793 según aparezca en AS_PATH, AGGREGATOR o sus atributos de transición de cuatro octetos.

El registro IANA de parámetros BGP mantiene los códigos de atributo y de error. El registro permite identificar el campo; la acción segura sigue perteneciendo a la norma que define su semántica.

Mantener el peer desplaza el riesgo hacia la consistencia

Un reset produce una pérdida grande y uniforme. Treat-as-withdraw produce una pérdida menor, pero puede ser diferente entre receptores. RFC 7606 advierte que aplicarlo sobre iBGP puede dejar estados incompatibles dentro del mismo AS y causar bucles persistentes o agujeros negros. Dos reflectores que no reciben, analizan o configuran igual el mensaje pueden ofrecer realidades distintas a sus clientes.

Incluso sin divergencia, los destinos del UPDATE pueden quedar totalmente inaccesibles o tomar un camino peor. El éxito del mecanismo se mide frente al daño que evitó y al daño que todavía causó, no frente a la ausencia de un flap.

La prueba empieza con el PDU. RFC 7606 exige capacidad de diagnóstico que enumere las NLRI afectadas y conserve el UPDATE malformado completo. Un contador de errores sin bytes, atributo y rutas no permite decidir si el receptor podía analizar las NLRI, si eligió la acción correcta o si varias rutas sanas compartieron el mensaje.

La Route Mirroring de BMP, RFC 7854 puede transportar una copia exacta del mensaje recibido y marcar un PDU erróneo tratado como retirada. Esa captura no se debe idealizar: puede muestrearse, perder mensajes y consumir recursos; Messages Lost es una advertencia forense, no ruido operativo.

Del UPDATE a la FIB

La reconstrucción debe fijar vecino, dirección, AFI/SAFI, código y flags del atributo, longitudes declaradas y reales y todas las NLRI. También debe guardar la versión del receptor y la configuración efectiva tras herencia de grupos. Un nombre de función igual en dos plataformas no prueba la misma clasificación.

Después se documenta el veredicto exacto: NOTIFICATION y reset, desactivación de familia, retirada de todas las rutas del UPDATE o descarte del atributo. La entrada de log debe correlacionarse con el mensaje, no solo con un peer que pudo enviar miles de actualizaciones.

Adj-RIB-In o la vista de rutas ocultas demuestra qué se eliminó. Loc-RIB muestra si ganó una alternativa. Los reflectores y cada salida material revelan incoherencias y propagación. La FIB o la tabla de hardware indica qué acción de reenvío quedó instalada. Las pruebas de paquetes, en ambos sentidos y durante la condición de fallo, completan una cadena que el estado Established no puede sustituir.

Los fabricantes documentan fronteras distintas. Cisco IOS XR muestra mensajes con vecino, longitud, atributo, familia, NLRI y acciones como TreatAsWithdraw y DiscardAttr. Junos describe reset, rutas ocultas, retirada y registro. Nokia SR OS documenta update-fault-tolerance para usar respuestas revisadas ante errores no críticos en vez del tratamiento heredado. Ninguna de estas páginas convierte su default, sintaxis o matriz de errores en regla universal.

Recuperar significa corregir el origen

Ante un atributo malformado visto en iBGP, RFC 7606 recomienda rastrearlo hasta el router de ingreso que lo originó o recibió externamente y aplicar allí la corrección o el filtro. Contener solo en el último receptor puede dejar al resto del AS dividido.

El cierre debe incluir un UPDATE limpio del emisor. Las rutas tienen que volver a Adj-RIB-In, converger sin discrepancias, producir la selección esperada, instalarse en FIB y transportar paquetes. Si se añadió un filtro de emergencia, su alcance y retiro deben decidirse de forma explícita; el silencio del contador no demuestra que el defecto haya desaparecido.

La pregunta de autoridad es concreta: ¿quién puede decidir que conservar una sesión vale retirar todas las rutas de un mensaje, y con qué evidencia? Una respuesta responsable puede ser treat-as-withdraw. Pero solo lo es cuando el receptor conoce la unidad sacrificada, conserva la causa y demuestra la recuperación de cada capa.