Auf dieser Seite
Konfigurieren der Verzögerung, bevor LDP-Nachbarn als inaktiv betrachtet werden
Aktivieren von streng gezielten Begrüssungsnachrichten für LDP
Beispiel: Konfigurieren der längsten Übereinstimmung für LDP
Steuern der Transportadresse, die für die Ziel-LDP-Sitzung verwendet wird
Konfigurieren der Präfixe, die in LDP aus der Routing-Tabelle angekündigt werden
Konfigurieren von ECMP-fähigem BFD für LDP-Sprachdienstleister
Konfigurieren einer Fehleraktion für die BFD-Sitzung auf einem LDP-LSP
Beispiel: Konfigurieren der schnellen Multicast-Weiterleitung in einer Multipoint-LDP-Domäne
Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalisierung für Point-to-Multipoint-LSPs
Mapping von Client und Server für Segment-Routing auf LDP-Interoperabilität
LDP-Konfiguration
LDP-Mindestkonfiguration
So aktivieren Sie LDP mit minimaler Konfiguration:
Aktivieren Sie alle relevanten Schnittstellen unter der MPLS-Familie. Im Falle von gerichtetem LDP muss die Loopback-Schnittstelle mit Familien-MPLS aktiviert werden.
(Optional) Konfigurieren Sie die entsprechenden Schnittstellen unter der
[edit protocol mpls]
Hierarchieebene.Aktivieren Sie LDP auf einer einzelnen Schnittstelle, fügen Sie die
ldp
Anweisung ein, und geben Sie die Schnittstelle mithilfe derinterface
Anweisung an.
Dies ist die minimale LDP-Konfiguration. Alle anderen LDP-Konfigurationsanweisungen sind optional.
ldp { interface interface-name; }
Um LDP auf allen Schnittstellen zu aktivieren, geben Sie all
für interface-name
an.
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen 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:
ldp { interface interface-name; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung.
Um LDP auf allen Schnittstellen zu aktivieren, geben Sie all
für interface-name
an.
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:
interface interface-name { disable; }
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
- Konfigurieren des LDP-Timers für gezielte Hallo-Nachrichten
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:
hello-interval seconds;
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:
targeted-hello { hello-interval seconds; }
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.
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
- Konfigurieren der LDP-Haltezeit für gezielte Hallo-Nachrichten
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:
hold-time seconds;
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:
targeted-hello { hold-time seconds; }
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:
LDP: Ignoring targeted hello from 10.0.0.1
Um streng zielgerichtete Hallo-Nachrichten zu aktivieren, fügen Sie die strict-targeted-hellos
folgende Anweisung ein:
strict-targeted-hellos;
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:
keepalive-interval seconds;
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:
keepalive-timeout seconds;
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:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie das MPLS-Protokoll.
Konfigurieren Sie das OSPF-Protokoll.
Um die längste Übereinstimmung für LDP zu konfigurieren, müssen Sie die folgenden Schritte ausführen:
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.

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
set interfaces ge-0/0/0 unit 0 family inet address 22.22.22.1/24 set interfaces ge-0/0/1 unit 0 family inet address 15.15.15.1/24 set interfaces ge-0/0/2 unit 0 family inet address 11.11.11.1/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.112.1/32 primary set interfaces lo0 unit 0 family inet address 10.255.112.1/32 preferred set interfaces lo0 unit 0 family iso address 49.0002.0192.0168.0001.00 set routing-options router-id 10.255.112.1 set protocols mpls interface ge-0/0/2.0 set protocols ospf area 0.0.0.1 interface ge-0/0/2.0 set protocols ospf area 0.0.0.1 interface lo0.0 passive set protocols ldp longest-match set protocols ldp interface ge-0/0/2.0 set protocols ldp interface lo0.0
R1
set interfaces ge-0/0/0 unit 0 family inet address 11.11.11.2/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 12.12.12.1/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.112.2/32 primary set interfaces lo0 unit 0 family inet address 10.255.112.2/32 preferred set interfaces lo0 unit 0 family iso address 49.0002.0192.0168.0002.00 set routing-options router-id 10.255.112.2 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.1 interface ge-0/0/0.0 set protocols ldp longest-match set protocols ldp interface ge-0/0/0.0 set protocols ldp interface ge-0/0/1.0 set protocols ldp interface lo0.0
R2
set interfaces ge-0/0/0 unit 0 family inet address 24.24.24.1/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 12.12.12.2/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 23.23.23.1/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 22.22.22.2/24 set interfaces ge-0/0/4 unit 0 family inet address 25.25.25.1/24 set interfaces ge-0/0/4 unit 0 family iso set interfaces ge-0/0/4 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.4/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.4/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0003.00 set routing-options router-id 10.255.111.4 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/4.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.2 area-range 10.255.111.0/24 set protocols ospf area 0.0.0.2 interface ge-0/0/2.0 set protocols ospf area 0.0.0.2 interface ge-0/0/0.0 set protocols ospf area 0.0.0.2 interface ge-0/0/4.0 set protocols ldp interface ge-0/0/0.0 set protocols ldp interface ge-0/0/1.0 set protocols ldp interface ge-0/0/2.0 set protocols ldp interface ge-0/0/4.0 set protocols ldp interface lo0.0
R3
set interfaces ge-0/0/0 unit 0 family inet address 35.35.35.1/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 23.23.23.2/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 34.34.34.1/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.1/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.1/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0004.00 set routing-options router-id 10.255.111.1 set protocols mpls interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface fxp0.0 disable set protocols ospf area 0.0.0.2 interface lo0.0 passive set protocols ldp interface ge-0/0/1.0 set protocols ldp interface lo0.0
R4
set interfaces ge-0/0/0 unit 0 family inet address 45.45.45.1/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 24.24.24.2/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 34.34.34.2/24 set interfaces ge-0/0/2 unit 0 family iso set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.2/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.2/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0005.00 set routing-options router-id 10.255.111.2 set protocols mpls interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface ge-0/0/1.0 set protocols ospf area 0.0.0.2 interface fxp0.0 disable set protocols ospf area 0.0.0.2 interface lo0.0 passive set protocols ldp interface ge-0/0/1.0 set protocols ldp interface lo0.0
R5
set interfaces ge-0/0/0 unit 0 family inet address 25.25.25.2/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 15.15.15.2/24 set interfaces ge-0/0/2 unit 0 family inet address 35.35.35.2/24 set interfaces ge-0/0/3 unit 0 family inet address 45.45.45.2/24 set interfaces ge-0/0/3 unit 0 family iso set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.111.3/32 primary set interfaces lo0 unit 0 family inet address 10.255.111.3/32 preferred set interfaces lo0 unit 0 family iso address 49.0003.0192.0168.0006.00 set routing-options router-id 10.255.111.3 set protocols mpls interface ge-0/0/0.0 set protocols ospf area 0.0.0.2 interface ge-0/0/0.0 set protocols ospf area 0.0.0.2 interface fxp0.0 disable set protocols ospf area 0.0.0.2 interface lo0.0 passive set protocols ldp interface ge-0/0/0.0 set protocols ldp interface lo0.0
Konfigurieren 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:
Konfigurieren Sie die Schnittstellen.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 22.22.22.1/24 set ge-0/0/1 unit 0 family inet address 15.15.15.1/24 set ge-0/0/2 unit 0 family inet address 11.11.11.1/24 set ge-0/0/2 unit 0 family iso set ge-0/0/2 unit 0 family mpls
Weisen Sie dem Gerät die Loopback-Adressen zu.
[edit interfaces lo0 unit 0 family] set inet address 10.255.112.1/32 primary set inet address 10.255.112.1/32 preferred set iso address 49.0002.0192.0168.0001.00
Konfigurieren Sie die Router-ID.
[edit routing-options] set router-id 10.255.112.1
Konfigurieren Sie das MPLS-Protokoll auf der Schnittstelle.
[edit protocols mpls] set interface ge-0/0/2.0
Konfigurieren Sie das OSPF-Protokoll auf der Schnittstelle.
[edit protocols ospf] set area 0.0.0.1 interface ge-0/0/2.0 set area 0.0.0.1 interface lo0.0 passive
Konfigurieren Sie die längste Übereinstimmung für das LDP-Protokoll.
[edit protocols ldp] set longest-match
Konfigurieren Sie das LDP-Protokoll auf der Schnittstelle.
[edit protocols ldp] set interface ge-0/0/2.0 set interface lo0.0
Ergebnisse
Bestätigen Sie 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.
user@R0# show interfaces ge-0/0/0 { unit 0 { family inet { address 22.22.22.1/24; } } } ge-0/0/1 { unit 0 { family inet { address 15.15.15.1/24; } } } ge-0/0/2 { unit 0 { family inet { address 11.11.11.1/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.255.112.1/32 { primary; preferred; } } family iso { address 49.0002.0192.0168.0001.00; } } }
user@R0# show protocols mpls { interface ge-0/0/2.0; } ospf { area 0.0.0.1 { interface ge-0/0/2.0; interface lo0.0 { passive; } } } ldp { longest-match; interface ge-0/0/2.0; interface lo0.0; }
user@R0# show routing-options router-id 10.255.112.1;
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie es im Konfigurationsmodus ein commit
.
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Verifizieren der Routen
- Überprüfen der LDP-Übersichtsinformationen
- Überprüfen Sie die LDP-Einträge in der internen Topologietabelle
- Überprüfen Sie nur die FEC-Informationen der LDP-Route
- FEC- und Schattenrouten von LDP verifizieren
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.
user@R0> show route
inet.0: 62 destinations, 62 routes (62 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.4.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.5.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.6.128.0/17 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.9.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.10.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.13.4.0/23 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.13.10.0/23 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.82.0.0/15 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.84.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.85.12.0/22 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.92.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.92.16.0/20 *[Direct/0] 10:08:01
> via fxp0.0
10.92.20.175/32 *[Local/0] 10:08:01
Local via fxp0.0
10.94.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.99.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.102.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.150.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.155.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.157.64.0/19 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.160.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.204.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.205.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.206.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.207.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.209.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.212.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.213.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.214.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.215.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.216.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.13.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.14.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.16.0/20 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.218.32.0/20 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.227.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
10.255.111.0/24 *[OSPF/10] 09:52:14, metric 3
> to 11.11.11.2 via ge-0/0/2.0
10.255.111.4/32 *[OSPF/10] 09:54:10, metric 2
> to 11.11.11.2 via ge-0/0/2.0
10.255.112.1/32 *[Direct/0] 09:55:05
> via lo0.0
10.255.112.2/32 *[OSPF/10] 09:54:18, metric 1
> to 11.11.11.2 via ge-0/0/2.0
11.11.11.0/24 *[Direct/0] 09:55:05
> via ge-0/0/2.0
11.11.11.1/32 *[Local/0] 09:55:05
Local via ge-0/0/2.0
12.12.12.0/24 *[OSPF/10] 09:54:18, metric 2
> to 11.11.11.2 via ge-0/0/2.0
15.15.15.0/24 *[Direct/0] 09:55:05
> via ge-0/0/1.0
15.15.15.1/32 *[Local/0] 09:55:05
Local via ge-0/0/1.0
22.22.22.0/24 *[Direct/0] 09:55:05
> via ge-0/0/0.0
22.22.22.1/32 *[Local/0] 09:55:05
Local via ge-0/0/0.0
23.23.23.0/24 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
24.24.24.0/24 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
25.25.25.0/24 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.17.45/32 *[OSPF/10] 09:54:05, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.20.175/32 *[Direct/0] 10:08:01
> via lo0.0
128.92.21.186/32 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.25.135/32 *[OSPF/10] 09:54:10, metric 3
> to 11.11.11.2 via ge-0/0/2.0
128.92.27.91/32 *[OSPF/10] 09:54:18, metric 1
> to 11.11.11.2 via ge-0/0/2.0
128.92.28.70/32 *[OSPF/10] 09:54:10, metric 2
> to 11.11.11.2 via ge-0/0/2.0
172.16.0.0/12 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
192.168.0.0/16 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
192.168.102.0/23 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
207.17.136.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
207.17.136.192/32 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
207.17.137.0/24 *[Static/5] 10:08:01
> to 10.92.31.254 via fxp0.0
224.0.0.5/32 *[OSPF/10] 09:55:05, metric 1
MultiRecv
inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.111.1/32 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Push 300128
10.255.111.2/32 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Push 300144
10.255.111.3/32 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Push 300160
10.255.111.4/32 *[LDP/9] 09:54:10, metric 2, tag 0
> to 11.11.11.2 via ge-0/0/2.0, Push 300000
10.255.112.2/32 *[LDP/9] 09:54:48, metric 1, tag 0
> to 11.11.11.2 via ge-0/0/2.0
iso.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
47.0005.80ff.f800.0000.0108.0001.1280.9202.0175/152
*[Direct/0] 10:08:01
> via lo0.0
49.0002.0192.0168.0001/72
*[Direct/0] 09:55:05
> via lo0.0
mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 09:55:05, metric 1
Receive
1 *[MPLS/0] 09:55:05, metric 1
Receive
2 *[MPLS/0] 09:55:05, metric 1
Receive
13 *[MPLS/0] 09:55:05, metric 1
Receive
300064 *[LDP/9] 09:54:48, metric 1
> to 11.11.11.2 via ge-0/0/2.0, Pop
300064(S=0) *[LDP/9] 09:54:48, metric 1
> to 11.11.11.2 via ge-0/0/2.0, Pop
300112 *[LDP/9] 09:54:10, metric 2, tag 0
> to 11.11.11.2 via ge-0/0/2.0, Swap 300000
300192 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Swap 300128
300208 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Swap 300144
300224 *[LDP/9] 09:41:03, metric 3
> to 11.11.11.2 via ge-0/0/2.0, Swap 300160
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
abcd::128:92:20:175/128
*[Direct/0] 10:08:01
> via lo0.0
fe80::5668:a50f:fcc1:1f9c/128
*[Direct/0] 10:08:01
> via lo0.0
Bedeutung
Die Ausgabe zeigt alle Routen in der Routing-Tabelle des Geräts R0 an.
Überprüfen der LDP-Übersichtsinformationen
Zweck
LDP-Übersichtsinformationen anzeigen.
Action!
Führen Sie auf Gerät R0 im Betriebsmodus den show ldp overview
Befehl aus, um die Übersicht über das LDP anzuzeigen.
user@R0> show ldp overview
Instance: master
Reference count: 2
Router ID: 10.255.112.1
Message id: 8
Configuration sequence: 6
Deaggregate: disabled
Explicit null: disabled
IPv6 tunneling: disabled
Strict targeted hellos: disabled
Loopback if added: yes
Route preference: 9
Unicast transit LSP chaining: disabled
P2MP transit LSP chaining: disabled
Transit LSP statistics based on route statistics: disabled
LDP route acknowledgement: enabled
LDP mtu discovery: disabled
Longest Match: enabled
Capabilities enabled: none
Egress FEC capabilities enabled: entropy-label-capability
Downstream unsolicited Sessions:
Operational: 1
Retention: liberal
Control: ordered
Auto targeted sessions:
Auto targeted: disabled
Timers:
Keepalive interval: 10, Keepalive timeout: 30
Link hello interval: 5, Link hello hold time: 15
Targeted hello interval: 15, Targeted hello hold time: 45
Label withdraw delay: 60, Make before break timeout: 30
Make before break switchover delay: 3
Link protection timeout: 120
Graceful restart:
Restart: disabled, Helper: enabled, Restart in process: false
Reconnect time: 60000, Max neighbor reconnect time: 120000
Recovery time: 160000, Max neighbor recovery time: 240000
Traffic Engineering:
Bgp igp: disabled
Both ribs: disabled
Mpls forwarding: disabled
IGP:
Tracking igp metric: disabled
Sync session up delay: 10
Session protection:
Session protection: disabled
Session protection timeout: 0
Interface addresses advertising:
11.11.11.1
10.255.112.1
128.92.20.175
Label allocation:
Current number of LDP labels allocated: 5
Total number of LDP labels allocated: 11
Total number of LDP labels freed: 6
Total number of LDP label allocation failure: 0
Current number of labels allocated by all protocols: 5
Bedeutung
Die Ausgabe zeigt die LDP-Übersichtsinformationen des Geräts R0 an
Überprüfen 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.
user@R0> show ldp route
Destination Next-hop intf/lsp/table Next-hop address
10.4.0.0/16 fxp0.0 10.92.31.254
10.5.0.0/16 fxp0.0 10.92.31.254
10.6.128.0/17 fxp0.0 10.92.31.254
10.9.0.0/16 fxp0.0 10.92.31.254
10.10.0.0/16 fxp0.0 10.92.31.254
10.13.4.0/23 fxp0.0 10.92.31.254
10.13.10.0/23 fxp0.0 10.92.31.254
10.82.0.0/15 fxp0.0 10.92.31.254
10.84.0.0/16 fxp0.0 10.92.31.254
10.85.12.0/22 fxp0.0 10.92.31.254
10.92.0.0/16 fxp0.0 10.92.31.254
10.92.16.0/20 fxp0.0
10.92.20.175/32
10.94.0.0/16 fxp0.0 10.92.31.254
10.99.0.0/16 fxp0.0 10.92.31.254
10.102.0.0/16 fxp0.0 10.92.31.254
10.150.0.0/16 fxp0.0 10.92.31.254
10.155.0.0/16 fxp0.0 10.92.31.254
10.157.64.0/19 fxp0.0 10.92.31.254
10.160.0.0/16 fxp0.0 10.92.31.254
10.204.0.0/16 fxp0.0 10.92.31.254
10.205.0.0/16 fxp0.0 10.92.31.254
10.206.0.0/16 fxp0.0 10.92.31.254
10.207.0.0/16 fxp0.0 10.92.31.254
10.209.0.0/16 fxp0.0 10.92.31.254
10.212.0.0/16 fxp0.0 10.92.31.254
10.213.0.0/16 fxp0.0 10.92.31.254
10.214.0.0/16 fxp0.0 10.92.31.254
10.215.0.0/16 fxp0.0 10.92.31.254
10.216.0.0/16 fxp0.0 10.92.31.254
10.218.13.0/24 fxp0.0 10.92.31.254
10.218.14.0/24 fxp0.0 10.92.31.254
10.218.16.0/20 fxp0.0 10.92.31.254
10.218.32.0/20 fxp0.0 10.92.31.254
10.227.0.0/16 fxp0.0 10.92.31.254
10.255.111.0/24 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.112.1/32 lo0.0
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
11.11.11.0/24 ge-0/0/2.0
11.11.11.1/32
12.12.12.0/24 ge-0/0/2.0 11.11.11.2
15.15.15.0/24 ge-0/0/1.0
15.15.15.1/32
22.22.22.0/24 ge-0/0/0.0
22.22.22.1/32
23.23.23.0/24 ge-0/0/2.0 11.11.11.2
24.24.24.0/24 ge-0/0/2.0 11.11.11.2
25.25.25.0/24 ge-0/0/2.0 11.11.11.2
128.92.17.45/32 ge-0/0/2.0 11.11.11.2
128.92.20.175/32 lo0.0
128.92.21.186/32 ge-0/0/2.0 11.11.11.2
128.92.25.135/32 ge-0/0/2.0 11.11.11.2
128.92.27.91/32 ge-0/0/2.0 11.11.11.2
128.92.28.70/32 ge-0/0/2.0 11.11.11.2
172.16.0.0/12 fxp0.0 10.92.31.254
192.168.0.0/16 fxp0.0 10.92.31.254
192.168.102.0/23 fxp0.0 10.92.31.254
207.17.136.0/24 fxp0.0 10.92.31.254
207.17.136.192/32 fxp0.0 10.92.31.254
207.17.137.0/24 fxp0.0 10.92.31.254
224.0.0.5/32
Bedeutung
Die Ausgabe zeigt die Routeneinträge in der internen Topologietabelle des Label Distribution Protocol (LDP) 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.
user@R0> show ldp route fec-only
Destination Next-hop intf/lsp/table Next-hop address
10.255.111.1/32 ge-0/0/2.0 11.11.11.2
10.255.111.2/32 ge-0/0/2.0 11.11.11.2
10.255.111.3/32 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.112.1/32 lo0.0
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
Bedeutung
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.
user@R0> show ldp route fec-and-route
Destination Next-hop intf/lsp/table Next-hop address
10.4.0.0/16 fxp0.0 10.92.31.254
10.5.0.0/16 fxp0.0 10.92.31.254
10.6.128.0/17 fxp0.0 10.92.31.254
10.9.0.0/16 fxp0.0 10.92.31.254
10.10.0.0/16 fxp0.0 10.92.31.254
10.13.4.0/23 fxp0.0 10.92.31.254
10.13.10.0/23 fxp0.0 10.92.31.254
10.82.0.0/15 fxp0.0 10.92.31.254
10.84.0.0/16 fxp0.0 10.92.31.254
10.85.12.0/22 fxp0.0 10.92.31.254
10.92.0.0/16 fxp0.0 10.92.31.254
10.92.16.0/20 fxp0.0
10.92.20.175/32
10.94.0.0/16 fxp0.0 10.92.31.254
10.99.0.0/16 fxp0.0 10.92.31.254
10.102.0.0/16 fxp0.0 10.92.31.254
10.150.0.0/16 fxp0.0 10.92.31.254
10.155.0.0/16 fxp0.0 10.92.31.254
10.157.64.0/19 fxp0.0 10.92.31.254
10.160.0.0/16 fxp0.0 10.92.31.254
10.204.0.0/16 fxp0.0 10.92.31.254
10.205.0.0/16 fxp0.0 10.92.31.254
10.206.0.0/16 fxp0.0 10.92.31.254
10.207.0.0/16 fxp0.0 10.92.31.254
10.209.0.0/16 fxp0.0 10.92.31.254
10.212.0.0/16 fxp0.0 10.92.31.254
10.213.0.0/16 fxp0.0 10.92.31.254
10.214.0.0/16 fxp0.0 10.92.31.254
10.215.0.0/16 fxp0.0 10.92.31.254
10.216.0.0/16 fxp0.0 10.92.31.254
10.218.13.0/24 fxp0.0 10.92.31.254
10.218.14.0/24 fxp0.0 10.92.31.254
10.218.16.0/20 fxp0.0 10.92.31.254
10.218.32.0/20 fxp0.0 10.92.31.254
10.227.0.0/16 fxp0.0 10.92.31.254
10.255.111.0/24 ge-0/0/2.0 11.11.11.2
10.255.111.1/32 ge-0/0/2.0 11.11.11.2
10.255.111.2/32 ge-0/0/2.0 11.11.11.2
10.255.111.3/32 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.111.4/32 ge-0/0/2.0 11.11.11.2
10.255.112.1/32 lo0.0
10.255.112.1/32 lo0.0
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
10.255.112.2/32 ge-0/0/2.0 11.11.11.2
11.11.11.0/24 ge-0/0/2.0
11.11.11.1/32
12.12.12.0/24 ge-0/0/2.0 11.11.11.2
15.15.15.0/24 ge-0/0/1.0
15.15.15.1/32
22.22.22.0/24 ge-0/0/0.0
22.22.22.1/32
23.23.23.0/24 ge-0/0/2.0 11.11.11.2
24.24.24.0/24 ge-0/0/2.0 11.11.11.2
25.25.25.0/24 ge-0/0/2.0 11.11.11.2
128.92.17.45/32 ge-0/0/2.0 11.11.11.2
128.92.20.175/32 lo0.0
128.92.21.186/32 ge-0/0/2.0 11.11.11.2
128.92.25.135/32 ge-0/0/2.0 11.11.11.2
128.92.27.91/32 ge-0/0/2.0 11.11.11.2
128.92.28.70/32 ge-0/0/2.0 11.11.11.2
172.16.0.0/12 fxp0.0 10.92.31.254
192.168.0.0/16 fxp0.0 10.92.31.254
192.168.102.0/23 fxp0.0 10.92.31.254
207.17.136.0/24 fxp0.0 10.92.31.254
207.17.136.192/32 fxp0.0 10.92.31.254
207.17.137.0/24 fxp0.0 10.92.31.254
224.0.0.5/32
Bedeutung
Die Ausgabe zeigt 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:
preference preference;
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
- Deaktivieren des LDP-Graceful-Neustarts oder des Hilfsmodus
- Konfigurieren der Wiederverbindungszeit
- Konfigurieren der Wiederherstellungszeit und der maximalen Wiederherstellungszeit
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:
graceful-restart;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit routing-options]
[edit logical-systems logical-system-name routing-options]
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:
ldp { graceful-restart { disable; } }
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:
ldp { graceful-restart { helper-disable; } }
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:
graceful-restart { reconnect-time seconds; }
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:
graceful-restart { maximum-neighbor-recovery-time seconds; recovery-time seconds; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen konfigurieren können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.
Filtern eingehender LDP-Label-Bindungen
Sie können empfangene LDP-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:
import [ policy-names ];
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.
from Operator |
Beschreibung |
---|---|
|
Übereinstimmungen mit Bindungen, die von einem Nachbarn empfangen wurden, der über die angegebene Schnittstelle benachbart ist |
|
Übereinstimmungen mit Bindungen, die von der angegebenen LDP-Router-ID empfangen wurden |
|
Übereinstimmungen mit Bindungen, die von einem Nachbarn empfangen wurden, der die angegebene Schnittstellenadresse ankündigt |
|
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:
user@host> show ldp database Input label database, 10.10.255.1:0-10.10.255.6:0 Label Prefix 3 10.10.255.6/32 (Filtered) Output label database, 10.10.255.1:0-10.10.255.6:0 Label Prefix 3 10.10.255.1/32 (Filtered)
Weitere Informationen 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:
[edit] protocols { ldp { import only-32; ... } } policy-options { policy-statement only-32 { term first { from { route-filter 0.0.0.0/0 upto /31; } then reject; } then accept; } }
Akzeptieren Sie oder länger von der Router-ID 131.108/16
10.10.255.2
und akzeptieren Sie alle Präfixe von allen anderen Nachbarn:
[edit] protocols { ldp { import nosy-neighbor; ... } } policy-options { policy-statement nosy-neighbor { term first { from { neighbor 10.10.255.2; route-filter 131.108.0.0/16 orlonger accept; route-filter 0.0.0.0/0 orlonger reject; } } then accept; } }
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:
export [policy-name];
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.
zum Bediener |
Beschreibung |
---|---|
|
Übereinstimmungen mit Bindungen, die an einen Nachbarn gesendet werden, der über die angegebene Schnittstelle benachbart ist |
|
Übereinstimmungen mit Bindungen, die an die angegebene LDP-Router-ID gesendet werden |
|
Ü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:
user@host> show ldp database Input label database, 10.10.255.1:0-10.10.255.3:0 Label Prefix 100007 10.10.255.2/32 3 10.10.255.3/32 Output label database, 10.10.255.1:0-10.10.255.3:0 Label Prefix 3 10.10.255.1/32 100001 10.10.255.6/32 (Filtered)
Weitere Informationen 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:
[edit protocols] ldp { export block-one; } policy-options { policy-statement block-one { term first { from { route-filter 10.10.255.6/32 exact; } then reject; } then accept; } }
131.108/16
Nur oder länger an Router-ID 10.10.255.2
senden und alle Präfixe an alle anderen Router senden:
[edit protocols] ldp { export limit-lsps; } policy-options { policy-statement limit-lsps { term allow-one { from { route-filter 131.108.0.0/16 orlonger; } to { neighbor 10.10.255.2; } then accept; } term block-the-rest { to { neighbor 10.10.255.2; } then reject; } then accept; } }
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:
transport-address (router-id | interface);
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.
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
- Übersicht über Ziel-LDP-Transportadressen
- Bevorzugte Transportadressen
- Fehlerbehebung bei der Konfiguration von Transportadressen
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 session
Konfigurationsanweisungen , 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:
Unter
[edit protocols ldp session]
Hierarchie.Unter
[edit protocols ldp session-group]
Hierarchie.Unter
[edit protocols ldp interfcae lo0]
Hierarchie.Unter
[edit protocols ldp]
Hierarchie.Standardadresse.
Die Reihenfolge der Präferenz der Transportadresse für die ermittelten Nachbarn lautet wie folgt:
Unter
[edit protocols ldp interfcae]
Hierarchie.Unter
[edit protocols ldp]
Hierarchie.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:
Unter
[edit protocols ldp interfcae lo0]
Hierarchie.Unter
[edit protocols ldp]
Hierarchie.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 desshow 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:
May 29 10:47:11.569722 Incoming connect from 10.55.1.4 May 29 10:47:11.570064 Connection 10.55.1.4 state Closed -> Open May 29 10:47:11.570727 Session 10.55.1.4 state Nonexistent -> Initialized May 29 10:47:11.570768 Session 10.55.1.4 state Initialized -> OpenRec May 29 10:47:11.570799 LDP: Session param Max PDU length 4096 from 10.55.1.4, negotiated 4096 May 29 10:47:11.570823 Session 10.55.1.4 GR state Nonexistent -> Operational May 29 10:47:11.669295 Session 10.55.1.4 state OpenRec -> Operational May 29 10:47:11.669387 RPD_LDP_SESSIONUP: LDP session 10.55.1.4 is up
Wenn die Konfiguration von der Verwendung einer gültigen Transportadresse in eine Transportadresse geändert wird, die ungültig (nicht erreichbar) ist, können die folgenden Traces beobachtet werden:
May 29 10:42:36.317942 Session 10.55.1.4 GR state Operational -> Nonexistent May 29 10:42:36.318171 Session 10.55.1.4 state Operational -> Closing May 29 10:42:36.318208 LDP session 10.55.1.4 is down, reason: received notification from peer May 29 10:42:36.318236 RPD_LDP_SESSIONDOWN: LDP session 10.55.1.4 is down, reason: received notification from peer May 29 10:42:36.320081 Connection 10.55.1.4 state Open -> Closed May 29 10:42:36.322411 Session 10.55.1.4 state Closing -> Nonexistent
Führen Sie im Falle einer fehlerhaften Konfiguration die folgenden Fehlerbehebungsaufgaben durch:
Aktivieren Sie die
address family
Option . Die Transportadresse, die unter dersession
Anweisung konfiguriert wird, muss derselben Adressfamilie angehören wie der Nachbar oder die Sitzung.Die Adresse, die als Transportadresse unter einer
neighbor
oder-Anweisungsession
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:
egress-policy policy-name;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisung.
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.
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:
[edit protocols] ldp { egress-policy connected-only; } policy-options { policy-statement connected-only { from { protocol direct; } then accept; } }
Konfigurieren der FEC-Deaggregation
Wenn ein LDP-Ausgangsrouter mehrere Präfixe ankündigt, 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:
deaggregate;
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:
no-deaggregate;
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-set
und 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:
policing { fec fec-address { ingress-traffic filter-name; transit-traffic filter-name; } }
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:
l2-smart-policy;
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:
RPD_LDP_BFD_UP: LDP BFD session for FEC 10.255.16.14/32 is up RPD_LDP_BFD_DOWN: LDP BFD session for FEC 10.255.16.14/32 is down
Sie können 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 oam
bfd-liveness-detection
und-Anweisungen ein:
oam { bfd-liveness-detection { detection-time threshold milliseconds; ecmp; failure-action { remove-nexthop; remove-route; } holddown-interval seconds; ingress-policy ingress-policy-name; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-transmit-interval milliseconds; multiplier detection-time-multiplier; no-adaptation; transmit-interval { minimum-interval milliseconds; threshold milliseconds; } version (0 | 1 | automatic); } fec fec-address { bfd-liveness-detection { detection-time threshold milliseconds; ecmp; failure-action { remove-nexthop; remove-route; } holddown-interval milliseconds; ingress-policy ingress-policy-name; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-transmit-interval milliseconds; multiplier detection-time-multiplier; no-adaptation; transmit-interval { minimum-interval milliseconds; threshold milliseconds; } version (0 | 1 | automatic); } no-bfd-liveness-detection; periodic-traceroute { disable; exp exp-value; fanout fanout-value; frequency minutes; paths number-of-paths; retries retry-attempts; source address; ttl ttl-value; wait seconds; } } lsp-ping-interval seconds; periodic-traceroute { disable; exp exp-value; fanout fanout-value; frequency minutes; paths number-of-paths; retries retry-attempts; source address; ttl ttl-value; wait seconds; } }
Sie können BFD für die LDP-LSPs aktivieren, die 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]
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, umping 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 dieecmp
Option konfigurieren, müssen Sie auch dieperiodic-traceroute
Anweisung für die angegebene FEC konfigurieren. Wenn Sie dies nicht tun, schlägt der Commit-Vorgang fehl. Sie können dieperiodic-traceroute
Anweisung auf der globalen Hierarchieebene ([edit protocols ldp oam]
) konfigurieren, während Sie nur dieecmp
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 dieminimum-interval
Option konfigurieren, müssen Sie dieminimum-receive-interval
Option oder dieminimum-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.
ecmp;
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.
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:
failure-action { remove-nexthop; remove-route; }
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.
holddown-interval seconds;
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-Link-Schutzes
Sie können den LDP-Verbindungsschutz (Label Distribution Protocol) sowohl für Unicast- als auch für Multicast-LDP-Label-Switched-Pfade (LSPs) konfigurieren, um Ausfallsicherheit bei Verbindungs- oder Knotenausfällen zu gewährleisten.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie die Router-ID und die autonome Systemnummer für das Gerät.
Konfigurieren Sie die folgenden Protokolle:
RSVP
MPLS mit Traffic-Engineering-Funktionen.
OSPF mit Traffic-Engineering-Funktionen.
HINWEIS:Aktivieren Sie für den Multicast-LDP-Link-Schutz mit schleifenfreier Alternative (LFA) den Link-Schutz.
[edit protocols] user@R0# set ospf area 0 interface all link-protection
So konfigurieren Sie den LDP-Link-Schutz:
Beispiel: Konfigurieren des LDP-Link-Schutzes
LDP-Link-Schutz – Übersicht
- Einführung in LDP
- Implementierung des Junos OS LDP-Protokolls
- Grundlegendes zu Multipoint-Erweiterungen für LDP
- Verwenden von Multipoint-Erweiterungen für LDP in gezielten LDP-Sitzungen
- Aktuelle Einschränkungen des LDP-Link-Schutzes
- Verwendung von RSVP LSP als Lösung
- Grundlegendes zum Schutz von Multicast-LDP-Verbindungen
- Verschiedene Modi für die Bereitstellung von LDP-Link-Schutz
- Label-Operation für den LDP-Link-Schutz
- Beispiel für eine Multicast-LDP-Link-Schutzkonfiguration
- Make-Before-Break
- Vorsichtsmaßnahmen und Einschränkungen
Einführung in LDP
Das Label Distribution Protocol (LDP) ist ein Protokoll zum Verteilen von Etiketten in Anwendungen, die nicht auf Datenverkehr ausgelegt sind. LDP ermöglicht es Routern, Label-Switched-Pfade (LSPs) durch ein Netzwerk einzurichten, indem Routing-Informationen auf Netzwerkschicht direkt den Datenverbindungs-LSPs zugeordnet werden.
Diese Sprachdienstleister können einen Endpunkt bei einem direkt angeschlossenen Nachbarn (vergleichbar mit IP-Hop-by-Hop-Weiterleitung) oder an einem Netzwerkausgangsknoten haben, wodurch das Switching über alle zwischengeschalteten Knoten ermöglicht wird. Von LDP eingerichtete LSPs können auch von RSVP erstellte Traffic-Engineering-LSPs durchlaufen.
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. Dieser Prozess bildet eine Struktur von LSPs, die auf dem Ausgangsrouter konvergieren.
Implementierung des Junos OS LDP-Protokolls
Die Junos OS-Implementierung von LDP unterstützt LDP Version 1. Junos OS unterstützt einen einfachen Mechanismus für Tunneling zwischen Routern in einem Interior Gateway Protocol (IGP), um die erforderliche Verteilung externer Routen innerhalb des Core zu eliminieren. Junos OS ermöglicht einen MPLS-Tunnel für den nächsten Hop zu allen Ausgangsroutern im Netzwerk, wobei nur ein IGP im Core ausgeführt wird, um Routen an die Ausgangsrouter zu verteilen. Edge-Router führen BGP aus, verteilen aber keine externen Routen an den Core. Stattdessen wird die rekursive Routensuche am Edge in einen LSP aufgelöst, der zum Ausgangsrouter gewechselt ist. Auf den Transit-LDP-Routern sind keine externen Routen erforderlich.
Grundlegendes zu Multipoint-Erweiterungen für LDP
Ein LDP definiert Mechanismen zum Einrichten von Punkt-zu-Punkt-, Multipunkt-zu-Punkt-, Punkt-zu-Multipunkt- und Multipunkt-zu-Multipunkt-LSPs im Netzwerk. Die Point-to-Multipoint- und Multipoint-to-Multipoint-LSPs werden zusammenfassend als Multipoint-LSPs bezeichnet, bei denen der Datenverkehr von einer einzigen Quelle zu mehreren Zielen bzw. von mehreren Quellen zu mehreren Zielen fließt. Die Ziel- oder Ausgangsrouter werden als Leaf-Knoten bezeichnet, und der Datenverkehr von der Quelle durchläuft einen oder mehrere Transitknoten, bevor er die Leaf-Knoten erreicht.
Junos OS bietet keine Unterstützung für Multipoint-to-Multipoint-LSPs.
Durch die Nutzung der MPLS-Paketreplikationsfunktion des Netzwerks vermeiden Multipoint-LSPs unnötige Paketreplikationen am Eingangsrouter. Die Paketreplikation findet nur statt, wenn Pakete an zwei oder mehr verschiedene Ziele weitergeleitet werden, für die unterschiedliche Netzwerkpfade erforderlich sind.
Verwenden von Multipoint-Erweiterungen für LDP in gezielten LDP-Sitzungen
Die Spezifikation für die Multipoint-Erweiterungen von LDP erfordert, dass die beiden Endpunkte einer LDP-Sitzung direkt über ein Layer-2-Medium verbunden sind oder vom IGP des Netzwerks als Nachbarn betrachtet werden. Dies wird als LDP-Link-Sitzung bezeichnet. Wenn die beiden Endpunkte einer LDP-Sitzung nicht direkt verbunden sind, wird die Sitzung als LDP-Zielsitzung bezeichnet.
Frühere Junos OS-Implementierungen unterstützen Multicast-LDP nur für Link-Sitzungen. Mit der Einführung der LDP-Link-Schutzfunktion werden die Multicast-LDP-Funktionen auf gezielte LDP-Sitzungen ausgeweitet. Abbildung 2 zeigt eine Beispieltopologie.

Die Router R7 und R8 sind die Upstream- (LSR-U) bzw. Downstream-Router (LSR-D) Label-Switched Router (LSRs) und stellen Multicast-LDP bereit. Für den Core-Router, Router R5, ist RSVP-TE aktiviert.
Wenn LSR-D den Punkt-zu-Mehrpunkt-LSP mit den Attributen root und LSP ID einrichtet, bestimmt es das Upstream-LSR-U als Next-Hop auf dem besten Pfad zum Root (derzeit wird davon ausgegangen, dass es sich bei diesem Next-Hop um einen IGP-Next-Hop handelt).
Mit der Multicast-LDP-Unterstützung für gezielte LDP-Sitzungen können Sie feststellen, ob es einen LSP-nächsten Hop zu LSR-U gibt, der sich auf dem Pfad von LSR-D zum Root befindet, wobei LSR-D und LSR-U keine direkt verbundenen Nachbarn, sondern gezielte LDP-Peers sind. Die Punkt-zu-Mehrpunkt-Bezeichnung, die in der Ziel-LDP-Sitzung zwischen LSR-D und LSR-U angekündigt wird, wird nur verwendet, wenn ein LSP zwischen LSR-D und LSR-U vorhanden ist. Daher ist ein entsprechender LSP in umgekehrter Richtung von LSR-U zu LSR-D erforderlich.
Die Datenübertragung erfolgt auf dem Punkt-zu-Mehrpunkt-LSP mithilfe der Unicast-Replikation von Paketen, wobei LSR-U eine Kopie an jeden nachgeschalteten LSR des Punkt-zu-Mehrpunkt-LSP sendet.
Die Datenübertragung erfolgt auf folgende Weise:
Die Punkt-zu-Multipoint-Funktionen für die Ziel-LDP-Sitzung werden ausgehandelt.
Der Algorithmus zur Auswahl des Upstream-LSR wird geändert, d. h. wenn die nächsten IGP-Hops nicht verfügbar sind oder mit anderen Worten, es gibt keine LDP-Verbindungssitzung zwischen LSR-D und LSR-U, wird ein RSVP-LSP als nächster Hop verwendet, um LSR-U zu erreichen.
Die eingehenden Labels, die über die Ziel-LDP-Sitzungen empfangen werden, werden als Branch Next Hop für diese Point-to-Multipoint-FEC-Route mit dem LDP-Label als innerem Label und dem RSVP-Label als äußerem Label installiert.
Aktuelle Einschränkungen des LDP-Link-Schutzes
Wenn es in einer LDP-Netzwerkbereitstellung zu einem Verbindungs- oder Knotenausfall kommt, sollte eine schnelle Wiederherstellung des Datenverkehrs bereitgestellt werden, um die betroffenen Datenverkehrsströme für unternehmenskritische Dienste wiederherzustellen. Wenn bei Multipoint-LSPs eine der Verbindungen der Punkt-zu-Multipoint-Struktur ausfällt, können die Teilbäume getrennt werden, bis der IGP wieder konvergiert und der Multipoint-LSP über den besten Pfad vom Downstream-Router zum neuen Upstream-Router eingerichtet wird.
Bei der schnellen Weiterleitung mit lokaler Reparatur für LDP-Datenverkehr ist ein Backup-Pfad (Reparaturpfad) in der Packet Forwarding Engine vorinstalliert. Wenn der primäre Pfad ausfällt, wird der Datenverkehr schnell auf den Backup-Pfad verschoben, ohne dass auf die Konvergenz der Routing-Protokolle gewartet werden muss. Loop-free alternate (LFA) ist eine der Methoden, die verwendet werden, um IP-Fast-Reroute-Funktionen in den Core- und Service Provider-Netzwerken bereitzustellen.
Wenn ohne LFA eine Verbindung oder ein Router ausfällt oder wieder in Betrieb genommen wird, berechnen die verteilten Routing-Algorithmen die neuen Routen auf der Grundlage der Änderungen im Netzwerk. Die Zeit, in der die neuen Routen berechnet werden, wird als Routing-Übergang bezeichnet. Bis der Routing-Übergang abgeschlossen ist, wird die Netzwerkkonnektivität unterbrochen, da die an einen Ausfall angrenzenden Router die Datenpakete so lange über die ausgefallene Komponente weiterleiten, bis ein alternativer Pfad identifiziert wird.
Aufgrund der IGP-Metriken bietet LFA jedoch nicht eine vollständige Abdeckung in allen Netzwerkbereitstellungen. Daher ist dies eine Einschränkung der aktuellen LDP-Link-Schutzschemata.
Abbildung 3 veranschaulicht ein Beispielnetzwerk mit unvollständiger LFA-Abdeckung, bei dem der Datenverkehr vom Quellrouter (S) zum Zielrouter (D) über Router R1 fließt. Unter der Annahme, dass jede Verbindung im Netzwerk dieselbe Metrik aufweist und die Verbindung zwischen Router S und Router R1 ausfällt, ist Router R4 keine LFA, die die S-R1-Verbindung schützt, sodass die Ausfallsicherheit des Datenverkehrs verloren geht. Daher wird durch die Verwendung von reinem LFA keine vollständige Abdeckung erreicht. In typischen Netzwerken gibt es immer eine gewisse prozentuale Lücke zwischen der Abdeckung von LFA und reiner LFA.

Verwendung von RSVP LSP als Lösung
Der Schlüssel zum Schutz des Datenverkehrs, der durch LDP-LSPs fließt, ist ein expliziter Tunnel, der den Datenverkehr im Falle eines Verbindungs- oder Knotenausfalls umleitet. Der explizite Pfad muss auf dem nächsten Downstream-Router enden, und der Datenverkehr muss auf dem expliziten Pfad akzeptiert werden, wo die RPF-Prüfung bestehen soll.
RSVP-LSPs helfen dabei, die derzeitigen Einschränkungen von Loop-Free Alternate (LFA) sowohl für Punkt-zu-Punkt- als auch für Punkt-zu-Mehrpunkt-LDP-LSPs zu überwinden, indem sie die LFA-Abdeckung mit den folgenden Methoden erweitern:
Manuell konfigurierte RSVP-LSPs
Unter Berücksichtigung des Beispiels in Abbildung 3, wenn die S-R1-Verbindung ausfällt und Router R4 keine LFA für diese bestimmte Verbindung ist, wird eine manuell erstellte RSVP-LSP als Patch verwendet, um eine vollständige LFA-Abdeckung bereitzustellen. Der RSVP LSP ist in der Packet Forwarding Engine von Router S vorsignalisiert und vorinstalliert, sodass er verwendet werden kann, sobald Router S erkennt, dass die Verbindung fehlgeschlagen ist.

In diesem Fall wird ein RSVP-LSP zwischen den Routern S, R4 und R3 erstellt, wie in Abbildung 4dargestellt. Zwischen Router S und Router R3 wird eine gezielte LDP-Sitzung erstellt, wodurch bei einem Ausfall der S-R1-Verbindung der Datenverkehr Router R3 erreicht. Router R3 leitet den Datenverkehr an Router R2 weiter, da dies der kürzeste Weg ist, um das Ziel, Router D, zu erreichen.
Dynamisch konfigurierte RSVP-LSPs
Bei dieser Methode werden die RSVP-LSPs automatisch erstellt und im System vorinstalliert, so dass sie bei einem Verbindungsausfall sofort verwendet werden können. Hier ist der Ausgang der Knoten auf der anderen Seite der zu schützenden Verbindung, wodurch die LFA-Abdeckung verbessert wird.
Benefits of Enabling Dynamic RSVP LSPs
Einfache Konfiguration.
100-prozentige Abdeckung gegen Verbindungsausfälle, solange es einen alternativen Pfad zum anderen Ende der zu schützenden Verbindung gibt.
Das Auf- und Abbauen des RSVP-Bypass-LSP erfolgt automatisch.
RSVP LSP wird nur für den Link-Schutz und nicht für die Weiterleitung von Datenverkehr verwendet, während der zu schützende Link aktiv ist.
Reduziert die Gesamtzahl der im System erforderlichen RSVP-LSPs.
Unter Berücksichtigung des in Abbildung 3verwendeten Beispiels wird zum Schutz des Datenverkehrs vor dem potenziellen Ausfall der S-R1-Verbindung automatisch ein RSVP-Bypass-LSP für diesen bestimmten Link erstellt, da Router R4 keine LFA für diese bestimmte Verbindung ist, bei dem es sich um den Knoten auf der anderen Seite der geschützten Verbindung handelt, wie in Abbildung 5dargestellt. Von Router R1 wird der Datenverkehr an sein ursprüngliches Ziel, Router D, weitergeleitet.
Die RSVP-LSP ist in der Packet Forwarding Engine von Router S vorsignalisiert und vorinstalliert, sodass sie verwendet werden kann, sobald Router S erkennt, dass die Verbindung fehlgeschlagen ist.

Eine alternative Betriebsart besteht darin, LFA überhaupt nicht zu verwenden und immer die RSVP-LSP so zu erstellen, dass sie alle Verbindungsausfälle abdeckt.
Um dynamische RSVP-LSPs zu aktivieren, fügen Sie die dynamic-rsvp-lsp
Anweisung auf Hierarchieebene [edit protocols ldp interface interface-name link-protection]
ein, zusätzlich zum Aktivieren des RSVP-Protokolls auf den entsprechenden Schnittstellen.
Grundlegendes zum Schutz von Multicast-LDP-Verbindungen
Ein Punkt-zu-Mehrpunkt-LDP-Label-Switched-Pfad (LSP) ist ein LDP-signalisierter LSP, der Punkt-zu-Multipunkt ist und als Multicast-LDP bezeichnet wird.
Ein Multicast-LDP-LSP kann verwendet werden, um Datenverkehr von einem einzelnen Stamm- oder Eingangsknoten an eine Reihe von Blatt- oder Ausgangsknoten zu senden, die einen oder mehrere Transitknoten durchlaufen. Der Multicast-LDP-Link-Schutz ermöglicht im Falle eines Verbindungsausfalls eine schnelle Umleitung von Datenverkehr, der über Point-to-Multipoint-LDP-LSPs übertragen wird. Wenn eine der Verbindungen der Punkt-zu-Mehrpunkt-Struktur ausfällt, können die Unterstrukturen getrennt werden, bis der IGP wieder konvergiert und der Multipoint-LSP über den besten Pfad vom Downstream-Router zum neuen Upstream-Router eingerichtet wird.
Um den Datenverkehr zu schützen, der durch die Multicast-LDP-LSP fließt, können Sie einen expliziten Tunnel konfigurieren, der den Datenverkehr im Falle eines Verbindungsausfalls umleitet. Der explizite Pfad muss auf dem nächsten Downstream-Router enden. Die Reverse-Path-Weiterleitung für den Datenverkehr sollte erfolgreich sein.
Der Multicast-LDP-Link-Schutz führt die folgenden Features und Funktionen ein:
Verwendung von dynamischen RSVP LSP als Bypass-Tunnel
Das Explicit Route Object (ERO) des RSVP-LSP wird mithilfe von CSPF (Constrained Shortest Path First) berechnet, wobei die Einschränkung die zu vermeidende Verbindung darstellt. Der LSP wird immer dann signalisiert und dynamisch abgeschaltet, wenn ein Verbindungsschutz erforderlich ist.
Make-before-break
Die Make-before-Break-Funktion stellt sicher, dass beim Versuch, einen neuen LSP-Pfad zu signalisieren, nur minimaler Paketverlust auftritt, bevor der alte LSP-Pfad für den Multicast-LDP-LSP zerstört wird.
Gezielte LDP-Sitzung
Eine gezielte Nachbarschaft zum nachgeschalteten Label-Switching-Router (LSR) wird aus zwei Gründen erstellt:
Um die Sitzung nach einem Verbindungsausfall aufrechtzuerhalten.
So verwenden Sie die von der Sitzung empfangene Punkt-zu-Multipoint-Bezeichnung, um Datenverkehr an den nachgeschalteten LSR im RSVP-LSP-Umgehungstunnel zu senden.
Wenn der Downstream-LSR den Multicast-LDP-LSP mit dem Stammknoten und der LSP-ID einrichtet, verwendet er den Upstream-LSR, der sich auf dem besten Weg zum Stammknoten befindet.
Der Multicast-LDP-Link-Schutz ist nicht erforderlich, wenn mehrere Link-Nachbarschaften (parallele Verbindungen) zum nachgeschalteten LSR vorhanden sind.
Verschiedene Modi für die Bereitstellung von LDP-Link-Schutz
Im Folgenden stehen drei verschiedene Betriebsmodi für den Unicast- und Multicast-LDP-Link-Schutz zur Verfügung:
Case A: LFA only
Bei diesem Betriebsmodus wird der Multicast-LDP-Link-Schutz durch eine vorhandene lebensfähige schleifenfreie Alternative (LFA) bereitgestellt. In Ermangelung einer praktikablen LFA wird kein Verbindungsschutz für den Multicast-LDP-LSP bereitgestellt.
Case B: LFA and Dynamic RSVP LSP
Bei diesem Betriebsmodus wird der Multicast-LDP-Link-Schutz unter Verwendung einer vorhandenen funktionsfähigen LFA bereitgestellt. In Ermangelung einer funktionsfähigen LFA wird automatisch ein RSVP-Bypass-LSP erstellt, um den Verbindungsschutz für den Multicast-LDP-LSP bereitzustellen.
Case C: Dynamic RSVP LSP only
In dieser Betriebsart wird LFA nicht für den Verbindungsschutz verwendet. Der Multicast-LDP-Link-Schutz wird durch die Verwendung von automatisch erstellten RSVP-Bypass-LSPs bereitgestellt.
Abbildung 6 ist eine Beispieltopologie, die die verschiedenen Betriebsmodi für den Schutz von Multicast-LDP-Verbindungen veranschaulicht. Router R5 ist der Root, der mit zwei Leaf-Knoten, den Routern R3 und R4, verbunden ist. Router R0 und Router R1 sind die Upstream- bzw. Downstream-Label-Switched-Router (LSRs). Ein Multicast-LDP-LSP wird zwischen dem Stamm- und dem Blattknoten ausgeführt.

In Anbetracht der Tatsache, dass Router R0 den Multicast-LDP-LSP für den Fall schützen muss, dass die R0-R1-Verbindung ausfällt, funktionieren die verschiedenen Modi des Verbindungsschutzes wie folgt:
Case A: LFA only
Router R0 prüft, ob ein brauchbarer LFA-Pfad vorhanden ist, der die R0-R1-Verbindung vermeiden kann, um Router R1 zu erreichen. Basierend auf den Metriken ist Router R2 ein gültiger LFA-Pfad für die R0-R1-Verbindung und wird zur Weiterleitung von Unicast-LDP-Datenverkehr verwendet. Wenn mehrere Multicast-LDP-LSPs die R0-R1-Verbindung verwenden, wird dieselbe LFA (Router R2) für den Schutz der Multicast-LDP-Verbindung verwendet.
Wenn die R0-R1-Verbindung ausfällt, wird der Multicast-LDP-LSP-Datenverkehr von Router R0 auf den LFA-Pfad verschoben, und das Unicast-LDP-Label zum Erreichen von Router R1 (L100) wird auf das Multicast-LDP-Label (L21) geschoben.
Case B: LFA and Dynamic RSVP LSP
Router R0 prüft, ob ein brauchbarer LFA-Pfad vorhanden ist, der die R0-R1-Verbindung vermeiden kann, um Router R1 zu erreichen. Basierend auf den Metriken ist Router R2 ein gültiger LFA-Pfad für die R0-R1-Verbindung und wird zur Weiterleitung von Unicast-LDP-Datenverkehr verwendet. Wenn mehrere Multicast-LDP-LSPs die R0-R1-Verbindung verwenden, wird dieselbe LFA (Router R2) für den Schutz der Multicast-LDP-Verbindung verwendet. Wenn die R0-R1-Verbindung ausfällt, wird der Multicast-LDP-LSP-Datenverkehr von Router R0 auf den LFA-Pfad verschoben.
Wenn die Metrik für die R2-R1-Verbindung jedoch 50 statt 10 war, ist Router 2 keine gültige LFA für die R0-R1-Verbindung. In diesem Fall wird automatisch ein RSVP-LSP erstellt, um den Multicast-LDP-Datenverkehr zwischen den Routern R0 und R1 zu schützen.
Case C: Dynamic RSVP LSP only
Ein RSVP-LSP wird automatisch von Router R0 über Router R2 an Router R1 signalisiert, wodurch die Schnittstelle ge-1/1/0 vermieden wird. Wenn mehrere Multicast-LDP-LSPs die R0-R1-Verbindung verwenden, wird dieselbe RSVP-LSP für den Schutz der Multicast-LDP-Verbindung verwendet.
Wenn die R0-R1-Verbindung ausfällt, wird der Multicast-LDP-LSP-Datenverkehr von Router R0 auf den RSVP-LSP verschoben, und das RSVP-Label zum Erreichen von Router R1 (L100) wird auf das Multicast-LDP-Label (L21) geschoben.
Label-Operation für den LDP-Link-Schutz
Unter Verwendung der gleichen Netzwerktopologie wie in Abbildung 5 Abbildung 7 wird der Bezeichnungsvorgang für den Unicast- und Multicast-LDP-Verbindungsschutz veranschaulicht.

Router R5 ist der Root, der mit zwei Leaf-Knoten, den Routern R3 und R4, verbunden ist. Router R0 und Router R1 sind die Upstream- bzw. Downstream-Label-Switched-Router (LSRs). Ein Multicast-LDP-LSP wird zwischen dem Stamm- und dem Blattknoten ausgeführt. Ein Unicast-LDP-Pfad verbindet Router R1 mit Router R5.
Der Label-Vorgang wird in den folgenden Modi des LDP-Link-Schutzes unterschiedlich ausgeführt:
Fall A: Nur LFA
Mit der show route detail
Befehlsausgabe auf Router R0 kann der Unicast-LDP-Datenverkehr und der Multicast-LDP-Datenverkehr abgeleitet werden.
user@R0> show route detail 299840 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Router Address: 0x93bc22c Next-hop reference count: 1 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1, selected Label operation: Swap 299824 Session Id: 0x1 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0xf000 Label operation: Swap 299808 Session Id: 0x3 State: <Active Int> Age: 3:16 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I Prefixes bound to route: 192.168.0.4/32 299856 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x9340e04 Next-hop reference count: 3 Next hop type: Router, Next hop index: 262143 Address: 0x93bc3dc Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1 Label operation: Swap 299888 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0xf000 Label operation: Swap 299888, Push 299776(top) Label TTL action: prop-ttl, prop-ttl(top) State: <Active Int AckRequest> Age: 3:16 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 192.168.0.5, lsp-id 99
Bei der Bezeichnung 299840 handelt es sich um Datenverkehr, der an Router R0 eingeht und dem Unicast-LDP-Datenverkehr an Router R1 entspricht. Label 299856 ist der an Router 0 eingehende Datenverkehr, der dem Multicast-LDP-Datenverkehr vom Stammknoten R5 zu den Leaf-Ausgangsknoten R3 und R4 entspricht.
Der Hauptpfad für Unicast- und Multicast-LDP-LSPs führt über die Schnittstelle ge-0/0/1 (die Verbindung zu Router R1) und der LFA-Pfad über die Schnittstelle ge-0/0/2 (die Verbindung zu Router R2). Der LFA-Pfad wird nur verwendet, wenn die ge-0/0/1-Schnittstelle ausfällt.
Bei der Label-Operation für Fall A unterscheidet sich der Nur-LFA-Betriebsmodus für Unicast- und Multicast-LDP-Datenverkehr:
Unicast-Label-Operation
Bei Unicast-LDP-Datenverkehr werden die FECs und die zugehörigen Bezeichnungen auf allen Verbindungen im Netzwerk angekündigt, auf denen LDP aktiviert ist. Dies bedeutet, dass Router R0 zum Bereitstellen einer LFA-Aktion für den Unicast-LDP-Datenverkehr zu Router R4 anstelle des Austauschs des eingehenden Labels gegen das von Router R1 für FEC R4 angekündigte Label 299824 Label-299808 einfach das eingehende Label gegen das Label austauscht, das von Router R2 für FEC R4 angekündigt wird. Dies ist der standardmäßige Junos OS LFA-Vorgang für Unicast-LDP-Datenverkehr.
Abbildung 8 Veranschaulicht den Bezeichnungsvorgang für Unicastdatenverkehr, wenn die R0-R1-Verbindung fehlschlägt. Die grauen Kästchen zeigen den Bezeichnungsvorgang für Unicast-LDP-Datenverkehr unter normalen Bedingungen, und die gepunkteten Kästchen zeigen den Bezeichnungsvorgang für Unicast-LDP-Datenverkehr, wenn die R0-R1-Verbindung fehlschlägt.
Abbildung 8: Unicast-LDP-Label-OperationMulticast-Label-Vorgang
Der Bezeichnungsvorgang für Multicast-LDP-Datenverkehr unterscheidet sich vom Unicast-LDP-Bezeichnungsvorgang, da Multipoint-LSP-Bezeichnungen nur entlang des besten Pfads vom Blattknoten zum Eingangsknoten angekündigt werden. Infolgedessen hat Router R2 keine Kenntnis vom Multicast-LDP. Um dieses Problem zu lösen, wird der Multicast-LDP-LSP-Datenverkehr einfach innerhalb des Unicast-LDP-LSP-Pfads durch Router R2 getunnelt, der bei Router R1 endet.
Um dies zu erreichen, tauscht Router R0 zunächst das eingehende Multicast-LDP-LSP-Label 299856 gegen das Label 299888 aus, das von Router R1 angekündigt wird. Das Etikett 299776 wird dann oben aufgeschoben, wobei es sich um das LDP-Etikett handelt, das von Router R2 für FEC R1 angekündigt wird. Wenn das Paket bei Router R2 eintrifft, wird das oberste Label aufgrund des vorletzten Hop-Poppings herausgeklappt. Dies bedeutet, dass das Paket bei Router R1 mit dem Multicast-LDP-Label 299888 ankommt, das Router R1 ursprünglich Router R0 angekündigt hatte.
Abbildung 9 veranschaulicht den Bezeichnungsvorgang für Multicast-LDP-Datenverkehr, wenn die R0-R1-Verbindung ausfällt. Die blauen Kästchen zeigen den Bezeichnungsvorgang für Multicast-LDP-Datenverkehr unter normalen Bedingungen, und die gepunkteten Kästchen zeigen den Bezeichnungsvorgang für Multicast-LDP-Datenverkehr, wenn die R0-R1-Verbindung fehlschlägt.
Abbildung 9: Multicast-LDP-Label-Vorgang
Wenn die Metrik für die R2-R1-Verbindung auf 1000 statt auf 1 festgelegt ist, ist Router R2 keine gültige LFA für Router R0. Wenn in diesem Fall Router R2 ein Paket empfängt, das für Router R1, R3 oder R4 bestimmt ist, bevor sein IGP konvergiert ist, wird das Paket an Router R0 zurückgesendet, was zu Schleifenpaketen führt.
Da Router R0 über keine brauchbare LFA verfügt, werden keine Sicherungspfade in der Packet Forwarding Engine installiert. Wenn die R0-R1-Verbindung ausfällt, wird der Datenverkehrsfluss unterbrochen, bis IGP und LDP konvergieren und neue Einträge auf den betroffenen Routern installiert werden.
Der show route detail
Befehl zeigt den Status an, wenn keine LFA für den Linkschutz verfügbar ist.
user@host> show route detail 299840 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Router, Next hop index: 578 Address: 0x9340d20 Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0, selected Label operation: Swap 299824 Session Id: 0x1 State: <Active Int> Age: 5:38 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I Prefixes bound to route: 192.168.0.4/32 299856 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x9340e04 Next-hop reference count: 3 Next hop type: Router, Next hop index: 579 Address: 0x93407c8 Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0 Label operation: Swap 299888 State: <Active Int AckRequest> Age: 5:38 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 192.168.0.5, lsp-id 99
Fall B: LFA und Dynamic RSVP LSP
Wenn in diesem Betriebsmodus ein brauchbarer LFA-Nachbar vorhanden ist, ähnelt das Verhalten des Label-Vorgangs dem von Fall A, reiner LFA-Modus. Wenn jedoch kein brauchbarer LFA-Nachbar vorhanden ist, wird automatisch ein RSVP-Bypass-Tunnel erstellt.
Wenn die Metrik für die Verbindung R2-R1 auf 1000 statt auf 1 festgelegt ist, ist Router R2 keine LFA für Router R0. Wenn festgestellt wird, dass es keine LFA-Pfade zum Schutz vor dem Ausfall der R0-R1-Verbindung gibt, wird automatisch ein RSVP-Bypass-Tunnel mit Router R1 als Ausgangsknoten erstellt, der einem Pfad folgt, der die R0-R1-Verbindung umgeht (z. B. R0-R2-R1).
Wenn die R0-R1-Verbindung ausfällt, wird der Unicast-LDP- und Multicast-LDP-Datenverkehr durch den RSVP-Bypass-Tunnel getunnelt. Der RSVP-Bypass-Tunnel wird nicht für die normale Weiterleitung verwendet und dient nur dazu, den Verbindungsschutz für den LDP-Datenverkehr im Falle eines Ausfalls der R0-R1-Verbindung zu gewährleisten.
Mit dem show route detail
Befehl kann der Unicast- und Multicast-LDP-Datenverkehr abgeleitet werden.
user@host> show route detail 299840 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Router Address: 0x940c3dc Next-hop reference count: 1 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1, selected Label operation: Swap 299824 Session Id: 0x1 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0x8001 Label-switched-path ge-0/0/1.0:BypassLSP->192.168.0.1 Label operation: Swap 299824, Push 299872(top) Label TTL action: prop-ttl, prop-ttl(top) Session Id: 0x3 State: <Active Int NhAckRequest> Age: 19 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I Prefixes bound to route: 192.168.0.4/32 299856 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x9340e04 Next-hop reference count: 3 Next hop type: Router, Next hop index: 262143 Address: 0x940c154 Next-hop reference count: 2 Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1 Label operation: Swap 299888 Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0x8001 Label-switched-path ge-0/0/1.0:BypassLSP->192.168.0.1 Label operation: Swap 299888, Push 299872(top) Label TTL action: prop-ttl, prop-ttl(top) State: < Active Int AckRequest> Age: 20 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 192.168.0.5, lsp-id 99
Der Hauptpfad für Unicast- und Multicast-LDP-LSP führt über die Schnittstelle ge-0/0/1 (die Verbindung zu Router R1) und der LFA-Pfad über die Schnittstelle ge-0/0/2 (die Verbindung zu Router R2). Der LFA-Pfad wird nur verwendet, wenn die ge-0/0/1-Schnittstelle ausfällt.
Bei der Bezeichnung 299840 handelt es sich um Datenverkehr, der an Router R0 eingeht und dem Unicast-LDP-Datenverkehr an Router R4 entspricht. Label 299856 ist der an Router 0 eingehende Datenverkehr, der dem Multicast-LDP-Datenverkehr vom Stammknoten R5 zu den Leaf-Ausgangsknoten R3 und R4 entspricht.
Wie in der show route detail
Befehlsausgabe zu sehen ist, sind die Bezeichnungsvorgänge für den Schutzpfad für Unicast-LDP- und Multicast-LDP-Datenverkehr identisch. Die eingehende LDP-Bezeichnung an Router R0 wird durch die LDP-Bezeichnung ersetzt, die von Router R1 für Router R0 angekündigt wird. Das RSVP-Label, das für den Umgehungstunnel 299872, wird dann auf das Paket übertragen. Das vorletzte Hop-Popping wird im Bypass-Tunnel verwendet, was dazu führt, dass Router R2 dieses Label platzen lässt. Daher kommt das Paket bei Router R1 mit der LDP-Bezeichnung an, die es ursprünglich für Router R0 angekündigt hatte.
Abbildung 10 veranschaulicht den Bezeichnungsvorgang für Unicast-LDP- und Multicast-LDP-Datenverkehr, der durch den RSVP-Bypass-Tunnel geschützt ist. Die grauen und blauen Kästchen stellen Beschriftungswerte dar, die unter normalen Bedingungen für Unicast- bzw. Multicast-LDP-Datenverkehr verwendet werden. Die gepunkteten Felder stellen Beschriftungswerte dar, die verwendet werden, wenn die Verbindung R0-R1 fehlschlägt.

Fall C: Dynamische RSVP, nur LSP
In dieser Betriebsart wird LFA überhaupt nicht verwendet. Ein dynamischer RSVP-Bypass-LSP wird automatisch erstellt, um den Link-Schutz zu gewährleisten. Die Ausgabe des show route detail
Befehls und der Beschriftungsvorgänge ähnelt dem Modus Fall B, LFA und dynamischem RSVP-LSP.
Beispiel für eine Multicast-LDP-Link-Schutzkonfiguration
Um den Multicast-LDP-Link-Schutz zu aktivieren, ist die folgende Konfiguration auf Router R0 erforderlich:
In diesem Beispiel ist der Multicast-LDP-Link-Schutz auf der ge-1/0/0-Schnittstelle des Routers R0 aktiviert, der eine Verbindung zu Router R1 herstellt, obwohl in der Regel alle Schnittstellen für den Linkschutz konfiguriert werden müssen.
Router R0
protocols { rsvp { interface all; interface ge-0/0/0.0 { disable; } } mpls { interface all; interface ge-0/0/0.0 { disable; } } ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0; interface ge-0/0/1.0 { link-protection; } interface ge-0/0/2.0; interface ge-0/0/3.0; } } ldp { make-before-break { timeout seconds; switchover-delay seconds; } interface ge-1/1/0.0 { link-protection { disable; dynamic-rsvp-lsp; } } } }
Die folgenden Konfigurationsanweisungen gelten für die verschiedenen Modi des Multicast-LDP-Schutzes wie folgt:
link-protection
Statement bei[edit protocols ospf interface ge-0/0/1.0]
Diese Konfiguration wird nur für die Modi Fall A (nur LFA) und Fall B (LFA und dynamisches RSVP LSP) des Multicast-LDP-Link-Schutzes angewendet. Die Konfiguration des Link-Schutzes unter einer IGP ist für Fall C (nur dynamisches RSVP, LSP) nicht erforderlich.
link-protection
Statement bei[edit protocols ldp interface ge-0/0/1.0]
Diese Konfiguration ist für alle Modi des Multicast-LDP-Schutzes erforderlich. Wenn jedoch nur Unicast-Datenverkehr vorhanden ist und keine dynamischen RSVP-Umgehungen erforderlich sind, ist diese Konfiguration nicht erforderlich, da die
link-protection
Anweisung auf Hierarchieebene[edit protocols ospf interface ge-0/0/1.0]
zu einer LFA-Aktion für den LDP-Unicast-Datenverkehr führt.dynamic-rsvp-lsp
Statement bei[edit protocols ldp interface ge-0/0/1.0 link-protection]
Diese Konfiguration wird nur für die Modi Fall B (LFA und dynamisches RSVP LSP) und Fall C (nur dynamisches RSVP LSP) des LDP-Link-Schutzes angewendet. Die dynamische RSVP-LSP-Konfiguration gilt nicht für Fall A (nur LFA).
Make-Before-Break
Die Make-before-Break-Funktion ist unter Junos OS standardmäßig aktiviert und bietet einige Vorteile für Point-to-Multipoint-LSPs.
Bei einem Punkt-zu-Mehrpunkt-LSP wählt ein Label-Switched-Router (LSR) den LSR aus, der sein nächster Hop zum Stamm des LSP ist, als Upstream-LSR. Wenn sich der beste Pfad zum Erreichen der Wurzel ändert, wählt der LSR einen neuen Upstream-LSR aus. Während dieses Zeitraums kann der LSP vorübergehend unterbrochen werden, was zu Paketverlusten führt, bis der LSP wieder zu einem neuen Upstream-LSR konvergiert. Das Ziel von Make-before-break ist in diesem Fall, den Paketverlust zu minimieren. In Fällen, in denen sich der beste Pfad vom LSR zum Stammverzeichnis ändert, der LSP aber weiterhin Datenverkehr an den vorherigen nächsten Hop zum Stammverzeichnis weiterleitet, sollte ein neuer LSP eingerichtet werden, bevor der alte LSP zurückgezogen wird, um die Dauer des Paketverlusts zu minimieren.
Beispielsweise empfängt ein Downstream-LSR (z. B. LSR-D) nach einem Verbindungsausfall immer noch Pakete an die anderen Downstream-LSRs, da es weiterhin Pakete vom One-Hop-RSVP-LSP empfängt. Sobald das Routing konvergiert, wählt LSR-D ein neues Upstream-LSR (LSR-U) für die FEC (FEC-A) dieses Punkt-zu-Mehrpunkt-LSP aus. Der neue LSR leitet möglicherweise bereits Pakete für FEC-A an andere nachgeschaltete LSRs als LSR-D weiter. Nachdem LSR-U ein Label für FEC-A von LSR-D erhalten hat, benachrichtigt es LSR-D, wenn es erfahren hat, dass LSP für FEC-A von der Wurzel bis zu sich selbst eingerichtet wurde. Wenn LSR-D eine solche Benachrichtigung erhält, ändert es seinen nächsten Hop für den LSP-Stamm in LSR-U. Hierbei handelt es sich um einen Vorgang zum Löschen und Hinzufügen von Routen auf LSR-D. An diesem Punkt führt LSR-D einen LSP-Switchover durch, und der Datenverkehr, der über RSVP, LSP oder LFA getunnelt wird, wird verworfen, und der Datenverkehr von LSR-U wird akzeptiert. Die neue Transitroute für LSR-U wird hinzugefügt. Die RPF-Prüfung wird so geändert, dass Datenverkehr von LSR-U akzeptiert und Datenverkehr vom alten Upstream-LSR verworfen wird, oder die alte Route wird gelöscht und die neue Route hinzugefügt.
Es wird davon ausgegangen, dass LSR-U von seinem Upstream-Router eine Make-before-Break-Benachrichtigung für den FEC-A Point-to-Multipoint-LSP erhalten und einen Weiterleitungsstatus für den LSP installiert hat. Zu diesem Zeitpunkt sollte es LSR-D durch eine Make-before-Break-Benachrichtigung signalisieren, dass es Teil des von FEC-A identifizierten Baums geworden ist und dass LSR-D seine Umschaltung auf den LSP einleiten soll. Andernfalls sollte LSR-U daran denken, dass es eine Benachrichtigung an LSR-D senden muss, wenn es eine Make-before-Break-Benachrichtigung vom Upstream-LSR für FEC-A erhält und einen Weiterleitungsstatus für diesen LSP installiert. LSR-D empfängt weiterhin Datenverkehr vom alten nächsten Hop zum Stammknoten über einen Hop-, RSVP-, LSP- oder LFA-Pfad, bis er zum neuen Punkt-zu-Multipoint-LSP zu LSR-U wechselt.
Die Make-before-Break-Funktion mit Multicast-LDP-Link-Schutz umfasst die folgenden Funktionen:
Make-before-Break-Fähigkeit
Ein LSR wirbt damit, dass er in der Lage ist, Make-before-Break-LSPs mit der Capability-Ankündigung zu handhaben. Wenn der Peer nicht Make-before-Break-fähig ist, werden die Make-before-Break-Parameter nicht an diesen Peer gesendet. Wenn ein LSR einen Make-before-Break-Parameter von einem Downstream-LSR (LSR-D) empfängt, der Upstream-LSR (LSR-U) jedoch nicht Make-before-Break-fähig ist, sendet der LSR sofort eine Make-before-Break-Benachrichtigung an LSR-D, und der Make-before-Break-fähige LSP wird nicht eingerichtet. Stattdessen wird der normale LSP eingerichtet.
Statuscode "Make-before-break"
Der Make-before-Break-Statuscode umfasst:
1 – Make-Before-Break-Anfrage
2 – Make-before-Break-Bestätigung
Wenn ein nachgeschalteter LSR eine Labelzuordnungsnachricht für Punkt-zu-Mehrpunkt-LSP sendet, enthält er den Make-before-Break-Statuscode 1 (Anforderung). Wenn der Upstream-LSR den Weiterleitungsstatus für den Point-to-Multipoint-LSP aktualisiert, informiert er den Downstream-LSR mit einer Benachrichtigung, die den Make-before-Break-Statuscode 2 (Bestätigung) enthält. An diesem Punkt führt das nachgeschaltete LSR eine LSP-Umschaltung durch.
Vorsichtsmaßnahmen und Einschränkungen
Für die Junos OS-Implementierung der LDP-Verbindungsschutzfunktion gelten die folgenden Einschränkungen:
Make-before-break wird für die folgenden Punkt-zu-Mehrpunkt-LSPs auf einem Ausgangs-LSR nicht unterstützt:
Multicast Virtual Private Network (MVPN) der nächsten Generation mit virtuellem Routing- und Weiterleitungslabel (VRF)
Statischer Sprachdienstleister
Die folgenden Funktionen werden nicht unterstützt:
Unterbrechungsfreies aktives Routing für Punkt-zu-Multipoint-LSP in den Junos OS-Versionen 12.3, 13.1 und 13.2
Graceful-Restart-Switchover Punkt-zu-Multipoint-LSP
Link-Schutz für Routing-Instanz
Beispiel: Konfigurieren des LDP-Link-Schutzes
In diesem Beispiel wird gezeigt, wie der LDP-Verbindungsschutz (Label Distribution Protocol) für Unicast- und Multicast-LDP-LSPs (Label Switched Paths) konfiguriert wird.
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Sechs Router, bei denen es sich um eine Kombination aus Routern der M-Serie, MX-Serie oder T-Serie mit einem Root-Knoten und zwei Leaf-Knoten handeln kann, auf denen ein Point-to-Multipoint-LDP-LSP ausgeführt wird.
Junos OS Version 12.3 oder höher, das auf allen Routern ausgeführt wird.
Bevor Sie beginnen:
Konfigurieren Sie die Geräteschnittstellen.
Konfigurieren Sie die folgenden Protokolle:
RSVP
MPLS
OSPF oder eine andere IGP
LDP
Überblick
Der LDP-Link-Schutz ermöglicht im Falle eines Verbindungsausfalls eine schnelle Umleitung von Datenverkehr, der über LDP-LSPs übertragen wird. LDP-Punkt-zu-Multipunkt-LSPs können verwendet werden, um Datenverkehr von einem einzelnen Stamm- oder Eingangsknoten an eine Reihe von Blattknoten oder Ausgangsknoten zu senden, die einen oder mehrere Transitknoten durchlaufen. Wenn eine der Verbindungen der Punkt-zu-Mehrpunkt-Struktur ausfällt, können die Teilstrukturen getrennt werden, bis der IGP wieder konvergiert und Multicast-LDP die Labelzuordnung unter Verwendung des besten Pfads vom Downstream-Router zum neuen Upstream-Router initiiert. Um den Datenverkehr im Falle eines Verbindungsausfalls zu schützen, können Sie einen expliziten Tunnel konfigurieren, sodass der Datenverkehr über den Tunnel umgeleitet werden kann. Junos OS unterstützt Make-before-Break-Funktionen, um einen minimalen Paketverlust zu gewährleisten, wenn versucht wird, einen neuen LSP-Pfad zu signalisieren, bevor der alte LSP-Pfad gelöscht wird. Diese Funktion bietet auch gezielte LDP-Unterstützung für den Multicast-LDP-Link-Schutz.
Beachten Sie bei der Konfiguration des LDP-Verbindungsschutzes die folgenden Überlegungen:
Konfigurieren Sie Traffic Engineering unter IGP (falls es nicht standardmäßig unterstützt wird), und schließen Sie die für MPLS und RSVP konfigurierten Schnittstellen ein, sodass das auf Einschränkungen basierende, verbindungsgeschützte dynamische RSVP-LSP von RSVP mithilfe von CSPF (Constrained Shortest Path First) signalisiert wird. Wenn diese Bedingung nicht erfüllt ist, wird RSVP-LSP möglicherweise nicht aktiviert, und LDP kann es nicht als geschützten nächsten Hop verwenden.
Konfigurieren Sie einen Pfad zwischen zwei Label-Switched-Routern (LSRs), um bei einem Verbindungsausfall IP-Konnektivität zwischen den Routern bereitzustellen. Auf diese Weise kann CSPF einen alternativen Pfad für den Link-Schutz berechnen. Wenn die Verbindung zwischen den Routern unterbrochen wird, wird die LDP-Zielnachbarschaft nicht aktiviert, und dynamisches RSVP-LSP kann nicht signalisiert werden, was dazu führt, dass die LDP-Weiterleitungsäquivalenzklasse (FEC), für die der Peer der Downstream-LSR ist, nicht geschützt ist.
Wenn der Linkschutz nur auf einem LSR aktiv ist, sollte der andere LSR nicht mit der
strict-targeted-hellos
Anweisung konfiguriert werden. Dadurch kann der LSR ohne Verbindungsschutz die asymmetrische Erkennung von Remotenachbarn zulassen und regelmäßig gezielte Hallos an den LSR senden, der den Remotenachbarn initiiert hat. Wenn diese Bedingung nicht erfüllt ist, wird keine LDP-gezielte Nachbarschaft gebildet.LDP muss auf der Loopback-Schnittstelle des LSR aktiviert sein, um Remote-Nachbarn basierend auf LDP-Tunneling, LDP-basiertem VPLS (Virtual Private LAN Service), Layer-2-Verbindungen oder LDP-Sitzungsschutz zu erstellen. Wenn diese Bedingung nicht erfüllt ist, wird keine LDP-gezielte Nachbarschaft gebildet.
Für Unicast-LDP-LSP sollte LFA (Loop-Free Alternate) in IGP konfiguriert werden.
Die Eingangsroute zum Zusammenführungspunkt sollte mindestens einen nächsten Hop aufweisen, um die primäre Verbindung zwischen dem Zusammenführungspunkt und dem Punkt der lokalen Reparatur für Unicast-LDP-LSP zu vermeiden.
Der Punkt der lokalen Reparatur sollte über eine Unicast-LDP-Bezeichnung für den nächsten Hop der Sicherung verfügen, um den Zusammenführungspunkt zu erreichen.
Topologie

In diesem Beispiel ist Router R5 der Stamm, der eine Verbindung zu den beiden Leaf-Knoten R3 und R4 herstellt. Router R0 ist der Ort für die lokale Reparatur.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für 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
.
R5
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.5/32 set routing-options router-id 10.255.1.5 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 20.10.10.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 30.10.10.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.0/32 set routing-options router-id 10.255.1.0 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R1
set interfaces ge-0/0/0 unit 0 family inet address 60.10.10.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 40.10.10.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 30.10.10.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 50.10.10.1/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.1/32 set routing-options router-id 10.255.1.1 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R2
set interfaces ge-0/0/0 unit 0 family inet address 60.10.10.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 20.10.10.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.2/32 set routing-options router-id 10.255.1.2 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp
R3
set interfaces ge-0/0/1 unit 0 family inet address 40.10.10.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.3/32 set routing-options router-id 10.255.1.3 set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp root-address 10.255.1.5 lsp-id 1
R4
set interfaces ge-0/0/3 unit 0 family inet address 50.10.10.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.1.4/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all metric 1 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface all link-protection dynamic-rsvp-lsp set protocols ldp interface fxp0.0 disable set protocols ldp p2mp root-address 10.255.1.5 lsp-id 1
Verfahren
Schritt-für-Schritt-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.
So konfigurieren Sie Router R0:
Konfigurieren Sie die Schnittstellen des Routers R0.
[edit interfaces]
user@R0# set ge-0/0/0 unit 0 family inet address 10.10.10.2/30 user@R0# set ge-0/0/0 unit 0 family mpls user@R0# set ge-0/0/1 unit 0 family inet address 20.10.10.1/30 user@R0# set ge-0/0/1 unit 0 family mpls user@R0# set ge-0/0/2 unit 0 family inet address 30.10.10.1/30 user@R0# set ge-0/0/2 unit 0 family mpls user@R0# set lo0 unit 0 family inet address 10.255.1.0/32Konfigurieren Sie die Router-ID und das autonome System des Routers R0.
[edit routing-options]
user@R0# set router-id 10.255.1.0 user@R0# set autonomous-system 100Aktivieren Sie RSVP auf allen Schnittstellen des Routers R0 (mit Ausnahme der Verwaltungsschnittstelle).
[edit protocols]
user@R0# set rsvp interface all user@R0# set rsvp interface fxp0.0 disableAktivieren Sie MPLS auf allen Schnittstellen des Routers R0 (mit Ausnahme der Verwaltungsschnittstelle) zusammen mit Traffic-Engineering-Funktionen.
[edit protocols]
user@R0# set mpls traffic-engineering user@R0# set mpls interface all user@R0# set mpls interface fxp0.0 disableAktivieren Sie OSPF auf allen Schnittstellen des Routers R0 (mit Ausnahme der Verwaltungsschnittstelle), weisen Sie den Verbindungen die gleiche Kostenmetrik zu und aktivieren Sie die Traffic-Engineering-Funktionen.
[edit protocols]
user@R0# set ospf traffic-engineering user@R0# set ospf area 0.0.0.0 interface all metric 1 user@R0# set ospf area 0.0.0.0 interface fxp0.0 disableHINWEIS:Aktivieren Sie für den Multicast-LDP-Link-Schutz mit schleifenfreier Alternative (LFA) die folgende Konfiguration unter der Hierarchieebene
[edit protocols]
:set ospf area 0 interface all link-protection
Aktivieren Sie LDP auf allen Schnittstellen des Routers R0 (mit Ausnahme der Verwaltungsschnittstelle) und konfigurieren Sie den Verbindungsschutz mit dynamischem RSVP-Bypass-LSP.
[edit protocols]
user@R0# set ldp interface all link-protection dynamic-rsvp-lsp user@R0# set ldp interface fxp0.0 disable user@R0# set ldp p2mp
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfaces
Befehle , show routing-options
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.
user@R0# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.10.10.2/30; } family mpls; } } ge-0/0/1 { unit 0 { family inet { address 20.10.10.1/30; } family mpls; } } ge-0/0/2 { unit 0 { family inet { address 30.10.10.1/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.255.1.0/32; } } }
user@R0# show routing-options router-id 10.255.1.0; autonomous-system 100;
user@R0# show protocols rsvp { interface all; interface fxp0.0 { disable; } } mpls { traffic-engineering; interface all; interface fxp0.0 { disable; } } ospf { traffic-engineering; area 0.0.0.0 { interface all { metric 1; } interface fxp0.0 { disable; } } } ldp { interface all { link-protection { dynamic-rsvp-lsp; } } interface fxp0.0 { disable; } p2mp; }
Verifizierung
Überprüfen Sie, ob die Konfiguration ordnungsgemäß funktioniert.
Überprüfen des Umgehungs-RSVP-LSP-Pfads
Zweck
Stellen Sie sicher, dass der Umgehungs-RSVP-LSP-Pfad am Punkt der lokalen Reparatur (PLR) erstellt wurde.
Action!
Führen Sie den show route tale mpls.0
Befehl im Betriebsmodus aus.
user@R0> show route tale mpls.0 mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 05:28:13, metric 1 Receive 1 *[MPLS/0] 05:28:13, metric 1 Receive 2 *[MPLS/0] 05:28:13, metric 1 Receive 13 *[MPLS/0] 05:28:13, metric 1 Receive 299792 *[LDP/9] 00:41:41, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Pop 299792(S=0) *[LDP/9] 00:41:41, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Pop 299808 *[LDP/9] 00:41:41, metric 1 > to 20.10.10.2 via ge-0/0/1.0, Pop 299808(S=0) *[LDP/9] 00:41:41, metric 1 > to 20.10.10.2 via ge-0/0/1.0, Pop 299920 *[RSVP/7/1] 01:51:43, metric 1 > to 30.10.10.2 via ge-0/0/2.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.1 299920(S=0) *[RSVP/7/1] 01:51:43, metric 1 > to 30.10.10.2 via ge-0/0/2.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.1 299936 *[RSVP/7/1] 01:51:25, metric 1 > to 20.10.10.2 via ge-0/0/1.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.2 299936(S=0) *[RSVP/7/1] 01:51:25, metric 1 > to 20.10.10.2 via ge-0/0/1.0, label-switched-path ge-0/0/0.0:BypassLSP->10.255.1.2 299952 *[LDP/9] 00:06:11, metric 1 > to 10.10.10.1 via ge-0/0/0.0, Pop 299952(S=0) *[LDP/9] 00:06:11, metric 1 > to 10.10.10.1 via ge-0/0/0.0, Pop 299968 *[LDP/9] 00:05:39, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Swap 299984 299984 *[LDP/9] 00:05:38, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Swap 300000 300000 *[LDP/9] 00:05:15, metric 1 > to 30.10.10.2 via ge-0/0/2.0, Swap 300016
Bedeutung
Wenn die R0-R1-Verbindung ausfällt, wird die RSVP-Umgehungs-LSP zum Weiterleiten des Datenverkehrs verwendet.
Überprüfen des Etikettierungsvorgangs
Zweck
Überprüfen Sie, ob das Etikett im PLR ausgetauscht wurde.
Action!
Führen Sie den show route table mpls.0 label label extensive
Befehl im Betriebsmodus aus.
user@R0> show route table mpls.0 label 300000 extensive mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) 300000 (1 entry, 1 announced) TSI: KRT in-kernel 300000 /52 -> {Swap 300016} *LDP Preference: 9 Next hop type: Router, Next hop index: 589 Address: 0x9981610 Next-hop reference count: 2 Next hop: 30.10.10.2 via ge-0/0/2.0, selected Label operation: Swap 300016 Load balance label: Label 300016: None; Session Id: 0x2 State: <Active Int> Local AS: 100 Age: 12:50 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 1-KRT AS path: I Prefixes bound to route: 10.255.1.4/32
Bedeutung
Die Bezeichnung muss Router R4 erreichen, bei dem es sich um einen Leaf-Knoten handelt.
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.
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
- PIM-Funktionalität
- Multipoint-LDP-Funktionalität
- Paketweiterleitung
- Einschränkungen und Vorbehalte
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).

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.


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.

Einschränkungen und Vorbehalte
- MoFRR-Einschränkungen und Vorbehalte bei Switching- und Routing-Geräten
- MoFRR-Einschränkungen beim Switching von Geräten mit PIM
- MoFRR-Einschränkungen und Vorsichtsmaßnahmen bei Routing-Geräten mit Multipoint-LDP
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 wieInput packets
undOutput packets
hö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:
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:
stream-protection { policy policy-name; }
Topologie
Abbildung 16 zeigt das Beispielnetzwerk an.

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
set interfaces ge-1/2/10 unit 0 description src1-to-R1 set interfaces ge-1/2/10 unit 0 family inet address 10.5.0.1/30 set interfaces ge-1/2/11 unit 0 description src1-to-R1 set interfaces ge-1/2/11 unit 0 family inet address 192.168.219.11/24 set interfaces lo0 unit 0 family inet address 10.0.1.17/32 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive
Gerät src2
set interfaces ge-1/2/24 unit 0 description src2-to-R5 set interfaces ge-1/2/24 unit 0 family inet address 10.5.0.2/30 set interfaces lo0 unit 0 family inet address 10.0.1.18/32 set protocols rsvp interface all set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive
Gerät R1
set interfaces ge-1/2/12 unit 0 description R1-to-R2 set interfaces ge-1/2/12 unit 0 family inet address 10.1.2.1/30 set interfaces ge-1/2/12 unit 0 family mpls set interfaces ge-1/2/13 unit 0 description R1-to-R6 set interfaces ge-1/2/13 unit 0 family inet address 10.1.6.1/30 set interfaces ge-1/2/13 unit 0 family mpls set interfaces ge-1/2/10 unit 0 description R1-to-src1 set interfaces ge-1/2/10 unit 0 family inet address 10.1.0.2/30 set interfaces ge-1/2/11 unit 0 description R1-to-src1 set interfaces ge-1/2/11 unit 0 family inet address 192.168.219.9/30 set interfaces lo0 unit 0 family inet address 10.1.1.1/32 set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 10.1.1.1 set protocols bgp group ibgp export static-route-tobgp set protocols bgp group ibgp peer-as 65010 set protocols bgp group ibgp neighbor 10.1.1.3 set protocols bgp group ibgp neighbor 10.1.1.7 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface ge-1/2/12.0 set protocols ldp interface ge-1/2/13.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim rp static address 10.1.1.5 set protocols pim interface lo0.0 set protocols pim interface ge-1/2/10.0 set protocols pim interface ge-1/2/11.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 10.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 10.1.1.7/32 orlonger set policy-options policy-statement mldppim-ex term A from source-address-filter 10.1.0.0/30 orlonger set policy-options policy-statement mldppim-ex term A then accept set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set routing-options autonomous-system 65010
Gerät R2
set interfaces ge-1/2/12 unit 0 description R2-to-R1 set interfaces ge-1/2/12 unit 0 family inet address 10.1.2.2/30 set interfaces ge-1/2/12 unit 0 family mpls set interfaces ge-1/2/14 unit 0 description R2-to-R3 set interfaces ge-1/2/14 unit 0 family inet address 10.2.3.1/30 set interfaces ge-1/2/14 unit 0 family mpls set interfaces ge-1/2/16 unit 0 description R2-to-R5 set interfaces ge-1/2/16 unit 0 family inet address 10.2.5.1/30 set interfaces ge-1/2/16 unit 0 family mpls set interfaces ge-1/2/17 unit 0 description R2-to-R7 set interfaces ge-1/2/17 unit 0 family inet address 10.2.7.1/30 set interfaces ge-1/2/17 unit 0 family mpls set interfaces ge-1/2/15 unit 0 description R2-to-R3 set interfaces ge-1/2/15 unit 0 family inet address 10.2.94.1/30 set interfaces ge-1/2/15 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.2/32 set interfaces lo0 unit 0 family mpls set protocols rsvp interface all set protocols mpls interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface all set protocols ldp p2mp set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 10.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 65010
Gerät R3
set chassis network-services enhanced-ip set interfaces ge-1/2/14 unit 0 description R3-to-R2 set interfaces ge-1/2/14 unit 0 family inet address 10.2.3.2/30 set interfaces ge-1/2/14 unit 0 family mpls set interfaces ge-1/2/18 unit 0 description R3-to-R4 set interfaces ge-1/2/18 unit 0 family inet address 10.3.4.1/30 set interfaces ge-1/2/18 unit 0 family mpls set interfaces ge-1/2/19 unit 0 description R3-to-R6 set interfaces ge-1/2/19 unit 0 family inet address 10.3.6.2/30 set interfaces ge-1/2/19 unit 0 family mpls set interfaces ge-1/2/21 unit 0 description R3-to-R7 set interfaces ge-1/2/21 unit 0 family inet address 10.3.7.1/30 set interfaces ge-1/2/21 unit 0 family mpls set interfaces ge-1/2/22 unit 0 description R3-to-R8 set interfaces ge-1/2/22 unit 0 family inet address 10.3.8.1/30 set interfaces ge-1/2/22 unit 0 family mpls set interfaces ge-1/2/15 unit 0 description R3-to-R2 set interfaces ge-1/2/15 unit 0 family inet address 10.2.94.2/30 set interfaces ge-1/2/15 unit 0 family mpls set interfaces ge-1/2/20 unit 0 description R3-to-R6 set interfaces ge-1/2/20 unit 0 family inet address 10.2.96.2/30 set interfaces ge-1/2/20 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.3/32 primary set routing-options autonomous-system 65010 set routing-options multicast stream-protection set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 10.1.1.3 set protocols bgp group ibgp peer-as 10 set protocols bgp group ibgp neighbor 10.1.1.1 set protocols bgp group ibgp neighbor 10.1.1.5 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface all set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface lo0.0 set protocols pim interface ge-1/2/18.0 set protocols pim interface ge-1/2/22.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 10.1.0.1/30 orlonger set policy-options policy-statement mldppim-ex term A then accept set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept
Gerät R4
set interfaces ge-1/2/18 unit 0 description R4-to-R3 set interfaces ge-1/2/18 unit 0 family inet address 10.3.4.2/30 set interfaces ge-1/2/18 unit 0 family mpls set interfaces ge-1/2/23 unit 0 description R4-to-R7 set interfaces ge-1/2/23 unit 0 family inet address 10.4.7.1/30 set interfaces lo0 unit 0 family inet address 10.1.1.4/32 set protocols igmp interface ge-1/2/18.0 version 3 set protocols igmp interface ge-1/2/18.0 static group 232.1.1.1 group-count 2 set protocols igmp interface ge-1/2/18.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface ge-1/2/18.0 static group 232.2.2.2 source 10.2.7.7 set protocols sap listen 232.1.1.1 set protocols sap listen 232.2.2.2 set protocols rsvp interface all set protocols mpls interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface ge-1/2/23.0 set protocols pim interface ge-1/2/18.0 set protocols pim interface lo0.0 set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 10.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 65010
Gerät R5
set interfaces ge-1/2/24 unit 0 description R5-to-src2 set interfaces ge-1/2/24 unit 0 family inet address 10.5.0.1/30 set interfaces ge-1/2/16 unit 0 description R5-to-R2 set interfaces ge-1/2/16 unit 0 family inet address 10.2.5.2/30 set interfaces ge-1/2/16 unit 0 family mpls set interfaces ge-1/2/25 unit 0 description R5-to-R6 set interfaces ge-1/2/25 unit 0 family inet address 10.5.6.1/30 set interfaces ge-1/2/25 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.5/32 set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 10.1.1.5 set protocols bgp group ibgp export static-route-tobgp set protocols bgp group ibgp peer-as 65010 set protocols bgp group ibgp neighbor 10.1.1.7 set protocols bgp group ibgp neighbor 10.1.1.3 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface ge-1/2/16.0 set protocols ldp interface ge-1/2/25.0 set protocols ldp p2mp set protocols pim interface lo0.0 set protocols pim interface ge-1/2/24.0 set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set routing-options autonomous-system 65010
Gerät R6
set interfaces ge-1/2/13 unit 0 description R6-to-R1 set interfaces ge-1/2/13 unit 0 family inet address 10.1.6.2/30 set interfaces ge-1/2/13 unit 0 family mpls set interfaces ge-1/2/19 unit 0 description R6-to-R3 set interfaces ge-1/2/19 unit 0 family inet address 10.3.6.1/30 set interfaces ge-1/2/19 unit 0 family mpls set interfaces ge-1/2/25 unit 0 description R6-to-R5 set interfaces ge-1/2/25 unit 0 family inet address 10.5.6.2/30 set interfaces ge-1/2/25 unit 0 family mpls set interfaces ge-1/2/26 unit 0 description R6-to-R7 set interfaces ge-1/2/26 unit 0 family inet address 10.6.7.1/30 set interfaces ge-1/2/26 unit 0 family mpls set interfaces ge-1/2/20 unit 0 description R6-to-R3 set interfaces ge-1/2/20 unit 0 family inet address 10.2.96.1/30 set interfaces ge-1/2/20 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.6/30 set protocols rsvp interface all set protocols mpls interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface all set protocols ldp p2mp
Gerät R7
set interfaces ge-1/2/17 unit 0 description R7-to-R2 set interfaces ge-1/2/17 unit 0 family inet address 10.2.7.2/30 set interfaces ge-1/2/17 unit 0 family mpls set interfaces ge-1/2/21 unit 0 description R7-to-R3 set interfaces ge-1/2/21 unit 0 family inet address 10.3.7.2/30 set interfaces ge-1/2/21 unit 0 family mpls set interfaces ge-1/2/23 unit 0 description R7-to-R4 set interfaces ge-1/2/23 unit 0 family inet address 10.4.7.2/30 set interfaces ge-1/2/23 unit 0 family mpls set interfaces ge-1/2/26 unit 0 description R7-to-R6 set interfaces ge-1/2/26 unit 0 family inet address 10.6.7.2/30 set interfaces ge-1/2/26 unit 0 family mpls set interfaces ge-1/2/27 unit 0 description R7-to-R8 set interfaces ge-1/2/27 unit 0 family inet address 10.7.8.1/30 set interfaces ge-1/2/27 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.7/32 set protocols rsvp interface all set protocols mpls interface all set protocols bgp group ibgp local-address 10.1.1.7 set protocols bgp group ibgp export static-route-tobgp set protocols bgp group ibgp peer-as 65010 set protocols bgp group ibgp neighbor 10.1.1.5 set protocols bgp group ibgp neighbor 10.1.1.1 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface ge-1/2/17.0 set protocols ldp interface ge-1/2/21.0 set protocols ldp interface ge-1/2/26.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface lo0.0 set protocols pim interface ge-1/2/27.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 10.1.0.1/30 orlonger set policy-options policy-statement mldppim-ex term A then accept set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set routing-options autonomous-system 65010 set routing-options multicast stream-protection policy mldppim-ex
Gerät R8
set interfaces ge-1/2/22 unit 0 description R8-to-R3 set interfaces ge-1/2/22 unit 0 family inet address 10.3.8.2/30 set interfaces ge-1/2/22 unit 0 family mpls set interfaces ge-1/2/27 unit 0 description R8-to-R7 set interfaces ge-1/2/27 unit 0 family inet address 10.7.8.2/30 set interfaces ge-1/2/27 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.8/32 set protocols igmp interface ge-1/2/22.0 version 3 set protocols igmp interface ge-1/2/22.0 static group 232.1.1.1 group-count 2 set protocols igmp interface ge-1/2/22.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface ge-1/2/22.0 static group 232.2.2.2 source 10.2.7.7 set protocols sap listen 232.1.1.1 set protocols sap listen 232.2.2.2 set protocols rsvp interface all set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface ge-1/2/27.0 set protocols pim interface ge-1/2/22.0 set protocols pim interface lo0.0 set policy-options policy-statement static-route-tobgp term static from protocol static set policy-options policy-statement static-route-tobgp term static from protocol direct set policy-options policy-statement static-route-tobgp term static then accept set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 10.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 65010
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:
Aktivieren Sie den erweiterten IP-Modus.
[edit chassis] user@R3# set network-services enhanced-ip
Konfigurieren Sie die Geräteschnittstellen.
[edit interfaces] user@R3# set ge-1/2/14 unit 0 description R3-to-R2 user@R3# set ge-1/2/14 unit 0 family inet address 10.2.3.2/30 user@R3# set ge-1/2/14 unit 0 family mpls user@R3# set ge-1/2/18 unit 0 description R3-to-R4 user@R3# set ge-1/2/18 unit 0 family inet address 10.3.4.1/30 user@R3# set ge-1/2/18 unit 0 family mpls user@R3# set ge-1/2/19 unit 0 description R3-to-R6 user@R3# set ge-1/2/19 unit 0 family inet address 10.3.6.2/30 user@R3# set ge-1/2/19 unit 0 family mpls user@R3# set ge-1/2/21 unit 0 description R3-to-R7 user@R3# set ge-1/2/21 unit 0 family inet address 10.3.7.1/30 user@R3# set ge-1/2/21 unit 0 family mpls user@R3# set ge-1/2/22 unit 0 description R3-to-R8 user@R3# set ge-1/2/22 unit 0 family inet address 10.3.8.1/30 user@R3# set ge-1/2/22 unit 0 family mpls user@R3# set ge-1/2/15 unit 0 description R3-to-R2 user@R3# set ge-1/2/15 unit 0 family inet address 10.2.94.2/30 user@R3# set ge-1/2/15 unit 0 family mpls user@R3# set ge-1/2/20 unit 0 description R3-to-R6 user@R3# set ge-1/2/20 unit 0 family inet address 10.2.96.2/30 user@R3# set ge-1/2/20 unit 0 family mpls user@R3# set lo0 unit 0 family inet address 10.1.1.3/32 primary
Konfigurieren Sie die AS-Nummer (Autonomous System).
user@R3# set routing-options autonomous-system 6510
Konfigurieren Sie die Routing-Richtlinien.
[edit policy-options policy-statement mldppim-ex] user@R3# set term B from source-address-filter 192.168.0.0/24 orlonger user@R3# set term B from source-address-filter 192.168.219.11/32 orlonger user@R3# set term B then accept user@R3# set term A from source-address-filter 10.1.0.1/30 orlonger user@R3# set term A then accept [edit policy-options policy-statement static-route-tobgp] user@R3# set term static from protocol static user@R3# set term static from protocol direct user@R3# set term static then accept
Konfigurieren Sie PIM.
[edit protocols pim] user@R3# set mldp-inband-signalling policy mldppim-ex user@R3# set interface lo0.0 user@R3# set interface ge-1/2/18.0 user@R3# set interface ge-1/2/22.0
Konfigurieren Sie LDP.
[edit protocols ldp] user@R3# set interface all user@R3# set p2mp
Konfigurieren Sie eine IGP oder statische Routen.
[edit protocols ospf] user@R3# set traffic-engineering user@R3# set area 0.0.0.0 interface all user@R3# set area 0.0.0.0 interface fxp0.0 disable user@R3# set area 0.0.0.0 interface lo0.0 passive
Konfigurieren Sie internes BGP.
[edit protocols bgp group ibgp] user@R3# set local-address 10.1.1.3 user@R3# set peer-as 65010 user@R3# set neighbor 10.1.1.1 user@R3# set neighbor 10.1.1.5
Konfigurieren Sie MPLS und optional RSVP.
[edit protocols mpls] user@R3# set interface all [edit protocols rsvp] user@R3# set interface all
Aktivieren Sie MoFRR.
[edit routing-options multicast] user@R3# set stream-protection
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show chassis
Befehle , show interfaces
, show protocols
, show policy-options
und 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.
user@R3# show chassis network-services enhanced-ip;
user@R3# show interfaces ge-1/2/14 { unit 0 { description R3-to-R2; family inet { address 10.2.3.2/30; } family mpls; } } ge-1/2/18 { unit 0 { description R3-to-R4; family inet { address 10.3.4.1/30; } family mpls; } } ge-1/2/19 { unit 0 { description R3-to-R6; family inet { address 10.3.6.2/30; } family mpls; } } ge-1/2/21 { unit 0 { description R3-to-R7; family inet { address 10.3.7.1/30; } family mpls; } } ge-1/2/22 { unit 0 { description R3-to-R8; family inet { address 10.3.8.1/30; } family mpls; } } ge-1/2/15 { unit 0 { description R3-to-R2; family inet { address 10.2.94.2/30; } family mpls; } } ge-1/2/20 { unit 0 { description R3-to-R6; family inet { address 10.2.96.2/30; } family mpls; } } lo0 { unit 0 { family inet { address 192.168.15.1/32; address 10.1.1.3/32 { primary; } } } }
user@R3# show protocols rsvp { interface all; } mpls { interface all; } bgp { group ibgp { local-address 10.1.1.3; peer-as 65010; neighbor 10.1.1.1; neighbor 10.1.1.5; } } ospf { traffic-engineering; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } interface lo0.0 { passive; } } } ldp { interface all; p2mp; } pim { mldp-inband-signalling { policy mldppim-ex; } interface lo0.0; interface ge-1/2/18.0; interface ge-1/2/22.0; }
user@R3# show policy-options policy-statement mldppim-ex { term B { from { source-address-filter 192.168.0.0/24 orlonger; source-address-filter 192.168.219.11/32 orlonger; } then accept; } term A { from { source-address-filter 10.1.0.1/30 orlonger; } then accept; } } policy-statement static-route-tobgp { term static { from protocol [ static direct ]; then accept; } }
user@R3# show routing-options autonomous-system 65010; multicast { stream-protection; }
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
- Untersuchen der Etiketteninformationen
- Überprüfen der Multicast-Routen
- Überprüfen der LDP-Punkt-zu-Multipunkt-Datenverkehrsstatistiken
Ü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!
user@R3> show ldp p2mp fec LDP P2MP FECs: P2MP root-addr 10.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 MoFRR enabled Fec type: Egress (Active) Label: 301568 P2MP root-addr 10.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 MoFRR enabled Fec type: Egress (Active) Label: 301600
Bedeutung
Die Ausgabe zeigt, dass MoFRR aktiviert ist, und 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!
user@R3> show route label 301568 detail mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 301568 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x2735208 Next-hop reference count: 3 Next hop type: Router, Next hop index: 1397 Address: 0x2735d2c Next-hop reference count: 3 Next hop: 10.3.8.2 via ge-1/2/22.0 Label operation: Pop Load balance label: None; Next hop type: Router, Next hop index: 1395 Address: 0x2736290 Next-hop reference count: 3 Next hop: 10.3.4.2 via ge-1/2/18.0 Label operation: Pop Load balance label: None; State: <Active Int AckRequest MulticastRPF> Local AS: 65010 Age: 54:05 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 10.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 Primary Upstream : 10.1.1.3:0--10.1.1.2:0 RPF Nexthops : ge-1/2/15.0, 10.2.94.1, Label: 301568, weight: 0x1 ge-1/2/14.0, 10.2.3.1, Label: 301568, weight: 0x1 Backup Upstream : 10.1.1.3:0--10.1.1.6:0 RPF Nexthops : ge-1/2/20.0, 10.2.96.1, Label: 301584, weight: 0xfffe ge-1/2/19.0, 10.3.6.1, Label: 301584, weight: 0xfffe
user@R3> show route label 301600 detail mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 301600 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x27356b4 Next-hop reference count: 3 Next hop type: Router, Next hop index: 1520 Address: 0x27350f4 Next-hop reference count: 3 Next hop: 10.3.8.2 via ge-1/2/22.0 Label operation: Pop Load balance label: None; Next hop type: Router, Next hop index: 1481 Address: 0x273645c Next-hop reference count: 3 Next hop: 10.3.4.2 via ge-1/2/18.0 Label operation: Pop Load balance label: None; State: <Active Int AckRequest MulticastRPF> Local AS: 65010 Age: 54:25 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 10.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 Primary Upstream : 10.1.1.3:0--10.1.1.6:0 RPF Nexthops : ge-1/2/20.0, 10.2.96.1, Label: 301600, weight: 0x1 ge-1/2/19.0, 10.3.6.1, Label: 301600, weight: 0x1 Backup Upstream : 10.1.1.3:0--1.1.1.2:0 RPF Nexthops : ge-1/2/15.0, 10.2.94.1, Label: 301616, weight: 0xfffe ge-1/2/14.0, 10.2.3.1, Label: 301616, weight: 0xfffe
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!
user@R3> show ldp p2mp path P2MP path type: Transit/Egress Output Session (label): 10.1.1.2:0 (301568) (Primary) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 10.2.94.1, 301568, 1 Interface ge-1/2/20.0, 10.2.96.1, 301584, 65534 Interface ge-1/2/14.0, 10.2.3.1, 301568, 1 Interface ge-1/2/19.0, 10.3.6.1, 301584, 65534 Attached FECs: P2MP root-addr 10.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 (Active) P2MP path type: Transit/Egress Output Session (label): 10.1.1.6:0 (301584) (Backup) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 10.2.94.1, 301568, 1 Interface ge-1/2/20.0, 10.2.96.1, 301584, 65534 Interface ge-1/2/14.0, 10.2.3.1, 301568, 1 Interface ge-1/2/19.0, 10.3.6.1, 301584, 65534 Attached FECs: P2MP root-addr 10.1.1.1, grp: 232.1.1.1, src: 192.168.219.11 (Active) P2MP path type: Transit/Egress Output Session (label): 10.1.1.6:0 (301600) (Primary) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 10.2.94.1, 301616, 65534 Interface ge-1/2/20.0, 10.2.96.1, 301600, 1 Interface ge-1/2/14.0, 10.2.3.1, 301616, 65534 Interface ge-1/2/19.0, 10.3.6.1, 301600, 1 Attached FECs: P2MP root-addr 10.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 (Active) P2MP path type: Transit/Egress Output Session (label): 10.1.1.2:0 (301616) (Backup) Egress Nexthops: Interface ge-1/2/18.0 Interface ge-1/2/22.0 RPF Nexthops: Interface ge-1/2/15.0, 10.2.94.1, 301616, 65534 Interface ge-1/2/20.0, 10.2.96.1, 301600, 1 Interface ge-1/2/14.0, 10.2.3.1, 301616, 65534 Interface ge-1/2/19.0, 10.3.6.1, 301600, 1 Attached FECs: P2MP root-addr 10.1.1.1, grp: 232.1.1.2, src: 192.168.219.11 (Active)
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!
user@R3> show ldp traffic-statistics p2mp P2MP FEC Statistics: FEC(root_addr:lsp_id/grp,src) Nexthop Packets Bytes Shared 10.1.1.1:232.1.1.1,192.168.219.11, Label: 301568 10.3.8.2 0 0 No 10.3.4.2 0 0 No 10.1.1.1:232.1.1.1,192.168.219.11, Label: 301584, Backup route 10.3.4.2 0 0 No 10.3.8.2 0 0 No 10.1.1.1:232.1.1.2,192.168.219.11, Label: 301600 10.3.8.2 0 0 No 10.3.4.2 0 0 No 10.1.1.1:232.1.1.2,192.168.219.11, Label: 301616, Backup route 10.3.4.2 0 0 No 10.3.8.2 0 0 No
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
- Verteilen von LDP-Downstream-on-Demand-Routen in gelabelte BGP
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:
-
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.
[edit policy-options] user@host# set prefix-list Request-Loopbacks 10.1.1.1/32 user@host# set prefix-list Request-Loopbacks 10.1.1.2/32 user@host# set prefix-list Request-Loopbacks 10.1.1.3/32 user@host# set prefix-list Request-Loopbacks 10.1.1.4/32 user@host# set policy-statement DOD-Request-Loopbacks term 1 from prefix-list Request-Loopbacks user@host# set policy-statement DOD-Request-Loopbacks term 1 then accept
-
Geben Sie die DOD-Request-Loopbacks-Richtlinie mithilfe der
dod-request-policy
Anweisung auf Hierarchieebene[edit protocols ldp]
an.Die mit der
dod-request-policy
Anweisung angegebene Richtlinie wird verwendet, um die Präfixe 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 derDOD-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.[edit protocols ldp] user@host# set dod-request-policy DOD-Request-Loopbacks
-
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.[edit protocols ldp] user@host# set session 172.16.1.1 downstream-on-demand
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.
-
Konfigurieren Sie die LDP-Routingrichtlinie (
redistribute_ldp
in diesem Beispiel).[edit policy-options] user@host# set policy-statement redistribute_ldp term 1 from protocol ldp user@host# set policy-statement redistribute_ldp term 1 from tag 1000 user@host# set policy-statement redistribute_ldp term 1 then accept
-
Fügen Sie die LDP-Routing-Richtlinie
redistribute_ldp
in die BGP-Konfiguration ein (in diesem Beispiel als Teil der BGP-Gruppenkonfigurationebgp-to-abr
).BGP leitet die LDP-Routen basierend auf der
redistribute_ldp
Richtlinie an den Remote-PE-Router weiter[edit protocols bgp] user@host# set group ebgp-to-abr type external user@host# set group ebgp-to-abr local-address 192.168.0.1 user@host# set group ebgp-to-abr peer-as 65319 user@host# set group ebgp-to-abr local-as 65320 user@host# set group ebgp-to-abr neighbor 192.168.6.1 family inet unicast user@host# set group ebgp-to-abr neighbor 192.168.6.1 family inet labeled-unicast rib inet.3 user@host# set group ebgp-to-abr neighbor 192.168.6.1 export redistribute_ldp
Schritt-für-Schritt-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:
-
Konfigurieren Sie die Richtlinie so, dass Routen
dod-routes
von LDP akzeptiert werden.user@host# set policy-options policy-statement dod-routes term 1 from protocol ldp user@host# set policy-options policy-statement dod-routes term 1 from tag 1145307136 user@host# set policy-options policy-statement dod-routes term 1 then accept
-
Konfigurieren Sie die Richtlinie so, dass Routen
do-not-propagate-du-sessions
nicht an Nachbarn10.1.1.1
weitergeleitet werden,10.2.2.2
und10.3.3.3
.user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 10.1.1.1 user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 10.2.2.2 user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 10.3.3.3 user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 then reject
-
Konfigurieren Sie die
filter-dod-on-du-sessions
Richtlinie so, dass die von derdod-routes
Richtlinie untersuchten Routen nicht an die benachbarten Router weitergeleitet werden, die in derdo-not-propagate-du-sessions
Richtlinie definiert sind.user@host# set policy-options policy-statement filter-dod-routes-on-du-sessions term 1 from policy dod-routes user@host# set policy-options policy-statement filter-dod-routes-on-du-sessions term 1 to policy do-not-propagate-du-sessions
-
Geben Sie die
filter-dod-routes-on-du-sesssion
Richtlinie als Exportrichtlinie für BGP groupebgp-to-abr
an.[edit protocols bgp] user@host# set group ebgp-to-abr neighbor 192.168.6.2 export filter-dod-routes-on-du-sessions
Ergebnisse
Bestätigen Sie 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.
user@host# show policy-options prefix-list Request-Loopbacks { 10.1.1.1/32; 10.1.1.2/32; 10.1.1.3/32; 10.1.1.4/32; } policy-statement DOD-Request-Loopbacks { term 1 { from { prefix-list Request-Loopbacks; } then accept; } } policy-statement redistribute_ldp { term 1 { from { protocol ldp; tag 1000; } then accept; } }
user@host# show protocols ldp dod-request-policy DOD-Request-Loopbacks; session 172.16.1.1 { downstream-on-demand; }
user@host# show protocols bgp group ebgp-to-abr { type external; local-address 192.168.0.1; peer-as 65319; local-as 65320; neighbor 192.168.6.1 { family inet { unicast; labeled-unicast { rib { inet.3; } } } export redistribute_ldp; } }
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 derAdv. Mode
(Label Advertisement-Modus) istDOD
(was bedeutet, dass die LDP-Downstream-On-Demand-Sitzung betriebsbereit ist):user@host>
show ldp session
Address State Connection Hold time Adv. Mode 172.16.1.2 Operational Open 22 DOD -
Die folgende Befehlsausgabe für den
show ldp session detail
Befehl gibt an, dass derLocal Label Advertisement mode
Standardwert istDownstream unsolicited
(d. h., Downstream-On-Demand ist für die lokale Sitzung nicht konfiguriert). Umgekehrt geben dasRemote Label Advertisement mode
und beideNegotiated Label Advertisement mode
an, dassDownstream on demand
in der Remotesitzung konfiguriert istuser@host>
show ldp session detail
Address: 172.16.1.2, State: Operational, Connection: Open, Hold time: 24 Session ID: 10.1.1.1:0--10.1.1.2:0 Next keepalive in 4 seconds Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 Neighbor types: configured-tunneled Keepalive interval: 10, Connect retry interval: 1 Local address: 10.1.1.1, Remote address: 10.1.1.2 Up for 17:54:52 Capabilities advertised: none Capabilities received: none Protection: disabled Local - Restart: disabled, Helper mode: enabled, Remote - Restart: disabled, Helper mode: enabled Local maximum neighbor reconnect time: 120000 msec Local maximum neighbor recovery time: 240000 msec Local Label Advertisement mode: Downstream unsolicited Remote Label Advertisement mode: Downstream on demand Negotiated Label Advertisement mode: Downstream on demand Nonstop routing state: Not in sync Next-hop addresses received: 10.1.1.2
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:
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.

Konfiguration
- CLI-Schnellkonfiguration
- Konfigurieren von R1
- Konfigurieren Sie die Transporteinstellung, um den bevorzugten Transport auszuwählen
- Konfigurieren Sie Dual-Transport zum Einrichten separater Sitzungen für IPv4 mit einem IPv4-Nachbarn und IPv6 mit einem IPv6-Nachbarn
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
set interfaces ge-1/0/0 unit 0 family inet address 192.168.12.1/24 set interfaces ge-1/0/0 unit 0 family iso set interfaces ge-1/0/0 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 set interfaces ge-1/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.0.1/32 set interfaces lo0 unit 0 family iso address 49.0001.1720.1600.1010.00 set interfaces lo0 unit 0 family inet6 address 2001:db8::1/128 set protocols isis interface ge-1/0/0.0 set protocols isis interface lo0.0 set protocols mpls interface ge-1/0/0.0 set protocols ldp deaggregate set protocols ldp interface ge-1/0/0.0 set protocols ldp interface lo0.0 set protocols ldp family inet6 set protocols ldp family inet
R2
set interfaces ge-1/0/1 unit 0 family inet address 192.168.12.2/24 set interfaces ge-1/0/1 unit 0 family iso set interfaces ge-1/0/1 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 set interfaces ge-1/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.0.2/32 set interfaces lo0 unit 0 family iso address 49.0001.1720.1600.2020.00 set interfaces lo0 unit 0 family inet6 address 2001:db8::2/128 set protocols isis interface ge-1/0/1.0 set protocols isis interface lo0.0 set protocols mpls interface ge-1/0/1.0 set protocols ldp deaggregate set protocols ldp interface ge-1/0/1.0 set protocols ldp interface lo0.0 set protocols ldp family inet6 set protocols ldp family inet
Konfigurieren von R1
Schritt-für-Schritt-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:
-
Konfigurieren Sie die Schnittstellen.
[edit interfaces] set ge-1/0/0 unit 0 family inet address 192.168.12.1/24 set ge-1/0/0 unit 0 family iso set ge-1/0/0 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 set ge-1/0/0 unit 0 family mpls
-
Weisen Sie dem Gerät eine Loopback-Adresse zu.
[edit interfaces lo0 unit 0] set family inet address 10.255.0.1/32 set family iso address 49.0001.1720.1600.1010.00 set family inet6 address 2001:db8::1/128
-
Konfigurieren Sie die IS-IS-Schnittstellen.
[edit protocols isis] set interface ge-1/0/0.0 set interface lo0.0
-
Konfigurieren Sie MPLS für die Verwendung von LDP-Schnittstellen auf dem Gerät.
[edit protocols mpls] set protocols mpls interface ge-1/0/0.0 set interface ge-1/0/0.0 set interface lo0.0
-
Aktivieren Sie die FEC-Deaggregation (Forwarding Equivalence Class), um unterschiedliche Bezeichnungen für verschiedene Adressfamilien zu verwenden.
[edit protocols ldp] set deaggregate
-
Konfigurieren Sie LDP-Adressfamilien.
[edit protocols ldp] set family inet6 set family inet
Ergebnisse
Bestätigen Sie 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.
user@R1# show interfaces ge-1/0/0 { unit 0 { family inet { address 192.168.12.1/24; } family iso; family inet6 { address 2001:db8:0:12::/64 { eui-64; } } family mpls; } } lo0 { unit 0 { family inet { address 10.255.0.1/32; } family iso { address 49.0001.1720.1600.1010.00 } family inet6 { address 2001:db8::1/128; } } }
user@R1# show protocols mpls { interface ge-1/0/0.0; } isis { interface ge-1/0/0.0; interface lo0.0; } ldp { deaggregate; interface ge-1/0/0.0; interface lo0.0; family { inet6; inet; } }
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.
[edit protocols ldp] set transport-preference ipv4
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.
user@R1# show protocols mpls { interface ge-1/0/0.0; } isis { interface ge-1/0/0.0; interface lo0.0; } ldp { deaggregate; interface ge-1/0/0.0; interface lo0.0; family { inet6; inet; } transport-preference ipv4; }
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.
[edit protocols ldp dual-transport] set inet-lsr-id 10.255.0.1 set inet6-lsr-id 10.1.1.1
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.
user@R1# show protocols mpls { interface ge-1/0/0.0; } isis { interface ge-1/0/0.0; interface lo0.0; } ldp { deaggregate; interface ge-1/0/0.0; interface lo0.0; family { inet6; inet; } dual-transport { inet-lsr-id 10.255.0.1; inet6-lsr-id 10.1.1.1; } }
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Routeneinträge in der Tabelle mpls.0
- Verifizieren der Routeneinträge in der inet.3-Tabelle
- Überprüfen der Routeneinträge in der inet6.3-Tabelle
- Verifizieren der LDP-Datenbank
- Überprüfen der LDP-Nachbarinformationen
- Überprüfen der LDP-Sitzungsinformationen
Ü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.
user@R1> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 05:19:58, metric 1
Receive
1 *[MPLS/0] 05:19:58, metric 1
Receive
2 *[MPLS/0] 05:19:58, metric 1
Receive
13 *[MPLS/0] 05:19:58, metric 1
Receive
299824 *[LDP/9] 04:28:45, metric 1
> to fe80::21f:1200:cb6:4c8d via ge-1/0/0.0, Pop
299824(S=0) *[LDP/9] 04:28:45, metric 1
> to fe80::21f:1200:cb6:4c8d via ge-1/0/0.0, Pop
299888 *[LDP/9] 00:56:12, metric 1
> to 192.168.12.2 via ge-1/0/0.0, Pop
299888(S=0) *[LDP/9] 00:56:12, metric 1
> to 192.168.12.2 via ge-1/0/0.0, Pop
Bedeutung
Die Ausgabe zeigt die 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.
user@R1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.0.2/32 *[LDP/9] 00:58:38, metric 1
> to 192.168.12.2 via ge-1/0/0.0
Bedeutung
Die Ausgabe zeigt die Informationen 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.
user@R1> show route table inet6.3
inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:db8::2/128 *[LDP/9] 04:31:17, metric 1
> to fe80::21f:1200:cb6:4c8d via ge-1/0/0.0
Bedeutung
Die Ausgabe zeigt die Informationen der 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.
user@R1> show ldp database
Input label database, 10.255.0.1:0--10.255.0.2:0
Labels received: 3
Label Prefix
299840 10.255.0.1/32
3 10.255.0.2/32
299808 2001:db8::1/128
3 2001:db8::2/128
Output label database, 10.255.0.1:0--10.255.0.2:0
Labels advertised: 3
Label Prefix
3 10.255.0.1/32
299888 10.255.0.2/32
3 2001:db8::1/128
299824 2001:db8::2/128
Bedeutung
Die Ausgabe zeigt die Einträge in der LDP-Datenbank.
Ü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.
user@R1>show ldp neighbor
Address Interface Label space ID Hold time fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 12 192.168.12.2 ge-1/0/0.0 10.255.0.2:0 11 user@R1>show ldp neighbor extensive
Address Interface Label space ID Hold time 192.168.12.2 ge-1/0/0.0 10.255.0.2:0 11 Transport address: 10.255.0.2, Transport preference: IPv6, Configuration sequence: 10 Up for 00:04:35 Reference count: 1 Hold time: 15, Proposed local/peer: 15/15 Hello flags: none Neighbor types: discovered Address Interface Label space ID Hold time fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 14 Transport address: 2001:db8::2, Transport preference: IPv6, Configuration sequence: 10 Up for 00:04:35 Reference count: 1 Hold time: 15, Proposed local/peer: 15/15 Hello flags: none Neighbor types: discovered
Bedeutung
Die Ausgabe zeigt LDP-Nachbarinformationen von IPv4- und IPv6-Adressen.
Ü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.
user@R1>show ldp session
session Address State Connection Hold time Adv. Mode 2001:db8::2 Operational Open 20 DU user@R1>show ldp session extensive
Address: 2001:db8::2, State: Operational, Connection: Open, Hold time: 29 Session ID: 10.255.0.1:0--10.255.0.2:0 Next keepalive in 9 seconds Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 Neighbor types: discovered Keepalive interval: 10, Connect retry interval: 1 Local address: 2001:db8::1, Remote address: 2001:db8::2 Up for 00:05:31 Capabilities advertised: none Capabilities received: none Protection: disabled Session flags: none Local - Restart: disabled, Helper mode: enabled Remote - Restart: disabled, Helper mode: enabled Local maximum neighbor reconnect time: 120000 msec Local maximum neighbor recovery time: 240000 msec Local Label Advertisement mode: Downstream unsolicited Remote Label Advertisement mode: Downstream unsolicited Negotiated Label Advertisement mode: Downstream unsolicited MTU discovery: disabled Nonstop routing state: Not in sync Next-hop addresses received: 10.255.0.2 192.168.12.2 2001:db8::2 fe80::21f:1200:cb6:4c8d Queue depth: 0 Message type Total Last 5 seconds Sent Received Sent Received Initialization 1 1 0 0 Keepalive 34 34 0 0 Notification 0 0 0 0 Address 1 1 0 0 Address withdraw 0 0 0 0 Label mapping 3 3 0 0 Label request 0 0 0 0 Label withdraw 0 0 0 0 Label release 0 0 0 0 Label abort 0 0 0 0
Bedeutung
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.
user@R1> show ldp neighbor extensive
Address Interface Label space ID Hold time
192.168.12.2 ge-1/0/0.0 10.255.0.2:0 14
Transport address: 10.255.0.2, Transport preference: IPv4, Configuration sequence: 9
Up for 00:00:14
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Address Interface Label space ID Hold time
fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 14
Transport address: 2001:db8::2, Transport preference: IPv4, Configuration sequence: 9
Up for 00:00:14
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Bedeutung
Die Ausgabe zeigt LDP-Nachbarinformationen 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.
user@R1> show ldp session extensive
Address: 10.255.0.2, State: Operational, Connection: Open, Hold time: 24
Session ID: 10.255.0.1:0--10.255.0.2:0
Next keepalive in 4 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 2
Neighbor types: discovered
Keepalive interval: 10, Connect retry interval: 1
Local address: 10.255.0.1, Remote address: 10.255.0.2
Up for 00:05:26
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
10.255.0.2
192.168.12.2
2001:db8::2
fe80::21f:1200:cb6:4c8d
Queue depth: 0
Message type Total Last 5 seconds
Sent Received Sent Received
Initialization 1 1 0 0
Keepalive 33 33 1 1
Notification 0 0 0 0
Address 2 2 0 0
Address withdraw 0 0 0 0
Label mapping 6 6 0 0
Label request 0 0 0 0
Label withdraw 0 0 0 0
Label release 0 0 0 0
Label abort 0 0 0 0
Bedeutung
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.
user@R1> show ldp neighbor extensive
Address Interface Label space ID Hold time
192.168.12.2 ge-1/0/0.0 10.255.0.2:0 11
Transport address: 10.255.0.2, Configuration sequence: 10
Up for 00:04:35
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Address Interface Label space ID Hold time
fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10.255.0.2:0 14
Transport address: 2001:db8::2, Configuration sequence: 10
Up for 00:04:35
Reference count: 1
Hold time: 15, Proposed local/peer: 15/15
Hello flags: none
Neighbor types: discovered
Bedeutung
Die Ausgabe zeigt LDP-Nachbarinformationen 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.
user@R1> show ldp session extensive
Address: 2001:db8::2, State: Operational, Connection: Open, Hold time: 29
Session ID: 10.1.1.1:0--10.255.0.2:0
Next keepalive in 9 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: discovered
Keepalive interval: 10, Connect retry interval: 1
Local address: 2001:db8::1, Remote address: 2001:db8::2
Up for 00:05:31
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
2001:db8::2
fe80::21f:1200:cb6:4c8d
Queue depth: 0
Message type Total Last 5 seconds
Sent Received Sent Received
Initialization 1 1 0 0
Keepalive 34 34 0 0
Notification 0 0 0 0
Address 1 1 0 0
Address withdraw 0 0 0 0
Label mapping 3 3 0 0
Label request 0 0 0 0
Label withdraw 0 0 0 0
Label release 0 0 0 0
Label abort 0 0 0 0
Address: 10.255.0.2, State: Operational, Connection: Open, Hold time: 29
Session ID: 10.255.0.1:0--10.255.0.2:0
Next keepalive in 9 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: discovered
Keepalive interval: 10, Connect retry interval: 1
Local address: 10.255.0.1, Remote address: 10.255.0.2
Up for 00:05:31
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
10.255.0.2
192.168.12.2
Queue depth: 0
Message type Total Last 5 seconds
Sent Received Sent Received
Initialization 1 1 0 0
Keepalive 34 34 0 0
Notification 0 0 0 0
Address 1 1 0 0
Address withdraw 0 0 0 0
Label mapping 3 3 0 0
Label request 0 0 0 0
Label withdraw 0 0 0 0
Label release 0 0 0 0
Label abort 0 0 0 0
Beispiel: Konfigurieren der Multipoint-LDP-In-Band-Signalisierung für Point-to-Multipoint-LSPs
- Grundlegendes zur Multipoint-LDP-Inband-Signalübertragung für Punkt-zu-Mehrpunkt-LSPs
- 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
- Terminologie
- Ingress-Join-Übersetzung und Pseudo-Interface-Behandlung
- Eindringendes Spleißen
- Reverse Path Forwarding
- LSP-Root-Erkennung
- Übersetzung von Ausgangsjoins und Handhabung von Pseudoschnittstellen
- Ausgangs-Spleißen
- Unterstützte Funktionen
- Nicht unterstützte Funktionen
- LDP-Funktionalität
- Ausgangs-LER-Funktionalität
- Transit LSR-Funktionalität
- Ingress LER-Funktionalität
Funktionsweise von M-LDP
- Label-Bindungen in der M-LDP-Signalübertragung
- M-LDP im PIM-freien MPLS-Kern
- M-LDP im PIM-fähigen MPLS-Kern
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.

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.

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:
protocols { pim { mldp-inband-signalling { policy lsp-mapping-policy-example; } } }
policy-options { policy-statement lsp-mapping-policy-example { term channel1 { from { source-address-filter ip-prefix</prefix-length>; #policy filter for channel1 } then { p2mp-lsp-root { # Statically configured ingress address of edge # used by channel1 address ip-address; } accept; } } } }
M-LDP im PIM-fähigen MPLS-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.

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.
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:
protocols { pim { mldp-inband-signalling { policy lsp-mapping-policy-example; } } }
policy-options { policy-statement lsp-mapping-policy-example { term channel1 { from { source-address-filter ip-prefix</prefix-length>; #policy filter for channel1 } then { selected-mldp-egress; accept; } } term channel2 { from { source-address-filter ip-prefix</prefix-length>; #policy filter for channel2 route-filter ip-prefix</prefix-length>; #policy filter on multicast group address } then { selected-mldp-egress; p2mp-lsp-root { # Statically configured ingress address of edge # used by channel2 address ip-address; } accept; } } term channel3 { from { route-filter ip-prefix</prefix-length>; #policy filter on multicast group address } then { selected-mldp-egress; accept; } } } }
Einige der Einschränkungen der obigen Konfiguration sind wie folgt:
Die
selected-mldp-egress
Anweisung sollte nur auf dem LER konfiguriert werden. Das Konfigurieren derselected-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:
Wenn die vorhandene statische Konfiguration die Quelladresse angibt, wird der Stamm wie in der Konfiguration angegeben verwendet.
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
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.

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
set logical-systems src1 interfaces fe-1/2/0 unit 0 family inet address 10.2.7.7/24 set logical-systems src1 interfaces lo0 unit 0 family inet address 10.1.1.7/32 set logical-systems src1 protocols ospf area 0.0.0.0 interface all
Geräte-IngressPE
set interfaces so-0/1/2 unit 0 family inet address 192.168.93.9/28 set interfaces fe-1/2/0 unit 0 family inet address 10.2.3.2/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.2.5.2/24 set interfaces fe-1/2/2 unit 0 family inet address 10.2.6.2/24 set interfaces fe-1/2/2 unit 0 family mpls set interfaces fe-1/2/3 unit 0 family inet address 10.2.7.2/24 set interfaces fe-1/3/1 unit 0 family inet address 192.168.219.9/28 set interfaces lo0 unit 0 family inet address 10.1.1.2/32 set protocols igmp interface fe-1/2/1.0 version 3 set protocols igmp interface fe-1/2/1.0 static group 232.1.1.1 source 192.168.219.11 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.1.1.2 set protocols bgp group ibgp family inet any set protocols bgp group ibgp family inet-vpn any set protocols bgp group ibgp neighbor 10.1.1.3 set protocols bgp group ibgp neighbor 10.1.1.4 set protocols bgp group ibgp neighbor 10.1.1.1 set protocols ospf area 0.0.0.0 interface all set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/2.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim rp static address 10.1.1.5 set protocols pim interface fe-1/3/1.0 set protocols pim interface lo0.0 set protocols pim interface fe-1/2/0.21 set protocols pim interface fe-1/2/3.0 set protocols pim interface fe-1/2/1.0 set protocols pim interface so-0/1/2.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 10.1.1.7/32 orlonger set policy-options policy-statement mldppim-ex term A from source-address-filter 10.2.7.0/24 orlonger set policy-options policy-statement mldppim-ex term A then accept set routing-options autonomous-system 64510
GeräteausgangPE
set interfaces so-0/1/3 unit 0 point-to-point set interfaces so-0/1/3 unit 0 family inet address 192.168.92.9/28 set interfaces fe-1/2/0 unit 0 family inet address 10.1.3.1/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.4.1/24 set interfaces fe-1/2/2 unit 0 family inet address 10.1.6.1/24 set interfaces fe-1/2/2 unit 0 family mpls set interfaces fe-1/3/0 unit 0 family inet address 192.168.209.9/28 set interfaces lo0 unit 0 family inet address 10.1.1.1/32 set routing-options autonomous-system 64510 set protocols igmp interface fe-1/3/0.0 version 3 set protocols igmp interface fe-1/3/0.0 static group 232.1.1.1 group-count 3 set protocols igmp interface fe-1/3/0.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface fe-1/3/0.0 static group 227.1.1.1 set protocols igmp interface so-0/1/3.0 version 3 set protocols igmp interface so-0/1/3.0 static group 232.1.1.1 group-count 2 set protocols igmp interface so-0/1/3.0 static group 232.1.1.1 source 192.168.219.11 set protocols igmp interface so-0/1/3.0 static group 232.2.2.2 source 10.2.7.7 set protocols mpls interface fe-1/2/0.0 set protocols mpls interface fe-1/2/2.0 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.1.1.1 set protocols bgp group ibgp family inet any set protocols bgp group ibgp neighbor 10.1.1.2 set protocols msdp local-address 10.1.1.1 set protocols msdp peer 10.1.1.5 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/2.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim rp local address 10.1.1.1 set protocols pim rp local group-ranges 227.0.0.0/8 set protocols pim rp static address 10.1.1.4 set protocols pim rp static address 10.2.7.7 group-ranges 226.0.0.0/8 set protocols pim interface lo0.0 set protocols pim interface fe-1/3/0.0 set protocols pim interface fe-1/2/0.0 set protocols pim interface fe-1/2/1.0 set protocols pim interface so-0/1/3.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 10.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term A from source-address-filter 10.2.7.0/24 orlonger set policy-options policy-statement mldppim-ex term A then accept
Gerät p6
set interfaces fe-1/2/0 unit 0 family inet address 10.1.6.6/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.2.6.6/24 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.6/32 set interfaces lo0 unit 0 family mpls set protocols ospf area 0.0.0.0 interface all set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/1.0 set protocols ldp interface lo0.0 set protocols ldp p2mp
Gerät pr3
set interfaces ge-0/3/1 unit 0 family inet address 192.168.215.9/28 set interfaces fe-1/2/0 unit 0 family inet address 10.1.3.3/24 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.2.3.3/24 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.1.3/32 set protocols igmp interface ge-0/3/1.0 version 3 set protocols igmp interface ge-0/3/1.0 static group 232.1.1.2 source 192.168.219.11 set protocols igmp interface ge-0/3/1.0 static group 232.2.2.2 source 10.2.7.7 set protocols bgp group ibgp local-address 10.1.1.3 set protocols bgp group ibgp type internal set protocols bgp group ibgp neighbor 10.1.1.2 set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 2 set protocols ldp interface fe-1/2/0.0 set protocols ldp interface fe-1/2/1.0 set protocols ldp interface lo0.0 set protocols ldp p2mp set protocols pim mldp-inband-signalling policy mldppim-ex set protocols pim interface fe-0/3/1.0 set protocols pim interface lo0.0 set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 10.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 orlonger set policy-options policy-statement mldppim-ex term B from source-address-filter 10.2.7.7/32 orlonger set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 10.1.1.2 set policy-options policy-statement mldppim-ex term B then accept set routing-options autonomous-system 64510
Gerät pr4
set interfaces ge-0/3/0 unit 0 family inet address 192.168.207.9/28 set interfaces fe-1/2/0 unit 0 family inet address 10.1.4.4/24 set interfaces fe-1/2/0 unit 0 family iso set interfaces lo0 unit 0 family inet address 10.1.1.4/32 set protocols igmp interface ge-0/3/0.0 version 3 set protocols igmp interface ge-0/3/0.0 static group 232.1.1.2 source 192.168.219.11 set protocols igmp interface ge-0/3/0.0 static group 225.1.1.1 set protocols bgp group ibgp local-address 10.1.1.4 set protocols bgp group ibgp type internal set protocols bgp group ibgp neighbor 10.1.1.2 set protocols msdp local-address 10.1.1.4 set protocols msdp peer 10.1.1.5 set protocols ospf area 0.0.0.0 interface all set protocols pim rp local address 10.1.1.4 set protocols pim interface ge-0/3/0.0 set protocols pim interface lo0.0 set protocols pim interface fe-1/2/0.0 set routing-options autonomous-system 64510
Gerät pr5
set interfaces fe-1/2/0 unit 0 family inet address 10.2.5.5/24 set interfaces lo0 unit 0 family inet address 10.1.1.5/24 set protocols igmp interface lo0.0 version 3 set protocols igmp interface lo0.0 static group 232.1.1.1 source 192.168.219.11 set protocols msdp local-address 10.1.1.5 set protocols msdp peer 10.1.1.4 set protocols msdp peer 10.1.1.1 set protocols ospf area 0.0.0.0 interface all set protocols pim rp local address 10.1.1.5 set protocols pim interface all
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:
Konfigurieren Sie die Schnittstellen.
Aktivieren Sie MPLS auf den Core-Schnittstellen. Auf den nächsten Hops des Ausgangs müssen Sie MPLS nicht aktivieren.
[edit interfaces] user@EgressPE# set fe-1/2/0 unit 0 family inet address 10.1.3.1/24 user@EgressPE# set fe-1/2/0 unit 0 family mpls user@EgressPE# set fe-1/2/2 unit 0 family inet address 10.1.6.1/24 user@EgressPE# set fe-1/2/2 unit 0 family mpls user@EgressPE# set so-0/1/3 unit 0 point-to-point user@EgressPE# set so-0/1/3 unit 0 family inet address 192.168.92.9/28 user@EgressPE# set fe-1/2/1 unit 0 family inet address 10.1.4.1/24 user@EgressPE# set fe-1/3/0 unit 0 family inet address 192.168.209.9/28 user@EgressPE# set lo0 unit 0 family inet address 10.1.1.1/32
Konfigurieren Sie IGMP auf den Ausgangsschnittstellen.
Zu Testzwecken enthält dieses Beispiel statische Gruppen- und Quelladressen.
[edit protocols igmp] user@EgressPE# set interface fe-1/3/0.0 version 3 user@EgressPE# set interface fe-1/3/0.0 static group 232.1.1.1 group-count 3 user@EgressPE# set interface fe-1/3/0.0 static group 232.1.1.1 source 192.168.219.11 user@EgressPE# set interface fe-1/3/0.0 static group 227.1.1.1 user@EgressPE# set interface so-0/1/3.0 version 3 user@EgressPE# set interface so-0/1/3.0 static group 232.1.1.1 group-count 2 user@EgressPE# set interface so-0/1/3.0 static group 232.1.1.1 source 192.168.219.11 user@EgressPE# set interface so-0/1/3.0 static group 232.2.2.2 source 10.2.7.7
Konfigurieren Sie MPLS auf den Core-Schnittstellen.
[edit protocols mpls] user@EgressPE# set interface fe-1/2/0.0 user@EgressPE# set interface fe-1/2/2.0
Konfigurieren Sie BGP.
BGP ist ein richtliniengesteuertes Protokoll, daher sollten Sie auch alle erforderlichen Routing-Richtlinien konfigurieren und anwenden.
Sie können z. B. statische Routen in BGP exportieren.
[edit protocols bgp group ibgp] user@EgressPE# set type internal user@EgressPE# set local-address 10.1.1.1 user@EgressPE# set family inet any user@EgressPE# set neighbor 10.1.1.2
(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.
[edit protocols msdp] user@EgressPE# set local-address 10.1.1.1 user@EgressPE# set peer 10.1.1.5
Konfigurieren Sie OSPF.
[edit protocols ospf area 0.0.0.0] user@EgressPE# set interface all user@EgressPE# set interface fxp0.0 disable
Konfigurieren Sie LDP auf den Core-zugewandten Schnittstellen und auf der Loopback-Schnittstelle.
[edit protocols ldp] user@EgressPE# set interface fe-1/2/0.0 user@EgressPE# set interface fe-1/2/2.0 user@EgressPE# set interface lo0.0
Aktivieren Sie Punkt-zu-Mehrpunkt-MPLS-LSPs.
[edit protocols ldp] user@EgressPE# set p2mp
Konfigurieren Sie PIM auf den nachgeschalteten Schnittstellen.
[edit protocols pim] user@EgressPE# set interface lo0.0 user@EgressPE# set interface fe-1/3/0.0 user@EgressPE# set interface fe-1/2/1.0 user@EgressPE# set interface so-0/1/3.0
Konfigurieren Sie die RP-Einstellungen, da dieses Gerät als PIM-Rendezvouspunkt (RP) dient.
[edit protocols pim] user@EgressPE# set rp local address 10.1.1.1 user@EgressPE# set rp local group-ranges 227.0.0.0/8 user@EgressPE# set rp static address 10.1.1.4 user@EgressPE# set rp static address 10.2.7.7 group-ranges 226.0.0.0/8
Aktivieren Sie die In-Band-Signalisierung von M-LDP, und legen Sie die zugehörige Richtlinie fest.
[edit protocols pim] user@EgressPE# set mldp-inband-signalling policy mldppim-ex
Konfigurieren Sie die Routingrichtlinie, die die Stammadresse für den Punkt-zu-Mehrpunkt-LSP und die zugehörigen Quelladressen angibt.
[edit policy-options policy-statement mldppim-ex] user@EgressPE# set term B from source-address-filter 192.168.0.0/24 orlonger user@EgressPE# set term B from source-address-filter 192.168.219.11/32 orlonger user@EgressPE# set term B then p2mp-lsp-root address 10.1.1.2 user@EgressPE# set term B then accept user@EgressPE# set term A from source-address-filter 10.2.7.0/24 orlonger user@EgressPE# set term A then accept
Konfigurieren Sie die ID des autonomen Systems (AS).
[edit routing-options] user@EgressPE# set autonomous-system 64510
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die show interfaces
Befehle , show protocols
, show policy-options
und 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
user@EgressPE# show interfaces
so-0/1/3 {
unit 0 {
point-to-point;
family inet {
address 192.168.92.9/28;
}
}
}
fe-1/2/0 {
unit 0 {
family inet {
address 10.1.3.1/24;
}
family mpls;
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 10.1.4.1/24;
}
}
}
fe-1/2/2 {
unit 0 {
family inet {
address 10.1.6.1/24;
}
family mpls;
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 192.168.209.9/28;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.1.1.1/32;
}
}
}
user@EgressPE# show protocols
igmp {
interface fe-1/3/0.0 {
version 3;
static {
group 232.1.1.1 {
group-count 3;
source 192.168.219.11;
}
group 227.1.1.1;
}
}
interface so-0/1/3.0 {
version 3;
static {
group 232.1.1.1 {
group-count 2;
source 192.168.219.11;
}
group 232.2.2.2 {
source 10.2.7.7;
}
}
}
}
mpls {
interface fe-1/2/0.0;
interface fe-1/2/2.0;
}
bgp {
group ibgp {
type internal;
local-address 10.1.1.1;
family inet {
any;
}
neighbor 10.1.1.2;
}
}
msdp {
local-address 10.1.1.1;
peer 10.1.1.5;
}
ospf {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
ldp {
interface fe-1/2/0.0;
interface fe-1/2/2.0;
interface lo0.0;
p2mp;
}
pim {
mldp-inband-signalling {
policy mldppim-ex;
}
rp {
local {
address 10.1.1.1;
group-ranges {
227.0.0.0/8;
}
}
static {
address 10.1.1.4;
address 10.2.7.7 {
group-ranges {
226.0.0.0/8;
}
}
}
}
interface lo0.0;
interface fe-1/3/0.0;
interface fe-1/2/0.0;
interface fe-1/2/1.0;
interface so-0/1/3.0;
}
user@EgressPE# show policy-options
policy-statement mldppim-ex {
term B {
from {
source-address-filter 192.168.0.0/24 orlonger;
source-address-filter 192.168.219.11/32 orlonger;
}
then {
p2mp-lsp-root {
address 10.1.1.2;
}
accept;
}
}
term A {
from {
source-address-filter 10.2.7.0/24 orlonger;
}
then accept;
}
}
user@EgressPE# show routing-options
autonomous-system 64510;
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
- Überprüfen der PIM-Quellen
- Überprüfung der LDP-Datenbank
- Nachschlagen der Routeninformationen für die MPLS-Beschriftung
- Überprüfen der LDP-Datenverkehrsstatistik
Ü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.
user@IngressPE> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 232.1.1.1 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/3/1.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 23:00:12 Downstream neighbors: Interface: Pseudo-MLDP Interface: fe-1/2/1.0 10.2.5.2 State: Join Flags: S Timeout: Infinity Uptime: 1d 23:00:12 Time since last Join: 1d 23:00:12 Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/3/1.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 22:59:59 Downstream neighbors: Interface: Pseudo-MLDP Group: 232.1.1.3 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/3/1.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 22:07:31 Downstream neighbors: Interface: Pseudo-MLDP Group: 232.2.2.2 Source: 10.2.7.7 Flags: sparse,spt Upstream interface: fe-1/2/3.0 Upstream neighbor: Direct Upstream state: Local Source Keepalive timeout: Uptime: 1d 22:59:59 Downstream neighbors: Interface: Pseudo-MLDP user@EgressPE> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 227.1.1.1 Source: * RP: 10.1.1.1 Flags: sparse,rptree,wildcard Upstream interface: Local Upstream neighbor: Local Upstream state: Local RP Uptime: 1d 23:14:21 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: SRW Timeout: Infinity Uptime: 1d 23:14:21 Time since last Join: 1d 20:12:35 Group: 232.1.1.1 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <10.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 23:14:22 Downstream neighbors: Interface: so-0/1/3.0 192.168.92.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <10.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 23:14:22 Downstream neighbors: Interface: so-0/1/3.0 192.168.92.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Downstream neighbors: Interface: fe-1/2/1.0 10.1.4.4 State: Join Flags: S Timeout: 198 Uptime: 1d 22:59:59 Time since last Join: 00:00:12 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Group: 232.1.1.3 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <10.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:12:35 Downstream neighbors: Interface: fe-1/3/0.0 192.168.209.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 Group: 232.2.2.2 Source: 10.2.7.7 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <10.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:12:35 Downstream neighbors: Interface: so-0/1/3.0 192.168.92.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 20:12:35 Time since last Join: 1d 20:12:35 user@pr3> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <10.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:14:40 Downstream neighbors: Interface: Pseudo-GMP ge-0/3/1.0 Group: 232.2.2.2 Source: 10.2.7.7 Flags: sparse,spt Upstream protocol: MLDP Upstream interface: Pseudo MLDP Upstream neighbor: MLDP LSP root <10.1.1.2> Upstream state: Join to Source Keepalive timeout: Uptime: 1d 20:14:40 Downstream neighbors: Interface: Pseudo-GMP ge-0/3/1.0 user@pr4> show pim join extensive Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 225.1.1.1 Source: * RP: 10.1.1.4 Flags: sparse,rptree,wildcard Upstream interface: Local Upstream neighbor: Local Upstream state: Local RP Uptime: 1d 23:13:43 Downstream neighbors: Interface: ge-0/3/0.0 192.168.207.9 State: Join Flags: SRW Timeout: Infinity Uptime: 1d 23:13:43 Time since last Join: 1d 23:13:43 Group: 232.1.1.2 Source: 192.168.219.11 Flags: sparse,spt Upstream interface: fe-1/2/0.0 Upstream neighbor: 10.1.4.1 Upstream state: Local RP, Join to Source Keepalive timeout: 0 Uptime: 1d 23:13:43 Downstream neighbors: Interface: ge-0/3/0.0 192.168.207.9 State: Join Flags: S Timeout: Infinity Uptime: 1d 23:13:43 Time since last Join: 1d 23:13:43 user@pr5> show pim join extensive ge-0/3/1.0 Instance: PIM.master Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Instance: PIM.master Family: INET6 R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Überprüfen der PIM-Quellen
Zweck
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.
user@IngressPE> show pim source Instance: PIM.master Family: INET Source 10.1.1.1 Prefix 10.1.1.1/32 Upstream interface Local Upstream neighbor Local Source 10.2.7.7 Prefix 10.2.7.0/24 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <10.1.1.2> Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <10.1.1.2>
user@EgressPE> show pim source Instance: PIM.master Family: INET Source 10.2.7.7 Prefix 1.2.7.0/24 Upstream interface fe-1/2/3.0 Upstream neighbor 10.2.7.2 Source 10.2.7.7 Prefix 10.2.7.0/24 Upstream interface fe-1/2/3.0 Upstream neighbor Direct Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream interface fe-1/3/1.0 Upstream neighbor 192.168.219.9 Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream interface fe-1/3/1.0 Upstream neighbor Direct
user@pr3> show pim source Instance: PIM.master Family: INET Source 10.2.7.7 Prefix 1.2.7.0/24 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <10.1.1.2> Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream protocol MLDP Upstream interface Pseudo MLDP Upstream neighbor MLDP LSP root <10.1.1.2>
user@pr4> show pim source Instance: PIM.master Family: INET Source 10.1.1.4 Prefix 10.1.1.4/32 Upstream interface Local Upstream neighbor Local Source 192.168.219.11 Prefix 192.168.219.0/28 Upstream interface fe-1/2/0.0 Upstream neighbor 10.1.4.1
Überprüfung der LDP-Datenbank
Zweck
Stellen Sie sicher, dass der show ldp database
Befehl die erwarteten root-to-(S,G)-Bindungen anzeigt.
Action!
user@IngressPE> show ldp database Input label database, 10.255.2.227:0--10.1.1.3:0 Label Prefix 300096 10.1.1.2/32 3 10.1.1.3/32 299856 10.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--10.1.1.3:0 Label Prefix 300144 10.1.1.2/32 299776 10.1.1.3/32 299856 10.1.1.6/32 3 10.255.2.227/32 Input label database, 10.255.2.227:0--10.1.1.6:0 Label Prefix 299936 10.1.1.2/32 299792 10.1.1.3/32 3 10.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--10.1.1.6:0 Label Prefix 300144 10.1.1.2/32 299776 10.1.1.3/32 299856 10.1.1.6/32 3 10.255.2.227/32 300432 P2MP root-addr 10.1.1.2, grp: 232.2.2.2, src: 10.2.7.7 300288 P2MP root-addr 10.1.1.2, grp: 232.1.1.1, src: 192.168.219.11 300160 P2MP root-addr 10.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 300480 P2MP root-addr 10.1.1.2, grp: 232.1.1.3, src: 192.168.219.11
user@EgressPE> show ldp database Input label database, 10.1.1.2:0--10.1.1.3:0 Label Prefix 300096 10.1.1.2/32 3 10.1.1.3/32 299856 10.1.1.6/32 299776 10.255.2.227/32 300144 P2MP root-addr 10.1.1.2, grp: 232.2.2.2, src: 10.2.7.7 300128 P2MP root-addr 10.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 Output label database, 10.1.1.2:0--10.1.1.3:0 Label Prefix 3 10.1.1.2/32 299776 10.1.1.3/32 299808 10.1.1.6/32 299792 10.255.2.227/32 Input label database, 10.1.1.2:0--10.1.1.6:0 Label Prefix 299936 10.1.1.2/32 299792 10.1.1.3/32 3 10.1.1.6/32 299776 10.255.2.227/32 300128 P2MP root-addr 10.1.1.2, grp: 232.2.2.2, src: 10.2.7.7 299984 P2MP root-addr 10.1.1.2, grp: 232.1.1.1, src: 192.168.219.11 299952 P2MP root-addr 10.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 300176 P2MP root-addr 10.1.1.2, grp: 232.1.1.3, src: 192.168.219.11 300192 P2MP root-addr 10.1.1.2, grp: ff3e::1:2, src: 2001:db8:abcd::10:2:7:7 Output label database, 10.1.1.2:0--10.1.1.6:0 Label Prefix 3 10.1.1.2/32 299776 10.1.1.3/32 299808 10.1.1.6/32 299792 10.255.2.227/32 ----- logical-system: default Input label database, 10.255.2.227:0--10.1.1.3:0 Label Prefix 300096 10.1.1.2/32 3 10.1.1.3/32 299856 10.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--10.1.1.3:0 Label Prefix 300144 10.1.1.2/32 299776 10.1.1.3/32 299856 10.1.1.6/32 3 10.255.2.227/32 Input label database, 10.255.2.227:0--10.1.1.6:0 Label Prefix 299936 10.1.1.2/32 299792 10.1.1.3/32 3 10.1.1.6/32 299776 10.255.2.227/32 Output label database, 10.255.2.227:0--10.1.1.6:0 Label Prefix 300144 10.1.1.2/32 299776 10.1.1.3/32 299856 10.1.1.6/32 3 10.255.2.227/32 300432 P2MP root-addr 10.1.1.2, grp: 232.2.2.2, src: 10.2.7.7 300288 P2MP root-addr 10.1.1.2, grp: 232.1.1.1, src: 192.168.219.11 300160 P2MP root-addr 10.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 300480 P2MP root-addr 10.1.1.2, grp: 232.1.1.3, src: 192.168.219.11 300496 P2MP root-addr 10.1.1.2, grp: ff3e::1:2, src: 2001:db8:abcd::10:2:7:7
user@p6> show ldp database Input label database, 10.1.1.6:0--10.1.1.2:0 Label Prefix 3 10.1.1.2/32 299776 10.1.1.3/32 299808 10.1.1.6/32 Output label database, 10.1.1.6:0--10.1.1.2:0 Label Prefix 299776 10.1.1.2/32 299792 10.1.1.3/32 3 10.1.1.6/32
user@pr3> show ldp database Input label database, 10.1.1.3:0--10.1.1.2:0 Label Prefix 3 10.1.1.2/32 299776 10.1.1.3/32 299808 10.1.1.6/32 299792 10.255.2.227/32 Output label database, 10.1.1.3:0--10.1.1.2:0 Label Prefix 300096 10.1.1.2/32 3 10.1.1.3/32 299856 10.1.1.6/32 299776 10.255.2.227/32 300144 P2MP root-addr 10.1.1.2, grp: 232.2.2.2, src: 10.2.7.7 300128 P2MP root-addr 10.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 Input label database, 10.1.1.3:0--10.255.2.227:0 Label Prefix 300144 10.1.1.2/32 299776 10.1.1.3/32 299856 10.1.1.6/32 3 10.255.2.227/32 Output label database, 10.1.1.3:0--10.255.2.227:0 Label Prefix 300096 10.1.1.2/32 3 10.1.1.3/32 299856 10.1.1.6/32 299776 10.255.2.227/32
Nachschlagen der Routeninformationen für die MPLS-Beschriftung
Zweck
Zeigen Sie die Punkt-zu-Mehrpunkt-FEC-Informationen an.
Action!
user@EgressPE> show route label 299808 detail mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) 299808 (1 entry, 1 announced) *LDP Preference: 9 Next hop type: Flood Address: 0x931922c Next-hop reference count: 3 Next hop type: Router, Next hop index: 1109 Address: 0x9318b0c Next-hop reference count: 2 Next hop: via so-0/1/3.0 Label operation: Pop Next hop type: Router, Next hop index: 1110 Address: 0x93191e0 Next-hop reference count: 2 Next hop: 192.168.209.11 via fe-1/3/0.0 Label operation: Pop State: **Active Int AckRequest> Local AS: 10 Age: 13:08:15 Metric: 1 Validation State: unverified Task: LDP Announcement bits (1): 0-KRT AS path: I FECs bound to route: P2MP root-addr 10.1.1.2, grp: 232.1.1.1, src: 192.168.219.11
Überprüfen der LDP-Datenverkehrsstatistik
Zweck
Überwachen Sie die Datenverkehrsstatistiken für den Punkt-zu-Mehrpunkt-LSP.
Action!
user@EgressPE> show ldp traffic-statistics p2mp P2MP FEC Statistics: FEC(root_addr:lsp_id/grp,src) Nexthop Packets Bytes Shared 10.1.1.2:232.2.2.2,10.2.7.7 so-0/1/3.0 0 0 No 10.1.1.2:232.1.1.1,192.168.219.11 so-0/1/3.0 0 0 No fe-1/3/0.0 0 0 No 10.1.1.2:232.1.1.2,192.168.219.11 so-0/1/3.0 0 0 No fe-1/3/0.0 0 0 No lt-1/2/0.14 0 0 No 10.1.1.2:232.1.1.3,192.168.219.11 fe-1/3/0.0 0 0 No 10.1.1.2:ff3e::1:2,2001:db8:abcd::1:2:7:7 fe-1/3/0.0 0 0 No
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
- Interoperabilität zwischen Segment-Routing und LDP mithilfe von OSPF
- Interoperabilität des Segment-Routings mit LDP unter Verwendung von ISIS
Ü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.

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
undmpls.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.
-
Definieren Sie die SRMS-Funktion:
[edit routing-options source-packet-routing ] user@R2# set mapping-server-entry ospf-mapping-server prefix-segment-range ldp-lo0s start-prefix 192.168.0.5 user@R2# set mapping-server-entry ospf-mapping-server prefix-segment-range ldp-lo0s start-index 1000 user@R2# set mapping-server-entry ospf-mapping-server prefix-segment-range ldp-lo0s size 2
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öße2
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 einzigenprefix-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:[edit routing-options source-packet-routing] show mapping-server-entry map-server-name { prefix-segment-range lo1 { start-prefix 192.168.0.5/32; start-index 1000; size 1; } prefix-segment-range lo2 { start-prefix 192.168.0.10/32; start-index 2000; size 1; } } }
-
Konfigurieren Sie als Nächstes die OSPF-Unterstützung für die erweiterte LSA, die zum Überfluten der zugeordneten Präfixe verwendet wird.
[edit protocols] user@R2# set ospf source-packet-routing mapping-server ospf-mapping-server
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. -
Aktivieren Sie die SRMC-Funktionalität. Für unsere Beispieltopologie müssen Sie die SRMC-Funktionalität auf R4 aktivieren.
[edit protocols] user@R4# set ldp sr-mapping-client
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 generiert
RPD_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:
-
Definieren Sie die SRMS-Funktion:
[edit routing-options source-packet-routing ] user@R2# set mapping-server-entry isis-mapping-server prefix-segment-range ldp-lo0s start-prefix 192.168.0.5 user@R2# set mapping-server-entry isis-mapping-server prefix-segment-range ldp-lo0s start-index 1000 user@R2# set mapping-server-entry isis-mapping-server prefix-segment-range ldp-lo0s size 2
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öße2
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 einerprefix-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:[edit routing-options source-packet-routing] show mapping-server-entry map-server-name { prefix-segment-range lo1 { start-prefix 192.168.0.5/32; start-index 1000; size 1; } prefix-segment-range lo2 { start-prefix 192.168.0.10/32; start-index 2000; size 1; } } }
-
Konfigurieren Sie als Nächstes die ISIS-Unterstützung für den erweiterten LSP, der zum Überfluten der zugeordneten Präfixe verwendet wird.
[edit protocols] user@R2# set isis source-packet-routing mapping-server isis-mapping-server
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. -
Aktivieren Sie die SRMC-Funktionalität. Für unsere Beispieltopologie müssen Sie die SRMC-Funktionalität auf R4 aktivieren.
[edit protocols] user@R4# set ldp sr-mapping-client
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
- Verhindern des Hinzufügens von Eingangsrouten zur inet.0-Routing-Tabelle
- LDP- und Carrier-of-Carrier-VPNs mit mehreren Instanzen
- Konfigurieren Sie MPLS und LDP so, dass die Bezeichnung auf dem Ultimate-Hop-Router angezeigt wird.
- Aktivieren von LDP über RSVP-etablierte LSPs
- Aktivieren von LDP über RSVP-etablierte Sprachdienstleister in heterogenen Netzwerken
- Konfigurieren der TCP-MD5-Signatur für LDP-Sitzungen
- Konfigurieren des LDP-Sitzungsschutzes
- Deaktivieren von SNMP-Traps für LDP
- Konfigurieren der LDP-Synchronisierung mit dem IGP auf LDP-Links
- Konfigurieren der LDP-Synchronisierung mit der IGP auf dem Router
- Konfigurieren des Timers für die Etikettenentnahme
- Ignorieren der LDP-Subnetzprüfung
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:
track-igp-metric;
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.
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:
no-forwarding;
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:
explicit-null;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisung.
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:
[edit] protocols { mpls { label-switched-path lsp-name { from source; to destination; ldp-tunneling; } } }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisung.
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:
ignore-lsp-metrics;
Sie können diese Anweisung auf den folgenden Hierarchieebenen konfigurieren:
-
[edit protocols ospf traffic-engineering shortcuts]
-
[edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]
Router der ACX-Serie unterstützen 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:
[edit protocols ldp] session-group prefix-length { authentication-key md5-authentication-key; }
Verwenden Sie die session-group
Anweisung, um die Adresse für das Remote-Ende der LDP-Sitzung zu konfigurieren.
Das md5-authentication-key
oder 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.
[edit security authentication-key-chains] key-chain key-chain-name { key key { secret secret-data; start-time yyyy-mm-dd.hh:mm:ss; } }
Um den 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.
[edit protocols ldp] group group-name { neighbor address { authentication-algorithm algorithm; authentication-key-chain key-chain-name; } }
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.
session-protection { timeout seconds; }
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:
log-updown { trap disable; }
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:
ldp-synchronization { disable; hold-time seconds; }
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:
igp-synchronization holddown-interval seconds;
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:
label-withdrawal-delay seconds;
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:
allow-subnet-mismatch;
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]
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:
periodic-traceroute { disable; exp exp-value; fanout fanout-value; frequency minutes; paths number-of-paths; retries retry-attempts; source address; ttl ttl-value; wait seconds; }
Sie können diese Anweisung auf den folgenden Hierarchieebenen konfigurieren:
Sie können die periodic-traceroute
Anweisung 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:
traffic-statistics { file filename <files number> <size size> <world-readable | no-world-readable>; interval interval; no-penultimate-hop; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt Anweisungszusammenfassung für diese Anweisung.
Dieser Abschnitt enthält die folgenden Themen:
- LDP-Statistikausgabe
- Deaktivieren der LDP-Statistik auf dem Penultimate-Hop-Router
- Einschränkungen der LDP-Statistik
LDP-Statistikausgabe
Die folgende Beispielausgabe stammt aus einer LDP-Statistikdatei:
FEC Type Packets Bytes Shared 10.255.350.448/32 Transit 0 0 No Ingress 0 0 No 10.255.350.450/32 Transit 0 0 Yes Ingress 0 0 No 10.255.350.451/32 Transit 0 0 No Ingress 0 0 No 220.220.220.1/32 Transit 0 0 Yes Ingress 0 0 No 220.220.220.2/32 Transit 0 0 Yes Ingress 0 0 No 220.220.220.3/32 Transit 0 0 Yes Ingress 0 0 No May 28 15:02:05, read 12 statistics in 00:00:00 seconds
Die LDP-Statistikdatei enthält die folgenden Datenspalten:
FEC
– FEC, für die LDP-Datenverkehrsstatistiken erfasst werden.Type
- Art des Datenverkehrs, der von einem Router stammt, entwederIngress
(von diesem Router stammend) oderTransit
(über diesen Router weitergeleitet).Packets
- Anzahl der Pakete, die 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
– EinYes
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:
traffic-statistics { no-penultimate-hop; }
Eine Liste der Hierarchieebenen, auf denen Sie die traffic-statistics
Anweisung konfigurieren können, finden Sie im Abschnitt Anweisungszusammenfassung zu dieser Anweisung.
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:
FEC Type Packets Bytes Shared 10.255.245.218/32 Transit 0 0 No Ingress 4 246 No 10.255.245.221/32 Transit statistics disabled Ingress statistics disabled 13.1.1.0/24 Transit statistics disabled Ingress statistics disabled 13.1.3.0/24 Transit statistics disabled Ingress statistics disabled
Einschränkungen 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
- Ablaufverfolgung des LDP-Protokolldatenverkehrs innerhalb von FECs
- Beispiele: Ablaufverfolgung des Datenverkehrs im LDP-Protokoll
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:
traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung 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 deraddress
Modifikatoren ,initialization
,label
,notification
undperiodic
.Sie können den
filter
Flag-Modifikator auch mit dermatch-on address
Unteroption für daspackets
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
, path
und binding
.
Das folgende Beispiel veranschaulicht, wie Sie die LDP-Anweisung traceoptions
konfigurieren können, um LDP-Ablaufverfolgungsanweisungen basierend auf einer FEC zu filtern:
[edit protocols ldp traceoptions] set flag route filter match-on fec policy "filter-policy-for-ldp-fec";
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 immerreject
.Die einzige
match-on
Option istfec
. 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:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5; flag path; } } }
Verfolgen Sie alle ausgehenden LDP-Nachrichten:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5; flag packets; } } }
Verfolgen Sie alle LDP-Fehlerbedingungen:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5; flag error; } } }
Verfolgen Sie alle eingehenden LDP-Nachrichten und alle Bezeichnungsbindungsvorgänge nach:
[edit] protocols { ldp { traceoptions { file ldp size 10m files 5 world-readable; flag packets receive; flag binding; } interface all { } } }
Verfolgen Sie den LDP-Protokolldatenverkehr für eine FEC, die dem LSP zugeordnet ist:
[edit] protocols { ldp { traceoptions { flag route filter match-on fec policy filter-policy-for-ldp-fec; } } }
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.