Resumen

  • Maria Matejka advirtió en APNIC 62, el 9 de septiembre, que BIRD trata con excesiva dureza las rutas OTC inválidas. Citó 2.20.0 y 3.4.0 como versiones previstas para una corrección, no como una entrega comprobada.
  • El código examinado de BIRD 2.19.2 convierte determinadas infracciones OTC, según el rol de la sesión, en retiradas. En ese recorrido no se construye el objeto de ruta ordinario que una vista de rutas filtradas querría guardar.
  • Conservar pruebas no debe rehabilitar la ruta: la exclusión de la selección activa y de la exportación prohibida tiene que mantenerse. Un error de formato del atributo es, además, un caso distinto.

Para quien opera un punto de intercambio, una ruta que no pasa y una ruta que no se puede explicar son problemas diferentes. El primero puede ser la señal de que una protección funciona. El segundo deja una conversación pendiente con el participante cuya información ya no aparece en la vista que consulta.

El aviso presentado en APNIC 62 reúne esas dos cuestiones. El 9 de septiembre, Maria Matejka señaló un rechazo demasiado severo de rutas OTC inválidas en BIRD y anticipó una corrección destinada a 2.20.0 y 3.4.0. También situó las herramientas de observación externas dentro de sus límites: ven una parte de las rutas y no garantizan que alguien avise del problema.

La frase sobre versiones no demuestra una publicación, una actualización instalada ni una nueva obligación de APNIC. Sí da actualidad a una pregunta que los operadores habían formulado antes: ¿puede seguir existiendo la evidencia de una ruta cuya propagación debe detenerse?

La ruta no tiene derecho a seguir, la prueba sí puede tener utilidad

El RFC 9234 de mayo de 2022 utiliza los roles BGP y OTC para imponer límites de propagación acordes con la relación entre vecinos. Su definición de ruta no elegible la excluye de la instalación en la Loc-RIB y de la siguiente fase de selección.

No equivale a ordenar que desaparezca cualquier representación diagnóstica. Una copia aislada puede informar sobre el rechazo sin convertirse en candidata a encaminar tráfico. Pero esa separación debe ser real. La definición tampoco permite instalar sin más una ruta inválida en una tabla activa y confiar en que un distintivo rojo impida utilizarla.

Hay otra diferencia que conviene conservar: un atributo bien formado puede revelar una fuga por su valor o por la dirección de recepción. Un atributo de longitud incorrecta plantea primero un error del mensaje. Hacer visible un diagnóstico no significa aceptar ambos casos como rutas utilizables.

Lo que ya pedía un operador en 2025

En una solicitud de junio de 2025, André Grüneberg, desde el entorno de BCIX, pidió poder mostrar las rutas OTC rechazadas en una herramienta de consulta, identificando su estado. Propuso una forma de almacenarlas para hacerlas visibles. Aquello fue una petición a los desarrolladores, no una prueba de una configuración implantada ni de su conformidad normativa.

En la respuesta posterior de ese mes explicó que no encontraba interacción entre el camino de retirada y la conservación de rutas filtradas. La conversación también reconoció un coste de trasladar el tratamiento OTC exclusivamente a filtros: perder la comprobación de los roles en la sesión.

No es una recomendación para reproducir ese atajo. Una pantalla más informativa no compensa por sí sola la desaparición de un control de relación entre vecinos. La cuestión de diseño es cómo conservar el motivo de rechazo sin cambiar la prohibición que lo provocó.

Tampoco puede utilizarse aquel intercambio para describir la configuración actual de BCIX o la frecuencia mundial de esas prácticas. Su valor es documentar una necesidad operativa y la frontera que el corresponsal identificó.

El límite está antes de la ruta ordinaria

La página oficial de descargas examinada el 14 de septiembre mostraba, entre otras versiones, 2.19.2 y 3.3.2, fechadas el 30 de julio. En esa captura no figuraban las dos versiones previstas en la presentación. Esto delimita la evidencia pública revisada; no descarta otras ramas, paquetes de terceros o adaptaciones privadas.

El código de atributos del tag 2.19.2 permite una observación más precisa. Cuando los roles se aplican al canal, recibir una ruta marcada con OTC provoca una retirada si el rol local es proveedor o servidor de rutas. Con el rol de par, también hay retirada cuando el ASN de OTC no coincide con el ASN remoto.

La operación registra un mensaje, activa la señal de retirada y regresa al llamador. En el mismo archivo hay una comprobación separada: la longitud de OTC debe ser de cuatro octetos. Si no lo es, se toma una retirada por error de formato, no por la decisión posterior sobre la relación.

El archivo de procesamiento de paquetes del mismo tag muestra el siguiente paso. Tras finalizar los atributos, la señal de retirada hace que su puntero sea nulo. Al aplicar esa información se envía una retirada a la rutina de actualización. La rama con puntero no nulo es la que crea el objeto temporal de ruta.

De ahí se desprende una conclusión acotada: conservar rutas rechazadas por filtros posteriores no permite suponer que se recuperará un objeto sustituido antes por una retirada. No se ha ejecutado un ensayo en un router ni se ha demostrado el comportamiento de todas las versiones.

El registro de mensajes sigue existiendo. No se evaluaron capturas de paquetes, tablas de importación, flujos BMP ni otras herramientas. Por tanto, sería excesivo decir que la ruta es invisible en cualquier sistema. Lo que falta en este recorrido es la equivalencia automática entre un mensaje de rechazo y un expediente consultable con la ruta recibida, su contexto y su motivo.