¿El laboratorio MPLS L3VPN no hace ping? Revise estos cinco saltos

Dos routers de cliente, un par de cajas provider edge y un ping que muere sin mensaje de error. En un laboratorio MPLS L3VPN pequeño, el fallo casi siempre se sienta en uno de los cinco puntos de control, y cada uno tiene un comando que muestra si la dependencia funciona o si falta. El error es reiniciar BGP cada vez que falla el ping en lugar de probar las dependencias en orden. Si salta directamente a la configuración de VRF, puede pasar una hora en un problema que empezó con un siguiente salto sin resolver dos equipos más allá.

Trabaje la lista de abajo hacia arriba. Un punto de control que pasa queda aprobado, y el primer fallo es el que merece la pena depurar.

Punto de control uno: los PE se alcanzan entre sí

Cada PE necesita una ruta hacia el loopback del otro PE, y esa ruta debe resolverse a través de algo real. Un interior gateway protocol es la vía habitual, pero una ruta estática también sirve siempre que la búsqueda recursiva acabe en una adjacency viva. En equipos de estilo IOS, show ip route 10.0.0.2 seguido de show ip cef 10.0.0.2 indica si el prefijo existe y si hay una adjacency resuelta detrás. Una ruta en la tabla sin adjacency detrás no es alcanzabilidad.

Compruebe ambos sentidos. Costes IGP asimétricos, una passive interface en el lado equivocado o una distribute list que filtra el loopback rompen cada uno solo un sentido, y un sentido basta para matar la sesión. Si los loopbacks responden al ping pero la sesión BGP se queda en Active, mire la update source antes de tocar nada más.

Punto de control dos: existe un camino de etiquetas

Una ruta IP hacia el loopback remoto no demuestra que el transporte vaya a poner una etiqueta. En un diseño LDP, confirme que el loopback remoto tiene una binding local y una remota, y que la etiqueta saliente aparece en la tabla de forwarding. show mpls ldp bindings 10.0.0.2 32 muestra los pares de etiquetas, y show mpls forwarding-table 10.0.0.2 muestra lo que la line card pondrá realmente. Cuando el segundo comando no muestra ninguna etiqueta o recae en IP, el transporte no lleva el tráfico VPN como supone el diseño.

La distinción viene de cómo MPLS separa el estado de forwarding de los prefijos de destino, el modelo que se describe en la RFC 3031. Si su laboratorio usa RSVP-TE o etiquetas adyacentes a BGP en lugar de LDP, compruebe el estado propio de ese mecanismo; suponer que LDP distribuye cada etiqueta de la capa inferior es una forma habitual de perseguir un fallo fantasma. Un camino de etiquetas roto suele aparecer más tarde como una ruta VPN presente pero inutilizable.

Punto de control tres: la ruta VPN llegó intacta

Mire la ruta VPNv4 o VPNv6 del prefijo de cliente exacto, no el resumen de sesión. show bgp vpnv4 unicast all 10.10.1.0/24 debería mostrar el route distinguisher, el next hop ajustado al loopback del PE remoto y una etiqueta. Si falta el prefijo, la política de exportación en el PE de origen o la política de importación en el PE receptor es el primer sospechoso, y las route targets son el culpable habitual.

Lea la comprobación de route target por separado de la recepción BGP. Una ruta puede llegar con el next hop correcto y no aterrizar en la VRF porque el import target no coincide. En el PE receptor, show ip route vrf CUSTOMER 10.10.1.0 es la prueba que importa; la tabla BGP solo demuestra que la ruta cruzó el plano de control.

Punto de control cuatro: la interfaz está en la VRF

Una definición de VRF con un route distinguisher y route targets no mueve ninguna interfaz dentro. La interfaz del lado CE necesita la asignación de VRF, y show ip vrf interfaces o show ip interface brief debería listarla bajo la instancia correcta. Este es el punto de control donde una configuración copiada falla más a menudo, porque el bloque VRF parece completo mientras la interfaz sigue en la tabla global.

Después confirme que el PE ha aprendido el prefijo de cliente local en esa VRF, y que el CE tiene una ruta de vuelta por el enlace. Una default estática en el CE apuntando al PE basta para un laboratorio, siempre que la VRF del PE tenga una ruta hacia la LAN del CE. Si falta cualquiera de las dos mitades, el ping falla antes de que se ponga ninguna etiqueta.

Punto de control cinco: la respuesta encuentra el camino a casa

Rastree el paquete de ida y luego el de vuelta, porque usan tablas distintas. En el PE de entrada, el origen del cliente debe resolverse dentro de la VRF hacia el prefijo remoto con la etiqueta remota. En el PE de salida, el destino debe resolverse dentro de la misma VRF hacia la interfaz del lado CE. Un ping lanzado desde el propio PE no es prueba: puede salir por la tabla global o por otra dirección de origen, y por eso ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 es la prueba que hay que ejecutar.

Los cortafuegos de los hosts, el reverse-path filtering y las listas de acceso del CE siguen aplicándose. Si el camino de ida funciona y la respuesta muere, el problema es una ruta o un filtro en el lado de vuelta, no el transporte MPLS.

Mantenga una línea por punto de control con la primera dependencia que falló. Esa línea convierte la queja de que el cliente no puede hacer ping en una pregunta concreta sobre alcanzabilidad, estado de etiquetas, importación de rutas, pertenencia de interfaz o camino de vuelta, y evita que la siguiente sesión de depuración repita los mismos cinco comandos en el mismo orden.