Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Teoria

Meccanismo query e ACK MBB

Funzionalità MBB

Ritardo MBB

MBB per reindirizzamento

MBB per protezione

Teoria della protezione mLDP

Configurazione richiesta

Esempio di MBB per FRR

MBB in uso

Traccia mLDP

Configurare il timer FRR per i provider di servizi di traduzione multidimensionali (LSP)

Conclusioni

Introduzione

Questo documento descrive il comportamento di Make-Before-Break (MBB) in Cisco IOS® XR.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

- Questo documento è specifico per Cisco IOS® XR, ma non è limitato a una versione software o a un hardware specifico.

- Su tutti i dispositivi menzionati in questo articolo viene eseguito Cisco IOS XR 6.5.2. Tutte le schede di linea sono schede di linea ASR9k di terza o quarta generazione.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Lo scopo di Make-Before-Break (MBB) è quello di impostare una nuova struttura mLDP (Multipoint Label Distribution Protocol) prima di eliminare la struttura precedente e passare dal vecchio al nuovo albero senza perdere il traffico multicast. Può essere utilizzato in due scenari:

1. Quando si verifica il reindirizzamento, quando diventa disponibile un nuovo percorso con una metrica IGP (Interior Gateway Protocol) migliore: passare dal vecchio al nuovo albero e quindi eliminare il vecchio albero.

2. Quando il traffico multicast è protetto su un percorso di backup: passare il traffico dal percorso di backup alla struttura mLDP nativa appena segnalata, quindi eliminare la struttura di backup.

Se il router sa che il vecchio LSP (Label Switched Path) è interrotto, non deve attendere di iniziare a utilizzare il nuovo LSP. Aspettare qui non ha senso, poiché non c'è più traffico che arriva sul vecchio albero. Se il vecchio albero funziona ancora, il router non deve smantellare il vecchio albero fino a quando il nuovo albero non è completamente configurato.

Teoria

L'MBB è guidato da un meccanismo Query and Ack come descritto nella RFC 6388. RFC di base di mLDP. Questo meccanismo Query e ACK segnala quando il nuovo albero è pronto per inoltrare il traffico multicast. In questo modo, non deve verificarsi alcuna perdita di pacchetti. Se il router sa che il vecchio LSP è guasto, non deve attendere di iniziare a utilizzare il nuovo LSP. Aspettare qui non ha senso, poiché non c'è più traffico che arriva sul vecchio albero. Se il vecchio albero funziona ancora, il router non deve smantellare il vecchio albero fino a quando il nuovo albero non è completamente configurato.

I casi in cui MBB può essere utile sono:

- L'albero esistente viene reindirizzato a causa di una modifica della topologia, un evento di collegamento attivo o una riduzione del costo IGP di un collegamento.

- Ripristino di una struttura nativa mLDP, dopo la ricezione del traffico multicast su un percorso TE tunnel/LFA (Alternativo senza loop) o Ti-LFA (LFA indipendente dalla topologia) protetto attivamente.

Notate che questi due eventi rappresentano eventi positivi.  Un esempio di evento negativo è rappresentato da un collegamento collegato direttamente a un router sul percorso upstream. MBB non è in grado di risolvere questo problema. In questo caso, è necessario usare IP FRR (Fast ReRoute).

Quando si verifica l'MBB, esistono temporaneamente più router adiacenti a monte e/o più router adiacenti a valle.  Nella RFC 6388 viene specificato che possono esistere più elementi accettabili. Ciò significa che possono esistere più valori di etichette upstream e adiacenti upstream per albero. Un "elemento di accettazione" indica che il router adiacente del protocollo mLDP a monte è un candidato per l'accettazione del traffico su. Un elemento di accettazione è l'elemento attivo. L'elemento attivo è quello per il quale l'etichetta MPLS è installata nel piano di inoltro. L'altro elemento accettante è l'elemento inattivo. Questo elemento è quello per il quale l'etichetta MPLS non è ancora installata nel piano di inoltro. Questo elemento inattivo è quello per la parte dell'albero segnalata di recente con il meccanismo Query/Ack e deve essere di breve durata, prima di passare a diventare l'elemento di accettazione attivo. Per ogni albero possono esistere solo due elementi accettanti: uno attivo, l'altro inattivo. Al termine della segnalazione Query/Ack o quando viene raggiunto un ritardo fisso, i precedenti elementi adiacenti vengono rimossi dall'albero.

Anziché il meccanismo Query/Ack, l'altra opzione di implementazione potrebbe essere quella di ritardare semplicemente il passaggio al nuovo provider di servizi di traduzione con un ritardo configurabile fisso.

È importante notare che il protocollo mLDP condivide lo spazio delle etichette assegnato a valle che il protocollo unicast utilizza, e quindi per il piano di inoltro MPLS non vi è sostanzialmente alcuna differenza tra pacchetti multicast o pacchetti unicast. Poiché il piano di inoltro è condiviso con unicast, alcune funzionalità unicast vengono ereditate per il multicast, ad esempio FRR IP.

Le procedure MBB si applicano agli alberi P2MP (Point-to-Multipoint) e MP2MP (Multipoint-to-Multipoint).

Meccanismo query e ACK MBB

L'opzione MBB è facoltativa (è facoltativa anche nell'RFC), quindi deve essere configurata per essere abilitata. Quando è configurato, è possibile associare uno stato MBB al messaggio di mappatura delle etichette inviato a monte e a un messaggio di notifica LDP inviato da un router a monte al router a valle. Un router può collegare uno stato MBB in un TLV di stato MP LDP.

Lo stato MBB è un tipo dell'elemento valore stato MP 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   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Il codice di stato è 1 per una richiesta MBB e 2 per una richiesta MBB.

Il TLV di stato MP LDP è codificato come segue:

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                               |

~                                                               ~

|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Il campo Valore contiene uno o più elementi Valore stato MP LDP.

L'elemento Valore stato MP LDP incluso nel valore TLV Stato MP LDP presenta la codifica successiva:

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |

~                                                               ~

|                                                               |

|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Il TLV Stato MP LDP può essere visualizzato in un messaggio di mappatura etichette o in un messaggio di notifica LDP.

In un messaggio di notifica 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                            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In un messaggio di mapping di etichette:

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 precedente descrive il comportamento dinamico dell'MBB. Un'altra opzione consiste nell'avere un comportamento statico in cui il passaggio al nuovo albero è determinato solo da un ritardo. In questo caso, il passaggio avviene un certo numero di (millisecondi)secondi dopo che il nuovo albero è pronto.

L'immagine 1 mostra un'acquisizione in Wireshark del messaggio mlDP Label Mapping. È collegato un TLV di stato MP LDP.

Immagine 1

01000102 decodifica in 1 per MBB di tipo 1, 0001 per la lunghezza 1 e 02 per MBB di tipo ACK.

Notare che il meccanismo MBB si applica alla FEC (Forwarding Equivalence Class) P2MP mLDP e alle FEC Upstream o Downstream MP.

Funzionalità MBB

Un router in grado di eseguire MBB lo annuncia in un annuncio di funzionalità MBB sulla sessione LDP ai router adiacenti.

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 non è abilitato per impostazione predefinita per Cisco IOS XR.

Il comando "make-before-break" abilita la funzionalità e l'annuncio della funzionalità.

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 0

Per impostazione predefinita, all'MBB non è associato alcun ritardo. È necessario aumentare il ritardo solo in un'impostazione scalata. Il motivo è che con molte voci di database mLDP possono essere presenti molte voci di inoltro mLDP da installare. L'installazione di queste voci di inoltro nel piano dati delle schede di linea può richiedere del tempo.

Ritardo MBB

Guardate l'immagine 2.

Immagine 2

C'è il vecchio albero e l'albero appena segnalato. Il router su cui si trovano le due diramazioni è il punto di riparazione locale (PLR). Il router su cui i due alberi si uniscono di nuovo è il punto di unione (MP). La nuova parte dell'albero mLDP viene segnalata perché i router scoprono un percorso migliore. Il nuovo collegamento R4 - R2 è diventato disponibile oppure la metrica IGP su quel collegamento è stata abbassata per produrre un percorso con una metrica globale inferiore.

È possibile configurare due valori di ritardo per MBB. Il primo è il ritardo quando si utilizza MBB per riportare lo switchover MP su un percorso nativo. Questa è l'ora successiva alla ricezione della chiave MBB.

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

<0-600> Forwarding delay in seconds

Un ritardo pari a zero significa che il nuovo percorso segnalato viene utilizzato immediatamente dopo la ricezione dell'ACK MBB sul router in cui il vecchio e il nuovo percorso sono diversi, ossia il PLR. Il secondo è il ritardo per l'eliminazione del percorso di backup dopo che il pannello di gestione è passato al percorso 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>

Sul pannello di gestione vengono utilizzati sia il ritardo di switchover che il ritardo di eliminazione.

MBB per reindirizzamento

MBB si occupa di impostare un nuovo albero mLDP prima di rimuovere quello vecchio. Ciò ha senso solo se il vecchio albero è ancora presente e inoltrando il traffico. Una convergenza IGP, ad esempio un evento di collegamento verso l'alto, può produrre un percorso migliore per l'albero mLDP. Ciò significa una metrica IGP più piccola verso la radice o verso la foglia se si tratta di un albero MP2MP mLDP.

Guardate un esempio.

L'immagine 3 mostra una rete prima dell'evento di convergenza del routing.

Immagine 3

R5 è il router radice di un albero mLDP e R6 è il router foglia. Un albero P2MP mLDP viene segnalato con un messaggio Label Mapping (compresa un'etichetta MPLS), da ogni router verso la radice. Questo messaggio LDP Label Mapping non contiene una richiesta MBB.

Il traffico mLDP va da sinistra (radice) a destra (foglia) sul percorso superiore. In ciascun collegamento, l'etichetta MPLS indicata si trova sopra il pacchetto multicast.

L'immagine 4 mostra la rete dopo l'evento di convergenza del routing (senza MBB).

Immagine 4

Il collegamento R4 - R2 è attivo. La metrica di questo collegamento ha un valore basso, in modo che il percorso inferiore abbia una metrica inferiore rispetto al percorso superiore. Due cose devono accadere: occorre stabilire l'adiacenza dell'IGP sul collegamento e anche la sessione LDP deve essere stabilita su questo nuovo collegamento. Al termine della sessione LDP, il messaggio Label Mapping viene scambiato su questo collegamento in modo da spostare la struttura mLDP dall'alto verso il basso.

Se MBB non è configurato, è presente una segnalazione regolare con i messaggi LDP Label Mapping sul percorso inferiore. Non appena il messaggio Label Mapping (senza una richiesta MBB) raggiunge R1, R1 interrompe l'inoltro del traffico multicast sul percorso superiore e inizia l'inoltro del traffico multicast sul percorso inferiore.

Alla fine, R1 non ha mai inoltrato il traffico multicast sui due percorsi, ma solo su uno: ha commutato il traffico dall'alto al basso. Lo switchover è immediato, il che potrebbe portare a un breve periodo di traffico multicast perso a causa del fatto che la segnalazione del control plane da R2 a R1 su R4 potrebbe essere un po' più veloce del tempo necessario per l'installazione delle voci mLDP nel data plane sui router del nuovo percorso.

Notifica di registrazione mLDP attivata esplicitamente.

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 MBB è configurato, è possibile procedere come segue.

Si noti che non è sufficiente configurare solo MBB su R1.

Questa è una configurazione di esempio in R2:

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 60

!

Si desidera che R2 ritardi il passaggio dal vecchio al nuovo percorso con 60 secondi quando la sessione LDP attraverso il collegamento R4-R2 è attiva. Non succede. Affinché la segnalazione MBB funzioni tra R2 e R1 in R4, è necessario che su ogni router (o almeno R1, R4 e R2) sia abilitato.

Per abilitare la segnalazione MBB, è necessario avere questa configurazione minima su ogni router.

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 0

!

Guardate l'immagine 5.

Immagine 5

È stata predisposta la configurazione corretta. Esaminiamo gli eventi fin dall'inizio, quindi la situazione prima dell'evento di convergenza.

Il percorso superiore attivo è l'inizio. In R1, R3 è l'unico client 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

In R2, R3 è l'unico elemento accettante.

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

Dopo la segnalazione MBB, R2 dispone di due elementi accettanti, uno attivo e uno inattivo.

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 dispone di due client 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

Inoltro di R1 su entrambi i percorsi:

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 ora ha due vicini a monte, uno attivo (R3) e uno inattivo (R4). Questa fase dura 60 secondi, il tempo di ritardo dell'inoltro.

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

Si noti che l'etichetta locale per ogni albero mLDP è diversa. Quindi, R2 non ha problemi a differenziare il traffico mLDP in entrata e a identificare quale pacchetto mLDP in entrata appartiene a quale albero mLDP. R2 inoltra il traffico proveniente da un solo albero alla volta. Il flag ED significa 'Egress Drop' e significa che i pacchetti in arrivo con l'etichetta 24009 vengono scartati. Si tratta dei pacchetti della struttura per i quali l'elemento accettante è inattivo. Non sono presenti duplicati del traffico in arrivo ai destinatari.

Si noti che l'etichetta in uscita per ogni albero mLDP in R2 è la stessa. Pertanto, in R6, un router a valle di R2, non è possibile distinguere se il traffico è arrivato sul vecchio percorso (in alto) originale o sul nuovo percorso (in basso) dopo il reindirizzamento.

Dopo 60 secondi, R2 interrompe l'inoltro del traffico dal percorso superiore e avvia il traffico dal percorso inferiore.

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 dispone di un solo client 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 ha un solo router adiacente a monte:

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

La traccia mLDP in R2 indica che è stata utilizzata la segnalazione MBB, che è stato rilevato un ritardo di 60 secondi prima del passaggio dal vecchio al nuovo percorso e un successivo ritardo di 0 secondi per l'eliminazione del vecchio percorso. A questo punto, R2 invia un messaggio di Ritiro etichetta a R3 per il percorso precedente e riceve un messaggio di rilascio etichetta da R3 come risposta.

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 per protezione

La protezione mLDP è composta da due parti principali: la protezione stessa e MBB (Make-Before-Break).

Protezione

La protezione del traffico MLDP è simile ai meccanismi di protezione del traffico MPLS unicast. Non appena viene rilevato un errore di collegamento, il router PLR passa il traffico multicast proveniente dagli alberi che attraversano il collegamento al percorso di backup. Questo percorso di backup è un percorso precalcolato installato nel piano di inoltro. Pertanto, non appena si verifica un errore, il traffico multicast può essere commutato immediatamente al percorso di backup.

La protezione è solo per il collegamento non attivo. Nessuna protezione dei nodi per mLDP.

L'evento di collegamento non attivo deve essere rilevato molto rapidamente. Ciò significa che è necessario utilizzare il BFD (Bidirectional Forwarding Detection).

MBB

Dopo l'avvio della protezione, il traffico multicast non rimane per sempre sul percorso di backup. Il traffico deve essere commutato su un percorso/albero mLDP nativo appena calcolato. Il passaggio al digitale deve avvenire in modo che non si verifichi alcuna perdita di traffico multicast. Per questa operazione viene utilizzato il protocollo MBB, in modo che il traffico venga commutato solo quando la struttura appena segnalata è completamente configurata e sta inoltrando il traffico. Il router MP può quindi passare in modo sicuro all'inoltro del traffico dalla vecchia struttura di backup alla struttura appena segnalata senza alcuna perdita di traffico.

Teoria della protezione mLDP

Guardate l'immagine 6. Mostra una rete con un collegamento R1 - R2 che è protetto con Ti-LFA.

Immagine 6

Il traffico mLDP viene inoltrato sul collegamento R1 - R2. FRR calcola e installa un percorso di backup tramite R3.

Guardate l'immagine 7.

Immagine 7

L'immagine 7 mostra la situazione in cui la protezione è attiva.

Quando il collegamento R1 - R2 si interrompe, la sessione LDP al suo interno viene mantenuta in vita dalla protezione della sessione LDP. La sessione LDP, che è una sessione TCP, esegue il routing su R3. In questo modo si evita che i binding di etichetta per LDP e mLDP tra R1 e R2 vengano rimossi. Affinché la sessione LDP possa essere instradata su R3 ed essere multi-hop, deve essere una sessione LDP di destinazione. Questa operazione viene eseguita automaticamente quando viene configurata la protezione della sessione LDP.

Quando il collegamento R1 - R2 si interrompe, il traffico mLDP può essere reindirizzato rapidamente su R3. Affinché questa operazione funzioni, è necessario che in R1 sia presente una qualche forma di protezione per il percorso verso l'ID router LDP di R2. Ciò si ottiene abilitando i tunnel MPLS Traffic Engineering, LFA (Loop-Free Alternate) o Ti-LFA (Topology Independent LFA). Il traffico multicast da R1 a R2 aveva un'etichetta mLDP. Quando il collegamento R1 - 2 diventa inattivo, il traffico multicast riceve un'etichetta aggiuntiva quando viene inviato a R2. C'è Penultimate Hop Popping (PHP), quindi il traffico viene inoltrato con un'etichetta verso R2. R2 riceve questo traffico con la stessa etichetta di quando il collegamento R1 - R2 era attivo. R2 continua ad inoltrare questo traffico multicast.

Questa protezione è veloce. Anche se esiste una protezione per il traffico mLDP, R2 inizia a segnalare un nuovo percorso nativo da esso verso R1 attraverso R3. R2 invia quindi un messaggio di mappatura dell'etichetta mLDP a R3. R3 esegue lo stesso verso R1. Si tratta dello stesso processo/segnalazione utilizzato per la creazione di un nuovo percorso mLDP. Mentre questa segnalazione è in corso, R2 continua ad inoltrare il traffico dal percorso mLDP di backup. Quando R2 inizia l'inoltro del traffico dal nuovo percorso nativo creato? Il trigger può essere costituito da due elementi: un ritardo o un trigger di segnalazione. Il ritardo programmato è configurato. Il trigger di segnalazione è il comportamento Make-Before-Break (MBB) introdotto in mLDP e specificato nella RFC 6388. Quando R2 riceve il segnale da R1, indica che il nuovo percorso mLDP nativo è pronto, quindi R2 può iniziare ad inoltrare il traffico proveniente dal nuovo percorso mLDP e interrompere l'inoltro del traffico proveniente dal percorso di backup.

R1 è chiamato PLR (Point-of-Local-Repair), è il router da cui si disconnettono il percorso protetto e il nuovo percorso nativo segnalato. R2 è il MP (Merge Point), il router in cui il percorso protetto e il percorso nativo appena segnalato si uniscono di nuovo.

Guardate l'immagine 8.

Immagine 8

L'immagine 8 mostra un messaggio di mappatura delle etichette mLDP da R2 a R3 e da R3 a R1. Questo messaggio di mapping di etichette contiene la richiesta MBB.

Guardate l'immagine 9.

Immagine 9

R1 risponde a questa segnalazione con una notifica LDP, riportando la conferma MBB in direzione inversa. Quindi, giù per l'albero. Questo messaggio va da R1 a R3 e da R3 a R2. In questo modo, R2, il router MP, viene informato che il nuovo percorso mLDP nativo è pronto. A questo punto R1 inoltra il traffico mLDP due volte, una volta sul percorso di backup e una volta sul nuovo percorso nativo

MBB viene utilizzato in questo caso per riportare lo switchover MP (R2) su un percorso nativo (appena creato). Quando MBB ha terminato la parte di segnalazione, il pannello di gestione interrompe l'inoltro del traffico mLDP in arrivo dal percorso di backup e avvia l'inoltro del traffico dal nuovo percorso nativo segnalato. L'MBB viene utilizzato per indicare quando il nuovo percorso segnalato è pronto. Un'altra possibilità è configurare un ritardo. In tal caso, il pannello di gestione interrompe l'inoltro del traffico mLDP in arrivo dal percorso di backup e avvia l'inoltro del traffico dal nuovo percorso nativo segnalato dopo che l'MBB ha segnalato che il nuovo percorso nativo è pronto e dopo il timer di ritardo configurato.

Quando R2 avvia l'inoltro del traffico dal nuovo percorso nativo, interrompe l'inoltro del traffico dal percorso di backup e segnala la disinstallazione del percorso di backup inviando un messaggio LDP Label Withdraw per la struttura (e un messaggio LDP Label Release).

È possibile aggiungere un ulteriore ritardo di eliminazione per rimuovere la struttura precedente in modo da consentire alla piattaforma di programmare tutto lo stato di inoltro alle schede di linea.

Dopo questo, c'è solo l'albero nativo appena segnalato. Osservare l'immagine 10 per vedere l'inoltro del traffico mLDP in questo caso.

Immagine 10

Notare che il traffico mLDP ha di nuovo un'etichetta MPLS in primo piano.

Configurazione richiesta

Per il corretto funzionamento di mLDP FRR (Fast ReRoute) sono necessari i tre elementi di configurazione successivi.

Sono necessari:

- Inoltro ricorsivo per mLDP abilitato

- Protezione sessione LDP abilitata

- LFA (alternativa senza loop) o Ti-LFA (LFA indipendente dalla topologia) nell'ambito dell'IGP (Ti-LFA richiede il routing dei segmenti). Progettazione del traffico point-to-point è possibile.

Se uno di questi tre elementi non è presente, non è disponibile alcuna protezione FRR per mLDP. mLDP protegge solo da errori di collegamento e non di nodo.

Esempio di configurazione

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

!

!

!

Il comando make-before-break è facoltativo.

Verificare che l'interfaccia in uscita sia protetta da 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

!

Non vi è alcun impatto sulla protezione del traffico multicast se su uno dei router del nuovo percorso nativo non è stato configurato il protocollo MBB. La protezione dipende solo dalla configurazione della protezione della sessione LDP, dell'inoltro ricorsivo e della FRR sul PLR. La configurazione MBB sui router del nuovo percorso nativo ha una conseguenza solo quando il traffico viene spostato dal percorso di backup alla struttura ad albero appena segnalata. Se un router mLDP ha ricevuto un messaggio di mappatura delle etichette con richiesta MBB da un router a valle e deve inviare un messaggio di mappatura delle etichette a un router a monte, ma tale router a monte non dispone di MBB abilitato, il router mLDP invierà un messaggio di notifica LDP a questo router a valle non appena avrà inviato il messaggio di mappatura delle etichette (senza richiesta MBB) al router a monte. Il risultato è un albero mLDP regolare.

Esempio di MBB per FRR

Per la topologia, vedere l'immagine 11.

Immagine 11

Quando il collegamento si interrompe tra R1 e R2, la sessione mLDP tra di essi è protetta da una sessione LDP mirata tra di essi su R3. Pertanto, la sessione mLDP tra R1 e R2 rimane attiva anche quando il collegamento tra di essi non è attivo. In questo modo vengono mantenuti i binding delle etichette mLDP tra di essi. Quando il collegamento R1-R2 si interrompe, il piano di inoltro passa immediatamente: il collegamento in uscita R1-R2 passa al collegamento R1-R3 in modo molto rapido, grazie alla MPLS Point-to-Point TE, LFA o Ti-LFA in posizione. Questo P2P MPLS TE, LFA o Ti-LFA deve proteggere su R1 il percorso verso il router-ID LDP di R2 per poter commutare correttamente le voci di inoltro per mLDP. Infine, l'inoltro ricorsivo è necessario perché la sessione mLDP passa da una sessione connessa direttamente a una sessione remota, in cui l'ID del router LDP viene risolto in modo ricorsivo.

R1 è chiamato PLR (Point-of-Local-Repair), è il router da cui si disconnettono il percorso protetto e il nuovo percorso nativo segnalato. R2 è il MP (Merge Point), il router in cui il percorso protetto e il percorso nativo appena segnalato si uniscono di nuovo.

Verificare i tre requisiti:

-Protezione LDP

Per il router adiacente LDP (mLDP) con connessione diretta su Bundle-Ethernet10362, è necessario attenersi anche a quanto segue:

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 nell'ambito dell'IGP

Verificare che il percorso verso l'ID router adiacente LDP disponga di un percorso di backup. Il percorso di backup dei file RIB (Routing Information Base) e FIB (Forwarding Information Base o CEF) deve essere il seguente:

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}

-inoltro ricorsivo per mLDP

La voce del database mLDP non dispone di un'interfaccia in uscita in LFIB se è applicato l'inoltro ricorsivo:

Senza inoltro ricorsivo:

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 inoltro ricorsivo:

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

Si noti che non esiste più un'interfaccia in uscita per la voce di inoltro mLDP. Questo rende la risoluzione dei problemi un po' più difficile.

Il pannello di gestione ha la successiva configurazione per mLDP. Notare i timer 600 sec e 60 sec. Il PLR ha gli stessi timer. Il PLR inoltra il traffico sul percorso di backup e il percorso nativo per 600 secondi. Il ritardo di 600 secondi indica che il MP inoltra il traffico dal percorso di backup per 600 secondi, mentre elimina il traffico in arrivo dal percorso nativo. 600 secondi sono un tempo lungo per questo timer. È stato usato in un ambiente lab per avere il tempo sufficiente per acquisire l'output con i comandi show. Il ritardo di 60 secondi indica che il pannello di gestione attende l'eliminazione del percorso MBB per 60 secondi dopo aver iniziato l'inoltro del traffico in arrivo dal percorso nativo e l'eliminazione del traffico in arrivo sul percorso di backup. Il valore corretto per questi due ritardi dipende dalla rete. Deve essere derivato dal test della rete, del software e dell'hardware specifici.

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 in uso

L'immagine 12 mostra l'inoltro mentre mLDP è in modalità di protezione.

Immagine 12

Prima che l'interfaccia in uscita sia inattiva, questa è la voce LFIB per l'ID 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.

Questa è la voce del database della struttura mLDP sul 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

Questa è la voce di inoltro mLDP per la struttura:

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)

Voce di inoltro LFIB (Label Forwarding Instance Base) per la struttura:

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 voce di inoltro mLDP è protetta. La voce di inoltro è protetta dall'etichetta 100010, la voce per l'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

Voce di inoltro nell'hardware. I router sono 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

…

Sono disponibili il FGID (Fabric Group Index) e il FGID di backup. Il FGID viene utilizzato dal fabric dello switch per inoltrare il traffico multicast alle schede di linea corrette. È inoltre disponibile l'identificatore MGID (Multicast Group Identifier). Il MGID viene utilizzato per inoltrare il traffico multicast agli elementi di replica corretti sulle schede di linea.

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

Di seguito viene riportata la procedura per cercare la voce 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

L'interfaccia in uscita è inattiva e MBB è in uso.

L'immagine 13 mostra la segnalazione.

Immagine 13

R1 dispone ora di due voci di inoltro per questo albero:

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

Esistono due client 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)

Il pannello di gestione (R2) ha due vicini a monte, uno attivo e l'altro inattivo:

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

L'interfaccia di backup non è più disponibile su 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

Il pannello di gestione è passato all'albero nativo appena segnalato ed è entro i 60 secondi prima di eliminare il vecchio albero:

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

Dopo l'eliminazione del vecchio albero, è presente lo stato:

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

Il PLR dispone di un solo client 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)

Traccia mLDP

La traccia mLDP mostra gli eventi in modo più dettagliato.

Su PLR

L'interfaccia BE10362 è guasta:

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

Il collegamento è stato perso, ma l'adiacenza LDP non viene persa, ma viene mantenuto come sessione mirata.

Le voci successive sono la nuova filiale sul 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

Il resto è la pulizia. R3 invia il messaggio Ritiro etichetta e il messaggio Rilascio etichetta 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

Nel pannello di gestione

L'interfaccia del pannello di gestione non è attiva. L'adiacenza viene persa sul collegamento, ma l'adiacenza LDP viene mantenuta come sessione avviata:

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

Avvio MBB: il ritardo di switching configurato è 600 secondi

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)

Viene creato il nuovo percorso tramite il router IP:

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

Il timer di 600 secondi scade:

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 voce viene eliminata dopo altri 60 secondi.

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

Il timer di ritardo dell'eliminazione scade. R3 invia il messaggio Ritiro etichetta e il messaggio Rilascio etichetta 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

Configurare il timer FRR per i provider di servizi di traduzione multidimensionali (LSP)

In una configurazione scalabile con più di 500 LSP, quando si verifica una FRR, il protocollo IGP (Internet Gateway Protocol) unicast può convergere più rapidamente rispetto agli aggiornamenti multicast (da LMRIB a FIB) per gli aggiornamenti delle etichette mLDP. Di conseguenza, FIB può contrassegnare il bit FRR in 2 secondi dopo un evento FRR, dove la programmazione hardware delle etichette mLDP non è completa sulla scheda di linea in uscita, ospitando il percorso di backup. Il tempo di attesa FRR è di default di 2 secondi.

Si consiglia di aumentare il tempo di attesa FRR in una configurazione scalabile.

Il comando frr-holdtime configura il tempo di attesa FRR in modo che sia proporzionale al numero di scala dei provider di servizi di traduzione. Il valore di frr-holdtime consigliato è uguale o inferiore al timer di ritardo MBB. In questo modo la scheda di linea in uscita è in stato FRR dopo l'evento percorso primario verso il basso. Se non è configurato, il frr-holdtimer predefinito, in secondi, è impostato su 2.

Questo comando è stato introdotto nella versione 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

Conclusioni

MBB è in grado di prevenire la perdita di traffico multicast per il reindirizzamento in caso di convergenza di routing e in caso di protezione del traffico in caso di interruzione di un collegamento, quando si ripristina il traffico multicast dal percorso di backup a un percorso nativo.

Per attivarlo, è necessario configurare MBB. Deve essere configurato su tutti i router.

Per consentire l'installazione dell'albero mLDP appena segnalato nel piano di inoltro prima di inoltrare il traffico proveniente da tale albero, è necessario configurare un ritardo di inoltro MBB di diversi secondi.