Seguimiento de Trayectoria Múltiple MPLS LSP

Introducción

MPLS LSP Ping es una herramienta básica que se utiliza para validar el estado de la ruta conmutada de etiquetas (LSP) entre el ingreso y la 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 obtener información detallada sobre las opciones 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 Failure.

Al establecer la dirección de destino IP del paquete de sonda 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, cada vez que hay 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 trayectorias, es posible que el ping LSP no siempre ayude a identificar todas las fallas LSP. Como se puede observar, cualquier router de switch de etiquetas (LSR) al recibir un paquete etiquetado que se puede enviar a varias interfaces de salida, utiliza ciertas claves del paquete y del algoritmo de entrada al hash para decidir la interfaz de salida. Según el proveedor, el hardware, etc., se puede considerar cualquiera de las siguientes opciones para el hashing:

1. Pila de etiquetas entrante sola.
2. Detalles de encabezado IP y pila de etiquetas entrantes (si la carga útil 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).

Asumir después de la topología.

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

PATH1: R1-R2-R3-R4-R5

PATH2: R1-R2-R6-R4-R5

PATH3: R1-R2-R6-R7-R5

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

LSP Ping permite establecer la dirección de destino IP como cualquier dirección del rango 127.0.0.0/8. Aunque una opción simple es intentar manualmente enviar varios paquetes ping con una dirección de destino diferente, no hay garantía de que se validen todas las trayectorias ECMP posibles. Necesita una manera de consultar y validar todas las trayectorias posibles entre el origen y el destino. El seguimiento del árbol de múltiples rutas 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 trayectorias ECMP.

Seguimiento de árbol LSP - Cómo funciona

Un ping MPLS o traceroute normal 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 están funcionando realmente.  

En el seguimiento del á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 de 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 rango de etiquetas de entropía. Actualmente, los dispositivos de Cisco admiten la opción IP destination, por lo que nuestro ejemplo se detallará con el rango 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 dirección IP (o etiqueta de entropía) de la solicitud para cada interfaz.

Seguimiento de árbol LSP - Ejemplo detallado

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

Para simplificar, este ejemplo utiliza un rango de direcciones de 127.0.0.0-127.0.0.200. Estos son los detalles de los pasos en un seguimiento de árbol LSP.

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

• IP destination como 127.0.0.0
• Información de trayecto 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 lo mismo responderá con Información de Trayectoria Múltiple para cada interfaz de egreso. En este ejemplo, responderá como se muestra a continuación:

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

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

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

• IP destination como 127.0.0.0
• Información de trayecto múltiple TLV que lleva el rango de direcciones de 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 la misma respuesta responderá con la misma información de trayecto múltiple, ya que sólo hay una interfaz de salida.

Lo mismo es cierto hasta que alcanza R5.

6) Una vez que se complete el seguimiento PATH1 (después de recibir la respuesta de egreso), Iniciador consultará ahora PATH2. Esto se realiza enviando la solicitud de eco con los detalles siguientes:

• IP destination como 127.0.0.101
• Información de trayecto 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 se establece en 2.

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

• Si el destino IP está dentro de 127.0.0.101 a 127.0.0.150, el paquete se enviará a R4.
• Si el destino IP se encuentra dentro de 127.0.0.151 a 127.0.0.200, el paquete se enviará a R7.

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

• IP destination como 127.0.0.101
• Información de trayecto 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 se establece 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 ECMP y, por lo tanto, responderá con la misma información de trayecto múltiple. El siguiente paquete alcanzará la salida R5.

10) Dado que el seguimiento PATH2 está completo, R1 continuará la consulta para PATH3. Esto se realiza enviando la solicitud de eco con los detalles siguientes:

• IP destination como 127.0.0.151
• Información de trayecto 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 se establece 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 egreso R5.

Después de completar 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á influido 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 sean validadas 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

Observe que el resultado anterior muestra que hay 3 trayectos y que todas las trayectorias funcionan bien. El uso del botón detallado en el comando anterior enumerará todos los saltos como se muestra 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