RSVP-Konfiguration

Um RSVP auf einer einzelnen Schnittstelle zu aktivieren, schließen Sie die Anweisung ein, und geben Sie die Schnittstelle mithilfe der Anweisung an.rsvpinterface Dies ist die minimale RSVP-Konfiguration. Alle anderen RSVP-Konfigurationsanweisungen sind optional.

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

• [edit protocols]

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

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

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

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

• [edit protocols rsvp interface interface-name ]

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

Der Hauptzweck der Junos RSVP-Software besteht darin, dynamische Signale innerhalb von Label-Switched-Pfaden (LSPs) zu unterstützen. Wenn Sie sowohl MPLS als auch RSVP auf einem Router aktivieren, wird MPLS zu einem 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 eingerichtet werden, indem Sie die Anweisung auf Hierarchieebene verwenden.label-switched-path[edit protocols mpls] Jeder Sprachdienstleister wird in eine RSVP-Anfrage übersetzt, um 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 stammt vom lokalen Router und ist für das Ziel des LSP bestimmt.

Wenn eine RSVP-Sitzung erfolgreich erstellt wurde, wird der Sprachdienstleister entlang der von der RSVP-Sitzung erstellten Pfade eingerichtet. Wenn die RSVP-Sitzung nicht erfolgreich ist, benachrichtigt RSVP MPLS über seinen Status. Es liegt an MPLS, Sicherungspfade zu initiieren oder den ursprünglichen Pfad zu wiederholen.

Zum Übergeben von Signalinformationen für das Label-Switching unterstützt RSVP vier zusätzliche Objekte: Label-Request-Objekt, Label-Objekt, Explicit Route-Objekt und Record Route-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 Record Route-Objekt nicht obligatorisch.

Gehen Sie wie folgt vor, um MPLS zu konfigurieren und zu einem RSVP-Client zu machen:

• 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 auf allen Routerschnittstellen, die den LSP bilden.

• Konfigurieren Sie die Router zu Beginn des LSP.

Sie können RSVP-Label-Switched-Pfade (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 Hierarchie eingeführt haben.[edit protocols mpls label-switched-path name]

In den folgenden Abschnitten wird beschrieben, wie RSVP-Schnittstellen konfiguriert werden:

• Konfigurieren der RSVP-Aktualisierungsreduzierung
• Konfigurieren des Antwort-Hallo-Intervalls
• Konfigurieren der RSVP-Authentifizierung
• Konfigurieren des Bandbreitenabonnements für Klassentypen
• Konfigurieren des RSVP-Aktualisierungsschwellenwerts auf einer Schnittstelle
• Konfigurieren von RSVP für nicht nummerierte Schnittstellen

In diesem Beispiel wird gezeigt, wie ein LSP zwischen Routern in einem IP-Netzwerk mit RSVP als Signalisierungsprotokoll erstellt wird.

Service Provider verwenden häufig BGP- und MPLS-VPNs, um das Netzwerk effizient zu skalieren und gleichzeitig umsatzgenerierende Services bereitzustellen. In diesen Umgebungen wird BGP verwendet, um die VPN-Routing-Informationen über das Netzwerk des Service Providers zu verteilen, während MPLS verwendet wird, um diesen VPN-Datenverkehr von einem VPN-Standort zu einem anderen weiterzuleiten.

Wenn Sie einen neuen PE-Router hinzufügen, der an BGP- und MPLS-VPNs teilnimmt, müssen alle zuvor vorhandenen PE-Router für das Peering mit dem neuen PE-Router sowohl für BGP als auch für MPLS konfiguriert werden. Mit jedem neuen PE-Router im Netzwerk des Service Providers wird der Konfigurationsaufwand schnell zu groß.

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 auf allen PE-Routern ermöglicht es RSVP, automatisch die erforderlichen LSPs zu erstellen, wenn ein neuer PE-Router hinzugefügt wird.rsvp-te

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

Alternativ können Sie den Datenverkehr über alle Sprachdienstleister hinweg ausgleichen, indem Sie den Lastenausgleich pro Paket aktivieren.

Um den Paketlastenausgleich für einen Eingangs-LSP zu aktivieren, konfigurieren Sie die Anweisung wie folgt:policy-statement

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

Sobald der Load Balancing pro Paket angewendet wurde, wird der Datenverkehr gleichmäßig auf die Sprachdienstleister verteilt (standardmäßig).

Sie müssen den Lastenausgleich pro Paket konfigurieren, wenn Sie die schnelle PFE-Umleitung aktivieren möchten. Um die schnelle PFE-Umleitung zu aktivieren, fügen Sie die in diesem Abschnitt gezeigte Anweisung für den Lastenausgleich pro Paket in die Konfiguration jedes Routers ein, an dem eine Umleitung stattfinden kann.policy-statement Siehe auch Konfigurieren der schnellen Weiterleitung.Konfigurieren der schnellen Weiterleitung

Sie können auch einen Lastenausgleich für den Datenverkehr zwischen den Sprachdienstleistern im Verhältnis zu der für jeden Sprachdienstleister konfigurierten Bandbreite durchführen. Diese Funktion kann den Datenverkehr in Netzwerken mit asymmetrischen Bandbreitenfunktionen besser auf externe Verbindungen verteilen, da die konfigurierte Bandbreite eines LSP in der Regel die Datenverkehrskapazität dieses LSP widerspiegelt.

Um den RSVP-LSP-Lastenausgleich zu konfigurieren, fügen Sie die Anweisung mit der folgenden Option ein:load-balancebandwidth

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 Anweisung verwenden:load-balance

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

• Die Anweisung gilt nur für Eingangs-LSPs, für die der Lastenausgleich pro Paket aktiviert ist.load-balance

• Bei Differentiated Services-fähigen LSPs, die Traffic Engineering betreiben, wird die Bandbreite eines LSP berechnet, indem die Bandbreite aller Klassentypen summiert wird.

RSVP verwendet zwei verwandte Timing-Parameter:

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

  Aktualisierungsnachrichten enthalten Pfad- und Resv-Nachrichten. Aktualisierungsnachrichten werden in regelmäßigen Abständen gesendet, damit bei Reservierungszuständen in benachbarten Knoten kein Timeout auftritt. Jeder Pfad und jede Resv-Nachricht enthält den Aktualisierungstimerwert, 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. Sie gibt die Anzahl der Nachrichten an, die verloren gehen können, bevor ein bestimmter Status als veraltet deklariert wird 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 ( – 1) müssen aufeinanderfolgende Aktualisierungsmeldungen verloren gehen, bevor ein Reservierungsstatus gelöscht wird.keep-multiplier

Es wird nicht empfohlen, einen kurzen RSVP-Hallo-Timer zu konfigurieren. Wenn eine schnelle Erkennung eines ausgefallenen Nachbarn erforderlich ist, konfigurieren Sie kurze IGP-Hello-Timer (OSPF oder IS-IS).

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

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

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

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

• [edit protocols rsvp]

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

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

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

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

• [edit protocols rsvp]

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

Um die vorzeitige Entfernung von RSVP-Sitzungen zu deaktivieren, fügen Sie die Anweisung mit der folgenden Option ein:preemptiondisabled

Um zur Standardeinstellung zurückzukehren (d. h. eine Sitzung nur für eine neue Sitzung mit höherer Priorität vorwegzunehmen), fügen Sie die Anweisung mit der folgenden Option ein:preemptionnormal

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

• [edit protocols rsvp]

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

Um die MTU-Signalisierung (Maximum Transmission Unit) 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-Signalisierung in RSVP konfigurieren. Zur Fehlerbehebung können Sie die MTU-Signalisierung allein konfigurieren, ohne die Paketfragmentierung zu aktivieren.

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

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

• [edit protocols mpls]

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

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

• Aktivieren der MTU-Signalübertragung in RSVP
• Aktivieren der Paketfragmentierung

Sie können den Bezeichnungswert steuern, der auf dem Ausgangsrouter eines LSP angekündigt wird. Die standardmäßig angekündigte Bezeichnung ist Label 3 (Implizite Null-Bezeichnung). Wenn Label 3 angekündigt wird, entfernt der Router des vorletzten Hops das Label und sendet das Paket an den Ausgangsrouter. Wenn Ultimate-Hop-Popping aktiviert ist, wird Label 0 (IP Version 4 [IPv4] Explicit Null label) angekündigt. Ultimate-Hop-Popping stellt sicher, dass alle Pakete, die ein MPLS-Netzwerk durchqueren, ein Label enthalten.

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

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

• [edit protocols mpls]

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

Standardmäßig wird sowohl für Punkt-zu-Punkt- als auch für Punkt-zu-Mehrpunkt-LSPs das Preultimate-Hop-Popping für MPLS-Datenverkehr verwendet. MPLS-Labels werden aus Paketen auf dem Router direkt vor dem Ausgangsrouter des LSP entfernt. Die einfachen IP-Pakete werden dann an den Ausgangsrouter weitergeleitet. Beim Ultimate-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, Ultimate-Hop-Popping auf Punkt-zu-Multipunkt-LSPs zu aktivieren, insbesondere wenn der Transitdatenverkehr dasselbe Ausgangsgerät durchläuft. Wenn Sie Ultimate-Hop-Popping aktivieren, kann eine einzelne Kopie des Datenverkehrs über die eingehende Verbindung gesendet werden, wodurch erhebliche Bandbreite eingespart wird. Standardmäßig ist das Popping von Ultimate-Hops deaktiviert.

Sie aktivieren Ultimate-Hop-Popping für Punkt-zu-Multipunkt-LSPs, indem Sie die Anweisung konfigurieren.tunnel-services Wenn Sie Ultimate-Hop-Popping aktivieren, wählt das Junos-Betriebssystem eine der verfügbaren VT-Schnittstellen (Virtual Loopback Tunnel) aus, um die Pakete zur IP-Weiterleitung an die PFE zurückzusenden. Standardmäßig wird der Auswahlprozess der VT-Schnittstelle automatisch durchgeführt. Die Bandbreitenzulassungssteuerung 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 das Junos-Betriebssystem eine andere VT-Schnittstelle mit ausreichender Bandbreite für die Zugangssteuerung aus.

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

Damit Ultimate-Hop-Popping auf Punkt-zu-Multipunkt-LSPs ordnungsgemäß funktioniert, muss der Ausgangsrouter über einen PIC verfügen, der Tunnelservices bereitstellt, z. B. den Tunnelservices PIC oder den Adaptive Services PIC. Tunneldienste werden benötigt, um das endgültige MPLS-Label aufzulösen und Pakete für die IP-Adresssuche zurückzugeben.

Sie können explizit konfigurieren, welche VT-Schnittstellen den RSVP-Datenverkehr verarbeiten, indem Sie die Option für die Anweisung einfügen.devicestunnel-services Mit dieser Option können Sie festlegen, welche VT-Schnittstellen von RSVP verwendet werden sollen.devices Wenn Sie diese Option nicht konfigurieren, können alle VT-Schnittstellen verwendet werden, die dem Router zur Verfügung stehen.

Konfigurieren Sie die folgende Anweisung, um Ultimate-Hop-Popping für die Ausgangspunkt-zu-Multipunkt-LSPs auf einem Router zu aktivieren:tunnel-services

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

• [edit protocols rsvp]

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

Um Ultimate-Hop-Popping für Ausgangspunkt-zu-Multipunkt-LSPs zu aktivieren, müssen Sie die Anweisung auch mit der folgenden Option konfigurieren:interfaceall

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

Um den Datenverkehr des RSVP-Protokolls zu verfolgen, fügen Sie die folgende Anweisung ein:traceoptions

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

• [edit protocols rsvp]

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

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

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

• all– Alle Ablaufverfolgungsvorgänge.

• error—Alle erkannten Fehlerzustände

• event—RSVP-bezogene Ereignisse (hilft bei der Verfolgung von Ereignissen im Zusammenhang mit dem ordnungsgemäßen Neustart von RSVP)

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

• packets—Alle RSVP-Pakete

• path—Alle Pfad-Meldungen

• pathtear—PathTear-Nachrichten

• resv—Resv-Nachrichten

• resvtear—ResvTear-Nachrichten

• route—Routing-Informationen

• state– Sitzungsstatusübergänge, z. B. wenn RSVP-signalisierte LSPs hoch- und ausgehen.

Um die Protokolldatei anzuzeigen, die generiert wird, wenn Sie RSVP-Ablaufverfolgungsoptionen aktivieren, geben Sie den Befehl where is the file is the file you where the file you specified with the statement (wo sich die Datei befindet, die Sie mit der Anweisung angegeben haben) ein.show log file-namefile-nametraceoptions

Allgemeine Informationen zu Tracing und globalen Tracing-Optionen finden Sie in der Junos OS Routing Protocols Library for Routing Devices.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-routing/index.html

Der ordnungsgemäße RSVP-Neustart ermöglicht es einem Router, der einen Neustart durchläuft, seine benachbarten Nachbarn über seinen Zustand zu informieren. Der neu startende Router fordert eine Kulanzzeit vom Nachbarn oder Peer an, der dann mit dem neu startenden Router zusammenarbeiten kann. Der neu startende Router kann während des Neustartzeitraums weiterhin MPLS-Datenverkehr weiterleiten. Die Konvergenz im Netzwerk wird nicht unterbrochen. Der Neustart ist für den Rest des Netzwerks nicht sichtbar, und der neu startende Router wird nicht aus der Netzwerktopologie entfernt. Der ordnungsgemäße RSVP-Neustart kann sowohl auf Transitroutern als auch auf Eingangsroutern aktiviert werden. Es ist sowohl für Punkt-zu-Punkt-LSPs als auch für Punkt-zu-Mehrpunkt-LSPs verfügbar.

Der ordnungsgemäße RSVP-Neustart wird in den folgenden Abschnitten beschrieben:

• RSVP Graceful Restart Standard

• Terminologie für RSVP Graceful Restart

• RSVP Graceful-Restart

• Verarbeiten des Restart Cap-Objekts

Damit der ordnungsgemäße RSVP-Neustart funktioniert, muss die Funktion auf der globalen Routing-Instanz aktiviert sein. Der ordnungsgemäße Neustart von RSVP kann auf Protokollebene (nur für RSVP) oder auf globaler Ebene für alle Protokolle deaktiviert werden.

Der ordnungsgemäße RSVP-Neustart erfordert Folgendes eines neu startenden Routers und der Nachbarn des Routers:

• Für den neu startenden Router versucht RSVP Graceful Restart, die von RSVP installierten Routen und die zugewiesenen Bezeichnungen beizubehalten, damit der Datenverkehr weiterhin ohne Unterbrechung weitergeleitet wird. Der ordnungsgemäße Neustart von RSVP erfolgt schnell genug, um die Auswirkungen auf benachbarte Knoten zu verringern oder zu beseitigen.

• Die benachbarten Router müssen den RSVP-Hilfsmodus für einen ordnungsgemäßen Neustart aktiviert haben, damit sie einen Router unterstützen können, der versucht, RSVP neu zu starten.

Ein Objekt mit dem Namen "Restart Cap", das in RSVP-Hello-Nachrichten gesendet wird, kündigt die Neustartfunktion eines Knotens an. Der benachbarte Knoten sendet ein Recover Label-Objekt an den neu startenden Knoten, um seinen Weiterleitungsstatus wiederherzustellen. Bei diesem Objekt handelt es sich im Wesentlichen um die alte Bezeichnung, die der neu startende Knoten angekündigt hat, bevor der Knoten ausfiel.

Im Folgenden sind die Verhaltensweisen für einen ordnungsgemäßen RSVP-Neustart aufgeführt, die je nach Konfiguration und aktivierten Features variieren:

• Wenn Sie den Hilfsmodus deaktivieren, versucht das Junos-Betriebssystem nicht, einem Nachbarn beim Neustart der RSVP zu helfen. Alle Informationen, die mit einem Restart Cap-Objekt von einem Nachbarn eingehen, werden ignoriert.

• Wenn Sie den ordnungsgemäßen Neustart unter der Routing-Instance-Konfiguration aktivieren, kann der Router mithilfe seiner Nachbarn ordnungsgemäß neu gestartet werden. RSVP kündigt ein Restart Cap-Objekt (RSVP RESTART) in Hallonachrichten an, in denen Neustart- und Wiederherstellungszeiten angegeben sind (keiner der Werte ist 0).

• Wenn Sie den ordnungsgemäßen RSVP-Neustart auf der Hierarchieebene explizit deaktivieren, wird das Objekt "Neustartobergrenze" mit den Neustart- und Wiederherstellungszeiten angekündigt, die als 0 angegeben sind. 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.[protocols rsvp]

• Wenn RSVP nach einem Neustart feststellt, dass kein Weiterleitungsstatus beibehalten wurde, wird das Restart Cap-Objekt mit den Neustart- und Wiederherstellungszeiten angekündigt, die mit 0 angegeben sind.

• Wenn der ordnungsgemäße Neustart und der Hilfsmodus deaktiviert sind, ist der ordnungsgemäße RSVP-Neustart vollständig deaktiviert. Der Router erkennt die RSVP-Objekte für einen ordnungsgemäßen Neustart weder noch kündigt er sie an.

Sie können die Werte für die Neustart- und Wiederherstellungszeiten nicht explizit konfigurieren.

Im Gegensatz zu anderen Protokollen gibt es für RSVP keine andere Möglichkeit festzustellen, ob ein Neustartvorgang abgeschlossen wurde, außer einer festen Zeitüberschreitung. Alle RSVP-Vorgänge für einen ordnungsgemäßen Neustart sind zeitgeberbasiert. Ein Befehl kann darauf hinweisen, dass der Neustart auch dann noch ausgeführt wird, wenn alle RSVP-Sitzungen gesichert sind und die Routen wiederhergestellt wurden.show rsvp version

Die folgenden Annahmen werden in Bezug auf einen Nachbarn basierend auf dem Objekt "Restart Cap" getroffen (unter der Annahme, dass ein Steuerkanalausfall eindeutig von einem Neustart des Knotens unterschieden werden kann):

• Ein Nachbar, der das Restart Cap-Objekt nicht in seinen Hallo-Nachrichten ankündigt, kann einen Router weder bei der Wiederherstellung des Status oder der Bezeichnung unterstützen, noch kann er einen ordnungsgemäßen RSVP-Neustart durchführen.

• Nach einem Neustart hat ein Nachbar, der ein Restart Cap-Objekt mit einer Neustartzeit gleich einem beliebigen Wert und einer Wiederherstellungszeit gleich 0 ankündigt, seinen Weiterleitungsstatus nicht beibehalten. Wenn eine Wiederherstellungszeit gleich 0 ist, gilt der Nachbar als tot, und alle Zustände, die sich auf diesen Nachbarn beziehen, 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ündigt, den Weiterleitungsstatus beibehalten oder hat ihn beibehalten. Wenn der lokale Router seinen Nachbarn bei Neustart- oder Wiederherstellungsvorgängen unterstützt, sendet er ein Recover Label-Objekt an diesen Nachbarn.

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

• Sowohl der ordnungsgemäße Neustart als auch der Hilfsmodus sind aktiviert (Standardeinstellung).

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

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

• Sowohl der ordnungsgemäße Neustart als auch der Hilfsmodus sind deaktiviert. Mit dieser Konfiguration wird der ordnungsgemäße RSVP-Neustart (einschließlich Neustart- und Wiederherstellungsverfahren und Hilfsmodus) vollständig deaktiviert. Der Router verhält sich wie ein Router, der den ordnungsgemäßen RSVP-Neustart nicht unterstützt.

In den folgenden Abschnitten wird beschrieben, wie Sie den ordnungsgemäßen RSVP-Neustart konfigurieren:

• Aktivieren eines ordnungsgemäßen Neustarts für alle Routing-Protokolle
• Deaktivieren des ordnungsgemäßen Neustarts für RSVP
• Deaktivieren des RSVP-Hilfsmodus
• Konfigurieren der maximalen Wiederherstellungszeit für Helfer
• Konfigurieren der maximalen Neustartzeit des Hilfsprogramms

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

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

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

Durch die Weiterleitungsnachbarschaft wird ein getunnelter Pfad zum Senden von Daten zwischen Peer-Geräten in einem RSVP-LSP-Netzwerk erstellt. Sobald ein Forwarding Adjacency LSP (FA-LSP) eingerichtet wurde, können andere LSPs über den FA-LSP gesendet werden, indem Constrained Shortest Path First (CSPF), Link Management Protocol (LMP), Open Shortest Path First (OSPF) und RSVP verwendet werden.

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

• LMP: LMP wurde ursprünglich für GMPLS entwickelt und stellt Weiterleitungsverbindungen 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 weiterzuleiten, die sich auf eine physische Schnittstellenkarte (PIC) beziehen. Dieses Protokoll wurde erweitert, um Pakete an virtuelle Peer-Schnittstellen weiterzuleiten, 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 Einrichtung von Pfaden für Paket-LSPs anzufordern, die zu virtuellen Peer-Schnittstellen übertragen werden, 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 Router-Instanztypen 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 für mehrere Instanzen bietet die Flexibilität, die Entitäten auf der Steuerungsebene, die instanzbewusst sein müssen, auszuwählen, z. B. kann ein Router an mehreren TE-Instanzen teilnehmen, während weiterhin eine einzige BGP-Instanz ausgeführt wird.

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

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

  • Sicherstellen der LSP-Data-Plane-Bereitschaft während der LSP-Resignalisierung, bevor der Datenverkehr den LSP mit dem RSVP-TE LSP-Selfping-Mechanismus durchläuft.

    Ein Sprachdienstleister sollte nur dann mit der Übertragung von Datenverkehr beginnen, wenn bekannt ist, dass er in der Datenebene programmiert wurde. Der Datenaustausch in der LSP-Datenebene, z. B. LSP-Ping-Anforderungen, erfolgt am Eingangsrouter, bevor der Datenverkehr an einen LSP oder seine MBB-Instanz weitergeleitet wird. In großen Netzwerken kann dieser Datenverkehr einen LSP-Ausgangsrouter überfordern, da der Ausgangs-LSP auf die LSP-Ping-Anforderungen antworten 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 Empfang dieser Nachrichten leitet der Ausgangs-LER sie an den Eingang weiter, was die Lebendigkeit der LSP-Datenebene anzeigt. Dadurch wird sichergestellt, dass der LSP erst dann mit der Übertragung des Datenverkehrs beginnt, wenn die Datenebene programmiert wurde.

  • Entfernen des aktuellen harten Limits von 64K LSPs auf einem Eingangsrouter und Skalieren der Gesamtzahl der LSPs mit RSVP-TE-signalisierten LSPs. Pro Ausgang können bis zu 64 KB LSPs konfiguriert werden. Früher war dieser Grenzwert die aggregierte Anzahl von LSPs, die für den Eingangs-LER konfiguriert werden konnten.

  • Verhindern eines abrupten Herunterbrechens von LSPs durch den Eingangsrouter aufgrund von Verzögerungen bei der Signalisierung des LSP an den Transitroutern.

  • Ermöglichung einer flexiblen Ansicht von LSP-Datensätzen, um die Visualisierung von LSP-Merkmalsdaten zu erleichtern.

  HINWEIS:

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

Für LSP-Hierarchien gelten die folgenden Einschränkungen:

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

• Ein ordnungsgemäßer Neustart wird nicht unterstützt.

• Der Verbindungsschutz ist für FA-LSPs oder am Ausgangspunkt der Weiterleitungsnachbarschaft nicht verfügbar.

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

Abbildung 5: RSVP-LSP-Tunneltopologiediagramm

Abbildung 5 zeigt eine aufgerufene End-to-End-RSVP-LSP an, die auf Router 0 beginnt und auf Router 5 endet. Während des Transports durchquert dieser LSP den FA-LSP .e2e_lsp_r0r5fa_lsp_r1r4 Der Rückgabepfad wird durch den End-to-End-RSVP-LSP dargestellt, der über den FA-LSP läuft.e2e_lsp_r5r0fa_lsp_r4r1

Konfigurieren Sie auf Router 0 den End-to-End-RSVP-LSP, der an Router 5 übertragen wird. Verwenden Sie einen strikten Pfad, der Router 1 und die LMP-Traffic-Engineering-Verbindung von Router 1 zu Router 4 durchquert.

Router 0

Konfigurieren Sie auf Router 1 einen FA-LSP so, dass Router 4 erreicht wird. Stellen Sie eine LMP-Traffic-Engineering-Verbindung und eine LMP-Peer-Beziehung mit Router 4 her. Verweisen Sie im Traffic Engineering-Link auf den FA-LSP, und fügen Sie die Peerschnittstelle sowohl in OSPF als auch in RSVP hinzu.

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

Router 1

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

Router 2

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

Router 3

Konfigurieren Sie auf Router 4 einen Rückkanal FA-LSP, um Router 1 zu erreichen. Stellen Sie eine LMP-Traffic-Engineering-Verbindung und eine LMP-Peer-Beziehung mit Router 1 her. Verweisen Sie im Traffic Engineering-Link auf den FA-LSP, und fügen Sie die Peerschnittstelle sowohl in OSPF als auch in 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 Datenverkehr an Router 5 weiterleiten. Stellen Sie sicher, dass Sie OSPF zwischen Router 4 und Router 5 korrekt konfigurieren.

Router 4

Konfigurieren Sie auf Router 5 den End-to-End-RSVP-LSP des Rückgabepfads, der zu Router 0 geleitet wird. Verwenden Sie einen strikten Pfad, der Router 4 und die LMP-Traffic-Engineering-Verbindung von Router 4 zu Router 1 durchquert.

Router 5