Resumen

  • BGP interpreta normalmente el ASN local dentro de AS_PATH como evidencia de bucle. allowas-in cambia el veredicto receptor; as-override cambia el camino antes de que se evalúe.
  • Ambos mecanismos pueden servir a sedes que comparten ASN, pero no autentican prefijos ni demuestran reenvío. Route Target, Site of Origin y autorización son controles separados.
  • Una excepción auditable conserva los caminos anterior y posterior, delimita vecino, AFI/SAFI y ocurrencias, prueba controles de sitio y prefijo y sigue la ruta hasta el FIB y los paquetes.

El rechazo no era el fallo

Imaginemos un servicio acotado, no un incidente real. Las sedes A y B usan el mismo ASN de cliente detrás de una red de proveedor. A anuncia un prefijo. El proveedor lo entrega a B, cuyo router encuentra su propio ASN en AS_PATH y descarta la ruta. La sesión sigue establecida y el PE conserva el anuncio, pero B no lo utiliza.

Ese resultado es la protección ordinaria. RFC 4271 excluye del proceso de decisión una ruta que contiene el ASN local y declara fuera de su alcance la operación configurada para aceptarlo. El camino está avisando que la información ya pasó por ese dominio de enrutamiento. RFC 4271

Hay dos propuestas frecuentes. El receptor puede permitir un número limitado de apariciones de su ASN mediante allowas-in o allow-own-as. O el proveedor puede sustituir las apariciones del ASN del cliente antes de anunciarle la ruta, mediante as-override.

No son botones equivalentes. El primero mantiene el camino y modifica la regla que lo juzga. El segundo modifica la evidencia para que la regla predeterminada ya no se active. Uno entrega la excepción al cliente receptor; el otro entrega al proveedor la custodia del historial.

Una evidencia útil porque puede cambiar

AS_PATH ayuda a detectar bucles y seleccionar rutas, pero no es una firma del trayecto físico. RFC 4272 explica que cada speaker comprueba ante todo su propio ASN, no todas las transiciones declaradas, y que un camino falso o acortado puede alterar selección y bucles. La lección no es desechar AS_PATH, sino proteger su valor probatorio cuando alguien decide mutarlo o tolerarlo. RFC 4272

allowas-in cambia la admisión. Una implementación puede ofrecer límite de ocurrencias, alcance por vecino, grupo o familia, condición de origen o route-map. FRRouting documenta varias de esas posibilidades. RFC 7938 describe la función como ampliamente disponible pero no estandarizada en un Clos que reutiliza ASN privados. Esa seguridad depende de una topología concreta y no define una cifra universal. Documentación BGP de FRRouting, RFC 7938

as-override cambia la salida. FRRouting y Junos documentan que las apariciones iguales al ASN del peer se reemplazan por el ASN local del proveedor. Junos advierte además que el prepend repetido del cliente también se sustituye. El camino puede conservar su longitud aparente mientras pierde la identidad que explicaba esas posiciones. Documentación BGP de FRRouting, Junos as-override

Por eso una captura posterior no basta. El expediente debe conservar el anuncio original del CE, la recepción del PE, la exportación que existiría sin override, la exportación real y la vista aceptada por el CE remoto. Sin esa secuencia no es posible distinguir una mutación autorizada de una pérdida accidental de historia.

RT, SoO y autorización no son sinónimos

RFC 4364 asigna a Route Target la pertenencia e importación de rutas VPN. Site of Origin identifica el sitio donde se aprendió una ruta y evita devolverla a un CE de ese sitio cuando se aplica conforme al diseño. La autorización de prefijo responde a una tercera pregunta: si esa conexión tenía derecho a originar la red. RFC 4364

Un RT puede distribuir perfectamente una ruta que circula; no sustituye la evidencia self-AS. SoO está más cerca del problema de bucle de sitio, pero solo funciona si todas las conexiones pertinentes lo fijan y lo ejecutan de manera coherente. No autentica al cliente ni demuestra que no haya un camino alternativo alrededor del control.

La documentación actual de IOS XR advierte en su escenario L3VPN que AS override pierde información y puede causar bucles, y usa SoO como compensación. Es una prueba específica del diseño documentado, no una garantía automática para cualquier red. Documentación BGP de Cisco IOS XR

RFC 9835 también modela por separado as-override, allow-own-as, su máximo de ocurrencias y Site of Origin. El YANG no impone semántica idéntica a todos los productos, pero muestra que son decisiones independientes. RFC 9835

Custodia completa de una ruta

Primero se registra el estado estricto: Adj-RIB-Out de A, Adj-RIB-In del PE, camino del PE remoto antes de exportar y vista rechazada de B con el motivo self-AS. Si existe VPN, RD y RT se anotan como atributos de servicio, no como prueba de origen.

En una excepción receptora hay que leer la política efectiva después de herencias: vecino exacto, AFI/SAFI, número permitido, posible condición origin-only y filtros de prefijo o route-map. Una ruta de control fuera del conjunto debe seguir rechazada. La línea escrita no demuestra por sí sola el alcance compilado.

En una reescritura emisora se comparan todos los elementos del AS_SEQUENCE antes y después. Si el cliente hizo prepend varias veces, cada coincidencia puede mutar. El original debe guardarse fuera del estado cambiante del equipo, pues el anuncio final no puede reconstruir la identidad borrada.

Después se verifican por separado autorización, RT, SoO y cualquier conexión paralela, reflector o redistribución que eluda el punto de control. RFC 6368 recuerda que remapear ASN o aceptar el propio tiene inconvenientes cuando el cliente usa BGP internamente para otras funciones; el efecto puede superar la sesión PE–CE. RFC 6368

Aceptar no es reenviar. Se comprueban selección Loc-RIB, resolución, FIB o hardware y tráfico controlado en ambos sentidos. Una prueba segura de fallo debe revelar una reentrada inesperada sin crear circulación peligrosa. RFC 7705 demuestra, en migración ASN, que manipular el historial puede permitir lo que la regla self-AS habría detenido. No define as-override, pero explica por qué “la ruta apareció” no es un criterio suficiente. RFC 7705

La reversión debe restaurar la propiedad anti-bucle. El canario con ASN local vuelve a rechazarse donde corresponde; la conectividad autorizada, el FIB y los paquetes regresan al estado esperado. Borrar una orden sin probar esa cadena es una acción, no una recuperación.