Ruta de Seguimiento en Red MPLS
Contenido
Introducción
Este documento describe el comportamiento del traceroute del protocolo de mensajes de control de Internet (ICMP) en la red MPLS (Multiprotocol Label Switching) y una comparación rápida con el seguimiento de LSP.
Antecedentes
En el entorno IP, cualquier nodo cuando recibe un paquete y si el Tiempo de vida (TTL) caduca, se espera que genere un mensaje de error ICMP "TTL Exceeded" (TTL excedido) (Tipo=11, Código=0) y que lo envíe a la dirección de origen del paquete. Este concepto se aprovecha para rastrear la trayectoria IP de origen a destino mediante el envío de paquetes UDP con TTL secuencialmente a partir de 1. Cabe señalar que los requisitos básicos para esta funcionalidad son:
- La dirección de origen del paquete es accesible desde los nodos de tránsito
- El ICMP no se filtra a lo largo de la trayectoria
En el entorno MPLS, es posible que un LSR del proveedor de tránsito no siempre tenga disponibilidad para la dirección de origen y necesite alguna mejora para el manejo de ICMP en el dominio MPLS.
Traceroute ICMP en la Red MPLS
El comportamiento predeterminado de cualquier LSR al recibir un paquete con TTL=1 en la etiqueta superior sigue el comportamiento IP tradicional de descartar el paquete y activar el mensaje de error ICMP. Para rutear el mensaje ICMP al origen, el LSR realizará lo siguiente:
- Almacenar en búfer la pila de etiquetas del paquete entrante (el paquete recibido con TTL=1)
- Generar mensaje de error ICMP con el origen como su propia dirección y destino como dirección de origen del paquete recibido.
- Añada todas las etiquetas de la parte inferior de la pila de etiquetas (que se almacenó en la memoria intermedia anteriormente en el paso 1) con TTL=255 excepto la superior.
- Obtenga la etiqueta superior de la pila de etiquetas guardadas en búfer y realice una búsqueda local de LFIB para que la etiqueta se intercambie y el siguiente salto asociado.
- Añada la nueva etiqueta a la parte superior de la pila con TTL=255 y envíela.
Con este enfoque, el mensaje de error ICMP pasa del LSR de tránsito al LER de salida y luego de regreso al LER de ingreso al origen real.
Seguimiento ICMP desencadenado de PE a PE remoto
Este es un ejemplo simple que explica el comportamiento cuando se activa el seguimiento ICMP de PE a PE remoto dentro del mismo dominio MPLS:
En esta topología, cuando el traceroute ICMP se activa de R2 a 10.1.4.4, el primer paquete se envía con TTL de 1. R3 al recibir el paquete disminuirá el TTL a 0 y activará el mecanismo de generación ICMP.
R3 almacenará en búfer la pila de etiquetas y generará el mensaje de error ICMP e incluirá la pila de etiquetas entrantes del búfer en la carga útil ICMP. Además, rellena el encabezado IP con la dirección de origen de la interfaz entrante del paquete etiquetado, la dirección de destino como el origen del paquete etiquetado. El TTL está configurado en 255. Ahora coloca la pila de etiquetas del búfer y consulta la tabla LFIB para reenviar la acción en la etiqueta superior. En esta topología, la pila de etiquetas recibida es 17. Al realizar una búsqueda en la tabla LFIB, la etiqueta 17 se intercambia con la etiqueta 16 y se reenvía hacia la siguiente dirección R6. R6, a su vez, mostrará la etiqueta superior y reenviará a R4, que enviará el paquete de nuevo hacia R2.
Como se puede observar en la salida de traceroute en R2, la etiqueta entrante será enumerada por cada salto a lo largo de la trayectoria.
Seguimiento ICMP desencadenado de CE a CE remoto
Este es un ejemplo simple que explica el comportamiento cuando se activa el seguimiento ICMP de CE a CE remoto sobre dominio MPLS:
En esta topología, cuando se activa el traceroute ICMP de R1 (CE) a 192.168.5.5 (CE remoto), el primer paquete se envía con TTL de 1. Este es un paquete IP normal y entonces R2 sigue el comportamiento tradicional de generar ICMP y enviar directamente a R1. El segundo paquete enviado con TTL=2 caducará en R3.
R3 almacenará en búfer la pila de etiquetas y generará el mensaje de error ICMP e incluirá la pila de etiquetas entrantes del búfer en la carga útil ICMP. Además, rellena el encabezado IP con la dirección de origen de la interfaz entrante del paquete etiquetado, la dirección de destino como el origen del paquete etiquetado. El TTL está configurado en 255. Ahora coloca la pila de etiquetas del búfer y consulta la tabla LFIB para reenviar la acción en la etiqueta superior. En la topología anterior, la pila de etiquetas recibida es {17, 18}. Al realizar una búsqueda en la tabla LFIB para la etiqueta superior, 17 se intercambiará con la etiqueta 16 y se reenviará hacia la siguiente dirección R6. R6 a su vez mostrará la etiqueta superior y reenviará a R4. R4 utilizará la etiqueta VRF para identificar el VRF y reenviar el paquete hacia R1.
Como se puede observar en el resultado del traceroute en R1, la pila de etiquetas entrante es enumerada por cada salto a lo largo del trayecto.
MPLS LSP Traceroute en Red MPLS
A diferencia del traceroute basado en ICMP, LSP traceroute utiliza la maquinaria definida en RFC4379. Utiliza la encapsulación IP/UDP con la dirección de destino de la solicitud establecida en la dirección de loopback (rango 127.0.0.0/8). Se espera que el Ping LSP se active dentro del mismo dominio MPLS y por lo tanto la respuesta se enviará directamente al Iniciador.
Cuando se activa LSP traceroute ("traceroute mpls ipv4 <FEC>") desde cualquier LSR, los detalles sobre la FEC que se validará se incluirán en un TLV como "Pila FEC de Destino" en la Solicitud de Eco MPLS. Este mensaje se enviará con TTL en la pila de etiquetas secuencialmente a partir de 1. Cualquier LSR de tránsito al recibir el paquete y si el TTL caduca procesará el paquete IP, ya que la dirección de destino es la dirección de loopback. e ingrese a la CPU para el procesamiento de MPLS OAM.
Responder realizará opcionalmente la validación de FEC obteniendo las etiquetas de la pila de etiquetas de la solicitud de eco MPLS recibida y los detalles de FEC de TLV de la pila FEC de destino para validar lo mismo con la información del plano de control local. En caso de seguimiento, Responder incluirá la información de flujo descendente como la etiqueta saliente y la dirección de vecino descendente, etc. en un TLV como TLV de asignación descendente (DSMAP). (DDMAP desaprobará DSMAP porque es más flexible que DSMAP).
Seguimiento LSP desencadenado de PE a PE remoto
En esta topología, el seguimiento LSP se activa desde R2 para validar el LSP al prefijo 10.1.4.4/32. El TTL de la etiqueta se establecerá en 1. R3 al recibirlo ingresará a la CPU para el procesamiento de OAM.
R3 responderá a R2 con MPLS Echo Reply con DSMAP TLV que lleva la etiqueta de salida 16 e información adicional como detalles de vecinos descendentes. A diferencia de los mensajes ICMP, MPLS Echo Reply se reenviará directamente del respondedor R3 al iniciador R2.
Como se pudo observar en la salida de traceroute LSP en R2, la pila de etiquetas saliente será enumerada por cada salto a lo largo de la trayectoria. Esto es diferente del traceroute basado en ICMP donde la etiqueta enumerada en el resultado será pila de etiquetas entrante.
Seguimiento LSP desencadenado de CE a CE remoto
Esto se aplica en escenarios como CSC donde MPLS se habilita entre PE-CE. Hay 2 retos en la ejecución del seguimiento LSP desde CE al dominio CE remoto sobre MPLS de operador como se muestra a continuación:
- La respuesta de eco LSP se enviará directamente al iniciador. Por lo tanto, el respondedor DEBE tener disponibilidad para el iniciador. En la topología anterior, R3 puede no tener alcance a R1 como lo es en el VRF.
- Para cada etiqueta de la pila de etiquetas, se deben incluir los detalles FEC relevantes en la pila FEC objetivo para la validación. La FEC incluida por el iniciador será 1 mientras que PE presionará 2 etiquetas. En la topología anterior, R1 envía la solicitud de eco MPLS con FEC={192.168.5.5/32} e incluye la etiqueta 28 en la pila. Dado que R2 intercambia la etiqueta 28 con {17, 27}, R3 recibirá la solicitud con 2 etiquetas en la pila mientras que 1 FEC en TLV confunde la validación FEC.
RFC6424 define el concepto de "TLV de cambio de pila FEC" para abordar el problema 2. Este TLV se incluirá en la respuesta con FEC relevante como PUSH/POP que el iniciador puede incluir en la solicitud de eco posterior.
draft-ietf-mpls-lsp-ping-relay-reply define el concepto de transporte de la pila de direcciones de nodo de relé en TLV que puede utilizar Responder para retransmitir la respuesta aunque no tenga alcance con el iniciador.
Estos 2 problemas no son soportados actualmente en Cisco IOS® y por lo tanto el seguimiento LSP de CE a CE remoto sólo enumerará el PE de ingreso y el CE remoto. Esto se incluye sólo para que esté completo.
Comentarios