RSVP-Konfiguration

Um RSVP auf einer einzelnen Schnittstelle zu aktivieren, schließen Sie die rsvp Anweisung ein, und geben Sie die Schnittstelle mithilfe der interface Anweisung an. 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 all die interface-name Variable.

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 disable folgende Anweisung ein:

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 label-switched-path Anweisung auf Hierarchieebene [edit protocols mpls] verwenden. 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 [edit protocols mpls label-switched-path name] eingeführt haben.

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

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 policy-statement Anweisung wie folgt:

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 policy-statement in diesem Abschnitt gezeigte Anweisung für den Lastenausgleich pro Paket in die Konfiguration jedes Routers ein, an dem eine Umleitung stattfinden kann. Siehe auch 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 load-balance Anweisung mit der bandwidth folgenden Option ein:

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

• [edit protocols rsvp]

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

Beachten Sie die folgenden Informationen, wenn Sie die load-balance Anweisung verwenden:

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

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

• 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 RSVP-Statusaktualisierungsnachrichten. Der Standardwert für die Aktualisierungszeit (R) beträgt 1200 Sekunden oder 20 Minuten, wie in RFC 8370 empfohlen. Wenn Sie die set protocols rsvp no-enhanced-frr-bypass Anweisung konfigurieren, wird die Aktualisierungszeit auf 30 Sekunden festgelegt. Um die Synchronisierung von Aktualisierungsmeldungen im Netzwerk zu vermeiden, wird die Aktualisierungszeit für einen Status nach dem Zufallsprinzip auf einen Wert im Bereich von 0,5R und 1,5R festgelegt, wie in RFC 2205 angegeben.

  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 (keep-multiplier – 1) müssen aufeinanderfolgende Aktualisierungsmeldungen verloren gehen, bevor ein Reservierungsstatus gelöscht wird.

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

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

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 preemption Anweisung mit der aggressive Option ein:

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 preemption Anweisung mit der disabled folgenden Option ein:

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 preemption Anweisung mit der normal folgenden Option ein:

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 path-mtu folgende Anweisung ein:

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 explicit-null folgende Anweisung ein:

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 tunnel-services Anweisung konfigurieren. 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 devices Option für die tunnel-services Anweisung einfügen. Mit dieser devices Option können Sie festlegen, welche VT-Schnittstellen von RSVP verwendet werden sollen. Wenn Sie diese Option nicht konfigurieren, können alle VT-Schnittstellen verwendet werden, die dem Router zur Verfügung stehen.

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

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 interface Anweisung auch mit der all folgenden Option konfigurieren:

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

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

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 traceoptions angeben:

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

• 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 show log file-name Befehl where file-name is the file is the file you where the file you specified with the statement (wo sich die Datei befindet, die Sie mit der traceoptions Anweisung angegeben haben) ein.

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

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 [protocols rsvp] 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.

• 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 show rsvp version Befehl kann darauf hinweisen, dass der Neustart auch dann noch ausgeführt wird, wenn alle RSVP-Sitzungen gesichert sind und die Routen wiederhergestellt wurden.

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 e2e_lsp_r0r5 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 fa_lsp_r1r4. Der Rückgabepfad wird durch den End-to-End-RSVP-LSP e2e_lsp_r5r0 dargestellt, der über den FA-LSP fa_lsp_r4r1läuft.

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