Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RSVP-Konfiguration

Mindestkonfiguration des RSVP

Um RSVP auf einer einzigen Schnittstelle zu aktivieren, fügen Sie die rsvp Anweisung ein und geben Sie die Schnittstelle mit der interface Anweisung an. Dies ist die mindeste RSVP-Konfiguration. Alle anderen RSVP-Konfigurationsanweisungen sind optional.

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

  • [edit protocols]

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

Um RSVP auf allen Schnittstellen zu aktivieren, ersetzen Sie all die interface-name Variable.

Wenn Sie Schnittstelleneigenschaften für eine Gruppe von Schnittstellen konfiguriert haben und RSVP auf einer der Schnittstellen deaktivieren möchten, fügen Sie die disable Anweisung ein:

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

  • [edit protocols rsvp interface interface-name ]

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

Konfigurieren von RSVP und MPLS

Der Hauptzweck der Junos RSVP-Software ist die Unterstützung dynamischer Signalübertragung innerhalb von Label-Switched Paths (LSPs). Wenn Sie MPLS und RSVP auf einem Router aktivieren, wird MPLS zum Client von RSVP. Für die Bindung von MPLS und RSVP ist keine zusätzliche Konfiguration erforderlich.

Sie können MPLS so konfigurieren, dass signalisierte Pfade mithilfe der label-switched-path Anweisung auf Hierarchieebene [edit protocols mpls] eingerichtet werden. Jeder LSP übersetzt sich in eine Anfrage an RSVP, eine RSVP-Sitzung zu initiieren. Diese Anforderung wird über die interne Schnittstelle zwischen Label Switching und RSVP weitergeleitet. Nachdem die Anforderungsinformationen untersucht, der RSVP-Status geprüft und die lokalen Routingtabellen geprüft wurden, initiiert RSVP eine Sitzung für jeden LSP. Die Sitzung wird vom lokalen Router bezogen und ist für das Ziel des LSP bestimmt.

Wenn eine RSVP-Sitzung erfolgreich erstellt wird, wird der LSP entlang der von der RSVP-Sitzung erstellten Pfade eingerichtet. Wenn die RSVP-Sitzung nicht erfolgreich ist, benachrichtigt RSVP MPLS über ihren Status. Es liegt an MPLS, Backup-Pfade zu initiieren oder den ursprünglichen Pfad erneut zu versuchen.

Um Informationen zur Label-Switching-Signalübertragung weiterzugeben, unterstützt RSVP vier zusätzliche Objekte: Label Request-Objekt, Label-Objekt, Explicit Route-Objekt und Datensatz-Route-Objekt. Damit ein LSP erfolgreich eingerichtet werden kann, müssen alle Router auf dem Pfad MPLS, RSVP und die vier Objekte unterstützen. Von den vier Objekten ist das Objekt "Record Route" nicht zwingend erforderlich.

Gehen Sie zum Konfigurieren von MPLS und zum Client von RSVP wie folgt vor:

  • Aktivieren Sie MPLS auf allen Routern, die am Label-Switching teilnehmen (d. h. auf allen Routern, die Teil eines Label-Switching-Pfads sein könnten).

  • Aktivieren Sie RSVP auf allen Routern und an allen Routerschnittstellen, die den LSP bilden.

  • Konfigurieren Sie die Router am Anfang des LSP.

Sie können RSVP Label Switched Paths (LSPs) so konfigurieren, dass eine Verzögerungsmetrik für die Berechnung des Pfads verwendet wird. Verwenden Sie zum Konfigurieren die CLI-Optionen, die wir unter der [edit protocols mpls label-switched-path name] Hierarchie eingeführt haben.

Beispiel: Konfigurieren von RSVP und MPLS

Im Folgenden sehen Sie eine Beispielkonfiguration für einen Router am Anfang eines LSP:

Im Folgenden sehen Sie eine Beispielkonfiguration für alle anderen Router, die den LSP bilden:

Konfigurieren von RSVP-Schnittstellen

In den folgenden Abschnitten wird die Konfiguration von RSVP-Schnittstellen beschrieben:

Konfigurieren der RSVP-Aktualisierungsreduzierung

Sie können die RSVP-Aktualisierungsreduzierung auf jeder Schnittstelle konfigurieren, indem Sie die folgenden Anweisungen in die Schnittstellenkonfiguration einbeziehen:

  • aggregate und reliable— Alle Funktionen zur RSVP-Aktualisierungsreduzierung aktivieren: RSVP-Nachrichtenbündelung, RSVP-Nachrichten-ID, zuverlässige Nachrichtenübermittlung und Zusammenfassungsaktualisierung.

    Um eine Aktualisierungsreduzierung und zuverlässige Bereitstellung zu ermöglichen, müssen Sie die aggregate Informationen und reliable Anweisungen enthalten.

  • no-aggregate— Deaktivieren Sie die Bündelung von RSVP-Nachrichten und die Aktualisierung der Zusammenfassung.

  • no-reliable— Deaktivieren Sie die RSVP-Nachrichten-ID, die zuverlässige Nachrichtenübermittlung und die Zusammenfassungsaktualisierung.

Weitere Informationen zur Reduzierung der RSVP-Aktualisierung finden Sie unter RSVP Refresh Reduction.

Wenn die no-reliable Anweisung auf dem Router konfiguriert ist (zuverlässige Nachrichtenübermittlung ist deaktiviert), akzeptiert der Router RSVP-Nachrichten, die das Message ID-Objekt enthalten, ignoriert aber das Message ID-Objekt und führt die Standard-Nachrichtenverarbeitung fort. In diesem Fall wird kein Fehler generiert, und RSVP funktioniert normalerweise.

Allerdings funktionieren nicht alle Kombinationen zwischen zwei Nachbarn mit unterschiedlichen Aktualisierungsverkleinerungsfunktionen korrekt. Beispielsweise wird ein Router entweder mit der aggregate Anweisung und no-reliable Anweisung oder mit der und no-aggregate den reliable Anweisungen konfiguriert. Wenn ein RSVP-Nachbar ein Summary Refresh-Objekt an diesen Router sendet, wird kein Fehler generiert, aber das Summary Refresh-Objekt kann nicht verarbeitet werden. Daher können RSVP-Zustände auf diesem Router eine Auszeit nehmen, wenn der Nachbar sich nur auf Summary Refresh verlässt, um diese RSVP-Zustände zu aktualisieren.

Wir empfehlen, die RSVP-Aktualisierungsreduzierung bei jedem RSVP-Nachbarn auf ähnliche Weise zu konfigurieren, es sei denn, es gibt spezifische Anforderungen.

Um alle RSVP-Aktualisierungsfunktionen auf einer Schnittstelle zu aktivieren, fügen Sie die aggregate Anweisung ein:

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

  • [edit protocols rsvp interface interface-name]

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

Um die RSVP-Nachrichtenbündelung und Zusammenfassungsaktualisierung zu deaktivieren, fügen Sie die no-aggregate Anweisung ein:

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

  • [edit protocols rsvp interface interface-name]

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

Um die RSVP-Nachrichten-ID und die zuverlässige Nachrichtenübermittlung an einer Schnittstelle zu ermöglichen, fügen Sie die reliable Anweisung ein:

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

  • [edit protocols rsvp interface interface-name]

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

Um die RSVP-Nachrichten-ID, die zuverlässige Nachrichtenübermittlung und die Zusammenfassungsaktualisierung zu deaktivieren, fügen Sie die no-reliable Anweisung ein:

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

  • [edit protocols rsvp interface interface-name]

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

Bestimmung der Aktualisierungsreduktionsfunktion von RSVP Neighbors

Um die RSVP-Aktualisierungsfunktion eines RSVP-Nachbarn zu bestimmen, benötigen Sie die folgenden Informationen:

  • Das vom Nachbarn angekündigte RR-Bit

  • Die lokale Konfiguration der RSVP-Aktualisierungsreduzierung

  • Die tatsächlichen RSVP-Nachrichten, die vom Nachbarn empfangen wurden

Um diese Informationen zu erhalten, können Sie einen show rsvp neighbor detail Befehl ausstellen. Die Beispielausgabe folgt:

Weitere Informationen zum show rsvp neighbor detail Befehl.

Konfiguration des RSVP Hello Interval

RSVP überwacht den Status der Nachbarn des Interior Gateway Protocol (IGP) (IS-IS oder OSPF) und stützt sich auf die IGP-Protokolle, um zu erkennen, wenn ein Knoten ausfällt. Wenn ein IGP-Protokoll einen Nachbarn deklariert (weil keine Hello-Pakete mehr empfangen werden), führt RSVP auch den Nachbar herunter. Die IGP-Protokolle und RSVP agieren jedoch immer noch unabhängig, wenn sie einen Nachbarn aufziehen.

Bei Routern von Juniper Networks hat die Konfiguration eines kürzeren oder längeren RSVP-Hello-Intervalls keine Auswirkungen darauf, ob eine RSVP-Sitzung beendet wird oder nicht. RSVP-Sitzungen werden auch dann beibehalten, wenn RSVP-Hello-Pakete nicht mehr empfangen werden. RSVP-Sitzungen werden so lange aufrechterhalten, bis entweder der Router keine IGP-Hello-Pakete mehr empfängt, oder die Auszeit für RSVP-Pfad- und Resv-Nachrichten. Doch ab Junos OS Version 16.1 werden die RSVP-Sitzungen heruntergefahren, wenn DIE RSVP-Nachrichten aus der Auszeit gesendet werden.

Das RSVP-Hello-Intervall kann auch beeinträchtigt werden, wenn die Geräte eines anderen Anbieters eine RSVP-Sitzung lahmlegen. Beispielsweise kann ein benachbarter Router von Juniper Networks so konfiguriert werden, dass er RSVP Hello Packets überwacht.

Um zu ändern, wie oft RSVP Hello-Pakete sendet, fügen Sie die hello-interval Anweisung ein:

Anmerkung:

Ab Version 16.1 sendet Junos RSVP-Hello-Nachrichten über einen Bypass-LSP, wenn eine verfügbar ist. Erfahren Sie, wie Sie no-node-hello-on-bypass auf das historische Verhalten des Sendens von Hallos über den IGP Next Hop zurückgreifen können.

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

Konfigurieren der RSVP-Authentifizierung

Alle RSVP-Protokollaustausche können authentifiziert werden, um sicherzustellen, dass nur vertrauenswürdige Nachbarn an der Einrichtung von Reservierungen teilnehmen. Standardmäßig ist die RSVP-Authentifizierung deaktiviert.

Die RSVP-Authentifizierung verwendet einen nachrichtenbasierten Hashed Message Authentication Code (HMAC)-MD5 nachrichtenbasierten Digest. Dieses Schema erzeugt einen Nachrichten-Digest basierend auf einem geheimen Authentifizierungsschlüssel und dem Nachrichteninhalt. (Der Nachrichteninhalt enthält auch eine Sequenznummer.) Der berechnete Digest wird mit RSVP-Nachrichten übertragen. Sobald Sie die Authentifizierung konfiguriert haben, werden alle empfangenen und übertragenen RSVP-Nachrichten mit allen Nachbarn an dieser Schnittstelle authentifiziert.

Die MD5-Authentifizierung bietet Schutz vor Fälschung und Nachrichtenmodifikation. Es kann auch Replay-Angriffe verhindern. Sie bietet jedoch keine Vertraulichkeit, da alle Nachrichten im Klartext gesendet werden.

Standardmäßig ist die Authentifizierung deaktiviert. Um die Authentifizierung zu aktivieren, konfigurieren Sie einen Schlüssel auf jeder Schnittstelle, indem Sie die authentication-key Anweisung:

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

  • [edit protocols rsvp interface interface-name]

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

Konfigurieren des Bandbreitenabonnements für Klassentypen

Standardmäßig ermöglicht RSVP die Verwendung von 100 Prozent der Bandbreite für einen Klassentyp für RSVP-Reservierungen. Wenn Sie einen Klassentyp für einen mehrschichtigen LSP überschreiben, darf die gesamtnachfrage aller RSVP-Sitzungen die tatsächliche Kapazität des Klassentyps überschreiten.

Detaillierte Anweisungen zur Konfiguration des Bandbreitenabonnements für Klassentypen finden Sie unter Konfigurieren des Prozentsatzes der Bandbreitenabonnemente für LSPs.

Konfigurieren des RSVP-Update-Schwellenwerts an einer Schnittstelle

Die Interior Gateway Protocols (IGPs) verwalten die Traffic-Engineering-Datenbank, aber die aktuelle verfügbare Bandbreite auf den Traffic-Engineering-Datenbankverbindungen stammt von RSVP. Wenn sich die Bandbreite einer Verbindung ändert, informiert RSVP die IGPs, die dann die Traffic-Engineering-Datenbank aktualisieren und die neuen Bandbreiteninformationen an alle Netzwerkknoten weiterleiten können. Die Netzwerkknoten wissen dann, wie viel Bandbreite auf der Datenverkehrs-Engineering-Datenbankverbindung verfügbar ist (lokal oder remote), und CSPF kann die Pfade richtig berechnen.

IGP-Updates können jedoch übermäßige Systemressourcen verbrauchen. Je nach Anzahl der Knoten in einem Netzwerk ist es möglicherweise nicht wünschenswert, ein IGP-Update für kleine Änderungen der Bandbreite durchzuführen. Durch Die Konfiguration der update-threshold Anweisung auf Hierarchieebene [edit protocols rsvp] können Sie den Schwellenwert anpassen, an dem eine Änderung der reservierten Bandbreite ein IGP-Update ausgelöst hat.

Sie können einen Wert von 0,001 bis 20 Prozent (Standardmäßig 10 Prozent) für das Auslösen eines IGP-Updates konfigurieren. Wenn die Änderung der reservierten Bandbreite größer oder gleich dem konfigurierten Schwellwert der statischen Bandbreite an dieser Schnittstelle ist, erfolgt eine IGP-Aktualisierung. Wenn Sie beispielsweise die update-threshold Anweisung auf 15 Prozent konfiguriert haben und der Router feststellt, dass sich die reservierte Bandbreite auf einer Verbindung um 10 Prozent der Verbindungsbandbreite geändert hat, löst RSVP kein IGP-Update aus. Wenn sich die reservierte Bandbreite auf einer Verbindung jedoch um 20 Prozent der Verbindungsbandbreite ändert, löst RSVP ein IGP-Update aus.

Sie können den Schwellenwert auch mithilfe der Option unter der threshold-valueupdate-threshold Anweisung als absoluten Wert konfigurieren.

Wenn der Schwellwert auf mehr als 20 % der Bandbreite auf dieser Verbindung konfiguriert ist, wird der Schwellenwert auf 20 % der Bandbreite begrenzt.

Wenn beispielsweise die Bandbreite an einer Schnittstelle 1 Gbit/s beträgt und die threshold-value Konfiguration über 200 Mbit/s liegt, ist die threshold-value Bandbreite auf 200 Mbit/s begrenzt. Der Schwellwert wird als 20,000 % und der threshold-value als 200 Mbit/s angezeigt.

Anmerkung:

Die beiden Optionen Schwellwert und threshold-valueProzent schließen sich gegenseitig aus. Sie können zu einem bestimmten Zeitpunkt nur eine Option konfigurieren, um ein IGP-Update für Reservierungen mit geringerer Bandbreite zu generieren. Wenn also eine Option konfiguriert ist, wird die andere Option berechnet und in der CLI angezeigt.

Wenn beispielsweise bei einer Verbindung von 1 Gbit/s der Schwellenwert %, der auf 5 % konfiguriert ist, threshold-value berechnet und mit 50 Mbit/s angezeigt wird. In ähnlicher Weise wird der threshold-valueSchwellwert berechnet und als 5 % angezeigt, wenn er auf 50 m konfiguriert ist.

Um den Schwellenwert anzupassen, bei dem eine Änderung der reservierten Bandbreite ein IGP-Update ausgelöst hat, fügen Sie die Update-Schwellwertanweisung ein. Aufgrund des Update-Schwellenwerts ist es für Constrained Shortest Path First (CSPF) möglich, einen Pfad mithilfe veralteter Datenverkehrs-Engineering-Datenbankbandbreiteninformationen auf einer Verbindung zu berechnen. Wenn RSVP versucht, einen LSP über diesen Pfad zu erstellen, wird möglicherweise festgestellt, dass die Bandbreite auf dieser Verbindung unzureichend ist. In diesem Fall löst RSVP ein IGP Traffic Engineering-Datenbankupdate aus und überflutet die aktualisierten Bandbreiteninformationen im Netzwerk. CSPF kann dann den Pfad mithilfe der aktualisierten Bandbreiteninformationen neu komputieren und versuchen, einen anderen Pfad zu finden, um den überlasteten Link zu vermeiden. Beachten Sie, dass diese Funktionalität standardmäßig ist und keine zusätzliche Konfiguration benötigt.

Sie können die rsvp-error-hold-time Anweisung auf Hierarchie [edit protocols mpls] - oder [edit logical-systems logical-system-name protocols mpls] Hierarchieebene konfigurieren, um die Genauigkeit der Traffic Engineering-Datenbank (einschließlich der Genauigkeit von Bandbreitenschätzungen für LSPs) mithilfe von Informationen zu verbessern, die von PathErr-Nachrichten bereitgestellt werden. Siehe Verbessern der Genauigkeit der Traffic Engineering-Datenbank mit RSVP PathErr-Nachrichten.

RSVP-Konfiguration für nicht nummerierte Schnittstellen

Das Junos OS unterstützt RSVP Traffic Engineering über nicht nummerierte Schnittstellen. Traffic Engineering-Informationen über nicht nummerierte Verbindungen werden in den IGP Traffic Engineering-Erweiterungen für OSPF und IS-IS übertragen, wie in RFC 4203 beschrieben, OSPF-Erweiterungen zur Unterstützung von Generalized Multi-Protocol Label Switching (GMPLS) und RFC 4205, Intermediate System to Intermediate System (IS-IS) Erweiterungen zur Unterstützung von Generalized Multi-Protocol Label Switching (GMPLS). Nicht nummerierte Verbindungen können auch in der TRAFFIC Engineering-Signalisierung von MPLS angegeben werden, wie in RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) beschrieben. Mit dieser Funktion können Sie vermeiden, dass Sie IP-Adressen für jede Schnittstelle konfigurieren müssen, die am RSVP-signalisierten Netzwerk teilnimmt.

Um RSVP für nicht nummerierte Schnittstellen zu konfigurieren, müssen Sie den Router mit einer Router-ID konfigurieren, wobei die router-id auf der [edit routing-options] Hierarchieebene angegebene Anweisung verwendet wird. Die Router-ID muss für das Routing verfügbar sein (Sie können normalerweise die Loopback-Adresse verwenden). Die RSVP-Steuermeldungen für die nicht nummerierten Links werden mit der Router-ID-Adresse (anstelle einer zufällig ausgewählten Adresse) gesendet.

Um link protection und fast reroute auf einem Router mit nicht nummerierten Schnittstellen zu konfigurieren, müssen Sie mindestens zwei Adressen konfigurieren. Wir empfehlen, neben der Konfiguration der Router-ID auch eine sekundäre Schnittstelle auf dem Loopback zu konfigurieren.

Konfiguration von RSVP Node-ID Hallo

Sie können node-ID-basierte RSVP-Hellos konfigurieren, um sicherzustellen, dass Die Router von Juniper Networks mit der Ausrüstung anderer Anbieter kompatibel sind. Junos OS verwendet standardmäßig schnittstellenbasierte RSVP Hellos. Node-ID-basierte RSVP Hellos sind in RFC 4558 angegeben, Node-ID Based Resource Reservation Protocol (RSVP) Hallo: Eine Klarstellung. RSVP-Node-ID-Hellos sind nützlich, wenn Sie BFD so konfiguriert haben, dass Probleme über RSVP-Schnittstellen erkannt werden, sodass Sie Schnittstellen-Hellos für diese Schnittstellen deaktivieren können. Sie können auch Node-ID Hellos für den unterbrechungsfreien Neustart verwenden.

Node-ID hellos kann für alle RSVP-Nachbarn global aktiviert werden. Standardmäßig ist die Node-ID Hello-Unterstützung deaktiviert. Wenn Sie RSVP-Knoten-IDs auf dem Router nicht aktiviert haben, akzeptiert Junos OS keine Hello-Pakete mit Node-ID.

Anmerkung:

Ab Version 16.1 sendet Junos RSVP-Hello-Nachrichten über einen Bypass-LSP, wenn eine verfügbar ist. Erfahren Sie, wie Sie no-node-hello-on-bypass auf das historische Verhalten des Sendens von Hallos über den IGP Next Hop zurückgreifen können.

Um RSVP Node-ID Hellos global auf dem Router zu aktivieren, fügen Sie die node-hello-Anweisung auf den folgenden Hierarchieebenen ein:

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

Sie können auch RSVP-Schnittstelle hellos global explizit deaktivieren. Diese Art von Konfiguration kann in Netzwerken erforderlich sein, in denen der Router von Juniper Networks über zahlreiche RSVP-Verbindungen mit Geräten anderer Anbieter verfügt. Wenn Sie jedoch die RSVP-Schnittstelle hellos global deaktivieren, können Sie auch ein Hello-Intervall auf einer RSVP-Schnittstelle mithilfe der Hello-Interval-Anweisung konfigurieren. Diese Konfiguration deaktiviert die RSVP-Schnittstelle weltweit, ermöglicht aber RSVP-Schnittstellen-Hellos auf der angegebenen Schnittstelle (der RSVP-Schnittstelle, auf der Sie die hello-interval Anweisung konfigurieren). Diese Konfiguration kann in einem heterogenen Netzwerk erforderlich sein, in dem einige Geräte RSVP Node-ID Hellos und andere Geräte RSVP-Schnittstelle hallo unterstützen.

Um die RSVP-Schnittstelle "Hellos global" auf dem Router zu deaktivieren, fügen Sie die no-interface-hello-Anweisung auf den folgenden Hierarchieebenen ein:

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

Beispiel: Konfigurieren von RSVP-signalisierten LSPs

In diesem Beispiel wird gezeigt, wie ein LSP zwischen Routern in einem IP-Netzwerk unter Verwendung von RSVP als Signalprotokoll erstellt wird.

Anforderungen

Bevor Sie beginnen, löschen Sie Sicherheitsdienste vom Gerät. Siehe Beispiel: Sicherheitsservices löschen.

Überblick und Topologie

Mit RSVP als Signalisierungsprotokoll können Sie LSPs zwischen Routern in einem IP-Netzwerk erstellen. In diesem Beispiel konfigurieren Sie ein Beispielnetzwerk wie in Abbildung 1dargestellt.

Topologie

Abbildung 1: Typischer RSVP-signalisierter LSPTypischer RSVP-signalisierter LSP

Um einen LSP zwischen Routern zu erstellen, müssen Sie die MPLS-Familie einzeln aktivieren und RSVP auf jeder der Transitschnittstellen im MPLS-Netzwerk konfigurieren. Dieses Beispiel zeigt, wie SIE MPLS aktivieren und RSVP auf der Ge-0/0/0-Transitschnittstelle konfigurieren. Darüber hinaus müssen Sie den MPLS-Prozess auf allen MPLS-Schnittstellen im Netzwerk aktivieren.

Dieses Beispiel zeigt, wie Sie einen LSP von R1 bis R7 auf dem Ingress-Router (R1) mit der Loopback-Adresse von R7 (10.0.9.7) definieren. Die Konfiguration reserviert eine Bandbreite von 10 Mbit/s. Darüber hinaus deaktiviert die Konfiguration den CSPF-Algorithmus und stellt sicher, dass die Hosts C1 und C2 den RSVP-signalisierten LSP verwenden, der dem kürzesten Pfad des Netzwerks entspricht.

Konfiguration

Verfahren

CLI-Schnellkonfiguration

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

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie RSVP:

  1. Aktivieren Sie die MPLS-Familie auf allen Transitschnittstellen im MPLS-Netzwerk.

  2. Aktivieren Sie RSVP auf jeder Transitschnittstelle im MPLS-Netzwerk.

  3. Aktivieren Sie den MPLS-Prozess an der Transitschnittstelle im MPLS-Netzwerk.

  4. Beschreiben Sie den LSP auf dem Eingangsrouter.

  5. Reservieren Sie 10 Mbit/s Bandbreite auf dem LSP.

Ergebnisse

Bestätigen Sie Ihre Konfiguration, indem Sie den Befehl aus dem show Konfigurationsmodus eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Zur Kürze enthält diese show Befehlsausgabe nur die Konfiguration, die für dieses Beispiel relevant ist. Jede andere Konfiguration des Systems wurde durch Ellipsen ersetzt (...).

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Überprüfung

Um zu bestätigen, dass die Konfiguration ordnungsgemäß funktioniert, führen Sie folgende Aufgaben aus:

Überprüfen von RSVP-Nachbarn

Zweck

Vergewissern Sie sich, dass auf jedem Gerät die entsprechenden RSVP-Nachbarn angezeigt werden, z. B. dass Router R1 sowohl Abbildung 1 Router R3 als auch Router R2 als RSVP-Nachbarn auflistet.

Aktion

Geben Sie über die CLI den show rsvp neighbor Befehl ein.

Die Ausgabe zeigt die IP-Adressen der benachbarten Router an. Vergewissern Sie sich, dass jede benachbarte RSVP-Router-Loopback-Adresse aufgeführt ist.

Überprüfen von RSVP-Sitzungen

Zweck

Überprüfen Sie, ob eine RSVP-Sitzung zwischen allen RSVP-Nachbarn eingerichtet wurde. Vergewissern Sie sich außerdem, dass der Bandbreitenreservierungswert aktiv ist.

Aktion

Geben Sie über die CLI den show rsvp session detail Befehl ein.

Die Ausgabe zeigt die detaillierten Informationen, einschließlich Sitzungs-IDs, Bandbreitenreservierung und Next-Hop-Adressen für jede etablierte RSVP-Sitzung. Überprüfen Sie die folgenden Informationen:

  • Jede RSVP-Nachbaradresse hat einen Eintrag für jeden Nachbarn, der nach Loopback-Adresse aufgeführt ist.

  • Der Status für jede LSP-Sitzung lautet Up.

  • Für Tspecwird der entsprechende Bandbreitenwert 10Mbpsangezeigt.

Überprüfen des Vorhandenseins von RSVP-signalisierten LSPs

Zweck

Vergewissern Sie sich, dass die Routing-Tabelle des Eingangsrouter mit einem konfigurierten LSP an die Loopback-Adresse des anderen Routers verfügt. Überprüfen Sie beispielsweise, ob die inet.3 Routingtabelle des R1-Einstiegsrouters in Abbildung 1 über einen konfigurierten LSP zur Loopback-Adresse des Routers R7 verfügt.

Aktion

Geben Sie über die CLI den show route table inet.3 Befehl ein.

Die Ausgabe zeigt die RSVP-Routen, die in der inet.3 Routingtabelle vorhanden sind. Vergewissern Sie sich, dass ein RSVP-signalisierter LSP mit der Loopback-Adresse des Exit-Routers (R7) im MPLS-Netzwerk verbunden ist.

Beispiel: Automatisches RSVP-Mesh konfigurieren

Service Provider verwenden häufig BGP- und MPLS-VPNs, um das Netzwerk effizient zu skalieren und gleichzeitig umsatzsteigernde Services bereitzustellen. In diesen Umgebungen wird BGP verwendet, um die VPN-Routing-Informationen über das Netzwerk des Service Providers zu verteilen, während MPLS zur Weiterleitung des VPN-Datenverkehrs von einer VPN-Site an eine andere verwendet wird.

Beim Hinzufügen eines neuen PE-Routers, der an BGP- und MPLS-VPNs teilnimmt, müssen alle zuvor vorhandenen PE-Router so konfiguriert werden, dass sie mit dem neuen PE-Router für BGP und MPLS peeren. Wenn jeder neue PE-Router dem Netzwerk des Service Providers hinzugefügt wird, wird die Konfigurationslast bald zu viel, um sie zu bewältigen.

Die Konfigurationsanforderungen für BGP-Peering können mithilfe von Routenreflektoren reduziert werden. In MIT RSVP signalisierten MPLS-Netzwerken kann das automatische RSVP-Mesh den Konfigurationsaufwand für den MPLS-Teil des Netzwerks minimieren. Durch die Konfiguration rsvp-te auf allen PE-Routern kann RSVP automatisch die benötigten LSPs erstellen, wenn ein neuer PE-Router hinzugefügt wird.

Anforderungen

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

  • Ein Router, auf dem Junos OS Version 10.1 oder höher ausgeführt wird.

  • Ein BGP- und MPLS-VPN unter Verwendung von RSVP als LSP-Signalübertragungsprotokoll (Label Switched Path, MPLS Label Switched Path).

Überblick

Dieses Beispiel zeigt, wie Sie mithilfe der rsvp-te Konfigurationsanweisung ein automatisches RSVP-Mesh auf einem PE-Router konfigurieren. Damit das automatische RSVP-Mesh ordnungsgemäß funktioniert, müssen alle PE-Router in der Full-Mesh-Konfiguration die rsvp-te Anweisung konfiguriert haben. Auf diese Weise wird sichergestellt, dass alle neuen PE-Router, die später hinzugefügt werden, auch von der automatischen Mesh-Funktion profitieren, sofern auch sie mit der rsvp-te Anweisung konfiguriert sind.

Angesichts dieser Voraussetzung zeigt dieses Beispiel nur die Konfiguration auf dem neu hinzugefügten PE-Router. Es wird davon ausgegangen, dass das automatische RSVP-Mesh bereits auf den vorhandenen PE-Routern konfiguriert wurde.

Topologie

In Abbildung 2gibt es drei vorhandene PE-Router, PE1, PE2 und PE3, in der Topologie. PE4 wurde hinzugefügt und das automatische RSVP-Mesh wird konfiguriert. Die Cloud repräsentiert das Service Provider-Netzwerk, und die Netzwerkadresse 192.0.2.0/24 wird in der Mitte der Abbildung dargestellt.

Abbildung 2: Service Provider-Netzwerk mit PE-RouternService Provider-Netzwerk mit PE-Routern

Konfiguration

Die Konfiguration des automatischen RSVP-Mesh erfordert die Ausführung dieser Aufgaben:

  • Aktivieren der rsvp-te Konfigurationsanweisung auf Hierarchieebene [edit routing-options dynamic-tunnels dynamic-tunnel-name] .

  • Konfigurieren des erforderlichen destination-networks Elements.

    Dieses Konfigurationselement gibt den IPv4-Präfixbereich für das Zielnetzwerk an. Es können nur Tunnel innerhalb des angegebenen Prefix-Bereichs erstellt werden.

  • Konfigurieren des erforderlichen label-switched-path-template Elements.

    Dieses Konfigurationselement nimmt entweder default-template oder den Namen einer vorkonfigurierten LSP-Vorlage als Argument. Bei dieser default-template Vorlage handelt es sich um eine systemdefinierte Vorlage, für die keine Benutzerkonfiguration erforderlich ist.

CLI-Schnellkonfiguration

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

PE4-Router

Automatisches RSVP-Mesh konfigurieren

Schritt-für-Schritt-Verfahren

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

So aktivieren Sie das automatische RSVP-Mesh:

  1. Konfigurieren Sie rsvp-te auf Hierarchieebene [edit routing-options dynamic-tunnels] .

  2. Konfigurieren Sie destination-networks auf Hierarchieebene [edit routing-options dynamic-tunnels] .

Ergebnisse

Geben Sie den show Befehl von der [edit routing-options dynamic-tunnels] Hierarchieebene aus, um die Ergebnisse ihrer Konfiguration zu sehen:

Überprüfung

Überprüfen der Existenz automatischer RSVP-Mesh-Tunnel auf Router-PE4

Zweck

Um den Betrieb des neu konfigurierten PE4-Routers zu überprüfen, geben Sie den Befehl aus dem show dynamic-tunnels database Betriebsmodus aus. Dieser Befehl zeigt das Zielnetzwerk an, zu dem dynamische Tunnel erstellt werden können.

Aktion

Überprüfen der Existenz von MPLS-LSPs auf Router-PE4

Zweck

Um die Existenz von MPLS-LSPs auf dem PE4-Router zu überprüfen, geben Sie den Befehl aus dem show mpls lsp Betriebsmodus aus. Dieser Befehl zeigt den Status der MPLS-LSPs an.

Aktion

Konfigurieren von "Hello Acknowledgementments for Nonsession RSVP Neighbors"

Die hello-acknowledgements Anweisung steuert das Hello-Bestätigungsverhalten zwischen RSVP-Nachbarn, unabhängig davon, ob sie sich in derselben Sitzung befinden oder nicht.

Hallo Nachrichten, die von RSVP-Nachbarn empfangen werden, die nicht Teil einer normalen RSVP-Sitzung sind, werden verworfen. Wenn Sie die hello-acknowledgements Anweisung auf Hierarchieebene [edit protocols rsvp] konfigurieren, werden Hello-Nachrichten von Nichtsitzungsnachbarn mit einer Hello-Bestätigungsnachricht bestätigt. Wenn Hallos von Nichtsessionsnachbarn empfangen werden, wird eine RSVP-Nachbarbeziehung erstellt und periodische Hallo-Nachrichten können jetzt vom Nichtsitzungsnachbarn empfangen werden. Die hello-acknowledgements Anweisung ist standardmäßig deaktiviert. Die Konfiguration dieser Anweisung ermöglicht die Entdeckung von RSVP-fähigen Routern mit Hello-Paketen und überprüft, ob die Schnittstelle RSVP-Pakete empfangen kann, bevor MPLS-LSP-Setup-Nachrichten gesendet werden.

Sobald Sie Hello-Bestätigungen für NICHT-Sitzungs-RSVP-Nachbarn aktiviert haben, erkennt der Router weiterhin Hello-Nachrichten von nicht-Sitzungs-RSVP-Nachbarn, es sei denn, die Schnittstelle selbst läuft ab oder Sie ändern die Konfiguration. Schnittstellenbasierte Nachbarn altern nicht automatisch.

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

  • [edit protocols rsvp]

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

Switching-LSPs weg von einem Netzwerkknoten

Sie können den Router so konfigurieren, dass aktive LSPs über einen für eine Schnittstelle aktivierten Bypass-LSP von einem Netzwerkknoten entfernt werden. Diese Funktion kann verwendet werden, um aktive Netzwerke aufrechtzuerhalten, wenn ein Gerät ersetzt werden muss, ohne den Datenverkehr im Netzwerk zu unterbrechen. Die LSPs können entweder statisch oder dynamisch sein.

  1. Sie müssen zunächst entweder den Link- oder Knotenschutz für den Datenverkehr konfigurieren, der das netzwerkorientierte Gerät passieren muss, das Sie deaktivieren möchten. Um ordnungsgemäß funktionieren zu können, muss der Bypass-LSP eine andere logische Schnittstelle als der geschützte LSP verwenden.
  2. Um den Router so vorzubereiten, dass er den Datenverkehr von einem Netzwerkknoten wegschaltet, konfigurieren Sie die always-mark-connection-protection-tlv Anweisung:

    Der Router markiert dann den gesamten OAM-Datenverkehr, der über diese Schnittstelle übertragen wird, und bereitet den Datenverkehr auf einen alternativen Pfad basierend auf der OAM-Funktionalität vor.

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

    • [edit protocols mpls interface interface-name]

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

  3. Anschließend müssen Sie die switch-away-lsps Anweisung so konfigurieren, dass der Datenverkehr vom geschützten LSP auf den Bypass-LSP umgestellt wird, wodurch das Standard-Downstream-Netzwerkgerät effektiv umgangen wird. Die tatsächliche Verbindung selbst wird durch diese Konfiguration nicht heruntergefahren.

    Um den Router so zu konfigurieren, dass er den Datenverkehr von einem Netzwerkknoten wegschaltet, konfigurieren Sie die switch-away-lsps Anweisung:

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

    • [edit protocols mpls interface interface-name]

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

Beachten Sie die folgenden Einschränkungen im Zusammenhang mit dem Switching aktiver LSPs weg von einem Netzwerkknoten:

  • Die Switch-Away-Funktion wird nur auf Routern der MX-Serie unterstützt.

  • Die Switch-Away-Funktion wird nicht für das Switching des Datenverkehrs von primären Point-to-Multipoint-LSPs zur Umgehung von Point-to-Multipoint-LSPs unterstützt. Wenn Sie die switch-away-lsps Anweisung für einen Point-to-Multipoint-LSP konfigurieren, wird der Datenverkehr nicht auf den Bypass-Point-to-Multipoint-LSP geschaltet.

  • Wenn Sie die Switch-Away-Funktion auf einer Schnittstelle entlang des Pfads eines dynamischen LSP konfigurieren, können über diesem Pfad keine neuen dynamischen LSPs eingerichtet werden. Die Switch-Away-Funktion verhindert das Make-before-Break-Verhalten von LSPs mit RSVP-Signalen. Das Make-before-Break-Verhalten bewirkt normalerweise, dass der Router zuerst versucht, ein dynamisches LSP neu zu signalisieren, bevor das Original abgerissen wird.

Konfiguration von RSVP-Einrichtungsschutz

Sie können den Fast Reroute-Mechanismus für Facility-Backup konfigurieren, um einen Einrichtungsschutz für LSPs zu bieten, die gerade signalisiert werden. Es werden sowohl Point-to-Point-LSPs als auch Point-to-Multipoint-LSPs unterstützt. Diese Funktion ist in folgendem Szenario anwendbar:

  1. Eine fehlgeschlagene Verbindung oder ein ausgefallener Knoten ist auf dem strengen expliziten Pfad eines LSP vorhanden, bevor der LSP signalisiert wird.

  2. Es gibt auch einen Bypass-LSP, der die Verbindung oder den Knoten schützt.

  3. RSVP signalisiert den LSP durch den Bypass-LSP. Der LSP scheint so, als wäre er ursprünglich entlang seines primären Pfads eingerichtet und dann wegen des Verbindungs- oder Knotenfehlers auf den Bypass-LSP übergegangen.

  4. Wenn die Verbindung oder der Knoten wiederhergestellt wurde, kann der LSP automatisch auf den primären Pfad zurückgesetzt werden.

Sie sollten die setup-protection Anweisung auf [edit protocols rsvp] jedem der Router entlang des LSP-Pfads konfigurieren, auf dem Sie den LSP-Einrichtungsschutz aktivieren möchten. Sie sollten auch das IGP Traffic Engineering auf allen Routern auf dem LSP-Pfad konfigurieren. Sie können einen show rsvp session Befehl ausstellen, um zu bestimmen, ob der LSP einen Einrichtungsschutz auf einem Router aktiviert hat, der als Point of Local Repair (PLR) oder als Merge Point fungiert.

Um den RSVP-Einrichtungsschutz zu aktivieren, fügen Sie die setup-protection Anweisung ein

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

  • [edit protocols rsvp]

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

Konfiguration von Load Balancing über RSVP-LSPs hinweg

Wenn Sie standardmäßig mehrere RSVP-LSPs für denselben Ausgangsrouter konfiguriert haben, wird der LSP mit der niedrigsten Metrik ausgewählt und überträgt den gesamten Datenverkehr. Wenn alle LSPs dieselbe Metrik haben, wird einer der LSPs nach dem Zufallsprinzip ausgewählt und der gesamte Datenverkehr wird über sie weitergeleitet.

Alternativ können Sie den Datenverkehr über alle LSPs durch Aktivieren des Load Balancing pro Paket lastausgleichen.

Konfigurieren Sie die policy-statement Anweisung wie folgt, um das Load Balancing pro Paket auf einem Ingress-LSP zu ermöglichen:

Anschließend müssen Sie diese Anweisung als Exportrichtlinie auf die Weiterleitungstabelle anwenden.

Nach der Anwendung des Lastausgleichs pro Paket wird der Datenverkehr gleichmäßig zwischen den LSPs verteilt (standardmäßig).

Sie müssen den Lastausgleich pro Paket konfigurieren, wenn Sie PFE Fast Reroute aktivieren möchten. Um PFE Fast Reroute zu aktivieren, fügen Sie die Anweisung für den policy-statement Lastausgleich pro Paket in die Konfiguration jedes Routers, in dem eine Umleitung stattfinden könnte, in diesen Abschnitt ein. Siehe auch Konfiguration von Fast Reroute.

Sie können auch den Datenverkehr zwischen den LSPs proportional zur für jeden LSP konfigurierten Bandbreitenmenge lastausgleichen. Diese Funktion kann Datenverkehr in Netzwerken mit asymmetrischen Bandbreitenfunktionen besser über externe Verbindungen verteilen, da die konfigurierte Bandbreite eines LSP in der Regel die Datenverkehrskapazität dieses LSP widerspiegelt.

Zum Konfigurieren von RSVP LSP-Load Balancing fügen Sie die load-balance Anweisung mit der bandwidth Option ein:

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

  • [edit protocols rsvp]

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

Beachten Sie bei der Verwendung der load-balance Anweisung folgende Informationen:

  • Wenn Sie die load-balance Anweisung konfigurieren, wird das Verhalten der derzeit ausgeführten LSPs nicht geändert. Um die derzeit ausgeführten LSPs zur Verwendung des neuen Verhaltens zu zwingen, können Sie einen clear mpls lsp Befehl ausführen.

  • Die load-balance Anweisung gilt nur für Ingress-LSPs, die pro Paket Load Balancing aktiviert haben.

  • Für differenzierte Services–aware Traffic Engineered LSPs wird die Bandbreite eines LSP berechnet, indem die Bandbreite aller Klassentypen summiert wird.

Automatisches RSVP-Mesh konfigurieren

Sie können RSVP so konfigurieren, dass Point-to-Point Label Switched Paths (LSPs) automatisch für jeden neuen PE-Router erstellt werden, der zu einem vollen Mesh von LSPs hinzugefügt wird. Um diese Funktion zu aktivieren, müssen Sie die rsvp-te Anweisung auf allen PE-Routern im Full-Mesh konfigurieren.

Anmerkung:

Sie können die automatische RSVP-Mesh-Konfiguration nicht zusammen mit CCC konfigurieren. CCC kann die dynamisch generierten LSPs nicht verwenden.

Um die automatische RSVP-Mesh-Konfiguration zu konfigurieren, geben Sie die rsvp-te Anweisung ein:

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

  • [edit routing-options dynamic-tunnels tunnel-name]

  • [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

Sie müssen auch die folgenden Anweisungen konfigurieren, um ein automatisches RSVP-Mesh zu aktivieren:

  • destination-networks— Geben Sie den Prefix-Bereich der IP-Version 4 (IPv4) für das Zielnetzwerk an. Dynamische Tunnel innerhalb des angegebenen IPv4-Präfixbereichs können initiiert werden.

  • label-switched-path-template (Multicast)— Sie können entweder die Standardvorlage explizit mit der default-template Option konfigurieren, oder Sie können eine eigene LSP-Vorlage mithilfe der template-name Option konfigurieren. Die LSP-Vorlage fungiert als Modellkonfiguration für die dynamisch generierten LSPs.

Konfigurieren von Timern für RSVP-Aktualisierungsmeldungen

RSVP verwendet zwei verwandte Zeitsteuerungsparameter:

  • refresh-time— Die Aktualisierungszeit steuert das Intervall zwischen der Generierung aufeinanderfolgender Aktualisierungsnachrichten. Der Standardwert für die Aktualisierungszeit beträgt 45 Sekunden. Diese Zahl wird aus dem Standardwert 30 der refresh-time Anweisung abgeleitet und mit einem festen Wert von 1,5 multipliziert. Diese Berechnung unterscheidet sich von RFC 2205, was besagt, dass die Aktualisierungszeit mit einem Zufallswert im Bereich von 0,5 bis 1,5 multipliziert werden sollte.

    Zu den Aktualisierungsnachrichten gehören Pfad- und Resv-Nachrichten. Nachrichten werden regelmäßig aktualisiert, damit die Reservierungszustände in benachbarten Knoten nicht auszeiten. Jeder Pfad und jede Resv-Nachricht trägt den Aktualisierungszeitpunkt, und der empfangende Knoten extrahiert diesen Wert aus den Nachrichten.

  • keep-multiplier— Der Keep-Multiplikator ist eine kleine, lokal konfigurierte Ganzzahl von 1 bis 255. Der Standardwert ist 3. Es gibt die Anzahl der Nachrichten an, die verlorengehen können, bevor ein bestimmter Zustand für veraltet erklärt wird und gelöscht werden muss. Der Keep-Multiplikator wirkt sich direkt auf die Lebensdauer eines RSVP-Status aus.

Um die Lebensdauer eines Reservierungsstatus zu bestimmen, verwenden Sie die folgende Formel:

Im schlimmsten Fall müssen (keep-multiplier – 1) aufeinanderfolgende Aktualisierungsmeldungen verlorengehen, bevor ein Reservierungsstatus gelöscht wird.

Wir empfehlen nicht, einen kurzen RSVP Hello Timer zu konfigurieren. Wenn eine schnelle Erkennung eines fehlgeschlagenen Nachbarn erforderlich ist, konfigurieren Sie kurze IGP -Hello-Timer (OSPF oder IS-IS).

Der Aktualisierungszeitwert beträgt standardmäßig 30 Sekunden. Um diesen Wert zu ändern, fügen Sie die refresh-time Anweisung ein:

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

  • [edit protocols rsvp]

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

Der Standardwert des Keep-Multiplikators ist 3. Um diesen Wert zu ändern, fügen Sie die keep-multiplier Anweisung ein:

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

  • [edit protocols rsvp]

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

Vorbereitung auf RSVP-Sitzungen

Wenn die Bandbreite nicht ausreicht, um alle RSVP-Sitzungen zu verarbeiten, können Sie die Preemption von RSVP-Sitzungen steuern. Standardmäßig wird eine RSVP-Sitzung nur durch eine neue Sitzung mit höherer Priorität unterbrochen.

Um eine Sitzung immer vorzubelasten, wenn die Bandbreite nicht ausreicht, fügen Sie die preemption Anweisung mit der aggressive Option ein:

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

  • [edit protocols rsvp]

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

Um die RSVP-Sitzungsvorbereitung zu deaktivieren, fügen Sie die preemption Anweisung mit der disabled Option ein:

Um zum Standard zurückzukehren (d. s. eine Sitzung nur für eine neue Sitzung mit höherer Priorität zu trennen), fügen Sie die preemption Anweisung mit der normal Option ein:

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

  • [edit protocols rsvp]

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

Konfigurieren der MTU-Signalübertragung in RSVP

Um MTU-Signalübertragung (Maximum Transmission Unit) in RSVP zu konfigurieren, müssen Sie MPLS so konfigurieren, dass IP-Pakete fragmentiert werden können, bevor sie in MPLS eingekapselt werden. Sie müssen auch die MTU-Signalübertragung in RSVP konfigurieren. Zur Fehlerbehebung können Sie mtu-Signalübertragung allein konfigurieren, ohne die Paketfragmentierung zu aktivieren.

Zum Konfigurieren der MTU-Signalisierung in RSVP fügen Sie die path-mtu Anweisung ein:

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

  • [edit protocols mpls]

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

In den folgenden Abschnitten wird beschrieben, wie Paketfragmentierung und MTU-Signalübertragung in RSVP aktiviert werden:

Aktivieren der MTU-Signalübertragung in RSVP

Um MTU-Signalübertragung in RSVP zu aktivieren, fügen Sie die rsvp mtu-signaling Anweisung ein:

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

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

Sobald Sie die Konfiguration festgelegt haben, werden änderungen am MTU-Signalverhalten für RSVP wirksam, wenn der Pfad das nächste Mal aktualisiert wird.

Sie können die mtu-signaling Anweisung auf Hierarchieebene [edit protocols mpls path-mtu rsvp] selbst konfigurieren. Dies kann für die Fehlerbehebung nützlich sein. Wenn Sie nur die mtu-signaling Anweisung konfigurieren, können Sie mithilfe des show rsvp session detail Befehls bestimmen, was die kleinste MTU auf einem LSP ist. Der show rsvp session detail Befehl zeigt den MTU-Wert an, der empfangen und im Adspec-Objekt gesendet wird.

Aktivieren der Paketfragmentierung

Um zu ermöglichen, dass IP-Pakete fragmentiert werden, bevor sie in MPLS eingekapselt werden, fügen Sie die allow-fragmentation Anweisung ein:

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

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

    Anmerkung:

    Konfigurieren Sie die allow-fragmentation Anweisung nicht allein. Konfigurieren Sie sie immer zusammen mit der mtu-signaling Anweisung.

Konfigurieren von Ultimate-Hop Popping für LSPs

Standardmäßig verwenden RSVP-signalisierte LSPs penultimate-hop popping (PHP). Abbildung 3 zeigt einen vorletzten Hop aufspringenden LSP zwischen Router PE1 und Router PE2. Router CE1 leitet ein Paket an seinen nächsten Hop (Router PE1) weiter, der auch der LSP-Eingang ist. Der Router PE1 überträgt das Label 1 auf das Paket und leitet das markierte Paket an den Router P1 weiter. Der Router P1 schließt den Standardmäßigen MPLS-Label-Swapping-Vorgang ab, tauscht label 1 gegen Label 2 aus und leitet das Paket an Router P2 weiter. Da der Router P2 der vorletzte Hop-Router für den LSP-zu-Router-PE2 ist, öffnet er zuerst das Label und leitet das Paket dann an Router PE2 weiter. Wenn Router PE2 das Paket empfängt, kann es über ein Service-Label, ein Explicit-Null-Label oder einfach nur ein IP- oder VPLS-Paket verfügen. Der Router PE2 leitet das nicht gekennzeichnete Paket an Router CE2 weiter.

Abbildung 3: Penultimate Hop Popping für einen LSPPenultimate Hop Popping für einen LSP

Sie können auch ultimate-hop popping (UHP) (wie in Abbildung 4dargestellt) für RSVP-signalisierte LSPs konfigurieren. Bei einigen Netzwerkanwendungen kann es erforderlich sein, dass Pakete mit einem nicht null äußeren Label am Ausgangsrouter (Router PE2) ankommen. Für einen ultimativen Hop-Popping-LSP führt der vorletzte Router (Router P2 in Abbildung 4) den Standard-MPLS-Label-Swapping-Vorgang durch (in diesem Beispiel Label 2 für Label 3), bevor das Paket an den Ausgangsrouter PE2 weitergeleitet wird. Router PE2 öffnet das äußere Label und führt eine zweite Suche der Paketadresse durch, um das Endziel zu bestimmen. Anschließend leitet es das Paket an das entsprechende Ziel weiter (entweder Router CE2 oder Router CE4).

Abbildung 4: Ultimativer Hop-Popping für einen LSPUltimativer Hop-Popping für einen LSP

Die folgenden Netzwerkanwendungen erfordern die Konfiguration von UHP-LSPs:

  • MPLS-TP zur Leistungsüberwachung und In-Band-OAM

  • Virtuelle Circuits mit Edge-Schutz

Die folgenden Funktionen unterstützen das UHP-Verhalten nicht:

  • LDP-signalisierte LSPs

  • Statische LSPs

  • Point-to-Multipoint-LSPs

  • CCC

  • traceroute Befehl

Weitere Informationen zum UHP-Verhalten finden Sie unter Internet draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP Behavior und Out-of-Band Mapping für RSVP-TE LSPs.

Für punktweise RSVP-signalisierte LSPs wird das UHP-Verhalten vom LSP-Eingang signalisiert. Basierend auf der Ingress-Routerkonfiguration kann RSVP das UHP LSP mit dem Nicht-PHP-Flag-Set signalisieren. RSVP PATH-Nachrichten tragen die beiden Flags im LSP-ATTRIBUTES-Objekt. Wenn der Ausgangsrouter die PATH-Nachricht empfängt, weist er dem LSP ein Nicht-Null-Label zu. RSVP erstellt und installiert außerdem zwei Routen in der mpls.0-Routingtabelle. S bezieht sich auf das S-Bit des MPLS-Labels, das angibt, ob der untere Rand des Labelstacks erreicht wurde oder nicht.

  • Route S=0: Gibt an, dass sich mehr Labels im Stack befinden. Der nächste Hop für diese Route zeigt auf die mpls.0-Routingtabelle und löst eine verkettete MPLS-Labelsuche aus, um die verbleibenden MPLS-Labels im Stack zu erkennen.

  • Route S=1: Gibt an, dass es keine weiteren Labels gibt. Der nächste Hop verweist auf die Routing-Tabelle inet.0, wenn die Plattform verkettete Und Multi-Family-Suche unterstützt. Alternativ kann die Labelroute auf eine VT-Schnittstelle verweisen, um die IP-Weiterleitung zu initiieren.

Wenn Sie UHP-LSPs aktivieren, können MPLS-Anwendungen wie Layer-3-VPNs, VPLS, Layer-2-VPNs und Layer-2-Circuits die UHP-LSPs verwenden. Im Folgenden wird erläutert, wie SICH UHP-LSPs auf die verschiedenen Arten von MPLS-Anwendungen auswirken:

  • Layer-2-VPNs und Layer-2-Circuits: Ein Paket kommt mit zwei Labeln am PE-Router (Ausgang des UHP-LSP) an. Das äußere Label (S=0) ist das UHP-Label, und das innere Label (S=1) ist das VC-Label . Eine Suche basierend auf dem Transportetikett führt zu einem Tabellenhandler für die mpls.0-Routingtabelle. Es gibt eine zusätzliche Route in der mpls.0-Routingtabelle, die dem inneren Label entspricht. Eine Suche basierend auf dem inneren Label führt zum NÄCHSTEN Hop des CE-Routers.

  • Layer-3-VPN: Ein Paket kommt mit zwei Labeln am PE-Router (Ausgang des UHP-LSP) an. Das äußere Label (S=0) ist das UHP-Label, und das innere Label ist das VPN-Label (S=1). Eine Suche basierend auf dem Transportetikett führt zum Tabellenhandler für die mpls.0-Routingtabelle. In diesem Szenario gibt es zwei Fälle. Layer-3-VPNs werben standardmäßig mit dem Label pro nächstem Hop. Eine Suche basierend auf dem inneren Label führt zum nächsten Hop zum CE-Router. Wenn Sie jedoch die Anweisung für die vrf-table-label Layer-3-VPN-Routinginstanz konfiguriert haben, verweist das innere LSI-Label auf die VRF-Routingtabelle. Eine IP-Suche wird auch für die VRF-Routingtabelle abgeschlossen.

    Anmerkung:

    UHP für mit der Anweisung konfigurierte Layer-3-VPNs wird nur auf universellen 5G-Routing-Plattformen der vrf-table-label MX-Serie unterstützt.

  • VPLS: Ein Paket kommt mit zwei Labeln am PE-Router (Ausgang des UHP-LSP) an. Das äußere Label ist das Transportetikett (S=0) und das innere Label das VPLS-Label (S=1). Eine Suche basierend auf dem Transportetikett führt zum Tabellenhandler für die mpls.0-Routingtabelle. Eine Suche basierend auf dem inneren Label in der mpls.0-Routingtabelle führt zur LSI-Tunnelschnittstelle der VPLS-Routinginstanz, wenn Tunneldienste nicht konfiguriert sind (oder eine VT-Schnittstelle nicht verfügbar ist). Router der MX 3D-Serie unterstützen verkettete Suche und Suche mit mehreren Produktfamilien.

    Anmerkung:

    UHP für MIT der Anweisung konfigurierte VPLS wird nur auf Routern der no-tunnel-service MX 3D-Serie unterstützt.

  • IPv4 über MPLS: Ein Paket kommt mit einem Label (S=1) am PE-Router an (Ausgang des UHP-LSP). Eine Suche basierend auf diesem Label gibt eine VT-Tunnelschnittstelle zurück. Eine weitere IP-Suche wird an der VT-Schnittstelle ausgeführt, um zu bestimmen, wo das Paket weitergeleitet werden soll. Wenn die Routing-Plattform Multi-Family- und Chained-Lookups (z. B. MX 3D-Router und Paketübertragungs-Router der PTX-Serie) unterstützt, erfolgt die Suche basierend auf Label Route(S=1)-Punkten auf die Routing-Tabelle inet.0.

  • IPv6 über MPLS: Für IPv6-Tunneling über MPLS werben PE-Router IPv6-Routen untereinander mit einem Labelwert von 2. Dies ist das explizite Null-Label für IPv6. Aus diesem Grund pushen die Forwarding Next Hops für IPv6-Routen, die von Remote-PE-Routern gelernt werden, normalerweise zwei Labels. Das innere Label ist 2 (es könnte anders sein, wenn der PE-Werberouter von einem anderen Anbieter stammt), und das Router-Label ist das LSP-Label. Pakete kommen mit zwei Labeln am PE-Router (Ausgang des UHP-LSP) an. Das äußere Label ist das Transport-Label (S=0), und das innere Label ist das IPv6 Explicit-Null-Label (Label 2). Die Suche basierend auf dem inneren Label in der mpls.0-Routingtabelle leitet zurück zur mpls.0-Routingtabelle. Auf Routern der MX 3D-Serie wird das innere Label (Label 2) entfernt und eine IPv6-Suche mithilfe der Routing-Tabelle inet6.0 durchgeführt.

  • Aktivierung von PHP- und UHP-LSPs: Sie können sowohl PHP- als auch UHP-LSPs über den gleichen Netzwerkpfad konfigurieren. Sie können PHP- und UHP-Datenverkehr trennen, indem Sie LSP Next Hops mit einem regulären Ausdruck mit der install-nexthop Anweisung weiterleiten. Sie können den Datenverkehr auch trennen, indem Sie die LSPs einfach entsprechend benennen.

Die folgenden Anweisungen ermöglichen ultimatives Hop-Popping für einen LSP. Sie können diese Funktion auf einem bestimmten LSP oder für alle auf dem Router konfigurierten Eingangs-LSPs aktivieren. Konfigurieren Sie diese Anweisungen auf dem Router am LSP-Eingang.

  1. Um ultimatives Hop-Popping zu ermöglichen, fügen Sie die ultimate-hop-popping Anweisung ein:

    Fügen Sie diese Anweisung auf der [edit protocols mpls label-switched-path label-switched-path-name] Hierarchieebene ein, um das Ultimative Hop-Popping auf einem bestimmten LSP zu ermöglichen. Fügen Sie diese Anweisung auf der [edit protocols mpls] Hierarchieebene ein, um das ultimative Hop-Popping auf allen auf dem Router konfigurierten Eingangs-LSPs zu ermöglichen. Sie können die ultimate-hop-popping Anweisung auch unter den entsprechenden [edit logical-routers] Hierarchieebenen konfigurieren.

    Anmerkung:

    Wenn Sie ultimatives Hop-Popping ermöglichen, versucht RSVP, vorhandene LSPs als ultimative Hop-LSPs make-before-break-Weise neu zu signalisieren. Wenn ein Egress-Router das Ultimative Hop-Popping nicht unterstützt, wird der vorhandene LSP heruntergerissen (RSVP sendet eine PathTear-Nachricht entlang des Pfads eines LSP, entfernt den Pfadstatus und den abhängigen Reservierungsstatus und freigegeben die zugehörigen Netzwerkressourcen).

    Wenn Sie ultimate-hop popping deaktivieren, gibt RSVP vorhandene LSPs als vorletztes Hop-Popping-LSPs auf make-before-break-Weise neu an.

  2. Wenn Sie sowohl ultimative Hop-Popping- als auch verkettete Next Hops nur auf Routern der MX 3D-Serie aktivieren möchten, müssen Sie auch die Option für die enhanced-ipnetwork-services Anweisung konfigurieren:

    Sie konfigurieren diese Anweisung auf Hierarchieebene [edit chassis] . Sobald Sie die network-services Anweisung konfiguriert haben, müssen Sie den Router neu starten, um UHP-Verhalten zu aktivieren.

Konfigurieren von RSVP zum Pop-the-Label auf dem Ultimate-Hop-Router

Sie können den auf dem Ausgangsrouter eines LSP angegebenen Labelwert steuern. Das standardmäßig angekündigte Label ist Label 3 (Implizites Null-Label). Wenn Label 3 angekündigt wird, entfernt der vorletzte Hop-Router das Label und sendet das Paket an den Ausgangsrouter. Wenn ultimate-hop popping aktiviert ist, wird Label 0 (IP Version 4 [IPv4] Explicit Null Label) angekündigt. Ultimate-Hop-Popping stellt sicher, dass alle Pakete, die ein MPLS-Netzwerk passieren, ein Label enthalten.

Anmerkung:

Router von Juniper Networks Warteschlangenpakete basierend auf dem eingehenden Label. Router von anderen Anbietern könnten Pakete unterschiedlich in die Warteschlangen warteschlangen. Bedenken Sie dies bei der Arbeit mit Netzwerken, die Router von mehreren Anbietern enthalten.

Um ultimate-hop popping für RSVP zu konfigurieren, fügen Sie die explicit-null Anweisung ein:

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

  • [edit protocols mpls]

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

Ermöglichen von Ultimativem Hop-Popping auf Point-to-Multipoint-LSPs

Standardmäßig wird für Point-to-Point- und Point-to-Multipoint-LSPs das vorletzte Hop-Popping für MPLS-Datenverkehr verwendet. MPLS-Labels werden kurz vor dem Egress-Router des LSP von Paketen auf dem Router entfernt. Die einfachen IP-Pakete werden dann an den Ausgangsrouter weitergeleitet. Für ultimatives Hop-Popping ist der Egress-Router sowohl für das Entfernen des MPLS-Labels als auch die Verarbeitung des einfachen IP-Pakets verantwortlich.

Es kann besonders dann von Vorteil sein, wenn der Transitdatenverkehr über dasselbe Ausgangsgerät übertragen wird, das ultimative Hop-Popping auf Point-to-Multipoint-LSPs ermöglicht. Wenn Sie ultimate-hop-Popping aktivieren, kann eine einzelne Kopie des Datenverkehrs über den eingehenden Link gesendet werden, wodurch erhebliche Bandbreite eingespart wird. Standardmäßig ist das Ultimative Hop-Popping deaktiviert.

Sie ermöglichen das ultimative Hop-Popping für Point-to-Multipoint-LSPs, indem Sie die tunnel-services Anweisung konfigurieren. Wenn Sie das Ultimative Hop-Popping aktivieren, wählt Junos OS eine der verfügbaren VT-Schnittstellen (Virtual Loopback Tunnel) aus, um die Pakete zur IP-Weiterleitung an das PFE zurückzuleiten. Standardmäßig wird der VT-Schnittstellenauswahlprozess automatisch ausgeführt. Die Bandbreitenzugangskontrolle wird verwendet, um die Anzahl der LSPs zu begrenzen, die auf einer VT-Schnittstelle verwendet werden können. Sobald die gesamte Bandbreite auf einer Schnittstelle verbraucht wird, wählt Junos OS eine andere VT-Schnittstelle mit ausreichend Bandbreite für die Zugangskontrolle aus.

Wenn ein LSP mehr Bandbreite benötigt, als von einer der VT-Schnittstellen verfügbar ist, kann das Ultimative Hop-Popping nicht aktiviert werden und stattdessen ist das vorletzte Hop-Popping aktiviert.

Damit die Point-to-Multipoint-LSPs am ultimativen Hop ordnungsgemäß funktionieren können, muss der Ausgangsrouter über eine PIC verfügen, die Tunneldienste wie die Tunneldienste-PIC oder die PIC für adaptive Dienste bereitstellt. Tunneldienste sind für das Herausbrechen des endgültigen MPLS-Labels und für die Rückgabe von Paketen für IP-Adressensuche erforderlich.

Sie können explizit konfigurieren, welche VT-Schnittstellen den RSVP-Datenverkehr verarbeiten, indem Sie die devices Option für die tunnel-services Anweisung einbeziehen. Mit devices dieser Option können Sie angeben, welche VT-Schnittstellen von RSVP verwendet werden sollen. Wenn Sie diese Option nicht konfigurieren, können alle für den Router verfügbaren VT-Schnittstellen verwendet werden.

Um das ultimative Hop-Popping für die Ausgangs-Point-to-Multipoint-LSPs auf einem Router zu ermöglichen, konfigurieren Sie die tunnel-services Anweisung:

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

  • [edit protocols rsvp]

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

Um ultimatives Hop-Popping für Ausgangs-Point-to-Multipoint-LSPs zu ermöglichen, müssen Sie die interface Anweisung auch mit der all Option konfigurieren:

Sie müssen diese Anweisung auf Hierarchieebene [edit protocols rsvp] konfigurieren.

Ablaufverfolgung des RSVP-Protokolldatenverkehrs

Um den RSVP-Protokolldatenverkehr zu verfolgen, fügen Sie die traceoptions Anweisung ein:

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

  • [edit protocols rsvp]

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

Sie können die folgenden RSVP-spezifischen Flags in der RSVP-Anweisung traceoptions angeben:

Verwenden Sie die file Anweisung, um den Namen der Datei anzugeben, die die Ausgabe des Ablaufverfolgungsvorgangs empfängt. Alle Dateien werden im Verzeichnis /var/logabgelegt. Wir empfehlen, die RSVP-Tracing-Ausgabe in der Datei rsvp-logzu platzieren.

  • all— Alle Ablaufverfolgungsvorgänge.

  • error– Alle erkannten Fehlerbedingungen

  • event— RSVP-bezogene Ereignisse (hilft bei der Verfolgung von Ereignissen im Zusammenhang mit RSVP-Unterbrechungsneustart)

  • lmp— Interaktionen zwischen RSVP-Link Management Protocol (LMP)

  • packets– Alle RSVP-Pakete

  • path— Alle Pfadmeldungen

  • pathtear—PathTear-Nachrichten

  • resv— Resv-Nachrichten

  • resvtear— ResvTear-Nachrichten

  • route— Routing-Informationen

  • state— Übergänge zum Sitzungsstatus, auch wenn LSPs mit RSVP-Signalen hoch- und abgehen.

Anmerkung:

Verwenden Sie das all Trace-Flag und den detail Flag-Modifikator mit Vorsicht, da diese dazu führen können, dass die CPU sehr beschäftigt wird.

Um die beim Aktivieren von RSVP Traceoptions generierte Protokolldatei anzuzeigen, geben Sie den show log file-name Befehl aus, wobei file-name die Datei ist, die Sie mit der traceoptions Anweisung angegeben haben.

Allgemeine Informationen zu Tracing- und globalen Tracing-Optionen finden Sie in der Junos OS Routing Protocols Library for Routing Devices.

Beispiele: Ablaufverfolgung des RSVP-Protokolldatenverkehrs

RSVP-Pfadmeldungen im Detail verfolgen:

Verfolgen Sie alle RSVP-Nachrichten:

Verfolgen Sie alle RSVP-Fehlerbedingungen:

RSVP-Statusübergänge nachverfolgen:

RSVP-Protokolldateiausgabe

Im Folgenden finden Sie die Beispielausgabe, die durch die Ausgabe des show log file-name Befehls auf einem Router erzeugt wird, auf dem RSVP-Traceoptions mit konfiguriertem state Flag aktiviert wurden. Der RSVP-signalisierte LSP E-D wird am 11. März 14:04:36.707092 abgerissen. Am 11. März 14:05:30.101492 wird gezeigt, dass sie wieder verfügbar ist.

RSVP Graceful Restart

Der unterbrechungsfreier RSVP-Neustart ermöglicht einen Router, der einen Neustart durchläuft, um seine benachbarten Nachbarn über seinen Zustand zu informieren. Der neustartende Router fordert vom Nachbarn oder Peer eine Nachfrist, die dann mit dem neustartenden Router zusammenarbeiten kann. Der neustartende Router kann während des Neustartzeitraums weiterhin MPLS-Datenverkehr weiterleiten; die Konvergenz im Netzwerk nicht unterbrochen wird. Der Neustart ist für den Rest des Netzwerks nicht sichtbar, und der Neustart-Router wird nicht aus der Netzwerktopologie entfernt. Der unterbrechungsfreier RSVP-Neustart kann sowohl auf Transitroutern als auch ingress-Routern aktiviert werden. Es ist sowohl für Point-to-Point-LSPs als auch für Point-to-Multipoint-LSPs verfügbar.

Der unterbrechungsfreier RSVP-Neustart wird in den folgenden Abschnitten beschrieben:

RSVP Graceful Restart-Terminologie

Restart-Zeit (in Millisekunden)

Der Standardwert beträgt 60.000 Millisekunden (1 Minute). Die Restart-Zeit wird in der Hello-Nachricht angegeben. Die Zeit gibt an, wie lange ein Nachbar warten soll, um eine Hello-Nachricht von einem neustartenden Router zu erhalten, bevor er den Router für tot erklärt und den Status bereinigen kann.

Das Junos OS kann die angekündigte Neustartzeit eines Nachbarn überschreiben, wenn die Zeit mehr als ein Drittel der lokalen Restartzeit beträgt. Angesichts der Standardneustartzeit von 60 Sekunden wartet ein Router beispielsweise 20 Sekunden oder weniger, um eine Hello-Nachricht von einem neustartenden Nachbarn zu erhalten. Wenn die Neustartzeit null ist, kann der neustartende Nachbar sofort für tot erklärt werden.

Wiederherstellungszeit (in Millisekunden)

Gilt nur, wenn der Steuerkanal aktiv ist (der Hello Exchange ist abgeschlossen), bevor die Neustartzeit erfolgt. Gilt nur für Knotenfehler.

Wenn ein unterbrechungsfreier Neustart durchgeführt wird, wird die zeit bis zum Abschluss einer Wiederherstellungszeit angegeben. Zu anderen Zeiten ist dieser Wert Null. Die maximale angekündigte Wiederherstellungszeit beträgt 2 Minuten (120.000 Millisekunden).

Während der Wiederherstellungszeit versucht ein neustartender Knoten, seinen verlorenen Status mit Unterstützung seiner Nachbarn wiederherzustellen. Der Nachbar des neustartenden Knotens muss die Pfadmeldungen mit den Wiederherstellungsetiketten innerhalb eines Zeitraums von einer Hälfte der Wiederherstellungszeit an den neustartenden Knoten senden. Der neustartende Knoten betrachtet den unterbrechungsfreien Neustart nach der angekündigten Wiederherstellungszeit als abgeschlossen.

RSVP Graceful Restart-Betrieb

Damit der RSVP-Neustart unterbrechungsfrei funktioniert, muss die Funktion in der globalen Routinginstanz aktiviert sein. Der unterbrechungsfreier RSVP-Neustart kann auf Protokollebene (nur für RSVP) oder auf globaler Ebene für alle Protokolle deaktiviert werden.

Der unterbrechungsfreier RSVP-Neustart erfordert die folgenden Schritte eines Neustart-Routers und der Nachbarn des Routers:

  • Beim Neustart des Routers versucht der RSVP-Neustart, die von RSVP und den zugewiesenen Labels installierten Routen aufrechtzuerhalten, sodass der Datenverkehr ohne Unterbrechung weitergeleitet wird. Der unterbrechungsfreier RSVP-Neustart erfolgt schnell genug, um die Auswirkungen auf benachbarte Knoten zu reduzieren oder zu beseitigen.

  • Die benachbarten Router müssen den RSVP-Hilfsmodus für den Unterbrechungsneustart aktiviert haben, damit sie einen Router beim Neustart von RSVP unterstützen können.

Ein Objekt namens Restart Cap, das in RSVP-Hello-Nachrichten gesendet wird, kündigt die Restart-Funktion eines Knotens an. Der benachbarte Knoten sendet ein Recover Label-Objekt an den neustartenden Knoten, um seinen Weiterleitungsstatus wiederherzustellen. Dieses Objekt ist im Wesentlichen das alte Label, das der neustartende Knoten angekündigt hat, bevor der Knoten ausfällt.

In der folgenden Liste sind die RSVP-Verhalten beim Unterbrechungsneustart aufgeführt, die je nach Konfiguration und aktivierten Funktionen variieren:

  • Wenn Sie den Helper-Modus deaktivieren, versucht Das Junos OS nicht, einen Neighbor Restart RSVP zu unterstützen. Alle Informationen, die mit einem Restart Cap-Objekt von einem Nachbarn eintreffen, werden ignoriert.

  • Wenn Sie einen Unterbrechungsneustart unter der Konfiguration der Routinginstanz aktivieren, kann der Router mit Hilfe seiner Nachbarn unterbrechungsfrei neu gestartet werden. RSVP kündigt ein Restart Cap-Objekt (RSVP RESTART) in Hello-Nachrichten an, in denen Neustart- und Wiederherstellungszeiten angegeben werden (weder der Wert ist 0).

  • Wenn Sie den RSVP-Unterbrechungsneustart unter der [protocols rsvp] Hierarchieebene explizit deaktivieren, wird das Restart Cap-Objekt mit als 0 angegebenen Neustart- und Wiederherstellungszeiten angezeigt. Der Neustart benachbarter Router wird unterstützt (es sei denn, der Helper-Modus ist deaktiviert), aber der Router selbst behält den RSVP-Weiterleitungsstatus nicht bei und kann seinen Kontrollstatus nicht wiederherstellen.

  • Wenn rsvp nach einem Neustart feststellt, dass kein Weiterleitungsstatus beibehalten wurde, wird das Restart Cap-Objekt mit Restart- und Wiederherstellungszeiten, die als 0 angegeben sind, angezeigt.

  • Wenn der Unterbrechungsfreier Neustart und der Helper-Modus deaktiviert sind, ist der RSVP-Unterbrechungsneustart vollständig deaktiviert. Der Router erkennt die RSVP-Objekte für den Unterbrechungsneustart weder, noch gibt er sie an.

Sie können Werte nicht explizit für neustart- und wiederherstellungszeiten konfigurieren.

Im Gegensatz zu anderen Protokollen gibt es für RSVP keine Möglichkeit, festzustellen, dass es eine Neustartprozedur außer einem festen Timeout abgeschlossen hat. Alle RSVP-Verfahren zum unterbrechungsfreien Neustart sind timerbasiert. Ein show rsvp version Befehl kann darauf hinweisen, dass der Neustart noch im Gange ist, selbst wenn alle RSVP-Sitzungen gesichert sind und die Routen wiederhergestellt werden.

Verarbeitung des Restart Cap-Objekts

Die folgenden Annahmen werden über einen Nachbarn basierend auf dem Restart Cap-Objekt getroffen (vorausgesetzt, dass ein Steuerkanalfehler eindeutig von einem Knotenneustart unterschieden werden kann):

  • Ein Nachbar, der das Restart Cap-Objekt in seinen Hello-Nachrichten nicht ankündigt, kann einen Router nicht bei der Zustands- oder Labelwiederherstellung unterstützen oder einen RSVP-Unterbrechungsneustart durchführen.

  • Nach einem Neustart meldet ein Nachbar ein Restart Cap-Objekt mit einer Neustartzeit, die jedem Wert entspricht, und eine Wiederherstellungszeit von 0 hat den Weiterleitungsstatus nicht beibehalten. Wenn eine Wiederherstellungszeit 0 entspricht, gilt der Nachbar als tot, und alle mit diesem Nachbarn verbundenen Zustände werden bereinigt, unabhängig vom Wert der Neustartzeit.

  • Nach einem Neustart kann ein Nachbar, der seine Wiederherstellungszeit mit einem anderen Wert als 0 ankn nen, den Weiterleitungsstatus beibehalten oder beibehalten. Wenn der lokale Router seinen Nachbarn bei Neustart- oder Wiederherstellungsvorgängen unterstützt, sendet er ein Recover Label-Objekt an diesen Nachbarn.

Konfiguration von RSVP Graceful Restart

Die folgenden RSVP-Graceful-Restart-Konfigurationen sind möglich:

  • Graceful-Neustart und Helper-Modus sind beide aktiviert (Standard).

  • Der Graceful-Neustart ist aktiviert, aber der Helper-Modus ist deaktiviert. Ein auf diese Weise konfigurierter Router kann zwar problemlos neu gestartet werden, kann aber einem Nachbarn mit seinen Neustart- und Wiederherstellungsvorgängen nicht helfen.

  • Der Graceful-Neustart ist deaktiviert, aber der Helper-Modus ist aktiviert. Ein auf diese Weise konfigurierter Router kann nicht unterbrechungsgerecht neu gestartet werden, kann aber einen neustartenden Nachbarn unterstützen.

  • Der Unterbrechungsfreier Neustart und der Helper-Modus sind beide deaktiviert. Diese Konfiguration deaktiviert den RSVP-Unterbrechungsneustart vollständig (einschließlich Neustart- und Wiederherstellungsverfahren und Helper-Modus). Der Router verhält sich wie ein Router, der den RSVP-Neustart nicht unterstützt.

Anmerkung:

Um den RSVP-Unterbrechungsneustart zu aktivieren, müssen Sie den globalen Graceful Restart-Timer auf mindestens 180 Sekunden festlegen.

In den folgenden Abschnitten wird die Konfiguration des RSVP-Neustarts beschrieben:

Aktivierung des Graceful Restart für alle Routing-Protokolle

Um einen Unterbrechungsneustart für RSVP zu ermöglichen, müssen Sie den Unterbrechungsfreier Neustart für alle Protokolle aktivieren, die einen Unterbrechungsneustart auf dem Router unterstützen. Weitere Informationen zum unterbrechungsfreien Neustart finden Sie in der Junos OS Routing Protocols Library for Routing Devices.

Um einen Unterbrechungsneustart auf dem Router zu ermöglichen, fügen Sie die graceful-restart Anweisung ein:

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

  • [edit routing-options]

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

Deaktivierung des Graceful-Neustarts für RSVP

Standardmäßig sind der RSVP-Unterbrechungsneustart und der RSVP-Helper-Modus aktiviert, wenn Sie einen Unterbrechungsneustart aktivieren. Sie können jedoch eine oder beide dieser Funktionen deaktivieren.

Um den unterbrechungsfreien RSVP-Neustart und die Wiederherstellung zu deaktivieren, fügen Sie die disable Anweisung auf Hierarchieebene [edit protocols rsvp graceful-restart] ein:

Deaktivieren des RSVP-Helper-Modus

Um den RSVP-Helper-Modus zu deaktivieren, fügen Sie die helper-disable Anweisung auf der [edit protocols rsvp graceful-restart] Hierarchieebene ein:

Konfigurieren der maximalen Helper-Wiederherstellungszeit

Um zu konfigurieren, wie viel Zeit der Router den Status seiner RSVP-Nachbarn behält, während er einen Unterbrechungsneustart durchläuft, fügen Sie die maximum-helper-recovery-time Anweisung auf Hierarchieebene [edit protocols rsvp graceful-restart] ein. Dieser Wert wird auf alle benachbarten Router angewendet, daher sollte er auf der Zeit basieren, die der langsamste RSVP-Nachbar für die Wiederherstellung benötigt.

Konfigurieren der maximalen Helper-Restart-Zeit

Um die Verzögerung zwischen dem Erkennen des Ausfalls eines benachbarten Routers und dem Deklarieren des Nachbarn nach unten zu konfigurieren, fügen Sie die maximum-helper-restart-time Anweisung auf Hierarchieebene [edit protocols rsvp graceful-restart] ein. Dieser Wert wird auf alle benachbarten Router angewendet, daher sollte er auf der Zeit basieren, die vom langsamsten RSVP-Nachbarn zum Neustart benötigt wird.

RSVP LSP-Tunnel – Übersicht

Ein LSP-Tunnel (Resource Reservation Protocol) ermöglicht es Ihnen, RSVP-LSPs innerhalb anderer RSVP-LSPs zu senden. Dadurch kann ein Netzwerkadministrator Traffic Engineering von einem Ende des Netzwerks zum anderen bereitstellen. Eine nützliche Anwendung für diese Funktion ist die Verbindung von Customer Edge (CE)-Routern mit Provider Edge (PE)-Routern über einen RSVP-LSP und anschließendes Tunneln dieses Edge-LSP innerhalb eines zweiten RSVP-LSP, der über den Netzwerkkern übertragen wird.

Sie sollten ein allgemeines Verständnis von MPLS- und Label-Switching-Konzepten haben. Weitere Informationen zu MPLS finden Sie im Konfigurationshandbuch für Junos MPLS-Anwendungen.

Ein RSVP-LSP-Tunnel fügt das Konzept einer Weiterleitungsadjacency hinzu, ähnlich dem für generalisiertes Multiprotocol Label Switching (GMPLS). (Weitere Informationen zu GMPLS finden Sie im Junos GMPLS-Benutzerhandbuch.

Die Weiterleitungsadjacency erstellt einen Tunnelpfad zum Senden von Daten zwischen Peer-Geräten in einem RSVP-LSP-Netzwerk. Sobald ein Forwarding Adjacency LSP (FA-LSP) eingerichtet wurde, können andere LSPs mit Constrained Shortest Path First (CSPF), Link Management Protocol (LMP), Open Shortest Path First (OSPF) und RSVP über das FA-LSP gesendet werden.

Um einen RSVP-LSP-Tunnel zu aktivieren, verwendet das Junos OS die folgenden Mechanismen:

  • LMP: Ursprünglich für GMPLS konzipiert, stellt LMP Weiterleitungs-Nachbarschaften zwischen RSVP-LSP-Tunnel-Peers her und verwaltet und weist Ressourcen für Traffic-Engineering-Verbindungen zu.

  • OSPF-Erweiterungen: OSPF wurde entwickelt, um Pakete an physische und logische Schnittstellen zu routen, die mit einer Physical Interface Card (PIC) zusammenhängen. Dieses Protokoll wurde erweitert, um Pakete an in einer LMP-Konfiguration definierte virtuelle Peer-Schnittstellen zu routen.

  • RSVP-TE-Erweiterungen– RSVP-TE wurde entwickelt, um die Einrichtung von Paket-LSPs an physische Schnittstellen zu signalisieren. Das Protokoll wurde erweitert, um die Pfadeinrichtung für Paket-LSPs anzufordern, die zu in einer LMP-Konfiguration definierten virtuellen Peer-Schnittstellen übertragen werden.

    Anmerkung:

    Ab Junos OS Version 15.1 wird die Unterstützung für mehrere Instanzen auf MPLS RSVP-TE ausgeweitet. Diese Unterstützung ist nur für den Typ einer virtuellen Routerinstanz verfügbar. Ein Router kann mehrere unabhängige TE-Topologiepartitionen erstellen und daran teilnehmen, wodurch jede partitionierte TE-Domäne unabhängig skaliert werden kann. RSVP-TE mit mehreren Instanzen bietet die Flexibilität, die Entitäten der Steuerungsebene auszuwählen, die auf Instanzen vorbereitet sein müssen. Beispielsweise kann ein Router an mehreren TE-Instanzen teilnehmen, während gleichzeitig eine einzelne BGP-Instanz ausgeführt wird.

    Die Junos OS-Implementierung von MPLS RSVP-TE wurde skaliert, um die Benutzerfreundlichkeit, Transparenz, Konfiguration und Fehlerbehebung von LSPs in Junos OS Version 16.1 zu verbessern.

    Diese Verbesserungen erleichtern die skalierbare RSVP-TE-Konfiguration durch:

    • Sicherstellen der LSP-Datenebenenbereitschaft während der LSP-Resignalisierung, bevor der Datenverkehr mit dem RSVP-TE LSP-Selbst-Ping-Mechanismus den LSP durchläuft.

      Ein LSP sollte den Datenverkehr nur dann übertragen, wenn bekannt ist, dass er in der Datenebene programmiert wurde. Der Datenaustausch auf der LSP-Datenebene, z. B. LSP-Ping-Anfragen, erfolgt am Eingangsrouter, bevor der Datenverkehr zu einem LSP oder zu seiner MBB-Instanz umgestellt wird. In großen Netzwerken kann dieser Datenverkehr einen LSP-Ausgangsrouter überfordern, da der Ausgangs-LSP auf die LSP-Ping-Anfragen reagieren muss. Der LSP-Self-Ping-Mechanismus ermöglicht es dem Ingress-LER, LSP-Ping-Antwortmeldungen zu erstellen und sie über die LSP-Datenebene zu senden. Beim Empfang dieser Nachrichten leitet der Ausgangs-LER sie an den Eingang weiter, was die Lebendigkeit der LSP-Datenebene angibt. Dadurch wird sichergestellt, dass der LSP nicht beginnt, Den Datenverkehr zu übertragen, bevor die Datenebene programmiert wurde.

    • Entfernen der aktuellen harten Begrenzung von 64.000 LSPs auf einem Ingress-Router und Skalierung der Gesamtanzahl von LSPs mit von RSVP-TE signalisierten LSPs. Pro Ausgang können bis zu 64.000 LSPs konfiguriert werden. Früher war diese Begrenzung die aggregierte Anzahl von LSPs, die auf dem Eingangs-LER konfiguriert werden konnten.

    • Verhindern eines abrupten Abreißens von LSPs durch den Eingangsrouter aufgrund einer Verzögerung bei der Signalübertragung des LSP an den Transitroutern.

    • Ermöglicht eine flexible Ansicht von LSP-Datensätzen, um die Visualisierung der LSP-charakteristischen Daten zu erleichtern.

    Anmerkung:

    Ab Junos OS Version 17.4 wird ein Standardzeitpunkt von 1800 Sekunden für Self-Ping eingeführt.

Für LSP-Hierarchien gibt es folgende Einschränkungen:

  • Circuit Cross-Connect (CCC)-basierte LSPs werden nicht unterstützt.

  • Graceful-Neustart wird nicht unterstützt.

  • Link Protection ist weder für FA-LSPs noch am Ausgangspunkt der Weiterleitungsadjacency verfügbar.

  • Point-to-Multipoint-LSPs werden nicht über FA-LSPs hinweg unterstützt.

Beispiel: RSVP LSP-Tunnelkonfiguration

Abbildung 5: RSVP LSP-TunneltopologiediagrammRSVP LSP-Tunneltopologiediagramm

Abbildung 5 zeigt einen End-to-End-RSVP-LSP namens e2e_lsp_r0r5 , der von Router 0 stammt und auf Router 5 endet. Im Transit durchläuft dieser LSP die FA-LSP fa_lsp_r1r4. Der Rückweg wird durch den durchgängigen RSVP-LSP e2e_lsp_r5r0 dargestellt, der über FA-LSP fa_lsp_r4r1zurückgelegt wird.

Konfigurieren Sie auf Router 0 den end-to-End-RSVP-LSP, der zu Router 5 übertragen wird. Verwenden Sie einen strengen Pfad, der Router 1 und den LMP Traffic Engineering-Link von Router 1 zu Router 4 durchläuft.

Router 0

Konfigurieren Sie auf Router 1 einen FA-LSP, um Router 4 zu erreichen. Richten Sie eine LMP Traffic Engineering-Verbindung und eine LMP-Peer-Beziehung mit Router 4 ein. Referenzieren Sie die FA-LSP im Traffic Engineering-Link, und fügen Sie die Peer-Schnittstelle sowohl zu OSPF als auch zu RSVP hinzu.

Wenn der End-to-End-LSP des Rücklaufpfads bei Router 1 eintrifft, führt die Routing-Plattform eine Routing-Suche durch und kann den Datenverkehr an Router 0 weiterleiten. Stellen Sie sicher, dass Sie OSPF zwischen den Routern 0 und 1 richtig konfigurieren.

Router 1

Konfigurieren Sie auf Router 2 OSPF, MPLS und RSVP auf allen Schnittstellen, die FA-LSPs über das Core-Netzwerk übertragen.

Router 2

Konfigurieren Sie auf Router 3 OSPF, MPLS und RSVP auf allen Schnittstellen, die FA-LSPs über das Core-Netzwerk übertragen.

Router 3

Konfigurieren Sie auf Router 4 einen Rückgabepfad FA-LSP, um Router 1 zu erreichen. Richten Sie eine LMP Traffic Engineering-Verbindung und eine LMP-Peer-Beziehung zu Router 1 ein. Referenzieren Sie die FA-LSP im Traffic Engineering-Link, und fügen Sie die Peer-Schnittstelle sowohl zu OSPF als auch zu RSVP hinzu.

Wenn der erste End-to-End-LSP bei Router 4 eintrifft, führt die Routing-Plattform eine Routing-Suche durch und kann den Datenverkehr an Router 5 weiterleiten. Stellen Sie sicher, dass Sie OSPF zwischen Router 4 und Router 5 richtig konfigurieren.

Router 4

Konfigurieren Sie auf Router 5 den End-to-End-Return-Pfad RSVP LSP, der zu Router 0 übertragen wird. Verwenden Sie einen strengen Pfad, der Router 4 und den LMP Traffic Engineering-Link von Router 4 zu Router 1 durchläuft.

Router 5

Verifizierung Ihrer Arbeit

Um zu überprüfen, ob Der RSVP-LSP-Tunnel ordnungsgemäß funktioniert, geben Sie die folgenden Befehle aus:

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

  • show link-management te-link name (detail)

Weitere Informationen zu den im Konfigurationsbeispiel verwendeten Befehlen finden Sie in den folgenden Abschnitten:

Router 0

Auf Router 0 können Sie überprüfen, ob die FA-LSPs in der Traffic Engineering-Datenbank als gültige Pfade angezeigt werden. Suchen Sie in diesem Fall nach den Pfaden von Router 1 (10.255.41.216) und Router 4 (10.255.41.217), die auf die LMP Traffic Engineering-Linkadressen von 172.16.30.1 und 172.16.30.2verweisen. Sie können den show rsvp session extensive Befehl auch ausführen, um nach dem Pfad des End-to-End-LSP zu suchen, während er über FA-LSP zu Router 5 übertragen wird.

Router 1

Überprüfen Sie auf Router 1, ob Ihre LMP Traffic Engineering Link-Konfiguration funktioniert und dass der End-to-End-LSP den Traffic Engineering-Link durchläuft, indem Sie den show link-management Befehlssatz ausgeben. Sie können den show rsvp session extensive Befehl auch ausstellen, um zu bestätigen, dass fa-LSP betriebsbereit ist.

Konfigurieren von Peer-Schnittstellen in OSPF und RSVP

Nachdem Sie LMP-Peers erstellt haben, müssen Sie PEER-Schnittstellen zu OSPF und RSVP hinzufügen. Eine Peer-Schnittstelle ist eine virtuelle Schnittstelle zur Unterstützung der Steueradjacency zwischen zwei Peers.

Der Name der Peer-Schnittstelle muss mit der peer peer-name in LMP konfigurierten Anweisung auf Der [edit protocols link-management] Hierarchieebene übereinstimmen. Da tatsächliche Protokollpakete von Peer-Schnittstellen gesendet und empfangen werden, können die Peer-Schnittstellen wie jede andere für OSPF und RSVP konfigurierte physische Schnittstelle signalisiert und an Peers weitergeleitet werden. Um OSPF-Routing für LMP-Peers zu konfigurieren, fügen Sie die peer-interface Anweisung auf Hierarchieebene [edit protocols ospf area area-number] ein. Um die RSVP-Signalübertragung für LMP-Peers zu konfigurieren, fügen Sie die peer-interface Anweisung aufhierarchische [edit protocols rsvp] Ebene ein.

Definition labelvermittelter Pfade für FA-LSP

Definieren Sie als nächstes Ihren FA-LSP, indem Sie die label-switched-path Anweisung auf der [edit protocols mpls] Hierarchieebene einbeziehen. Fügen Sie die Router-ID des Peers in die to Anweisung auf Hierarchieebene [edit protocols mpls label-switched-path] ein. Da Paket-LSPs unidirektional sind, müssen Sie einen FA-LSP erstellen, um den Peer zu erreichen, und ein zweites FA-LSP, um vom Peer zurückzukehren.

Einrichten von FA-LSP-Pfadinformationen

Wenn Sie explizite LSP-Pfade für ein FA-LSP konfigurieren, müssen Sie die Remoteadresse des Traffic Engineering-Links als Next-Hop-Adresse verwenden. Wenn CSPF unterstützt wird, können Sie jede gewünschte Pfadoption verwenden. Wenn CSPF jedoch mit der no-cspf Anweisung auf Hierarchieebene [edit protocols mpls label-switched-path lsp-name] deaktiviert ist, müssen Sie strenge Pfade verwenden.

Anmerkung:

Wenn der End-to-End-LSP von derselben Routing-Plattform wie FA-LSP stammt, müssen Sie CSPF deaktivieren und strenge Pfade verwenden.

Option: RSVP-LSPs gracefully herunterreißen

Sie können einen RSVP-LSP in einem zweistufigen Prozess beenden, der die vom LSP verwendete RSVP-Sitzung auf gracefully zurückzieht. Für alle Nachbarn, die ein unterbrechungsfreies Teardown unterstützen, wird eine Anforderung für den Teardown von der Routing-Plattform an das Zielendpunkt für den LSP und alle RSVP-Nachbarn im Pfad gesendet. Die Anfrage ist im ADMIN_STATUS Feld des RSVP-Pakets enthalten. Wenn Nachbarn die Anfrage erhalten, bereiten sie sich darauf vor, dass die RSVP-Sitzung zurückgezogen wird. Eine zweite Nachricht wird von der Routing-Plattform gesendet, um den Abbruch der RSVP-Sitzung abzuschließen. Wenn ein Nachbar kein unterbrechungsfreier Teardown unterstützt, wird die Anfrage als Standard-Session-Teardown und nicht als graceful behandelt.

Geben Sie den clear rsvp session gracefully Befehl aus, um einen graceful Teardown einer RSVP-Sitzung durchzuführen. Optional können Sie die Quell- und Zieladresse der RSVP-Sitzung, den LSP-Identifier des RSVP-Senders und den Tunnel-Identifier der RSVP-Sitzung angeben. Um diese Qualifikationen zu verwenden, schließen Sie die connection-sourceOptionen , connection-destination, lsp-idund tunnel-id ein, wenn Sie den clear rsvp session gracefully Befehl ausstellen.

Sie können auch die Zeit konfigurieren, die die Routing-Plattform darauf wartet, dass Nachbarn die Graceful-Teardown-Anforderung erhalten, bevor sie den tatsächlichen Teardown einleitet, indem Sie die graceful-deletion-timeout Anweisung auf Hierarchieebene [edit protocols rsvp] einbeziehen. Der Standardmäßige Graceful Deletion Timeout-Wert beträgt 30 Sekunden mit einem Minimalwert von 1 Sekunde und einem Maximalwert von 300 Sekunden. Um den aktuellen Wert anzuzeigen, der für das Graceful Deletion Timeout konfiguriert ist, geben Sie den Befehl für den show rsvp version Betriebsmodus aus.

Release-Verlaufstabelle
Release
Beschreibung
19.4R1
16.1
Doch ab Junos OS Version 16.1 werden die RSVP-Sitzungen heruntergefahren, wenn DIE RSVP-Nachrichten aus der Auszeit gesendet werden.