MPLS LSP Multipath Trace

Introducción

MPLS LSP Ping es una herramienta básica que se utiliza para validar el estado del trayecto conmutado por etiquetas (LSP) entre entrada y salida.  Este documento tiene como objetivo explicar la interacción de la información de múltiples rutas entre el iniciador y el respondedor en el seguimiento del árbol LSP. Para conocer las opciones detalladas disponibles para esta herramienta, sería útil consultar este documento.

Antecedentes

Esta implementación de la función MPLS EM—MPLS LSP Multipath Tree Trace se basa en RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.

Al establecer la dirección de destino IP del paquete de sondeo como dirección de loopback (127.x.x.x), el seguimiento del árbol LSP se puede utilizar para detectar fallas en LSP evitando que el paquete obtenga IP enrutado. Por lo tanto, siempre que haya un problema de conectividad de extremo a extremo, es útil utilizar LSP Ping como el primer paso para eliminar cualquier falla de LSP.

En el caso de escenarios de múltiples rutas, el ping de LSP puede no siempre ayudar a identificar todos los fallos de LSP. Como se puede observar, cualquier router de switch de etiquetas (LSR) al recibir un paquete etiquetado que se puede enviar a través de múltiples interfaces de salida, utiliza ciertas claves del paquete y el algoritmo de entrada a hash para decidir la interfaz de salida. Según el proveedor, el hardware, etc., se puede considerar cualquiera de las siguientes opciones para el hash:

1. Pila de etiquetas entrantes sola.
2. Pila de etiquetas entrantes y detalles del encabezado IP (si la carga es IP).
3. Pila de etiquetas entrantes, encabezado IP y detalles del encabezado de transporte.

Normalmente, los routers de Cisco consideran una combinación de pila de etiquetas y encabezado IP si la pila tiene un tamaño inferior o igual a 3 (con IP como carga útil).

Suponga la siguiente topología.

R1-R7 son routers. En la topología anterior, hay 3 rutas de múltiples rutas de igual costo (ECMP) de R1 a R5, como se muestra a continuación.

RUTA1: R1-R2-R3-R4-R5

RUTA2: R1-R2-R6-R4-R5

RUTA3: R1-R2-R6-R7-R5

Supongamos que hay un problema entre R6 y R7 (como el protocolo de distribución de etiquetas roto (LDP) o la mala programación de etiquetas, etc.) que hace que se descarte el tráfico de R1 a R5 a través de PATH3. Si LSP Ping de R1 toma PATH1 o PATH2, puede terminar suponiendo que la trayectoria entre R1 y R5 está bien.

LSP Ping permite configurar la dirección IP de destino como cualquiera del rango 127.0.0.0/8. Aunque una opción simple es intentar enviar manualmente varios paquetes ping con direcciones de destino diferentes, no hay garantía de que se validen todas las trayectorias ECMP posibles. Necesita una forma de consultar y validar todas las rutas posibles entre el origen y el destino. El seguimiento de árbol de múltiples rutas de LSP aprovecha la "codificación de información de múltiples rutas" definida en la sección 3.3.1 de RFC4379 y le ayuda a validar todas las rutas de ECMP.

Seguimiento del árbol LSP - Cómo funciona

Un ping MPLS regular o traceroute puede indicar que no hay falla dependiendo de cómo los routers de tránsito comparten la carga de los paquetes sobre ECMP, sin embargo el seguimiento del árbol LSP proporciona un mejor método para validar que todas las trayectorias realmente están funcionando.  

En el seguimiento de árbol LSP, el router iniciador envía una solicitud de eco MPLS a cada salto estableciendo el TTL en la etiqueta superior de manera incremental (a partir del 1). La solicitud de eco transportará información de trayecto múltiple TLV que transporta un rango de direcciones IP (dentro del rango 127.0.0.0/8) o un rango de etiquetas de entropía. Actualmente, los dispositivos de Cisco admiten la opción de destino IP, por lo que nuestro ejemplo se detallará con el intervalo de direcciones IP.

Cada LSR de tránsito al recibir el paquete de solicitud responderá con todas las interfaces de salida ECMP y asociará un rango de direcciones IP (o etiquetas de entropía) de la solicitud para cada interfaz.

Rastreo del árbol LSP - Ejemplo detallado

Suponga la siguiente topología, por ejemplo, a continuación.

Para simplificar, este ejemplo utiliza el rango de direcciones de 127.0.0.0-127.0.0.200. Aquí están los detalles de los pasos de un seguimiento de árbol LSP.

1) El iniciador (R1) envía la solicitud de eco con los siguientes detalles:

• IP destination as 127.0.0.0
• Información de Trayectoria Múltiple TLV que lleva el rango de direcciones de 127.0.0.0 a 127.0.0.200.
• El TTL de la etiqueta superior se establecerá en 1.

2) R2 al recibir el mismo responderá con información de múltiples trayectorias para cada interfaz de salida. En este ejemplo, responderá de la siguiente manera:

• Si el destino IP está entre 127.0.0.0 y 127.0.0.100, el paquete se enviará a R3.
• Si el destino IP está entre 127.0.0.101 y 127.0.0.200, el paquete se enviará a R6.

3) R1 se da cuenta de que hay 2 trayectorias ECMP posibles y, por lo tanto, necesita enviar 2 solicitudes de eco con TTL configurado en 2. A partir de varias pruebas, se observó que el Iniciador siempre termina con 1 trayectoria antes de ir a la siguiente. (Pero esto puede ser cierto para una implementación específica).

4) R1 ahora envía la solicitud de eco con los siguientes detalles:

• IP destination as 127.0.0.0
• Información de Trayectoria Múltiple TLV que transporta el rango de direcciones como 127.0.0.0 a 127.0.0.100.
• El TTL de la etiqueta superior se establecerá en 2.

5) R2 reenviará el paquete a R3 (ya que la dirección de destino es 127.0.0.0). R3 al recibir el mismo responderá con la misma información de trayecto múltiple, ya que solo hay una interfaz de salida.

Lo mismo es válido hasta que alcanza R5.

6) Una vez que se completa el seguimiento de PATH1 (después de recibir la respuesta de la salida), el iniciador consultará ahora PATH2. Esto se realiza mediante el envío de la solicitud de eco con los siguientes detalles:

• IP destination as 127.0.0.101
• Información de Trayectoria Múltiple TLV que lleva el rango de direcciones de 127.0.0.101 a 127.0.0.200
• El TTL de la etiqueta superior establecido en 2.

7) R2 reenviará el paquete a R6 (ya que la dirección de destino es 127.0.0.101). R6 al recibir el mismo responderá con la información de trayecto múltiple como se muestra a continuación:

• Si el destino IP está entre 127.0.0.101 y 127.0.0.150, el paquete se enviará a R4.
• Si el destino IP está entre 127.0.0.151 y 127.0.0.200, el paquete se enviará a R7.

8) R1 se da cuenta de que hay una ruta ECMP más que hace que el total de rutas posibles sea 3. R1 continúa consultando PATH2 al enviar la siguiente solicitud de eco con los siguientes detalles:

• IP destination as 127.0.0.101
• Información de Trayectoria Múltiple TLV que lleva el rango de direcciones de 127.0.0.101 a 127.0.0.150
• El TTL de la etiqueta superior establecido en 3.

9) R2 reenviará el paquete a R6 (ya que el destino es 127.0.0.101) y R6 lo reenviará a R4 (ya que el destino es 127.0.0.101). R4 no tiene ninguna ruta de ECMP, por lo que responderá con la misma información de múltiples rutas. El siguiente paquete alcanzará la salida R5.

10) Dado que el seguimiento de PATH2 ha finalizado, R1 continuará la consulta de PATH3. Esto se realiza mediante el envío de la solicitud de eco con los siguientes detalles:

• IP destination as 127.0.0.151
• Información de Trayectoria Múltiple TLV que lleva el rango de direcciones de 127.0.0.151 a 127.0.0.200
• El TTL de la etiqueta superior establecido en 3.

11) R2 reenviará el paquete a R6, que a su vez lo reenviará a R7. R7 responderá con el mismo TLV de información de trayecto múltiple. El siguiente paquete alcanza el router de salida R5.

Una vez completados estos pasos, R1 tendrá los siguientes detalles:

                            

Al utilizar la dirección de destino dentro de 127.0.0.0 y 127.0.0.100, el reenvío de paquetes se verá influenciado sobre PATH1 mientras que el uso de la dirección de otros rangos influirá en el reenvío del paquete sobre las trayectorias respectivas.

12) Ahora el iniciador enviará 3 paquetes de solicitud de eco con TTL configurado en 255 y seleccionará la dirección de cada rango para que todas las trayectorias se validen de extremo a extremo.

El comando que se utilizará para el seguimiento de ECMP es traceroute mpls multipath ipv4 <prefix> <mask>. A continuación se muestra un ejemplo de salida.

R1#traceroute mpls multipath ipv4 10.1.5.5 255.255.255.255

Starting LSP Multipath Traceroute for 10.1.5.5/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
LLL!
Path 0 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.4
LL!
Path 1 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.2
L!
Path 2 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.0
Paths (found/broken/unexplored) (3/0/0)
Echo Request (sent/fail) (9/0)
Echo Reply (received/timeout) (9/0)
Total Time Elapsed 27 ms

Tenga en cuenta que el resultado anterior muestra que hay 3 trayectorias y que todas las trayectorias funcionan correctamente. Usando el botón de verbose en el comando anterior enumerará todos los saltos como a continuación:

R1#traceroute mpls multipath ipv4 10.1.5.5 255.255.255.255 verbose

Starting LSP Multipath Traceroute for 10.1.5.5/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
LLL!
Path 0 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.4
0 10.1.12.1 10.1.12.2 MRU 1500 [Labels: 22 Exp: 0] multipaths 0
L 1 10.1.12.2 10.1.23.3 MRU 1500 [Labels: 23 Exp: 0] ret code 8 multipaths 2
L 2 10.1.23.3 10.1.34.4 MRU 1500 [Labels: 22 Exp: 0] ret code 8 multipaths 1
L 3 10.1.34.4 10.1.45.5 MRU 1500 [Labels: implicit-null Exp: 0] ret code 8 multipaths 1
! 4 10.1.45.5, ret code 3 multipaths 0
LL!
Path 1 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.2
0 10.1.12.1 10.1.12.2 MRU 1500 [Labels: 22 Exp: 0] multipaths 0
L 1 10.1.12.2 10.1.26.6 MRU 1500 [Labels: 16 Exp: 0] ret code 8 multipaths 2
L 2 10.1.26.6 10.1.46.4 MRU 1500 [Labels: 22 Exp: 0] ret code 8 multipaths 2
L 3 10.1.46.4 10.1.45.5 MRU 1500 [Labels: implicit-null Exp: 0] ret code 8 multipaths 1
! 4 10.1.45.5, ret code 3 multipaths 0
L!
Path 2 found,
output interface Et0/0.12 nexthop 10.1.12.2
source 10.1.12.1 destination 127.0.0.0
0 10.1.12.1 10.1.12.2 MRU 1500 [Labels: 22 Exp: 0] multipaths 0
L 1 10.1.12.2 10.1.26.6 MRU 1500 [Labels: 16 Exp: 0] ret code 8 multipaths 2
L 2 10.1.26.6 10.1.67.7 MRU 1500 [Labels: 17 Exp: 0] ret code 8 multipaths 2
L 3 10.1.67.7 10.1.57.5 MRU 1500 [Labels: implicit-null Exp: 0] ret code 8 multipaths 1
! 4 10.1.57.5, ret code 3 multipaths 0
Paths (found/broken/unexplored) (3/0/0)
Echo Request (sent/fail) (9/0)
Echo Reply (received/timeout) (9/0)
Total Time Elapsed 29 ms