Resumen

  • El «dominio» de la RFC 10039 es una unidad de reenvío del arrendatario: no coincide necesariamente con un sistema autónomo, una instancia IGP, un centro de datos o una organización.
  • DOMAIN-ID es una afirmación configurada con efectos ejecutivos. Si aparece en el D-PATH local, la ruta se trata como un retorno; además, la longitud del atributo participa en la selección. Un mapa erróneo puede crear tanto falsos bucles como bucles invisibles.

En la revisión del cambio, todos podían explicar D-PATH y nadie podía explicar el dominio. El diagrama mostraba tres nubes, dos pares de pasarelas y un ASN. La plantilla asignaba identificadores a las nubes porque parecía natural. Cuando se preguntó dónde ocurría la búsqueda IP en el espacio del arrendatario, las respuestas dejaron de coincidir.

Esa pregunta es más importante que la sintaxis del atributo.

La RFC 10039 normaliza la interconexión de dominios EVPN e IPVPN. Una PE de interworking recibe una ruta, la importa en una IP-VRF y la vuelve a originar con la familia y los parámetros adecuados para el dominio vecino. Con pasarelas redundantes, la misma ruta puede cruzar por una de ellas y regresar por otra. D-PATH añade una secuencia de dominios para reconocer ese retorno antes de que la redistribución alimente un bucle.

El mecanismo es potente, pero recibe su topología de la configuración. No la mide.

La frontera no se hereda del ASN

La RFC define que dos PE están en el mismo dominio cuando pertenecen al mismo arrendatario y el tráfico entre ellas no necesita una consulta IP, en el espacio del arrendatario, en un router de tránsito. Si la consulta es necesaria, una pasarela cruza una frontera de dominio.

Por eso un dominio puede abarcar más de un AS y un AS puede albergar varios dominios. La misma independencia vale frente a áreas IGP y límites empresariales. Es posible que el dibujo físico y la definición de reenvío coincidan, pero la coincidencia debe demostrarse; no se obtiene del nombre del sitio.

DOMAIN-ID tiene seis octetos. El subcampo de administrador global ocupa cuatro y puede contener un ASN público o privado, una dirección IPv4 o cualquier valor adecuado; el administrador local completa los dos octetos restantes. La forma ayuda a asignar y depurar. No convierte el número en una prueba de pertenencia. Un valor que se parece a un ASN sigue siendo un identificador opaco del dominio en este contexto.

La coherencia exigida es concreta. Cada dominio usa un ID único. Todas las PE de pasarela unidas al mismo dominio deben compartirlo. Una PE que comunica dos dominios mantiene dos IDs distintos. El alcance puede ser el conjunto del peering o una IP-VRF específica; esta última opción es relevante cuando una ruta pasa entre VRF, porque la detección se evalúa contra los IDs locales de ese contexto.

Antes de activar nada, el operador ya necesita una autoridad de asignación, una lista completa de pasarelas y una explicación verificable de la frontera. Sin eso, el atributo solo distribuye ambigüedad con mayor eficiencia.

El identificador vota en la decisión BGP

La IANA registra D-PATH como atributo BGP 36. Es opcional y transitivo. Cada paso codifica el DOMAIN-ID y un ISF_SAFI_TYPE que cuenta si el tramo corresponde a EVPN, IPVPN u otra indicación permitida. Ese segundo dato ayuda a observar el interworking, pero no modifica el juicio de bucle.

Cuando una pasarela recibe una ruta cuyo D-PATH contiene uno de los DOMAIN-ID asociados localmente a la IP-VRF, la considera un retorno a efectos de reanuncio. La comparación ignora el tipo SAFI. Así se evita que una ruta escape del control solo porque cambió de familia. También se amplifica una equivocación: reutilizar el mismo ID en dos dominios puede vetar una ruta legítima, mientras que escribir dos IDs para un solo dominio puede ocultar el regreso.

El atributo participa además en el mejor camino. Para un prefijo que compite mediante EVPN y otra SAFI de inter-subnet forwarding, el procedimiento aplica LOCAL_PREF y, a continuación, descarta los candidatos que no tengan el D-PATH más corto. Una ruta sin atributo tiene longitud cero. El resultado es determinista, pero la magnitud no significa latencia, distancia física, coste o fiabilidad. Es la longitud de una narración configurada.

El hecho de que el campo influya tanto no lo vuelve verdadero. La ruta expresa «he cruzado estos dominios»; no aporta una firma de cada frontera, una medición del plano de datos ni una resolución de quién tenía derecho a nombrarla.

Aislar o conservar el contexto

D-PATH no se anuncia por defecto y solo corresponde a rutas IPVPN y EVPN. La RFC ofrece dos posturas distintas al volver a originar atributos.

No Propagation Mode es el valor predeterminado. La pasarela inicializa de nuevo los atributos al cruzar el límite, como si el prefijo fuese local. Al no conservar D-PATH, reduce el estado remoto que puede influir en el dominio siguiente. Sin embargo, varias pasarelas pueden seguir formando un bucle; filtros y comunidades pueden ayudar, pero la RFC no los presenta como una detección completa.

Uniform Propagation Mode preserva un conjunto limitado: AS_PATH, D-PATH cuando procede y ciertos atributos internos en iBGP. Los demás no deberían propagarse salvo permiso explícito de la política de importación o exportación. Se gana visibilidad sobre el recorrido y se acepta que atributos sintácticamente válidos pero semánticamente impropios alcancen más decisiones.

No hay una respuesta automática. Reinicializar protege una frontera eliminando contexto, pero elimina también pruebas útiles. Propagar sostiene una cadena de observación, pero obliga a revisar su contenido. La hoja de cambio tiene que indicar el modo por frontera, el conjunto admitido y el responsable de cada excepción.

La robustez sintáctica no valida el mapa

Para una estructura mal formada, la respuesta es clara. Una longitud imposible, un segmento roto o D-PATH en una familia no autorizada activa treat-as-withdraw conforme a la RFC 7606. Un tipo SAFI desconocido puede aceptarse, porque la comparación de identidad no depende de él. Si el UPDATE contiene varios D-PATH, se conserva el primero y se descartan los restantes.

La contención de errores evita tumbar una sesión por ciertos defectos. No detecta que dos equipos hayan asignado correctamente el mismo valor a realidades distintas. La RFC advierte que IDs mal configurados o soporte desigual pueden causar falsos positivos, descarte de tráfico y decisiones subóptimas o divergentes. También reconoce el riesgo de inyectar información falsa en un atributo transitivo.

El perímetro final es el CE. D-PATH pertenece al ámbito VPN cerrado. Una PE conforme debe retirarlo antes de anunciar un prefijo al cliente como unicast SAFI 1. Si un equipo antiguo lo transporta como atributo desconocido, podría escapar de ese jardín. Los equipos actualizados deberían imponer una política ante rutas con D-PATH procedentes de peers no actualizados, pero la RFC no decide cómo identificarlos. El inventario real de versiones no es opcional.

Del acuerdo a un recibo de ejecución

Un despliegue gobernable puede resumirse en un documento por arrendatario. Primero registra la prueba de reenvío que separa cada dominio. Después identifica quién asigna los DOMAIN-ID, dónde deben ser únicos, qué búsqueda de colisiones se realizó y en qué pasarelas, interfaces e IP-VRF se instalarán. El uso de un ASN o una dirección como notación debe acompañarse de una advertencia: no es una deducción topológica.

El recibo de ejecución completa el acuerdo con versiones de software, soporte probado, modo de propagación por frontera, allowlist de atributos, tratamiento de rutas locales, ventana de observación y plan de reversión. Debe incluir un resultado esperado por salto, no solo la intención global «evitar bucles».

Las pruebas negativas dan valor al recibo. Un prefijo legítimo debe cruzar el itinerario previsto. Otro anuncio incluye deliberadamente un ID local y activa la defensa. Un tipo SAFI desconocido demuestra que el ID sigue comparándose. Una estructura rota verifica el retiro contenido. Un peer de versión anterior revela si conserva, ignora o maneja de forma inesperada el atributo. La salida al CE debe mostrar su eliminación.

Para el mismo conjunto de prefijos, la observación une Adj-RIB-In, candidatos, ruta elegida, FIB y paquetes. No basta con que la sesión BGP esté Established ni con que el comando aparezca en la configuración. La afirmación final debe ser estrecha: en esta fecha, estos gateways compartieron esta definición de dominio y produjeron este comportamiento observado.

RFC 4271 define la base de BGP; RFC 4364, el marco IPVPN; RFC 7432, RFC 9135 y RFC 9136, las piezas EVPN. Son normas y modelos, no certificados sobre implementaciones concretas.

Fuentes