Troubleshooting de Make-Before-Break (MBB) para mLDP

Introducción

Este documento describe el comportamiento de Make-Before-Break (MBB) en Cisco IOS^® XR.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

• Este documento es específico de Cisco IOS^® XR, pero no se limita a una versión de software o hardware específicos.
• Todos los dispositivos utilizados en este artículo ejecutan Cisco IOS XR 6.5.2. Todas las tarjetas de línea son de tercera o cuarta generación ASR9k.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Make-Before-Break (MBB) tiene un propósito: configurar un nuevo árbol mLDP (Multipoint Label Distribution Protocol) antes de derribar el antiguo árbol y conmutar el tráfico del antiguo al nuevo sin perder tráfico de multidifusión. Esto se puede utilizar en dos situaciones:

1. Cuando el re-ruteo ocurre cuando una nueva trayectoria vuelve a estar disponible con una mejor métrica IGP (Interior Gateway Protocol): cambie el tráfico del antiguo al nuevo árbol y luego elimine el antiguo.
2. Cuando el tráfico multicast está protegido en una trayectoria de respaldo: cambie el tráfico de la trayectoria de respaldo al árbol mLDP nativo recién señalado y luego elimine el árbol de respaldo.

Si el router sabe que el LSP antiguo (trayecto conmutado por etiquetas) está dañado, no debe esperar para comenzar a usar el nuevo LSP. Esperar no tiene sentido aquí, ya que ya no llega tráfico al viejo árbol. Si el árbol antiguo sigue funcionando, el router no debe derribar el árbol antiguo hasta que el nuevo esté completamente configurado.

Teoría

MBB se controla mediante un mecanismo Query and Ack, como se describe en RFC 6388. Este es el RFC base de mLDP. Este mecanismo de consulta y confirmación indica que el nuevo árbol está listo para reenviar el tráfico de multidifusión. De esta manera, no debe haber ninguna pérdida de paquetes. Si el router sabe que el LSP antiguo está dañado, no debe esperar para comenzar a usar el nuevo LSP. Esperar no tiene sentido aquí, ya que ya no llega tráfico al viejo árbol. Si el árbol antiguo sigue funcionando, el router no debe derribar el árbol antiguo hasta que el nuevo esté completamente configurado.

Los casos en los que MBB puede ayudar son:

• El árbol existente está siendo re-enrutado debido a un cambio en la topología, un evento de link activo o una reducción en el costo IGP de un link ocurre,
• Volver a un árbol mLDP nativo, después de recibir el tráfico multicast en un túnel TE/LFA (Alternativo sin Loop) protegido activamente, o en una trayectoria Ti-LFA (LFA independiente de la topología).

Observe que estos dos representan buenos eventos.  Un ejemplo de un evento incorrecto sería un link conectado directamente que se desconecta en un router en la trayectoria ascendente. MBB no puede ayudar en este caso. En este caso, se necesita IP FRR (Fast ReRoute).
Cuando se produce MBB, hay temporalmente más de un vecino ascendente y/o más de un vecino descendente.  En RFC 6388, se especifica que puede haber varios elementos de aceptación. Esto significa que puede haber varios vecinos ascendentes y valores de etiquetas ascendentes por árbol. Un "elemento de aceptación" significa que el vecino mLDP ascendente es candidato para aceptar tráfico en. Un elemento aceptante es el elemento activo. El elemento activo es aquél para el que la etiqueta MPLS está instalada en el plano de reenvío. El otro elemento aceptante es el elemento inactivo. Este elemento es aquél para el cual la etiqueta MPLS aún no está instalada en el plano de reenvío. Este elemento inactivo es el de la parte recién señalada del árbol con el mecanismo de consulta/confirmación y debe tener una vida corta, antes de pasar a convertirse en el elemento de aceptación activo. Sólo puede haber dos elementos aceptados por árbol: uno es el activo y el otro es el inactivo. Tan pronto como la señalización Query/Ack finaliza o se alcanza un retraso de tiempo fijo, los vecinos antiguos se eliminan del árbol.
En lugar del mecanismo Query/Ack, la otra opción de implementación podría ser simplemente retrasar el switchover al nuevo LSP por un retraso configurable fijo.

Es importante tener en cuenta que mLDP comparte el espacio de etiquetas asignado de flujo descendente que utiliza unicast y, por lo tanto, para el plano de reenvío MPLS no existe, en esencia, ninguna diferencia entre los paquetes multicast o los paquetes unicast. Dado que el plano de reenvío se comparte con la unidifusión, algunas funciones de unidifusión se heredan para la multidifusión, como FRR IP.

Los procedimientos MBB se aplican a árboles P2MP (punto a multipunto) y MP2MP (multipunto a multipunto).

Mecanismo de consulta y confirmación MBB

MBB es opcional (también es opcional en RFC), por lo que debe configurarse para que se active. Cuando se configura, puede haber un estado MBB adjunto al mensaje de asignación de etiquetas enviado en sentido ascendente y también puede adjuntarse a un mensaje de notificación LDP enviado por un router ascendente al router descendente. Un router puede adjuntar un estado MBB en un TLV de estado MP LDP.

 El MBB Status es un tipo del LDP MP Status Value Element:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MBB Type = 1  |      Length = 1               | Status Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

El código de estado es 1 para una solicitud MBB y 2 para una devolución MBB.

El LDP MP Status TLV está codificado de la siguiente manera:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| LDP MP Status Type(0x096F)|            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Value                               |
      ~                                                               ~
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

El campo Valor contiene uno o más elementos LDP MP Status Value.
El elemento de valor de estado MP LDP que se incluye en el valor TLV de estado MP LDP tiene la siguiente codificación:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type          | Length                        | Value ...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      ~                                                               ~
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

El TLV de estado MP de LDP puede aparecer en un mensaje de asignación de etiquetas o en un mensaje de notificación de LDP.

En un Mensaje de Notificación LDP:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Notification (0x0001)     |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Message ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Status TLV                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   LDP MP Status TLV                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Optional LDP MP FEC TLV                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Optional Label TLV                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

En un mensaje de asignación de etiquetas:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Mapping (0x0400)    |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label TLV                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional LDP MP Status TLV                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Additional Optional Parameters            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La anterior describe el comportamiento dinámico de MBB. Otra opción es tener un comportamiento estático donde el switchover al nuevo árbol está determinado solamente por un retraso. En este caso, el switchover ocurre una cierta cantidad de (mili)segundos después de que el nuevo árbol esté listo.

La imagen 1 muestra una captura en Wireshark del mensaje de asignación de etiquetas mLDP. Hay un LDP MP Status TLV adjunto.

Imagen 1

01000102 decodifica a 1 para MBB tipo 1, 0001 para longitud 1 y 02 para MBB ack.

Observe que el mecanismo MBB se aplica a P2MP mLDP FEC (Clase de Equivalencia de Reenvío) y a MP2MP FECs de Flujo Ascendente o Descendente.

Capacidad MBB

Un router capaz de realizar MBB, anuncia esto en un anuncio de capacidad MBB en la sesión LDP a sus vecinos.

RP/0/RSP1/CPU0:R2#show mpls mldp neighbors
MLDP peer ID      : 10.79.196.14:0, uptime 22:32:06 Up,
  Capabilities     : Typed Wildcard FEC, P2MP, MP2MP, MBB
  Target Adj       : No
  Upstream count   : 0
  Branch count     : 0
  Label map timer  : never
  Policy filter in :
  Path count       : 1
  Path(s)          : 10.159.248.201    Bundle-Ether120 No LDP
  Adj list         : 10.254.3.36      Bundle-Ether10362
  Peer addr list   : 10.79.196.14
                   : 10.55.55.1
                   : 10.196.91.134
                   : 10.200.30.1

MBB no está habilitado de forma predeterminada para Cisco IOS XR.

El comando "make-before-break" habilita la función y el anuncio de la capacidad.

mpls ldp
 mldp
 logging notifications
 address-family ipv4
 make-before-break delay 0

El MBB no tiene un retraso de forma predeterminada. Sólo en una configuración a escala, el retraso debe aumentarse. La razón es que con muchas entradas de la base de datos mLDP puede haber muchas entradas de reenvío mLDP que necesitan ser instaladas. El tiempo para instalar estas entradas de reenvío en el plano de datos de las tarjetas de línea puede tardar algún tiempo.

Retraso de MBB

Mira la imagen 2.

Imagen 2

Ahí está el árbol viejo y el árbol recién señalado. El router en el que se bifurcan los dos árboles es el punto de reparación local (PLR). El router en el que se vuelven a fusionar los dos árboles es el punto de fusión (MP). La nueva parte del árbol mLDP se señala debido a que los routers descubren una mejor trayectoria. O bien, el nuevo link R4 - R2 estuvo disponible, o la métrica IGP en ese link se redujo para producir un trayecto con una métrica general más baja.

Puede configurar dos valores de retraso para MBB. La primera es el retraso cuando MBB se utiliza para que el switch MP vuelva a una trayectoria nativa. Este es el tiempo después de que se reciba la confirmación de MBB.

RP/0/RP1/CPU0:Router(config-ldp-mldp-af)#make-before-break delay ?
 <0-600> Forwarding delay in seconds

Una demora de cero significa que la trayectoria recién señalada se utiliza inmediatamente después de que se reciba la confirmación MBB en el router, donde la trayectoria anterior y la nueva son diversas, el PLR. El segundo es el retraso para la eliminación de la trayectoria de respaldo después de que el MP haya cambiado a la trayectoria nativa. 

RP/0/RP1/CPU0:Router(config-ldp-mldp-af)#make-before-break delay 10 ?
 <0-60> Delete delay in seconds
 <cr> 

RP/0/RP1/CPU0:Router(config-ldp-mldp-af)#make-before-break delay 10 10 ?
 <cr>

Tanto la demora de switchover como la demora de eliminación se utilizan en el MP.

MBB para redireccionamiento

MBB se encarga de configurar un nuevo árbol mLDP antes de que el antiguo sea eliminado. Esto solo tiene sentido si el árbol antiguo aún está presente y reenviando tráfico. Una convergencia IGP, como un evento link up, puede producir una mejor trayectoria para el árbol mLDP. Esto significa una métrica IGP más pequeña hacia la raíz, o hacia la hoja si es un árbol mLDP MP2MP.

Mira un ejemplo.

La imagen 3 muestra una red antes del evento de convergencia de ruteo.

Imagen 3

R5 es el router raíz de un árbol mLDP y R6 es el router de hoja. Un árbol mLDP P2MP se señala con un mensaje de Label Mapping (incluida una etiqueta MPLS), desde cada router hacia la raíz. Este mensaje de asignación de etiquetas LDP no lleva una solicitud MBB.

El tráfico mLDP va de izquierda (raíz) a derecha (hoja) sobre la trayectoria superior. En cada link, la etiqueta MPLS indicada se encuentra en la parte superior del paquete de multidifusión.

La imagen 4 muestra la red después del evento de convergencia de routing (sin MBB).

Imagen 4

El link R4 - R2 ya está activo. La métrica de este link es de un valor bajo de modo que la trayectoria inferior tiene una métrica inferior que la trayectoria superior. Hay dos cosas que deben suceder: la adyacencia IGP debe establecerse sobre el link y la sesión LDP también debe establecerse sobre este nuevo link. Una vez que esta sesión LDP está activa, el mensaje de Asignación de Etiquetas se intercambia sobre este link para mover el árbol mLDP de arriba abajo.

Si el MBB no está configurado, entonces hay una señalización regular con mensajes de LDP Label Mapping en la trayectoria inferior. Tan pronto como el mensaje de Asignación de etiquetas (sin una Solicitud MBB) llega a R1, R1 deja de reenviar el tráfico multicast en la trayectoria superior y comienza a reenviar el tráfico multicast en la trayectoria inferior.

Al final, R1 nunca reenvió el tráfico multicast a través de las dos trayectorias, sino solamente a través de una: conmutó el tráfico de la trayectoria superior a la inferior. El switchover es inmediato, lo que podría conducir a un corto período de tráfico multicast descartado debido al hecho de que la señalización del plano de control de R2 a R1 sobre R4 podría ser un poco más rápida que el tiempo necesario para que las entradas mLDP se instalen en el plano de datos en los routers en la nueva trayectoria.

Hay una notificación de registro mLDP habilitada explícitamente.

RP/0/0/CPU0:Jan  1 16:06:49.778 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Add LDP 10.0.0.4:0 branch remote label 24009

RP/0/0/CPU0:Jan  1 16:06:49.838 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_DELETE : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Delete LDP 10.0.0.3:0 branch remote label 24009

Si MBB está configurado, tenemos lo siguiente.

Tenga en cuenta que no es suficiente configurar solamente el MBB en R1.

Este es un ejemplo de configuración en R2:

mpls ldp
 mldp
  logging notifications
  address-family ipv4
   make-before-break delay 60
  !

Desearía que R2 retrase el switchover de la ruta antigua a la nueva con 60 segundos cuando la sesión LDP a través del link R4-R2 esté activa. Eso no sucede. Debe tener MBB habilitado en cada router (o al menos R1, R4 y R2) para que la señalización MBB funcione entre R2 y R1 en R4.

Necesita tener esta configuración mínima en cada router para tener habilitada la señalización MBB.

mpls ldp
 mldp
  logging notifications
  address-family ipv4
   make-before-break delay 0
  !

Mira la imagen 5.

Imagen 5

Toda la configuración correcta está en su lugar. Miramos los eventos desde el principio, así que la situación antes del evento de convergencia.

La ruta superior activa es el inicio. En R1, R3 es el único cliente descendente.

RP/0/0/CPU0:R1#show mpls mldp database
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 00:19:43
  FEC Root           : 10.0.0.5
  Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]
  Features           : MBB
  Upstream neighbor(s) :
    10.0.0.5:0 [Active] [MBB] Uptime: 00:19:43
      Local Label (D) : 24008
  Downstream  client(s):
    LDP 10.0.0.3:0     Uptime: 00:03:28
      Next Hop         : 10.1.3.3
      Interface        : GigabitEthernet0/0/0/0
      Remote label (D) : 24009

RP/0/0/CPU0:R1#show mpls mldp forwarding
mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None
   24009, NH: 10.1.3.3, Intf: GigabitEthernet0/0/0/0 Role: M

En R2, R3 es el único elemento aceptante.

RP/0/0/CPU0:R2#show mpls mldp database
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 00:23:58
  FEC Root           : 10.0.0.5
  Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]
  Features           : MBB
  Upstream neighbor(s) :
    10.0.0.3:0 [Active] [MBB] Uptime: 00:03:19
      Local Label (D) : 24008
  Downstream  client(s):
    LDP 10.0.0.6:0     Uptime: 00:23:58
      Next Hop         : 10.2.6.6
      Interface        : GigabitEthernet0/0/0/2
      Remote label (D) : 24010

RP/0/0/CPU0:R2#show mpls mldp forwarding
mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None
   24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

Después de la señalización MBB, R2 tiene dos elementos aceptadores, uno activo y otro inactivo.

Jan  1 16:52:43.700 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Add LDP 10.0.0.4:0 branch remote label 240

 R1 tiene dos clientes descendentes, R3 y R4:

RP/0/0/CPU0:R1#show mpls mldp database
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 00:22:35
  FEC Root           : 10.0.0.5
  Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]
  Features           : MBB
  Upstream neighbor(s) :
    10.0.0.5:0 [Active] [MBB] Uptime: 00:22:35
      Local Label (D) : 24008
  Downstream  client(s):
    LDP 10.0.0.3:0     Uptime: 00:06:20
      Next Hop         : 10.1.3.3
      Interface        : GigabitEthernet0/0/0/0
      Remote label (D) : 24009
    LDP 10.0.0.4:0     Uptime: 00:00:36
      Next Hop         : 10.1.4.4
      Interface        : GigabitEthernet0/0/0/1
      Remote label (D) : 24009

R1 está reenviando por ambas trayectorias:

RP/0/0/CPU0:R1#show mpls mldp forwarding
mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None
   24009, NH: 10.1.3.3, Intf: GigabitEthernet0/0/0/0 Role: M
   24009, NH: 10.1.4.4, Intf: GigabitEthernet0/0/0/1 Role: M

R2 ahora tiene dos vecinos ascendentes, uno activo (R3) y otro inactivo (R4). Esta fase dura 60 segundos, el tiempo de retraso de reenvío.

RP/0/0/CPU0:R2#show mpls mldp database
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 00:27:00
  FEC Root           : 10.0.0.5
  Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]
  MBB nbr evaluate   : 00:00:21
  Features           : MBB
  Upstream neighbor(s) :
    10.0.0.4:0 [Inactive] [MBB] Uptime: 00:00:38
      Local Label (D) : 24009
    10.0.0.3:0 [Active] [Delete] [MBB] Uptime: 00:06:22
      Local Label (D) : 24008
  Downstream  client(s):
    LDP 10.0.0.6:0     Uptime: 00:27:00
      Next Hop         : 10.2.6.6
      Interface        : GigabitEthernet0/0/0/2
      Remote label (D) : 24010

RP/0/0/CPU0:R2#show mpls mldp forwarding
mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None
   24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

24009  LSM-ID: 0x00001 flags: ED
   24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

Observe que la etiqueta local para cada árbol mLDP es diferente. Por lo tanto, R2 no tiene ningún problema para diferenciar el tráfico mLDP entrante e identificar qué paquete mLDP entrante pertenece a qué árbol mLDP. R2 sólo reenvía el tráfico de un árbol a la vez. El indicador ED significa 'Abandono de salida' e indica que los paquetes que llegan con la etiqueta 24009 se descartan. Estos son los paquetes en el árbol para los cuales el elemento de aceptación está inactivo. ¡No hay tráfico duplicado llegando a los receptores!

Observe que la etiqueta de salida para cada árbol mLDP en R2 es la misma. Por lo tanto, para R6, un router de flujo descendente de R2, no puede distinguir si el tráfico llegó a través de la trayectoria original antigua (superior) o la nueva trayectoria (inferior) después del rerouting.

Después de 60 segundos, R2 deja de reenviar el tráfico desde la ruta superior e inicia el tráfico desde la ruta inferior.

RP/0/0/CPU0:R1 Jan  1 16:53:44.236 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_DELETE : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Delete LDP 10.0.0.3:0 branch remote label 24009

R1 solo tiene un cliente descendente, R4.

RP/0/0/CPU0:R1#show mpls mldp database
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 00:25:21
  FEC Root           : 10.0.0.5
  Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]
  Features           : MBB
  Upstream neighbor(s) :
    10.0.0.5:0 [Active] [MBB] Uptime: 00:25:21
      Local Label (D) : 24008
  Downstream  client(s):
    LDP 10.0.0.4:0     Uptime: 00:03:22
      Next Hop         : 10.1.4.4
      Interface        : GigabitEthernet0/0/0/1
      Remote label (D) : 24009

RP/0/0/CPU0:R1#show mpls mldp forwarding
mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None
   24009, NH: 10.1.4.4, Intf: GigabitEthernet0/0/0/1 Role: M

R2 sólo tiene un vecino ascendente:

RP/0/0/CPU0:R2#show mpls mldp database
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 00:29:54
  FEC Root           : 10.0.0.5
  Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]
  Features           : MBB
  Upstream neighbor(s) :
    10.0.0.4:0 [Active] [MBB] Uptime: 00:03:31
      Local Label (D) : 24009
  Downstream  client(s):
    LDP 10.0.0.6:0     Uptime: 00:29:54
      Next Hop         : 10.2.6.6
      Interface        : GigabitEthernet0/0/0/2
      Remote label (D) : 24010

RP/0/0/CPU0:R2#show mpls mldp forwarding
mLDP MPLS forwarding database

24009  LSM-ID: 0x00001 flags: None
   24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

El seguimiento mLDP en R2 muestra que se utilizó la señalización MBB, que hubo un retraso de 60 segundos antes de cambiar de la ruta antigua a la nueva y un retraso posterior de 0 segundos para eliminar la ruta antigua. Después de esto, R2 envía un mensaje de Retiro de Etiqueta a R3 para la trayectoria anterior y recibe un mensaje de Liberación de Etiqueta de R3 como respuesta.

RP/0/0/CPU0:R2#show mpls mldp trace

Jan  1 16:52:43.370 MLDP GLO 0/0/CPU0 t21 NBR  : New LDP peer 10.0.0.4:0 UP cap: f
Jan  1 16:52:43.370 MLDP GLO 0/0/CPU0 t21 NBR  : 10.0.0.4:0 LDP Adjacency addr: 10.2.4.4, Interface: GigabitEthernet0/0/0/1 Add
Jan  1 16:52:43.660 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.4:0 installed local label 24009
Jan  1 16:52:43.660 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP label mappping MBB Request msg to 10.0.0.4:0 Success
Jan  1 16:52:43.660 MLDP LSP 0/0/CPU0 t21 FWD  : 0x00001 Label 24009 add path label 24010 intf GigabitEthernet0/0/0/2 nexthop 10.2.6.6 id 0x00001 Success
Jan  1 16:52:43.660 MLDP GLO 0/0/CPU0 t21 GEN  : Root 10.0.0.5 path 10.2.4.4 php nh 10.2.4.4 peer 134a338c:10.0.0.4:0
Jan  1 16:52:43.910 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP notification from 10.0.0.4:0 root 10.0.16.0 Opaque Len: 83886090 MBB Ack
Jan  1 16:52:43.910 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 Start MBB Notification timer 100 msec (MBB ack)
Jan  1 16:52:43.910 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL selection delayed for 60 seconds (MBB)
Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 start delete pending timer at 0 sec
Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.4:0 activate
Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 update active ident from 10.0.0.3:0 to 10.0.0.4:0
Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 deactivate
Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 delete delay timer expired, delete pending TRUE
Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 FWD  : 0x00001 Label 24008 delete, Success
Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 binding list Local Delete
Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 Released label 24008 to LSD
Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP label withdraw msg to 10.0.0.3:0 Success
Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 remove
Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP label release from 10.0.0.3:0 label 24008 root 10.0.0.5 Opaque Len 11
Jan  1 16:53:44.356 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 MBB notification delay timer expired

MBB para protección

La protección mLDP se compone de dos partes principales: la protección en sí y MBB (Make-Before-Break).

Protección

La protección del tráfico mLDP es similar a los mecanismos de protección del tráfico MPLS de unidifusión. Tan pronto como se detecta una falla de link, el router PLR conmuta el tráfico multicast de los árboles que cruzan ese link a la trayectoria de respaldo. Esta ruta de copia de seguridad es una ruta precalculada que se instala en el plano de reenvío. Por lo tanto, tan pronto como ocurre la falla, el tráfico multicast se puede conmutar inmediatamente a la trayectoria de respaldo.

La protección es solo para link inactivo. No hay protección de nodo para mLDP.

El evento de desconexión de link debe detectarse muy rápidamente. Esto significa que se debe utilizar BFD (detección de reenvío bidireccional).

MBB

Una vez que la protección se activa, el tráfico de multidifusión no permanece en la ruta de copia de seguridad para siempre. El tráfico debe conmutarse a un árbol/trayectoria mLDP nativo recién calculado. Este switchover debe ocurrir de tal manera que no se pierda tráfico multicast. MBB se utiliza para esto, de modo que el tráfico sólo se conmuta cuando el árbol recién señalado está completamente configurado y está reenviando tráfico. El router MP puede entonces conmutar de forma segura el reenvío del tráfico desde el árbol de respaldo antiguo al árbol recién señalado sin pérdida de tráfico.

Teoría de la protección mLDP

Mira la imagen 6. Muestra una red con un link R1 - R2 que está protegido con Ti-LFA.

Imagen 6

El tráfico mLDP se reenvía a través del link R1 - R2. FRR calcula e instala una ruta de respaldo a través de R3.

Mira la imagen 7.

Imagen 7

La imagen 7 muestra la situación en la que la protección está activa.

Cuando el link R1 - R2 deja de funcionar, la sesión LDP a través de él se mantiene activa mediante la protección de sesión LDP. La sesión LDP, que es una sesión TCP, se redirecciona sobre R3. Esto evita que se eliminen los enlaces de etiquetas para LDP y mLDP entre R1 y R2. Para que esta sesión LDP pueda enrutarse a través de R3 y ser multisalto, debe ser una sesión LDP dirigida. Esto se realiza automáticamente cuando se configura la protección de sesión LDP.

Cuando el link R1 - R2 deja de funcionar, el tráfico mLDP se puede re-enrutar de una manera rápida sobre R3. Para que esto funcione, debe haber alguna forma de protección en R1 para la ruta hacia el router LDP ID de R2. Esto se logra habilitando túneles de ingeniería de tráfico MPLS, LFA (alternativa sin bucles) o Ti-LFA (LFA independiente de la topología). El tráfico multicast de R1 a R2 tenía una etiqueta mLDP. Cuando el link R1 - 2 deja de funcionar, el tráfico multicast recibe una etiqueta adicional cuando se envía a R2. Hay Penultimate Hop Popping (PHP), por lo que el tráfico se reenvía con una etiqueta hacia R2. R2 recibe este tráfico con la misma etiqueta que cuando el link R1 - R2 estaba activo. R2 continúa reenviando este tráfico de multidifusión.

Esta protección es rápida. Mientras hay protección para el tráfico mLDP, R2 comienza a señalar una nueva trayectoria nativa desde él hacia R1 a través de R3. Por lo tanto, R2 envía un mensaje de mapeo de etiquetas mLDP a R3. R3 hace lo mismo hacia R1. Este es el mismo proceso/señalización que siempre cuando se crea una nueva trayectoria mLDP. Mientras esta señalización continúa, R2 continúa reenviando el tráfico desde la trayectoria mLDP de respaldo. ¿Cuándo R2 comienza a reenviar el tráfico desde la trayectoria nativa recién creada? El disparador puede ser dos cosas: un retardo temporizado o un disparador de señalización. La demora temporizada es algo configurado. El disparador de señalización es el comportamiento Make-Before-Break (MBB) introducido en mLDP y especificado en RFC 6388. Cuando R2 recibe la señal de R1, indica que la trayectoria mLDP recién nativa está lista, por lo que R2 puede comenzar a reenviar el tráfico desde esa nueva trayectoria mLDP y dejar de reenviar el tráfico desde la trayectoria de respaldo.

R1 se llama PLR (Point-of-Local-Repair), es el router donde se bifurcan el trayecto protegido y el trayecto nativo recién señalado. R2 es el MP (punto de fusión), el router en el que se combinan de nuevo la ruta protegida y la ruta nativa recién señalada.

Mira la imagen 8.

Imagen 8

La imagen 8 muestra que hay un mensaje de Mapeo de Etiquetas mLDP de R2 a R3, y de R3 a R1. Este mensaje de asignación de etiquetas tiene la solicitud MBB.

Mira la imagen 9.

Imagen 9

R1 contesta esta señalización con una Notificación LDP, llevando el reconocimiento MBB en la dirección inversa. Así que, abajo del árbol. Este mensaje viaja de R1 a R3, y de R3 a R2. Esto indica a R2, el router MP, que la nueva trayectoria mLDP nativa está lista. En este punto R1 reenvía el tráfico mLDP dos veces, una vez en la trayectoria de respaldo y otra en la nueva trayectoria nativa

MBB se utiliza aquí para que el switch MP (R2) vuelva a una ruta nativa (recién creada). Cuando MBB ha terminado la parte de señalización, el MP deja de reenviar el tráfico mLDP que llega desde la trayectoria de respaldo y comienza a reenviar el tráfico desde la trayectoria nativa recién señalizada. El MBB se utiliza aquí para indicar cuándo está listo este trayecto recién señalado. Otra posibilidad es configurar un retraso. En ese caso, el MP deja de reenviar el tráfico mLDP que llega de la trayectoria de respaldo y comienza a reenviar el tráfico de la trayectoria nativa recién señalada después de que el MBB haya señalado que esta nueva trayectoria nativa está lista y después del temporizador de demora configurado.

Cuando R2 comienza a reenviar el tráfico desde la nueva trayectoria nativa, deja de reenviar el tráfico desde la trayectoria de respaldo y señala la eliminación de la trayectoria de respaldo enviando un mensaje de Retirada de etiqueta LDP para el árbol (y un mensaje de Liberación de etiqueta LDP).

Se puede agregar un retardo de eliminación adicional para quitar el árbol antiguo a fin de permitir que la plataforma programe todo el estado de reenvío a las tarjetas de línea.

Después de esto, sólo existe el árbol nativo recién señalado. Mire la imagen 10 para ver el reenvío del tráfico mLDP en este caso.

Imagen 10

Observe que el tráfico mLDP tiene una etiqueta MPLS en la parte superior nuevamente.

Configuración necesaria

Los siguientes tres elementos de configuración son necesarios para que funcione mLDP FRR (Fast ReRoute).

Necesita:

- Reenvío recursivo para mLDP habilitado

- Protección de sesión LDP habilitada

- LFA (alternativa libre de bucles) o Ti-LFA (LFA independiente de la topología) bajo el IGP (Ti-LFA requiere routing de segmentos). La ingeniería de tráfico punto a punto también es posible.

Si falta alguno de estos tres, entonces no hay protección FRR para mLDP. mLDP protege solamente contra fallas de link, no contra fallas de nodo.

Ejemplo de configuración

mpls ldp
 log
  neighbor
  nsr
  graceful-restart
  session-protection                   
 !
 igp sync delay on-session-up 25
 mldp
  logging notifications
  address-family ipv4
   make-before-break delay 600 60      <<<<<<
   forwarding recursive                <<<<<<
  !
 !
 router-id 10.79.196.14
 neighbor
  dual-stack transport-connection prefer ipv4
 !
session protection for LDP-PEERS     <<<<<<
 address-family ipv4
  label
   local
    allocate for host-routes
   !
  !
 !

El comando make-before-break es opcional.

Verifique que la interfaz saliente esté protegida por LFA o Ti-LFA:

router isis IGP
 set-overload-bit on-startup 600
 net 49.0010.0000.0000.0001.00
 segment-routing global-block 100000 150000
 nsf cisco
 log adjacency changes
 lsp-gen-interval maximum-wait 5000 initial-wait 1 secondary-wait 50
 lsp-refresh-interval 1800
 max-lsp-lifetime 1880
 address-family ipv4 unicast
  metric-style wide
  fast-reroute per-prefix priority-limit critical
  fast-reroute per-prefix tiebreaker lowest-backup-metric index 20
  fast-reroute per-prefix tiebreaker node-protecting index 30
  fast-reroute per-prefix tiebreaker srlg-disjoint index 10
  mpls traffic-eng level-2-only
  mpls traffic-eng router-id Loopback145
  mpls traffic-eng multicast-intact
  spf-interval maximum-wait 7000 initial-wait 1 secondary-wait 50
  segment-routing mpls sr-prefer
  segment-routing prefix-sid-map advertise-local
  spf prefix-priority critical tag 17
  mpls ldp auto-config
 !
 address-family ipv6 unicast
  metric-style wide
  fast-reroute per-prefix priority-limit critical
  fast-reroute per-prefix tiebreaker lowest-backup-metric index 20
  fast-reroute per-prefix tiebreaker node-protecting index 30
  fast-reroute per-prefix tiebreaker srlg-disjoint index 10
  spf-interval maximum-wait 7000 initial-wait 1 secondary-wait 50
  segment-routing mpls sr-prefer
  spf prefix-priority critical tag 17
 !
interface Bundle-Ether10362
  circuit-type level-2-only
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix            <<<<<<
   fast-reroute per-prefix ti-lfa     <<<<<<
   metric 420 level 2
   mpls ldp sync level 2
  !
  address-family ipv6 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   metric 420 level 2
  !

No hay impacto en la protección del tráfico multicast si alguno de los routers a lo largo de la nueva trayectoria nativa no tiene MBB configurado. La protección depende solamente de la configuración de la protección de sesión LDP, el reenvío recursivo y FRR en el PLR. La configuración MBB en los routers de trayectoria recién nativos sólo tiene una consecuencia cuando el tráfico se conmuta de la trayectoria de respaldo al árbol recién señalado. Si un router mLDP recibió un mensaje de Label Mapping con MBB Request de un router de flujo descendente y necesita enviar un mensaje de Label Mapping a un router de flujo ascendente, pero ese router de flujo ascendente no tiene MBB habilitado, el router mLDP envía un mensaje de Notificación LDP a este router de flujo descendente tan pronto como haya enviado el mensaje de Label Mapping (sin MBB Request) al router de flujo ascendente. Como tal, el resultado es un árbol mLDP normal.

Ejemplo de MBB para FRR

Consulte la imagen 11 para ver la topología.

Imagen 11

Cuando el Link falla entre R1 y R2, la sesión mLDP entre ellos está protegida por una sesión de destino LDP entre ellos sobre R3. Por lo tanto, la sesión mLDP entre R1 y R2 permanece activa incluso cuando el link entre ellos está inactivo. Esto protege los enlaces de etiquetas mLDP entre ellos, se mantienen. Cuando el link R1-R2 deja de funcionar, el plano de reenvío pasa inmediatamente: el link saliente R1-R2 cambia al link R1-R3 de una manera muy rápida, gracias al TE MPLS punto a punto, LFA o Ti-LFA en su lugar. Este P2P MPLS TE, LFA o Ti-LFA debe proteger en R1 la ruta al router LDP-ID de R2 para conmutar las entradas de reenvío para mLDP de una manera correcta. Finalmente, el reenvío recursivo es necesario porque la sesión mLDP pasa de una sesión conectada directamente a una sesión remota, donde el ID de router LDP se resuelve de manera recursiva.

R1 se llama PLR (Point-of-Local-Repair), es el router donde se bifurcan el trayecto protegido y el trayecto nativo recién señalado. R2 es el MP (punto de fusión), el router en el que se combinan de nuevo la ruta protegida y la ruta nativa recién señalada.

Compruebe los tres requisitos:

-Protección LDP

Para el vecino LDP (mLDP) conectado directamente a través de Bundle-Ethernet10362, también debe haber saludos dirigidos:

RP/0/RP0/CPU0:R1#show mpls ldp discovery 10.79.196.10

Local LDP Identifier: 10.79.196.14:0
Discovery Sources:
 Interfaces:
    Bundle-Ether10362 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 10.79.196.10:0, Transport address: 10.79.196.10
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Dec 28 10:23:16.144 (00:02:13 ao)


  Targeted Hellos:
    10.79.196.14 -> 10.79.196.10 (active), xmit/recv
      LDP Id: 10.79.196.10:0
          Hold time: 90 sec (local:90 sec, peer:90 sec)
          Established: Dec 28 10:23:30.008 (00:01:59 ago)

-LFA o Ti-LFA en virtud del IGP

Verifique que la ruta al router-id vecino LDP tenga una trayectoria de respaldo. La RIB (Base de información de ruteo) y la FIB (Base de información de reenvío o CEF) deben tener esta trayectoria de respaldo:

RP/0/RP0/CPU0:R1#show route 10.79.196.10

Routing entry for 10.79.196.10/32
  Known via "isis IGP", distance 115, metric 420, labeled SR
  Tag 17, type level-2
  Installed Dec 28 10:23:42.659 for 00:07:58
  Routing Descriptor Blocks
    10.254.1.144, from 10.79.196.10, via Bundle-Ether10301, Backup (Local-LFA)
      Route metric is 2000
    10.254.3.37, from 10.79.196.10, via Bundle-Ether10362, Protected
      Route metric is 420
  No advertising protos.

RP/0/RP0/CPU0:R1#show cef 10.79.196.10
10.79.196.10/32, version 7364, labeled SR, internal 0x1000001 0x83 (ptr 0x788e1f78) [1], 0x0 (0x788ab5a8), 0xa28 (0x79dd1138)
 Updated Oct 25 11:32:44.299
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 10.254.1.144/32, Bundle-Ether10301, 11 dependencies, weight 0, class 0, backup (Local-LFA) [flags 0x300]
    path-idx 0 NHID 0x0 [0x78f4e9b0 0x0]
    next hop 10.254.1.144/32
    local adjacency
     local label 100010      labels imposed {100010}
   via 10.254.3.37/32, Bundle-Ether10362, 11 dependencies, weight 0, class 0, protected [flags 0x400]
    path-idx 1 bkup-idx 0 NHID 0x0 [0x7905e510 0x7905e350]
    next hop 10.254.3.37/32
     local label 100010      labels imposed {ImplNull}

-reenvío recursivo para mLDP

La entrada de la base de datos mLDP no tiene una interfaz de salida en la LFIB si se aplica el reenvío recursivo:

Sin reenvío recursivo:

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
25426  24440       mLDP/IR: 0x00001   BE10362      10.254.3.37    7893474

Con reenvío recursivo:

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
25426  24440       mLDP/IR: 0x00001                10.79.196.10    2516786878

Observe que ya no hay interfaz de salida para la entrada de reenvío mLDP. Esto dificulta un poco la resolución de problemas.

El MP tiene la siguiente configuración para mLDP. Observe los temporizadores 600 seg y 60 seg. El PLR tiene los mismos temporizadores. El PLR reenvía el tráfico a través de la trayectoria de respaldo y la trayectoria nativa durante 600 segundos. El retraso de 600 segundos significa que el MP reenvía el tráfico de la trayectoria de respaldo durante 600 segundos, mientras descarta el tráfico que llega de la trayectoria nativa. 600 segundos es mucho tiempo para este temporizador. Se utilizó en un entorno de laboratorio para proporcionar tiempo suficiente para capturar el resultado con los comandos show. El retraso de 60 segundos significa que el MP espera la eliminación de la trayectoria MBB por 60 segundos después de que comience a reenviar el tráfico que llega de la trayectoria nativa y a descartar el tráfico que llega sobre la trayectoria de respaldo. El valor correcto para estos dos retrasos depende de la red. Debe derivarse de la prueba de la red, el software y el hardware específicos.

mpls ldp
 log
  neighbor
  nsr
  graceful-restart
  session-protection
 !
 igp sync delay on-session-up 25
 mldp
  logging notifications
  address-family ipv4
   make-before-break delay 600 60
   forwarding recursive
  !
 !
 router-id 10.79.196.10
 neighbor
  dual-stack transport-connection prefer ipv4
 !
 session protection for LDP-PEERS
 address-family ipv4
  label
   local
    allocate for LDP-PEERS
   !
  !
 !

MBB en uso

Mire la imagen 12, muestra el reenvío mientras mLDP está en modo de protección.

Imagen 12

Antes de que la interfaz saliente esté inactiva, esta es la entrada LFIB para el ID del router LDP remoto (R2):

RP/0/RP0/CPU0:R1#show mpls forwarding labels 100010
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
100010 Pop         SR Pfx (idx 10)    BE10362      10.254.3.37    355616309429
       100010      SR Pfx (idx 10)    BE10301      10.254.1.144   0            (!)

The (!) indicates a backup path.

Esta es la entrada de la base de datos del árbol mLDP en el PLR:

RP/0/RP0/CPU0:R1#show mpls mldp database details
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 3d03h
  FEC Root           : 10.79.196.14 (we are the root)
  FEC Length         : 12 bytes
  FEC Value internal : 02010004000000015C4FC40E
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00000001
  Opaque decoded     : [global-id 1]
  Features           : MBB RFWD Trace
  Upstream neighbor(s) :
    None
  Downstream  client(s):
    LDP 10.79.196.10:0 Uptime: 02:09:09
      Rec Next Hop     : 10.79.196.10
      Remote label (D) : 24440
      LDP MSG ID       : 254705
    PIM MDT            Uptime: 3d03h
      Egress intf     : Lmdtvrfone
      Table ID        : IPv4: 0xe0000014 IPv6: 0xe0800014
      HLI             : 0x00001
      Ingress         : Yes
      Peek            : Yes
      PPMP            : Yes

Esta es la entrada de reenvío mLDP para el árbol:

RP/0/RP0/CPU0:R1#show mpls mldp forwarding label 25426
mLDP MPLS forwarding database

25426  LSM-ID: 0x00001 HLI: 0x00001 flags: In Pk
   Lmdtvrfone, RPF-ID: 0, TIDv4: E0000014, TIDv6: E0800014
   24440, NH: 10.79.196.10, Intf:  Role: H, Flags: 0x4      Local Label     : 25426 (internal)

Esta es la entrada de reenvío LFIB (Base de instancia de reenvío de etiquetas) para el árbol:

RP/0/RP0/CPU0:R1#show mpls for labels 25426
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
25426  24440       mLDP/IR: 0x00001                10.79.196.10    0

La entrada de reenvío mLDP está protegida. La entrada de reenvío está protegida mediante la etiqueta 100010, la entrada para el ID del router LDP remoto.

RP/0/RP0/CPU0:R1#show mpls for labels 25426 detail

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
25426              mLDP/IR: 0x00001 (0x00001)
       Updated Dec 28 10:23:42.669
       mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001
       IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014
       Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set
             Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set
             Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set
             Ingress Drop:not-set, Egress Drop:not-set
             RPF-ID:0, Encap-ID:0
             Disp-Tun:[ifh:0x0, label:-]
             Platform Data [64]:
              { 0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 2 9 0 0 2 10
                0 0 0 1 0 0 0 1
                }
       mpls paths: 1, local mpls paths: 0, protected mpls paths: 


       24440       mLDP/IR: 0x00001 (0x00001)   \
                                                   10.79.196.10    0
         Updated: Dec 28 10:23:42.670
         My Nodeid:0x20
         Interface Nodeids:
           [ 0x8620 - - - - - - - - -  ]
         Interface Handles:
           [ 0xc0001c0 - - - - - - - - -  ]
         Backup Interface Nodeids:
           [ 0x8520 - - - - - - - - - ]
         Backup Interface Handles:
           [ 0xa000400 - - - - - - - - - ]
         via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]
         Packets Switched: 0

Esta es la entrada de reenvío en el hardware. Los routers son routers ASR9k.

RP/0/RP0/CPU0:R1#show mpls for labels 25426 detail hardware ingress location 0/2/CPU0
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
25426              mLDP/IR: 0x00001 (0x00001)
       Updated Dec 28 10:23:42.674
       mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001
       IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014
       Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set
             Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set
             Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set
             Ingress Drop:not-set, Egress Drop:not-set
             RPF-ID:0, Encap-ID:0
             Disp-Tun:[ifh:0x0, label:-]
             Platform Data [64]:
              { 0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 2 9 0 0 2 10
                0 0 0 1 0 0 0 1
                }
       mpls paths: 1, local mpls paths: 0, protected mpls paths: 1

       24440       mLDP/IR: 0x00001 (0x00001)   \
                                                   10.79.196.10    N/A
         Updated: Dec 28 10:23:42.674
         My Nodeid:0x8420
         Interface Nodeids:
           [ 0x8620 - - - - - - - - -  ]
         Interface Handles:
           [ 0xc0001c0 - - - - - - - - -  ]
         Backup Interface Nodeids:
           [ 0x8520 - - - - - - - - - ]
         Backup Interface Handles:
           [ 0xa000400 - - - - - - - - - ]
         via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]
         Packets Switched: 0

 LEAF - HAL pd context :
 sub-type : MPLS_P2MP, ecd_marked:0, has_collapsed_ldi:0
 collapse_bwalk_required:0, ecdv2_marked:0,

Leaf H/W Result

Leaf H/W Result on NP:0
09000014000000921806352100020900006000020a0000600000a00001010400
vpn_special                        =           0 (0x0)
vc_label_vpws                      =           0 (0x0)
vc_label_vpls                      =           0 (0x0)
pwhe                               =           0 (0x0)
p2mp                               =           1 (0x1)
tp                                 =           0 (0x0)
recursive                          =           0 (0x0)
non_recursive                      =           1 (0x1)
flow_label_dispose                 =           0 (0x0)
receive_entry_type                 =           0 (0x0)
control_word_enabled               =           0 (0x0)
imp_ttl_255                        =           0 (0x0)
collapsed                          =           0 (0x0)
recursive_lsp_stats                =           0 (0x0)
vpn_key                            =          20 (0x14)
Non-recursive:
  rpf_id                           =           0 (0x0)
  nrldi_ptr                        =      406817 (0x63521)
P2MP:
  rpf_id                           =         146 (0x92)
  nrldi_ptr                        =         146 (0x92)
  mldp_egr_drop                    =           0 (0x0)
  mldp_ing_drop                    =           0 (0x0)
  mldp_signal                      =           0 (0x0)
  mldp_peek                        =           1 (0x1)
  mldp_tunnel                      =           1 (0x1)
  p2mp_bud_node                    =           0 (0x0)
  p2mp_ip_lookup                   =           0 (0x0)
  per_lc_receivers                 =           0 (0x0)
  igp_local_label: eos             =           1 (0x1)
  igp_local_label: exp             =           0 (0x0)
  igp_local_label: label           =       25426 (0x6352)
  fab_info: fab_mgid               =         521 (0x209)
  fab_info: fab_slotmask           =          96 (0x60)
  fab_info: fab_fgid               =   150995040 (0x9000060)
  backup_fab_info: backup_fab_mgid =         522 (0x20a)
  backup_fab_info: backup_fab_slotmask=          96 (0x60)
  backup_fab_info: backup_fab_fgid =   167772256 (0xa000060)
  rep_node_ndx                     =       40960 (0xa000)
  ecmp_size                        =           1 (0x1)
  stats_ptr                        =       66560 (0x10400)

Leaf H/W Result on NP:1
09000014000000921806352100020900006000020a0000600000a00001010400
…

Está el FGID (Fabric Group Index) y el FGID de respaldo. El fabric de switch utiliza el FGID para reenviar el tráfico de multidifusión a las tarjetas de línea correctas. También existe el MGID (Multicast Group Identifier). El MGID se utiliza para reenviar el tráfico multicast a los elementos de replicación correctos en las tarjetas de línea.

RP/0/RP0/CPU0:R1#show mrib encap-id

Encap ID Key    : 00000101000000600600020100000000000002
Encap ID Length : 19
Encap ID Value  : 262145

Platform Annotation:
  Slotmask: Primary: 0x40, Backup: 0x60
  MGID:     Primary: 64059,   Backup: 64060

Flags (Vrflite(v4/v6),Stale,v6): N/N, N, N
Oles:
  [1] type: 0x5, len: 12
      LSM-ID: 0x00001      MDT: 0x2000660   Turnaround: TRUE
Primary: 0/4/CPU0[1]
Backup: 0/3/CPU0[1]
TableId: 0xe0000014[1001]

Redist History:
client id 31 redist time: 02:01:27 redist flags 0x0

Así es como puede buscar la entrada MGID:

RP/0/RP0/CPU0:R1#show controllers mgidprgm mgidindex 521 location 0/2/CPU0

Device         MGID-Bits       Client-Last-Modified
=======================================================
XBAR-0         1               P2MP
XBAR-1         1               P2MP
FIA-0          1               P2MP
FIA-1          0               None
FIA-2          0               None
FIA-3          0               None
FIA-4          0               None
FIA-5          0               None
FIA-6          0               None
FIA-7          0               None
========================================================
Client         Mask
========================================================
MFIBV4         0x0
MFIBV6         0x0
L2FIB          0x0
sRP-pseudo-mc  0x0
UT             0x0
Prgm-Svr       0x0
P2MP           0x1
xbar           0x0
UT1            0x0
UT2            0x0
punt_lib       0x0

RP/0/RP0/CPU0:R1#show controllers mgidprgm mgidindex 522 location 0/2/CPU0

Device         MGID-Bits       Client-Last-Modified
=======================================================
XBAR-0         1               P2MP
XBAR-1         1               P2MP
FIA-0          1               P2MP
FIA-1          0               None
FIA-2          0               None
FIA-3          0               None
FIA-4          0               Non
FIA-5          0               None
FIA-6          0               None
FIA-7          0               None
========================================================
Client         Mask
========================================================
MFIBV4         0x0
MFIBV6         0x0
L2FIB          0x0
sRP-pseudo-mc  0x0
UT             0x0
Prgm-Svr       0x0
P2MP           0x1
xbar           0x0
UT1            0x0
UT2            0x0
punt_lib       0x0

La interfaz saliente está ahora inactiva y MBB está en uso.

La imagen 13 muestra la señalización.

Imagen 13

R1 ahora tiene dos entradas de reenvío para este árbol:

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes      
Label  Label       or ID              Interface                    Switched   
------ ----------- ------------------ ------------ --------------- ------------
25426  24440       mLDP/IR: 0x00001                10.79.196.10    1834250032 
       24033       mLDP/IR: 0x00001                10.79.196.13    1825230386 

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426 detail

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes      
Label  Label       or ID              Interface                    Switched   
------ ----------- ------------------ ------------ --------------- ------------
25426              mLDP/IR: 0x00001 (0x00001)
       Updated Dec 28 13:07:03.417
       mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001
       IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014
       Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set
             Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set
             Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set
             Ingress Drop:not-set, Egress Drop:not-set
             RPF-ID:0, Encap-ID:0
             Disp-Tun:[ifh:0x0, label:-]
             Platform Data [64]:
              { 0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 2 9 0 0 2 10
                0 0 0 1 0 0 0 1
                }
       mpls paths: 2, local mpls paths: 0, protected mpls paths: 

       24440       mLDP/IR: 0x00001 (0x00001)   \
                                                   10.79.196.10    2230150704 
         Updated: Dec 28 13:07:03.245
         My Nodeid:0x20
         Interface Nodeids:
           [ 0x8520 - - - - - - - - -  ]
         Interface Handles:
           [ 0xa000400 - - - - - - - - -  ]
         Backup Interface Nodeids:
           [ - - - - - - - - - - ]
         Backup Interface Handles:
           [ - - - - - - - - - - ]
         via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]
         Packets Switched: 21039158
       24033       mLDP/IR: 0x00001 (0x00001)   \
                                                   10.79.196.13    2221131058 
         Updated: Dec 28 13:07:03.417
         My Nodeid:0x20
         Interface Nodeids:
           [ 0x8520 - - - - - - - - -  ]
         Interface Handles:
           [ 0xa000400 - - - - - - - - -  ]
         Backup Interface Nodeids:
           [ - - - - - - - - - - ]
         Backup Interface Handles:
           [ - - - - - - - - - - ]
         via-label:100013, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]
         Packets Switched: 20954067

Hay dos clientes mLDP de flujo descendente, R2 y R3:

RP/0/RP0/CPU0:R1#show mpls mldp database details
mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 3d04h
  FEC Root           : 10.79.196.14 (we are the root)
  FEC Length         : 12 bytes
  FEC Value internal : 02010004000000015C4FC40E
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00000001
  Opaque decoded     : [global-id 1]
  Features           : MBB RFWD Trace
  Upstream neighbor(s) :
    None
  Downstream  client(s):
    LDP 10.79.196.10:0 Uptime: 02:44:09
      Rec Next Hop     : 10.79.196.10
      Remote label (D) : 24440            
      LDP MSG ID       : 254705
    LDP 10.79.196.13:0 Uptime: 00:00:48
      Rec Next Hop     : 10.79.196.13
      Remote label (D) : 24033            
      LDP MSG ID       : 98489
    PIM MDT            Uptime: 3d04h
      Egress intf     : Lmdtvrfone
      Table ID        : IPv4: 0xe0000014 IPv6: 0xe0800014
      HLI             : 0x00001
      Ingress         : Yes
      Peek            : Yes
      PPMP            : Yes
      Local Label     : 25426 (internal)

El MP (R2) tiene dos vecinos ascendentes, uno está activo, el otro está inactivo:

P/0/RSP1/CPU0:R2#show mpls mldp database details

LSM-ID: 0x00002  Type: P2MP  Uptime: 03:45:22
  FEC Root           : 10.79.196.14
  FEC Length         : 12 bytes
  FEC Value internal : 02010004000000015C4FC40E
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00000001
  Opaque decoded     : [global-id 1]
  MBB nbr evaluate   : 00:08:18
  Features           : MBB RFWD Trace
  Upstream neighbor(s) :
  Is CSI accepting    : N
    10.79.196.13:0 [Inactive] [MBB] Uptime: 00:01:42
      Local Label (D) : 24441
  Is CSI accepting    : N
    10.79.196.14:0 [Active] [Delete] [MBB] Uptime: 02:45:02
      Local Label (D) : 24440
  Downstream  client(s):
    PIM MDT            Uptime: 03:45:22
      Egress intf     : Lmdtvrfone
      Table ID        : IPv4: 0xe0000013 IPv6: 0xe0800013
      RPF ID          : 3
      Peek            : Yes
      RD              : 3209:92722001

La interfaz de respaldo no está en R1:

RP/0/RP0/CPU0:R1#show mpls for labels 25426 detail hardware ingress location 0/2/CPU0

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes      
Label  Label       or ID              Interface                    Switched   
------ ----------- ------------------ ------------ --------------- ------------
25426              mLDP/IR: 0x00001 (0x00001)
       Updated Dec 28 13:07:03.418
       mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001
       IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014
       Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set
             Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set
             Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set
             Ingress Drop:not-set, Egress Drop:not-set
             RPF-ID:0, Encap-ID:0
             Disp-Tun:[ifh:0x0, label:-]
             Platform Data [64]:
              { 0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 0 96 0 0 0 96
                0 0 0 0 0 0 0 0
                0 0 0 0 0 0 0 0
                0 0 2 9 0 0 2 10
                0 0 0 1 0 0 0 1
                }
       mpls paths: 2, local mpls paths: 0, protected mpls paths: 

       24440       mLDP/IR: 0x00001 (0x00001)   \
                                                   10.79.196.10    N/A        
         Updated: Dec 28 13:07:03.255
         My Nodeid:0x8420
         Interface Nodeids:
           [ 0x8520 - - - - - - - - -  ]
         Interface Handles:
           [ 0xa000400 - - - - - - - - -  ]
         Backup Interface Nodeids:
           [ - - - - - - - - - - ]
         Backup Interface Handles:
           [ - - - - - - - - - - ]
         via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]
         Packets Switched: 0
       24033       mLDP/IR: 0x00001 (0x00001)   \
                                                   10.79.196.13    N/A        
         Updated: Dec 28 13:07:03.418
         My Nodeid:0x8420
         Interface Nodeids:
           [ 0x8520 - - - - - - - - -  ]
         Interface Handles:
           [ 0xa000400 - - - - - - - - -  ]
         Backup Interface Nodeids:
           [ - - - - - - - - - - ]
         Backup Interface Handles:
           [ - - - - - - - - - - ]
         via-label:100013, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]
         Packets Switched: 0

RP/0/RP0/CPU0:R1#show mrib encap-id 

Encap ID Key    : 00000101000000600600020100000000000002
Encap ID Length : 19
Encap ID Value  : 262145

Platform Annotation:
  Slotmask: Primary: 0x20, Backup: 0x20
  MGID:     Primary: 64059,   Backup: 64060

Flags (Vrflite(v4/v6),Stale,v6): N/N, N, N
Oles:
  [1] type: 0x5, len: 12
      LSM-ID: 0x00001      MDT: 0x2000660   Turnaround: TRUE
Primary: 0/3/CPU0[1]
Backup:
TableId: 0xe0000014[1001]

Redist History:
client id 31 redist time: 00:01:22 redist flags 0x0

El MP cambió al árbol nativo recién señalado, y está dentro de los 60 segundos antes de eliminar el árbol antiguo:

RP/0/RSP1/CPU0:R2#show mpls mldp database details

LSM-ID: 0x00002  Type: P2MP  Uptime: 03:53:56
  FEC Root           : 10.79.196.14
  FEC Length         : 12 bytes
  FEC Value internal : 02010004000000015C4FC40E
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00000001
  Opaque decoded     : [global-id 1]
  Features           : MBB RFWD Trace
  Upstream neighbor(s) :
  Is CSI accepting    : N
    10.79.196.13:0 [Active] [MBB] Uptime: 00:10:16
      Local Label (D) : 24441
  Is CSI accepting    : N
    10.79.196.14:0 [Inactive] [Delete 00:00:44] [MBB] Uptime: 02:53:37
      Local Label (D) : 24440
  Downstream  client(s):
    PIM MDT            Uptime: 03:53:56
      Egress intf     : Lmdtvrfone
      Table ID        : IPv4: 0xe0000013 IPv6: 0xe0800013
      RPF ID          : 3
      Peek            : Yes
      RD              : 3209:92722001

Existe el estado, después de que se elimine el árbol antiguo:

RP/0/RSP1/CPU0:R2#show mpls mldp database details
mLDP database

LSM-ID: 0x00002  Type: P2MP  Uptime: 03:58:03
  FEC Root           : 10.79.196.14
  FEC Length         : 12 bytes
  FEC Value internal : 02010004000000015C4FC40E
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00000001
  Opaque decoded     : [global-id 1]
  Features           : MBB RFWD Trace
  Upstream neighbor(s) :
  Is CSI accepting    : N
    10.79.196.13:0 [Active] [MBB] Uptime: 00:14:23
      Local Label (D) : 24441
  Downstream  client(s):
    PIM MDT            Uptime: 03:58:03
      Egress intf     : Lmdtvrfone
      Table ID        : IPv4: 0xe0000013 IPv6: 0xe0800013
      RPF ID          : 3
      Peek            : Yes
      RD              : 3209:92722001

El PLR sólo tiene un cliente mLDP descendente:

RP/0/RP0/CPU0:R1#show mpls mldp database details

mLDP database
LSM-ID: 0x00001  Type: P2MP  Uptime: 3d04h
  FEC Root           : 10.79.196.14 (we are the root)
  FEC Length         : 12 bytes
  FEC Value internal : 02010004000000015C4FC40E
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00000001
  Opaque decoded     : [global-id 1]
  Features           : MBB RFWD Trace
  Upstream neighbor(s) :
    None
  Downstream  client(s): 
    LDP 10.79.196.13:0 Uptime: 00:11:13
      Rec Next Hop     : 10.79.196.13
      Remote label (D) : 24033            
      LDP MSG ID       : 98489
    PIM MDT            Uptime: 3d04h
      Egress intf     : Lmdtvrfone
      Table ID        : IPv4: 0xe0000014 IPv6: 0xe0800014
      HLI             : 0x00001
      Ingress         : Yes
      Peek            : Yes
      PPMP            : Yes
      Local Label     : 25426 (internal)

Seguimiento mLDP

El seguimiento mLDP muestra los eventos con más detalle.

En el PLR

La interfaz BE10362 se desactiva:

Dec 28 13:07:03.220 MLDP GLO 0/RP0/CPU0 t10704 RIB  : Read notification
Dec 28 13:07:03.225 MLDP GLO 0/RP0/CPU0 t10706 RIB  : Notify client 'Peer' for prefix: 10.79.196.10/32
Dec 28 13:07:03.225 MLDP GLO 0/RP0/CPU0 t10706 GEN  : Checkpoint save neighbor 10.79.196.10:0 canceled, no GR or NSR
Dec 28 13:07:03.227 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 delete adj 2000460/10.254.3.37
Dec 28 13:07:03.227 MLDP GLO 0/RP0/CPU0 t10706 GEN  : Checkpoint delete neighbor adj 2000460/10.254.3.37 objid 0 version 0 Failed
Dec 28 13:07:03.227 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 LDP Adjacency addr: 10.254.3.37, Interface: Bundle-Ether10362 Delete
Dec 28 13:07:03.325 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 Check branches for path change

El link se perdió, pero la adyacencia LDP no se pierde, se mantiene como una sesión de destino.

Las siguientes entradas son la nueva rama sobre el router IP (10.79.196.13):

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : P2MP Label mapping from 10.79.196.13:0 label 24033 root 10.79.196.14 Opaque Len 7
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Add branch LDP 10.79.196.13:0 Label 24033
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Branch LDP 10.79.196.13:0 binding list Remote Add
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Changing branch LDP 10.79.196.13:0 from None/0.0.0.0 to None/10.79.196.13
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Notify client Add event: 6 root TRUE
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Add update to PIM Root TRUE Upstream TRUE Ingress TRUE
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 add path label 24033 intf None nexthop 10.79.196.13 id 0x00001 Success
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 set HLI 0x00001 Success
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Notify client Add event: 6 root TRUE
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Add update to PIM Root TRUE Upstream TRUE Ingress TRUE
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 add path label 24033 intf None nexthop 10.79.196.13 id 0x00001 Success
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 set HLI 0x00001 Success
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10705 DB   : 0x00001 Add event from mLDP to PIM, ready TRUE root TRUE csc_rd 0:0 csc_umh 0.0.0.0, msg_len 50
Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10705 DB   : 0x00001 Add event from mLDP to PIM, ready TRUE root TRUE csc_rd 0:0 csc_umh 0.0.0.0, msg_len 50
Dec 28 13:07:05.296 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 to address: 10.254.3.37 mapping deleted

El resto es la limpieza. R3 envía el mensaje de Retirada de etiqueta y el mensaje de Liberación de etiqueta a R1:

Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 P2MP label withdraw from 10.79.196.10:0 label 24440 root 10.79.196.14 Opaque Len 7
Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 P2MP label release msg to 10.79.196.10:0 Success
Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 delete path label 24440 intf None nexthop 10.79.196.10 id 0x00001 Success
Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Branch LDP 10.79.196.10:0 binding list Remote Delete
Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Deleting branch entry LDP 10.79.196.10:0

En el Panel de administración

La interfaz al MP se desactiva. La adyacencia se pierde sobre el link, pero la adyacencia LDP se mantiene como una sesión iniciada:

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 delete adj 20003a0/10.254.3.36
Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint delete neighbor adj 20003a0/10.254.3.36 objid 0 version 0 Failed
Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 LDP Adjacency addr: 10.254.3.36, Interface: Bundle-Ether10362 Delete
Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Start path timer for root: 10.79.196.14
Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint save neighbor 10.79.196.14:0 canceled, no GR or NSR
Dec 28 13:05:27.152 MLDP GLO 0/RSP1/CPU0 t31488 RIB  : Read notification
Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Root paths count 1
Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 None 10.79.196.13
Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 added (chkpt FALSE)
Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 binding list Local Add
Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 path changed from None:0.0.0.0 to None:10.79.196.13
Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Request label type ACEL ident 10.79.196.13:0 LSD Success
Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 RIB  : Notify client 'Root' for prefix: 10.79.196.14/32
Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Root 10.79.196.14 path 10.254.1.184 php nh 10.254.1.184 peer 72d83798:10.79.196.13:0
Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : mldp_root_get_path: tid e0100000 ifh 0  php_nh 0.0.0.0
Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Failed to get intf type for ifh 0x0
Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 RIB  : Notify client 'Peer' for prefix: 10.79.196.14/32
Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint save neighbor 10.79.196.14:0 canceled, no GR or NSR
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Main Entry LSD label 24441 type ACEL ident 10.79.196.13:0 assigned
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 installed local label 24441
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Neighbor 10.79.196.13:0 not MBB capable or worse metric, ignore MBB code 0

MBB comienza a funcionar: los 600 segundos son el retraso de switchover configurado

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Start MBB Notification timer 100 msec (MBB ack)
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL selection delayed for 600 seconds (MBB)
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 P2MP label mappping  msg to 10.79.196.13:0 Success
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL selection delayed for 600 seconds (MBB)

Se crea la nueva trayectoria a través del router P:

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 create, Flags: 5 Success
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 add path lspvif Lmdtvrfone rpf-id 3 tid v4 0xe0000013 v6 0xe0800013 Success
Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 id_val 0 id_type 0
Dec 28 13:05:27.154 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : ACEL for local label 24441 label up 1048577
Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Root paths count 1
Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 None 10.79.196.13
Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 found, retain TRUE, to front TRUE
Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL selection delayed for 600 seconds (MBB)
Dec 28 13:05:27.234 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 Check branches for path change
Dec 28 13:05:27.234 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checking paths for root: 10.79.196.14
Dec 28 13:05:27.234 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : mldp_root_get_path: tid e0100000 ifh 0  php_nh 0.0.0.0
Dec 28 13:05:27.350 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 MBB notification delay timer expired
Dec 28 13:05:29.275 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 to address: 10.254.3.36 mapping deleted

El temporizador de 600 segundos caduca:

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Peer change delay timer expired
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL evaluate

La entrada se elimina después de otros 60 segundos.

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 start delete pending timer at 60 sec
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 activate
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 create, Flags: 1 Success
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 update active ident from 10.79.196.14:0 to 10.79.196.13:0
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save Main Entry active 10.79.196.13:0 rec_nh 0.0.0.0 rec_rd 0:0 cont...
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save lbl no_label length: 88 obj 80002f60 version 136 Success
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 deactivate
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24440 create, Flags: 5 Success
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 update active ident from 10.79.196.13:0 to 0.0.0.0:0
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save Main Entry active 0.0.0.0:0 rec_nh 0.0.0.0 rec_rd 0:0 cont...
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save lbl no_label length: 88 obj 80002f60 version 137 Success
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 update active ident from 0.0.0.0:0 to 10.79.196.13:0
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save Main Entry active 10.79.196.13:0 rec_nh 0.0.0.0 rec_rd 0:0 cont...
Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save lbl no_label length: 88 obj 80002f60 version 138 Success
Dec 28 13:15:28.352 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : ACEL for local label 24441 label up 1048577
Dec 28 13:15:28.352 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : ACEL for local label 24440 label up 1048577

El temporizador de retraso de eliminación caduca. R3 envía el mensaje de Retirada de Etiquetas y el mensaje de Liberación de Etiquetas a R1:

Dec 28 13:15:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 MBB notification delay timer expired
Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 delete delay timer expired, delete pending TRUE
Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24440 delete, Success
Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 binding list Local Delete
Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Released label 24440 to LSD
Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 P2MP label withdraw msg to 10.79.196.14:0 Success
Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 remove
Dec 28 13:16:28.557 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 P2MP label release from 10.79.196.14:0 label 24440 root 10.79.196.14 Opaque Len 7

Configuración del temporizador FRR para LSPs MLDP de escala

En una configuración escalada con más de 500 LSPs, cuando se produce una FRR, el protocolo de gateway de Internet unidifusión (IGP) puede converger más rápido que las actualizaciones de multidifusión (LMRIB a FIB) para las actualizaciones de etiquetas mLDP. Como resultado, la FIB puede marcar el bit FRR en 2 segundos después de un evento FRR, donde la programación de hardware de etiquetas mLDP no está completa en la tarjeta de línea de salida, alojando la trayectoria de respaldo. El tiempo de espera FRR es de forma predeterminada de 2 segundos.

Se recomienda aumentar este tiempo de espera de FRR en una configuración escalada.

El comando frr-holdtime configura el tiempo de espera FRR para que sea proporcional al número de escala de los LSP. El valor de frr-holdtime recomendado es el mismo o menor que el temporizador de retraso MBB. Esto garantiza que la tarjeta de línea de salida esté en estado FRR después del evento de caída de la trayectoria principal. Cuando no está configurado, el frr-holdtimer predeterminado, en segundos, se establece en 2.

Este comando se introdujo en 5.3.2.

RP/0/RSP1/CPU0:ASR-9906#conf t

RP/0/RSP1/CPU0:ASR-9906(config)#cef platform ?
  lsm  Label-switched-multicast parameters

RP/0/RSP1/CPU0:ASR-9906(config)#cef platform lsm ?
  frr-holdtime  Time to keep FRR slots programmed post FRR

RP/0/RSP1/CPU0:ASR-9906(config)#cef platform lsm frr-holdtime ?

  <3-180>  Time in seconds

Conclusión

MBB puede trabajar para evitar la pérdida de tráfico multicast para el re-ruteo en el caso de la convergencia de ruteo y en el caso de proteger el tráfico en el caso de un link que se cae, cuando se vuelve a conmutar el tráfico multicast de la trayectoria de respaldo a una trayectoria nativa.

MBB debe estar configurado para activarlo. Se debe configurar en todos los routers.

Debe haber un retraso de reenvío MBB configurado de varios segundos para permitir la instalación del árbol mLDP recién señalado en el plano de reenvío antes de reenviar el tráfico desde ese árbol mLDP.