Fehlerbehebung: Make-Before-Break (MBB) für mLDP
Inhalt
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 kennen.
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:
- 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.
- 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, bevor die alte Baumstruktur gelöscht wurde:
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.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
18-Oct-2022 |
IP-Adressierungsüberarbeitung |
1.0 |
04-May-2021 |
Erstveröffentlichung |
Feedback