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

LDP-Mindestkonfiguration

So aktivieren Sie LDP mit minimaler Konfiguration:

  1. Aktivieren Sie alle relevanten Schnittstellen unter der MPLS-Familie. Im Falle von gerichtetem LDP muss die Loopback-Schnittstelle mit Familien-MPLS aktiviert werden.

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

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

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

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

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

Aktivieren und Deaktivieren von LDP

LDP ist Routing-instanzfähig. Um LDP auf einer bestimmten Schnittstelle zu aktivieren, fügen Sie die folgenden Anweisungen hinzu:

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

Wenn Sie Schnittstelleneigenschaften für eine Gruppe von Schnittstellen konfiguriert haben und LDP für eine der Schnittstellen deaktivieren möchten, fügen Sie die interface Anweisung mit der disable Option ein:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einbinden können, finden Sie im Abschnitt Anweisungszusammenfassung.

Konfigurieren des LDP-Timers für Hallo-Nachrichten

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

Es gibt zwei Arten von LDP-Hello-Nachrichten:

  • Link Hello-Nachrichten - Werden über die LDP-Schnittstelle als UDP-Pakete gesendet, die an den LDP-Erkennungsport adressiert sind. Der Empfang einer LDP-Link-Hello-Nachricht auf einer Schnittstelle identifiziert eine Nachbarschaft mit dem LDP-Peer-Router.

  • Gezielte Hallo-Nachrichten: Werden als UDP-Pakete gesendet, die an den LDP-Erkennungsport 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 Zielrouter bestimmt, ob eine gezielte Hallo-Nachricht beantwortet oder ignoriert werden soll. Ein Zielrouter, der sich für eine Antwort entscheidet, sendet dazu regelmäßig gezielte Hallo-Nachrichten an den initiierenden Router zurück.

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

Konfigurieren des LDP-Timers für Link-Hello-Nachrichten

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

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung 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 Intervall für gezielte Hallo-Nachrichten 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 als inaktiv betrachtet werden

Die Haltezeit bestimmt, wie lange ein LDP-Knoten auf eine Hallo-Nachricht warten soll, bevor er einen Nachbarn für ausgefallen erklärt. Dieser Wert wird als Teil einer Hello-Nachricht gesendet, sodass jeder LDP-Knoten seinen Nachbarn mitteilt, wie lange sie warten sollen. Die von den einzelnen Nachbarn gesendeten Werte müssen nicht übereinstimmen.

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

HINWEIS:

Durch die Konfiguration einer LDP-Haltezeit in der Nähe des Hello-Intervalls (weniger als das Dreifache des Hello-Intervalls) können LDP-Nachbarfehler schneller erkannt werden. Dies erhöht jedoch auch die Wahrscheinlichkeit, dass der Router einen LDP-Nachbarn für heruntergefahren erklärt, der noch normal funktioniert. Weitere Informationen finden Sie unter Konfigurieren des LDP-Timers für Hello-Nachrichten.

Die LDP-Haltezeit wird ebenfalls automatisch zwischen LDP-Peers ausgehandelt. Wenn sich zwei LDP-Peers gegenseitig 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 Peeraushandlung reduziert 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 z. B. 45 Sekunden beträgt, wird das Keepalive-Intervall auf 15 Sekunden festgelegt.

Diese automatische Berechnung des Keepalive-Intervalls 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 nach dem Zurücksetzen der Sitzung wirksam. Die Haltezeit wird ausgehandelt, wenn die LDP-Peering-Sitzung initiiert wird, und kann nicht neu ausgehandelt werden, solange die Sitzung aktiv ist (erforderlich gemäß RFC 5036, LDP-Spezifikation). Um das Zurücksetzen der LDP-Sitzung manuell zu erzwingen, geben Sie den clear ldp session Befehl ein.

Konfigurieren der LDP-Haltezeit für Link-Hello-Nachrichten

Um zu ändern, wie lange ein LDP-Knoten auf eine Link Hello-Nachricht warten soll, bevor der Nachbar als inaktiv deklariert wird, geben Sie mit der hold-time folgenden Anweisung eine neue Zeit in Sekunden an:

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

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

Um zu ändern, wie lange ein LDP-Knoten auf eine gezielte Hello-Nachricht warten soll, bevor der Nachbar deklariert wird, geben Sie eine neue Zeit in Sekunden an, indem Sie die hold-time Anweisung als Option für die targeted-hello Anweisung verwenden:

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

Aktivieren von streng gezielten Begrüssungsnachrichten für LDP

Verwenden Sie streng gezielte Hello-Nachrichten, um zu verhindern, dass LDP-Sitzungen mit Remotenachbarn eingerichtet werden, die nicht speziell konfiguriert wurden. Wenn Sie die strict-targeted-hellos Anweisung konfigurieren, antwortet ein LDP-Peer nicht auf gezielte Hello-Nachrichten, die von einer Quelle stammen, die nicht zu den konfigurierten Remotenachbarn gehört. Zu den konfigurierten Remote-Nachbarn gehören unter anderem:

  • Endpunkte von RSVP-Tunneln, für die LDP-Tunneling konfiguriert ist

  • Layer 2-Verbindungsnachbarn

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

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

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung 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 das Keepalive-Timeout nicht überschritten wird. Wenn in dieser Zeit kein anderer LDP-Datenverkehr über die Sitzung gesendet wird, wird eine Keepalive-Nachricht gesendet. Der Standardwert ist 10 Sekunden. Der Mindestwert beträgt 1 Sekunde.

Der für das Keepalive-Intervall konfigurierte Wert kann während der LDP-Sitzungsaushandlung 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 als inaktiv betrachtet werden.

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

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung 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 weiterhin funktioniert. Das Keepalive-Timeout definiert die Zeitspanne, die der benachbarte LDP-Knoten wartet, bevor er entscheidet, dass die Sitzung fehlgeschlagen ist. Dieser Wert wird in der Regel auf mindestens das Dreifache des Keepalive-Intervalls festgelegt. Der Standardwert ist 30 Sekunden.

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

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

Der für die keepalive-timeout Anweisung konfigurierte Wert wird als Haltezeit angezeigt, wenn Sie den show ldp session detail Befehl ausgeben.

Konfigurieren der längsten Übereinstimmung für LDP

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

Bevor Sie die längste Übereinstimmung für LDP konfigurieren, müssen Sie die folgenden Schritte ausführen:

  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.

    So konfigurieren Sie z. B. die Schnittstellen:

Beispiel: Konfigurieren der längsten Übereinstimmung für LDP

In diesem Beispiel wird gezeigt, wie die längste Übereinstimmung für LDP basierend auf RFC5283konfiguriert wird. Dies ermöglicht es LDP, die Routen aggregiert oder zusammengefasst über OSPF-Bereiche oder ISIS-Ebenen in Inter-Domain zu lernen. Die längste Übereinstimmungsrichtlinie bietet Granularität pro Präfix.

Anforderungen

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

  • Sechs Router der MX-Serie mit OSPF-Protokoll und LDP-aktiviert auf den angeschlossenen Schnittstellen.

  • Junos OS, Version 16.1 oder höher, läuft auf allen Geräten.

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 mithilfe eines IGP wie OSPF oder IS-IS einzurichten. In einem solchen Netzwerk haben alle Links in der Domäne sowohl IGP-Nachbarschaften als auch LDP-Nachbarschaften. LDP richtet die Sprachdienstleister auf dem kürzesten Weg zu einem Ziel ein, das durch die IP-Weiterleitung bestimmt wird. In Junos OS führt die LDP-Implementierung eine Suche nach exakten Übereinstimmungen der IP-Adresse des FEC in den RIB- oder IGP-Routen für die Label-Zuordnung durch. Für diese exakte Zuordnung müssen in allen LERs MPLS-End-to-End-LDP-Endpunkt-IP-Adressen konfiguriert werden. Dies vereitelt den Zweck des hierarchischen IP-Designs oder des Standard-Routings in Zugriffsgeräten. Die Konfiguration longest-match hilft, dieses Problem zu überwinden, indem das exakte Übereinstimmungsverhalten unterdrückt und LSP basierend auf der längsten übereinstimmenden Route pro Präfix eingerichtet wird.

Topologie

Zeigt in der Topologie an, Abbildung 1dass die längste Übereinstimmung für LDP auf Gerät R0 konfiguriert ist.

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

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem [edit] Konfigurationsmodus ein commit .

R0

R1

R2

R3

R4

R5

Konfigurieren des Geräts R0

Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere 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 im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfacesBefehle , show protocolsund show routing-options eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

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

Verifizierung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Verifizieren der Routen

Zweck

Stellen Sie sicher, dass die erwarteten Routen gelernt wurden.

Action!

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 des Geräts R0 an.

Überprüfen der LDP-Übersichtsinformationen

Zweck

LDP-Übersichtsinformationen anzeigen.

Action!

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

Bedeutung

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

Überprüfen Sie die LDP-Einträge in der internen Topologietabelle

Zweck

Zeigen Sie die Routeneinträge in der internen Topologietabelle des Label Distribution Protocol (LDP) an.

Action!

Führen Sie auf Gerät R0 im Betriebsmodus den show ldp route Befehl aus, um die interne Topologietabelle von LDP anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Routeneinträge in der internen Topologietabelle des Label Distribution Protocol (LDP) von Gerät R0 an.

Überprüfen Sie nur die FEC-Informationen der LDP-Route

Zweck

Zeigt nur die FEC-Informationen der LDP-Route an.

Action!

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

In der Ausgabe werden nur die FEC-Routen des LDP-Protokolls angezeigt, die für Gerät R0 verfügbar sind.

FEC- und Schattenrouten von LDP verifizieren

Zweck

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

Action!

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

Bedeutung

Die Ausgabe zeigt die FEC und die Schattenrouten von Gerät R0 an

LDP-Routeneinstellungen konfigurieren

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

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

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

LDP Graceful-Restart

Der LDP-Graceful-Restart ermöglicht es einem Router, dessen LDP-Steuerungsebene neu gestartet wird, weiterhin den Datenverkehr weiterzuleiten und gleichzeitig seinen Status von benachbarten Routern wiederherzustellen. Außerdem wird ein Router, auf dem der Hilfsmodus aktiviert ist, aktiviert, um einen benachbarten Router zu unterstützen, der versucht, LDP neu zu starten.

Während der Sitzungsinitialisierung kündigt ein Router seine Fähigkeit an, einen ordnungsgemäßen LDP-Neustart durchzuführen oder einen Nachbarn zu nutzen, der einen ordnungsgemäßen LDP-Neustart durchführt, indem er die TLV für den ordnungsgemäßen Neustart sendet. Diese TLV enthält zwei Felder, die für den LDP-Graceful-Neustart relevant sind: die Zeit für die Wiederherstellung der Verbindung und die Wiederherstellungszeit. Die Werte der Wiederverbindungs- und Wiederherstellungszeiten geben die vom Router unterstützten Funktionen für einen ordnungsgemäßen Neustart an.

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

Sie können den ordnungsgemäßen LDP-Neustart sowohl in der Master-Instance für das LDP-Protokoll als auch für eine bestimmte Routing-Instanz konfigurieren. Sie können den ordnungsgemäßen Neustart auf globaler Ebene für alle Protokolle, nur auf Protokollebene für LDP und für eine bestimmte Routing-Instanz deaktivieren. Der ordnungsgemäße LDP-Neustart ist standardmäßig deaktiviert, da auf globaler Ebene der ordnungsgemäße Neustart standardmäßig deaktiviert ist. Der Hilfsmodus (die Fähigkeit, einen benachbarten Router beim Versuch eines ordnungsgemäßen Neustarts zu unterstützen) ist jedoch standardmäßig aktiviert.

Im Folgenden sind einige der Verhaltensweisen aufgeführt, die mit dem ordnungsgemäßen LDP-Neustart verbunden sind:

  • Ausgehende Bezeichnungen werden bei Neustarts nicht beibehalten. Neue ausgehende Etiketten werden zugewiesen.

  • Wenn ein Router neu gestartet wird, werden keine Beschriftungszuordnungsnachrichten an Nachbarn gesendet, die einen ordnungsgemäßen Neustart unterstützen, bis sich der neu startende Router stabilisiert hat (Beschriftungszuordnungsnachrichten werden sofort an Nachbarn gesendet, die keinen ordnungsgemäßen Neustart unterstützen). Alle anderen Nachrichten (keepalive, address-message, notification und release) werden jedoch wie gewohnt gesendet. Durch das Verteilen dieser anderen Nachrichten wird verhindert, dass der Router unvollständige Informationen verteilt.

  • Der Hilfsmodus und der ordnungsgemäße Neustart sind unabhängig. Sie können den ordnungsgemäßen Neustart in der Konfiguration deaktivieren, dem Router aber dennoch erlauben, mit einem Nachbarn zusammenzuarbeiten, der versucht, ordnungsgemäß neu zu starten.

Konfigurieren des LDP-Graceful-Neustarts

Wenn Sie die Konfiguration für den ordnungsgemäßen Neustart auf der [edit routing-options graceful-restart] oder [edit protocols ldp graceful-restart] der Hierarchieebene ändern, wird jede laufende LDP-Sitzung automatisch neu gestartet, um die Konfiguration für den ordnungsgemäßen Neustart anzuwenden. Dieses Verhalten spiegelt das Verhalten von BGP wider, wenn Sie die Konfiguration für einen ordnungsgemäßen Neustart ändern.

Standardmäßig ist der Hilfsmodus für einen ordnungsgemäßen Neustart aktiviert, der ordnungsgemäße Neustart ist jedoch deaktiviert. Daher besteht das Standardverhalten eines Routers darin, benachbarte Router bei dem Versuch eines ordnungsgemäßen Neustarts zu unterstützen, aber nicht, selbst einen ordnungsgemäßen Neustart zu versuchen.

Informationen zum Konfigurieren des ordnungsgemäßen LDP-Neustarts finden Sie in den folgenden Abschnitten:

Aktivieren des ordnungsgemäßen Neustarts

Um den ordnungsgemäßen LDP-Neustart zu aktivieren, müssen Sie auch den ordnungsgemäßen Neustart auf dem Router aktivieren. Um einen ordnungsgemäßen Neustart zu ermöglichen, fügen Sie die graceful-restart folgende Anweisung ein:

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

  • [edit routing-options]

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

HINWEIS:

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

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

Standardmäßig ist der ordnungsgemäße LDP-Neustart aktiviert, wenn Sie den ordnungsgemäßen Neustart sowohl auf der LDP-Protokollebene als auch auf allen Routing-Instanzen aktivieren. Sie können jedoch sowohl den LDP-Graceful-Restart als auch den LDP-Helfermodus für Graceful-Restart deaktivieren.

Deaktivieren des LDP-Graceful-Neustarts oder des Hilfsmodus

Um den ordnungsgemäßen LDP-Neustart und die Wiederherstellung zu deaktivieren, fügen Sie die disable folgende Anweisung ein:

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

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

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

Die folgenden LDP-Konfigurationen für einen ordnungsgemäßen Neustart sind möglich:

  • LDP Graceful Restart und Hilfsmodus sind beide aktiviert.

  • Der ordnungsgemäße LDP-Neustart ist deaktiviert, aber der Hilfsmodus ist aktiviert. Ein auf diese Weise konfigurierter Router kann nicht ordnungsgemäß neu gestartet werden, kann aber einem Nachbarn beim Neustart helfen.

  • Der LDP-Graceful-Restart und der Hilfsmodus sind beide deaktiviert. Der Router verwendet weder den ordnungsgemäßen LDP-Neustart noch den in der Initialisierungsnachricht gesendeten Typ, Länge und Wert (TLV) des ordnungsgemäßen Neustarts. Der Router verhält sich wie ein Router, der den ordnungsgemäßen LDP-Neustart nicht unterstützen kann.

Ein Konfigurationsfehler wird ausgegeben, wenn Sie versuchen, den ordnungsgemäßen Neustart zu aktivieren und den Hilfsmodus zu deaktivieren.

Konfigurieren der Wiederverbindungszeit

Nachdem die LDP-Verbindung zwischen Nachbarn fehlgeschlagen ist, warten die Nachbarn eine bestimmte Zeit, bis der ordnungsgemäß neu gestartete Router das Senden von LDP-Nachrichten wieder aufnimmt. Nach Ablauf der Wartezeit kann die LDP-Sitzung wiederhergestellt werden. Sie können die Wartezeit in Sekunden konfigurieren. Dieser Wert ist in der fehlertoleranten Sitzungs-TLV enthalten, die in LDP-Initialisierungsnachrichten gesendet wird, wenn der ordnungsgemäße LDP-Neustart aktiviert ist.

Angenommen, Router A und Router B sind LDP-Nachbarn. Router A ist der neu startende Router. Die Wiederverbindungszeit ist die Zeit, die Router A Router B anweist, zu warten, nachdem Router B erkannt hat, dass Router A neu gestartet wurde.

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

Sie können die Zeit für die Wiederherstellung der Verbindung auf einen Wert im Bereich von 30 bis 300 Sekunden einstellen. Standardmäßig sind es 60 Sekunden.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen konfigurieren können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.

Konfigurieren der Wiederherstellungszeit und der maximalen Wiederherstellungszeit

Die Wiederherstellungszeit ist die Zeitspanne, die ein Router darauf wartet, dass LDP ordnungsgemäß neu gestartet wird. Der Wiederherstellungszeitraum beginnt, wenn eine Initialisierungsnachricht gesendet oder empfangen wird. Dieser Zeitraum ist in der Regel auch die Zeitspanne, in der ein benachbarter Router seine Informationen über den neu startenden Router beibehält, 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 neu startenden Router erhält, können Sie die maximale Wiederherstellungszeit auf dem benachbarten Router konfigurieren. Ein benachbarter Router behält seinen Status für das kürzere der beiden Male bei. Beispiel: Router A führt einen ordnungsgemäßen LDP-Neustart durch. Er hat eine Wiederherstellungszeit von 900 Sekunden an den benachbarten Router B gesendet. Die maximale Wiederherstellungszeit von Router B ist jedoch auf 400 Sekunden festgelegt. Router B wartet nur 400 Sekunden, bevor er seine LDP-Informationen von Router A löscht.

Um die Wiederherstellungszeit zu konfigurieren, schließen Sie die recovery-time Anweisung und die maximum-neighbor-recovery-time Anweisung ein:

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen konfigurieren können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.

Filtern eingehender LDP-Label-Bindungen

Sie können empfangene LDP-Label-Bindungen filtern und Richtlinien anwenden, um Bindungen zu akzeptieren oder abzulehnen, die von benachbarten Routern angekündigt wurden. Um die Filterung nach empfangenen Etiketten zu konfigurieren, fügen Sie die import folgende Anweisung ein:

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

Die benannte Richtlinie (auf Hierarchieebene [edit policy-options] konfiguriert) wird auf alle Bezeichnungsbindungen angewendet, die von allen LDP-Nachbarn empfangen werden. Die gesamte Filterung erfolgt mit from Anweisungen. Tabelle 1 listet die einzigen from Operatoren auf, die für die LDP-Filterung mit empfangenen Bezeichnungen gelten.

Tabelle 1: von Operatoren, die für die LDP-Filterung mit empfangenen Bezeichnungen gelten

from Operator

Beschreibung

interface

Übereinstimmungen mit Bindungen, die von einem Nachbarn empfangen wurden, der über die angegebene Schnittstelle benachbart ist

neighbor

Übereinstimmungen mit Bindungen, die von der angegebenen LDP-Router-ID empfangen wurden

next-hop

Übereinstimmungen mit Bindungen, die von einem Nachbarn empfangen wurden, der die angegebene Schnittstellenadresse ankündigt

route-filter

Stimmt mit Bindungen mit dem angegebenen Präfix überein

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

Im Allgemeinen kann das Anwenden 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 das Unicast-Routing und nicht durch LDP bestimmt wird. Wenn es jedoch mehrere Pfade mit gleichen Kosten zum Ziel über verschiedene Nachbarn gibt, können Sie die LDP-Filterung verwenden, um einige der möglichen nächsten Hops von der Berücksichtigung auszuschließen. (Andernfalls wählt LDP nach dem Zufallsprinzip einen der möglichen nächsten Hops aus.)

LDP-Sitzungen sind nicht an Schnittstellen oder Schnittstellenadressen gebunden. LDP wirbt nur für Labels pro Router (nicht pro Schnittstelle). Wenn also mehrere parallele Verbindungen zwischen zwei Routern vorhanden sind, wird nur eine LDP-Sitzung aufgebaut, die nicht an eine einzelne Schnittstelle gebunden ist. Wenn ein Router mehrere Nachbarschaften zum selben Nachbarn hat, stellen Sie sicher, dass der Filter die erwartete Leistung erbringt. (Im Allgemeinen ist die Verwendung von next-hop und interface in diesem Fall nicht angemessen.)

Wenn eine Bezeichnung gefiltert wurde (d. h., sie wurde von der Richtlinie abgelehnt und wird nicht zum Erstellen eines LSP verwendet), wird sie in der Datenbank als gefiltert markiert:

Weitere Informationen zum Konfigurieren von Richtlinien für LDP finden Sie im Benutzerhandbuch für Routingrichtlinien, Firewallfilter und Traffic Policers.

Beispiele: Filtern eingehender LDP-Label-Bindungen

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

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

Filtern ausgehender LDP-Labelbindungen

Sie können Exportrichtlinien konfigurieren, um ausgehende LDP-Etiketten zu filtern. Sie können ausgehende Label-Bindungen filtern, indem Sie Routing-Richtlinien anwenden, um zu verhindern, dass Bindungen an benachbarte Router angekündigt werden. Um die Filterung ausgehender Etiketten zu konfigurieren, fügen Sie die export folgende Anweisung ein:

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

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

Tabelle 2: an Operatoren für LDP-Filterung mit ausgehenden Etiketten

zum Bediener

Beschreibung

interface

Übereinstimmungen mit Bindungen, die an einen Nachbarn gesendet werden, der über die angegebene Schnittstelle benachbart ist

neighbor

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

next-hop

Übereinstimmungen mit Bindungen, die an einen Nachbarn gesendet werden, der die angegebene Schnittstellenadresse ankündigt

Wenn eine Bindung gefiltert wird, wird die Bindung nicht dem 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 Sprachdienstleistern 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 wirbt nur für Bezeichnungen pro Router (nicht pro Schnittstelle). Wenn mehrere parallele Verbindungen zwischen zwei Routern vorhanden sind, wird nur eine LDP-Sitzung aufgebaut, die nicht an eine einzelne Schnittstelle gebunden ist.

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

Gefilterte Labels werden in der Datenbank markiert:

Weitere Informationen zum Konfigurieren von Richtlinien für LDP finden Sie im Benutzerhandbuch für Routingrichtlinien, Firewallfilter und Traffic Policers.

Beispiele: Filtern ausgehender LDP-Labelbindungen

Blockieren Sie die Übertragung der Route an 10.10.255.6/32 beliebige Nachbarn:

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

Angeben der von LDP verwendeten Transportadresse

Router müssen zuerst eine TCP-Sitzung untereinander aufbauen, bevor sie eine LDP-Sitzung einrichten können. Die TCP-Sitzung ermöglicht es den Routern, die für die LDP-Sitzung benötigten Label-Ankündigungen auszutauschen. Um die TCP-Sitzung aufzubauen, muss jeder Router die Transportadresse des anderen Routers lernen. 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 Anweisungszusammenfassung für diese Anweisung.

Wenn Sie die router-id Option angeben, wird die Adresse der Router-ID als Transportadresse verwendet (sofern nicht anders konfiguriert, ist die Router-ID in der Regel identisch mit der Loopback-Adresse). Wenn Sie die interface Option angeben, wird die Schnittstellenadresse als Transportadresse 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 den ordnungsgemäßen Betrieb muss die LDP-Transportadresse erreichbar sein. Bei der Router-ID handelt es sich um eine Kennung, nicht um eine routingfähige IP-Adresse. Aus diesem Grund wird empfohlen, die Router-ID so einzustellen, 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 zum selben LDP-Nachbarn vorhanden sind, da die LDP-Spezifikation erfordert, dass dieselbe Transportadresse auf allen Schnittstellen desselben Nachbarn angekündigt wird. Wenn LDP mehrere parallele Links zum selben Nachbarn erkennt, werden Schnittstellen zu diesem Nachbarn nacheinander deaktiviert, bis die Bedingung gelöscht wird, entweder durch Trennen des Nachbarn auf einer Schnittstelle oder durch Angeben der router-id Option.

Steuern der Transportadresse, die für die Ziel-LDP-Sitzung verwendet wird

Um eine TCP-Sitzung zwischen zwei Geräten aufzubauen, muss jedes Gerät die Transportadresse des anderen Geräts lernen. Die Transportadresse ist eine IP-Adresse, die zur Identifizierung der TCP-Sitzung verwendet wird, über die die LDP-Sitzung ausgeführt wird. Bisher konnte diese Transportadresse nur die Router-ID oder eine Schnittstellenadresse sein. Mit der LDP-Transportadressenfunktion können Sie jede IP-Adresse explizit als Transportadresse für LDP-Zielnachbarn für Layer-2-Circuit-, MPLS- und VPLS-Nachbarschaften konfigurieren. Auf diese Weise können Sie die Ziel-LDP-Sitzungen mithilfe der Transportadresskonfiguration steuern.

Vorteile der Steuerung der Transportadresse, die für eine Ziel-LDP-Sitzung verwendet wird

Das Konfigurieren der Transportadresse zum Einrichten von Ziel-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 LDP-Zielnachbarn 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 Ziel-LDP-Transportadressen

Vor Junos OS Version 19.1R1 bot LDP nur Unterstützung für die Router-ID oder die Schnittstellenadresse als Transportadresse auf jeder LDP-Schnittstelle. Die Adjacencies, die auf dieser Schnittstelle gebildet wurden, verwendeten eine der IP-Adressen, die der Schnittstelle zugewiesen waren, oder die Router-ID. Im Falle einer gezielten Nachbarschaft ist die Schnittstelle die Loopback-Schnittstelle. Wenn mehrere Loopbackadressen auf dem Gerät konfiguriert waren, 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 LDP-Zielsitzungen verwendet werden, jede andere IP-Adresse als Transportadresse unter den sessionKonfigurationsanweisungen , session-group und interface konfigurieren. Die Transportadresskonfiguration gilt nur für konfigurierte Nachbarn, einschließlich Layer-2-Verbindungen, MPLS- und VPLS-Nachbarschaften. Diese Konfiguration gilt nicht für erkannte Nachbarschaften (zielgerichtet oder nicht).

Bevorzugte Transportadressen

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

Nachdem die Transportadresse konfiguriert wurde, wird die Ziel-LDP-Sitzung basierend auf der Transportadresspräferenz von LDP eingerichtet.

Die Reihenfolge der Präferenz der Transportadresse für den Zielnachbarn (konfiguriert über Layer 2-Verbindung, 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 Reihenfolge der Präferenz der Transportadresse für die ermittelten Nachbarn lautet wie folgt:

  1. Unter [edit protocols ldp interfcae] Hierarchie.

  2. Unter [edit protocols ldp] Hierarchie.

  3. Standardadresse.

Die Reihenfolge der Präferenz der Transportadresse für automatisch adressierte Nachbarn, bei denen LDP so konfiguriert ist, dass Hello-Pakete akzeptiert werden, 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 Probleme bei Ziel-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 aus nicht erreichbar ist, wird die LDP-Sitzung nicht gestartet.

  • show configuration protocols ldp

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

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

  • Wenn die Konfiguration von der Verwendung einer gültigen Transportadresse in eine Transportadresse geändert wird, die ungültig (nicht erreichbar) ist, können die folgenden Traces beobachtet werden:

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

  • Aktivieren Sie die address familyOption . Die Transportadresse, die unter der session Anweisung konfiguriert wird, muss derselben Adressfamilie angehören wie der Nachbar oder die Sitzung.

  • Die Adresse, die als Transportadresse unter einer neighbor oder-Anweisung session konfiguriert ist, muss für den Router lokal sein, damit die angestrebten Hello-Nachrichten gestartet werden können. Sie können überprüfen, ob die Adresse konfiguriert ist. Wenn die Adresse unter keiner Schnittstelle konfiguriert ist, wird die Konfiguration abgelehnt.

Konfigurieren der Präfixe, die in LDP aus der Routing-Tabelle angekündigt werden

Sie können den Satz von Präfixen steuern, die in LDP angekündigt werden, und veranlassen, dass der Router der Ausgangsrouter für diese Präfixe ist. Standardmäßig wird nur die Loopback-Adresse in LDP angekündigt. Fügen Sie die egress-policy folgende Anweisung ein, um den Satz von Präfixen aus der Routingtabelle zu konfigurieren, die in LDP angekündigt werden sollen:

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

HINWEIS:

Wenn Sie eine Ausgangsrichtlinie für LDP konfigurieren, die die Loopbackadresse nicht enthält, wird sie in LDP nicht mehr angekündigt. Wenn Sie die Loopbackadresse weiterhin ankündigen möchten, müssen Sie sie explizit als Teil der LDP-Ausgangsrichtlinie konfigurieren.

Die benannte Richtlinie (konfiguriert auf der [edit policy-options] Hierarchieebene oder [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 von Nachbarn, für die diese Präfixe angekündigt werden, mithilfe der export Anweisung steuern. Es werden nur from Operatoren berücksichtigt, Sie können jeden gültigen from Operator verwenden. Weitere Informationen finden Sie in der Junos OS Routing Protocols Library for Routing Devices.

HINWEIS:

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

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

Kündigen Sie alle verbundenen Routen in LDP an:

Konfigurieren der FEC-Deaggregation

Wenn ein LDP-Ausgangsrouter mehrere Präfixe ankündigt, werden die Präfixe an ein einzelnes Label gebunden und zu einer einzigen Weiterleitungsäquivalenzklasse (FEC) aggregiert. Standardmäßig behält LDP diese Aggregation bei, wenn die Ankündigung das Netzwerk durchläuft.

Da ein LSP nicht auf mehrere nächste Hops aufgeteilt ist und die Präfixe an einen einzelnen LSP gebunden sind, findet normalerweise kein Lastenausgleich über Pfade mit gleichen Kosten statt. Sie können jedoch einen Lastenausgleich über Pfade zu gleichen Kosten durchführen, wenn Sie eine Lastenausgleichsrichtlinie konfigurieren und die FECs deaggregieren.

Das Deaggregieren der FECs bewirkt, dass jedes Präfix an ein separates Label gebunden wird und zu einem separaten LSP wird.

Um deaggregierte FECs zu konfigurieren, fügen Sie die deaggregate folgende Anweisung ein:

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

Für alle LDP-Sitzungen können Sie deaggregierte FECs nur global konfigurieren.

Durch die Deaggregation einer FEC können die resultierenden mehreren LSPs auf mehrere Pfade mit gleichen Kosten verteilt werden, und LSPs werden auf die mehreren nächsten Hops in den Ausgangssegmenten verteilt, es wird jedoch nur ein nächster Hop pro LSP installiert.

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

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung 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 das Junos-Betriebssystem so konfigurieren, dass der Datenverkehr für LDP-FECs verfolgt und überwacht wird. LDP FEC-Policer können für Folgendes verwendet werden:

  • Verfolgen oder überwachen Sie den eingehenden Datenverkehr für eine LDP FEC.

  • Verfolgen oder überwachen Sie den Transitverkehr für eine LDP FEC.

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

  • Verfolgen oder überwachen 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 bestimmt ist.

Um den Datenverkehr für eine LDP-FEC zu überwachen, müssen Sie zunächst einen Filter konfigurieren. Insbesondere müssen Sie entweder die interface Anweisung oder die interface-set Anweisung auf Hierarchieebene [edit firewall family protocol-family filter filter-name term term-name from] konfigurieren. Mit dieser interface Anweisung können Sie den Filter einer einzelnen Schnittstelle zuordnen. Mit dieser interface-set Anweisung können Sie den Filter mehreren Schnittstellen zuordnen.

Weitere Informationen zum Konfigurieren der interface Anweisung, der Anweisung und der Policer für LDP-FECs finden Sie im Benutzerhandbuch für Routingrichtlinien, Firewallfilterinterface-setund Traffic Policers.

Nachdem Sie die Filter konfiguriert haben, müssen Sie sie in die policing Anweisungskonfiguration für LDP aufnehmen. Um Policer für LDP-FECs zu konfigurieren, fügen Sie die policing folgende Anweisung ein:

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

Die policing Anweisung enthält die folgenden Optionen:

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

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

  • transit-traffic– Geben Sie den Namen des Filters für den Transitdatenverkehr an.

Konfigurieren der LDP-IPv4-FEC-Filterung

Wenn eine LDP-Zielsitzung eingerichtet wird, tauscht das Junos-Betriebssystem standardmäßig immer sowohl die IPv4-Weiterleitungsäquivalenzklassen (FECs) als auch die FECs der Layer-2-Verbindung über die LDP-Zielsitzung aus. Für eine LDP-Sitzung mit einem indirekt verbundenen Nachbarn sollten Sie Layer-2-Circuit-FECs nur dann in den Neighbor exportieren, wenn die Session speziell für die Unterstützung von Layer-2-Circuits oder VPLS konfiguriert wurde.

In einem Netzwerk gemischter Anbieter, 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-Verbindung oder einer LDP-VPLS-Konfiguration gebildet wurden. Ebenso kann es nützlich sein, alle IPv4-FECs zu filtern, die in dieser Art von Umgebung empfangen werden.

Wenn es sich bei allen LDP-Nachbarn, die einer LDP-Sitzung zugeordnet sind, nur um Layer- 2-Nachbarn handelt, können Sie das Junos-Betriebssystem so konfigurieren, dass nur Layer- 2-Circuit-FECs angekündigt werden, indem Sie die l2-smart-policy Anweisung konfigurieren. Diese Funktion filtert auch automatisch die IPv4-FECs heraus, die in dieser Sitzung empfangen wurden. Wenn Sie eine explizite Export- oder Importrichtlinie konfigurieren, die für l2-smart-policy aktiviert ist, wird diese Funktion in die entsprechende Richtung deaktiviert.

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

Fügen Sie die folgende Anweisung ein, um zu verhindern, dass LDP IPv4-FECs über LDP-Sitzungen nur mit Layer- 2-Nachbarn exportiert, und um IPv4-FECs herauszufiltern, die l2-smart-policy über solche Sitzungen empfangen wurden:

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 die Bidirectional Forwarding Detection (BFD) für LDP-LSPs konfigurieren. Das BFD-Protokoll ist ein einfacher Hello-Mechanismus, der Fehler in einem Netzwerk erkennt. Hello-Pakete werden in einem festgelegten, regelmäßigen Intervall gesendet. Ein Nachbarfehler wird erkannt, wenn der Router nach einem bestimmten Intervall keine Antwort mehr empfängt. BFD funktioniert mit einer Vielzahl von Netzwerkumgebungen und Topologien. Die Fehlererkennungs-Timer für BFD haben kürzere Zeitlimits als die Fehlererkennungsmechanismen statischer Routen und ermöglichen so eine schnellere Erkennung.

Ein Fehler wird protokolliert, wenn eine BFD-Sitzung für einen Pfad fehlschlägt. Im Folgenden wird gezeigt, 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-signalisierte LSPsbeschrieben.

Die Timer für die BFD-Fehlererkennung sind adaptiv und können so eingestellt werden, dass sie mehr oder weniger aggressiv sind. Beispielsweise können sich die Timer an einen höheren Wert anpassen, wenn die Nachbarschaft fehlschlägt, oder ein Nachbar kann einen höheren Wert für einen Timer aushandeln als den konfigurierten Wert. Die Timer passen sich an einen höheren Wert an, wenn eine BFD-Sitzungsklappe mehr als dreimal innerhalb von 15 Sekunden auftritt. Ein Backoff-Algorithmus erhöht das Empfangsintervall (Rx) um zwei, wenn die lokale BFD-Instanz der Grund für die Sitzungsklappe ist. Das Übertragungsintervall (Tx) wird um zwei erhöht, wenn die Remote-BFD-Instanz der Grund für die Sitzungsklappe ist. Sie können den clear bfd adaptation Befehl verwenden, um BFD-Intervall-Timer auf ihre konfigurierten Werte zurückzusetzen. Der clear bfd adaptation Befehl ist trefferlos, d. h., der Befehl wirkt sich nicht auf den Datenverkehrsfluss auf dem Routinggerät aus.

Um BFD für LDP-LSPs zu aktivieren, fügen Sie die oambfd-liveness-detection und-Anweisungen ein:

Sie können BFD für die LDP-LSPs aktivieren, die einer bestimmten Weiterleitungsäquivalenzklasse (FEC) zugeordnet sind, indem Sie die FEC-Adresse mit der fec Option auf Hierarchieebene [edit protocols ldp] konfigurieren. Alternativ können Sie eine OAM-Eingangsrichtlinie (Operation Administration and Management) konfigurieren, um BFD für einen Bereich 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 die entsprechenden 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 gestartet.

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 die Hierarchieebene [edit logical-systems] nicht.

Die oam Anweisung enthält 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 gestartet wird.

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

Die bfd-liveness-detection Anweisung enthält die folgenden Optionen:

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

  • holddown-interval: Geben Sie die Dauer an, für die die BFD-Sitzung aktiv bleiben soll, bevor die Route oder der nächste Hop hinzugefügt wird. Wenn Sie eine Zeit von 0 Sekunden angeben, wird die Route oder der nächste Hop hinzugefügt, sobald die BFD-Sitzung wieder gestartet wird.

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

  • minimum-receive-interval– Geben Sie das minimale Empfangsintervall an. Der Bereich liegt zwischen 1 und 255.000 Millisekunden.

  • minimum-transmit-interval– Geben Sie das minimale Übertragungsintervall an. Der Bereich liegt zwischen 1 und 255.000 Millisekunden.

  • multiplier: Geben Sie den Multiplikator für die Erkennungszeit 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-fähigem BFD für LDP-Sprachdienstleister

Wenn Sie BFD für einen FEC konfigurieren, wird eine BFD-Sitzung nur für einen aktiven lokalen Next-Hop für den Router eingerichtet. Sie können jedoch mehrere BFD-Sitzungen konfigurieren, eine für jeden FEC, der einem bestimmten ECMP-Pfad (Equal-Cost Multipath) zugeordnet ist. Damit dies ordnungsgemäß funktioniert, müssen Sie auch die regelmäßige LDP-LSP-Traceroute konfigurieren. (Siehe Konfigurieren von LDP-LSP-Traceroute.) LDP LSP-Traceroute wird verwendet, um ECMP-Pfade zu ermitteln. Für jeden erkannten ECMP-Pfad wird eine BFD-Sitzung initiiert. Wenn eine BFD-Sitzung für einen der ECMP-Pfade fehlschlägt, wird ein Fehler protokolliert.

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

  • Wenn die letzte LDP-LSP-Traceroute für eine FEC von der vorherigen Traceroute abweicht, werden die BFD-Sitzungen, die dieser FEC zugeordnet sind (die BFD-Sitzungen für Adressbereiche, die sich gegenüber der vorherigen Ausführung geändert haben), heruntergefahren, und neue BFD-Sitzungen werden für die Zieladressen in den geänderten Bereichen initiiert.

  • Wenn die LDP-LSP-Traceroute einen Fehler zurückgibt (z. B. eine Zeitüberschreitung), werden alle BFD-Sitzungen, die dieser FEC zugeordnet sind, abgebrochen.

Um LDP so zu konfigurieren, dass BFD-Sitzungen für alle ECMP-Pfade eingerichtet werden, die für die angegebene FEC konfiguriert sind, fügen Sie die ecmp Anweisung ein.

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

Zusammen mit der ecmp Anweisung müssen Sie die periodic-traceroute Anweisung entweder in der globalen LDP-OAM-Konfiguration (auf der [edit protocols ldp oam] Hierarchieebene oder [edit logical-systems logical-system-name protocols ldp oam] ) oder in der Konfiguration für die angegebene FEC (auf der [edit protocols ldp oam fec address] Hierarchieebene oder [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 die Hierarchieebene [edit logical-systems] nicht.

Konfigurieren einer Fehleraktion für die BFD-Sitzung auf einem LDP-LSP

Sie können Routen- und Next-Hop-Eigenschaften für den Fall eines BFD-Sitzungsfehlers auf einem LDP-LSP konfigurieren. Bei dem Fehlerereignis kann es sich um eine vorhandene BFD-Sitzung handeln, die ausgefallen ist, oder um eine BFD-Sitzung, die nie gestartet wurde. LDP fügt die Route oder den nächsten Hop zurück, wenn die entsprechende BFD-Sitzung wieder verfügbar ist.

Sie können eine der folgenden Fehleraktionsoptionen für die failure-action Anweisung im Falle eines BFD-Sitzungsfehlers auf dem LDP-LSP konfigurieren:

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

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

Um eine Fehleraktion im Falle eines BFD-Sitzungsfehlers auf einem LDP-LSP zu konfigurieren, schließen Sie entweder die remove-nexthop Option oder die remove-route Option für die failure-action Anweisung ein:

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

Holddown-Intervall für die BFD-Sitzung konfigurieren

Sie können die Dauer angeben, für die die BFD-Sitzung aktiv sein soll, bevor eine Route oder ein nächster Hop hinzugefügt wird, indem Sie die holddown-interval Anweisung entweder auf der [edit protocols ldp oam bfd-livenesss-detection] Hierarchieebene oder auf der [edit protocols ldp oam fec address bfd-livenesss-detection] Hierarchieebene konfigurieren. Wenn Sie eine Zeit von 0 Sekunden angeben, wird die Route oder der nächste Hop hinzugefügt, sobald die BFD-Sitzung wieder gestartet wird.

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

Grundlegendes zu Multicast-only Fast Reroute

Multicast-only Fast Reroute (MoFRR) minimiert den Paketverlust für Datenverkehr in einem Multicast-Verteilungsbaum bei Verbindungsfehlern 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-Pfaden und Multipoint-LDP nicht unterstützt.

Bei Routern der MX-Serie wird MoFRR nur auf Routern der MX-Serie mit MPC-Linecards unterstützt. Voraussetzung ist, dass Sie den Router im network-services enhanced-ip Modus konfigurieren, und alle Linecards im Router müssen MPCs sein.

Wenn MoFRR aktiviert ist, senden Geräte Join-Nachrichten auf primären und Backup-Upstream-Pfaden an eine Multicast-Quelle. Geräte empfangen Datenpakete sowohl vom primären als auch vom Backup-Pfad und verwerfen die redundanten Pakete basierend auf ihrer Priorität (Gewichtungen, die dem primären und dem Backup-Pfad zugewiesen sind). Wenn ein Gerät einen Fehler auf dem primären Pfad erkennt, beginnt es sofort mit der Annahme von Paketen von der sekundären Schnittstelle (dem Backup-Pfad). Die schnelle Umschaltung verbessert die Konvergenzzeiten bei Ausfällen der primären Pfadverbindung erheblich.

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

MoFRR Übersicht

Beim schnellen Rerouting in Unicast-Streams richtet ein Upstream-Routing-Gerät MPLS-Label-Switched-Pfade (LSPs) im Voraus ein oder berechnet einen IP-loop-free alternate (LFA) Fast-Reroute-Backup-Pfad im Voraus, um den Ausfall eines Segments im Downstream-Pfad zu behandeln.

Beim Multicast-Routing stammen die Datenverkehrsverteilungsdiagramme in der Regel von der Empfängerseite. Dies unterscheidet sich vom Unicast-Routing, bei dem im Allgemeinen der Pfad von der Quelle zum Empfänger festgelegt wird. PIM (für IP), Multipoint LDP (für MPLS) und RSVP-TE (für MPLS) sind Protokolle, die in der Lage sind, Multicast-Verteilungsdiagramme zu erstellen. Von diesen initiieren PIM- und Multipoint-LDP-Empfänger die Einrichtung des Verteilungsgraphen, sodass MoFRR mit diesen beiden Multicast-Protokollen arbeiten kann, sofern sie unterstützt werden.

Wenn das Gerät in einer Multicast-Struktur einen Ausfall einer Netzwerkkomponente erkennt, dauert es einige Zeit, bis eine reaktive Reparatur durchgeführt wird, was zu erheblichen Datenverkehrsverlusten beim Einrichten eines alternativen Pfads führt. MoFRR reduziert den Datenverkehrsverlust in einem Multicast-Verteilungsbaum, wenn eine Netzwerkkomponente ausfällt. Bei MoFRR richtet eines der nachgeschalteten Routing-Geräte einen alternativen Pfad zur Quelle ein, um einen Backup-Livestream desselben Multicast-Datenverkehrs zu empfangen. Wenn ein Fehler entlang des primären Datenstroms auftritt, kann das MoFRR-Routing-Gerät schnell zum Sicherungsdatenstrom wechseln.

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

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

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

Abbildung 12: MoFRR-BeispieltopologieMoFRR-Beispieltopologie

Wenn MoFRR aktiviert ist, richtet das Ausgangs-Routing-Gerät (Empfängerseite) zwei Multicast-Bäume ein, einen primären Pfad und einen Backup-Pfad, in Richtung der Multicast-Quelle für jeden (S,G). Mit anderen Worten, das Ausgangsroutinggerät gibt dieselben (S,G) Join-Nachrichten an zwei verschiedene Upstreamnachbarn weiter und erstellt so zwei Multicast-Strukturen.

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

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 mithilfe der link-protection Anweisung in der IGP-Konfiguration (Interior Gateway Protocol). Wenn Sie den Link-Schutz auf einer OSPF- oder IS-IS-Schnittstelle aktivieren, erstellt das Gerät für alle Zielrouten, die die geschützte Schnittstelle durchlaufen, einen Backup-LFA-Pfad zum primären nächsten Hop.

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. Bei Multipoint-LDP-MoFRR richtet das Gerät zwei Pfade zum Upstream-PE-Routing-Gerät ein, um zwei Ströme von MPLS-Paketen am LER zu empfangen. Das Gerät akzeptiert einen der Streams (den primären), und der andere (das Backup) wird in der LER gelöscht. Wenn der primäre Pfad ausfällt, akzeptiert das Gerät stattdessen den Backup-Stream. Die Unterstützung von Inband-Signalen ist eine Voraussetzung für MoFRR mit Multipoint-LDP (siehe Grundlegendes zur Multipoint-LDP-Inband-Signalübertragung für Punkt-zu-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, schließen Sie die mofrr-asm-starg Konfigurationsanweisung in die [edit routing-options multicast stream-protection] Hierarchie ein. Für jede Gruppe G funktioniert MoFRR entweder für (S,G) oder (*,G), aber nicht für beide. (S,G) hat immer Vorrang vor (*,G).

Wenn MoFRR aktiviert ist, gibt ein PIM-Routing-Gerät Join-Nachrichten an zwei Upstream-RPF-Schnittstellen (Reverse Path Forwarding) weiter, um Multicast-Datenverkehr auf beiden Verbindungen für dieselbe Join-Anforderung zu empfangen. MoFRR bevorzugt zwei Pfade, die nicht zum gleichen unmittelbar vorgeschalteten Routing-Gerät konvergieren. PIM installiert entsprechende Multicast-Routen mit Upstream-RPF-Next-Hops mit zwei Schnittstellen (für den Primär- und den Backup-Pfad).

Wenn der primäre Pfad ausfällt, wird der Backup-Pfad auf den primären Status aktualisiert, und das Gerät leitet den Datenverkehr entsprechend weiter. Wenn alternative Pfade verfügbar sind, berechnet MoFRR einen neuen Backup-Pfad und aktualisiert oder installiert die entsprechende 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 auf die Links jedoch möglicherweise nicht gleichmäßig. Wenn eine neue ECMP-Verbindung hinzugefügt wird, werden Join-Nachrichten auf dem primären Pfad neu verteilt und für die Last ausgeglichen. Die Verknüpfungsnachrichten auf dem Sicherungspfad folgen möglicherweise immer noch demselben Pfad und werden möglicherweise nicht gleichmäßig verteilt.

Sie aktivieren MoFRR mithilfe der stream-protection Konfigurationsanweisung in der Hierarchie [edit routing-options multicast] . MoFRR wird durch eine Reihe von Filterrichtlinien verwaltet.

Wenn ein ausgehendes PIM-Routing-Gerät eine Join-Nachricht oder einen IGMP-Bericht empfängt, prüft es, ob eine MoFRR-Konfiguration vorliegt, und geht wie folgt vor:

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

  • Wenn die MoFRR-Konfiguration vorhanden ist, prüft das Gerät, ob eine Richtlinienkonfiguration vorliegt.

  • Wenn keine Richtlinie vorhanden ist, sucht das Gerät nach Primär- und Backup-Pfaden (Upstream-Schnittstellen) und geht wie folgt vor:

    • Wenn Primär- und Backup-Pfade nicht verfügbar sind, sendet PIM eine Join-Nachricht stromaufwärts an einen vorgelagerten Nachbarn (z. B. Ebene 2 in Abbildung 12).

    • Wenn Primär- und Sicherungspfade verfügbar sind, sendet PIM die Join-Nachricht stromaufwärts an zwei der verfügbaren Upstream-Nachbarn. Junos OS richtet primäre und sekundäre Multicast-Pfade für den Empfang von Multicast-Datenverkehr ein (z. B. Ebene 1 in Abbildung 12).

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

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

    • Wenn diese Richtlinienprüfung erfolgreich ist, prüft das Gerät, ob Primär- und Sicherungspfade (Upstream-Schnittstellen) vorhanden sind.

      • Wenn der primäre Pfad und der Sicherungspfad nicht verfügbar sind, sendet PIM eine Join-Nachricht stromaufwärts an einen vorgelagerten Nachbarn (z. B. Ebene 2 in Abbildung 12).

      • Wenn der primäre Pfad und der Sicherungspfad verfügbar sind, sendet PIM die Join-Nachricht stromaufwärts an zwei der verfügbaren Upstreamnachbarn. 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 die Duplizierung des MPLS-Datenverkehrs zu vermeiden, wählt Multipoint-LDP in der Regel nur einen Upstreampfad aus. (Siehe Abschnitt 2.4.1.1. Bestimmen des eigenen "Upstream-LSR" in RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.)

Bei Multipoint-LDP mit MoFRR wählt das Multipoint-LDP-Gerät zwei separate Upstream-Peers aus und sendet zwei separate Labels, eines an jeden Upstream-Peer. Das Gerät verwendet den gleichen Algorithmus, der in RFC 6388 beschrieben ist, um den primären Upstreampfad auszuwählen. Das Gerät verwendet denselben Algorithmus, um den Backup-Upstream-Pfad auszuwählen, schließt jedoch den primären Upstream-LSR als Kandidaten aus. Die beiden verschiedenen Upstream-Peers senden zwei Ströme von MPLS-Datenverkehr an das Ausgangsroutinggerät. Das Gerät wählt nur einen der Upstream-Nachbarpfade als primären Pfad aus, von dem der MPLS-Datenverkehr angenommen werden soll. Der andere Pfad wird zum Backup-Pfad, und das Gerät verwirft diesen Datenverkehr. Wenn der primäre Upstreampfad ausfällt, beginnt das Gerät, Datenverkehr vom Backup-Pfad zu akzeptieren. Das Multipoint-LDP-Gerät wählt die beiden Upstreampfade basierend auf dem nächsten Hop des Interior Gateway Protocol (IGP)-Root-Geräts aus.

Eine Weiterleitungsäquivalenzklasse (FEC) ist eine Gruppe von IP-Paketen, die auf die gleiche Weise, über denselben Pfad und mit der gleichen Weiterleitungsbehandlung weitergeleitet werden. Normalerweise stellt die Bezeichnung, die auf einem bestimmten Paket angebracht wird, die FEC dar, der dieses Paket zugewiesen ist. In MoFRR werden für jede FEC zwei Routen in die Tabelle mpls.0 eingefügt – eine Route für die primäre Bezeichnung und die andere Route für die Backup-Bezeichnung.

Wenn parallele Verbindungen zum gleichen unmittelbar vorgeschalteten Gerät vorhanden sind, betrachtet das Gerät beide parallelen Verbindungen als primär. Zu jedem Zeitpunkt sendet das Upstream-Gerät Datenverkehr nur über eine der mehreren parallelen Verbindungen.

Ein Bud-Knoten ist ein LSR, der ein Ausgangs-LSR ist, aber auch einen oder mehrere direkt verbundene nachgeschaltete LSRs hat. Bei einem Bud-Knoten wird der Datenverkehr vom primären Upstream-Pfad an einen Downstream-LSR weitergeleitet. Wenn der primäre Upstream-Pfad ausfällt, wird der MPLS-Datenverkehr vom Backup-Upstream-Pfad an den Downstream-LSR weitergeleitet. Dies bedeutet, dass der nachgelagerte LSR-Hop zusammen mit dem ausgehenden nächsten Hop zu beiden MPLS-Routen hinzugefügt wird.

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

Wenn Sie die Multipoint-LDP-Punkt-zu-Mehrpunkt-FEC für MoFRR aktiviert haben, berücksichtigt das Gerät bei der Auswahl des Upstreampfads die folgenden Überlegungen:

  • Die Ziel-LDP-Sitzungen werden übersprungen, wenn es eine nicht zielgerichtete LDP-Sitzung gibt. Wenn es eine einzelne Ziel-LDP-Sitzung gibt, wird die Ziel-LDP-Sitzung ausgewählt, aber der entsprechende Punkt-zu-Mehrpunkt-FEC verliert die MoFRR-Funktion, da der Ziel-LDP-Sitzung keine Schnittstelle zugeordnet ist.

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

  • Bei allen Aktualisierungen der Root-Node-Route wird der Upstream-Pfad basierend auf den letzten nächsten Hops vom IGP geändert. Wenn ein besserer Pfad verfügbar ist, versucht Multipoint-LDP, zum besseren Pfad zu wechseln.

Paketweiterleitung

Bei PIM oder Multipoint-LDP führt das Gerät die Auswahl des Multicast-Quelldatenstroms an der Eingangsschnittstelle durch. Dadurch wird die Bandbreite des Fabric geschont und die Weiterleitungsleistung maximiert, da es:

  • Vermeidet das Versenden doppelter Streams über die Fabric

  • Verhindert mehrere Routensuchvorgänge (die zu Paketverlusten führen).

Bei PIM enthält jeder IP-Multicast-Stream dieselbe Zieladresse. Unabhängig von der Schnittstelle, auf der die Pakete ankommen, haben die Pakete die gleiche Route. Das Gerät überprüft die Schnittstelle, auf der die einzelnen Pakete ankommen, und leitet nur diejenigen weiter, die von der primären Schnittstelle stammen. Wenn die Schnittstelle mit einer Backup-Stream-Schnittstelle übereinstimmt, verwirft das Gerät die Pakete. 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 Steuerungsebene.

Abbildung 13 zeigt diesen Prozess anhand von Beispiel-Primär- und Backup-Schnittstellen für Router mit PIM. Abbildung 14 zeigt dies ähnlich für Switches mit PIM.

Abbildung 13: MoFRR-IP-Routensuche in der Paketweiterleitungs-Engine auf RouternMoFRR-IP-Routensuche in der Paketweiterleitungs-Engine auf Routern
Abbildung 14: MoFRR-IP-Routenverarbeitung in der Paketweiterleitungs-Engine auf SwitchesMoFRR-IP-Routenverarbeitung in der Paketweiterleitungs-Engine auf Switches

Für MoFRR mit Multipoint-LDP auf Routern verwendet das Gerät mehrere MPLS-Labels, um die Auswahl des MoFRR-Datenstroms zu steuern. Jede Beschriftung stellt eine separate Route dar, verweist jedoch jeweils auf dieselbe Schnittstellenlistenprüfung. Das Gerät leitet nur das primäre Label weiter und löscht alle anderen. Mehrere Schnittstellen können Pakete mit demselben Label empfangen.

Abbildung 15 zeigt diesen Prozess für Router mit Multipoint-LDP.

Abbildung 15: MoFRR MPLS-Routensuche in der Paketweiterleitungs-EngineMoFRR MPLS-Routensuche in der Paketweiterleitungs-Engine

Einschränkungen und Vorbehalte

MoFRR-Einschränkungen und Vorbehalte bei Switching- und Routing-Geräten

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

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

  • MoFRR unterstützt das schnelle Rerouting auf zwei ausgewählten disjunkten Pfaden zur Quelle. Zwei der ausgewählten Upstream-Nachbarn können sich nicht auf derselben Schnittstelle befinden, d. h. zwei Upstream-Nachbarn auf einem LAN-Segment. Das Gleiche gilt, wenn es sich bei der Upstream-Schnittstelle um eine Multicast-Tunnelschnittstelle handelt.

  • Die Erkennung der maximalen End-to-End-disjunkten Upstream-Pfade wird nicht unterstützt. Das empfängerseitige (Ausgangs-)Routinggerät stellt nur sicher, dass ein disjunktes Upstream-Gerät (der unmittelbar vorherige Hop) vorhanden ist. PIM und Multipoint-LDP unterstützen nicht das Äquivalent von expliziten Routenobjekten (Explicit Route Objects, EROs). Daher ist die Erkennung disjunkter Upstream-Pfade auf die Steuerung des unmittelbar vorhergehenden Hop-Geräts beschränkt. Aufgrund dieser Einschränkung kann der Pfad zum Upstreamgerät des vorherigen Hops, der als primärer Hop und Backup ausgewählt wurde, freigegeben werden.

  • In den folgenden Szenarien kann es zu Datenverkehrsverlusten kommen:

    • Auf einem Ausgangsgerät wird ein besserer Upstreampfad verfügbar.

    • MoFRR wird auf dem Ausgangsgerät aktiviert oder deaktiviert, während ein aktiver Datenverkehrsstrom fließt.

  • PIM-Join-Lastenausgleich für Join-Nachrichten für Backup-Pfade werden nicht unterstützt.

  • Für eine Multicastgruppe G ist MoFRR sowohl für (S,G) als auch für (*,G) Join-Nachrichten nicht zulässig. (S,G)-Verknüpfungsnachrichten haben Vorrang vor (*,G).

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

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

  • Der PIM-Dense-Mode wird von MoFRR nicht unterstützt.

  • Multicast-Statistiken für den Backup-Datenverkehrsstrom werden von PIM nicht verwaltet und sind daher in der Betriebsausgabe von Befehlen show nicht verfügbar.

  • Die Ratenüberwachung wird nicht unterstützt.

MoFRR-Einschränkungen beim Switching von Geräten mit PIM

MoFRR mit PIM weist die folgenden Einschränkungen für das Wechseln von Geräten auf:

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

  • Paketreplikation und Multicast-Lookups bei der Weiterleitung von Multicast-Datenverkehr können dazu führen, dass Pakete mehrmals durch PFEs zirkulieren. Daher können die angezeigten Werte für die Anzahl der Multicast-Pakete aus dem show pfe statistics traffic Befehl in Ausgabefeldern wie Input packets und Output packetshöher als erwartet angezeigt werden. Dieses Verhalten kann in MoFRR-Szenarien häufiger auftreten, da doppelte Primär- und Sicherungsdatenströme den Datenverkehrsfluss im Allgemeinen erhöhen.

MoFRR-Einschränkungen und Vorsichtsmaßnahmen bei Routing-Geräten mit Multipoint-LDP

MoFRR weist bei Verwendung mit Multipoint-LDP die folgenden Einschränkungen und Vorbehalte für Router auf:

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

  • Gemischte Upstream-MoFRR wird nicht unterstützt. Dies bezieht sich auf PIM-Multipoint-LDP-In-Band-Signalisierung, wobei ein Upstream-Pfad über Multipoint-LDP und der zweite Upstream-Pfad über PIM verläuft.

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

  • Wenn die Quelle über mehrere eingehende (quellenseitige) Provider-Edge-Routing-Geräte (PE) erreichbar ist, wird Multipoint-LDP-MoFRR nicht unterstützt.

  • Gezielte LDP-Upstream-Sitzungen werden nicht als Upstream-Gerät für MoFRR ausgewählt.

  • Der Multipoint-LDP-Link-Schutz auf dem Sicherungspfad wird nicht unterstützt, da interne MoFRR-Bezeichnungen nicht unterstützt werden.

Konfigurieren der schnellen Multicast-Weiterleitung

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

Wenn eine schnelle Umleitung auf Unicast-Streams angewendet wird, richtet ein Upstream-Router MPLS-Label-Switched-Pfade (LSPs) vor oder berechnet einen schnellen LFA-Backup-Sicherungspfad (IP Loop-Free Alternate) für schnelle Umleitungen, um den Ausfall eines Segments im Downstream-Pfad zu behandeln.

Beim Multicast-Routing werden die Verteilungsdiagramme des Datenverkehrs in der Regel vom Empfänger erstellt. Dies unterscheidet sich vom Unicast-Routing, bei dem in der Regel der Pfad von der Quelle zum Empfänger festgelegt wird. Protokolle, die in der Lage sind, Multicast-Verteilungsdiagramme zu erstellen, sind PIM (für IP), Multipoint-LDP (für MPLS) und RSVP-TE (für MPLS). Von diesen initiieren PIM- und Multipoint-LDP-Empfänger die Einrichtung des Verteilungsdiagramms und deshalb:

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

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

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

(Nur für Router der MX-Serie) MoFRR wird von Routern der MX-Serie mit MPC-Linecards unterstützt. Voraussetzung ist, dass alle Linecards im Router MPCs sind.

So konfigurieren Sie MoFRR auf Routern oder Switches:

  1. (Nur für Router der MX- und SRX-Serie) Stellen Sie den Router auf den erweiterten IP-Modus 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 betroffen sind.

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

    Zum Beispiel:

  4. (Optional) Wenn Sie eine Routing-Richtlinie zum Filtern der Gruppe von Multicastgruppen konfiguriert haben, die von Ihrer MoFRR-Konfiguration betroffen sein sollen, wenden Sie die Richtlinie für den MoFRR-Stream-Schutz an.

    Zum Beispiel:

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

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

  6. (Optional) Lassen Sie in einer PIM-Domäne mit MoFRR nur ein disjunktes RPF (ein RPF auf einer separaten Ebene) als Backup-RPF-Pfad zu.

    Dies wird für Multipoint-LDP-MoFRR nicht unterstützt. In einer Multipoint-LDP-MoFRR-Domäne wird dieselbe Bezeichnung von parallelen Links zum gleichen Upstreamnachbarn gemeinsam genutzt. Dies ist in einer PIM-Domäne nicht der Fall, in der jeder Link einen Nachbarn bildet. Die mofrr-disjoint-upstream-only Anweisung lässt nicht zu, dass ein Backup-RPF-Pfad ausgewählt wird, wenn der Pfad zum gleichen Upstreamnachbarn wie der des primären RPF-Pfads führt. Dadurch wird sichergestellt, dass MoFRR nur in einer Topologie ausgelöst wird, die über mehrere RPF-Upstream-Nachbarn verfügt.

  7. (Optional) Verhindern Sie in einer PIM-Domäne mit MoFRR das Senden von Join-Nachrichten auf dem Sicherungspfad, behalten Sie jedoch 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 Auswahl des Unicast-Gateways für die Unicast-Route zur Quelle basiert und sich ändert, wenn sich die Unicastauswahl ändert, anstatt dass der Sicherungspfad als primärer Pfad hochgestuft wird. Dadurch 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, ist nicht garantiert, dass der Sicherungspfad zum neuen primären Pfad hochgestuft wird, wenn der primäre Pfad ausfällt.

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

Beispiel: Konfigurieren der schnellen Multicast-Weiterleitung in einer Multipoint-LDP-Domäne

In diesem Beispiel wird gezeigt, wie MoFRR (Multicast-Only Fast Reroute) konfiguriert wird, um Paketverluste 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-Router (PE) für den Empfang von zwei Streams von MPLS-Paketen am Label-Edge-Router (LER) eingerichtet. Einer der Streams (der primäre) wird akzeptiert, und der andere (das Backup) wird bei der LER gelöscht. Der Backup-Stream wird akzeptiert, wenn der primäre Pfad ausfällt.

Anforderungen

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

Damit MoFRR in einer Multipoint-LDP-Domäne funktioniert, muss MoFRR nur für den ausgehenden PE-Router aktiviert sein. Die anderen Router müssen MoFRR nicht unterstützen.

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

Für dieses Beispiel ist Junos OS Version 14.1 oder höher auf dem ausgehenden 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 mithilfe des set protocols igmp interface interface-name static group group Befehls statisch der gewünschten Gruppe beitreten. Für den Fall, dass kein echter Multicast-Empfängerhost verfügbar ist, wie in diesem Beispiel, ist diese statische IGMP-Konfiguration nützlich. Auf den Empfängern wird in diesem Beispiel . set protocols sap listen group

Die MoFRR-Konfiguration enthält eine Richtlinienoption, die in diesem Beispiel nicht gezeigt, aber separat erläutert wird. Die Option wird wie folgt konfiguriert:

Topologie

Abbildung 16 zeigt das Beispielnetzwerk an.

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

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

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 sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] 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-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere 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 AS-Nummer (Autonomous System).

  4. Konfigurieren Sie die Routing-Richtlinien.

  5. Konfigurieren Sie PIM.

  6. Konfigurieren Sie LDP.

  7. Konfigurieren Sie eine IGP oder statische Routen.

  8. Konfigurieren Sie internes BGP.

  9. Konfigurieren Sie MPLS und optional RSVP.

  10. Aktivieren Sie MoFRR.

Ergebnisse

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

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .

Verifizierung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der LDP-Punkt-zu-Mehrpunkt-Weiterleitungsäquivalenzklassen

Zweck

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

Action!
Bedeutung

Die Ausgabe zeigt, dass MoFRR aktiviert ist, und sie zeigt, dass die Bezeichnungen 301568 und 301600 für die beiden Multipoint-LDP-Punkt-zu-Multipoint-LSPs verwendet werden.

Untersuchen der Etiketteninformationen

Zweck

Stellen Sie sicher, dass das Ausgangsgerät über zwei Upstreamschnittstellen für den Multicast-Gruppenbeitritt verfügt.

Action!
Bedeutung

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

Überprüfen der Multicast-Routen

Zweck

Untersuchen Sie die IP-Multicastweiterleitungstabelle, um sicherzustellen, dass eine Upstream-RPF-Schnittstellenliste mit einer primären und einer Backup-Schnittstelle vorhanden ist.

Action!
Bedeutung

Die Ausgabe zeigt Primär- und Sicherungssitzungen sowie die nächsten RPF-Hops.

Überprüfen der LDP-Punkt-zu-Multipunkt-Datenverkehrsstatistiken

Zweck

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

Action!
Bedeutung

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

Beispiel: LDP-Downstream bei Bedarf konfigurieren

In diesem Beispiel wird gezeigt, wie LDP nachgelagert bei Bedarf konfiguriert wird. LDP wird üblicherweise im Downstream-Modus für unerwünschte Ankündigungen konfiguriert, was bedeutet, dass Label-Ankündigungen für alle Routen von allen LDP-Peers empfangen werden. Da Service Provider die Zugangs- und Aggregationsnetzwerke in eine einzige MPLS-Domäne integrieren, ist LDP Downstream on Demand erforderlich, um die Bindungen zwischen den Zugangs- und Aggregationsnetzwerken zu verteilen und die Verarbeitungsanforderungen für die Steuerungsebene zu reduzieren.

Downstream-Knoten könnten potenziell Zehntausende von Label-Bindungen von Upstream-Aggregationsknoten erhalten. Anstatt alle Label-Bindings für alle möglichen Loopback-Adressen innerhalb des gesamten MPLS-Netzwerks zu lernen und zu speichern, kann der Downstream-Aggregationsknoten mithilfe von LDP Downstream on Demand so konfiguriert werden, dass nur die Label-Bindings für die FECs angefordert werden, 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 die 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] einschließen. Wenn Sie Downstream-On-Demand konfiguriert haben, kündigt der Router von Juniper Networks die Downstream-On-Demand-Anfrage an seine Peer-Router an. Damit eine Downstream-On-Demand-Sitzung zwischen zwei Routern eingerichtet werden kann, müssen beide während des Aufbaus der LDP-Sitzung den Downstream-On-Demand-Modus ankündigen. Wenn ein Router den unaufgeforderten Downstream-Modus ankündigt und der andere Downstream-Modus bei Bedarf, wird der Downstream-Modus verwendet.

Konfiguration

LDP-Downstream bei Bedarf konfigurieren

Schritt-für-Schritt-Anleitung

So konfigurieren Sie eine LDP-Downstream-On-Demand-Richtlinie und konfigurieren dann diese Richtlinie und aktivieren LDP-Downstream-On-Demand für die 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 mit der DOD-Request-Loopbacks Richtlinie übereinstimmen.

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

    Die mit der dod-request-policy Anweisung angegebene Richtlinie wird verwendet, um die Präfixe zum Senden von Bezeichnungsanforderungsnachrichten zu identifizieren. Diese Richtlinie ähnelt einer Ausgangsrichtlinie oder einer Importrichtlinie. Bei der Verarbeitung von Routen aus der Routing-Tabelle 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 Bezeichnungsanforderungsnachrichten an die entsprechende nachgeschaltete LDP-Sitzung gesendet.

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

Verteilen von LDP-Downstream-on-Demand-Routen in gelabelte BGP

Schritt-für-Schritt-Anleitung

Verwenden Sie eine BGP-Exportrichtlinie, um LDP-Downstream-On-Demand-Routen in gekennzeichnete BGP zu verteilen.

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

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

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

Schritt-für-Schritt-Anleitung

Konfigurieren Sie die folgenden Richtlinien, um die Weitergabe von Labels auf andere Router zu beschränken, die im Downstream-Modus für unerwünschte Router(statt Downstream-on-Demand) konfiguriert sind:

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

  2. Konfigurieren Sie die Richtlinie so, dass Routen do-not-propagate-du-sessions nicht an Nachbarn 10.1.1.1weitergeleitet werden, 10.2.2.2und 10.3.3.3.

  3. Konfigurieren Sie die filter-dod-on-du-sessions Richtlinie so, dass die von der dod-routes Richtlinie untersuchten Routen nicht an die benachbarten Router weitergeleitet werden, die in der do-not-propagate-du-sessions Richtlinie definiert sind.

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

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show policy-options Befehle und show protocols ldp eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Verifizierung

Überprüfen des Etikettenankündigungsmodus

Zweck

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

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

Action!

Geben Sie die show ldp session Befehle und show ldp session detail ein:

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

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

Konfigurieren der nativen LDP-IPv6-Unterstützung

LDP wird in einem reinen IPv6-Netzwerk und in einem IPv6- oder IPv4-Dual-Stack-Netzwerk unterstützt, wie in RFC 7552beschrieben. Konfigurieren Sie die Adressfamilie wie inet für IPv4 oder inet6 für IPv6 oder beides, und die Transporteinstellung ist entweder IPv4 oder IPv6. Die dual-transport Anweisung ermöglicht es Junos OS LDP, die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herzustellen. Die inet-lsr-id und inet6-lsr-id IDs sind die beiden LSR-IDs, die konfiguriert werden müssen, um eine LDP-Sitzung über IPv4- und IPv6-TCP-Transport einzurichten. Diese beiden IDs sollten ungleich Null sein und müssen mit unterschiedlichen Werten konfiguriert werden.

Bevor Sie IPv6 als Dual-Stack konfigurieren, stellen Sie sicher, dass Sie die Routing- und Signalisierungsprotokolle konfigurieren.

Um die native LDP-IPv6-Unterstützung zu konfigurieren, müssen Sie die folgenden Schritte ausführen:

  1. Aktivieren Sie die FEC-Deaggregation (Forwarding Equivalence Class), um unterschiedliche Bezeichnungen für verschiedene Adressfamilien zu verwenden.
  2. Konfigurieren Sie LDP-Adressfamilien.
  3. Konfigurieren Sie die transport-preference Anweisung so, dass der bevorzugte Transport für die TCP-Verbindung ausgewählt wird, 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 Dual-Transport so, dass 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 z. B. inet-lsr-id als 10.255.0.1 und inet6-lsr-id als 10.1.1.1.

Beispiel: Konfigurieren der nativen LDP-IPv6-Unterstützung

In diesem Beispiel wird gezeigt, wie Sie dem Junos OS Label Distribution Protocol (LDP) erlauben, die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herzustellen. Dadurch wird Tunneling von IPv6 über IPv4-MPLS-Kern mit IPv4-signalisierten MPLS-Label-Switched-Pfaden (LSPs) vermieden.

Anforderungen

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

  • Zwei Router der MX-Serie

  • Junos OS Version 16.1 oder höher, das auf allen Geräten ausgeführt wird

Bevor Sie IPv6 als Dual-Stack konfigurieren, stellen Sie sicher, dass Sie die Routing- und Signalisierungsprotokolle konfigurieren.

Überblick

LDP wird in einem reinen IPv6-Netzwerk und in einem IPv6- oder IPv4-Dual-Stack-Netzwerk unterstützt, wie in RFC 7552beschrieben. 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. Mit der Dual-Transport-Anweisung kann Junos LDP die TCP-Verbindung über IPv4 mit IPv4-Nachbarn und über IPv6 mit IPv6-Nachbarn als Single-Stack-LSR herstellen. Das inet-lsr-id und inet6-lsr-id sind die beiden LSR-IDs, die konfiguriert werden müssen, um eine LDP-Sitzung über IPv4- und IPv6-TCP-Transport einzurichten. Diese beiden IDs sollten ungleich Null sein und müssen mit unterschiedlichen Werten konfiguriert werden.

Topologie

Abbildung 17 zeigt das LDP-IPv6 an, das als Dual-Stack auf Gerät R1 und Gerät R2 konfiguriert ist.

Abbildung 17: Beispiel für LDP Native IPv6-UnterstützungBeispiel für LDP Native IPv6-Unterstützung

Konfiguration

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem [edit] Konfigurationsmodus ein commit .

R1

R2

Konfigurieren von R1

Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene 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 die FEC-Deaggregation (Forwarding Equivalence Class), um unterschiedliche Bezeichnungen für verschiedene Adressfamilien zu verwenden.

  6. Konfigurieren Sie LDP-Adressfamilien.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfaces Befehle und show protocols eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Konfigurieren Sie die Transporteinstellung, um den bevorzugten Transport auszuwählen

CLI-Schnellkonfiguration
Schritt-für-Schritt-Anleitung

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 für den Aufbau einer LDP-Verbindung verwendet.

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

Schritt-für-Schritt-Anleitung
Ergebnisse

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

Konfigurieren Sie Dual-Transport zum Einrichten separater Sitzungen für IPv4 mit einem IPv4-Nachbarn und IPv6 mit einem IPv6-Nachbarn

Schritt-für-Schritt-Anleitung

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 Dual-Transport so, dass 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 im Konfigurationsmodus Ihre Konfiguration, indem Sie den show protocols Befehl eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Verifizierung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der Routeneinträge in der Tabelle mpls.0
Zweck

Zeigen Sie Informationen zur mpls.0-Routing-Tabelle an.

Action!

Führen Sie auf Gerät R1 im Betriebsmodus den show route table mpls.0 Befehl aus, um Informationen zur mpls.0-Routing-Tabelle anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Informationen der mpls.0-Routing-Tabelle.

Verifizieren der Routeneinträge in der inet.3-Tabelle
Zweck

Zeigen Sie inet.3-Routing-Tabelleninformationen an.

Action!

Führen Sie auf Gerät R1 im Betriebsmodus den show route table inet.3 Befehl aus, um Informationen zur inet.3-Routing-Tabelle anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Informationen der inet.3-Routing-Tabelle.

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

Zeigen Sie Informationen zur inet6.3-Routing-Tabelle an.

Action!

Führen Sie auf Gerät R1 im Betriebsmodus den show route table inet6.3 Befehl aus, um Informationen zur inet6.3-Routing-Tabelle anzuzeigen.

Bedeutung

Die Ausgabe zeigt die Informationen der inet6.3-Routing-Tabelle.

Verifizieren der LDP-Datenbank
Zweck

Zeigen Sie die LDP-Datenbankinformationen an.

Action!

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

Bedeutung

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

Überprüfen der LDP-Nachbarinformationen
Zweck

Zeigen Sie die LDP-Nachbarinformationen an.

Action!

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

Bedeutung

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

Überprüfen der LDP-Sitzungsinformationen
Zweck

Zeigen Sie die LDP-Sitzungsinformationen an.

Action!

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

Bedeutung

In der Ausgabe werden Informationen für die LDP-Sitzung angezeigt, die IPv6 als TCP-Transport verwendet.

Verifizierung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der LDP-Nachbarinformationen
Zweck

Zeigen Sie die LDP-Nachbarinformationen an.

Action!

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

Bedeutung

Die Ausgabe zeigt LDP-Nachbarinformationen sowohl für die IPv4- als auch für die IPv6-Adresse.

Überprüfen der LDP-Sitzungsinformationen
Zweck

Zeigen Sie die LDP-Sitzungsinformationen an.

Action!

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

Bedeutung

In der Ausgabe werden Informationen für die LDP-Sitzung angezeigt, die IPv6 als TCP-Transport verwendet.

Verifizierung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der LDP-Nachbarinformationen
Zweck

Zeigen Sie die LDP-Nachbarinformationen an.

Action!

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

Bedeutung

Die Ausgabe zeigt LDP-Nachbarinformationen sowohl für die IPv4- als auch für die IPv6-Adresse.

Überprüfen der LDP-Sitzungsinformationen
Zweck

Zeigen Sie die LDP-Sitzungsinformationen an.

Action!

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

Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalisierung für Point-to-Multipoint-LSPs

Grundlegendes zur Multipoint-LDP-Inband-Signalübertragung für Punkt-zu-Mehrpunkt-LSPs

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

Die seit Jahren am weitesten verbreitete Lösung für den Transport von Multicast-Datenverkehr ist die Verwendung von nativem IP-Multicast im Service Provider-Kern mit Multipoint-IP-Tunneling zur Isolierung des Kundendatenverkehrs. Zum Einrichten der Weiterleitungspfade wird ein Multicast-Routing-Protokoll, in der Regel Protocol Independent Multicast (PIM), bereitgestellt. Für die Weiterleitung wird IP-Multicast-Routing verwendet, wobei im Core PIM-Signale verwendet werden. Damit dieses Modell funktioniert, muss das Core-Netzwerk Multicast-fähig sein. Dies ermöglicht effektive und stabile Bereitstellungen auch in Szenarien mit interautonomen Systemen (AS).

In einem bestehenden 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 Beweggründe für die Umstellung auf MPLS-Label-Switching sind die Nutzung von MPLS-Traffic-Engineering- und Schutzfunktionen und die Reduzierung des Kontrolldatenverkehrs-Overheads im Provider-Kern.

Zu diesem Zweck sind Service Provider daran interessiert, die Erweiterung der vorhandenen Bereitstellungen zu nutzen, um Multicast-Datenverkehr durchzulassen. Bei den vorhandenen Multicast-Erweiterungen für IP/MPLS handelt es sich um 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 for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths, erläutert. Diese Funktionsübersicht beschränkt sich auf Punkt-zu-Mehrpunkt-Erweiterungen für LDP.

Funktionsweise von M-LDP

Label-Bindungen in der M-LDP-Signalübertragung

Die Multipoint-Erweiterung von LDP verwendet Point-to-Multipoint- und Multipoint-to-Multipoint-FEC-Elemente (Forwarding Equivalence Class) (definiert in RFC 5036, LDP-Spezifikation) zusammen mit Funktionsankündigungen, Bezeichnungszuordnung und Signalisierungsverfahren. Zu den FEC-Elementen gehören die Idee des LSP-Stamms, bei dem es sich um eine IP-Adresse handelt, und eines "undurchsichtigen" Werts, bei dem es sich um einen Selektor handelt, der die Blattknoten gruppiert, die denselben undurchsichtigen Wert verwenden. 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 Labelbindung an den vorgeschalteten LDP-Knoten auf dem kürzesten Pfad zur Stamm-IP-Adresse an, die in der FEC gefunden wird. Der Upstreamknoten, der die Labelbindungen empfängt, erstellt seine eigene lokale Bezeichnung und seine eigenen ausgehenden Schnittstellen. Dieser Label-Zuweisungsprozess kann zu einer Paketreplikation führen, wenn mehrere ausgehende Zweigstellen vorhanden sind. Wie in Abbildung 18gezeigt, führt ein LDP-Knoten die Beschriftungsbindungen für denselben undurchsichtigen Wert zusammen, wenn er nachgelagerte Knoten findet, die denselben Upstream-Knoten verwenden. Dies ermöglicht den effektiven Aufbau von Punkt-zu-Mehrpunkt-LSPs und die Erhaltung von Etiketten.

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

Abbildung 19 zeigt ein verkleinertes 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 auf den Border-Schnittstellen. Darüber hinaus sammeln und verteilen diese Border-Router die Routing-Informationen von den benachbarten Standorten an das Kernnetzwerk. Die Edge-Router an Standort C führen BGP für die Erkennung von Stammknoten aus. IGP-Routen (Interior Gateway Protocol) können nicht für die Eingangserkennung verwendet werden, da in den meisten Fällen der von der IGP bereitgestellte Weiterleitungs-Hop keine Informationen über das Eingangsgerät zur Quelle liefern würde. Die M-LDP-Inband-Signalübertragung weist eine Eins-zu-Eins-Zuordnung zwischen dem Punkt-zu-Mehrpunkt-LSP und dem (S,G)-Fluss auf. Mit der In-Band-Signalisierung werden PIM-Nachrichten direkt in M-LDP-FEC-Bindungen übersetzt. Im Gegensatz dazu basiert die Out-of-Band-Signalisierung auf einer manuellen Konfiguration. Eine Anwendung für M-LDP-Inband-Signale ist die Übertragung von IPTV-Multicast-Datenverkehr in einem MPLS-Backbone.

Abbildung 19: Beispiel für eine M-LDP-Topologie im PIM-freien MPLS-KernBeispiel für eine M-LDP-Topologie im PIM-freien MPLS-Kern
Konfiguration

Die Konfigurationsanweisung mldp-inband-signalling auf dem Label-Edge-Router (LER) ermöglicht es PIM, M-LDP-In-Band-Signale für die Upstream-Nachbarn zu verwenden, wenn der LER keinen PIM-Upstream-Nachbarn erkennt. Die statische Konfiguration des MPLS-LSP-Stamms ist mithilfe der Richtlinie in der PIM-Konfiguration enthalten. Dies ist erforderlich, wenn IBGP in der Core-Site nicht verfügbar ist oder um die IBGP-basierte LSP-Root-Erkennung außer Kraft zu setzen.

Zum Beispiel:

M-LDP im PIM-fähigen MPLS-Kern

Ab Junos OS Version 14.1 müssen Sie für die Migration bestehender IPTV-Services von nativem IP-Multicast zu MPLS-Multicast einen reibungslosen Übergang von PIM- zu M-LDP-Punkt-zu-Multipunkt-LSPs mit minimalem Ausfall durchführen. Abbildung 20 zeigt eine ähnliche M-LDP-Topologie wie Abbildung 19, jedoch mit einem anderen Szenario. Der Core ist mit PIM ausgestattet, wobei eine Quelle alle IPTV-Kanäle streamt. Die TV-Sender werden als ASM-Streams gesendet, wobei jeder Kanal durch seine Gruppenadresse identifiziert wird. Bisher wurden diese Kanäle als IP-Streams auf den Core gestreamt und über PIM signalisiert.

Abbildung 20: Beispiel für eine M-LDP-Topologie in einem PIM-fähigen MPLS-KernBeispiel für eine M-LDP-Topologie in einem PIM-fähigen MPLS-Kern

Durch die Konfiguration der In diesem Szenario wird die mldp-inband-signaling M-LDP-Signalisierung nur dann initiiert, wenn kein PIM-Nachbar in Richtung der Quelle vorhanden ist. Da es jedoch immer einen PIM-Nachbarn in Richtung Quelle gibt, es sei denn, PIM ist auf den Upstreamschnittstellen des Ausgangs-PE deaktiviert, hat PIM Vorrang vor M-LDP, und M-LDP wird nicht wirksam.

Konfiguration

Um Kanal für Kanal schrittweise zum M-LDP-MPLS-Core zu migrieren, mit wenigen Streams, die M-LDP Upstream verwenden, und anderen Streams, die vorhandenes PIM Upstream verwenden, fügen Sie die selected-mldp-egress Konfigurationsanweisung zusammen mit gruppenbasierten Filtern in den Richtlinienfilter für M-LDP-Inband-Signale ein.

HINWEIS:

Der M-LDP-Inband-Signalisierungsrichtlinienfilter 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. Das Konfigurieren der selected-mldp-egress Anweisung auf PIM-Routern ohne Ausgang 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 umzuschalten, ist mit Paketverlusten zu rechnen, da auf der Steuerungsebene ein Break-and-Make-Mechanismus ausgeführt wird.

Terminologie

Die folgenden Begriffe sind wichtig für das 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 Punkt-zu-Mehrpunkt- oder ein Multipunkt-zu-Mehrpunkt-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 Gruppe von Knoten verbindet, sodass der von einem beliebigen Knoten im LSP gesendete Datenverkehr an alle anderen übermittelt wird.

Ingress LSR

Ein Eingangs-LSR für einen bestimmten LSP ist ein LSR, der ein Datenpaket entlang des LSP senden kann. Multipoint-to-Multipoint-LSPs können über mehrere Eingangs-LSRs verfügen. Punkt-zu-Mehrpunkt-LSPs haben nur einen, und dieser Knoten wird oft als Stammknoten bezeichnet.
Egress LSR

Ein Ausgangs-LSR für einen bestimmten LSP ist ein LSR, der ein Datenpaket aus diesem LSP zur weiteren Verarbeitung entfernen kann. Punkt-zu-Punkt- und Multipunkt-zu-Punkt-LSPs haben nur einen einzigen Ausgangsknoten. Point-to-Multipoint- und Multipoint-to-Multipoint-LSPs können über mehrere Ausgangsknoten verfügen.
Transit LSR

Ein LSR, der über einen direkt angeschlossenen Upstream-LSR und einen oder mehrere direkt angeschlossene Downstream-LSRs bis zum Stamm des Multipoint-LSP erreichbar ist.

Bud LSR

Ein LSR, bei dem es sich um einen Ausgang handelt, der aber auch über ein oder mehrere direkt angeschlossene nachgeschaltete LSRs verfügt.
Leaf node

Entweder ein Ausgangs- oder Bud-LSR im Kontext eines Punkt-zu-Mehrpunkt-LSP. Im Kontext eines Multipoint-zu-Multipoint-LSP ist ein LSR sowohl Ein- als auch Ausgang für denselben Multipoint-to-Multipoint-LSP und kann auch ein Bud-LSR sein.

Ingress-Join-Übersetzung und Pseudo-Interface-Behandlung

Am Eingangs-LER benachrichtigt LDP PIM über die (S,G)-Nachrichten, die über die In-Band-Signalisierung empfangen werden. PIM ordnet jede (S,G)-Nachrichteiner Pseudoschnittstelle zu. Anschließend wird eine SPT-Join-Nachricht (Shortest-Path-Tree) zur Quelle initiiert. PIM behandelt dies als eine neue Art von lokalem Empfänger. Wenn der LSP abgeschaltet wird, entfernt PIM diesen lokalen Empfänger basierend auf einer Benachrichtigung von LDP.

Eindringendes Spleißen

LDP stellt PIM einen nächsten Hop zur Verfügung, der jedem Eintrag (S,G) zugeordnet wird. PIM installiert eine PIM (S,G)-Multicastroute mit dem LDP Next Hop und anderen PIM-Empfängern. Der nächste Hop ist ein zusammengesetzter nächster Hop aus lokalen Empfängern + die Liste der PIM-Downstreamnachbarn + ein nächster Hop auf Unterebene für den LDP-Tunnel.

Reverse Path Forwarding

Die RPF-Berechnung (Reverse Path-Forwarding) von PIM wird am Ausgangsknoten durchgeführt.

PIM führt M-LDP-In-Band-Signale durch, wenn alle der folgenden Bedingungen erfüllt sind:

  • Es gibt keine PIM-Nachbarn in Richtung der Quelle.

  • Die In-Band-Signalanweisung M-LDP ist konfiguriert.

  • Der nächste Hop wird über BGP erlernt oder ist in der statischen Zuordnung vorhanden (angegeben in einer M-LDP-In-Band-Signalisierungsrichtlinie).

Andernfalls, wenn die LSP-Stammerkennung fehlschlägt, behält PIM den Eintrag (S,G) mit dem RPF-Status "Nicht aufgelöst" bei.

PIM RPF registriert diese Quelladresse jedes Mal, wenn sich Unicast-Routing-Informationen ändern. Wenn sich also die Route zur Quelle ändert, wird die RPF-Neuberechnung wiederholt. Die nächsten Hops des BGP-Protokolls zur Quelle werden ebenfalls auf Änderungen im LSP-Stamm überwacht. Solche Änderungen können zu kurzzeitigen Verkehrsbehinderungen führen.

LSP-Root-Erkennung

Wenn der RPF-Vorgang die Notwendigkeit einer M-LDP-In-Band-Signalübertragung im Upstream erkennt, wird der LSP-Stamm (Eingang) erkannt. Dieser Stamm ist ein Parameter für den LDP-LSP-Signalweg.

Der Stammknoten wird wie folgt erkannt:

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

  2. Eine Suche wird in der Unicast-Routingtabelle durchgeführt. Wenn die Quelladresse gefunden wird, wird der nächste Hop des Protokolls zur Quelle als LSP-Stamm verwendet.

    Vor Junos OS Version 16.1 wird M-LDP-Punkt-zu-Multipunkt-LSP von einem Ausgang zum Eingang mithilfe der Stammadresse des Eingangs-LSR signalisiert. Diese Root-Adresse ist nur über IGP erreichbar, wodurch der M-LDP-Punkt-zu-Mehrpunkt-LSP auf ein einziges autonomes System beschränkt ist. Wenn die Root-Adresse nicht über ein IGP, sondern über BGP erreichbar ist und diese BGP-Route rekursiv über einen MPLS-LSP aufgelöst wird, wird der Punkt-zu-Multipoint-LSP nicht weiter von diesem Punkt in Richtung der Eingangs-LSR-Root-Adresse signalisiert.

    Es besteht die Notwendigkeit, dass diese nicht segmentierten Punkt-zu-Mehrpunkt-LSPs über mehrere autonome Systeme hinweg signalisiert werden, die für die folgenden Anwendungen verwendet werden können:

    • Inter-AS MVPN mit nicht segmentierten Punkt-zu-Mehrpunkt-LSPs.

    • In-Band-Signalübertragung zwischen Client-Netzwerken, die über ein MPLS-Kernnetzwerk verbunden sind.

    • Inter-Area-MVPN- oder M-LDP-In-Band-Signalübertragung mit nicht segmentierten Punkt-zu-Mehrpunkt-LSPs (nahtloser MPLS-Multicast).

    Ab Junos OS Version 16.1 kann M-LDP Punkt-zu-Mehrpunkt-LSPs bei ASBR oder Transit oder Ausgang signalisieren, wenn die Root-Adresse eine BGP-Route ist, die weiter rekursiv über eine MPLS-LSP aufgelöst wird.

Übersetzung von Ausgangsjoins und Handhabung von Pseudoschnittstellen

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

Ausgangs-Spleißen

Am Ausgangsknoten des Kernnetzwerks, 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 ein LSP-Teardown auf, wenn der Eintrag (S,G) verloren geht, wenn sich der LSP-Stamm ändert oder wenn der Eintrag (S,G) über einen PIM-Nachbarn erreichbar ist.

Unterstützte Funktionen

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

  • Ausgangs-Spleißen des nächsten PIM-Hops mit der LDP-Route

  • Eingangs-Spleißen der PIM-Route mit dem nächsten LDP-Hop

  • Übersetzung von PIM-Join-Meldungen in LDP-Punkt-zu-Multipoint-LSP-Setup-Parameter

  • Übersetzung von M-LDP-In-Band-LSP-Parametern zum Einrichten von PIM-Join-Meldungen

  • Statisch konfigurierte und auf dem BGP-Protokoll basierende Next-Hop-basierte LSP-Root-Erkennung

  • PIM (S,G)-Status in den Bereichen PIM Source-Specific Multicast (SSM) und Anysource Multicsast (ASM)

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

  • IGMP-Join-Meldungen auf LERs

  • Übertragung der IPv6-Quell- und -Gruppenadresse als undurchsichtige Information an einen IPv4-Stammknoten

  • Statische Konfiguration zur Zuordnung einer IPv6 (S,G) zu einer IPv4-Stammadresse

Nicht unterstützte Funktionen

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

  • Volle Unterstützung für PIM ASM

  • Der mpls lsp point-to-multipoint ping Befehl mit der Option (S,G)

  • Nonstop Active Routing (NSR)

  • Make-before-break (MBB) für PIM

  • IPv6-LSP-Stammadressen (LDP unterstützt keine IPv6-LSPs.)

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

  • Graceful-Restart

  • PIM-Dense-Modus

  • Bidirektionaler PIM-Modus

LDP-Funktionalität

Die PIM (S,G)-Informationen werden als M-LDP-TLV-Kodierungen (Opaque Type-Length-Value) übertragen. Das Punkt-zu-Mehrpunkt-FEC-Element besteht aus der Adresse des Stammknotens. Bei Multicast-VPNs der nächsten Generation (NGEN MVPNs) wird der Punkt-zu-Multipunkt-LSP anhand der Adresse des Root-Knotens und der LSP-ID identifiziert.

Ausgangs-LER-Funktionalität

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

  • Wurzelknoten

  • (S,G)

  • Nächster Hop

PIM findet den Stammknoten basierend auf der Quelle der Multicast-Struktur. Wenn die Stammadresse für diesen Eintrag (S,G) konfiguriert ist, wird die konfigurierte Adresse als Punkt-zu-Mehrpunkt-LSP-Stamm verwendet. Andernfalls wird die Routing-Tabelle verwendet, um die Route zur Quelle nachzuschlagen. Wenn es sich bei der Route zur Quelle der Multicaststruktur um eine BGP-gelernte Route handelt, ruft PIM die BGP-Adresse des nächsten Hops ab und verwendet sie als Stammknoten für den Punkt-zu-Mehrpunkt-LSP.

LDP sucht den Upstream-Knoten basierend auf dem Stammknoten, weist eine Bezeichnung zu und sendet die Label-Zuordnung an den Upstream-Knoten. LDP verwendet kein vorletztes Hop-Popping (PHP) für In-Band-M-LDP-Signale.

Wenn sich die Stammadressen für die Quelle der Multicaststruktur ändern, löscht PIM den Punkt-zu-Mehrpunkt-LSP und löst LDP aus, um einen neuen Punkt-zu-Mehrpunkt-LSP zu erstellen. In diesem Fall wird die Liste der ausgehenden Schnittstellen zu NULL, PIM löst LDP aus, um den Punkt-zu-Mehrpunkt-LSP zu löschen, und LDP sendet eine Meldung zum Zurückziehen der Bezeichnung an den Upstreamknoten.

Transit LSR-Funktionalität

Der Transit-LSR kündigt dem Upstream-LSR eine Bezeichnung in Richtung Quelle des Punkt-zu-Mehrpunkt-FEC an und installiert den erforderlichen Weiterleitungsstatus, um die Pakete weiterzuleiten. Der Transit-LSR kann ein beliebiger M-LDP-fähiger Router sein.

Ingress LER-Funktionalität

Auf dem Eingangs-LER stellt LDP PIM nach Erhalt der Labelzuordnung die folgenden Informationen zur Verfügung:

  • (S,G)

  • Nächster Hop überfluten

Anschließend installiert PIM den Weiterleitungsstatus. Wenn die neuen Branches hinzugefügt oder gelöscht werden, wird der nächste Flood-Hop entsprechend aktualisiert. Wenn alle Verzweigungen gelöscht werden, weil eine Bezeichnung zurückgezogen wurde, sendet LDP aktualisierte Informationen an PIM. Wenn mehrere Verbindungen zwischen den Upstream- und Downstream-Nachbarn vorhanden sind, wird für den Punkt-zu-Mehrpunkt-LSP kein Lastenausgleich durchgeführt.

Siehe auch

Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalisierung für Point-to-Multipoint-LSPs

In diesem Beispiel wird gezeigt, wie die In-Band-Signalisierung Multipoint LDP (M-LDP) für Multicastdatenverkehr, als Erweiterung des PIM-Protokolls (Protocol Independent Multicast) 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 die Provider-Edge-Router (PE)

  • Paketübertragungs-Router der PTX-Serie, die als Transit-Label-Switched-Router fungieren

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

HINWEIS:

Bei den PE-Routern kann es sich auch um Core-Router der T-Serie handeln, aber das ist nicht typisch. Abhängig von Ihren Skalierungsanforderungen kann es sich bei den Core-Routern auch um universelle 5G-Routing-Plattformen der MX-Serie oder Multiservice-Edge-Router der M-Serie handeln. Bei den Customer Edge (CE)-Geräten 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 21an. In diesem Abschnitt #d363e66__d363e834 werden die Schritte zu Device EgressPE beschrieben.

Abbildung 21: M-LDP-In-Band-Signalübertragung für Punkt-zu-Mehrpunkt-LSPs BeispieltopologieM-LDP-In-Band-Signalübertragung für Punkt-zu-Mehrpunkt-LSPs Beispieltopologie

Konfiguration

Verfahren
CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] ein.

Gerät src1

Geräte-IngressPE

GeräteausgangPE

Gerät p6

Gerät pr3

Gerät pr4

Gerät pr5

Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.

So konfigurieren Sie Device EgressPE:

  1. Konfigurieren Sie die Schnittstellen.

    Aktivieren Sie MPLS auf den Core-Schnittstellen. Auf den nächsten Hops des Ausgangs müssen Sie MPLS nicht aktivieren.

  2. Konfigurieren Sie IGMP auf den Ausgangsschnittstellen.

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

  3. Konfigurieren Sie MPLS auf den Core-Schnittstellen.

  4. Konfigurieren Sie BGP.

    BGP ist ein richtliniengesteuertes Protokoll, daher sollten Sie auch alle erforderlichen Routing-Richtlinien konfigurieren und anwenden.

    Sie können z. B. statische Routen in BGP exportieren.

  5. (Optional) Konfigurieren Sie eine MSDP-Peerverbindung mit Gerät 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-zugewandten Schnittstellen und auf der Loopback-Schnittstelle.

  8. Aktivieren Sie Punkt-zu-Mehrpunkt-MPLS-LSPs.

  9. Konfigurieren Sie PIM auf den nachgeschalteten Schnittstellen.

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

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

  12. Konfigurieren Sie die Routingrichtlinie, die die Stammadresse für den Punkt-zu-Mehrpunkt-LSP und die zugehörigen Quelladressen angibt.

  13. Konfigurieren Sie die ID des autonomen Systems (AS).

Ergebnisse

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

GeräteausgangPE

Konfigurieren Sie auf ähnliche Weise die anderen Ausgangsgeräte.

Wenn Sie mit der Konfiguration der Geräte fertig sind, rufen Sie den Konfigurationsmodus auf commit .

Verifizierung

Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.

Überprüfen der PIM-Verknüpfungszustände
Zweck

Zeigen Sie Informationen zu PIM-Verknüpfungszuständen an, um die M-LDP-In-Band-Upstream- und Downstream-Details zu überprüfen. Auf dem Eingangsgerät wird der show pim join extensive Befehl für die Downstreamschnittstelle angezeigt Pseudo-MLDP . Auf dem Ausgang wird der show pim join extensive Befehl für die Upstreamschnittstelle angezeigt Pseudo-MLDP .

Action!

Geben Sie im Betriebsmodus den show pim join extensive Befehl ein.

Überprüfen der PIM-Quellen
Zweck

Stellen Sie sicher, dass die PIM-Quellen über die erwarteten M-LDP-In-Band-Upstream- und Downstream-Details verfügen.

Action!

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.

Action!
Nachschlagen der Routeninformationen für die MPLS-Beschriftung
Zweck

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

Action!
Überprüfen der LDP-Datenverkehrsstatistik
Zweck

Überwachen Sie die Datenverkehrsstatistiken für den Punkt-zu-Mehrpunkt-LSP.

Action!

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

Die Unterstützung von Segment-Routing-Zuordnungsservern und -Clients ermöglicht die Interoperabilität zwischen Netzwerkinseln, auf denen LDP ausgeführt wird, und Segment-Routing (SR oder SPRING). Diese Interoperabilität ist bei der 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 zusammenarbeiten können, sind die Funktionen LDP Segment Routing Mapping Server (SRMS) und Segment Routing Mapping Client (SRMC) erforderlich. Sie aktivieren diese Server- und Clientfunktionen auf einem Gerät im Segment-Routing-Netzwerk.

Die SR-Zuordnungsserver- und -Clientfunktionalität wird entweder mit OSPF oder ISIS unterstützt.

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

Abbildung 22 zeigt eine einfache LDP-Netzwerktopologie, um zu veranschaulichen, wie die Interoperabilität von Segment-Routing-Geräten mit LDP-Geräten funktioniert. Denken Sie daran, dass sowohl OSPF als auch ISIS unterstützt werden, daher bleiben wir in Bezug auf die IGP vorerst agnostisch. Die Beispieltopologie umfasst sechs Geräte (R1 bis R6) in einem Netzwerk, das von LDP auf Segment-Routing migriert wird.

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 Legacy-LDP-Domäne und unterstützen SR derzeit nicht. Das 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. Interoperabilität basiert auf der Zuordnung eines LDP-FEC zu einer SR-Knoten-ID und umgekehrt.

Abbildung 22: Beispiel für Segment-Routing zur LDP-InteroperabilitätstopologieBeispiel für Segment-Routing zur 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, wenn man den Datenverkehrsfluss in eine unidirektionale Weise betrachtet. Basierend auf Abbildung 22sagen wir, dass der Datenverkehr, der von links nach rechts fließt, in der SR-Domäne beginnt und in der LDP-Domäne endet. In gleicher Weise beginnt der Datenverkehr, der von rechts nach links fließt, in der LDP-Domäne und endet in der SR-Domäne.

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

  • Von links nach rechts Verkehrsfluss: Der Segment-Routing-Zuordnungsserver

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

    Sie wenden die SRMS-Zuordnungskonfiguration auf der [edit protocols ospf] Hierarchieebene "oder [edit protocols isis] " an. Diese Auswahl hängt davon ab, welche IGP verwendet wird. Beachten Sie, dass sich sowohl der SR- als auch der LDP-Knoten eine gemeinsame IGP-Routing-Domäne auf einer einzigen Bereichs-/Ebene teilen.

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

    Die erweiterte LSA (oder LSP) wird im gesamten (einzelnen) IGP-Bereich geflutet. Das bedeutet, dass Sie die SRMS-Konfiguration auf jedem Router in der SR-Domäne platzieren können. Auf dem SRMS-Knoten muss LDP nicht ausgeführt werden.

  • Verkehrsfluss von rechts nach links: Der Segment-Routing-Mapping-Client

    Um von rechts nach links zu interagieren, d. h. von der LDP-Insel zur SR-Insel, aktivieren Sie einfach die Client-Funktionalität für die Segmentrouting-Routingzuordnung auf einem Knoten, der sowohl SR als auch LDP spricht. In unserem Beispiel ist das R4. Die SRMC-Funktionalität aktivieren Sie mit der mapping-client Anweisung in der Hierarchie [edit protocols ldp] .

    Die SRMC-Konfiguration aktiviert automatisch eine LDP-Ausgangsrichtlinie, um den Knoten der SR-Domäne anzukündigen und SIDs als LDP-Ausgangs-FECs zu präfixieren. Dadurch sind die LDP-Knoten mit LSP-Erreichbarkeit für die Knoten in der SR-Domäne erreichbar.

  • Die SRMC-Funktion muss auf einem Router konfiguriert werden, der sowohl mit der SR- als auch mit der LSP-Domäne verbunden ist. Auf Wunsch kann derselbe Knoten auch als SRMS fungieren.

Interoperabilität zwischen Segment-Routing und LDP mithilfe von OSPF

Angenommen Abbildung 22, dvice R2 (im Segment-Routing-Netzwerk) ist das SRMS.

  1. Definieren Sie die SRMS-Funktion:

    Durch diese Konfiguration wird ein Zuordnungsblock für die beiden LDP-Geräte-Loopbackadressen in der Beispieltopologie erstellt. Der anfängliche Segment-ID-Index (SID), der dem Loopback von R5 zugeordnet ist, lautet 1000. Die Angabe der Größe 2 führt dazu, dass der SID-Index 10001 der Loopback-Adresse von R6 zugeordnet wird.

    HINWEIS:

    Die verwendete start-prefix 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 der SR-Domäne zuordnen. Wenn die Loopbackadressen zusammenhängen, 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 eine einzelne prefix-segment-range angezeigt wird. Im Folgenden finden Sie ein Beispiel für mehrere Zuordnungen, um den Fall von zwei LDP-Knoten mit nicht zusammenhängender Loopback-Adressierung zu unterstützen:

  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 Konfiguration des Zuordnungsservers auf Gerät R2 festgeschrieben wurde, wird der TLV für den erweiterten Präfixbereich über den OSPF-Bereich geflutet. Die Geräte, die Segment-Routing unterstützen (R1, R2 und R3), installieren OSPF-Segment-Routing-Routen für die angegebene Loopback-Adresse (in diesem Beispiel R5 und R6) mit einem Segment-ID-Index (SID). 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 Konfiguration des Zuordnungsclients auf Gerät R4 festgeschrieben wurde, werden die SR-Knoten-IDs und Label-Blöcke als Ausgangs-FECs an Router R5 angekündigt, der sie dann erneut an R6 ankündigt.

Die Unterstützung für Stitching-Segment-Routing und LDP-Next-Hops mit OSPF wurde in Junos OS 19.1R1 eingeführt.

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

  • Präfixkonflikte werden nur am SRMSerkannt. Wenn ein Präfixbereichskonflikt vorliegt, hat die Präfix-SID der niedrigeren Router-ID Vorrang. In solchen Fällen wird eine Systemprotokollfehlermeldung generiertRPD_OSPF_PFX_SID_RANGE_CONFLICT.

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

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

  • Die Funktionalität des bereichsübergreifenden LDP-Zuordnungsservers wird nicht unterstützt.

  • Die ABR-Funktionalität von Extended Prefix Opaque LSA wird nicht unterstützt.

  • Die ASBR-Funktionalität von Extended Prefix Opaque LSA wird nicht unterstützt.

  • Die Präferenz TLV des Segment-Routing-Mapping-Servers wird nicht unterstützt.

Interoperabilität des Segment-Routings mit LDP unter Verwendung von ISIS

Siehe Abbildung 22, nehmen wir an, dass das Gerät R2 (im Segment-Routing-Netzwerk) das SRMS ist. Für die Mapping-Funktion wird folgende Konfiguration hinzugefügt:

  1. Definieren Sie die SRMS-Funktion:

    Durch diese Konfiguration wird ein Zuordnungsblock für die beiden LDP-Geräte-Loopbackadressen in der Beispieltopologie erstellt. Der anfängliche Segment-ID-Index (SID), der dem Loopback von R5 zugeordnet ist, lautet 1000. Die Angabe der Größe 2 führt dazu, dass der SID-Index 10001 der Loopback-Adresse von R6 zugeordnet wird.

    HINWEIS:

    Die verwendete start-prefix 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 Loopbackadressen zusammenhängen, 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 eine einzelne prefix-segment-range angezeigt wird. Im Folgenden finden Sie ein Beispiel für Präfixzuordnungen, um den Fall von zwei LDP-Routern mit nicht zusammenhängender Loopback-Adressierung zu behandeln:

  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 Konfiguration des Zuordnungsservers auf Gerät R2 festgeschrieben wurde, wird der TLV für den erweiterten Präfixbereich über den OSPF-Bereich geflutet. Die Geräte, die Segment-Routing unterstützen (R1, R2 und R3), installieren ISIS-Segment-Routing-Routen für die angegebene Loopback-Adresse (in diesem Beispiel R5 und R6) mit einem Segment-ID-Index (SID). 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 Konfiguration des Zuordnungsclients auf Gerät R4 festgeschrieben wurde, werden die SR-Knoten-IDs und Label-Blöcke als Ausgangs-FECs an Router R5 und von dort weiter an R6 angekündigt.

Die Unterstützung für Stitching-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 Popping-Verhalten des vorletzten Hops für Labelbindungs-TLV wird nicht unterstützt.

  • Die Ankündigung eines Präfixbereichs in TLV für die Etikettenbindung wird nicht unterstützt.

  • Die Konfliktlösung beim 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-Präfixattribute für erweiterte IPv4 wird nicht unterstützt.

  • Das erneute Verteilen der LDP-Route als Präfix-Sid am Stitching-Knoten wird nicht unterstützt.

Verschiedene LDP-Eigenschaften

In den folgenden Abschnitten wird beschrieben, wie Sie eine Reihe verschiedener LDP-Eigenschaften konfigurieren.

Konfigurieren von LDP für die Verwendung der IGP-Routenmetrik

Verwenden Sie die track-igp-metric Anweisung, wenn die IGP-Routenmetrik (Interior Gateway Protocol) für die LDP-Routen anstelle der standardmäßigen LDP-Routenmetrik verwendet werden soll (die standardmäßige LDP-Routenmetrik ist 1).

Um die IGP-Routenmetrik zu verwenden, fügen Sie die track-igp-metric folgende Anweisung ein:

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

Verhindern des Hinzufügens von Eingangsrouten zur inet.0-Routing-Tabelle

Durch Konfigurieren der no-forwarding Anweisung können Sie verhindern, dass Eingangsrouten der Routingtabelle inet.0 anstelle der Routingtabelle inet.3 hinzugefügt werden, selbst wenn Sie die traffic-engineering bgp-igp Anweisung auf der [edit protocols mpls] oder der [edit logical-systems logical-system-name protocols mpls] Hierarchieebene aktiviert haben. Standardmäßig ist die no-forwarding Anweisung deaktiviert.

HINWEIS:

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

Um Eingangsrouten aus der inet.0-Routingtabelle auszuschließen, fügen Sie die no-forwarding folgende Anweisung ein:

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

LDP- und Carrier-of-Carrier-VPNs mit mehreren Instanzen

Durch die Konfiguration mehrerer LDP-Routing-Instanzen können Sie LDP verwenden, um Labels 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 Netzbetreiberkunde ein grundlegender Internetdienstanbieter (ISP) ist und vollständige Internetrouten auf seine PE-Router beschränken möchte. Durch die Verwendung von LDP anstelle von BGP schirmt der Netzbetreiberkunde seine anderen internen Router vom Internet ab. LDP mit mehreren Instanzen ist auch nützlich, wenn ein Netzbetreiberkunde 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-Carriers-VPNs finden Sie im Benutzerhandbuch für das Label Distribution Protocol.

Konfigurieren Sie MPLS und LDP so, dass die Bezeichnung auf dem Ultimate-Hop-Router angezeigt wird.

Die standardmäßig angekündigte Bezeichnung ist Label 3 (Implizite Null-Bezeichnung). Wenn Label 3 angekündigt wird, entfernt der Router des vorletzten Hops 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 durchqueren, ein Label enthalten.

Um Ultimate-Hop-Popping zu konfigurieren, fügen Sie die explicit-null folgende Anweisung ein:

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

HINWEIS:

Router von Juniper Networks stellen Pakete basierend auf dem eingehenden Label in die Warteschlange. Router anderer Anbieter stellen Pakete möglicherweise anders in die Warteschlange. Beachten Sie dies, wenn Sie mit Netzwerken arbeiten, die Router von mehreren Anbietern enthalten.

Weitere Informationen zu Beschriftungen finden Sie unter MPLS-Beschriftungsübersicht und MPLS-Beschriftungszuweisung.

Aktivieren von LDP über RSVP-etablierte LSPs

Sie können LDP über LSPs ausführen, die von RSVP eingerichtet wurden, wodurch der LDP-etablierte LSP effektiv durch den von RSVP eingerichteten getunnelt wird. Aktivieren Sie dazu LDP auf der lo0.0-Schnittstelle (siehe Aktivieren und Deaktivieren von LDP). Sie müssen auch die LSPs konfigurieren, für die LDP ausgeführt werden soll, indem Sie die ldp-tunneling Anweisung auf Hierarchieebene [edit protocols mpls label-switched-path lsp-name] einschließen:

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

HINWEIS:

LDP kann über eine RSVP-Sitzung getunnelt werden, für die der Link-Schutz aktiviert ist. Ab Junos OS Release 21.1R1werden bei der Anzeige von Details zur LDP-Tunnelroute sowohl der primäre als auch der Bypass-LSP-Next-Hop angezeigt. In früheren Junos OS-Versionenzeigte die Umgehung des LSP-nächsten Hops den nächsten Hop für den primären LSP an.

Aktivieren von LDP über RSVP-etablierte Sprachdienstleister 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 manuell konfigurieren, wenn Sie LDP-Tunneling über RSVP-LSPs in heterogenen Netzwerken bereitstellen.

Wenn ein Router von Juniper Networks über einen RSVP-Tunnel mit dem Router eines anderen Anbieters verbunden ist und LDP-Tunneling ebenfalls aktiviert ist, verwendet der Router von Juniper Networks standardmäßig nicht den RSVP-Tunnel, um den Datenverkehr an die LDP-Ziele weiterzuleiten, die dem Ausgangsrouter des anderen Anbieters nachgeschaltet sind, wenn der RSVP-Pfad eine Metrik von 1 aufweist, die 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 folgende Anweisung einfügen:

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 noch das Verfahren in Abschnitt Aktivieren von LDP über RSVP-etablierte LSPsausführen.

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 gefälschter TCP-Segmente 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-Hello-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 HMAC (Hashed Message Authentication Code) und MD5-Authentifizierung für LDP-Sitzungen als Konfiguration pro Sitzung oder als Subnetzübereinstimmung (d. h. längste Präfixübereinstimmung) konfigurieren. Die Unterstützung für die Authentifizierung mit Subnetzübereinstimmung bietet Flexibilität bei der Konfiguration der Authentifizierung für automatisch ausgerichtete LDP-Sitzungen (TLDP). Dies erleichtert den Einsatz von LFA- (Remote Loop-Free Alternate) und FEC 129-Pseudodrähten.

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-keyoder Kennwort in der Konfiguration kann bis zu 69 Zeichen lang sein. Zeichen können beliebige ASCII-Zeichenfolgen enthalten. Wenn Sie Leerzeichen einfügen, schließen Sie alle Zeichen in Anführungszeichen ein.

Sie können auch einen Mechanismus zur Aktualisierung des Authentifizierungsschlüssels für das LDP-Routingprotokoll konfigurieren. Mit diesem Mechanismus können Sie Authentifizierungsschlüssel aktualisieren, ohne die zugehörigen Routing- und Signalisierungsprotokolle wieOSPF(Open Shortest Path First) undRSVP(Resource Reservation Setup Protocol) zu unterbrechen.

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

Um den Aktualisierungsmechanismus für den Authentifizierungsschlüssel für das LDP-Routingprotokoll zu konfigurieren, fügen Sie die authentication-key-chain Anweisung auf Hierarchieebene [edit protocols ldp] ein, um das Protokoll den [edit security suthentication-key-chains] Authentifizierungsschlüsseln zuzuordnen. Sie müssen auch den Authentifizierungsalgorithmus konfigurieren, indem Sie die authentication-algorithm algorithm Anweisung in die [edit protocols ldp] Hierarchieebene einschließen.

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

Konfigurieren des LDP-Sitzungsschutzes

Eine LDP-Sitzung wird normalerweise zwischen einem Paar von Routern erstellt, die über eine oder mehrere Verbindungen verbunden sind. Die Router bilden eine Hello-Nachbarschaft für jede Verbindung, die sie verbindet, und ordnen alle Nachbarschaften der entsprechenden LDP-Sitzung zu. Wenn die letzte Hello-Nachbarschaft für eine LDP-Sitzung verschwindet, wird die LDP-Sitzung beendet. Sie können dieses Verhalten ändern, um zu verhindern, dass eine LDP-Sitzung unnötigerweise beendet und wiederhergestellt wird.

Sie können das Junos-Betriebssystem so konfigurieren, dass die LDP-Sitzung zwischen zwei Routern auch dann aktiv bleibt, wenn auf den Links, die die beiden Router verbinden, keine Hello-Nachbarschaften vorhanden sind, indem Sie die session-protection Anweisung konfigurieren. Mit dieser timeout Option können Sie optional eine Zeit in Sekunden angeben. Die Sitzung bleibt für die angegebene Dauer aktiv, solange die Router die IP-Netzwerkverbindung aufrechterhalten.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einbinden können, finden Sie im Abschnitt Anweisungszusammenfassung.

Deaktivieren von SNMP-Traps für LDP

Jedes Mal, wenn ein LDP-LSP einen Übergang von oben nach unten oder von unten nach oben macht, sendet der Router einen SNMP-Trap. Es ist jedoch möglich, die LDP-SNMP-Traps auf einem Router, einem logischen System oder einer Routing-Instanz zu deaktivieren.

Weitere 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 Anweisungszusammenfassung für diese Anweisung.

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

LDP ist ein Protokoll zum Verteilen von Etiketten in Anwendungen, die nicht für den Datenverkehr ausgelegt sind. Die Etiketten werden entlang des besten Pfades verteilt, der von der IGP bestimmt wird. Wenn die Synchronisierung zwischen LDP und IGP nicht aufrechterhalten wird, fällt der LSP aus. Wenn LDP auf einer bestimmten Verbindung nicht voll funktionsfähig ist (eine Sitzung wird nicht aufgebaut und Labels werden nicht ausgetauscht), bewirbt die IGP die Verbindung mit der Metrik für maximale Kosten. Die Verbindung wird nicht bevorzugt, sondern verbleibt 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 des ordnungsgemäßen Neustarts nicht unterstützt.

Fügen Sie die folgende Anweisung ein, um die Metrik für die maximalen Kosten anzukündigen, bis LDP für die ldp-synchronization Synchronisierung betriebsbereit ist:

Um die Synchronisierung zu deaktivieren, schließen Sie die disable Anweisung ein. Fügen Sie die Anweisung ein, um den Zeitraum für die Ankündigung der Metrik für die maximalen Kosten für einen Link zu konfigurieren, der hold-time nicht vollständig funktionsfähig ist.

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

Konfigurieren der LDP-Synchronisierung mit der IGP auf dem Router

Sie können die Zeit konfigurieren, die der LDP wartet, bevor er die IGP darüber informiert, dass der LDP-Nachbar und die Sitzung für eine Schnittstelle betriebsbereit sind. Bei großen Netzwerken mit zahlreichen FECs müssen Sie möglicherweise einen längeren Wert konfigurieren, damit genügend Zeit für den Austausch der LDP-Bezeichnungsdatenbanken bleibt.

Um die Zeit zu konfigurieren, die der LDP wartet, bevor er den IGP darüber informiert, dass der LDP-Nachbar und die Sitzung betriebsbereit sind, fügen Sie die igp-synchronization Anweisung ein und geben Sie eine Zeit in Sekunden für die holddown-interval Option an:

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

Konfigurieren des Timers für die Etikettenentnahme

Der Timer für das Zurückziehen von Etiketten verzögert das Senden einer Nachricht zum Zurückziehen von Etiketten für eine FEC an einen Nachbarn. Wenn eine IGP-Verbindung zu einem Nachbarn fehlschlägt, muss das der FEC zugeordnete Label von allen Upstream-Routern entfernt werden, wenn der Nachbar der nächste Hop für die FEC ist. Nachdem die IGP konvergiert ist und ein Label von einem neuen nächsten Hop empfangen wurde, wird das Label für alle Upstream-Router erneut angekündigt. Dies ist das typische Netzwerkverhalten. Durch eine Verzögerung des Label-Entfernens um eine kleine Zeitspanne (z. B. bis die IGP konvergiert und der Router ein neues Label für die FEC vom Downstream-nächsten Hop erhält) könnte der Label-Rückzug und das baldige Senden einer Label-Zuordnung vermieden werden. Mit dieser label-withdrawal-delay 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 abläuft, wird der Timer für das Zurückziehen des Labels abgebrochen. Wenn der Timer jedoch abläuft, wird die Bezeichnung für die FEC von allen Upstream-Routern zurückgezogen.

Standardmäßig wartet LDP 60 Sekunden, bevor es Labels zurückzieht, um zu vermeiden, dass LSPs mehrmals neu signalisiert werden, während der IGP rekonvergiert. Um die Verzögerungszeit für das Zurückziehen des Etiketts in Sekunden zu konfigurieren, fügen Sie die label-withdrawal-delay folgende Anweisung ein:

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

Ignorieren der LDP-Subnetzprüfung

In Junos OS Version 8.4 und höheren Versionen wird während der Nachbarschaftseinrichtung eine LDP-Quelladress-Subnetzprüfung durchgeführt. Die Quelladresse im LDP-Link-Hello-Paket wird mit der Schnittstellenadresse abgeglichen. Dies führt zu einem Interoperabilitätsproblem mit den Geräten einiger anderer Anbieter.

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

Diese Anweisung kann auf den folgenden Hierarchieebenen enthalten sein:

  • [edit protocols ldp interface interface-name]

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

HINWEIS:

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

Siehe auch

Konfigurieren von LDP LSP Traceroute

Sie können die Route verfolgen, der ein LDP-signalisierter LSP folgt. LDP LSP-Traceroute basiert auf RFC 4379 ( Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. 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 Ablaufverfolgung eines LDP-LSP aus. Sie können eine Traceroute jedoch manuell initiieren. Wenn die Traceroute-Anforderung für einen FEC gilt, der sich derzeit in der Datenbank befindet, wird der Inhalt der Datenbank mit den Ergebnissen aktualisiert.

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

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

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

Sie können die periodic-traceroute Anweisung einzeln oder mit einer der folgenden Optionen konfigurieren:

  • exp– Geben Sie die Serviceklasse an, die beim Senden von Sonden verwendet werden soll.

  • fanout: Geben Sie die maximale Anzahl der nächsten Hops an, die pro Knoten durchsucht werden sollen.

  • frequency– Geben Sie das Intervall zwischen den Traceroute-Versuchen an.

  • paths: Geben Sie die maximale Anzahl von Pfaden an, die durchsucht werden sollen.

  • retries: Geben Sie die Anzahl der Versuche an, eine Sondierung an einen bestimmten Knoten zu senden, bevor aufgegeben wird.

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

  • ttl: Geben Sie den maximalen Wert für die Gültigkeitsdauer an. Knoten, die über diesem Wert liegen, werden nicht verfolgt.

  • wait– Geben Sie das Warteintervall an, bevor ein Testpaket erneut gesendet wird.

Sammeln von LDP-Statistiken

LDP-Datenverkehrsstatistiken zeigen das Datenverkehrsvolumen an, 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 regelmäßig erfasst und in eine Datei geschrieben. Sie können konfigurieren, wie oft Statistiken gesammelt werden (in Sekunden), indem Sie die interval Option verwenden. Das standardmäßige Erfassungsintervall beträgt 5 Minuten. Sie müssen eine LDP-Statistikdatei konfigurieren. Andernfalls werden keine LDP-Datenverkehrsstatistiken erfasst. Wenn der LSP ausfällt, werden die LDP-Statistiken zurückgesetzt.

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

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung 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 erfasst werden.

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

  • Packets- Anzahl der Pakete, die von der FEC seit der Einrichtung des LSP übergeben wurden.

  • Bytes– Anzahl der Bytes an Daten, die von der FEC seit der Einrichtung des LSP übergeben wurden.

  • Shared– Ein Yes Wert gibt an, dass mehrere Präfixe an dieselbe Bezeichnung 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 angezeigt wird) kann von der tatsächlichen Zahl der angezeigten Statistiken abweichen. Einige der Statistiken werden zusammengefasst, bevor sie angezeigt werden.

Deaktivieren der LDP-Statistik auf dem Penultimate-Hop-Router

Das Sammeln von LDP-Datenverkehrsstatistiken am Router des vorletzten Hops kann übermäßig viele Systemressourcen beanspruchen, insbesondere auf Routen des nächsten Hops. Dieses Problem wird noch verschärft, wenn Sie die deaggregate Anweisung zusätzlich zur traffic-statistics Anweisung konfiguriert haben. Für Router, die ihr Limit für die Nutzung der Next-Hop-Route erreichen, empfehlen wir, die no-penultimate-hop Option für die traffic-statistics folgende Anweisung zu konfigurieren:

Eine Liste der Hierarchieebenen, auf denen Sie die traffic-statistics Anweisung konfigurieren können, finden Sie im Abschnitt Anweisungszusammenfassung zu dieser Anweisung.

HINWEIS:

Wenn Sie die no-penultimate-hop Option konfigurieren, sind keine Statistiken für die FECs verfügbar, die den vorletzten Hop für diesen Router darstellen.

Wenn Sie diese Option in die Konfiguration aufnehmen oder daraus entfernen, werden die LDP-Sitzungen heruntergefahren und dann neu gestartet.

Die folgende Beispielausgabe stammt aus einer LDP-Statistikdatei, in der Router aufgeführt sind, auf denen die no-penultimate-hop Option konfiguriert ist:

Einschränkungen der LDP-Statistik

Im Folgenden finden Sie Probleme im Zusammenhang mit dem Sammeln von LDP-Statistiken durch Konfigurieren der traffic-statistics Anweisung:

  • Sie können die LDP-Statistiken nicht löschen.

  • Wenn Sie das angegebene Intervall verkürzen, wird nur dann eine neue LDP-Statistikanforderung ausgegeben, wenn der Statistiktimer später als das neue Intervall abläuft.

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

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

Ablaufverfolgung des Datenverkehrs im LDP-Protokoll

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

Ablaufverfolgung des LDP-Protokolldatenverkehrs auf Protokoll- und Routing-Instanzebene

Um den Datenverkehr des LDP-Protokolls zu verfolgen, können Sie Optionen in der globalen traceoptions Anweisung auf Hierarchieebene [edit routing-options] angeben, und Sie können LDP-spezifische Optionen angeben, indem Sie die traceoptions folgende Anweisung einschließen:

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

Verwenden Sie die file Anweisung, um den Namen der Datei anzugeben, die die Ausgabe des Ablaufverfolgungsvorgangs empfängt. Alle Dateien werden im Verzeichnis /var/log abgelegt. Es wird empfohlen, die LDP-Ablaufverfolgungsausgabe in der Datei ldp-logzu platzieren.

Die folgenden Ablaufverfolgungsflags zeigen die Vorgänge an, die mit dem Senden und Empfangen verschiedener LDP-Nachrichten verbunden sind. Jeder kann einen oder mehrere der folgenden Modifikatoren tragen:

  • address—Verfolgen Sie den Vorgang von Adress- und Adressrückzugsnachrichten.

  • binding– Verfolgen Sie Beschriftungsbindungsvorgänge.

  • error– Verfolgen Sie Fehlerbedingungen.

  • event– Protokollereignisse verfolgen.

  • initialization– Verfolgen Sie den Vorgang von Initialisierungsmeldungen.

  • label: Verfolgen Sie den Vorgang von Label-Anforderungs-, Label-Map-, Label-Withdrawal- und Label-Release-Meldungen.

  • notification– Verfolgen Sie den Vorgang von Benachrichtigungen.

  • packets– Verfolgen Sie den Vorgang von Adresse, Adressentzug, Initialisierung, Etikettenanforderung, Etikettenzuordnung, Etikettenentzug, Etikettenfreigabe, Benachrichtigung und regelmäßigen Nachrichten. Dieser Modifikator entspricht dem Festlegen der addressModifikatoren , initialization, label, notificationund periodic .

    Sie können den filter Flag-Modifikator auch mit der match-on address Unteroption für das packets Flag konfigurieren. Auf diese Weise können Sie die Verfolgung basierend auf den Quell- und Zieladressen der Pakete durchführen.

  • path– Verfolgen Sie Vorgänge mit Label-Switched-Pfaden.

  • path– Verfolgen Sie Vorgänge mit Label-Switched-Pfaden.

  • periodic– Verfolgen Sie den Vorgang von Hello- und Keepalive-Nachrichten.

  • route– Verfolgen Sie den Vorgang von Routenmeldungen.

  • state– Verfolgen Sie Protokollstatusübergänge.

Ablaufverfolgung des LDP-Protokolldatenverkehrs innerhalb von FECs

LDP ordnet jedem erstellten LSP eine Weiterleitungsäquivalenzklasse (FEC) zu. Die FEC, die einem LSP zugeordnet ist, gibt an, welche Pakete diesem LSP zugeordnet werden. LSPs werden über ein Netzwerk erweitert, wenn jeder Router die Bezeichnung auswählt, die vom nächsten Hop für die FEC angekündigt wird, und sie mit der Bezeichnung verbindet, die er allen anderen Routern ankündigt.

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

Das folgende Beispiel veranschaulicht, wie Sie die LDP-Anweisung traceoptions konfigurieren können, um LDP-Ablaufverfolgungsanweisungen basierend auf einer FEC zu filtern:

Für diese Funktion gelten die folgenden Einschränkungen:

  • Die Filterfunktion ist nur für FECs verfügbar, die aus IPv4-Präfixen (IP Version 4) bestehen.

  • Layer-2-Schaltungs-FECs können nicht gefiltert werden.

  • Wenn Sie sowohl die Routenverfolgung als auch die Filterung konfigurieren, werden MPLS-Routen nicht angezeigt (sie werden durch den Filter blockiert).

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

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

Beispiele: Ablaufverfolgung des Datenverkehrs im LDP-Protokoll

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 Bezeichnungsbindungsvorgänge nach:

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

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

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 so konfigurieren, dass sie den gesamten Adressbereich in diesem Subnetz umfasst.
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 zum LDP-Next-Hop und umgekehrt zusammenfügen.
16.1
Ab Junos OS Version 16.1 kann M-LDP Punkt-zu-Mehrpunkt-LSPs bei ASBR oder Transit oder Ausgang signalisieren, wenn die Root-Adresse eine BGP-Route ist, die weiter rekursiv über eine MPLS-LSP aufgelöst wird.
14.1
Ab Junos OS Version 14.1 müssen Sie für die Migration bestehender IPTV-Services von nativem IP-Multicast zu MPLS-Multicast einen reibungslosen Übergang von PIM- zu M-LDP-Punkt-zu-Multipunkt-LSPs mit minimalem Ausfall durchführen.