Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

Fehlerbehebung bei MPLS

MPLS-Schnittstellen verifizieren

Zweck

Wenn das MPLS-Protokoll auf den Routern in Ihrem Netzwerk nicht korrekt konfiguriert ist, können die Schnittstellen kein MPLS-Switching durchführen.

HINWEIS:

Damit eine beschriftete Route über eine Schnittstelle aufgelöst werden kann, muss sie auf Hierarchieebene [edit interfaces] konfiguriert werden, family mplsdamit die Route erfolgreich aufgelöst werden kann. Wenn die Schnittstelle nicht mit family mplskonfiguriert ist, werden beschriftete Routen nicht aufgelöst.

Action!

Um MPLS-Schnittstellen zu überprüfen, geben Sie den folgenden Befehl für den Betriebsmodus der Befehlszeilenschnittstelle (CLI) von Junos OS ein:

Beispielausgabe 1

Befehlsname

Die folgende Beispielausgabe gilt für alle Router im Netzwerk, die in MPLS-Netzwerktopologieangezeigt werden.

Beispielausgabe 2

Befehlsname

Beispielausgabe 3

Befehlsname

Bedeutung

Beispielausgabe 1 zeigt, dass alle MPLS-Schnittstellen auf allen Routern im Netzwerk aktiviert sind (Up) und MPLS-Switching durchführen können. Wenn Sie es versäumen, die richtige Schnittstelle auf der Hierarchieebene [edit protocols mpls] zu konfigurieren oder die family mpls Anweisung auf der Hierarchieebene [edit interfaces type-fpc/pic/port unit number ] einzufügen, kann die Schnittstelle keine MPLS-Umschaltung ausführen und wird nicht in der Ausgabe für den show mpls interface Befehl angezeigt.

Administrative Gruppen sind auf keiner der Schnittstellen konfiguriert, die im Beispielnetzwerk in MPLS-Netzwerktopologiegezeigt werden. Wenn dies jedoch der Fall wäre, würde die Ausgabe angeben, welche Affinitätsklassenbits auf dem Router aktiviert sind.

Beispielausgabe 2 zeigt, dass die Schnittstelle so-0/0/2.0 fehlt und daher möglicherweise falsch konfiguriert ist. Beispielsweise ist die Schnittstelle möglicherweise nicht auf der Hierarchieebene [edit protocols mpls] enthalten, oder die family mpls Anweisung ist möglicherweise nicht auf der Hierarchieebene [edit interfaces type-fpc/pic/port unit number] enthalten. Wenn die Schnittstelle korrekt konfiguriert ist, hat RSVP möglicherweise noch keine Signale über diese Schnittstelle gesendet. Weitere Informationen zum Ermitteln der falsch konfigurierten Schnittstelle finden Sie unter Überprüfen von Protokollfamilien.

Beispielausgabe 3 zeigt, dass das MPLS-Protokoll nicht auf der Hierarchieebene [edit protocols mpls] konfiguriert ist.

Protokollfamilien verifizieren

Zweck

Wenn für eine logische Schnittstelle MPLS nicht aktiviert ist, kann kein MPLS-Switching durchgeführt werden. Mit diesem Schritt können Sie schnell bestimmen, welche Schnittstellen mit MPLS und anderen Protokollfamilien konfiguriert sind.

Action!

Um die auf den Routern in Ihrem Netzwerk konfigurierten Protokollfamilien zu überprüfen, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:

Beispielausgabe 1

Befehlsname

Beispielausgabe 2

Befehlsname

Bedeutung

Beispielausgabe 1 zeigt die Schnittstelle, den administrativen Status der Verbindung (Admin), den Status der Datenverbindungsschicht der Verbindung (Link), die auf der Schnittstelle konfigurierten Protokollfamilien (Proto) sowie die lokalen und Remoteadressen auf der Schnittstelle.

Alle Schnittstellen auf allen Routen im Netzwerk, die in MPLS-Netzwerktopologie dargestellt sind, sind administrativ aktiviert und funktionieren auf der Datenverbindungsschicht mit MPLS und IS-IS und haben eine inet Adresse. Alle sind mit einer IPv4-Protokollfamilie (inet) konfiguriert und verfügen über die Protokollfamilien IS-IS (iso) und MPLS (mpls), die auf der Hierarchieebene [edit interfaces type-fpc/pic/port unit number] konfiguriert sind.

Beispielausgabe 2 zeigt, dass interface so-0/0/2.0 on R6 die mpls Anweisung nicht auf der Hierarchieebene [edit interfaces type-fpc/pic/port unit number] enthält.

Überprüfen der MPLS-Konfiguration

Zweck

Nachdem Sie die Transit- und Eingangsrouter überprüft, den traceroute Befehl zum Überprüfen des nächsten BGP-Hops und den ping Befehl zum Überprüfen des aktiven Pfads verwendet haben, können Sie auf der [edit protocols mpls] Hierarchieebene und [edit interfaces] nach Problemen mit der MPLS-Konfiguration suchen.

HINWEIS:

Damit eine beschriftete Route über eine Schnittstelle aufgelöst werden kann, muss sie auf Hierarchieebene [edit interfaces] konfiguriert werden, family mplsdamit die Route erfolgreich aufgelöst werden kann. Wenn die Schnittstelle nicht mit family mplskonfiguriert ist, werden beschriftete Routen nicht aufgelöst.

Action!

Um die MPLS-Konfiguration zu überprüfen, geben Sie die folgenden Befehle von den Eingangs-, Transit- und Ausgangsroutern ein:

Beispielausgabe 1

Befehlsname

Beispielausgabe 2

Befehlsname

Bedeutung

Beispielausgabe 1 der Eingangs-, Transit- und Ausgangsrouter zeigt, dass die Konfiguration der Schnittstellen auf dem Ausgangsrouter R6 falsch ist. Die Schnittstelle so-0/0/3.0 wird auf der Hierarchieebene [edit protocols mpls] als inaktiv einbezogen, obwohl sie aktiv sein sollte, da es sich um die Schnittstelle handelt, über die der Sprachdienstleister läuft.

Beispielausgabe 2 zeigt, dass Schnittstellen für MPLS auf dem Ausgangsrouter R6korrekt konfiguriert sind. Die Schnittstellen sind auch auf den Eingangs- und Transit-Routern korrekt konfiguriert (nicht dargestellt).

Überprüfen der MPLS-Schicht

Zweck

Nachdem Sie den label-switched path (LSP) konfiguriert, den show mpls lsp Befehl ausgegeben und festgestellt haben, dass ein Fehler vorliegt, stellen Sie möglicherweise fest, dass der Fehler nicht in den Schichten physisch, Datenverbindung, Internet Protocol (IP), Interior Gateway Protocol (IGP) oder Resource Reservation Protocol (RSVP) liegt. Untersuchen Sie das Problem auf der MPLS-Ebene des Netzwerks weiter.

Abbildung 1 veranschaulicht die MPLS-Schicht des MPLS-Modells mit Schichten.

Abbildung 1: Überprüfen der MPLS-SchichtÜberprüfen der MPLS-Schicht

Mit der MPLS-Schicht überprüfen Sie, ob der LSP betriebsbereit ist und ordnungsgemäß funktioniert. Wenn das Netzwerk auf dieser Ebene nicht funktioniert, funktioniert der Sprachdienstleister nicht wie konfiguriert.

Abbildung 2 veranschaulicht das in diesem Thema verwendete MPLS-Netzwerk.

Abbildung 2: MPLS-Netzwerk auf MPLS-Ebene unterbrochenMPLS-Netzwerk auf MPLS-Ebene unterbrochen

Bei dem gezeigten Abbildung 2 Netzwerk handelt es sich um eine vollständig vermaschte Konfiguration, bei der jede direkt verbundene Schnittstelle Pakete empfangen und an jede andere ähnliche Schnittstelle senden kann. Der LSP in diesem Netzwerk ist so konfiguriert, dass er vom Eingangsrouter R1über den Transitrouter R3zum Ausgangsrouter R6ausgeführt wird. Darüber hinaus ist ein Reverse-LSP so konfiguriert, dass er von R6 bis R3 bis R1ausgeführt wird, wodurch bidirektionaler Datenverkehr erzeugt wird.

In diesem Beispiel ist der umgekehrte LSP jedoch ohne einen Pfad von R6 bis ausgefallen R1.

Das in Abbildung 2 gezeigte Kreuz zeigt an, wo der LSP gebrochen ist. Einige mögliche Gründe, warum der LSP fehlerhaft ist, können ein falsch konfiguriertes MPLS-Protokoll oder Schnittstellen sein, die falsch für MPLS konfiguriert sind.

In dem in Abbildung 2gezeigten Netzwerk verhindert ein Konfigurationsfehler auf dem Ausgangsrouter R6 , dass der LSP das Netzwerk wie erwartet durchquert.

Gehen Sie folgendermaßen vor, um den MPLS-Layer zu überprüfen:

Überprüfen des LSP

Zweck

In der Regel verwenden Sie den show mpls lsp extensive Befehl, um den LSP zu überprüfen. Verwenden Sie jedoch für eine schnelle Überprüfung des LSP-Status den show mpls lsp Befehl. Wenn der Sprachdienstleister ausgefallen ist, verwenden Sie die extensive Option (show mpls lsp extensive) als Folge. Wenn Ihr Netzwerk über zahlreiche Sprachdienstleister verfügt, können Sie den Namen des Sprachdienstleisters angeben, indem Sie die name Option (show mpls lsp name name oder show mpls lsp name name extensive).

Action!

Um zu überprüfen, ob der LSP aktiv ist, geben Sie einige oder alle der folgenden Befehle vom Eingangsrouter ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname
Beispielausgabe 3
Befehlsname
Beispielausgabe 4
Befehlsname

Bedeutung

Beispielausgabe 1 zeigt eine kurze Beschreibung des Status des LSP für die Eingangs-, Transit- und Ausgangsrouter. Die Ausgabe des Eingangsrouters R1 und des Ausgangsrouters R6 zeigt, R1-to-R6 dass beide LSPs ausgefallen sind und R6-toR1. Wenn die konfigurierten LSPs aktiviert R1 und R6sind, würden wir ausgehende LSP-Sitzungen sowohl für als auch R1R6für erwarten. Darüber hinaus verfügt der Transitrouter R3 über keine Transitsitzungen.

Beispielausgabe 2 zeigt alle Informationen zu den LSPs, einschließlich des gesamten bisherigen Zustandsverlaufs und des Grundes, warum ein LSP fehlgeschlagen ist. Ausgabe von R1 und R6 gibt an, dass es keine Route zum Ziel gibt, da der CSPF-Algorithmus (Constrained Shortest Path First) fehlgeschlagen ist.

Die Beispielausgaben 3 und 4 zeigen Beispiele für die Ausgabe des show mpls lsp name Befehls mit der extensive Option. In diesem Fall ist die Ausgabe dem show mpls lsp Befehl sehr ähnlich, da im Beispielnetzwerk nur ein LSP in MPLS Network Broken at the MPLS Layerkonfiguriert ist. In einem großen Netzwerk mit vielen konfigurierten Sprachdienstleistern würden die Ergebnisse der beiden Befehle jedoch sehr unterschiedlich ausfallen.

Überprüfen der LSP-Route auf dem Transitrouter

Zweck

Wenn der Sprachdienstleister aktiv ist, sollte die LSP-Route in der mpls.0 Routingtabelle angezeigt werden. MPLS verwaltet eine MPLS-Pfadrouting-Tabelle (mpls.0), die eine Liste des nächsten label-switched-Routers in jedem LSP enthält. Diese Routing-Tabelle wird auf Transitroutern verwendet, um Pakete entlang eines LSP an den nächsten Router weiterzuleiten. Wenn in der Ausgabe für den Transit-Router keine Routen vorhanden sind, überprüfen Sie die MPLS-Protokollkonfiguration auf den Eingangs- und Ausgangsroutern.

Action!

Um die LSP-Route auf dem Transit-Router zu überprüfen, geben Sie den folgenden Befehl vom Transit-Router ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 des Transit-Routers R3 zeigt drei Routeneinträge in Form von MPLS-Label-Einträgen. Bei diesen MPLS-Bezeichnungen handelt es sich um reservierte MPLS-Bezeichnungen, die in RFC 3032 definiert sind und unabhängig vom Status des LSP immer in der mpls.0 Routing-Tabelle vorhanden sind. Die eingehenden Bezeichnungen, die RSVP dem Upstreamnachbarn zugewiesen hat, fehlen in der Ausgabe, was darauf hinweist, dass der LSP ausgefallen ist. Weitere Informationen zu MPLS-Bezeichnungseinträgen finden Sie unter Prüfliste zur Überprüfung der LSP-Verwendung.

Im Gegensatz dazu zeigt Beispielausgabe 2 die MPLS-Labels und -Routen für einen korrekt konfigurierten LSP. Die drei reservierten MPLS-Bezeichnungen sind vorhanden, und die vier anderen Einträge stellen die eingehenden Bezeichnungen dar, die dem Upstreamnachbarn von RSVP zugewiesen wurden. Diese vier Einträge stellen zwei Routen dar. Es gibt zwei Einträge pro Route, da die Stack-Werte im MPLS-Header unterschiedlich sein können. Für jede Route gibt der zweite Eintrag 100864 (S=0) und 100880 (S=0) an, dass die Stack-Tiefe nicht 1 ist und zusätzliche Label-Werte im Paket enthalten sind. Im Gegensatz dazu hat der erste Eintrag und 100880 einen abgeleiteten S=1-Wert, 100864der eine Stack-Tiefe von 1 angibt und jedes Label zum letzten Label in diesem bestimmten Paket macht. Die beiden Einträge zeigen an, dass dies der vorletzte Router ist. Weitere Informationen zum MPLS-Label-Stacking finden Sie unter RFC 3032, MPLS Label Stack Encoding.

Überprüfen der LSP-Route auf dem Eingangsrouter

Zweck

Prüfen Sie, ob die LSP-Route in den aktiven Einträgen in der inet.3 Routing-Tabelle für die angegebene Adresse enthalten ist.

Action!

Um die LSP-Route zu überprüfen, geben Sie den folgenden Befehl vom Eingangsrouter ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 zeigt nur Einträge in der inet.0 Routing-Tabelle. Die inet.3 Routing-Tabelle fehlt in der Ausgabe, da der LSP nicht funktioniert. Die inet.0 Routing-Tabelle wird von Interior Gateway Protocols (IGPs) und Border Gateway Protocol (BGP) zum Speichern von Routing-Informationen verwendet. In diesem Fall handelt es sich bei der IGP um ein Intermediate System-to-Intermediate System (IS-IS). Weitere Informationen zur inet.0 Routing-Tabelle finden Sie im Konfigurationshandbuch für Junos MPLS-Anwendungen.

Wenn der Sprachdienstleister funktioniert, erwarten wir Einträge, die den Sprachdienstleister in der inet.3 Routingtabelle enthalten. Die inet.3 Routing-Tabelle wird auf Eingangsroutern verwendet, um BGP-Pakete an den Ausgangsziel-Router weiterzuleiten. BGP verwendet die inet.3 Routing-Tabelle auf dem Eingangsrouter, um Next-Hop-Adressen aufzulösen. BGP wird in dem Beispielnetzwerk konfiguriert, das unter MPLS-Netzwerkfehler auf der MPLS-Schichtgezeigt wird.

Beispielausgang 2 zeigt die Ausgabe, die Sie erhalten sollten, wenn der LSP aktiv ist. Die Ausgabe zeigt sowohl die Routing- als inet.3 auch die inet.0 Routing-Tabelle an, was darauf hinweist, dass LSPs R1-to-R6 und R6-to-R1 verfügbar sind.

Überprüfen von MPLS-Labels mit dem Befehl traceroute

Zweck

Zeigen Sie die Route an, die Pakete zu einem BGP-Ziel nehmen, wobei der nächste BGP-Hop für diese Route die LSP-Ausgangsadresse ist. Standardmäßig verwendet BGP die inet.0 und die inet.3 Routing-Tabellen, um die Next-Hop-Adresse aufzulösen. Wenn die Next-Hop-Adresse der BGP-Route nicht die Router-ID des Ausgangsrouters ist, wird der Datenverkehr IGP-Routen und nicht dem LSP zugeordnet. Verwenden Sie den traceroute Befehl als Debugtool, um zu bestimmen, ob der LSP zum Weiterleiten von Datenverkehr verwendet wird.

Action!

Um MPLS-Labels zu überprüfen, geben Sie den folgenden Befehl vom Eingangsrouter ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 zeigt, dass der BGP-Datenverkehr nicht den LSP verwendet, sodass MPLS-Bezeichnungen nicht in der Ausgabe angezeigt werden. Anstatt den LSP zu verwenden, verwendet der BGP-Datenverkehr das IGP (IS-IS, im Beispielnetzwerk in MPLS Network Broken at the MPLS Layer), um die BGP-Ausgangsadresse des Next-Hop-LSP zu erreichen. Das Standardverhalten von Junos OS verwendet LSPs für BGP-Datenverkehr, wenn der nächste BGP-Hop der LSP-Ausgangsadresse entspricht.

Beispielausgang 2 ist ein Beispiel für die Ausgabe eines korrekt konfigurierten LSP. Die Ausgabe zeigt MPLS-Bezeichnungen an, die darauf hinweisen, dass BGP-Datenverkehr den LSP verwendet, um den nächsten BGP-Hop zu erreichen.

Überprüfen Sie MPLS-Labels mit dem Befehl ping

Zweck

Wenn Sie einen bestimmten Sprachdienstleister anpingen, überprüfen Sie, ob Echoanforderungen als MPLS-Pakete über den Sprachdienstleister gesendet werden.

Action!

Um MPLS-Bezeichnungen zu überprüfen, geben Sie den folgenden Befehl vom Eingangsrouter ein, um den Ausgangsrouter anzupingen:

Zum Beispiel:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 zeigt, dass der LSP nicht über einen aktiven Pfad zum Weiterleiten von Echoanforderungen verfügt, was darauf hinweist, dass der LSP ausgefallen ist.

Beispielausgang 2 ist ein Beispiel für eine Ausgabe, die Sie erhalten sollten, wenn der LSP aktiv ist und Pakete weiterleitet.

Geeignete Maßnahmen ergreifen

Problem

Beschreibung

Abhängig von dem Fehler, der bei der Untersuchung aufgetreten ist, müssen Sie die entsprechenden Maßnahmen ergreifen, um das Problem zu beheben. In diesem Beispiel ist eine Schnittstelle auf der Hierarchieebene [edit protocols mpls] des Ausgangsrouters falsch konfiguriert R6.

Lösung

Gehen Sie folgendermaßen vor, um den Fehler in diesem Beispiel zu beheben:

  1. Aktivieren Sie die Schnittstelle in der MPLS-Protokollkonfiguration auf dem Ausgangsrouter R6:

  2. Überprüfen und bestätigen Sie die Konfiguration:

Beispielausgabe
Bedeutung

Die Beispielausgabe zeigt, dass die falsch konfigurierte Schnittstelle so-0/0/3.0 auf dem Ausgangsrouter R6 jetzt auf der Hierarchieebene [edit protocols mpls] aktiviert ist. Der LSP kann nun hochgefahren werden.

Überprüfen Sie den LSP erneut

Zweck

Nachdem Sie die entsprechenden Maßnahmen ergriffen haben, um den Fehler zu beheben, muss der LSP erneut überprüft werden, um zu bestätigen, dass das Problem in der BGP-Schicht behoben wurde.

Action!

Um den LSP erneut zu überprüfen, geben Sie den folgenden Befehl von den Eingangs-, Transit- und Ausgangsroutern ein:

Beispielausgabe
Befehlsname

Bedeutung

Beispielausgabe 1 des Eingangsrouters R1 zeigt, dass LSP R1-to-R6 über eine aktive Route R6 zu verfügt und der Status aktiv ist.

Beispielausgabe 2 des Transitrouters R3 zeigt, dass es zwei Transit-LSP-Sitzungen gibt, eine von R1 nach R6 und und die andere von R6 . R1 Beide Sprachdienstleister sind aktiv.

Beispielausgabe 3 des Ausgangsrouters R6 zeigt, dass der LSP aktiv ist und die aktive Route die primäre Route ist. Der LSP durchläuft nun das Netzwerk entlang des erwarteten Pfads von R1 über R3 bis R6und der umgekehrte LSP von R6 bis R3 . R1

Überprüfen der Eins-zu-Eins-Sicherung

Zweck

Sie können überprüfen, ob eine Eins-zu-Eins-Sicherung eingerichtet ist, indem Sie den Eingangsrouter und die anderen Router im Netzwerk untersuchen.

Action!

Um die Eins-zu-Eins-Sicherung zu überprüfen, geben Sie die folgenden Befehle für den Betriebsmodus der Junos OS CLI ein:

Beispielausgabe

Befehlsname

Die folgende Beispielausgabe stammt vom Eingangsrouter R1 :

Bedeutung

Die Beispielausgabe von R1 zeigt, dass das FastReroute desired Objekt in den Pfadmeldungen für den LSP enthalten war, sodass R1 der aktive Pfad für den LSP ausgewählt und ein Umweg eingerichtet werden kann, um zu vermeiden R2.

In Zeile 8 wird angezeigt, Fast-reroute Detour Up dass die Umleitung betriebsbereit ist. Die Zeilen 6 und 7 weisen darauf hin, dass Transit-Router und R4 ihre Umleitungspfade R2 eingerichtet haben.

R2, 10.0.12.14, enthält (flag=9)und gibt an, dass der Knotenschutz für den nachgelagerten Knoten und die Verbindung verfügbar ist. R4, 10.0.24.2, schließt ein, was (flag=1)angibt, dass der Verknüpfungsschutz für die nächste nachgelagerte Verbindung verfügbar ist. In diesem Fall kann nur die Downstreamverbindung geschützt werden, R4 da der Knoten der Ausgangsrouter R5ist, der nicht geschützt werden kann. Weitere Informationen zu Flags finden Sie im Junos-Benutzerhandbuch.

Die Ausgabe des show mpls lsp extensive Befehls zeigt nicht den tatsächlichen Pfad der Umleitung an. Um die tatsächlichen Links zu sehen, die von den Umleitungspfaden verwendet werden, müssen Sie den show rsvp session ingress detail Befehl verwenden.

Beispielausgabe

Die folgende Beispielausgabe stammt vom Eingangsrouter R1 im Netzwerk, wie in Eins-zu-Eins-Backup-Umleitungengezeigt.

Bedeutung

Die Beispielausgabe von R1 zeigt die RSVP-Sitzung des Haupt-LSP. Der Umleitungsweg ist eingerichtet, Detour is Up. Der physikalische Pfad der Umleitung wird in Detour Explct routeangezeigt. Der Umleitungspfad verwendet R7 und R9 als Transit-Router den Egress-Router zu erreichen R5.

Beispielausgabe

Die folgende Beispielausgabe stammt vom ersten Transitrouter R2 im Netzwerk, das in Eins-zu-Eins-Sicherungsumleitungengezeigt wird:

Bedeutung

Die Beispielausgabe von R2 zeigt, dass der Umweg hergestellt wird (Detour is Up) und vermeidet R4, und die Verbindung verbindet R4 und R5 (10.0.45.2). Der Umleitungspfad führt durch R7 (10.0.27.2) und R9 (10.0.79.2) nach R5 (10.0.59.1), was sich von der expliziten Route für den Umweg von R1unterscheidet. R1 hat den Umweg, der über den 10.0.17.14 Link R7führt, während R1 der 10.0.27.2 Link verwendet wird. Beide Umwege führen durch R9 den 10.0.79.2 Link zu R5 (10.0.59.1) zusammen.

Beispielausgabe

Die folgende Beispielausgabe stammt vom zweiten Transitrouter R4 im Netzwerk, das in Eins-zu-Eins-Backup-Umleitungengezeigt wird:

Bedeutung

Die Beispielausgabe von R4 zeigt, dass der Umweg hergestellt ist (Detour is Up) und vermeidet die Verknüpfung R4 von und R5 (10.0.45.2). Der Umleitungsweg führt über R9 (10.0.49.2) nach R5 (10.0.59.1). Einige der Informationen ähneln denen, die in der Ausgabe für R1 und R2zu finden sind. Die explizite Route für den Umweg ist jedoch eine andere, da sie über die Verbindung führt R4 und R9 (so-0/0/3 oder 10.0.49.2.

Beispielausgabe

Die folgende Beispielausgabe stammt von R7, die in dem Umleitungspfad im Netzwerk verwendet wird, der in Eins-zu-Eins-Sicherungsumleitungengezeigt wird:

Bedeutung

Die Beispielausgabe von R7 zeigt die gleichen Informationen wie für einen regulären Transitrouter, der im primären Pfad des LSP verwendet wird: die Eingangsadresse (192.168.1.1), die Ausgangsadresse (192.168.5.1 ) und der Name des LSP (r1-to-r5). Es werden zwei Umleitungspfade angezeigt; die erste zu vermeiden R4 (192.168.4.1) und die zweite zu vermeiden R2 (192.168.2.1). Da R7 als Transit-Router von R2 und R4verwendet wird, können die Umleitungspfade zusammengeführt werden, R7 wie durch den identischen Label out Wert (100368) für beide Umleitungspfade angegeben. Gibt an, ob R7 Datenverkehr von R4 mit einem Bezeichnungswert von 100736 oder von R2 mit einem Bezeichnungswert von empfangen 100752wird, R7 leitet das Paket an R5 mit einem Bezeichnungswert von 100368weiter.

Beispielausgabe

Die folgende Beispielausgabe stammt von R9, einem Router, der im Umleitungspfad im Netzwerk verwendet wird, der in Eins-zu-Eins-Sicherungsumleitungengezeigt wird:

Bedeutung

Die Beispielausgabe von R9 zeigt, dass R9 dies der vorletzte Router für den Umleitungspfad ist, die explizite Route nur die Adresse des Ausgangslinks (10.0.59.1) enthält und der Label out Wert (3) angibt, dass das R9 Label des vorletzten Hops gepoppt wurde. Außerdem enthält die Umleitungsverzweigung von 10.0.27.1 keine Pfadinformationen, da R7 die Umleitungspfade von R2 und R4zusammengeführt wurden. Beachten Sie, dass der Label out Wert in der Umleitungsverzweigung von 10.0.17.13 , 100368derselbe Wert wie der Label out Wert auf R7ist.

Beispielausgabe

Die folgende Beispielausgabe stammt vom Ausgangsrouter R5 in dem Netzwerk, das in Eins-zu-Eins-Backup-Umleitungengezeigt wird:

Bedeutung

Die Beispielausgabe von R5 zeigt den Haupt-LSP im Record route Feld und die Umwege durch das Netzwerk.

Vergewissern Sie sich, dass der primäre Pfad betriebsbereit ist.

Zweck

Primäre Pfade müssen immer im Netzwerk verwendet werden, wenn sie verfügbar sind, daher kehrt ein LSP nach einem Ausfall immer zum primären Pfad zurück, es sei denn, die Konfiguration wird angepasst. Weitere Informationen zum Anpassen der Konfiguration, um zu verhindern, dass ein fehlerhafter primärer Pfad wiederhergestellt wird, finden Sie unter Verhindern der Verwendung eines zuvor fehlgeschlagenen Pfads.

Action!

Um zu überprüfen, ob der primäre Pfad betriebsbereit ist, geben Sie die folgenden Befehle für den Betriebsmodus der Befehlszeilenschnittstelle (CLI) des Betriebssystems ein:

Beispielausgabe 1

Befehlsname

Beispielausgabe 2

Befehlsname

Bedeutung

Beispielausgabe 1 zeigt, dass der LSP betriebsbereit ist und den primären Pfad (via-r2) mit R2 (10.0.12.14) und R4 (10.0.24.2) als Transitrouter verwendet. Die Prioritätswerte sind für Setup und Hold, 6 6. Priorität 0 ist die höchste (beste) Priorität und 7 ist die niedrigste (schlechteste) Priorität. Der Junos OS-Standardwert für die Setup- und Haltepriorität ist 7:0. Sofern einige Sprachdienstleister nicht wichtiger sind als andere, empfiehlt es sich, die Standardeinstellung beizubehalten. Das Konfigurieren einer Setup-Priorität, die besser als die Hold-Priorität ist, ist nicht zulässig, was zu einem fehlgeschlagenen Commit führt, um Preemption-Schleifen zu vermeiden.

Vergewissern Sie sich, dass der sekundäre Pfad eingerichtet ist.

Zweck

Wenn der sekundäre Pfad mit der standby Anweisung konfiguriert ist, sollte der sekundäre Pfad aktiv , aber nicht aktivsein. Er wird aktiv, wenn der primäre Pfad fehlschlägt. Ein sekundärer Pfad, der ohne die standby Anweisung konfiguriert ist, wird nur angezeigt, wenn der primäre Pfad fehlschlägt. Um zu testen, ob der sekundäre Pfad korrekt konfiguriert ist und bei einem Ausfall des primären Pfads angezeigt wird, müssen Sie eine Verbindung oder einen Knoten deaktivieren, die für den primären Pfad kritisch sind, und dann den show mpls lsp lsp-path-name extensive Befehl absetzen.

Action!

Um zu überprüfen, ob der sekundäre Pfad eingerichtet ist, geben Sie den folgenden Junos OS CLI-Befehl für den Betriebsmodus ein:

Beispielausgabe

Beispielausgabe

Befehlsname

Die folgende Beispielausgabe zeigt einen ordnungsgemäß konfigurierten sekundären Pfad vor und nach dem Aufrufen. Im Beispiel ist die Schnittstelle fe-0/1/0 eingeschaltet R2 , wodurch der primäre Pfad via-r2heruntergefahren wird. Der Eingangsrouter R1 leitet den Datenverkehr auf den sekundären Pfad via-r7um.

Bedeutung

Die Beispielausgabe des Ausgangsrouters R1 zeigt einen ordnungsgemäß konfigurierten sekundären Standby-Pfad in einem inaktiven Zustand, da der primäre Pfad noch aktiv ist. Bei der Deaktivierung einer Schnittstelle (interface fe-0/1/0 ein ), die für den primären Pfad kritisch ist, wird der primäre Pfad via-r2 unterbrochen und der sekundäre Standby-Pfad via-r7 wird aktiviert, sodass der Datenverkehr auf den sekundären Standby-Pfad umgeschaltet werden kann R1R2.

Verifizieren der physikalischen Schicht

Zweck

Nachdem Sie den Sprachdienstleister konfiguriert, den show mpls lsp extensive Befehl ausgegeben und festgestellt haben, dass ein Fehler vorliegt, können Sie mit der Untersuchung des Problems auf der physischen Ebene des Netzwerks beginnen.

Abbildung 3 veranschaulicht die physikalische Schicht des MPLS-Modells mit Schichten.

Abbildung 3: Verifizieren der physikalischen SchichtVerifizieren der physikalischen Schicht

Mit dieser Ebene müssen Sie sicherstellen, dass die Router verbunden sind und dass die Schnittstellen auf den Eingangs-, Ausgangs- und Transit-Routern verfügbar und korrekt konfiguriert sind.

Wenn das Netzwerk auf dieser Ebene nicht funktioniert, funktioniert der Label-Switched-Pfad (LSP) nicht wie konfiguriert.

Abbildung 4 veranschaulicht das MPLS-Netzwerk und das in diesem Thema beschriebene Problem.

Abbildung 4: MPLS-Netzwerk auf der physischen Ebene unterbrochenMPLS-Netzwerk auf der physischen Ebene unterbrochen

Bei dem gezeigten Abbildung 4 Netzwerk handelt es sich um eine vollständig vermaschte Konfiguration, bei der jede direkt verbundene Schnittstelle Pakete empfangen und an jede andere ähnliche Schnittstelle senden kann. Der LSP in diesem Netzwerk ist so konfiguriert, dass er vom Eingangsrouter R1über den Transitrouter R3zum Ausgangsrouter R6ausgeführt wird. Darüber hinaus ist ein Reverse-LSP so konfiguriert, dass er von R6 bis R3 bis R1ausgeführt wird, wodurch bidirektionaler Datenverkehr erzeugt wird.

In diesem Beispiel wird für den Datenverkehr jedoch nicht der konfigurierte LSP verwendet. Stattdessen nutzt der Verkehr die alternative Route von R1 durch R2 bis R6und in umgekehrter Richtung von R6 durch R5 to R1.

Wenn Sie feststellen, dass eine alternative Route anstelle des konfigurierten LSP verwendet wird, überprüfen Sie, ob die physische Schicht ordnungsgemäß funktioniert. Möglicherweise stellen Sie fest, dass Router nicht verbunden sind oder dass Schnittstellen auf den Eingangs-, Ausgangs- oder Transit-Routern nicht aktiv und korrekt konfiguriert sind.

Das in Abbildung 4 gezeigte Kreuz zeigt an, wo der LSP aufgrund eines Konfigurationsfehlers auf dem Eingangsrouter R1defekt ist.

Gehen Sie folgendermaßen vor, um die physische Schicht zu überprüfen:

Überprüfen des LSP

Zweck

In der Regel verwenden Sie den show mpls lsp extensive Befehl, um den LSP zu überprüfen. Verwenden Sie jedoch für eine schnelle Überprüfung des LSP-Status den show mpls lsp Befehl. Wenn der Sprachdienstleister ausgefallen ist, verwenden Sie die extensive Option (show mpls lsp extensive) als Folge. Wenn Ihr Netzwerk über zahlreiche Sprachdienstleister verfügt, können Sie den Namen des Sprachdienstleisters angeben, indem Sie die name Option (show mpls lsp name name oder show mpls lsp name name extensive).

Action!

Um festzustellen, ob der LSP aktiv ist, geben Sie den folgenden Befehl vom Eingangsrouter ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe des Eingangsrouters R1 zeigt, dass der LSP einen alternativen Pfad anstelle des konfigurierten Pfads verwendet. Der konfigurierte Pfad für den LSP ist R1 durch R3 zu R6, und für den umgekehrten LSP R6 bis R3 . R1 Der alternative Pfad, der vom LSP verwendet wird, ist R1 durch R2 zu R6, und für den umgekehrten LSP,hrough R5 R6 tto R1.

Überprüfen der Routerverbindung

Zweck

Vergewissern Sie sich, dass die entsprechenden Eingangs-, Transit- und Ausgangsrouter funktionieren, indem Sie prüfen, ob die Pakete mit einem Paketverlust von 0 % empfangen und übertragen wurden.

Action!

Um festzustellen, ob die Router verbunden sind, geben Sie den folgenden Befehl von den Eingangs- und Transit-Routern ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, dass der Eingangsrouter R1 Pakete vom Transitrouter R3empfängt und dass der Transitrouter Pakete vom Ausgangsrouter empfängt. Daher sind die Router im LSP verbunden.

Schnittstellen verifizieren

Zweck

Vergewissern Sie sich mit der family mpls Anweisung, dass die Schnittstellen korrekt konfiguriert sind.

Action!

Um festzustellen, ob die relevanten Schnittstellen aktiv und korrekt konfiguriert sind, geben Sie die folgenden Befehle von den Eingangs-, Transit- und Ausgangsroutern ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, dass für die Schnittstelle so-0/0/2.0 auf dem Eingangsrouter die family mpls Anweisung auf der Hierarchieebene [edit interfaces type-fpc/pic/port] nicht konfiguriert ist, was darauf hinweist, dass die Schnittstelle falsch für die Unterstützung des LSP konfiguriert ist. Der LSP ist auf der Hierarchieebene [edit protocols mpls] korrekt konfiguriert.

Die Ausgabe der Transit- und Ausgangsrouter (nicht dargestellt) zeigt, dass die Schnittstellen auf diesen Routern ordnungsgemäß konfiguriert sind.

Geeignete Maßnahmen ergreifen

Problem

Beschreibung

Abhängig von dem Fehler, der bei der Untersuchung aufgetreten ist, müssen Sie die entsprechenden Maßnahmen ergreifen, um das Problem zu beheben. Im folgenden Beispiel ist die Anweisung, die family mpls fehlte, in der Konfiguration des Eingangsrouters R1enthalten.

Lösung

Um den Fehler in diesem Beispiel zu beheben, geben Sie die folgenden Befehle ein:

Beispielausgabe
Bedeutung

Die Beispielausgabe des Eingangsrouters R1 zeigt, dass die family mpls Anweisung für die Schnittstelle so-0/0/2.0ordnungsgemäß konfiguriert ist und dass der LSP jetzt wie ursprünglich konfiguriert funktioniert.

Überprüfen Sie den LSP erneut

Zweck

Nachdem Sie die entsprechenden Maßnahmen ergriffen haben, um den Fehler zu beheben, muss der Sprachdienstleister erneut überprüft werden, um zu bestätigen, dass das Problem in der physikalischen Ebene behoben wurde.

Action!

Geben Sie den folgenden Befehl ein, um zu überprüfen, ob der LSP wie erwartet aktiv ist und das Netzwerk durchläuft:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 des Eingangsrouters R1 zeigt, dass der LSP nun das Netzwerk entlang des erwarteten Pfads durchläuft, von R1 über R3 bis R6und der umgekehrte LSP von R6 bis R3 . R1

Beispielausgabe 2 des Eingangsrouters R1 zeigt, dass der LSP gezwungen ist, den beabsichtigten Pfad zu nehmen, da MPLS auf R1 Schnittstellen so-0/0/0.0 deaktiviert ist und so-0/0/1.0. Wenn diese Schnittstellen nicht deaktiviert würden, würde der LSP das Netzwerk immer noch über den alternativen Pfad durchqueren, obwohl die Konfiguration jetzt korrekt ist.

Verifizieren der IP- und IGP-Schicht

Problem

Beschreibung

Nachdem Sie den Label-Switched-Pfad (LSP) konfiguriert, den show mpls lsp extensive Befehl ausgegeben und festgestellt haben, dass ein Fehler vorliegt, stellen Sie möglicherweise fest, dass der Fehler nicht in der physischen oder Datenverbindungsschicht auftritt. Untersuchen Sie das Problem auf der IP- und IGP-Ebene des Netzwerks weiter.

Abbildung 7 veranschaulicht die IP- und IGP-Schichten des MPLS-Schichtmodells.

Abbildung 7: IP- und IGP-SchichtenIP- und IGP-Schichten

Lösung

Auf der IP- und IGP-Ebene müssen Sie Folgendes überprüfen:

  • Die Schnittstellen haben die korrekte IP-Adressierung, und die IGP-Nachbarn oder Nachbarschaften werden eingerichtet.

  • OSPF-Protokolle (Open Shortest Path First) oder IS-IS (Intermediate System-to-Intermediate System) sind konfiguriert und werden ordnungsgemäß ausgeführt.

    • Wenn das OSPF-Protokoll konfiguriert ist, überprüfen Sie zuerst die IP-Schicht und dann die OSPF-Konfiguration, um sicherzustellen, dass das Protokoll, die Schnittstellen und das Traffic Engineering korrekt konfiguriert sind.

    • Wenn das IS-IS-Protokoll konfiguriert ist, spielt es keine Rolle, ob Sie zuerst IS-IS oder IP prüfen, da beide Protokolle unabhängig voneinander sind. Stellen Sie sicher, dass IS-IS-Nachbarschaften aktiv sind und dass die Schnittstellen und das IS-IS-Protokoll ordnungsgemäß konfiguriert sind.

      HINWEIS:

      Beim IS-IS-Protokoll ist Traffic Engineering standardmäßig aktiviert.

Wenn das Netzwerk auf der IP- oder IGP-Ebene nicht funktioniert, funktioniert der LSP nicht wie konfiguriert.

Abbildung 8 veranschaulicht das in diesem Thema verwendete MPLS-Netzwerk.

Abbildung 8: MPLS-Netzwerk auf IP- und IGP-Schicht unterbrochenMPLS-Netzwerk auf IP- und IGP-Schicht unterbrochen

Bei dem gezeigten Abbildung 8 Netzwerk handelt es sich um eine vollständig vermaschte Konfiguration, bei der jede direkt verbundene Schnittstelle Pakete empfangen und an jede andere ähnliche Schnittstelle senden kann. Der LSP in diesem Netzwerk ist so konfiguriert, dass er vom Eingangsrouter R1über den Transitrouter R3zum Ausgangsrouter R6ausgeführt wird. Darüber hinaus ist ein Reverse-LSP so konfiguriert, dass er von R6, über , bis R3läuft R1und bidirektionalen Datenverkehr erzeugt. Die Kreuze zeigen Abbildung 8 an, wo der LSP aufgrund der folgenden Probleme auf der IP- und IGP-Ebene nicht funktioniert:

  • Eine IP-Adresse ist auf dem Eingangsrouter falsch konfiguriert (R1).

  • Das OSPF-Protokoll ist mit einer Router-ID (RID), aber ohne die Loopback-Schnittstelle (lo0) konfiguriert, und Traffic Engineering fehlt auf dem Transit-Router (R3).

  • Die Ebenen im IS-IS-Netzwerk stimmen nicht überein.

Verifizieren der IP-Schicht

Zweck

Sie können die IP-Schicht vor oder nach der Überprüfung der IGP-Schicht (Interior Gateway Protocol) überprüfen, je nachdem, ob Sie OSPF oder IS-IS als IGP konfiguriert haben. Wenn Ihr MPLS-Netzwerk mit OSPF als IGP konfiguriert ist, müssen Sie zuerst die IP-Schicht überprüfen, d. h. überprüfen, ob die Schnittstellen die richtige IP-Adressierung haben und ob die OSPF-Nachbarn eingerichtet sind, bevor Sie die OSPF-Schicht überprüfen.

Wenn Sie IS-IS als IGP in Ihrem MPLS-Netzwerk konfiguriert haben, können Sie zuerst entweder die IP-Schicht oder die IS-IS-Protokollschicht verifizieren. Die Reihenfolge, in der Sie die IP- oder IS-IS-Schicht überprüfen, hat keinen Einfluss auf die Ergebnisse.

Abbildung 9: MPLS-Netzwerk auf IP-Ebene kaputtMPLS-Netzwerk auf IP-Ebene kaputt

Das Kreuz in Abbildung 9 zeigt an, wo der LSP aufgrund der falschen Konfiguration einer IP-Adresse auf dem Eingangsrouter R1defekt ist.

Überprüfen des LSP

Zweck

Nachdem Sie den LSP konfiguriert haben, müssen Sie überprüfen, ob der LSP aktiv ist. LSPs können Ingress, Transit oder Egress sein. Verwenden Sie den show mpls lsp Befehl für eine schnelle Überprüfung des LSP-Status mit der extensive Option (show mpls lsp extensive) als Folge, wenn der LSP ausgefallen ist. Wenn Ihr Netzwerk über zahlreiche Sprachdienstleister verfügt, können Sie den Namen des Sprachdienstleisters mit der name Option (show mpls lsp name name oder show mpls lsp name name extensive).

Action!

Um zu überprüfen, ob der LSP aktiv ist, geben Sie den folgenden Befehl vom Eingangsrouter ein:

Beispielausgabe 1
Befehlsname

Bedeutung

Die Beispielausgabe des Eingangsrouters R1 zeigt, dass ein Fehler bei der MPLS-Labelzuweisung aufgetreten ist und der CSPF-Algorithmus (Constrained Shortest Path First) fehlgeschlagen ist, was dazu führte, dass keine Route zum Ziel 10.0.0.6 auf R6.

Überprüfen der IP-Adressierung

Zweck

Wenn Sie die IP-Schicht untersuchen, stellen Sie sicher, dass Schnittstellen über die richtige IP-Adressierung verfügen und ob OSPF-Nachbarn oder IS-IS-Nachbarschaften eingerichtet sind. In diesem Beispiel ist eine IP-Adresse auf dem Eingangsrouter falsch konfiguriert (R1).

Action!

Um die IP-Adresse zu überprüfen, geben Sie den folgenden Befehl vom Eingangs-, Transit- und Ausgangsrouter ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, dass die IP-Adressen für Schnittstelle so-0/0/2.0 ein R1 und Schnittstelle so-0/0/2.0 ein R3 identisch sind. Schnittstellen-IP-Adressen innerhalb eines Netzwerks müssen eindeutig sein, damit die Schnittstelle korrekt identifiziert werden kann.

Verifizieren von Nachbarn oder Nachbarschaften auf der IP-Ebene

Zweck

Wenn die IP-Adressierung falsch konfiguriert ist, müssen sowohl die OSPF-Nachbarn als auch die IS-IS-Nachbarschaften überprüft werden, um festzustellen, ob eine oder beide von ihnen eingerichtet sind.

Action!

Geben Sie die folgenden Befehle von den Eingangs-, Transit- und Ausgangsroutern ein, um Nachbarn (OSPF) oder Nachbarschaften (IS-IS) zu überprüfen:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 der Eingangs-, Transit- und Ausgangsrouter zeigt, dass R1 und R3 keine etablierten OSPF-Nachbarn sind. Wenn man bedenkt, dass die beiden Schnittstellen so-0/0/2.0 (R1 und R3) mit identischen IP-Adressen konfiguriert sind, würde man dies erwarten. Das OSPF-Protokoll routet IP-Pakete ausschließlich basierend auf der Ziel-IP-Adresse, die im IP-Paket-Header enthalten ist. Daher führen identische IP-Adressen im autonomen System (AS) dazu, dass sich Nachbarn nicht einrichten.

Beispielausgabe 2 der Eingangs-, Transit- und Ausgangsrouter zeigt, dass R1 und R3 trotz identischer IP-Adressen, die auf Schnittstellen so-0/0/2.0 auf R1 und R3konfiguriert sind, eine IS-IS-Nachbarschaft eingerichtet haben. Das IS-IS-Protokoll verhält sich anders als das OSPF-Protokoll, da es nicht auf IP angewiesen ist, um eine Nachbarschaft herzustellen. Wenn der Sprachdienstleister jedoch nicht aktiv ist, ist es dennoch sinnvoll, die IP-Subnetzadressierung zu überprüfen, falls ein Fehler in dieser Schicht vorliegt. Durch das Korrigieren des Adressierungsfehlers wird der LSP möglicherweise wieder aktiviert.

Geeignete Maßnahmen ergreifen

Problem

Beschreibung

Abhängig von dem Fehler, der bei der Untersuchung aufgetreten ist, müssen Sie die entsprechenden Maßnahmen ergreifen, um das Problem zu beheben. In diesem Beispiel ist die IP-Adresse einer Schnittstelle auf einem Transitrouter R2 falsch konfiguriert.

Lösung

Um den Fehler in diesem Beispiel zu beheben, geben Sie die folgenden Befehle ein:

Beispielausgabe
Bedeutung

Die Beispielausgabe zeigt, dass die Schnittstelle so-0/0/2 auf dem Eingangsrouter R1 jetzt mit der richtigen IP-Adresse konfiguriert ist. Diese Korrektur führt zu eindeutigen Subnetz-IP-Adressen für alle Schnittstellen im MPLS-Netzwerk in MPLS Network Broken auf der IP- und IGP-Schichtund der Möglichkeit, dass der LSP auftritt.

Überprüfen Sie den LSP erneut

Zweck

Nachdem Sie die entsprechenden Maßnahmen ergriffen haben, um den Fehler zu beheben, muss der Sprachdienstleister erneut überprüft werden, um zu bestätigen, dass das Problem im OSPF-Protokoll behoben wurde.

Action!

Um den LSP erneut zu überprüfen, geben Sie den folgenden Befehl auf den Eingangs-, Transit- und Ausgangsroutern ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname
Beispielausgabe 3
Befehlsname

Bedeutung

Beispielausgabe 1 des Eingangsrouters R1 zeigt, dass LSP R1-to-R6 über eine aktive Route R6 zu verfügt und der Status aktiv ist. Die Ausgabe zeigt, dass die ausgehende LSP-Sitzung R6-to-R1 eine Wiederherstellungsbezeichnung empfangen und gesendet hat.

Beispielausgabe 2 des Transitrouters R3 zeigt, dass es zwei Transit-LSP-Sitzungen gibt, eine von R1 nach R6 und und die andere von R6 bis R1. Beide LSPs sind aktiv.

Beispielausgabe 3 des Ausgangsrouters R6 zeigt, dass der LSP aktiv ist und die aktive Route die primäre Route ist. Der LSP durchläuft nun das Netzwerk entlang des erwarteten Pfads von R1 über R3 bis R6 und der umgekehrte LSP von R6R3 bis R1 .

Überprüfen Sie den LSP erneut

Zweck

Nachdem die entsprechenden Maßnahmen zur Behebung des Fehlers ergriffen wurden, muss der Sprachdienstleister erneut überprüft werden, um zu bestätigen, dass das Problem im IS-IS-Protokoll behoben wurde.

Action!

Um zu überprüfen, ob der LSP wie erwartet betriebsbereit ist und das Netzwerk durchläuft, geben Sie den folgenden Befehl von den Eingangs-, Ausgangs- und Transitroutern ein:

Beispielausgabe

Befehlsname

Bedeutung

Die Beispielausgabe des Eingangsrouters R1 und des Ausgangsrouters R6 zeigt, dass der LSP nun das Netzwerk entlang des erwarteten Pfads durchläuft, von R1 über R3 bis und R6der umgekehrte LSP von R6 bis R3 . R1 Darüber hinaus zeigt die Beispielausgabe des Transitrouters R3 , dass es zwei Transit-LSP-Sitzungen gibt, eine von R1 nach R6und und die andere von R6 . R1

Überprüfen der RSVP-Ebene

Zweck

Nachdem Sie den Label-Switched-Pfad (LSP) konfiguriert, den show mpls lsp extensive Befehl ausgegeben und festgestellt haben, dass ein Fehler vorliegt, stellen Sie möglicherweise fest, dass der Fehler nicht in den Schichten "Physisch", "Datenverbindung" oder "Internet Protocol" (IP) und "Interior Gateway Protocol" (IGP) auftritt. Untersuchen Sie das Problem auf der RSVP-Ebene des Netzwerks weiter.

Abbildung 10 veranschaulicht die RSVP-Schicht des MPLS-Schichtmodells.

Abbildung 10: Überprüfen der RSVP-EbeneÜberprüfen der RSVP-Ebene

Mit dieser Ebene überprüfen Sie, ob die dynamische RSVP-Signalisierung wie erwartet erfolgt, Nachbarn verbunden sind und Schnittstellen ordnungsgemäß für RSVP konfiguriert sind. Überprüfen Sie die Eingangs-, Ausgangs- und Transit-Router.

Wenn das Netzwerk auf dieser Ebene nicht funktioniert, funktioniert der Sprachdienstleister nicht wie konfiguriert.

Abbildung 11 veranschaulicht das in diesem Thema verwendete MPLS-Netzwerk.

Abbildung 11: MPLS-Netzwerk auf der RSVP-Ebene unterbrochenMPLS-Netzwerk auf der RSVP-Ebene unterbrochen

Bei dem gezeigten Abbildung 11 Netzwerk handelt es sich um eine vollständig vermaschte Konfiguration, bei der jede direkt verbundene Schnittstelle Pakete empfangen und an jede andere ähnliche Schnittstelle senden kann. Der LSP in diesem Netzwerk ist so konfiguriert, dass er vom Eingangsrouter R1über den Transitrouter R3zum Ausgangsrouter R6ausgeführt wird. Darüber hinaus ist ein Reverse-LSP so konfiguriert, dass er von R6 bis R3 bis R1ausgeführt wird, wodurch bidirektionaler Datenverkehr erzeugt wird.

In diesem Beispiel ist der LSP jedoch ohne Pfad in die eine oder andere Richtung ausgefallen, von R1 zu R6 oder von R6 nach R1.

Die in Abbildung 11 gezeigten Kreuze zeigen an, wo der LSP gebrochen ist. Einige mögliche Gründe für eine Fehlfunktion des LSP können sein, dass die dynamische RSVP-Signalisierung nicht wie erwartet erfolgt, Nachbarn nicht verbunden sind oder Schnittstellen falsch für RSVP konfiguriert sind.

Im Netzwerk in Abbildung 11verhindert ein Konfigurationsfehler auf dem Transitrouter R3 , dass der LSP das Netzwerk wie erwartet durchläuft.

Gehen Sie folgendermaßen vor, um den RSVP-Layer zu überprüfen:

Überprüfen des LSP

Zweck

In der Regel verwenden Sie den show mpls lsp extensive Befehl, um den LSP zu überprüfen. Verwenden Sie jedoch für eine schnelle Überprüfung des LSP-Status den show mpls lsp Befehl. Wenn der Sprachdienstleister ausgefallen ist, verwenden Sie die extensive Option (show mpls lsp extensive) als Folge. Wenn Ihr Netzwerk über zahlreiche Sprachdienstleister verfügt, können Sie den Namen des Sprachdienstleisters angeben, indem Sie die name Option (show mpls lsp name name oder show mpls lsp name name extensive).

Action!

Um festzustellen, ob der LSP aktiv ist, geben Sie den folgenden Befehl vom Eingangsrouter ein:

Beispielausgabe 1
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, dass der LSP in beide Richtungen nach unten geht, von R1 nach R6und und R6 von . R1 Die Ausgabe von R1 zeigt, dass ein no-cspf LSP verwendet wird, R1 da er versucht hat, den Anruf zu starten, ohne das Ziel erreichen zu können. Die Ausgabe von R6 zeigt, dass der CSPF-Algorithmus (Constrained Shortest Path First) fehlgeschlagen ist, was dazu führte, dass keine Route zum Ziel 10.0.0.1erstellt wurde.

RSVP-Sitzungen verifizieren

Zweck

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, funktioniert der LSP nicht wie konfiguriert.

Action!

Um die derzeit aktiven RSVP-Sitzungen zu überprüfen, geben Sie den folgenden Befehl vom Eingangs-, Transit- und Ausgangsrouter ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 von allen Routern zeigt, dass keine RSVP-Sitzungen erfolgreich erstellt wurden, obwohl der LSP R6-to-R1 konfiguriert ist.

Im Gegensatz zu Beispielausgabe 1 und zur Veranschaulichung der korrekten Ausgabe zeigt Beispielausgabe 2 die Ausgabe des Eingangs-, Transit- und Ausgangsrouters an, wenn die RSVP-Konfiguration korrekt ist und der LSP wie konfiguriert das Netzwerk durchläuft. R1 und R6 beide zeigen eine eingehende und ausgehende RSVP-Sitzung mit dem LSP R1-to-R6und dem umgekehrten LSP R6-to-R1. Der Transitrouter R3 zeigt zwei Transit-RSVP-Sitzungen an.

RSVP-Nachbarn verifizieren

Zweck

Zeigen Sie eine Liste der RSVP-Nachbarn an, die beim Austausch von RSVP-Paketen dynamisch gelernt wurden. Sobald ein Nachbar gelernt wurde, wird er nie aus der Liste der RSVP-Nachbarn entfernt, es sei denn, die RSVP-Konfiguration wird vom Router entfernt.

Action!

Um RSVP-Nachbarn zu überprüfen, geben Sie den folgenden Befehl vom Eingangs-, Transit- und Ausgangsrouter ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 zeigt, dass R1 und R6 jeweils einen RSVP-Nachbarn haben, R3. Die Werte im Up/Dn Feld unterscheiden sich jedoch. R1 hat einen Wert von 1/0 und R6 hat einen Wert von 1/1, was darauf hinweist, dass es R1 sich um einen aktiven Nachbarn mit R3handelt, R6 dies aber nicht ist. Wenn die Aufwärtszählung eins höher ist als die Abwärtszählung, ist der Nachbar aktiv. Wenn die Werte gleich sind, ist der Nachbar ausgefallen. Die Werte für R6 sind gleich, was darauf hinweist, 1/1dass der Nachbar R3 ausgefallen ist.

Der Transit-Router R3 kennt zwei Nachbarn, R1 und R6. Das Up/Dn Feld gibt an, dass es sich um einen aktiven Nachbarn handelt, R1 der R6 ausgefallen ist. An dieser Stelle ist es nicht möglich festzustellen, ob das Problem bei R3 oder R6liegt, da beide Nachbarn nicht aktiv sind.

Im Gegensatz zu Beispielausgabe 1 und zur Veranschaulichung der korrekten Ausgabe zeigt Beispielausgabe 2 die korrekte Nachbarbeziehung zwischen Transitrouter R3 und Ausgangsrouter R6. Das Up/Dn Feld zeigt an, dass die Anzahl nach oben höher ist als die Anzahl nach unten, was darauf hinweist, 1/0dass die Nachbarn aktiv sind.

Überprüfen der RSVP-Schnittstellen

Zweck

Zeigen Sie den Status jeder Schnittstelle an, auf der RSVP aktiviert ist, um festzustellen, wo der Konfigurationsfehler aufgetreten ist.

Action!

Um den Status der RSVP-Schnittstellen zu überprüfen, geben Sie den folgenden Befehl von den Eingangs-, Transit- und Ausgangsroutern ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispielausgabe 1 zeigt, dass, obwohl jeder Router über Schnittstellen verfügt, die aktiv sind und RSVP aktiv ist, es keine Reservierungen (Active resv) auf keinem der Router gibt. In diesem Beispiel würden wir mindestens eine Reservierung für den Eingangs- und Ausgangsrouter und zwei Reservierungen für den Transitrouter erwarten.

Darüber hinaus ist die Schnittstelle so-0/0/3 des Transit-Routers R3 nicht in der Konfiguration enthalten. Die Einbindung dieser Schnittstelle ist entscheidend für den Erfolg des Sprachdienstleisters.

Im Gegensatz zu Sample Output 1 und zur Veranschaulichung der korrekten Output zeigt Sample Output 2 die relevanten Schnittstellen mit aktiven Reservierungen.

Überprüfen der Konfiguration des RSVP-Protokolls

Zweck

Nachdem Sie RSVP-Sitzungen, Schnittstellen und Nachbarn überprüft und festgestellt haben, dass möglicherweise ein Konfigurationsfehler vorliegt, überprüfen Sie die Konfiguration des RSVP-Protokolls.

Action!

Um die RSVP-Konfiguration zu überprüfen, geben Sie den folgenden Befehl von den Eingangs-, Transit- und Ausgangsroutern ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, dass R3 die Schnittstelle so-0/0/3.0 in der Konfiguration des RSVP-Protokolls fehlt. Diese Schnittstelle ist entscheidend für das korrekte Funktionieren des Sprachdienstleisters.

Geeignete Maßnahmen ergreifen

Problem

Beschreibung

Abhängig von dem Fehler, der bei der Untersuchung aufgetreten ist, müssen Sie die entsprechenden Maßnahmen ergreifen, um das Problem zu beheben. In diesem Beispiel fehlt eine Schnittstelle in der Konfiguration des Routers R3.

Lösung

Gehen Sie folgendermaßen vor, um den Fehler in diesem Beispiel zu beheben:

  1. Nehmen Sie die fehlende Schnittstelle in die Konfiguration des Transit-Routers R3 auf:

  2. Überprüfen und bestätigen Sie die Konfiguration:

Beispielausgabe
Bedeutung

Die Beispielausgabe zeigt, dass die fehlende Schnittstelle so-0/0/3.0 auf dem Transitrouter R3 jetzt korrekt auf der Hierarchieebene [edit protocols rsvp] enthalten ist. Daraus ergibt sich die Möglichkeit, dass der LSP auftaucht.

Überprüfen Sie den LSP erneut

Zweck

Nachdem Sie die entsprechenden Maßnahmen ergriffen haben, um den Fehler zu beheben, muss der LSP erneut überprüft werden, um zu bestätigen, dass das Problem in der MPLS-Schicht behoben wurde.

Action!

Um den LSP erneut zu überprüfen, geben Sie den folgenden Befehl auf den Eingangs-, Transit- und Ausgangsroutern ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname
Beispielausgabe 3
Befehlsname

Bedeutung

Beispielausgabe 1 des Eingangsrouters R1 zeigt, dass LSP R1-to-R6 über eine aktive Route R6 zu verfügt und der Status aktiv ist.

Beispielausgabe 2 des Transitrouters R3 zeigt, dass es zwei Transit-LSP-Sitzungen gibt, eine von R1 nach R6 und und die andere von R6 . R1 Beide Sprachdienstleister sind aktiv.

Beispielausgabe 3 des Ausgangsrouters R6 zeigt, dass der LSP aktiv ist und die aktive Route die primäre Route ist. Der LSP durchläuft nun das Netzwerk entlang des erwarteten Pfads von R1 über R3 bis R6und der umgekehrte LSP von R6 bis R3 . R1

Ermitteln von LSP-Statistiken

Zweck

Zeigen Sie detaillierte Informationen zu RSVP-Objekten an, um die Diagnose eines LSP-Problems zu unterstützen.

Action!

Um RSVP-Objekte zu überprüfen, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:

Beispielausgabe

Befehlsname

Bedeutung

Die Beispielausgabe zeigt, dass es eine eingehende und eine ausgehende RSVP-Sitzung gibt. Die Eingangssitzung hat die Quelladresse ( 10.0.0.1R1), und die Sitzung ist mit einer aktiven Route aktiv. Der LSP-Name ist R1-to-R6 und es ist der primäre Pfad für den LSP.

Die Wiederherstellungsbezeichnung (100064) wird von einem Router mit ordnungsgemäßem Neustart an seinen Nachbarn gesendet, um einen Weiterleitungsstatus wiederherzustellen. Es ist wahrscheinlich das alte Label, mit dem der Router geworben hat, bevor er ausfiel.

In diesem Programm wird der Reservierungsstil () mit festem Filter (FFResv style) verwendet. Da es sich um einen Eingangsrouter handelt, gibt es kein eingehendes Label. Die ausgehende Bezeichnung (die vom nächsten Downstream-Router bereitgestellt wird) lautet 100064.

Das Time Left Feld gibt die Anzahl der Sekunden an, die in der RSVP-Sitzung verbleiben, und das Tspec Objekt enthält Informationen über die kontrollierte Laderate (rate) und die maximale Burstgröße (peak), einen unendlichen Wert (Infbps) für die garantierte Übermittlungsoption sowie die Angabe, dass Pakete, die kleiner als 20 Byte sind, als 20 Byte behandelt werden, während Pakete, die größer als 1500 Byte sind, als 1500 Byte behandelt werden.

Die Portnummer ist die IPv4-Tunnel-ID, während die Portnummer des Senders/Empfängers die LSP-ID ist. Die IPv4-Tunnel-ID ist für die Lebensdauer des LSP eindeutig, während sich die Sender-/Empfänger-LSP-ID ändern kann, z. B. bei einer Reservierung im SE-Stil.

Das PATH rcvfrom Feld enthält die Quelle der Pfadnachricht. Da es sich um den Eingangsrouter handelt, hat der lokale Client die Pfadnachricht erstellt.

Das PATH sentto Feld enthält den Pfad Nachrichtenziel (10.1.13.2) und die ausgehende Schnittstelle (so-0/0/2.0). Das RESV rcvfrom Feld enthält sowohl die Quelle der empfangenen Resv-Nachricht (10.1.13.2) als auch die eingehende Schnittstelle (so-0/0/2.0).

Die explizite RSVP-Route und die Werte des Routendatensatzes sind identisch: 10.1.13.2 und 10.1.36.2. In den meisten Fällen sind die Werte für die explizite Route und die Datensatzroute identisch. Unterschiede weisen darauf hin, dass eine gewisse Pfadumleitung stattgefunden hat, in der Regel während der schnellen Umleitung.

Die Total Felder geben die Gesamtzahl der eingehenden, ausgehenden und transitartigen RSVP-Sitzungen an, wobei die Summe der Up- und Down-Sitzungen entspricht. In diesem Beispiel gibt es eine Eingangssitzung, eine Ausgangssitzung und keine Transit-RSVP-Sitzungen.

Überprüfen der LSP-Nutzung in Ihrem Netzwerk

Zweck

Wenn Sie die gültige Verwendung eines LSP auf den Eingangs- und Transitroutern in Ihrem Netzwerk überprüfen, können Sie feststellen, ob ein Problem mit Multiprotocol Label Switching (MPLS) in Ihrem Netzwerk vorliegt. Abbildung 12 Beschreibt das Beispielnetzwerk, das in diesem Thema verwendet wird.

Abbildung 12: MPLS-Topologie zur Überprüfung der LSP-NutzungMPLS-Topologie zur Überprüfung der LSP-Nutzung

Das MPLS-Netzwerk in Abbildung 12 veranschaulicht ein reines Router-Netzwerk mit SONET-Schnittstellen, die aus den folgenden Komponenten bestehen:

  • Eine innermaschige IBGP-Topologie (Border Gateway Protocol) mit AS 65432

  • MPLS und Resource Reservation Protocol (RSVP) auf allen Routern aktiviert

  • Eine send-statics Richtlinie auf den Routern R1 und R6, die es ermöglicht, eine neue Route im Netzwerk anzukündigen

  • Ein LSP zwischen den Routern R1 und R6

Bei dem gezeigten Abbildung 12 Netzwerk handelt es sich um ein BGP-Full-Mesh-Netzwerk (Border Gateway Protocol). Da Routenreflektoren und Konföderationen nicht zur Weitergabe von BGP-gelernten Routen verwendet werden, muss jeder Router über eine BGP-Sitzung mit jedem anderen Router verfügen, auf dem BGP ausgeführt wird.

Gehen Sie folgendermaßen vor, um die LSP-Nutzung in Ihrem Netzwerk zu überprüfen:

Überprüfen eines LSP auf dem Eingangsrouter

Zweck

Sie können die Verfügbarkeit eines LSP überprüfen, wenn er aktiv ist, indem Sie die inet.3 Routing-Tabelle auf dem Eingangsrouter untersuchen. Die inet.3 Routing-Tabelle enthält die Hostadresse des Ausgangsrouters jedes LSP. Diese Routing-Tabelle wird auf Eingangsroutern verwendet, um BGP-Pakete an den Ausgangs-Zielrouter weiterzuleiten. BGP verwendet die inet.3 Routing-Tabelle auf dem Eingangsrouter, um Next-Hop-Adressen aufzulösen.

Action!

Um einen LSP auf einem Eingangsrouter zu überprüfen, geben Sie den folgenden Befehl für den Betriebsmodus der Junos OS-Befehlszeilenschnittstelle (CLI) ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt die inet.3 Routingtabelle. Standardmäßig können nur BGP- und MPLS-VPNs (Virtual Private Networks) die inet.3 Routing-Tabelle verwenden, um Informationen zum nächsten Hop aufzulösen. Ein Ziel ist in der Routing-Tabelle aufgeführt. 10.0.0.6 Dieses Ziel (10.0.0.6) wird durch RSVP signalisiert und ist der aktuell aktive Pfad, wie durch das Sternchen (*) angegeben. Die Protokollpräferenz für diese Route ist 7und die damit verknüpfte Metrik ist 20. Der Label-Switched-Pfad ist R1-to-R6, über die Schnittstelle so-0/0/2.0, bei der es sich um die physische Next-Hop-Transitschnittstelle handelt.

In der Regel gibt der vorletzte Router im LSP entweder die Bezeichnung des Pakets frei oder ändert die Bezeichnung in den Wert 0. Wenn der vorletzte Router die oberste Beschriftung aufweist und sich darunter ein IPv4-Paket befindet, leitet der Ausgangsrouter das IPv4-Paket weiter und konsultiert die IP-Routing-Tabelle inet.0 , um zu bestimmen, wie das Paket weitergeleitet werden soll. Wenn sich unter der obersten Bezeichnung eine andere Bezeichnung befindet (z. B. eine, die von LDP-Tunneling (Label Distribution Protocol) oder VPNs, aber nicht von IPv4 erstellt wurde), untersucht der Ausgangsrouter die inet.0 Routing-Tabelle nicht. Stattdessen wird die mpls.0 Routing-Tabelle auf Weiterleitungsentscheidungen überprüft.

Wenn der vorletzte Router die Bezeichnung des Pakets auf den Wert 0 ändert, entfernt der Ausgangsrouter die Bezeichnung 0 und zeigt damit an, dass ein IPv4-Paket folgt. Das Paket wird von der inet.0 Routing-Tabelle auf Weiterleitungsentscheidungen untersucht.

Wenn ein Transit- oder Ausgangsrouter ein MPLS-Paket empfängt, werden Informationen in der MPLS-Weiterleitungstabelle verwendet, um den nächsten Transitrouter im LSP zu bestimmen oder festzustellen, ob es sich bei diesem Router um den Ausgangsrouter handelt.

Wenn BGP ein Next-Hop-Präfix auflöst, untersucht es sowohl die Routing-Tabelle als inet.3 auch die inet.0Routing-Tabelle und sucht nach dem nächsten Hop mit der niedrigsten Präferenz. Beispielsweise wird RSVP-Präferenz 7 gegenüber OSPF-Präferenz 10 bevorzugt. Der RSVP-signalisierte LSP wird verwendet, um den nächsten BGP-Hop zu erreichen. Dies ist die Standardeinstellung, wenn der nächste BGP-Hop der LSP-Ausgangsadresse entspricht. Sobald der nächste BGP-Hop durch einen LSP aufgelöst wurde, verwendet der BGP-Datenverkehr den LSP, um den BGP-Transitdatenverkehr weiterzuleiten.

Verifizieren eines LSP auf einem Transitrouter

Zweck

Sie können die Verfügbarkeit eines LSP überprüfen, wenn er aktiv ist, indem Sie die mpls.0 Routing-Tabelle auf einem Transitrouter untersuchen. MPLS verwaltet die mpls.0 Routing-Tabelle, die eine Liste des nächsten label-switched-Routers in jedem LSP enthält. Diese Routing-Tabelle wird auf Transitroutern verwendet, um Pakete entlang eines LSP an den nächsten Router weiterzuleiten.

Action!

Um einen LSP auf einem Transitrouter zu verifizieren, geben Sie den folgenden Junos OS CLI-Befehl für den Betriebsmodus ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe des Transitrouters R3 zeigt Routeneinträge in Form von MPLS-Label-Einträgen, die darauf hinweisen, dass es nur eine aktive Route gibt, obwohl es fünf aktive Einträge gibt.

Bei den ersten drei MPLS-Bezeichnungen handelt es sich um reservierte MPLS-Bezeichnungen, die in RFC 3032 definiert sind. Pakete, die mit diesen Label-Werten empfangen werden, werden zur Verarbeitung an die Routing-Engine gesendet. Label 0 ist die explizite IPv4-NULL-Bezeichnung. Label 1 ist das MPLS-Äquivalent des IP-Router-Alert-Labels und Label 2 ist das explizite IPv6-NULL-Label.

Die beiden Einträge mit der 100064 Bezeichnung beziehen sich auf denselben LSP. R1-to-R6. Es gibt zwei Einträge, da die Stack-Werte im MPLS-Header unterschiedlich sein können. Der zweite Eintrag, , gibt an, 100064 (S=0)dass die Stapeltiefe nicht 1 ist und zusätzliche Bezeichnungswerte im Paket enthalten sind. Im Gegensatz dazu hat der erste Eintrag von 100064 ein abgeleitetes S = 1, was eine Stapeltiefe von 1 angibt und es zum letzten Label im Paket macht. Der doppelte Eintrag zeigt an, dass dies der vorletzte Router ist. Weitere Informationen zum MPLS-Label-Stacking finden Sie unter RFC 3032, MPLS Label Stack Encoding.

Das eingehende Label ist der MPLS-Header des MPLS-Pakets und wird durch RSVP dem Upstreamnachbarn zugewiesen. Router von Juniper Networks weisen RSVP-Traffic-Engineering-LSPs im Bereich von 100.000 bis 1.048.575 dynamisch Labels zu.

Der Router weist Labels ab Label 100.000 in Schritten von 16 zu. Die Reihenfolge der Beschriftungszuweisungen ist 100.000, 100.016, 100.032, 100.048 usw. Am Ende der zugewiesenen Beschriftungen beginnen die Beschriftungsnummern wieder bei 100001 und werden in Einheiten von 16 erhöht. Juniper Networks behält sich Etiketten für verschiedene Zwecke vor. Tabelle 1 Listet die verschiedenen Zuweisungen von Etikettenbereichen für eingehende Etiketten auf.

Tabelle 1: MPLS-Label-Bereichszuweisungen

Eingehendes Etikett

Status

0 durch 15

Reserviert von IETF

16 durch 1023

Reserviert für statische LSP-Zuweisung

1024 durch 9999

Reserviert für den internen Gebrauch (z. B. CCC-Etiketten)

10,000 durch 99,999

Reserviert für statische LSP-Zuweisung

100,000 durch 1,048,575

Reserviert für die dynamische Label-Zuweisung

Überprüfen, ob der Lastenausgleich funktioniert

Zweck

Nachdem Sie den Lastenausgleich konfiguriert haben, überprüfen Sie, ob der Datenverkehr gleichmäßig auf die Pfade verteilt ist. In diesem Abschnitt spiegelt die Befehlsausgabe die Lastenausgleichskonfiguration des Beispielnetzwerks wider, das unter Lastenausgleichs-Netzwerktopologiegezeigt wird. Die clear Befehle werden verwendet, um LSP- und Schnittstellenzähler auf Null zurückzusetzen, sodass die Werte den Betrieb der Lastenausgleichskonfiguration widerspiegeln.

Action!

Um den Lastenausgleich über Schnittstellen und LSPs hinweg zu überprüfen, verwenden Sie den folgenden Befehl auf dem Eingangsrouter:

Verwenden Sie die folgenden Befehle auf einem Transitrouter, um den Lastenausgleich über Schnittstellen und LSPs hinweg zu überprüfen:

Beispielausgabe

Befehlsname

Die folgende Beispielausgabe bezieht sich auf die Konfiguration auf dem Eingangsrouter R1:

Bedeutung

Die Beispielausgabe für den Befehl auf dem show configuration Eingangsrouter R1 zeigt, dass der Lastenausgleich mit der lbpp policy-Anweisung korrekt konfiguriert ist. Außerdem wird die lbpp Richtlinie auf Hierarchieebene [edit routing-options] in die Weiterleitungstabelle exportiert.

Beispielausgabe

Die folgende Beispielausgabe stammt vom Transitrouter R2:

Bedeutung

Die Beispielausgabe für den Befehl, der auf dem show route Transitrouter R2 ausgegeben wird, zeigt die beiden Pfade mit gleichen Kosten (so-0/0/1 und so-0/0/2) durch das Netzwerk zur Loopback-Adresse zu R0 (192.168.0.1). Obwohl die rechte spitze Klammer (>) normalerweise die aktive Route anzeigt, ist dies in diesem Fall nicht der Fall, wie in den folgenden vier Beispielausgaben gezeigt.

Beispielausgabe

Die folgende Beispielausgabe stammt vom Transitrouter R2:

Bedeutung

Die Beispielausgabe für den Befehl, der auf dem monitor interface traffic Transitrouter R2 ausgegeben wird, zeigt, dass der Ausgabedatenverkehr gleichmäßig auf die beiden Schnittstellen so-0/0/1 verteilt ist und so-0/0/2.

Beispielausgabe

Die folgende Beispielausgabe stammt vom Transitrouter R2:

Bedeutung

Die Beispielausgabe für den Befehl, der auf dem show mpls lsp statistics Transitrouter R2 ausgegeben wird, zeigt, dass der Ausgabedatenverkehr gleichmäßig auf die vier LSPs verteilt ist, die auf dem Eingangsrouter R6konfiguriert sind.

Beispielausgabe

Die folgende Beispielausgabe stammt vom Transitrouter R2:

Bedeutung

Die Beispielausgabe für den Befehl, der auf dem show route forwarding-table destinationType Transitrouter R2ausgegeben wird, wird im Feld angezeigt ulst , was darauf hinweist, dass der Lastenausgleich funktioniert. Die beiden Unicasteinträgeucst) ( Type im Feld sind die beiden nächsten Hops für die LSPs.

Beispielausgabe

Die folgende Beispielausgabe stammt vom Transitrouter R2:

Bedeutung

Die Beispielausgabe für den Befehl, der auf dem show route forwarding-table | find mpls Transitrouter R2 ausgegeben wird, zeigt die MPLS-Routingtabelle, die die von diesem Router empfangenen und zum Weiterleiten von Paketen an den Next-Hop-Router verwendeten Bezeichnungen enthält. Diese Routing-Tabelle wird hauptsächlich auf Transitroutern verwendet, um Pakete entlang eines LSP an den nächsten Router weiterzuleiten. Die ersten drei Bezeichnungen in der Destination Spalte (Beschriftung 0, Beschriftung 1 und Beschriftung 2) werden automatisch von MPLS eingegeben, wenn das Protokoll aktiviert wird. Bei diesen Bezeichnungen handelt es sich um reservierte MPLS-Bezeichnungen, die in RFC 3032 definiert sind. Label 0 ist die explizite IPv4-NULL-Bezeichnung. Bezeichnung 1 ist das MPLS-Äquivalent der IP-Router-Warnungsbezeichnung, und Bezeichnung 2 ist die explizite IPv6-Nullbezeichnung.

Bei den verbleibenden fünf Bezeichnungen in der Destination Spalte handelt es sich um nicht reservierte Bezeichnungen, die der Router zum Weiterleiten des Datenverkehrs verwendet, und in der letzten Spalte Netifwerden die Schnittstellen angezeigt, die zum Senden des gekennzeichneten Datenverkehrs verwendet werden. Bei nicht reservierten Bezeichnungen wird in der zweiten Type Spalte der Vorgang angezeigt, der für übereinstimmende Pakete ausgeführt wurde. In diesem Beispiel werden alle nicht reservierten Pakete gegen ausgehende Paketbezeichnungen ausgetauscht. Bei Paketen mit der Bezeichnung 100112 wird beispielsweise die Bezeichnung ausgetauscht 100032 , bevor sie aus der Schnittstelle so-0/0/1.0verschoben werden.

Überprüfen der Funktionsweise des Lastenausgleichs mit ungleichmäßiger Bandbreite

Zweck

Wenn ein Router einen Lastenausgleich zu ungleichen Kosten zwischen LSP-Pfaden durchführt, zeigt der Befehl ein Saldofeld an, das show route detail jedem verwendeten nächsten Hop zugeordnet ist.

Action!

Verwenden Sie die folgenden Junos OS CLI-Betriebsmodusbefehle, um zu überprüfen, ob ein RSVP-LSP einen ungleichmäßigen Lastenausgleich aufweist:

Beispielausgabe

Befehlsname

Bedeutung

Die Beispielausgabe des Eingangsrouters R1 zeigt, dass der Datenverkehr entsprechend der LSP-Bandbreitenkonfiguration verteilt wird, wie durch das Balance: xx% Feld angegeben. Beispiel: lsp1 Es ist eine Bandbreite von 10 Mbit/s konfiguriert, wie im Balance: 10% Feld angegeben.

Verwenden Sie den Befehl traceroute, um MPLS-Labels zu überprüfen

Zweck

Sie können den traceroute Befehl verwenden, um zu überprüfen, ob Pakete über den LSP gesendet werden.

Action!

Um MPLS-Bezeichnungen zu überprüfen, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein, wobei host-name sich die IP-Adresse oder der Name des Remote-Hosts befindet:

Beispielausgabe 1

Befehlsname

Beispielausgabe 2

Befehlsname

Bedeutung

Beispielausgabe 1 zeigt, dass MPLS-Labels verwendet werden, um Pakete über das Netzwerk weiterzuleiten. In der Ausgabe enthalten sind ein Beschriftungswert (MPLS Label=100048), der Time-to-Live-Wert (TTL=1) und der Stack-Bit-Wert (S=1).

Das MPLS Label Feld wird verwendet, um das Paket für einen bestimmten LSP zu identifizieren. Es handelt sich um ein 20-Bit-Feld mit einem Maximalwert von (2^^20-1) oder ungefähr 1.000.000.

Der TTL-Wert enthält eine Begrenzung für die Anzahl der Hops, die dieses MPLS-Paket durch das Netzwerk übertragen kann (1). Sie wird bei jedem Hop dekrementiert, und wenn der TTL-Wert unter eins fällt, wird das Paket verworfen.

Der untere Teil des Stack-Bitwerts (S=1) gibt an, dass dies das letzte Label im Stack ist und dass diesem MPLS-Paket ein Label zugeordnet ist. Die MPLS-Implementierung im Junos OS unterstützt eine Stacking-Tiefe von 3 auf den Routern der M-Serie und bis zu 5 auf den Plattformen der T-Serie. Weitere Informationen zum MPLS-Label-Stacking finden Sie unter RFC 3032, MPLS Label Stack Encoding.

MPLS-Bezeichnungen werden in Beispielausgabe 1 angezeigt, da der traceroute Befehl an ein BGP-Ziel ausgegeben wird, wobei der nächste BGP-Hop für diese Route die LSP-Ausgangsadresse ist. Das Standardverhalten von Junos OS verwendet LSPs für BGP-Datenverkehr, wenn der nächste BGP-Hop der LSP-Ausgangsadresse entspricht.

Beispielausgabe 2 zeigt, dass MPLS-Beschriftungen nicht in der Ausgabe für den traceroute Befehl angezeigt werden. Wenn der nächste BGP-Hop nicht mit der LSP-Ausgangsadresse übereinstimmt oder das Ziel eine IGP-Route ist, verwendet der BGP-Datenverkehr den LSP nicht. Anstatt den LSP zu verwenden, verwendet der BGP-Datenverkehr den IGP (IN DIESEM FALL IS-IS), um die Ausgangsadresse (R6) zu erreichen.

Fehlerbehebung bei GMPLS und GRE-Tunnel

Problem

Beschreibung

Der logische Steuerkanal für GMPLS muss eine Punkt-zu-Punkt-Verbindung sein und über eine IP-Erreichbarkeit verfügen. Verwenden Sie auf Broadcast-Schnittstellen oder bei mehreren Hops zwischen Steuerkanalpeers einen GRE-Tunnel für den Steuerkanal. Ausführlichere Informationen zu GMPLS- und GRE-Tunneln finden Sie im Konfigurationshandbuch für Junos MPLS-Anwendungen und im Junos-Benutzerhandbuch.

Ein Tunnel-PIC ist nicht erforderlich, um einen GRE-Tunnel für den GMPLS-Steuerkanal zu konfigurieren. Verwenden Sie stattdessen die softwarebasierte gre Schnittstelle anstelle der hardwarebasierten gr-fpc/pic/port Schnittstelle.

VORSICHT:

Aufgrund von Einschränkungen der softwarebasierten gre Schnittstelle ist der GMPLS-Steuerkanal die einzige unterstützte Verwendung der softwarebasierten gre Schnittstelle. Jede andere Verwendung wird ausdrücklich nicht unterstützt und kann zu einem Anwendungsfehler führen.

Das folgende Beispiel zeigt eine grundlegende gre Schnittstellenkonfiguration. In diesem Fall ist die Tunnelquelle die Loopback-Adresse des lokalen Routers und die Zieladresse das Loopback-Ziel des Remote-Routers. Datenverkehr, der einen nächsten Hop des Tunnelziels hat, verwendet den Tunnel. Der Tunnel wird nicht automatisch vom gesamten Datenverkehr verwendet, der die Schnittstelle passiert. Nur der Datenverkehr mit dem Tunnelziel als nächster Hop verwendet den Tunnel.

Beispielausgabe

Beispielausgabe

Die folgende Beispielausgabe für den Befehl show interfaces zeigt den Kapselungstyp und den Header, die maximale Geschwindigkeit, Pakete über die logische Schnittstelle, das Ziel und die logische Adresse.

Im Folgenden finden Sie verschiedene Anforderungen, wenn Sie einen GMPLS-LSP mit einem GRE-Tunnel konfigurieren:

  • Der Datenkanal muss auf demselben Schnittstellentyp beginnen und enden.

  • Bei dem Steuerkanal kann es sich um einen GRE-Tunnel handeln, der auf demselben oder einem anderen Schnittstellentyp beginnt und endet.

  • Der GRE-Tunnel muss indirekt mit der peer-interface peer-name Anweisung auf Hierarchieebene [edit protocol ospf] konfiguriert werden.

  • Die GRE-Schnittstelle muss auf den [edit protocols ospf] Hierarchieebenen und [edit protocols rsvp] deaktiviert sein.

  • Daten- und Steuerkanäle müssen in der LMP-Konfiguration korrekt definiert sein.

  • Es ist optional, Constrained Shortest Path First (CSPF) mit der no-cspf Anweisung zu deaktivieren.

Dieser Fall konzentriert sich auf die falsche Konfiguration der Endpunkte des GRE-Tunnels. Sie können jedoch einen ähnlichen Prozess und ähnliche Befehle verwenden, um andere GRE-Tunnelprobleme zu diagnostizieren. Abbildung 13 veranschaulicht eine Netzwerktopologie mit MPLS, das über eine GRE-Schnittstelle getunnelt wird.

Abbildung 13: GMPLS-NetzwerktopologieGMPLS-Netzwerktopologie

Die MPLS-Netzwerktopologie zeigt Router von Abbildung 13 Juniper Networks, die mit einem GRE-Tunnel konfiguriert sind, der aus den folgenden Komponenten besteht:

  • Ein strikter GMPLS-LSP-Pfad vom Eingangsrouter zum Ausgangsrouter.

  • Auf dem Eingangsrouter wurde CSPF mit der no-cspf Anweisung auf der Hierarchieebene [edit protocol mpls label-switched-path lsp-name] deaktiviert.

  • Traffic-Engineering-Links und Steuerkanäle innerhalb der peer Anweisung auf der Hierarchieebene [edit protocols link-management] auf allen Routern.

  • OSPF und OSPF Traffic Engineering auf allen Routern konfiguriert.

  • Ein Verweis auf die peer-interface in OSPF und RSVP auf allen Routern.

  • Ein Switching-Problem zwischen R2 und R3.

Symptom

Der LSP im Netzwerk Abbildung 13 ist ausgefallen, wie durch die Ausgabe der Befehle und show rsvp session angezeigt wird, die show mpls lspsehr ähnliche Informationen anzeigen. Der show mpls lsp Befehl zeigt alle auf dem Router konfigurierten LSPs sowie alle Transit- und Ausgangs-LSPs an. Der show rsvp session Befehl zeigt zusammenfassende Informationen zu RSVP-Sitzungen an. Sie können beide Befehle verwenden, um den Status des LSP zu überprüfen. In diesem Fall ist LSP gmpls-r1-to-r3 nicht verfügbar (Dn).

Beispielausgabe

Verursachen

Die Ursache des Problems mit dem GMPLS LSP ist die Konfiguration unterschiedlicher Schnittstellentypen an beiden Enden des GMPLS-Datenkanals.

Befehle zur Fehlerbehebung

Das Junos-Betriebssystem enthält Befehle, die bei der Fehlerbehebung hilfreich sind. Dieses Thema enthält eine kurze Beschreibung der einzelnen Befehle, gefolgt von einer Beispielausgabe und einer Erläuterung der Ausgabe in Bezug auf das Problem.

Sie können die folgenden Befehle verwenden, wenn Sie ein GMPLS-Problem beheben:

Beispielausgabe

Verwenden Sie den Befehl show mpls lsp extensive auf dem Transitrouter R1, um detaillierte Informationen zu allen LSPs anzuzeigen, die auf dem Router übertragen, beendet und konfiguriert werden.

Bedeutung

Die Beispielausgabe für den show mpls lsp extensive Befehl zeigt eine Fehlermeldung (MPLS label allocation failure) im Protokollabschnitt der Ausgabe. Dieses LSP-Ereignis weist darauf hin, dass das MPLS-Protokoll oder die family mpls Anweisung nicht ordnungsgemäß konfiguriert wurden. Wenn dem LSP-Ereignis eine IP-Adresse vorangestellt ist, handelt es sich bei der Adresse in der Regel um den Router, bei dem der MPLS-Konfigurationsfehler aufgetreten ist. In diesem Fall scheint der Router mit der lo0 Adresse 192.168.4.1 (R3) einen MPLS-Konfigurationsfehler zu haben.

Beispielausgabe

Verwenden Sie den Befehl show rsvp session detail, um detaillierte Informationen zu RSVP-Sitzungen anzuzeigen.

Bedeutung

Die Beispielausgabe für den show rsvp session detail Befehl zeigt, dass LSP gmpls-r1-to-r3 ausgefallen ist (LSPstate: Dn). Der Routendatensatz ist unvollständig und weist auf ein Problem mit der expliziten Route 100.100.100.100 93.93.93.93hin. Die Adresse 100.100.100.100 ist der Datenkanal am R2 so-0/0/0und die Adresse 93.93.93.93 ist der Datenkanal am R3.

Beispielausgabe

Verwenden Sie den Befehl show link-management peer, um MPLS-Peer-Link-Informationen anzuzeigen.

Bedeutung

Die Beispielausgabe aller Router im Beispielnetzwerk für Abbildung 13 den show link-management peer Befehl zeigt, dass alle Steuerkanäle aktiv sind. Eine detaillierte Analyse der Ausgabe zeigt die folgenden Informationen:

  • Name des Peers oder tester3, der auf benachbarten Routern identisch ist, tester2 um die Fehlerbehebung zu erleichtern.

  • Interner Bezeichner für den Peer, 48428 for tester2 und 48429 for tester3. Der interne Bezeichner ist ein Wertebereich von 0 bis 64.000.

  • Der Status des Peers, der "Up" oder "Down" sein kann. In diesem Fall sind alle Peers aktiv.

  • Die Adresse, zu der ein Steuerkanal aufgebaut wird, z.B. 10.35.1.5.

  • Der Status des Steuerkanals, der aktiv, inaktiv oder aktiv sein kann.

  • Die verkehrtechnischen Verbindungen, die von ihrem Peer verwaltet werden, was darauf hinweist, dass der Steuerungskanal gre.0 von verwaltet wird tester3.

Beispielausgabe

Verwenden Sie den Befehl show link-management te-link, um die Ressourcen anzuzeigen, die zum Einrichten von MPLS-Weiterleitungspfaden (Multiprotocol Label Switching) verwendet werden.

Bedeutung

Die Beispielausgabe für den Befehl, der show link-management te-link auf den drei Routern im Netzwerk in Abbildung 13 ausgegeben wird, zeigt die Ressourcen, die den verkehrgesteuerten Verbindungen te-tester2 und te-tester3zugewiesen sind. Die Ressourcen sind die SONET-Schnittstellen so-0/0/0 und so-0/0/1. On und R2, tdie R1 SONET-Schnittstellen werden für den LSP gmpls-r1-to-r3verwendet, wie im YesUsed Feld angegeben.Die eingeschaltete SONET-Schnittstelle so-0/0/1 ist jedoch inaktiv (Dn) und wird nicht für den LSP (Used No) verwendet.R3 Weitere Untersuchungen sind erforderlich, um herauszufinden, warum die SONET-Schnittstelle nicht R3 verfügbar ist.

Probe Outut

Verwenden Sie den Befehl show log filename , um den Inhalt der angegebenen Protokolldatei anzuzeigen. In diesem Fall wird die Protokolldatei rsvp.log auf der Hierarchieebene [edit protocols rsvp traceoptions] konfiguriert. Wenn die Protokolldatei konfiguriert ist, müssen Sie den Befehl monitor start filename absetzen, um mit der Protokollierung von Meldungen in der Datei zu beginnen.

HINWEIS:

Die find Error Option, die nach dem senkrechten Strich ( | eingegeben wird, durchsucht die Ausgabe nach einer Instanz des Begriffs Error.

Beispielausgabe

Bedeutung

Die Beispielausgabe des Ausgangsrouters R3 für den show log rsvp.log Befehl ist ein Ausschnitt aus der Protokolldatei. Der Codeausschnitt zeigt eine LMP-Ressourcenanforderung (Link Management Protocol) für den LSP gmpls-r1-to-r3. Die Anforderung weist Probleme mit dem Codierungstyp (SDH/SONET) auf, was auf einen möglichen Fehler bei der Verbindung R2 von und durch R3die SONET-Schnittstelle hinweist. Weitere Untersuchungen der Konfiguration des LMP sind R2R3 erforderlich.

Beispielausgabe

Verwenden Sie den Befehl show configuration statement-path , um eine bestimmte Konfigurationshierarchie anzuzeigen, in diesem Fall link-management.

Bedeutung

Die Beispielausgabe von Transitrouter R2 und Eingangsrouter R3 für den show configuration protocols link-management Befehl zeigt, dass der Schnittstellentyp auf den beiden Routern unterschiedlich ist. Die Ressource te-tester3 , die dem Transitrouter R2 zugewiesen ist, ist eine SONET-Schnittstelle, während die Ressource te-tester3 , die dem Ausgangsrouter R3 zugewiesen ist, eine ATM-Schnittstelle ist. Der Schnittstellentyp an beiden Enden der Daten- oder Steuerkanäle muss vom gleichen Typ sein. In diesem Fall sollten beide Enden SONET oder ATM sein.

Lösung

Lösung

Die Lösung für das Problem der unterschiedlichen Schnittstellen- oder Verkapselungstypen an beiden Enden des GMPLS LSP besteht darin, sicherzustellen, dass der Schnittstellentyp an beiden Enden gleich ist. In diesem Fall wurde die ATM-Schnittstelle aus der Link-Management-Konfiguration R3gelöscht und stattdessen eine SONET-Schnittstelle konfiguriert.

Die folgenden Befehle veranschaulichen die korrekte Konfiguration und die Befehle, um zu überprüfen, ob der GMPLS LSP aktiv ist und den Datenkanal verwendet:

Beispielausgabe

Bedeutung

Die Beispielausgabe für , und show link-management te-link die show protocols link-managementshow mpls lspBefehle des Eingangsrouters R3 zeigen, dass das Problem behoben ist. LMP ist korrekt konfiguriert, und der Sprachdienstleister gmpls-r1-to-r3 ist aktiv und verwendet den Datenkanal so-0/0/1.

Fazit

Zusammenfassend lässt sich sagen, dass beide Enden eines GMPLS-Datenkanals den gleichen Verkapselungs- oder Schnittstellentyp aufweisen müssen. Dieser Fall veranschaulicht die korrekte Konfiguration des Datenkanals. Die Prinzipien sind für den Steuerkanal die gleichen.

Router-Konfigurationen

Ausgabe, die die Konfigurationen des Eingangsrouters im Netzwerk anzeigt. Die no-more nach der Pipe ( | eingegebene Option ) verhindert, dass die Ausgabe paginiert wird, wenn die Ausgabe länger als die Länge des Terminalbildschirms ist.

Beispielausgabe

Die folgende Beispielausgabe bezieht sich auf den Eingangsrouter R1:

Beispielausgabe

Die folgende Beispielausgabe bezieht sich auf den Transitrouter R2:

Beispielausgabe

Die folgende Beispielausgabe bezieht sich auf den Ausgangsrouter R3:

Ermitteln des LSP-Status

Zeigen Sie detaillierte Informationen zu RSVP-Objekten (Resource Reservation Protocol) und dem LSP-Verlauf (Label Switched Path) an, um ein Problem mit dem LSP zu ermitteln.

Abbildung 14 Veranschaulicht die in diesem Thema verwendete Netzwerktopologie.

Abbildung 14: MPLS-NetzwerktopologieMPLS-Netzwerktopologie

Gehen Sie folgendermaßen vor, um den LSP-Status zu bestimmen:

Überprüfen Sie den Status des Sprachdienstleisters

Zweck

Zeigen Sie den Status des Label-Switched-Pfades (LSP) an.

Action!

Um den LSP-Status zu ermitteln, geben Sie auf dem Eingangsrouter den folgenden CLI-Befehl (Junos OS-Befehlszeilenschnittstelle) für den Betriebsmodus ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe stammt vom Eingangsrouter (R1) und zeigt Eingangs-, Ausgangs- und Transit-LSP-Informationen an. Die Eingangsinformationen beziehen sich auf die Sitzungen, die von diesem Router stammen, die Ausgangsinformationen beziehen sich auf Sitzungen, die auf diesem Router beendet werden, und die Transitinformationen beziehen sich auf Sitzungen, die über diesen Router geleitet werden.

Es gibt eine Eingangsroute von R1 (10.0.0.1) nach R6 (10.0.0.6). Diese Route ist derzeit aktiv und ist eine aktive Route, die in der Routing-Tabelle installiert ist (Rt). Der LSP R1-to-R6 ist der primäre Pfad (P) im Gegensatz zum sekundären Pfad und wird durch ein Sternchen (*) gekennzeichnet. Die Route zu R6 enthält keinen benannten Pfad (ActivePath).

Es gibt einen Ausgangs-LSP von R6 bis . R1 Es State sind keine Routen in der Routing-Tabelle installiert. Der RSVP-Reservierungsstil (Style) besteht aus zwei Teilen. Die erste ist die Anzahl der aktiven Reservierungen (1). Der zweite ist der Reservierungsstil, der (fester Filter) ist FF . Der Reservierungsstil kann , SE (shared explicit) oder WF (Platzhalterfilter) seinFF. Für diesen LSP gibt es drei eingehende Labels (Labelin) und keine ausgehenden Labels (Labelout).

Es gibt keine Transit-LSPs.

Weitere Informationen zum Überprüfen des LSP-Status finden Sie unter Prüfliste für die Arbeit mit dem MPLS-Fehlerbehebungsmodell mit mehreren Ebenen.

Zeigen Sie den umfangreichen Status des LSP an

Zweck

Zeigen Sie umfassende Informationen zu LSPs an, einschließlich des gesamten bisherigen Statusverlaufs und der Gründe, warum ein LSP möglicherweise ausgefallen ist.

Action!

Um umfangreiche Informationen zu LSPs anzuzeigen, geben Sie auf dem Eingangsrouter den folgenden Junos OS CLI-Betriebsmodusbefehl ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe stammt vom Eingangsrouter (R1) und zeigt Eingangs-, Ausgangs- und Transit-LSP-Informationen im Detail, einschließlich des gesamten bisherigen Zustandsverlaufs und der Gründe, warum ein LSP fehlgeschlagen ist. Die Eingangsinformationen beziehen sich auf Sitzungen, die von diesem Router stammen, die Ausgangsinformationen beziehen sich auf Sitzungen, die auf diesem Router beendet werden, und die Transitinformationen beziehen sich auf Sitzungen, die über diesen Router geleitet werden.

Es gibt eine Eingangsroute von R1 (10.0.0.1) nach R6 (10.0.0.6). Diese Route ist derzeit aktiv (State), wobei eine Route aktiv den LSP verwendet, R1-to-R6. Der aktive LSP-Pfad ist der primäre Pfad. Auch wenn der LSP kein primary oder-Schlüsselwort secondary enthält, behandelt der Router den LSP weiterhin als primären LSP, was darauf hinweist, dass der Router bei einem Ausfall des LSP standardmäßig versucht, inaktive LSPs in Intervallen von 30 Sekunden zu signalisieren.

Load Balancing ist Random, was die Standardeinstellung ist, was darauf hinweist, dass der Router bei der Auswahl des physischen Pfads für einen LSP nach dem Zufallsprinzip zwischen Pfaden mit gleichen Kosten und gleicher Hop-Anzahl auswählt. Weitere Optionen, die Sie konfigurieren können, sind Least-fill und Most-fill. Least-fill platziert den LSP über den am wenigsten genutzten Link der Pfade mit gleichen Kosten und gleicher Hopanzahl. Most-fill platziert den LSP über den am häufigsten genutzten Link der Pfade mit gleichen Kosten, die eine gleiche Hopanzahl aufweisen. Die Auslastung basiert auf dem Prozentsatz der verfügbaren Bandbreite.

In diesem Encoding type Feld werden die Signalparameter fürPacket)Generalized MPLS (GMPLS) (, die IPv4 angeben. Das Switching type ist Packet, und der Generalized Payload Identifier (GPID) ist IPv4.

Der primäre Pfad ist der aktive Pfad, der durch ein Sternchen (*) gekennzeichnet ist. Der Status des LSP ist Up.

Das Explicit Route Object (ERO) enthält die CSPF-Kosten20(Constrained Shortest Path First) für den physischen Pfad, dem der LSP folgt. Das Vorhandensein der CSPF-Metrik gibt an, dass es sich um einen CSPF-LSP handelt. Das Fehlen der CSPF-Metrik weist auf einen LSP ohne CSPF hin.

Das Feld 10.1.13.2 S zeigt die tatsächliche ERO an. Die RSVP-Signalisierungsnachrichten gingen an 10.1.13.2 strictly (als nächster Hop) und endeten bei 10.1.36.2 strict. Alle ERO-Adressen sind strikte Hops, wenn es sich bei dem LSP um einen CSPF-LSP handelt. Lose Hops können nur in einem LSP ohne CSPF angezeigt werden.

Das empfangene Datensatz-Routenobjekt (RRO) verfügt über die folgenden Schutzflags:

  • 0x01—Lokaler Schutz verfügbar. Die Verbindung stromabwärts dieses Knotens ist durch einen lokalen Reparaturmechanismus geschützt. Dieses Flag kann nur gesetzt werden, wenn das Flag Lokaler Schutz im SESSION_ATTRIBUTE Objekt der entsprechenden Pfadnachricht gesetzt wurde.

  • 0x02—Lokaler Schutz im Einsatz. Ein lokaler Reparaturmechanismus wird verwendet, um diesen Tunnel aufrechtzuerhalten (in der Regel aufgrund eines Ausfalls der Verbindung, über die er zuvor geroutet wurde).

  • 0x04— Bandbreitenschutz. Der Downstream-Router verfügt über einen Backup-Pfad, der die gleiche Bandbreitengarantie wie der geschützte LSP für den geschützten Bereich bietet.

  • 0x08– Knotenschutz. Der Downstream-Router verfügt über einen Backup-Pfad, der Schutz vor Verbindungs- und Knotenausfällen auf dem entsprechenden Pfadabschnitt bietet. Wenn der Downstream-Router nur einen Backup-Pfad für den Link-Schutz einrichten kann, wird das Bit "Lokaler Schutz verfügbar" gesetzt, aber das Bit "Knotenschutz" wird gelöscht.

  • 0x10—Vorzeitige Entfernung ausstehend. Der Preempting-Knoten legt dieses Flag fest, wenn eine ausstehende vorzeitige Entfernung für den Traffic Engineering-LSP ausgeführt wird. Dies zeigt dem Eingangslabel-Edge-Router (LER) dieses LSP an, dass er umgeleitet werden sollte.

Weitere Informationen zu Schutzflags finden Sie in der Junos Routing Protocols and Policies Command Reference.

Das Feld 10.1.13.2.10.1.36.2 ist die tatsächlich empfangene Datensatzroute (RRO). Beachten Sie, dass die Adressen im RRO Feld mit denen im ERO Feld übereinstimmen. Dies ist der Normalfall für CSPF-LSPs. Wenn die RRO- und ERO-Adressen für einen CSPF-LSP nicht übereinstimmen, muss der LSP umleiten oder umleiten.

Die Zeilen mit den Nummern 91 bis 42 enthalten die 49 letzten Einträge im Verlaufsprotokoll. Jede Zeile ist mit einem Zeitstempel versehen. Die neuesten Einträge haben die größte Protokollverlaufsnummer und befinden sich am Anfang des Protokolls, was darauf hinweist, dass Zeile 91 der neueste Protokolleintrag ist. Wenn Sie das Protokoll lesen, beginnen Sie mit dem ältesten Eintrag (42) bis zum neuesten (91).

Das Verlaufsprotokoll wurde am 10. Juli gestartet und zeigt die folgende Abfolge von Aktivitäten an: Ein LSP wurde als aktiv ausgewählt, es wurde festgestellt, dass er nicht verfügbar ist, die MPLS-Labelzuweisung schlug mehrmals fehl, wurde mehrmals gelöscht, wurde wegen eines ResvTear vorzeitig entfernt, wurde als aktiv abgewählt und gelöscht. Am Ende berechnete der Router eine CSPF-ERO, signalisierte den Anruf, der LSP kam mit dem aufgeführten RRO (Leitung 90) und wurde als aktiv aufgeführt.

Weitere Informationen zu Fehlermeldungen finden Sie in der Protokollreferenz des Junos MPLS Network Operations Guide.

Die Gesamtzahl der angezeigten Eingangs-LSPs ist 1, mit 1 up und 0 down. Die Zahl im Up Feld plus die Zahl im Down Feld sollte der Summe entsprechen.

Es gibt eine Ausgangs-LSP-Sitzung von R6 bis . R1 Es State sind keine Routen in der Routing-Tabelle installiert. Der RSVP-Reservierungsstil (Style) besteht aus zwei Teilen. Die erste ist die Anzahl der aktiven Reservierungen (1). Der zweite ist der Reservierungsstil, der (fester Filter) ist FF . Der Reservierungsstil kann , SE (shared explicit) oder WF (Platzhalterfilter) seinFF. Für diesen LSP gibt es drei eingehende Labels (Labelin) und keine ausgehenden Labels (Labelout).

Es gibt keine Transit-LSPs.

Weitere Informationen zum Überprüfen des LSP-Status finden Sie unter Prüfliste für die Arbeit mit dem MPLS-Fehlerbehebungsmodell mit mehreren Ebenen.

Überprüfen, ob RSVP-Pfadnachrichten gesendet und empfangen werden

Zweck

Das Vorhandensein oder Fehlen verschiedener RSVP-Nachrichten kann dabei helfen, festzustellen, ob ein Problem mit Multiprotocol Label Switching (MPLS) in Ihrem Netzwerk vorliegt. Wenn z. B. Pfadnachrichten in der Ausgabe ohne Resv-Nachrichten auftreten, kann dies darauf hindeuten, dass keine label-switched-Pfade (LSPs) erstellt werden.

Action!

Um zu überprüfen, ob RSVP-Pfadnachrichten gesendet und empfangen werden, geben Sie den folgenden Befehl für den Betriebsmodus der Befehlszeilenschnittstelle (CLI) von Junos OS ein:

Beispielausgabe

Befehlsname

Bedeutung

Die Beispielausgabe zeigt gesendete und empfangene RSVP-Nachrichten. Die Gesamtzahl der RSVP-Path-Nachrichten beträgt 11,4532 gesendet und 80,185 empfangen. Innerhalb der letzten 5 Sekunden wurden keine Nachrichten gesendet oder empfangen.

Insgesamt wurden 5 PathErr Nachrichten gesendet und 10 empfangen. Wenn Pfadfehler auftreten (in der Regel aufgrund von Parameterproblemen in einer Pfadnachricht), sendet der Router eine Unicast-PathErr-Nachricht an den Absender, der die Pfadnachricht ausgegeben hat. In diesem Fall R1 wurden mindestens 10 Pfadnachrichten mit einem Fehler gesendet, wie durch die 10 empfangenen PathErr-Nachrichten R1 angezeigt. Der Downstream-Router hat fünf Pfadnachrichten mit einem Fehler gesendet R1 , wie durch die fünf gesendeten PathErr-Nachrichten R1 angezeigt wird. PathErr-Nachrichten werden in die entgegengesetzte Richtung zu Pfadnachrichten übertragen.

Insgesamt wurden 12 PathTear Nachrichten gesendet und 6 empfangen, keine in den letzten 5 Sekunden. Im Gegensatz zu PathErr-Nachrichten werden PathTear-Nachrichten in die gleiche Richtung wie Pfadnachrichten gesendet. Da Pfadnachrichten sowohl gesendet als auch empfangen werden, werden auch PathTear-Nachrichten gesendet und empfangen. Wenn jedoch nur Pfadnachrichten gesendet werden, werden nur die gesendeten PathTear-Nachrichten in der Ausgabe angezeigt.

Insgesamt wurden 80.515 Reservierungsnachrichten (Resv) mit dem Reservierungsstil mit festem Filter (FF) gesendet und 111.476 empfangen, keine in den letzten 5 Sekunden. Ein FF Reservierungsstil gibt an, dass innerhalb jeder Sitzung jeder Empfänger seine eigene Reservierung bei jedem Upstreamsender einrichtet und dass alle ausgewählten Absender aufgelistet werden. Es werden keine Nachrichten für den Platzhalterfilter (WF) oder freigegebene explizite (SE) Reservierungsstile gesendet oder empfangen. Weitere Informationen zu RSVP-Reservierungsstilen finden Sie im Konfigurationshandbuch für Junos MPLS-Anwendungen.

Andere RSVP-Nachrichtentypen werden nicht gesendet oder empfangen. Weitere Informationen zu den Nachrichtentypen ResvErr, ResvTear und Resvconf finden Sie im Konfigurationshandbuch für Junos MPLS-Anwendungen.

Bestätigungs- und Zusammenfassungsaktualisierungsmeldungen (SRefresh) werden nicht in der Ausgabe angezeigt. Bestätigungs- und Zusammenfassungsaktualisierungsnachrichten sind in RFC 2961 definiert und Teil der RSVP-Erweiterungen. Bestätigungsnachrichten werden verwendet, um die Menge des RSVP-Steuerungsdatenverkehrs im Netzwerk zu reduzieren.

Insgesamt wurden 915.851 Hallo-Nachrichten gesendet und 915.881 empfangen, wobei in den letzten 5 Sekunden keine gesendet oder empfangen wurde. Das Antwort-Hallo-Intervall beträgt 9 Sekunden. Wenn in den letzten 5 Sekunden mehr als eine Hallo-Nachricht gesendet oder empfangen wird, bedeutet dies, dass mehr als eine Schnittstelle RSVP unterstützt.

EndtoEnd RSVP-Nachrichten sind ältere RSVP-Nachrichten, die nicht für RSVP-Traffic-Engineering verwendet werden. Diese Leistungsindikatoren werden nur erhöht, wenn RSVP ältere RSVP-Nachrichten weiterleitet, die von einem VPN-Kunden (Virtual Private Network) zur Übertragung über das Backbone an die anderen Standorte im VPN ausgegeben wurden. Sie werden als End-to-End-Nachrichten bezeichnet, da sie für die gegenüberliegende Seite des Netzwerks bestimmt sind und nur an den beiden Enden des Provider-Netzwerks eine Bedeutung haben.

Der Errors Abschnitt der Ausgabe zeigt Statistiken über RSVP-Pakete mit Fehlern. Insgesamt wurden 15 PathErr to client Pakete an die Routing-Engine gesendet. Die Summe kombiniert die gesendeten und empfangenen PathErr Pakete.