Auf dieser Seite
Konfigurieren der Verzögerung, bevor LDP-Nachbarn als nach unten betrachtet werden
Aktivieren strenger zielgerichteter Hello-Nachrichten für LDP
Beispiel: Konfigurieren der längsten Übereinstimmung für LDP
Steuerungsübertragungsadresse, die für zielgerichtete LDP-Sitzungen verwendet wird
Konfigurieren der in LDP angekündigten Präfixe aus der Routing-Tabelle
Konfigurieren einer Fehleraktion für die BFD-Sitzung auf einem LDP-LSP
Beispiel: Konfigurieren von Multicast-Only Fast Reroute in einer Multipoint-LDP-Domäne
Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalübertragung für Point-to-Multipoint-LSPs
LDP Mapping Server for Interoperability of Segment Routing with LDP Overview
LDP-Konfiguration
Minimale LDP-Konfiguration
So aktivieren Sie LDP mit minimaler Konfiguration:
Aktivieren Sie alle relevanten Schnittstellen unter MPLS-Familie. Im Fall von directed LDP muss die Loopback-Schnittstelle mit MPLS-Familie aktiviert werden.
(Optional) Konfigurieren Sie die relevanten Schnittstellen unter der
[edit protocol mpls]
Hierarchieebene.Aktivieren Sie LDP auf einer einzigen Schnittstelle, fügen Sie die
ldp
Anweisung ein und geben Sie die Schnittstelle mithilfe derinterface
Anweisung an.
Dies ist die minimale LDP-Konfiguration. Alle anderen LDP-Konfigurationsanweisungen sind optional.
ldp { interface interface-name; }
Um LDP auf allen Schnittstellen zu aktivieren, geben Sie all
für interface-name
an.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einbeziehen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung.
Aktivieren und Deaktivieren von LDP
LDP ist routinginstanzensensibel. Um LDP auf einer bestimmten Schnittstelle zu aktivieren, fügen Sie die folgenden Anweisungen ein:
ldp { interface interface-name; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einbeziehen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung.
Um LDP auf allen Schnittstellen zu aktivieren, geben Sie all
für interface-name
an.
Wenn Sie Schnittstelleneigenschaften für eine Gruppe von Schnittstellen konfiguriert haben und LDP auf einer der Schnittstellen deaktivieren möchten, fügen Sie die interface
Anweisung mit der disable
Option ein:
interface interface-name { disable; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary.
Konfigurieren des LDP-Timers für Hello-Nachrichten
LDP-Hello-Nachrichten ermöglichen es LDP-Knoten, sich gegenseitig zu erkennen und das Versagen eines Nachbarn oder der Verbindung zum Nachbarn zu erkennen. Hallo Nachrichten werden regelmäßig an allen Schnittstellen gesendet, an denen LDP aktiviert ist.
Es gibt zwei Arten von LDP-Hello-Nachrichten:
"Link Hello"-Nachrichten: Wird über die LDP-Schnittstelle als UDP-Pakete gesendet, die an den LDP-Erkennungsport adressiert sind. Der Erhalt einer LDP-Link-Hallo-Nachricht an einer Schnittstelle identifiziert eine Nachbarschaft zum LDP-Peer-Router.
Zielgerichtete Hallo-Nachrichten: Gesendet als UDP-Pakete, die an den LDP-Erkennungsport an einer bestimmten Adresse adressiert werden. Gezielte Hello-Nachrichten werden zur Unterstützung von LDP-Sitzungen zwischen Routern verwendet, die nicht direkt verbunden sind. Ein gezielter Router bestimmt, ob eine zielgerichtete Hello-Nachricht reagiert oder ignoriert werden soll. Ein gezielter Router, der sich dafür entscheidet, darauf zu reagieren, indem er regelmäßig gezielte Hallo-Nachrichten an den initiierenden Router sendet.
Standardmäßig sendet LDP alle 5 Sekunden Hello-Nachrichten für Link Hello-Nachrichten und alle 15 Sekunden für gezielte Hello-Nachrichten. Sie können den LDP-Timer so konfigurieren, dass er ändert, wie häufig beide Arten von Hallo-Nachrichten gesendet werden. Sie können jedoch keine Zeit für den LDP-Timer konfigurieren, der größer als die LDP-Haltezeit ist. Weitere Informationen finden Sie unter Konfigurieren der Verzögerung, bevor LDP-Nachbarn als nach unten betrachtet werden.
- Konfigurieren des LDP-Timers für Link Hello Messages
- Konfigurieren des LDP-Timers für zielgerichtete Hello-Nachrichten
Konfigurieren des LDP-Timers für Link Hello Messages
Um zu ändern, wie oft LDP Link Hello-Nachrichten sendet, geben Sie ein neues Verbindungs-Hello-Nachrichtenintervall für den LDP-Timer mithilfe der hello-interval
Anweisung an:
hello-interval seconds;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren des LDP-Timers für zielgerichtete Hello-Nachrichten
Um zu ändern, wie oft LDP gezielte Hello-Nachrichten sendet, geben Sie ein neues zielgerichtetes Hello-Nachrichtenintervall für den LDP-Timer an, indem Sie die hello-interval
Anweisung als Option für die targeted-hello
Anweisung konfigurieren:
targeted-hello { hello-interval seconds; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einbeziehen können, finden Sie in den Zusammenfassenden Abschnitten der Anweisung für diese Anweisungen.
Konfigurieren der Verzögerung, bevor LDP-Nachbarn als nach unten betrachtet werden
Die Haltezeit bestimmt, wie lange ein LDP-Knoten auf eine Hello-Nachricht warten soll, bevor er einen Nachbarn für ausfallen erklärt. Dieser Wert wird als Teil einer Hello-Nachricht gesendet, sodass jeder LDP-Knoten seinen Nachbarn sagt, wie lange er warten soll. Die von jedem Nachbarn gesendeten Werte müssen nicht übereinstimmen.
Die Haltezeit sollte normalerweise mindestens das Dreifache des Hello-Intervalls sein. Standardmäßig beträgt der Standard 15 Sekunden für Link Hello-Nachrichten und 45 Sekunden für gezielte Hello-Nachrichten. Es ist jedoch möglich, eine LDP-Haltezeit zu konfigurieren, die nahe dem Wert für das Hello-Intervall liegt.
Durch die Konfiguration einer LDP-Haltezeit in der Nähe des Hello-Intervalls (weniger als das Dreifache des Hello-Intervalls) können LDP-Nachbarfehler schneller erkannt werden. Dies erhöht jedoch auch die Möglichkeit, dass der Router einen LDP-Nachbarn deklarieren kann, der weiterhin normal funktioniert. Weitere Informationen finden Sie unter Konfigurieren des LDP-Timers für Hello Messages.
Die LDP-Haltezeit wird auch automatisch zwischen LDP-Peers ausgehandelt. Wenn zwei LDP-Peers unterschiedliche LDP-Haltezeiten zueinander anzeigen, wird der kleinere Wert verwendet. Wenn ein LDP-Peer-Router eine kürzere Haltezeit als der von Ihnen konfigurierte Wert anpries, wird die angekündigte Haltezeit des Peer-Routers verwendet. Diese Aushandlung kann sich auch auf das LDP-Abstandsintervall auswirken.
Wenn die lokale LDP-Haltezeit während der LDP-Peer-Aushandlung nicht verkürzt wird, bleibt das benutzerkonfigurierte Keepalive Interval unverändert. Wenn jedoch die lokale Haltezeit während der Peer-Verhandlung reduziert wird, wird das Abstandsintervall neu berechnet. Wenn die LDP-Haltezeit während der Peer-Verhandlung reduziert wurde, wird das Halteintervall auf ein Drittel des neuen Haltezeitwerts reduziert. Wenn der neue Hold-Time-Wert beispielsweise 45 Sekunden beträgt, wird das Keepalive-Intervall auf 15 Sekunden festgelegt.
Diese automatische Keepalive Interval-Berechnung kann dazu führen, dass auf jedem Peer-Router unterschiedliche Keepalive-Intervalle konfiguriert werden. Dadurch können die Router flexibel sein, wie oft sie keepalive Nachrichten senden, da die LDP-Peer-Aushandlung sicherstellt, dass sie häufiger gesendet werden als die LDP-Haltezeit.
Wenn Sie das Hold-Time-Intervall neu konfigurieren, werden die Änderungen erst wirksam, nachdem die Sitzung zurückgesetzt wurde. Die Haltezeit wird ausgehandelt, wenn die LDP-Peering-Sitzung initiiert wird, und kann nicht neu verhandelt werden, solange die Sitzung verfügbar ist (erforderlich nach RFC 5036, LDP-Spezifikation). Um die LDP-Sitzung manuell zurückzusetzen, geben Sie den clear ldp session
Befehl aus.
- Konfigurieren der LDP-Haltezeit für Link Hallo Nachrichten
- Konfigurieren der LDP-Haltezeit für zielgerichtete Hello-Nachrichten
Konfigurieren der LDP-Haltezeit für Link Hallo Nachrichten
Um zu ändern, wie lange ein LDP-Knoten auf eine Link Hello-Nachricht warten soll, bevor er den Nachbarn deklariert, geben Sie mit der hold-time
Anweisung eine neue Zeit in Sekunden an:
hold-time seconds;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren der LDP-Haltezeit für zielgerichtete Hello-Nachrichten
Um zu ändern, wie lange ein LDP-Knoten auf eine gezielte Hello-Nachricht warten soll, bevor der Nachbar deklariert wird, geben Sie eine neue Zeit in Sekunden an, indem Sie die hold-time
Anweisung als Option für die targeted-hello
Anweisung verwenden:
targeted-hello { hold-time seconds; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einbeziehen können, finden Sie in den Zusammenfassenden Abschnitten der Anweisung für diese Anweisungen.
Aktivieren strenger zielgerichteter Hello-Nachrichten für LDP
Verwenden Sie strikte, zielgerichtete Hello-Nachrichten, um zu verhindern, dass LDP-Sitzungen mit Remote-Nachbarn eingerichtet werden, die nicht speziell konfiguriert wurden. Wenn Sie die strict-targeted-hellos
Anweisung konfigurieren, reagiert ein LDP-Peer nicht auf gezielte Hello-Nachrichten, die von einer Quelle stammen, die nicht zu den konfigurierten Remote-Nachbarn gehört. Zu den konfigurierten Remote-Nachbarn gehören:
Endpunkte von RSVP-Tunneln, für die LDP-Tunneling konfiguriert ist
Layer-2-Circuit-Nachbarn
Wenn ein nicht konfigurierter Nachbar eine Hello-Nachricht sendet, ignoriert der LDP-Peer die Nachricht und protokolliert einen Fehler (mit dem Trace-Flag), der die error
Quelle angibt. Wenn der LDP-Peer beispielsweise eine gezielte Begrüßung von der Internetadresse 10.0.0.1 erhalten hat und kein Nachbar mit dieser Adresse speziell konfiguriert ist, wird die folgende Nachricht in die LDP-Protokolldatei gedruckt:
LDP: Ignoring targeted hello from 10.0.0.1
Um strikte zielgerichtete Hallo-Nachrichten zu aktivieren, fügen Sie die strict-targeted-hellos
Anweisung ein:
strict-targeted-hellos;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren des Intervalls für LDP-Keepalive-Nachrichten
Das Abstandsintervall bestimmt, wie oft eine Nachricht über die Sitzung gesendet wird, um sicherzustellen, dass das keepalive Timeout nicht überschritten wird. Wenn in diesem Zeitraum kein anderer LDP-Datenverkehr über die Sitzung gesendet wird, wird eine Keepalive-Nachricht gesendet. Der Standard beträgt 10 Sekunden. Der Mindestwert beträgt 1 Sekunde.
Der für das Keepalive-Intervall konfigurierte Wert kann während der LDP-Sitzungsverhandlung geändert werden, wenn der für die LDP-Haltezeit auf dem Peer-Router konfigurierte Wert niedriger als der lokal konfigurierte Wert ist. Weitere Informationen finden Sie unter Konfigurieren der Verzögerung, bevor LDP-Nachbarn als nach unten betrachtet werden.
Um das Abstandsintervall zu ändern, fügen Sie die keepalive-interval
Anweisung ein:
keepalive-interval seconds;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren des LDP-Keepalive Timeout
Nach der Einrichtung einer LDP-Sitzung müssen regelmäßig Nachrichten ausgetauscht werden, um sicherzustellen, dass die Sitzung weiterhin funktioniert. Der keepalive Timeout definiert die Zeit, die der benachbarte LDP-Knoten wartet, bevor er entscheidet, dass die Sitzung fehlgeschlagen ist. Dieser Wert wird in der Regel auf das mindestens dreifache des Abstandsintervalls festgelegt. Der Standard beträgt 30 Sekunden.
Um das Abstandsintervall zu ändern, fügen Sie die keepalive-timeout
Anweisung ein:
keepalive-timeout seconds;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Der für die keepalive-timeout
Anweisung konfigurierte Wert wird als Haltezeit beim Ausführen des Befehls show ldp session detail
angezeigt.
Konfigurieren der längsten Übereinstimmung für LDP
Damit LDP die über OSPF-Bereiche oder ISIS-Ebenen in domänenübergreifenden Ebenen aggregierten oder zusammengefassten Routen erlernen kann, ermöglicht Ihnen Junos OS die Konfiguration der längsten Übereinstimmung für LDP basierend auf RFC5283.
Bevor Sie die längste Übereinstimmung für LDP konfigurieren, müssen Sie Folgendes tun:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie das MPLS-Protokoll.
Konfigurieren Sie das OSPF-Protokoll.
Um die längste Übereinstimmung für LDP zu konfigurieren, müssen Sie Folgendes tun:
Beispiel: Konfigurieren der längsten Übereinstimmung für LDP
Dieses Beispiel zeigt, wie sie die längste Übereinstimmung für LDP basierend auf RFC5283 konfigurieren. Auf diese Weise kann LDP die über OSPF-Bereiche oder ISIS-Ebenen in verschiedenen Domänen aggregierten oder zusammengefassten Routen erlernen. Die längste Übereinstimmungsrichtlinie bietet die Granularität pro Präfix.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Sechs Router der MX-Serie mit OSPF-Protokoll und LDP an den angeschlossenen Schnittstellen.
Junos OS Version 16.1 oder höher, die auf allen Geräten ausgeführt wird.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
OSPF konfigurieren.
Überblick
LDP wird häufig verwendet, um MPLS Label Switched Paths (LSPs) über eine komplette Netzwerkdomäne mit einem IGP wie OSPF oder IS-IS einzurichten. In einem solchen Netzwerk verfügen alle Links in der Domain über IGP-Nachbarschaften sowie LDP-Nachbarschaften. LDP stellt die LSPs auf dem kürzesten Pfad zu einem Ziel fest, wie durch IP-Weiterleitung bestimmt. In Junos OS sucht die LDP-Implementierung genau nach der IP-Adresse des FEC in den RIB- oder IGP-Routen für die Labelzuordnung. Für diese exakte Zuordnung müssen die END-to-End-LDP-Endpunkt-IP-Adressen von MPLS in allen LERs konfiguriert werden. Dadurch wird der Zweck des HIERarchischen IP-Designs oder des Standardroutings bei Zugriffsgeräten verfliegt. Die Konfiguration longest-match
hilft dabei, dies zu überwinden, indem das genaue Übereinstimmungsverhalten unterdrückt und LSP basierend auf der längsten übereinstimmenden Route pro Präfix eingerichtet wird.
Topologie
Zeigt in der Topologie an, dass Abbildung 1die längste Übereinstimmung für LDP auf Gerät R0 konfiguriert ist.

Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit] CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit
.
R0
set interfaces ge-0/0/0 unit 0 family inet address 22.22.22.1/24 set interfaces ge-0/0/1 unit 0 family inet address 15.15.15.1/24 set interfaces ge-0/0/2 unit 0 family inet address 11.11.11.1/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.112.1/32 primary set interfaces lo0 unit 0 family inet address 10.255.112.1/32 preferred set interfaces lo0 unit 0 family iso address 49.0002.0192.0168.0001.00 set routing-options router-id 10.255.112.1 set protocols mpls interface ge-0/0/2.0 set protocols ospf area 0.0.0.1 interface ge-0/0/2.0 set protocols ospf area 0.0.0.1 interface lo0.0 passive set protocols ldp longest-match set protocols ldp interface ge-0/0/2.0 set protocols ldp interface lo0.0
R1
set interfaces ge-0/0/0 unit 0 family inet address 11.11.11.2/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 12.12.12.1/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.112.2/32 primary set interfaces lo0 unit 0 family inet address 10.255.112.2/32 preferred set interfaces lo0 unit 0 family iso address 49.0002.0192.0168.0002.00 set routing-options router-id 10.255.112.2 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.1 interface ge-0/0/0.0 set protocols ldp longest-match set protocols ldp interface ge-0/0/0.0 set protocols ldp interface ge-0/0/1.0 set protocols ldp interface lo0.0
R2
set interfaces ge-0/0/0 unit 0 family inet address 24.24.24.1/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 12.12.12.2/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 23.23.23.1/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 22.22.22.2/24 set interfaces ge-0/0/4 unit 0 family inet address 25.25.25.1/24 set interfaces ge-0/0/4 unit 0 family iso set interfaces ge-0/0/4 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.4/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.4/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0003.00 set routing-options router-id 10.255.111.4 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/4.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.2 area-range 10.255.111.0/24 set protocols ospf area 0.0.0.2 interface ge-0/0/2.0 set protocols ospf area 0.0.0.2 interface ge-0/0/0.0 set protocols ospf area 0.0.0.2 interface ge-0/0/4.0 set protocols ldp interface ge-0/0/0.0 set protocols ldp interface ge-0/0/1.0 set protocols ldp interface ge-0/0/2.0 set protocols ldp interface ge-0/0/4.0 set protocols ldp interface lo0.0
R3
set interfaces ge-0/0/0 unit 0 family inet address 35.35.35.1/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 23.23.23.2/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 34.34.34.1/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.1/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.1/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0004.00 set routing-options router-id 10.255.111.1 set protocols mpls interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface fxp0.0 disable set protocols ospf area 0.0.0.2 interface lo0.0 passive set protocols ldp interface ge-0/0/1.0 set protocols ldp interface lo0.0
R4
set interfaces ge-0/0/0 unit 0 family inet address 45.45.45.1/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 24.24.24.2/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 34.34.34.2/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.2/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.2/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0005.00 set routing-options router-id 10.255.111.2 set protocols mpls interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface fxp0.0 disable set protocols ospf area 0.0.0.2 interface lo0.0 passive set protocols ldp interface ge-0/0/1.0 set protocols ldp interface lo0.0
R5
set interfaces ge-0/0/0 unit 0 family inet address 25.25.25.2/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 15.15.15.2/24 set interfaces ge-0/0/2 unit 0 family inet address 35.35.35.2/24 set interfaces ge-0/0/3 unit 0 family inet address 45.45.45.2/24 set interfaces ge-0/0/3 unit 0 family iso set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.3/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.3/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0006.00 set routing-options router-id 10.255.111.3 set protocols mpls interface ge-0/0/0.0 set protocols ospf area 0.0.0.2 interface ge-0/0/0.0 set protocols ospf area 0.0.0.2 interface fxp0.0 disable set protocols ospf area 0.0.0.2 interface lo0.0 passive set protocols ldp interface ge-0/0/0.0 set protocols ldp interface lo0.0
Konfigurieren von Gerät R0
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie Gerät R0:
Konfigurieren Sie die Schnittstellen.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 22.22.22.1/24 set ge-0/0/1 unit 0 family inet address 15.15.15.1/24 set ge-0/0/2 unit 0 family inet address 11.11.11.1/24 set ge-0/0/2 unit 0 family iso set ge-0/0/2 unit 0 family mpls
Weisen Sie dem Gerät die Loopback-Adressen zu.
[edit interfaces lo0 unit 0 family] set inet address 10.255.112.1/32 primary set inet address 10.255.112.1/32 preferred set iso address 49.0002.0192.0168.0001.00
Konfigurieren Sie die Router-ID.
[edit routing-options] set router-id 10.255.112.1
Konfigurieren Sie das MPLS-Protokoll auf der Schnittstelle.
[edit protocols mpls] set interface ge-0/0/2.0
Konfigurieren Sie das OSPF-Protokoll auf der Schnittstelle.
[edit protocols ospf] set area 0.0.0.1 interface ge-0/0/2.0 set area 0.0.0.1 interface lo0.0 passive
Konfigurieren Sie die längste Übereinstimmung für das LDP-Protokoll.
[edit protocols ldp] set longest-match
Konfigurieren Sie das LDP-Protokoll auf der Schnittstelle.
[edit protocols ldp] set interface ge-0/0/2.0 set interface lo0.0
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus durch Eingabe von show interfaces, show protocolsund show routing-options Befehlen. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R0# show interfaces ge-0/0/0 { unit 0 { family inet { address 22.22.22.1/24; } } } ge-0/0/1 { unit 0 { family inet { address 15.15.15.1/24; } } } ge-0/0/2 { unit 0 { family inet { address 11.11.11.1/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.255.112.1/32 { primary; preferred; } } family iso { address 49.0002.0192.0168.0001.00; } } }
user@R0# show protocols mpls { interface ge-0/0/2.0; } ospf { area 0.0.0.1 { interface ge-0/0/2.0; interface lo0.0 { passive; } } } ldp { longest-match; interface ge-0/0/2.0; interface lo0.0; }
user@R0# show routing-options router-id 10.255.112.1;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie aus dem Konfigurationsmodus ein commit
.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Routen
- Überprüfen der LDP-Übersichtsinformationen
- Überprüfen der LDP-Einträge in der internen Topologietabelle
- Nur FEC-Informationen der LDP-Route überprüfen
- Überprüfen von FEC- und Schattenrouten von LDP
Überprüfen der Routen
Zweck
Vergewissern Sie sich, dass die erwarteten Routen erlernt werden.
Aktion
Führen Sie auf Gerät R0 im Betriebsmodus den show route
Befehl aus, um die Routen in der Routingtabelle anzuzeigen.
user@R0> show route
inet.0: 62 destinations, 62 routes (62 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.4.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.5.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.6.128.0/17 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.9.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.10.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.13.4.0/23 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.13.10.0/23 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.82.0.0/15 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.84.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.85.12.0/22 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.92.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.92.16.0/20 *[Direct/0] 10:08:01
> via fxp0.0
10.92.20.175/32 *[Local/0] 10:08:01
Local via fxp0.0
10.94.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.99.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.102.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.150.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.155.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.157.64.0/19 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.160.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.204.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.205.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.206.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.207.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.209.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.212.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.213.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.214.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.215.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.216.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.13.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.14.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.16.0/20 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.32.0/20 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.227.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.255.111.0/24 *[OSPF/10] 09:52:14, metric 3
> to 11.11.11.2 via ge-0/0/2.0
10.255.111.4/32 *[OSPF/10] 09:54:10, metric 2
> to 11.11.11.2 via ge-0/0/2.0
10.255.112.1/32 *[Direct/0] 09:55:05
> via lo0.0
10.255.112.2/32 *[OSPF/10] 09:54:18, metric 1
> to 11.11.11.2 via ge-0/0/2.0
11.11.11.0/24 *[Direct/0] 09:55:05
> via ge-0/0/2.0
11.11.11.1/32 *[Local/0] 09:55:05
Local via ge-0/0/2.0
12.12.12.0/24 *[OSPF/10] 09:54:18, metric 2
> to 11.11.11.2 via ge-0/0/2.0
15.15.15.0/24 *[Direct/0] 09:55:05
> via ge-0/0/1.0
15.15.15.1/32 *[Local/0] 09:55:05
Local via ge-0/0/1.0
22.22.22.0/24 *[Direct/0] 09:55:05
> via ge-0/0/0.0
22.22.22.1/32 *[Local/0] 09:55:05
Local via ge-0/0/0.0
23.23.23.0/24 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
24.24.24.0/24 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
25.25.25.0/24 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.17.45/32 *[OSPF/10] 09:54:05, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.20.175/32 *[Direct/0] 10:08:01
> via lo0.0
128.92.21.186/32 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.25.135/32 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.27.91/32 *[OSPF/10] 09:54:18, metric 1
> to 11.11.11.2 via ge-0/0/2.0
128.92.28.70/32 *[OSPF/10] 09:54:10, metric 2
> to 11.11.11.2 via ge-0/0/2.0
172.16.0.0/12 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
192.168.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
192.168.102.0/23 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
207.17.136.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
207.17.136.192/32 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
207.17.137.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
224.0.0.5/32 *[OSPF/10] 09:55:05, metric 1
MultiRecv
inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.111.1/32 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Push 300128
10.255.111.2/32 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Push 300144
10.255.111.3/32 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Push 300160
10.255.111.4/32 *[LDP/9] 09:54:10, metric 2, tag 0
> to 11.11.11.2 via ge-0/0/2.0, Push 300000
10.255.112.2/32 *[LDP/9] 09:54:48, metric 1, tag 0
> to 11.11.11.2 via ge-0/0/2.0
iso.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
47.0005.80ff.f800.0000.0108.0001.1280.9202.0175/152
*[Direct/0] 10:08:01
> via lo0.0
49.0002.0192.0168.0001/72
*[Direct/0] 09:55:05
> via lo0.0
mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 09:55:05, metric 1
Receive
1 *[MPLS/0] 09:55:05, metric 1
Receive
2 *[MPLS/0] 09:55:05, metric 1
Receive
13 *[MPLS/0] 09:55:05, metric 1
Receive
300064 *[LDP/9] 09:54:48, metric 1
> to 11.11.11.2 via ge-0/0/2.0, Pop
300064(S=0) *[LDP/9] 09:54:48, metric 1
> to 11.11.11.2 via ge-0/0/2.0, Pop
300112 *[LDP/9] 09:54:10, metric 2, tag 0
> to 11.11.11.2 via ge-0/0/2.0, Swap 300000
300192 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Swap 300128
300208 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Swap 300144
300224 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Swap 300160
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
abcd::128:92:20:175/128
*[Direct/0] 10:08:01
> via lo0.0
fe80::5668:a50f:fcc1:1f9c/128
*[Direct/0] 10:08:01
> via lo0.0
Bedeutung
Die Ausgabe zeigt alle Routen in der Routing-Tabelle des Geräts R0 an.
Überprüfen der LDP-Übersichtsinformationen
Zweck
LDP-Übersichtsinformationen anzeigen.
Aktion
Führen Sie auf Gerät R0 im Betriebsmodus den show ldp overview
Befehl aus, um die Übersicht über die LDP anzuzeigen.
user@R0> show ldp overview
Instance: master
Reference count: 2
Router ID: 10.255.112.1
Message id: 8
Configuration sequence: 6
Deaggregate: disabled
Explicit null: disabled
IPv6 tunneling: disabled
Strict targeted hellos: disabled
Loopback if added: yes
Route preference: 9
Unicast transit LSP chaining: disabled
P2MP transit LSP chaining: disabled
Transit LSP statistics based on route statistics: disabled
LDP route acknowledgement: enabled
LDP mtu discovery: disabled
Longest Match: enabled
Capabilities enabled: none
Egress FEC capabilities enabled: entropy-label-capability
Downstream unsolicited Sessions:
Operational: 1
Retention: liberal
Control: ordered
Auto targeted sessions:
Auto targeted: disabled
Timers:
Keepalive interval: 10, Keepalive timeout: 30
Link hello interval: 5, Link hello hold time: 15
Targeted hello interval: 15, Targeted hello hold time: 45
Label withdraw delay: 60, Make before break timeout: 30
Make before break switchover delay: 3
Link protection timeout: 120
Graceful restart:
Restart: disabled, Helper: enabled, Restart in process: false
Reconnect time: 60000, Max neighbor reconnect time: 120000
Recovery time: 160000, Max neighbor recovery time: 240000
Traffic Engineering:
Bgp igp: disabled
Both ribs: disabled
Mpls forwarding: disabled
IGP:
Tracking igp metric: disabled
Sync session up delay: 10
Session protection:
Session protection: disabled
Session protection timeout: 0
Interface addresses advertising:
11.11.11.1
10.255.112.1
128.92.20.175
Label allocation:
Current number of LDP labels allocated: 5
Total number of LDP labels allocated: 11
Total number of LDP labels freed: 6
Total number of LDP label allocation failure: 0
Current number of labels allocated by all protocols: 5
Bedeutung
Die Ausgabe zeigt die LDP-Übersichtsinformationen des Geräts R0 an
Überprüfen der LDP-Einträge in der internen Topologietabelle
Zweck
Zeigen Sie die Routeneinträge in der internen Topologietabelle des Label Distribution Protocol (LDP) an.
Aktion
Führen Sie auf Gerät R0 im Betriebsmodus den show ldp route
Befehl aus, um die interne Topologietabelle von LDP anzuzeigen.
user@R0> show ldp route
Destination Next-hop intf/lsp/table Next-hop address
10.4.0.0/16 fxp0.0 10.92.31.254
10.5.0.0/16 fxp0.0 10.92.31.254
10.6.128.0/17 fxp0.0 10.92.31.254
10.9.0.0/16 fxp0.0 10.92.31.254
10.10.0.0/16 fxp0.0 10.92.31.254
10.13.4.0/23 fxp0.0 10.92.31.254
10.13.10.0/23 fxp0.0 10.92.31.254
10.82.0.0/15 fxp0.0 10.92.31.254
10.84.0.0/16 fxp0.0 10.92.31.254
10.85.12.0/22 fxp0.0 10.92.31.254
10.92.0.0/16 fxp0.0 10.92.31.254
10.92.16.0/20 fxp0.0
10.92.20.175/32
10.94.0.0/16 fxp0.0 10.92.31.254
10.99.0.0/16 fxp0.0 10.92.31.254
10.102.0.0/16 fxp0.0 10.92.31.254
10.150.0.0/16 fxp0.0 10.92.31.254
10.155.0.0/16 fxp0.0 10.92.31.254
10.157.64.0/19 fxp0.0 10.92.31.254
10.160.0.0/16 fxp0.0 10.92.31.254
10.204.0.0/16 fxp0.0 10.92.31.254
10.205.0.0/16 fxp0.0 10.92.31.254
10.206.0.0/16 fxp0.0 10.92.31.254
10.207.0.0/16 fxp0.0 10.92.31.254
10.209.0.0/16 fxp0.0 10.92.31.254
10.212.0.0/16 fxp0.0 10.92.31.254
10.213.0.0/16 fxp0.0 10.92.31.254
10.214.0.0/16 fxp0.0 10.92.31.254
10.215.0.0/16 fxp0.0 10.92.31.254
10.216.0.0/16 fxp0.0 10.92.31.254
10.218.13.0/24 fxp0.0 10.92.31.254
10.218.14.0/24 fxp0.0 10.92.31.254
10.218.16.0/20 fxp0.0 10.92.31.254
10.218.32.0/20 fxp0.0 10.92.31.254
10.227.0.0/16 fxp0.0 10.92.31.254
10.255.111.0/24 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.112.1/32 lo0.0
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
11.11.11.0/24 ge-0/0/2.0
11.11.11.1/32
12.12.12.0/24 ge-0/0/2.0 11.11.11.2
15.15.15.0/24 ge-0/0/1.0
15.15.15.1/32
22.22.22.0/24 ge-0/0/0.0
22.22.22.1/32
23.23.23.0/24 ge-0/0/2.0 11.11.11.2
24.24.24.0/24 ge-0/0/2.0 11.11.11.2
25.25.25.0/24 ge-0/0/2.0 11.11.11.2
128.92.17.45/32 ge-0/0/2.0 11.11.11.2
128.92.20.175/32 lo0.0
128.92.21.186/32 ge-0/0/2.0 11.11.11.2
128.92.25.135/32 ge-0/0/2.0 11.11.11.2
128.92.27.91/32 ge-0/0/2.0 11.11.11.2
128.92.28.70/32 ge-0/0/2.0 11.11.11.2
172.16.0.0/12 fxp0.0 10.92.31.254
192.168.0.0/16 fxp0.0 10.92.31.254
192.168.102.0/23 fxp0.0 10.92.31.254
207.17.136.0/24 fxp0.0 10.92.31.254
207.17.136.192/32 fxp0.0 10.92.31.254
207.17.137.0/24 fxp0.0 10.92.31.254
224.0.0.5/32
Bedeutung
Die Ausgabe zeigt die Routeneinträge in der internen Topologietabelle des Label Distribution Protocol (LDP) des Geräts R0 an.
Nur FEC-Informationen der LDP-Route überprüfen
Zweck
Zeigen Sie nur die FEC-Informationen der LDP-Route an.
Aktion
Führen Sie auf Gerät R0 im Betriebsmodus den show ldp route fec-only
Befehl aus, um die Routen in der Routingtabelle anzuzeigen.
user@R0> show ldp route fec-only
Destination Next-hop intf/lsp/table Next-hop address
10.255.111.1/32 ge-0/0/2.0 11.11.11.2
10.255.111.2/32 ge-0/0/2.0 11.11.11.2
10.255.111.3/32 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.112.1/32 lo0.0
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
Bedeutung
Die Ausgabe zeigt nur die FEC-Routen des LDP-Protokolls an, die für Gerät R0 verfügbar sind.
Überprüfen von FEC- und Schattenrouten von LDP
Zweck
Zeigen Sie den FEC und die Schattenrouten in der Routingtabelle an.
Aktion
Führen Sie auf Gerät R0 im Betriebsmodus den show ldp route fec-and-route
Befehl aus, um die FEC- und Schattenrouten in der Routingtabelle anzuzeigen.
user@R0> show ldp route fec-and-route
Destination Next-hop intf/lsp/table Next-hop address
10.4.0.0/16 fxp0.0 10.92.31.254
10.5.0.0/16 fxp0.0 10.92.31.254
10.6.128.0/17 fxp0.0 10.92.31.254
10.9.0.0/16 fxp0.0 10.92.31.254
10.10.0.0/16 fxp0.0 10.92.31.254
10.13.4.0/23 fxp0.0 10.92.31.254
10.13.10.0/23 fxp0.0 10.92.31.254
10.82.0.0/15 fxp0.0 10.92.31.254
10.84.0.0/16 fxp0.0 10.92.31.254
10.85.12.0/22 fxp0.0 10.92.31.254
10.92.0.0/16 fxp0.0 10.92.31.254
10.92.16.0/20 fxp0.0
10.92.20.175/32
10.94.0.0/16 fxp0.0 10.92.31.254
10.99.0.0/16 fxp0.0 10.92.31.254
10.102.0.0/16 fxp0.0 10.92.31.254
10.150.0.0/16 fxp0.0 10.92.31.254
10.155.0.0/16 fxp0.0 10.92.31.254
10.157.64.0/19 fxp0.0 10.92.31.254
10.160.0.0/16 fxp0.0 10.92.31.254
10.204.0.0/16 fxp0.0 10.92.31.254
10.205.0.0/16 fxp0.0 10.92.31.254
10.206.0.0/16 fxp0.0 10.92.31.254
10.207.0.0/16 fxp0.0 10.92.31.254
10.209.0.0/16 fxp0.0 10.92.31.254
10.212.0.0/16 fxp0.0 10.92.31.254
10.213.0.0/16 fxp0.0 10.92.31.254
10.214.0.0/16 fxp0.0 10.92.31.254
10.215.0.0/16 fxp0.0 10.92.31.254
10.216.0.0/16 fxp0.0 10.92.31.254
10.218.13.0/24 fxp0.0 10.92.31.254
10.218.14.0/24 fxp0.0 10.92.31.254
10.218.16.0/20 fxp0.0 10.92.31.254
10.218.32.0/20 fxp0.0 10.92.31.254
10.227.0.0/16 fxp0.0 10.92.31.254
10.255.111.0/24 ge-0/0/2.0 11.11.11.2
10.255.111.1/32 ge-0/0/2.0 11.11.11.2
10.255.111.2/32 ge-0/0/2.0 11.11.11.2
10.255.111.3/32 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.112.1/32 lo0.0
10.255.112.1/32 lo0.0
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
11.11.11.0/24 ge-0/0/2.0
11.11.11.1/32
12.12.12.0/24 ge-0/0/2.0 11.11.11.2
15.15.15.0/24 ge-0/0/1.0
15.15.15.1/32
22.22.22.0/24 ge-0/0/0.0
22.22.22.1/32
23.23.23.0/24 ge-0/0/2.0 11.11.11.2
24.24.24.0/24 ge-0/0/2.0 11.11.11.2
25.25.25.0/24 ge-0/0/2.0 11.11.11.2
128.92.17.45/32 ge-0/0/2.0 11.11.11.2
128.92.20.175/32 lo0.0
128.92.21.186/32 ge-0/0/2.0 11.11.11.2
128.92.25.135/32 ge-0/0/2.0 11.11.11.2
128.92.27.91/32 ge-0/0/2.0 11.11.11.2
128.92.28.70/32 ge-0/0/2.0 11.11.11.2
172.16.0.0/12 fxp0.0 10.92.31.254
192.168.0.0/16 fxp0.0 10.92.31.254
192.168.102.0/23 fxp0.0 10.92.31.254
207.17.136.0/24 fxp0.0 10.92.31.254
207.17.136.192/32 fxp0.0 10.92.31.254
207.17.137.0/24 fxp0.0 10.92.31.254
224.0.0.5/32
Bedeutung
Die Ausgabe zeigt den FEC und die Schattenrouten von Gerät R0 an
Konfigurieren von LDP-Routeneinstellungen
Wenn mehrere Protokolle Routen zum selben Ziel berechnen, werden Routeneinstellungen verwendet, um auszuwählen, welche Route in der Weiterleitungstabelle installiert ist. Die Route mit dem niedrigsten Präferenzwert wird ausgewählt. Der Präferenzwert kann eine Zahl im Bereich 0 bis 255 sein. LDP-Routen haben standardmäßig einen Präferenzwert von 9.
Um die Routeneinstellungen zu ändern, fügen Sie die preference
Anweisung ein:
preference preference;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Unterbrechungsfreier LDP-Neustart
Der Unterbrechungsfreier LDP-Neustart ermöglicht einen Router, dessen LDP-Steuerungsebene einen Neustart durchläuft, um den Datenverkehr weiterzuleiten, während der Status von benachbarten Routern wiederhergestellt wird. Es ermöglicht auch einem Router, auf dem der Hilfsmodus aktiviert ist, einen benachbarten Router zu unterstützen, der versucht, LDP neu zu starten.
Während der Sitzungs initialisierung kündigt ein Router seine Fähigkeit an, den LDP-Unterbrechungsneustart durchzuführen oder einen Nachbarn zu nutzen, der einen LDP-Graceful-Neustart durchführt, indem er den Graceful Restart TLV sendet. Dieser TLV enthält zwei Felder, die für den unterbrechungsbehafteten LDP-Neustart relevant sind: die Wiederherstellungszeit und die Wiederherstellungszeit. Die Werte der Reconnect- und Wiederherstellungszeiten zeigen die vom Router unterstützten Graceful Restart-Funktionen an.
Wenn ein Router erkennt, dass ein benachbarter Router neu gestartet wird, wartet er bis zum Ende der Wiederherstellungszeit, bevor er versucht, die Verbindung wieder herzustellen. Die Wiederherstellungszeit ist die Dauer, in der ein Router darauf wartet, dass LDP unterbrechungsgerecht neu gestartet wird. Der Wiederherstellungszeitraum beginnt, wenn eine Initialisierungsnachricht gesendet oder empfangen wird. Dieser Zeitraum ist in der Regel auch die Dauer, über die ein benachbarter Router seine Informationen über den neustartenden Router verwaltet und so den Datenverkehr weiterleiten kann.
Sie können den LDP-Unterbrechungsneustart sowohl in der Master-Instanz für das LDP-Protokoll als auch für eine bestimmte Routinginstanz konfigurieren. Sie können den unterbrechungsfreien Neustart auf globaler Ebene für alle Protokolle, auf Protokollebene nur für LDP und für eine bestimmte Routinginstanz deaktivieren. Der Unterbrechungsfreier LDP-Neustart wird standardmäßig deaktiviert, da der Unterbrechungsfreier Neustart auf globaler Ebene standardmäßig deaktiviert ist. Der Helper-Modus (die Möglichkeit, einen benachbarten Router zu unterstützen, der einen unterbrechungsreichen Neustart versucht) ist jedoch standardmäßig aktiviert.
Im Folgenden sind einige der Verhaltensweisen zu erfahren, die mit einem unterbrechungsfreien LDP-Neustart verbunden sind:
Ausgehende Labels werden bei Neustarts nicht aufrechterhalten. Neue ausgehende Labels werden zugewiesen.
Wenn ein Router neu gestartet wird, werden keine Label-Map-Nachrichten an Nachbarn gesendet, die einen Unterbrechungsneustart unterstützen, bis sich der Neustart-Router stabilisiert hat (Label-Map-Nachrichten werden sofort an Nachbarn gesendet, die einen Unterbrechungsneustart nicht unterstützen). Alle anderen Nachrichten (Haltepflicht, Adressnachricht, Benachrichtigung und Freigabe) werden jedoch wie üblich gesendet. Die Verteilung dieser anderen Nachrichten hindert den Router daran, unvollständige Informationen zu verteilen.
Der Helper-Modus und der unterbrechungsfreie Neustart sind unabhängig. Sie können den unterbrechungsfreien Neustart in der Konfiguration deaktivieren, aber dennoch zulassen, dass der Router mit einem Nachbarn zusammenarbeitet, der versucht, ihn nach Belieben neu zu starten.
Konfiguration von LDP Graceful Restart
Wenn Sie die Graceful Restart-Konfiguration entweder auf den Hierarchieebenen oder [edit protocols ldp graceful-restart]
auf der [edit routing-options graceful-restart]
Hierarchieebene ändern, wird jede laufende LDP-Sitzung automatisch neu gestartet, um die Graceful Restart-Konfiguration anzuwenden. Dieses Verhalten spiegelt das Verhalten von BGP wieder, wenn Sie die Graceful Restart-Konfiguration ändern.
Standardmäßig ist der Graceful Restart Helper-Modus aktiviert, aber der Graceful Restart ist deaktiviert. Das Standardverhalten eines Routers besteht also darin, benachbarte Router bei einem Unterbrechungsneustart zu unterstützen, aber keinen unterbrechungsfreien Neustart selbst zu versuchen.
Informationen zum Konfigurieren des unterbrechungsreichen LDP-Neustarts finden Sie in den folgenden Abschnitten:
- Unterbrechungsfreier Neustart ermöglichen
- Deaktivieren des LDP-Graceful Restart- oder Helper-Modus
- Neukonnektivitätszeit konfigurieren
- Wiederherstellungszeit konfigurieren und maximale Wiederherstellungszeit
Unterbrechungsfreier Neustart ermöglichen
Um einen Unterbrechungsfreier LDP-Neustart zu ermöglichen, müssen Sie auch einen Unterbrechungsneustart auf dem Router aktivieren. Um einen Unterbrechungsneustart zu ermöglichen, fügen Sie die graceful-restart
Anweisung ein:
graceful-restart;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einfügen:
[edit routing-options]
[edit logical-systems logical-system-name routing-options]
Router der ACX-Serie unterstützen keine [edit logical-systems logical-system-name routing-options
] Hierarchieebene.
Die graceful-restart
Anweisung ermöglicht einen unterbrechungsfreien Neustart für alle Protokolle, die diese Funktion auf dem Router unterstützen. Weitere Informationen zum unterbrechungsfreien Neustart finden Sie in der Junos OS Routing Protocols Library for Routing Devices.
Standardmäßig ist der Unterbrechungsfreier LDP-Neustart aktiviert, wenn Sowohl auf LDP-Protokollebene als auch auf allen Routing-Instanzen ein Graceful-Neustart aktiviert wird. Sie können jedoch sowohl den LDP-Graceful-Restart- als auch den LDP-Graceful-Restart-Helper-Modus deaktivieren.
Deaktivieren des LDP-Graceful Restart- oder Helper-Modus
Um den unterbrechungsfreien LDP-Neustart und die Wiederherstellung zu deaktivieren, fügen Sie die disable
Anweisung ein:
ldp { graceful-restart { disable; } }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Sie können den Helper-Modus nur auf LDP-Protokollebene deaktivieren. Sie können den Helper-Modus für eine bestimmte Routinginstanz nicht deaktivieren. Um den LDP-Helper-Modus zu deaktivieren, fügen Sie die helper-disable
Anweisung ein:
ldp { graceful-restart { helper-disable; } }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Die folgenden LDP-Graceful-Restart-Konfigurationen sind möglich:
LDP-Neustart und Helper-Modus sind beide aktiviert.
Der Unterbrechungsfreier LDP-Neustart ist deaktiviert, aber der Helper-Modus ist aktiviert. Ein auf diese Weise konfigurierter Router kann nicht unterbrechungsgerecht neu gestartet werden, sondern kann einem neustartenden Nachbarn helfen.
Der Unterbrechungsfreier LDP-Neustart und der Helper-Modus sind beide deaktiviert. Der Router verwendet weder den LDP-Graceful-Neustart noch den in der Initialisierungsnachricht gesendeten Graceful Restart-Typ, die Länge und den Wert (TLV). Der Router verhält sich wie ein Router, der den LDP-Neustart nicht unterstützen kann.
Wenn Sie versuchen, einen Unterbrechungsneustart zu aktivieren und den Helper-Modus zu deaktivieren, wird ein Konfigurationsfehler ausgegeben.
Neukonnektivitätszeit konfigurieren
Nach dem Ausfall der LDP-Verbindung zwischen Nachbarn warten Nachbarn eine bestimmte Zeit, bis der Unterbrechungsneustart-Router das Senden von LDP-Nachrichten fortsetzen kann. Nach der Wartezeit kann die LDP-Sitzung wieder hergestellt werden. Sie können die Wartezeit in Sekunden konfigurieren. Dieser Wert ist in der fehlertoleranten Sitzung TLV enthalten, die in LDP-Initialisierungsmeldungen gesendet wird, wenn der unterbrechungsfreier LDP-Neustart aktiviert ist.
Nehmen wir an, Router A und Router B sind LDP-Nachbarn. Router A ist der routerneustartende Router. Die Zeit für die erneute Verbindung ist der Zeitpunkt, zu dem Router A Router B angewiesen hat, zu warten, nachdem Router B den Router A neu gestartet hat.
Um die Rekonnektivitätszeit zu konfigurieren, fügen Sie die reconnect-time
Anweisung ein:
graceful-restart { reconnect-time seconds; }
Sie können die Verbindungszeit auf einen Wert im Bereich von 30 bis 300 Sekunden festlegen. Standardmäßig sind es 60 Sekunden.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen konfigurieren können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.
Wiederherstellungszeit konfigurieren und maximale Wiederherstellungszeit
Die Wiederherstellungszeit ist die Zeit, mit der ein Router darauf wartet, dass LDP unterbrechungsgerecht neu gestartet wird. Der Wiederherstellungszeitraum beginnt, wenn eine Initialisierungsnachricht gesendet oder empfangen wird. Dieser Zeitraum ist in der Regel auch der Zeitraum, in dem ein benachbarter Router seine Informationen über den neustartenden Router verwaltet, sodass er den Datenverkehr weiterleiten kann.
Um zu verhindern, dass ein benachbarter Router beeinträchtigt wird, wenn er einen falschen Wert für die Wiederherstellungszeit des neustartenden Routers erhält, können Sie die maximale Wiederherstellungszeit auf dem benachbarten Router konfigurieren. Ein benachbarter Router behält seinen Status für die kürzere der beiden Zeiten bei. Router A führt beispielsweise einen unterbrechungsfreien LDP-Neustart durch. Er hat eine Wiederherstellungszeit von 900 Sekunden an den benachbarten Router B gesendet. Der Router B hat jedoch seine maximale Wiederherstellungszeit bei 400 Sekunden konfiguriert. Router B wartet nur 400 Sekunden, bevor er seine LDP-Informationen von Router A bereinigen wird.
Um die Wiederherstellungszeit zu konfigurieren, fügen Sie die recovery-time
Anweisung und die maximum-neighbor-recovery-time
Anweisung ein:
graceful-restart { maximum-neighbor-recovery-time seconds; recovery-time seconds; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen konfigurieren können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.
Filtern eingehender LDP-Label-Bindungen
Sie können empfangene LDP-Labelbindungen filtern und Richtlinien anwenden, um von benachbarten Routern angekündigte Bindungen zu akzeptieren oder abzulehnen. Um das Filtern von empfangenen Labeln zu konfigurieren, geben Sie die import
Anweisung ein:
import [ policy-names ];
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Die benannte Richtlinie (auf Hierarchieebene [edit policy-options]
konfiguriert) wird auf alle Labelbindungen angewendet, die von allen LDP-Nachbarn empfangen wurden. Die gesamte Filterung erfolgt mit from
Anweisungen. Tabelle 1 Liste der einzigen from
Operatoren, die sich auf die LDP-Filterung mit empfangenen Labeln beziehen.
from Operator |
Beschreibung |
---|---|
|
Treffer bei Bindungen, die von einem Nachbarn empfangen werden, der über der angegebenen Schnittstelle nebeneinander liegt |
|
Treffer bei Bindungen, die von der angegebenen LDP-Router-ID empfangen wurden |
|
Treffer bei Bindungen, die von einem Nachbarn empfangen werden, der die angegebene Schnittstellenadresse angibt |
|
Gleicht bei Bindungen mit dem angegebenen Präfix ab |
Wenn eine Bindung gefiltert wird, wird sie immer noch in der LDP-Datenbank angezeigt, wird aber nicht als Teil eines Label Switched Path (LSP) für die Installation in Betracht gezogen.
Im Allgemeinen kann die Anwendung von Richtlinien in LDP nur verwendet werden, um die Einrichtung von LSPs zu blockieren, nicht um deren Routing zu kontrollieren. Dies liegt daran, dass der Pfad, den ein LSP folgt, durch Unicast-Routing und nicht durch LDP bestimmt wird. Wenn es jedoch mehrere pfade zu gleichen Kosten über verschiedene Nachbarn zum Ziel gibt, können Sie mithilfe von LDP-Filtern einige der möglichen nächsten Hops von der Prüfung ausschließen. (Andernfalls wählt LDP zufällig einen der möglichen nächsten Hops aus.)
LDP-Sitzungen sind nicht an Schnittstellen oder Schnittstellenadressen gebunden. LDP kündigt nur Label pro Router (nicht pro Schnittstelle) an; Wenn also mehrere parallele Verbindungen zwischen zwei Routern vorhanden sind, wird nur eine LDP-Sitzung eingerichtet und nicht an eine einzige Schnittstelle gebunden. Wenn ein Router mehrere Nachbarschaften zum selben Nachbarn hat, achten Sie darauf, dass der Filter das tut, was erwartet wird. (In diesem Fall ist die Verwendung next-hop
im interface
Allgemeinen nicht geeignet.)
Wenn ein Label gefiltert wurde (was bedeutet, dass es von der Richtlinie abgelehnt wurde und nicht zum Erstellen eines LSP verwendet wird), wird es in der Datenbank als gefiltert markiert:
user@host> show ldp database Input label database, 10.10.255.1:0-10.10.255.6:0 Label Prefix 3 10.10.255.6/32 (Filtered) Output label database, 10.10.255.1:0-10.10.255.6:0 Label Prefix 3 10.10.255.1/32 (Filtered)
Weitere Informationen zur Konfiguration von Richtlinien für LDP finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Beispiele: Filtern eingehender LDP-Label-Bindungen
Nur /32 Präfixe von allen Nachbarn akzeptieren:
[edit] protocols { ldp { import only-32; ... } } policy-options { policy-statement only-32 { term first { from { route-filter 0.0.0.0/0 upto /31; } then reject; } then accept; } }
Von Router-ID 10.10.255.2
oder länger akzeptieren 131.108/16
und alle Präfixe von allen anderen Nachbarn akzeptieren:
[edit] protocols { ldp { import nosy-neighbor; ... } } policy-options { policy-statement nosy-neighbor { term first { from { neighbor 10.10.255.2; route-filter 131.108.0.0/16 orlonger accept; route-filter 0.0.0.0/0 orlonger reject; } } then accept; } }
Herausfiltern ausgehender LDP-Label-Bindungen
Sie können Exportrichtlinien so konfigurieren, dass LDP-Ausgehende Labels gefiltert werden. Sie können ausgehende Label-Bindungen filtern, indem Sie Routing-Richtlinien anwenden, um zu blockieren, dass Bindungen an benachbarte Router angeboten werden. Um das Filtern ausgehender Label zu konfigurieren, fügen Sie die export
Anweisung ein:
export [policy-name];
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Die benannte Exportrichtlinie (auf Hierarchieebene [edit policy-options]
konfiguriert) wird auf alle Labelbindungen angewendet, die an alle LDP-Nachbarn übertragen werden. Der einzige from
Operator, der für die LDP-Outbound-Labelfilterung gilt, ist route-filter
, der Bindungen mit dem angegebenen Präfix abgleicht. Die einzigen to
Operatoren, die sich auf die Outbound-Labelfilterung anwenden, sind die Operatoren in Tabelle 2.
zum Betreiber |
Beschreibung |
---|---|
|
Treffer bei Bindungen, die an einen Benachbarten über die angegebene Schnittstelle gesendet werden |
|
Treffer bei Bindungen, die an die angegebene LDP-Router-ID gesendet wurden |
|
Treffer bei Bindungen, die an einen Nachbarn gesendet werden, der die angegebene Schnittstellenadresse angibt |
Wenn eine Bindung gefiltert wird, wird die Bindung nicht an den benachbarten Router angekündigt, sondern kann als Teil eines LSP auf dem lokalen Router installiert werden. Sie können Richtlinien in LDP anwenden, um die Einrichtung von LSPs zu blockieren, aber nicht, um deren Routing zu steuern. Der Pfad, den ein LSP verfolgt, wird durch Unicast-Routing bestimmt, nicht durch LDP.
LDP-Sitzungen sind nicht an Schnittstellen oder Schnittstellenadressen gebunden. LDP kündigt nur Label pro Router (nicht pro Schnittstelle) an. Wenn mehrere parallele Verbindungen zwischen zwei Routern vorhanden sind, wird nur eine LDP-Sitzung eingerichtet und nicht an eine einzige Schnittstelle gebunden.
Verwenden Sie die next-hop
Und-Betreiber interface
nicht, wenn ein Router mehrere Nachbarschaften zum selben Nachbarn hat.
Gefilterte Labels werden in der Datenbank markiert:
user@host> show ldp database Input label database, 10.10.255.1:0-10.10.255.3:0 Label Prefix 100007 10.10.255.2/32 3 10.10.255.3/32 Output label database, 10.10.255.1:0-10.10.255.3:0 Label Prefix 3 10.10.255.1/32 100001 10.10.255.6/32 (Filtered)
Weitere Informationen zur Konfiguration von Richtlinien für LDP finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Beispiele: Herausfiltern ausgehender LDP-Label-Bindungen
Die Übertragung der Route an 10.10.255.6/32
beliebige Nachbarn blockieren:
[edit protocols] ldp { export block-one; } policy-options { policy-statement block-one { term first { from { route-filter 10.10.255.6/32 exact; } then reject; } then accept; } }
Nur 131.108/16
oder länger an Router-ID 10.10.255.2
senden und alle Präfixe an alle anderen Router senden:
[edit protocols] ldp { export limit-lsps; } policy-options { policy-statement limit-lsps { term allow-one { from { route-filter 131.108.0.0/16 orlonger; } to { neighbor 10.10.255.2; } then accept; } term block-the-rest { to { neighbor 10.10.255.2; } then reject; } then accept; } }
Angabe der von LDP verwendeten Transportadresse
Router müssen zunächst eine TCP-Sitzung untereinander einrichten, bevor sie eine LDP-Sitzung einrichten können. Die TCP-Sitzung ermöglicht es den Routern, die für die LDP-Sitzung erforderlichen Label-Advertisements auszutauschen. Um die TCP-Sitzung einzurichten, muss jeder Router die Transportadresse des anderen Routers erlernen. Die Übertragungsadresse ist eine IP-Adresse, die verwendet wird, um die TCP-Sitzung zu identifizieren, über die die LDP-Sitzung ausgeführt wird.
Um die LDP-Transportadresse zu konfigurieren, fügen Sie die Transportadressenanweisung ein:
transport-address (router-id | interface);
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Wenn Sie die router-id
Option angeben, wird die Adresse des Router-Identifiers als Transportadresse verwendet (sofern nicht anders konfiguriert, entspricht die Router-Kennung in der Regel der Loopback-Adresse). Wenn Sie die interface
Option angeben, wird die Schnittstellenadresse als Übertragungsadresse für alle LDP-Sitzungen zu Nachbarn verwendet, die über diese Schnittstelle erreicht werden können. Beachten Sie, dass standardmäßig die Router-Kennung als Transportadresse verwendet wird.
Sie können die interface
Option nicht angeben, wenn mehrere parallele Verbindungen zum selben LDP-Nachbarn vorhanden sind, da die LDP-Spezifikation erfordert, dass dieselbe Transportadresse auf allen Schnittstellen zum selben Nachbarn angekündigt wird. Wenn LDP mehrere parallele Verbindungen zum selben Nachbarn erkennt, deaktiviert es Schnittstellen zu diesem Nachbarn nacheinander, bis die Bedingung gelöscht wird, entweder durch die Trennung des Nachbarn auf einer Schnittstelle oder durch Angabe der router-id
Option.
Steuerungsübertragungsadresse, die für zielgerichtete LDP-Sitzungen verwendet wird
Um eine TCP-Sitzung zwischen zwei Geräten einzurichten, muss jedes Gerät die Übertragungsadresse des anderen Geräts erlernen. Die Übertragungsadresse ist eine IP-Adresse, die verwendet wird, um die TCP-Sitzung zu identifizieren, über die die LDP-Sitzung ausgeführt wird. Früher kann es sich bei dieser Übertragungsadresse nur um die Router-ID oder eine Schnittstellenadresse handelt. Mit der LDP-Transportadressfunktion können Sie jede IP-Adresse explizit als Transportadresse für gezielte LDP-Nachbarn für Layer-2-Circuit-, MPLS- und VPLS-Nachbarschaften konfigurieren. Auf diese Weise können Sie die zielgerichteten LDP-Sitzungen mithilfe der Transportadressenkonfiguration steuern.
- Vorteile der Steuerung der Transportadresse, die für zielgerichtete LDP-Sitzungen verwendet wird
- Übersicht über zielgerichtete LDP-Übertragungsadressen
- Bevorzugte Transportadressen
- Fehlerbehebung bei der Konfiguration von Übertragungsadressen
Vorteile der Steuerung der Transportadresse, die für zielgerichtete LDP-Sitzungen verwendet wird
Die Konfiguration der Übertragungsadresse für die Einrichtung zielgerichteter LDP-Sitzungen hat die folgenden Vorteile:
Flexible interface configurations— Bietet die Flexibilität, mehrere IP-Adressen für eine Loopback-Schnittstelle zu konfigurieren, ohne die Erstellung einer LDP-Sitzung zwischen den zielgerichteten LDP-Nachbarn zu unterbrechen.
Ease of operation— Die auf Schnittstellenebene konfigurierte Transportadresse ermöglicht die Verwendung von mehr als einem Protokoll im IGP-Backbone für LDP. Dies ermöglicht einen reibungslosen und einfachen Betrieb.
Übersicht über zielgerichtete LDP-Übertragungsadressen
Vor junos OS Version 19.1R1 unterstützte LDP nur die Router-ID oder die Schnittstellenadresse als Übertragungsadresse auf jeder LDP-Schnittstelle. Die an dieser Schnittstelle gebildeten Nachbarschaften verwendeten eine der IP-Adressen, die der Schnittstelle oder der Router-ID zugewiesen wurden. Bei gezielter Nachbarschaft ist die Schnittstelle die Loopback-Schnittstelle. Wenn mehrere Loopback-Adressen auf dem Gerät konfiguriert wurden, konnte die Übertragungsadresse nicht für die Schnittstelle abgeleitet werden, und infolgedessen konnte die LDP-Sitzung nicht eingerichtet werden.
Ab Junos OS Version 19.1R1 können Sie zusätzlich zu den standardmäßigen IP-Adressen, die für die Transportadresse von zielgerichteten LDP-Sitzungen verwendet werden, auch jede andere IP-Adresse als Transportadresse unter den session
, session-group
und interface
Konfigurationsanweisungen konfigurieren. Die Konfiguration der Transportadresse gilt nur für konfigurierte Nachbarn, einschließlich Layer-2-Circuits, MPLS und VPLS-Nachbarschaften. Diese Konfiguration gilt nicht für erkannte Nachbarschaften (zielgerichtet oder nicht).
Bevorzugte Transportadressen
Sie können die Transportadresse für zielgerichtete LDP-Sitzungen auf Sitzungs-, Sitzungs- und Schnittstellenebene konfigurieren.
Nach der Konfiguration der Übertragungsadresse wird die zielgerichtete LDP-Sitzung basierend auf der Präferenz der Übertragungsadresse von LDP festgelegt.
Die Reihenfolge der Präferenz der Transportadresse für den zielgerichteten Nachbarn (konfiguriert über Layer-2-Schaltung, MPLS, VPLS und LDP-Konfiguration) lautet wie folgt:
Unter
[edit protocols ldp session]
Hierarchie.Unter
[edit protocols ldp session-group]
Hierarchie.Unter
[edit protocols ldp interfcae lo0]
Hierarchie.Unter
[edit protocols ldp]
Hierarchie.Standardadresse.
Die Reihenfolge der Präferenz der Transportadresse für die entdeckten Nachbarn lautet wie folgt:
Unter
[edit protocols ldp interfcae]
Hierarchie.Unter
[edit protocols ldp]
Hierarchie.Standardadresse.
Die Reihenfolge der Einstellung der Transportadresse für auto-zielgerichtete Nachbarn, bei denen LDP so konfiguriert ist, dass sie Hello-Pakete akzeptieren, lautet wie folgt:
Unter
[edit protocols ldp interfcae lo0]
Hierarchie.Unter
[edit protocols ldp]
Hierarchie.Standardadresse.
Fehlerbehebung bei der Konfiguration von Übertragungsadressen
Sie können die folgenden Show-Befehlsausgänge verwenden, um die Fehlerbehebung bei zielgerichteten LDP-Sitzungen zu beheben:
show ldp session
show ldp neighbor
Die
detail
Ausgabeebene desshow ldp neighbor
Befehls zeigt die Transportadresse an, die in den Hello-Nachrichten an den zielspezifischen Nachbarn gesendet wird. Wenn diese Adresse vom Nachbarn nicht erreichbar ist, wird die LDP-Sitzung nicht abgerufen.show configuration protocols ldp
Sie können auch LDP-Traceoptions für die weitere Fehlerbehebung aktivieren.
Wenn die Konfiguration von der Verwendung einer ungültigen (nicht erreichbaren) Übertragungsadresse auf eine gültige Übertragungsadresse geändert wird, können die folgenden Spuren beobachtet werden:
May 29 10:47:11.569722 Incoming connect from 10.55.1.4 May 29 10:47:11.570064 Connection 10.55.1.4 state Closed -> Open May 29 10:47:11.570727 Session 10.55.1.4 state Nonexistent -> Initialized May 29 10:47:11.570768 Session 10.55.1.4 state Initialized -> OpenRec May 29 10:47:11.570799 LDP: Session param Max PDU length 4096 from 10.55.1.4, negotiated 4096 May 29 10:47:11.570823 Session 10.55.1.4 GR state Nonexistent -> Operational May 29 10:47:11.669295 Session 10.55.1.4 state OpenRec -> Operational May 29 10:47:11.669387 RPD_LDP_SESSIONUP: LDP session 10.55.1.4 is up
Wenn die Konfiguration von der Verwendung einer gültigen Transportadresse auf eine ungültige (nicht erreichbare) Übertragungsadresse geändert wird, können folgende Spuren beobachtet werden:
May 29 10:42:36.317942 Session 10.55.1.4 GR state Operational -> Nonexistent May 29 10:42:36.318171 Session 10.55.1.4 state Operational -> Closing May 29 10:42:36.318208 LDP session 10.55.1.4 is down, reason: received notification from peer May 29 10:42:36.318236 RPD_LDP_SESSIONDOWN: LDP session 10.55.1.4 is down, reason: received notification from peer May 29 10:42:36.320081 Connection 10.55.1.4 state Open -> Closed May 29 10:42:36.322411 Session 10.55.1.4 state Closing -> Nonexistent
Führen Sie im Falle einer fehlerhaften Konfiguration die folgenden Fehlerbehebungsaufgaben aus:
Überprüfen Sie die
address family
. Die Transportadresse, die unter dersession
Anweisung konfiguriert ist, muss zur gleichen Adressfamilie gehören wie der Nachbar oder die Sitzung.Die Adresse, die als Transportadresse unter einer
neighbor
Oder-Anweisungsession
konfiguriert ist, muss lokal zum Router sein, damit die angestrebten Hello-Nachrichten gestartet werden können. Sie können überprüfen, ob die Adresse konfiguriert ist. Wenn die Adresse nicht unter einer Schnittstelle konfiguriert ist, wird die Konfiguration abgelehnt.
Konfigurieren der in LDP angekündigten Präfixe aus der Routing-Tabelle
Sie können den Satz von Präfixen steuern, die in LDP angegeben werden, und dafür sorgen, dass der Router der Ausgangsrouter für diese Präfixe ist. Standardmäßig wird nur die Loopback-Adresse in LDP angezeigt. Um den Satz von Präfixen aus der Routingtabelle zu konfigurieren, die in LDP eingesenkbar werden sollen, fügen Sie die egress-policy
Anweisung ein:
egress-policy policy-name;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Wenn Sie eine Ausgangsrichtlinie für LDP konfigurieren, die die Loopback-Adresse nicht enthält, wird sie nicht mehr in LDP angekündigt. Um die Loopback-Adresse weiterhin anzuzeigen, müssen Sie sie explizit als Teil der LDP-Ausgangsrichtlinie konfigurieren.
Die benannte Richtlinie (konfiguriert auf der [edit policy-options]
Oderhierarchieebene [edit logical-systems logical-system-name policy-options]
) wird auf alle Routen in der Routingtabelle angewendet. Die Routen, die mit der Richtlinie übereinstimmen, werden in LDP eingesenkt. Sie können den Satz von Nachbarn steuern, denen diese Präfixe mithilfe der export
Anweisung angekündigt werden. Es werden nur from Betreiber berücksichtigt; Sie können jeden gültigen from Betreiber verwenden. Weitere Informationen finden Sie in der Junos OS Routing Protocols Library for Routing Devices.
Router der ACX-Serie unterstützen keine [edit logical-systems
] Hierarchieebene.
Beispiel: Konfigurieren der in LDP angekündigten Präfixe
Alle verbundenen Routen in LDP anzeigen:
[edit protocols] ldp { egress-policy connected-only; } policy-options { policy-statement connected-only { from { protocol direct; } then accept; } }
Konfigurieren der FEC-Deaggregation
Wenn ein LDP-Ausgangsrouter mehrere Präfixe ankündigt, sind die Präfixe an ein einzelnes Label gebunden und in einer einzigen Weiterleitungsgleichheitsklasse (FEC) aggregiert. Standardmäßig behält LDP diese Aggregation bei, wenn die Anzeige das Netzwerk durchläuft.
Da ein LSP normalerweise nicht auf mehrere next Hops verteilt ist und die Präfixe an einen einzelnen LSP gebunden sind, erfolgt kein Load Balancing über Gleichkostenpfade. Sie können jedoch bei der Konfiguration einer Load Balancing-Richtlinie und der Deaggregation der FECs den Lastausgleich über kostengleiche Pfade ermöglichen.
Durch die Deaggregation der FECs wird jedes Präfix an ein separates Label gebunden und zu einem separaten LSP.
Um deaggregierte FECs zu konfigurieren, fügen Sie die deaggregate
Anweisung ein:
deaggregate;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Für alle LDP-Sitzungen können Sie deaggregierte FECs nur global konfigurieren.
Durch die Deaggregation eines FEC können die resultierenden mehrere LSPs auf mehrere zu gleichen Kosten verteilte Pfade verteilt werden und LSPs über mehrere nächste Hops auf den Ausgangssegmenten verteilt werden, aber nur einen nächsten Hop pro LSP installieren.
Um FECs zu aggregieren, fügen Sie die no-deaggregate
Anweisung ein:
no-deaggregate;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Für alle LDP-Sitzungen können Sie aggregierte FECs nur global konfigurieren.
Konfigurieren von Policern für LDP-FECs
Sie können Junos OS so konfigurieren, dass der Datenverkehr für LDP-FECs verfolgt und kontrolliert wird. LDP-FEC-Policer können für einen der folgenden Aufgaben verwendet werden:
Verfolgen oder überwachen Sie den eingehenden Datenverkehr für ein LDP-FEC.
Verfolgen oder überwachen Sie den Transitdatenverkehr für ein LDP-FEC.
Verfolgen oder Überwachen von LDP-FEC-Datenverkehr, der von einer bestimmten Weiterleitungsklasse stammt.
Verfolgen oder Überwachen von LDP-FEC-Datenverkehr, der von einer bestimmten virtuellen Routing- und Weiterleitungs-Site (VRF) stammt.
Verwerfen Sie falschen Datenverkehr, der für einen bestimmten LDP-FEC gebunden ist.
Um den Datenverkehr für ein LDP-FEC zu steuern, müssen Sie zunächst einen Filter konfigurieren. Insbesondere müssen Sie entweder die interface
Anweisung oder die interface-set
Anweisung auf der [edit firewall family protocol-family filter filter-name term term-name from]
Hierarchieebene konfigurieren. Mit interface
der Anweisung können Sie den Filter an eine einzige Schnittstelle anpassen. Mit interface-set
der Anweisung können Sie den Filter an mehrere Schnittstellen anpassen.
Weitere Informationen zur Konfiguration der interface
Anweisung, der interface-set
Anweisung und der Policer für LDP-FECs finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Sobald Sie die Filter konfiguriert haben, müssen sie in die Anweisungskonfiguration policing
für LDP eingefügt werden. Um Policer für LDP-FECs zu konfigurieren, fügen Sie die policing
Anweisung ein:
policing { fec fec-address { ingress-traffic filter-name; transit-traffic filter-name; } }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Die policing
Erklärung umfasst die folgenden Optionen:
fec
– Geben Sie die FEC-Adresse für das LDP-FEC an, das Sie policen möchten.ingress-filter
– Geben Sie den Namen des Eingehenden Datenverkehrsfilters an.transit-traffic
– Geben Sie den Namen des Transitdatenverkehrsfilters an.
Konfigurieren von LDP-IPv4-FEC-Filterung
Wenn eine zielgerichtete LDP-Sitzung eingerichtet wird, tauscht Junos OS standardmäßig immer sowohl die IPv4-Weiterleitungsgleichheitsklassen (FECs) als auch die Layer-2-Circuit-FECs über die angestrebte LDP-Sitzung aus. Für eine LDP-Sitzung an einen indirekt verbundenen Nachbarn möchten Sie möglicherweise nur Layer-2-Circuit-FECs an den Nachbarn exportieren, wenn die Sitzung speziell für die Unterstützung von Layer-2-Circuits oder VPLS konfiguriert wurde.
In einem Netzwerk mit gemischten Anbietern, in dem alle Nicht-BGP-Präfixe in LDP angegeben werden, kann die LDP-Datenbank groß werden. Für diese Art von Umgebung kann es nützlich sein, die Anzeige von IPv4-FECs über LDP-Sitzungen zu verhindern, die aufgrund der Layer-2-Circuit- oder LDP-VPLS-Konfiguration gebildet wurden. Ebenso kann es nützlich sein, alle IPv4-FECs zu filtern, die in dieser Art von Umgebung empfangen werden.
Wenn alle LDP-Nachbarn, die einer LDP-Sitzung zugeordnet sind, nur Layer 2 sind, können Sie das Junos OS so konfigurieren, dass nur Layer-2-Circuit-FECs angekündigt werden, indem Sie die l2-smart-policy
Anweisung konfigurieren. Diese Funktion filtert auch automatisch die IPv4-FECs heraus, die auf dieser Sitzung empfangen wurden. Die Konfiguration einer expliziten Export- oder Importrichtlinie, die zum l2-smart-policy
Deaktivieren dieser Funktion in der entsprechenden Richtung aktiviert ist.
Wenn einer der Nachbarn der LDP-Sitzung aufgrund einer entdeckten Nachbarschaft gebildet wird oder wenn die Nachbarschaft aufgrund einer LDP-Tunneling-Konfiguration auf einem oder mehreren RSVP-LSPs gebildet wird, werden die IPv4-FECs mithilfe des Standardverhaltens angekündigt und empfangen.
Um zu verhindern, dass LDP IPv4-FECs über LDP-Sitzungen nur mit Layer-2-Nachbarn exportiert und IPv4-FECs, die über solche Sitzungen empfangen wurden, herausfiltert, fügen Sie die l2-smart-policy
Anweisung ein:
l2-smart-policy;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie in der Statement-Zusammenfassung für diese Anweisung.
BfD-Konfiguration für LDP-LSPs
Sie können Bidirectional Forwarding Detection (BFD) für LDP-LSPs konfigurieren. Das BFD-Protokoll ist ein einfacher Hello-Mechanismus, der Ausfälle in einem Netzwerk erkennt. Hallo Pakete werden in einem festgelegten, regelmäßigen Intervall gesendet. Ein Nachbarfehler wird erkannt, wenn der Router nach einem festgelegten Intervall keine Antwort mehr erhält. Das BFD arbeitet mit einer Vielzahl von Netzwerkumgebungen und Topologien. Die Fehlererkennungs-Timer für BFD haben kürzere Zeitlimits als die Mechanismen zur Fehlererkennung statischer Routen und sorgen so für eine schnellere Erkennung.
Wenn eine BFD-Sitzung für einen Pfad ausfällt, wird ein Fehler protokolliert. Im Folgenden wird dargestellt, wie BFD für LDP-LSP-Protokollmeldungen angezeigt werden kann:
RPD_LDP_BFD_UP: LDP BFD session for FEC 10.255.16.14/32 is up RPD_LDP_BFD_DOWN: LDP BFD session for FEC 10.255.16.14/32 is down
Sie können auch BFD für RSVP-LSPs konfigurieren, wie unter Konfigurieren von BFD für RSVP-signalisierte LSPs beschrieben.
Die Zeitgeber für die Fehlererkennung des BFD sind anpassungsfähig und können so angepasst werden, dass sie mehr oder weniger aggressiv sind. Die Timer können sich beispielsweise an einen höheren Wert anpassen, wenn die Nachbarschaft ausfällt, oder ein Nachbar kann einen höheren Wert für einen Timer aushandeln als der konfigurierte Wert. Die Timer passen sich an einen höheren Wert an, wenn eine BFD-Sitzungs-Flap in einer Zeitspanne von 15 Sekunden mehr als das Dreifache erfolgt. Ein Back-off-Algorithmus erhöht das Empfangsintervall (Rx) um zwei, wenn die lokale BFD-Instanz der Grund für die Sitzungs-Flap ist. Das Übertragungsintervall (Tx) wird um zwei erhöht, wenn die BfD-Remoteinstanz der Grund für die Sitzungs-Flap ist. Sie können den clear bfd adaptation
Befehl verwenden, um BFD-Intervall-Timer an die konfigurierten Werte zurückzugeben. Der clear bfd adaptation
Befehl ist hitless, was bedeutet, dass der Befehl keinen Einfluss auf den Datenverkehrsfluss auf dem Routinggerät hat.
Um BFD für LDP-LSPs zu aktivieren, fügen Sie die oam
folgenden Anweisungen und bfd-liveness-detection
Anweisungen ein:
oam { bfd-liveness-detection { detection-time threshold milliseconds; ecmp; failure-action { remove-nexthop; remove-route; } holddown-interval seconds; ingress-policy ingress-policy-name; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-transmit-interval milliseconds; multiplier detection-time-multiplier; no-adaptation; transmit-interval { minimum-interval milliseconds; threshold milliseconds; } version (0 | 1 | automatic); } fec fec-address { bfd-liveness-detection { detection-time threshold milliseconds; ecmp; failure-action { remove-nexthop; remove-route; } holddown-interval milliseconds; ingress-policy ingress-policy-name; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-transmit-interval milliseconds; multiplier detection-time-multiplier; no-adaptation; transmit-interval { minimum-interval milliseconds; threshold milliseconds; } version (0 | 1 | automatic); } no-bfd-liveness-detection; periodic-traceroute { disable; exp exp-value; fanout fanout-value; frequency minutes; paths number-of-paths; retries retry-attempts; source address; ttl ttl-value; wait seconds; } } lsp-ping-interval seconds; periodic-traceroute { disable; exp exp-value; fanout fanout-value; frequency minutes; paths number-of-paths; retries retry-attempts; source address; ttl ttl-value; wait seconds; } }
Sie können BFD für die LDP-LSPs aktivieren, die mit einer bestimmten Forwarding Equivalence Class (FEC) verknüpft sind, indem Sie die FEC-Adresse mit der fec
Option auf Hierarchieebene [edit protocols ldp]
konfigurieren. Alternativ können Sie eine OAM-Eingangsrichtlinie (Operation Administration and Management) konfigurieren, um BFD auf einer Reihe von FEC-Adressen zu aktivieren. Weitere Informationen finden Sie unter Konfigurieren von OAM-Eingangsrichtlinien für LDP.
Sie können BFD-LDP-LSPs nur aktivieren, wenn ihre entsprechenden FEC-Adressen explizit konfiguriert sind oder OAM auf den FECs mit einer OAM-Eingangsrichtlinie aktiviert ist. Wenn das BFD für keine FEC-Adressen aktiviert ist, wird die BFD-Sitzung nicht eingeschaltet.
Sie können die oam
Anweisung auf den folgenden Hierarchieebenen konfigurieren:
[edit protocols ldp]
[edit logical-systems logical-system-name protocols ldp]
Router der ACX-Serie unterstützen keine [edit logical-systems
] Hierarchieebene.
Die oam
Erklärung umfasst die folgenden Optionen:
fec
– Geben Sie die FEC-Adresse an. Sie müssen entweder eine FEC-Adresse angeben oder eine OAM-Eingangsrichtlinie konfigurieren, um sicherzustellen, dass die BFD-Sitzung hochkommt.lsp-ping-interval
– Geben Sie die Dauer des LSP-Ping-Intervalls in Sekunden an. Verwenden Sie denping mpls ldp
Befehl, um einen Ping auf einem LDP-signalisierten LSP auszugeben. Weitere Informationen finden Sie im CLI-Explorer.
Die bfd-liveness-detection
Erklärung umfasst die folgenden Optionen:
ecmp
— Ursache: LDP erstellt BFD-Sitzungen für alle für das angegebene FEC konfigurierten ECMP-Pfade. Wenn Sie dieecmp
Option konfigurieren, müssen Sie auch dieperiodic-traceroute
Anweisung für das angegebene FEC konfigurieren. Wenn Sie dies nicht tun, schlägt der Commit-Vorgang fehl. Sie können dieperiodic-traceroute
Anweisung auf globaler Hierarchieebene[edit protocols ldp oam]
() konfigurieren, während Sie nur dieecmp
Option für ein bestimmtes FEC ([edit protocols ldp oam fec address bfd-liveness-detection]
) konfigurieren.Holddown-Intervall: Geben Sie die Dauer an, die die BFD-Sitzung beibehalten soll, bevor Sie die Route oder den nächsten Hop hinzufügen. Die Angabe einer Zeit von 0 Sekunden bewirkt, dass die Route oder der nächste Hop hinzugefügt werden, sobald die BFD-Sitzung wieder verfügbar ist.
minimum-interval
— Geben Sie das minimale Übertragungs- und Empfangsintervall an. Wenn Sie dieminimum-interval
Option konfigurieren, müssen Sie dieminimum-receive-interval
Option oder dieminimum-transmit-interval
Option nicht konfigurieren.minimum-receive-interval
— Geben Sie das mindeste Empfangsintervall an. Der Bereich liegt zwischen 1 und 255.000 Millisekunden.minimum-transmit-interval
— Geben Sie das minimale Übertragungsintervall an. Der Bereich liegt zwischen 1 und 255.000 Millisekunden.multiplier
– Geben Sie den Erkennungszeitmultiplikator an. Der Bereich liegt zwischen 1 und 255.Version – Geben Sie die BFD-Version an. Die Optionen sind BFD Version 0 oder BFD Version 1. Standardmäßig versucht die Junos OS-Software, die BFD-Version automatisch zu bestimmen.
Konfigurieren von ECMP-aware BFD für LDP-LSPs
Wenn Sie BFD für ein FEC konfigurieren, wird eine BFD-Sitzung für nur einen aktiven lokalen Next-Hop für den Router eingerichtet. Sie können jedoch mehrere BFD-Sitzungen konfigurieren, eine für jedes FEC, das einem bestimmten EcMP-Pfad (Equal-Cost Multipath) zugeordnet ist. Damit dies ordnungsgemäß funktioniert, müssen Sie auch die periodische LDP-LSP-Traceroute konfigurieren. (Siehe Konfigurieren von LDP LSP Traceroute.) LDP LSP-Traceroute wird zur Erkennung von ECMP-Pfaden verwendet. Für jeden entdeckten ECMP-Pfad wird eine BFD-Sitzung eingeleitet. Wenn eine BFD-Sitzung für einen der ECMP-Pfade ausfällt, wird ein Fehler protokolliert.
LDP LSP Traceroute wird regelmäßig ausgeführt, um die Integrität der ECMP-Pfade zu überprüfen. Das Folgende kann auftreten, wenn ein Problem erkannt wird:
Wenn sich die neueste LDP-LSP-Traceroute für ein FEC von der vorherigen Traceroute unterscheidet, werden die mit diesem FEC verknüpften BFD-Sitzungen (die BFD-Sitzungen für Adressbereiche, die sich von der vorherigen Ausführung geändert haben) heruntergefahren und neue BFD-Sitzungen für die Zieladressen in den geänderten Bereichen initiiert.
Wenn der LDP-LSP-Traceroute einen Fehler zurückgibt (z. B. ein Timeout), werden alle BFD-Sitzungen, die mit diesem FEC verknüpft sind, heruntergerissen.
Um LDP zu konfigurieren, um BFD-Sitzungen für alle für das angegebene FEC konfigurierten ECMP-Pfade zu erstellen, fügen Sie die ecmp
Anweisung ein.
ecmp;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Zusammen mit der ecmp
Anweisung müssen Sie die periodic-traceroute
Anweisung entweder in die globale LDP-OAM-Konfiguration (auf der [edit protocols ldp oam]
oder [edit logical-systems logical-system-name protocols ldp oam]
Hierarchieebene) oder in die Konfiguration für das angegebene FEC (auf der [edit protocols ldp oam fec address]
oder [edit logical-systems logical-system-name protocols ldp oam fec address]
Hierarchieebene) einbeziehen. Andernfalls schlägt der Commit-Vorgang fehl.
Router der ACX-Serie unterstützen keine [edit logical-systems
] Hierarchieebene.
Konfigurieren einer Fehleraktion für die BFD-Sitzung auf einem LDP-LSP
Sie können Routen- und Next-Hop-Eigenschaften im Falle eines Ausfalls einer BFD-Sitzung auf einem LDP-LSP konfigurieren. Das Fehlerereignis kann eine bestehende BFD-Sitzung sein, die ausgefallen ist, oder eine BFD-Sitzung sein, die nie aufgetreten ist. LDP fügt die Route oder den nächsten Hop zurück, wenn die relevante BFD-Sitzung wieder aktiviert wird.
Sie können eine der folgenden Fehleraktionsoptionen für die failure-action
Anweisung im Falle eines Ausfalls einer BFD-Sitzung auf dem LDP-LSP konfigurieren:
remove-nexthop
— Entfernt die Route, die dem nächsten Hop der LSP-Route am Eingangsknoten entspricht, wenn ein BFD-Sitzungsausfallereignis erkannt wird.remove-route
— Entfernt die dem LSP entsprechende Route aus den entsprechenden Routingtabellen, wenn ein BFD-Sitzungsfehlerereignis erkannt wird. Wenn der LSP mit ECMP konfiguriert ist und eine BFD-Sitzung entsprechend jedem Pfad abstürzt, wird die Route entfernt.
Um eine Fehleraktion im Falle eines Ausfalls einer BFD-Sitzung auf einem LDP-LSP zu konfigurieren, fügen Sie entweder die remove-nexthop
Option oder die Option für die remove-route
failure-action
Anweisung ein:
failure-action { remove-nexthop; remove-route; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren des Holddown-Intervalls für die BFD-Sitzung
Sie können die Dauer angeben, für die die BFD-Sitzung hoch sein soll, bevor Sie eine Route oder den nächsten Hop hinzufügen, indem Sie die holddown-interval
Anweisung entweder auf der [edit protocols ldp oam bfd-livenesss-detection]
Hierarchieebene oder auf der [edit protocols ldp oam fec address bfd-livenesss-detection]
Hierarchieebene konfigurieren. Die Angabe einer Zeit von 0 Sekunden bewirkt, dass die Route oder der nächste Hop hinzugefügt werden, sobald die BFD-Sitzung wieder verfügbar ist.
holddown-interval seconds;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren von LDP-Verbindungsschutz
Sie können den Label Distribution Protocol (LDP)-Verbindungsschutz für Unicast- und Multicast-LDP Label Switched Paths (LSPs) konfigurieren, um Ausfallsicherheit bei Verbindungs- oder Knotenausfällen zu gewährleisten.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie die Router-ID und die autonome Systemnummer für das Gerät.
Konfigurieren Sie die folgenden Protokolle:
RSVP
MPLS mit Traffic-Engineering-Fähigkeit.
OSPF mit Traffic-Engineering-Fähigkeit.
Anmerkung:Aktivieren Sie für den Multicast-LDP-Verbindungsschutz mit loop-free alternative (LFA) den Linkschutz.
[edit protocols] user@R0# set ospf area 0 interface all link-protection
So konfigurieren Sie den LDP-Verbindungsschutz:
Beispiel: Konfigurieren von LDP-Verbindungsschutz
LDP-Link-Schutz – Übersicht
- Einführung in LDP
- Junos OS LDP-Protokollimplementierung
- Verstehen von Multipoint-Erweiterungen für LDP
- Verwenden von Multipoint-Erweiterungen zu LDP bei zielgerichteten LDP-Sitzungen
- Aktuelle Einschränkungen des LDP-Verbindungsschutzes
- RSVP LSP als Lösung verwenden
- Informationen zum Multicast-LDP-Verbindungsschutz
- Verschiedene Modi für die Bereitstellung von LDP-Verbindungsschutz
- Label-Betrieb für LDP-Verbindungsschutz
- Beispielkonfiguration für Multicast-LDP-Verbindungsschutz
- Make-before-Break
- Einschränkungen und Einschränkungen
Einführung in LDP
Das Label Distribution Protocol (LDP) ist ein Protokoll zur Verteilung von Labeln in anwendungen ohne Datenverkehr. LDP ermöglicht Routern die Erstellung von Label-Switched Paths (LSPs) über ein Netzwerk, indem Sie Routinginformationen auf Netzwerkebene direkt den LSPs der Datenverbindung zuordnen.
Diese LSPs verfügen möglicherweise über ein Endgerät an einem direkt angeschlossenen Nachbarn (vergleichbar mit IP Hop-by-Hop-Weiterleitung) oder an einem Netzwerk-Ausgangsknoten, wodurch das Switching über alle Zwischenknoten ermöglicht wird. LSPs, die von LDP eingerichtet wurden, können auch datenverkehrsgesteuerte LSPs durchlaufen, die von RSVP erstellt wurden.
LDP verknüpft eine Forwarding Equivalence Class (FEC) mit jedem erstellten LSP. Das mit einem LSP verbundene FEC gibt an, welche Pakete diesem LSP zugeordnet werden. LSPs werden über ein Netzwerk erweitert, da jeder Router das vom nächsten Hop für das FEC angekündigte Label auswählt und es mit dem Label verbindet, das es allen anderen Routern anwirbt. Dieser Prozess bildet einen Baum von LSPs, die auf dem Ausgangsrouter konvergieren.
Junos OS LDP-Protokollimplementierung
Die Junos OS-Implementierung von LDP unterstützt LDP-Version 1. Junos OS unterstützt einen einfachen Mechanismus für das Tunneling zwischen Routern in einem Interior Gateway Protocol (IGP), um die erforderliche Verteilung externer Routen innerhalb des Cores zu vermeiden. Junos OS ermöglicht einen MPLS-Tunnel Next Hop zu allen Egress-Routern im Netzwerk, wobei nur ein IGP im Core ausgeführt wird, um Routen an Ausgangsrouter zu verteilen. Edge-Router führen BGP aus, verteilen aber keine externen Routen an den Core. Stattdessen löst sich die rekursive Routensuche am Edge auf einen LSP, der auf den Ausgangsrouter umgestellt wird. Auf den Transit-LDP-Routern sind keine externen Routen erforderlich.
Verstehen von Multipoint-Erweiterungen für LDP
Ein LDP definiert Mechanismen für die Einrichtung von Point-to-Point-, Multipoint-to-Point-, Point-to-Multipoint- und Multipoint-zu-Multipoint-LSPs im Netzwerk. Die Point-to-Multipoint- und Multipoint-to-Multipoint-LSPs werden gemeinsam als Multipoint-LSPs bezeichnet, bei denen der Datenverkehr von einer einzelnen Quelle zu mehreren Zielen bzw. von mehreren Quellen zu mehreren Zielen fließt. Die Ziel- oder Ausgangsrouter heißen Leaf-Knoten, und der Datenverkehr von der Quelle durchläuft einen oder mehrere Transitknoten, bevor er die Leaf-Knoten erreicht.
Junos OS bietet keine Unterstützung für Multipoint-to-Multipoint-LSPs.
Durch die Nutzung der MPLS-Paketreplikationsfunktion des Netzwerks vermeiden Multipoint-LSPs unnötige Paketreplikation am Eingangsrouter. Die Paketreplikation erfolgt nur, wenn Pakete an zwei oder mehr verschiedene Ziele weitergeleitet werden, die unterschiedliche Netzwerkpfade erfordern.
Verwenden von Multipoint-Erweiterungen zu LDP bei zielgerichteten LDP-Sitzungen
Die Spezifikation für die Multipoint-Erweiterungen zu LDP erfordert, dass die beiden Endpunkte einer LDP-Sitzung direkt über ein Layer-2-Medium verbunden sind oder vom IGP des Netzwerks als Nachbarn betrachtet werden. Dies wird als LDP-Linksitzung bezeichnet. Wenn die beiden Endpunkte einer LDP-Sitzung nicht direkt verbunden sind, wird die Sitzung als zielgerichtete LDP-Sitzung bezeichnet.
Frühere Junos OS-Implementierungen unterstützen Multicast-LDP nur für Verbindungssitzungen. Mit der Einführung der LDP-Link protection-Funktion werden die Multicast-LDP-Funktionen auf gezielte LDP-Sitzungen erweitert. Abbildung 2 zeigt eine Beispieltopologie.

Die Router R7 und R8 sind die labelvermittelten Router (LSR-U) bzw. Downstream (LSR-D) und implementieren Multicast-LDP. Der Core-Router R5 ist RSVP-TE-fähig.
Wenn LSR-D den Point-to-Multipoint-LSP mit Root- und LSP-ID-Attributen einrichtt, wird der upstreame LSR-U als next-hop auf dem besten Pfad zum Root bestimmt (derzeit wird davon ausgegangen, dass dieser next-hop ein IGP Next Hop ist).
Mit der Multicast-LDP-Unterstützung für gezielte LDP-Sitzungen können Sie feststellen, ob es einen LSP-nächsten Hop zu LSR-U gibt, der sich auf dem LSR-D-Pfad zum Root befindet, wobei LSR-D und LSR-Sie nicht direkt benachbarte, sondern gezielte LDP-Peers sind. Das auf der angestrebten LDP-Sitzung zwischen LSR-D und LSR-U angekündigte Point-to-Multipoint-Label wird nur verwendet, wenn es einen LSP zwischen LSR-D und LSR-U gibt. Daher ist ein entsprechender LSP in umgekehrter Richtung von LSR-you zu LSR-D erforderlich.
Die Daten werden über die Unicastreplikation von Paketen auf den Point-to-Multipoint-LSP übertragen, wobei LSR-U eine Kopie an jede downstream LSR des Point-to-Multipoint-LSP sendet.
Die Datenübertragung erfolgt auf folgende Weise:
Die Point-to-Multipoint-Funktionen der angestrebten LDP-Sitzung werden ausgehandelt.
Der Algorithmus zur Auswahl des upstreamen LSR wird geändert, wobei, wenn IGP Next Hops nicht verfügbar sind, oder mit anderen Worten, es keine LDP-Linksitzung zwischen LSR-D und LSR-U gibt, wird ein RSVP-LSP als nächster Hop verwendet, um LSR-U zu erreichen.
Die eingehenden Labels, die über die angestrebten LDP-Sitzungen empfangen werden, werden als nächster Zweigstellen-Hop für diese Point-to-Multipoint-FEC-Route mit dem LDP-Label als innerem Label und dem RSVP-Label als äußerem Label installiert.
Aktuelle Einschränkungen des LDP-Verbindungsschutzes
Bei einem Verbindungs- oder Knotenausfall in einer LDP-Netzwerkbereitstellung sollte eine schnelle Wiederherstellung des Datenverkehrs zur Wiederherstellung beeinträchtigter Datenströme für geschäftskritische Services bereitgestellt werden. Im Fall von Multipoint-LSPs werden die Subtree möglicherweise losgelöst, bis das IGP rekonvergiert und der Multipoint-LSP über den besten Pfad vom Downstream-Router zum neuen Upstream-Router eingerichtet wird, wenn eine der Verbindungen der Point-to-Multipoint-Struktur ausfällt.
Bei der schnellen Umleitung mit lokaler Reparatur für LDP-Datenverkehr ist ein Backup-Pfad (Reparaturpfad) in der Packet Forwarding Engine vorinstalliert. Wenn der primäre Pfad ausfällt, wird der Datenverkehr schnell zum Backup-Pfad verschoben, ohne dass auf die Konvergenz der Routingprotokolle gewartet werden muss. Loop-Free Alternate (LFA) ist eine der Methoden zur Bereitstellung von IP-Schnellumleitungsfunktionen in Core- und Service Provider-Netzwerken.
Ohne LFA berechnen die verteilten Routing-Algorithmen die neuen Routen basierend auf den Änderungen im Netzwerk, wenn eine Verbindung oder ein Router ausfällt oder zum Service zurückgegeben wird. Die Zeit, in der die neuen Routen berechnet werden, wird als Routing-Übergang bezeichnet. Bis zum Abschluss des Routing-Übergangs wird die Netzwerkkonnektivität unterbrochen, da die Router neben einem Fehler die Datenpakete weiterhin über die fehlgeschlagene Komponente weiterleiten, bis ein alternativer Pfad identifiziert wird.
Aufgrund der IGP-Metriken bietet die LFA jedoch keine vollständige Abdeckung in allen Netzwerkbereitstellungen. Infolgedessen ist dies eine Beschränkung auf die aktuellen LDP-Verbindungsschutzschemata.
Abbildung 3 zeigt ein Beispielnetzwerk mit unvollständiger LFA-Abdeckung, in dem der Datenverkehr vom Quellrouter (S) zum Zielrouter (D) über Router R1 fließt. Angenommen, dass jede Verbindung im Netzwerk dieselbe Metrik hat, ist der Router R4 bei einem Ausfall der Verbindung zwischen Router S und Router R1 kein LFA, der die S-R1-Verbindung schützt, sodass die Ausfallsicherheit des Datenverkehrs verloren geht. Eine vollständige Abdeckung wird somit nicht durch die Verwendung eines einfachen LFA erreicht. In typischen Netzwerken besteht immer ein gewisser Prozentsatz der LFA-Abdeckungslücke mit einfacher LFA.

RSVP LSP als Lösung verwenden
Der Schlüssel zum Schutz des Datenverkehrs, der durch LDP-LSPs fließt, ist ein expliziter Tunnel, um den Datenverkehr im Falle eines Verbindungs- oder Knotenausfalls umzuleiten. Der explizite Pfad muss auf dem nächsten downstream-Router beendet werden, und der Datenverkehr muss auf dem expliziten Pfad akzeptiert werden, an dem die RPF-Prüfung bestehen sollte.
RSVP-LSPs helfen bei der Überwindung der aktuellen Einschränkungen von Loop-Free Alternate (LFA) für Punkt-zu-Punkt- und Punkt-zu-Multipoint-LDP-LSPs, indem sie die LFA-Abdeckung in den folgenden Methoden erweitern:
Manuell konfigurierte RSVP-LSPs
Unter Berücksichtigung des beispiels in Abbildung 3, wenn die S-R1-Verbindung ausfällt und Router R4 keine LFA für diese bestimmte Verbindung ist, wird ein manuell erstellter RSVP-LSP als Patch verwendet, um eine vollständige LFA-Abdeckung zu gewährleisten. Der RSVP-LSP ist in der Packet Forwarding Engine von Router S vorinstalliert und vorinstalliert, sodass er verwendet werden kann, sobald Router S feststellt, dass die Verbindung ausgefallen ist.

In diesem Fall wird ein RSVP-LSP zwischen den Routern S, R4 und R3 erstellt, wie in Abbildung 4dargestellt. Zwischen Router S und Router R3 wird eine gezielte LDP-Sitzung erstellt, wodurch der Datenverkehr beim Ausfall der S-R1-Verbindung den Router R3 erreicht. Router R3 leitet den Datenverkehr an Router R2 weiter, da er der kürzeste Pfad zum Ziel ist: Router D.
Dynamisch konfigurierte RSVP-LSPs
Bei dieser Methode werden die RSVP-LSPs automatisch erstellt und im System vorinstalliert, sodass sie bei einem Verbindungsfehler sofort verwendet werden können. Hier ist der Ausgang der Knoten auf der anderen Seite der Verbindung, der geschützt wird, wodurch die LFA-Abdeckung verbessert wird.
Benefits of Enabling Dynamic RSVP LSPs
Einfache Konfiguration.
100%ige Abdeckung gegen Verbindungsfehler, solange es einen alternativen Pfad zum ende des zu schützenen Links gibt.
Das Einrichten und Abreißen des RSVP-Bypass-LSP erfolgt automatisch.
RSVP LSP wird nur zum Schutz der Verbindung und nicht für die Weiterleitung des Datenverkehrs verwendet, während die Verbindung geschützt ist.
Reduziert die Gesamtzahl der im System erforderlichen RSVP-LSPs.
Unter Berücksichtigung des Beispiels, das in Abbildung 3verwendet wird, um den Datenverkehr vor dem potenziellen Ausfall der S-R1-Verbindung zu schützen, da Router R4 kein LFA für diese bestimmte Verbindung ist, wird automatisch ein RSVP-Bypass-LSP zu Router R1 erstellt, dem Knoten auf der anderen Seite der geschützten Verbindung, wie in Abbildung 5dargestellt. Vom Router R1 wird der Datenverkehr an sein ursprüngliches Ziel, Router D, weitergeleitet.
Der RSVP-LSP ist vorinstalliert und in der Packet Forwarding Engine von Router S vorinstalliert, sodass er verwendet werden kann, sobald Router S feststellt, dass die Verbindung ausgefallen ist.

Eine alternative Betriebsart besteht darin, LFA überhaupt nicht zu verwenden, und immer den RSVP-LSP erstellen zu lassen, um alle Verbindungsfehler abzudecken.
Um dynamische RSVP-LSPs zu aktivieren, fügen Sie die dynamic-rsvp-lsp
Anweisung auf Hierarchieebene [edit protocols ldp interface interface-name link-protection]
hinzu und aktivieren Sie das RSVP-Protokoll an den entsprechenden Schnittstellen.
Informationen zum Multicast-LDP-Verbindungsschutz
Ein Point-to-Multipoint LDP Label Switched Path (LSP) ist ein LDP-signalisierter LSP, der Point-to-Multipoint ist und als Multicast-LDP bezeichnet wird.
Ein Multicast-LDP-LSP kann verwendet werden, um Datenverkehr von einem einzelnen Stamm- oder Eingangsknoten an eine Reihe von Leaf- oder Ausgangsknoten zu senden, die einen oder mehrere Transitknoten passieren. Multicast LDP-Verbindungsschutz ermöglicht im Falle eines Verbindungsausfalls eine schnelle Umleitung des Datenverkehrs, der über Point-to-Multipoint-LDP-LSPs übertragen wird. Wenn eine der Verbindungen des Point-to-Multipoint-Tree ausfällt, werden die Unterbäume möglicherweise losgelöst, bis das IGP rekonvergiert und der Multipoint-LSP über den besten Pfad vom Downstream-Router zum neuen Upstream-Router eingerichtet wird.
Um den Datenverkehr, der durch den Multicast-LDP-LSP fließt, zu schützen, können Sie einen expliziten Tunnel konfigurieren, um den Datenverkehr im Falle eines Verbindungsausfalls umzuleiten. Der explizite Pfad muss auf dem nächsten Downstream-Router beendet werden. Die Umgekehrte Pfadweiterleitung für den Datenverkehr sollte erfolgreich sein.
Der Multicast-LDP-Linkschutz bietet die folgenden Funktionen:
Verwendung von dynamischem RSVP LSP als Bypass-Tunnel
Das Explicit Route Object (ERO) des RSVP LSP wird mit cspf (Constrained Shortest Path First) berechnet, wobei die Einschränkung als Verbindung zu vermeiden ist. Der LSP wird bei Bedarf dynamisch signalisiert und abgerissen.
Make-before-Break
Die Make-before-Break-Funktion stellt sicher, dass beim Signalisieren eines neuen LSP-Pfads ein minimaler Paketverlust vor dem Abreißen des alten LSP-Pfads für den Multicast-LDP-LSP erfolgt.
Gezielte LDP-Sitzung
Aus zwei Gründen wird eine gezielte Nachbarschaft zum Downstream-Label-Switching-Router (LSR) erstellt:
So halten Sie die Sitzung nach einem Verbindungsfehler aufrecht.
Um das von der Sitzung empfangene Point-to-Multipoint-Label zu verwenden, um Datenverkehr an die Downstream-LSR im RSVP LSP-Bypass-Tunnel zu senden.
Wenn der Downstream-LSR den Multicast-LDP-LSP mit dem Root-Knoten und der LSP-ID einrichtt, verwendet er diese Upstream-LSR, die sich auf dem besten Pfad zum Root befindet.
Multicast LDP-Verbindungsschutz ist nicht erforderlich, wenn mehrere Link-Nachbarschaften (parallele Verbindungen) mit der Downstream-LSR vorhanden sind.
Verschiedene Modi für die Bereitstellung von LDP-Verbindungsschutz
Für den Unicast- und Multicast-LDP-Linkschutz stehen drei verschiedene Betriebsmodi zur Verfügung:
Case A: LFA only
Unter dieser Arbeitsweise wird der Multicast-LDP-Verbindungsschutz mit einer vorhandenen Brauchbaren Schleifenfreien Alternative (LFA) bereitgestellt. Wenn kein praktikables LFA vorhanden ist, ist für den Multicast-LDP-LSP kein Verbindungsschutz vorgesehen.
Case B: LFA and Dynamic RSVP LSP
Unter dieser Betriebsweise wird der Multicast-LDP-Verbindungsschutz über eine vorhandene brauchbare LFA bereitgestellt. Wenn keine praktikable LFA vorhanden ist, wird automatisch ein RSVP-Bypass-LSP erstellt, um den Linkschutz für den Multicast-LDP-LSP bereitzustellen.
Case C: Dynamic RSVP LSP only
Unter dieser Arbeitsweise wird die LFA nicht zum Verbindungsschutz verwendet. Multicast LDP-Verbindungsschutz wird durch die Verwendung automatisch erstellter RSVP-Bypass-LSP bereitgestellt.
Abbildung 6 ist eine Beispieltopologie, die die verschiedenen Betriebsmodi für den Multicast-LDP-Verbindungsschutz veranschaulicht. Der Router R5 ist die Wurzel, die mit zwei Leaf-Knoten, den Routern R3 und R4, verbunden ist. Der Router R0 und der Router R1 sind die upstreamen bzw. downstream labelvermittelten Router (LSRs). Ein Multicast-LDP-LSP wird zwischen den Root- und Leaf-Knoten ausgeführt.

Wenn man bedenkt, dass der Router R0 den Multicast-LDP-LSP schützen muss, wenn die R0-R1-Verbindung ausfällt, werden die verschiedenen Verbindungsschutzmodi wie folgt ausgeführt:
Case A: LFA only
Der Router R0 prüft, ob ein praktikabler LFA-Pfad vorhanden ist, der die Verbindung R0-R1 vermeiden kann, um den Router R1 zu erreichen. Basierend auf den Metriken ist der Router R2 ein gültiger LFA-Pfad für den R0-R1-Link und wird zum Weiterleiten von Unicast-LDP-Datenverkehr verwendet. Wenn mehrere Multicast-LDP-LSPs den R0-R1-Link verwenden, wird dieselbe LFA (Router R2) für den Multicast-LDP-Linkschutz verwendet.
Wenn die Verbindung R0-R1 ausfällt, wird der Multicast-LDP-LSP-Datenverkehr von Router R0 auf den LFA-Pfad verschoben, und das Unicast-LDP-Label, um den Router R1 (L100) zu erreichen, wird über das Multicast-LDP-Label (L21) geschoben.
Case B: LFA and Dynamic RSVP LSP
Der Router R0 prüft, ob ein praktikabler LFA-Pfad vorhanden ist, der die Verbindung R0-R1 vermeiden kann, um den Router R1 zu erreichen. Basierend auf den Metriken ist der Router R2 ein gültiger LFA-Pfad für den R0-R1-Link und wird zum Weiterleiten von Unicast-LDP-Datenverkehr verwendet. Wenn mehrere Multicast-LDP-LSPs den R0-R1-Link verwenden, wird dieselbe LFA (Router R2) für den Multicast-LDP-Linkschutz verwendet. Wenn die Verbindung R0-R1 ausfällt, wird der Multicast-LDP-LSP-Datenverkehr von Router R0 auf den LFA-Pfad verschoben.
Wenn die Metrik auf dem R2-R1-Link jedoch 50 statt 10 war, ist Router 2 ein nicht gültiges LFA für den R0-R1-Link. In diesem Fall wird automatisch ein RSVP-LSP erstellt, um den Multicast-LDP-Datenverkehr zwischen den Routern R0 und R1 zu schützen.
Case C: Dynamic RSVP LSP only
Ein RSVP-LSP wird automatisch von Router R0 über Router R2 an Router R1 signalisiert, wodurch die Schnittstelle ge-1/1/0 vermieden wird. Wenn mehrere Multicast-LDP-LSPs den R0-R1-Link verwenden, wird derselbe RSVP-LSP für den Multicast-LDP-Verbindungsschutz verwendet.
Wenn die Verbindung R0-R1 ausfällt, wird der Multicast-LDP-LSP-Datenverkehr von Router R0 auf den RSVP LSP verschoben, und das RSVP-Label, um den Router R1 (L100) zu erreichen, wird über das Multicast-LDP-Label (L21) geschoben.
Label-Betrieb für LDP-Verbindungsschutz
Die Verwendung derselben Netzwerktopologie wie in Abbildung 5 Abbildung 7 veranschaulicht den Labelbetrieb für Unicast- und Multicast-LDP-Verbindungsschutz.

Der Router R5 ist die Wurzel, die mit zwei Leaf-Knoten, den Routern R3 und R4, verbunden ist. Der Router R0 und der Router R1 sind die upstreamen bzw. downstream labelvermittelten Router (LSRs). Ein Multicast-LDP-LSP wird zwischen den Root- und Leaf-Knoten ausgeführt. Ein Unicast-LDP-Pfad verbindet Router R1 mit Router R5.
Der Label-Betrieb wird unter den folgenden Modi des LDP-Verbindungsschutzes unterschiedlich ausgeführt:
Fall A: Nur LFA
Mithilfe der Befehlsausgabe show route detail
auf Router R0 kann der Unicast-LDP-Datenverkehr und der Multicast-LDP-Datenverkehr abgeleitet werden.
user@R0> show route detail 299840 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Router Address: 0x93bc22c Next-hop reference count: 1 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1, selected Label operation: Swap 299824 Session Id: 0x1 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0xf000 Label operation: Swap 299808 Session Id: 0x3 State: <Active Int> Age: 3:16 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I Prefixes bound to route: 192.168.0.4/32 299856 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x9340e04 Next-hop reference count: 3 Next hop type: Router, Next hop index: 262143 Address: 0x93bc3dc Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1 Label operation: Swap 299888 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0xf000 Label operation: Swap 299888, Push 299776(top) Label TTL action: prop-ttl, prop-ttl(top) State: <Active Int AckRequest> Age: 3:16 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 192.168.0.5, lsp-id 99
Label 299840 ist der Datenverkehr, der am Router R0 ankommt und dem Unicast-LDP-Datenverkehr zu Router R1 entspricht. Label-299856 ist der Datenverkehr, der am Router 0 ankommt und dem Multicast-LDP-Datenverkehr vom Stammknoten R5 zu den Leaf-Ausgangsknoten R3 und R4 entspricht.
Der Hauptpfad für Unicast- und Multicast-LDP-LSPs ist über die Schnittstelle ge-0/0/1 (die Verbindung zu Router R1), und der LFA-Pfad ist über die Schnittstelle ge-0/0/2 (die Verbindung zu Router R2). Der LFA-Pfad wird nur verwendet, wenn die Ge-0/0/1-Schnittstelle ausfällt.
Im Label-Betrieb für Case A unterscheidet sich der nur LFA-Modus für Unicast- und Multicast-LDP-Datenverkehr:
Unicast-Labelbetrieb
Für Unicast-LDP-Datenverkehr werden die FECs und die zugehörigen Labels auf allen Verbindungen im Netzwerk, auf denen LDP aktiviert ist, angekündigt. Das bedeutet, dass Der Router R0 den eingehenden Label-299824, der von Router R1 für FEC R4 angekündigt wird, anstelle des eingehenden Labels für die vom Router R1 für FEC R4 angekündigte Label-299808 zu ersetzen, um den Unicast-LDP-Datenverkehr an Router R4 weiterzuleiten. Dies ist der Standardmäßige Junos OS-LFA-Betrieb für Unicast-LDP-Datenverkehr.
Abbildung 8 zeigt den Label-Vorgang für Unicast-Datenverkehr, wenn die R0-R1-Verbindung ausfällt. Die grauen Felder zeigen den Label-Betrieb für Unicast-LDP-Datenverkehr unter normalem Zustand, und die gestrichelten Felder zeigen den Labelbetrieb für Unicast-LDP-Datenverkehr, wenn die R0-R1-Verbindung ausfällt.
Abbildung 8: Unicast LDP-Label-BetriebMulticast-Label-Betrieb
Der Label-Betrieb für Multicast-LDP-Datenverkehr unterscheidet sich vom Unicast-LDP-Labelbetrieb, da Multipoint-LSP-Labels nur auf dem besten Pfad vom Leaf-Knoten zum Eingangsknoten angezeigt werden. Dadurch hat Router R2 keine Kenntnisse der Multicast-LDP. Um dies zu überwinden, wird der Multicast-LDP-LSP-Datenverkehr einfach innerhalb des Unicast-LDP-LSP-Pfads durch Router R2 getunnelt, der am Router R1 endet.
Um dies zu erreichen, austauscht Router R0 zunächst die eingehende Multicast-LDP-LSP-Label-299856, um von Router R1 angekündigte 299888 zu kennzeichnen. Der Label-299776 wird dann darüber geschoben, d. h. das LDP-Label, das von Router R2 für FEC R1 angekündigt wird. Wenn das Paket am Router R2 ankommt, wird das obere Label aufgrund des vorletzten Hop-Poppings ausgeschrieben. Das bedeutet, dass das Paket mit dem Multicast-LDP-Label 299888, das Router R1 ursprünglich für Router R0 angekündigt hatte, am Router R1 eintrifft.
Abbildung 9 zeigt den Label-Betrieb für Multicast-LDP-Datenverkehr, wenn die R0-R1-Verbindung ausfällt. Die blauen Felder zeigen den Label-Betrieb für Multicast-LDP-Datenverkehr unter normalem Zustand, und die gestrichelten Felder zeigen den Labelbetrieb für Multicast-LDP-Datenverkehr, wenn die R0-R1-Verbindung ausfällt.
Abbildung 9: Multicast-LDP-Label-Betrieb
Wenn die Metrik auf dem R2-R1-Link auf 1000 anstelle von 1 festgelegt ist, ist Router R2 kein gültiges LFA für Router R0. Wenn der Router R2 in diesem Fall ein Paket empfängt, das für die Router R1, R3 oder R4 bestimmt ist, bevor sein IGP konvergiert ist, wird das Paket zurück an den Router R0 gesendet, was zu einer Looping-Paketübertragung führt.
Da der Router R0 über keine praktikable LFA verfügt, werden in der Packet Forwarding Engine keine Backup-Pfade installiert. Wenn die Verbindung R0-R1 ausfällt, wird der Datenverkehrsfluss unterbrochen, bis IGP und LDP konvergieren und neue Einträge auf den betroffenen Routern installiert sind.
Der show route detail
Befehl zeigt den Status an, wenn kein LFA für den Verbindungsschutz verfügbar ist.
user@host> show route detail 299840 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Router, Next hop index: 578 Address: 0x9340d20 Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0, selected Label operation: Swap 299824 Session Id: 0x1 State: <Active Int> Age: 5:38 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I Prefixes bound to route: 192.168.0.4/32 299856 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x9340e04 Next-hop reference count: 3 Next hop type: Router, Next hop index: 579 Address: 0x93407c8 Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0 Label operation: Swap 299888 State: <Active Int AckRequest> Age: 5:38 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 192.168.0.5, lsp-id 99
Fall B: LFA und Dynamic RSVP LSP
Wenn es einen brauchbaren LFA-Nachbarn gibt, entspricht das Verhalten des Label-Betriebs in diesem Betriebsmodus dem des einzigen Case A-, LFA-Modus. Wenn jedoch kein brauchbarer LFA-Nachbar vorhanden ist, wird automatisch ein RSVP-Bypass-Tunnel erstellt.
Wenn die Metrik auf der Verbindung R2-R1 auf 1000 anstelle von 1 festgelegt ist, ist Router R2 kein LFA für Router R0. Da keine LFA-Pfade zum Schutz des Verbindungsfehlers von R0-R1 vorhanden sind, wird automatisch ein RSVP-Bypass-Tunnel mit dem Router R1 als Ausgangsknoten erstellt und folgt einem Pfad, der die Verbindung R0-R1 vermeidet (z. B. R0-R2-R1).
Wenn die Verbindung R0-R1 ausfällt, wird der Unicast-LDP- und Multicast-LDP-Datenverkehr durch den RSVP-Bypass-Tunnel getunnelt. Der RSVP-Bypass-Tunnel wird nicht für die normale Weiterleitung verwendet und dient im Falle eines Verbindungsausfalls von R0-R1 nur zur Bereitstellung von Verbindungsschutz für LDP-Datenverkehr.
Mithilfe des show route detail
Befehls kann der Unicast- und Multicast-LDP-Datenverkehr abgeleitet werden.
user@host> show route detail 299840 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Router Address: 0x940c3dc Next-hop reference count: 1 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1, selected Label operation: Swap 299824 Session Id: 0x1 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0x8001 Label-switched-path ge-0/0/1.0:BypassLSP->192.168.0.1 Label operation: Swap 299824, Push 299872(top) Label TTL action: prop-ttl, prop-ttl(top) Session Id: 0x3 State: <Active Int NhAckRequest> Age: 19 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I Prefixes bound to route: 192.168.0.4/32 299856 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x9340e04 Next-hop reference count: 3 Next hop type: Router, Next hop index: 262143 Address: 0x940c154 Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1 Label operation: Swap 299888 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0x8001 Label-switched-path ge-0/0/1.0:BypassLSP->192.168.0.1 Label operation: Swap 299888, Push 299872(top) Label TTL action: prop-ttl, prop-ttl(top) State: < Active Int AckRequest> Age: 20 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 192.168.0.5, lsp-id 99
Der Hauptpfad für Unicast- und Multicast-LDP-LSP ist über die Schnittstelle ge-0/0/1 (die Verbindung zu Router R1), und der LFA-Pfad erfolgt über die Schnittstelle ge-0/0/2 (die Verbindung zu Router R2). Der LFA-Pfad wird nur verwendet, wenn die Ge-0/0/1-Schnittstelle ausfällt.
Label 299840 ist der Datenverkehr, der am Router R0 ankommt und dem Unicast-LDP-Datenverkehr zu Router R4 entspricht. Label-299856 ist der Datenverkehr, der am Router 0 ankommt und dem Multicast-LDP-Datenverkehr vom Stammknoten R5 zu den Leaf-Ausgangsknoten R3 und R4 entspricht.
Wie in der Befehlsausgabe show route detail
zu sehen, sind die Labelvorgänge für den Schutzpfad für Unicast-LDP- und Multicast-LDP-Datenverkehr gleich. Das eingehende LDP-Label am Router R0 wird gegen das von Router R1 zu Router R0 angebotene LDP-Label ausgetauscht. Das RSVP-Label 299872 für den Bypass-Tunnel wird dann auf das Paket geschoben. Penultimate Hop-Popping wird im Bypass-Tunnel verwendet, wodurch Router R2 dieses Label popt. Somit gelangt das Paket mit dem LDP-Label, das es ursprünglich für Router R0 angekündigt hatte, an Router R1.
Abbildung 10 veranschaulicht den Label-Betrieb für Unicast-LDP- und Multicast-LDP-Datenverkehr, der durch den RSVP-Bypass-Tunnel geschützt ist. Die grauen und blauen Felder repräsentieren die Labelwerte, die unter normalen Bedingungen für Unicast- bzw. Multicast-LDP-Datenverkehr verwendet werden. Die gestrichelten Felder stellen Labelwerte dar, die beim Ausfall der R0-R1-Verbindung verwendet werden.

Fall C: Nur dynamischer RSVP-LSP
In dieser Betriebsweise wird LFA überhaupt nicht verwendet. Ein dynamischer RSVP-Bypass-LSP wird automatisch erstellt, um einen Verbindungsschutz zu gewährleisten. Die Ausgabe des Befehls show route detail
und der Labeloperationen ähneln dem Case B-, LFA- und dynamischen RSVP LSP-Modus.
Beispielkonfiguration für Multicast-LDP-Verbindungsschutz
Um den Multicast-LDP-Linkschutz zu aktivieren, ist auf Router R0 die folgende Konfiguration erforderlich:
In diesem Beispiel ist der Multicast-LDP-Linkschutz an der Ge-1/0/0-Schnittstelle des Routers R0 aktiviert, der mit Router R1 verbunden ist, obwohl normalerweise alle Schnittstellen für den Verbindungsschutz konfiguriert werden müssen.
Router R0
protocols { rsvp { interface all; interface ge-0/0/0.0 { disable; } } mpls { interface all; interface ge-0/0/0.0 { disable; } } ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0; interface ge-0/0/1.0 { link-protection; } interface ge-0/0/2.0; interface ge-0/0/3.0; } } ldp { make-before-break { timeout seconds; switchover-delay seconds; } interface ge-1/1/0.0 { link-protection { disable; dynamic-rsvp-lsp; } } } }
Die folgenden Konfigurationsanweisungen gelten wie folgt für die verschiedenen Modi des Multicast-LDP-Schutzes:
link-protection
Statement unter[edit protocols ospf interface ge-0/0/1.0]
Diese Konfiguration wird nur für die Modi Case A (nur LFA) und Case B (LFA und dynamische RSVP LSP) des Multicast-LDP-Verbindungsschutzes angewendet. Die Konfiguration des Verbindungsschutzes unter einem IGP ist für Fall C (nur dynamisches RSVP LSP) nicht erforderlich.
link-protection
Statement unter[edit protocols ldp interface ge-0/0/1.0]
Diese Konfiguration ist für alle Modi des Multicast-LDP-Schutzes erforderlich. Wenn jedoch der einzige vorhandene LDP-Datenverkehr Unicast ist und dynamische RSVP-Bypasses nicht erforderlich sind, ist diese Konfiguration nicht erforderlich, da die
link-protection
Anweisung auf[edit protocols ospf interface ge-0/0/1.0]
Hierarchieebene zu einer LFA-Aktion für den LDP-Unicast-Datenverkehr führt.dynamic-rsvp-lsp
Statement unter[edit protocols ldp interface ge-0/0/1.0 link-protection]
Diese Konfiguration wird nur für die Modi Case B (LFA und dynamic RSVP LSP) und Case C (dynamic RSVP LSP only) des LDP-Verbindungsschutzes angewendet. Die dynamische RSVP-LSP-Konfiguration gilt nicht für Fall A (nur LFA).
Make-before-Break
Die Make-before-Break-Funktion ist standardmäßig auf Junos OS aktiviert und bietet einige Vorteile für Point-to-Multipoint-LSPs.
Für einen Point-to-Multipoint-LSP wählt ein Label-Switched-Router (LSR) die LSR aus, die als upstreame LSR den nächsten Hop zum Stamm des LSP bildet. Wenn der beste Pfad zum Erreichen der Root-Änderungen ist, wählt die LSR eine neue Upstream-LSR. In diesem Zeitraum kann der LSP vorübergehend unterbrochen werden, was zu Paketverlusten führt, bis der LSP zu einer neuen upstreamen LSR rekonvergent wird. Das Ziel von Make-before-Break in diesem Fall ist es, den Paketverlust zu minimieren. In Fällen, in denen sich der beste Pfad vom LSR zum Stamm ändert, der LSP aber weiterhin Datenverkehr an den vorherigen nächsten Hop zum Stamm weiterleitt, sollte ein neuer LSP eingerichtet werden, bevor der alte LSP zurückgezogen wird, um die Dauer des Paketverlustes zu minimieren.
Beispielsweise empfängt ein downstreames LSR (z. B. LSR-D) nach einem Verbindungsfehler immer noch Pakete und/oder leitet sie an die anderen Downstream-LSRs weiter, da sie weiterhin Pakete aus dem 1-Hop-RSVP-LSP empfängt. Sobald das Routing konvergiert ist, wählt LSR-D eine neue Upstream-LSR (LSR-U) für dieses Point-to-Multipoint-LSP-FEC (FEC-A). Die neue LSR kann bereits Pakete für FEC-A an andere downstream-LSRs als LSR-D weiterleiten. Nachdem LSR-U ein Label für FEC-A von LSR-D erhält, benachrichtigt es LSR-D, wenn es gelernt hat, dass LSP für FEC-A von der Wurzel zu sich selbst eingerichtet wurde. Wenn LSR-D eine solche Benachrichtigung erhält, ändert es seinen nächsten Hop für den LSP-Stamm in LSR-U. Dies ist ein Routenlösch- und Erweiterungsvorgang auf LSR-D. An dieser Stelle führt LSR-D einen LSP-Switchover durch, und der Datenverkehr, der durch RSVP LSP oder LFA tunnelt, wird abgebrochen, und der Datenverkehr von LSR-U wird akzeptiert. Die neue Transitroute für LSR-U wird hinzugefügt. Die RPF-Prüfung wird geändert, um Datenverkehr von LSR-you zu akzeptieren und den Datenverkehr von der alten upstreamen LSR abzunehmen, oder die alte Route wird gelöscht und die neue Route wird hinzugefügt.
Es wird davon ausgegangen, dass LSR-U von seinem Upstream-Router für den FEC-A-Point-to-Multipoint-LSP eine Benachrichtigung vor der Unterbrechung erhalten hat und einen Weiterleitungsstatus für den LSP installiert hat. An diesem Punkt sollte es LSR-D mittels Einer Benachrichtigung vor der Pause signalisieren, dass es Teil des von FEC-A identifizierten Baums geworden ist und dass LSR-D seine Umstellung auf den LSP einleiten sollte. Andernfalls sollte LSR-U bedenken, dass es eine Benachrichtigung an LSR-D senden muss, wenn es eine Make-before-Break-Benachrichtigung von der Upstream-LSR für FEC-A erhält und einen Weiterleitungsstatus für diesen LSP installiert. LSR-D empfängt weiterhin Datenverkehr vom alten nächsten Hop zum Stammknoten über einen Hop RSVP LSP- oder LFA-Pfad, bis er zum neuen Point-to-Multipoint-LSP zu LSR-U wechselt.
Die Make-before-Break-Funktionalität mit Multicast-LDP-Verbindungsschutz umfasst die folgenden Funktionen:
Make-before-Break-Funktion
Ein LSR kündigt an, dass es in der Lage ist, make-before-break-LSPs mithilfe der Funktionsanzeige zu verarbeiten. Wenn der Peer nicht make-before-break-fähig ist, werden die Make-before-Break-Parameter nicht an diesen Peer gesendet. Wenn eine LSR einen Make-before-Break-Parameter von einer Downstream-LSR (LSR-D) empfängt, die upstreame LSR (LSR-U) jedoch nicht make-before-break-fähig ist, sendet die LSR sofort eine Make-before-Break-Benachrichtigung an LSR-D, und der make-before-break-fähige LSP wird nicht festgelegt. Stattdessen wird der normale LSP festgelegt.
Make-before-Break-Statuscode
Der Make-before-Break-Statuscode umfasst:
1 – Anforderung vor der Pause
2 – Make-before-Break-Anerkennung
Wenn ein downstreames LSR eine Label-Mapping-Nachricht für Point-to-Multipoint-LSP sendet, enthält es den Make-before-Break-Statuscode als 1 (Anfrage). Wenn die Upstream-LSR den Weiterleitungsstatus für den Point-to-Multipoint-LSP aktualisiert, informiert sie die downstream-LSR mit einer Benachrichtigung, die den Make-before-Break-Statuscode als 2 (Bestätigung) enthält. An diesem Punkt führt die Downstream-LSR einen LSP-Switchover durch.
Einschränkungen und Einschränkungen
Die Junos OS-Implementierung der LDP-Verbindungsschutzfunktion weist folgende Einschränkungen auf:
Make-before-Break wird für die folgenden Point-to-Multipoint-LSPs auf einem ausgehenden LSR nicht unterstützt:
Multicast Virtual Private Network (MVPN) der nächsten Generation mit virtuellem Routing und Weiterleitung (VRF)-Label
Statischer LSP
Die folgenden Funktionen werden nicht unterstützt:
Nonstop Active Routing für Point-to-Multipoint LSP in Junos OS Releases 12.3, 13.1 und 13.2
Graceful Restart-Switchover Point-to-Multipoint-LSP
Linkschutz für Routing-Instanz
Beispiel: Konfigurieren von LDP-Verbindungsschutz
Dieses Beispiel zeigt, wie Sie den Label Distribution Protocol (LDP)-Verbindungsschutz für Unicast- und Multicast-LDP Label Switched Paths (LSPs) konfigurieren.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Sechs Router, die eine Kombination aus Routern der M-Serie, MX-Serie oder T-Serie mit einem Stammknoten und zwei Leaf-Knoten sein können, auf denen ein Point-to-Multipoint-LDP-LSP ausgeführt wird.
Junos OS Version 12.3 oder höher, die auf allen Routern ausgeführt wird.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie die folgenden Protokolle:
RSVP
MPLS
OSPF oder ein anderes IGP
LDP
Überblick
Der LDP-Verbindungsschutz ermöglicht im Falle eines Verbindungsausfalls eine schnelle Umleitung des Datenverkehrs, der über LDP-LSPs übertragen wird. LDP-Point-to-Multipoint-LSPs können verwendet werden, um Datenverkehr von einem einzelnen Stamm- oder Eingangsknoten an eine Reihe von Leaf-Knoten oder Ausgangsknoten zu senden, die einen oder mehrere Transitknoten passieren. Wenn eine der Verbindungen des Point-to-Multipoint-Tree ausfällt, können die Subtres losgelöst werden, bis das IGP rekonvergiert und Multicast-LDP die Labelzuordnung über den besten Pfad vom Downstream-Router zum neuen Upstream-Router einleitet. Um den Datenverkehr im Falle eines Verbindungsausfalls zu schützen, können Sie einen expliziten Tunnel so konfigurieren, dass der Datenverkehr über den Tunnel umgeleitet werden kann. Junos OS unterstützt Make-before-Break-Funktionen, um einen minimalen Paketverlust zu gewährleisten, wenn versucht wird, einen neuen LSP-Pfad zu signalisieren, bevor der alte LSP-Pfad abgerissen wird. Diese Funktion bietet außerdem gezielte LDP-Unterstützung für Multicast-LDP-Verbindungsschutz.
Beachten Sie bei der Konfiguration von LDP-Verbindungsschutz die folgenden Überlegungen:
Konfigurieren Sie Traffic-Engineering unter IGP (wenn es standardmäßig nicht unterstützt wird) und fügen Sie die für MPLS und RSVP konfigurierten Schnittstellen ein, sodass der zugriffsgeschützte dynamische RSVP-LSP mit Constrained Shortest Path First (CSPF) von RSVP signalisiert wird. Wenn diese Bedingung nicht erfüllt ist, kann RSVP LSP nicht hochkommen und LDP kann sie nicht als geschützten nächsten Hop verwenden.
Konfigurieren Sie einen Pfad zwischen zwei Label-Switched-Routern (LSRs), um bei einem Verbindungsfehler die IP-Konnektivität zwischen den Routern bereitzustellen. Dadurch kann CSPF einen alternativen Pfad für den Verbindungsschutz berechnen. Wenn die Verbindung zwischen den Routern verloren geht, wird die angestrebte LDP-Nachbarschaft nicht angezeigt, und dynamisches RSVP-LSP kann nicht signalisiert werden, was zu keinem Schutz für die LDP-Weiterleitungsgleichungsklasse (FEC) führt, für die der Peer die Downstream-LSR ist.
Wenn der Verbindungsschutz nur auf einer LSR aktiv ist, sollte die andere LSR nicht mit der
strict-targeted-hellos
Anweisung konfiguriert werden. Dies ermöglicht dem LSR ohne Linkschutz die asymmetrische Remote neighbor Discovery und sendet regelmäßig gezielte Hellos an die LSR, die den Entfernten Nachbarn initiiert hat. Wenn diese Bedingung nicht erfüllt ist, wird keine gezielte LDP-Nachbarschaft gebildet.LDP muss an der Loopback-Schnittstelle des LSR aktiviert werden, um Remote-Nachbarn zu erstellen, die auf LDP-Tunneling, LDP-basiertem Virtual Private LAN Service (VPLS), Layer-2-Circuits oder LDP-Sitzungsschutz basieren. Wenn diese Bedingung nicht erfüllt ist, wird keine gezielte LDP-Nachbarschaft gebildet.
Für Unicast-LDP-LSP sollte loop-free alternate (LFA) in IGP konfiguriert werden.
Die Eingangsroute zum Merge-Punkt sollte mindestens einen nächsten Hop haben, wodurch die primäre Verbindung zwischen dem Merge-Punkt und dem Ort der lokalen Reparatur für Unicast-LDP-LSP vermieden wird.
Der Ort der lokalen Reparatur sollte über ein Unicast-LDP-Label für den Backup-Next Hop verfügen, um den Zusammenführungspunkt zu erreichen.
Topologie

In diesem Beispiel ist der Router R5 der Stamm, der mit zwei Leaf-Knoten, den Routern R3 und R4, verbunden ist. Router R0 ist der Ort der lokalen Reparatur.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit]
CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit
.
R5
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.5/32 set routing-options router-id 10.255.1.5 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 20.10.10.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 30.10.10.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.0/32 set routing-options router-id 10.255.1.0 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R1
set interfaces ge-0/0/0 unit 0 family inet address 60.10.10.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 40.10.10.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 30.10.10.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 50.10.10.1/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.1/32 set routing-options router-id 10.255.1.1 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R2
set interfaces ge-0/0/0 unit 0 family inet address 60.10.10.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 20.10.10.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.2/32 set routing-options router-id 10.255.1.2 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R3
set interfaces ge-0/0/1 unit 0 family inet address 40.10.10.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.3/32 set routing-options router-id 10.255.1.3 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp root-address 10.255.1.5 lsp-id 1
R4
set interfaces ge-0/0/3 unit 0 family inet address 50.10.10.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.4/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp root-address 10.255.1.5 lsp-id 1
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.
So konfigurieren Sie Router R0:
Konfigurieren Sie die Router-R0-Schnittstellen.
[edit interfaces]
user@R0# set ge-0/0/0 unit 0 family inet address 10.10.10.2/30 user@R0# set ge-0/0/0 unit 0 family mpls user@R0# set ge-0/0/1 unit 0 family inet address 20.10.10.1/30 user@R0# set ge-0/0/1 unit 0 family mpls user@R0# set ge-0/0/2 unit 0 family inet address 30.10.10.1/30 user@R0# set ge-0/0/2 unit 0 family mpls user@R0# set lo0 unit 0 family inet address 10.255.1.0/32Konfigurieren Sie die Router-ID und das autonome System von Router R0.
[edit routing-options]
user@R0# set router-id 10.255.1.0 user@R0# set autonomous-system 100Aktivieren Sie RSVP auf allen Schnittstellen von Router R0 (außer der Verwaltungsschnittstelle).
[edit protocols]
user@R0# set rsvp interface all user@R0# set rsvp interface fxp0.0 disableAktivieren Sie MPLS auf allen Schnittstellen von Router R0 (außer der Verwaltungsschnittstelle) sowie Traffic-Engineering-Funktionen.
[edit protocols]
user@R0# set mpls traffic-engineering user@R0# set mpls interface all user@R0# set mpls interface fxp0.0 disableAktivieren Sie OSPF auf allen Schnittstellen des Router R0 (außer der Verwaltungsschnittstelle), weisen Sie den Verbindungen eine kostengleiche Metrik zu und aktivieren Sie Traffic-Engineering-Funktionen.
[edit protocols]
user@R0# set ospf traffic-engineering user@R0# set ospf area 0.0.0.0 interface all metric 1 user@R0# set ospf area 0.0.0.0 interface fxp0.0 disableAnmerkung:Aktivieren Sie für den Multicast-LDP-Linkschutz mit loop-free alternative (LFA) die folgende Konfiguration unter der
[edit protocols]
Hierarchieebene:set ospf area 0 interface all link-protection
Aktivieren Sie LDP auf allen Schnittstellen von Router R0 (außer der Verwaltungsschnittstelle) und konfigurieren Sie den Verbindungsschutz mit dynamischem RSVP-Bypass-LSP.
[edit protocols]
user@R0# set ldp interface all link-protection dynamic-rsvp-lsp user@R0# set ldp interface fxp0.0 disable user@R0# set ldp p2mp
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus durch Eingabe von show interfaces
, show routing-options
und show protocols
Befehlen. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R0# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.10.10.2/30; } family mpls; } } ge-0/0/1 { unit 0 { family inet { address 20.10.10.1/30; } family mpls; } } ge-0/0/2 { unit 0 { family inet { address 30.10.10.1/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.255.1.0/32; } } }
user@R0# show routing-options router-id 10.255.1.0; autonomous-system 100;
user@R0# show protocols rsvp { interface all; interface fxp0.0 { disable; } } mpls { traffic-engineering; interface all; interface fxp0.0 { disable; } } ospf { traffic-engineering; area 0.0.0.0 { interface all { metric 1; } interface fxp0.0 { disable; } } } ldp { interface all { link-protection { dynamic-rsvp-lsp; } } interface fxp0.0 { disable; } p2mp; }
Überprüfung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen des Bypass RSVP LSP-Pfads
Zweck
Vergewissern Sie sich, dass der Bypass-RSVP-LSP-Pfad am Point of Local Repair (PLR) erstellt wurde.
Aktion
Führen Sie im Betriebsmodus den show route tale mpls.0
Befehl aus.
user@R0> show route tale mpls.0 mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 05:28:13, metric 1 Receive 1 *[MPLS/0] 05:28:13, metric 1 Receive 2 *[MPLS/0] 05:28:13, metric 1 Receive 13 *[MPLS/0] 05:28:13, metric 1 Receive 299792 *[LDP/9] 00:41:41, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Pop 299792(S=0) *[LDP/9] 00:41:41, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Pop 299808 *[LDP/9] 00:41:41, metric 1 > to 20.10.10.2 via ge-0/0/1.0, Pop 299808(S=0) *[LDP/9] 00:41:41, metric 1 > to 20.10.10.2 via ge-0/0/1.0, Pop 299920 *[RSVP/7/1] 01:51:43, metric 1 > to 30.10.10.2 via ge-0/0/2.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.1 299920(S=0) *[RSVP/7/1] 01:51:43, metric 1 > to 30.10.10.2 via ge-0/0/2.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.1 299936 *[RSVP/7/1] 01:51:25, metric 1 > to 20.10.10.2 via ge-0/0/1.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.2 299936(S=0) *[RSVP/7/1] 01:51:25, metric 1 > to 20.10.10.2 via ge-0/0/1.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.2 299952 *[LDP/9] 00:06:11, metric 1 > to 10.10.10.1 via ge-0/0/0.0, Pop 299952(S=0) *[LDP/9] 00:06:11, metric 1 > to 10.10.10.1 via ge-0/0/0.0, Pop 299968 *[LDP/9] 00:05:39, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Swap 299984 299984 *[LDP/9] 00:05:38, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Swap 300000 300000 *[LDP/9] 00:05:15, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Swap 300016
Bedeutung
Wenn die Verbindung R0-R1 ausfällt, wird der RSVP-Bypass-LSP zum Routen des Datenverkehrs verwendet.
Überprüfung des Label-Betriebs
Zweck
Überprüfen Sie den Label-Swapping an der PLR.
Aktion
Führen Sie im Betriebsmodus den show route table mpls.0 label label extensive
Befehl aus.
user@R0> show route table mpls.0 label 300000 extensive mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) 300000 (1 entry, 1 announced) TSI: KRT in-kernel 300000 /52 -> {Swap 300016} *LDP Preference: 9 Next hop type: Router, Next hop index: 589 Address: 0x9981610 Next-hop reference count: 2 Next hop: 30.10.10.2 via ge-0/0/2.0, selected Label operation: Swap 300016 Load balance label: Label 300016: None; Session Id: 0x2 State: <Active Int> Local AS: 100 Age: 12:50 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 1-KRT AS path: I Prefixes bound to route: 10.255.1.4/32
Bedeutung
Das Label ist an den Router R4 gebunden, bei dem es sich um einen Leaf-Knoten handelt.
Verstehen von Multicast-Only Fast Reroute
Multicast-only Fast Reroute (MoFRR) minimiert Paketverluste für Datenverkehr in einer Multicast-Verteilungsstruktur, wenn Verbindungsausfälle auftreten, und verbessert Multicast-Routing-Protokolle wie Protocol Independent Multicast (PIM) und Multipoint Label Distribution Protocol (Multipoint LDP) auf Geräten, die diese Funktionen unterstützen.
Auf Switches wird MoFRR mit MPLS Label Switched Paths und Multipoint LDP nicht unterstützt.
Für Router der MX-Serie wird MoFRR nur auf Routern der MX-Serie mit MPC-Linekarten unterstützt. Als Voraussetzung müssen Sie den Router in network-services enhanced-ip
den Modus konfigurieren, und alle Linekarten im Router müssen MPCs sein.
Mit aktiviertem MoFRR senden Geräte Join-Nachrichten auf primären und Backup-Upstream-Pfaden an eine Multicast-Quelle. Geräte erhalten Datenpakete sowohl vom primären als auch vom Backup-Pfad und verwerfen die redundanten Pakete basierend auf der Priorität (Gewichtungen, die den primären und Backup-Pfaden zugewiesen sind). Wenn ein Gerät einen Fehler auf dem primären Pfad erkennt, beginnt es sofort damit, Pakete von der sekundären Schnittstelle (dem Backup-Pfad) zu akzeptieren. Der schnelle Switchover verbessert die Konvergenzzeiten bei Verbindungsausfällen des primären Pfads erheblich.
Eine Anwendung für MoFRR ist das Streaming von IPTV. IPTV-Streams werden als UDP-Streams multicastiert, sodass verlorene Pakete nicht erneut übertragen werden, was zu einer weniger als zufriedenstellenden Benutzererfahrung führt. MoFRR kann die Situation verbessern.
- MoFRR – Übersicht
- PIM-Funktionalität
- Multipoint-LDP-Funktionen
- Paketweiterleitung
- Einschränkungen und Einschränkungen
MoFRR – Übersicht
Mit Fast Reroute auf Unicaststreams stellt ein Upstream-Routing-Gerät MPLS Label Switched Paths (LSPs) vor oder berechnet einen IP Loop-Free Alternate (LFA) Fast Reroute Backup-Pfad, um das Versagen eines Segments im Downstream-Pfad zu bewältigen.
Beim Multicast-Routing stammt die Empfangende Seite in der Regel von den Datenverkehrsverteilungsdiagrammen. Dies ist im Gegensatz zu Unicast-Routing, bei dem im Allgemeinen der Pfad von der Quelle zum Empfänger festgelegt wird. PIM (für IP), Multipoint LDP (für MPLS) und RSVP-TE (für MPLS) sind Protokolle, die Multicast-Verteilungsdiagramme erstellen können. Von diesen initiieren PIM- und Multipoint-LDP-Empfänger die Einrichtung des Verteilungsdiagramms, sodass MoFRR mit diesen beiden Multicastprotokollen arbeiten kann, wo sie unterstützt werden.
Wenn das Gerät in einem Multicast-Tree einen Fehler bei der Netzwerkkomponente erkennt, dauert es einige Zeit, um eine reaktive Reparatur durchzuführen, was bei der Einrichtung eines alternativen Pfads zu erheblichen Datenverkehrsverlusten führt. MoFRR reduziert Datenverkehrsverluste in einem Multicast-Verteilungsbaum, wenn eine Netzwerkkomponente ausfällt. Mit MoFRR richtet eines der downstream-Routing-Geräte einen alternativen Pfad zur Quelle ein, um einen Backup-Live-Stream desselben Multicast-Datenverkehrs zu erhalten. Wenn ein Fehler entlang des primären Streams auftritt, kann das MoFRR-Routinggerät schnell zum Backup-Stream wechseln.
Wenn MoFRR für jeden (S,G)-Eintrag aktiviert ist, verwendet das Gerät zwei der verfügbaren Upstream-Schnittstellen, um eine Join-Nachricht zu senden und Multicast-Datenverkehr zu empfangen. Das Protokoll versucht, zwei unzusammenhängende Pfade auszuwählen, wenn zwei solche Pfade verfügbar sind. Wenn keine unzusammenhängenden Pfade verfügbar sind, wählt das Protokoll zwei nicht unzusammenhängende Pfade aus. Wenn zwei nicht unzusammenhängende Pfade nicht verfügbar sind, wird nur ein primärer Pfad ohne Sicherung ausgewählt. MoFRR priorisiert die unzusammenhängende Sicherung zugunsten des Load Balancing der verfügbaren Pfade.
MoFRR wird sowohl für IPv4- als auch für IPv6-Protokollfamilien unterstützt.
Abbildung 12 zeigt zwei Pfade vom Multicast-Empfänger-Routinggerät (das auch als Egress Provider Edge (PE)-Gerät bezeichnet wird) zum Multicast-Source-Routing-Gerät (auch als Ingress-PE-Gerät bezeichnet).

Mit aktiviertem MoFRR richtet das Ausgangs-Routinggerät (empfängerseitig) zwei Multicastbäume, einen primären Pfad und einen Backup-Pfad in Richtung der Multicast-Quelle für jede (S,G) ein. Mit anderen Worten, das Ausgangsroutinggerät übermittelt dieselben (S,G) Join-Nachrichten zu zwei verschiedenen upstreamen Nachbarn und erzeugt so zwei Multicast-Bäume.
Einer der Multicastbäume durchläuft die Ebene 1 und die andere durch Ebene 2, wie in Abbildung 12dargestellt. Für jeden (S,G) leitet das Ausgangsroutinggerät den auf dem primären Pfad empfangenen Datenverkehr weiter und verfällt der auf dem Backup-Pfad empfangene Datenverkehr.
MoFRR wird sowohl auf Equal-Cost-Multipath-Pfaden (ECMP)- als auch auf Nicht-ECMP-Pfaden unterstützt. Das Gerät muss Unicast Loop-Free Alternate (LFA)-Routen aktivieren, um MoFRR auf Nicht-ECMP-Pfaden zu unterstützen. Sie aktivieren LFA-Routen mithilfe der link-protection
Anweisung in der Interior Gateway Protocol (IGP)-Konfiguration. Wenn Sie den Verbindungsschutz auf einer OSPF- oder IS-IS-Schnittstelle aktivieren, erstellt das Gerät einen Backup-LFA-Pfad zum primären nächsten Hop für alle Zielrouten, die die geschützte Schnittstelle passieren.
Junos OS implementiert MoFRR im IP-Netzwerk für IP MoFRR und auf dem MPLS Label-Edge Routing-Gerät (LER) für Multipoint LDP MoFRR.
Multipoint LDP MoFRR wird am Ausgangsgerät eines MPLS-Netzwerks verwendet, wo die Pakete an ein IP-Netzwerk weitergeleitet werden. Mit Multipoint-LDP-MoFRR erstellt das Gerät zwei Pfade zum upstreamen PE-Routing-Gerät für den Empfang von zwei MPLS-Paketströmen am LER. Das Gerät akzeptiert einen der Streams (primär) und der andere (das Backup) wird am LER abgebrochen. Wenn der primäre Pfad ausfällt, akzeptiert das Gerät stattdessen den Backup-Stream. Unterstützung von Inband-Signalübertragung ist Eine Voraussetzung für MoFRR mit Multipoint-LDP (siehe Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs).
PIM-Funktionalität
Junos OS unterstützt MoFRR für SPT-Joins (Shortest Path Tree) in PIM Source-Specific Multicast (SSM) und Any-Source Multicast (ASM). MoFRR wird sowohl für SSM- als auch für ASM-Bereiche unterstützt. Um MoFRR für (*,G)-Joins zu aktivieren, fügen Sie die mofrr-asm-starg
Konfigurationsanweisung in der [edit routing-options multicast stream-protection]
Hierarchie hinzu. Für jede Gruppe G wird MoFRR entweder für (S,G) oder (*,G) betrieben, aber nicht für beide. (S,G) hat immer Vorrang vor (*,G).
Mit aktiviertem MoFRR verbreitet ein PIM-Routinggerät Join-Nachrichten an zwei Upstream-Reverse-Path Forwarding (RPF)-Schnittstellen, um Multicast-Datenverkehr auf beiden Links für dieselbe Join-Anforderung zu empfangen. MoFRR gibt zwei Pfaden den Vorzug, die nicht zum selben unmittelbaren Upstream-Routing-Gerät konvergieren. PIM installiert geeignete Multicast-Routen mit upstreamen RPF-Next Hops mit zwei Schnittstellen (für die primären und Backup-Pfade).
Wenn der primäre Pfad ausfällt, wird der Backup-Pfad auf den primären Status aktualisiert, und das Gerät leitet den Datenverkehr entsprechend weiter. Wenn alternative Pfade verfügbar sind, berechnet MoFRR einen neuen Backup-Pfad und aktualisiert oder installiert die entsprechende Multicastroute.
Sie können MoFRR mit PIM Join Load Balancing aktivieren (siehe join-load-balance automatic
Anweisung). In diesem Fall ist die Verteilung der Join-Nachrichten unter den Links möglicherweise nicht gleichmäßig. Wenn eine neue ECMP-Verbindung hinzugefügt wird, werden Join-Nachrichten auf dem primären Pfad neu verteilt und lastausgleichen. Die Join-Nachrichten auf dem Backup-Pfad folgen möglicherweise immer noch demselben Pfad und werden möglicherweise nicht gleichmäßig neu verteilt.
Sie aktivieren MoFRR mit der stream-protection
Konfigurationsanweisung in der [edit routing-options multicast]
Hierarchie. MoFRR wird durch eine Reihe von Filterrichtlinien verwaltet.
Wenn ein Ausgangs-PIM-Routinggerät eine Join-Nachricht oder einen IGMP-Bericht empfängt, prüft es auf eine MoFRR-Konfiguration und wird wie folgt ausgeführt:
Wenn die MoFRR-Konfiguration nicht vorhanden ist, sendet PIM eine Join-Nachricht upstream zu einem Upstream-Nachbarn (z. B. Plane 2 in Abbildung 12).
Wenn die MoFRR-Konfiguration vorhanden ist, prüft das Gerät auf eine Richtlinienkonfiguration.
Wenn keine Richtlinie vorhanden ist, prüft das Gerät nach primären und Backup-Pfaden (Upstream-Schnittstellen) und geht wie folgt vor:
Wenn primäre und Backup-Pfade nicht verfügbar sind: PIM sendet eine Join-Nachricht upstream zu einem Upstream-Nachbarn (z. B. Plane 2 in Abbildung 12).
Wenn Primär- und Backup-Pfade verfügbar sind, sendet PIM die Join-Nachricht upstream an zwei der verfügbaren Upstream-Nachbarn. Junos OS richtet primären und sekundären Multicastpfad für den Empfang von Multicast-Datenverkehr ein (z. B. Plane 1 in Abbildung 12).
Wenn eine Richtlinie vorhanden ist, überprüft das Gerät, ob die Richtlinie MoFRR dafür (S,G) zulässt, und wird wie folgt ausgeführt:
Wenn diese Richtlinienprüfung fehlschlägt: PIM sendet eine Join-Nachricht upstream an einen Upstream-Nachbarn (z. B. Plane 2 in Abbildung 12).
Wenn diese Richtlinienprüfung besteht– Das Gerät prüft auf Primäre und Backup-Pfade (Upstream-Schnittstellen).
Wenn der primäre und der Backup-Pfad nicht verfügbar sind, sendet PIM eine Join-Nachricht upstream zu einem Upstream-Nachbarn (z. B. Plane 2 in Abbildung 12).
Wenn der primäre und der Backup-Pfad verfügbar sind, sendet PIM die Join-Nachricht upstream an zwei der verfügbaren Upstream-Nachbarn. Das Gerät richtet primäre und sekundäre Multicastpfade ein, um Multicast-Datenverkehr zu empfangen (z. B. Plane 1 in Abbildung 12).
Multipoint-LDP-Funktionen
Zur Vermeidung von MPLS-Datenverkehrsduplizierung wählt Multipoint-LDP in der Regel nur einen Upstream-Pfad aus. (Siehe Abschnitt 2.4.1.1. Determining One's 'Upstream LSR' in RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.)
Für Multipoint-LDP mit MoFRR wählt das Multipoint-LDP-Gerät zwei separate Upstream-Peers aus und sendet zwei separate Labels, einen an jeden Upstream-Peer. Das Gerät verwendet denselben Algorithmus, der in RFC 6388 beschrieben wird, um den primären Upstream-Pfad auszuwählen. Das Gerät verwendet den gleichen Algorithmus zur Auswahl des Backup-Upstream-Pfads, schließt jedoch die primäre Upstream-LSR als Kandidaten aus. Die beiden verschiedenen Upstream-Peers senden zwei MPLS-Datenverkehrsströme an das Ausgangsroutinggerät. Das Gerät wählt nur einen der upstreamen Nachbarpfade als primären Pfad aus, von dem der MPLS-Datenverkehr akzeptiert werden soll. Der andere Pfad wird zum Backup-Pfad, und das Gerät löscht den Datenverkehr. Wenn der primäre Upstream-Pfad ausfällt, nimmt das Gerät den Datenverkehr vom Backup-Pfad auf. Das Multipoint-LDP-Gerät wählt die beiden Upstream-Pfade basierend auf dem Interior Gateway Protocol (IGP) Root Device Next Hop aus.
Eine Forwarding Equivalency Class (FEC) ist eine Gruppe von IP-Paketen, die auf die gleiche Weise, über den gleichen Pfad und mit der gleichen Weiterleitungsbehandlung weitergeleitet werden. Normalerweise repräsentiert das Label, das auf einem bestimmten Paket liegt, das FEC, dem dieses Paket zugewiesen ist. In MoFRR werden für jedes FEC zwei Routen in die mpls.0-Tabelle eingefügt: eine Route für das primäre Label und die andere route für das Backup-Label.
Wenn parallele Verbindungen zum selben unmittelbar vorgeschalteten Gerät vorhanden sind, betrachtet das Gerät beide parallelen Verbindungen als primär. Das upstreame Gerät sendet jederzeit Datenverkehr auf nur einer der mehreren parallelen Verbindungen.
Ein Knospenknoten ist eine LSR, die eine Ausgangs-LSR ist, aber auch über einen oder mehrere direkt verbundene Downstream-LSRs verfügt. Für einen Knospenknoten wird der Datenverkehr vom primären Upstream-Pfad an eine downstream-LSR weitergeleitet. Wenn der primäre Upstream-Pfad ausfällt, wird der MPLS-Datenverkehr vom Backup-Upstream-Pfad an die Downstream-LSR weitergeleitet. Das bedeutet, dass der downstream LSR Next Hop zu beiden MPLS-Routen zusammen mit dem ausgangsnächsten Hop hinzugefügt wird.
Wie bei PIM aktivieren Sie MoFRR mit Multipoint-LDP unter Verwendung der stream-protection
Konfigurationsanweisung in der [edit routing-options multicast]
Hierarchie und werden durch eine Reihe von Filterrichtlinien verwaltet.
Wenn Sie das Multipoint-LDP-Point-to-Multipoint-FEC für MoFRR aktiviert haben, berücksichtigt das Gerät die folgenden Überlegungen bei der Auswahl des Upstream-Pfads:
Die angestrebten LDP-Sitzungen werden übersprungen, wenn es eine nicht-getarnte LDP-Sitzung gibt. Wenn es eine einzelne zielgerichtete LDP-Sitzung gibt, wird die angestrebte LDP-Sitzung ausgewählt, aber das entsprechende Point-to-Multipoint-FEC verliert die MoFRR-Funktion, da keine Schnittstelle mit der angestrebten LDP-Sitzung verbunden ist.
Alle Schnittstellen, die zum selben Upstream-LSR gehören, gelten als primärer Pfad.
Für alle Root-Node-Routenaktualisierungen wird der Upstream-Pfad basierend auf den neuesten Hops aus dem IGP geändert. Wenn ein besserer Pfad verfügbar ist, versucht Multipoint-LDP, auf den besseren Pfad umzusteigen.
Paketweiterleitung
Für PIM- oder Multipoint-LDP führt das Gerät die Multicast-Quellstromauswahl an der Eingangsschnittstelle durch. Dadurch bleibt die Fabric-Bandbreite erhalten und die Weiterleitungsleistung wird maximiert, da:
Vermeidet das Versenden doppelter Streams über die Fabric
Verhindert mehrere Routensuche (die zu Paketverlusten führen).
Für PIM enthält jeder IP-Multicast-Stream dieselbe Zieladresse. Unabhängig von der Schnittstelle, an der die Pakete ankommen, haben die Pakete dieselbe Route. Das Gerät überprüft die Schnittstelle, auf der jedes Paket eintrifft, und leitet nur diejenigen weiter, die von der primären Schnittstelle stammen. Wenn die Schnittstelle mit einer Backup-Stream-Schnittstelle übereinstimmt, löscht das Gerät die Pakete. Wenn die Schnittstelle nicht mit der primären oder der Backup-Stream-Schnittstelle übereinstimmt, verarbeitet das Gerät die Pakete als Ausnahmen in der Steuerungsebene.
Abbildung 13 zeigt diesen Prozess mit Beispiel-Primär- und Backup-Schnittstellen für Router mit PIM. Abbildung 14 zeigt dies ähnlich für Switches mit PIM.


Bei MoFRR mit Multipoint-LDP auf Routern verwendet das Gerät mehrere MPLS-Labels, um die MoFRR-Stream-Auswahl zu steuern. Jedes Label repräsentiert eine separate Route, aber jedes verweist auf die gleiche Schnittstellenlistenprüfung. Das Gerät leitet nur das primäre Label weiter und löscht alle anderen. Mehrere Schnittstellen können Pakete mit demselben Label empfangen.
Abbildung 15 zeigt diesen Prozess für Router mit Multipoint-LDP.

Einschränkungen und Einschränkungen
- MoFRR-Einschränkungen und Einschränkungen für Switching- und Routing-Geräte
- MoFRR-Beschränkungen für Switching-Geräte mit PIM
- MoFRR-Einschränkungen und Einschränkungen bei Routing-Geräten mit Multipoint-LDP
MoFRR-Einschränkungen und Einschränkungen für Switching- und Routing-Geräte
MoFRR weist die folgenden Einschränkungen und Einschränkungen bei Routing- und Switching-Geräten auf:
Die MoFRR-Fehlererkennung wird für den sofortigen Linkschutz des Routing-Geräts unterstützt, auf dem MoFRR aktiviert ist, und nicht auf allen Verbindungen (End-to-End) im Multicast-Datenverkehrspfad.
MoFRR unterstützt die schnelle Umleitung auf zwei ausgewählten, unzusammenhängenden Pfaden zur Quelle. Zwei der ausgewählten upstreamen Nachbarn können sich nicht an derselben Schnittstelle befinden, d. h. zwei upstreame Nachbarn in einem LAN-Segment. Dasselbe gilt, wenn es sich bei der Upstream-Schnittstelle um eine Multicast-Tunnelschnittstelle handelt.
Die Erkennung der maximalen End-to-End-disjunkten Upstream-Pfade wird nicht unterstützt. Das empfängerseitige (Ausgangs-) Routing-Gerät stellt nur sicher, dass es ein unzusammenhängendes Upstream-Gerät (den unmittelbaren vorherigen Hop) gibt. PIM- und Multipoint-LDP unterstützen nicht die Äquivalente von Explicit Route Objects (EROs). Daher ist die unzusammenhängende Erkennung von Upstream-Pfaden auf die Steuerung des unmittelbar vorherigen Hop-Geräts beschränkt. Aufgrund dieser Einschränkung kann der Pfad zum upstreamen Gerät des vorherigen Hops, der als primäres Und Backup ausgewählt wurde, gemeinsam genutzt werden.
In den folgenden Szenarien kann es zu Datenverkehrsverlusten führen:
Ein besserer Upstream-Pfad wird auf einem Ausgangsgerät verfügbar.
MoFRR ist auf dem Ausgangsgerät aktiviert oder deaktiviert, während ein aktiver Datenverkehrsstrom fließt.
PIM Join Load Balancing für Join-Nachrichten für Backup-Pfade wird nicht unterstützt.
Für eine Multicastgruppe G ist MoFRR nicht für die Join-Nachrichten (S,G) und (*,G) zulässig. (S,G) Join-Nachrichten haben Vorrang vor (*,G).
MoFRR wird nicht für Multicast-Datenverkehrsströme unterstützt, die zwei verschiedene Multicastgruppen verwenden. Jede (S,G)-Kombination wird als ein einzigartiger Multicast-Datenverkehrsstrom behandelt.
Der bidirektionale PIM-Bereich wird mit MoFRR nicht unterstützt.
PIM Dense Mode wird mit MoFRR nicht unterstützt.
Multicaststatistiken für den Backup-Datenverkehrsstrom werden von PIM nicht verwaltet und sind daher in der Betriebsausgabe von
show
Befehlen nicht verfügbar.Die Überwachung der Übertragungsrate wird nicht unterstützt.
MoFRR-Beschränkungen für Switching-Geräte mit PIM
MoFRR mit PIM hat die folgenden Einschränkungen für Switching-Geräte:
MoFRR wird nicht unterstützt, wenn es sich bei der Upstream-Schnittstelle um eine integrierte Routing- und Bridging-Schnittstelle (IRB) handelt, die sich auf andere Multicast-Funktionen wie Das Internet Group Management Protocol Version 3 (IGMPv3)-Snooping auswirkt.
Paketreplikation und Multicast-Suche während der Weiterleitung des Multicast-Datenverkehrs können dazu führen, dass Pakete mehrmals durch PFEs zurückgeführt werden. Infolgedessen können angezeigte Werte für Multicastpaketzähler des
show pfe statistics traffic
Befehls höhere Zahlen anzeigen als in Ausgabefeldern wieInput packets
undOutput packets
erwartet. In MoFRR-Szenarien wird dieses Verhalten möglicherweise häufiger bemerkt, da duplizierte primäre und Backup-Streams den Datenverkehrsfluss im Allgemeinen erhöhen.
MoFRR-Einschränkungen und Einschränkungen bei Routing-Geräten mit Multipoint-LDP
MoFRR weist die folgenden Einschränkungen und Einschränkungen auf Routern auf, wenn sie mit Multipoint-LDP verwendet werden:
MoFRR gilt nicht für Multipoint-LDP-Datenverkehr, der in einem RSVP-Tunnel empfangen wird, da der RSVP-Tunnel nicht mit einer Schnittstelle verknüpft ist.
Gemischtes Upstream-MoFRR wird nicht unterstützt. Dies bezieht sich auf PIM-Multipoint-LDP-In-Band-Signalübertragung, wobei ein Upstream-Pfad durch Multipoint-LDP und der zweite Upstream-Pfad über PIM erfolgt.
Multipoint-LDP-Labels als innere Labels werden nicht unterstützt.
Wenn die Quelle über mehrere Ingress-Provider-Edge-Routinggeräte (PE) erreichbar ist, wird Multipoint-LDP-MoFRR nicht unterstützt.
Gezielte LDP-Upstream-Sitzungen werden nicht als Upstream-Gerät für MoFRR ausgewählt.
Der Multipoint-LDP-Linkschutz auf dem Backup-Pfad wird nicht unterstützt, da moFRR-interne Labels nicht unterstützt werden.
Konfigurieren von Multicast-Only Fast Reroute
Sie können Multicast-Only Fast Reroute (MoFRR) konfigurieren, um Paketverluste in einem Netzwerk zu minimieren, wenn eine Verbindung ausfällt.
Wenn fast reroute auf Unicast-Streams angewendet wird, baut ein Upstream-Router MPLS Label Switched Paths (LSPs) oder einen IP Loop-Free Alternate (LFA) Fast Reroute Backup-Pfad vor, um das Versagen eines Segments im Downstream-Pfad zu bewältigen.
Beim Multicast-Routing werden die Datenverkehrsverteilungsdiagramme in der Regel vom Empfänger stammen. Dies ist im Gegensatz zu Unicast-Routing, das normalerweise den Pfad von der Quelle zum Empfänger festlegt. Protokolle, die Multicastverteilungsdiagramme einrichten können, sind PIM (für IP), Multipoint LDP (für MPLS) und RSVP-TE (für MPLS). Von diesen initiieren PIM- und Multipoint-LDP-Empfänger die Verteilungsdiagrammeinrichtung und damit:
Auf der QFX-Serie wird MoFRR in PIM-Domänen unterstützt.
Auf der MX-Serie und der SRX-Serie wird MoFRR in PIM- und Multipoint-LDP-Domänen unterstützt.
Die Konfigurationsschritte sind für die Aktivierung von MoFRR für PIM auf allen Geräten, die diese Funktion unterstützen, gleich, sofern nicht anders angegeben. Konfigurationsschritte, die für Multipoint-LDP-MoFRR nicht geeignet sind, werden ebenfalls angegeben.
(Nur für Router der MX-Serie) MoFRR wird auf Routern der MX-Serie mit MPC-Linekarten unterstützt. Als Voraussetzung müssen alle Linekarten im Router MPCs sein.
So konfigurieren Sie MoFRR auf Routern oder Switches:
Beispiel: Konfigurieren von Multicast-Only Fast Reroute in einer Multipoint-LDP-Domäne
Dieses Beispiel zeigt, wie Sie Multicast-Only Fast Reroute (MoFRR) konfigurieren, um Paketverluste in einem Netzwerk zu minimieren, wenn eine Verbindung ausfällt.
Multipoint LDP MoFRR wird am Ausgangsknoten eines MPLS-Netzwerks verwendet, wo die Pakete an ein IP-Netzwerk weitergeleitet werden. Im Fall von Multipoint-LDP-MoFRR werden die beiden Pfade zum Upstream Provider Edge (PE)-Router für den Empfang von zwei MPLS-Paketströmen am Label-Edge-Router (LER) eingerichtet. Einer der Streams (der primäre) wird akzeptiert, der andere (die Sicherung) wird am LER abgebrochen. Der Backup-Stream wird akzeptiert, wenn der primäre Pfad ausfällt.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration über die Geräte initialisierung hinaus erforderlich.
In einer Multipoint-LDP-Domäne muss MoFRR nur auf dem Egress-PE-Router moFRR aktiviert sein. Die anderen Router müssen MoFRR nicht unterstützen.
MoFRR wird auf Plattformen der MX-Serie mit MPC-Linekarten unterstützt. Als Voraussetzung muss der Router auf network-services enhanced-ip
den Modus eingestellt werden, und alle Linekarten auf der Plattform müssen MPCs sein.
Dieses Beispiel erfordert Junos OS Version 14.1 oder höher auf dem Egress PE-Router.
Überblick
In diesem Beispiel ist Gerät R3 der Ausgangs-Edge-Router. MoFRR ist nur auf diesem Gerät aktiviert.
OSPF wird für die Konnektivität verwendet, obwohl jedes Interior Gateway Protocol (IGP) oder statische Routen verwendet werden kann.
Zu Testzwecken werden Router zur Simulation der Quelle und des Empfängers verwendet. Gerät R4 und Gerät R8 werden mithilfe des set protocols igmp interface interface-name static group group
Befehls so konfiguriert, dass sie statisch der gewünschten Gruppe beitreten. Wenn ein echter Multicastempfänger-Host nicht verfügbar ist, wie in diesem Beispiel, ist diese statische IGMP-Konfiguration nützlich. Auf den Empfängern wird in diesem Beispiel set protocols sap listen group
verwendet, um die Multicastgruppenadresse abzuhören.
Die MoFRR-Konfiguration enthält eine Richtlinienoption, die in diesem Beispiel nicht dargestellt, aber separat erklärt wird. Die Option ist wie folgt konfiguriert:
stream-protection { policy policy-name; }
Topologie
Abbildung 16 zeigt das Beispielnetzwerk.

CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 16an.
Der Abschnitt Konfiguration beschreibt die Schritte auf Gerät R3.
CLI-Schnellkonfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
Gerät src1
set interfaces ge-1/2/10 unit 0 description src1-to-R1 set interfaces ge-1/2/10 unit 0 family inet address 1.1.0.1/30 set interfaces ge-1/2/11 unit 0 description src1-to-R1 set interfaces ge-1/2/11 unit 0 family inet address 192.168.219.11/24 set interfaces lo0 unit 0 family inet address 1.1.1.17/32 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive
Gerät src2
set interfaces ge-1/2/24 unit 0 description src2-to-R5 set interfaces ge-1/2/24 unit 0 family inet address 1.5.0.2/30 set interfaces lo0 unit 0 family inet address 1.1.1.18/32 set protocols rsvp interface all set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive
Gerät R1
set interfaces ge-1/2/12 unit 0 description R1-to-R2 set interfaces ge-1/2/12 unit 0 family inet address 1.1.2.1/30 set interfaces ge-1/2/12 unit 0 family mpls set interfaces ge-1/2/13 unit 0 description R1-to-R6 set interfaces ge-1/2/13 unit 0 family inet address 1.1.6.1/30 set interfaces ge-1/2/13 unit 0 family mpls set interfaces ge-1/2/10 unit 0 description R1-to-src1 set interfaces ge-1/2/10 unit 0 family inet address 1.1.0.2/30 set interfaces ge-1/2/11 unit 0 description R1-to-src1 set interfaces ge-1/2/11 unit 0 family inet address 192.168.219.9/30 set interfaces lo0 unit 0 family inet address 1.1.1.1/32 set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 1.1.1.1 set protocols bgp group ibgp export static-route-tobgp set protocols bgp group ibgp peer-as 10 set protocols bgp group ibgp neighbor 1.1.1.3 set protocols bgp group ibgp neighbor 1.1.1.7 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface ge-1/2/12.0 set protocols ldp interface ge-1/2/13.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim rp static address 1.1.1.5 set protocols pim interface lo0.0 set protocols pim interface ge-1/2/10.0 set protocols pim interface ge-1/2/11.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.1.7/32 orlonger set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.0.0/30 orlonger set policy-options policy-statement mldppim-ex term A then accept set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set routing-options autonomous-system 10
Gerät R2
set interfaces ge-1/2/12 unit 0 description R2-to-R1 set interfaces ge-1/2/12 unit 0 family inet address 1.1.2.2/30 set interfaces ge-1/2/12 unit 0 family mpls set interfaces ge-1/2/14 unit 0 description R2-to-R3 set interfaces ge-1/2/14 unit 0 family inet address 1.2.3.1/30 set interfaces ge-1/2/14 unit 0 family mpls set interfaces ge-1/2/16 unit 0 description R2-to-R5 set interfaces ge-1/2/16 unit 0 family inet address 1.2.5.1/30 set interfaces ge-1/2/16 unit 0 family mpls set interfaces ge-1/2/17 unit 0 description R2-to-R7 set interfaces ge-1/2/17 unit 0 family inet address 1.2.7.1/30 set interfaces ge-1/2/17 unit 0 family mpls set interfaces ge-1/2/15 unit 0 description R2-to-R3 set interfaces ge-1/2/15 unit 0 family inet address 1.2.94.1/30 set interfaces ge-1/2/15 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.2/32 set interfaces lo0 unit 0 family mpls set protocols rsvp interface all set protocols mpls interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface all set protocols ldp p2mp set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 10
Gerät R3
set chassis network-services enhanced-ip set interfaces ge-1/2/14 unit 0 description R3-to-R2 set interfaces ge-1/2/14 unit 0 family inet address 1.2.3.2/30 set interfaces ge-1/2/14 unit 0 family mpls set interfaces ge-1/2/18 unit 0 description R3-to-R4 set interfaces ge-1/2/18 unit 0 family inet address 1.3.4.1/30 set interfaces ge-1/2/18 unit 0 family mpls set interfaces ge-1/2/19 unit 0 description R3-to-R6 set interfaces ge-1/2/19 unit 0 family inet address 1.3.6.2/30 set interfaces ge-1/2/19 unit 0 family mpls set interfaces ge-1/2/21 unit 0 description R3-to-R7 set interfaces ge-1/2/21 unit 0 family inet address 1.3.7.1/30 set interfaces ge-1/2/21 unit 0 family mpls set interfaces ge-1/2/22 unit 0 description R3-to-R8 set interfaces ge-1/2/22 unit 0 family inet address 1.3.8.1/30 set interfaces ge-1/2/22 unit 0 family mpls set interfaces ge-1/2/15 unit 0 description R3-to-R2 set interfaces ge-1/2/15 unit 0 family inet address 1.2.94.2/30 set interfaces ge-1/2/15 unit 0 family mpls set interfaces ge-1/2/20 unit 0 description R3-to-R6 set interfaces ge-1/2/20 unit 0 family inet address 1.2.96.2/30 set interfaces ge-1/2/20 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.3/32 primary set routing-options autonomous-system 10 set routing-options multicast stream-protection set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 1.1.1.3 set protocols bgp group ibgp peer-as 10 set protocols bgp group ibgp neighbor 1.1.1.1 set protocols bgp group ibgp neighbor 1.1.1.5 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface all set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface lo0.0 set protocols pim interface ge-1/2/18.0 set protocols pim interface ge-1/2/22.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.0.1/30 orlonger set policy-options policy-statement mldppim-ex term A then accept set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept
Gerät R4
set interfaces ge-1/2/18 unit 0 description R4-to-R3 set interfaces ge-1/2/18 unit 0 family inet address 1.3.4.2/30 set interfaces ge-1/2/18 unit 0 family mpls set interfaces ge-1/2/23 unit 0 description R4-to-R7 set interfaces ge-1/2/23 unit 0 family inet address 1.4.7.1/30 set interfaces lo0 unit 0 family inet address 1.1.1.4/32 set protocols igmp interface ge-1/2/18.0 version 3 set protocols igmp interface ge-1/2/18.0 static group 232.1.1.1 group-count 2 set protocols igmp interface ge-1/2/18.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface ge-1/2/18.0 static group 232.2.2.2 source 1.2.7.7 set protocols sap listen 232.1.1.1 set protocols sap listen 232.2.2.2 set protocols rsvp interface all set protocols mpls interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface ge-1/2/23.0 set protocols pim interface ge-1/2/18.0 set protocols pim interface lo0.0 set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 10
Gerät R5
set interfaces ge-1/2/24 unit 0 description R5-to-src2 set interfaces ge-1/2/24 unit 0 family inet address 1.5.0.1/30 set interfaces ge-1/2/16 unit 0 description R5-to-R2 set interfaces ge-1/2/16 unit 0 family inet address 1.2.5.2/30 set interfaces ge-1/2/16 unit 0 family mpls set interfaces ge-1/2/25 unit 0 description R5-to-R6 set interfaces ge-1/2/25 unit 0 family inet address 1.5.6.1/30 set interfaces ge-1/2/25 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.5/32 set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 1.1.1.5 set protocols bgp group ibgp export static-route-tobgp set protocols bgp group ibgp peer-as 10 set protocols bgp group ibgp neighbor 1.1.1.7 set protocols bgp group ibgp neighbor 1.1.1.3 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface ge-1/2/16.0 set protocols ldp interface ge-1/2/25.0 set protocols ldp p2mp set protocols pim interface lo0.0 set protocols pim interface ge-1/2/24.0 set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set routing-options autonomous-system 10
Gerät R6
set interfaces ge-1/2/13 unit 0 description R6-to-R1 set interfaces ge-1/2/13 unit 0 family inet address 1.1.6.2/30 set interfaces ge-1/2/13 unit 0 family mpls set interfaces ge-1/2/19 unit 0 description R6-to-R3 set interfaces ge-1/2/19 unit 0 family inet address 1.3.6.1/30 set interfaces ge-1/2/19 unit 0 family mpls set interfaces ge-1/2/25 unit 0 description R6-to-R5 set interfaces ge-1/2/25 unit 0 family inet address 1.5.6.2/30 set interfaces ge-1/2/25 unit 0 family mpls set interfaces ge-1/2/26 unit 0 description R6-to-R7 set interfaces ge-1/2/26 unit 0 family inet address 1.6.7.1/30 set interfaces ge-1/2/26 unit 0 family mpls set interfaces ge-1/2/20 unit 0 description R6-to-R3 set interfaces ge-1/2/20 unit 0 family inet address 1.2.96.1/30 set interfaces ge-1/2/20 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.6/30 set protocols rsvp interface all set protocols mpls interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface all set protocols ldp p2mp
Gerät R7
set interfaces ge-1/2/17 unit 0 description R7-to-R2 set interfaces ge-1/2/17 unit 0 family inet address 1.2.7.2/30 set interfaces ge-1/2/17 unit 0 family mpls set interfaces ge-1/2/21 unit 0 description R7-to-R3 set interfaces ge-1/2/21 unit 0 family inet address 1.3.7.2/30 set interfaces ge-1/2/21 unit 0 family mpls set interfaces ge-1/2/23 unit 0 description R7-to-R4 set interfaces ge-1/2/23 unit 0 family inet address 1.4.7.2/30 set interfaces ge-1/2/23 unit 0 family mpls set interfaces ge-1/2/26 unit 0 description R7-to-R6 set interfaces ge-1/2/26 unit 0 family inet address 1.6.7.2/30 set interfaces ge-1/2/26 unit 0 family mpls set interfaces ge-1/2/27 unit 0 description R7-to-R8 set interfaces ge-1/2/27 unit 0 family inet address 1.7.8.1/30 set interfaces ge-1/2/27 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.7/32 set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 1.1.1.7 set protocols bgp group ibgp export static-route-tobgp set protocols bgp group ibgp peer-as 10 set protocols bgp group ibgp neighbor 1.1.1.5 set protocols bgp group ibgp neighbor 1.1.1.1 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface ge-1/2/17.0 set protocols ldp interface ge-1/2/21.0 set protocols ldp interface ge-1/2/26.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface lo0.0 set protocols pim interface ge-1/2/27.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.0.1/30 orlonger set policy-options policy-statement mldppim-ex term A then accept set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set routing-options autonomous-system 10 set routing-options multicast stream-protection policy mldppim-ex
Gerät R8
set interfaces ge-1/2/22 unit 0 description R8-to-R3 set interfaces ge-1/2/22 unit 0 family inet address 1.3.8.2/30 set interfaces ge-1/2/22 unit 0 family mpls set interfaces ge-1/2/27 unit 0 description R8-to-R7 set interfaces ge-1/2/27 unit 0 family inet address 1.7.8.2/30 set interfaces ge-1/2/27 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.8/32 set protocols igmp interface ge-1/2/22.0 version 3 set protocols igmp interface ge-1/2/22.0 static group 232.1.1.1 group-count 2 set protocols igmp interface ge-1/2/22.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface ge-1/2/22.0 static group 232.2.2.2 source 1.2.7.7 set protocols sap listen 232.1.1.1 set protocols sap listen 232.2.2.2 set protocols rsvp interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface ge-1/2/27.0 set protocols pim interface ge-1/2/22.0 set protocols pim interface lo0.0 set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 10
Konfiguration
Verfahren
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie Gerät R3:
Aktivieren Sie den erweiterten IP-Modus.
[edit chassis] user@R3# set network-services enhanced-ip
Konfigurieren Sie die Geräteschnittstellen.
[edit interfaces] user@R3# set ge-1/2/14 unit 0 description R3-to-R2 user@R3# set ge-1/2/14 unit 0 family inet address 1.2.3.2/30 user@R3# set ge-1/2/14 unit 0 family mpls user@R3# set ge-1/2/18 unit 0 description R3-to-R4 user@R3# set ge-1/2/18 unit 0 family inet address 1.3.4.1/30 user@R3# set ge-1/2/18 unit 0 family mpls user@R3# set ge-1/2/19 unit 0 description R3-to-R6 user@R3# set ge-1/2/19 unit 0 family inet address 1.3.6.2/30 user@R3# set ge-1/2/19 unit 0 family mpls user@R3# set ge-1/2/21 unit 0 description R3-to-R7 user@R3# set ge-1/2/21 unit 0 family inet address 1.3.7.1/30 user@R3# set ge-1/2/21 unit 0 family mpls user@R3# set ge-1/2/22 unit 0 description R3-to-R8 user@R3# set ge-1/2/22 unit 0 family inet address 1.3.8.1/30 user@R3# set ge-1/2/22 unit 0 family mpls user@R3# set ge-1/2/15 unit 0 description R3-to-R2 user@R3# set ge-1/2/15 unit 0 family inet address 1.2.94.2/30 user@R3# set ge-1/2/15 unit 0 family mpls user@R3# set ge-1/2/20 unit 0 description R3-to-R6 user@R3# set ge-1/2/20 unit 0 family inet address 1.2.96.2/30 user@R3# set ge-1/2/20 unit 0 family mpls user@R3# set lo0 unit 0 family inet address 1.1.1.3/32 primary
Konfigurieren Sie die autonome Systemnummer (AS).
user@R3# set routing-options autonomous-system 10
Konfigurieren Sie die Routing-Richtlinien.
[edit policy-options policy-statement mldppim-ex] user@R3# set term B from source-address-filter 192.168.0.0/24 orlonger user@R3# set term B from source-address-filter 192.168.219.11/32 orlonger user@R3# set term B then accept user@R3# set term A from source-address-filter 1.1.0.1/30 orlonger user@R3# set term A then accept [edit policy-options policy-statement static-route-tobgp] user@R3# set term static from protocol static user@R3# set term static from protocol direct user@R3# set term static then accept
PIM konfigurieren.
[edit protocols pim] user@R3# set mldp-inband-signalling policy mldppim-ex user@R3# set interface lo0.0 user@R3# set interface ge-1/2/18.0 user@R3# set interface ge-1/2/22.0
LDP konfigurieren.
[edit protocols ldp] user@R3# set interface all user@R3# set p2mp
Konfigurieren Sie ein IGP oder statische Routen.
[edit protocols ospf] user@R3# set traffic-engineering user@R3# set area 0.0.0.0 interface all user@R3# set area 0.0.0.0 interface fxp0.0 disable user@R3# set area 0.0.0.0 interface lo0.0 passive
Konfigurieren Sie internes BGP.
[edit protocols bgp group ibgp] user@R3# set local-address 1.1.1.3 user@R3# set peer-as 10 user@R3# set neighbor 1.1.1.1 user@R3# set neighbor 1.1.1.5
Konfigurieren Sie MPLS und optional RSVP.
[edit protocols mpls] user@R3# set interface all [edit protocols rsvp] user@R3# set interface all
MoFRR aktivieren.
[edit routing-options multicast] user@R3# set stream-protection
Ergebnisse
Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration, indem Sie die show chassis
Befehle , , show interfaces
show protocols
, show policy-options
und eingebenshow routing-options
. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R3# show chassis network-services enhanced-ip;
user@R3# show interfaces ge-1/2/14 { unit 0 { description R3-to-R2; family inet { address 1.2.3.2/30; } family mpls; } } ge-1/2/18 { unit 0 { description R3-to-R4; family inet { address 1.3.4.1/30; } family mpls; } } ge-1/2/19 { unit 0 { description R3-to-R6; family inet { address 1.3.6.2/30; } family mpls; } } ge-1/2/21 { unit 0 { description R3-to-R7; family inet { address 1.3.7.1/30; } family mpls; } } ge-1/2/22 { unit 0 { description R3-to-R8; family inet { address 1.3.8.1/30; } family mpls; } } ge-1/2/15 { unit 0 { description R3-to-R2; family inet { address 1.2.94.2/30; } family mpls; } } ge-1/2/20 { unit 0 { description R3-to-R6; family inet { address 1.2.96.2/30; } family mpls; } } lo0 { unit 0 { family inet { address 192.168.15.1/32; address 1.1.1.3/32 { primary; } } } }
user@R3# show protocols rsvp { interface all; } mpls { interface all; } bgp { group ibgp { local-address 1.1.1.3; peer-as 10; neighbor 1.1.1.1; neighbor 1.1.1.5; } } ospf { traffic-engineering; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } interface lo0.0 { passive; } } } ldp { interface all; p2mp; } pim { mldp-inband-signalling { policy mldppim-ex; } interface lo0.0; interface ge-1/2/18.0; interface ge-1/2/22.0; }
user@R3# show policy-options policy-statement mldppim-ex { term B { from { source-address-filter 192.168.0.0/24 orlonger; source-address-filter 192.168.219.11/32 orlonger; } then accept; } term A { from { source-address-filter 1.1.0.1/30 orlonger; } then accept; } } policy-statement static-route-tobgp { term static { from protocol [ static direct ]; then accept; } }
user@R3# show routing-options autonomous-system 10; multicast { stream-protection; }
Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der LDP-Punkt-zu-Multipoint-Weiterleitungsgleichheitsklassen
- Prüfung der Labelinformationen
- Überprüfen der Multicast-Routen
- Überprüfen der LDP-Datenverkehrsstatistiken von Point-to-Multipoint
Überprüfen der LDP-Punkt-zu-Multipoint-Weiterleitungsgleichheitsklassen
Zweck
Stellen Sie sicher, dass moFRR aktiviert ist, und bestimmen Sie, welche Labels verwendet werden.
Aktion
user@R3> show ldp p2mp fec LDP P2MP FECs: P2MP root-addr 1.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 MoFRR enabled Fec type: Egress (Active) Label: 301568 P2MP root-addr 1.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 MoFRR enabled Fec type: Egress (Active) Label: 301600
Bedeutung
Die Ausgabe zeigt, dass MoFRR aktiviert ist, und es zeigt, dass die Labels 301568 und 301600 für die beiden Multipoint-LDP-Point-to-Multipoint-LSPs verwendet werden.
Prüfung der Labelinformationen
Zweck
Stellen Sie sicher, dass das Ausgangsgerät über zwei Upstream-Schnittstellen für den Multicastgruppen-Join verfügt.
Aktion
user@R3> show route label 301568 detail mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 301568 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x2735208 Next-hop reference count: 3 Next hop type: Router, Next hop index: 1397 Address: 0x2735d2c Next-hop reference count: 3 Next hop: 1.3.8.2 via ge-1/2/22.0 Label operation: Pop Load balance label: None; Next hop type: Router, Next hop index: 1395 Address: 0x2736290 Next-hop reference count: 3 Next hop: 1.3.4.2 via ge-1/2/18.0 Label operation: Pop Load balance label: None; State: <Active Int AckRequest MulticastRPF> Local AS: 10 Age: 54:05 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 1.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 Primary Upstream : 1.1.1.3:0--1.1.1.2:0 RPF Nexthops : ge-1/2/15.0, 1.2.94.1, Label: 301568, weight: 0x1 ge-1/2/14.0, 1.2.3.1, Label: 301568, weight: 0x1 Backup Upstream : 1.1.1.3:0--1.1.1.6:0 RPF Nexthops : ge-1/2/20.0, 1.2.96.1, Label: 301584, weight: 0xfffe ge-1/2/19.0, 1.3.6.1, Label: 301584, weight: 0xfffe
user@R3> show route label 301600 detail mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 301600 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x27356b4 Next-hop reference count: 3 Next hop type: Router, Next hop index: 1520 Address: 0x27350f4 Next-hop reference count: 3 Next hop: 1.3.8.2 via ge-1/2/22.0 Label operation: Pop Load balance label: None; Next hop type: Router, Next hop index: 1481 Address: 0x273645c Next-hop reference count: 3 Next hop: 1.3.4.2 via ge-1/2/18.0 Label operation: Pop Load balance label: None; State: <Active Int AckRequest MulticastRPF> Local AS: 10 Age: 54:25 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 1.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 Primary Upstream : 1.1.1.3:0--1.1.1.6:0 RPF Nexthops : ge-1/2/20.0, 1.2.96.1, Label: 301600, weight: 0x1 ge-1/2/19.0, 1.3.6.1, Label: 301600, weight: 0x1 Backup Upstream : 1.1.1.3:0--1.1.1.2:0 RPF Nexthops : ge-1/2/15.0, 1.2.94.1, Label: 301616, weight: 0xfffe ge-1/2/14.0, 1.2.3.1, Label: 301616, weight: 0xfffe
Bedeutung
Die Ausgabe zeigt die primären Upstream-Pfade und die Backup-Upstream-Pfade. Es zeigt auch die nächsten Hops von RPF.
Überprüfen der Multicast-Routen
Zweck
Prüfen Sie die IP-Multicastweiterleitungstabelle, um sicherzustellen, dass es eine Upstream-RPF-Schnittstellenliste mit einer primären und einer Backup-Schnittstelle gibt.
Aktion
user@R3> show ldp p2mp path P2MP path type: Transit/Egress Output Session (label): 1.1.1.2:0 (301568) (Primary) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 1.2.94.1, 301568, 1 Interface ge-1/2/20.0, 1.2.96.1, 301584, 65534 Interface ge-1/2/14.0, 1.2.3.1, 301568, 1 Interface ge-1/2/19.0, 1.3.6.1, 301584, 65534 Attached FECs: P2MP root-addr 1.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 (Active) P2MP path type: Transit/Egress Output Session (label): 1.1.1.6:0 (301584) (Backup) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 1.2.94.1, 301568, 1 Interface ge-1/2/20.0, 1.2.96.1, 301584, 65534 Interface ge-1/2/14.0, 1.2.3.1, 301568, 1 Interface ge-1/2/19.0, 1.3.6.1, 301584, 65534 Attached FECs: P2MP root-addr 1.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 (Active) P2MP path type: Transit/Egress Output Session (label): 1.1.1.6:0 (301600) (Primary) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 1.2.94.1, 301616, 65534 Interface ge-1/2/20.0, 1.2.96.1, 301600, 1 Interface ge-1/2/14.0, 1.2.3.1, 301616, 65534 Interface ge-1/2/19.0, 1.3.6.1, 301600, 1 Attached FECs: P2MP root-addr 1.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 (Active) P2MP path type: Transit/Egress Output Session (label): 1.1.1.2:0 (301616) (Backup) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 1.2.94.1, 301616, 65534 Interface ge-1/2/20.0, 1.2.96.1, 301600, 1 Interface ge-1/2/14.0, 1.2.3.1, 301616, 65534 Interface ge-1/2/19.0, 1.3.6.1, 301600, 1 Attached FECs: P2MP root-addr 1.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 (Active)
Bedeutung
Die Ausgabe zeigt primäre und Backup-Sitzungen sowie RPF Next Hops.
Überprüfen der LDP-Datenverkehrsstatistiken von Point-to-Multipoint
Zweck
Stellen Sie sicher, dass sowohl primäre als auch Backup-Statistiken aufgeführt sind.
Aktion
user@R3> show ldp traffic-statistics p2mp P2MP FEC Statistics: FEC(root_addr:lsp_id/grp,src) Nexthop Packets Bytes Shared 1.1.1.1:232.1.1.1,192.168.219.11, Label: 301568 1.3.8.2 0 0 No 1.3.4.2 0 0 No 1.1.1.1:232.1.1.1,192.168.219.11, Label: 301584, Backup route 1.3.4.2 0 0 No 1.3.8.2 0 0 No 1.1.1.1:232.1.1.2,192.168.219.11, Label: 301600 1.3.8.2 0 0 No 1.3.4.2 0 0 No 1.1.1.1:232.1.1.2,192.168.219.11, Label: 301616, Backup route 1.3.4.2 0 0 No 1.3.8.2 0 0 No
Bedeutung
Die Ausgabe zeigt sowohl Primär- als auch Backup-Routen mit den Labeln.
Beispiel: Konfiguration von LDP Downstream auf Abruf
In diesem Beispiel wird gezeigt, wie LDP-Downstream-On-Demand konfiguriert wird. LDP wird üblicherweise mithilfe des Downstream-Modus für unerwünschte Werbung konfiguriert, d. h. Label-Werbung für alle Routen wird von allen LDP-Peers empfangen. Da Service Provider die Zugriffs- und Aggregationsnetzwerke in eine einzelne MPLS-Domäne integrieren, ist LDP-Downstream-on-Demand erforderlich, um die Bindungen zwischen den Zugriffs- und Aggregationsnetzwerken zu verteilen und die Verarbeitungsanforderungen für die Steuerungsebene zu reduzieren.
Downstream-Knoten könnten zehntausende Labelbindungen von upstreamen Aggregationsknoten erhalten. Anstatt alle Label-Bindungen für alle möglichen Loopback-Adressen innerhalb des gesamten MPLS-Netzwerks zu lernen und zu speichern, kann der Downstream-Aggregationsknoten mit LDP Downstream on Demand konfiguriert werden, um nur die Labelbindungen für die FECs zu anfordern, die den Loopback-Adressen der Ausgangsknoten entsprechen, auf denen die Services konfiguriert sind.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Router der M-Serie
Junos OS 12.2
Überblick
Sie können LDP-Downstream-On-Demand-Label-Werbung für eine LDP-Sitzung aktivieren, indem Sie die Downstream-on-Demand-Anweisung auf der [edit protocols ldp session]
Hierarchieebene einbeziehen. Wenn Sie Downstream-On-Demand konfiguriert haben, wirbt der Router von Juniper Networks bei seinen Peer-Routern für die Downstream-On-Demand-Anfrage. Damit eine Downstream-On-Demand-Sitzung zwischen zwei Routern eingerichtet werden kann, müssen beide während der LDP-Sitzungseinrichtung den Downstream-On-Demand-Modus anzeigen. Wenn ein Router den nachgeschalteten unerwünschten Modus und den anderen downstream-on-Demand-Modus anwirbt, wird der nachgeschaltete unerwünschte Modus verwendet.
Konfiguration
- Konfiguration von LDP Downstream auf Abruf
- Verteilung von LDP-Downstream-On-Demand-Routen in gekennzeichnetes BGP
Konfiguration von LDP Downstream auf Abruf
Schritt-für-Schritt-Verfahren
So konfigurieren Sie eine LDP-Downstream-On-Demand-Richtlinie, konfigurieren diese Richtlinie und aktivieren LDP Downstream-on-Demand auf der LDP-Sitzung:
Konfigurieren Sie die Downstream-On-Demand-Richtlinie (DOD-Request-Loopbacks in diesem Beispiel).
Diese Richtlinie bewirkt, dass der Router Nachrichten zur Labelanforderung nur an die FECs weiterleitet, die von der DOD-Request-Loopbacks-Richtlinie übereinstimmen.
[edit policy-options] user@host# set prefix-list Request-Loopbacks 10.1.1.1/32 user@host# set prefix-list Request-Loopbacks 10.1.1.2/32 user@host# set prefix-list Request-Loopbacks 10.1.1.3/32 user@host# set prefix-list Request-Loopbacks 10.1.1.4/32 user@host# set policy-statement DOD-Request-Loopbacks term 1 from prefix-list Request-Loopbacks user@host# set policy-statement DOD-Request-Loopbacks term 1 then accept
Geben Sie die DOD-Request-Loopbacks-Richtlinie mithilfe der
dod-request-policy
Anweisung auf Hierarchieebene[edit protocols ldp]
an.Die mit der
dod-request-policy
Anweisung angegebene Richtlinie wird verwendet, um die Präfixe zu identifizieren, die Nachrichten zum Senden von Label-Request-Nachrichten senden. Diese Richtlinie ähnelt einer Ausgangsrichtlinie oder einer Importrichtlinie. Bei der Verarbeitung von Routen aus der Routing-Tabelle inet.0 prüft die Junos OS-Software, ob Routen der Richtlinie entsprechen (in diesemDOD-Request-Loopbacks
Beispiel). Wenn die Route mit der Richtlinie übereinstimmt und die LDP-Sitzung mit dem DOD-Werbemodus ausgehandelt wird, werden Nachrichten zur Labelanforderung an die entsprechende downstream-LDP-Sitzung gesendet.[edit protocols ldp] user@host# set dod-request-policy DOD-Request-Loopbacks
Fügen Sie die
downstream-on-demand
Anweisung in die Konfiguration für die LDP-Sitzung ein, um den Downstream-On-Demand-Verteilungsmodus zu aktivieren.[edit protocols ldp] user@host# set session 1.1.1.1 downstream-on-demand
Verteilung von LDP-Downstream-On-Demand-Routen in gekennzeichnetes BGP
Schritt-für-Schritt-Verfahren
Verwenden Sie eine BGP-Exportrichtlinie, um LDP-Downstream-On-Demand-Routen in BGP zu verteilen.
Konfigurieren Sie die LDP-Routenrichtlinie (
redistribute_ldp
in diesem Beispiel).[edit policy-options] user@host# set policy-statement redistribute_ldp term 1 from protocol ldp user@host# set policy-statement redistribute_ldp term 1 from tag 1000 user@host# set policy-statement redistribute_ldp term 1 then accept
Fügen Sie die LDP-Routenrichtlinie
redistribute_ldp
in die BGP-Konfiguration ein (als Teil der Konfiguration der BGP-Gruppeebgp-to-abr
in diesem Beispiel).BGP leitet die LDP-Routen basierend auf der
redistribute_ldp
Richtlinie an den Remote-PE-Router weiter[edit protocols bgp] user@host# set group ebgp-to-abr type external user@host# set group ebgp-to-abr local-address 192.168.0.1 user@host# set group ebgp-to-abr peer-as 65319 user@host# set group ebgp-to-abr local-as 65320 user@host# set group ebgp-to-abr neighbor 192.168.6.1 family inet unicast user@host# set group ebgp-to-abr neighbor 192.168.6.1 family inet labeled-unicast rib inet.3 user@host# set group ebgp-to-abr neighbor 192.168.6.1 export redistribute_ldp
Schritt-für-Schritt-Verfahren
Konfigurieren Sie die folgenden Richtlinien, um die Labelausbreitung auf andere Router zu beschränken, die im Downstream-Modus (anstelle von Downstream-on-Demand) konfiguriert sind:
Konfigurieren Sie die
dod-routes
Richtlinie, um Routen von LDP zu akzeptieren.user@host# set policy-options policy-statement dod-routes term 1 from protocol ldp user@host# set policy-options policy-statement dod-routes term 1 from tag 1145307136 user@host# set policy-options policy-statement dod-routes term 1 then accept
Konfigurieren Sie die
do-not-propagate-du-sessions
Richtlinie, um Routen nicht an Nachbarn1.1.1.1
weiterzuleiten ,2.2.2.2
und3.3.3.3
.user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 1.1.1.1 user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 2.2.2.2 user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 3.3.3.3 user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 then reject
Konfigurieren Sie die
filter-dod-on-du-sessions
Richtlinie, um zu verhindern, dass die von derdod-routes
Richtlinie untersuchten Routen an die in derdo-not-propagate-du-sessions
Richtlinie definierten benachbarten Router weitergeleitet werden.user@host# set policy-options policy-statement filter-dod-routes-on-du-sessions term 1 from policy dod-routes user@host# set policy-options policy-statement filter-dod-routes-on-du-sessions term 1 to policy do-not-propagate-du-sessions
Geben Sie die
filter-dod-routes-on-du-sesssion
Richtlinie als Exportrichtlinie für BGP-Broup anebgp-to-abr
.[edit protocols bgp] user@host# set group ebgp-to-abr neighbor 192.168.6.2 export filter-dod-routes-on-du-sessions
Ergebnisse
Bestätigen Sie ihre Konfiguration vom Konfigurationsmodus aus, indem Sie die Befehle und show protocols ldp
die Befehle show policy-options
eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options prefix-list Request-Loopbacks { 10.1.1.1/32; 10.1.1.2/32; 10.1.1.3/32; 10.1.1.4/32; } policy-statement DOD-Request-Loopbacks { term 1 { from { prefix-list Request-Loopbacks; } then accept; } } policy-statement redistribute_ldp { term 1 { from { protocol ldp; tag 1000; } then accept; } }
user@host# show protocols ldp dod-request-policy DOD-Request-Loopbacks; session 1.1.1.1 { downstream-on-demand; }
user@host# show protocols bgp group ebgp-to-abr { type external; local-address 192.168.0.1; peer-as 65319; local-as 65320; neighbor 192.168.6.1 { family inet { unicast; labeled-unicast { rib { inet.3; } } } export redistribute_ldp; } }
Überprüfung
Überprüfung des Label Advertisement-Modus
Zweck
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Verwenden Sie den show ldp session
Befehl, um den Status des Label-Advertisement-Modus für die LDP-Sitzung zu überprüfen.
Aktion
Geben Sie die show ldp session
Und-Befehle show ldp session detail
aus:
Die folgende Befehlsausgabe für den
show ldp session
Befehl gibt an, dass derAdv. Mode
(Label-Advertisement-Modus) istDOD
(d. h. die LDP-Downstream-On-Demand-Sitzung ist betriebsbereit):user@host>
show ldp session
Address State Connection Hold time Adv. Mode 1.1.1.2 Operational Open 22 DODDie folgende Befehlsausgabe für den
show ldp session detail
Befehl gibt an, dass derLocal Label Advertisement mode
Downstream unsolicited
Standardwert ist , der Standardwert (d. h. Downstream-on-Demand ist nicht auf der lokalen Sitzung konfiguriert). Umgekehrt geben sowohl dieRemote Label Advertisement mode
als auch dieNegotiated Label Advertisement mode
beiden Anzeigen an, dass dieDownstream on demand
Konfiguration auf der Remotesitzunguser@host>
show ldp session detail
Address: 1.1.1.2, State: Operational, Connection: Open, Hold time: 24 Session ID: 1.1.1.1:0--1.1.1.2:0 Next keepalive in 4 seconds Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 Neighbor types: configured-tunneled Keepalive interval: 10, Connect retry interval: 1 Local address: 1.1.1.1, Remote address: 1.1.1.2 Up for 17:54:52 Capabilities advertised: none Capabilities received: none Protection: disabled Local - Restart: disabled, Helper mode: enabled, Remote - Restart: disabled, Helper mode: enabled Local maximum neighbor reconnect time: 120000 msec Local maximum neighbor recovery time: 240000 msec Local Label Advertisement mode: Downstream unsolicited Remote Label Advertisement mode: Downstream on demand Negotiated Label Advertisement mode: Downstream on demand Nonstop routing state: Not in sync Next-hop addresses received: 1.1.1.2
Konfiguration der LDP-nativen IPv6-Unterstützung
LDP wird in einem IPv6-Netzwerk und in einem IPv6- oder IPv4-Dual-Stack-Netzwerk unterstützt, wie in RFC 7552 beschrieben. Konfigurieren Sie die Adressfamilie wie inet
für IPv4 oder inet6
für IPv6 oder beide und die Übertragungspräferenz entweder IPv4
oder IPv6
. Mit dual-transport
der Anweisung kann Junos OS LDP die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herstellen. Bei inet-lsr-id
den inet6-lsr-id
IDs und IDs handelt es sich um die beiden LSR-IDs, die konfiguriert werden müssen, um eine LDP-Sitzung über IPv4- und IPv6-TCP-Transport einzurichten. Diese beiden IDs sollten nicht null sein und müssen mit unterschiedlichen Werten konfiguriert werden.
Bevor Sie IPv6 als Dual-Stack konfigurieren, stellen Sie sicher, dass Sie die Routing- und Signalprotokolle konfigurieren.
Um die LDP-native IPv6-Unterstützung zu konfigurieren, müssen Sie Folgendes tun:
Beispiel: Konfiguration der LDP-nativen IPv6-Unterstützung
Dieses Beispiel zeigt, wie das Junos OS Label Distribution Protocol (LDP) die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herstellen kann. So wird das Tunneling von IPv6 über IPv4 MPLS-Core mit IPv4-signalisierten MPLS Label Switched Paths (LSPs) vermieden.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Zwei Router der MX-Serie
Junos OS Version 16.1 oder höher, die auf allen Geräten ausgeführt wird
Bevor Sie IPv6 als Dual-Stack konfigurieren, stellen Sie sicher, dass Sie die Routing- und Signalprotokolle konfigurieren.
Überblick
LDP wird in einem IPv6-Netzwerk und in einem IPv6- oder IPv4-Dual-Stack-Netzwerk unterstützt, wie in RFC 7552 beschrieben. Konfigurieren Sie die Adressfamilie wie inet
für IPv4 oder inet6
IPv6. Standardmäßig wird IPv6 als TCP-Transport für die LDP-Sitzung mit seinen Peers verwendet, wenn sowohl IPv4 als auch IPv6 aktiviert sind. Mithilfe der Dual-Transport-Anweisung kann Junos LDP die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herstellen. inet6-lsr-id
Die inet-lsr-id
beiden LSR-IDs, die konfiguriert werden müssen, um eine LDP-Sitzung über IPv4- und IPv6-TCP-Transport einzurichten. Diese beiden IDs sollten nicht null sein und müssen mit unterschiedlichen Werten konfiguriert werden.
Topologie
Abbildung 17 zeigt die LDP-IPv6-Konfiguration als Dual-Stack auf Gerät R1 und Gerät R2.

Konfiguration
- CLI-Schnellkonfiguration
- Konfigurieren von R1
- Konfiguration der Transportpräferenz zur Auswahl des bevorzugten Transports
- Konfiguration von Dual-Transport zur Einrichtung separater Sitzungen für IPv4 mit einem IPv4 Neighbor und IPv6 mit einem IPv6 Neighbor
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit] CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit
.
R1
set interfaces ge-1/0/0 unit 0 family inet address 192.168.12.1/24 set interfaces ge-1/0/0 unit 0 family iso set interfaces ge-1/0/0 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 set interfaces ge-1/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.0.1/32 set interfaces lo0 unit 0 family iso address 49.0001.1720.1600.1010.00 set interfaces lo0 unit 0 family inet6 address 2001:db8::1/128 set protocols isis interface ge-1/0/0.0 set protocols isis interface lo0.0 set protocols mpls interface ge-1/0/0.0 set protocols ldp deaggregate set protocols ldp interface ge-1/0/0.0 set protocols ldp interface lo0.0 set protocols ldp family inet6 set protocols ldp family inet
R2
set interfaces ge-1/0/1 unit 0 family inet address 192.168.12.2/24 set interfaces ge-1/0/1 unit 0 family iso set interfaces ge-1/0/1 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 set interfaces ge-1/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.0.2/32 set interfaces lo0 unit 0 family iso address 49.0001.1720.1600.2020.00 set interfaces lo0 unit 0 family inet6 address 2001:db8::2/128 set protocols isis interface ge-1/0/1.0 set protocols isis interface lo0.0 set protocols mpls interface ge-1/0/1.0 set protocols ldp deaggregate set protocols ldp interface ge-1/0/1.0 set protocols ldp interface lo0.0 set protocols ldp family inet6 set protocols ldp family inet
Konfigurieren von R1
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie in verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden SieUsing the CLI Editor in Configuration Mode im Cli-Benutzerhandbuch von Junos OS.
So konfigurieren Sie Gerät R1:
Konfigurieren Sie die Schnittstellen.
[edit interfaces] set ge-1/0/0 unit 0 family inet address 192.168.12.1/24 set ge-1/0/0 unit 0 family iso set ge-1/0/0 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 set ge-1/0/0 unit 0 family mpls
Weisen Sie dem Gerät eine Loopback-Adresse zu.
[edit interfaces lo0 unit 0] set family inet address 10.255.0.1/32 set family iso address 49.0001.1720.1600.1010.00 set family inet6 address 2001:db8::1/128
Konfigurieren Sie die IS-IS-Schnittstellen.
[edit protocols isis] set interface ge-1/0/0.0 set interface lo0.0
Konfigurieren Sie MPLS für die Verwendung von LDP-Schnittstellen auf dem Gerät.
[edit protocols mpls] set protocols mpls interface ge-1/0/0.0 set interface ge-1/0/0.0 set interface lo0.0
Ermöglichen Sie die Deaggregation der Forwarding Equivalence Class (FEC), um verschiedene Label für verschiedene Adressfamilien zu verwenden.
[edit protocols ldp] set deaggregate
Konfigurieren Sie LDP-Adressfamilien.
[edit protocols ldp] set family inet6 set family inet
Ergebnisse
Bestätigen Sie ihre Konfiguration vom Konfigurationsmodus aus, indem Sie die Befehle und show protocols die Befehle show interfaces eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show interfaces ge-1/0/0 { unit 0 { family inet { address 192.168.12.1/24; } family iso; family inet6 { address 2001:db8:0:12::/64 { eui-64; } } family mpls; } } lo0 { unit 0 { family inet { address 10.255.0.1/32; } family iso { address 49.0001.1720.1600.1010.00 } family inet6 { address 2001:db8::1/128; } } }
user@R1# show protocols mpls { interface ge-1/0/0.0; } isis { interface ge-1/0/0.0; interface lo0.0; } ldp { deaggregate; interface ge-1/0/0.0; interface lo0.0; family { inet6; inet; } }
Konfiguration der Transportpräferenz zur Auswahl des bevorzugten Transports
CLI-Schnellkonfiguration
Schritt-für-Schritt-Verfahren
Sie können die transport-preference
Anweisung so konfigurieren, dass der bevorzugte Transport für eine TCP-Verbindung ausgewählt wird, wenn sowohl IPv4 als auch IPv6 aktiviert sind. Standardmäßig wird IPv6 als TCP-Transport zum Herstellen einer LDP-Verbindung verwendet.
(Optional) Konfigurieren Sie die Transportpräferenz für eine LDP-Verbindung.
[edit protocols ldp] set transport-preference ipv4
Schritt-für-Schritt-Verfahren
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show protocols Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show protocols mpls { interface ge-1/0/0.0; } isis { interface ge-1/0/0.0; interface lo0.0; } ldp { deaggregate; interface ge-1/0/0.0; interface lo0.0; family { inet6; inet; } transport-preference ipv4; }
Konfiguration von Dual-Transport zur Einrichtung separater Sitzungen für IPv4 mit einem IPv4 Neighbor und IPv6 mit einem IPv6 Neighbor
Schritt-für-Schritt-Verfahren
Sie können die dual-transport
Anweisung so konfigurieren, dass LDP eine separate IPv4-Sitzung mit einem IPv4-Nachbarn und eine IPv6-Sitzung mit einem IPv6-Nachbarn einrichten kann. Dies erfordert die Konfiguration von inet-lsr-id
als LSR-ID für IPv4 und inet6-lsr-id
als LSR-ID für IPv6.
(Optional) Konfigurieren Sie Dual-Transport, damit LDP die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herstellt.
[edit protocols ldp dual-transport] set inet-lsr-id 10.255.0.1 set inet6-lsr-id 1.1.1.1
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show protocols Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@R1# show protocols mpls { interface ge-1/0/0.0; } isis { interface ge-1/0/0.0; interface lo0.0; } ldp { deaggregate; interface ge-1/0/0.0; interface lo0.0; family { inet6; inet; } dual-transport { inet-lsr-id 10.255.0.1; inet6-lsr-id 1.1.1.1; } }
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Routeneinträge in der mpls.0-Tabelle
- Überprüfen der Routeneinträge in der Tabelle inet.3
- Überprüfen der Routeneinträge in der Tabelle inet6.3
- Überprüfen der LDP-Datenbank
- Überprüfen der LDP-Nachbarinformationen
- Überprüfen der LDP-Sitzungsinformationen
Überprüfen der Routeneinträge in der mpls.0-Tabelle
Zweck
Mpls.0-Routentabelleninformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um die show route table mpls.0
Mpls.0-Routentabelleninformationen anzuzeigen.
user@R1> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 05:19:58, metric 1
Receive
1 *[MPLS/0] 05:19:58, metric 1
Receive
2 *[MPLS/0] 05:19:58, metric 1
Receive
13 *[MPLS/0] 05:19:58, metric 1
Receive
299824 *[LDP/9] 04:28:45, metric 1
> to fe80::21f:1200:cb6:4c8d via ge-1/0/0.0, Pop
299824(S=0) *[LDP/9] 04:28:45, metric 1
> to fe80::21f:1200:cb6:4c8d via ge-1/0/0.0, Pop
299888 *[LDP/9] 00:56:12, metric 1
> to 192.168.12.2 via ge-1/0/0.0, Pop
299888(S=0) *[LDP/9] 00:56:12, metric 1
> to 192.168.12.2 via ge-1/0/0.0, Pop
Bedeutung
Die Ausgabe zeigt die Mpls.0-Routentabelleninformationen an.
Überprüfen der Routeneinträge in der Tabelle inet.3
Zweck
Inet.3-Routentabelleninformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den show route table inet.3
Befehl aus, um informationen zur Routentabelle inet.3 anzuzeigen.
user@R1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.0.2/32 *[LDP/9] 00:58:38, metric 1
> to 192.168.12.2 via ge-1/0/0.0
Bedeutung
Die Ausgabe zeigt die Informationen zur Routentabelle inet.3 an.
Überprüfen der Routeneinträge in der Tabelle inet6.3
Zweck
Inet6.3-Routentabelleninformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den show route table inet6.3
Befehl aus, um informationen zur Routentabelle inet6.3 anzuzeigen.
user@R1> show route table inet6.3
inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::2/128 *[LDP/9] 04:31:17, metric 1
> to fe80::21f:1200:cb6:4c8d via ge-1/0/0.0
Bedeutung
Die Ausgabe zeigt die Informationen der Routentabelle inet6.3 an.
Überprüfen der LDP-Datenbank
Zweck
LDP-Datenbankinformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Datenbankinformationen show ldp database
anzuzeigen.
user@R1> show ldp database
Input label database, 10.255.0.1:0--10.255.0.2:0
Labels received: 3
Label Prefix
299840 10.255.0.1/32
3 10.255.0.2/32
299808 2001:db8::1/128
3 2001:db8::2/128
Output label database, 10.255.0.1:0--10.255.0.2:0
Labels advertised: 3
Label Prefix
3 10.255.0.1/32
299888 10.255.0.2/32
3 2001:db8::1/128
299824 2001:db8::2/128
Bedeutung
Die Ausgabe zeigt die Einträge in der LDP-Datenbank an.
Überprüfen der LDP-Nachbarinformationen
Zweck
LDP-Nachbarinformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 aus dem Betriebsmodus die Befehle ausshow ldp neighbor extensive
, um LDP-Nachbarinformationen show ldp neighbor
anzuzeigen.
user@R1>show ldp neighbor
Address Interface Label space ID Hold time fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 12 192.168.12.2 ge-1/0/0.0 10.255.0.2:0 11 user@R1>show ldp neighbor extensive
Address Interface Label space ID Hold time 192.168.12.2 ge-1/0/0.0 10.255.0.2:0 11 Transport address: 10.255.0.2, Transport preference: IPv6, Configuration sequence: 10 Up for 00:04:35 Reference count: 1 Hold time: 15, Proposed local/peer: 15/15 Hello flags: none Neighbor types: discovered Address Interface Label space ID Hold time fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 14 Transport address: 2001:db8::2, Transport preference: IPv6, Configuration sequence: 10 Up for 00:04:35 Reference count: 1 Hold time: 15, Proposed local/peer: 15/15 Hello flags: none Neighbor types: discovered
Bedeutung
Die Ausgabe zeigt LDP-Nachbarinformationen von IPv4- und IPv6-Adressen an.
Überprüfen der LDP-Sitzungsinformationen
Zweck
LDP-Sitzungsinformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 aus dem Betriebsmodus die Befehle ausshow ldp session extensive
, um LDP-Sitzungsinformationen show ldp session
anzuzeigen.
user@R1>show ldp session
session Address State Connection Hold time Adv. Mode 2001:db8::2 Operational Open 20 DU user@R1>show ldp session extensive
Address: 2001:db8::2, State: Operational, Connection: Open, Hold time: 29 Session ID: 10.255.0.1:0--10.255.0.2:0 Next keepalive in 9 seconds Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 Neighbor types: discovered Keepalive interval: 10, Connect retry interval: 1 Local address: 2001:db8::1, Remote address: 2001:db8::2 Up for 00:05:31 Capabilities advertised: none Capabilities received: none Protection: disabled Session flags: none Local - Restart: disabled, Helper mode: enabled Remote - Restart: disabled, Helper mode: enabled Local maximum neighbor reconnect time: 120000 msec Local maximum neighbor recovery time: 240000 msec Local Label Advertisement mode: Downstream unsolicited Remote Label Advertisement mode: Downstream unsolicited Negotiated Label Advertisement mode: Downstream unsolicited MTU discovery: disabled Nonstop routing state: Not in sync Next-hop addresses received: 10.255.0.2 192.168.12.2 2001:db8::2 fe80::21f:1200:cb6:4c8d Queue depth: 0 Message type Total Last 5 seconds Sent Received Sent Received Initialization 1 1 0 0 Keepalive 34 34 0 0 Notification 0 0 0 0 Address 1 1 0 0 Address withdraw 0 0 0 0 Label mapping 3 3 0 0 Label request 0 0 0 0 Label withdraw 0 0 0 0 Label release 0 0 0 0 Label abort 0 0 0 0
Bedeutung
Die Ausgabe zeigt Informationen für die LDP-Sitzung an, die IPv6 als TCP-Transport verwenden.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der LDP-Nachbarinformationen
Zweck
LDP-Nachbarinformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Nachbarinformationen show ldp neighbor extensive
anzuzeigen.
user@R1> show ldp neighbor extensive
Address Interface Label space ID Hold time
192.168.12.2 ge-1/0/0.0 10.255.0.2:0 14
Transport address: 10.255.0.2, Transport preference: IPv4, Configuration sequence: 9
Up for 00:00:14
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Address Interface Label space ID Hold time
fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 14
Transport address: 2001:db8::2, Transport preference: IPv4, Configuration sequence: 9
Up for 00:00:14
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Bedeutung
Die Ausgabe zeigt LDP-Nachbarinformationen für die IPv4- und IPv6-Adressen an.
Überprüfen der LDP-Sitzungsinformationen
Zweck
LDP-Sitzungsinformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Sitzungsinformationen show ldp session extensive
anzuzeigen.
user@R1> show ldp session extensive
Address: 10.255.0.2, State: Operational, Connection: Open, Hold time: 24
Session ID: 10.255.0.1:0--10.255.0.2:0
Next keepalive in 4 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 2
Neighbor types: discovered
Keepalive interval: 10, Connect retry interval: 1
Local address: 10.255.0.1, Remote address: 10.255.0.2
Up for 00:05:26
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
10.255.0.2
192.168.12.2
2001:db8::2
fe80::21f:1200:cb6:4c8d
Queue depth: 0
Message type Total Last 5 seconds
Sent Received Sent Received
Initialization 1 1 0 0
Keepalive 33 33 1 1
Notification 0 0 0 0
Address 2 2 0 0
Address withdraw 0 0 0 0
Label mapping 6 6 0 0
Label request 0 0 0 0
Label withdraw 0 0 0 0
Label release 0 0 0 0
Label abort 0 0 0 0
Bedeutung
Die Ausgabe zeigt Informationen für die LDP-Sitzung an, die IPv6 als TCP-Transport verwenden.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der LDP-Nachbarinformationen
Zweck
LDP-Nachbarinformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Nachbarinformationen show ldp neighbor extensive
anzuzeigen.
user@R1> show ldp neighbor extensive
Address Interface Label space ID Hold time
192.168.12.2 ge-1/0/0.0 10.255.0.2:0 11
Transport address: 10.255.0.2, Configuration sequence: 10
Up for 00:04:35
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Address Interface Label space ID Hold time
fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 14
Transport address: 2001:db8::2, Configuration sequence: 10
Up for 00:04:35
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Bedeutung
Die Ausgabe zeigt LDP-Nachbarinformationen für die IPv4- und IPv6-Adressen an.
Überprüfen der LDP-Sitzungsinformationen
Zweck
LDP-Sitzungsinformationen anzeigen.
Aktion
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Nachbarinformationen show ldp session extensive
anzuzeigen.
user@R1> show ldp session extensive
Address: 2001:db8::2, State: Operational, Connection: Open, Hold time: 29
Session ID: 1.1.1.1:0--10.255.0.2:0
Next keepalive in 9 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: discovered
Keepalive interval: 10, Connect retry interval: 1
Local address: 2001:db8::1, Remote address: 2001:db8::2
Up for 00:05:31
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
2001:db8::2
fe80::21f:1200:cb6:4c8d
Queue depth: 0
Message type Total Last 5 seconds
Sent Received Sent Received
Initialization 1 1 0 0
Keepalive 34 34 0 0
Notification 0 0 0 0
Address 1 1 0 0
Address withdraw 0 0 0 0
Label mapping 3 3 0 0
Label request 0 0 0 0
Label withdraw 0 0 0 0
Label release 0 0 0 0
Label abort 0 0 0 0
Address: 10.255.0.2, State: Operational, Connection: Open, Hold time: 29
Session ID: 10.255.0.1:0--10.255.0.2:0
Next keepalive in 9 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: discovered
Keepalive interval: 10, Connect retry interval: 1
Local address: 10.255.0.1, Remote address: 10.255.0.2
Up for 00:05:31
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
10.255.0.2
192.168.12.2
Queue depth: 0
Message type Total Last 5 seconds
Sent Received Sent Received
Initialization 1 1 0 0
Keepalive 34 34 0 0
Notification 0 0 0 0
Address 1 1 0 0
Address withdraw 0 0 0 0
Label mapping 3 3 0 0
Label request 0 0 0 0
Label withdraw 0 0 0 0
Label release 0 0 0 0
Label abort 0 0 0 0
Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalübertragung für Point-to-Multipoint-LSPs
- Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs
- Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalübertragung für Point-to-Multipoint-LSPs
Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs
Das Multipoint Label Distribution Protocol (M-LDP) für Point-to-Multipoint Label Switched Paths (LSPs) mit In-Band-Signalübertragung ist nützlich in einer Bereitstellung mit einem vorhandenen IP/MPLS-Backbone, in dem Sie Multicast-Datenverkehr für IPTV übertragen müssen.
Seit Jahren ist die am häufigsten verwendete Lösung für die Übertragung von Multicast-Datenverkehr die Verwendung von nativem IP-Multicast im Core des Dienstanbieters mit Multipoint-IP-Tunneling zur Isolierung des Kundendatenverkehrs. Zur Einrichtung der Weiterleitungspfade wird ein Multicast-Routing-Protokoll bereitgestellt, das üblicherweise Protocol Independent Multicast (PIM) ist. IP-Multicast-Routing wird für die Weiterleitung mit PIM-Signalen im Core verwendet. Damit dieses Modell funktioniert, muss das Core-Netzwerk Multicast-fähig sein. Dies ermöglicht effektive und stabile Bereitstellungen auch in interautonome System (AS)-Szenarien.
In einem vorhandenen IP/MPLS-Netzwerk ist die Bereitstellung von PIM jedoch möglicherweise nicht die erste Wahl. Einige Dienstanbieter sind daran interessiert, IP-Tunneling durch MPLS-Label-Einkapselung zu ersetzen. Die Motivation für den Wechsel zu MPLS-Label-Switching besteht darin, MPLS Traffic Engineering- und Schutzfunktionen zu nutzen und den Kontrolldatenverkehr-Overhead im Provider-Core zu reduzieren.
Um dies zu erreichen, sind Service Provider daran interessiert, die Erweiterung der vorhandenen Bereitstellungen zu nutzen, um die Weitergabe von Multicast-Datenverkehr zu ermöglichen. Die vorhandenen Multicast-Erweiterungen für IP/MPLS sind Point-to-Multipoint-Erweiterungen für RSVP-TE und Point-to-Multipoint- und Multipoint-to-Multipoint-Erweiterungen für LDP. Diese Implementierungsszenarien werden in RFC 6826, Multipoint LDP In-Band Signaling für Point-to-Multipoint und Multipoint-to-Multipoint Label Switched Paths erörtert. Diese Funktionsübersicht beschränkt sich auf Point-to-Multipoint-Erweiterungen für LDP.
- Funktionsweise von M-LDP
- Terminologie
- Ingress Join Translation und Pseudo Interface Handling
- Ingress Splicing
- Reverse Path Forwarding
- LSP-Root-Erkennung
- Egress Join Translation und Pseudo Interface Handling
- Ausgangs-Splicing
- Unterstützte Funktionen
- Nicht unterstützte Funktionen
- LDP-Funktionalität
- Egress LER-Funktionalität
- Transit-LSR-Funktionalität
- Eingangs-LER-Funktionalität
Funktionsweise von M-LDP
- Label-Bindungen in M-LDP-Signalübertragung
- M-LDP in PIM-freiem MPLS-Core
- M-LDP im PIM-fähigen MPLS-Core
Label-Bindungen in M-LDP-Signalübertragung
Die Multipoint-Erweiterung zu LDP verwendet Elemente der Point-to-Multipoint- und Multipoint-to-Multipoint-Forwarding Equivalence Class (FEC) (definiert in RFC 5036, LDP-Spezifikation) zusammen mit Funktionen, Label-Mapping und Signalübertragungsverfahren. Die FEC-Elemente umfassen die Idee des LSP-Stamms, bei dem es sich um eine IP-Adresse handelt, und einen "intransparenten" Wert, bei dem es sich um einen Selektor handelt, der die Leaf-Knoten mit dem gleichen undurchsichtigen Wert gruppiert. Der undurchsichtige Wert ist für die Zwischenknoten transparent, hat aber eine Bedeutung für den LSP-Stamm. Jeder LDP-Knoten gibt die Bindung des lokalen eingehenden Labels an den Upstream-LDP-Knoten auf dem kürzesten Pfad zur im FEC gefundenen Root-IP-Adresse an. Der Upstream-Knoten, der die Labelbindungen empfängt, erstellt eigene lokale Label- und ausgehende Schnittstellen. Dieser Prozess der Labelzuweisung kann zur Paketreplikation führen, wenn mehrere ausgehende Zweigstellen vorhanden sind. Wie in Abbildung 18dargestellt, führt ein LDP-Knoten die Labelbindungen für den gleichen opaken Wert zusammen, wenn er findet, dass downstream-Knoten den gleichen Upstream-Knoten teilen. Dies ermöglicht den effektiven Aufbau von Point-to-Multipoint-LSPs und die Kennzeichnungskonservierung.

M-LDP in PIM-freiem MPLS-Core
Abbildung 19 zeigt ein herunterskaliertes Bereitstellungsszenario. Zwei separate PIM-Domänen werden über einen PIM-freien Core-Standort miteinander verbunden. Die Randrouter an diesem Core-Standort unterstützen PIM an den Randschnittstellen. Darüber hinaus erfassen und verteilen diese Randrouter die Routing-Informationen von den benachbarten Standorten zum Kernnetzwerk. Die Edge-Router in Site C führen BGP für die Erkennung von Root-Knoten aus. Interior Gateway Protocol (IGP)-Routen können nicht für die Eingangserkennung verwendet werden, da in den meisten Fällen die vom IGP bereitgestellte Weiterleitung des nächsten Hops keine Informationen über das Eingangsgerät zur Quelle liefert. M-LDP-Inband-Signalübertragung verfügt über eine One-to-One-Zuordnung zwischen dem Point-to-Multipoint-LSP und dem (S,G)-Fluss. Bei In-Band-Signalübertragung werden PIM-Nachrichten direkt in M-LDP FEC-Bindungen übersetzt. Out-of-Band-Signalübertragung hingegen basiert auf manueller Konfiguration. Eine Anwendung für M-LDP-Inband-Signalübertragung ist das Übertragen von IPTV-Multicast-Datenverkehr in einem MPLS-Backbone.

Konfiguration
Die Konfigurationsanweisung mldp-inband-signalling
auf dem Label-Edge-Router (LER) ermöglicht ES PIM, M-LDP-In-Band-Signalübertragung für die upstreamen Nachbarn zu verwenden, wenn der LER keinen PIM-Upstream-Nachbarn erkennt. Die statische Konfiguration des MPLS-LSP-Stamms ist mithilfe von Richtlinie in der PIM-Konfiguration enthalten. Dies ist erforderlich, wenn IBGP nicht am Core-Standort verfügbar ist oder ibgp-basierte LSP-Root-Erkennung außer Kraft setzt.
Zum Beispiel:
protocols { pim { mldp-inband-signalling { policy lsp-mapping-policy-example; } } }
policy-options { policy-statement lsp-mapping-policy-example { term channel1 { from { source-address-filter ip-prefix</prefix-length>; #policy filter for channel1 } then { p2mp-lsp-root { # Statically configured ingress address of edge # used by channel1 address ip-address; } accept; } } } }
M-LDP im PIM-fähigen MPLS-Core
Um vorhandene IPTV-Dienste von nativem IP-Multicast zu MPLS-Multicast zu migrieren, müssen Sie ab Junos OS Version 14.1 einen reibungslosen Übergang von PIM zu M-LDP Point-to-Multipoint-LSPs mit minimalem Ausfall durchführen. Abbildung 20 zeigt eine ähnliche M-LDP-Topologie wie Abbildung 19, aber mit einem anderen Szenario. Der Core ist mit PIM aktiviert, wobei alle IPTV-Kanäle über eine Quelle gestreamt werden. Die TV-Kanäle werden als ASM-Streams gesendet, wobei jeder Kanal anhand seiner Gruppenadresse identifiziert wird. Zuvor wurden diese Kanäle als IP-Streams auf dem Core gestreamt und mitHILFE von PIM signalisiert.

Durch die Konfiguration der In diesem Szenario wird die mldp-inband-signaling
M-LDP-Signalübertragung nur initiiert, wenn kein PIM-Nachbar zur Quelle vorhanden ist. Da jedoch immer ein PIM-Nachbar zur Quelle hin vorhanden ist, es sei denn, piM ist an den vorgeschalteten Schnittstellen des Ausgangs-PE deaktiviert, hat PIM Vorrang vor M-LDP und M-LDP greift nicht.
Konfiguration
Um Kanal für Kanal schrittweise zu M-LDP MPLS-Core zu migrieren, wobei nur wenige Streams mit M-LDP Upstream und andere Streams mit vorhandenem PIM Upstream verwendet werden, fügen Sie die selected-mldp-egress
Konfigurationsanweisung zusammen mit gruppenbasierten Filtern in den Richtlinienfilter für M-LDP-Inband-Signalübertragung ein.
Der Inband-Signalisierungsrichtlinienfilter M-LDP kann entweder die source-address-filter
Anweisung oder die route-filter
Anweisung oder eine Kombination aus beidem enthalten.
Zum Beispiel:
protocols { pim { mldp-inband-signalling { policy lsp-mapping-policy-example; } } }
policy-options { policy-statement lsp-mapping-policy-example { term channel1 { from { source-address-filter ip-prefix</prefix-length>; #policy filter for channel1 } then { selected-mldp-egress; accept; } } term channel2 { from { source-address-filter ip-prefix</prefix-length>; #policy filter for channel2 route-filter ip-prefix</prefix-length>; #policy filter on multicast group address } then { selected-mldp-egress; p2mp-lsp-root { # Statically configured ingress address of edge # used by channel2 address ip-address; } accept; } } term channel3 { from { route-filter ip-prefix</prefix-length>; #policy filter on multicast group address } then { selected-mldp-egress; accept; } } } }
Einige der Einschränkungen der oben genannten Konfiguration sind wie folgt:
Die
selected-mldp-egress
Anweisung sollte nur auf dem LER konfiguriert werden. Die Konfiguration der Anweisung auf nicht ausgehenden PIM-Routern kann zu Ausfällen bei derselected-mldp-egress
Pfadeinrichtung führen.Wenn Richtlinienänderungen vorgenommen werden, um den Datenverkehr von PIM upstream auf M-LDP upstream und umgekehrt umzustellen, kann mit Paketverlusten gerechnet werden, wenn der Break-and-Make-Mechanismus auf der Steuerungsebene durchgeführt wird.
Terminologie
Die folgenden Begriffe sind wichtig für ein Verständnis der M-LDP-In-Band-Signalübertragung für Multicast-Datenverkehr.
Punkt-zu-Punkt-LSP | Ein LSP mit einem Ingress Label Switched Router (LSR) und einem Ausgangs-LSR. |
Multipoint-LSP | Entweder ein Point-to-Multipoint- oder ein Multipoint-to-Multipoint-LSP. |
Point-to-Multipoint-LSP | Ein LSP mit einer Eingangs-LSR und einem oder mehreren Ausgangs-LSRs. |
Multipoint-to-Point-LSP | Ein LSP mit einem oder mehreren eingehenden LSRs und einer einzigartigen Ausgangs-LSR. |
Multipoint-to-Multipoint-LSP | Ein LSP, der eine Reihe von Knoten verbindet, sodass der Datenverkehr, der von jedem Knoten im LSP gesendet wird, an alle anderen weitergeleitet wird. |
Eingangs-LSR | Ein Eingangs-LSR für einen bestimmten LSP ist ein LSR, der ein Datenpaket entlang des LSP senden kann. Multipoint-zu-Multipoint-LSPs können über mehrere Eingangs-LSRs verfügen. Point-to-Multipoint-LSPs haben nur einen, und dieser Knoten wird oft als Stammknoten bezeichnet. |
Ausgangs-LSR | Ein Ausgangs-LSR für einen bestimmten LSP ist ein LSR, der ein Datenpaket aus diesem LSP zur weiteren Verarbeitung entfernen kann. Point-to-Point- und Multipoint-to-Point-LSPs haben nur einen einzigen Ausgangsknoten. Point-to-Multipoint- und Multipoint-to-Multipoint-LSPs können über mehrere Ausgangsknoten verfügen. |
Transit-LSR | Eine LSR, die über eine direkt angebundene Upstream-LSR und eine oder mehrere direkt verbundene Downstream-LSRs zum Stamm des Multipoint-LSP erreichbar ist. |
Bud LSR | Ein LSR, der ein Ausgang ist, aber auch über einen oder mehrere direkt nachgeschaltete LSRs verfügt. |
Leaf-Knoten | Entweder ein Ausgangs- oder Bud-LSR im Kontext eines Point-to-Multipoint-LSP. Im Kontext eines Multipoint-to-Multipoint-LSP ist eine LSR sowohl ingress als auch egress für das gleiche Multipoint-to-Multipoint-LSP und kann auch eine Bud-LSR sein. |
Ingress Join Translation und Pseudo Interface Handling
Am Eingangs-LER benachrichtigt LDP PIM über die (S,G)-Nachrichten, die über die In-Band-Signalübertragung empfangen werden. PIM verknüpft jede (S,G)-Nachrichtmit einer Pseudoschnittstelle. Anschließend wird eine Join-Nachricht mit dem kürzesten Pfadbaum (SPT) in Richtung Quelle eingeleitet. PIM behandelt dies als eine neue Art von lokalem Empfänger. Wenn der LSP heruntergerissen wird, entfernt PIM diesen lokalen Empfänger basierend auf der Benachrichtigung aus LDP.
Ingress Splicing
LDP bietet PIM einen nächsten Hop, der jedem (S,G)-Eintrag zugeordnet werden soll. PIM installiert eine PIM(S,G)-Multicastroute mit dem LDP Next Hop und anderen PIM-Empfängern. Der nächste Hop ist ein zusammengesetzter nächster Hop aus lokalen Empfängern , der Liste der PIM-Downstream-Nachbarn + ein nächster Hop auf Unterebenefür den LDP-Tunnel.
Reverse Path Forwarding
Die Reverse Path Forwarding (RPF)-Berechnung von PIM wird am Ausgangsknoten durchgeführt.
PIM führt M-LDP-In-Band-Signalübertragung durch, wenn alle folgenden Bedingungen zutreffen:
Es gibt keine PIM-Nachbarn in Richtung Quelle.
Die M-LDP-In-Band-Signalisierungsaussage ist konfiguriert.
Der nächste Hop wird durch BGP gelernt oder ist in der statischen Zuordnung vorhanden (angegeben in einer M-LDP-In-Band-Signalisierungsrichtlinie).
Andernfalls behält PIM bei einem Ausfall der LSP-Root-Erkennung den (S,G)-Eintrag mit dem RPF-Status "Ungelöst" bei.
PIM RPF registriert diese Quelladresse bei jeder Änderung der Unicast-Routing-Informationen. Wenn sich die Route zur Quelle ändert, wird die RPF-Neuberechnung erneut durchgeführt. Auch die nächsten Hops des BGP-Protokolls in Richtung Quelle werden auf Änderungen im LSP-Stamm überwacht. Solche Änderungen können für kurze Zeit zu Unterbrechungen des Datenverkehrs führen.
LSP-Root-Erkennung
Wenn der RPF-Betrieb den Bedarf an M-LDP-In-Band-Signalübertragung upstream erkennt, wird der LSP-Stamm (Ingress) erkannt. Dieser Stamm ist ein Parameter für LDP-LSP-Signalübertragung.
Der Stammknoten wird wie folgt erkannt:
Wenn die vorhandene statische Konfiguration die Quelladresse angibt, wird der Stamm wie in der Konfiguration angegeben genommen.
Eine Suche wird in der Unicast-Routingtabelle durchgeführt. Wenn die Quelladresse gefunden wird, wird das Protokoll als nächster Hop zur Quelle als LSP-Root verwendet.
Vor Junos OS Version 16.1 wird M-LDP Point-to-Multipoint-LSP über die Root-Adresse der Eingangs-LSR von einem Ausgang zum Eingang signalisiert. Diese Root-Adresse ist nur über IGP erreichbar und beschränkt den M-LDP-Point-to-Multipoint-LSP auf ein einziges autonomes System. Wenn die Root-Adresse nicht über ein IGP erreichbar, aber über BGP erreichbar ist und wenn diese BGP-Route rekursiv über einen MPLS-LSP aufgelöst wird, wird der Point-to-Multipoint-LSP von diesem Punkt aus nicht weiter in Richtung der Eingangs-LSR-Root-Adresse signalisiert.
Es ist erforderlich, dass diese nicht segmentierten Punkt-zu-Multipoint-LSPs über mehrere autonome Systeme signalisiert werden, die für die folgenden Anwendungen verwendet werden können:
Inter-AS MVPN mit nicht segmentierten Point-to-Multipoint-LSPs.
Inter-AS M-LDP-Inband-Signalübertragung zwischen Client-Netzwerken, die über ein MPLS-Core-Netzwerk verbunden sind.
Inter-Area MVPN- oder M-LDP-Inband-Signalübertragung mit nicht segmentierten Point-to-Multipoint-LSPs (nahtloser MPLS-Multicast).
M-LDP kann ab Junos OS Version 16.1 Point-to-Multipoint-LSPs bei ASBR oder transit oder egress signalisieren, wenn die Stammadresse eine BGP-Route ist, die weiter rekursiv über ein MPLS-LSP aufgelöst wird.
Egress Join Translation und Pseudo Interface Handling
Am Ausgangs-LER benachrichtigt PIM die LDP-Meldung der (S,G)-Nachricht, die zusammen mit dem LSP-Stamm signalisiert werden soll. PIM erstellt eine Pseudoschnittstelle als Upstream-Schnittstelle für diese (S,G)-Nachricht. Wenn eine (S,G)-Prune-Nachricht empfangen wird, wird diese Zuordnung entfernt.
Ausgangs-Splicing
Am Ausgangsknoten des Core-Netzwerks, wo die Join-Nachricht (S,G) vom Downstream-Standort empfangen wird, wird diese Join-Nachricht in M-LDP-In-Band-Signalparameter übersetzt und LDP wird benachrichtigt. Darüber hinaus erfolgt der LSP-Teardown, wenn der Eintrag (S,G) verloren geht, sich der LSP-Stamm ändert oder wenn der Eintrag (S,G) über einen PIM-Nachbarn erreichbar ist.
Unterstützte Funktionen
Für M-LDP-In-Band-Signalübertragung unterstützt Junos OS die folgenden Funktionen:
Egress-Splicing des PIM Next Hop mit der LDP-Route
Ingress-Splicing der PIM-Route mit dem LDP Next Hop
Übersetzung von PIM-Join-Nachrichten zu LDP-Point-to-Multipoint-LSP-Setupparametern
Übersetzung von M-LDP-In-Band-LSP-Parametern zur Einrichtung von PIM-Join-Nachrichten
Statisch konfigurierte und BGP-Protokoll next Hop-basierte LSP-Root-Erkennung
PIM-Zustände (S,G) im PIM Source-Specific Multicast (SSM) und Anysource Multicsast (ASM)-Bereich
Konfigurationsanweisungen zu Ingress- und Egress-LERs, damit diese als Edge-Router fungieren können
IGMP-Join-Nachrichten auf LERs
IPv6-Quell- und Gruppenadresse als intransparente Informationen zu einem IPv4-Stammknoten tragen
Statische Konfiguration zur Zuordnung eines IPv6 (S,G) zu einer IPv4-Stammadresse
Nicht unterstützte Funktionen
Für M-LDP-In-Band-Signalübertragung unterstützt Junos OS die folgenden Funktionen nicht :
Vollständige Unterstützung für PIM-ASM
Der
mpls lsp point-to-multipoint ping
Befehl mit einer (S,G)-OptionNonstop Active Routing (NSR)
Make-before-Break (MBB) für PIM
IPv6-LSP-Root-Adressen (LDP unterstützt IPv6-LSPs nicht.)
Nachbarbeziehung zwischen PIM-Lautsprechern, die nicht direkt verbunden sind
Graceful-Restart
PIM-Dense Mode
PIM bidirektionaler Modus
LDP-Funktionalität
Die PIM(S,G)-Informationen werden als M-LDP opaque Type-Length-Value (TLV)-Codierungen übertragen. Das Point-to-Multipoint-FEC-Element besteht aus der Root-Node-Adresse. Bei Multicast-VPNs der nächsten Generation (NGEN-MVPNs) wird der Point-to-Multipoint-LSP durch die Stammknotenadresse und die LSP-ID identifiziert.
Egress LER-Funktionalität
Auf dem Ausgangs-LER löst PIM LDP mit den folgenden Informationen aus, um einen Point-to-Multipoint-LSP zu erstellen:
Stammknoten
(S,G)
Nächster Hop
PIM findet den Stammknoten basierend auf der Quelle des Multicast-Tree. Wenn die Stammadresse für diesen (S,G)-Eintrag konfiguriert ist, wird die konfigurierte Adresse als Point-to-Multipoint-LSP-Root verwendet. Andernfalls wird die Routing-Tabelle verwendet, um die Route zur Quelle zu suchen. Wenn es sich bei der Route zur Quelle des Multicast-Tree um eine BGP-erlernte Route handelt, ruft PIM die BGP Next Hop-Adresse ab und verwendet sie als Stammknoten für den Point-to-Multipoint-LSP.
LDP findet den Upstream-Knoten basierend auf dem Stammknoten, weist ein Label zu und sendet die Labelzuordnung an den Upstream-Knoten. LDP verwendet kein vorletztes Hop Popping (PHP) für in-Band-M-LDP-Signalübertragung.
Wenn sich die Stammadressen für die Quelle des Multicastbaums ändern, löscht PIM den Point-to-Multipoint-LSP und löst LDP aus, um einen neuen Point-to-Multipoint-LSP zu erstellen. In diesem Fall wird die Ausgangsschnittstellenliste zu NULL, PIM löst LDP aus, um den Point-to-Multipoint-LSP zu löschen, und LDP sendet eine Label-Rückzugsnachricht an den Upstream-Knoten.
Transit-LSR-Funktionalität
Die Transit-LSR gibt ein Label an die vorgeschaltete LSR zur Quelle des Point-to-Multipoint-FEC an und installiert den erforderlichen Weiterleitungsstatus, um die Pakete weiterzuleiten. Der Transit-LSR kann jeder M-LDP-fähige Router sein.
Eingangs-LER-Funktionalität
Auf dem Eingangs-LER stellt LDP PIM nach Erhalt der Labelzuordnung folgende Informationen zur Verfügung:
(S,G)
Flood Next Hop
Dann installiert PIM den Weiterleitungsstatus. Wenn die neuen Zweigstellen hinzugefügt oder gelöscht werden, wird der flood next hop entsprechend aktualisiert. Wenn alle Zweigstellen aufgrund des Entfernens eines Labels gelöscht werden, sendet LDP aktualisierte Informationen an PIM. Wenn es mehrere Verbindungen zwischen den vor- und nachgeschalteten Nachbarn gibt, ist der Punkt-zu-Multipoint-LSP nicht lastausgleichend.
Siehe auch
Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalübertragung für Point-to-Multipoint-LSPs
In diesem Beispiel wird gezeigt, wie Multipoint LDP (M-LDP)-In-Band-Signalübertragung für Multicast-Datenverkehr, als Erweiterung des Protokolls Protocol Independent Multicast (PIM) oder als Ersatz für PIM konfiguriert wird.
Anforderungen
Dieses Beispiel kann mithilfe der folgenden Hardware- und Softwarekomponenten konfiguriert werden:
Junos OS Version 13.2 oder höher
Universelle 5G-Routing-Plattformen der MX-Serie oder Multiservice Edge-Router der M-Serie für Provider Edge -Router (PE)
Paketübertragungs-Router der PTX-Serie, die als Transit Label Switched Router fungieren
Core-Router der T-Serie für Core-Router
Die PE-Router könnten auch Core-Router der T-Serie sein, aber das ist nicht typisch. Je nach Skalierungsanforderungen können die Core-Router auch universelle 5G-Routing-Plattformen der MX-Serie oder Multiservice Edge-Router der M-Serie sein. Kunden-Edge-Geräte (CE) können andere Router oder Switches von Juniper Networks oder einem anderen Anbieter sein.
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration über die Geräte initialisierung hinaus erforderlich.
Überblick
CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 21an. Der Abschnitt #d158e60__d158e616 beschreibt die Schritte auf Geräte-EgressPE.

Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie auf Hierarchieebene in die [edit]
CLI ein.
Gerät src1
set logical-systems src1 interfaces fe-1/2/0 unit 0 family inet address 1.2.7.7/24 set logical-systems src1 interfaces lo0 unit 0 family inet address 1.1.1.7/32 set logical-systems src1 protocols ospf area 0.0.0.0 interface all
GeräteingressPE
set interfaces so-0/1/2 unit 0 family inet address 192.168.93.9/28 set interfaces fe-1/2/0 unit 0 family inet address 1.2.3.2/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 1.2.5.2/24 set interfaces fe-1/2/2 unit 0 family inet address 1.2.6.2/24 set interfaces fe-1/2/2 unit 0 family mpls set interfaces fe-1/2/3 unit 0 family inet address 1.2.7.2/24 set interfaces fe-1/3/1 unit 0 family inet address 192.168.219.9/28 set interfaces lo0 unit 0 family inet address 1.1.1.2/32 set protocols igmp interface fe-1/2/1.0 version 3 set protocols igmp interface fe-1/2/1.0 static group 232.1.1.1 source 192.168.219.11 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 1.1.1.2 set protocols bgp group ibgp family inet any set protocols bgp group ibgp family inet-vpn any set protocols bgp group ibgp neighbor 1.1.1.3 set protocols bgp group ibgp neighbor 1.1.1.4 set protocols bgp group ibgp neighbor 1.1.1.1 set protocols ospf area 0.0.0.0 interface all set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/2.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim rp static address 1.1.1.5 set protocols pim interface fe-1/3/1.0 set protocols pim interface lo0.0 set protocols pim interface fe-1/2/0.21 set protocols pim interface fe-1/2/3.0 set protocols pim interface fe-1/2/1.0 set protocols pim interface so-0/1/2.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.1.7/32 orlonger set policy-options policy-statement mldppim-ex term A from source-address-filter 1.2.7.0/24 orlonger set policy-options policy-statement mldppim-ex term A then accept set routing-options autonomous-system 64510
Geräte-Ausgangs-PE
set interfaces so-0/1/3 unit 0 point-to-point set interfaces so-0/1/3 unit 0 family inet address 192.168.92.9/28 set interfaces fe-1/2/0 unit 0 family inet address 1.1.3.1/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 1.1.4.1/24 set interfaces fe-1/2/2 unit 0 family inet address 1.1.6.1/24 set interfaces fe-1/2/2 unit 0 family mpls set interfaces fe-1/3/0 unit 0 family inet address 192.168.209.9/28 set interfaces lo0 unit 0 family inet address 1.1.1.1/32 set routing-options autonomous-system 64510 set protocols igmp interface fe-1/3/0.0 version 3 set protocols igmp interface fe-1/3/0.0 static group 232.1.1.1 group-count 3 set protocols igmp interface fe-1/3/0.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface fe-1/3/0.0 static group 227.1.1.1 set protocols igmp interface so-0/1/3.0 version 3 set protocols igmp interface so-0/1/3.0 static group 232.1.1.1 group-count 2 set protocols igmp interface so-0/1/3.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface so-0/1/3.0 static group 232.2.2.2 source 1.2.7.7 set protocols mpls interface fe-1/2/0.0 set protocols mpls interface fe-1/2/2.0 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 1.1.1.1 set protocols bgp group ibgp family inet any set protocols bgp group ibgp neighbor 1.1.1.2 set protocols msdp local-address 1.1.1.1 set protocols msdp peer 1.1.1.5 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/2.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim rp local address 1.1.1.1 set protocols pim rp local group-ranges 227.0.0.0/8 set protocols pim rp static address 1.1.1.4 set protocols pim rp static address 1.2.7.7 group-ranges 226.0.0.0/8 set protocols pim interface lo0.0 set protocols pim interface fe-1/3/0.0 set protocols pim interface fe-1/2/0.0 set protocols pim interface fe-1/2/1.0 set protocols pim interface so-0/1/3.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 1.2.7.0/24 orlonger set policy-options policy-statement mldppim-ex term A then accept
Gerät p6
set interfaces fe-1/2/0 unit 0 family inet address 1.1.6.6/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 1.2.6.6/24 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.6/32 set interfaces lo0 unit 0 family mpls set protocols ospf area 0.0.0.0 interface all set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/1.0 set protocols ldp interface lo0.0 set protocols ldp p2mp
Gerät pr3
set interfaces ge-0/3/1 unit 0 family inet address 192.168.215.9/28 set interfaces fe-1/2/0 unit 0 family inet address 1.1.3.3/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 1.2.3.3/24 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 1.1.1.3/32 set protocols igmp interface ge-0/3/1.0 version 3 set protocols igmp interface ge-0/3/1.0 static group 232.1.1.2 source 192.168.219.11 set protocols igmp interface ge-0/3/1.0 static group 232.2.2.2 source 1.2.7.7 set protocols bgp group ibgp local-address 1.1.1.3 set protocols bgp group ibgp type internal set protocols bgp group ibgp neighbor 1.1.1.2 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 2 set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/1.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface fe-0/3/1.0 set protocols pim interface lo0.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 1.2.7.7/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 64510
Gerät pr4
set interfaces ge-0/3/0 unit 0 family inet address 192.168.207.9/28 set interfaces fe-1/2/0 unit 0 family inet address 1.1.4.4/24 set interfaces fe-1/2/0 unit 0 family iso set interfaces lo0 unit 0 family inet address 1.1.1.4/32 set protocols igmp interface ge-0/3/0.0 version 3 set protocols igmp interface ge-0/3/0.0 static group 232.1.1.2 source 192.168.219.11 set protocols igmp interface ge-0/3/0.0 static group 225.1.1.1 set protocols bgp group ibgp local-address 1.1.1.4 set protocols bgp group ibgp type internal set protocols bgp group ibgp neighbor 1.1.1.2 set protocols msdp local-address 1.1.1.4 set protocols msdp peer 1.1.1.5 set protocols ospf area 0.0.0.0 interface all set protocols pim rp local address 1.1.1.4 set protocols pim interface ge-0/3/0.0 set protocols pim interface lo0.0 set protocols pim interface fe-1/2/0.0 set routing-options autonomous-system 64510
Gerät pr5
set interfaces fe-1/2/0 unit 0 family inet address 1.2.5.5/24 set interfaces lo0 unit 0 family inet address 1.1.1.5/24 set protocols igmp interface lo0.0 version 3 set protocols igmp interface lo0.0 static group 232.1.1.1 source 192.168.219.11 set protocols msdp local-address 1.1.1.5 set protocols msdp peer 1.1.1.4 set protocols msdp peer 1.1.1.1 set protocols ospf area 0.0.0.0 interface all set protocols pim rp local address 1.1.1.5 set protocols pim interface all
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So konfigurieren Sie Geräte-Ausgangs-PE:
Konfigurieren Sie die Schnittstellen.
Aktivieren Sie MPLS an den Core-Schnittstellen. Bei den ausgangsnächsten Hops müssen Sie MPLS nicht aktivieren.
[edit interfaces] user@EgressPE# set fe-1/2/0 unit 0 family inet address 1.1.3.1/24 user@EgressPE# set fe-1/2/0 unit 0 family mpls user@EgressPE# set fe-1/2/2 unit 0 family inet address 1.1.6.1/24 user@EgressPE# set fe-1/2/2 unit 0 family mpls user@EgressPE# set so-0/1/3 unit 0 point-to-point user@EgressPE# set so-0/1/3 unit 0 family inet address 192.168.92.9/28 user@EgressPE# set fe-1/2/1 unit 0 family inet address 1.1.4.1/24 user@EgressPE# set fe-1/3/0 unit 0 family inet address 192.168.209.9/28 user@EgressPE# set lo0 unit 0 family inet address 1.1.1.1/32
Konfigurieren Sie IGMP an den Ausgangsschnittstellen.
Zu Testzwecken enthält dieses Beispiel statische Gruppen- und Quelladressen.
[edit protocols igmp] user@EgressPE# set interface fe-1/3/0.0 version 3 user@EgressPE# set interface fe-1/3/0.0 static group 232.1.1.1 group-count 3 user@EgressPE# set interface fe-1/3/0.0 static group 232.1.1.1 source 192.168.219.11 user@EgressPE# set interface fe-1/3/0.0 static group 227.1.1.1 user@EgressPE# set interface so-0/1/3.0 version 3 user@EgressPE# set interface so-0/1/3.0 static group 232.1.1.1 group-count 2 user@EgressPE# set interface so-0/1/3.0 static group 232.1.1.1 source 192.168.219.11 user@EgressPE# set interface so-0/1/3.0 static group 232.2.2.2 source 1.2.7.7
Konfigurieren Sie MPLS an den Core-Schnittstellen.
[edit protocols mpls] user@EgressPE# set interface fe-1/2/0.0 user@EgressPE# set interface fe-1/2/2.0
Konfigurieren Sie BGP.
BGP ist ein richtliniengesteuertes Protokoll, das auch die erforderlichen Routing-Richtlinien konfiguriert und anwendet.
Sie könnten beispielsweise statische Routen in BGP exportieren.
[edit protocols bgp group ibgp] user@EgressPE# set type internal user@EgressPE# set local-address 1.1.1.1 user@EgressPE# set family inet any user@EgressPE# set neighbor 1.1.1.2
(Optional) Konfigurieren Sie eine MSDP-Peer-Verbindung mit Device pr5, um die unterschiedlichen PIM-Domänen zu verbinden und so redundante RPs zu ermöglichen.
[edit protocols msdp] user@EgressPE# set local-address 1.1.1.1 user@EgressPE# set peer 1.1.1.5
OSPF konfigurieren.
[edit protocols ospf area 0.0.0.0] user@EgressPE# set interface all user@EgressPE# set interface fxp0.0 disable
Konfigurieren Sie LDP an den Core-Schnittstellen und an der Loopback-Schnittstelle.
[edit protocols ldp] user@EgressPE# set interface fe-1/2/0.0 user@EgressPE# set interface fe-1/2/2.0 user@EgressPE# set interface lo0.0
Aktivieren Sie Point-to-Multipoint MPLS-LSPs.
[edit protocols ldp] user@EgressPE# set p2mp
Konfigurieren Sie PIM an den downstreamen Schnittstellen.
[edit protocols pim] user@EgressPE# set interface lo0.0 user@EgressPE# set interface fe-1/3/0.0 user@EgressPE# set interface fe-1/2/1.0 user@EgressPE# set interface so-0/1/3.0
Konfigurieren Sie die RP-Einstellungen, da dieses Gerät als PIM-Rendezvouspunkt (RP) dient.
[edit protocols pim] user@EgressPE# set rp local address 1.1.1.1 user@EgressPE# set rp local group-ranges 227.0.0.0/8 user@EgressPE# set rp static address 1.1.1.4 user@EgressPE# set rp static address 1.2.7.7 group-ranges 226.0.0.0/8
Aktivieren Sie M-LDP-In-Band-Signalübertragung und legen Sie die zugehörige Richtlinie fest.
[edit protocols pim] user@EgressPE# set mldp-inband-signalling policy mldppim-ex
Konfigurieren Sie die Routing-Richtlinie, die die Stammadresse für den Point-to-Multipoint-LSP und die zugehörigen Quelladressen angibt.
[edit policy-options policy-statement mldppim-ex] user@EgressPE# set term B from source-address-filter 192.168.0.0/24 orlonger user@EgressPE# set term B from source-address-filter 192.168.219.11/32 orlonger user@EgressPE# set term B then p2mp-lsp-root address 1.1.1.2 user@EgressPE# set term B then accept user@EgressPE# set term A from source-address-filter 1.2.7.0/24 orlonger user@EgressPE# set term A then accept
Konfigurieren Sie die autonome System-ID (AS).
[edit routing-options] user@EgressPE# set autonomous-system 64510
Ergebnisse
Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfaces
Befehle , , show protocols
show policy-options
undshow routing-options
. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
Geräte-Ausgangs-PE
user@EgressPE# show interfaces
so-0/1/3 {
unit 0 {
point-to-point;
family inet {
address 192.168.92.9/28;
}
}
}
fe-1/2/0 {
unit 0 {
family inet {
address 1.1.3.1/24;
}
family mpls;
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 1.1.4.1/24;
}
}
}
fe-1/2/2 {
unit 0 {
family inet {
address 1.1.6.1/24;
}
family mpls;
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 192.168.209.9/28;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.1/32;
}
}
}
user@EgressPE# show protocols
igmp {
interface fe-1/3/0.0 {
version 3;
static {
group 232.1.1.1 {
group-count 3;
source 192.168.219.11;
}
group 227.1.1.1;
}
}
interface so-0/1/3.0 {
version 3;
static {
group 232.1.1.1 {
group-count 2;
source 192.168.219.11;
}
group 232.2.2.2 {
source 1.2.7.7;
}
}
}
}
mpls {
interface fe-1/2/0.0;
interface fe-1/2/2.0;
}
bgp {
group ibgp {
type internal;
local-address 1.1.1.1;
family inet {
any;
}
neighbor 1.1.1.2;
}
}
msdp {
local-address 1.1.1.1;
peer 1.1.1.5;
}
ospf {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
ldp {
interface fe-1/2/0.0;
interface fe-1/2/2.0;
interface lo0.0;
p2mp;
}
pim {
mldp-inband-signalling {
policy mldppim-ex;
}
rp {
local {
address 1.1.1.1;
group-ranges {
227.0.0.0/8;
}
}
static {
address 1.1.1.4;
address 1.2.7.7 {
group-ranges {
226.0.0.0/8;
}
}
}
}
interface lo0.0;
interface fe-1/3/0.0;
interface fe-1/2/0.0;
interface fe-1/2/1.0;
interface so-0/1/3.0;
}
user@EgressPE# show policy-options
policy-statement mldppim-ex {
term B {
from {
source-address-filter 192.168.0.0/24 orlonger;
source-address-filter 192.168.219.11/32 orlonger;
}
then {
p2mp-lsp-root {
address 1.1.1.2;
}
accept;
}
}
term A {
from {
source-address-filter 1.2.7.0/24 orlonger;
}
then accept;
}
}
user@EgressPE# show routing-options
autonomous-system 64510;
Konfigurieren Sie in ähnlicher Weise die anderen Ausgangsgeräte.
Wenn Sie die Konfiguration der Geräte durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit
.
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
- PIM-Beitrittsstatus prüfen
- Überprüfen der PIM-Quellen
- Überprüfen der LDP-Datenbank
- Suchen der Routeninformationen für das MPLS-Label
- Überprüfen der LDP-Datenverkehrsstatistiken
PIM-Beitrittsstatus prüfen
Zweck
Zeigen Sie Informationen über PIM-Join-Status an, um die M-LDP-In-Band-Upstream- und Downstream-Details zu überprüfen. Auf dem Eingangsgerät wird der show pim join extensive
Befehl für die Downstream-Schnittstelle angezeigt Pseudo-MLDP
. Am Ausgang wird der show pim join extensive
Befehl für die Upstream-Schnittstelle angezeigt Pseudo-MLDP
.
Aktion
Geben Sie im Betriebsmodus den show pim join extensive
Befehl ein.
user@IngressPE> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 232.1.1.1 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/3/1.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 23:00:12 Downstream neighbors: Interface: Pseudo-MLDP Interface: fe-1/2/1.0 1.2.5.2 State: Join Flags: S Timeout: Infinity Uptime: 1d 23:00:12 Time since last Join: 1d 23:00:12 Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/3/1.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 22:59:59 Downstream neighbors: Interface: Pseudo-MLDP Group: 232.1.1.3 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/3/1.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 22:07:31 Downstream neighbors: Interface: Pseudo-MLDP Group: 232.2.2.2 Source: 1.2.7.7 Flags: sparse,spt Upstream interface: fe-1/2/3.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 22:59:59 Downstream neighbors: Interface: Pseudo-MLDP user@EgressPE> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 227.1.1.1 Source: * RP: 1.1.1.1 Flags: sparse,rptree,wildcard Upstream interface: Local Upstream neighbor: Local Upstream state: Local RP Uptime: 1d 23:14:21 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: SRW Timeout: Infinity Uptime: 1d 23:14:21 Time since last Join: 1d 20:12:35 Group: 232.1.1.1 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <1.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 23:14:22 Downstream neighbors: Interface: so-0/1/3.0 192.168.92.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <1.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 23:14:22 Downstream neighbors: Interface: so-0/1/3.0 192.168.92.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Downstream neighbors: Interface: fe-1/2/1.0 1.1.4.4 State: Join Flags: S Timeout: 198 Uptime: 1d 22:59:59 Time since last Join: 00:00:12 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Group: 232.1.1.3 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <1.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:12:35 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Group: 232.2.2.2 Source: 1.2.7.7 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <1.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:12:35 Downstream neighbors: Interface: so-0/1/3.0 192.168.92.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 user@pr3> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <1.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:14:40 Downstream neighbors: Interface: Pseudo-GMP ge-0/3/1.0 Group: 232.2.2.2 Source: 1.2.7.7 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <1.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:14:40 Downstream neighbors: Interface: Pseudo-GMP ge-0/3/1.0 user@pr4> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 225.1.1.1 Source: * RP: 1.1.1.4 Flags: sparse,rptree,wildcard Upstream interface: Local Upstream neighbor: Local Upstream state: Local RP Uptime: 1d 23:13:43 Downstream neighbors: Interface: ge-0/3/0.0 192.168.207.9 State: Join Flags: SRW Timeout: Infinity Uptime: 1d 23:13:43 Time since last Join: 1d 23:13:43 Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/2/0.0 Upstream neighbor: 1.1.4.1 Upstream state: Local RP, Join to Source Keepalive timeout: 0 Uptime: 1d 23:13:43 Downstream neighbors: Interface: ge-0/3/0.0 192.168.207.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 23:13:43 Time since last Join: 1d 23:13:43 user@pr5> show pim join extensive ge-0/3/1.0 Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Instance: PIM.master Family: INET6 R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Überprüfen der PIM-Quellen
Zweck
Überprüfen Sie, ob die PIM-Quellen über die erwarteten M-LDP-In-Band-Upstream- und Downstream-Details verfügen.
Aktion
Geben Sie im Betriebsmodus den show pim source
Befehl ein.
user@IngressPE> show pim source Instance: PIM.master Family: INET Source 1.1.1.1 Prefix 1.1.1.1/32 Upstream interface Local Upstream neighbor Local Source 1.2.7.7 Prefix 1.2.7.0/24 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <1.1.1.2> Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <1.1.1.2>
user@EgressPE> show pim source Instance: PIM.master Family: INET Source 1.2.7.7 Prefix 1.2.7.0/24 Upstream interface fe-1/2/3.0 Upstream neighbor 1.2.7.2 Source 1.2.7.7 Prefix 1.2.7.0/24 Upstream interface fe-1/2/3.0 Upstream neighbor Direct Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream interface fe-1/3/1.0 Upstream neighbor 192.168.219.9 Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream interface fe-1/3/1.0 Upstream neighbor Direct
user@pr3> show pim source Instance: PIM.master Family: INET Source 1.2.7.7 Prefix 1.2.7.0/24 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <1.1.1.2> Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <1.1.1.2>
user@pr4> show pim source Instance: PIM.master Family: INET Source 1.1.1.4 Prefix 1.1.1.4/32 Upstream interface Local Upstream neighbor Local Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream interface fe-1/2/0.0 Upstream neighbor 1.1.4.1
Überprüfen der LDP-Datenbank
Zweck
Stellen Sie sicher, dass der show ldp database
Befehl die erwarteten Root-to-(S,G)-Bindungen anzeigt.
Aktion
user@IngressPE> show ldp database Input label database, 10.255.2.227:0--1.1.1.3:0 Label Prefix 300096 1.1.1.2/32 3 1.1.1.3/32 299856 1.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--1.1.1.3:0 Label Prefix 300144 1.1.1.2/32 299776 1.1.1.3/32 299856 1.1.1.6/32 3 10.255.2.227/32 Input label database, 10.255.2.227:0--1.1.1.6:0 Label Prefix 299936 1.1.1.2/32 299792 1.1.1.3/32 3 1.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--1.1.1.6:0 Label Prefix 300144 1.1.1.2/32 299776 1.1.1.3/32 299856 1.1.1.6/32 3 10.255.2.227/32 300432 P2MP root-addr 1.1.1.2, grp: 232.2.2.2, src: 1.2.7.7 300288 P2MP root-addr 1.1.1.2, grp: 232.1.1.1, src: 192.168.219.11 300160 P2MP root-addr 1.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 300480 P2MP root-addr 1.1.1.2, grp: 232.1.1.3, src: 192.168.219.11
user@EgressPE> show ldp database Input label database, 1.1.1.2:0--1.1.1.3:0 Label Prefix 300096 1.1.1.2/32 3 1.1.1.3/32 299856 1.1.1.6/32 299776 10.255.2.227/32 300144 P2MP root-addr 1.1.1.2, grp: 232.2.2.2, src: 1.2.7.7 300128 P2MP root-addr 1.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 Output label database, 1.1.1.2:0--1.1.1.3:0 Label Prefix 3 1.1.1.2/32 299776 1.1.1.3/32 299808 1.1.1.6/32 299792 10.255.2.227/32 Input label database, 1.1.1.2:0--1.1.1.6:0 Label Prefix 299936 1.1.1.2/32 299792 1.1.1.3/32 3 1.1.1.6/32 299776 10.255.2.227/32 300128 P2MP root-addr 1.1.1.2, grp: 232.2.2.2, src: 1.2.7.7 299984 P2MP root-addr 1.1.1.2, grp: 232.1.1.1, src: 192.168.219.11 299952 P2MP root-addr 1.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 300176 P2MP root-addr 1.1.1.2, grp: 232.1.1.3, src: 192.168.219.11 300192 P2MP root-addr 1.1.1.2, grp: ff3e::1:2, src: abcd::1:2:7:7 Output label database, 1.1.1.2:0--1.1.1.6:0 Label Prefix 3 1.1.1.2/32 299776 1.1.1.3/32 299808 1.1.1.6/32 299792 10.255.2.227/32 ----- logical-system: default Input label database, 10.255.2.227:0--1.1.1.3:0 Label Prefix 300096 1.1.1.2/32 3 1.1.1.3/32 299856 1.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--1.1.1.3:0 Label Prefix 300144 1.1.1.2/32 299776 1.1.1.3/32 299856 1.1.1.6/32 3 10.255.2.227/32 Input label database, 10.255.2.227:0--1.1.1.6:0 Label Prefix 299936 1.1.1.2/32 299792 1.1.1.3/32 3 1.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--1.1.1.6:0 Label Prefix 300144 1.1.1.2/32 299776 1.1.1.3/32 299856 1.1.1.6/32 3 10.255.2.227/32 300432 P2MP root-addr 1.1.1.2, grp: 232.2.2.2, src: 1.2.7.7 300288 P2MP root-addr 1.1.1.2, grp: 232.1.1.1, src: 192.168.219.11 300160 P2MP root-addr 1.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 300480 P2MP root-addr 1.1.1.2, grp: 232.1.1.3, src: 192.168.219.11 300496 P2MP root-addr 1.1.1.2, grp: ff3e::1:2, src: abcd::1:2:7:7
user@p6> show ldp database Input label database, 1.1.1.6:0--1.1.1.2:0 Label Prefix 3 1.1.1.2/32 299776 1.1.1.3/32 299808 1.1.1.6/32 Output label database, 1.1.1.6:0--1.1.1.2:0 Label Prefix 299776 1.1.1.2/32 299792 1.1.1.3/32 3 1.1.1.6/32
user@pr3> show ldp database Input label database, 1.1.1.3:0--1.1.1.2:0 Label Prefix 3 1.1.1.2/32 299776 1.1.1.3/32 299808 1.1.1.6/32 299792 10.255.2.227/32 Output label database, 1.1.1.3:0--1.1.1.2:0 Label Prefix 300096 1.1.1.2/32 3 1.1.1.3/32 299856 1.1.1.6/32 299776 10.255.2.227/32 300144 P2MP root-addr 1.1.1.2, grp: 232.2.2.2, src: 1.2.7.7 300128 P2MP root-addr 1.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 Input label database, 1.1.1.3:0--10.255.2.227:0 Label Prefix 300144 1.1.1.2/32 299776 1.1.1.3/32 299856 1.1.1.6/32 3 10.255.2.227/32 Output label database, 1.1.1.3:0--10.255.2.227:0 Label Prefix 300096 1.1.1.2/32 3 1.1.1.3/32 299856 1.1.1.6/32 299776 10.255.2.227/32
Suchen der Routeninformationen für das MPLS-Label
Zweck
Zeigen Sie die Punkt-zu-Multipoint-FEC-Informationen an.
Aktion
user@EgressPE> show route label 299808 detail mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) 299808 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x931922c Next-hop reference count: 3 Next hop type: Router, Next hop index: 1109 Address: 0x9318b0c Next-hop reference count: 2 Next hop: via so-0/1/3.0 Label operation: Pop Next hop type: Router, Next hop index: 1110 Address: 0x93191e0 Next-hop reference count: 2 Next hop: 192.168.209.11 via fe-1/3/0.0 Label operation: Pop State: **Active Int AckRequest> Local AS: 10 Age: 13:08:15 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 1.1.1.2, grp: 232.1.1.1, src: 192.168.219.11
Überprüfen der LDP-Datenverkehrsstatistiken
Zweck
Überwachung der Datenverkehrsstatistiken für Point-to-Multipoint-LSP.
Aktion
user@EgressPE> show ldp traffic-statistics p2mp P2MP FEC Statistics: FEC(root_addr:lsp_id/grp,src) Nexthop Packets Bytes Shared 1.1.1.2:232.2.2.2,1.2.7.7 so-0/1/3.0 0 0 No 1.1.1.2:232.1.1.1,192.168.219.11 so-0/1/3.0 0 0 No fe-1/3/0.0 0 0 No 1.1.1.2:232.1.1.2,192.168.219.11 so-0/1/3.0 0 0 No fe-1/3/0.0 0 0 No lt-1/2/0.14 0 0 No 1.1.1.2:232.1.1.3,192.168.219.11 fe-1/3/0.0 0 0 No 1.1.1.2:ff3e::1:2,abcd::1:2:7:7 fe-1/3/0.0 0 0 No
LDP Mapping Server for Interoperability of Segment Routing with LDP Overview
In einem LDP-Netzwerk mit schrittweiser Implementierung von Segment-Routing kann es Inseln von Geräten geben, die entweder nur LDP oder nur Segment-Routing unterstützen. Damit die Geräte miteinander arbeiten, muss die LDP-Zuordnungsserverfunktion auf jedem Gerät im Segment-Routing-Netzwerk konfiguriert werden.
Die LDP-Zuordnungsserverfunktion wird entweder mit OSPF oder ISIS implementiert.
- Interoperabilität des Segment-Routing mit LDP mit OSPF
- Interoperabilität des Segment-Routing mit LDP mit ISIS
Interoperabilität des Segment-Routing mit LDP mit OSPF
Um die Interoperabilität des Segment-Routing mit LDP mit OSPF zu implementieren, wird eine erweiterte Prefix Link State Advertisement (LSA) mit Bereichstyp, Länge und Wert (TLV) für alle LDP-Präfixe generiert, und die Zuordnung von Routen, die dem Präfix entsprechen, wird in den Routing-Tabellen inet.3 und mpls.0 installiert.
Abbildung 22 ist eine einfache LDP-Netzwerktopologie zur Verdeutlichung der Interoperabilität von Segment-Routing-Geräten mit LDP-Geräten mit OSPF. Die Topologie umfasst sechs Geräte (Geräte R1, R2, R3, R4, R5 und R6) mit LDP-zu-Segment-Routing-Migration.

In der oben genannten Topologie können die Geräte R1, R2 und R3 nur Segment-Routing nutzen, die Geräte R5 und R6 können nur LDP, und Gerät R4 unterstützt sowohl LDP als auch Segment-Routing. Hier kann Gerät R1 aufgrund von Interoperabilitätsproblemen nicht mit Gerät R6 kompatibel sein.
Um die Interoperabilität zwischen den LDP-fähigen und Segment-Routing-Geräten zu ermöglichen, wird eine Schnittstelle des Geräts im Segment-Routing-Netzwerksegment als LDP-Zuordnungsserver konfiguriert. Derzeit konfiguriert der Zuordnungsserver Präfixe unter der [edit routing-options source-packet-routing]
Hierarchieebene. Mit dieser Funktion wird die LDP-Zuordnungsserverkonfiguration unter der [edit protocols ospf]
Hierarchieebene angewendet, wobei ein neues erweitertes Präfix LSA mit Bereichs-TLV für alle LDP-Präfixe von OSPF angekündigt wird. Das Gerät, das segmentieren kann, analysiert den erweiterten Prefix-Bereich TLV, und Zuordnungsrouten, die dem Präfix entsprechen, werden in den Routing-Tabellen inet.3 und mpls.0 installiert.
Wenn beispielsweise Abbildung 22Gerät R2 (im Segment-Routing-Netzwerk) der LDP-Zuordnungsserver ist, ist folgende Konfiguration enthalten:
[edit routing-options] user@R2# set source-packet-routing mapping-server-entry mapping-server-nameprefix-segment-range prefix-range start-prefix loopback-address user@R2# set source-packet-routing mapping-server-entry mp1 prefix-segment-range rg1 start-index 5 user@R2# set source-packet-routing mapping-server-entry mp1 prefix-segment-range rg1 size 1
Die IP-Adresse, die start-prefix
als Loopback-Adresse des Geräts im LDP-Netzwerk verwendet wird (Gerät R5 in diesem Beispiel).
[edit protocols] user@R2# set ospf source-packet-routing mapping-server mapping-server-name
Wenn die LDP-Zuordnungsserverkonfiguration auf Gerät R2 festgelegt wird, wird der erweiterte Prefix-Bereich TLV über den OSPF-Bereich übertragen. Die Geräte, die Segment-Routing (Geräte R1, R2 und R3) können OSPF-Segment-Routing-Routen für die angegebene Loopback-Adresse mit einem Segment-ID (SID)-Index installieren. Der SID-Index wird auch in der routing-Tabelle mpls.0 von den Segment-Routinggeräten aktualisiert.
Ab Junos OS-Version 19.1R1 kann der Segment-Routing-LDP-Border-Router den Segment-Routing-Datenverkehr mit LDP Next-Hop verbinden und umgekehrt.
Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using OSPF
Der Prefix-Konflikt wird nur in der Quellkonfiguration erkannt. Wenn es einen Prefix-Bereichskonflikt gibt, hat das Präfix SID von der niedrigeren Router-ID Vorrang. In solchen Fällen wird eine Fehlermeldung
RPD_OSPF_PFX_SID_RANGE_CONFLICT
des Systemprotokolls generiert.IPv6-Präfixe werden nicht unterstützt.
Eine Überflutung der OSPF Extended Prefix Opaque LSA, die vom Segment-Routing-Mapping-Server für autonome Systeme (ASs) generiert wird, wird nicht unterstützt.
LDP-zuordnende Serverfunktionäre werden nicht unterstützt.
ABR-Funktionen von Extended Prefix Opaque LSA werden nicht unterstützt.
ASBR-Funktionen von Extended Prefix Opaque LSA werden nicht unterstützt.
Segment-Routing-Zuordnungsserver Präferenz TLV wird nicht unterstützt.
Interoperabilität des Segment-Routing mit LDP mit ISIS
Um die Interoperabilität des Segment-Routing mit LDP mit ISIS zu implementieren, ist eine Server-Client-Konfiguration unter den Protokollen ISIS bzw. LDP erforderlich, und Routen aus den Inet.3- oder inet.0-Routingtabellen werden zum Zusammenfügen von Segment-Routing-LSP mit einem LDP-LSP und umgekehrt verwendet.
Abbildung 23 ist eine einfache LDP-Netzwerktopologie, mit der die Interoperabilität von Segment-Routing-Geräten mit LDP-Geräten anhand einer LDP-Zuordnung von Server-Client-Funktion veranschaulicht wird. Die Topologie umfasst vier Provider-Edge-Geräte (PE1, PE2, PE3 und PE4) und vier Provider-Geräte (P5, P6, P7 und P8).

Die Geräte PE3, PE4, P6, P7 und P8 sind die LDP-fähigen Geräte. Die Geräte PE1, PE2, P5 und P6 sind in der Lage, Segment-Routing mit dem SRGB-Wert (Segment Routing Global Block) von 100 und 200 und dem Node Segment IDs (SIDs)-Wert von 101, 102,105 und 106 zu segmentieren.
Damit ein Service-Flow mithilfe eines kontinuierlichen MPLS-Tunnels zu Geräte-PE3 und Geräte-PE1 getunnelt werden kann, müssen die Geräteinseln, die Segment-Routing unterstützen, und LDP zusammenarbeiten.
LDP Mapping Client Functionality (LDP to Segment Routing)
Die LDP-Clientfunktionalität ist die LDP-zu-Segment-Routingzuordnung, d. h. der Datenverkehr von rechts nach links in Abbildung 23. Auf Gerät P6 wird eine LDP-Ausgangsrichtlinie so konfiguriert, dass alle Knoten-SIDs und Prefix-SIDs aus dem Segment-Routing-Netzwerk auf der linken Seite angezeigt werden. Daher wird auf Gerät P6 von LDP die Geräte PE1, PE2 und P5 als Ausgangs-FEC-Label-Bindungen an Gerät P7 angekündigt.
Geräte-PE3 hat eine Serviceroute mit Gerät PE1 als Protokoll next Hop gelernt. Geräte-PE3 verfügt über eine LDP-Labelbindung vom P8 Next Hop für den PE1 FEC. Infolgedessen sendet Geräte-PE3 sein Servicepaket gemäß dem klassischen LDP-Verhalten an Gerät P8. Gerät P8 verfügt über eine LDP-Labelbindung von seinem nächsten P7-Hop für das PE1-FEC, daher leitet Gerät P8 gemäß dem klassischen LDP-Verhalten an Gerät P7 weiter.
Gerät P7 verfügt über eine LDP-Labelbindung von seinem P6 Next Hop, dem PE1 FEC, sodass Gerät P7 gemäß dem klassischen LDP-Verhalten an Gerät P6 weiterleitet.
Gerät P6that fungiert als LDP-Ausgang für das PE1-FEC und vertauscht das eingehende Egress-LDP-Label für das PE1-FEC mit einem entsprechenden Segment-Routingknoten-SID (in diesem Beispiel 101), um den Datenverkehr an Gerät P5 weiterzuleiten.
Gerät P5 pops 101 SID vorausgesetzt, dass Geräte-PE1 sein Node-Segment 101 mit dem vorletzten Pop-Flag angekündigt und dann den Datenverkehr an Gerät PE1 weiterleitet. Geräte-PE1 erkennt das tunnelierte Paket und verarbeitet das Service-Label.
Aus diesem Grund besteht der End-to-End-MPLS-Tunnel aus einem LDP-LSP von Geräte-PE3 zu Gerät P6 und dem zugehörigen Knotensegment von Gerät P6 zu Gerät PE1.
LDP Mapping Server Functionality (Segment Routing to LDP)
Die LDP-Serverfunktionalität ist die Zuordnung von Segment-Routing zu LDP, d. h. der Datenverkehrsfluss von links nach rechts in Abbildung 23. Auf Gerät P6 ist die Konfiguration der Zuordnungsserver-Präfixe in der [edit routing-options source-packet-routing]
Hierarchieebene enthalten. Wenn die Konfiguration unter dem spezifischen IGP angewendet wird, werden der Labelbindungstyp, die Länge und der Wert (TLV) für alle LDP-FEC-Label-Bindungen aus dem LDP-Netzwerk als inet.3-LDP-Routen angekündigt.
Hier fungiert Device P6 als Segment Routing Mapping Server (SRMS) und kündigt die folgenden Zuordnungen an – (P7, 107), (P8, 108), (PE3, 103), (PE4, 104) und (P7, 107). Wenn segmentiertes Routing auf Gerät PE3 unterstützt würde, wäre der Knoten SID 103 auf Geräte-PE3 konfiguriert worden. Da Geräte-PE3 das Segment-Routing nicht unterstützt, wird die Richtlinie am SRMS auf Gerät P6 konfiguriert, und Gerät P6 ist für die Werbung für die Zuordnungen verantwortlich.
Diese Zuordnungsserveranzeigen werden nur von den Segment-Routing-Geräten verstanden. Die Segment-Routing-Geräte installieren die zugehörigen Knoten-SIDs in der MPLS-Datenebene genau so, wie die Knotensegmente von den Knoten selbst angekündigt wurden. Beispielsweise installiert Geräte-PE1 den Knoten SID 103 mit dem nächsten P5-Hop genau so, als hätte Geräte-PE3 SID 103 angekündigt.
Gerät PE1 hat eine Serviceroute mit PE3 als Protokoll next Hop. Geräte-PE1 hat ein Knotensegment für diese IGP-Route – 103 mit P5 Next Hop. Aus diesem Grund sendet Geräte-PE1 sein Servicepaket mit zwei Labeln an Gerät P5: das untere Label, das ist das Service-Label, und das obere Label, nämlich SID 103. Gerät P5 austauscht 103 für 103 und leitet an Gerät P6 weiter. Der nächste Hop für Gerät P6 ist die IGP-Route PE3, die nicht segmentiert werden kann. (Gerät P7 wirbt nicht für die Segment-Routing-Funktion). Gerät P6 verfügt jedoch über eine LDP-Labelbindung von diesem nächsten Hop für dasselbe FEC (z. B. LDP-Label 1037). Daher wird auf Gerät P6 der IGP 103 für 1037 ausgetauscht und an Gerät P7 weitergeleitet.
Gerät P7 austauscht dieses Label mit dem LDP-Label, das von Gerät P8 empfangen wurde, und leitet es dann an Gerät P8 weiter. Das LDP-Label wird von Gerät P8 gestempelt und an Device PE3 weitergeleitet.
Gerät PE3 empfängt das tunnelierte Paket und verarbeitet das Service-Label. Der End-to-End-MPLS-Tunnel besteht aus einem Segment-Routing-Knoten von Geräten PE1 bis P6 und einem LDP-LSP von Geräten P6 bis PE3.
Segment Routing to LDP Stitching
Wenn der IP Next Hop des IGP-Segment-Routing-LSP das Segment-Routing nicht unterstützt, prüft das IGP die Routingtabelle inet.3, um zu sehen, ob ein LDP-LSP für das gleiche Präfix vorhanden ist. Wenn der LDP-LSP vorhanden ist, verknüpft das IGP das Segment-Routing-LSP mit dem LDP-LSP, indem es eine MPLS-Transitroute programmiert, die das Segment-Routing-Label mit dem LDP-Label austauscht, um den Datenverkehr von der Segment-Routing-Domäne in die LDP-Domäne zu wechseln.
Abbildung 24 zeigt das Stitching von Segment-Routing und LDP-LSPs zur Unterstützung der Interoperabilität.

In der Topologie ist Geräte-PE3 LDP-fähig und unterstützt kein Segment-Routing. Der Zuordnungsserver in der Segment-Routing-Domäne kann label binding TLV für die Geräte P7, P8 und PE4 anzeigen. In einem solchen Szenario kann Geräte-PE1 sowohl Prefix SID als auch Remote-Label binding TLV und SID haben, um Geräte-PE4 zu erreichen. Geräte-PE1 bevorzugt beim Programmieren der Ingress-Segment-Routingroute für Geräte-PE4 jedoch das Präfix SID über die Remote-Labelbindung TLV. Aus diesem Grund verwendet Geräte-PE1 das Segment-Routing-LSP End-to-End zum Senden von Datenverkehr an Geräte-PE4 und das Segment-Routing-zu-LDP-Stitching beim Senden von Datenverkehr an Gerät PE3.
Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS
Vorletztes Hop-Popping-Verhalten für die Labelbindung TLV wird nicht unterstützt.
Werbung für eine Reihe von Präfixen in der Labelbindung TLV wird nicht unterstützt.
Konfliktlösung für Segment-Routing wird nicht unterstützt.
LDP-Datenverkehrsstatistiken funktionieren nicht.
Nonstop Active Routing (NSR) und Graceful Routing Engine Switchover (GRES) werden nicht unterstützt.
ISIS-übergreifende Ebenen werden nicht unterstützt.
RFC 7794, IS-IS Prefix-Attribute für erweitertes IPv4 werden nicht unterstützt.
Eine Neuverteilung der LDP-Route als Prefix-SID am Stitching-Knoten wird nicht unterstützt.
Konfigurieren verschiedener LDP-Eigenschaften
In den folgenden Abschnitten wird die Konfiguration einer Reihe verschiedener LDP-Eigenschaften beschrieben:
- Konfigurieren von LDP zur Verwendung der IGP-Routenmetrik
- Verhindern des Hinzufügens von Eingangsrouten zur Routingtabelle inet.0
- LDP mit mehreren Instanzen und Carrier-of-Carrier-VPNs
- Konfigurieren von MPLS und LDP zum Pop-the-Label auf dem Ultimate-Hop-Router
- Aktivieren von LDP über VON RSVP eingerichtete LSPs
- Aktivieren von LDP über VON RSVP eingerichtete LSPs in heterogenen Netzwerken
- Konfigurieren der TCP MD5-Signatur für LDP-Sitzungen
- Konfigurieren von LDP-Sitzungsschutz
- Deaktivieren von SNMP-Traps für LDP
- Konfigurieren der LDP-Synchronisation mit dem IGP auf LDP-Verbindungen
- Konfigurieren der LDP-Synchronisierung mit dem IGP auf dem Router
- Konfigurieren des Label Withdrawal Timer
- Ignorieren der LDP-Subnetzprüfung
Konfigurieren von LDP zur Verwendung der IGP-Routenmetrik
Verwenden Sie die track-igp-metric
Anweisung, wenn die Interior Gateway Protocol (IGP)-Routenmetrik für die LDP-Routen anstelle der Standard-LDP-Routenmetrik verwendet werden soll (die Standard-LDP-Routenmetrik ist 1).
Um die IGP-Routenmetrik zu verwenden, fügen Sie die track-igp-metric
Anweisung ein:
track-igp-metric;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Verhindern des Hinzufügens von Eingangsrouten zur Routingtabelle inet.0
Durch die Konfiguration der no-forwarding
Anweisung können Sie verhindern, dass Eingehende Routen der Routingtabelle inet.0 anstelle der Routingtabelle inet.3 hinzugefügt werden, selbst wenn Sie die traffic-engineering bgp-igp
Anweisung auf der [edit protocols mpls]
oder der [edit logical-systems logical-system-name protocols mpls]
Hierarchieebene aktiviert haben. Standardmäßig ist die no-forwarding
Anweisung deaktiviert.
Router der ACX-Serie unterstützen keine [edit logical-systems
] Hierarchieebene.
Um Ingress-Routen aus der Routing-Tabelle inet.0 zu unterlassen, fügen Sie die no-forwarding
Anweisung ein:
no-forwarding;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
LDP mit mehreren Instanzen und Carrier-of-Carrier-VPNs
Durch die Konfiguration mehrerer LDP-Routinginstanzen können Sie mithilfe von LDP Labels in einem Carrier-of-Carrier-VPN von einem Service Provider Edge (PE)-Router zu einem Kunden-Carrier-Customer Edge (CE)-Router anzeigen. Dies ist besonders nützlich, wenn der Carrier-Kunde ein grundlegender Internet Service Provider (ISP) ist und vollständige Internetrouter auf seine PE-Router beschränken möchte. Durch die Verwendung von LDP anstelle von BGP schützt der Carrier-Kunde seine anderen internen Router aus dem Internet. LDP mit mehreren Instanzen ist auch nützlich, wenn ein Carrier-Kunde seinen Kunden Layer-2- oder Layer-3-VPN-Services bereitstellen möchte.
Ein Beispiel für die Konfiguration mehrerer LDP-Routinginstanzen für Carrier-of-Carrier-VPNs finden Sie im Benutzerhandbuch "Mehrere Instanzen für Label Distribution Protocol".
Konfigurieren von MPLS und LDP zum Pop-the-Label auf dem Ultimate-Hop-Router
Das standardmäßig angekündigte Label ist Label 3 (Implizites Null-Label). Wenn Label 3 angekündigt wird, entfernt der vorletzte Hop-Router das Label und sendet das Paket an den Ausgangsrouter. Wenn ultimate-hop popping aktiviert ist, wird Label 0 (IPv4 Explicit Null Label) angekündigt. Ultimate-Hop-Popping stellt sicher, dass alle Pakete, die ein MPLS-Netzwerk passieren, ein Label enthalten.
Um ultimate-hop popping zu konfigurieren, fügen Sie die explicit-null
Anweisung ein:
explicit-null;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Router von Juniper Networks Warteschlangenpakete basierend auf dem eingehenden Label. Router von anderen Anbietern könnten Pakete unterschiedlich in die Warteschlangen warteschlangen. Bedenken Sie dies bei der Arbeit mit Netzwerken, die Router von mehreren Anbietern enthalten.
Weitere Informationen zu Labeln finden Sie unter MPLS Label Overview and MPLS Label Allocation.
Aktivieren von LDP über VON RSVP eingerichtete LSPs
Sie können LDP über von RSVP eingerichtete LSPs ausführen und den LDP-etablierten LSP effektiv durch den von RSVP eingerichteten tunneln. Aktivieren Sie dazu LDP auf der lo0.0-Schnittstelle (siehe Aktivieren und Deaktivieren von LDP). Sie müssen auch die LSPs konfigurieren, über die LDP betrieben werden soll, indem Sie die ldp-tunneling
Anweisung auf der [edit protocols mpls label-switched-path lsp-name]
Hierarchieebene einbeziehen:
[edit] protocols { mpls { label-switched-path lsp-name { from source; to destination; ldp-tunneling; } } }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Aktivieren von LDP über VON RSVP eingerichtete LSPs in heterogenen Netzwerken
Einige andere Anbieter verwenden für die Loopback-Adresse eine OSPF-Metrik von 1. Router von Juniper Networks verwenden eine OSPF-Metrik von 0 für die Loopback-Adresse. Dies kann erfordern, dass Sie die RSVP-Metrik manuell konfigurieren, wenn Sie LDP-Tunneling über RSVP-LSPs in heterogenen Netzwerken bereitstellen.
Wenn ein Router von Juniper Networks über einen RSVP-Tunnel mit dem Router eines anderen Anbieters verbunden ist und das LDP-Tunneling ebenfalls aktiviert ist, verwendet der Router von Juniper Networks standardmäßig den RSVP-Tunnel nicht, um den Datenverkehr zu den LDP-Adressen hinter dem Ausgangsrouter des anderen Anbieters zu routen, wenn der RSVP-Pfad eine Kennzahl von 1 größer als der physische OSPF-Pfad hat.
Um sicherzustellen, dass LDP-Tunneling-Funktionen in heterogenen Netzwerken ordnungsgemäß funktionieren, können Sie OSPF so konfigurieren, dass die RSVP-LSP-Metrik ignoriert wird, indem Sie die ignore-lsp-metrics
Anweisung:
ignore-lsp-metrics;
Sie können diese Anweisung auf den folgenden Hierarchieebenen konfigurieren:
[edit protocols ospf traffic-engineering shortcuts]
[edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]
Router der ACX-Serie unterstützen keine [edit logical-systems
] Hierarchieebene.
Um LDP-over-RSVP-LSPs zu aktivieren, müssen Sie auch das Verfahren in Abschnitt Aktivieren von LDP über VON RSVP eingerichtete LSPsvervollständigen.
Konfigurieren der TCP MD5-Signatur für LDP-Sitzungen
Sie können eine MD5-Signatur für eine LDP-TCP-Verbindung konfigurieren, um vor der Einführung von manipulierten TCP-Segmenten in LDP-Sitzungsverbindungsstreams zu schützen.
Ein Router, der die MD5-Signaturoption verwendet, wird mit einem Kennwort für jeden Peer konfiguriert, für den eine Authentifizierung erforderlich ist. Das Kennwort wird verschlüsselt gespeichert.
LDP-Nachbarschaften können auch dann noch erstellt werden, wenn Peering-Schnittstellen mit verschiedenen Sicherheitssignaturen konfiguriert werden. Die TCP-Sitzung kann jedoch nicht authentifiziert werden und wird nie eingerichtet.
Ab Junos OS Version 16.1R1 wird die Unterstützung von Hashed Message Authentication Code (HMAC) und MD5-Authentifizierung für LDP-Sitzungen von einer Sitzungskonfiguration auf eine Subnetz-Übereinstimmung (d. h. die längste Prefix-Übereinstimmung) ausgeweitet.
Die Unterstützung der Subnetz-Match-Authentifizierung bietet Flexibilität bei der Konfiguration der Authentifizierung für automatisch gezielte LDP-Sitzungen (TLDP), wodurch die Bereitstellung von Remote Loop-Free Alternate (LFA) und FEC 129 Pseudowires einfach wird.
Um eine MD5-Signatur für eine LDP-TCP-Verbindung zu konfigurieren, fügen Sie die Folgendes und authentication-key
eine session-group
Anweisung ein:
session-group prefix-length { authentication-key authentication-key; }
Verwenden Sie die session-group
Anweisung, um die Adresse für das Remote-Ende der LDP-Sitzung zu konfigurieren.
Das md5-authentication-key
Kennwort kann bis zu 69 Zeichen lang sein. Zeichen können beliebige ASCII-Zeichenfolgen enthalten. Wenn Sie Leerzeichen enthalten, umschließen Sie alle Zeichen in Anführungszeichen.
Sie können auch einen Authentifizierungsschlüsselaktualisierungsmechanismus für das LDP-Routingprotokoll konfigurieren. Mit diesem Mechanismus können Sie Authentifizierungsschlüssel aktualisieren, ohne die zugehörigen Routing- und Signalprotokolle wie Open Shortest Path First (OSPF) und Resource Reservation Setup Protocol (RSVP) zu unterbrechen.
Um den Authentifizierungsschlüsselaktualisierungsmechanismus zu konfigurieren, fügen Sie die key-chain
Anweisung auf Hierarchieebene [edit security authentication-key-chains]
ein und geben Sie die key
Option an, eine Schlüsselkette zu erstellen, die aus mehreren Authentifizierungsschlüsseln besteht.
[edit security authentication-key-chains] key-chain key-chain-name { key key { secret secret-data; start-time yyyy-mm-dd.hh:mm:ss; } }
Um den Authentifizierungsschlüsselaktualisierungsmechanismus für das LDP-Routingprotokoll zu konfigurieren, fügen Sie die authentication-key-chain
Anweisung auf Hierarchieebene [edit protocols ldp]
ein, um das Protokoll mit den [edit security authentication-key-chains]
Authentifizierungsschlüsseln zu verknüpfen. Sie müssen auch den Authentifizierungsalgorithmus konfigurieren, indem Sie die Anweisung in die authentication-algorithm algorithm
[edit protocols ldp]
Hierarchieebene einbeziehen.
[edit protocols ldp] group group-name { neighbor address { authentication-algorithm algorithm; authentication-key-chain key-chain-name; } }
Weitere Informationen zur Update-Funktion für Authentifizierungsschlüssel finden Sie unter Konfigurieren des Authentifizierungsschlüsselaktualisierungsmechanismus für BGP- und LDP-Routingprotokolle.
Konfigurieren von LDP-Sitzungsschutz
Normalerweise wird eine LDP-Sitzung zwischen zwei Routern erstellt, die über eine oder mehrere Verbindungen verbunden sind. Die Router bilden eine "Hallo"-Nachbarschaft für jeden Link, der sie verbindet, und verknüpfen alle Nachbarschaften mit der entsprechenden LDP-Sitzung. Wenn die letzte Nachbarschaft für eine LDP-Sitzung unterbrochen wird, wird die LDP-Sitzung beendet. Möglicherweise möchten Sie dieses Verhalten ändern, um zu verhindern, dass eine LDP-Sitzung unnötig beendet und wieder hergestellt wird.
Sie können junos OS so konfigurieren, dass die LDP-Sitzung zwischen zwei Routern aktiviert wird, auch wenn es keine "Hallo"-Nachbarschaften auf den Verbindungen zwischen den beiden Routern gibt, indem Sie die session-protection
Anweisung konfigurieren. Sie können optional eine Zeit in Sekunden mithilfe der timeout
Option angeben. Die Sitzung bleibt für die angegebene Dauer aktiv, solange die Router die IP-Netzwerkkonnektivität aufrecht erhalten.
session-protection { timeout seconds; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary.
Deaktivieren von SNMP-Traps für LDP
Jedes Mal, wenn ein LDP-LSP einen Übergang von oben nach unten oder von oben nach oben macht, sendet der Router eine SNMP-Trap. Es ist jedoch möglich, die LDP SNMP-Traps auf einem Router, einem logischen System oder einer Routinginstanz zu deaktivieren.
Informationen zu LDP SNMP-Traps und der proprietären LDP-MIB finden Sie im SNMP MIB Explorer.
Um SNMP-Traps für LDP zu deaktivieren, geben Sie die trap disable
Option für die log-updown
Anweisung an:
log-updown { trap disable; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren der LDP-Synchronisation mit dem IGP auf LDP-Verbindungen
LDP ist ein Protokoll zur Verteilung von Labeln in anwendungen ohne Datenverkehr. Label werden auf dem besten, vom IGP festgelegten Pfad verteilt. Wenn die Synchronisierung zwischen LDP und IGP nicht aufrechterhalten wird, läuft der LSP ab. Wenn LDP auf einer bestimmten Verbindung nicht vollständig funktionsfähig ist (eine Sitzung wird nicht eingerichtet und Labels werden nicht ausgetauscht), gibt das IGP den Link mit der maximalen Kostenmetrik an. Die Verbindung wird nicht bevorzugt, bleibt aber in der Netzwerktopologie.
LDP-Synchronisierung wird nur an aktiven Punkt-zu-Punkt-Schnittstellen und LAN-Schnittstellen unterstützt, die als Punkt-zu-Punkt-Konfiguration unter dem IGP konfiguriert sind. Die LDP-Synchronisation wird während des unterbrechungsfreien Neustarts nicht unterstützt.
Um die maximale Kostenmetrik so lange zu werben, bis LDP für die Synchronisierung betriebsbereit ist, geben Sie die ldp-synchronization
Anweisung ein:
ldp-synchronization { disable; hold-time seconds; }
Um die Synchronisierung zu deaktivieren, fügen Sie die disable
Anweisung ein. Um den Zeitraum zu konfigurieren, um die maximale Kostenmetrik für eine Verbindung zu werben, die nicht vollständig funktionsfähig ist, fügen Sie die hold-time
Anweisung ein.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren der LDP-Synchronisierung mit dem IGP auf dem Router
Sie können die Zeit konfigurieren, zu der die LDP wartet, bevor Sie dem IGP mitteilen, dass der LDP-Nachbar und die Sitzung für eine Schnittstelle betriebsbereit sind. Für große Netzwerke mit zahlreichen FECs müssen Sie möglicherweise einen längeren Wert konfigurieren, um ausreichend Zeit für den Austausch von LDP-Labeldatenbanken einzuräumen.
Um die Zeit zu konfigurieren, die LDP wartet, bevor das IGP darüber informiert wird, dass der LDP-Nachbar und die Sitzung betriebsbereit sind, fügen Sie die igp-synchronization
Anweisung ein und geben Sie eine Zeit in Sekunden für die holddown-interval
Option an:
igp-synchronization holddown-interval seconds;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt statement summary für diese Anweisung.
Konfigurieren des Label Withdrawal Timer
Der Label-Auszahlungs-Timer verzögert das Senden einer Label-Auszahlungsnachricht für ein FEC an einen Nachbarn. Wenn eine IGP-Verbindung mit einem Nachbarn ausfällt, muss das mit dem FEC verbundene Label von allen upstreamen Routern entfernt werden, wenn der Nachbar der nächste Hop für das FEC ist. Nachdem das IGP konvergiert und ein Label von einem neuen next Hop empfangen wird, wird das Label auf alle upstreamen Router zurückgesetzt. Dies ist das typische Netzwerkverhalten. Durch die Verzögerung des Label-Entzugs um eine kleine Zeit (z. B. bis das IGP konvergiert und der Router ein neues Label für das FEC aus dem downstream nächsten Hop erhält), könnte der Label-Entzug und das Senden einer Labelzuordnung bald vermieden werden. Mit label-withdrawal-delay
der Anweisung können Sie diese Verzögerungszeit konfigurieren. Die Verzögerung beträgt standardmäßig 60 Sekunden.
Wenn der Router das neue Label erhält, bevor der Timer ausläuft, wird der Label-Auszahlungs-Timer abgebrochen. Wenn der Timer jedoch ausläuft, wird das Label für den FEC von allen vorgeschalteten Routern entfernt.
Standardmäßig wartet LDP 60 Sekunden, bevor die Label aus dem Verkehr ziehen werden, um zu vermeiden, dass LSPs mehrmals resignaliert werden, während das IGP rekonvergiert. Um die Zeit für die Label-Entzugsverzögerung in Sekunden zu konfigurieren, fügen Sie die label-withdrawal-delay
Anweisung hinzu:
label-withdrawal-delay seconds;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt statement summary für diese Anweisung.
Ignorieren der LDP-Subnetzprüfung
In Junos OS Version 8.4 und höher wird während der Nachbareinrichtung eine LDP-Quelladress-Subnetzprüfung durchgeführt. Die Quelladresse im LDP-Link Hello Packet wird mit der Schnittstellenadresse abgegleicht. Dies führt zu einem Interoperabilitätsproblem mit den Geräten einiger anderer Anbieter.
Um die Subnetzprüfung zu deaktivieren, fügen Sie die allow-subnet-mismatch
Anweisung ein:
allow-subnet-mismatch;
Diese Anweisung kann auf den folgenden Hierarchieebenen eingefügt werden:
[edit protocols ldp interface interface-name]
[edit logical-systems logical-system-name protocols ldp interface interface-name]
Router der ACX-Serie unterstützen keine [edit logical-systems
] Hierarchieebene.
Siehe auch
Konfigurieren von LDP LSP Traceroute
Sie können die Route verfolgen, gefolgt von einem LDP-signalisierten LSP. LDP LSP Traceroute basiert auf RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures (MPLS). Mit dieser Funktion können Sie periodisch alle Pfade in einem FEC verfolgen. Die FEC-Topologieinformationen werden in einer Datenbank gespeichert, auf die über die BEFEHLSZEILE zugegriffen werden kann.
Eine Topologieänderung löst nicht automatisch eine Trace eines LDP-LSP aus. Sie können jedoch einen Traceroute manuell initiieren. Wenn die Traceroute-Anforderung für ein FEC ist, das sich derzeit in der Datenbank befindet, wird der Inhalt der Datenbank mit den Ergebnissen aktualisiert.
Das periodische Traceroute-Feature gilt für alle FECs, die von der oam
auf Hierarchieebene [edit protocols ldp]
konfigurierten Anweisung angegeben werden. Um periodische LDP-LSP-Traceroute zu konfigurieren, fügen Sie die periodic-traceroute
Anweisung ein:
periodic-traceroute { disable; exp exp-value; fanout fanout-value; frequency minutes; paths number-of-paths; retries retry-attempts; source address; ttl ttl-value; wait seconds; }
Sie können diese Anweisung auf den folgenden Hierarchieebenen konfigurieren:
Sie können die periodic-traceroute
Anweisung selbst oder mit einer der folgenden Optionen konfigurieren:
exp
– Geben Sie die Dienstklasse an, die beim Senden von Sondierungen verwendet werden soll.fanout
– Geben Sie die maximale Anzahl der nächsten Hops an, die pro Knoten gesucht werden sollen.frequency
– Geben Sie das Intervall zwischen Traceroute-Versuchen an.paths
– Geben Sie die maximale Anzahl der zu suchenen Pfade an.retries
– Geben Sie die Anzahl der Versuche an, eine Probe an einen bestimmten Knoten zu senden, bevor Sie aufgeben.source
— Geben Sie die zu verwendende IPv4-Quelladresse beim Senden von Sondierungen an.ttl
– Geben Sie den maximalen Time-to-Live-Wert an. Knoten, die über diesen Wert hinausgehen, werden nicht verfolgt.wait
– Geben Sie das Warteintervall an, bevor Sie ein Probe-Paket erneut senden.
Sammeln von LDP-Statistiken
LDP-Datenverkehrsstatistiken zeigen das Datenverkehrsvolumen, das über ein bestimmtes FEC auf einem Router übertragen wurde.
Wenn Sie die traffic-statistics
Anweisung auf Hierarchieebene [edit protocols ldp]
konfigurieren, werden die LDP-Datenverkehrsstatistiken regelmäßig erfasst und in eine Datei geschrieben. Sie können konfigurieren, wie oft Statistiken (in Sekunden) erfasst werden, indem Sie die interval
Option verwenden. Das Standard-Erfassungsintervall beträgt 5 Minuten. Sie müssen eine LDP-Statistikdatei konfigurieren. Andernfalls werden keine LDP-Datenverkehrsstatistiken erfasst. Wenn der LSP ausfällt, werden die LDP-Statistiken zurückgesetzt.
Um LDP-Datenverkehrsstatistiken zu erfassen, fügen Sie die traffic-statistics
Anweisung ein:
traffic-statistics { file filename <files number> <size size> <world-readable | no-world-readable>; interval interval; no-penultimate-hop; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Dieser Abschnitt enthält die folgenden Themen:
- Ausgabe von LDP-Statistiken
- Deaktivieren von LDP-Statistiken auf dem Penultimate-Hop-Router
- Einschränkungen von LDP-Statistiken
Ausgabe von LDP-Statistiken
Die folgende Beispielausgabe stammt aus einer LDP-Statistikdatei:
FEC Type Packets Bytes Shared 10.255.350.448/32 Transit 0 0 No Ingress 0 0 No 10.255.350.450/32 Transit 0 0 Yes Ingress 0 0 No 10.255.350.451/32 Transit 0 0 No Ingress 0 0 No 220.220.220.1/32 Transit 0 0 Yes Ingress 0 0 No 220.220.220.2/32 Transit 0 0 Yes Ingress 0 0 No 220.220.220.3/32 Transit 0 0 Yes Ingress 0 0 No May 28 15:02:05, read 12 statistics in 00:00:00 seconds
Die LDP-Statistikdatei enthält die folgenden Datenspalten:
FEC
– FEC, für das LDP-Datenverkehrsstatistiken gesammelt werden.Type
— Art des Datenverkehrs, der von einem Router stammt, entwederIngress
(von diesem Router stammend) oderTransit
(über diesen Router weitergeleitet).Packets
— Anzahl der Pakete, die seit dem Einrichten des LSP vom FEC übermittelt wurden.Bytes
— Anzahl der Bytes von Daten, die vom FEC seit Dementen des LSP übergeben wurden.Shared
— EinYes
Wert gibt an, dass mehrere Präfixe an das gleiche Label gebunden sind (z. B. wenn mehrere Präfixe mit einer Ausgangsrichtlinie angekündigt werden). Die LDP-Datenverkehrsstatistiken für diesen Fall gelten für alle Präfixe und sollten als solche behandelt werden.read
– Diese Zahl (die neben Datum und Uhrzeit erscheint) kann von der tatsächlichen Anzahl der angezeigten Statistiken abweichen. Einige der Statistiken werden kurz zusammengefasst, bevor sie angezeigt werden.
Deaktivieren von LDP-Statistiken auf dem Penultimate-Hop-Router
Das Sammeln von LDP-Datenverkehrsstatistiken auf dem vorletzten Hop-Router kann übermäßige Systemressourcen verbrauchen, insbesondere auf Next-Hop-Routen. Dieses Problem wird noch verschärft, wenn Sie die deaggregate
Anweisung zusätzlich zur traffic-statistics
Anweisung konfiguriert haben. Für Router, die ihre Grenzen der Next-Hop-Routennutzung erreichen, empfehlen wir die Konfiguration der no-penultimate-hop
Option für die traffic-statistics
Anweisung:
traffic-statistics { no-penultimate-hop; }
Eine Liste der Hierarchieebenen, auf denen Sie die traffic-statistics
Anweisung konfigurieren können, finden Sie im Abschnitt statement summary für diese Anweisung.
Wenn Sie die no-penultimate-hop
Option konfigurieren, sind keine Statistiken für die FECs verfügbar, die der vorletzte Hop für diesen Router sind.
Jedes Mal, wenn Sie diese Option in die Konfiguration einbeziehen oder entfernen, werden die LDP-Sitzungen abgenommen und dann neu gestartet.
Die folgende Beispielausgabe stammt aus einer LDP-Statistikdatei mit Routern, auf denen die no-penultimate-hop
Option konfiguriert ist:
FEC Type Packets Bytes Shared 10.255.245.218/32 Transit 0 0 No Ingress 4 246 No 10.255.245.221/32 Transit statistics disabled Ingress statistics disabled 13.1.1.0/24 Transit statistics disabled Ingress statistics disabled 13.1.3.0/24 Transit statistics disabled Ingress statistics disabled
Einschränkungen von LDP-Statistiken
Die folgenden Probleme betreffen das Sammeln von LDP-Statistiken durch Konfiguration der traffic-statistics
Anweisung:
Sie können die LDP-Statistiken nicht löschen.
Wenn Sie das angegebene Intervall verkürzen, wird eine neue LDP-Statistikanforderung nur dann erstellt, wenn der Statistik-Timer später als das neue Intervall abläuft.
Ein neuer LDP-Statistikerfassungsvorgang kann erst gestartet werden, wenn der vorherige vorgang abgeschlossen ist. Wenn das Intervall kurz ist oder die Anzahl der LDP-Statistiken groß ist, kann die Zeitlücke zwischen den beiden Statistiksammlungen länger sein als das Intervall.
Wenn ein LSP ausfällt, werden die LDP-Statistiken zurückgesetzt.
Verfolgen des LDP-Protokolldatenverkehrs
In den folgenden Abschnitten wird beschrieben, wie die Trace-Optionen für die Prüfung des LDP-Protokolldatenverkehrs konfiguriert werden:
- Verfolgen des LDP-Protokolldatenverkehrs auf Protokoll- und Routinginstanzebene
- Verfolgen des LDP-Protokolldatenverkehrs innerhalb von FECs
- Beispiele: Verfolgen des LDP-Protokolldatenverkehrs
Verfolgen des LDP-Protokolldatenverkehrs auf Protokoll- und Routinginstanzebene
Um den LDP-Protokolldatenverkehr nachzuverfolgen, können Sie auf Hierarchieebene Optionen in der [edit routing-options]
globalen traceoptions
Anweisung angeben, und Sie können LDP-spezifische Optionen angeben, indem Sie die traceoptions
Anweisung angeben:
traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.
Verwenden Sie die file
Anweisung, um den Namen der Datei anzugeben, die die Ausgabe des Ablaufverfolgungsvorgangs empfängt. Alle Dateien werden im Verzeichnis /var/log abgelegt. Wir empfehlen, dass Sie die LDP-Tracing-Ausgabe in der Datei ldp-logplatzieren.
Die folgenden Trace-Flags zeigen die Vorgänge an, die mit dem Senden und Empfangen verschiedener LDP-Nachrichten verbunden sind. Jeder kann einen oder mehrere der folgenden Modifikatoren tragen:
address
— Verfolgen Sie den Betrieb von Adress- und Adressentzugsmeldungen.binding
— Ablaufverfolgung von Labelbindungsvorgängen.error
— Fehlerbedingungen nachverfolgen.event
— Protokollereignisse verfolgen.initialization
— Verfolgen Sie den Betrieb von Initialisierungsmeldungen.label
— Verfolgen Sie den Betrieb von Label-Request-, Label-Map-, Label-Auszahlungs- und Label-Release-Nachrichten.notification
— Verfolgen Sie den Betrieb von Benachrichtigungen.packets
— Verfolgen Sie den Betrieb von Adresse, Adressentzug, Initialisierung, Label-Anfrage, Label-Map, Label-Auszahlung, Label-Freigabe, Benachrichtigung und regelmäßigen Nachrichten. Dieser Modifikator entspricht dem Festlegen deraddress
,initialization
,label
,notification
undperiodic
Modifizierer.Sie können den
filter
Flag-Modifikator auch mit dermatch-on address
Unteroption für daspackets
Flag konfigurieren. Dies ermöglicht es Ihnen, basierend auf den Quell- und Zieladressen der Pakete nachzuverfolgen.path
— Ablaufverfolgung von Label-Switched Path-Vorgängen.path
— Ablaufverfolgung von Label-Switched Path-Vorgängen.periodic
- Verfolgen Sie den Betrieb von Hello- und Keepalive-Nachrichten.route
— Verfolgen Sie den Betrieb von Routenmeldungen.state
— Protokollstatusübergänge verfolgen.
Verfolgen des LDP-Protokolldatenverkehrs innerhalb von FECs
LDP verknüpft eine Forwarding Equivalence Class (FEC) mit jedem erstellten LSP. Das mit einem LSP verbundene FEC gibt an, welche Pakete diesem LSP zugeordnet werden. LSPs werden über ein Netzwerk erweitert, da jeder Router das vom nächsten Hop für das FEC angekündigte Label auswählt und es mit dem Label verbindet, das es allen anderen Routern anwirbt.
Sie können den LDP-Protokolldatenverkehr innerhalb eines bestimmten FEC verfolgen und LDP-Trace-Anweisungen basierend auf einem FEC filtern. Dies ist nützlich, wenn Sie den LDP-Protokolldatenverkehr, der mit einem FEC verknüpft ist, verfolgen oder beheben möchten. Zu diesem Zweck sind die folgenden Trace-Flags verfügbar: route
, path
und binding
.
Im folgenden Beispiel wird veranschaulicht, wie Sie die LDP-Anweisung so konfigurieren, dass LDP-Trace-Anweisungen traceoptions
basierend auf einem FEC gefiltert werden:
[edit protocols ldp traceoptions] set flag route filter match-on fec policy "filter-policy-for-ldp-fec";
Diese Funktion hat folgende Einschränkungen:
Die Filterfunktion ist nur für FECs verfügbar, die aus IPv4-Präfixen (IP Version 4) bestehen.
Layer-2-Circuit-FECs können nicht gefiltert werden.
Wenn Sie sowohl die Routenverfolgung als auch die Filterung konfigurieren, werden MPLS-Routen nicht angezeigt (sie werden durch den Filter blockiert).
Das Filtern wird durch die Richtlinie und den konfigurierten Wert für die
match-on
Option bestimmt. Achten Sie bei der Konfiguration der Richtlinie darauf, dass das Standardverhalten immerreject
lautet.Die einzige
match-on
Option istfec
. Daher sollten Sie nur eine Richtlinie zum Routenfiltern verwenden.
Beispiele: Verfolgen des LDP-Protokolldatenverkehrs
Detaillierte Verfolgung von LDP-Pfadmeldungen:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5; flag path; } } }
Verfolgen Sie alle ausgehenden LDP-Nachrichten:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5; flag packets; } } }
Verfolgen Sie alle LDP-Fehlerbedingungen:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5; flag error; } } }
Verfolgen Sie alle eingehenden LDP-Nachrichten und alle Label-Binding-Vorgänge:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5 world-readable; flag packets receive; flag binding; } interface all { } } }
Trace-LDP-Protokolldatenverkehr für ein FEC, das mit dem LSP verknüpft ist:
[edit] protocols { ldp { traceoptions { flag route filter match-on fec policy filter-policy-for-ldp-fec; } } }