Solucionar problemas do Make-Before-Break (MBB) para mLDP

Introdução

Este documento descreve o comportamento de Make-Before-Break (MBB) no Cisco IOS^® XR.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

• Este documento é específico do Cisco IOS^® XR, mas não está restrito a uma versão de software ou hardware específico.
• Todos os dispositivos usados neste artigo executam o Cisco IOS XR 6.5.2. Todas as placas de linha são placas de linha ASR9k de terceira ou quarta geração.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O Make-Before-Break (MBB) tem uma finalidade: configurar uma nova árvore mLDP (Multipoint Label Distribution Protocol) antes de destruir a árvore antiga e alternar o tráfego da árvore antiga para a nova sem perder o tráfego de multicast. Isso pode ser usado em dois cenários:

1. Quando o novo roteamento ocorre quando um novo caminho se torna disponível com uma melhor métrica IGP (Interior Gateway Protocol): alterne o tráfego da árvore antiga para a nova e exclua a árvore antiga.
2. Quando o tráfego multicast é protegido em um caminho de backup: alterne o tráfego do caminho de backup para a árvore mLDP nativa recém-sinalizada e exclua a árvore de backup.

Se o roteador souber que o antigo LSP (Label Switched Path, Caminho Comutado de Rótulo) foi interrompido, ele não deverá esperar para começar a usar o novo LSP. Esperar não faz sentido aqui, pois não há mais tráfego chegando à árvore antiga. Se a árvore antiga ainda estiver funcionando, o roteador não deverá derrubar a árvore antiga até que a nova árvore esteja totalmente configurada.

Teoria

O MBB é orientado por um mecanismo de consulta e confirmação, conforme descrito no RFC 6388. Este é o RFC base do mLDP. Esse mecanismo de consulta e confirmação sinaliza quando a nova árvore está pronta para encaminhar tráfego multicast. Dessa forma, não deve haver nenhuma perda de pacotes. Se o roteador souber que o LSP antigo está quebrado, ele não deverá esperar para começar a usar o novo LSP. Esperar não faz sentido aqui, pois não há mais tráfego chegando à árvore antiga. Se a árvore antiga ainda estiver funcionando, o roteador não deverá derrubar a árvore antiga até que a nova árvore esteja totalmente configurada.

Os casos em que o MBB pode ajudar são:

• A árvore existente está sendo roteada novamente devido a uma alteração na topologia, a um evento de link ativo ou a uma redução no custo IGP de um link,
• Revertendo novamente para uma árvore mLDP nativa, depois de receber o tráfego multicast em um caminho de túnel TE/LFA (Alternativa sem loop) ou Ti-LFA (LFA independente de topologia) ativamente protegido.

Observe que esses dois representam bons eventos.  Um exemplo de um evento ruim seria um link diretamente conectado desativado em um roteador no caminho de upstream. A MBB não pode ajudar neste caso. O IP FRR (Fast ReRoute) é necessário neste caso.
Quando ocorre MBB, há temporariamente mais de um vizinho upstream e/ou mais de um vizinho downstream.  No RFC 6388, é especificado que pode haver vários elementos de aceitação. Isso significa que pode haver vários vizinhos de upstream e valores de rótulo de upstream por árvore. Um "elemento de aceitação" significa que o vizinho mLDP de upstream é um candidato para aceitar tráfego no. Um elemento de aceitação é o elemento ativo. O elemento ativo é aquele para o qual o rótulo MPLS é instalado no plano de encaminhamento. O outro elemento de aceitação é o elemento inativo. Este elemento é aquele para o qual a etiqueta MPLS ainda não está instalada no plano de encaminhamento. Esse elemento inativo é o da parte recém-sinalizada da árvore com o mecanismo Consulta/Confirmações e deve ter vida curta, antes de passar a ser o elemento de aceitação ativo. Pode haver apenas dois elementos de aceitação por árvore: um é o ativo, o outro é o inativo. Assim que a sinalização Query/Ack terminar ou um atraso de tempo fixo for atingido, os vizinhos antigos serão removidos da árvore.
Em vez do mecanismo Query/Ack, a outra opção de implementação poderia ser apenas atrasar o switchover para o novo LSP por um atraso fixo configurável.

É importante observar que o mLDP compartilha o espaço de rótulo atribuído a downstream que o unicast usa e, portanto, para o plano de encaminhamento MPLS, não há, em essência, nenhuma diferença entre pacotes multicast ou pacotes unicast. Como o plano de encaminhamento é compartilhado com unicast, certos recursos unicast são herdados para multicast, como o IP FRR.

Os procedimentos MBB aplicam-se a árvores P2MP (ponto a multiponto) e MP2MP (multiponto a multiponto).

Mecanismo MBB Query e Ack

O MBB é opcional (também é opcional no RFC), portanto deve ser configurado para que seja ativado. Quando configurado, pode haver um status MBB anexado à mensagem de mapeamento de rótulo enviada upstream e também pode ser anexado a uma mensagem de notificação LDP enviada por um roteador upstream para o roteador downstream. Um roteador pode anexar um Status MBB em um TLV de Status MP LDP.

 O status de MBB é um tipo do elemento de valor de status de MP do 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MBB Type = 1  |      Length = 1               | Status Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

O Código de Status é 1 para uma solicitação MBB e 2 para um MBB ack.

O LDP MP Status TLV é codificado da seguinte maneira:

       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                               |
      ~                                                               ~
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

O campo Valor contém um ou mais elementos de Valor de Status MP do LDP.
O elemento de valor de status MP do LDP que está incluído no valor TLV de status MP do LDP tem a próxima codificação:

       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 ...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      ~                                                               ~
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

O LDP MP Status TLV pode aparecer em uma mensagem Label Mapping ou em uma mensagem LDP Notification.

Em uma mensagem de notificação 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                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Em uma Mensagem de Mapeamento de Rótulo:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A anterior descreve o comportamento dinâmico do MBB. Outra opção é ter um comportamento estático em que o switchover para a nova árvore é determinado apenas por um atraso. Nesse caso, o switchover ocorre uma certa quantidade de (milissegundos) segundos depois que a nova árvore está pronta.

A Imagem 1 representa uma captura no Wireshark da mensagem mLDP Label Mapping. Há um LDP MP Status TLV anexado.

Imagem 1

01000102 decodifica para 1 para MBB Tipo 1, 0001 para Comprimento 1 e 02 para MBB Ack.

Observe que o mecanismo MBB se aplica ao FEC mLDP P2MP (Forwarding Equivalence Class) e aos FECs upstream ou downstream de MP2MP.

Capacidade de MBB

Um roteador capaz de executar MBB anuncia isso em um anúncio de capacidade de MBB na sessão LDP para seus vizinhos.

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

O MBB não está habilitado por padrão para o Cisco IOS XR.

O comando "make-before-break" ativa o recurso e o anúncio de capacidade.

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

O MBB não tem um atraso por padrão. Somente em uma configuração dimensionada, o atraso deve ser aumentado. O motivo é que com muitas entradas de banco de dados mLDP pode haver muitas entradas de encaminhamento mLDP que precisam ser instaladas. O tempo para instalar essas entradas de encaminhamento no plano de dados das placas de linha pode levar algum tempo.

Atraso de MBB

Veja a imagem 2.

Imagem 2

Há a árvore antiga e a árvore recém-sinalizada. O roteador onde as duas árvores se ramificam é o Ponto de Reparo Local (PLR). O roteador onde as duas árvores se mesclam novamente é o Ponto de Mesclagem (MP). A nova parte da árvore mLDP é sinalizada devido à descoberta de um caminho melhor pelos roteadores. O novo link R4 - R2 tornou-se disponível ou a métrica IGP nesse link foi reduzida para produzir um caminho com uma métrica geral mais baixa.

Você pode configurar dois valores de atraso para MBB. O primeiro é o atraso quando o MBB é usado para fazer com que o switchover MP retorne a um caminho nativo. Este é o tempo após o recebimento do retorno de MBB.

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

Um atraso de zero significa que o caminho recém-sinalizado é imediatamente usado depois que o MBB Ack é recebido no roteador onde o caminho antigo e o novo são diversos, o PLR. O segundo é o atraso para a exclusão do caminho de backup depois que o MP tiver mudado para o caminho nativo. 

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 o atraso de switchover quanto o atraso de exclusão são usados no MP.

MBB para Redirecionamento

A MBB cuida da montagem de uma nova árvore mLDP antes que a antiga seja derrubada. Isso só fará sentido se a árvore antiga ainda estiver presente e encaminhando o tráfego. Uma convergência de IGP, como um evento de link up, pode produzir um caminho melhor para a árvore mLDP. Isso significa uma métrica IGP menor em direção à raiz, ou em direção à folha, se for uma árvore mLDP MP2MP.

Veja um exemplo.

A imagem 3 mostra uma rede antes do evento de convergência de roteamento.

Imagem 3

R5 é o roteador raiz de uma árvore mLDP e R6 é o roteador folha. Uma árvore mLDP P2MP é sinalizada com uma mensagem Label Mapping (incluindo um rótulo MPLS), de cada roteador em direção à raiz. Essa mensagem de Mapeamento de rótulo LDP não transporta uma Solicitação MBB.

O tráfego mLDP vai da esquerda (raiz) para a direita (folha) sobre o caminho superior. Em cada link, o rótulo MPLS indicado está na parte superior do pacote multicast.

A imagem 4 mostra a rede após o evento de convergência de roteamento (sem MBB).

Imagem 4

O link R4 - R2 está ativo agora. A métrica desse link é de um valor baixo para que o caminho inferior tenha uma métrica inferior ao caminho superior. Duas coisas precisam acontecer: a adjacência IGP precisa ser estabelecida no link e a sessão LDP precisa ser estabelecida também nesse novo link. Quando essa sessão LDP estiver ativa, a mensagem Label Mapping será trocada por esse link para mover a árvore mLDP de cima para baixo.

Se o MBB não estiver configurado, haverá sinalização regular com mensagens de Mapeamento de rótulo LDP no caminho inferior. Assim que a mensagem Label Mapping (sem uma solicitação MBB) chegar a R1, o R1 pára de encaminhar o tráfego multicast no caminho superior e começa a encaminhar o tráfego multicast no caminho inferior.

No final, R1 nunca encaminhou o tráfego multicast pelos dois caminhos, mas apenas por um: ele trocou o tráfego de cima para baixo. O switchover é imediato, o que pode levar a um curto período de tráfego multicast descartado devido ao fato de que a sinalização do plano de controle de R2 para R1 sobre R4 pode ser um pouco mais rápida do que o tempo necessário para que as entradas mLDP sejam instaladas no plano de dados nos roteadores no novo caminho.

Há notificação de log mLDP habilitada explicitamente.

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

Se o MBB estiver configurado, temos o seguinte.

Observe que não é suficiente apenas configurar o MBB em R1.

Este é um exemplo de configuração em R2:

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

Você gostaria que o R2 atrasasse o switchover do caminho antigo para o novo com 60 segundos quando a sessão LDP no link R4-R2 estiver ativa. Isso não acontece. Você precisa ter o MBB habilitado em cada roteador (ou pelo menos R1, R4 e R2) para ter a sinalização MBB funcionando entre R2 e R1 através de R4.

Você precisa ter essa configuração mínima em cada roteador para ter a sinalização MBB habilitada.

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

Veja a imagem 5.

Imagem 5

Todas as configurações corretas estão em vigor. Vemos os acontecimentos desde o início, portanto a situação antes do acontecimento de convergência.

O caminho superior ativo é o início. Em R1, R3 é o único cliente downstream.

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

Em R2, R3 é o único elemento de aceitação.

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

Após a sinalização MBB, R2 tem dois elementos de aceitação, um ativo e um inativo.

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 tem dois clientes downstream, R3 e 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á encaminhando em ambos os caminhos:

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 agora tem dois vizinhos de upstream, um ativo (R3) e um inativo (R4). Essa fase está lá por 60 segundos, o tempo de atraso de encaminhamento.

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 o rótulo local para cada árvore mLDP é diferente. Assim, R2 não tem problema para diferenciar o tráfego mLDP de entrada e identificar qual pacote mLDP de entrada pertence a qual árvore mLDP. O R2 encaminha o tráfego de uma árvore por vez. O flag ED significa 'Queda de Saída' e significa que os pacotes que chegam com rótulo 24009 são descartados. Esses são os pacotes na árvore para os quais o elemento de aceitação está inativo. Não há tráfego duplicado chegando aos receptores!

Observe que o rótulo de saída para cada árvore mLDP em R2 é o mesmo. Assim, para R6, um roteador downstream de R2, ele não pode distinguir se o tráfego veio sobre o caminho antigo original (superior) ou o novo caminho (inferior) após o novo roteamento.

Após 60 segundos, R2 pára de encaminhar o tráfego do caminho superior e inicia o tráfego do caminho 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 tem apenas um cliente downstream, 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 tem apenas um vizinho upstream:

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

O rastreamento mLDP em R2 mostra que a sinalização MBB foi usada, que houve um atraso de 60 segundos antes de alternar do caminho antigo para o novo caminho e um atraso subsequente de 0 segundo para excluir o caminho antigo. Depois disso, R2 envia uma mensagem Label Withdraw para R3 para o caminho antigo e recebe uma mensagem Label Release de R3 como uma resposta.

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 proteção

A proteção mLDP é composta por duas partes principais: a própria proteção e MBB (Make-Before-Break).

Proteção

A proteção do tráfego mLDP é semelhante aos mecanismos de proteção do tráfego MPLS unicast. Assim que uma falha de link é detectada, o roteador PLR comuta o tráfego multicast das árvores que atravessam esse link para o caminho de backup. Esse caminho de backup é um caminho pré-calculado que é instalado no plano de encaminhamento. Assim, assim que a falha ocorrer, o tráfego multicast pode ser comutado imediatamente para o caminho de backup.

A proteção é somente para link inativo. Não há proteção de nó para mLDP.

O evento de link inativo deve ser detectado muito rapidamente. Isso significa que o BFD (Detecção de encaminhamento bidirecional) deve ser usado.

MBB

Após o início da proteção, o tráfego multicast não fica no caminho de backup para sempre. O tráfego deve ser comutado para uma árvore/caminho mLDP nativo recém-calculado. Esse switchover deve ocorrer de forma que nenhum tráfego multicast seja perdido. O MBB é usado para isso, de modo que o tráfego só é comutado quando a árvore recém-sinalizada está completamente configurada e está encaminhando o tráfego. O roteador MP pode, então, comutar com segurança o encaminhamento do tráfego da antiga árvore de backup para a árvore recém-sinalizada sem perda de tráfego.

Teoria da proteção mLDP

Veja a imagem 6. Ele mostra uma rede com um link R1 - R2 que é protegido com Ti-LFA.

Imagem 6

O tráfego mLDP é encaminhado pelo link R1 - R2. O FRR calcula e instala um caminho de backup via R3.

Veja a imagem 7.

Imagem 7

A imagem 7 mostra a situação quando a proteção está ativa.

Quando o link R1 - R2 é desativado, a sessão LDP através dele é mantida ativa pela proteção de sessão LDP. A sessão LDP - que é uma sessão TCP - faz o reroteamento em R3. Isso evita que as vinculações de rótulo para LDP e mLDP entre R1 e R2 sejam removidas. Para que essa sessão LDP possa ser roteada por R3 e ser multi-hop, ela deve ser uma sessão LDP de destino. Isso é feito automaticamente quando a proteção de sessão LDP é configurada.

Quando o link R1 - R2 fica inativo, o tráfego mLDP pode ser roteado novamente de forma rápida sobre R3. Para que isso funcione, deve haver alguma forma de proteção em R1 para a rota em direção ao LDP router-ID de R2. Isso é obtido ativando os túneis de Engenharia de Tráfego MPLS, LFA (Loop-free Alternate) ou Ti-LFA (Topology Independent LFA). O tráfego multicast de R1 para R2 tinha um rótulo mLDP. Quando o link R1 - 2 fica inativo, o tráfego multicast recebe um rótulo extra quando enviado para R2. Há um Penultimate Hop Popping (PHP), de modo que o tráfego é encaminhado com um rótulo para R2. R2 recebe esse tráfego com o mesmo rótulo de quando o link R1 - R2 estava ativo. O R2 continua encaminhando esse tráfego multicast.

Essa proteção é rápida. Embora haja proteção para o tráfego mLDP, o R2 começa a sinalizar um novo caminho nativo dele em direção ao R1 por meio do R3. R2 envia uma mensagem de mapeamento de rótulo mLDP para R3. R3 faz o mesmo em relação a R1. Este é o mesmo processo/sinalização como sempre ao criar um novo caminho mLDP. Enquanto essa sinalização está acontecendo, o R2 continua encaminhando o tráfego do caminho mLDP de backup. Quando o R2 começa a encaminhar o tráfego do caminho nativo recém-criado? O acionador pode ser duas coisas: um atraso cronometrado ou um acionador de sinalização. O atraso cronometrado é algo configurado. O disparador de sinalização é o comportamento Make-Before-Break (MBB) introduzido no mLDP e especificado no RFC 6388. Quando o R2 recebe o sinal do R1, ele indica que o caminho mLDP nativo recentemente está pronto, de modo que o R2 pode começar a encaminhar o tráfego desse novo caminho mLDP e parar de encaminhar o tráfego do caminho de backup.

R1 é chamado de PLR (Point-of-Local-Repair, ponto de reparo local), é o roteador onde o caminho protegido e o caminho nativo recém-sinalizado se ramificam. R2 é o MP (Ponto de Mesclagem), o roteador onde o caminho protegido e o caminho nativo recém-sinalizado se mesclam novamente.

Veja a imagem 8.

Imagem 8

A imagem 8 mostra que há uma mensagem mLDP Label Mapping de R2 para R3 e de R3 para R1. Esta mensagem de Mapeamento de Rótulo tem a Solicitação MBB.

Veja a imagem 9.

Imagem 9

R1 responde essa sinalização com uma Notificação LDP, transportando a confirmação MBB na direção inversa. Então, descendo a árvore. Essa mensagem viaja de R1 para R3 e de R3 para R2. Isso sinaliza para R2, o roteador MP, que o novo caminho mLDP nativo está pronto. Nesse ponto, R1 encaminha o tráfego mLDP duas vezes, uma no caminho de backup e outra no novo caminho nativo

O MBB é usado aqui para ter o switchover MP (R2) de volta para um caminho nativo (que acabou de ser criado). Quando o MBB tiver concluído a parte de sinalização, o MP interromperá o encaminhamento do tráfego mLDP que chega do caminho de backup e começará a encaminhar o tráfego do caminho nativo recém-sinalizado. O MBB é usado aqui para indicar quando esse caminho recém-sinalizado está pronto. Outra possibilidade é configurar um atraso. Nesse caso, o MP pára de encaminhar o tráfego mLDP que chega do caminho de backup e começa a encaminhar o tráfego do caminho nativo recém-sinalizado depois que o MBB sinalizou que esse novo caminho nativo está pronto e após o temporizador de atraso configurado.

Quando R2 começa a encaminhar o tráfego do novo caminho nativo, ele para de encaminhar o tráfego do caminho de backup e sinaliza a destruição do caminho de backup enviando uma mensagem LDP Label Withdraw para a árvore (e uma mensagem LDP Label Release).

Um retardo de exclusão adicional pode ser adicionado para remover a árvore antiga, a fim de permitir que a plataforma programe todo o estado de encaminhamento para as placas de linha.

Depois disso, há apenas a árvore nativa recém-sinalizada. Observe a imagem 10 para ver o encaminhamento do tráfego mLDP nesse caso.

Imagem 10

Observe que o tráfego mLDP tem um rótulo MPLS no topo novamente.

Configuração necessária

Os próximos três itens de configuração são necessários para que o mLDP FRR (Fast ReRoute) funcione.

Você precisa de:

- Encaminhamento recursivo para mLDP habilitado

- Proteção de sessão LDP habilitada

- LFA (Loop-free Alternate) ou Ti-LFA (Topology Independent LFA) sob o IGP (Ti-LFA requer roteamento de segmento). A engenharia de tráfego ponto-a-ponto também é possível.

Se qualquer um desses três estiver ausente, não haverá proteção de FRR para mLDP. O mLDP protege apenas contra falhas de link, não contra falhas de nó.

Exemplo de configuração

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
   !
  !
 !

O comando make-before-break é opcional.

Verifique se a interface de saída está protegida por LFA ou 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
  !

Não há impacto na proteção do tráfego multicast se qualquer um dos roteadores ao longo do novo caminho nativo não tiver MBB configurado. A proteção depende apenas da configuração da proteção de sessão LDP, do encaminhamento recursivo e do FRR, no PLR. A configuração de MBB nos roteadores de caminho recém-nativos somente tem uma consequência quando o tráfego é comutado do caminho de backup para a árvore recém-sinalizada. Se um roteador mLDP recebeu uma mensagem Label Mapping com solicitação MBB de um roteador downstream e precisa enviar uma mensagem Label Mapping para um roteador upstream, mas esse roteador upstream não tem MBB habilitado, o roteador mLDP envia uma mensagem LDP Notification para esse roteador downstream assim que ele envia a mensagem Label Mapping (sem a solicitação MBB) para o roteador upstream. Como tal, uma árvore mLDP regular é o resultado.

Exemplo de MBB para FRR

Veja a imagem 11 para a topologia.

Imagem 11

Quando o link falha entre R1 e R2, a sessão mLDP entre eles é protegida por uma sessão de destino LDP entre eles sobre R3. Assim, a sessão mLDP entre R1 e R2 permanece ativa mesmo quando o link entre eles está inativo. Isso protege as vinculações de rótulo mLDP entre elas, elas são mantidas. Quando o link R1-R2 é desativado, o plano de encaminhamento imediatamente alterna: o link de saída R1-R2 alterna para o link R1-R3 de forma muito rápida, graças ao MPLS TE, LFA ou Ti-LFA de ponto a ponto no lugar. Esse TE, LFA ou Ti-LFA de MPLS P2P deve proteger em R1 a rota para o ID do roteador LDP de R2 para comutar as entradas de encaminhamento para mLDP de maneira correta. Finalmente, o encaminhamento recursivo é necessário porque a sessão mLDP alterna de uma sessão diretamente conectada para uma sessão remota, onde o ID do roteador LDP é resolvido de forma recursiva.

R1 é chamado de PLR (Point-of-Local-Repair, ponto de reparo local), é o roteador onde o caminho protegido e o caminho nativo recém-sinalizado se ramificam. R2 é o MP (Ponto de Mesclagem), o roteador onde o caminho protegido e o caminho nativo recém-sinalizado se mesclam novamente.

Verifique os três requisitos:

-proteção LDP

Para o vizinho LDP (mLDP) conectado diretamente sobre Bundle-Ethernet10362, também devem existir helloS direcionados:

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 ou Ti-LFA no IGP

Verifique se a rota para o vizinho LDP router-id tem um caminho de backup. O RIB (Routing Information Base) e o FIB (Forwarding Information Base ou CEF) devem ter este caminho de backup:

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}

-encaminhamento recursivo para mLDP

A entrada do banco de dados mLDP não tem uma interface de saída no LFIB se o encaminhamento recursivo for aplicado:

Sem encaminhamento 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

Com encaminhamento 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 não há mais interface de saída para a entrada de encaminhamento mLDP. Isso torna a solução de problemas um pouco mais difícil.

O MP tem a próxima configuração para mLDP. Observe os temporizadores de 600 e 60 segundos. O PLR tem os mesmos temporizadores. O PLR encaminha o tráfego pelo caminho de backup e pelo caminho nativo por 600 segundos. O atraso de 600 segundos significa que o MP encaminha o tráfego do caminho de backup por 600 segundos, enquanto descarta o tráfego que chega do caminho nativo. 600 segundos é muito tempo para este temporizador. Ele foi usado em um ambiente de laboratório para fornecer tempo suficiente para capturar a saída com comandos show. O atraso de 60 segundos significa que o MP aguarda a exclusão do caminho MBB por 60 segundos depois de começar a encaminhar o tráfego que chega do caminho nativo e descartar o tráfego que chega pelo caminho de backup. O valor correto para esses dois atrasos depende da rede. Ela precisa ser derivada do teste de rede, software e 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 em uso

Observe a imagem 12, ela mostra o encaminhamento enquanto o mLDP está no modo de proteção.

Imagem 12

Antes da interface de saída ser desativada, esta é a entrada LFIB para o LDP router-ID 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 é a entrada do banco de dados da árvore mLDP no 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 é a entrada de encaminhamento mLDP para a árvore:

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 é a entrada de encaminhamento LFIB (Label Forwarding Instance Base) para a árvore:

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

A entrada de encaminhamento mLDP está protegida. A entrada de encaminhamento é protegida por rótulo 100010, a entrada para o ID do roteador 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 é a entrada de encaminhamento no hardware. Os roteadores são 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
…

Existe o FGID (Fabric Group Index, índice de grupos de estrutura) e o FGID de backup. O FGID é usado pela matriz de comutação para encaminhar o tráfego multicast para as placas de linha corretas. Há também o MGID (Multicast Group Identifier). O MGID é usado para encaminhar o tráfego multicast aos elementos de replicação corretos nas placas de linha.

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

É assim que você pode procurar a 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

A interface de saída está inoperante e o MBB está em uso.

A imagem 13 mostra a sinalização.

Imagem 13

R1 agora tem duas entradas de encaminhamento para esta árvore:

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

Há dois clientes mLDP downstream, R2 e 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)

O MP (R2) tem dois vizinhos upstream, um está ativo e o outro está inativo:

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

A interface de backup foi removida em 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

O MP mudou para a árvore nativa recém-sinalizada e está dentro dos 60 segundos antes de excluir a árvore antiga:

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 o estado, depois que a árvore antiga é excluída:

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

O PLR tem apenas um cliente mLDP downstream:

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)

Rastreamento mLDP

O rastreamento mLDP mostra os eventos com mais detalhes.

No PLR

A interface BE10362 fica inativa:

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

O link foi perdido, mas a adjacência de LDP não é perdida, ela é mantida como uma sessão de destino.

As próximas entradas são a nova filial sobre o roteador P (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

O resto é a limpeza. R3 envia a mensagem Label Withdraw e a mensagem Label Release para 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

No MP

A interface para o MP é desativada. A adjacência é perdida no link, mas a adjacência LDP é mantida como uma sessão 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 entra em ação: os 600 segundos são o atraso 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)

O novo caminho através do roteador P é criado:

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

O temporizador de 600 segundos expira:

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

A entrada é excluída após outros 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

O temporizador de atraso de exclusão expira. O R3 envia a mensagem de Retirada de Rótulo e a mensagem de Liberação de Rótulo para 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

Configurar o temporizador de FRR para dimensionar LSPs MLDP

Em uma configuração em escala com mais de 500 LSPs, quando ocorre um FRR, o protocolo de gateway de Internet (IGP - Internet Gateway Protocol) unicast pode convergir mais rápido do que as atualizações de multicast (LMRIB para FIB) para atualizações de rótulo mLDP. Como resultado, a FIB pode marcar o bit de FRR em 2 segundos após um evento de FRR, em que a programação de hardware de rótulo mLDP não é concluída na placa de linha de saída, hospedando o caminho de backup. O tempo de espera de FRR é, por padrão, de 2 segundos.

É aconselhável aumentar esse tempo de espera de FRR em uma configuração dimensionada.

O comando frr-holdtime configura o tempo de espera de FRR para ser proporcional ao número de escala de LSPs. O valor de frr-holdtime recomendado é o mesmo ou menor que o temporizador de atraso MBB. Isso garante que a placa de linha de saída esteja no estado FRR após o evento de caminho principal inativo. Quando não configurado, o frr-holdtimer padrão, em segundos, é definido como 2.

Esse comando foi apresentado na versão 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

Conclusão

O MBB pode funcionar para evitar a perda de tráfego multicast para reroteamento no caso de convergência de roteamento e no caso de proteção de tráfego no caso de um link ficar inoperante, ao alternar de volta o tráfego multicast do caminho de backup para um caminho nativo.

O MBB deve ser configurado para ativá-lo. Ele deve ser configurado em todos os roteadores.

Deve haver um atraso de encaminhamento de MBB configurado de vários segundos para permitir a instalação da árvore mLDP recém-sinalizada no plano de encaminhamento antes de encaminhar o tráfego dessa árvore mLDP.