Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Theorie

MBB-Abfrage- und Bestätigungsmechanismus

MBB-Funktion

MBB-Verzögerung

MBB für Rerouting

MBB zum Schutz

Theorie des mLDP-Schutzes

Erforderliche Konfiguration

Beispiel für MBB für FRR

Verwendete MBB

mLDP-Trace

Konfigurieren des FRR-Timers zur Skalierung von MLDP-LSPs

Schlussfolgerung

Einleitung

In diesem Dokument wird das Verhalten von Make-Before-Break (MBB) in Cisco IOS® XR beschrieben.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

- Dieses Dokument bezieht sich speziell auf Cisco IOS® XR, ist jedoch nicht auf eine bestimmte Softwareversion oder Hardware beschränkt.

- Auf allen in diesem Artikel verwendeten Geräten wird Cisco IOS XR 6.5.2 ausgeführt. Alle Linecards sind ASR9k Linecards der dritten oder vierten Generation.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

Der Zweck von "Make-Before-Break" (MBB) besteht darin, einen neuen mLDP-Tree (Multipoint Label Distribution Protocol) einzurichten, bevor der alte Tree entfernt und der Datenverkehr vom alten zum neuen Tree umgeleitet wird, ohne dass Multicast-Datenverkehr verloren geht. Dies kann in zwei Szenarien verwendet werden:

1. Wenn ein Rerouting auftritt, wenn ein neuer Pfad mit einer besseren IGP-Metrik (Interior Gateway Protocol) verfügbar wird, schalten Sie den Datenverkehr vom alten in den neuen Tree um, und löschen Sie dann den alten Tree.

2. Wenn der Multicast-Datenverkehr auf einem Backup-Pfad geschützt ist: Stellen Sie den Datenverkehr vom Backup-Pfad auf den neu signalisierten nativen mLDP-Tree um, und löschen Sie dann den Backup-Tree.

Wenn der Router weiß, dass der alte LSP (Label Switched Path) defekt ist, darf er nicht warten, bis er den neuen LSP verwendet. Warten macht hier keinen Sinn, da auf dem alten Baum kein Verkehr mehr ankommt. Wenn der alte Baum noch funktioniert, darf der Router den alten Baum erst abreißen, wenn der neue Baum vollständig eingerichtet ist.

Theorie

MBB wird von einem Abfrage- und Bestätigungsmechanismus gesteuert, wie in RFC 6388 beschrieben. Dies ist die Basis-RFC von mLDP. Dieser Abfrage- und Bestätigungsmechanismus signalisiert, wenn der neue Tree für die Weiterleitung von Multicast-Datenverkehr bereit ist. Auf diese Weise darf es nicht zu Paketverlusten kommen. Wenn der Router weiß, dass der alte LSP defekt ist, darf er nicht warten, bis er mit der Verwendung des neuen LSP beginnt. Warten macht hier keinen Sinn, da auf dem alten Baum kein Verkehr mehr ankommt. Wenn der alte Baum noch funktioniert, darf der Router den alten Baum erst abreißen, wenn der neue Baum vollständig eingerichtet ist.

MBB bietet folgende Vorteile:

- Der vorhandene Tree wird aufgrund einer Topologieänderung, eines Linkup-Ereignisses oder einer Reduzierung der IGP-Kosten einer Verbindung umgeleitet.

- Rückkehr zu einem nativen mLDP-Tree nach Empfang des Multicast-Verkehrs über einen aktiv geschützten TE-Tunnel-/LFA-Pfad (Loop-free Alternate) oder Ti-LFA-Pfad (topologieunabhängiges LFA).

Beachten Sie, dass diese beiden Beispiele gute Ereignisse darstellen.  Ein Beispiel für ein fehlerhaftes Ereignis wäre eine direkt verbundene Verbindung, die auf einem Router im Upstream-Pfad abgebaut wird. MBB kann in diesem Fall nicht helfen. In diesem Fall ist IP FRR (Fast ReRoute) erforderlich.

Bei Auftreten von MBB gibt es vorübergehend mehr als einen vorgeschalteten Nachbarn und/oder mehr als einen nachgeschalteten Nachbarn.  In RFC 6388 wird angegeben, dass mehrere übernehmende Elemente vorhanden sein können. Dies bedeutet, dass es mehrere Upstream-Nachbarn und Upstream-Labelwerte pro Tree geben kann. Ein "akzeptierendes Element" bedeutet, dass der Upstream-mLDP-Nachbar ein Kandidat für die Annahme von Datenverkehr ist. Ein akzeptierendes Element ist das aktive Element. Das aktive Element ist das Element, für das das MPLS-Label auf der Weiterleitungsebene installiert ist. Das andere akzeptierende Element ist das inaktive Element. Bei diesem Element ist das MPLS-Label noch nicht auf der Weiterleitungsebene installiert. Dieses inaktive Element ist das Element für den neu signalisierten Teil des Baums mit dem Abfrage-/Bestätigungsmechanismus und muss kurzlebig sein, bevor es zum aktiven akzeptierenden Element wird. Es können nur zwei Elemente pro Baum akzeptiert werden: das eine ist das aktive, das andere das inaktive. Sobald die Abfrage/Ack-Signalisierung beendet ist oder eine feste Zeitverzögerung erreicht ist, werden die alten Nachbarn aus dem Baum entfernt.

Anstelle des Abfrage-/Bestätigungsmechanismus könnte die andere Implementierungsoption darin bestehen, den Wechsel zum neuen LSP nur um eine feste konfigurierbare Verzögerung zu verzögern.

Es ist wichtig zu beachten, dass mLDP den von Unicast verwendeten, Downstream-zugewiesenen Labelraum gemeinsam nutzt und es daher für die MPLS-Weiterleitungsebene im Wesentlichen keinen Unterschied zwischen Multicast- und Unicast-Paketen gibt. Da die Weiterleitungsebene gemeinsam mit Unicast genutzt wird, werden bestimmte Unicast-Funktionen für Multicast übernommen, z. B. IP FRR.

Die MBB-Verfahren gelten für P2MP- (Point-to-Multipoint) und MP2MP- (Multipoint-to-Multipoint) Trees.

MBB-Abfrage- und Bestätigungsmechanismus

MBB ist optional (im RFC ebenfalls optional), muss daher konfiguriert werden, damit es aktiviert werden kann. Bei der Konfiguration kann ein MBB-Status mit der Label Mapping-Nachricht verknüpft werden, die Upstream gesendet wird, und mit einer LDP-Benachrichtigungsnachricht verknüpft werden, die von einem Upstream-Router an den Downstream-Router gesendet wird. Ein Router kann einen MBB-Status in einem LDP MP-Status-TLV anhängen.

Der MBB-Status ist ein Typ des LDP MP-Statuswertelements:

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   |

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

Der Statuscode lautet 1 für eine MBB-Anfrage und 2 für eine MBB-Rack.

Die LDP-MP-Status-TLV ist wie folgt codiert:

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                               |

~                                                               ~

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

|                               |

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

Das Feld "Value" enthält ein oder mehrere LDP MP Status Value-Elemente.

Das LDP MP Status Value Element, das im LDP MP Status TLV Value enthalten ist, hat die nächste Kodierung:

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

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

~                                                               ~

|                                                               |

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

|                               |

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

Die LDP-MP-Status-TLV kann entweder in einer Label-Zuordnungsmeldung oder in einer LDP-Benachrichtigungsmeldung angezeigt werden.

In einer LDP-Benachrichtigungsmeldung:

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 einer Nachricht zur Labelzuordnung:

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            |

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

Im vorherigen Abschnitt wird das dynamische MBB-Verhalten beschrieben. Eine weitere Option ist ein statisches Verhalten, bei dem der Wechsel zum neuen Tree nur durch eine Verzögerung bestimmt wird. In diesem Fall erfolgt der Switchover eine bestimmte Zeit (Milli)Sekunden, nachdem der neue Baum fertig ist.

Abbildung 1 zeigt eine Erfassung der mLDP-Label-Zuordnungsnachricht in Wireshark. Es ist ein LDP-MP-Status-TLV angeschlossen.

Bild 1

01000102 decodiert für MBB Typ 1 auf 1, 0001 für Länge 1 und 02 für MBB Ack.

Der MBB-Mechanismus gilt für die P2MP mLDP FEC (Forwarding Equivalence Class) und die MP2MP Upstream- oder Downstream-FECs.

MBB-Funktion

Ein Router, der MBB ausführen kann, kündigt dies in einer MBB-Funktionsankündigung in der LDP-Sitzung seinen Nachbarn an.

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 ist für Cisco IOS XR nicht standardmäßig aktiviert.

Der Befehl "make-before-break" aktiviert die Funktion und die Funktionsankündigung.

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 0

Der MBB hat standardmäßig keine Verzögerung. Nur in einer skalierten Konfiguration muss die Verzögerung erhöht werden. Der Grund hierfür ist, dass bei vielen mLDP-Datenbankeinträgen möglicherweise viele mLDP-Weiterleitungseinträge installiert werden müssen. Die Installation dieser Weiterleitungseinträge auf der Datenebene der Linecards kann einige Zeit in Anspruch nehmen.

MBB-Verzögerung

Schauen Sie sich Bild 2 an.

Bild 2

Da ist der alte Baum und der neu signalisierte Baum. Der Router, auf den sich die beiden Trees verzweigen, ist der Point of Local Repair (PLR). Der Router, auf dem die beiden Trees wieder zusammengeführt werden, ist der Merge Point (MP). Der neue Teil des mLDP-Trees wird signalisiert, da die Router einen besseren Pfad erkennen. Entweder wurde die neue Verbindung R4 - R2 verfügbar, oder die IGP-Metrik für diese Verbindung wurde gesenkt, um einen Pfad mit einer niedrigeren Gesamtmetrik zu erstellen.

Sie können zwei Verzögerungswerte für MBB konfigurieren. Die erste ist die Verzögerung, mit der der MP-Switchover mithilfe von MBB auf einen nativen Pfad zurückgesetzt wird. Dies ist die Zeit nach dem Empfang des MBB-Backs.

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

<0-600> Forwarding delay in seconds

Eine Verzögerung von Null bedeutet, dass der neu signalisierte Pfad sofort verwendet wird, nachdem die MBB-Bestätigung auf dem Router empfangen wurde, auf dem der alte und der neue Pfad diversifiziert sind, dem PLR. Die zweite ist die Verzögerung für das Löschen des Backup-Pfads, nachdem der MP auf den nativen Pfad umgeschaltet wurde.

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>

Sowohl die Umschaltverzögerung als auch die Löschverzögerung werden auf der VA verwendet.

MBB für Rerouting

MBB richtet einen neuen mLDP-Tree ein, bevor der alte entfernt wird. Dies ist nur sinnvoll, wenn der alte Tree weiterhin vorhanden ist und Datenverkehr weiterleitet. IGP-Konvergenz, z. B. ein Link-up-Ereignis, kann einen besseren Pfad für den mLDP-Tree bereitstellen. Dies bedeutet eine kleinere IGP-Metrik zum Root oder zum Leaf hin, wenn es sich um einen MP2MP mLDP-Tree handelt.

Schauen Sie sich ein Beispiel an.

Abbildung 3 zeigt ein Netzwerk vor dem Ereignis der Routing-Konvergenz.

Bild 3

R5 ist der Root-Router eines mLDP-Tree, R6 der Leaf-Router. Ein P2MP-mLDP-Tree wird mit einer Label Mapping-Nachricht (einschließlich eines MPLS-Labels) signalisiert, und zwar von jedem Router zum Root. Diese LDP-Label-Zuordnungsnachricht enthält keine MBB-Anforderung.

Der mLDP-Datenverkehr verläuft über den obersten Pfad von links (Root) nach rechts (Leaf). An jeder Verbindung befindet sich das angegebene MPLS-Label oben auf dem Multicast-Paket.

Abbildung 4 zeigt das Netzwerk nach dem Routing-Konvergenzereignis (ohne MBB).

Bild 4

Die Verbindung R4 - R2 ist nun aktiv. Die Metrik dieser Verbindung hat einen niedrigen Wert, sodass der untere Pfad eine geringere Metrik hat als der obere Pfad. Zwei Dinge müssen passieren: Die IGP-Adjacency muss über die Verbindung hergestellt werden, und die LDP-Sitzung muss ebenfalls über diese neue Verbindung hergestellt werden. Nach dem Start der LDP-Sitzung wird über diesen Link eine Label Mapping-Nachricht ausgetauscht, um den mLDP-Tree von oben nach unten zu verschieben.

Wenn MBB nicht konfiguriert ist, wird eine regelmäßige Signalisierung mit LDP-Label-Zuordnungsmeldungen im unteren Pfad durchgeführt. Sobald die Label Mapping-Nachricht (ohne MBB-Anforderung) R1 erreicht, stoppt R1 die Weiterleitung des Multicast-Verkehrs auf dem obersten Pfad und beginnt mit der Weiterleitung des Multicast-Verkehrs auf dem untersten Pfad.

Letztlich leitete R1 den Multicast-Datenverkehr nie über die beiden Pfade weiter, sondern nur über einen: Er leitete den Datenverkehr vom obersten zum untersten Pfad um. Der Switchover ist unmittelbar, was dazu führen könnte, dass der Multicast-Datenverkehr kurzzeitig unterbrochen wird, da die Signalisierung der Kontrollebene von R2 zu R1 über R4 etwas schneller sein könnte als die Zeit, die für die Installation der mLDP-Einträge auf der Datenebene der Router auf dem neuen Pfad benötigt wird.

Die mLDP-Protokollierungsbenachrichtigung ist explizit aktiviert.

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

Wenn MBB konfiguriert ist, gilt Folgendes:

Beachten Sie, dass es nicht ausreicht, nur MBB auf R1 zu konfigurieren.

Dies ist eine Beispielkonfiguration auf R2:

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 60

!

Wenn die LDP-Sitzung über die Verbindung R4-R2 aktiv ist, sollte R2 den Wechsel vom alten zum neuen Pfad um 60 Sekunden verzögern. Das passiert nicht. Sie müssen MBB auf jedem Router (oder mindestens R1, R4 und R2) aktivieren, damit die MBB-Signalisierung zwischen R2 und R1 auf R4 funktioniert.

Diese Mindestkonfiguration muss auf jedem Router vorhanden sein, damit die MBB-Signalisierung aktiviert ist.

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 0

!

Schauen Sie sich Bild 5 an.

Bild 5

Alle richtigen Konfigurationen sind vorhanden. Wir betrachten die Ereignisse von Anfang an, also die Situation vor dem Konvergenzereignis.

Der aktive oberste Pfad ist der Start. Auf R1 ist R3 der einzige Downstream-Client.

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

Auf R2 ist R3 das einzige akzeptierende Element.

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

Nach der MBB-Signalisierung weist R2 zwei Empfangselemente auf, eines aktiv, eines inaktiv.

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 hat zwei Downstream-Clients, R3 und R4:

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

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 00:22:35

FEC Root           : 10.0.0.5

Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]

Features           : MBB

Upstream neighbor(s) :

10.0.0.5:0 [Active] [MBB] Uptime: 00:22:35

Local Label (D) : 24008

Downstream  client(s):

LDP 10.0.0.3:0     Uptime: 00:06:20

Next Hop         : 10.1.3.3

Interface        : GigabitEthernet0/0/0/0

Remote label (D) : 24009

LDP 10.0.0.4:0     Uptime: 00:00:36

Next Hop         : 10.1.4.4

Interface        : GigabitEthernet0/0/0/1

Remote label (D) : 24009

R1 wird über beide Pfade weitergeleitet:

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 hat nun zwei vorgeschaltete Nachbarn, einen aktiven (R3) und einen inaktiven (R4). Diese Phase ist für 60 Sekunden da, die Weiterleitungsverzögerung.

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

Beachten Sie, dass die lokalen Bezeichnungen für die einzelnen mLDP-Trees unterschiedlich sind. R2 hat also kein Problem damit, den eingehenden mLDP-Datenverkehr zu differenzieren und zu bestimmen, welches eingehende mLDP-Paket zu welchem mLDP-Tree gehört. R2 leitet den Datenverkehr jeweils nur von einem Tree weiter. Das Flag ED bedeutet "Egress Drop" und bedeutet, dass Pakete, die mit dem Label 24009 eintreffen, verworfen werden. Dies sind die Pakete in der Struktur, für die das übernehmende Element inaktiv ist. Es kommt kein doppelter Datenverkehr an den Empfängern an!

Beachten Sie, dass das ausgehende Label für jeden mLDP-Tree in R2 identisch ist. Für R6, einen Downstream-Router von R2, kann es nach dem Rerouting also nicht unterscheiden, ob der Datenverkehr über den ursprünglichen alten (oberen) oder den neuen (unteren) Pfad übertragen wurde.

Nach 60 Sekunden beendet R2 die Weiterleitung des Datenverkehrs vom obersten Pfad und startet den Datenverkehr vom untersten Pfad.

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 hat nur einen Downstream-Client, 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 hat nur einen Upstream-Nachbarn:

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

Die mLDP-Spur auf R2 zeigt, dass die MBB-Signalisierung verwendet wurde, dass vor dem Umschalten vom alten Pfad auf den neuen Pfad eine Verzögerung von 60 Sekunden und danach eine Verzögerung von 0 Sekunden zum Löschen des alten Pfads auftrat. Danach sendet R2 eine Label Withdraw Nachricht an R3 für den alten Pfad und erhält als Antwort eine Label Release Nachricht von R3.

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 zum Schutz

Der mLDP-Schutz besteht aus zwei Hauptkomponenten: dem Schutz selbst und MBB (Make-Before-Break).

Schutz

Der Schutz des mLDP-Datenverkehrs ähnelt den Schutzmechanismen des Unicast-MPLS-Datenverkehrs. Sobald ein Verbindungsausfall erkannt wird, schaltet der PLR-Router den Multicast-Verkehr von den Bäumen, die diese Verbindung überqueren, auf den Backup-Pfad um. Bei diesem Sicherungspfad handelt es sich um einen vorab berechneten Pfad, der auf der Weiterleitungsebene installiert ist. Sobald der Fehler auftritt, kann der Multicast-Datenverkehr sofort an den Backup-Pfad weitergeleitet werden.

Der Schutz ist nur für den Verbindungsabbau vorgesehen. Es gibt keinen Knotenschutz für mLDP.

Das Link-Down-Ereignis muss sehr schnell erkannt werden. Dies bedeutet, dass BFD (Bidirectional Forwarding Detection) verwendet werden muss.

MBB

Wenn der Schutz aktiviert ist, bleibt der Multicast-Verkehr nicht ewig auf dem Backup-Pfad. Der Datenverkehr muss auf einen neu berechneten nativen mLDP-Tree/Pfad umgeschaltet werden. Dieser Switchover muss so erfolgen, dass kein Multicast-Verkehr verloren geht. Hierfür wird MBB verwendet, sodass der Datenverkehr erst umgeschaltet wird, wenn der neu signalisierte Tree vollständig eingerichtet ist und Datenverkehr weiterleitet. Der MP-Router kann dann die Weiterleitung des Datenverkehrs vom alten Backup-Tree zum neu signalisierten Tree sicher und ohne Datenverlust umschalten.

Theorie des mLDP-Schutzes

Schauen Sie sich Bild 6 an. Es zeigt ein Netzwerk mit einer Verbindung R1 - R2, die mit Ti-LFA geschützt ist.

Bild 6

Der mLDP-Datenverkehr wird über die Verbindung R1 - R2 weitergeleitet. FRR berechnet und installiert einen Backup-Pfad über R3.

Schauen Sie sich Bild 7 an.

Bild 7

Abbildung 7 zeigt die Situation, in der der Schutz aktiv ist.

Wenn die Verbindung R1 - R2 ausfällt, wird die LDP-Sitzung über diese Verbindung durch den LDP-Sitzungsschutz aufrechterhalten. Die LDP-Sitzung, also eine TCP-Sitzung, wird über R3 umgeleitet. Dadurch wird vermieden, dass die Label-Bindungen für LDP und mLDP zwischen R1 und R2 entfernt werden. Damit diese LDP-Sitzung über R3 geroutet werden kann und Multi-Hop sein kann, muss es sich um eine gezielte LDP-Sitzung handeln. Dies erfolgt automatisch, wenn der LDP-Sitzungsschutz konfiguriert ist.

Wenn die Verbindung R1 - R2 ausfällt, kann der mLDP-Datenverkehr schnell über R3 umgeleitet werden. Damit dies funktioniert, muss auf R1 eine Art Schutz für die Route zur LDP-Router-ID von R2 vorhanden sein. Dies wird entweder durch die Aktivierung von MPLS Traffic Engineering-Tunneln, LFA (Loop-free Alternate) oder Ti-LFA (Topology Independent LFA) erreicht. Der Multicast-Datenverkehr von R1 zu R2 verfügte über ein mLDP-Label. Wenn die Verbindung R1-2 ausfällt, erhält der Multicast-Verkehr ein zusätzliches Label, wenn er an R2 gesendet wird. Es gibt Penultimate Hop Popping (PHP), sodass der Datenverkehr mit einem Label an R2 weitergeleitet wird. R2 empfängt diesen Datenverkehr mit demselben Label wie bei Aktivierung der R1-R2-Verbindung. R2 leitet diesen Multicast-Datenverkehr weiter.

Dieser Schutz ist schnell. Während der mLDP-Datenverkehr geschützt ist, signalisiert R2 über R3 einen neuen nativen Pfad von ihm zu R1. R2 sendet also eine mLDP-Label-Zuordnungsnachricht an R3. R3 macht das Gleiche gegenüber R1. Dabei handelt es sich um denselben Prozess bzw. dieselbe Signalisierung wie beim Erstellen eines neuen mLDP-Pfads. Während dieser Signalisierung leitet R2 den Datenverkehr vom Backup-mLDP-Pfad weiter. Wann beginnt R2 mit der Weiterleitung des Datenverkehrs vom neu erstellten nativen Pfad? Der Trigger kann zweierlei sein: eine zeitgesteuerte Verzögerung oder ein Signalisierungs-Trigger. Die zeitgesteuerte Verzögerung ist konfiguriert. Der Signalisierungs-Trigger ist das Make-Before-Break-Verhalten (MBB), das in mLDP eingeführt und in RFC 6388 angegeben wird. Wenn R2 das Signal von R1 empfängt, zeigt es an, dass der neue native mLDP-Pfad bereit ist, sodass R2 mit der Weiterleitung des Datenverkehrs von diesem neuen mLDP-Pfad beginnen und die Weiterleitung des Datenverkehrs vom Backup-Pfad beenden kann.

R1 wird als PLR (Point-of-Local-Repair) bezeichnet und ist der Router, über den der geschützte Pfad und der neu signalisierte native Pfad verzweigen. R2 ist der MP (Merge Point), der Router, bei dem der geschützte Pfad und der neu signalisierte native Pfad wieder zusammengeführt werden.

Schauen Sie sich Bild 8 an.

Bild 8

Abbildung 8 zeigt, dass von R2 bis R3 und von R3 bis R1 eine mLDP-Label-Mapping-Nachricht vorliegt. Diese Labelzuordnungsmeldung enthält die MBB-Anforderung.

Schauen Sie sich Bild 9 an.

Bild 9

R1 beantwortet diese Signalisierung mit einer LDP-Benachrichtigung und überträgt die MBB-Bestätigung in die umgekehrte Richtung. Also, den Baum runter. Diese Nachricht wird von R1 nach R3 und von R3 nach R2 übertragen. Dies signalisiert dem MP-Router R2, dass der neue native mLDP-Pfad bereit ist. An diesem Punkt leitet R1 den mLDP-Datenverkehr zweimal weiter, einmal auf dem Backup-Pfad und einmal auf dem neuen nativen Pfad

MBB wird hier verwendet, um den MP (R2)-Switchover auf einen nativen Pfad zurückzusetzen (der gerade erstellt wurde). Wenn der MBB die Signalisierung abgeschlossen hat, beendet der MP die Weiterleitung des vom Backup-Pfad eingehenden mLDP-Datenverkehrs und beginnt mit der Weiterleitung des Datenverkehrs vom neu signalisierten nativen Pfad. Der MBB wird hier verwendet, um anzugeben, wann dieser neu signalisierte Pfad bereit ist. Eine weitere Möglichkeit besteht darin, eine Verzögerung zu konfigurieren. In diesem Fall beendet der MP die Weiterleitung des vom Backup-Pfad eingehenden mLDP-Datenverkehrs und beginnt mit der Weiterleitung des Datenverkehrs vom neu signalisierten nativen Pfad, nachdem der MBB signalisiert hat, dass dieser neue native Pfad bereit ist, und nach dem konfigurierten Verzögerungs-Timer.

Wenn R2 mit der Weiterleitung des Datenverkehrs vom neuen nativen Pfad beginnt, wird die Weiterleitung des Datenverkehrs vom Backup-Pfad gestoppt, und der Backup-Pfad wird abgebrochen, indem eine LDP Label Withdraw-Nachricht für den Tree (und eine LDP Label Release-Nachricht) gesendet wird.

Um den alten Tree zu entfernen, kann eine zusätzliche Löschverzögerung hinzugefügt werden, damit die Plattform den gesamten Weiterleitungsstatus für die Linecards programmieren kann.

Danach gibt es nur noch den neu signalisierten nativen Baum. In Abbildung 10 sehen Sie, wie der mLDP-Datenverkehr in diesem Fall weitergeleitet wird.

Bild 10

Beachten Sie, dass für den mLDP-Datenverkehr wieder ein MPLS-Label obenauf steht.

Erforderliche Konfiguration

Die nächsten drei Konfigurationselemente sind erforderlich, damit mLDP FRR (Fast ReRoute) funktioniert.

Sie benötigen:

- Rekursive Weiterleitung bei aktiviertem mLDP

- LDP-Sitzungsschutz aktiviert

- LFA (Loop-free Alternate) oder Ti-LFA (Topology Independent LFA) unter dem IGP (Ti-LFA erfordert Segment Routing). Point-to-Point Traffic Engineering ist ebenfalls möglich.

Wenn einer dieser drei Punkte fehlt, gibt es keinen FRR-Schutz für mLDP. mLDP schützt nur vor Verbindungsausfällen, nicht vor Knotenausfällen.

Konfigurationsbeispiel

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

!

!

!

Der Befehl make-before-break ist optional.

Prüfen Sie, ob die ausgehende Schnittstelle durch LFA oder Ti-LFA geschützt ist:

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

!

Der Schutz des Multicast-Verkehrs wird nicht beeinträchtigt, wenn für einen der Router auf dem neuen nativen Pfad kein MBB konfiguriert ist. Der Schutz hängt nur von der Konfiguration des LDP-Sitzungsschutzes, der rekursiven Weiterleitung und des FRR auf dem PLR ab. Die MBB-Konfiguration auf den Routern des neuen nativen Pfads hat nur dann eine Auswirkung, wenn der Datenverkehr vom Backup-Pfad zum neu signalisierten Tree umgeschaltet wird. Wenn ein mLDP-Router eine Label Mapping-Nachricht mit einer MBB-Anforderung von einem Downstream-Router erhalten hat und eine Label Mapping-Nachricht an einen Upstream-Router senden muss, dieser Upstream-Router jedoch MBB nicht aktiviert hat, sendet der mLDP-Router eine LDP-Benachrichtigungsnachricht an diesen Downstream-Router, sobald er die Label Mapping-Nachricht (ohne die MBB-Anforderung) an den Upstream-Router gesendet hat. Das Ergebnis ist ein regulärer mLDP-Tree.

Beispiel für MBB für FRR

Die Topologie ist in Abbildung 11 dargestellt.

Bild 11

Wenn der Link zwischen R1 und R2 ausfällt, wird die mLDP-Sitzung zwischen ihnen durch eine LDP-gezielte Sitzung zwischen ihnen über R3 geschützt. Die mLDP-Sitzung zwischen R1 und R2 bleibt also aktiv, auch wenn die Verbindung zwischen den beiden Geräten unterbrochen ist. Dadurch werden die mLDP-Label-Bindungen zwischen ihnen geschützt, sie bleiben erhalten. Wenn die Verbindung R1-R2 ausfällt, schaltet die Weiterleitungsebene sofort um: Die ausgehende Verbindung R1-R2 schaltet dank der vorhandenen Point-to-Point MPLS TE, LFA oder Ti-LFA sehr schnell auf die Verbindung R1-R3 um. Dieser P2P-MPLS-TE, -LFA oder -Ti-LFA muss auf R1 die Route zur LDP-Router-ID von R2 schützen, damit die Weiterleitungseinträge für mLDP korrekt weitergeleitet werden. Schließlich ist die rekursive Weiterleitung erforderlich, da die mLDP-Sitzung von einer direkt verbundenen Sitzung zu einer Remote-Sitzung wechselt, in der die LDP-Router-ID rekursiv aufgelöst wird.

R1 wird als PLR (Point-of-Local-Repair) bezeichnet und ist der Router, über den der geschützte Pfad und der neu signalisierte native Pfad verzweigen. R2 ist der MP (Merge Point), der Router, bei dem der geschützte Pfad und der neu signalisierte native Pfad wieder zusammengeführt werden.

Überprüfen Sie die drei Anforderungen:

- LDP-Schutz

Für den direkt verbundenen LDP (mLDP)-Nachbarn über das Paket Ethernet10362 müssen außerdem gezielte Hellos vorhanden sein:

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 oder Ti-LFA unter IGP

Überprüfen Sie, ob die Route zur LDP-Nachbarrouter-ID über einen Backup-Pfad verfügt. Für die RIB (Routing Information Base) und die FIB (Forwarding Information Base oder CEF) muss folgender Backup-Pfad verfügbar sein:

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}

- rekursive Weiterleitung für mLDP

Der mLDP-Datenbankeintrag verfügt über keine ausgehende Schnittstelle in der LFIB, wenn eine rekursive Weiterleitung angewendet wird:

Ohne rekursive Weiterleitung:

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

Rekursive Weiterleitung:

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

Beachten Sie, dass es für den mLDP-Weiterleitungseintrag keine ausgehende Schnittstelle mehr gibt. Dies erschwert die Fehlerbehebung.

Die VA verfügt über die nächste Konfiguration für mLDP. Notieren Sie die Timer 600 Sek. und 60 Sek. Der PLR verfügt über dieselben Timer. Der PLR leitet den Datenverkehr über den Backup-Pfad und den nativen Pfad 600 Sekunden lang weiter. Die Verzögerung von 600 Sekunden bedeutet, dass der MP den Datenverkehr vom Backup-Pfad 600 Sekunden lang weiterleitet und dabei den Datenverkehr vom nativen Pfad verwirft. 600 Sekunden sind eine lange Zeit für diesen Timer. Es wurde in einer Laborumgebung verwendet, um genügend Zeit für die Erfassung der Ausgabe mit Show-Befehlen zur Verfügung zu stellen. Die Verzögerung von 60 Sekunden bedeutet, dass der MP 60 Sekunden lang auf das Löschen des MBB-Pfads wartet, nachdem er mit der Weiterleitung des Datenverkehrs vom nativen Pfad und dem Verwerfen des Datenverkehrs über den Backup-Pfad begonnen hat. Der richtige Wert für diese beiden Verzögerungen hängt vom Netzwerk ab. Es muss aus dem Testen des jeweiligen Netzwerks, der Software und der Hardware abgeleitet werden.

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

!

!

!

Verwendete MBB

Abbildung 12 zeigt die Weiterleitung, während sich mLDP im Schutzmodus befindet.

Bild 12

Bevor die ausgehende Schnittstelle ausgefallen ist, ist dies der LFIB-Eintrag für die LDP-Router-ID (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.

Dies ist der mLDP-Tree-Datenbankeintrag auf dem 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

Dies ist der mLDP-Weiterleitungseintrag für den Tree:

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)

Dies ist der LFIB-Weiterleitungseintrag (Label Forwarding Instance Base) für den Tree:

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

Der mLDP-Weiterleitungseintrag ist geschützt. Der Weiterleitungseintrag wird mit dem Label 100010 geschützt, dem Eintrag für die LDP-Router-ID der Außenstelle.

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

Dies ist der Weiterleitungseintrag in der Hardware. Die Router sind ASR9k-Router.

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

…

Es gibt die FGID (Fabric Group Index) und die Backup-FGID. Die FGID wird von der Switch-Fabric verwendet, um den Multicast-Datenverkehr an die richtigen Linecards weiterzuleiten. Es gibt auch die MGID (Multicast Group Identifier). Die MGID wird für die Weiterleitung des Multicast-Datenverkehrs an die richtigen Replikationselemente auf den Linecards verwendet.

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

So können Sie den MGID-Eintrag suchen:

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

Die ausgehende Schnittstelle ist jetzt ausgefallen, und MBB wird verwendet.

Abbildung 13 zeigt die Signalisierung.

Bild 13

R1 verfügt jetzt über zwei Weiterleitungseinträge für diesen Tree:

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

Es gibt zwei Downstream-mLDP-Clients, R2 und 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)

Der MP (R2) hat zwei vorgeschaltete Nachbarn, einer ist aktiv, der andere ist inaktiv:

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

Die Backup-Schnittstelle auf R1 ist deaktiviert:

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

Die VA wechselte zur neu signalisierten nativen Baumstruktur, und dies innerhalb der 60 Sekunden vor dem Löschen der alten Baumstruktur:

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

Nachdem der alte Baum gelöscht wurde, gibt es den Status:

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

Der PLR verfügt nur über einen Downstream-mLDP-Client:

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)

mLDP-Trace

Im mLDP-Trace werden die Ereignisse detaillierter angezeigt.

Über den PLR

Die Schnittstelle BE10362 fällt aus:

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

Die Verbindung wurde unterbrochen, aber die LDP-Adjacency geht nicht verloren. Sie wird als gezielte Sitzung beibehalten.

Die nächsten Einträge sind die neue Verzweigung über den P-Router (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

Der Rest ist die Reinigung. R3 sendet die Nachricht "Label Withdraw" (Label zurückziehen) und die Nachricht "Label Release" (Label-Freigabe) an 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

Auf der VA

Die Schnittstelle zur VA fällt aus. Die Adjacency geht über die Verbindung verloren, aber die LDP-Adjacency wird als angefangene Sitzung beibehalten:

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 delete adj 20003a0/10.254.3.36

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint delete neighbor adj 20003a0/10.254.3.36 objid 0 version 0 Failed

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 LDP Adjacency addr: 10.254.3.36, Interface: Bundle-Ether10362 Delete

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Start path timer for root: 10.79.196.14

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint save neighbor 10.79.196.14:0 canceled, no GR or NSR

Dec 28 13:05:27.152 MLDP GLO 0/RSP1/CPU0 t31488 RIB  : Read notification

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Root paths count 1

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 None 10.79.196.13

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 added (chkpt FALSE)

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 binding list Local Add

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 path changed from None:0.0.0.0 to None:10.79.196.13

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Request label type ACEL ident 10.79.196.13:0 LSD Success

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 RIB  : Notify client 'Root' for prefix: 10.79.196.14/32

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Root 10.79.196.14 path 10.254.1.184 php nh 10.254.1.184 peer 72d83798:10.79.196.13:0

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : mldp_root_get_path: tid e0100000 ifh 0  php_nh 0.0.0.0

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Failed to get intf type for ifh 0x0

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 RIB  : Notify client 'Peer' for prefix: 10.79.196.14/32

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint save neighbor 10.79.196.14:0 canceled, no GR or NSR

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Main Entry LSD label 24441 type ACEL ident 10.79.196.13:0 assigned

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 installed local label 24441

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Neighbor 10.79.196.13:0 not MBB capable or worse metric, ignore MBB code 0

MBB: Die konfigurierte Switchover-Verzögerung beträgt 600 Sekunden.

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)

Der neue Pfad über den P-Router wird erstellt:

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

Der 600-Sekunden-Timer läuft ab:

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

Der Eintrag wird nach weiteren 60 Sekunden gelöscht.

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

Der Zeitgeber für die Löschverzögerung läuft ab. R3 sendet die Nachricht "Label Whitdraw" und die Nachricht "Label Release" an 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

Konfigurieren des FRR-Timers zur Skalierung von MLDP-LSPs

In einer skalierten Konfiguration mit mehr als 500 LSPs kann das Unicast Internet Gateway Protocol (IGP) bei Auftreten einer FRR schneller als Multicast-Updates (LMRIB zu FIB) für mLDP-Label-Updates konvergiert werden. Dadurch kann FIB das FRR-Bit in 2 Sekunden nach einem FRR-Ereignis markieren, wenn die Programmierung der mLDP-Label-Hardware auf der Ausgangs-Linecard, die den Backup-Pfad hostet, nicht abgeschlossen ist. Die FRR-Haltezeit beträgt standardmäßig 2 Sekunden.

Es wird empfohlen, diese FRR-Haltezeit in einer skalierten Konfiguration zu erhöhen.

Mit dem Befehl frr-holdtime wird die FRR-Holdtime proportional zur Skalierungsanzahl der LSPs konfiguriert. Der empfohlene Wert für die Wartezeit vor Anhalten ist entweder gleich oder kleiner als der Wert für die MBB-Verzögerung. Dadurch wird sichergestellt, dass sich die Ausgangs-Linecard nach dem Ausfall des primären Pfads im FRR-Zustand befindet. Wenn diese Option nicht konfiguriert ist, wird der Standard-FRE-Holdtimer in Sekunden auf 2 gesetzt.

Dieser Befehl wurde in 5.3.2 eingeführt.

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

Schlussfolgerung

MBB kann bei Routing-Konvergenz und beim Schutz des Datenverkehrs bei einem Verbindungsausfall den Verlust von Multicast-Datenverkehr für das Rerouting verhindern, wenn der Multicast-Datenverkehr vom Backup-Pfad auf einen nativen Pfad zurückgeschaltet wird.

Um sie zu aktivieren, muss MBB konfiguriert werden. Sie muss auf allen Routern konfiguriert werden.

Es muss eine MBB-Weiterleitungsverzögerung von mehreren Sekunden konfiguriert werden, damit der neu signalisierte mLDP-Tree auf der Weiterleitungsebene installiert werden kann, bevor der Datenverkehr von diesem mLDP-Tree weitergeleitet wird.