Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RSVP-Konfiguration

Minimale RSVP-Konfiguration

Um RSVP auf einer einzigen Schnittstelle zu aktivieren, müssen Sie die Anweisung angeben und rsvp die Schnittstelle mithilfe der Anweisung interface angeben. Dies ist die minimale RSVP-Konfiguration. Alle anderen RSVP-Konfigurationserklärungen sind optional.

Sie können diese Anweisungen in den folgenden Hierarchieebenen enthalten:

  • [edit protocols]

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

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

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

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp interface interface-name ]

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

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 client of RSVP. Für die Bindung von Daten und RSVP MPLS Konfiguration ist keine zusätzliche Konfiguration erforderlich.

Sie können die MPLS für die Einrichtung von signalisierten Pfaden konfigurieren, indem Sie die Anweisung label-switched-path auf der [edit protocols mpls] Hierarchieebene verwenden. Jeder LSP übersetzt eine Anfrage an RSVP, um eine RSVP-Sitzung zu initiieren. Diese Anfrage wird über die interne Schnittstelle zwischen Label Switching und RSVP bestanden. Nach der Prüfung der Anforderungsinformationen, der Prüfung von RSVP-Zuständen und der Prüfung der lokalen Routing-Tabellen initiiert RSVP eine Sitzung für jeden LSP. Die Sitzung wird vom lokalen Router stammen und ist für das Ziel des LSP bestimmt.

Wenn eine RSVP-Sitzung erfolgreich erstellt wurde, wird der LSP entlang der von der RSVP-Sitzung erstellten Pfade eingerichtet. Wenn die RSVP-Sitzung ohne Erfolg ist, benachrichtigt RSVP MPLS seines Status. Es ist an der MPLS, Backup-Pfade zu initiieren oder den ursprünglichen Pfad erneut zu wiederholen.

Für das Weitergeben von Label-Switching-Signalisierungsinformationen unterstützt RSVP vier weitere Objekte: Label Request-Objekt, Label-Objekt, Explicit Route-Objekt und Record Route-Objekt. Damit ein LSP erfolgreich eingerichtet werden kann, müssen alle Router auf dem Pfad MPLS, RSVP und die vier Objekte unterstützen. Eines der vier Objekte ist das Record Route-Objekt nicht erforderlich.

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

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

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

  • Konfigurieren Sie die Router am Anfang des LSP.

Beispiel: RSVP- und MPLS

Im Folgenden wird eine Beispielkonfiguration für einen Router zu Beginn eines LSP gezeigt:

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

Konfigurieren von RSVP-Schnittstellen

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

Konfiguration von RSVP Refresh-Reduktion

Sie können die Einsparung von RSVP-Aktualisierungen an jeder Schnittstelle konfigurieren, indem Sie die folgenden Anweisungen in der Schnittstellenkonfiguration enthalten:

  • aggregate und reliable – Aktivierung aller RSVP-Aktualisierungsfunktionen: RSVP-Nachrichtenbündelung, RSVP-Nachrichten-ID, zuverlässige Nachrichtenbereitstellung und Zusammenfassungsaktualisierung.

    Um eine Aktualisierung der Einsparung und zuverlässigen Bereitstellung zu erhalten, müssen Sie die aggregate Anweisungen und Angaben reliable enthalten.

  • no-aggregate— Deaktivieren Sie die RSVP-Nachrichtenbündelung und die Zusammenfassungsaktualisierung.

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

Weitere Informationen zur Einsparung von RSVP-Aktualisierungen finden Sie unter RSVP Refresh Reduction.

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

Aber nicht alle Kombinationen zwischen zwei Nachbarn mit unterschiedlichen Aktualisierungs-Reduktionsfunktionen funktionieren richtig. Ein Router wird z. B. entweder mit der Anweisung und der Anweisung aggregateno-reliable oder mit den reliableno-aggregate Anweisungen konfiguriert. Wenn ein RSVP-Nachbar ein Summary Refresh-Objekt an diesen Router sendet, wird kein Fehler generiert, aber das Summary Refresh-Objekt kann nicht verarbeitet werden. Daher kann der RSVP-Zustände diesen Router auszeiten, wenn der Nachbar sich nur auf Summary Refresh zur Aktualisierung dieser RSVP-Zustände angewiesen hat.

Wir empfehlen, dass Sie die RSVP-Aktualisierungsreduzierung auf ähnliche Weise konfigurieren, sofern keine speziellen Anforderungen erfüllt werden.

Um alle RSVP-Aktualisierungsfunktionen an einer Schnittstelle zu ermöglichen, müssen Sie die Aussage aggregate beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp interface interface-name]

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

Um die RSVP-Nachrichtenbündelung und die Zusammenfassungsaktualisierung zu deaktivieren, müssen Sie die no-aggregate Anweisung beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp interface interface-name]

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

Um eine RSVP-Nachrichten-ID und zuverlässige Nachrichtenzustellung an einer Schnittstelle zu ermöglichen, müssen Sie die Aussage reliable beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [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 Aussage no-reliable ein:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp interface interface-name]

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

Ermittlung der Refresh-Reduktionsfunktion von RSVP-Nachbarn

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

  • Das vom Nachbarn angekündigte RR-Bit

  • Die lokale Konfiguration der RSVP-Aktualisierungsreduzierung

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

Um diese Informationen zu erhalten, können Sie einen Befehl show rsvp neighbor detail aus geben. Beispielausgabe:

Weitere Informationen zum show rsvp neighbor detail Befehl.

Konfigurieren des RSVP Hello Interval

RSVP überwacht den Status der Nachbarn (IS-IS oder OSPF) des Interior Gateway Protocol (IGP) und vertraut auf die IGP-Protokolle, um zu erkennen, wenn ein Knoten ausfällt. Wenn ein IGP-Protokoll einen Nachbarn herunter erklärt (weil Hello-Pakete nicht mehr empfangen werden), setzt RSVP diesen Nachbarn ebenfalls aus. Bei der Einrichtung eines IGP und RSVP agieren die Protokolle und RSVP jedoch immer noch unabhängig.

Für Juniper Networks-Router hat die Konfiguration eines kürzeren oder längeren RSVP-Hello-Intervalls keine Auswirkungen darauf, ob eine RSVP-Sitzung beendet wird oder nicht. RSVP-Sitzungen werden auch dann beibehalten, wenn RSVP-Hello-Pakete nicht mehr empfangen werden. RSVP-Sitzungen werden so lange aufrechterhalten, bis der Router IGP oder der RSVP-Pfad und die Resv-Nachrichten nicht mehr empfangen werden. Ab Version Junos OS 16.1 werden jedoch die RSVP-Sitzungen gestartet, wenn die Time-out von RSVP-Nachrichten gestartet wird.

Das RSVP-Hello-Intervall kann sich auch auswirken, wenn die Ausrüstung eines anderen Herstellers eine RSVP-Sitzung beendet. Beispielsweise kann ein benachbarter nicht-Juniper Networks-Router für die Überwachung von RSVP Hello-Paketen konfiguriert werden.

Um zu ändern, wie oft RSVP Hello-Pakete sendet, geben Sie die Aussage hello-interval an:

Eine Liste von Hierarchieebenen, in denen Sie diese Aussage enthalten können, finden Sie im Abschnitt "Statement Summary".

Konfigurieren der RSVP-Authentifizierung

Alle RSVP-Protokollwechsel 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 Hashed Message Authentication Code (HWP)-MD5 message-basierten Digest. Dieses Schema erzeugt eine Message Digest, die auf einem geheimen Authentifizierungsschlüssel und den Nachrichteninhalten basiert. (Der Nachrichteninhalt enthält auch eine Folgenummer.) Der Rechner wird mit RSVP-Nachrichten übertragen. Sobald Sie die Authentifizierung konfiguriert haben, werden alle empfangenen und übertragenen RSVP-Nachrichten mit allen Nachbarn an dieser Schnittstelle authentifiziert.

Die MD5-Authentifizierung bietet Schutz vor Forgery- und Nachrichtenmodifikation. Es kann auch Replay-Angriffe verhindern. Dies macht jedoch keine Vertraulichkeit, da alle Nachrichten im klartext gesendet werden.

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

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp interface interface-name]

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

Konfigurieren des Bandbreitenabonnements für Klassentypen

Standardmäßig ermöglicht RSVP die Verwendung von 100 Prozent der Bandbreite für einen Klassentyp für RSVP-Reservierungen. Wenn Sie einen Klassentyp für einen Multi-Class-LSP überlasten, ist der Gesamtbedarf aller RSVP-Sitzungen zulässig, die tatsächliche Kapazität des Klassentyps zu übersteigen.

Ausführliche Anweisungen zum Konfigurieren des Bandbreitenabonnements für Klassentypen finden Sie unter Konfigurieren des Prozentwerts für Bandbreitenabonnements für LSPs.

Konfigurieren des Grenzwerts für RSVP-Aktualisierungen an einer Schnittstelle

Die Interior Gateway Protocols (IGPs) pflegen die Traffic Engineering-Datenbank, aber die aktuelle verfügbare Bandbreite der Traffic Engineering-Datenbankverbindungen stammt von RSVP. Wenn sich die Bandbreite einer Verbindung ändert, informiert RSVP die IGPs, die dann die Traffic Engineering-Datenbank aktualisieren und die neuen Bandbreiteninformationen an alle Netzwerkknoten weitergeleitet 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 richtig berechnet.

Wenn IGP Updates jedoch überschätzen, werden die Ressourcen des Systems stark überzogen. Je nach Anzahl der Knoten in einem Netzwerk ist es möglicherweise nicht wünschenswert, ein Update der IGP für kleine Bandbreitenänderungen durchzuführen. Indem Sie die Anweisung in der Hierarchieebene konfigurieren, können Sie den Schwellenwert anpassen, an dem eine Änderung der reservierten Bandbreite ein Update IGP update-threshold[edit protocols rsvp] wird.

Sie können einen Wert von 0,001 bis 20 Prozent (Standardmäßig 10 Prozent) konfigurieren, um zu wann ein IGP wird. Wenn die Änderung der reservierten Bandbreite den konfigurierten Grenzwert der statischen Bandbreite an dieser Schnittstelle übersteigt oder gleich ist, erfolgt eine IGP Aktualisierung. Wenn Sie die Anweisung beispielsweise auf 15 Prozent konfiguriert haben und der Router festgestellt hat, dass die reservierte Bandbreite einer Verbindung um 10 Prozent der Linkbandbreite geändert wurde, löst RSVP kein Aktualisierung von update-threshold IGP aus. Wenn sich die reservierte Bandbreite einer Verbindung jedoch um 20 Prozent der Linkbandbreite ändert, löst RSVP ein IGP aus.

Sie können den Grenzwert auch als absoluten Wert konfigurieren. Verwenden Sie dazu die threshold-value Option in der update-threshold Aussage.

Wenn der Grenzwert auf mehr als 20 % der Bandbreite dieser Verbindung konfiguriert wird, wird der Grenzwert bei 20 % der Bandbreite überschritten.

Wenn beispielsweise die Bandbreite auf einer Schnittstelle 1 Gbit/s beträgt und über 200Mbit/s konfiguriert ist, liegt der Wert bei threshold-valuethreshold-value 200Mbit/s. Der Grenzwert wird als 20,000 % und der als threshold-value 200 Mbps angezeigt.

Anmerkung:

Die beiden Optionen "Threshold", "Threshold Percent" und threshold-value "," stehen gegenseitig nicht zur Verfügung. Sie können zu einem bestimmten Zeitpunkt nur eine Option konfigurieren, um ein Aktualisierungs-IGP für Reservierungen mit niedrigerer Bandbreite zu generieren. Wenn Sie daher eine Option konfigurieren, wird die andere Option berechnet und auf der CLI.

Wenn beispielsweise der Grenzwert auf 5 % konfiguriert ist, wird auf einer Verbindung von 1 Gbit/s der Wert auf threshold-value 50 Mbps berechnet und angezeigt. Wenn die Konfiguration auf 50 m konfiguriert ist, wird der Grenzwert ebenfalls mit threshold-value 5 % berechnet und angezeigt.

Um den Schwellenwert anzupassen, an dem eine Änderung der reservierten Bandbreite ein Update IGP, fügen Sie die Aktualisierungs-Grenzwertserklärung bei. Aufgrund des Update-Grenzwerts ist es möglich, dass Constrained Shortest Path First (CSPF) einen Pfad aus veralteten Daten der Traffic Engineering-Datenbank auf einem Link berechnet. Wenn RSVP versucht, einen LSP über diesen Pfad zu erstellen, wird möglicherweise feststellen, dass die Bandbreite der Verbindung nicht ausreichend ist. In diesem Fall löst RSVP eine Aktualisierung IGP Traffic Engineering-Datenbank aus und überflutet die aktualisierten Bandbreiteninformationen im Netzwerk. CSPF kann dann den Pfad mithilfe der aktualisierten Bandbreiteninformationen neu komputen und versuchen, einen anderen Pfad zu finden, um die überlastete Verbindung zu vermeiden. Beachten Sie, dass diese Funktion standardmäßig ist und keine zusätzliche Konfiguration benötigt.

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

Konfigurieren von RSVP für Nichtnummerierte Schnittstellen

Der Junos OS unterstützt das RSVP Traffic Engineering über nichtnummerierte Schnittstellen. Traffic Engineering-Informationen über nicht in unternummerierte Links werden in den IGP Traffic Engineering Erweiterungen für OSPF und IS-IS gemäß RFC 4203, OSPF Extensions zur Unterstützung von Generalized Multi-Protocol Label Switching (GMPLS)und RFC 4205, Intermediate System to Intermediate System (IS-IS) Erweiterungen zur Unterstützung von GENERALIZED Multi-Protocol Label Switching (GMPLS)durchgeführt. Nicht innummerierte Links können in der MPLS-Traffic Engineering-Signalübertragung wie in RFC 3477 beschrieben, Signalling Unnumbered Links im Resource ReSerVation Protocol – Traffic Engineering (RSVP-TE)angegeben werden. Mit dieser Funktion müssen Sie nicht mehr die IP-Adressen für jede Schnittstelle konfigurieren, die am RSVP-signalisierten Netzwerk beteiligt ist.

Zur Konfiguration von RSVP für nicht innummerierte Schnittstellen muss der Router mit der in der Hierarchieebene angegebenen Anweisung mit einer Router-ID router-id[edit routing-options] konfiguriert werden. Die Router-ID muss für das Routing verfügbar sein (sie kann normalerweise die Loopback-Adresse verwenden). Die RSVP-Steuerungsmeldungen für die nicht innummerierten Links werden mithilfe der Router-ID-Adresse gesendet (anstelle einer zufällig ausgewählten Adresse).

Zum Konfigurieren des Verbindungsschutzes und schnellen Umleitens auf einem Router mit aktivierter Nicht-Nummer müssen Sie mindestens zwei Adressen konfigurieren. Es wird empfohlen, eine sekundäre Schnittstelle auf dem Loopback zu konfigurieren und nicht nur die Router-ID zu konfigurieren.

Konfigurieren von RSVP Node-ID Hellos

Sie können node-ID-basierte RSVP-Hellos konfigurieren, um sicherzustellen, dass Router Juniper Networks mit der Ausrüstung anderer Anbieter zusammenarbeiten können. Standardmäßig verwendet Junos OS schnittstellenbasierte RSVP Hellos. Node-ID-basierte RSVP-Hellos sind in RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) festgelegt Hello: Eine Klärungserklärung. RSVP Node-ID Hellos sind nützlich, wenn Sie BFD für die Erkennung von Problemen über RSVP-Schnittstellen konfiguriert haben, sodass Sie Schnittstellen-Hellos für diese Schnittstellen deaktivieren können. Sie können auch Node-ID-Hellos für graceful Restart-Verfahren verwenden.

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

Um RSVP Node-ID-Hellos global auf dem Router zu aktivieren, geben Sie die Node-Hello-Erklärung in den folgenden Hierarchieebenen ein:

  • [edit protocols rsvp]

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

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

Um RSVP-Schnittstellen-Hellos global auf dem Router zu deaktivieren, geben Sie die No-Interface-Hello-Anweisung in den folgenden Hierarchieebenen ein:

  • [edit protocols rsvp]

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

Beispiel: Konfigurieren von LSPs mit RSVP-Signalen

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

Anforderungen

Löschen Sie Sicherheitsservices auf dem Gerät, bevor Sie beginnen. Siehe Beispiel: Löschen von Sicherheitsdiensten.

Überblick und Topologie

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

Topologie

Abbildung 1: Typischer LSP mit RSVP-SignalTypischer LSP mit RSVP-Signal

Um einen LSP zwischen Routern zu erstellen, müssen Sie die MPLS familie einzeln aktivieren und RSVP auf jeder der Transitschnittstellen im Netzwerk MPLS konfigurieren. In diesem Beispiel wird gezeigt, wie MPLS und RSVP auf der Ge-0/0/0-Transitschnittstelle konfiguriert werden können. Außerdem müssen Sie den MPLS auf allen Schnittstellen MPLS Netzwerk aktivieren.

In diesem Beispiel wird gezeigt, wie ein LSP von R1 zu R7 auf dem Ingress-Router (R1) unter Verwendung der Loopback-Adresse von R7 (10.0.9.7) definiert wird. Die Konfiguration reserviert 10 Mbit/s Bandbreite. Darüber hinaus deaktiviert die Konfiguration den CSPF-Algorithmus und sorgt dafür, dass Hosts C1 und C2 den RSVP-signalisierten LSP verwenden, der dem kürzesten Pfad des Netzwerks IGP entspricht.

Konfiguration

Verfahren

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.

Schritt-für-Schritt-Verfahren

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

So konfigurieren Sie RSVP:

  1. Aktivieren Sie MPLS auf allen Transitschnittstellen im Netzwerk MPLS Netzwerk.

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

  3. Aktivieren Sie den MPLS auf der Transitschnittstelle im Netzwerk MPLS Netzwerk.

  4. Definieren Sie den LSP auf dem Ingress-Router.

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

Ergebnisse

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

Diese Befehlsausgabe enthält in Kürze nur show die Konfiguration, die für dieses Beispiel relevant ist. Alle anderen Konfigurationen auf dem System wurden durch Ellipsen ersetzt (...).

Wenn Sie die Konfiguration des Geräts bereits durchgeführt haben, geben Sie commit sie im Konfigurationsmodus ein.

Überprüfung

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

RSVP-Nachbarn überprüfen

Zweck

Stellen Sie sicher, dass auf jedem Gerät die entsprechenden RSVP-Nachbarn angezeigt werden – z. B. dass Router R1 in Router R3 und Router R2 als Abbildung 1 RSVP-Nachbarn auflistet.

Aktion

Geben Sie CLI den Befehl im Befehl show rsvp neighbor ein.

Die Ausgabe zeigt die IP-Adressen der benachbarten Router. Stellen Sie sicher, dass jede benachbarte RSVP-Router-Loopback-Adresse aufgelistet 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 Bandbreitenreservierungswert aktiv ist.

Aktion

Geben Sie CLI den Befehl im Befehl show rsvp session detail 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:

  • Jeder RSVP-Nachbaradresse hat einen Eintrag für jeden Nachbarn, der durch die Loopback-Adresse aufgelistet ist.

  • Der Status jeder LSP-Sitzung Up ist.

  • Für Tspec wird der entsprechende Bandbreitenwert 10Mbps angezeigt.

Prüfung von LSPs mit RSVP-Signalen

Zweck

Stellen Sie sicher, dass die Routingtabelle des Eingangsrouters über einen konfigurierten LSP zur Loopback-Adresse des anderen Routers verfügt. Stellen Sie beispielsweise sicher, dass die Routingtabelle des R1-Eingangsrouters über einen konfigurierten LSP zur Loopback-Adresse von inet.3Abbildung 1 Router R7 verfügt.

Aktion

Geben Sie CLI den Befehl im Befehl show route table inet.3 ein.

Die Ausgabe zeigt die RSVP-Routen, die in der inet.3 Routingtabelle vorhanden sind. Stellen Sie sicher MPLS, dass ein LSP mit RSVP-Signal im Netzwerk mit der Loopback-Adresse des Ausgangsrouters R7 verknüpft ist.

Beispiel: Konfiguration von RSVP Automatic Mesh

Service Provider verwenden häufig BGP- MPLS VPNs, um das Netzwerk effizient zu skalieren und gleichzeitig umsatzgenerierende Services zu bieten. In diesen Umgebungen wird BGP zur Verteilung der VPN-Routinginformationen über das Netzwerk des Dienstanbieters verwendet, während MPLS verwendet wird, um diesen VPN-Datenverkehr von einem VPN-Standort an einen anderen zu weiterleiten.

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

Die Konfigurationsanforderungen für BGP-Peering können mit der Verwendung von Route Reflectors reduziert werden. In RSVP-signalisierten MPLS Netzwerken kann das automatische RSVP-Mesh die Konfigurationslast für den MPLS Teil des Netzwerks minimieren. Durch die Konfiguration auf allen PE-Routern kann RSVP automatisch die erforderlichen LSPs erstellen, wenn rsvp-te ein neuer PE-Router hinzugefügt wird.

Anforderungen

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

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

  • Ein BGP- MPLS-VPN mit RSVP als LSP-Signalisierungsprotokoll (Label MPLS Switched Path).

Überblick

In diesem Beispiel wird gezeigt, wie die Konfiguration des automatischen RSVP-Mesh auf einem PE-Router mithilfe der rsvp-te Konfigurationserklärung erfolgt. Damit das automatische RSVP-Mesh ordnungsgemäß funktioniert, müssen alle PE-Router im Netzwerk Full-Mesh-Konfiguration Anweisung rsvp-te konfiguriert sein. So wird sichergestellt, dass alle neuen PE-Router, die später hinzugefügt werden, auch von der automatischen Mesh-Funktion profitieren, vorausgesetzt, dass sie mit der Anweisung konfiguriert rsvp-te sind.

In diesem Beispiel wird nur die Konfiguration auf dem neu hinzugefügten PE-Router gezeigt. Es wird davon ausgegangen, dass für die vorhandenen PE-Router bereits ein automatisches RSVP-Mesh konfiguriert wurde.

Topologie

In der Topologie gibt es drei Abbildung 2 PE-Router, PE1, PE2 und PE3. PE4 wurde hinzugefügt und RSVP-automatisches Mesh wird konfiguriert. Die Cloud stellt das Netzwerk der Service Provider dar, und die Netzwerkadresse 192.0.2.0/24 ist im Zentrum der Abbildung dargestellt.

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

Konfiguration

Die Konfiguration des automatischen RSVP-Mesh umfasst die Durchführung dieser Aufgaben:

  • Ermöglicht die rsvp-te Konfiguration auf der [edit routing-options dynamic-tunnels dynamic-tunnel-name] Hierarchieebene.

  • Das erforderliche Element destination-networks konfigurieren.

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

  • Das erforderliche Element label-switched-path-template konfigurieren.

    Für dieses Konfigurationselement wird entweder default-template der Name einer vorkonfigurierten LSP-Vorlage als Argument verwendet. Dies default-template ist eine systemdefinierte Vorlage, die keine Benutzerkonfiguration erfordert.

CLI-Konfiguration

Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] ein.

PE4-Router

Konfiguration von RSVP Automatic Mesh

Schritt-für-Schritt-Verfahren

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

Um ein automatisches RSVP-Mesh zu ermöglichen:

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

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

Ergebnisse

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

Überprüfung

Sicherstellen der Existenz von RSVP-automatischen Mesh-Tunneln auf Router-PE4

Zweck

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

Aktion

Sicherstellen der Existenz von MPLS LSPs auf Router-PE4

Zweck

Geben Sie den Befehl aus dem Betriebsmodus aus, um die Existenz MPLS LSPs auf dem PE4-Router show mpls lsp zu prüfen. Dieser Befehl zeigt den Status der LSPs MPLS an.

Aktion

Konfigurieren von Hello Acknowledgments für nonsenssession RSVP-Nachbarn

Die hello-acknowledgements Aussage steuert das Hello-Acknowledgment-Verhalten zwischen RSVP-Nachbarn, unabhängig davon, ob sie sich in der gleichen Sitzung befinden oder nicht.

Hallo Nachrichten, die von RSVP-Nachbarn empfangen wurden, die nicht Teil einer gemeinsamen RSVP-Sitzung sind, werden verworfen. Wenn Sie die Anweisung in der Hierarchieebene konfigurieren, werden Hello-Nachrichten von nicht sessionen Nachbarn mit einer hello-acknowledgements[edit protocols rsvp] Hello-Acknowledgment-Nachricht anerkennt. Wenn hallos von singfreien Nachbarn empfangen werden, wird eine RSVP-Nachbarbeziehung erstellt und regelmäßige Hello-Nachrichten können nun von einem leidenschaftsfreien Nachbarn empfangen werden. Die hello-acknowledgements Aussage ist standardmäßig deaktiviert. Die Konfiguration dieser Anweisung ermöglicht das Entdecken RSVP-fähiger Router mithilfe von Hello-Paketen und überprüft, ob die Schnittstelle RSVP-Pakete empfangen kann, bevor sie alle LSP-MPLS-Einrichtungsmeldungen senden.

Sobald Sie Hello-Bestätigungen für singfreie RSVP-Nachbarn aktivieren, erkennt der Router weiterhin Hello-Nachrichten von anderen singungsfreien RSVP-Nachbarn, es sei denn, die Schnittstelle selbst wird aus dem Weg gehen oder Sie ändern die Konfiguration. Schnittstellenbasierte Nachbarn werden nicht automatisch auf andere Lösungen zugreifen.

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp]

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

Switching-LSPs Weg von einem Netzwerkknoten

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

  1. Zunächst müssen Sie den Link- oder Node-Schutz für den Datenverkehr konfigurieren, der das zu deaktivierende Netzwerkgerät passieren muss. Um ordnungsgemäß zu funktionieren, muss der Bypass-LSP eine andere logische Schnittstelle verwenden als der geschützte LSP.
  2. Konfigurieren Sie die Anweisung, um den Router so vorzubereiten, dass er mit dem Switching des Datenverkehrs weg vom Netzwerkknoten always-mark-connection-protection-tlv beginnt:

    Der Router markiert dann den ganzen OAM-Datenverkehr, der diese Schnittstelle durchfährt, um den Datenverkehr basierend auf der OAM-Funktion auf einen alternativen Pfad umzuschalten.

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

    • [edit protocols mpls interface interface-name]

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

  3. Diese Anweisung muss so konfiguriert werden, dass der Datenverkehr vom geschützten LSP auf den Bypass-LSP umgestellt wird, um das standardmäßige, switch-away-lsps nachgeschaltete Netzwerkgerät effektiv zu umgehen. Die tatsächliche Verbindung selbst wird durch diese Konfiguration nicht ausgefahren.

    Konfigurieren Sie die Anweisung, um den Router so zu konfigurieren, dass der Datenverkehr weg von einem Netzwerkknoten umgeschaltet switch-away-lsps wird:

    Sie können diese Anweisung in 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 beim Switching aktiver LSPs vom Netzwerkknoten:

  • Die Switch-away-Funktion wird nur von Routern der MX-Serie unterstützt.

  • Die Switch-away-Funktion wird nicht unterstützt, um den Switching-Datenverkehr von primären Point-to-Multipoint-LSPs zu umgehen, um Point-to-Multipoint-LSPs zu umgehen. Wenn Sie die Anweisung für einen Point-to-Multipoint LSP konfigurieren, wird der Datenverkehr nicht auf den switch-away-lsps Bypass-Point-to-Multipoint-LSP umgeschaltet.

  • Wenn Sie die Switch-Away-Funktion auf einer Schnittstelle auf dem Weg zu einem dynamischen LSP konfigurieren, können keine neuen dynamischen LSPs über diesen Pfad eingerichtet werden. Die Switch-Away-Funktion verhindert das Make-Before-Break-Verhalten von LSPs mit RSVP-Signalen. Normalerweise versucht der Router, einen dynamischen LSP zu signalisieren, bevor er das Original wieder aufbricht.

Konfigurieren von RSVP-Einrichtungsschutz

Sie können den Facility-Backup Fast Reroute-Mechanismus konfigurieren, um Setup-Schutz für LSPs zu bieten, die sich im Prozess der Signalübertragung befinden. Es werden sowohl Punkt-zu-Punkt-LSPs als auch Point-to-Multipoint-LSPs unterstützt. Diese Funktion ist für folgende Szenarien anwendbar:

  1. Ein fehlerhafter Link oder Knoten ist auf dem strict Explicit Path eines LSP vorhanden, bevor der LSP signalisiert wird.

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

  3. RSVP signalisiert den LSP über den Bypass-LSP. Der LSP wirkt so, als ob er ursprünglich auf dem primären Pfad eingerichtet worden wäre und dann aufgrund des Links oder Knotenausfalls auf den Bypass-LSP übergeht.

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

Sie sollten die Anweisung auf jedem der Router entlang des LSP-Pfads konfigurieren, für den Sie den setup-protection[edit protocols rsvp] LSP-Einrichtungsschutz aktivieren möchten. Sie sollten auch IGP Traffic Engineering auf allen Routern im LSP-Pfad konfigurieren. Sie können einen Befehl ausführen, um zu bestimmen, ob der LSP über einen Setup-Schutz auf einem Router verfügt, der als Point of Local Repair (PLR) oder als Merge show rsvp session Point agiert.

Geben Sie die Anweisung an, um den RSVP-Einrichtungsschutz setup-protection zu aktivieren

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp]

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

Konfigurieren des Lastausgleichs über RSVP-LSPs

Wenn Sie standardmäßig mehrere RSVP-LSPs auf denselben Ausgangsrouter konfiguriert haben, wird der LSP mit der geringsten Kennzahl ausgewählt und transportiert den ganzen Datenverkehr. Wenn alle LSPs dieselbe Kennzahl haben, wird einer der LSPs nach dem Zufallsprinzip ausgewählt, und der ganze Datenverkehr wird darüber weitergeleitet.

Alternativ können Sie durch die Aktivierung eines Load Balancing pro Paket einen Load Balancing-Datenverkehr über alle LSPs hinweg ermöglichen.

Konfigurieren Sie die Anweisung wie folgt, um Load Balancing pro Paket auf einem ingress-LSP policy-statement zu aktivieren:

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

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

Sie müssen den Load Balancing pro Paket konfigurieren, wenn Sie PFE Fast Reroute aktivieren möchten. Um die schnelle Paket-Routen-Aktivierung zu ermöglichen, fügen Sie die Anweisung für das Load Balancing pro Paket in diesem Abschnitt in der Konfiguration der einzelnen Router ein, für die eine policy-statement Umleitung stattfinden könnte. Siehe auch Fast Reroute konfigurieren.

Darüber hinaus können Sie den Datenverkehr zwischen den LSPs proportional zur für den jeweiligen LSP konfigurierten Bandbreite ausgleichen. Diese Fähigkeit kann den Datenverkehr in Netzwerken mit asymmetrischen Bandbreitenfunktionen über externe Verbindungen besser verteilen, da die konfigurierte Bandbreite eines LSP in der Regel die Datenverkehrskapazität dieses LSP enthält.

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

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

  • [edit protocols rsvp]

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

Beachten Sie bei der Verwendung der Aussage die folgenden load-balance Informationen:

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

  • Die load-balance Aussage gilt nur für Ingress-LSPs, die über ein Load Balancing pro Paket verfügen.

  • Für differenzierte Dienste, die Traffic Engineered-LSPs nutzen, berechnet die Bandbreite eines LSP anhand der Bandbreite aller Klassentypen.

Konfiguration von RSVP Automatic Mesh

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

Anmerkung:

Sie können rsVP-automatisches Mesh nicht zusammen mit CCC konfigurieren. CCC kann die dynamisch generierten LSPs nicht nutzen.

Zum Konfigurieren des automatischen RSVP-Mesh müssen Sie die Aussage rsvp-te beinhalten:

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

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

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

Um ein automatisches RSVP-Mesh zu ermöglichen, müssen Sie auch die folgenden Anweisungen konfigurieren:

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

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

Konfigurieren von Timern für RSVP-Aktualisierungsmeldungen

RSVP verwendet zwei verwandte Zeitsteuerungsparameter:

  • refresh-time—Die Aktualisierungszeit steuert das Intervall zwischen der Erstellung der nachfolgenden Aktualisierungsmeldungen. Der Standardwert für die Aktualisierungszeit beträgt 45 Sekunden. Diese Nummer wird aus dem Standardwert der Aussage mit 30 abgeleitet, der mit einem festen Wert von refresh-time 1,5 multipliziert wird. Diese Berechnung unterscheidet sich von RFC 2205, in dem angegeben wird, dass die Aktualisierungszeit mit einem zufallsartigen Wert im Bereich von 0,5 bis 1,5 multipliziert werden sollte.

    Nachrichten werden mit Pfad- und Resv-Nachrichten aktualisiert. Nachrichten werden regelmäßig aktualisiert, damit die Reservierungszustände in den benachbarten Knoten nicht zu einem Time out führen. Jeder Pfad und jede Resv-Nachricht enthält den Refresh-Timer-Wert, und der empfangende Knoten extrahiert diesen Wert aus den Nachrichten.

  • keep-multiplier—Der Keep Multiplier ist eine kleine, lokal konfigurierte Ganzzahl von 1 bis 255. Der Standardwert ist 3. Er gibt die Anzahl an Nachrichten an, die verloren gehen können, bevor ein bestimmter Status als abverkauft erklärt wird, und die gelöscht werden müssen. Der Keep Multiplier 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 nachfolgende Aktualisierungsmeldungen verloren gehen, keep-multiplier bevor ein Reservierungsstatus gelöscht wird.

Wir empfehlen nicht, einen kurzen RSVP Hello Timer zu konfigurieren. Wenn Sie einen fehlerhaften Nachbarn schnell finden möchten, konfigurieren Sie IGP kurze IGP (OSPF oder IS-IS) Hello Timer.

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

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [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 Aussage keep-multiplier hinzu:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp]

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

RsVP-Sitzungen vorab

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

Um eine Sitzung bei unzureichender Bandbreite stets vorher zu nutzen, geben Sie preemption die Aussage mit der Option aggressive an:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp]

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

Um die RSVP-Sitzungsvorbehaltung zu deaktivieren, schließen Sie die preemption Anweisung mit der Option disabled ein:

Um zu dem Standard zurückzukehren (d. h. eine Sitzung nur für eine neue Sitzung mit höherer Priorität voreingestellt) müssen Sie die preemption Anweisung mit der Option normal beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp]

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

Konfigurieren MTU Signalübertragung in RSVP

Um die MTU (MTU) Signalübertragung in RSVP zu konfigurieren, müssen Sie MPLS konfigurieren, damit IP-Pakete fragmentiert werden können, bevor sie in einem Paket verkapselt MPLS. Sie müssen auch die Signalübertragung MTU RSVP konfigurieren. Zur Fehlerbehebung können Sie die Signalübertragung MTU, ohne die Paketfragmentierung zu aktivieren.

Um die MTU-Signalübertragung in RSVP zu konfigurieren, müssen Sie die Aussage path-mtu beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

In den folgenden Abschnitten wird beschrieben, wie die Paketfragmentierung und MTU in RSVP ermöglicht wird:

Ermöglichung MTU-Signalübertragung in RSVP

Um die MTU in RSVP zu aktivieren, müssen Sie die Aussage rsvp mtu-signaling beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls path-mtu]

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

Sobald Sie die Konfiguration vorgenommen haben, treten bei der nächsten Aktualisierung des Pfads Änderungen MTU Signalverhalten für RSVP in Kraft.

Sie können die mtu-signaling Anweisung selbst in der [edit protocols mpls path-mtu rsvp] Hierarchieebene konfigurieren. Dies kann zur Fehlerbehebung nützlich sein. Wenn Sie nur die Anweisung konfigurieren, können Sie mit dem Befehl bestimmen, was die MTU Daten mtu-signalingshow rsvp session detail auf einem LSP ist. Der show rsvp session detail Befehl zeigt den empfangenen MTU und an das Adspec-Objekt gesendeten Wert an.

Ermöglichen der Paketfragmentierung

Um IP-Pakete zu fragmentieren, bevor sie in eine andere Umgebung eingekapselt MPLS, müssen Sie die Aussage allow-fragmentation beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls path-mtu]

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

    Anmerkung:

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

Konfigurieren von Ultimate-Hop-Popping für LSPs

Standardmäßig verwenden LSPs mit RSVP-Signalen das Penultimate-Hop-Popping (PHP).Abbildung 3 zeigt einen vorletzten LSP (Popping-Hop) zwischen Router PE1 und Router-PE2. Router CE1 weitergeleitet ein Paket an seinen nächsten Hop (Router PE1), bei dem es sich auch um den LSP-Ingress handelt. Router PE1 pusht Label 1 im Paket und weitergeleitet das gekennzeichnete Paket an Router P1. Router P1 schließt den Standardbetrieb MPLS Label Swapping ab, austauscht Label 1 für Label 2 und weitergeleitet das Paket an Router P2. Da der Router P2 der vorletzte Hop-Router für den LSP an Router PE2 ist, wird das Label zuerst aus dem Pop-and-Pop-Label und dann an Router PE2 weitergeleitet. Wenn Router-PE2 diesen empfängt, kann das Paket über ein Service-Label, ein Explicit-Null-Label oder einfach ein Nur-IP- oder VPLS-Paket sein. Router PE2 weitergeleitet das nicht gekennzeichnete Paket an Router CE2.

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

Sie können auch Ultimate-Hop-Popping (UHP)(wie in sehen) für Abbildung 4 LSPs mit RSVP-Signal konfigurieren. Für einige Netzwerkanwendungen kann es erforderlich sein, dass Pakete mit einem äußeren Nicht-Null-Label am Egress Router (Router PE2) eintreffen. Für den ultimativen Hop-Popping-LSP führt der vorletzte Router (Router P2 in) den standardmäßigen MPLS Label Swapping-Vorgang (in diesem Beispiel Label 2 für Label 3) aus, bevor das Paket an den Abbildung 4 Egress Router PE2 gesendet wird. Router-PE2 erscheint im äußeren Label und führt eine zweite Suche der Paketadresse durch, um das Endziel zu bestimmen. Und weitergeleitet das Paket dann an das entsprechende Ziel (entweder Router CE2 oder Router CE4).

Abbildung 4: Ultimate-Hop-Popping für einen LSPUltimate-Hop-Popping für einen LSP

Die folgenden Netzwerkanwendungen erfordern die Konfiguration von OHNP-LSPs:

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

  • Virtuelle Circuits zum Edge-Schutz

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

  • LSPs mit LDP-Signalen

  • Statische LSPs

  • Point-to-Multipoint-LSPs

  • CCC

  • traceroute Befehl

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

Bei punkt-zu-Punkt-RSVP-signalisierten LSPs wird das UHP-Verhalten vom LSP-Ingress signalisiert. Basierend auf der Ingress-Routerkonfiguration kann RSVP den UHP LSP mit dem nicht-PHP-Flag-Set signalisieren. RSVP-PFAD-Nachrichten tragen die beiden Flags im LSP-ATTRIBUTES-Objekt. Wenn der Ausgangsrouter die PATH-Nachricht empfängt, weist er dem LSP ein Non-Null-Label zu. RSVP erstellt und installiert außerdem zwei Routen in der mpls.0-Routingtabelle. S bezieht sich auf den S-Bit des MPLS-Labels, der angibt, ob der untere Bereich 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 führt zur mpls.0-Routingtabelle und löst eine verkettete MPLS-Label-Suche aus, um die verbleibenden MPLS im Stack zu entdecken.

  • Route S=1: Gibt an, dass keine Label mehr enthalten sind. Der nächste Hop weist auf die Inet.0-Routingtabelle zu, wenn die Plattform eine verkettete und mehrfamilienfamilienbasierte Suche unterstützt. Alternativ kann die Labelroute auch 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 erklärt, welchen Einfluss die UHP-LSPs auf die verschiedenen Arten von MPLS haben:

  • Layer 2-VPNs und Layer-2-Circuits: Ein Paket kommt mit zwei Labeln am PE-Router (Egress des UHP LSP) an. Das äußere Label (S=0) ist das UHP-Label und das innere Label (S=1) das VC-Label. Eine auf dem Transport-Label basierende Suche führt zu einem Tabellen-Handle für die mpls.0-Routingtabelle. In der mpls.0-Routingtabelle gibt es eine weitere Route, die dem inneren Label entspricht. Eine Suche basierend auf dem inneren Label führt im CE-Router zum nächsten Hop.

  • Layer 3-VPN: Ein Paket kommt mit zwei Labeln am PE-Router (Egress des UHP LSP) an. Das äußere Label (S=0) ist das UHP-Label und das innere Label das VPN-Label (S=1). Eine Suche basierend auf dem Transport-Label führt im Tabellen-Handle für die mpls.0-Routingtabelle. In diesem Szenario gibt es zwei Fälle: Standardmäßig geben Layer 3-VPNs das Label pro Next Hop an. Eine Suche basierend auf dem inneren Label führt im nächsten Hop in Richtung Router CE Router. Wenn Sie die Anweisung für die Layer-3-VPN-Routinginstanz konfiguriert haben, weist das inner vrf-table-labelLSI-Label auf die VRF-Routingtabelle hin. Außerdem wird eine IP-Suche für die VRF-Routingtabelle abgeschlossen.

    Anmerkung:

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

  • VPLS: Ein Paket kommt mit zwei Labeln am PE-Router (Egress des UHP LSP) an. Das äußere Label ist das Transport-Label (S=0), und das innene Label ist das VPLS-Label (S=1). Eine Suche basierend auf dem Transport-Label führt im Tabellen-Handle für die mpls.0-Routingtabelle. Eine Suche basierend auf dem inneren Label in mpls.0-Routingtabelle führt zur LSI-Tunnelschnittstelle der VPLS-Routinginstanz, wenn Tunnel-Dienste nicht konfiguriert sind (oder eine VT-Schnittstelle nicht verfügbar ist). Router der MX 3D-Serie unterstützen eine verkettete Suche und Die Suche nach mehreren Familien.

    Anmerkung:

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

  • IPv4 über MPLS: Ein Paket kommt mit einem Label (S=1) am PE-Router (Egress des UHP LSP) an. Eine auf diesem Label basierende Suche gibt eine VT-Tunnelschnittstelle zurück. An der VT-Schnittstelle wird eine weitere IP-Suche durchgeführt, um zu bestimmen, wo das Paket weitergeleitet werden soll. Wenn die Routing-Plattform Suchreihen mit mehreren Produktfamilien und Verkettungsverkettungen unterstützt (z. B. Mx 3D-Router und Paketübertragungs-Router der PTX-Serie), dann ist eine Suche basierend auf Label Route (S=1) zur Inet.0-Routingtabelle erforderlich.

  • IPv6-over-MPLS: Beim IPv6-Tunneling über MPLS geben PE-Router IPv6-Routen mit einem Label-Wert von 2 an. Dies ist das explizite Null-Label für IPv6. Daher werden für die Weiterleitung der nächsten Hops für IPv6-Routen, die von Remote-PE-Routern gelernt werden, normalerweise zwei Labels pusht. Das innene Label ist 2 (es könnte anders sein, wenn der PE-Router der Werbe-PE von einem anderen Anbieter ist), und das Router-Label ist das LSP-Label. Pakete landen am PE-Router (Ausgangs-des UHP-LSP) mit zwei Labeln. Das äußere Label ist das Transport-Label (S=0), und das innene Label ist das IPv6 Explicit-Null-Label (Label 2). Die Suche basiert auf dem inneren Label in der mpls.0-Routingtabelle und leitet zurück zur mpls.0-Routingtabelle um. Auf Routern der MX 3D-Serie wird das inner Label (Label 2) entfernt und mithilfe der Inet6.0-Routingtabelle wird eine IPv6-Suche durchgeführt.

  • Dank PHP und UHP-LSPs können Sie sowohl PHP- als auch UHP-LSPs über die gleichen Netzwerkpfade konfigurieren. Sie können den PHP- und UHP-Datenverkehr trennen, indem Sie die LSP-Weiterleitungs-Next-Hops mit einem regelmäßigen Ausdruck mit der Anweisung install-nexthop auswählen. Sie können den Datenverkehr auch trennen, indem Sie die LSPs einfach entsprechend benennen.

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

  1. Um ultimatives Hop-Popping zu ermöglichen, müssen Sie die ultimate-hop-popping Anweisung beinhalten:

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

    Anmerkung:

    Wenn Sie Ultimate-Hop-Popping aktivieren, versucht RSVP, vorhandene LSPs nach einem Make-Before-Break als Ultimate-Hop-Popping-LSPs neu zu besignalen. Wenn ein Ausgangsrouter keinen Ultimate-Hop-Popping unterstützt, wird der vorhandene LSP heruntergefahren (RSVP sendet eine PathTear-Nachricht über einen LSP-Pfad, entfernt den Pfadstatus und den abhängigen Reservierungsstatus und gibt die zugehörigen Netzwerkressourcen frei).

    Wenn Sie Ultimate-Hop-Popping deaktivieren, gibt RSVP vorhandene LSPs als Penultimate-Hop-Popping-LSPs make-before-break neu.

  2. Wenn Sie sowohl Ultimate-Hop-Popping als auch Verkettung der nächsten Hops nur auf Routern der MX 3D-Serie aktivieren möchten, müssen Sie auch die Option für die enhanced-ip Anweisung network-services konfigurieren:

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

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

Sie können den auf dem Egress-Router eines LSP angegebenen Labelwert kontrollieren. Das standardmäßig angekündigte Label ist Label 3 (implizites Null-Label). Wenn Label 3 angekündigt ist, entfernt der Router penultimate-hop das Label und sendet das Paket an den Egress-Router. Wenn das Popping des ultimativen Hops aktiviert ist, wird Label 0 (IP-Version 4 [IPv4] Explicit Null-Label) angekündigt. Beim Ultimate Hop-Popping wird sichergestellt, dass alle Pakete, die in einem Netzwerk MPLS, ein Label enthalten.

Anmerkung:

Juniper Networks-Router Warteschlangenpakete basierend auf dem eingehenden Label. Router von anderen Anbietern können Pakete in eine andere Warteschlange stellen. Berücksichtigen Sie dies bei der Arbeit mit Netzwerken, die Router von verschiedenen Anbietern enthalten.

Zur Konfiguration von Ultimate-Hop-Popping für RSVP müssen Sie die Aussage explicit-null beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

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

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

Standardmäßig wird für Point-to-Point- und Point-to-Multipoint-LSPs penultimate Hop-Popping für den MPLS verwendet. MPLS werden direkt vor dem Ausgangsrouter des LSP aus den Paketen auf dem Router entfernt. Die Nur-IP-Pakete werden dann an den Egress-Router weitergeleitet. Beim Ultimate-Hop-Popping ist der Egress-Router verantwortlich sowohl dafür, das Label MPLS zu entfernen als auch das Nur-IP-Paket zu verarbeiten.

Die Aktivierung von Ultimate-Hop-Popping auf Point-to-Multipoint-LSPs ist nützlich, insbesondere wenn der Transitdatenverkehr dasselbe Ausgangsgerät durchquert. Wenn Sie Ultimate-Hop-Popping aktivieren, kann eine einzige Kopie des Datenverkehrs über die eingehende Verbindung gesendet werden, was erhebliche Bandbreite spart. Standardmäßig ist das Popping im ultimativen Hop deaktiviert.

Sie aktivieren ultimaten Hop-Popping für Point-to-Multipoint-LSPs durch Konfiguration der tunnel-services Anweisung. Wenn Sie Ultimate-Hop-Popping aktivieren, wählt der Junos OS eine der verfügbaren virtuellen Loopback-Tunnel-Schnittstellen (VT) aus, um die Pakete zur IP-Weiterleitung wieder an das PFE zu senden. Standardmäßig wird der VT-Schnittstellenauswahlprozess automatisch ausgeführt. Mit Bandbreitensteuerung wird die Anzahl der LSPs, die an einer VT-Schnittstelle verwendet werden können, limitiert. Sobald die ganze Bandbreite an einer Schnittstelle verbraucht ist, wählt Junos OS eine andere VT-Schnittstelle mit ausreichend Bandbreite für die Zugangssteuerung.

Wenn ein LSP mehr Bandbreite erfordert, als über eine der VT-Schnittstellen verfügbar ist, kann ultimate-Hop-Popping nicht aktiviert werden und das Popultimate-Hop-Popping ist stattdessen aktiviert.

Damit der Ultimate-Hop-Popping auf Point-to-Multipoint-LSPs ordnungsgemäß funktioniert, muss der Egress-Router über eine PIC verfügen, die Tunneldienste wie die Tunneldienste-PIC oder die PIC für adaptive Dienste bietet. Tunneldienste sind erforderlich, um das MPLS Label zu poppingen und Pakete für IP-Adressensuchen zu senden.

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

Konfigurieren Sie die Anweisung, um ultimatives Hop-Popping für die Egress Point-to-Multipoint-LSPs auf einem Router tunnel-services zu ermöglichen:

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

  • [edit protocols rsvp]

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

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

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

Tracing RSVP-Protokolldatenverkehr

Um den RSVP-Protokolldatenverkehr zu verfolgen, müssen Sie die Aussage traceoptions beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols rsvp]

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

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

Verwenden Sie file die Anweisung, um den Namen der Datei anzugeben, die die Ausgabe des Ablaufverfolgungsbetriebs erhält. Alle Dateien werden in das Verzeichnis /var/log platziert. Es wird empfohlen, die RSVP-Tracing-Ausgabe in der Datei zu rsvp-log platzieren.

  • all— Alle Ablaufverfolgungsvorgänge.

  • error— Alle erkannten Fehlerbedingungen

  • event— RSVP-bezogene Ereignisse (hilft bei der Nachverfolgung von Ereignissen in Bezug auf 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— Übergänge im Sitzungsstatus, auch bei Einem- und Abstieg von RSVP-signalisierten LSPs.

Anmerkung:

Verwenden Sie all das Trace-Flag und den Flag-Modifizierer aus Vorsicht, da die CPU dadurch detail sehr ausgelastet sein könnte.

Geben Sie den Befehl aus, und zeigen Sie die Protokolldatei an, die generiert wird, wenn Sie RSVP Traceoptions aktivieren. Geben Sie den Befehl aus und geben Sie die angegebene Datei show log file-namefile-name mithilfe der Anweisung traceoptions an.

Allgemeine Informationen zur Ablaufverfolgung und globalen Tracing-Optionen finden Sie in der Junos OS Routing Protocols Library für Routinggeräte.

Beispiele: Tracing RSVP-Protokolldatenverkehr

Trace RSVP-Pfadmeldungen im Detail:

Verfolgen Sie alle RSVP-Nachrichten:

Verfolgen Sie alle RSVP-Fehlerbedingungen:

Trace RSVP-Statuswechsel:

RSVP-Protokolldateiausgabe

Im Folgenden sehen Sie eine Beispielausgabe, die durch die Ausgabe des Befehls auf einem Router generiert wird, auf dem RSVP-Traceoptions mit der konfigurierten Flag show log file-namestate aktiviert wurden. Der LSP E-D mit RSVP-Signal wird am Mar 11 14:04:36.707092 abgerissen. Am 11. März 14:05:30.101492 ist es wieder da.

RSVP Graceful Restart

RsVP graceful Restart ermöglicht einem Router einen Neustart, um seine benachbarten Nachbarn über seinen Zustand zu informieren. Der neu gestartete Router fordert eine Schonfrist von dem Nachbarn oder Peer an, der dann beim Neustart-Router zusammenarbeiten kann. Der neu gestartete Router kann den Datenverkehr MPLS Neustartzeitraum weiterhin weitergeleitet werden. die Konvergenz im Netzwerk nicht unterbrochen wird. Der Neustart wird für den Rest des Netzwerks nicht sichtbar, und der neu gestartete Router wird nicht aus der Netzwerktopologie entfernt. RSVP Graceful Restart kann sowohl auf Transitroutern als auch Ingress-Routern aktiviert werden. Er 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 beträgt 60.000 Millisekunden (1 Minute). Die Neustartzeit wird in der Hello-Nachricht angegeben. Die Zeit gibt an, wie lange ein Nachbar warten sollte, um eine Hello-Nachricht von einem Neustart-Router zu erhalten, bevor er den Router erklärt und den Zustände entfernt.

Die Junos OS kann die angekündigte Neustartzeit eines Nachbarn außer Kraft setzen, wenn die Zeit größer ist als ein Drittel der lokalen Neustartzeit. Ein Router warten beispielsweise 20 Sekunden oder weniger, um eine Hello-Nachricht eines neu gestarteten Nachbarn zu erhalten. Wenn die Neustartzeit bei Null liegt, kann der neu gestartete Nachbar sofort als tot erklärt werden.

Wiederherstellungszeit (in Millisekunden)

Gilt nur, wenn der Steuerungskanal verfügbar ist (der Hello-Exchange ist abgeschlossen) vor dem Neustart. Wendet sich nur auf nodale Fehler an.

Wenn ein graceful-Neustart in Arbeit ist, wird die Zeit angegeben, die zum Abschließen einer Wiederherstellung bleibt. Zum anderen liegt dieser Wert bei Null. Die maximal angekündigte Wiederherstellungszeit beträgt 2 Minuten (120.000 Millisekunden).

Während der Wiederherstellungszeit versucht ein neu gestarteter Knoten, seinen verlorenenZustände mitHilfe seiner Nachbarn wiederherstellung zu finden. Der Nachbar des neu gestarteten Knotens muss die Pfadmeldungen mit den Wiederherstellungslabeln innerhalb eines Zeitraums von einer Hälfte der Wiederherstellungszeit an den neu gestarteten Knoten senden. Der neu gestartete Knoten berücksichtigt den graceful-Neustart nach der angekündigten Wiederherstellungszeit als abgeschlossen.

RSVP Graceful Restart-Vorgang

Damit RSVP graceful Restart funktioniert, muss die Funktion auf der globalen Routinginstanz aktiviert sein. RSVP Graceful Restart kann auf Protokollebene (nur für RSVP) oder auf der globalen Ebene für alle Protokolle deaktiviert werden.

RsVP Graceful Restart erfordert das Folgende von einem Neustart des Routers und den Nachbarn des Routers:

  • Beim Neustart des Routers versucht RSVP graceful Restart, die von RSVP und den zugewiesenen Labels installierten Routen zu pflegen, sodass der Datenverkehr ohne Unterbrechung weiter weitergeleitet wird. RsVP Graceful Restart wird schnell genug durchgeführt, um die Auswirkungen auf die benachbarten Knoten zu reduzieren oder zu eliminieren.

  • Die benachbarten Router müssen den RSVP Graceful Restart Helper Mode aktiviert haben, damit sie einen Router beim Neustart von RSVP unterstützen können.

Ein Objekt namens Restart Cap, das in RSVP -Hello-Nachrichten gesendet wird, gibt die Neustartfunktion eines Knotens an. Der benachbarte Knoten sendet ein Recover Label-Objekt an den neu gestarteten Knoten, um den Weiterleitungsstatus wiederhergestellt zu haben. Dieses Objekt ist im Wesentlichen das alte Label, das der neu gestartete Knoten angekündigt hat, bevor der Knoten ausgelaufen ist.

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

  • Wenn Sie den Hilfsmodus deaktivieren, versucht der Junos OS nicht, einen Nachbar neu zu starten RSVP. Alle Informationen, die mit einem Restart Cap-Objekt eines Nachbarn eintreffen, werden ignoriert.

  • Wenn Sie unter der Konfiguration der Routinginstanz den graceful-Neustart aktivieren, kann der Router mithilfe seiner Nachbarn den Router einfach neu starten. RSVP gibt ein Restart Cap-Objekt (RSVP RESTART) in Hello-Nachrichten an, in denen Neustart- und Wiederherstellungszeiten angegeben werden (beide Werte sind 0).

  • Wenn Sie den RSVP-Graceful-Neustart unter der Hierarchieebene explizit deaktivieren, wird das Restart Cap-Objekt mit Neustart- und Wiederherstellungszeiten angekündigt, die als [protocols rsvp] 0 angegeben sind. Es wird der Neustart benachbarter Router unterstützt (sofern der Hilfsmodus nicht deaktiviert ist). Der Router selbst kann den RSVP-Weiterleitungsstatus jedoch nicht wiederherstellen und kann den Steuerungsstatus nicht wiederherstellen.

  • Wenn bei rsVP nach einem Neustart festgestellt wird, dass kein Weiterleitungsstatus beibehalten wurde, wird das Restart Cap-Objekt mit Neustarts und wiederherstellungszeiten angekündigt, die als 0 angegeben sind.

  • Wenn der Graceful-Restart- und der Hilfsmodus deaktiviert sind, ist der graceful-Restart von RSVP vollständig deaktiviert. Der Router erkennt und startet die RSVP-Objekte beim Neustart weder neu, noch gibt er sie an.

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

Im Gegensatz zu anderen Protokollen kann RSVP nicht feststellen, dass ein Neustartvorgang abgeschlossen wurde (ab hinaus von einem festen Timeout). Alle RSVP Graceful Restart-Verfahren sind Timer-basiert. Ein Befehl kann angeben, dass der Neustart immer noch ausgeführt wird, selbst wenn alle RSVP-Sitzungen wiederhergestellt sind und show rsvp version die Routen wiederhergestellt sind.

Verarbeitung des Cap-Restart-Objekts

Es werden folgende Annahmen über einen Nachbarn auf der Basis des Restart Cap-Objekts gemacht (es wird vorausgesetzt, dass ein Kontrollkanalfehler eindeutig von einem Knotenneustart eindeutig unterschieden werden kann):

  • Ein Nachbar, der das Restart Cap-Objekt in seinen Hello-Nachrichten nicht anknifft, kann einem Router nicht den Status oder die Label-Wiederherstellung unterstützen oder einen rsVP-graceful-Neustart durchführen.

  • Nach einem Neustart gibt ein Nachbar ein Restart-Cap-Objekt mit einem Neustartzeit gleich einem beliebigen Wert und einer Wiederherstellungszeit, die gleich 0 ist, den Weiterleitungsstatus nicht beibehalten. Wenn eine Wiederherstellungszeit 0 entspricht, gilt der Nachbar als tot, und alle Zustände in Bezug auf diesen Nachbar werden unabhängig von dem Wert der Neustartzeit gelöscht.

  • Nach einem Neustart kann ein Nachbar die Wiederherstellungszeit mit einem anderen Wert als 0 beibehalten oder den Weiterleitungsstatus beibehalten. Wenn der lokale Router beim Neustart oder bei der Wiederherstellung beim Nachbar hilft, sendet er ein Recover Label-Objekt an diesen Nachbarn.

RsVP Graceful Restart konfigurieren

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

  • Der Graceful-Restart- und der Hilfsmodus sind beide aktiviert (Standard).

  • Der Graceful-Restart ist aktiviert, der Hilfsmodus ist jedoch deaktiviert. Ein auf diese Weise konfigurierter Router kann einfach neu gestartet werden, kann aber einem Nachbarn beim Neustart und den Wiederherstellungsverfahren nicht helfen.

  • Der Graceful-Restart ist deaktiviert, der Hilfsmodus ist jedoch aktiviert. Ein auf diese Weise konfigurierter Router kann nicht ohne Systemneustart starten, kann aber beim Neustart des Nachbars helfen.

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

Anmerkung:

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

In den folgenden Abschnitten wird die Konfiguration von RSVP Graceful Restart beschrieben:

Aktivierung von Graceful Restart für alle Routingprotokolle

Um den Graceful-Restart für RSVP zu aktivieren, müssen Sie den Graceful-Restart für alle Protokolle aktivieren, die den graceful-Restart auf dem Router unterstützen. Weitere Informationen zum Neustart der Anwendung finden Sie in der Junos OS Routingprotokollbibliothek für Routinggeräte.

Um den Graceful-Restart auf dem Router zu aktivieren, müssen Sie die graceful-restart Anweisung beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit routing-options]

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

Graceful Restart für RSVP deaktivieren

Standardmäßig sind RSVP Graceful Restart und RSVP Helper Mode aktiviert, wenn Sie den Graceful Restart aktivieren. Sie können jedoch eine oder beide Funktionen deaktivieren.

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

RSVP-Hilfsmodus deaktivieren

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

Konfigurieren der maximalen Hilfewiederherstellungszeit

Um die Zeit zu konfigurieren, in der der Router den Status seiner RSVP-Nachbarn bei einem graceful-Neustart beibehalten kann, fügen Sie die Anweisung maximum-helper-recovery-time auf der [edit protocols rsvp graceful-restart] Hierarchieebene ein. Dieser Wert wird auf alle benachbarten Router angewendet und sollte daher auf die Zeit beruhen, die der langsamste RSVP-Nachbar zum Wiederherstellen benötigt.

Konfigurieren der maximalen Helper-Restart-Zeit

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

RSVP LSP-Tunnel im Überblick

Ein RSVP-Label-Switched Path (LSP)-Tunnel (Resource Reservation Protocol) ermöglicht es Ihnen, RSVP-LSPs innerhalb anderer RSVP-LSPs zu senden. So kann ein Netzwerkadministrator Traffic-Engineering von einem Netzwerkende zum anderen bereitstellen. Eine nützliche Anwendung für diese Funktion ist das Verbinden von Kunden-Edge-Routern (CE) mit Provider Edge-Routern (PE) durch Verwendung eines RSVP LSP. Diese Edge-LSP wird dann in ein zweites RSVP LSP in den Netzwerkkern getunnelt.

Sie sollten sich über allgemeine Kenntnisse zu den Konzepten MPLS Label Switching verfügen. Weitere Informationen über diese MPLS finden Sie im Konfigurationshandbuch MPLS Junos- und Anwendungskonfiguration.

Ein RSVP-LSP-Tunnel fügt das Konzept der Weiterleitungsanjacency hinzu, ähnlich wie bei allgemeinem MPLS (Multiprotocol Label Switching) (GMPLS). (Weitere Informationen zu GMPLS finden Sie im Junos GMPLS-Benutzerhandbuch.

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

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

  • LMP – LMP wurde ursprünglich für GMPLS entwickelt und stellt Weiterleitungsanbindungen 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 routen, die mit einer Physical Interface Card (PIC) verbunden sind. Dieses Protokoll wurde erweitert, um Pakete an virtuelle Peer-Schnittstellen zu routen, 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 an virtuellen Peer-Schnittstellen zu beantragen, die in einer LMP-Konfiguration definiert sind.

    Anmerkung:

    Ab Version Junos OS 15.1 wird die Multi-Instance-Unterstützung auf RSVP-MPLS TE erweitert. Diese Unterstützung ist nur für den Typ virtueller Routerinstanzen verfügbar. Ein Router kann mehrere unabhängige Topologiepartitionen erstellen TE beteiligt werden, wodurch jeder TE Domain unabhängig skaliert werden kann. Multi-Instance RSVP-TE bietet die Flexibilität, die Instanzen der Steuerungsebene zu wählen, die instanzsensiert sein müssen. So kann ein Router beispielsweise in mehreren TE-Instanzen teilnehmen, während gleichzeitig gleichzeitig eine einzelne BGP-Instanz ausgeführt wird.

    Die Junos OS von MPLS RSVP-TE wurde skaliert, um die Verwendbarkeit, Sichtbarkeit, Konfiguration und Fehlerbehebung von LSPs im Skalieren Junos OS Version 16.1.

    Diese Erweiterungen vereinfachen die RSVP-TE-Konfiguration um:

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

      Ein LSP sollte den Datenverkehr nur dann weiter tragen, wenn bekannt ist, dass er auf der Datenebene programmiert wurde. Der Datenaustausch auf der LSP-Datenebene, z. B. LSP-Ping-Anforderungen, erfolgt am Ingress-Router, bevor der Datenverkehr zu einem LSP oder einer MBB-Instanz wechselt. In großen Netzwerken kann dieser Datenverkehr einen LSP-Egress-Router überlasten, da der egress LSP auf die LSP-Ping-Anforderungen reagieren muss. Der Selbst-Ping-Mechanismus des LSP ermöglicht dem Ingress-LER, LSP-Ping-Antwortmeldungen zu erstellen und diese über die LSP-Datenebene zu senden. Nachdem er diese Nachrichten erhalten hat, überträgt der Egress-LER diese an den Eingang und gibt die Lebensadern der LSP-Datenebene an. Auf diese Weise wird sichergestellt, dass der LSP den Datenverkehr nicht mehr weiter trägt, bevor die Datenebene programmiert wurde.

    • Entfernen der aktuellen Festgrenze von 64.000 LSPs auf einem Ingress-Router und Skalierung der gesamten Anzahl von LSPs mit RSVP-TE LSPs. Pro Ausgangsbasis können bis zu 64.000 LSPs konfiguriert werden. Diese Begrenzung war zuvor die aggregierte Anzahl von LSPs, die auf dem Ingress-LER konfiguriert werden konnte.

    • Verhindern des Abbruchs von LSPs durch den Ingress-Router aufgrund einer Verzögerung bei der Signalübertragung des LSP an den Transitroutern.

    • Ermöglicht eine flexible Ansicht der LSP-Datensätze, um die charakteristische LSP-Datenvisualisierung zu unterstützen.

    Anmerkung:

    Beginnend mit Junos OS Version 17.4 wird ein Standard-Timer von 1800 Sekunden für Self-Ping eingeführt.

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

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

  • Graceful-Restart wird nicht unterstützt.

  • Für FA-LSPs oder am Egress-Punkt der Weiterleitungs adjacency ist kein Verbindungsschutz verfügbar.

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

Beispiel: RSVP LSP Tunnelkonfiguration

Abbildung 5: RSVP LSP Tunnel-TopologiediagrammRSVP LSP Tunnel-Topologiediagramm

Abbildung 5zeigt einen End-to-End-RSVP-LSP (LSP), der von Router 0 stammt und e2e_lsp_r0r5 auf Router 5 endet. Bei der Übertragung durchläuft dieser LSP den FA-LSP. fa_lsp_r1r4 Der Rückpfad wird von dem End-to-End-RSVP LSP dargestellt, der über e2e_lsp_r5r0 den FA-LSP fa_lsp_r4r1 reist.

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

Router 0

Konfigurieren Sie auf Router 1 einen FA-LSP, um Router 4 zu erreichen. Richten Sie eine LMP-Traffic-Engineering-Verbindung und eine LMP-Peer-Beziehung mit Router 4 ein. Referenz auf FA-LSP in der Traffic Engineering-Verbindung und Hinzufügen der Peer-Schnittstelle sowohl OSPF als auch RSVP.

Wenn der End-to-End-LSP des Rückpfads an Router 1 ankommt, führt die Routing-Plattform eine Routingsuche durch und kann den Datenverkehr an Router 0 weiterleiten. Stellen Sie sicher, dass OSPF zwischen Router 0 und 1 richtig konfiguriert sind.

Router 1

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

Router 2

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

Router 3

Konfigurieren Sie auf Router 4 einen FA-LSP-Rückpfad, um Router 1 zu erreichen. Richten Sie eine LMP-Traffic-Engineering-Verbindung und eine LMP-Peer-Beziehung mit Router 1 ein. Referenz auf FA-LSP in der Traffic Engineering-Verbindung und Hinzufügen der Peer-Schnittstelle sowohl OSPF als auch RSVP.

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

Router 4

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

Router 5

Überprüfung Ihrer Arbeit

Geben Sie die folgenden Befehle aus, um sicherzustellen, dass Ihr RSVP LSP-Tunnel richtig funktioniert:

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

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

Die im Konfigurationsbeispiel verwendeten Befehle finden Sie in den folgenden Abschnitten:

Router 0

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

Router 1

Stellen Sie auf Router 1 sicher, dass die Konfiguration Ihrer LMP-Verbindung zum Traffic Engineering funktioniert und dass der End-to-End-LSP den Traffic-Engineering-Link durch die Ausgabe der Befehlssatzdaten show link-management durchträgt. Sie können auch den Befehl show rsvp session extensive ausführen, um zu bestätigen, dass FA-LSP in Betrieb ist.

Konfigurieren von Peer-Schnittstellen in OSPF und RSVP

Nach der Einrichtung von LMP-Peers müssen Sie OSPF und RSVP Peer-Schnittstellen hinzufügen. Eine Peer-Schnittstelle ist eine virtuelle Schnittstelle zur Unterstützung der Steuerungsschnittstelle zwischen zwei Peers.

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

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

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

Einrichten von FA-LSP-Pfadinformationen

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

Anmerkung:

Wenn der End-to-End-LSP von derselben Routingplattform wie der FA-LSP stammt, müssen Sie CSPF deaktivieren und Strict-Paths verwenden.

Option: RSVP-LSPs gracefully abreißen

Sie können einen RSVP LSP in einem zweistufigen Prozess beenden, der die vom LSP verwendete RSVP-Sitzung z. B. zurückzieht. Für alle Nachbarn, die eine Graceful-Teardown unterstützen, wird eine Anforderung für den Teardown durch die Routingplattform zum Zielenpunkt des LSP und allen RSVP-Nachbarn auf dem Pfad gesendet. Die Anfrage ist im ADMIN_STATUS Feld des RSVP-Pakets enthalten. Wenn Nachbarn die Anfrage erhalten, bereiten sie sich auf die zurückgenommene RSVP-Sitzung vor. Eine zweite Nachricht wird von der Routing-Plattform gesendet, um die RSVP-Sitzung vollständig zu beenden. Wenn ein Nachbar keinen Graceful-Teardown unterstützt, wird die Anfrage nicht wie eine Graceful-Teardown-Sitzung, sondern als eine Graceful-Sitzung behandelt.

Geben Sie den Befehl aus, um eine RSVP-Sitzung graceful zu clear rsvp session gracefully beenden. Optional können Sie die Quell- und Zieladresse der RSVP-Sitzung, die LSP-Kennung des RSVP-Absenders und die Tunnelkennung der RSVP-Sitzung angeben. Um dieseQualifizierer zu verwenden, gehören die , und Optionen, wenn connection-source Sie den Befehl connection-destinationlsp-idtunnel-idclear rsvp session gracefully ausführen.

Sie können auch den Zeitraum konfigurieren, in dem die Routingplattform darauf wartet, dass die Nachbarn die Graceful-Teardown-Anforderung erhalten, bevor sie das tatsächliche Ende einleiten, indem Sie die Anweisung auf der graceful-deletion-timeout[edit protocols rsvp] Hierarchieebene einschlenden. Der Zeitout-Wert für die graceful-Löschung beträgt 30 Sekunden mit einem Minimalwert von 1 Sekunde und einem maximalen Wert von 300 Sekunden. Geben Sie den Betriebsmodusbefehl aus, um den aktuellen Wert für die Graceful-Deletion-Timeout show rsvp version anzeigen zu können.

Release-Verlaufstabelle
Release
Beschreibung
19.4R1
16.1
Ab Version Junos OS 16.1 werden jedoch die RSVP-Sitzungen gestartet, wenn die Time-out von RSVP-Nachrichten gestartet wird.