Sesión BGP activa, camino del cliente roto: MPLS sobre DMVPN

El peering lleva semanas activo, el número de prefijos parece correcto y, aun así, el tráfico de un cliente sigue tomando el camino largo o nunca llega. Se están juzgando dos cosas distintas con el mismo indicador. Una sesión BGP informa de que dos peers pueden intercambiar mensajes por una conexión TCP; no dice nada sobre si el overlay puede transportar un paquete etiquetado para ese cliente concreto.

Esa brecha se ve más fácilmente en un diseño MPLS sobre DMVPN, donde el camino por el hub y el camino directo por el spoke pueden comportarse de forma distinta por motivos que nada tienen que ver con el peering.

Qué demuestra realmente la sesión

BGP funciona sobre TCP, así que cada peer necesita una ruta hacia la dirección del otro extremo antes de que ocurra cualquier otra cosa. Si elige una loopback como ese extremo, ha creado un requisito de alcanzabilidad, no una garantía de reenvío. La sesión puede entonces mantenerse activa por una interfaz que el tráfico del cliente nunca usaría.

Anote cuatro hechos en ambos extremos antes de sacar conclusiones: la dirección de origen de la sesión, su dirección de destino, el contexto de encaminamiento en el que se sitúa y qué interfaz elegiría el núcleo o el router para ese par. Esos hechos describen el plano de control. Los paquetes del cliente añaden encima un VRF, una pila de etiquetas y un mapeo de overlay.

Cuatro mecanismos, no uno

La documentación de Cisco sobre MPLS sobre DMVPN separa las piezas con claridad. MP-BGP distribuye las etiquetas de overlay del cliente entre los dispositivos del borde del proveedor. MPLS usa esas etiquetas para seleccionar el contexto de reenvío de un paquete. NHRP mapea una dirección de overlay al extremo de transporte que necesita un túnel dinámico. IPsec protege el camino entre peers donde corresponde.

Cualquiera de los cuatro puede estar bien mientras otro está mal, y la combinación es lo que transporta el tráfico. Un intercambio de rutas puede completarse mientras falta la vinculación de etiqueta para un VRF, mientras el mapeo NHRP apunta a una dirección de transporte obsoleta o mientras el túnel existe pero ninguna política permite el paquete interno. Ninguna de esas condiciones tumba la sesión.

Compare el camino por el hub con el atajo, una variable cada vez

Fije el host de origen, el host de destino y el VRF, y después siga el mismo flujo dos veces. En el camino por el hub, anote el siguiente salto, la etiqueta de servicio que identifica el contexto del cliente remoto y el mapeo de overlay a transporte en uso. En el camino directo previsto, anote las mismas tres cosas. La diferencia entre las dos listas es el fallo, o su ausencia.

Mantenga el flujo constante durante la comparación. Cambiar el host de origen, el VRF o el destino entre observaciones produce dos historias sin relación, y es la forma más habitual de que este ejercicio salga mal.

Mantenga las pruebas de loopback en su propio compartimento

Un ping con origen en la loopback de un router es una prueba útil y ejercita un caso distinto del de un flujo desde un host. La dirección de origen pertenece al router, su contexto de encaminamiento puede ser global en lugar de un VRF, y el camino de respuesta puede diferir del que tomaría un prefijo de cliente. Así que la loopback que responde y la aplicación que funciona por el atajo son resultados separados, y solo el segundo describe al cliente.

Pruebe ambos y etiquételos por separado en sus notas. Cuando no coinciden, ha aprendido algo concreto sobre dónde diverge el diseño, y eso es más de lo que le dirá jamás una sola marca verde.

Las afirmaciones sobre versiones y sobre defectos necesitan su propia evidencia

Los informes de campo a veces recomiendan cambiar una máscara de host o una dirección de origen de BGP, y esos informes solo vale la pena leerlos junto al defecto sobre el que se escribieron y a las versiones afectadas. Una solución temporal de una versión no es una declaración de que la arquitectura no admita ningún prefijo /32.

Use documentación que coincida con su fase de DMVPN, plataforma y versión, y recuerde que un capítulo puede cubrir varias disposiciones, incluida FlexVPN. Un ejemplo de una disposición no se traslada en silencio a otra. Elija los extremos de sesión para el diseño del plano de control que realmente necesita y después verifique por separado el camino de reenvío del cliente, porque reescribir cada máscara de loopback no sustituye al averiguar qué tarea falló.