Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

RSVP-Konfiguration

Minimale RSVP-Konfiguration

Um RSVP auf einer einzigen Schnittstelle zu aktivieren, fügen Sie die rsvp Anweisung ein und geben Sie die Schnittstelle mithilfe 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 einschließen:

  • [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 einschließen:

  • [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 sowohl MPLS als auch RSVP auf einem Router aktivieren, wird MPLS zu einem Client von RSVP. Es ist keine zusätzliche Konfiguration erforderlich, um MPLS und RSVP zu binden.

Sie können MPLS so konfigurieren, dass Signalpfade eingerichtet werden, indem Sie die label-switched-path Anweisung auf Hierarchieebene [edit protocols mpls] verwenden. Jeder LSP übersetzt in eine Anfrage für RSVP, eine RSVP-Sitzung zu initiieren. Diese Anforderung wird über die interne Schnittstelle zwischen Label-Switching und RSVP weitergeleitet. Nach Prüfung der Anforderungsinformationen, Überprüfung des RSVP-Status und Überprüfung der lokalen Routing-Tabellen 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 Pfade eingerichtet, die von der RSVP-Sitzung erstellt werden. Wenn die RSVP-Sitzung nicht erfolgreich ist, benachrichtigt RSVP MPLS über seinen Status. Es ist an MPLS, Backup-Pfade zu initiieren oder den ursprünglichen Pfad erneut zu versuchen.

Um Label-Switching-Signalisierungsinformationen zu übergeben, unterstützt RSVP vier zusätzliche Objekte: Label Request-Objekt, Label-Objekt, Explicit Route-Objekt und Protokollroute-Objekt. Damit ein LSP erfolgreich eingerichtet werden kann, müssen alle Router entlang des Pfads MPLS, RSVP und die vier Objekte unterstützen. Von den vier Objekten ist das Protokollroutenobjekt nicht obligatorisch.

Gehen Sie folgendermaßen vor, um MPLS zu konfigurieren und es zu einem Client von RSVP zu machen:

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

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

  • Konfigurieren Sie die Router am Anfang des LSP.

Sie können RSVP Label-Switched Paths (LSPs) konfigurieren, um eine Verzögerungskennzahl für die Berechnung des Pfads zu verwenden. Verwenden Sie zur Konfiguration die CLI-Optionen, die wir in der [edit protocols mpls label-switched-path name] Hierarchie eingeführt haben.

Beispiel: Konfigurieren von RSVP und MPLS

Im Folgenden wird eine Beispielkonfiguration für einen Router am Anfang eines LSP dargestellt:

Im Folgenden wird eine Beispielkonfiguration für alle anderen Router dargestellt, 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 Reduzierung der RSVP-Aktualisierung auf jeder Schnittstelle konfigurieren, indem Sie die folgenden Anweisungen in die Schnittstellenkonfiguration integrieren:

  • aggregate und reliable— Aktivieren Sie alle Funktionen zur Reduzierung der RSVP-Aktualisierung: RSVP-Nachrichtenbündelung, RSVP-Nachrichten-ID, zuverlässige Nachrichtenzustellung und Zusammenfassungsaktualisierung.

    Um die Aktualisierung zu reduzieren und eine zuverlässige Bereitstellung zu erhalten, müssen Sie die und reliable Die aggregate Erklärungen beigaben.

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

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

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

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

Allerdings funktionieren nicht alle Kombinationen zwischen zwei Nachbarn mit unterschiedlichen Funktionen zur Reduzierung der Aktualisierung korrekt. Beispielsweise wird ein Router entweder mit der Anweisung und no-reliable Anweisung aggregate oder mit den reliable Und no-aggregate Anweisungen konfiguriert. Wenn ein RSVP-Nachbarn ein Summary Refresh-Objekt an diesen Router sendet, wird kein Fehler generiert, aber das Summary Refresh-Objekt kann nicht verarbeitet werden. Folglich kann der RSVP-Status auf diesem Router eine Zeit außerhalb der Zeit ausfallen, wenn der Nachbar sich nur auf Summary Refresh verlässt, um diese RSVP-Status zu aktualisieren.

Wir empfehlen, es sei denn, es gibt spezifische Anforderungen, dass Sie die Reduzierung der RSVP-Aktualisierung auf ähnliche Weise für jeden RSVP-Nachbarn konfigurieren.

Um alle Funktionen zur Reduzierung der RSVP-Aktualisierung auf einer Schnittstelle zu aktivieren, fügen Sie die Anweisung ein aggregate :

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

  • [edit protocols rsvp interface interface-name]

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

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

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

  • [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 Nachrichtenzustellung auf einer Schnittstelle zu ermöglichen, fügen Sie die Anweisung ein reliable :

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

  • [edit protocols rsvp interface interface-name]

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

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

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

  • [edit protocols rsvp interface interface-name]

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

Ermitteln der Aktualisierungsreduzierungsfunktion von RSVP Neighbors

Um die Funktion zur Reduzierung der RSVP-Aktualisierung eines RSVP-Nachbarn zu bestimmen, benötigen Sie die folgenden Informationen:

  • Das vom Nachbarn beworbene RR-Bit

  • Die lokale Konfiguration der RSVP-Aktualisierungsreduzierung

  • Die tatsächlich vom Nachbarn empfangenen RSVP-Nachrichten

Um diese Informationen zu erhalten, können Sie einen show rsvp neighbor detail Befehl ausstellen. Es folgt ein Beispiel für die Ausgabe:

Weitere Informationen zum show rsvp neighbor detail Befehl.

Konfigurieren des RSVP Hallo Intervalls

RSVP überwacht den Status der Interior Gateway Protocol (IGP) (IS-IS oder OSPF)-Nachbarn und verlässt sich auf die IGP-Protokolle, um zu erkennen, wenn ein Knoten ausfällt. Wenn ein IGP-Protokoll einen Nachbarn deklariert (weil hallo Pakete nicht mehr empfangen werden), bringt RSVP auch diesen Nachbarn herunter. Die IGP-Protokolle und RSVP agieren jedoch immer noch unabhängig, wenn ein Nachbar eingerichtet wird.

Bei Routern von Juniper Networks hat die Konfiguration eines kürzeren oder längeren RSVP-Hallo-Intervalls keine Auswirkungen darauf, ob eine RSVP-Sitzung heruntergefahren wird oder nicht. RSVP-Sitzungen werden auch dann durchgeführt, wenn keine RSVP-Hallo-Pakete mehr empfangen werden. RSVP-Sitzungen werden gepflegt, bis entweder der Router keine IGP Hallo-Pakete mehr empfängt oder die RSVP-Pfad- und Resv-Nachrichten time out. Ab Junos OS Version 16.1 werden jedoch die RSVP-Sitzungen heruntergefahren, wenn RSVP hallo eine Time-Out-Nachricht gibt.

Das RSVP-Hallo-Intervall kann sich auch auswirken, wenn die Geräte eines anderen Anbieters eine RSVP-Sitzung ausfallen lassen. Zum Beispiel kann ein benachbarter Router, der nicht zu Juniper Networks ist, so konfiguriert werden, dass er RSVP-Hallo-Pakete überwacht.

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

HINWEIS:

Ab Version 16.1 sendet Junos RSVP Hallo-Nachrichten über einen Bypass-LSP, wenn eine verfügbar ist. Hier finden Sie no-node-hello-on-bypass Informationen dazu, wie Sie auf das historische Verhalten des Sendens von Hallos über den IGP-nächsten Hop zurücksetzen können.

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

Konfigurieren der RSVP-Authentifizierung

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

RSVP-Authentifizierung verwendet einen auf Hashed Message Authentication Code (HMAC)-MD5 nachrichtenbasierten Digest. Dieses Schema erstellt einen Nachrichten-Digest auf der Grundlage eines geheimen Authentifizierungsschlüssels und des Nachrichteninhalts. (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 über diese Schnittstelle authentifiziert.

DIE MD5-Authentifizierung bietet Schutz vor Fälschungen und Nachrichtenänderungen. Es kann auch Replay-Angriffe verhindern. Es bietet jedoch keine Vertraulichkeit, da alle Nachrichten als 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 angeben:

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

  • [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 erlaubt RSVP, dass 100 Prozent der Bandbreite für einen Klassentyp für RSVP-Reservierungen verwendet werden. Wenn Sie einen Klassentyp für einen multiklassigen LSP überschreiben, darf die Gesamtnachfrage aller RSVP-Sitzungen die tatsächliche Kapazität des Klassentyps überschreiten.

Ausführliche Anweisungen zur Konfiguration des Bandbreitenabonnements für Klassentypen finden Sie unter Konfigurieren des Bandbreitenabonnementanteils für LSPs.

Konfigurieren des Schwellenwerts für rsVP-Aktualisierung auf einer Schnittstelle

Die Interior Gateway Protokolle (IGPs) pflegen die Traffic-Engineering-Datenbank, aber die derzeit verfügbare Bandbreite auf den Traffic-Engineering-Datenbank-Links stammt von RSVP. Wenn sich die Bandbreite eines Links ä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 Traffic-Engineering-Datenbankverbindung verfügbar ist (lokal oder remote), und CSPF kann die Pfade korrekt berechnen.

IGP-Updates können jedoch zu viel Systemressourcen verbrauchen. Abhängig von der Anzahl der Knoten in einem Netzwerk ist es möglicherweise nicht wünschenswert, ein IGP-Update für kleine Bandbreitenänderungen durchzuführen. Indem Sie die update-threshold Anweisung auf Hierarchieebene [edit protocols rsvp] konfigurieren, können Sie den Schwellenwert anpassen, bei dem eine Änderung der reservierten Bandbreite ein IGP-Update auslöst.

Sie können einen Wert von 0,001 Prozent bis 20 Prozent (standardmässig 10 Prozent) für den Zeitpunkt des Auslösens eines IGP-Updates konfigurieren. Wenn die Änderung der reservierten Bandbreite größer oder gleich dem konfigurierten Schwellenwert der statischen Bandbreite auf dieser Schnittstelle ist, erfolgt ein IGP-Update. Wenn Sie beispielsweise die update-threshold Anweisung mit 15 Prozent konfiguriert haben und der Router feststellt, dass sich die reservierte Bandbreite eines Links um 10 Prozent der Verbindungsbandbreite geändert hat, löst RSVP kein IGP-Update aus. Wenn sich jedoch die reservierte Bandbreite eines Links um 20 Prozent der Verbindungsbandbreite ändert, löst RSVP ein IGP-Update aus.

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

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

Wenn die Bandbreite an einer Schnittstelle beispielsweise 1 Gbit/s beträgt und größer threshold-value als 200 Mbit/s konfiguriert ist, ist die threshold-value Bandbreite auf 200 Mbit/s begrenzt. Die threshold-percent wird mit 20.000 % und die threshold-value als 200 Mbit/s angezeigt.

HINWEIS:

Die beiden Optionen threshold-percent und threshold-value, 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.

Bei einer Verbindung von 1 Gbit/s wird beispielsweise bei einer Konfiguration von threshold-percent 5 % die threshold-value Verbindung mit 5 % berechnet und als 50 Mbit/s angezeigt. Wenn die threshold-value 50 m beträgt, wird dies threshold-percent berechnet und als 5 % angezeigt.

Um den Schwellenwert anzupassen, bei dem eine Änderung der reservierten Bandbreite ein IGP-Update auslöst, fügen Sie die Update-Schwellwert-Anweisung ein. Aufgrund des Update-Schwellenwerts ist es möglich, dass Eingeschränkte kürzester Pfad zuerst (CSPF) einen Pfad mithilfe veralteter Datenverkehrs-Engineering-Datenbankbandbreiteninformationen auf einem Link berechnet. Wenn RSVP versucht, einen LSP über diesen Pfad einzurichten, stellt er möglicherweise fest, dass auf diesem Link keine ausreichende Bandbreite vorhanden ist. In diesem Fall löst RSVP eine Aktualisierung der IGP Traffic Engineering-Datenbank aus, wodurch die aktualisierten Bandbreiteninformationen im Netzwerk überflutet werden. CSPF kann dann den Pfad mithilfe der aktualisierten Bandbreiteninformationen neu kompensieren und versuchen, einen anderen Pfad zu finden, um die überlastete Verbindung zu vermeiden. Beachten Sie, dass diese Funktionalität standardmässig ist und keine zusätzliche Konfiguration benötigt.

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

Konfigurieren von RSVP für nicht nummerierte Schnittstellen

Das Junos OS unterstützt RSVP Traffic Engineering über nicht nummerierte Schnittstellen. Traffic-Engineering-Informationen zu nicht nummerierten Links werden in den IGP Traffic Engineering-Erweiterungen für OSPF und IS-IS übertragen, wie in RFC 4203, OSPF-Erweiterungen zur Unterstützung von generalisiertem 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) beschrieben. Nicht nummerierte Verbindungen können auch im MPLS Traffic Engineering Signaling 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-signalierten Netzwerk teilnimmt.

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

Um den Verbindungsschutz und die schnelle Umleitung auf einem Router mit nicht nummerierten Schnittstellen zu konfigurieren, müssen Sie mindestens zwei Adressen konfigurieren. Wir empfehlen, zusätzlich zur Konfiguration der Router-ID eine sekundäre Schnittstelle auf dem Loopback zu konfigurieren.

Konfigurieren von RSVP Node-ID Hallo

Sie können node-ID-basierte RSVP hallos konfigurieren, um sicherzustellen, dass Die Router von Juniper Networks mit den Geräten anderer Anbieter zusammenarbeiten können. Standardmäßig verwendet Junos OS schnittstellenbasierte RSVP Hallos. Node-ID-basierte RSVP Hallos sind in RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) angegeben Hallo: Eine Klarstellungserklärung. RsVP Node-ID hallos sind nützlich, wenn Sie BFD so konfiguriert haben, dass Probleme über RSVP-Schnittstellen erkannt werden, sodass Sie Schnittstellen-Hallos für diese Schnittstellen deaktivieren können. Sie können auch Node-ID hallos für graceful Restart-Prozeduren verwenden.

Node-ID Hallos können global für alle RSVP-Nachbarn aktiviert werden. Standardmäßig ist node-ID hallo Support deaktiviert. Wenn Sie die RSVP-Knoten-IDs auf dem Router nicht aktiviert haben, akzeptiert das Junos OS keine Node-ID Hallo-Pakete.

HINWEIS:

Ab Version 16.1 sendet Junos RSVP Hallo-Nachrichten über einen Bypass-LSP, wenn eine verfügbar ist. Hier finden Sie no-node-hello-on-bypass Informationen dazu, wie Sie auf das historische Verhalten des Sendens von Hallos über den IGP-nächsten Hop zurücksetzen können.

Um rsVP node-ID 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 die RSVP-Schnittstelle auch explizit weltweit deaktivieren. Diese Art der 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 die RSVP-Schnittstelle jedoch global deaktivieren, können Sie auch ein Hallo-Intervall auf einer RSVP-Schnittstelle mit der Hello-interval-Anweisung konfigurieren. Diese Konfiguration deaktiviert die RSVP-Schnittstelle weltweit, aktiviert aber die RSVP-Schnittstelle hallos 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 hallos und andere Geräte RSVP-Schnittstellen hallos unterstützen.

Um die RSVP-Schnittstelle 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: Konfiguration von RSVP-signalisierten LSPs

Dieses Beispiel zeigt, wie Sie einen LSP zwischen Routern in einem IP-Netzwerk mit RSVP als Signalisierungsprotokoll erstellen.

Anforderungen

Löschen Sie sicherheitsservices vom Gerät, bevor Sie beginnen. Siehe Beispiel: Löschen von Sicherheitsservices.

Übersicht und Topologie

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

Topologie

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

Um einen LSP zwischen Routern einzurichten, müssen Sie die MPLS-Familie einzeln aktivieren und RSVP auf jedem 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 Eingangsrouter (R1) unter Verwendung der Loopback-Adresse (10.0.9.7) von R7 definieren. Die Konfiguration reserviert 10 Mbit/s Bandbreite. Darüber hinaus deaktiviert die Konfiguration den CSPF-Algorithmus und stellt sicher, dass die Hosts C1 und C2 den RSVP-signalierten LSP verwenden, der dem kürzesten Pfad der Netzwerk-IGP entspricht.

Konfiguration

Verfahren

CLI-Schnellkonfiguration

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

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie 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 auf der Transitschnittstelle im MPLS-Netzwerk.

  4. Definieren 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 in der Ausgabe die beabsichtigte Konfiguration nicht angezeigt wird, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Aus Gründen der Kürze enthält diese show Befehlsausgabe nur die Konfiguration, die für dieses Beispiel relevant ist. Jede andere Konfiguration auf dem System wurde durch Ellipsen ersetzt (...).

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

Überprüfung

Führen Sie die folgenden Aufgaben aus, um zu bestätigen, dass die Konfiguration ordnungsgemäß funktioniert:

Überprüfung von RSVP-Nachbarn

Zweck

Stellen Sie sicher, dass für jedes Gerät die entsprechenden RSVP-Nachbarn angezeigt werden, z. B. dass Router R1 in Abbildung 1 sowohl 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. Stellen Sie sicher, dass jede benachbarte RSVP-Router-Loopback-Adresse aufgeführt ist.

Überprüfung von RSVP-Sitzungen

Zweck

Stellen Sie sicher, dass eine RSVP-Sitzung zwischen allen RSVP-Nachbarn eingerichtet wurde. Stellen Sie außerdem sicher, dass der Wert für die Bandbreitenreservierung 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-Nachbarnadresse hat einen Eintrag für jeden Nachbarn, der nach Loopback-Adresse aufgeführt ist.

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

  • Für Tspecwird der entsprechende Bandbreitenwert 10Mbpsangezeigt.

Verifizieren des Vorhandenseins von RSVP-signalisierten LSPs

Zweck

Stellen Sie sicher, dass die Routing-Tabelle des Eingangsrouters einen konfigurierten LSP für die Loopback-Adresse des anderen Routers hat. Stellen Sie beispielsweise sicher, dass die inet.3 Routing-Tabelle des R1-Entry-Routers Abbildung 1 einen konfigurierten LSP zur Loopback-Adresse des Routers R7 hat.

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 Routing-Tabelle vorhanden sind. Stellen Sie sicher, dass ein RSVP-signalisierter LSP mit der Loopback-Adresse des Ausgangs-Routers R7 im MPLS-Netzwerk verknüpft ist.

Beispiel: Konfiguration des automatischen RSVP-Mesh

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 ServiceAnbieters zu verteilen, während MPLS verwendet wird, um diesen VPN-Datenverkehr von einem VPN-Standort an einen anderen weiterzuleiten.

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 für BGP und MPLS mit dem neuen PE-Router peeren. Wenn jeder neue PE-Router dem Netzwerk des ServiceAnbieters hinzugefügt wird, wird der Konfigurationsaufwand bald zu hoch.

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

Anforderungen

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

  • Ein Router mit Junos OS Version 10.1 oder höher.

  • Ein BGP- und MPLS-VPN mit RSVP als MPLS Label-Switched Path (LSP) Signalübertragungsprotokoll.

Überblick

Dieses Beispiel zeigt, wie Sie das automatische RSVP-Mesh auf einem PE-Router mithilfe der rsvp-te Konfigurationsaussage konfigurieren. Damit das automatische RsVP-Mesh ordnungsgemäß funktioniert, muss für alle PE-Router in der Full-Mesh-Konfiguration die rsvp-te Anweisung konfiguriert sein. So 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 Anforderung zeigt dieses Beispiel nur die Konfiguration des neu hinzugefügten PE-Routers. Es wird angenommen, 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 ist in der Mitte der Abbildung dargestellt.

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

Konfiguration

Bei der Konfiguration der automatischen RsVP-Mesh-Konfiguration werden folgende Aufgaben ausgeführt:

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

  • 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. Es default-template handelt sich um eine vom System definierte Vorlage, die keine Benutzerkonfiguration erfordert.

CLI-Schnellkonfiguration

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

PE4-Router

Konfiguration des automatischen RSVP-Mesh

Schritt-für-Schritt-Verfahren

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

So aktivieren Sie automatisches RSVP-Mesh:

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

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

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üfung der Existenz von RSVP-automatischen Mesh-Tunneln auf Router PE4

Zweck

Um den Betrieb des neu konfigurierten PE4-Routers zu überprüfen, erteilen Sie den show dynamic-tunnels database Befehl im Betriebsmodus. Dieser Befehl zeigt das Zielnetzwerk an, in 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 show mpls lsp Befehl aus dem Betriebsmodus aus. Dieser Befehl zeigt den Status der MPLS-LSPs an.

Aktion

Konfigurieren von Hallo Anerkennungen für NICHT-Sitzungs-RSVP Neighbors

Die hello-acknowledgements Anweisung steuert das Hallo-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 gemeinsamen RSVP-Sitzung sind, werden verworfen. Wenn Sie die hello-acknowledgements Anweisung auf Hierarchieebene [edit protocols rsvp] konfigurieren, werden Hallo-Nachrichten von nicht sitzungsfreien Nachbarn mit einer Hallo-Bestätigungsnachricht bestätigt. Wenn Hallos von Nichtsitzungsnachbarn empfangen werden, wird eine RSVP-Nachbarschaftsbeziehung erstellt, und regelmäßige Hallo-Nachrichten können nun vom Nichtsitzungsnachbarn empfangen werden. Die hello-acknowledgements Anweisung ist standardmäßig deaktiviert. Die Konfiguration dieser Anweisung ermöglicht es RSVP-fähigen Routern, mithilfe von Hallo-Paketen zu erkennen und zu überprüfen, ob die Schnittstelle RSVP-Pakete empfangen kann, bevor sie Meldungen zur MPLS-LSP-Einrichtung sendet.

Sobald Sie Hallo-Bestätigungen für nicht sitzungsfreie RSVP-Nachbarn aktiviert haben, erkennt der Router weiterhin Hallo-Nachrichten von nicht sitzungsfreien RSVP-Nachbarn, es sei denn, die Schnittstelle selbst fällt aus oder Sie ändern die Konfiguration. Schnittstellenbasierte Nachbarn altern nicht automatisch aus.

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

  • [edit protocols rsvp]

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

Switching von LSPs weg von einem Netzwerkknoten

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

  1. Zuerst müssen Sie den Link- oder Node-Schutz für den Datenverkehr konfigurieren, der das netzwerkgerät, das Sie deaktivieren möchten, passieren muss. Um richtig zu funktionieren, muss der Bypass-LSP eine andere logische Schnittstelle als der geschützte LSP verwenden.
  2. Um den Router darauf vorzubereiten, den Datenverkehr von einem Netzwerkknoten weg zu schalten, konfigurieren Sie die always-mark-connection-protection-tlv Anweisung:

    Der Router markiert dann den gesamten OAM-Datenverkehr, der diese Schnittstelle durchfuhr, um den Datenverkehr basierend auf der OAM-Funktionalität in einen alternativen Pfad zu wechseln.

    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. Der eigentliche Link selbst wird durch diese Konfiguration nicht zum Erliegen gebracht.

    Um den Router so zu konfigurieren, dass er den Datenverkehr von einem Netzwerkknoten entfernt, 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 Umschalten aktiver LSPs von einem Netzwerkknoten weg:

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

  • Die Switch-Away-Funktion wird für das Umschalten des Datenverkehrs von primären Point-to-Multipoint-LSPs zu Bypass-Point-to-Multipoint-LSPs nicht 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 umgestellt.

  • Wenn Sie die Switch-Away-Funktion auf einer Schnittstelle entlang des Pfads eines dynamischen LSP konfigurieren, können über diesen Pfad keine neuen dynamischen LSPs eingerichtet werden. Die Switch-Away-Funktion verhindert das Make-before-Break-Verhalten von RSVP-signalisierten LSPs. Das Make-before-Break-Verhalten bewirkt normalerweise, dass der Router zuerst versucht, einen dynamischen LSP neu zu signalisieren, bevor er das Original zerreißt.

Konfigurieren des RSVP-Setup-Schutzes

Sie können den Fast-Reroute-Mechanismus für facility-Backup konfigurieren, um Einen Setup-Schutz für LSPs zu bieten, die gerade signalisiert werden. Sowohl Point-to-Point-LSPs als auch Point-to-Multipoint-LSPs werden unterstützt. Diese Funktion ist im folgenden Szenario anwendbar:

  1. Ein ausgefallener Link oder Knoten ist auf dem streng 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 erscheint so, als wäre er ursprünglich entlang seines primären Pfads eingerichtet worden und konnte dann aufgrund des Verbindungs- oder Knotenfehlers nicht zum Bypass-LSP übergehen.

  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 an den [edit protocols rsvp] einzelnen Routern entlang des LSP-Pfads konfigurieren, für den Sie den LSP-Einrichtungsschutz aktivieren möchten. Sie sollten auch das IGP-Traffic-Engineering für alle Router auf dem LSP-Pfad konfigurieren. Sie können einen show rsvp session Befehl ausstellen, um zu bestimmen, ob der LSP den Setup-Schutz für einen Router aktiviert hat, der als PlR (Point of Local Repair) oder als Zusammenführungspunkt fungiert.

Fügen Sie die Anweisung ein, um den setup-protection RSVP-Setupschutz zu aktivieren.

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

  • [edit protocols rsvp]

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

Konfigurieren von Load Balancing für RSVP-LSPs

Wenn Sie mehrere RSVP-LSPs für denselben Ausgangsrouter konfiguriert haben, wird standardmäßig der LSP mit der niedrigsten Metrik ausgewählt und transportiert den gesamten Datenverkehr. Wenn alle LSPs dieselbe Kennzahl haben, wird eine der LSPs zufällig ausgewählt und der gesamte Datenverkehr darüber weitergeleitet.

Alternativ können Sie den Lastausgleich des Datenverkehrs über alle LSPs hinweg nutzen, indem Sie Load Balancing pro Paket aktivieren.

Konfigurieren Sie die policy-statement Anweisung wie folgt, um paketbasiertes Load Balancing auf einem Eingangs-LSP zu aktivieren:

Sie müssen diese Anweisung dann als Exportrichtlinie auf die Weiterleitungstabelle anwenden.

Sobald das Load Balancing pro Paket angewendet wird, wird der Datenverkehr (standardmäßig) gleichmäßig zwischen den LSPs verteilt.

Sie müssen das Load Balancing pro Paket konfigurieren, wenn Sie PFE Fast Reroute aktivieren möchten. Um eine schnelle PFE-Reroute zu ermöglichen, fügen Sie die policy-statement Anweisung für paketbasiertes Load Balancing ein, die in diesem Abschnitt in der Konfiguration jedes Routers angezeigt wird, auf denen eine Reroute stattfinden könnte. Siehe auch Konfigurieren von Fast Reroute.

Sie können auch den Lastausgleich des Datenverkehrs zwischen den LSPs im Verhältnis zur Für jeden LSP konfigurierten Bandbreite bereitstellen. Diese Funktion kann den Datenverkehr besser in Netzwerken mit asymmetrischen Bandbreitenfunktionen auf externe Verbindungen verteilen, da die konfigurierte Bandbreite eines LSP typischerweise die Datenverkehrskapazität dieses LSP widerspiegelt.

Um RSVP LSP Load Balancing zu konfigurieren, fügen Sie die load-balance Anweisung mit der Folgenden Option ein bandwidth :

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

  • [edit protocols rsvp]

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

Beachten Sie die folgenden Informationen, wenn Sie die load-balance Erklärung verwenden:

  • Wenn Sie die load-balance Anweisung konfigurieren, wird das Verhalten der derzeit ausgeführten LSPs nicht geändert. Um derzeit ausgeführte LSPs zu erzwingen, das neue Verhalten zu verwenden, können Sie einen clear mpls lsp Befehl ausstellen.

  • Die load-balance Anweisung gilt nur für Eingangs-LSPs, bei denen Load Balancing pro Paket aktiviert ist.

  • Für Differenzierte Service-basierte Traffic-Engineering-LSPs wird die Bandbreite eines LSP durch Summierung der Bandbreite aller Klassentypen berechnet.

Konfiguration des automatischen RSVP-Mesh

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

HINWEIS:

Sie können das automatische RsVP-Mesh nicht in Verbindung mit CCC konfigurieren. CCC kann die dynamisch generierten LSPs nicht verwenden.

Um das automatische RsVP-Mesh zu konfigurieren, fügen Sie die Anweisung ein rsvp-te :

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 automatisches RSVP-Mesh zu aktivieren:

  • destination-networks– Geben Sie den Ip-Version 4 (IPv4)-Präfixbereich 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 dieser default-template Option konfigurieren, oder Sie können mit dieser template-name Option eine eigene LSP-Vorlage konfigurieren. Die LSP-Vorlage fungiert als Modellkonfiguration für die dynamisch generierten LSPs.

Konfigurieren von Timern für RSVP-Aktualisierungsmeldungen

RSVP verwendet zwei zugehörige Timing-Parameter:

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

    Aktualisierungsnachrichten umfassen Pfad- und Resv-Nachrichten. Aktualisierungsnachrichten werden in regelmäßigen Abständen gesendet, sodass die Reservierungszustände auf benachbarten Knoten keine Zeitersparnis haben. Jeder Pfad und jede Resv-Nachricht enthält den Aktualisierungszeitgeberwert, und der empfangende Knoten extrahiert diesen Wert aus den Nachrichten.

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

Verwenden Sie die folgende Formel, um die Lebensdauer eines Reservierungsstatus zu bestimmen:

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

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

Standardmäßig beträgt der Zeitgeberwert für die Aktualisierung 30 Sekunden. Um diesen Wert zu ändern, fügen Sie die Anweisung ein refresh-time :

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

  • [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 Anweisung ein keep-multiplier :

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

  • [edit protocols rsvp]

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

Vorbesendung von RSVP-Sitzungen

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

Um einer Sitzung immer vorzubemerken, wenn die Bandbreite nicht ausreicht, fügen Sie die preemption Anweisung mit der Folgenden Option bei aggressive :

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

  • [edit protocols rsvp]

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

Fügen Sie die Anweisung mit der Folgenden Option ein, um die preemption RsVP-Sitzungs-Preemption disabled zu deaktivieren:

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

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

  • [edit protocols rsvp]

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

Konfiguration der MTU-Signalübertragung in RSVP

Um die maximale Signalübertragungseinheit (MTU) in RSVP zu konfigurieren, müssen Sie MPLS so konfigurieren, dass IP-Pakete fragmentiert werden können, bevor sie in MPLS gekapselt werden. Außerdem müssen Sie die MTU-Signalübertragung in RSVP konfigurieren. Für die Fehlerbehebung können Sie die MTU-Signalübertragung allein konfigurieren, ohne die Paketfragmentierung zu ermöglichen.

Um die MTU-Signalübertragung in RSVP zu konfigurieren, fügen Sie die Anweisung ein path-mtu :

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

  • [edit protocols mpls]

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

In den folgenden Abschnitten wird beschrieben, wie Sie die Paketfragmentierung und MTU-Signalübertragung in RSVP aktivieren:

Ermöglichung von MTU-Signalisierung in RSVP

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

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

  • [edit protocols mpls path-mtu]

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

Sobald Sie die Konfiguration vorgenommen haben, werden Änderungen im MTU-Signalverhalten für RSVP bei der nächsten Aktualisierung des Pfads wirksam.

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

Aktivierung der Paketfragmentierung

Geben Sie die allow-fragmentation Anweisung ein, um IP-Pakete zu fragmentieren, bevor sie in MPLS gekapselt werden:

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

  • [edit protocols mpls path-mtu]

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

    HINWEIS:

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

Konfigurieren von ultimativem Hop-Popping für LSPs

Standardmäßig verwenden RSVP-signalisierte LSPs vorletzte Hop Popping (PHP). Abbildung 3 zeigt einen vorletzten Hop, der zwischen Router PE1 und Router PE2 aufspringt. Router CE1 leitet ein Paket an den nächsten Hop (Router PE1) weiter, der gleichzeitig der LSP-Eingang ist. Router PE1 drückt das Label 1 auf das Paket und leitet das gekennzeichnete Paket an Router P1 weiter. Router P1 schließt den Standard-MPLS-Label-Swapping-Vorgang ab, tauscht Label 1 gegen Label 2 und leitet das Paket an Router P2 weiter. Da Router P2 der vorletzte Hop-Router für den LSP zu Router PE2 ist, gibt er zuerst das Label auf und leitet das Paket dann an Router PE2 weiter. Wenn Router PE2 es empfängt, kann das Paket ein Service-Label, ein explizites Null-Label oder einfach nur ein einfaches IP- oder VPLS-Paket haben. Router PE2 leitet das nicht gekennzeichnete Paket an Router CE2 weiter.

Abbildung 3: Vorletzter Hop Popping für einen LSPVorletzter Hop Popping für einen LSP

Sie können auch Ultimate-Hop Popping (UHP) (wie in Abbildung 4) für LSPs mit RSVP-Signal konfiguriert werden. Einige Netzwerkanwendungen können erfordern, 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 (in diesem Beispiel Label 2 für Label 3) aus, bevor er das Paket an den Ausgangsrouter PE2 weiterleitet. Router PE2 bricht 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 (entweder Router CE2 oder Router CE4) weiter.

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

Für die folgenden Netzwerkanwendungen müssen Sie UHP-LSPs konfigurieren:

  • MPLS-TP für Leistungsüberwachung und In-Band-OAM

  • Virtuelle Edge-Schaltungen

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

  • LDP-signalisierter 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, Nicht-PHP-Verhalten und Out-of-Band-Zuordnung für RSVP-TE-LSPs.

Bei Punkt-zu-Punkt-RSVP-signalisierten LSPs wird das UHP-Verhalten vom LSP-Eingang signalisiert. Basierend auf der Eingangs-Routerkonfiguration kann RSVP den 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 auch zwei Routen in der Routingtabelle mpls.0. S bezieht sich auf das S-Bit des MPLS-Labels, das angibt, ob der Unterboden des Labelstacks erreicht wurde oder nicht.

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

  • Route S=1– Zeigt an, dass es keine Label mehr gibt. Der nächste Hop zeigt auf die Routing-Tabelle inet.0, wenn die Plattform eine verkettete und mehrfamilienige Suche unterstützt. Alternativ kann die Label-Route 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, das innere (S=1) das VC-Label . Eine auf dem Transportlabel basierende Suche ergibt einen Tabellenhandy für die Routingtabelle mpls.0. Es gibt eine zusätzliche Route in der Routing-Tabelle mpls.0, die dem inneren Label entspricht. Eine Suche basierend auf dem inneren Label ergibt im CE-Router next Hop.

  • Layer 3 VPN: Ein Paket kommt am PE-Router (Ausgang des UHP LSP) mit zwei Labeln an. Das äußere Label (S=0) ist das UHP-Label, das innere ist das VPN-Label (S=1). Eine Suche basierend auf dem Transportetikett ergibt im Tabellenhandy für die Routing-Tabelle mpls.0. In diesem Szenario gibt es zwei Fälle. Standardmäßig werben Layer 3-VPNs für das Pro-Next-Hop-Label. Eine Suche basierend auf dem inneren Label ergibt den nächsten Hop zum CE-Router. Wenn Sie jedoch die Anweisung für die vrf-table-label Layer-3-VPN-Routing-Instanz konfiguriert haben, zeigt das innere LSI-Label auf die VRF-Routingtabelle. Eine IP-Suche für die VRF-Routing-Tabelle ist ebenfalls abgeschlossen.

    HINWEIS:

    UHP für Layer 3-VPNs, die mit der vrf-table-label Anweisung konfiguriert sind, werden nur auf universellen 5G-Routing-Plattformen der MX-Serie unterstützt.

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

    HINWEIS:

    UHP für VPLS, die mit der no-tunnel-service Anweisung konfiguriert ist, wird nur auf Routern der MX 3D-Serie unterstützt.

  • IPv4 über MPLS – Ein Paket kommt mit einem Label (S=1) am PE-Router (Ausgang des UHP LSP) an. Eine auf diesem Label basierende Suche gibt eine VT-Tunnelschnittstelle zurück. Eine weitere IP-Suche wird auf der VT-Schnittstelle abgeschlossen, um zu bestimmen, wohin das Paket weitergeleitet werden soll. Wenn die Routing-Plattform mehrschichtige und verkettete Lookups unterstützt (z. B. MX 3D-Router und Paketübertragungs-Router der PTX-Serie), wird die Suche basierend auf label route (S=1) zur Routingtabelle inet.0 angezeigt.

  • IPv6 über MPLS: Für IPv6-Tunneling über MPLS werben PE-Router IPv6-Routen miteinander mit dem Labelwert 2 an. Dies ist das explizite Null-Label für IPv6. Infolgedessen werden bei der Weiterleitung der nächsten Hops für IPv6-Routen, die von entfernten PE-Routern gelernt werden, normalerweise zwei Label übertragen. Das innere Label ist 2 (es könnte anders sein, wenn der Werbe-PE-Router 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 Transportetikett (S=0), das innere ist das IPv6 Explicit-Null-Label (Label 2). Die Suche nach dem inneren Label in der Routing-Tabelle mpls.0 leitet zurück zur Routingtabelle mpls.0. Auf Routern der MX 3D-Serie wird das innere Label (Label 2) entfernt und eine IPv6-Suche erfolgt mithilfe der Routingtabelle inet6.0.

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

Die folgenden Aussagen ermöglichen ein ultimatives Hop-Popping für einen LSP. Sie können diese Funktion auf einem bestimmten LSP oder für alle eingangsfähigen LSPs aktivieren, die auf dem Router konfiguriert sind. 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 Aussage 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 ultimatives Hop-Popping auf allen eingehenden LSPs zu ermöglichen, die auf dem Router konfiguriert sind. Sie können die ultimate-hop-popping Anweisung auch unter den entsprechenden [edit logical-routers] Hierarchieebenen konfigurieren.

    HINWEIS:

    Wenn Sie ultimatives Hop-Popping aktivieren, versucht RSVP, bestehende LSPs auf make-before-Break-Weise als ultimative Hop-Popping-LSPs zu resignalieren. Wenn ein Ausgangsrouter das Ultimative Hop-Popping nicht unterstützt, wird der vorhandene LSP abgerissen (RSVP sendet eine PathTear-Nachricht über den Pfad eines LSP, entfernt den Pfadstatus und den abhängigen Reservierungsstatus und gibt die zugehörigen Netzwerkressourcen frei).

    Wenn Sie ultimate-Hop-Popping deaktivieren, resignalisiert RSVP vorhandene LSPs als vorletzten Hop-Popping-LSPs in einer Make-before-Break-Art.

  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 [edit chassis] Hierarchieebene. Sobald Sie die network-services Anweisung konfiguriert haben, müssen Sie den Router neu starten, um das UHP-Verhalten zu aktivieren.

Konfigurieren von RSVP, um das Label auf dem Ultimate-Hop-Router zu popen

Sie können den auf dem Ausgangsrouter eines LSP angekündigten 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.

HINWEIS:

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

Um das ultimative Hop-Popping für RSVP zu konfigurieren, fügen Sie die Anweisung ein explicit-null :

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

  • [edit protocols mpls]

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

Ultimatives Hop-Popping für Point-to-Multipoint-LSPs

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

Es kann von Vorteil sein, ultimatives Hop-Popping auf Point-to-Multipoint-LSPs zu ermöglichen, insbesondere, wenn der Transitverkehr dasselbe Ausgangsgerät durchläuft. Wenn Sie Ultimate-Hop-Popping aktivieren, kann eine einzelne Kopie des Datenverkehrs über den eingehenden Link gesendet werden, was erhebliche Bandbreite spart. Standardmäßig ist Ultimate-Hop-Popping deaktiviert.

Sie ermöglichen ultimatives Hop-Popping für Point-to-Multipoint-LSPs, indem Sie die tunnel-services Anweisung konfigurieren. Wenn Sie Ultimate-Hop-Popping aktivieren, wählt Junos OS eine der verfügbaren virtuellen Loopback-Tunnel (VT)-Schnittstellen aus, um die Pakete für die IP-Weiterleitung auf die PFE zurück zu schleifen. Standardmäßig wird der VT-Schnittstellenauswahlprozess automatisch durchgeführt. Die Bandbreitensteuerung 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 ist, wählt Junos OS eine andere VT-Schnittstelle mit ausreichendEr Bandbreite für die Zugangskontrolle aus.

Wenn ein LSP mehr Bandbreite benötigt, als von einer der VT-Schnittstellen zur Verfügung steht, kann Ultimate-Hop-Popping nicht aktiviert werden und stattdessen vorletzte Hop-Popping aktiviert werden.

Damit Point-to-Multipoint-LSPs am besten funktionieren können, muss der Ausgangsrouter über einen PIC verfügen, der Tunnelservices wie den Tunnelservice PIC oder den adaptiven Service PIC bereitstellt. Tunneldienste werden benötigt, um das endgültige MPLS-Label zu knacken und Pakete für IP-Adressen-Suchen zurückzugeben.

Sie können explizit konfigurieren, welche VT-Schnittstellen den RSVP-Datenverkehr verarbeiten, indem Sie die devices Option für die tunnel-services Anweisung angeben. Mit devices der 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 das ultimative Hop-Popping für Ausgangs-Point-to-Multipoint-LSPs zu ermöglichen, müssen Sie die interface Anweisung auch mit der all Folgenden Option konfigurieren:

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

Verfolgung des RSVP-Protokoll-Datenverkehrs

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

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

  • [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 in das Verzeichnis /var/logabgelegt. Wir empfehlen, die RsVP-Tracing-Ausgabe in der Datei rsvp-logzu platzieren.

  • all– Alle Nachverfolgungsvorgänge.

  • error— Alle erkannten Fehlerbedingungen

  • event— RSVP-bezogene Ereignisse (hilft bei der Rückverfolgung von Ereignissen im Zusammenhang mit RSVP Graceful Restart)

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

  • packets— Alle RSVP-Pakete

  • path— Alle Pfadmeldungen

  • pathtear—PathTear-Nachrichten

  • resv— Resv-Nachrichten

  • resvtear— ResvTear-Nachrichten

  • route—Routing-Informationen

  • state— Session-Zustandsübergänge, auch wenn LSPs mit RSVP-Signalisierung hoch- und heruntergehen.

HINWEIS:

Verwenden Sie das all Trace-Flag und den detail Flag-Modifizierer mit Vorsicht, da dies dazu führen kann, dass die CPU sehr beschäftigt wird.

Um die Protokolldatei anzuzeigen, die beim Aktivieren der RSVP-Traceoptionen generiert wird, erteilen Sie den show log file-name Befehl, wobei file-name sich die Datei befindet, die Sie mit der traceoptions Anweisung angegeben haben.

Allgemeine Informationen zur Ablaufverfolgung und globalen Ablaufverfolgungsoptionen finden Sie in der Junos OS Routing Protocol Library for Routing Devices.

Beispiele: Verfolgung des RSVP-Protokoll-Datenverkehrs

Verfolgen Sie RSVP-Pfadmeldungen im Detail:

Verfolgen Sie alle RSVP-Nachrichten:

Verfolgen Sie alle RSVP-Fehlerbedingungen:

Trace-RSVP-Statusübergänge:

RSVP-Protokolldatei-Ausgabe

Die folgende Beispielausgabe wird durch Ausgabe des show log file-name Befehls auf einem Router generiert, auf dem RSVP-Traceoptionen mit konfigurierter state Flag aktiviert wurden. Die RSVP-signalisiert LSP E-D wird am 11. März 14:04:36.707092 abgerissen. Am 11. März 14:05:30.101492 wird es wieder angezeigt.

RSVP Graceful Restart

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

RSVP Graceful Restart wird in den folgenden Abschnitten beschrieben:

RSVP Graceful Restart Terminologie

Neustartzeit (in Millisekunden)

Der Standardwert ist 60.000 Millisekunden (1 Minute). Die Neustartzeit wird in der Hallo-Nachricht angekündigt. Die Uhrzeit gibt an, wie lange ein Nachbar warten sollte, um eine Hallo-Nachricht von einem neustartenden Router zu erhalten, bevor er diesen Router für tot erklärt und den Status bereinigung.

Das Junos OS kann die vom Nachbarn angekündigte Neustartzeit überschreiben, wenn die Zeit größer als ein Drittel der lokalen Neustartzeit ist. Angesichts der Standard-Neustartzeit von 60 Sekunden würde ein Router beispielsweise 20 Sekunden oder weniger warten, um eine Hallo-Nachricht von einem neu gestarteten 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 Steuerungskanal vor dem Neustart eingerichtet ist (der Hallo-Austausch ist abgeschlossen). Gilt nur für Knotenfehler.

Wenn ein graceful Restart ausgeführt wird, wird die Zeit bis zum Abschluss einer Wiederherstellung angekündigt. Zu anderen Zeiten ist dieser Wert Null. Die maximal angekündigte Wiederherstellungszeit beträgt 2 Minuten (120.000 Millisekunden).

Während der Wiederherstellungszeit versucht ein neu gestarteter Knoten, seinen verlorenen Status mit Hilfe seiner Nachbarn wiederherzustellen. Der Nachbar des neustartenden Knotens muss die Pfadnachrichten mit den Wiederherstellungsetiketten innerhalb eines Zeitraums von einer Hälfte der Wiederherstellungszeit an den neu startenden Knoten senden. Der neustartende Knoten betrachtet seinen graceful-Neustart nach der angekündigten Wiederherstellungszeit als abgeschlossen.

RSVP Graceful Restart-Betrieb

Damit RSVP graceful restart funktioniert, muss die Funktion in der globalen Routing-Instanz aktiviert sein. RSVP Graceful Restart kann auf Protokollebene (für RSVP allein) oder auf globaler Ebene für alle Protokolle deaktiviert werden.

RSVP Graceful Restart erfordert die Folgenden eines neustartenden Routers und der Nachbarn des Routers:

  • Für den neustartenden Router versucht RSVP Graceful Restart, die von RSVP installierten Routen und die zugewiesenen Label aufrechtzuerhalten, sodass der Datenverkehr weiterhin ohne Unterbrechung weitergeleitet wird. RsVP Graceful Restart erfolgt schnell genug, um die Auswirkungen auf benachbarte Knoten zu reduzieren oder zu beseitigen.

  • Die benachbarten Router müssen den RSVP Graceful Restart Helper Modus aktiviert haben, sodass sie einen Router unterstützen können, der versucht, RSVP neu zu starten.

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

Im Folgenden werden die graceful Restart-Verhaltensweisen des RSVP aufgeführt, die je nach Konfiguration und aktivierten Funktionen variieren:

  • Wenn Sie den Hilfsmodus deaktivieren, versucht Das Junos OS einem Nachbarn nicht dabei zu helfen, RSVP neu zu starten. Alle Informationen, die mit einem Restart Cap-Objekt von einem Nachbarn eingehen, werden ignoriert.

  • Wenn Sie den graceful Restart unter der Konfiguration der Routing-Instanz aktivieren, kann der Router mit Hilfe seiner Nachbarn gracefulful neu gestartet werden. RSVP kündigt ein Restart Cap-Objekt (RSVP RESTART) in Hallo-Nachrichten an, in denen Neustart- und Wiederherstellungszeiten angegeben werden (keiner der Werte ist 0).

  • Wenn Sie RSVP Graceful Restart unter der [protocols rsvp] Hierarchieebene explizit deaktivieren, wird für das Restart Cap-Objekt der Wert 0 angegeben. Der Neustart benachbarter Router wird unterstützt (es sei denn, der Hilfsmodus ist deaktiviert), aber der Router selbst behält den RSVP-Weiterleitungsstatus nicht bei und kann seinen Steuerungsstatus nicht wiederherstellen.

  • Wenn nach einem Restart-RSVP feststellt, dass kein Weiterleitungsstatus beibehalten wurde, wird das Restart Cap-Objekt mit neustart- und wiederherstellungszeiten als 0 angegeben.

  • Wenn der Graceful-Restart- und Hilfsmodus deaktiviert sind, ist RSVP graceful restart vollständig deaktiviert. Der Router erkennt oder kündigt die RSVP Graceful Restart-Objekte weder an noch an.

Die Werte für die Neustart- und Wiederherstellungszeiten können nicht explizit konfiguriert werden.

Im Gegensatz zu anderen Protokollen gibt es für RSVP keine Möglichkeit, festzustellen, dass er eine Neustart-Prozedur abgeschlossen hat, außer einem festen Timeout. Alle RSVP Graceful Restart-Prozeduren sind timerbasiert. Ein show rsvp version Befehl kann anzeigen, dass der Neustart noch läuft, selbst wenn alle RSVP-Sitzungen wieder eingerichtet und die Routen wiederhergestellt werden.

Verarbeitung des Cap-Objekts "Restart"

Die folgenden Annahmen werden über einen Nachbarn basierend auf dem Restart Cap-Objekt gemacht (vorausgesetzt, dass ein Steuerungskanalausfall eindeutig von einem Node-Neustart zu unterscheiden ist):

  • Ein Nachbar, der das Restart Cap-Objekt nicht in seinen Hallo-Meldungen ankündigen, kann einen Router weder bei der Status- noch bei der Labelwiederherstellung unterstützen, noch einen RSVP Graceful Restart durchführen.

  • Nach einem Neustart hat ein Nachbar, der ein Restart Cap-Objekt mit einer Neustartzeit gleich einem beliebigen Wert und einer Wiederherstellungszeit von 0 ankünbt, seinen Weiterleitungsstatus nicht beibehalten. Wenn eine Wiederherstellungszeit 0 entspricht, gilt der Neighbor als tot und alle Zustände, die mit diesem Nachbarn zusammenhängen, werden gelöscht, unabhängig vom Wert der Neustartzeit.

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

Konfigurieren von RSVP Graceful Restart

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

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

  • Graceful-Neustart ist aktiviert, aber der Hilfsmodus ist deaktiviert. Ein router, der auf diese Weise konfiguriert ist, kann einen ordnungsgemäßen Neustart durchführen, kann aber einem Nachbarn bei seinen Neustart- und Wiederherstellungsverfahren nicht helfen.

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

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

HINWEIS:

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

In den folgenden Abschnitten wird beschrieben, wie Sie RSVP Graceful Restart konfigurieren:

Aktivierung von Graceful Restart für alle Routing-Protokolle

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

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

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

  • [edit routing-options]

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

Deaktivieren von Graceful Restart für RSVP

Standardmäßig sind RSVP Graceful Restart und RSVP-Hilfsmodus aktiviert, wenn Sie graceful Restart aktivieren. Sie können jedoch eine oder beide dieser Funktionen deaktivieren.

Um RSVP graceful Restart and Recovery zu deaktivieren, fügen Sie die disable Anweisung auf Hierarchieebene [edit protocols rsvp graceful-restart] ein:

Deaktivieren des RSVP-Hilfsmodus

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

Konfigurieren der maximalen Hilfswiederherstellungszeit

Um zu konfigurieren, wie lange der Router den Status seiner RSVP-Nachbarn behält, während diese einem graceful-Neustart unterzogen werden, 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-Nachbarn zur Wiederherstellung benötigt.

Konfigurieren der maximalen Hilfszeit für den Neustart

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

RSVP LSP-Tunnel – Übersicht

Mit einem Label-Switched Path(LSP)-Tunnel (Resource Reservation Protocol) können Sie RSVP-LSPs innerhalb anderer RSVP-LSPs senden. Auf diese Weise kann ein Netzwerkadministrator Traffic-Engineering von einem Ende des Netzwerks zum anderen bereitstellen. Eine nützliche Anwendung für diese Funktion besteht darin, Kunden-Edge-Router (CE) mit Provider Edge (PE)-Routern über einen RSVP-LSP zu verbinden und diesen Edge-LSP dann in einem zweiten RSVP-LSP zu tunneln, der über den Netzwerkkern läuft.

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 wie für generalisiertes Multiprotocol Label Switching (GMPLS). (Weitere Informationen zu GMPLS finden Sie im Junos GMPLS-Benutzerhandbuch.

Die Weiterleitungsadjacency erstellt einen tunnelierten Pfad für das 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 über die FA-LSP gesendet werden, indem Sie cspf (Constrained Shortest Path First), Link Management Protocol (LMP), Open Shortest Path First (OSPF) und RSVP verwenden.

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

  • LMP: LMP wurde ursprünglich für GMPLS entwickelt und stellt Weiterleitungsadjacencies zwischen RSVP-LSP-Tunnel-Peers fest und verwaltet und weist Ressourcen für Traffic-Engineering-Verbindungen zu.

  • OSPF-Erweiterungen: OSPF wurde entwickelt, um Pakete an physische und logische Schnittstellen zu leiten, die mit einer Physical Interface Card (PIC) verbunden sind. Dieses Protokoll wurde erweitert, um Pakete an virtuelle Peer-Schnittstellen zu leiten, die in einer LMP-Konfiguration definiert sind.

  • 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 virtuellen Peer-Schnittstellen reisen, die in einer LMP-Konfiguration definiert sind.

    HINWEIS:

    Ab Junos OS Version 15.1 wird die Unterstützung für mehrere Instanzen auf MPLS RSVP-TE erweitert. Diese Unterstützung ist nur für virtuelle Routerinstanzen 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. Multi-Instance-RSVP-TE bietet die Flexibilität, die Entitäten auf der Steuerungsebene, die instanzsensibel sein müssen, per Hand auszuwählen, z. B. kann ein Router an mehreren TE-Instanzen teilnehmen, während er weiterhin eine einzelne BGP-Instanz ausführt.

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

    Diese Verbesserungen erleichtern die RSVP-TE-Konfiguration im großen Maßstab:

    • Sicherstellung der LSP-Data-Plane-Bereitschaft während des LSP-Resignalings, bevor der Datenverkehr den LSP durchläuft, mit dem RSVP-TE LSP-Selbstping-Mechanismus.

      Ein LSP sollte den Datenverkehr nur übertragen, wenn bekannt ist, dass er in der Data Plane programmiert wurde. Der Datenaustausch in der LSP-Datenebene, z. B. LSP-Ping-Anforderungen, erfolgt am Eingangsrouter, bevor der Datenverkehr zu einem LSP oder zu seiner MBB-Instanz umgeschaltet wird. In großen Netzwerken kann dieser Datenverkehr einen LSP-Ausgangsrouter überlasten, da der Ausgangs-LSP auf LSP-Ping-Anforderungen reagieren muss. Der LSP-Self-Ping-Mechanismus ermöglicht es dem Eingangs-LER, LSP-Ping-Antwortnachrichten zu erstellen und diese über die LSP-Datenebene zu senden. Nach dem Erhalt dieser Nachrichten leitet der Ausgangs-LER sie an den Eingang weiter, was die Lebendigkeit der LSP-Datenebene anzeigt. So wird sichergestellt, dass der LSP den Datenverkehr nicht weiterträgt, bevor die Data Plane programmiert wurde.

    • Entfernen sie die aktuelle harte Grenze von 64.000 LSPs auf einem Eingangsrouter und skalieren Sie die Gesamtzahl der LSPs mit RSVP-TE-signalisierten LSPs. Es können bis zu 64.000 LSPs pro Ausgangsbasis konfiguriert werden. Zuvor war diese Begrenzung die aggregierte Anzahl von LSPs, die auf dem Eingangs-LER konfiguriert werden konnten.

    • Verhindern eines plötzlichen Abrisses von LSPs durch den Eingangsrouter aufgrund einer Verzögerung bei der Signalübertragung des LSP an den Transit-Routern.

    • Ermöglichen einer flexiblen Ansicht von LSP-Datensätzen, um die Visualisierung von LSP-charakteristischen Daten zu erleichtern.

    HINWEIS:

    Ab Junos OS Version 17.4 wird ein Standard-Timer von 1800 Sekunden für den Selbstping eingeführt.

Für LSP-Hierarchien gelten folgende Einschränkungen:

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

  • Graceful Restart wird nicht unterstützt.

  • Der Linkschutz ist für FA-LSPs oder am Ausgangspunkt der Weiterleitungsadjacency nicht 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, der von e2e_lsp_r0r5 Router 0 stammt und auf Router 5 endet. Bei der Übertragung durchquert dieser LSP den FA-LSP fa_lsp_r1r4. Der Rückkehrpfad wird durch den End-to-End-RSVP-LSP e2e_lsp_r5r0 dargestellt, der über den FA-LSP fa_lsp_r4r1geleitet wird.

Konfigurieren Sie auf Router 0 den End-to-End-RSVP-LSP, der zu Router 5 wechselt. Verwenden Sie einen strengen Pfad, der Router 1 durchquert, und den LMP-Traffic-Engineering-Link, der von Router 1 zu Router 4 führt.

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. Verweisen Sie auf den FA-LSP im Traffic-Engineering-Link, und fügen Sie die Peer-Schnittstelle in OSPF und RSVP hinzu.

Wenn der End-to-End-LSP des Rückkehrpfads 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 korrekt zwischen den Routern 0 und 1 konfigurieren.

Router 1

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

Router 2

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

Router 3

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

Wenn der anfängliche 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 korrekt zwischen Router 4 und Router 5 konfigurieren.

Router 4

Konfigurieren Sie auf Router 5 den End-to-End-RSVP-LSP, der zu Router 0 geleitet wird. Verwenden Sie einen strengen Pfad, der Router 4 und den LMP Traffic Engineering-Link von Router 4 zu Router 1 durchquert.

Router 5

Ihre Arbeit verifizieren

Um zu überprüfen, ob Ihr RSVP-LSP-Tunnel richtig 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)

Diese Befehle, die für das Konfigurationsbeispiel verwendet werden, finden Sie in den folgenden Abschnitten:

Router 0

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

Router 1

Stellen Sie auf Router 1 sicher, dass ihre LMP Traffic Engineering Link-Konfiguration funktioniert und dass der End-to-End-LSP den Traffic-Engineering-Link durch Ausgabe show link-management der Befehle durchquert. Sie können den show rsvp session extensive Befehl auch ausstellen, um zu bestätigen, dass der FA-LSP betriebsbereit ist.

Konfigurieren von Peer-Schnittstellen in OSPF und RSVP

Nachdem Sie LMP-Peers einrichten, müssen Sie OSPF und RSVP Peer-Schnittstellen hinzufügen. Eine Peer-Schnittstelle ist eine virtuelle Schnittstelle, die zur Unterstützung der Steuerungsadjacency zwischen zwei Peers verwendet wird.

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

Definieren von Label-Switched Paths für FA-LSP

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

Einrichten von FA-LSP-Pfadinformationen

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

HINWEIS:

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

Option: RsVP-LSPs gracefully abreißen

Sie können einen RSVP-LSP in einem zweistufigen Prozess herunterreißen, bei dem die vom LSP verwendete RSVP-Sitzung ordnungsgemäß zurückgezogen wird. Für alle Nachbarn, die graceful Teardown unterstützen, wird eine Anfrage für den Teardown von der Routingplattform 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 Abriss der RSVP-Sitzung abzuschließen. Wenn ein Nachbar keinen graceful Teardown unterstützt, wird die Anfrage als Standardsitzungs-Teardown und nicht als graceful behandelt.

Um eine RSVP-Sitzung zu einem graceful Teardown durchzuführen, erteilen Sie den clear rsvp session gracefully Befehl. Optional können Sie die Quell- und Zieladresse der RSVP-Sitzung, die LSP-Kennung des RSVP-Absenders und den Tunnelbezeichner der RSVP-Sitzung angeben. Um diese Qualifizierer zu verwenden, schließen Sie die connection-sourceOptionen , connection-destinationlsp-idund tunnel-id Optionen ein, wenn Sie den clear rsvp session gracefully Befehl ausstellen.

Sie können auch den Zeitraum konfigurieren, in dem die Routing-Plattform darauf wartet, dass Nachbarn die graceful Teardown-Anforderung erhalten, bevor Sie den tatsächlichen Teardown starten, indem Sie die graceful-deletion-timeout Anweisung auf [edit protocols rsvp] Hierarchieebene angeben. Der Standardmäßige Timeoutwert für das graceful-Löschen beträgt 30 Sekunden, mit einem Mindestwert von 1 Sekunde und einem maximalen Wert von 300 Sekunden. Um den aktuellen Wert anzuzeigen, der für einen graceful-Timeout für das Löschen konfiguriert ist, erteilen Sie den show rsvp version Betriebsmodus-Befehl.

Verwandte Themen

Release-Verlaufstabelle
Release
Beschreibung
19.4R1
16.1
Ab Junos OS Version 16.1 werden jedoch die RSVP-Sitzungen heruntergefahren, wenn RSVP hallo eine Time-Out-Nachricht gibt.