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 Hierarchieebene.
[edit protocol mpls]
Aktivieren Sie LDP auf einer einzelnen Schnittstelle, fügen Sie die Anweisung ein, und geben Sie die Schnittstelle mithilfe der Anweisung an.
ldp
interface
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 für an.all
interface-name
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung.
Aktivieren und Deaktivieren von LDP
LDP ist Routing-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 für an.all
interface-name
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 Anweisung mit der Option ein:interface
disable
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 Anweisung ein neues Link-Hello-Meldungsintervall für den LDP-Timer an:hello-interval
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 Anweisung als Option für die Anweisung konfigurieren:hello-interval
targeted-hello
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 Befehl ein.clear ldp session
- 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 folgenden Anweisung eine neue Zeit in Sekunden an:hold-time
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 Anweisung als Option für die Anweisung verwenden:hold-time
targeted-hello
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 Anweisung konfigurieren, antwortet ein LDP-Peer nicht auf gezielte Hello-Nachrichten, die von einer Quelle stammen, die nicht zu den konfigurierten Remotenachbarn gehört.strict-targeted-hellos
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 die Quelle angibt.error
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 folgende Anweisung ein:strict-targeted-hellos
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 folgende Anweisung ein:keepalive-interval
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 folgende Anweisung ein:keepalive-timeout
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 Anweisung konfigurierte Wert wird als Haltezeit angezeigt, wenn Sie den Befehl ausgeben.keepalive-timeout
show ldp session detail
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 RFC5283 konfigurieren.
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 RFC5283 konfiguriert 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 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.longest-match
Topologie
Zeigt in der Topologie an, dass die längste Übereinstimmung für LDP auf Gerät R0 konfiguriert ist.Abbildung 1
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 Konfigurationsmodus ein .[edit]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.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
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 Befehle , und eingeben.show interfacesshow protocolsshow routing-options 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
Überprüfung
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.
Was
Führen Sie auf Gerät R0 im Betriebsmodus den Befehl aus, um die Routen in der Routing-Tabelle anzuzeigen.show route
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.
Was
Führen Sie auf Gerät R0 im Betriebsmodus den Befehl aus, um die Übersicht über das LDP anzuzeigen.show ldp overview
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.
Was
Führen Sie auf Gerät R0 im Betriebsmodus den Befehl aus, um die interne Topologietabelle von LDP anzuzeigen.show ldp route
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.
Was
Führen Sie auf Gerät R0 im Betriebsmodus den Befehl aus, um die Routen in der Routing-Tabelle anzuzeigen.show ldp route fec-only
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.
Was
Führen Sie auf Gerät R0 im Betriebsmodus den Befehl aus, um die FEC- und Schattenrouten in der Routing-Tabelle anzuzeigen.show ldp route fec-and-route
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 folgende Anweisung ein:preference
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 oder der Hierarchieebene ändern, wird jede laufende LDP-Sitzung automatisch neu gestartet, um die Konfiguration für den ordnungsgemäßen Neustart anzuwenden.[edit routing-options graceful-restart]
[edit protocols ldp graceful-restart]
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 folgende Anweisung ein:graceful-restart
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 [] nicht.edit logical-systems logical-system-name routing-options
Die Anweisung ermöglicht einen ordnungsgemäßen Neustart für alle Protokolle, die diese Funktion auf dem Router unterstützen.graceful-restart
Weitere Informationen zum ordnungsgemäßen Neustart finden Sie in der Junos OS Routing Protocols Library for Routing Devices.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-routing/index.html
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 folgende Anweisung ein:disable
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 folgende Anweisung ein:helper-disable
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 folgende Anweisung ein:reconnect-time
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 Anweisung und die Anweisung ein:recovery-time
maximum-neighbor-recovery-time
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 folgende Anweisung ein:import
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 konfiguriert) wird auf alle Bezeichnungsbindungen angewendet, die von allen LDP-Nachbarn empfangen werden.[edit policy-options]
Die gesamte Filterung erfolgt mit Anweisungen. listet die einzigen Operatoren auf, die für die LDP-Filterung mit empfangenen Bezeichnungen gelten. from
Tabelle 1from
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 und in diesem Fall nicht angemessen.)next-hop
interface
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.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-policy/config-guide-policy.html
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 und akzeptieren Sie alle Präfixe von allen anderen Nachbarn:131.108/16
10.10.255.2
[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 folgende Anweisung ein:export
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 konfiguriert) wird auf alle Bezeichnungsbindungen angewendet, die an alle LDP-Nachbarn übertragen werden.[edit policy-options]
Der einzige Operator, der für die LDP-Filterung ausgehender Bezeichnungen gilt, ist , der Bindungen mit dem angegebenen Präfix entspricht.from
route-filter
Die einzigen Operatoren, die für die Filterung ausgehender Bezeichnungen gelten, sind die Operatoren in .to
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 Operatoren und nicht, wenn ein Router mehrere Nachbarschaften zum selben Nachbarn hat.next-hop
interface
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.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-policy/config-guide-policy.html
Beispiele: Filtern ausgehender LDP-Labelbindungen
Blockieren Sie die Übertragung der Route an beliebige Nachbarn:10.10.255.6/32
[edit protocols] ldp { export block-one; } policy-options { policy-statement block-one { term first { from { route-filter 10.10.255.6/32 exact; } then reject; } then accept; } }
Nur oder länger an Router-ID senden und alle Präfixe an alle anderen Router senden:131.108/16
10.10.255.2
[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 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).router-id
Wenn Sie die Option angeben, wird die Schnittstellenadresse als Transportadresse für alle LDP-Sitzungen zu Nachbarn verwendet, die über diese Schnittstelle erreicht werden können.interface
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 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.interface
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 Option.router-id
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 Konfigurationsanweisungen , und konfigurieren.session
session-group
interface
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 Hierarchie.
[edit protocols ldp session]
Unter Hierarchie.
[edit protocols ldp session-group]
Unter Hierarchie.
[edit protocols ldp interfcae lo0]
Unter Hierarchie.
[edit protocols ldp]
Standardadresse.
Die Reihenfolge der Präferenz der Transportadresse für die ermittelten Nachbarn lautet wie folgt:
Unter Hierarchie.
[edit protocols ldp interfcae]
Unter Hierarchie.
[edit protocols ldp]
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 Hierarchie.
[edit protocols ldp interfcae lo0]
Unter Hierarchie.
[edit protocols ldp]
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 Ausgabeebene des Befehls zeigt die Transportadresse an, die in den Hallo-Nachrichten an den Zielnachbarn gesendet wird.
detail
show ldp neighbor
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 Option .
address family
Die Transportadresse, die unter der Anweisung konfiguriert wird, muss derselben Adressfamilie angehören wie der Nachbar oder die Sitzung.session
Die Adresse, die als Transportadresse unter einer oder-Anweisung konfiguriert ist, muss für den Router lokal sein, damit die angestrebten Hello-Nachrichten gestartet werden können.
neighbor
session
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 folgende Anweisung ein, um den Satz von Präfixen aus der Routingtabelle zu konfigurieren, die in LDP angekündigt werden sollen:egress-policy
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 Hierarchieebene oder) wird auf alle Routen in der Routingtabelle angewendet.[edit policy-options]
[edit logical-systems logical-system-name policy-options]
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 Anweisung steuern.export
Es werden nur Operatoren berücksichtigt, Sie können jeden gültigen Operator verwenden.fromfrom Weitere Informationen finden Sie in der Junos OS Routing Protocols Library for Routing Devices.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-routing/index.html
Router der ACX-Serie unterstützen die Hierarchieebene [] nicht.edit logical-systems
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 folgende Anweisung ein:deaggregate
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 folgende Anweisung ein:no-deaggregate
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 Anweisung oder die Anweisung auf Hierarchieebene konfigurieren.interface
interface-set
[edit firewall family protocol-family filter filter-name term term-name from]
Mit dieser Anweisung können Sie den Filter einer einzelnen Schnittstelle zuordnen.interface
Mit dieser Anweisung können Sie den Filter mehreren Schnittstellen zuordnen.interface-set
Weitere Informationen zum Konfigurieren der Anweisung, der Anweisung und der Policer für LDP-FECs finden Sie im Benutzerhandbuch für Routingrichtlinien, Firewallfilter und Traffic Policers.interface
interface-set
https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-policy/config-guide-policy.html
Nachdem Sie die Filter konfiguriert haben, müssen Sie sie in die Anweisungskonfiguration für LDP aufnehmen.policing
Um Policer für LDP-FECs zu konfigurieren, fügen Sie die folgende Anweisung ein:policing
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 Anweisung enthält die folgenden Optionen:policing
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 Anweisung konfigurieren.l2-smart-policy
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 aktiviert ist, wird diese Funktion in die entsprechende Richtung deaktiviert.l2-smart-policy
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 über solche Sitzungen empfangen wurden:l2-smart-policy
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 LSPs beschrieben.
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 Befehl verwenden, um BFD-Intervall-Timer auf ihre konfigurierten Werte zurückzusetzen.clear bfd adaptation
Der Befehl ist trefferlos, d. h., der Befehl wirkt sich nicht auf den Datenverkehrsfluss auf dem Routinggerät aus.clear bfd adaptation
Um BFD für LDP-LSPs zu aktivieren, fügen Sie die und-Anweisungen ein:oam
bfd-liveness-detection
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 Option auf Hierarchieebene konfigurieren.fec
[edit protocols ldp]
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.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 Anweisung auf den folgenden Hierarchieebenen konfigurieren:oam
[edit protocols ldp]
[edit logical-systems logical-system-name protocols ldp]
Router der ACX-Serie unterstützen die Hierarchieebene [] nicht.edit logical-systems
Die Anweisung enthält die folgenden Optionen:oam
fec
– Geben Sie die FEC-Adresse an. Sie müssen entweder eine FEC-Adresse angeben oder eine OAM-Eingangsrichtlinie konfigurieren, um sicherzustellen, dass die BFD-Sitzung gestartet wird.lsp-ping-interval
– Geben Sie die Dauer des LSP-Ping-Intervalls in Sekunden an. Verwenden Sie den Befehl, um einen Ping für einen LDP-signalisierten LSP auszugeben.ping mpls ldp
Weitere Informationen finden Sie im CLI-Explorer.https://www.juniper.net/documentation/content-applications/cli-explorer/junos/
Die Anweisung enthält die folgenden Optionen:bfd-liveness-detection
ecmp
– LDP veranlasst, BFD-Sitzungen für alle ECMP-Pfade einzurichten, die für den angegebenen FEC konfiguriert sind. Wenn Sie die Option konfigurieren, müssen Sie auch die Anweisung für die angegebene FEC konfigurieren.ecmp
periodic-traceroute
Wenn Sie dies nicht tun, schlägt der Commit-Vorgang fehl. Sie können die Anweisung auf der globalen Hierarchieebene () konfigurieren, während Sie nur die Option fÃ1/4r eine bestimmte FEC () konfigurieren.periodic-traceroute
[edit protocols ldp oam]
ecmp
[edit protocols ldp oam fec address bfd-liveness-detection]
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.holddown-interval Wenn Sie eine Zeit von 0 Sekunden angeben, wird die Route oder der nächste Hop hinzugefügt, sobald die BFD-Sitzung wieder gestartet wird.
minimum-interval
– Geben Sie das minimale Sende- und Empfangsintervall an. Wenn Sie die Option konfigurieren, müssen Sie die Option oder die Option nicht konfigurieren.minimum-interval
minimum-receive-interval
minimum-transmit-interval
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.version (BFD) 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 Anweisung ein.ecmp
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 Anweisung müssen Sie die Anweisung entweder in der globalen LDP-OAM-Konfiguration (auf der Hierarchieebene oder) oder in der Konfiguration für die angegebene FEC (auf der Hierarchieebene oder) einschließen.ecmp
periodic-traceroute
[edit protocols ldp oam]
[edit logical-systems logical-system-name protocols ldp oam]
[edit protocols ldp oam fec address]
[edit logical-systems logical-system-name protocols ldp oam fec address]
Andernfalls schlägt der Commit-Vorgang fehl.
Router der ACX-Serie unterstützen die Hierarchieebene [] nicht.edit logical-systems
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 Anweisung im Falle eines BFD-Sitzungsfehlers auf dem LDP-LSP konfigurieren:failure-action
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 Option oder die Option für die Anweisung ein:remove-nexthop
remove-route
failure-action
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 Anweisung entweder auf der Hierarchieebene oder auf der Hierarchieebene konfigurieren.holddown-interval
[edit protocols ldp oam bfd-livenesss-detection]
[edit protocols ldp oam fec address bfd-livenesss-detection]
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. zeigt eine Beispieltopologie.Abbildung 2
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 , 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.Abbildung 3 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 dargestellt.Abbildung 4 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 verwendeten 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 dargestellt.Abbildung 3Abbildung 5 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 Anweisung auf Hierarchieebene ein, zusätzlich zum Aktivieren des RSVP-Protokolls auf den entsprechenden Schnittstellen.dynamic-rsvp-lsp
[edit protocols ldp interface interface-name link-protection]
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 wird der Bezeichnungsvorgang für den Unicast- und Multicast-LDP-Verbindungsschutz veranschaulicht.Abbildung 7
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 Befehlsausgabe auf Router R0 kann der Unicast-LDP-Datenverkehr und der Multicast-LDP-Datenverkehr abgeleitet werden.show route detail
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 Befehl zeigt den Status an, wenn keine LFA für den Linkschutz verfügbar ist.show route detail
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 Befehl kann der Unicast- und Multicast-LDP-Datenverkehr abgeleitet werden.show route detail
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 Befehlsausgabe zu sehen ist, sind die Bezeichnungsvorgänge für den Schutzpfad für Unicast-LDP- und Multicast-LDP-Datenverkehr identisch.show route detail
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 Befehls und der Beschriftungsvorgänge ähnelt dem Modus Fall B, LFA und dynamischem RSVP-LSP.show route detail
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 Anweisung auf Hierarchieebene zu einer LFA-Aktion für den LDP-Unicast-Datenverkehr führt.
link-protection
[edit protocols ospf interface ge-0/0/1.0]
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 Anweisung konfiguriert werden.
strict-targeted-hellos
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 Konfigurationsmodus ein .[edit]
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.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 Befehle , und eingeben.show interfaces
show routing-options
show protocols
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; }
Überprüfung
Ü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.
Was
Führen Sie den Befehl im Betriebsmodus aus.show route tale mpls.0
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.
Was
Führen Sie den Befehl im Betriebsmodus aus.show route table mpls.0 label label extensive
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 Modus konfigurieren, und alle Linecards im Router müssen MPCs sein.network-services enhanced-ip
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 gezeigt.Abbildung 12 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 Anweisung in der IGP-Konfiguration (Interior Gateway Protocol).link-protection
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).https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ldp-configuration.html
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 Konfigurationsanweisung in die Hierarchie ein.mofrr-asm-starg
[edit routing-options multicast stream-protection]
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 Konfigurationsanweisung in der Hierarchie .stream-protection
[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 Konfigurationsanweisung in der Hierarchie, und es wird durch eine Reihe von Filterrichtlinien verwaltet.stream-protection
[edit routing-options multicast]
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.
zeigt diesen Prozess anhand von Beispiel-Primär- und Backup-Schnittstellen für Router mit PIM. zeigt dies ähnlich für Switches mit PIM.Abbildung 13Abbildung 14
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 nicht verfügbar.
show
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 Befehl in Ausgabefeldern wie und höher als erwartet angezeigt werden.
show pfe statistics traffic
Input packets
Output packets
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 Modus eingestellt ist, und alle Linecards auf der Plattform müssen MPCs sein.network-services enhanced-ip
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 Befehls statisch der gewünschten Gruppe beitreten.set protocols igmp interface interface-name static group group
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.
Zeigt die Konfiguration für alle Geräte in an.CLI-SchnellkonfigurationAbbildung 16
In diesem Abschnitt werden die Schritte auf Gerät R3 beschrieben.Konfiguration
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 ein.[edit]
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.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
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 Befehle , , , und eingeben.show chassis
show interfaces
show protocols
show policy-options
show routing-options
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
Überprüfung
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.
Was
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.
Was
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.
Was
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.
Was
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 einschließen.downstream-on-demand[edit protocols ldp session]
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 ( in diesem Beispiel).DOD-Request-Loopbacks
Diese Richtlinie bewirkt, dass der Router Label-Anforderungsnachrichten nur an die FECs weiterleitet, die mit der Richtlinie übereinstimmen.DOD-Request-Loopbacks
[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 Anweisung auf Hierarchieebene an.
dod-request-policy
[edit protocols ldp]
Die mit der Anweisung angegebene Richtlinie wird verwendet, um die Präfixe zum Senden von Bezeichnungsanforderungsnachrichten zu identifizieren.
dod-request-policy
Diese Richtlinie ähnelt einer Ausgangsrichtlinie oder einer Importrichtlinie. Bei der Verarbeitung von Routen aus der Routing-Tabelle inet.0 sucht die Junos OS-Software nach Routen, die der Richtlinie entsprechen (in diesem Beispiel).DOD-Request-Loopbacks
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-Verteilungsmodus zu aktivieren.
downstream-on-demand
[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 ( in diesem Beispiel).
redistribute_ldp
[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 in die BGP-Konfiguration ein (in diesem Beispiel als Teil der BGP-Gruppenkonfiguration ).
redistribute_ldp
ebgp-to-abr
BGP leitet die LDP-Routen basierend auf der Richtlinie an den Remote-PE-Router weiter
redistribute_ldp
[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 von LDP akzeptiert werden.
dod-routes
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 nicht an Nachbarn weitergeleitet werden, und .
do-not-propagate-du-sessions
10.1.1.1
10.2.2.2
10.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 Richtlinie so, dass die von der Richtlinie untersuchten Routen nicht an die benachbarten Router weitergeleitet werden, die in der Richtlinie definiert sind.
filter-dod-on-du-sessions
dod-routes
do-not-propagate-du-sessions
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 Richtlinie als Exportrichtlinie für BGP group an.
filter-dod-routes-on-du-sesssion
ebgp-to-abr
[edit protocols bgp] user@host# set group ebgp-to-abr neighbor 192.168.6.2 export filter-dod-routes-on-du-sessions
Ergebnisse
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle und eingeben.show policy-options
show protocols ldp
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; } }
Überprüfung
Überprüfen des Etikettenankündigungsmodus
Zweck
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Verwenden Sie den Befehl, um den Status des Bezeichnungsankündigungsmodus für die LDP-Sitzung zu überprüfen.show ldp session
Was
Geben Sie die Befehle und ein:show ldp session
show ldp session detail
-
Die folgende Befehlsausgabe für den Befehl gibt an, dass der (Label Advertisement-Modus) ist (was bedeutet, dass die LDP-Downstream-On-Demand-Sitzung betriebsbereit ist):
show ldp session
Adv. Mode
DOD
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 Befehl gibt an, dass der Standardwert ist (d. h., Downstream-On-Demand ist für die lokale Sitzung nicht konfiguriert).
show ldp session detail
Local Label Advertisement mode
Downstream unsolicited
Umgekehrt geben das und beide an, dass in der Remotesitzung konfiguriert istRemote Label Advertisement mode
Negotiated Label Advertisement mode
Downstream on demand
user@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 7552 beschrieben. Konfigurieren Sie die Adressfamilie wie für IPv4 oder für IPv6 oder beides, und die Transporteinstellung ist entweder oder .inet
inet6
IPv4
IPv6
Die 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.dual-transport
Die und IDs sind die beiden LSR-IDs, die konfiguriert werden müssen, um eine LDP-Sitzung über IPv4- und IPv6-TCP-Transport einzurichten.inet-lsr-id
inet6-lsr-id
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 7552 beschrieben. Konfigurieren Sie die Adressfamilie wie für IPv4 oder für IPv6.inet
inet6
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 und sind die beiden LSR-IDs, die konfiguriert werden müssen, um eine LDP-Sitzung über IPv4- und IPv6-TCP-Transport einzurichten.inet-lsr-id
inet6-lsr-id
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 Konfigurationsmodus ein .[edit]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 "" im Junos OS CLI-Benutzerhandbuch. Using the CLI Editor in Configuration Mode https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
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 Befehle und eingeben.show interfacesshow protocols 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 Anweisung so konfigurieren, dass der bevorzugte Transport für eine TCP-Verbindung ausgewählt wird, wenn sowohl IPv4 als auch IPv6 aktiviert sind.transport-preference
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 Befehl eingeben.show protocols 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 Anweisung so konfigurieren, dass LDP eine separate IPv4-Sitzung mit einem IPv4-Nachbarn und eine IPv6-Sitzung mit einem IPv6-Nachbarn einrichten kann.dual-transport
Dies erfordert die Konfiguration als LSR-ID für IPv4 und als LSR-ID für IPv6.inet-lsr-id
inet6-lsr-id
-
(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 Befehl eingeben.show protocols 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; } }
Überprüfung
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um Informationen zur mpls.0-Routing-Tabelle anzuzeigen.show route table mpls.0
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um Informationen zur inet.3-Routing-Tabelle anzuzeigen.show route table inet.3
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um Informationen zur inet6.3-Routing-Tabelle anzuzeigen.show route table inet6.3
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Datenbankinformationen anzuzeigen.show ldp database
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus die Befehle und aus, um LDP-Nachbarinformationen anzuzeigen.show ldp neighbor
show ldp neighbor extensive
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus die Befehle und aus, um LDP-Sitzungsinformationen anzuzeigen.show ldp session
show ldp session extensive
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.
Überprüfung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der LDP-Nachbarinformationen
Zweck
Zeigen Sie die LDP-Nachbarinformationen an.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Nachbarinformationen anzuzeigen.show ldp neighbor extensive
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Sitzungsinformationen anzuzeigen.show ldp session extensive
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.
Überprüfung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der LDP-Nachbarinformationen
Zweck
Zeigen Sie die LDP-Nachbarinformationen an.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Nachbarinformationen anzuzeigen.show ldp neighbor extensive
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.
Was
Führen Sie auf Gerät R1 im Betriebsmodus den Befehl aus, um LDP-Nachbarinformationen anzuzeigen.show ldp session extensive
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 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.mldp-inband-signalling
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.
Hier einige Zahlen zum Generationswechsel:
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. zeigt eine ähnliche M-LDP-Topologie wie , jedoch mit einem anderen Szenario.Abbildung 20Abbildung 19 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 M-LDP-Signalisierung nur dann initiiert, wenn kein PIM-Nachbar in Richtung der Quelle vorhanden ist.mldp-inband-signaling
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 Konfigurationsanweisung zusammen mit gruppenbasierten Filtern in den Richtlinienfilter für M-LDP-Inband-Signale ein.selected-mldp-egress
Der M-LDP-Inband-Signalisierungsrichtlinienfilter kann entweder die Anweisung oder die Anweisung oder eine Kombination aus beidem enthalten.source-address-filter
route-filter
Hier einige Zahlen zum Generationswechsel:
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 Anweisung sollte nur auf dem LER konfiguriert werden.
selected-mldp-egress
Das Konfigurieren der Anweisung auf PIM-Routern ohne Ausgang kann zu Fehlern bei der Pfadeinrichtung führen.selected-mldp-egress
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 Befehl mit der Option (S,G)
mpls lsp point-to-multipoint ping
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 werden die Schritte zu Device EgressPE beschrieben.#d358e62__d358e826
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 ein.[edit]
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.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
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 Befehle , , und eingeben.show interfaces
show protocols
show policy-options
show routing-options
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
Überprüfung
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 Befehl für die Downstreamschnittstelle angezeigt .show pim join extensive
Pseudo-MLDP
Auf dem Ausgang wird der Befehl für die Upstreamschnittstelle angezeigt .show pim join extensive
Pseudo-MLDP
Was
Geben Sie im Betriebsmodus den Befehl ein.show pim join extensive
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.
Was
Geben Sie im Betriebsmodus den Befehl ein.show pim source
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 Befehl die erwarteten root-to-(S,G)-Bindungen anzeigt.show ldp database
Was
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.
Was
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.
Was
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 sagen wir, dass der Datenverkehr, der von links nach rechts fließt, in der SR-Domäne beginnt und in der LDP-Domäne endet.Abbildung 22 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 abgebildet werden sollen.
[edit routing-options source-packet-routing]
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 Hierarchieebene "oder" an.
[edit protocols ospf]
[edit protocols isis]
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 und Routing-Tabellen der SR-Knoten installiert, um LSP-Eingangs- und Stitching-Vorgänge für Datenverkehr von links nach rechts zu erleichtern.
inet.3
mpls.0
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 Anweisung in der Hierarchie .
mapping-client
[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
Siehe, gehen Sie davon aus, dassdevice R2 (im Segment-Routing-Netzwerk) das SRMS ist.Abbildung 22
-
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öße führt dazu, dass der SID-Index 10001 der Loopback-Adresse von R6 zugeordnet wird.2
HINWEIS:Die verwendete IP-Adresse ist eine Loopback-Adresse eines Geräts im LDP-Netzwerk (in diesem Beispiel R5).
start-prefix
Für eine vollständige Konnektivität müssen Sie alle Loopback-Adressen der LDP-Router der SR-Domäne zuordnen. Wenn die Loopbackadressen zusammenhängen, können Sie dies mit einer einzigen Anweisung tun.prefix-segment-range
Nicht zusammenhängende Loopbacks erfordern die Definition mehrerer Präfixzuordnungsanweisungen.In unserem Beispiel werden zusammenhängende Loopbacks verwendet, sodass oben eine einzelne angezeigt wird.
prefix-segment-range
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 Routing-Tabelle von den Segment-Routing-Geräten aktualisiert.
mpls.0
-
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 SRMS erkannt. 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 , nehmen wir an, dass das Gerät R2 (im Segment-Routing-Netzwerk) das SRMS ist.Abbildung 22 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öße führt dazu, dass der SID-Index 10001 der Loopback-Adresse von R6 zugeordnet wird.2
HINWEIS:Die verwendete IP-Adresse ist eine Loopback-Adresse eines Geräts im LDP-Netzwerk (in diesem Beispiel R5).
start-prefix
Für eine vollständige Konnektivität müssen Sie alle Loopback-Adressen der LDP-Router in der SR-Domäne zuordnen. Wenn die Loopbackadressen zusammenhängen, können Sie dies mit einer Anweisung tun.prefix-segment-range
Nicht zusammenhängende Loopbacks erfordern die Definition mehrerer Zuordnungsanweisungen.In unserem Beispiel werden zusammenhängende Loopbacks verwendet, sodass oben eine einzelne angezeigt wird.
prefix-segment-range
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 Routing-Tabelle von den Segment-Routing-Geräten aktualisiert.
mpls.0
-
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 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).track-igp-metric
Um die IGP-Routenmetrik zu verwenden, fügen Sie die folgende Anweisung ein: track-igp-metric
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 Anweisung können Sie verhindern, dass Eingangsrouten der Routingtabelle inet.0 anstelle der Routingtabelle inet.3 hinzugefügt werden, selbst wenn Sie die Anweisung auf der oder der Hierarchieebene aktiviert haben.no-forwarding
traffic-engineering bgp-igp
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
Standardmäßig ist die Anweisung deaktiviert.no-forwarding
Router der ACX-Serie unterstützen die Hierarchieebene [] nicht.edit logical-systems
Um Eingangsrouten aus der inet.0-Routingtabelle auszuschließen, fügen Sie die folgende Anweisung ein: no-forwarding
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 folgende Anweisung ein: explicit-null
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.MPLS-Label-ÜbersichtMPLS-Label-Zuweisung
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).Aktivieren und Deaktivieren von LDP Sie müssen auch die LSPs konfigurieren, für die LDP ausgeführt werden soll, indem Sie die Anweisung auf Hierarchieebene einschließen:ldp-tunneling
[edit protocols mpls label-switched-path lsp-name]
[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.1R1 werden 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-Versionen zeigte 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 folgende Anweisung einfügen: ignore-lsp-metrics
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 [] nicht.edit logical-systems
Um LDP über RSVP-LSPs zu aktivieren, müssen Sie auch noch das Verfahren in Abschnitt ausführen.Aktivieren von LDP über RSVP-etablierte LSPs
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.No link title 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 Anweisung als Teil der Sitzungsgruppe ein: authentication-key
[edit protocols ldp] session-group prefix-length { authentication-key md5-authentication-key; }
Verwenden Sie die Anweisung, um die Adresse für das Remote-Ende der LDP-Sitzung zu konfigurieren.session-group
Das oder Kennwort in der Konfiguration kann bis zu 69 Zeichen lang sein.md5-authentication-key
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 wie OSPF (Open Shortest Path First) und RSVP (Resource Reservation Setup Protocol) zu unterbrechen.
Um den Aktualisierungsmechanismus für den Authentifizierungsschlüssel zu konfigurieren, fügen Sie die Anweisung auf Hierarchieebene ein und geben Sie die Option zum Erstellen eines Schlüsselbunds an, der aus mehreren Authentifizierungsschlüsseln besteht.key-chain
[edit security authentication-key-chains]
key
[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 Anweisung auf Hierarchieebene ein, um das Protokoll den Authentifizierungsschlüsseln zuzuordnen. authentication-key-chain
[edit protocols ldp]
[edit security suthentication-key-chains]
Sie müssen auch den Authentifizierungsalgorithmus konfigurieren, indem Sie die Anweisung in die Hierarchieebene einschließen.authentication-algorithm algorithm
[edit protocols ldp]
[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.Authentication for Routing Protocols
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 Anweisung konfigurieren.session-protection
Mit dieser Option können Sie optional eine Zeit in Sekunden angeben.timeout
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.http://contentapps.juniper.net/mib-explorer/
Um SNMP-Traps für LDP zu deaktivieren, geben Sie die Option für die Anweisung an:trap disable
log-updown
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 Synchronisierung betriebsbereit ist:ldp-synchronization
ldp-synchronization { disable; hold-time seconds; }
Um die Synchronisierung zu deaktivieren, schließen Sie die Anweisung ein.disable
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 nicht vollständig funktionsfähig ist.hold-time
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 Anweisung ein und geben Sie eine Zeit in Sekunden für die Option an:igp-synchronization
holddown-interval
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 Anweisung können Sie diese Verzögerungszeit konfigurieren.label-withdrawal-delay
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 folgende Anweisung ein:label-withdrawal-delay
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 folgende Anweisung ein:allow-subnet-mismatch
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 [] nicht.edit logical-systems
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 auf Hierarchieebene konfigurierte Anweisung angegeben werden.oam
[edit protocols ldp]
Um die regelmäßige LDP-LSP-Traceroute zu konfigurieren, fügen Sie die folgende Anweisung ein:periodic-traceroute
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 Anweisung einzeln oder mit einer der folgenden Optionen konfigurieren:periodic-traceroute
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 Anweisung auf Hierarchieebene konfigurieren, werden die LDP-Datenverkehrsstatistiken regelmäßig erfasst und in eine Datei geschrieben.traffic-statistics
[edit protocols ldp]
Sie können konfigurieren, wie oft Statistiken gesammelt werden (in Sekunden), indem Sie die Option verwenden.interval
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 folgende Anweisung ein:traffic-statistics
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.- Art des Datenverkehrs, der von einem Router stammt, entweder (von diesem Router stammend) oder (über diesen Router weitergeleitet).
Type
Ingress
Transit
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.– Ein Wert gibt an, dass mehrere Präfixe an dieselbe Bezeichnung gebunden sind (z. B. wenn mehrere Präfixe mit einer Ausgangsrichtlinie angekündigt werden).
Shared
Yes
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 Anweisung zusätzlich zur Anweisung konfiguriert haben.deaggregate
traffic-statistics
Für Router, die ihr Limit für die Nutzung der Next-Hop-Route erreichen, empfehlen wir, die Option für die folgende Anweisung zu konfigurieren:no-penultimate-hop
traffic-statistics
traffic-statistics { no-penultimate-hop; }
Eine Liste der Hierarchieebenen, auf denen Sie die Anweisung konfigurieren können, finden Sie im Abschnitt Anweisungszusammenfassung zu dieser Anweisung.traffic-statistics
Wenn Sie die Option konfigurieren, sind keine Statistiken für die FECs verfügbar, die den vorletzten Hop für diesen Router darstellen.no-penultimate-hop
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 Option konfiguriert ist:no-penultimate-hop
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 Anweisung:traffic-statistics
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 Anweisung auf Hierarchieebene angeben, und Sie können LDP-spezifische Optionen angeben, indem Sie die folgende Anweisung einschließen:traceoptions
[edit routing-options]
traceoptions
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 Anweisung, um den Namen der Datei anzugeben, die die Ausgabe des Ablaufverfolgungsvorgangs empfängt.file
Alle Dateien werden im Verzeichnis /var/log abgelegt. Es wird empfohlen, die LDP-Ablaufverfolgungsausgabe in der Datei zu platzieren.ldp-log
Die folgenden Ablaufverfolgungsflags zeigen die Vorgänge an, die mit dem Senden und Empfangen verschiedener LDP-Nachrichten verbunden sind. Jeder kann einen oder mehrere der folgenden Modifikatoren tragen:
address
—Verfolgen Sie den Vorgang von Adress- und Adressrückzugsnachrichten.binding
– Verfolgen Sie Beschriftungsbindungsvorgänge.error
– Verfolgen Sie Fehlerbedingungen.event
– Protokollereignisse verfolgen.initialization
– Verfolgen Sie den Vorgang von Initialisierungsmeldungen.label
: Verfolgen Sie den Vorgang von Label-Anforderungs-, Label-Map-, Label-Withdrawal- und Label-Release-Meldungen.notification
– Verfolgen Sie den Vorgang von Benachrichtigungen.packets
– Verfolgen Sie den Vorgang von Adresse, Adressentzug, Initialisierung, Etikettenanforderung, Etikettenzuordnung, Etikettenentzug, Etikettenfreigabe, Benachrichtigung und regelmäßigen Nachrichten. Dieser Modifikator entspricht dem Festlegen der Modifikatoren , , , und .address
initialization
label
notification
periodic
Sie können den Flag-Modifikator auch mit der Unteroption für das Flag konfigurieren.
filter
match-on address
packets
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: , und .route
path
binding
Das folgende Beispiel veranschaulicht, wie Sie die LDP-Anweisung konfigurieren können, um LDP-Ablaufverfolgungsanweisungen basierend auf einer FEC zu filtern:traceoptions
[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 Option bestimmt.
match-on
Achten Sie beim Konfigurieren der Richtlinie darauf, dass das Standardverhalten immer .reject
Die einzige Option ist .
match-on
fec
Folglich ist die einzige Art von Richtlinie, die Sie einschließen sollten, eine Routenfilterrichtlinie.
Beispiele: Ablaufverfolgung des Datenverkehrs im LDP-Protokoll
Verfolgen Sie LDP-Pfadmeldungen im Detail:
[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.