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 der MPLS-Familie. Im Fall von gerichteten LDP muss die Loopback-Schnittstelle mit der Familie MPLS aktiviert werden.

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

  3. Aktivieren Sie LDP auf einer einzigen Schnittstelle, schließen 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-name.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung.

Aktivieren und Deaktivieren von LDP

LDP ist Routing-Instanz-aware. Um LDP auf einer bestimmten Schnittstelle zu aktivieren, fügen Sie die folgenden Anweisungen ein:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung.

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

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 Folgenden Option ein disable :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Zusammenfassung der Anweisung.

Konfigurieren des LDP-Timers für Hallo-Nachrichten

LDP-Hallo-Meldungen ermöglichen es LDP-Knoten, sich gegenseitig zu erkennen und den Ausfall eines Nachbarn oder der Verbindung zum Nachbarn zu erkennen. Hallo Nachrichten werden regelmäßig auf allen Schnittstellen gesendet, auf denen LDP aktiviert ist.

Es gibt zwei Arten von LDP Hallo Nachrichten:

  • Hallo-Verbindungen: Wird über die LDP-Schnittstelle als UDP-Pakete gesendet, die an den LDP-Erkennungsport adressiert sind. Der Erhalt eines LDP-Links Hallo-Nachricht auf einer Schnittstelle identifiziert eine Verbindung mit dem LDP-Peer-Router.

  • Gezielte Hallo-Nachrichten: Gesendet als UDP-Pakete, die an den LDP-Discovery-Port an einer bestimmten Adresse adressiert sind. Gezielte Hallo-Nachrichten werden verwendet, um LDP-Sitzungen zwischen Routern zu unterstützen, die nicht direkt verbunden sind. Ein zielorientierter Router bestimmt, ob eine gezielte Hallo-Nachricht reagiert oder ignoriert werden soll. Ein zielorientierter Router, der darauf reagiert, tut dies, indem er in regelmäßigen Abständen gezielte Hallo-Nachrichten zurück an den initialen Router sendet.

Standardmäßig sendet LDP alle 5 Sekunden Hallo-Nachrichten für Link Hello-Nachrichten und alle 15 Sekunden für gezielte Hallo-Nachrichten. Sie können den LDP-Timer konfigurieren, um zu ändern, wie oft beide Arten von Hallo-Nachrichten gesendet werden. Sie können jedoch keine Zeit für den LDP-Timer konfigurieren, der größer ist als die LDP-Haltezeit. Weitere Informationen finden Sie unter Konfigurieren der Verzögerung, bevor LDP-Nachbarn berücksichtigt werden.

Konfigurieren des LDP-Timers für Link Hallo Nachrichten

Um zu ändern, wie oft LDP Link-Hallo-Nachrichten sendet, geben Sie mithilfe der Anweisung ein neues Link Hello Message-Intervall für den LDP-Timer hello-interval an:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Konfigurieren des LDP-Timers für gezielte Hallo-Nachrichten

Um zu ändern, wie oft LDP gezielte Hallo-Nachrichten sendet, geben Sie ein neues Zielintervall für die Hallo-Nachricht 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 einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.

Konfigurieren der Verzögerung, bevor LDP-Nachbarn berücksichtigt werden

Die Haltezeit bestimmt, wie lange ein LDP-Knoten auf eine Hallo-Nachricht warten sollte, bevor er einen Nachbarn zum Ausfall erklärt. Dieser Wert wird als Teil einer Hallo-Nachricht gesendet, sodass jeder LDP-Knoten seinen Nachbarn sagt, wie lange zu warten ist. Die von jedem Nachbarn gesendeten Werte müssen nicht übereinstimmen.

Die Haltezeit sollte normalerweise mindestens das Dreifache des Hallo-Intervalls sein. Die Standardeinstellung beträgt 15 Sekunden für "Link Hello"-Nachrichten und 45 Sekunden für gezielte Hallo-Nachrichten. Es ist jedoch möglich, eine LDP-Haltezeit zu konfigurieren, die nahe am Wert für das Hello-Intervall liegt.

HINWEIS:

Durch die Konfiguration einer LDP-Haltezeit nahe dem Hallo-Intervall (weniger als das Dreifache des Hallo-Intervalls) können LDP-Nachbarn-Fehler schneller erkannt werden. Dies erhöht jedoch auch die Möglichkeit, dass der Router einen LDP-Nachbarn deklariert, der noch normal funktioniert. Weitere Informationen finden Sie unter Konfigurieren des LDP-Timers für Hallo-Nachrichten.

Die LDP-Haltezeit wird auch automatisch zwischen LDP-Peers ausgehandelt. Wenn zwei LDP-Peers unterschiedliche LDP-Haltezeiten ankündigen, wird der kleinere Wert verwendet. Wenn ein LDP-Peer-Router eine kürzere Haltezeit als den von Ihnen konfigurierten Wert ankündigt, wird die angekündigte Haltezeit des Peer-Routers verwendet. Diese Aushandlung kann sich auch auf das LDP-Keepalive-Intervall auswirken.

Wenn die lokale LDP-Haltezeit während der LDP-Peer-Aushandlung nicht verkürzt wird, bleibt das vom Benutzer konfigurierte Keepalive-Intervall unverändert. Wenn jedoch die lokale Haltezeit während der Peer-Aushandlung verkürzt wird, wird das Keepalive-Intervall neu berechnet. Wenn die LDP-Haltezeit während der Peer-Aushandlung reduziert wurde, wird das Keepalive-Intervall auf ein Drittel des neuen Haltezeitwerts reduziert. Wenn der neue Haltezeitwert beispielsweise 45 Sekunden beträgt, wird das Keepalive-Intervall auf 15 Sekunden festgelegt.

Diese automatisierte Keepalive-Intervallberechnung 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 Haltezeitintervall 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 abgelaufen ist (gemäß RFC 5036, LDP-Spezifikation erforderlich). Um das Zurücksetzen der LDP-Sitzung manuell zu erzwingen, erteilen Sie den clear ldp session Befehl.

Konfigurieren der LDP-Haltezeit für Link Hallo Nachrichten

Um zu ändern, wie lange ein LDP-Knoten auf eine Link hallo-Nachricht warten soll, bevor er den Nachbarn deklariert, geben Sie mithilfe der hold-time Anweisung einen neuen Zeitpunkt in Sekunden an:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Konfigurieren der LDP-Haltezeit für gezielte Hallo-Nachrichten

Um zu ändern, wie lange ein LDP-Knoten vor dem Deklarieren des Nachbarn auf eine gezielte Hallo-Nachricht warten soll, geben Sie einen neuen Zeitpunkt 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 einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.

Ermöglichung strenger gezielter Hallo-Nachrichten für LDP

Verwenden Sie strenge gezielte Hallo-Meldungen, 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 Hallo-Nachrichten, die von einer Quelle stammen, die nicht zu ihren konfigurierten Remote-Nachbarn gehört. Konfigurierte Remote-Nachbarn können folgendes umfassen:

  • Endgeräte von RSVP-Tunneln, für die LDP-Tunneling konfiguriert ist

  • Layer-2-Circuit Neighbors

Wenn ein nicht konfigurierter Nachbar eine Hallo-Nachricht sendet, ignoriert der LDP-Peer die Nachricht und protokolliert (mit dem Trace-Flag) einen Fehler, der error die Quelle anzeigt. Wenn beispielsweise der LDP-Peer ein gezieltes Hallo von der Internetadresse 10.0.0.1 erhalten hat und kein Nachbar mit dieser Adresse speziell konfiguriert ist, wird die folgende Meldung in die LDP-Protokolldatei gedruckt:

Um strikte gezielte Hallo-Nachrichten zu ermöglichen, fügen Sie die Anweisung ein strict-targeted-hellos :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Konfigurieren des Intervalls für LDP-Keepalive-Nachrichten

Das Keepalive-Intervall bestimmt, wie oft eine Nachricht über die Sitzung gesendet wird, um sicherzustellen, dass der keepalive Timeout nicht überschritten wird. Wenn in so viel Zeit kein anderer LDP-Datenverkehr über die Sitzung gesendet wird, wird eine Keepalive-Nachricht gesendet. Der Standard ist 10 Sekunden. Der Mindestwert ist 1 Sekunde.

Der für das Keepalive-Intervall konfigurierte Wert kann während der LDP-Sitzungsverhandlungen geändert werden, wenn der für die LDP-Haltezeit auf dem Peer-Router konfigurierte Wert niedriger ist als der lokal konfigurierte Wert. Weitere Informationen finden Sie unter Konfigurieren der Verzögerung, bevor LDP-Nachbarn berücksichtigt werden.

Um das Keepalive-Intervall zu ändern, fügen Sie die Anweisung ein keepalive-interval :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Konfigurieren des LDP Keepalive Timeouts

Nachdem eine LDP-Sitzung eingerichtet wurde, müssen regelmäßig Nachrichten ausgetauscht werden, um sicherzustellen, dass die Sitzung noch funktioniert. Der Keepalive Timeout definiert die Zeitdauer, die der benachbarte LDP-Knoten wartet, bevor er entscheidet, dass die Sitzung fehlgeschlagen ist. Dieser Wert wird normalerweise auf das Dreifache des Keepalive-Intervalls festgelegt. Die Standardeinstellung ist 30 Sekunden.

Um das Keepalive-Intervall zu ändern, fügen Sie die Anweisung ein keepalive-timeout :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Der für die keepalive-timeout Anweisung konfigurierte Wert wird bei der Ausgabe des show ldp session detail Befehls als Haltezeit angezeigt.

Konfigurieren der längsten Übereinstimmung für LDP

Damit LDP lernen kann, welche Routen über OSPF-Bereiche oder ISIS-Ebenen in domänenübergreifenden Bereichen aggregiert oder zusammengefasst wurden, können Sie mit Junos OS basierend auf RFC5283 die längste Übereinstimmung für LDP konfigurieren.

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 die folgenden Schritte ausführen:

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

    Um beispielsweise die Schnittstellen zu konfigurieren,

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 lernen, welche Routen über OSPF-Bereiche oder ISIS-Ebenen in inter-Domain aggregiert oder zusammengefasst werden. Die Richtlinie für die längste Übereinstimmung bietet granulare Präfixe.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Sechs Router der MX-Serie mit OSPF-Protokoll und aktivierter 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.

  • Konfigurieren Sie OSPF.

Überblick

LDP wird häufig verwendet, um MPLS Label-Switched Paths (LSPs) in einer gesamten Netzwerkdomäne unter Verwendung einer IGP wie OSPF oder IS-IS einzurichten. In einem solchen Netzwerk haben alle Links in der Domain IGP-Verbindungen sowie LDP-Verbindungen. LDP ermittelt die LSPs auf dem kürzesten Pfad zu einem Ziel, der durch IP-Weiterleitung ermittelt wird. 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 genaue 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 Standard-Routings in Zugriffsgeräten verloren. Die Konfiguration longest-match hilft, dies zu überwinden, indem das genaue Übereinstimmungsverhalten unterdrückt wird und LSP basierend auf der längsten Übereinstimmungsroute pro Präfix eingerichtet wird.

Topologie

In der Topologie zeigt, Abbildung 1dass die längste Übereinstimmung für LDP auf Gerät R0 konfiguriert wurde.

Abbildung 1: Beispiel Longest Match für LDPBeispiel Longest Match für LDP

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie 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 auf 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, indem Sie die show interfacesBefehle und show routing-optionsshow protocolsdie Befehle eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .

Überprüfung

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

Verifizieren der Routen

Zweck

Stellen Sie sicher, dass die erwarteten Routen gelernt wurden.

Aktion

Führen Sie auf Gerät R0 im Betriebsmodus den show route Befehl aus, um die Routen in der Routing-Tabelle anzuzeigen.

Bedeutung

Die Ausgabe zeigt alle Routen in der Routing-Tabelle von Gerät R0.

LDP überprüfen – Übersichtsinformationen

Zweck

LDP-Übersichtsinformationen anzeigen.

Aktion

Führen Sie auf Gerät R0 aus dem Betriebsmodus den show ldp overview Befehl aus, um die Übersicht der LDP anzuzeigen.

Bedeutung

Die Ausgabe zeigt die LDP-Übersichtsinformationen des Geräts R0 an

Überprüfen der LDP-Einträge in der Tabelle "Interne Topologie"

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 der 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 Routing-Tabelle anzuzeigen.

Bedeutung

Die Ausgabe zeigt nur die FEC-Routen des LDP-Protokolls an, die für Gerät R0 verfügbar sind.

FEC- und Shadow-Routen von LDP überprüfen

Zweck

Zeigen Sie den FEC und die Schattenrouten in der Routing-Tabelle an.

Aktion

Führen Sie auf Gerät R0 im Betriebsmodus den show ldp route fec-and-route Befehl aus, um die FEC- und Shadow-Routen in der Routing-Tabelle anzuzeigen.

Bedeutung

Die Ausgabe zeigt den FEC und die Schattenrouten des Geräts R0 an.

Konfigurieren von LDP-Routeneinstellungen

Wenn mehrere Protokolle Routen zum selben Ziel berechnen, werden Routenvoreinstellungen verwendet, um auszuwählen, welche Route in der Weiterleitungstabelle installiert ist. Die Route mit dem niedrigsten Vorzugswert wird ausgewählt. Der Voreinstellungswert kann eine Zahl im Bereich 0 bis 255 sein. Standardmäßig haben LDP-Routen den Vorzugswert 9.

Um die Routeneinstellungen zu ändern, fügen Sie die Anweisung ein preference :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

LDP Graceful Restart

LDP Graceful Restart ermöglicht es einem Router, dessen LDP-Steuerungsebene einen Neustart durchläuft, den Datenverkehr weiterzuleiten und gleichzeitig seinen Zustand von benachbarten Routern wiederherzustellen. Außerdem ermöglicht es einem Router, auf dem der Hilfsmodus aktiviert ist, einen benachbarten Router zu unterstützen, der versucht, LDP neu zu starten.

Während der Sitzungsinitialisierung kündigt ein Router an, dass er LDP graceful Restart durchführen kann oder die Vorteile eines Nachbarn, der LDP Graceful Restart ausführt, indem er den graceful Restart sendet TLV. Diese TLV enthält zwei Felder, die für LDP Graceful Restart relevant sind: die Zeit für die Erneute Verbindung und die Wiederherstellungszeit. Die Werte der Wiederverbindungs- und Wiederherstellungszeiten zeigen die graceful Restart-Funktionen an, die vom Router unterstützt werden.

Wenn ein Router feststellt, dass ein benachbarter Router neu gestartet wird, wartet er bis zum Ende der Wiederherstellungszeit, bevor er versucht, eine Verbindung herzustellen. Die Wiederherstellungszeit ist die Dauer, in der ein Router wartet, bis LDP ordnungsgemäß neu gestartet wird. Der Wiederherstellungszeitraum beginnt, wenn eine Initialisierungsnachricht gesendet oder empfangen wird. Dieser Zeitraum ist in der Regel auch die Dauer, in der ein benachbarter Router seine Informationen über den neustartenden Router speichert, sodass er weiterhin Datenverkehr weiterleiten kann.

Sie können LDP Graceful Restart sowohl in der Master-Instanz für das LDP-Protokoll als auch für eine bestimmte Routing-Instanz konfigurieren. Sie können den graceful Restart auf globaler Ebene für alle Protokolle, auf Protokollebene nur für LDP und auf einer bestimmten Routing-Instanz deaktivieren. LDP Graceful Restart ist standardmäßig deaktiviert, da auf globaler Ebene graceful Restart standardmäßig deaktiviert ist. Der Hilfsmodus (die Möglichkeit, einen benachbarten Router bei einem graceful Restart zu unterstützen) ist jedoch standardmäßig aktiviert.

Im Folgenden sind einige der Verhaltensweisen, die mit LDP Graceful Restart verbunden sind:

  • Ausgehende Label werden bei Neustarts nicht beibehalten. Neue ausgehende Label werden zugewiesen.

  • Wenn ein Router neu gestartet wird, werden keine Label-Map-Meldungen an Nachbarn gesendet, die einen graceful Restart unterstützen, bis sich der neustartende Router stabilisiert hat (Label-Map-Meldungen werden sofort an Nachbarn gesendet, die graceful Restart nicht unterstützen). Alle anderen Nachrichten (Keepalive, Adressnachricht, Benachrichtigung und Freigabe) werden jedoch wie gewohnt versendet. Die Verteilung dieser anderen Nachrichten verhindert, dass der Router unvollständige Informationen weiterverteilt.

  • Hilfsmodus und graceful Restart sind unabhängig. Sie können den graceful Restart in der Konfiguration deaktivieren, aber dennoch zulassen, dass der Router mit einem Nachbarn zusammenarbeiten kann, der versucht, graceful neu zu starten.

Konfiguration von LDP Graceful Restart

Wenn Sie die Graceful-Restart-Konfiguration auf der [edit routing-options graceful-restart] Hierarchie- oder [edit protocols ldp 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-Hilfsmodus aktiviert, aber graceful restart ist deaktiviert. Daher besteht das Standardverhalten eines Routers darin, benachbarte Router zu unterstützen, einen graceful-Neustart zu versuchen, nicht aber einen graceful Restart selbst zu versuchen.

Informationen zur Konfiguration von LDP Graceful Restart finden Sie in den folgenden Abschnitten:

Aktivierung von Graceful Restart

Um LDP Graceful Restart zu aktivieren, müssen Sie auch einen graceful-Neustart auf dem Router aktivieren. Um einen graceful-Neustart zu ermöglichen, fügen Sie die Anweisung ein graceful-restart :

Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:

  • [edit routing-options]

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

HINWEIS:

Router der ACX-Serie unterstützen keine [edit logical-systems logical-system-name routing-options] Hierarchieebene.

Die graceful-restart Anweisung ermöglicht einen graceful Restart für alle Protokolle, die diese Funktion auf dem Router unterstützen. Weitere Informationen zum graceful Restart finden Sie in der Junos OS Routing Protocol Library for Routing Devices.

Standardmäßig ist LDP Graceful Restart aktiviert, wenn Sie einen graceful Restart sowohl auf LDP-Protokollebene als auch auf allen Routing-Instanzen aktivieren. Sie können jedoch sowohl den LDP Graceful Restart als auch den LDP Graceful Restart Hilfsmodus deaktivieren.

Deaktivieren des LDP Graceful Restart oder Hilfsmodus

Um LDP graceful Restart and Recovery zu deaktivieren, fügen Sie die Anweisung ein disable :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Sie können den Hilfsmodus nur auf LDP-Protokollebene deaktivieren. Sie können den Hilfsmodus für eine bestimmte Routing-Instanz nicht deaktivieren. Um den LDP-Hilfsmodus zu deaktivieren, fügen Sie die Anweisung ein helper-disable :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Folgende LDP-Graceful-Restart-Konfigurationen sind möglich:

  • LDP Graceful Restart und Hilfsmodus sind beide aktiviert.

  • LDP Graceful Restart ist deaktiviert, aber der Hilfsmodus ist aktiviert. Ein auf diese Weise konfigurierter Router kann nicht ordnungsgemäß neu gestartet werden, sondern kann einem neustartenden Nachbarn helfen.

  • LDP Graceful Restart und Hilfsmodus sind beide deaktiviert. Der Router verwendet nicht LDP Graceful Restart oder den graceful Restart Typ, Länge und Wert (TLV), der in der Initialisierungsnachricht gesendet wird. Der Router verhält sich wie ein Router, der LDP Graceful Restart nicht unterstützen kann.

Wenn Sie versuchen, einen graceful Restart zu aktivieren und den Hilfsmodus zu deaktivieren, wird ein Konfigurationsfehler ausgegeben.

Konfigurieren der Zeit für die erneute Verbindung

Nachdem die LDP-Verbindung zwischen Nachbarn fehlschlägt, warten Nachbarn eine gewisse Zeit darauf, dass der Router ordnungsgemäß neu gestartet wird, um wieder LDP-Nachrichten zu senden. Nach der Wartezeit kann die LDP-Sitzung erneut aufgebaut werden. Sie können die Wartezeit in Sekunden konfigurieren. Dieser Wert ist in der fehlertoleranten Sitzung enthalten TLV in LDP-Initialisierungsmeldungen gesendet, wenn LDP Graceful Restart aktiviert ist.

Nehmen wir an, Router A und Router B sind LDP-Nachbarn. Router A ist der neu gestartete Router. Die Zeit für die erneute Verbindung ist der Zeitpunkt, zu dem Router A Router B angibt, zu warten, nachdem Router B feststellt, dass Router A neu gestartet wurde.

Um die Zeit für die erneute Verbindung zu konfigurieren, fügen Sie die Anweisung ein reconnect-time :

Sie können die Zeit für die erneute Verbindung auf einen Wert im Bereich von 30 bis 300 Sekunden festlegen. Standardmäßig beträgt dies 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.

Konfigurieren der Wiederherstellungszeit und der maximalen Wiederherstellungszeit

Die Wiederherstellungszeit ist die Zeit, die ein Router wartet, bis LDP ordnungsgemäß 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 neu gestarteten Router speichert, sodass er weiterhin Datenverkehr weiterleiten kann.

Um zu verhindern, dass ein benachbarter Router beeinträchtigt wird, wenn er einen falschen Wert für die Wiederherstellungszeit vom neustartenden Router erhält, können Sie die maximale Wiederherstellungszeit für den benachbarten Router konfigurieren. Ein benachbarter Router behält seinen Zustand für den kürzeren der beiden Male bei. Router A führt beispielsweise einen LDP-Graceful-Neustart durch. Es hat eine Wiederherstellungszeit von 900 Sekunden an den benachbarten Router B gesendet. Router B hat jedoch seine maximale Wiederherstellungszeit mit 400 Sekunden konfiguriert. Router B wartet nur 400 Sekunden, bevor er seine LDP-Informationen von Router A löscht.

Um die Wiederherstellungszeit zu konfigurieren, fügen Sie die recovery-time Anweisung und die Anweisung ein maximum-neighbor-recovery-time :

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 Bindungen zu akzeptieren oder zu verweigern, die von benachbarten Routern angekündigt wurden. Um die Filterung empfangener Label zu konfigurieren, fügen Sie die Anweisung ein import :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Die benannte Richtlinie (konfiguriert auf Hierarchieebene [edit policy-options] ) wird auf alle Labelbindungen angewendet, die von allen LDP-Nachbarn empfangen werden. Alle Filter werden mit from Anweisungen durchgeführt. Tabelle 1 Liste der einzigen from Operatoren, die für die LDP-Filterung mit empfangenen Labeln gelten.

Tabelle 1: von Betreibern, die für die LDP-Empfangen-Label-Filterung gelten

from Operator

Beschreibung

interface

Übereinstimmung mit Bindungen, die von einem Nachbarn empfangen werden, der über die angegebene Schnittstelle angrenzt

neighbor

Übereinstimmungen bei Bindungen, die von der angegebenen LDP-Router-ID empfangen werden

next-hop

Übereinstimmungen auf Bindungen, die von einem Nachbarn empfangen wurden, und werben mit der angegebenen Schnittstellenadresse

route-filter

Übereinstimmung bei Bindungen mit dem angegebenen Präfix

Wenn eine Bindung gefiltert wird, wird sie weiterhin in der LDP-Datenbank angezeigt, wird aber für die Installation nicht als Teil eines Label-Switched Path (LSP) berücksichtigt.

Im Allgemeinen kann die Anwendung von Richtlinien in LDP nur verwendet werden, um die Einrichtung von LSPs zu blockieren, nicht um deren Routing zu steuern. Dies liegt daran, dass der Pfad, dem 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 die LDP-Filterung verwenden, um einige der möglichen nächsten Hops von der Prüfung auszuschließ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 gibt nur Label pro Router (nicht pro Schnittstelle) an; Wenn also mehrere parallele Verbindungen zwischen zwei Routern vorhanden sind, wird nur eine LDP-Sitzung eingerichtet, die nicht an eine einzige Schnittstelle gebunden ist. Wenn ein Router mehrere Nachbarschaften zumselben Nachbarn hat, achten Sie darauf, dass der Filter das tut, was erwartet wird. (Im Allgemeinen ist die Verwendung next-hop und interface in diesem Fall nicht angemessen.)

Wenn ein Label gefiltert wurde (d. h. 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 Policers.

Beispiele: Filtern eingehender LDP-Label-Bindungen

Akzeptieren Sie nur /32 Präfixe von allen Nachbarn:

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

Filterung ausgehender LDP-Label-Bindungen

Sie können Exportrichtlinien konfigurieren, um LDP-ausgehende Label zu filtern. Sie können ausgehende Labelbindungen filtern, indem Sie Routing-Richtlinien anwenden, um Bindungen zu blockieren, die an benachbarten Routern angekündigt werden. Um die Filterung ausgehender Label zu konfigurieren, fügen Sie die Anweisung ein export :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Die benannte Exportrichtlinie (konfiguriert auf Hierarchieebene [edit policy-options] ) wird auf alle Labelbindungen angewendet, die an alle LDP-Nachbarn übertragen werden. Der einzige from Operator, der für die LDP-Filterung ausgehender Label gilt, ist route-filter, der Bindungen mit dem angegebenen Präfix abschließt. Die einzigen to Betreiber, die für die Filterung ausgehender Label gelten, sind die Operatoren in Tabelle 2.

Tabelle 2: zu Betreibern für LDP-Outbound-Label-Filterung

zum Betreiber

Beschreibung

interface

Übereinstimmungen bei Bindungen, die an einen Nachbarn gesendet werden, der über die angegebene Schnittstelle grenzt

neighbor

Übereinstimmungen bei Bindungen, die an die angegebene LDP-Router-ID gesendet werden

next-hop

Übereinstimmungen bei Bindungen, die an einen Nachbarn gesendet werden, werben mit der angegebenen Schnittstellenadresse

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, dem ein LSP folgt, 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, die nicht an eine einzige Schnittstelle gebunden ist.

Verwenden Sie die next-hop Und-Betreiber interface nicht, wenn ein Router mehrere Nachbarschaften zum selben Nachbarn hat.

Gefilterte Label 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 Policers.

Beispiele: Filterung ausgehender LDP-Label-Bindungen

Blockieren Sie die Übertragung der Route für 10.10.255.6/32 alle Nachbarn:

Senden Sie nur 131.108/16 oder länger an die Router-ID 10.10.255.2und senden Sie alle Präfixe an alle anderen Router:

Angeben 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-Ankündigungen auszutauschen. Um die TCP-Sitzung einzurichten, muss jeder Router die Transportadresse des anderen Routers kennen. Die Transportadresse ist eine IP-Adresse, die zur Identifizierung der TCP-Sitzung verwendet wird, über die die LDP-Sitzung ausgeführt wird.

Um die LDP-Transportadresse zu konfigurieren, fügen Sie die Transport-Address-Anweisung ein:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Wenn Sie die router-id Option angeben, wird die Adresse des Router-Identifikators als Transportadresse verwendet (sofern nicht anders konfiguriert, ist der Routerbezeichner in der Regel dieselbe wie die 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.

HINWEIS:

Für einen ordnungsgemäßen Betrieb muss die LDP-Transportadresse erreichbar sein. Die Router-ID ist eine Kennung, keine routingfähige IP-Adresse. Aus diesem Grund wird empfohlen, die Router-ID so zu setzen, dass sie mit der Loopback-Adresse übereinstimmt, und dass die Loopback-Adresse von der IGP angekündigt wird.

Sie können die interface Option nicht angeben, wenn mehrere parallele Verbindungen zu einem 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 zu demselben Nachbarn erkennt, deaktiviert es die Schnittstellen zu diesem Nachbarn nacheinander, bis die Bedingung deaktiviert wird, entweder durch Trennen des Nachbarn auf einer Schnittstelle oder durch Festlegen der router-id Option.

Für zielgerichtete LDP-Sitzung verwendete Übertragungsadresse

Um eine TCP-Sitzung zwischen zwei Geräten einzurichten, muss jedes Gerät die Transportadresse des anderen Geräts kennen. Die Transportadresse ist eine IP-Adresse, die zur Identifizierung der TCP-Sitzung verwendet wird, über die die LDP-Sitzung betrieben wird. Früher konnte es sich bei dieser Transportadresse nur um die Router-ID oder eine Schnittstellenadresse handeln. Mit der LDP-Übertragungsadressenfunktion können Sie explizit jede beliebige IP-Adresse als Transportadresse für gezielte LDP-Nachbarn für Layer-2-Circuit-, MPLS- und VPLS-Adjacencies konfigurieren. Auf diese Weise können Sie die Ziel-LDP-Sitzungen über die Transport-Adresskonfiguration steuern.

Vorteile der Kontrolle von Transportadressen, die für zielgerichtete LDP-Sitzung verwendet werden

Die Konfiguration der Transportadresse für die Einrichtung gezielter 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 Ziel-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-Transportadressen

Vor Junos OS Version 19.1R1 unterstützte LDP nur Router-ID oder die Schnittstellenadresse als Transportadresse auf einer LDP-Schnittstelle. Die auf dieser Schnittstelle gebildeten Adjacencies verwendeten eine der der Schnittstelle zugewiesene IP-Adresse oder die Router-ID. Im Falle einer gezielten Nachbarschaft ist die Schnittstelle die Loopback-Schnittstelle. Wenn mehrere Loopback-Adressen auf dem Gerät konfiguriert wurden, konnte die Transportadresse für die Schnittstelle nicht abgeleitet werden, und infolgedessen konnte die LDP-Sitzung nicht eingerichtet werden.

Ab Junos OS Version 19.1R1 können Sie zusätzlich zu den Standard-IP-Adressen, die für die Transportadresse von Ziel-LDP-Sitzungen verwendet werden, jede andere IP-Adresse als Transportadresse unter den session, session-groupund interface Konfigurationsanweisungen konfigurieren. Die Konfiguration der Transportadresse ist nur für konfigurierte Nachbarn anwendbar, einschließlich Layer-2-Circuits, MPLS und VPLS-Adjacencies. Diese Konfiguration gilt nicht für erkannte Adjacencies (gezielt oder nicht).

Bevorzugte Transportadresse

Sie können die Transportadresse für zielgerichtete LDP-Sitzungen auf Sitzungs-, Sitzungsgruppen- und Schnittstellenebene konfigurieren.

Nach der Konfiguration der Transportadresse wird die Ziel-LDP-Sitzung basierend auf der Bevorzugten Transportadresse von LDP eingerichtet.

Die Reihenfolge der bevorzugten Transportadresse für den Zielnachbarn (konfiguriert über Layer-2-Circuit, MPLS-, VPLS- und LDP-Konfiguration) ist 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 Bevorzugte Reihenfolge 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 bevorzugten Transportadresse für automatisch zielgerichtete Nachbarn, bei denen LDP so konfiguriert ist, dass es Hallo-Pakete akzeptiert, lautet wie folgt:

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

  2. Unter [edit protocols ldp] Hierarchie.

  3. Standardadresse.

Fehlerbehebung bei der Konfiguration von Transportadressen

Sie können die folgenden Show-Befehlsausgaben verwenden, um die Fehlerbehebung für zielgerichtete 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 Hallo-Nachrichten an den Zielnachbarn gesendet wird. Wenn diese Adresse vom Nachbarn nicht erreichbar ist, wird die LDP-Sitzung nicht angezeigt.

  • show configuration protocols ldp

Sie können auch LDP-Traceoptionen für die weitere Fehlerbehebung aktivieren.

  • Wenn die Konfiguration von der Verwendung einer ungültigen (nicht erreichbaren) Transportadresse zur gültigen Transportadresse geändert wird, können die folgenden Ablaufverfolgungen beobachtet werden:

  • Wenn die Konfiguration von der Verwendung einer gültigen Transportadresse auf eine ungültige (nicht erreichbare Transportadresse) geändert wird, können die folgenden Ablaufverfolgungen beobachtet werden:

Führen Sie bei 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 session Anweisung konfiguriert ist, muss lokal beim Router sein, damit die zielgerichteten Hallo-Nachrichten gestartet werden. Sie können überprüfen, ob die Adresse konfiguriert ist. Wenn die Adresse unter keiner Schnittstelle konfiguriert ist, wird die Konfiguration abgelehnt.

Konfigurieren der in LDP aus der Routing-Tabelle angekündigten Präfixe

Sie können die Gruppe der Präfixe steuern, die in LDP angekündigt werden, und den Router als Ausgangsrouter für diese Präfixe zu veranlassen. Standardmäßig wird nur die Loopback-Adresse in LDP angekündigt. Um den Satz der Präfixe aus der Routing-Tabelle zu konfigurieren, die in LDP angekündigt werden sollen, fügen Sie die Anweisung ein egress-policy :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

HINWEIS:

Wenn Sie eine Ausgangsrichtlinie für LDP konfigurieren, die die Loopback-Adresse nicht enthält, wird diese in LDP nicht mehr angekündigt. Um die Loopback-Adresse weiterhin anzukündigen, müssen Sie sie explizit als Teil der LDP-Ausgangsrichtlinie konfigurieren.

Die benannte Richtlinie (konfiguriert auf Hierarchieebene [edit policy-options][edit logical-systems logical-system-name policy-options] ) wird auf alle Routen in der Routingtabelle angewendet. Die Routen, die der Richtlinie entsprechen, werden in LDP angekündigt. Sie können die Gruppe der Nachbarn steuern, für die diese Präfixe angekündigt werden, indem Sie die export Anweisung verwenden. Es werden nur from Betreiber in Betracht gezogen; Sie können einen beliebigen gültigen from Betreiber verwenden. Weitere Informationen finden Sie in der Junos OS Routing Protocol Library for Routing Devices.

HINWEIS:

Router der ACX-Serie unterstützen keine [edit logical-systems] Hierarchieebene.

Beispiel: Konfigurieren der in LDP angekündigten Präfixe

Stellen Sie alle vernetzten Routen in LDP vor:

Konfigurieren der FEC-Deaggregation

Wenn ein LDP-Ausgangsrouter mehrere Präfixe ankündigen, werden die Präfixe an ein einziges Label gebunden und in einer einzigen Forwarding Äquivalenzklasse (FEC) aggregiert. Standardmäßig behält LDP diese Aggregation bei, während die Ankündigung das Netzwerk durchläuft.

Da ein LSP nicht über mehrere Next Hops aufgeteilt ist und die Präfixe an einen einzigen LSP gebunden sind, ist ein Load Balancing über gleichpreisige Pfade normalerweise nicht möglich. Sie können jedoch einen Load-Balance-Ausgleich über Pfade zu gleichen Kosten erreichen, wenn Sie eine Load-Balancing-Richtlinie konfigurieren und die FECs deaggregieren.

Durch die Deaggregierung 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 Anweisung ein deaggregate :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen 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 Deaggregierung eines FEC können die resultierenden mehreren LSPs über mehrere Pfade zu gleichen Kosten verteilt werden und LSPs auf mehrere nächste Hops in den Ausgangssegmenten verteilt werden, aber es installiert nur einen nächsten Hop pro LSP.

Um FECs zu aggregieren, fügen Sie die Anweisung ein no-deaggregate :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen 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 konfigurieren, um den Datenverkehr für LDP-FECs zu verfolgen und zu kontrollieren. LDP FEC Policer können für die folgenden Schritte verwendet werden:

  • Verfolgen oder kontrollieren Sie den eingehenden Datenverkehr für einen LDP FEC.

  • Verfolgen oder kontrollieren Sie den Transitverkehr für einen LDP FEC.

  • Verfolgen oder verfolgen Sie LDP-FEC-Datenverkehr, der von einer bestimmten Weiterleitungsklasse stammt.

  • Verfolgen oder kontrollieren Sie den LDP-FEC-Datenverkehr, der von einem bestimmten virtuellen Routing- und Weiterleitungsstandort (VRF) stammt.

  • Verwerfen Sie falschen Datenverkehr, der für eine bestimmte LDP FEC gebunden ist.

Um den Datenverkehr für einen LDP-FEC zu steuern, müssen Sie zuerst einen Filter konfigurieren. Insbesondere müssen Sie entweder die Anweisung oder die interfaceinterface-set Anweisung auf [edit firewall family protocol-family filter filter-name term term-name from] Hierarchieebene konfigurieren. Mit interface der Anweisung können Sie den Filter einer einzigen Schnittstelle gleichen. Mit interface-set der Anweisung können Sie den Filter auf mehrere Schnittstellen anpassen.

Weitere Informationen zur Konfiguration der Anweisung, der interface Anweisung und der interface-set 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 sie in die Anweisungskonfiguration policing für LDP aufnehmen. Um Policer für LDP-FECs zu konfigurieren, fügen Sie die Anweisung ein policing :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Die policing Anweisung umfasst die folgenden Optionen:

  • fec– Geben Sie die FEC-Adresse für die LDP-FEC an, die Sie ermitteln möchten.

  • ingress-filter– Geben Sie den Namen des Filters für eingehenden Datenverkehr an.

  • transit-traffic– Geben Sie den Namen des Transitdatenverkehrsfilters an.

Konfiguration von LDP-IPv4-FEC-Filterung

Wenn eine gezielte LDP-Sitzung eingerichtet wird, tauscht Junos OS standardmäßig sowohl die IPv4 Forwarding Äquivalenzklassen (FECs) als auch die Layer-2-Circuit-FECs über die zielorientierte LDP-Sitzung aus. Für eine LDP-Sitzung an einen indirekt verbundenen Nachbarn möchten Sie möglicherweise nur Layer-2-Circuit-FECs in den Nachbarn exportieren, wenn die Sitzung speziell für die Unterstützung von Layer-2-Circuits oder VPLS konfiguriert wurde.

In einem gemischten Anbieternetzwerk, in dem alle Nicht-BGP-Präfixe in LDP angekündigt werden, kann die LDP-Datenbank groß werden. Für diese Art von Umgebung kann es nützlich sein, die Ankündigung von IPv4-FECs über LDP-Sitzungen zu verhindern, die aufgrund einer Layer-2-Circuit- oder LDP-VPLS-Konfiguration gebildet wurden. Ebenso kann es nützlich sein, alle in dieser Umgebung empfangenen IPv4-FECs zu filtern.

Wenn alle LDP-Nachbarn, die einer LDP-Sitzung zugeordnet sind, nur Layer 2 sind, können Sie junos OS so konfigurieren, dass nur Layer-2-Circuit-FECs ankündigen, indem Sie die l2-smart-policy Anweisung konfigurieren. Diese Funktion filtert auch automatisch die IPv4 FECs, die in dieser Sitzung empfangen werden. Die Konfiguration einer expliziten Export- oder Importrichtlinie, die für l2-smart-policy die Aktivierung aktiviert ist, deaktiviert diese Funktion in der entsprechenden Richtung.

Wenn einer der Nachbarn der LDP-Sitzung aufgrund einer entdeckten Adjacency gebildet wird oder wenn die Adjacency aufgrund einer LDP-Tunneling-Konfiguration auf einem oder mehreren RSVP-LSPs gebildet wird, werden die IPv4-FECs mit dem Standardverhalten angekündigt und empfangen.

Um zu verhindern, dass LDP IPv4 FECs über LDP-Sitzungen exportiert, nur mit Layer-2-Nachbarn und um IPv4-FECs, die über solche Sitzungen empfangen werden, herauszufiltern, 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 Anweisungszusammenfassung für diese Anweisung.

Konfigurieren von BFD für LDP-LSPs

Sie können Bidirectional Forwarding Detection (BFD) für LDP-LSPs konfigurieren. Das BFD-Protokoll ist ein einfacher Hallo-Mechanismus, der Fehler in einem Netzwerk erkennt. Hallo Pakete werden in einem bestimmten, regelmäßigen Intervall gesendet. Ein Neighbor-Fehler wird erkannt, wenn der Router nach einem angegebenen Intervall keine Antwort mehr empfängt. BFD funktioniert mit einer Vielzahl von Netzwerkumgebungen und Topologien. Die Timer zur Fehlererkennung für BFD haben kürzere Zeitgrenzen als die Fehlererkennungsmechanismen statischer Routen und bieten eine schnellere Erkennung.

Ein Fehler wird protokolliert, wenn eine BFD-Sitzung für einen Pfad ausfällt. Im Folgenden wird veranschaulicht, wie BFD für LDP-LSP-Protokollmeldungen angezeigt werden können:

Sie können BFD auch für RSVP-LSPs konfigurieren, wie unter Konfigurieren von BFD für RSVP-signalierte LSPs beschrieben.

Die BFD-Timer zur Fehlererkennung sind anpassungsfähig und können mehr oder weniger aggressiv eingestellt werden. Beispielsweise können sich die Timer an einen höheren Wert anpassen, wenn die Adjacency fehlschlägt, 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-Sitzungsklappe mehr als dreimal in einem Zeitraum von 15 Sekunden auftritt. Ein Back-off-Algorithmus erhöht das Empfangsintervall (Rx) um zwei, wenn die lokale BFD-Instanz der Grund für den Sitzungs-Flap ist. Das Übertragungsintervall (Tx) wird um zwei erhöht, wenn die Remote-BFD-Instanz der Grund für den Sitzungs-Flap ist. Sie können den clear bfd adaptation Befehl verwenden, um BFD-Intervall-Timer auf ihre konfigurierten Werte zurückzugeben. Der clear bfd adaptation Befehl ist hitless, was bedeutet, dass der Befehl keinen Einfluss auf den Datenverkehr auf dem Routinggerät hat.

Um BFD für LDP-LSPs zu aktivieren, fügen Sie die oam und bfd-liveness-detection Aussagen ein:

Sie können BFD für die LDP-LSPs aktivieren, die einer bestimmten Forwarding Equivalence Class (FEC) zugeordnet sind, indem Sie die FEC-Adresse mithilfe der fec Option auf [edit protocols ldp] Hierarchieebene konfigurieren. Alternativ können Sie eine Eingangsrichtlinie für Betriebsadministration und -verwaltung (OAM) konfigurieren, um BFD für eine 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 äquivalenten FEC-Adressen explizit konfiguriert sind oder OAM auf den FECs mithilfe einer OAM-Eingangsrichtlinie aktiviert ist. Wenn BFD für FEC-Adressen nicht aktiviert ist, wird die BFD-Sitzung nicht aktiviert.

Sie können die oam Anweisung auf den folgenden Hierarchieebenen konfigurieren:

  • [edit protocols ldp]

  • [edit logical-systems logical-system-name protocols ldp]

HINWEIS:

Router der ACX-Serie unterstützen keine [edit logical-systems] Hierarchieebene.

Die oam Anweisung 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 aktiviert wird.

  • lsp-ping-interval– Geben Sie die Dauer des LSP-Ping-Intervalls in Sekunden an. Verwenden Sie den ping mpls ldp Befehl, um einen Ping für einen LDP-signalisierten LSP aus. Weitere Informationen finden Sie im CLI-Explorer.

Die bfd-liveness-detection Anweisung umfasst die folgenden Optionen:

  • ecmp— Richtet LDP BFD-Sitzungen für alle ECMP-Pfade ein, die für den angegebenen FEC konfiguriert sind. Wenn Sie die ecmp Option konfigurieren, müssen Sie auch die periodic-traceroute Anweisung für den angegebenen FEC konfigurieren. Wenn Sie dies nicht tun, schlägt der Commit-Vorgang fehl. Sie können die periodic-traceroute Anweisung auf der globalen Hierarchieebene () konfigurieren,[edit protocols ldp oam] während Sie nur die ecmp Option für eine bestimmte FEC ([edit protocols ldp oam fec address bfd-liveness-detection]) konfigurieren.

  • Holddown-Intervall: Geben Sie die Dauer an, die die BFD-Sitzung vor dem Hinzufügen der Route oder des nächsten Hops beibehalten soll. Die Angabe einer Zeit von 0 Sekunden bewirkt, dass die Route oder der nächste Hop hinzugefügt wird, sobald die BFD-Sitzung wieder aktiviert wird.

  • minimum-interval– Geben Sie das mindeste Sende- und Empfangsintervall an. Wenn Sie die minimum-interval Option konfigurieren, müssen Sie die minimum-receive-interval Option oder Option minimum-transmit-interval nicht konfigurieren.

  • minimum-receive-interval– Geben Sie das minimale Empfangsintervall an. Der Bereich reicht von 1 bis 255.000 Millisekunden.

  • minimum-transmit-interval– Geben Sie das minimale Übertragungsintervall an. Der Bereich reicht von 1 bis 255.000 Millisekunden.

  • multiplier– Geben Sie den Erkennungszeitmultiplikator an. Der Bereich reicht von 1 bis 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 ermitteln.

Konfigurieren von ECMP-aware BFD für LDP-LSPs

Wenn Sie BFD für einen 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 jede FEC, die einem bestimmten ECMP-Pfad (Equal-Cost Multipath) zugeordnet ist. Damit dies richtig funktioniert, müssen Sie auch den regelmäßigen LDP-LSP-Traceroute konfigurieren. (Siehe Konfigurieren von LDP-LSP-Traceroute.) LDP LSP Traceroute wird verwendet, um ECMP-Pfade zu ermitteln. Für jeden entdeckten ECMP-Pfad wird eine BFD-Sitzung initiiert. Wenn eine BFD-Sitzung für einen der ECMP-Pfade fehlschlägt, wird ein Fehler protokolliert.

LDP LSP Traceroute wird in regelmäßigen Abständen ausgeführt, um die Integrität der ECMP-Pfade zu überprüfen. Wenn ein Problem entdeckt wird, kann Folgendes auftreten:

  • Wenn sich der neueste LDP-LSP-Traceroute für einen FEC von dem vorherigen Traceroute unterscheidet, werden die BFD-Sitzungen, die diesem FEC (die BFD-Sitzungen für Adressbereiche, die sich gegenüber dem vorherigen Ausführen geändert haben) zugeordnet sind, 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 mit diesem FEC verknüpften BFD-Sitzungen abgerissen.

Um LDP zum Einrichten von BFD-Sitzungen für alle ECMP-Pfade zu konfigurieren, die für die angegebene FEC konfiguriert sind, fügen Sie die Anweisung ein ecmp .

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Neben der ecmp Anweisung müssen Sie die periodic-traceroute Anweisung auch in der globalen LDP-OAM-Konfiguration (auf hierarchie [edit protocols ldp oam] - oder [edit logical-systems logical-system-name protocols ldp oam] hierarchieebene) oder in der Konfiguration für das angegebene FEC (auf Hierarchieebene [edit protocols ldp oam fec address][edit logical-systems logical-system-name protocols ldp oam fec address] ) einschließen. Andernfalls schlägt der Commit-Vorgang fehl.

HINWEIS:

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 Fall eines BFD-Sitzungsfehlers auf einem LDP-LSP konfigurieren. Bei dem Fehlerereignis kann es sich um eine vorhandene BFD-Sitzung, die ausgefallen ist, oder eine BFD-Sitzung sein, die nie aufgetreten ist. LDP fügt die Route oder den nächsten Hop wieder hinzu, wenn die entsprechende BFD-Sitzung wieder aktiviert wird.

Sie können eine der folgenden Fehleraktionsoptionen für die failure-action Anweisung konfigurieren, wenn eine BFD-Sitzung auf dem LDP-LSP ausfällt:

  • remove-nexthop– Entfernt die Route, die dem nächsten Hop der LSP-Route am Eingangsknoten entspricht, wenn ein BFD-Sitzungsfehler-Ereignis erkannt wird.

  • remove-route— Entfernt die dem LSP entsprechende Route aus den entsprechenden Routing-Tabellen, wenn ein BFD-Sitzungsfehler-Ereignis erkannt wird. Wenn der LSP mit ECMP konfiguriert ist und eine BFD-Sitzung, die einem beliebigen Pfad entspricht, ausfällt, wird die Route entfernt.

Um eine Fehleraktion im Fall eines BFD-Sitzungsausfalls auf einem LDP-LSP zu konfigurieren, fügen Sie entweder die remove-nexthop Option oder die remove-route Option für die Anweisung ein failure-action :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen 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 der BFD-Sitzung vor dem Hinzufügen einer Route oder des nächsten Hops angeben, indem Sie die holddown-interval Anweisung entweder [edit protocols ldp oam bfd-livenesss-detection] auf Hierarchie- oder Hierarchieebene [edit protocols ldp oam fec address bfd-livenesss-detection] konfigurieren. Die Angabe einer Zeit von 0 Sekunden bewirkt, dass die Route oder der nächste Hop hinzugefügt wird, sobald die BFD-Sitzung wieder aktiviert wird.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Grundlegendes zur schnellen Multicast-Umleitung

Multicast-Only Fast Reroute (MoFRR) minimiert den Paketverlust für Datenverkehr in einer Multicast-Verteilungsstruktur bei Verbindungsausfällen 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.

HINWEIS:

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-Linecards unterstützt. Als Voraussetzung müssen Sie den Router in network-services enhanced-ip den Modus konfigurieren, und alle Linecards im Router müssen MPCs sein.

Wenn MoFRR aktiviert ist, senden Geräte Join-Nachrichten über primäre und Backup-Upstream-Pfade zu einer Multicast-Quelle. Geräte erhalten Datenpakete sowohl aus dem primären als auch vom Backup-Pfad und verwerfen die redundanten Pakete basierend auf der Priorität (Gewichtung, die den primären und Backup-Pfaden zugewiesen sind). Wenn ein Gerät einen Fehler im primären Pfad erkennt, beginnt es sofort, Pakete von der sekundären Schnittstelle (dem Backup-Pfad) zu akzeptieren. Der schnelle Switchover verbessert die Konvergenzzeiten bei Ausfällen der primären Pfadverbindung erheblich.

Eine Anwendung für MoFRR ist Streaming-IPTV. IPTV-Streams sind Multicast als UDP-Streams, sodass verlorene Pakete nicht erneut übertragen werden, was zu einer weniger zufriedenstellenden Benutzererfahrung führt. MoFRR kann die Situation verbessern.

MoFRR–Übersicht

Mit fast Reroute auf Unicast-Streams erstellt ein Upstream-Routing-Gerät MPLS Label-Switched Paths (LSPs) oder einen IP Loop-free Alternate (LFA) Fast Reroute Backup-Pfad vor, um Fehler eines Segments im Downstream-Pfad zu behandeln.

Beim Multicast-Routing basiert die Empfangsseite in der Regel auf den Graphen der Datenverkehrsverteilung. Dies ist im Gegensatz zu Unicast-Routing, das im Allgemeinen den Pfad von der Quelle zum Empfänger bestimmt. 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 beginnen PIM- und Multipoint-LDP-Empfänger die Einrichtung des Verteilungsdiagramms, sodass MoFRR mit diesen beiden Multicast-Protokollen arbeiten kann, wo sie unterstützt werden.

Wenn das Gerät in einer Multicast-Struktur einen Ausfall einer Netzwerkkomponente erkennt, dauert es einige Zeit, eine reaktive Reparatur durchzuführen, was zu erheblichen Datenverkehrsverlusten führt, während ein alternativer Pfad eingerichtet wird. MoFRR reduziert Datenverkehrsverluste in einer Multicast-Verteilungsstruktur, 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 empfangen. Wenn ein Fehler entlang des primären Stroms auftritt, kann das MoFRR-Routinggerät schnell zum Backup-Stream wechseln.

Wenn MoFRR aktiviert ist, verwendet das Gerät für jeden (S,G)-Eintrag zwei der verfügbaren Upstream-Schnittstellen, um eine Join-Nachricht zu senden und Multicast-Datenverkehr zu empfangen. Das Protokoll versucht, zwei unzusammenhängene Pfade auszuwählen, wenn zwei solcher Pfade verfügbar sind. Wenn disjoint-Pfade nicht verfügbar sind, wählt das Protokoll zwei nicht unzusammenhängende Pfade aus. Wenn zwei nicht miteinander abgestimmte Pfade nicht verfügbar sind, wird nur ein primärer Pfad ohne Backup ausgewählt. MoFRR priorisiert das unzusammenhängene Backup zugunsten des Load Balancing der verfügbaren Pfade.

MoFRR wird sowohl für die IPv4- als auch für die IPv6-Protokollfamilien unterstützt.

Abbildung 12 zeigt zwei Pfade vom Multicast-Empfänger-Routinggerät (auch als Pe-Ausgangs-Provider-Edge-Gerät bezeichnet) zum Multicast-Quell-Routing-Gerät (auch als Eingangs-PE-Gerät bezeichnet).

Abbildung 12: MoFRR-StichprobentopologieMoFRR-Stichprobentopologie

Wenn MoFRR aktiviert ist, richtet das Ausgangs-Routinggerät (empfängerseitig) zwei Multicast-Bäume ein, einen primären Pfad und einen Backup-Pfad, zur Multicast-Quelle für jeden (S,G). Mit anderen Worten, das Ausgangs-Routing-Gerät verbreitet die gleichen (S,G)-Join-Nachrichten an zwei verschiedene Upstream-Nachbarn, wodurch zwei Multicast-Bäume erstellt werden.

Einer der Multicast-Bäume geht durch Ebene 1 und der andere durch Ebene 2, wie in Abbildung 12. Für jedes (S,G) leitet das Ausgangs-Routing-Gerät den auf dem primären Pfad empfangenen Datenverkehr weiter und leitet den empfangenen Datenverkehr auf dem Backup-Pfad ab.

MoFRR wird sowohl auf ECMP-Pfaden (Equal-Cost Multipath) 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 mit der link-protection Anweisung in der Konfiguration des Interior Gateway Protocol (IGP). Wenn Sie den Linkschutz 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 am 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 richtet das Gerät zwei Pfade zum upstream-PE-Routing-Gerät ein, um zwei Streams von MPLS-Paketen am LER zu empfangen. Das Gerät akzeptiert einen der Streams (den primären), und der andere (das Backup) wird am LER abgelegt. Wenn der primäre Pfad fehlschlägt, akzeptiert das Gerät stattdessen den Backup-Stream. Unterstützung von Inband-Signalen 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 Konfigurationsaussage in der [edit routing-options multicast stream-protection] Hierarchie ein. Für jede Gruppe G wird MoFRR entweder (S,G) oder (*,G) betrieben, aber nicht für beide. (S,G) hat immer Vorrang vor (*,G).

Wenn MoFRR aktiviert ist, verbreitet ein PIM-Routing-Gerät Join-Nachrichten über zwei upstream-Reverse-Path Forwarding (RPF)-Schnittstellen, um Multicast-Datenverkehr auf beiden Links für dieselbe Join-Anforderung zu empfangen. MoFRR bevorzugt zwei Pfade, die nicht mit demselben unmittelbaren Upstream-Routing-Gerät konvergieren. PIM installiert geeignete Multicast-Routen mit upstream-RPF-Next Hops mit zwei Schnittstellen (für den primären und den Backup-Pfad).

Wenn der primäre Pfad fehlschlägt, 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 Multicast-Route.

Sie können MoFRR mit PIM-Join-Load Balancing aktivieren (siehe Anweisung join-load-balance automatic ). In diesem Fall ist die Verteilung der Join-Nachrichten unter den Links jedoch möglicherweise nicht gleichmäßig. Wenn ein neuer ECMP-Link hinzugefügt wird, werden Join-Nachrichten auf dem primären Pfad neu verteilt und lastausgleichend. Die Join-Nachrichten auf dem Backup-Pfad folgen möglicherweise immer noch demselben Pfad und werden möglicherweise nicht gleichmäßig verteilt.

Sie aktivieren MoFRR mithilfe der stream-protection Konfigurationsaussage 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 nach einer MoFRR-Konfiguration und verläuft wie folgt:

  • Wenn die MoFRR-Konfiguration nicht vorhanden ist, sendet PIM eine Join-Nachricht upstream an einen Upstream-Nachbarn (z. B. Ebene 2 in Abbildung 12).

  • Wenn die MoFRR-Konfiguration vorhanden ist, prüft das Gerät nach einer Richtlinienkonfiguration.

  • Wenn keine Richtlinie vorhanden ist, prüft das Gerät die primären und Backup-Pfade (Upstream-Schnittstellen) und führt wie folgt aus:

    • Wenn primäre und Backup-Pfade nicht verfügbar sind, sendet PIM eine Join-Nachricht im Upstream an einen Upstream-Nachbarn (z. B. Ebene 2 in Abbildung 12).

    • Wenn Primär- und Backup-Pfade verfügbar sind, sendet PIM die Join-Nachricht im Upstream an zwei der verfügbaren Upstream-Nachbarn. Junos OS richtet primäre und sekundäre Multicast-Pfade ein, um Multicast-Datenverkehr zu empfangen (z. B. Ebene 1 in Abbildung 12).

  • Wenn eine Richtlinie vorhanden ist, prüft das Gerät, ob die Richtlinie MoFRR für dies (S,G) zulässt, und geht wie folgt vor:

    • Wenn diese Richtlinienprüfung fehlschlägt, sendet PIM eine Join-Nachricht im Upstream an einen Upstream-Nachbarn (z. B. Ebene 2 in Abbildung 12).

    • Wenn diese Richtlinienprüfung erfolgreich ist– Das Gerät sucht nach primären und Backup-Pfaden (Upstream-Schnittstellen).

      • Wenn die primären und Backup-Pfade nicht verfügbar sind, sendet PIM eine Join-Nachricht im Upstream an einen Upstream-Nachbarn (z. B. Ebene 2 in Abbildung 12).

      • Wenn die primären und Backup-Pfade verfügbar sind, sendet PIM die Join-Nachricht im Upstream an zwei der verfügbaren Upstream-Nachbarn. Das Gerät richtet primäre und sekundäre Multicast-Pfade ein, um Multicast-Datenverkehr zu empfangen (z. B. Ebene 1 in Abbildung 12).

Multipoint-LDP-Funktionalität

Um MPLS-Datenverkehrsduplikationen zu vermeiden, wählt multipoint-LDP in der Regel nur einen Upstream-Pfad. (Siehe Abschnitt 2.4.1.1. Bestimmung des '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 Label, eine an jeden Upstream-Peer. Das Gerät verwendet den in RFC 6388 beschriebenen Algorithmus, um den primären Upstream-Pfad auszuwählen. Das Gerät verwendet den gleichen Algorithmus, um den Backup-Upstream-Pfad auszuwählen, schließt jedoch den primären Upstream-LSR als Kandidat aus. Die zwei verschiedenen Upstream-Peers senden zwei Streams von MPLS-Datenverkehr an das Ausgangs-Routing-Gerät. Das Gerät wählt nur einen der Upstream-Neighbor-Pfade 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 diesen Datenverkehr. Wenn der primäre Upstream-Pfad ausfällt, nimmt das Gerät den Datenverkehr aus dem Backup-Pfad an. Das Multipoint-LDP-Gerät wählt die beiden Upstream-Pfade basierend auf dem Interior Gateway Protocol (IGP) Root-Gerät next Hop aus.

Eine Forwarding Equivalency Class (FEC) ist eine Gruppe von IP-Paketen, die auf dieselbe Weise, über den gleichen Pfad und mit derselben Weiterleitungsbehandlung weitergeleitet werden. Normalerweise repräsentiert das Label, das auf einem bestimmten Paket abgelegt wird, den FEC, dem dieses Paket zugewiesen ist. In MoFRR werden zwei Routen in die mpls.0-Tabelle für jeden FEC platziert : eine Route für das primäre Label und die andere Route für das Backup-Label.

Wenn parallele Verbindungen zu demselben unmittelbaren Upstream-Gerät vorhanden sind, betrachtet das Gerät beide parallelen Verbindungen als primär. Zu jedem Zeitpunkt sendet das Upstream-Gerät Datenverkehr nur auf einer der mehreren parallelen Verbindungen.

Ein Knospenknoten ist ein LSR, der eine Ausgangs-LSR ist, aber auch über eine oder mehrere direkt angeschlossene Downstream-LSRs verfügt. Bei einem Knospenknoten wird der Datenverkehr aus dem primären Upstream-Pfad an einen Downstream-LSR weitergeleitet. Wenn der primäre Upstream-Pfad fehlschlägt, wird der MPLS-Datenverkehr aus dem Backup-Upstream-Pfad an den Downstream-LSR weitergeleitet. Das bedeutet, dass der downstreamE-LSR-Next Hop zu beiden MPLS-Routen zusammen mit dem ausgehenden nächsten Hop hinzugefügt wird.

Wie bei PIM aktivieren Sie MoFRR mit Multipoint-LDP mithilfe der stream-protection Konfigurationsaussage in der [edit routing-options multicast] Hierarchie, die durch eine Reihe von Filterrichtlinien verwaltet wird.

Wenn Sie den 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 eine nicht zielorientierte LDP-Sitzung vorhanden ist. Wenn es eine einzelne gezielte LDP-Sitzung gibt, wird die zielorientierte LDP-Sitzung ausgewählt, aber der entsprechende Point-to-Multipoint-FEC verliert die MoFRR-Funktion, da keine Schnittstelle mit der zielorientierten LDP-Sitzung verknüpft ist.

  • Alle Schnittstellen, die zum gleichen Upstream-LSR gehören, gelten als primärer Pfad.

  • Für alle Root-Node-Routenaktualisierungen wird der Upstream-Pfad basierend auf den neuesten nächsten Hops aus der IGP geändert. Wenn ein besserer Pfad verfügbar ist, versucht multipoint-LDP, auf den besseren Pfad zu wechseln.

Paketweiterleitung

Für PIM- oder Multipoint-LDP führt das Gerät eine Multicast-Quellstromauswahl an der Eingangsschnittstelle aus. Dadurch bleibt die Fabric-Bandbreite erhalten und die Weiterleitungsleistung maximiert, da:

  • Vermeidet das Senden 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, über die die Pakete ankommen, haben die Pakete die gleiche Route. Das Gerät überprüft die Schnittstelle, über die jedes Paket ankommt, und leitet nur diejenigen weiter, die von der primären Schnittstelle sind. Wenn die Schnittstelle mit einer Backup-Stream-Schnittstelle übereinstimmt, lässt das Gerät die Pakete fallen. Wenn die Schnittstelle weder mit der primären noch mit der Backup-Stream-Schnittstelle übereinstimmt, behandelt das Gerät die Pakete als Ausnahmen in der Control Plane.

Abbildung 13 zeigt diesen Prozess mit Beispiel-primären und Backup-Schnittstellen für Router mit PIM. Abbildung 14 dies bei Switches mit PIM ähnlich zeigt.

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-Routenhandling in der Packet Forwarding Engine auf SwitchesMoFRR IP-Routenhandling in der Packet Forwarding Engine auf Switches

Für MoFRR mit Multipoint-LDP auf Routern verwendet das Gerät mehrere MPLS-Label, um die MoFRR-Stream-Auswahl zu steuern. Jedes Label stellt eine separate Route dar, aber jedes verweist auf dieselbe Schnittstellenlistenüberprüfung. Das Gerät leitet nur das primäre Label weiter und setzt alle anderen aus. 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

Einschränkungen und Vorbehalte des MoFRR für Switching- und Routing-Geräte

MoFRR hat die folgenden Einschränkungen und Einschränkungen für Routing- und Switching-Geräte:

  • Die MoFRR-Fehlererkennung wird für den sofortigen Linkschutz des Routing-Geräts, auf dem MoFRR aktiviert ist, und nicht für alle Verbindungen (End-to-End) im Multicast-Datenverkehrspfad unterstützt.

  • MoFRR unterstützt eine schnelle Umleitung auf zwei ausgewählten disjoint-Pfaden zur Quelle. Zwei der ausgewählten Upstream-Nachbarn können sich nicht auf derselben Schnittstelle befinden– mit anderen Worten, zwei Upstream-Nachbarn in einem LAN-Segment. Dasselbe gilt, wenn es sich bei der Upstream-Schnittstelle um eine Multicast-Tunnelschnittstelle handelt.

  • Die Erkennung der maximal unzusammenhängenden Upstream-Pfade wird nicht unterstützt. Das Empfängerseitige (Ausgangs-) Routing-Gerät stellt nur sicher, dass ein nicht miteinander vereinheiteltes Upstream-Gerät (der unmittelbare vorherige Hop) vorhanden ist. PIM und Multipoint-LDP unterstützen nicht das Äquivalent zu expliziten Routenobjekten (EROs). Daher ist die Erkennung nicht miteinander geteilter Upstream-Pfade auf die Kontrolle über das unmittelbar vorherige Hop-Gerät beschränkt. Aufgrund dieser Einschränkung kann der Pfad zum Upstream-Gerät des vorherigen Hops freigegeben werden, der als Primär- und Backup ausgewählt wurde.

  • In den folgenden Szenarien kann es zu Datenverkehrsverlusten kommen:

    • 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 werden nicht unterstützt.

  • Für eine Multicast-Gruppe G ist MoFRR für Nachrichten zum Beitreten (S,G) und (*,G) nicht zulässig. (S,G) Join-Nachrichten haben Vorrang vor (*,G).

  • MoFRR wird für Multicast-Datenverkehrsströme, die zwei unterschiedliche Multicast-Gruppen verwenden, nicht unterstützt. Jede (S,G)-Kombination wird als einzigartiger Multicast-Datenverkehrsstrom behandelt.

  • Der bidirektionale PIM-Bereich wird von MoFRR nicht unterstützt.

  • PIM Dense Mode wird mit MoFRR nicht unterstützt.

  • Multicast-Statistiken für den Backup-Datenverkehrsstrom werden nicht von PIM verwaltet und stehen daher nicht in der Betriebsausgabe von show Befehlen zur Verfügung.

  • Die Ratenüberwachung wird nicht unterstützt.

MoFRR-Einschränkungen für das Switching von Geräten mit PIM

MoFRR mit PIM hat die folgenden Einschränkungen für das Switching von Geräten:

  • MoFRR wird nicht unterstützt, wenn es sich bei der Upstream-Schnittstelle um eine integrierte Routing- und Bridging-Schnittstelle (IRB) handelt, was sich auf andere Multicast-Funktionen wie Internet Group Management Protocol Version 3 (IGMPv3)-Snooping auswirkt.

  • Paketreplikation und Multicast-Suchen bei der Weiterleitung von Multicast-Datenverkehr können dazu führen, dass Pakete mehrmals durch PFEs zirkulieren. Infolgedessen können die angezeigten Werte für die Multicast-Paketanzahl aus dem show pfe statistics traffic Befehl höhere Zahlen als erwartet in Ausgabefeldern wie Input packets und .Output packets In MoFRR-Szenarien kann dieses Verhalten häufiger auftreten, da duplizierte Primär- und Backup-Streams den Datenverkehr im Allgemeinen erhöhen.

MoFRR-Einschränkungen und Vorbehalte für Routing-Geräte mit Multipoint-LDP

MoFRR hat die folgenden Einschränkungen und Einschränkungen für Router, wenn es mit Multipoint-LDP verwendet wird:

  • MoFRR gilt nicht für Multipoint-LDP-Datenverkehr, der in einem RSVP-Tunnel empfangen wird, da der RSVP-Tunnel keiner Schnittstelle zugeordnet ist.

  • Gemischtes Upstream-MoFRR wird nicht unterstützt. Dies bezieht sich auf PIM-Multipoint-LDP-In-Band-Signalisierung, wobei ein Upstream-Pfad durch Multipoint-LDP und der zweite Upstream-Pfad über PIM führt.

  • Multipoint-LDP-Label als innere Label werden nicht unterstützt.

  • Wenn die Quelle über mehrere eingangs (source-side) Provider Edge (PE)-Routinggeräte 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 es keine Unterstützung für interne MoFRR-Label gibt.

Konfigurieren einer nur multicastbasierten schnellen Umleitung

Sie können Multicast-Only Fast Reroute (MoFRR) konfigurieren, um Paketverluste in einem Netzwerk zu minimieren, wenn ein Verbindungsausfall auftritt.

Wenn fast Reroute auf Unicast-Streams angewendet wird, erstellt ein Upstream-Router MPLS Label-Switched Paths (LSPs) oder erstellt einen IP Loop-free Alternate (LFA)-Fast-Reroute-Backup-Pfad vor, um Fehler eines Segments im Downstream-Pfad zu behandeln.

Beim Multicast-Routing werden die Verkehrsverteilungsdiagramme in der Regel vom Empfänger stammen. Dies ist im Gegensatz zu Unicast-Routing, das normalerweise den Pfad von der Quelle zum Empfänger bestimmt. Protokolle, die Multicast-Verteilungsdiagramme einrichten können, sind PIM (für IP), Multipoint-LDP (für MPLS) und RSVP-TE (für MPLS). Von diesen beginnen PIM- und Multipoint-LDP-Empfänger die Einrichtung des Verteilungsdiagramms, und daher:

  • In der QFX-Serie wird MoFRR in PIM-Domänen unterstützt.

  • Auf der MX- und SRX-Serie wird MoFRR in PIM- und Multipoint-LDP-Domänen unterstützt.

Die Konfigurationsschritte für die Aktivierung von MoFRR für PIM auf allen Geräten, die diese Funktion unterstützen, sind dieselben, sofern nicht anders angegeben. Konfigurationsschritte, die für Multipoint-LDP-MoFRR nicht anwendbar sind, werden ebenfalls angegeben.

(nur für Router der MX-Serie) MoFRR wird auf Routern der MX-Serie mit MPC-Linecards 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) Richten Sie den erweiterten IP-Modus für den Router ein.
  2. Aktivieren Sie MoFRR.
  3. (Optional) Konfigurieren Sie eine Routing-Richtlinie, die nach einer eingeschränkten Gruppe von Multicast-Streams filtert, die von Ihrer MoFRR-Konfiguration beeinflusst werden.

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

    Zum Beispiel:

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

    Zum Beispiel:

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

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

  6. (Optional) Lassen Sie in einer PIM-Domäne mit MoFRR als Backup-RPF-Pfad nur eine disjoint RPF (eine RPF auf einer separaten Ebene) auszuwählen.

    Dies wird für Multipoint-LDP-MoFRR nicht unterstützt. In einer Multipoint-LDP-MoFRR-Domäne wird dasselbe Label zwischen parallelen Verbindungen zu demselben Upstream-Nachbarn gemeinsam genutzt. Dies ist nicht der Fall in einer PIM-Domain, bei der jeder Link einen Nachbarn bildet. Die mofrr-disjoint-upstream-only Anweisung erlaubt nicht, dass ein Backup-RPF-Pfad ausgewählt wird, wenn der Pfad zum gleichen Upstream-Nachbarn wie der des primären RPF-Pfads führt. Dadurch wird sichergestellt, dass MoFRR nur in einer Topologie ausgelöst wird, die mehrere RPF-Upstream-Nachbarn hat.

  7. (Optional) Verhindern Sie in einer PIM-Domain mit MoFRR das Senden von Join-Nachrichten über den Backup-Pfad, aber behalten Sie alle anderen MoFRR-Funktionen bei.

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

  8. (Optional) Erlauben Sie in einer PIM-Domäne mit MoFRR, dass die Auswahl des neuen primären Pfads auf der Unicast-Gateway-Auswahl für die Unicast-Route zur Quelle basiert und bei Einer Änderung der Unicast-Auswahl geändert wird, anstatt dass der Backup-Pfad als primär befördert wird. So wird sichergestellt, dass sich der primäre RPF-Hop immer auf dem besten Pfad befindet.

    Wenn Sie die mofrr-primary-selection-by-routing Anweisung einschließen, wird nicht garantiert, dass der Backup-Pfad zum neuen primären Pfad befördert wird, wenn der primäre Pfad ausfällt.

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

Beispiel: Konfigurieren von Multicast-only Fast Reroute in einer Multipoint-LDP-Domäne

In diesem Beispiel wird gezeigt, wie Sie multicast-only Fast Reroute (MoFRR) konfigurieren, um den Paketverlust in einem Netzwerk bei einem Verbindungsausfall zu minimieren.

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 eingerichtet, um zwei Streams von MPLS-Paketen am Label-Edge-Router (LER) zu empfangen. Einer der Streams (der primäre) wird akzeptiert, der andere (das Backup) wird beim LER abgelegt. Der Backup-Stream wird akzeptiert, wenn der primäre Pfad fehlschlägt.

Anforderungen

Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

In einer Multipoint-LDP-Domain muss MoFRR nur für den Ausgangs-PE-Router moFRR aktiviert sein. Die anderen Router müssen MoFRR nicht unterstützen.

MoFRR wird auf Plattformen der MX-Serie mit MPC-Linecards unterstützt. Als Voraussetzung muss der Router auf network-services enhanced-ip den Modus eingestellt sein, und alle Linecards in der Plattform müssen MPCs sein.

Für dieses Beispiel ist Junos OS Version 14.1 oder höher auf dem AUSGANGS-PE-Router erforderlich.

Ü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 können.

Zu Testzwecken werden Router verwendet, um die Quelle und den Empfänger zu simulieren. Gerät R4 und Gerät R8 sind so konfiguriert, dass sie der gewünschten Gruppe mithilfe des set protocols igmp interface interface-name static group group Befehls statisch beitreten. Wenn ein echter Multicast-Empfänger-Host nicht verfügbar ist, wie in diesem Beispiel, ist diese statische IGMP-Konfiguration nützlich. Um die Multicast-Gruppenadresse an den Empfängern zu hören, wird in diesem Beispiel verwendet set protocols sap listen group.

Die MoFRR-Konfiguration enthält eine Richtlinienoption, die in diesem Beispiel nicht dargestellt wird, aber separat erklärt wird. Die Option ist wie folgt konfiguriert:

Topologie

Abbildung 16 zeigt das Beispielnetzwerk.

Abbildung 16: MoFRR in einer Multipoint-LDP-Domain MoFRR in einer Multipoint-LDP-Domain

CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 16.

In diesem Abschnitt Konfiguration werden die Schritte auf Gerät R3 beschrieben.

CLI-Schnellkonfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen 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 auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.

So konfigurieren Sie Gerät R3:

  1. Aktivieren Sie den erweiterten IP-Modus.

  2. Konfigurieren Sie die Geräteschnittstellen.

  3. Konfigurieren Sie die Nummer des autonomen Systems (AS).

  4. Konfigurieren Sie die Routing-Richtlinien.

  5. Konfigurieren Sie PIM.

  6. Konfigurieren Sie LDP.

  7. Konfigurieren Sie IGP- oder statische Routen.

  8. Konfigurieren Sie interne BGP.

  9. Konfigurieren Sie MPLS und optional RSVP.

  10. Aktivieren Sie MoFRR.

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show chassisBefehle , show interfaces, , show protocolsshow policy-optionsund show routing-options eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .

Überprüfung

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

Überprüfen der LDP-Punkt-zu-Multipoint-Weiterleitung äquivalenzklassen

Zweck

Stellen Sie sicher, dass das MoFRR aktiviert ist, und bestimmen Sie, welche Label verwendet werden.

Aktion
Bedeutung

Die Ausgabe zeigt, dass MoFRR aktiviert ist, und es zeigt, dass die Label 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 zwei Upstream-Schnittstellen für den Multicast-Gruppen-Join hat.

Aktion
Bedeutung

Die Ausgabe zeigt die primären Upstream-Pfade und die Backup-Upstream-Pfade. Außerdem werden die nächsten Hops der RPF angezeigt.

Überprüfen der Multicast-Routen

Zweck

Überprüfen Sie die IP-Multicast-Weiterleitungstabelle, um sicherzustellen, dass es eine upstreame 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 Point-to-Multipoint-Datenverkehrsstatistiken

Zweck

Stellen Sie sicher, dass sowohl Primär- als auch Backup-Statistiken aufgeführt sind.

Aktion
Bedeutung

Die Ausgabe zeigt sowohl primäre als auch Backup-Routen mit den Labeln.

Beispiel: Konfiguration von LDP-Downstream auf Abruf

Dieses Beispiel zeigt, wie Sie LDP-Downstream bei Bedarf konfigurieren. LDP wird üblicherweise im downstream-Modus für unerbetene Ankündigungen konfiguriert, was bedeutet, dass Label-Ankündigungen für alle Routen von allen LDP-Peers empfangen werden. Da Service Provider die Zugriffs- und Aggregationsnetzwerke in eine einzige MPLS-Domäne integrieren, ist LDP-Downstream auf Abruf erforderlich, um die Bindungen zwischen den Zugriffs- und Aggregationsnetzwerken zu verteilen und die Verarbeitungsanforderungen für die Steuerungsebene zu reduzieren.

Downstream-Knoten können potenziell Zehntausende von Label-Bindungen von upstream-Aggregationsknoten erhalten. Anstatt alle Labelbindungen für alle möglichen Loopback-Adressen innerhalb des gesamten MPLS-Netzwerks zu lernen und zu speichern, kann der Downstream-Aggregationsknoten mit LDP-Downstream bei Bedarf konfiguriert werden, um nur die Label-Bindungen für die FECs anzufordern, die den Loopback-Adressen der Ausgangsknoten entsprechen, auf denen 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-Ankündigung für eine LDP-Sitzung aktivieren, indem Sie die downstream-on-Demand-Anweisung auf Hierarchieebene [edit protocols ldp session] angeben. Wenn Sie Downstream-On-Demand konfiguriert haben, gibt der Router von Juniper Networks die Downstream-On-Demand-Anforderung an seine Peer-Router an. Damit eine Downstream-On-Demand-Sitzung zwischen zwei Routern eingerichtet werden kann, müssen beide während der Einrichtung der LDP-Sitzung den Downstream-On-Demand-Modus ankündigen. Wenn ein Router den ungebetenen Downstream-Modus und der andere downstream bei Bedarf den Downstream-Modus ankündigen, wird der Downstream-Modus verwendet, der nicht angefordert wird.

Konfiguration

Konfiguration von LDP-Downstream auf Abruf

Schritt-für-Schritt-Verfahren

So konfigurieren Sie eine LDP-Downstream-On-Demand-Richtlinie und konfigurieren diese Richtlinie und aktivieren LDP-Downstream on Demand in der LDP-Sitzung:

  1. Konfigurieren Sie die Downstream-On-Demand-Richtlinie (DOD-Request-Loopbacks in diesem Beispiel).

    Diese Richtlinie bewirkt, dass der Router Label-Anforderungsnachrichten nur an die FECs weiterleitet, die durch die DOD-Request-Loopbacks Richtlinie übereinstimmen.

  2. Geben Sie die Richtlinie DOD-Request-Loopbacks mithilfe der dod-request-policy Anweisung auf [edit protocols ldp] Hierarchieebene an.

    Die mit der dod-request-policy Anweisung angegebene Richtlinie wird verwendet, um die Präfixe für das Senden von Meldungen zur Labelanforderung zu identifizieren. Diese Richtlinie ähnelt einer Ausgangs- oder Importrichtlinie. Bei der Verarbeitung von Routen aus der Routingtabelle inet.0 sucht die Junos OS-Software nach Routen, die der DOD-Request-Loopbacks Richtlinie entsprechen (in diesem Beispiel). Wenn die Route mit der Richtlinie übereinstimmt und die LDP-Sitzung mit dem DOD-Ankündigungsmodus ausgehandelt wird, werden Label-Anforderungsmeldungen an die entsprechende Downstream-LDP-Sitzung gesendet.

  3. Fügen Sie die downstream-on-demand Anweisung in die Konfiguration der LDP-Sitzung ein, um den Downstream-On-Demand-Verteilungsmodus zu aktivieren.

Verteilung von LDP-Downstream-On-Demand-Routen in gekennzeichnete BGP

Schritt-für-Schritt-Verfahren

Verwenden Sie eine BGP-Exportrichtlinie, um LDP-Downstream-On-Demand-Routen in gekennzeichnete BGP-Routen 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 BGP-Gruppenkonfiguration ebgp-to-abr in diesem Beispiel).

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

Schritt-für-Schritt-Verfahren

Konfigurieren Sie die folgenden Richtlinien, um die Labelweitergabe auf andere Router zu beschränken, die im unaufgeforderten Downstream-Modus (anstelle von Downstream-On-Demand) konfiguriert sind:

  1. Konfigurieren Sie die dod-routes Richtlinie so, dass Routen von LDP akzeptiert werden.

  2. Konfigurieren Sie die do-not-propagate-du-sessions Richtlinie, um Routen nicht an Nachbarn 10.1.1.1weiterzuleiten , 10.2.2.2und 10.3.3.3.

  3. Konfigurieren Sie die filter-dod-on-du-sessions Richtlinie, um zu verhindern, dass die von der dod-routes Richtlinie geprüften 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 g-Roupan ebgp-to-abr.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show policy-options befehle eingeben show protocols ldp . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Überprüfung

Überprüfung des Label-Ankündigungsmodus

Zweck

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

Verwenden Sie den show ldp session Befehl, um den Status des Label-Ankündigungsmodus für die LDP-Sitzung zu überprüfen.

Aktion

Gibt die show ldp session Befehle und show ldp session detail Befehle aus:

  • Die folgende Befehlsausgabe für den show ldp session Befehl gibt an, dass der Adv. Mode (Label-Ankündigungsmodus) ist DOD (d. h. die LDP-Downstream-On-Demand-Sitzung ist betriebsbereit):

  • Die folgende Befehlsausgabe für den show ldp session detail Befehl zeigt an, dass der Local Label Advertisement mode Ist- und Standardwert ist Downstream unsolicited(d. h. downstream-On-Demand ist in der lokalen Sitzung nicht konfiguriert). Umgekehrt geben die Remote Label Advertisement mode und beide Negotiated Label Advertisement mode an, dass in Downstream on demand der Remote-Sitzung konfiguriert ist

Konfiguration von LDP-nativer IPv6-Unterstützung

LDP wird in einem reinen IPv6-Netzwerk und in einem IPv6- oder IPv4-Dual-Stack-Netzwerk unterstützt, wie in RFC 7552 beschrieben. Konfigurieren Sie die Adressfamilie als inet für IPv4 oder inet6 für IPv6 oder beides, und die Übertragungseinstellung ist entweder IPv4 oder IPv6. Die dual-transport Anweisung ermöglicht Junos OS LDP den Aufbau der TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR. Die inet-lsr-id beiden LSR-IDs und inet6-lsr-id IDs müssen konfiguriert werden, 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, müssen Sie unbedingt die Routing- und Signalprotokolle konfigurieren.

Um LDP-native IPv6-Unterstützung zu konfigurieren, müssen Sie folgendes tun:

  1. Aktivieren Sie FEC-Deaggregation (Forwarding Equivalence Class), um unterschiedliche Label für unterschiedliche 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 sowohl IPv4 als auch IPv6 aktiviert sind. Standardmäßig wird IPv6 als TCP-Transport für den Aufbau einer LDP-Verbindung verwendet.
  4. (Optional) Konfigurieren Sie den dualen 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.

Beispiel: Konfiguration von LDP-nativer 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. Dies hilft, ein Tunneling von IPv6 über IPv4 MPLS-Core mit IPv4-signalisierten MPLS-Label-Switched Paths (LSPs) zu vermeiden.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Zwei Router der MX-Serie

  • Junos OS Version 16.1 oder höher auf allen Geräten

Bevor Sie IPv6 als Dual-Stack konfigurieren, müssen Sie unbedingt die Routing- und Signalprotokolle konfigurieren.

Überblick

LDP wird nur 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. Standardmäßig wird IPv6 als TCP-Transport für die LDP-Sitzung mit ihren Peers verwendet, wenn sowohl IPv4 als auch IPv6 aktiviert sind. Die Dual-Transport-Anweisung ermöglicht Junos LDP den Aufbau der TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR. Die inet-lsr-id beiden inet6-lsr-id LSR-IDs müssen konfiguriert werden, 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, die als Dual-Stack auf Gerät R1 und Gerät R2 konfiguriert wurde.

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

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie 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 auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter " Using the CLI Editor in Configuration Mode " im Junos OS CLI-Benutzerhandbuch.

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. Aktivieren Sie FEC-Deaggregation (Forwarding Equivalence Class), um unterschiedliche Label für unterschiedliche Adressfamilien zu verwenden.

  6. Konfigurieren Sie LDP-Adressfamilien.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfaces befehle eingeben show protocols . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Konfigurieren Sie die Transportpräferenz, um den bevorzugten Transport auszuwählen

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 Aufbau einer LDP-Verbindung verwendet.

  • (Optional) Konfigurieren Sie die Transportpräferenz für eine LDP-Verbindung.

Schritt-für-Schritt-Verfahren
Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show protocols Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Konfigurieren Sie den dualen Transport, um separate Sitzungen für IPv4 mit einem IPv4-Nachbarn und IPv6 mit einem IPv6-Nachbarn einzurichten

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 als inet-lsr-id LSR-ID für IPv4 und inet6-lsr-id als LSR-ID für IPv6.

  • (Optional) Konfigurieren Sie dualen Transport, damit LDP die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herstellen kann.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show protocols Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, 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

Zeigen Sie mpls.0-Routingtabelleninformationen an.

Aktion

Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um die show route table mpls.0 Mpls.0-Routingtabelleninformationen anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Informationen zur Routingtabelle mpls.0.

Überprüfen der Routeneinträge in der Tabelle inet.3
Zweck

Zeigt inet.3-Routentabelleninformationen an.

Aktion

Führen Sie auf Gerät R1 aus dem Betriebsmodus den Befehl aus, um die show route table inet.3 Routingtabelleninformationen inet.3 anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Inet.3-Routingtabelleninformationen.

Überprüfen der Routeneinträge in der Tabelle inet6.3
Zweck

Zeigt inet6.3-Routentabelleninformationen an.

Aktion

Führen Sie auf Gerät R1 aus dem Betriebsmodus den Befehl aus, um die show route table inet6.3 Inet6.3-Routingtabelleninformationen anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Routingtabelleninformationen inet6.3.

Überprüfung der LDP-Datenbank
Zweck

Zeigen Sie die LDP-Datenbankinformationen an.

Aktion

Führen Sie auf Gerät R1 aus dem Betriebsmodus den Befehl aus, um LDP-Datenbankinformationen show ldp database anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Einträge in der LDP-Datenbank.

Überprüfen der LDP Neighbor Information
Zweck

Zeigen Sie die LDP-Nachbarninformationen an.

Aktion

Führen Sie auf Gerät R1 aus dem Betriebsmodus die show ldp neighbor Befehle aus show ldp neighbor extensive , um LDP-Nachbarn anzuzeigen.

Bedeutung

Die Ausgabe zeigt LDP-Nachbarninformationen von IPv4- und IPv6-Adressen.

Überprüfen der LDP-Sitzungsinformationen
Zweck

Zeigen Sie die LDP-Sitzungsinformationen an.

Aktion

Führen Sie auf Gerät R1 aus dem Betriebsmodus die show ldp session Befehle aus show ldp session extensive , um LDP-Sitzungsinformationen anzuzeigen.

Bedeutung

Die Ausgabe zeigt Informationen für die LDP-Sitzung mit IPv6 als TCP-Transport an.

Überprüfung

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

Überprüfen der LDP Neighbor Information
Zweck

Zeigen Sie die LDP-Nachbarninformationen an.

Aktion

Führen Sie auf Gerät R1 im Betriebsmodus den show ldp neighbor extensive Befehl aus, um LDP-Nachbarninformationen anzuzeigen.

Bedeutung

Die Ausgabe zeigt LDP-Nachbarninformationen für die IPv4- und IPv6-Adressen an.

Überprüfen der LDP-Sitzungsinformationen
Zweck

Zeigen Sie die LDP-Sitzungsinformationen an.

Aktion

Führen Sie den Befehl auf Gerät R1 aus dem Betriebsmodus aus, um LDP-Sitzungsinformationen show ldp session extensive anzuzeigen.

Bedeutung

Die Ausgabe zeigt Informationen für die LDP-Sitzung mit IPv6 als TCP-Transport an.

Überprüfung

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

Überprüfen der LDP Neighbor Information
Zweck

Zeigen Sie die LDP-Nachbarninformationen an.

Aktion

Führen Sie auf Gerät R1 im Betriebsmodus den show ldp neighbor extensive Befehl aus, um LDP-Nachbarninformationen anzuzeigen.

Bedeutung

Die Ausgabe zeigt LDP-Nachbarninformationen für die IPv4- und IPv6-Adressen an.

Überprüfen der LDP-Sitzungsinformationen
Zweck

Zeigen Sie die LDP-Sitzungsinformationen an.

Aktion

Führen Sie auf Gerät R1 im Betriebsmodus den show ldp session extensive Befehl aus, um LDP-Nachbarninformationen anzuzeigen.

Beispiel: Konfiguration von Multipoint-LDP-In-Band-Signalisierung für Point-to-Multipoint-LSPs

Verständnis der Multipoint-LDP-Inband-Signalisierung für Point-to-Multipoint-LSPs

Das Multipoint Label Distribution Protocol (M-LDP) für Point-to-Multipoint Label-Switched Paths (LSPs) mit In-Band-Signaling ist in einer Bereitstellung mit einem vorhandenen IP/MPLS-Backbone nützlich, in dem Sie Multicast-Datenverkehr, z. B. für IPTV, übertragen müssen.

Die seit Jahren am weitesten verbreitete Lösung für die Übertragung von Multicast-Datenverkehr war, native IP-Multicast im Service Provider-Core mit Multipoint-IP-Tunneling zu verwenden, um den Kundendatenverkehr zu isolieren. Zum Einrichten der Weiterleitungspfade wird ein Multicast-Routing-Protokoll (Protocol Independent Multicast, PIM) bereitgestellt. Ip-Multicast-Routing wird für die Weiterleitung verwendet, unter Verwendung von PIM-Signalen im Core. Damit dieses Modell funktioniert, muss das Core-Netzwerk Multicast-fähig sein. Dies ermöglicht effektive und stabile Bereitstellungen auch in Szenarien mit inter-autonomen Systemen (AS).

In einem vorhandenen IP/MPLS-Netzwerk ist die Bereitstellung von PIM jedoch möglicherweise nicht die erste Wahl. Einige Service Provider sind daran interessiert, IP-Tunneling durch MPLS-Label-Kapselung zu ersetzen. Die Gründe für die Umstellung auf MPLS-Label-Switching sind die Nutzung von MPLS Traffic Engineering- und Schutzfunktionen sowie die Reduzierung des Kontroll-Datenverkehrs-Overheads im Provider-Core.

Um dies zu tun, sind Service Provider daran interessiert, die Erweiterung der vorhandenen Bereitstellungen zu nutzen, um 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 Bereitstellungsszenarien werden in RFC 6826, Multipoint LDP In-Band Signaling für Point-to-Multipoint- und Multipoint-to-Multipoint-Label Switched Paths diskutiert. Diese Funktionsübersicht ist auf Point-to-Multipoint-Erweiterungen für LDP beschränkt.

Funktionsweise von M-LDP

Label-Bindungen in M-LDP-Signalübertragung

Die Multipoint-Erweiterung für LDP verwendet Point-to-Multipoint- und Multipoint-to-Multipoint Forwarding Equivalence Class(FEC)-Elemente (definiert in RFC 5036, LDP-Spezifikation) zusammen mit Funktionsanzeigen, Labelzuordnung und Signalverfahren. Die FEC-Elemente umfassen die Idee des LSP-Root, bei dem es sich um eine IP-Adresse handelt, und einen "undurchsichtigen" 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 kündigt seine lokale eingehende Label-Bindung an den Upstream-LDP-Knoten auf dem kürzesten Pfad zu der im FEC gefundenen Root-IP-Adresse an. Der Upstream-Knoten, der die Labelbindungen empfängt, erstellt seine eigenen lokalen Label- und ausgehenden Schnittstellen. Dieser Prozess der Labelzuweisung kann zu einer Paketreplikation führen, wenn mehrere ausgehende Zweigstellen vorhanden sind. Wie in Abbildung 18der Abbildung dargestellt, führt ein LDP-Knoten die Labelbindungen für den gleichen undurchsichtigen Wert zusammen, wenn er downstream-Knoten findet, die sich denselben Upstream-Knoten teilen. Dies ermöglicht den effektiven Aufbau von Point-to-Multipoint-LSPs und die Konservierung von Labeln.

Abbildung 18: Label-Bindungen in M-LDP-SignalübertragungLabel-Bindungen in M-LDP-Signalübertragung
M-LDP in PIM-freien MPLS-Core

Abbildung 19 zeigt ein herunterskaliertes Bereitstellungsszenario. Zwei separate PIM-Domänen sind durch einen PIM-freien Core-Standort miteinander verbunden. Die Border-Router an diesem Core-Standort unterstützen PIM an den Randschnittstellen. Darüber hinaus sammeln diese Border-Router die Routing-Informationen von den angrenzenden Standorten und verteilen sie auf das Core-Netzwerk. Die Edge-Router an Standort C führen BGP für die Root-Node-Erkennung aus. Interior Gateway Protocol (IGP)-Routen können nicht für die Eingangserkennung verwendet werden, da in den meisten Fällen der nächste Weiterleitungs-Hop, der von der IGP bereitgestellt wird, keine Informationen über das Eingangsgerät zur Quelle liefern würde. M-LDP-Inband-Signalisierung verfügt über eine 1-zu-eins-Zuordnung zwischen dem Point-to-Multipoint-LSP und dem (S,G)-Datenstrom. Mit In-Band-Signalisierung werden PIM-Nachrichten direkt in M-LDP FEC-Bindungen übersetzt. Im Gegensatz dazu basiert die Out-of-Band-Signalübertragung auf einer manuellen Konfiguration. Eine Anwendung für M-LDP-Inband-Signalisierung besteht darin, IPTV-Multicast-Datenverkehr in einem MPLS-Backbone zu übertragen.

Abbildung 19: Beispiel für die M-LDP-Topologie im PIM-freien MPLS-CoreBeispiel für die M-LDP-Topologie im PIM-freien MPLS-Core
Konfiguration

Die Konfigurationsaussage mldp-inband-signalling auf dem Label-Edge-Router (LER) ermöglicht PIM die Verwendung von M-LDP-In-Band-Signalisierung für die Upstream-Nachbarn, wenn der LER keinen PIM-Upstream-Nachbarn erkennt. Die statische Konfiguration des MPLS-LSP-Stammes ist mithilfe von Richtlinien in der PIM-Konfiguration enthalten. Dies ist erforderlich, wenn IBGP am Core-Standort nicht verfügbar ist oder um die IBGP-basierte LSP-Root-Erkennung zu überschreiben.

Zum Beispiel:

M-LDP in PIM-fähiger MPLS Core

Ab Junos OS Version 14.1 müssen Sie einen reibungslosen Übergang von PIM zu M-LDP-Point-to-Multipoint-LSPs mit minimalem Ausfall durchführen, um vorhandene IPTV-Services von nativem IP-Multicast auf MPLS-Multicast zu migrieren. 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 durch seine Gruppenadresse identifiziert wird. Zuvor wurden diese Kanäle als IP-Streams auf dem Core gestreamt und mit PIM signalisiert.

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

Durch die Konfiguration der mldp-inband-signaling in diesem Szenario erfolgten M-LDP-Signalübertragung nur dann, wenn kein PIM-Nachbarn zur Quelle hin vorhanden ist. Da es jedoch immer einen PIM-Nachbarn zur Quelle gibt, es sei denn, PIM wird an den Upstream-Schnittstellen des Ausgangs-PE deaktiviert, hat PIM Vorrang vor M-LDP und M-LDP tritt nicht in Kraft.

Konfiguration

Zur schrittweisen Migration von Kanal zu M-LDP-MPLS-Core mit wenigen Streams unter Verwendung des M-LDP-Upstreams und anderer Streams unter Verwendung vorhandener PIM-Upstream-Daten, fügen Sie die selected-mldp-egress Konfigurationsaussage zusammen mit gruppenbasierten Filtern in den Richtlinienfilter für M-LDP-Inbandsignalisierung ein.

HINWEIS:

Der M-LDP-Inband-Signalrichtlinienfilter kann entweder die source-address-filter Anweisung oder die route-filter Anweisung oder eine Kombination aus beidem enthalten.

Zum Beispiel:

HINWEIS:

Einige der Einschränkungen der obigen Konfiguration sind wie folgt:

  • Die selected-mldp-egress Anweisung sollte nur auf dem LER konfiguriert werden. Die Konfiguration der selected-mldp-egress Anweisung auf nicht ausgehenden PIM-Routern kann zu Fehlern bei der Pfadeinrichtung führen.

  • Wenn Richtlinienänderungen vorgenommen werden, um den Datenverkehr von PIM-Upstream zu M-LDP-Upstream und umgekehrt zu wechseln, 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-Signalisierung für Multicast-Datenverkehr.

Point-to-point LSP

Ein LSP mit einem Eingangs-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 einem Eingangs-LSR und einem oder mehreren Ausgangs-LSRs.
Multipoint-to-point LSP

Ein LSP mit einem oder mehreren Eingangs-LSRs und einem eindeutigen Ausgangs-LSR.
Multipoint-to-multipoint LSP

Ein LSP, der eine Reihe von Knoten verbindet, sodass der Datenverkehr, der von einem beliebigen Knoten im LSP gesendet wird, an alle anderen übermittelt wird.

Ingress LSR

Ein Eingangs-LSR für einen bestimmten LSP ist eine LSR, die ein Datenpaket über den LSP senden kann. Multipoint-to-Multipoint-LSPs können mehrere Eingangs-LSRs haben. Point-to-Multipoint-LSPs haben nur einen, und dieser Knoten wird oft als Root-Knoten bezeichnet.
Egress LSR

Ein Ausgangs-LSR für einen bestimmten LSP ist eine LSR, die ein Datenpaket für die weitere Verarbeitung aus diesem LSP entfernen kann. Punkt-zu-Punkt- und Multipoint-to-Point-LSPs haben nur einen einzigen Ausgangsknoten. Point-to-Multipoint- und Multipoint-to-Multipoint-LSPs können mehrere Ausgangsknoten haben.
Transit LSR

Ein LSR, der über einen direkt verbundenen Upstream-LSR und ein oder mehrere direkt angeschlossene Downstream-LSRs zum Ursprung des Multipoint-LSP erreichbar ist.

Bud LSR

Ein LSR, der ein Ausgang ist, aber auch über eine oder mehrere direkt angeschlossene Downstream-LSRs verfügt.
Leaf node

Entweder ein Ausgangs- oder Knospen-LSR im Kontext eines Point-to-Multipoint-LSP. Im Kontext eines Multipoint-to-Multipoint-LSP ist ein LSR sowohl Ein- als auch Ausgang für den gleichen 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 das In-Band-Signal empfangen werden. PIM verknüpft jede (S,G)-Nachricht mit einer Pseudo-Schnittstelle. Anschließend wird eine Join-Nachricht mit dem kürzesten Pfadbaum (SPT) in Richtung der Quelle eingeleitet. PIM behandelt dies als eine neue Art von lokalem Empfänger. Wenn der LSP abgerissen wird, entfernt PIM diesen lokalen Empfänger basierend auf einer Benachrichtigung von LDP.

Eingangs-Splicing

LDP stellt PIM mit einem nächsten Hop bereit, der jedem (S,G)-Eintrag zugeordnet wird. PIM installiert eine PIM(S,G)-Multicast-Route mit dem LDP Next Hop und anderen PIM-Empfängern. Der nächste Hop ist ein zusammengesetzter Next Hop aus lokalen Empfängern + die Liste der PIM-Downstream-Nachbarn + ein nächster Hop auf einer Untergeordneten Ebene fü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-Signalisierung durch, wenn alle folgenden Bedingungen zutreffen:

  • Es gibt keine PIM-Nachbarn gegenüber der 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-Signaling-Richtlinie).

Andernfalls, wenn die LSP-Root-Erkennung fehlschlägt, behält PIM den (S,G)-Eintrag mit einem RPF-Status nicht gelöst.

PIM RPF registriert diese Quelladresse bei jeder Änderung der Unicast-Routing-Informationen. Wenn sich also die Route zur Quelle ändert, wird die RPF-Neuberechnung wiederholt. Auch die nächsten Hops des BGP-Protokolls zur Quelle werden auf Änderungen am LSP-Root überwacht. Solche Änderungen können zu kurzzeitigen Unterbrechungen des Datenverkehrs führen.

LSP-Root-Erkennung

Wenn der RPF-Vorgang erkennt, dass M-LDP-In-Band-Signalübertragung vorgeschaltet ist, wird der LSP-Root (Eingang) erkannt. Dieser Root ist ein Parameter für LDP-LSP-Signalübertragung.

Der Root-Knoten wird wie folgt erkannt:

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

  2. Eine Suche wird in der Unicast-Routing-Tabelle 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 der M-LDP Point-to-Multipoint-LSP über die Root-Adresse des Eingangs-LSR vom Ausgangs- zum Eingang signalisiert. Diese Root-Adresse ist nur über IGP erreichbar, wodurch der M-LDP-Point-to-Multipoint-LSP auf ein einziges autonomes System beschränkt wird. Wenn die Root-Adresse nicht über eine IGP, 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-Stammadresse signalisiert.

    Diese nicht segmentierten Point-to-Multipoint-LSPs müssen über mehrere autonome Systeme hinweg 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.

    • Bereichsübergreifende MVPN- oder M-LDP-Inband-Signalübertragung mit nicht segmentierten Point-to-Multipoint-LSPs (seamless MPLS Multicast).

    Ab Junos OS Version 16.1 kann M-LDP Point-to-Multipoint-LSPs an ASBR oder transit oder ausgehend signalisieren, wenn es sich bei der Root-Adresse um eine BGP-Route handelt, die über einen MPLS-LSP weiter rekursiv aufgelöst wird.

Egress Join Translation und Pseudo Interface Handling

Am Ausgangs-LER benachrichtigt PIM die LDP der (S,G)-Nachricht, die zusammen mit dem LSP-Root signalisiert werden soll. PIM erstellt eine Pseudo-Schnittstelle als Upstream-Schnittstelle für diese (S,G)-Nachricht. Wenn eine (S,G)-Prune-Nachricht empfangen wird, wird diese Zuordnung entfernt.

Egress Splicing

Am Ausgangsknoten des Core-Netzwerks, wo die (S,G)-Join-Nachricht vom Downstream-Standort empfangen wird, wird diese Join-Nachricht in M-LDP-In-Band-Signalisierungsparameter übersetzt und LDP wird benachrichtigt. Darüber hinaus tritt der LSP-Teardown auf, wenn der (S,G)-Eintrag verloren geht, wenn sich der LSP-Root ändert oder wenn der (S,G)-Eintrag über einen PIM-Nachbarn erreichbar ist.

Unterstützte Funktionen

Für M-LDP-In-Band-Signalisierung unterstützt Junos OS die folgenden Funktionen:

  • Ausgangssplicing des PIM Next Hop mit der LDP-Route

  • Eingehendes Splicing der PIM-Route mit dem LDP next Hop

  • Übersetzung von PIM-Join-Nachrichten in LDP Point-to-Multipoint-LSP-Setup-Parameter

  • Übersetzung von M-LDP-In-Band-LSP-Parametern zur Einrichtung von PIM-Join-Nachrichten

  • Statisch konfiguriert und BGP-Protokoll next Hop-basierte LSP-Root-Erkennung

  • PIM-Zustände (S,G) in den PIM Source-Specific Multicast (SSM) und AnySource Multicsast (ASM) Bereichen

  • Konfigurationsanweisungen für Eingangs- und Ausgangs-LERs, damit sie als Edge-Router fungieren können

  • IGMP-Join-Nachrichten auf LERs

  • Mit IPv6-Quell- und Gruppenadresse als undurchsichtige Informationen zu einem IPv4-Root-Knoten

  • Statische Konfiguration zum Zuordnen einer IPv6 (S,G) zu einer IPv4-Root-Adresse

Nicht unterstützte Funktionen

Für M-LDP-In-Band-Signalisierung unterstützt Junos OS die folgenden Funktionen nicht :

  • Volle 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 keine IPv6-LSPs.)

  • Nachbarschaftsbeziehung zwischen PIM-Sprechern, die nicht direkt verbunden sind

  • Graceful-Restart

  • PIM-Dense-Modus

  • PIM-bidirektionaler Modus

LDP-Funktionalität

Die PIM-Informationen (S,G) werden als M-LDP-opaque Type-Length-Value (TLV) Codierung übertragen. Das Point-to-Multipoint-FEC-Element besteht aus der Root-Node-Adresse. Im Fall von Multicast-VPNs der nächsten Generation (NGEN MVPNs) wird der Point-to-Multipoint-LSP durch die Root-Node-Adresse und die LSP-ID identifiziert.

Ausgangs-LER-Funktionalität

Auf dem Ausgangs-LER löst PIM LDP mit den folgenden Informationen aus, um einen Point-to-Multipoint-LSP zu erstellen:

  • Root-Knoten

  • (S,G)

  • Nächster Hop

PIM findet den Root-Knoten basierend auf der Quelle der Multicast-Struktur. Wenn die Stammadresse für diesen Eintrag (S,G) 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 der Multicast-Struktur um eine BGP-gelernte Route handelt, ruft PIM die BGP-Adresse des nächsten Hops ab und verwendet sie als Root-Knoten für den Point-to-Multipoint-LSP.

LDP sucht den Upstream-Knoten basierend auf dem Stammknoten, weist ein Label zu und sendet die Labelzuordnung an den Upstream-Knoten. LDP verwendet nicht vorletzte Hop Popping (PHP) für in-Band M-LDP-Signalisierung.

Wenn sich die Stammadressen für die Quelle der Multicast-Struktur ä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 Liste der ausgehenden Schnittstellen null, PIM löst LDP aus, um den Point-to-Multipoint-LSP zu löschen, und LDP sendet eine Nachricht zum Zurücknehmen des Etiketts an den Upstream-Knoten.

Transit-LSR-Funktionalität

Der Transit-LSR kündigt ein Label an der Upstream-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 die folgenden 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 gelöscht werden, weil ein Label zurückgezogen wurde, sendet LDP aktualisierte Informationen an PIM. Wenn es mehrere Verbindungen zwischen den Upstream- und Downstream-Nachbarn gibt, wird der Point-to-Multipoint-LSP nicht lastausgleichen.

Siehe auch

Beispiel: Konfiguration von Multipoint-LDP-In-Band-Signalisierung für Point-to-Multipoint-LSPs

Dieses Beispiel zeigt, wie M-LDP (Multipoint LDP) In-Band-Signalisierung für Multicast-Datenverkehr, als Erweiterung des Protocol Independent Multicast (PIM)-Protokolls oder als Ersatz für PIM konfiguriert wird.

Anforderungen

Dieses Beispiel kann mit den 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 (PE)-Router

  • Paketübertragungs-Router der PTX-Serie fungieren als Transit label-switched Router

  • Core-Router der T-Serie für Core-Router

HINWEIS:

Bei den PE-Routern können auch Core-Router der T-Serie sein, aber das ist nicht typisch. Abhängig von Ihren Skalierungsanforderungen können die Core-Router auch universelle 5G-Routing-Plattformen der MX-Serie oder Multiservice-Edge-Router der M-Serie sein. Bei den Kunden-Edge-Geräten (CE) kann es sich um andere Router oder Switches von Juniper Networks oder einem anderen Anbieter handeln.

Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

Überblick

CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 21. In diesem Abschnitt #d158e70__d158e838 werden die Schritte für Device EgressPE beschrieben.

Abbildung 21: M-LDP-In-Band-Signalisierung für Point-to-Multipoint-LSPs – Beispieltopologie M-LDP-In-Band-Signalisierung 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 in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.

Gerät src1

GeräteingressPE

Geräte-AusgangPE

Gerät P6

Gerät pr3

Gerät pr4

Gerät pr5

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf 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äte-AusgangsPE:

  1. Konfigurieren Sie die Schnittstellen.

    Aktivieren Sie MPLS auf den Kernschnittstellen. Auf den ausgehenden nächsten Hops müssen Sie MPLS nicht aktivieren.

  2. Konfigurieren Sie IGMP auf den Ausgangsschnittstellen.

    Zu Testzwecken umfasst dieses Beispiel statische Gruppen- und Quelladressen.

  3. Konfigurieren Sie MPLS auf den Kernschnittstellen.

  4. Konfigurieren Sie BGP.

    BGP ist ein richtliniengesteuertes Protokoll, also konfigurieren und wenden Sie alle erforderlichen Routing-Richtlinien an.

    Sie können beispielsweise statische Routen in BGP exportieren.

  5. (Optional) Konfigurieren Sie eine MSDP-Peer-Verbindung mit Device pr5, um die unterschiedlichen PIM-Domänen miteinander zu verbinden und so redundante RPs zu ermöglichen.

  6. Konfigurieren Sie OSPF.

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

  8. Ermöglichen Sie Point-to-Multipoint-MPLS-LSPs.

  9. Konfigurieren Sie PIM auf den Downstream-Schnittstellen.

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

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

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

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

Ergebnisse

Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie die show interfacesBefehle , show protocols, show policy-optionsund show routing-options eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Geräte-AusgangPE

Konfigurieren Sie auch die anderen Ausgangsgeräte.

Wenn Sie mit der Konfiguration der Geräte fertig sind, geben Sie im Konfigurationsmodus ein commit .

Überprüfung

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

Überprüfung der PIM-Join-Status
Zweck

Zeigen Sie Informationen über PIM-Join-Status an, um die M-LDP-Upstream- und Downstream-Details im Upstream- und Downstream-Band 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üfung der PIM-Quellen
Zweck

Stellen Sie sicher, dass die PIM-Quellen die erwarteten M-LDP-In-Band-Upstream- und Downstream-Details haben.

Aktion

Geben Sie im Betriebsmodus den show pim source Befehl ein.

Überprüfung 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 Point-to-Multipoint-FEC-Informationen an.

Aktion
Überprüfung der LDP-Datenverkehrsstatistiken
Zweck

Überwachen Sie die Datenverkehrsstatistiken für den Point-to-Multipoint-LSP.

Aktion

Zuordnung von Client und Server für Segment-Routing auf LDP-Interoperabilität

Segment-Routing-Zuordnungsserver und Client-Unterstützung ermöglichen die Interoperabilität zwischen Netzwerkinseln, auf denen LDP und Segment-Routing (SR oder SPRING) ausgeführt werden. Diese Interoperabilität ist bei einer Migration von LDP zu SR nützlich. Während des Übergangs kann es Inseln (oder Domänen) mit Geräten geben, die entweder nur LDP oder nur Segment-Routing unterstützen. Damit diese Geräte die Funktionen des LDP-Segment-Routing-Mapping-Servers (SRMS) und des SrMC (Segment Routing Mapping Client) miteinander verzahnen können, ist erforderlich. Sie aktivieren diese Server- und Client-Funktionen auf einem Gerät im Segment-Routing-Netzwerk.

SR-Zuordnungsserver- und Client-Funktionen werden von OSPF oder ISIS unterstützt.

Überblick über Segment-Routing zu LDP-Interoperabilität

Abbildung 22 zeigt eine einfache LDP-Netzwerktopologie, um die Interoperabilität von Segment-Routing-Geräten mit LDP-Geräten zu veranschaulichen. Denken Sie daran, dass sowohl OSPF als auch ISIS unterstützt werden, daher werden wir die Dinge in Bezug auf die IGP vorerst unabhängig halten. Die Beispieltopologie umfasst sechs Geräte, R1 bis R6, in einem Netzwerk, das eine Migration von LDP zu Segment-Routing durchläuft.

In der Topologie sind die Geräte R1, R2 und R3 nur für das Segment-Routing konfiguriert. Die Geräte R5 und R6 sind Teil einer älteren LDP-Domäne und unterstützen DERZEIT keine SR. Gerät R4 unterstützt sowohl LDP- als auch Segment-Routing. Die Loopback-Adressen aller Geräte werden angezeigt. Diese Loopbacks werden als Ausgangs-FECs in der LDP-Domäne und als SR-Knoten-IDs in der SR-Domäne angekündigt. Die Interoperabilität basiert auf der Zuordnung eines LDP-FEC in eine SR-Knoten-ID und umgekehrt.

Abbildung 22: Beispiel für Segment-Routing zu LDP-Interoperabilitätstopologie Beispiel für Segment-Routing zu LDP-Interoperabilitätstopologie

Damit R1 mit R6 zusammenarbeiten kann, sind sowohl ein LDP-Segment-Routing-Mapping-Server (SRMS) als auch ein Segment-Routing-Mapping-Client (SRMC) erforderlich. Es ist einfacher, die Rolle von SRMS und SRMC zu verstehen, indem sie den Datenverkehrsfluss unidirektional betrachten. Basierend auf Abbildung 22, sagen wir, dass der Datenverkehr, der von links nach rechts fließt, aus der SR-Domäne stammt und in der LDP-Domäne endet. Der Datenverkehr, der von rechts nach links fließt, stammt aus der LDP-Domain und endet in der SR-Domain.

Das SRMS liefert die Informationen, die für die Zusammenführung des Datenverkehrs in links-rechts-Richtung erforderlich sind. Die SRMC bietet eine Zuordnung für den Datenverkehr, der von rechts nach links fließt.

  • Datenverkehrsfluss von links nach rechts: Der Segment-Routing-Zuordnungsserver

    Das SRMS erleichtert das LSP-Stitching zwischen den SR- und LDP-Domänen. Der Server ordnet LDP-FECs in SR-Knoten-IDs zu. Sie konfigurieren die LDP-FECs, die unter der [edit routing-options source-packet-routing] Hierarchieebene zugeordnet werden. Normalerweise müssen Sie alle LDP-Node-Loopback-Adressen für die vollständige Konnektivität zuordnen. Wie unten dargestellt, können Sie zusammenhängende Präfixe in einer einzigen Range-Anweisung zuordnen. Wenn die LDP-Knoten-Loopbacks nicht zusammenhängend sind, müssen Sie mehrere Zuordnungsanweisungen definieren.

    Sie wenden die SRMS-Zuordnungskonfiguration unter der [edit protocols ospf] Hierarchie- oder [edit protocols isis] Hierarchieebene an. Diese Wahl hängt davon ab, welche IGP verwendet wird. Beachten Sie, dass sowohl der SR- als auch der LDP-Knoten eine gemeinsame IGP-Routing-Domain mit einem einzigen Bereich/ebene teilen.

    Das SRMS generiert eine erweiterte Prefix-Liste LSA (oder LSP im Fall von ISIS). Die Informationen in dieser LSA ermöglichen es den SR-Knoten, LDP-Präfixe (FECs) auf SR-Knoten-IDs zu zuordnen. Die abgebildeten Routen für die LDP-Präfixe werden in den inet.3mpls.0 Routing-Tabellen der SR-Knoten installiert, um LSP-Eingangs- und Stitching-Operationen für den Datenverkehr in links nach rechts zu erleichtern.

    Die erweiterte LSA (oder LSP) wird im (einzigen) IGP-Bereich überflutet. Das bedeutet, dass Sie die SRMS-Konfiguration frei auf jedem Router in der SR-Domain platzieren können. Der SRMS-Knoten muss keine LDP ausführen.

  • Datenverkehrsfluss von rechts nach links: Der Client für die Segment-Routing-Zuordnung

    Wenn Sie in der rechten nach links-Richtung zusammenarbeiten möchten, d. h. von der LDP-Insel bis zur SR-Insel, aktivieren Sie einfach die Client-Funktionalität des Segment-Routings auf einem Knoten, der sowohl SR als auch LDP spricht. In unserem Beispiel ist das R4. Sie aktivieren die SRMC-Funktionalität mit der mapping-client Anweisung in der [edit protocols ldp] Hierarchie.

    Die SRMC-Konfiguration aktiviert automatisch eine LDP-Ausgangsrichtlinie, um den Knoten der SR-Domain und die Prefix-SIDs als LDP-Ausgangs-FECs ankündigen. Dadurch erhalten die LDP-Knoten eine LSP-Erreichbarkeit zu den Knoten in der SR-Domäne.

  • Die SRMC-Funktion muss auf einem Router konfiguriert werden, der sowohl an die SR- als auch an die LSP-Domänen angebunden ist. Auf Wunsch kann derselbe Knoten auch wie der SRMS funktionieren.

Segment-Routing zu LDP-Interoperabilität mit OSPF

Abbildung 22Gehen Sie davon aus, dass device R2 (im Segment-Routing-Netzwerk) das SRMS ist.

  1. Definieren der SRMS-Funktion:

    Diese Konfiguration erstellt einen Zuordnungsblock für beide LDP-Geräte-Loopback-Adressen in der Beispieltopologie. Der anfängliche Segment ID (SID)-Index, der dem Loopback von R5 zugeordnet wird, ist 1000. Das Festlegen der Größe 2 führt dazu, dass der SID-Index 10001 der Loopback-Adresse von R6 zugeordnet wird.

    HINWEIS:

    Die als start-prefix Schleife verwendete IP-Adresse ist eine Loopback-Adresse eines Geräts im LDP-Netzwerk (in diesem Beispiel R5). Für vollständige Konnektivität müssen Sie alle Loopback-Adressen der LDP-Router der SR-Domäne zuordnen. Wenn die Loopback-Adressen zusammenhängend sind, können Sie dies mit einer einzigen prefix-segment-range Anweisung tun. Nicht zusammenhängende Loopbacks erfordern die Definition mehrerer Präfixzuordnungsanweisungen.

    In unserem Beispiel werden zusammenhängende Loopbacks verwendet, sodass oben ein einzelner prefix-segment-range dargestellt wird. Hier ist ein Beispiel für mehrere Zuordnungen zur Unterstützung von zwei LDP-Knoten mit nicht zusammenhängender Loopback-Adressierung:

  2. Konfigurieren Sie als Nächstes die OSPF-Unterstützung für die erweiterte LSA, die zum Überfluten der zugeordneten Präfixe verwendet wird.

    Sobald die Zuordnungsserverkonfiguration auf Gerät R2 festgelegt wurde, wird der erweiterte Präfixbereich TLV im OSPF-Bereich überflutet. Die Geräte, die Segment-Routing können (R1, R2 und R3), installieren OSPF-Segment-Routing-Routen für die angegebene Loopback-Adresse (R5 und R6 in diesem Beispiel) mit einem Segment ID (SID)-Index. Der SID-Index wird auch in der mpls.0 Routing-Tabelle von den Segment-Routing-Geräten aktualisiert.

  3. Aktivieren Sie die SRMC-Funktionalität. Für unsere Beispieltopologie müssen Sie die SRMC-Funktionalität auf R4 aktivieren.

    Sobald die Client-Zuordnungskonfiguration auf Dem Gerät R4 festgelegt wurde, werden die SR-Knoten-IDs und Label-Blöcke als Ausgangs-FECs an Router R5 angekündigt, der sie dann erneut an R6 anpreist.

Die Unterstützung für das Stitching von Segment-Routing und LDP-Next-Hops mit OSPF begann in Junos OS 19.1R1.

Unsupported Features and Functionality for Segment Routing interoperability with LDP using OSPF

  • Prefix-Konfliktes werden nur am SRMS erkannt. Wenn ein Prefix-Bereichskonflikt besteht, hat die Präfix-SID von der unteren Router-ID Vorrang. In solchen Fällen wird eine FehlermeldungRPD_OSPF_PFX_SID_RANGE_CONFLICT aus dem Systemprotokoll generiert.

  • IPv6-Präfixe werden nicht unterstützt.

  • Flooding der OSPF Extended Prefix Opaque LSA über AS-Grenzen (Inter-AS) wird nicht unterstützt.

  • Die Funktionen von LDP-Zuordnungsservern zwischen bereichen 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.

  • Die Voreinstellungs-TLV für den Ement-Routing-Zuordnungsserverwird nicht unterstützt.

Interoperabilität von Segment-Routing mit LDP mit ISIS

Abbildung 22Gehen Sie davon aus, dass Gerät R2 (im Segment-Routing-Netzwerk) das SRMS ist. Die folgende Konfiguration wird für die Zuordnungsfunktion hinzugefügt:

  1. Definieren der SRMS-Funktion:

    Diese Konfiguration erstellt einen Zuordnungsblock für beide LDP-Geräte-Loopback-Adressen in der Beispieltopologie. Der anfängliche Segment-ID -Index (SID), der dem Loopback von R5 zugeordnet ist, ist 1000. Das Festlegen der Größe 2 führt dazu, dass der SID-Index 10001 der Loopback-Adresse von R6 zugeordnet wird.

    HINWEIS:

    Die als start-prefix Schleife verwendete IP-Adresse ist eine Loopback-Adresse eines Geräts im LDP-Netzwerk (in diesem Beispiel R5). Für eine vollständige Konnektivität müssen Sie alle Loopback-Adressen der LDP-Router in der SR-Domäne zuordnen. Wenn die Loopback-Adressen zusammenhängend sind, können Sie dies mit einer prefix-segment-range Anweisung tun. Nicht zusammenhängende Loopbacks erfordern die Definition mehrerer Zuordnungsanweisungen.

    In unserem Beispiel werden zusammenhängende Loopbacks verwendet, sodass oben ein einzelner prefix-segment-range dargestellt wird. Dies ist ein Beispiel für Präfixzuordnungen für den Fall von zwei LDP-Routern mit nicht zusammenhängender Loopback-Adressierung:

  2. Konfigurieren Sie als Nächstes die ISIS-Unterstützung für den erweiterten LSP, der zum Überfluten der zugeordneten Präfixe verwendet wird.

    Sobald die Zuordnungsserverkonfiguration auf Gerät R2 festgelegt wurde, wird der erweiterte Präfixbereich TLV im OSPF-Bereich überflutet. Die Geräte, die Segment-Routing können (R1, R2 und R3), installieren ISIS-Segment-Routing-Routen für die angegebene Loopback-Adresse (R5 und R6 in diesem Beispiel) mit einem Segment ID (SID)-Index. Der SID-Index wird auch in der mpls.0 Routing-Tabelle von den Segment-Routing-Geräten aktualisiert.

  3. Aktivieren Sie die SRMC-Funktionalität. Für unsere Beispieltopologie müssen Sie die SRMC-Funktionalität auf R4 aktivieren.

    Sobald die Zuordnungs-Client-Konfiguration auf Gerät R4 festgelegt wurde, werden die SR-Knoten-IDs und Label-Blöcke als Ausgangs-FECs zum Router R5 und von dort zu R6 angekündigt.

Die Unterstützung für das Zusammenfügen von Segment-Routing und LDP-Next-Hops mit ISIS begann in Junos OS 17.4R1.

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS

  • Das vorletzte Hop-Popping-Verhalten für die Labelbindung TLV wird nicht unterstützt.

  • Die Werbung für eine Reihe von Präfixen in der Labelbindung TLV wird nicht unterstützt.

  • Die Konfliktauflösung im 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-Inter-Level wird nicht unterstützt.

  • RFC 7794, IS-IS PrefixAttribute für Erweiterte IPv4 wird nicht unterstützt.

  • Die Neuverteilung der LDP-Route als Prefix-Sid am Stitching-Knoten wird nicht unterstützt.

Sonstige LDP-Eigenschaften

In den folgenden Abschnitten wird die Konfiguration einer Reihe verschiedener LDP-Eigenschaften beschrieben.

Konfigurieren von LDP für die Verwendung der IGP-Route-Metrik

Verwenden Sie die track-igp-metric Anweisung, wenn die Routingmetrik des Interior Gateway Protocol (IGP) 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 Anweisung ein track-igp-metric :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Verhindern des Hinzufügens von Eingangsrouten zur Routingtabelle inet.0

Indem Sie die no-forwarding Anweisung konfigurieren, können Sie verhindern, dass eingehende Routen zur 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] Hierarchie- oder [edit logical-systems logical-system-name protocols mpls] Hierarchieebene aktiviert haben. Standardmäßig ist die no-forwarding Anweisung deaktiviert.

HINWEIS:

Router der ACX-Serie unterstützen die Hierarchieebene [edit logical-systems] nicht.

Um eingehende Routen aus der Routingtabelle inet.0 auszulassen, fügen Sie die Anweisung ein no-forwarding :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Multiple-Instance-LDP und Carrier-of-Carrier-VPNs

Indem Sie mehrere LDP-Routing-Instanzen konfigurieren, können Sie LDP verwenden, um Label in einem Carrier-of-Carrier-VPN von einem Service Provider-Edge-Router (PE) zu einem Customer Carrier Customer Edge (CE)-Router anzukündigen. Dies ist besonders nützlich, wenn der Carrier-Kunde ein grundlegender Internet Service Provider (ISP) ist und vollständige Internetrouten 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 vor 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-Routing-Instanzen für CARRIER-of-Carrier-VPNs finden Sie im Benutzerhandbuch "Multiple Instances for Label Distribution Protocol".

Konfigurieren Sie MPLS und LDP, um das Label auf dem Ultimate-Hop-Router zu füllen

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 ultimative Hop-Popping zu konfigurieren, fügen Sie die Anweisung ein explicit-null :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

HINWEIS:

Router von Juniper Networks warteschlangen Pakete basierend auf dem eingehenden Label. Router anderer Anbieter können Pakete anders anstellen. Denken Sie daran, wenn Sie mit Netzwerken arbeiten, die Router von mehreren Anbietern enthalten.

Weitere Informationen zu Labeln finden Sie unter ÜBERSICHT ÜBER MPLS-Label und MPLS-Labelzuweisung.

Ermöglichen von LDP über RSVP-etablierte LSPs

Sie können LDP über LSPs ausführen, die von RSVP eingerichtet wurden, und den LDP-etablierten LSP 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 Hierarchieebene [edit protocols mpls label-switched-path lsp-name] angeben:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

HINWEIS:

LDP kann über eine RSVP-Sitzung tunnelt werden, die den Linkschutz aktiviert hat. Beginnend mit Junos OS Release 21.1R1 zeigt die Details zur LDP-tunnelten Route sowohl die primären als auch die Bypass-LSP-Next-Hops an. In früheren Junos OS-Versionen zeigte der Umgehungs-LSP den nächsten Hop für den primären LSP an.

Aktivierung von LDP über RSVP-etablierte LSPs in heterogenen Netzwerken

Einige andere Anbieter verwenden eine OSPF-Metrik von 1 für die Loopback-Adresse. Router von Juniper Networks verwenden eine OSPF-Metrik von 0 für die Loopback-Adresse. Dies kann erfordern, dass Sie die RSVP-Metrik bei der Bereitstellung von LDP-Tunneling über RSVP-LSPs in heterogenen Netzwerken manuell konfigurieren.

Wenn ein Router von Juniper Networks über einen RSVP-Tunnel mit dem Router eines anderen Anbieters verbunden ist und LDP-Tunneling ebenfalls aktiviert ist, verwendet der Router von Juniper Networks standardmäßig den RSVP-Tunnel möglicherweise nicht, um den Datenverkehr zu den LDP-Zielen zu leiten, die nach dem Ausgangsrouter des anderen Anbieters liegen, wenn der RSVP-Pfad eine Kennzahl von 1 größer ist als der physische OSPF-Pfad.

Um sicherzustellen, dass LDP-Tunneling in heterogenen Netzwerken ordnungsgemäß funktioniert, können Sie OSPF so konfigurieren, dass die RSVP-LSP-Metrik ignoriert wird, indem Sie die ignore-lsp-metrics Anweisung angeben:

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]

HINWEIS:

Router der ACX-Serie unterstützen die Hierarchieebene [edit logical-systems] nicht.

Um LDP über RSVP-LSPs zu aktivieren, müssen Sie auch weiterhin die Prozedur in Abschnitt Ermöglichen von LDP über RSVP-etablierte LSPsabschließen.

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 spoofierten TCP-Segmenten in LDP-Sitzungsverbindungsstreams zu schützen. Weitere Informationen zur TCP-Authentifizierung finden Sie unter TCP. Informationen zur Verwendung der TCP-Authentifizierungsoption (TCP-AO) anstelle von TCP MD5 finden Sie unter No link title.

Ein Router, der die MD5-Signaturoption verwendet, wird mit einem Kennwort für jeden Peer konfiguriert, für den eine Authentifizierung erforderlich ist. Das Passwort wird verschlüsselt gespeichert.

LDP hallo Adjacencies können auch dann erstellt werden, wenn Peering-Schnittstellen mit unterschiedlichen Sicherheitssignaturen konfiguriert sind. Die TCP-Sitzung kann jedoch nicht authentifiziert werden und wird nie eingerichtet.

Sie können Hashed Message Authentication Code (HMAC) und MD5-Authentifizierung für LDP-Sitzungen als eine Konfiguration pro Sitzung oder als Subnetz-Übereinstimmung (d. h. längste Prefix-Übereinstimmung) konfigurieren. Die Unterstützung für Subnetz-Match-Authentifizierung bietet Flexibilität bei der Konfiguration der Authentifizierung für automatisch zielgerichtete LDP-Sitzungen (TLDP). Dies vereinfacht die Bereitstellung von Remote Loop-Free Alternate (LFA) und FEC 129 Pseudowires.

Um eine MD5-Signatur für eine LDP-TCP-Verbindung zu konfigurieren, fügen Sie die authentication-key Anweisung als Teil der Sitzungsgruppe ein:

Verwenden Sie die session-group Anweisung, um die Adresse für das Remote-Ende der LDP-Sitzung zu konfigurieren.

Das md5-authentication-keyKennwort in der Konfiguration kann bis zu 69 Zeichen lang sein. Zeichen können beliebige ASCII-Zeichenfolgen enthalten. Wenn Sie Leerzeichen einschließen, schließen Sie alle Zeichen in Anführungszeichen ein.

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 Signalisierungsprotokolle wie Open Shortest Path First (OSPF) und Resource Reservation Setup Protocol (RSVP) zu unterbrechen.

Um den Authentifizierungsschlüssel-Aktualisierungsmechanismus zu konfigurieren, fügen Sie die key-chain Anweisung auf [edit security authentication-key-chains] Hierarchieebene ein und geben Sie die key Option zum Erstellen eines Schlüsselbundes aus mehreren Authentifizierungsschlüsseln an.

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 suthentication-key-chains] Authentifizierungsschlüsseln zu verknüpfen. Sie müssen auch den Authentifizierungsalgorithmus konfigurieren, indem Sie die authentication-algorithm algorithm Anweisung die [edit protocols ldp] Hierarchieebene angeben.

Weitere Informationen zur Aktualisierungsfunktion für Authentifizierungsschlüssel finden Sie unter Konfigurieren des Authentifizierungsschlüssel-Updatemechanismus für BGP- und LDP-Routingprotokolle.

Konfiguration des LDP-Sitzungsschutzes

Normalerweise wird eine LDP-Sitzung zwischen einem Routerpaar erstellt, das über einen oder mehrere Verbindungen verbunden ist. Die Router bilden für jeden Link, der sie verbindet, ein hallo Adjacenency und assoziieren alle Adjacencies mit der entsprechenden LDP-Sitzung. Wenn die letzte Hallo-Bindung für eine LDP-Sitzung wegfällt, wird die LDP-Sitzung beendet. Sie können dieses Verhalten ändern, um zu verhindern, dass eine LDP-Sitzung unnötig beendet und wieder aufgebaut wird.

Sie können das Junos OS so konfigurieren, dass die LDP-Sitzung zwischen zwei Routern eingeschaltet wird, auch wenn es keine guten Verbindungen auf den Verbindungen gibt, die die beiden Router verbinden, indem Sie die session-protection Anweisung konfigurieren. Sie können optional eine Zeit in Sekunden mit der timeout Option angeben. Die Sitzung bleibt für die angegebene Dauer aktiviert, solange die Router die IP-Netzwerkkonnektivität aufrechterhalten.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Zusammenfassung der Anweisung.

Deaktivieren von SNMP-Traps für LDP

Immer wenn ein LDP-LSP einen Übergang von oben nach unten oder von unten 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 Routing-Instanz zu deaktivieren.

Informationen zu den 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 einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Konfigurieren der LDP-Synchronisierung mit der IGP auf LDP-Links

LDP ist ein Protokoll zur Verteilung von Labeln in Anwendungen ohne Datenverkehrs-Engineering. Die Label werden auf dem besten Pfad verteilt, der von der IGP festgelegt wird. Wenn die Synchronisierung zwischen LDP und IGP nicht aufrechterhalten wird, fällt der LSP aus. Wenn LDP auf einem bestimmten Link nicht vollständig in Betrieb ist (eine Sitzung ist nicht eingerichtet und Label werden nicht ausgetauscht), gibt die IGP den Link mit der maximalen Kostenkennzahl an. Die Verbindung wird nicht bevorzugt, bleibt aber in der Netzwerktopologie.

Die LDP-Synchronisierung wird nur auf aktiven Punkt-zu-Punkt-Schnittstellen und LAN-Schnittstellen unterstützt, die unter der IGP als Punkt-zu-Punkt konfiguriert sind. Die LDP-Synchronisierung wird während eines graceful Restarts nicht unterstützt.

Um die maximale Kostenkennzahl ankündigen zu können, bis LDP für die Synchronisierung betriebsbereit ist, fügen Sie die Anweisung ein ldp-synchronization :

Um die Synchronisierung zu deaktivieren, fügen Sie die Anweisung ein disable . Fügen Sie die Anweisung bei, um den Zeitraum für die Anpreisung der maximalen Kostenkennzahl für eine Verbindung zu konfigurieren, die hold-time nicht vollständig in Betrieb ist.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt zur Anweisungszusammenfassung für diese Anweisung.

Konfigurieren der LDP-Synchronisierung mit der IGP auf dem Router

Sie können die Zeit konfigurieren, zu der die LDP wartet, bevor sie die IGP darüber informiert, dass der LDP-Nachbar und die Sitzung für eine Schnittstelle in Betrieb sind. Bei großen Netzwerken mit zahlreichen FECs müssen Sie möglicherweise einen längeren Wert konfigurieren, um genügend Zeit für den Austausch der LDP-Label-Datenbanken zu haben.

Um die Zeit zu konfigurieren, die LDP wartet, bevor sie die IGP darüber informiert, dass der LDP-Nachbarn und die LDP-Sitzung in Betrieb sind, fügen Sie die igp-synchronization Anweisung bei und geben Sie für die holddown-interval Option eine Uhrzeit in Sekunden an:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt zur Anweisungszusammenfassung für diese Anweisung.

Konfigurieren des Timers für die Label-Entzugserkennung

Der Timer für die Labelentnahme verzögert das Versenden einer Nachricht zur Label-Auszahlung für eine FEC an einen Nachbarn. Wenn eine IGP-Verbindung zu einem Nachbarn fehlschlägt, muss das mit dem FEC verknüpfte Label von allen Upstream-Routern zurückgezogen werden, wenn der Neighbor der nächste Hop für den FEC ist. Nachdem der IGP-Router konvergiert und ein Label von einem neuen nächsten Hop empfangen wird, wird das Label auf alle Upstream-Router umvertiert. Das ist das typische Netzwerkverhalten. Durch die Verzögerung der Labelentnahme um einen kleinen Zeitraum (z. B. bis der IGP zusammenläuft und der Router ein neues Label für den FEC vom downstream-nächsten Hop erhält), könnte die Entzugung des Etiketts und das Senden einer Labelzuordnung bald vermieden werden. Mit label-withdrawal-delay der Anweisung können Sie diese Verzögerungszeit konfigurieren. Standardmäßig beträgt die Verzögerung 60 Sekunden.

Wenn der Router das neue Label empfängt, bevor der Timer ausläuft, wird der Timer für die Labelentnahme abgebrochen. Wenn der Timer jedoch ausläuft, wird das Label für den FEC von allen Upstream-Routern zurückgezogen.

Standardmäßig wartet LDP 60 Sekunden, bevor die Label zurückgenommen werden, um zu vermeiden, dass LSPs mehrmals erneut signalisiert werden, während die IGP neu konfiguriert wird. Um die Verzögerungszeit des Etiketts in Sekunden zu konfigurieren, fügen Sie die Anweisung ein label-withdrawal-delay :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Abschnitt zur Anweisungszusammenfassung für diese Anweisung.

Ignorieren der LDP-Subnet-Prüfung

In Junos OS Version 8.4 und höher wird während der Einrichtung des Nachbarn eine LDP-Quelladressen-Subnet-Prüfung durchgeführt. Die Quelladresse im LDP-Link hallo Packet wird mit der Schnittstellenadresse abgeglichen. Dies verursacht ein Interoperabilitätsproblem mit geräten einiger anderer Anbieter.

Um die Subnetzprüfung zu deaktivieren, fügen Sie die Anweisung ein allow-subnet-mismatch :

Diese Anweisung kann auf den folgenden Hierarchieebenen eingefügt werden:

  • [edit protocols ldp interface interface-name]

  • [edit logical-systems logical-system-name protocols ldp interface interface-name]

HINWEIS:

Router der ACX-Serie unterstützen keine [edit logical-systems] Hierarchieebene.

Siehe auch

Konfiguration von LDP LSP Traceroute

Sie können die Route verfolgen, gefolgt von einem LDP-signalisierten LSP. LDP LSP Traceroute basiert auf RFC 4379, Erkennen von MPLS-Ausfällen (Multi-Protocol Label Switched). Mit dieser Funktion können Sie in regelmäßigen Abständen alle Pfade in einer FEC verfolgen. Die FEC-Topologieinformationen werden in einer Datenbank gespeichert, auf die über die CLI zugegriffen werden kann.

Eine Topologieänderung löst nicht automatisch eine Trace eines LDP-LSP aus. Sie können jedoch manuell einen Traceroute initiieren. Wenn es sich bei der Traceroute-Anforderung um einen FEC handelt, der sich derzeit in der Datenbank befindet, wird der Inhalt der Datenbank mit den Ergebnissen aktualisiert.

Die regelmäßige Traceroute-Funktion gilt für alle FECs, die durch die oam auf [edit protocols ldp] Hierarchieebene konfigurierte Anweisung angegeben werden. Um regelmäßigen LDP-LSP-Traceroute zu konfigurieren, fügen Sie die Anweisung ein periodic-traceroute :

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 Serviceklasse 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 von Pfaden an, die gesucht werden sollen.

  • retries— Geben Sie die Anzahl der Versuche an, eine Probe vor dem Aufgeben an einen bestimmten Knoten zu senden.

  • source– Geben Sie die IPv4-Quelladresse an, die beim Senden von Sondierungen verwendet werden soll.

  • ttl— Geben Sie den maximalen Time-to-Live-Wert an. Knoten, die über diesen Wert hinausgehen, werden nicht zurückverfolgt.

  • wait– Geben Sie das Wartezeitintervall vor dem erneuten Senden eines Sondierungspakets an.

Sammeln von LDP-Statistiken

LDP-Datenverkehrsstatistiken zeigen das Datenverkehrsvolumen, das eine bestimmte FEC auf einem Router passiert hat.

Wenn Sie die traffic-statistics Anweisung auf Hierarchieebene [edit protocols ldp] konfigurieren, werden die LDP-Datenverkehrsstatistiken in regelmäßigen Abständen erfasst und in eine Datei geschrieben. Mithilfe der interval Option können Sie konfigurieren, wie oft Statistiken (in Sekunden) erfasst werden. Das Standarderfassungsintervall beträgt 5 Minuten. Sie müssen eine LDP-Statistikdatei konfigurieren. andernfalls werden keine LDP-Datenverkehrsstatistiken gesammelt. Wenn der LSP ausfällt, werden die LDP-Statistiken zurückgesetzt.

Um LDP-Datenverkehrsstatistiken zu erfassen, fügen Sie die Anweisung ein traffic-statistics :

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.

Dieser Abschnitt enthält die folgenden Themen:

LDP-Statistikausgabe

Die folgende Beispielausgabe stammt aus einer LDP-Statistikdatei:

Die LDP-Statistikdatei enthält die folgenden Datenspalten:

  • FEC—FEC, für die LDP-Datenverkehrsstatistiken erhoben werden.

  • Type—Art des Datenverkehrs, der von einem Router stammt, entweder Ingress (stammt von diesem Router) oder Transit (über diesen Router weitergeleitet).

  • Packets— Anzahl der Pakete, die vom FEC seit der Einführung des LSP weitergeleitet wurden.

  • Bytes— Anzahl der Byte an Daten, die von der FEC seit der Einführung des LSP übermittelt wurden.

  • Shared— Ein Yes Wert gibt an, dass mehrere Präfixe an dasselbe 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 dem Datum und der Uhrzeit erscheint) kann von der tatsächlichen Anzahl der angezeigten Statistiken abweichen. Einige der Statistiken werden zusammengefasst, bevor sie angezeigt werden.

Deaktivieren von LDP-Statistiken auf dem Vorletzten-Hop-Router

Das Sammeln von LDP-Datenverkehrsstatistiken am 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 no-penultimate-hop Option für die Anweisung zu traffic-statistics konfigurieren:

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

HINWEIS:

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.

Immer wenn Sie diese Option in die Konfiguration einbinden oder aus der Konfiguration entfernen, werden die LDP-Sitzungen heruntergenommen und dann neu gestartet.

Die folgende Beispielausgabe stammt aus einer LDP-Statistikdatei, in der Router angezeigt werden, auf denen die no-penultimate-hop Option konfiguriert ist:

Einschränkungen für LDP-Statistiken

Im Folgenden finden Sie Probleme im Zusammenhang mit dem 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 ausgegeben, wenn der Statistik-Timer später abläuft als das neue Intervall.

  • Ein neuer LDP-Statistikerfassungsvorgang kann erst gestartet werden, wenn der vorherige abgeschlossen ist. Wenn das Intervall kurz ist oder die Anzahl der LDP-Statistiken groß ist, kann der Zeitabstand zwischen den beiden Statistiksammlungen länger sein als das Intervall.

Wenn ein LSP ausfällt, werden die LDP-Statistiken zurückgesetzt.

Verfolgung des LDP-Protokoll-Datenverkehrs

In den folgenden Abschnitten wird beschrieben, wie Sie die Trace-Optionen konfigurieren, um den LDP-Protokolldatenverkehr zu untersuchen:

Verfolgen des LDP-Protokoll-Datenverkehrs auf Protokoll- und Routing-Instanzebene

Um den LDP-Protokolldatenverkehr zurückzuverfolgen, können Sie in der globalen traceoptions Anweisung auf [edit routing-options] Hierarchieebene Optionen angeben und LDP-spezifische Optionen angeben, indem Sie die traceoptions Anweisung angeben:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen 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 in das Verzeichnis /var/log abgelegt. Wir empfehlen, die LDP-Tracing-Ausgabe in der Datei ldp-logzu platzieren.

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 Modifizierer tragen:

  • address—Rückverfolgung des Ablaufs von Adress- und Adressabhebungsnachrichten.

  • binding— Trace-Label-Bindungsvorgänge.

  • error– Fehlerbedingungen nachverfolgen.

  • event– Protokollereignisse verfolgen.

  • initialization– Verfolgen Sie den Betrieb von Initialisierungsmeldungen.

  • label— Verfolgen Sie den Betrieb von Label-Anforderung, Label-Zuordnung, Label-Rücknahme und Meldungen zur Label-Freigabe.

  • notification— Verfolgen Sie den Betrieb von Benachrichtigungen.

  • packets—Verfolgen Sie den Betrieb von Adresse, Adressabhebung, Initialisierung, Label-Anfrage, Labelzuordnung, Label-Rücknahme, Label-Freigabe, Benachrichtigung und regelmäßigen Meldungen. Dieser Modifizierer entspricht dem Festlegen der address, , initialization, label, , notificationund periodic Modifizierer.

    Sie können den filter Flag-Modifizierer auch mit der match-on address Unteroption für die packets Flagge konfigurieren. Auf diese Weise können Sie basierend auf den Quell- und Zieladressen der Pakete zurückverfolgen.

  • path– Trace-Switched Path-Vorgänge.

  • path– Trace-Switched Path-Vorgänge.

  • periodic— Verfolgen Sie den Betrieb von Hallo- und Keepalive-Nachrichten.

  • route– Verfolgen Sie den Betrieb von Routennachrichten.

  • state– Protokollstatusübergänge nachverfolgen

Verfolgung des LDP-Protokoll-Datenverkehrs innerhalb von FECs

LDP ordnet jedem erstellten LSP eine Forwarding Equivalence Class (FEC) zu. Der FEC, der einem LSP zugeordnet ist, gibt an, welche Pakete diesem LSP zugeordnet sind. LSPs werden durch ein Netzwerk erweitert, da jeder Router das label wählt, das vom nächsten Hop für den FEC angekündigt wird, und es mit dem Label zusammengepleißet wird, das er allen anderen Routern angekündigt hat.

Sie können den LDP-Protokolldatenverkehr innerhalb einer bestimmten FEC zurückverfolgen und LDP-Trace-Anweisungen basierend auf einem FEC filtern. Dies ist nützlich, wenn Sie den LDP-Protokolldatenverkehr im Zusammenhang mit einem FEC verfolgen oder beheben möchten. Hierfür stehen folgende Trace Flags zur Verfügung: route, pathund binding.

Im folgenden Beispiel wird veranschaulicht, wie Sie die LDP-Anweisung traceoptions konfigurieren können, um LDP-Trace-Anweisungen basierend auf einem FEC zu filtern:

Diese Funktion hat die folgenden Einschränkungen:

  • Die Filterfunktion ist nur für FECs verfügbar, die aus IP-Version 4 (IPv4)-Präfixen 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 vom Filter blockiert).

  • Die Filterung wird durch die Richtlinie und den konfigurierten Wert für die match-on Option bestimmt. Stellen Sie beim Konfigurieren der Richtlinie sicher, dass das Standardverhalten immer rejectlautet.

  • Die einzige match-on Option ist fec. Folglich ist die einzige Art von Richtlinie, die Sie einschließen sollten, eine Route-Filter-Richtlinie.

Beispiele: Verfolgung des LDP-Protokoll-Datenverkehrs

Verfolgen Sie LDP-Pfadmeldungen im Detail:

Verfolgen Sie alle ausgehenden LDP-Nachrichten:

Verfolgen Sie alle LDP-Fehlerbedingungen:

Verfolgen Sie alle eingehenden LDP-Nachrichten und alle Vorgänge zur Labelbindung:

Verfolgen Sie den LDP-Protokolldatenverkehr für einen FEC, der dem LSP zugeordnet ist:

Release-Verlaufstabelle
Release
Beschreibung
22.4R1
Ab Junos OS Evolved Version 22.4R1 können Sie die TCP-AO- oder TCP MD5-Authentifizierung mit einem IP-Subnetz konfigurieren, um den gesamten Adressbereich unter diesem Subnetz einzubeziehen.
22.4R1
Ab Junos OS Evolved Version 22.4R1 ist die TCP-Authentifizierung VRF-fähig.
19.1
Ab Junos OS Version 19.1R1 kann der Segment-Routing-LDP-Border-Router Segment-Routing-Datenverkehr mit LDP next-Hop und umgekehrt zusammenfügen.
16.1
Ab Junos OS Version 16.1 kann M-LDP Point-to-Multipoint-LSPs an ASBR oder transit oder ausgehend signalisieren, wenn es sich bei der Root-Adresse um eine BGP-Route handelt, die über einen MPLS-LSP weiter rekursiv aufgelöst wird.
14.1
Ab Junos OS Version 14.1 müssen Sie einen reibungslosen Übergang von PIM zu M-LDP-Point-to-Multipoint-LSPs mit minimalem Ausfall durchführen, um vorhandene IPTV-Services von nativem IP-Multicast auf MPLS-Multicast zu migrieren.