Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

LDP-Konfiguration

Minimale LDP-Konfiguration

So aktivieren Sie LDP mit minimaler Konfiguration:

  1. Aktivieren Sie alle relevanten Schnittstellen unter MPLS-Familie. Im Fall von directed LDP muss die Loopback-Schnittstelle mit MPLS-Familie aktiviert werden.

  2. (Optional) Konfigurieren Sie die relevanten Schnittstellen unter der [edit protocol mpls] Hierarchieebene.

  3. Aktivieren Sie LDP auf einer einzigen Schnittstelle, fügen Sie die ldp Anweisung ein und geben Sie die Schnittstelle mithilfe der interface Anweisung an.

Dies ist die minimale LDP-Konfiguration. Alle anderen LDP-Konfigurationsanweisungen sind optional.

Um LDP auf allen Schnittstellen zu aktivieren, geben Sie all für interface-namean.

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:

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

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:

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

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:

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:

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.

Anmerkung:

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

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:

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:

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:

Um strikte zielgerichtete Hallo-Nachrichten zu aktivieren, fügen Sie die strict-targeted-hellos Anweisung ein:

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:

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:

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:

  1. Konfigurieren Sie die Geräteschnittstellen.

  2. Konfigurieren Sie das MPLS-Protokoll.

  3. Konfigurieren Sie das OSPF-Protokoll.

Um die längste Übereinstimmung für LDP zu konfigurieren, müssen Sie Folgendes tun:

  1. Konfigurieren Sie die längste Übereinstimmung für das LDP-Protokoll.
  2. Konfigurieren Sie das LDP-Protokoll auf der Schnittstelle.

    Zum Beispiel zur Konfiguration der Schnittstellen:

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.

Abbildung 1: Beispiel: Längste Übereinstimmung für LDPBeispiel: Längste Übereinstimmung für LDP

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

R1

R2

R3

R4

R5

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:

  1. Konfigurieren Sie die Schnittstellen.

  2. Weisen Sie dem Gerät die Loopback-Adressen zu.

  3. Konfigurieren Sie die Router-ID.

  4. Konfigurieren Sie das MPLS-Protokoll auf der Schnittstelle.

  5. Konfigurieren Sie das OSPF-Protokoll auf der Schnittstelle.

  6. Konfigurieren Sie die längste Übereinstimmung für das LDP-Protokoll.

  7. Konfigurieren Sie das LDP-Protokoll auf der Schnittstelle.

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.

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

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.

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.

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.

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.

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.

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:

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

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:

Sie können diese Anweisung auf den folgenden Hierarchieebenen einfügen:

  • [edit routing-options]

  • [edit logical-systems logical-system-name routing-options]

Anmerkung:

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:

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:

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:

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:

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:

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.

Tabelle 1: von Operatoren, die auf LDP-Filterung mit empfangenen Labeln angewendet werden

from Operator

Beschreibung

interface

Treffer bei Bindungen, die von einem Nachbarn empfangen werden, der über der angegebenen Schnittstelle nebeneinander liegt

neighbor

Treffer bei Bindungen, die von der angegebenen LDP-Router-ID empfangen wurden

next-hop

Treffer bei Bindungen, die von einem Nachbarn empfangen werden, der die angegebene Schnittstellenadresse angibt

route-filter

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:

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:

Von Router-ID 10.10.255.2 oder länger akzeptieren 131.108/16 und alle Präfixe von allen anderen Nachbarn akzeptieren:

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:

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.

Tabelle 2: an Betreiber für LDP-Outbound-Label-Filterung

zum Betreiber

Beschreibung

interface

Treffer bei Bindungen, die an einen Benachbarten über die angegebene Schnittstelle gesendet werden

neighbor

Treffer bei Bindungen, die an die angegebene LDP-Router-ID gesendet wurden

next-hop

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:

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:

Nur 131.108/16 oder länger an Router-ID 10.10.255.2senden und alle Präfixe an alle anderen Router senden:

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:

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

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-groupund 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:

  1. Unter [edit protocols ldp session] Hierarchie.

  2. Unter [edit protocols ldp session-group] Hierarchie.

  3. Unter [edit protocols ldp interfcae lo0] Hierarchie.

  4. Unter [edit protocols ldp] Hierarchie.

  5. Standardadresse.

Die Reihenfolge der Präferenz der Transportadresse für die entdeckten Nachbarn lautet wie folgt:

  1. Unter [edit protocols ldp interfcae] Hierarchie.

  2. Unter [edit protocols ldp] Hierarchie.

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

  1. Unter [edit protocols ldp interfcae lo0] Hierarchie.

  2. Unter [edit protocols ldp] Hierarchie.

  3. 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 des show 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:

  • 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:

Führen Sie im Falle einer fehlerhaften Konfiguration die folgenden Fehlerbehebungsaufgaben aus:

  • Überprüfen Sie die address family. Die Transportadresse, die unter der session Anweisung konfiguriert ist, muss zur gleichen Adressfamilie gehören wie der Nachbar oder die Sitzung.

  • Die Adresse, die als Transportadresse unter einer neighbor Oder-Anweisung session 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:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.

Anmerkung:

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.

Anmerkung:

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:

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:

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:

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:

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:

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:

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:

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]

Anmerkung:

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 den ping 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 die ecmp Option konfigurieren, müssen Sie auch die periodic-traceroute Anweisung für das angegebene FEC konfigurieren. Wenn Sie dies nicht tun, schlägt der Commit-Vorgang fehl. Sie können die periodic-traceroute Anweisung auf globaler Hierarchieebene[edit protocols ldp oam] () konfigurieren, während Sie nur die ecmp 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 die minimum-interval Option konfigurieren, müssen Sie die minimum-receive-interval Option oder die minimum-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.

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.

Anmerkung:

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-routefailure-action Anweisung ein:

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.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.

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.

Anmerkung:

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

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

Abbildung 12: MoFRR-BeispieltopologieMoFRR-Beispieltopologie

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.

Abbildung 13: MoFRR IP-Routensuche in der Packet Forwarding Engine auf RouternMoFRR IP-Routensuche in der Packet Forwarding Engine auf Routern
Abbildung 14: MoFRR IP-Routenbehandlung in der Packet Forwarding Engine auf SwitchesMoFRR IP-Routenbehandlung in der Packet Forwarding Engine auf Switches

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.

Abbildung 15: MoFRR MPLS-Routensuche in der Packet Forwarding EngineMoFRR MPLS-Routensuche in der Packet Forwarding Engine

Einschränkungen und Einschränkungen

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 wie Input packets und Output packetserwartet. 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:

  1. (Nur für Router der MX- und SRX-Serie) Stellen Sie den Router auf erweiterten IP-Modus ein.
  2. MoFRR aktivieren.
  3. (Optional) Konfigurieren Sie eine Routing-Richtlinie, die Filter für einen eingeschränkten Satz von Multicast-Streams filtert, um von Ihrer MoFRR-Konfiguration betroffen zu sein.

    Sie können Filter anwenden, die auf Quell- oder Gruppenadressen basieren.

    Zum Beispiel:

  4. (Optional) Wenn Sie eine Routing-Richtlinie konfiguriert haben, um den Satz von Multicastgruppen zu filtern, die von Ihrer MoFRR-Konfiguration betroffen sind, wenden Sie die Richtlinie für den MoFRR-Stream-Schutz an.

    Zum Beispiel:

  5. (Optional) Erlauben Sie in einer PIM-Domäne mit MoFRR die Anwendung von MoFRR auf Any-Source-Multicast-Joins (ASM) (*,G).

    Dies wird für Multipoint-LDP-MoFRR nicht unterstützt.

  6. (Optional) In einer PIM-Domäne mit MoFRR können als Backup-RPF-Pfad nur unzusammenhängende RPF (ein RPF auf einer separaten Ebene) ausgewählt werden.

    Dies wird für Multipoint-LDP-MoFRR nicht unterstützt. In einer Multipoint-LDP-MoFRR-Domäne wird dasselbe Label zwischen parallelen Verbindungen mit demselben upstreamen Nachbarn gemeinsam genutzt. Dies ist nicht in einer PIM-Domäne der Fall, bei der jede Verbindung einen Nachbarn bildet. Die mofrr-disjoint-upstream-only Anweisung erlaubt nicht, dass ein Backup-RPF-Pfad ausgewählt wird, wenn der Pfad zum selben Upstream-Nachbarn wie der des primären RPF-Pfads wechselt. So wird sichergestellt, dass MoFRR nur in einer Topologie mit mehreren RPF Upstream-Nachbarn ausgelöst wird.

  7. (Optional) Verhindern Sie in einer PIM-Domäne mit MoFRR das Senden von Join-Nachrichten auf dem Backup-Pfad, sondern behalten Sie alle anderen MoFRR-Funktionen.

    Dies wird für Multipoint-LDP-MoFRR nicht unterstützt.

  8. (Optional) In einer PIM-Domäne mit MoFRR können neue primäre Pfade anhand der Unicast-Gateway-Auswahl für die Unicastroute zur Quelle ausgewählt und bei Einer Änderung der Unicastauswahl geändert werden, anstatt dass der Backup-Pfad als primär heraufgestuft wird. Dadurch wird sichergestellt, dass der primäre RPF-Hop immer auf dem besten Pfad ist.

    Wenn Sie die mofrr-primary-selection-by-routing Anweisung einfügen, wird der Backup-Pfad nicht garantiert als der neue primäre Pfad hochgestuft, wenn der primäre Pfad abstürzt.

    Dies wird für Multipoint-LDP-MoFRR nicht unterstützt.

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 groupverwendet, 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:

Topologie

Abbildung 16 zeigt das Beispielnetzwerk.

Abbildung 16: MoFRR in einer Multipoint-LDP-DomäneMoFRR in einer Multipoint-LDP-Domäne

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

Gerät src2

Gerät R1

Gerät R2

Gerät R3

Gerät R4

Gerät R5

Gerät R6

Gerät R7

Gerät R8

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:

  1. Aktivieren Sie den erweiterten IP-Modus.

  2. Konfigurieren Sie die Geräteschnittstellen.

  3. Konfigurieren Sie die autonome Systemnummer (AS).

  4. Konfigurieren Sie die Routing-Richtlinien.

  5. PIM konfigurieren.

  6. LDP konfigurieren.

  7. Konfigurieren Sie ein IGP oder statische Routen.

  8. Konfigurieren Sie internes BGP.

  9. Konfigurieren Sie MPLS und optional RSVP.

  10. MoFRR aktivieren.

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration, indem Sie die show chassisBefehle , , show interfacesshow protocols, show policy-optionsund eingebenshow routing-options. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

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

Zweck

Stellen Sie sicher, dass moFRR aktiviert ist, und bestimmen Sie, welche Labels verwendet werden.

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

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:

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

  2. 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 diesem DOD-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.

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

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.

  1. Konfigurieren Sie die LDP-Routenrichtlinie (redistribute_ldp in diesem Beispiel).

  2. Fügen Sie die LDP-Routenrichtlinie redistribute_ldp in die BGP-Konfiguration ein (als Teil der Konfiguration der BGP-Gruppe ebgp-to-abr in diesem Beispiel).

    BGP leitet die LDP-Routen basierend auf der redistribute_ldp Richtlinie an den Remote-PE-Router weiter

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:

  1. Konfigurieren Sie die dod-routes Richtlinie, um Routen von LDP zu akzeptieren.

  2. Konfigurieren Sie die do-not-propagate-du-sessions Richtlinie, um Routen nicht an Nachbarn 1.1.1.1weiterzuleiten , 2.2.2.2und 3.3.3.3.

  3. Konfigurieren Sie die filter-dod-on-du-sessions Richtlinie, um zu verhindern, dass die von der dod-routes Richtlinie untersuchten Routen an die in der do-not-propagate-du-sessions Richtlinie definierten benachbarten Router weitergeleitet werden.

  4. Geben Sie die filter-dod-routes-on-du-sesssion Richtlinie als Exportrichtlinie für BGP-Broup an ebgp-to-abr.

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.

Ü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 der Adv. Mode (Label-Advertisement-Modus) ist DOD (d. h. die LDP-Downstream-On-Demand-Sitzung ist betriebsbereit):

  • Die folgende Befehlsausgabe für den show ldp session detail Befehl gibt an, dass der Local Label Advertisement modeDownstream unsolicitedStandardwert ist , der Standardwert (d. h. Downstream-on-Demand ist nicht auf der lokalen Sitzung konfiguriert). Umgekehrt geben sowohl die Remote Label Advertisement mode als auch die Negotiated Label Advertisement mode beiden Anzeigen an, dass die Downstream on demand Konfiguration auf der Remotesitzung

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:

  1. Ermöglichen Sie die Deaggregation der Forwarding Equivalence Class (FEC), um verschiedene Label für verschiedene Adressfamilien zu verwenden.
  2. Konfigurieren Sie LDP-Adressfamilien.
  3. Konfigurieren Sie die transport-preference Anweisung, um den bevorzugten Transport für die TCP-Verbindung auszuwählen, wenn IPv4 und IPv6 aktiviert sind. Standardmäßig wird IPv6 als TCP-Transport zum Herstellen einer LDP-Verbindung verwendet.
  4. (Optional) Konfigurieren Sie Dual-Transport, damit LDP eine separate IPv4-Sitzung mit einem IPv4-Nachbarn und eine IPv6-Sitzung mit einem IPv6-Nachbarn einrichten kann. Konfigurieren Sie inet-lsr-id als LSR-ID für IPv4 und inet6-lsr-id als LSR-ID für IPv6.

    Konfigurieren Sie beispielsweise inet-lsr-id als 10.255.0.1 und inet6-lsr-id als 10.1.1.1.

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.

Abbildung 17: Beispiel: LDP-native IPv6-UnterstützungBeispiel: LDP-native IPv6-Unterstützung

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 .

R1

R2

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:

  1. Konfigurieren Sie die Schnittstellen.

  2. Weisen Sie dem Gerät eine Loopback-Adresse zu.

  3. Konfigurieren Sie die IS-IS-Schnittstellen.

  4. Konfigurieren Sie MPLS für die Verwendung von LDP-Schnittstellen auf dem Gerät.

  5. Ermöglichen Sie die Deaggregation der Forwarding Equivalence Class (FEC), um verschiedene Label für verschiedene Adressfamilien zu verwenden.

  6. Konfigurieren Sie LDP-Adressfamilien.

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.

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.

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.

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.

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.

Überprüfung

Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

Abbildung 18: Label-Bindungen in M-LDP-SignalübertragungLabel-Bindungen in M-LDP-Signalübertragung
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.

Abbildung 19: Beispiel-M-LDP-Topologie in PIM-freiem MPLS-CoreBeispiel-M-LDP-Topologie in PIM-freiem MPLS-Core
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:

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.

Abbildung 20: Beispiel-M-LDP-Topologie im PIM-fähigen MPLS-CoreBeispiel-M-LDP-Topologie im PIM-fähigen MPLS-Core

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.

Anmerkung:

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:

Anmerkung:

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 der selected-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:

  1. Wenn die vorhandene statische Konfiguration die Quelladresse angibt, wird der Stamm wie in der Konfiguration angegeben genommen.

  2. 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)-Option

  • Nonstop 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

Anmerkung:

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.

Abbildung 21: M-LDP-In-Band-Signalübertragung für Point-to-Multipoint-LSPs BeispieltopologieM-LDP-In-Band-Signalübertragung für Point-to-Multipoint-LSPs Beispieltopologie

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

GeräteingressPE

Geräte-Ausgangs-PE

Gerät p6

Gerät pr3

Gerät pr4

Gerät pr5

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:

  1. Konfigurieren Sie die Schnittstellen.

    Aktivieren Sie MPLS an den Core-Schnittstellen. Bei den ausgangsnächsten Hops müssen Sie MPLS nicht aktivieren.

  2. Konfigurieren Sie IGMP an den Ausgangsschnittstellen.

    Zu Testzwecken enthält dieses Beispiel statische Gruppen- und Quelladressen.

  3. Konfigurieren Sie MPLS an den Core-Schnittstellen.

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

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

  6. OSPF konfigurieren.

  7. Konfigurieren Sie LDP an den Core-Schnittstellen und an der Loopback-Schnittstelle.

  8. Aktivieren Sie Point-to-Multipoint MPLS-LSPs.

  9. Konfigurieren Sie PIM an den downstreamen Schnittstellen.

  10. Konfigurieren Sie die RP-Einstellungen, da dieses Gerät als PIM-Rendezvouspunkt (RP) dient.

  11. Aktivieren Sie M-LDP-In-Band-Signalübertragung und legen Sie die zugehörige Richtlinie fest.

  12. Konfigurieren Sie die Routing-Richtlinie, die die Stammadresse für den Point-to-Multipoint-LSP und die zugehörigen Quelladressen angibt.

  13. Konfigurieren Sie die autonome System-ID (AS).

Ergebnisse

Bestätigen Sie Im Konfigurationsmodus Ihre Konfiguration durch Eingabe der show interfacesBefehle , , show protocolsshow policy-optionsundshow 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

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

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

Überprüfen der LDP-Datenbank
Zweck

Stellen Sie sicher, dass der show ldp database Befehl die erwarteten Root-to-(S,G)-Bindungen anzeigt.

Aktion
Suchen der Routeninformationen für das MPLS-Label
Zweck

Zeigen Sie die Punkt-zu-Multipoint-FEC-Informationen an.

Aktion
Überprüfen der LDP-Datenverkehrsstatistiken
Zweck

Überwachung der Datenverkehrsstatistiken für Point-to-Multipoint-LSP.

Aktion

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

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.

Abbildung 22: Beispiel-LDP-Topologie mit Interoperabilität des Segment-Routings mit LDP mit OSPFBeispiel-LDP-Topologie mit Interoperabilität des Segment-Routings mit LDP mit OSPF

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:

Anmerkung:

Die IP-Adresse, die start-prefix als Loopback-Adresse des Geräts im LDP-Netzwerk verwendet wird (Gerät R5 in diesem Beispiel).

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

Abbildung 23: Beispiel-LDP-Topologie mit Interoperabilität des Segment-Routing mit LDP mit ISISBeispiel-LDP-Topologie mit Interoperabilität des Segment-Routing mit LDP mit ISIS

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.

Abbildung 24: Stitching Segment-Routing und LDP-LSPsStitching Segment-Routing und LDP-LSPs

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

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:

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.

Anmerkung:

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:

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:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einfügen können, finden Sie im Abschnitt statement summary für diese Anweisung.

Anmerkung:

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:

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:

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]

Anmerkung:

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:

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.

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.

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.

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:

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:

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:

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:

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:

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]

Anmerkung:

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:

Sie können diese Anweisung auf den folgenden Hierarchieebenen konfigurieren:

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

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:

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

Die folgende Beispielausgabe stammt aus einer LDP-Statistikdatei:

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, entweder Ingress (von diesem Router stammend) oder Transit (ü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— Ein Yes 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:

Eine Liste der Hierarchieebenen, auf denen Sie die traffic-statistics Anweisung konfigurieren können, finden Sie im Abschnitt statement summary für diese Anweisung.

Anmerkung:

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:

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

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:

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 der address, initialization, label, notificationund periodic Modifizierer.

    Sie können den filter Flag-Modifikator auch mit der match-on address Unteroption für das packets 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, pathund binding.

Im folgenden Beispiel wird veranschaulicht, wie Sie die LDP-Anweisung so konfigurieren, dass LDP-Trace-Anweisungen traceoptions basierend auf einem FEC gefiltert werden:

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

  • Die einzige match-on Option ist fec. Daher sollten Sie nur eine Richtlinie zum Routenfiltern verwenden.

Beispiele: Verfolgen des LDP-Protokolldatenverkehrs

Detaillierte Verfolgung von LDP-Pfadmeldungen:

Verfolgen Sie alle ausgehenden LDP-Nachrichten:

Verfolgen Sie alle LDP-Fehlerbedingungen:

Verfolgen Sie alle eingehenden LDP-Nachrichten und alle Label-Binding-Vorgänge:

Trace-LDP-Protokolldatenverkehr für ein FEC, das mit dem LSP verknüpft ist:

Release-Verlaufstabelle
Release
Beschreibung
19.1
Ab Junos OS-Version 19.1R1 kann der Segment-Routing-LDP-Border-Router den Segment-Routing-Datenverkehr mit LDP Next-Hop verbinden und umgekehrt.
16.1R1
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.
16.1
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.
14.1
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.