Risoluzione dei problemi relativi a Make-Before-Break (MBB) per mLDP
Sommario
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:
- 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.
- 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.
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
18-Oct-2022 |
Revisione indirizzamento IP |
1.0 |
04-May-2021 |
Versione iniziale |
Feedback