Resumen

  • D-PATH es el atributo BGP opcional y transitivo de código 36 definido por RFC 10039 para llevar secuencias de DOMAIN-ID en interconexiones EVPN/IPVPN configuradas.
  • Su aparición permite detectar el retorno de una ruta al mismo dominio y, después de Local Preference, favorece la secuencia más corta; no autentica a los dominios que enumera.
  • Un control defendible separa la evidencia de la actualización BGP de la evidencia de configuración, instalación RIB/FIB y entrega bidireccional del servicio.

El paquete que no obedeció al diagrama

El centro de operaciones ve una ruta válida. La sesión BGP está arriba, el next-hop se resuelve y el nuevo atributo muestra tres dominios sin repetir. En la pantalla, el recorrido parece limpio. En el VRF del cliente, sin embargo, el tráfico desaparece.

No hay contradicción. La pantalla y el fallo hablan de capas distintas. RFC 10039 ofrece una forma de expresar la historia interdominio dentro de la ruta, pero no convierte esa historia en una observación del plano de datos. La virtud del estándar consiste precisamente en hacer más visible una pieza que antes podía quedar implícita; el error operativo sería atribuirle autoridad sobre las piezas que no observa.

Qué registra D-PATH

El atributo contiene uno o más segmentos. Cada segmento identifica el tipo de familia de servicio y una secuencia de DOMAIN-ID. Cuando una pasarela exporta una ruta a otro dominio, añade el identificador que representa su dominio. Si una pasarela recibe una ruta y encuentra su propio identificador en la secuencia, dispone de una señal explícita de bucle.

RFC 10039 limita su aplicación a escenarios de interconexión EVPN e IPVPN y exige habilitación deliberada. No es un atributo que deba aparecer por el simple hecho de que exista una sesión BGP. En el modelo sin propagación, la frontera no lo pasa al dominio vecino; en el modelo uniforme, su conservación permite que la historia continúe. Antes de investigar su ausencia, el operador necesita saber qué modelo contrató.

Los DOMAIN-ID son valores opacos. Todas las pasarelas que pertenecen al mismo dominio deben compartir el mismo valor y dos dominios de pasarela distintos deben usar valores diferentes. El protocolo no descubre ni impone esa asignación. Si dos dominios reciben por error la misma identidad, una ruta legítima puede parecer un bucle; si un solo dominio usa varias identidades, un retorno puede pasar inadvertido.

Cuatro preguntas, cuatro fuentes de autoridad

La primera pregunta es administrativa: ¿la asignación de DOMAIN-ID representa la topología que la organización cree operar? La respuesta proviene de inventarios, configuración revisada y comparación entre pasarelas, no del atributo recibido.

La segunda es de protocolo: ¿la actualización cruzó cada frontera con el D-PATH, el tipo de familia y los atributos de servicio previstos? Aquí sí mandan las capturas BGP, la telemetría de rutas y la comparación de los anuncios de entrada y salida. El carácter transitivo ayuda a conservar el atributo, pero no lo firma ni impide que una política lo cambie.

La tercera es de realización: ¿la ruta que ganó en la RIB produjo la entrada esperada en la FIB, con next-hop, etiqueta o VNI utilizables? La tabla BGP no responde a esa pregunta. Una ruta puede ser conocida y aun así perder la selección, no programarse o quedar asociada a una resolución incompleta.

La cuarta es de servicio: ¿el tráfico del inquilino llega y vuelve dentro del VRF y de las políticas correctas? Una sonda desde la infraestructura general puede dar un resultado optimista. La evidencia debe nacer en el mismo contexto de aislamiento, direccionamiento y retorno que usa el cliente.

La longitud es una preferencia, no una métrica física

En la selección de mejor ruta, RFC 10039 compara la longitud de D-PATH después de Local Preference. Con los factores previos empatados, se prefiere el camino con menos DOMAIN-ID. La ausencia del atributo equivale a longitud cero para esta comparación.

Ese orden resuelve una decisión de control. No dice que el camino sea más corto en kilómetros, menos congestionado o más seguro. Tampoco crea una prioridad superior a Local Preference. Una política local puede escoger conscientemente una secuencia más larga, y el estándar respetará esa decisión.

La consecuencia práctica es que un cambio de mejor ruta acompañado por un D-PATH menor puede ser correcto y, a la vez, empeorar la entrega. El análisis debe registrar la decisión y medir el resultado. Confundir ambas cosas transforma una heurística de bucles en una promesa de rendimiento que el RFC nunca hizo.

Cuando el atributo está mal formado

RFC 10039 se apoya en el tratamiento treat-as-withdraw para errores de formato. Esta elección contiene el daño de una actualización inválida, pero también puede convertir una incompatibilidad de software en una retirada visible del alcance. Durante una actualización, el contador de mensajes mal formados y las retiradas asociadas importa tanto como la mera capacidad anunciada para el código 36.

La compatibilidad declarada tampoco garantiza que todas las implementaciones serialicen, propaguen y comparen exactamente igual. Una adopción prudente comienza en una frontera limitada, captura rutas antes y después y mantiene una vía de reversión que no requiera reiniciar servicios ajenos.