Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Fehlerbehebung BGP Sitzungen

Checkliste zur Prüfung des BGP Und Peers

Zweck

Tabelle 1 Bietet Links und Befehle, um zu prüfen, ob die Border Gateway Protocol (BGP) auf einem Juniper Networks-Router in Ihrem Netzwerk korrekt konfiguriert wurden, das interne Border Gateway Protocol (IBGP) und das Andernnetzwerk Border Gateway Protocol (EBGP) Sitzungen ordnungsgemäß eingerichtet wurden, die externen Routen werden korrekt ausgeschrieben und empfangen und der Pfadauswahlprozess von BGP funktioniert ordnungsgemäß.

Aktion

 

Tabelle 1: Checkliste zur Prüfung des BGP Und Peers

Aufgaben

Befehl oder Aktion

Überprüfung von BGP Peers
  1. Überprüfung der BGP auf einem internen Router

show configuration

  1. Überprüfung der BGP auf einem Border-Router

show configuration

  1. Geprüfte BGP Routen

show route advertising-protocol bgp neighbor-address

  1. Sicherstellen, dass ein bestimmter BGP Route auf Ihrem Router empfangen wird

show route receive-protocol bgp neighbor-address

Prüfung BGP Routen und Routenauswahl  
  1. Prüfung der lokalen Einstellungsauswahl

show route destination-prefix < detail >

  1. Prüfung von Multiple Exit Discriminator Route-Auswahl

show route destination-prefix < detail >

  1. Prüfung des EBGP über IBGP-Auswahl

show route destination-prefix < detail >

  1. Prüfung der IGP Kostenauswahl

show route destination-prefix < detail >

Prüfung von Routen in der Weiterleitungstabelle

show route forwarding-table

Überprüfung von BGP Peers

Zweck

Wenn alle Router für BGP richtig konfiguriert sind, können Sie überprüfen, ob IBGP- und EBGP-Sitzungen ordnungsgemäß eingerichtet wurden, externe Routen werden richtig ausgeschrieben und empfangen, und der BGP-Pfadauswahlprozess funktioniert ordnungsgemäß.

Abbildung 1 zeigt ein Beispiel für BGP Netzwerktopologie in diesem Thema.

Abbildung 1: BGP NetzwerktopologieBGP Netzwerktopologie

Das Netzwerk besteht aus zwei direkt verbundenen ASs, die externe und interne Peers umfassen. Die externen Peers sind direkt über eine gemeinsame Schnittstelle verbunden und führen EBGP aus. Die internen Peers sind über ihre Loopback ( lo0 ) Schnittstellen über IBGP verbunden. AS 65001 wird OSPF ausgeführt AS 65002 wird IS-IS zugrunde IGP. IBGP-Router müssen nicht direkt miteinander verbunden sein, die zugrunde liegenden IGP ermöglichen Nachbarn, einander zu erreichen.

Die beiden Router in AS 65001 enthalten jeweils eine EBGP-Verbindung zu AS 65002 ( und ) über die sie R2R4 aggregierte Präfixe ankündigen: 100.100.1.0, 100.100.2.0 und 100.100.3.0 100.100.4.0 . Außerdem werden für einige Routen mehrere R1R5 Exit Discriminator (MED)-Werte von 5 bzw. 10 ein fügt.

Die internen Router in beiden ASs nutzen eine full Mesh-IBGP-Topologie. Ein vollständiges Mesh ist erforderlich, da die Netzwerke keine Confederations oder Routenreflektoren verwenden, sodass alle über IBGP erlernten Routen nicht an andere interne Nachbarn verteilt werden. Lernt beispielsweise eine Route von, verteilt diese Route nicht auf, da sie über IBGP erlernt wird. Daher muss eine direkte BGP-Verbindung zum Erlernen der Route R3R2R3R6R6R2 haben.

In einer Full-Mesh-Topologie werden diese Informationen nur vom Randrouter, der externe Netzwerkdaten empfängt, BGP an andere Router in seiner AS. Der empfangende Router verteilt diese Informationen nicht an andere IBGP-Router in seinem AS.

Aus Sicht von AS 65002 sollten die folgenden Sitzungen eingerichtet werden:

  • Für die vier Router im AS 65002 sollten IBGP-Sitzungen untereinander eingerichtet werden.

  • R2 sollte eine EBGP-Sitzung mit eingerichtet R1 werden.

  • R4 sollte eine EBGP-Sitzung mit eingerichtet R5 werden.

Gehen Sie wie folgt vor, um die Identität BGP Peers zu überprüfen:

Überprüfung der BGP auf einem internen Router

Zweck

Um die Konfiguration BGP eines internen Routers zu prüfen.

Aktion

Geben Sie den folgenden BGP Junos OS Befehlszeilenschnittstelle (CLI) (CLI) Befehl ein, um die Konfiguration eines internen Routers zu überprüfen:

Die folgende Beispielausgabe für eine BGP Konfiguration auf R3:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt eine grundlegende BGP Konfiguration auf Routern R3R6 und. Das lokale AS (65002) und eine Gruppe ( ) werden auf beiden Routern konfiguriert. Verfügt über drei interne Peers – und – in der [ ] Hierarchieebene. Es gibt außerdem drei interne internalR310.0.0.210.0.0.410.0.0.6protocols bgp group groupR6 Peers: 10.0.0.2und 10.0.0.310.0.0.4 . Das zugrunde liegende IGP Protokoll Intermediate System-to-Intermediate System (IS-IS), und die entsprechenden Schnittstellen werden so konfiguriert, dass es IS-IS.

Beachten Sie, dass in dieser Konfiguration die Router-ID manuell konfiguriert wird, um mehrfache Probleme mit der Router-ID zu vermeiden.

Überprüfung der BGP auf einem Border-Router

Zweck

Um die Konfiguration BGP Randrouter zu prüfen.

Aktion

Geben Sie den folgenden Junos OS CLI Betriebsmodusbefehl ein, um die BGP Konfiguration eines Randrouters zu überprüfen:

Beispielausgabe
Befehlsname

Die folgende Beispielausgabe wird für eine BGP Konfiguration auf zwei Randroutern, R2 und R4 von AS 65002:

Bedeutung

Die Beispielausgabe zeigt eine grundlegende BGP Konfiguration auf Randroutern R2R4 und. Beide Router verfügen über die AS (65002), die auf der [ routing-options ] Hierarchieebene enthalten ist. Jeder Router verfügt über zwei Gruppen auf der [ protocols bgp group group ] Hierarchieebene. Externe Peers werden je nach Router in die externe Gruppe aufgenommen, entweder zu TOR1toR5 oder ( Interne Peers werden in die Gruppe internal aufgenommen. Das zugrunde liegende IGP Protokoll wird IS-IS sowohl auf Routern als auch auf relevanten Schnittstellen zur Ausführung dieser IS-IS.

Beachten Sie, dass in der Konfiguration beider Router die Router-ID manuell konfiguriert wird, um Mehrfachprobleme der Router-ID zu vermeiden. Die Anweisung wird enthalten, um Probleme mit BGP next-hop-self Next-Hop-Erreichbarkeit zu vermeiden.

Geprüfte BGP Routen

Zweck

Sie können festlegen, ob ein bestimmter Route, die Sie konfiguriert haben, einem Nachbarn angeboten wird.

Aktion

Geben Sie den folgenden Betriebsmodusbefehl ein, um die Routinginformationen zu überprüfen Junos OS CLI, die für den angegebenen BGP Nachbar erstellt wurden:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt die aus BGP, die von ihrem R2 Nachbarn ( ) aus angekündigt 10.0.0.4R4 werden. Von 22 Routen in der inet.0 Routing-Tabelle sind 20 aktive Ziele. Keine Routen sind hidden oder in dem hold-down Bundesstaat. Routen befinden sich im Bundesstaat, bevor sie als aktiv erklärt werden, und Routen, die durch eine Routing-Richtlinie abgelehnt werden, können hold-down dem Bundesstaat platziert hidden werden. Die angezeigten Informationen enthalten die Routen, die die Routing-Tabelle in das Routing BGP protokoll exportiert hat.

Sicherstellen, dass ein bestimmter BGP Route auf Ihrem Router empfangen wird

Zweck

Zeigen Sie die Routinginformationen an, die über einen bestimmten Nachbarn empfangen BGP und vom lokalen Router dem Nachbarn angegeben wurden.

Aktion

Geben Sie den folgenden Betriebsmodusbefehl ein Junos OS CLI, um zu überprüfen, ob eine bestimmte Route BGP Router empfangen wird:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt vier BGP Routen von R2 und zwei R4 von. Von den vier Routen von sind nur zwei in der Routingtabelle aktiv, wie durch das Sternchen ( angezeigt), während beide von ihnen empfangenen Routen in der R2*R4 Routingtabelle aktiv sind. Alle BGP kam über die AS 65001.

Prüfung BGP Routen und Routenauswahl

Zweck

Sie können den Auswahlprozess BGP Pfads untersuchen, um den einzelnen, aktiven Pfad zu bestimmen, wenn BGP Routen zum selben Zielpräfix empfängt.

Abbildung 2: BGP NetzwerktopologieBGP Netzwerktopologie

Das Netzwerk zeigt, dass und kündigen die gleichen aggregierten Routen zu und welche zum Erreichen von zwei Routen zum selben Ziel-Präfix führen und Abbildung 2R1R5R2R4,R2R4 empfangen. Der Routenauswahlprozess ermittelt, welche der BGP Routen aktiv sind und an die anderen internen R2R4 Router ausgeschrieben werden ( R3 und R6 ).

Bevor der Router eine Route BGP installiert, muss sichergestellt werden, dass das next-hop BGP attribut erreichbar ist. Wenn der BGP Hop nicht gelöst werden kann, wird die Route nicht installiert. Wenn eine BGP route in der Routingtabelle installiert ist, muss sie einen Pfadauswahlprozess durchgehen, wenn mehrere Routen zum selben Ziel-Präfix vorhanden sind. Der BGP Pfadauswahlprozess erfolgt in folgender Reihenfolge:

  1. Routenpräferenz in der Routingtabelle wird verglichen. Wenn beispielsweise eine OSPF- und eine BGP-Route für ein bestimmtes Ziel vorhanden sind, wird die OSPF-Route als aktive Route ausgewählt, da die OSPF-Route eine Standardpräferenz von 110 auf hat und die BGP-Route eine Standardpräferenz von 170 hat.

  2. Die Routen werden nach lokalen Vorlieben verglichen. Der Route mit den größten lokalen Vorlieben wird bevorzugt. Weitere Informationen finden Sie unter Überprüfen der lokalen Einstellungsauswahl.

  3. Das AS Pfadattribut wird ausgewertet. Der kürzere AS ist bevorzugt.

  4. Der Ursprungscode wird ausgewertet. Der niedrigste Ursprungscode wird bevorzugt ( I (IGP) < E (EGP) < ? (Incomplete) ).

  5. Die MED-Werte werden bewertet. Standardmäßig wird der niedrigste MED-Wert bevorzugt, wenn eine der Routen aus dem gleichen benachbarten AS angegeben wird. Das Fehlen eines MED-Werts wird als MED von 0 interpretiert. Ein Beispiel finden Sie unter Examine the Multiple Exit Discriminator Route Selection (Prüfung der Auswahl mehrerer Exit-Discriminator-Routen).

  6. Die Route wird bewertet, ob sie über EBGP oder IBGP erlernt wird. EBGP-erlernte Routen werden bevorzugt zu IBGP-erlernten Routen. Ein Beispiel finden Sie unter Ebgp über IBGP-Auswahl

  7. Wenn die Route aus IBGP gelernt wird, wird die Route mit den IGP bevorzugt. Ein Beispiel finden Sie unter Kostenauswahl IGP Kosten Der physische nächste Hop zum IBGP-Peer wird gemäß den folgenden drei Regeln installiert:

      1. Nach BGP werden die Routing- und die Routing-Tabellen untersucht. Es wird der physische nächste Hop der Route mit der geringsten inet.0 inet.3 Präferenz verwendet.

      1. Wenn die Einstellungswerte in der Routing-Tabelle und die Routing-Tabellen eine Binde sind, wird der physische nächste Hop der Route inet.0 inet.3 in der inet.3 Routing-Tabelle verwendet.

      1. Wenn eine Einstellungs-Tie in der gleichen Routingtabelle vorhanden ist, wird der physische Nächste Hop der Route mit mehr Pfaden installiert.

  8. Das Cluster-Listenattribut für Route Reflection wird bewertet. Die Clusterliste mit der kürzesten Länge wird bevorzugt. Routen ohne Clusterliste gelten als Clusterlisten mit der Länge 0.

  9. Die Router-ID wird ausgewertet. Die Route vom Peer mit der geringsten Router-ID wird bevorzugt (in der Regel die Loopback-Adresse).

  10. Der Peer-Adresswert wird untersucht. Der Peer mit der geringsten Peer-IP-Adresse wird bevorzugt.

Geben Sie den folgenden Befehl für den Junos OS CLI den Betriebsmodus ein, um den einzelnen, aktiven Pfad zu bestimmen, wenn BGP routen zum selben Zielpräfix empfängt:

Die folgenden Schritte zeigen den inaktiven Grund, der angezeigt wird, wenn BGP mehrere Routen zum selben Ziel-Präfix empfängt und eine Route als einzelner, aktiver Pfad ausgewählt wird:

Prüfung der lokalen Einstellungsauswahl

Zweck

Um einen Route zu prüfen, um zu ermitteln, ob lokale Vorliebe die Auswahlkriterien für den einzelnen, aktiven Pfad ist.

Aktion

Um eine Route zu prüfen, um zu bestimmen, ob lokale Vorliebe die Auswahlkriterien für den einzelnen, aktiven Pfad ist, geben Sie den folgenden Befehl Junos OS CLI Betriebsmodus ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, R4 dass zwei Instanzen der Route empfangen 100.100.1.0 wurden: Aus ( ) und eines aus ( ) wählten den Pfad aus seinem aktiven Pfad aus, wie im 10.0.0.2R210.1.45.2R5R4R2 Sternchen (*) angegeben. Die Auswahl basiert auf dem lokalen Einstellungswert, der im Feld Localpref enthalten ist. Der Pfad mit größtmöglicher lokaler Präferenz wird bevorzugt. In dem Beispiel ist der Pfad mit dem lokalen Einstellungswert der Pfad von R2 200.

Der Grund, warum die Route nicht ausgewählt wurde, liegt R5 in diesem Fall in der Praxis Inactive reasonLocal Preference vor.

Beachten Sie, dass die beiden Pfade vom selben benachbarten Netzwerk verwendet werden: AS 65001.

Prüfung von Multiple Exit Discriminator Route-Auswahl

Zweck

Um einen Route zu prüfen, um zu bestimmen, ob die MED die Auswahlkriterien für den einzelnen, aktiven Pfad ist.

Aktion

Um eine Route zu prüfen, um zu bestimmen, ob med die Auswahlkriterien für den einzelnen, aktiven Pfad ist, geben Sie den folgenden Befehl Junos OS CLI Betriebsmodus ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, R4 dass zwei Instanzen der Route empfangen 100.100.2.0 wurden: Aus ( ) und eines aus ( ) wählten den im Sternchen (*) angegebenen Pfad aus als aktive 10.0.0.2R2 Route 10.1.45.2R5R4R2 aus. Die Auswahl basiert auf dem im Feld enthaltenen Metric: MED-Wert. Der Pfad mit dem geringsten MED-Wert wird bevorzugt. In dem Beispiel ist der Pfad mit dem geringsten MED-Wert (5) der Pfad von R2 . Beachten Sie, dass die beiden Pfade vom selben benachbarten Netzwerk sind: AS 65001.

Der Grund, warum der inaktive Pfad nicht ausgewählt ist, wird in diesem Fall Inactive reason: im Feld Not Best in its group angezeigt. Dieser Ansatz wird verwendet, Junos OS standardmäßig den Prozess der deterministischen MED-Auswahl verwendet.

Prüfung des EBGP über IBGP-Auswahl

Zweck

Um einen Route zu prüfen, um zu ermitteln, ob EBGP über IBGP als Auswahlkriterien für den einzelnen, aktiven Pfad ausgewählt wird.

Aktion

Um eine Route zu prüfen, um zu bestimmen, ob EBGP über IBGP als Auswahlkriterien für den einzelnen aktiven Pfad ausgewählt wird, geben Sie den folgenden Junos OS CLI Betriebsmodusbefehl ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, R4 dass zwei Instanzen der Route empfangen 100.100.3.0 wurden: Aus ( ) und eines aus ( ) wählten den Pfad aus seinem aktiven Pfad aus, wie im 10.1.45.2R510.0.0.2R2R4R5 Sternchen (*) angegeben. Die Auswahl basiert auf einer Präferenz für Routen, die von einem EBGP-Peer über Routen gelernt werden, die aus einem IBGP gelernt wurden. R5 ist ein EBGP-Peer.

Sie können feststellen, ob ein Pfad von einem EBGP- oder IBGP-Peer empfangen wird, indem Sie die und Local As die Felder Peer As prüfen. Die Route von zeigt z. B. die lokale AS R5 65002 und die Peer-AS 65001 an, die angibt, dass die Route von einem EBGP-Peer empfangen wird. Die Route zeigt, dass sowohl die lokale als auch die Peer AS 65002 ist, die angibt, dass sie von einem R2 IBGP-Peer empfangen wird.

Der Grund, warum der inaktive Pfad nicht ausgewählt ist, wird in diesem Fall Inactive reason im Feld Interior > Exterior > Exterior via Interior angezeigt. Dadurch wird die Reihenfolge deutlich, in der Präferenzen angewandt werden, wenn derselbe Route von zwei Routern empfangen wird. Die Route, die ausschließlich von einer internen Quelle (IGP) empfangen wird, wird zuerst bevorzugt, die Route, die von einer externen Quelle (EBGP) empfangen wird, und alle Routen, die aus einer externen Quelle stammen und intern (IBGP) empfangen werden, werden zuletzt bevorzugt. Daher werden EBGP-Routen über IBGP-Routen als aktiver Pfad ausgewählt.

Prüfung der IGP Kostenauswahl

Zweck

Um einen Route zu prüfen, um zu ermitteln, ob EBGP über IBGP als Auswahlkriterien für den einzelnen, aktiven Pfad ausgewählt wird.

Aktion

Um eine Route zu prüfen, um zu bestimmen, ob EBGP über IBGP als Auswahlkriterien für den einzelnen aktiven Pfad ausgewählt wird, geben Sie den folgenden Junos OS CLI Betriebsmodusbefehl ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, R6 dass zwei Instanzen der Route empfangen 100.100.4.0 wurden: Aus ( ) und eines aus ( ) wählten den Pfad aus seiner aktiven Route aus, wie im 10.0.0.4R410.0.0.2 R2R6R4 Sternchen (*) angegeben. Die Auswahl basiert auf der kennzahlbasierten IGP und wird im Feld Metric2 angezeigt. Der Route mit der geringsten Kennzahl IGP vor. Der Pfad mit dem geringsten IGP ist der Pfad von 10 mit einem IGP-Kennwert, der pfad von IGP R4R2 20. Beachten Sie, dass die beiden Pfade vom selben benachbarten Netzwerk sind: AS 65001.

Der Grund, warum der inaktive Pfad nicht ausgewählt wurde, wird in diesem Fall Inactive reason im Feld IGP metric angezeigt.

Checkliste für die BGP Layer

Problem

Beschreibung

Diese Checkliste enthält die Schritte und Befehle zur Überprüfung der BGP Konfiguration des MPLS (Multiprotocol Label Switching) (MPLS). Die Prüfliste bietet Links zu einer Übersicht über die Konfiguration BGP Konfiguration und detailliertere Informationen zu den Befehlen zur Konfiguration BGP. (Siehe Tabelle 2 .)

Lösung

Tabelle 2: Checkliste für die BGP Layer

Aufgaben

Befehl oder Aktion

Prüfen der BGP Layer  
  1. Stellen Sie sicher BGP dass Der Datenverkehr den LSP verwendet

traceroute hostname

  1. Überprüfen BGP Sitzungen

show bgp summary

  1. Überprüfen der BGP Konfiguration

show configuration

  1. Prüfung der BGP Routen

show route destination-prefix detail

  1. Überprüfen der empfangenen BGP Routen

show route receive protocol bgp neighbor-address

  1. Ergreifen geeigneter Maßnahmen zur Lösung des Netzwerkproblems

Die folgende Reihenfolge von Befehlen behebt das in diesem Thema beschriebene Problem:

[edit] edit protocols bgp

[edit protocols bgp] show set local-address 10.0.0.1 delete group internal neighbor 10.1.36.2 show commit

  1. Stellen Sie sicher BGP dass der Datenverkehr den LSP erneut verwendet

traceroute hostname

Prüfen der BGP Layer

Zweck

Nachdem Sie den Label Switched Path (LSP) konfiguriert und festgestellt haben, ob dieser eingerichtet und BGP konfiguriert und festgestellt hat, dass Sitzungen eingerichtet wurden, stellen Sie sicher, dass BGP den LSP zur Datenverkehrs weitergeleitet.

Abbildung 3 beschreibt die BGP Schicht des mehrschichtigen Modells MPLS Mehrebene.

Abbildung 3: Prüfen der BGP LayerPrüfen der BGP Layer

Wenn Sie die BGP Layer überprüfen, stellen Sie sicher, dass die Route vorhanden und aktiv ist. Was noch wichtiger ist, stellen Sie sicher, dass der nächste Hop der LSP ist. Es ist kein Punkt, die BGP zu überprüfen, es sei denn, der LSP wurde eingerichtet, da BGP den LSP für die MPLS verwendet. Wenn das Netzwerk auf dieser BGP nicht funktioniert, funktioniert der LSP nicht wie konfiguriert.

Abbildung 4 beschreibt das MPLS Netzwerk in diesem Thema.

Abbildung 4: MPLS Defekte Netzwerke auf der BGP LayerMPLS Defekte Netzwerke auf der BGP Layer

Bei dem in dieser Abbildung dargestellten Netzwerk handelt es sich um eine Fully-Mesh-Konfiguration, in der jede direkt angebundene Schnittstelle Pakete empfangen und an jede andere Abbildung 4 ähnliche Schnittstelle senden kann. Der LSP in diesem Netzwerk ist so konfiguriert, dass er vom Ingress-Router über den Transit-Router bis zum R1R3 Egress-Router ausgeführt R6 wird. Darüber hinaus ist ein umgekehrter LSP konfiguriert, der von zu auf ausgeführt wird, und R6R3 erstellt R1 bidirektionalen Datenverkehr.

Das hier dargestellte Kreuz zeigt an, BGP nicht für die Abbildung 4 Datenverkehrs-Forwards über den LSP verwendet wird. Mögliche Gründe dafür, dass der LSP nicht richtig funktioniert, ist, dass die Ziel-IP-Adresse des LSP nicht mit dem BGP nächsten Hop entspricht oder BGP nicht richtig konfiguriert ist.

Gehen Sie wie folgt BGP Layer durch, um die Schicht zu überprüfen:

Stellen Sie sicher BGP dass Der Datenverkehr den LSP verwendet

Zweck

Auf dieser Ebene des Fehlerbehebungsmodells sind BGP und der LSP eventuell hoch, der Datenverkehr BGP LSP wird jedoch möglicherweise nicht zur Weiterbehandlung des Datenverkehrs verwendet.

Aktion

Um sicherzustellen, BGP den LSP verwendet, geben Sie auf dem Ingress-Router den folgenden Befehl Junos OS Befehlszeilenschnittstelle (CLI) (CLI) betriebsmodus ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, BGP den LSP nicht verwendet, so dass MPLS nicht in der Ausgabe angezeigt werden. Anstelle von LSP verwendet BGP das Interior Gateway Protocol (IGP), um die BGP-LSP-Ausgangsadresse für und zu R6R1 erreichen. Der Junos OS ist die Verwendung von LSPs für BGP Datenverkehrs, wenn der BGP nächste Hop der LSP-Ausgangsadresse entspricht.

Überprüfen BGP Sitzungen

Zweck

Anzeige von Zusammenfassungsinformationen BGP Daten und Nachbarn, um zu bestimmen, ob Routen von Peers im autonomen System (AS) empfangen werden. Wenn eine BGP Sitzung eingerichtet wird, tauschen die Peers Update-Nachrichten aus.

Aktion

Um zu prüfen BGP ob die Sitzungen verfügbar sind, geben Sie den folgenden Befehl Junos OS CLI Betriebsmodus auf dem Router ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Die Beispielausgabe 1 zeigt, dass ein Peer (Egress-Router) nicht festgelegt wurde, wie 10.0.0.6 im Feld Down Peers: 1 angegeben. In der letzten Spalte ( ) wird angezeigt, dass der Peer aktiv State|#Active/Received/Damped ist und nicht festgelegt 10.0.0.6 wurde. Alle anderen Peers werden angegeben durch die Anzahl aktiver, empfangener und damped-Routen. Ein Beispiel: Peer gibt an, dass keine BGP-Routen aktiv oder in der Routingtabelle empfangen wurden und keine BGP 0/0/010.0.0.2 gedämpft wurden; 1/1/0 für Peer gibt an, dass eine BGP-Route aktiv war und in der Routing-Tabelle empfangen wurde und keine BGP 10.1.36.2 gedämpft wurden.

Wenn die Ausgabe des Befehls eines Ingress-Routers zeigt, dass ein Nachbar aus ist, überprüfen Sie show bgp summary die BGP Konfiguration. Informationen zur Überprüfung der Konfiguration BGP finden Sie unter "Überprüfen der BGP Konfiguration".

Beispiel-Ausgabe 2 zeigt die Ausgabe des Ingress-Routers nach der BGP-Konfigurationen und wurde durch Ergreifen entsprechender Maßnahmen zum Lösen des R1R1R6Netzwerkproblems behoben. . Alle BGP werden eingerichtet, und eine Route wird aktiv und empfangen. Keine BGP waren gedämpft.

Wenn die Ausgabe des Befehls zeigt, dass ein Nachbar hoch ist, aber Pakete nicht weitergeleitet werden, überprüfen Sie auf empfangene Routen vom show bgp summary Ausgangsrouter. Informationen zur Überprüfung des Egress-Routers auf empfangene Routen finden Sie unter "Received BGP Routes"(Geprüfte BGP Routen).

Überprüfen der BGP Konfiguration

Zweck

Damit BGP Auf dem Router ausgeführt werden können, müssen Sie die lokale AS-Nummer festlegen, mindestens eine Gruppe konfigurieren und Informationen zu mindestens einem Peer in der Gruppe (IP-Adresse des Peers und AS-Nummer) angeben. Wenn BGP Teil eines MPLS-Netzwerks ist, müssen Sie sicherstellen, dass der LSP mit einer Ziel-IP-Adresse konfiguriert ist, die mit dem BGP-nächsten Hop entspricht, damit BGP-Routen im LSP als nächster Hop für diese Routen installiert werden können.

Aktion

Geben Sie zur BGP Konfiguration die folgenden Befehlszeilenbefehle Junos OS CLI Betriebsmodus ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Die Beispielausgabe zeigt die BGP Konfigurationen auf dem Ingress-Router und R1 Egress-Router. R6 Beide Konfigurationen zeigen den lokalen AS ( 65432 ), eine Gruppe internal () und sechs konfigurierte Peers. Das zugrundeliegende Interior Gateway-Protokoll wird IS-IS, und die entsprechenden Schnittstellen werden so konfiguriert, dass es IS-IS.

Anmerkung:

In dieser Konfiguration wird RID manuell konfiguriert, um mehrfache RID-Probleme zu vermeiden. Alle mit BGP konfigurierten Schnittstellen enthalten die Anweisung auf family inet der [ edit interfaces type-fpc/pic/port unit logical-unit-number ] Hierarchieebene.

Beispielausgabe für Ingress-Router und Egress-Router zeigt, dass die Konfigurationsdaten für das BGP-Protokoll die Anweisung für die R1 interne Gruppe nicht vorhanden R6 local-address sind. Wenn die Anweisung konfiguriert ist, BGP Pakete von der lokalen Router-Loopback-Adresse ( ) weitergeleitet werden, die die Adresse ist, an die BGP local-addresslo0 Peering. Wenn die Anweisung nicht konfiguriert ist, werden BGP Pakete von der ausgehenden Schnittstellenadresse weitergeleitet, die nicht mit der Adresse übereinstimmen, an die local-address BGP-Peers peeringen, und BGP wird nicht angezeigt.

Auf dem Ingress-Router sollte die IP-Adresse ( ) in der Anweisung dieselbe sein wie die Adresse, die für den LSP auf dem Egress Router ( ) in der Anweisung auf der [ ] Hierarchieebene konfiguriert 10.0.0.1local-addressR6to edit protocols mpls label-switched-path lsp-path-name ist. BGP verwendet diese Adresse, die identisch mit der LSP-Adresse ist, um BGP über den LSP weiter zu senden.

Darüber hinaus umfasst die BGP-Konfiguration zwei IP-Adressen für , eine Schnittstellenadresse ( ) und eine Loopback ( ) Schnittstellenadresse ( ), die dazu führt, dass die LSP-Zieladresse ( ) nicht R1R6 der 10.1.36.2lo010.0.0.610.0.0.6 BGP-Next-Hop-Adresse ( ) 10.1.36.2 abgleicht. Die BGP-Konfiguration umfasst zwei IP-Adressen für , eine Schnittstellenadresse ( ) und eine Loopback - Schnittstellenadresse, was dazu führt, dass die umgekehrte LSP-Zieladresse ( ) nicht an die R6R110.1.13.1lo010.0.0.1 BGP-Next-Hop-Adresse ( ) 10.1.13.1 anpasst.

Da in diesem Beispiel die Anweisung in den BGP-Konfigurationen sowohl von Routern als auch von der LSP-Zieladresse fehlt, nicht mit der BGP-Adresse des nächsten Hops übereinstimmen, verwendet BGP den LSP nicht zum Weitergeleitet des local-address Datenverkehrs.

Prüfung der BGP Routen

Zweck

Sie können den Prozess zur BGP Pfadauswahl untersuchen, um den einzelnen, aktiven Pfad zu bestimmen, wenn BGP mehrere Routen zum selben Ziel empfängt. In diesem Schritt untersuchen wir den reversen R6-to-R1 LSP, den R6 Ingress-Router für diesen LSP.

Aktion

Um die Auswahl BGP Routen und Routen zu prüfen, geben Sie den folgenden Befehl Junos OS CLI Betriebsmodus ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Die Beispielausgabe 1 zeigt, dass der BGP Next Hop ( ) nicht der LSP-Zieladresse ( ) in der Anweisung auf der [ ] Hierarchieebene entspricht, wenn die BGP-Konfiguration von und falsch 10.1.13.110.0.0.1 to edit protocols mpls label-switched-path label-switched-path-nameR6 R1 ist.

Beispiel-Ausgabe 2, die nach der Korrektur der Konfigurationen auf R1 und R6 ergriffen wird, zeigt, dass der BGP-Next-Hop ( ) und die LSP-Zieladresse ( ) identisch sind, was angibt, dass BGP den LSP zur BGP-Datenverkehr verwenden 10.0.0.110.0.0.1 kann.

Überprüfen der empfangenen BGP Routen

Zweck

Zeigen Sie die Routinginformationen an, die auf dem Router R6 , dem Ingress-Router für den umgekehrten LSP, empfangen R6-to-R1 wurden.

Aktion

Um sicherzustellen, dass eine bestimmte BGP Route auf dem Ausgangsrouter empfangen wird, geben Sie den folgenden Befehl Junos OS CLI Betriebsmodus ein:

Beispielausgabe 1
Befehlsname
Beispielausgabe 2
Befehlsname

Bedeutung

Beispiel-Ausgabe 1 zeigt, dass der Ingress-Router (umgekehrter LSP) keine BGP-Routen in die Routingtabelle erhält, wenn die falschen BGP Konfigurationen der Router R6R6-to-R1inet.0R1R6 sind.

Beispiel-Ausgabe 2 zeigt eine in BGP Routingtabelle installierte Route nach den BGP-Konfigurationen und wird mithilfe von "Geeignete Maßnahmen zum Lösen des Netzwerkproblems" inet.0R1 R6behoben.

Ergreifen geeigneter Maßnahmen zur Lösung des Netzwerkproblems

Problem

Beschreibung

Die geeignete Maßnahme hängt von der Art des isolierten Problems ab. In diesem Beispiel wird eine konfigurierte statische Route aus der R2 [ routing-options ] Hierarchieebene gelöscht. Weitere geeignete Maßnahmen können folgende sein:

Lösung

  • Überprüfen Sie die Konfiguration des lokalen Routers, und bearbeiten Sie sie gegebenenfalls.

  • Fehler beim Intermediate Router.

  • Überprüfen Sie die Konfiguration des Remote-Hosts, und bearbeiten Sie sie gegebenenfalls.

  • Fehlerbehebung bei Routing-Protokollen.

  • Identifizieren sie weitere mögliche Ursachen.

Geben Sie die folgenden Junos OS CLI Befehl ein, um das Problem in diesem Beispiel zu lösen:

Beispielausgabe

Bedeutung

Die Beispielausgabe zeigt die statische Route, die aus der [ ] Hierarchie gelöscht routing-options wird und die neue zugesagte Konfiguration. Die Ausgabe für den Befehl zeigt jetzt die BGP als bevorzugte Route, wie durch show route das Sternchen ( * ).

Stellen Sie sicher BGP dass Der Datenverkehr den LSP erneut verwendet

Zweck

Nachdem Sie die entsprechenden Maßnahmen ergreifen, um den Fehler zu beheben, muss der LSP erneut geprüft werden, um zu bestätigen, dass BGP-Datenverkehr den LSP verwendet und das Problem auf der BGP gelöst wurde.

Aktion

Um zu BGP LSP zu überprüfen, geben Sie im Ingress-Router den folgenden Befehl Junos OS CLI Betriebsmodus ein:

Beispielausgabe
Befehlsname

Bedeutung

Die Beispielausgabe zeigt, MPLS Datenlabel verwendet werden, um Pakete über den LSP weiter zu senden. Die Ausgabe enthalten einen Labelwert ( MPLS Label=100016 ), einen Time-to-Live-Wert ( ) und TTL=1 einen Stack-Bit-Wert ( S=1 ).

Dieses MPLS Label Feld wird zur Identifizierung des Pakets zu einem bestimmten LSP verwendet. Es ist ein 20-Bit-Feld mit einem maximalen Wert von (2^^20-1) und ca. 1.000.000.

Der TTL-Wert (Time-to-Live) enthält eine Begrenzung der Anzahl Hops, die dieses MPLS Paket durch das Netzwerk übertragen kann (1). Er wird in jedem Hop dekrementiert, und wenn der TTL-Wert unter einem Hop fällt, wird das Paket verworfen.

Der untere Stack-Bitwert ( ) gibt an, dass das letzte Label im Stack ist und dass MPLS Paket über ein zugehöriges S=1 Label verfügt. Die MPLS Implementierung im Junos OS unterstützt eine Stackingtiefe von 3 auf den Routern der M-Serie und bis zu 5 bei den Routingplattformen der T-Serie. Weitere Informationen zu labelstacking MPLS finden Sie in RFC 3032, MPLS Label Stack Encoding.

MPLS werden in der Beispielausgabe angezeigt, da der Befehl an ein Ziel BGP ausgegeben wird, wobei der BGP-Hop für diese Route die traceroute LSP-Ausgangsadresse ist. Der Junos OS verwendet standardmäßig LSPs für BGP Datenverkehr, wenn der BGP-Hop der LSP-Ausgangsadresse entspricht.

Wenn der BGP-nächste Hop nicht der LSP-Ausgangsadresse entspricht, wird der BGP-Datenverkehr nicht vom LSP verwendet. Daher werden MPLS-Labels nicht in der Ausgabe für den Befehl angezeigt, wie in der Beispielausgabe traceroute in "Check BGP Sessions"angegeben.

Gesendete oder empfangene BGP werden angezeigt

Aktion

Um die Ablaufverfolgung für gesendete oder empfangene BGP-Protokollpakete zu konfigurieren, führen Sie die folgenden Schritte aus:

  1. Gehen Sie im Konfigurationsmodus zu der folgenden Hierarchieebene:

  2. Konfigurieren Sie den Flag zur Anzeige der gesendeten, empfangenen oder sowohl gesendeten als auch empfangenen Paketinformationen:

    oder

    oder

  3. Konfiguration überprüfen:

    Zum Beispiel:

    oder

    oder

  4. Commit-Konfiguration:

  5. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an:

    Zum Beispiel:

Verständnis versteckter Routen

Verborgene Routen sind Routen, die das Gerät nicht nutzen kann, z. B. einen ungültigen Next Hop oder eine Routingrichtlinie, die die Routen abgelehnt.

Anmerkung:

Wenn eine Route komplett ungültig ist, wird die Route nicht als Kandidatenroute in die Routingtabelle platziert und wird nicht einmal als verborgen angezeigt.

Im Folgenden finden Sie einige nützliche Befehle zum Anzeigen und Beheben versteckter Routen:

Routen können aus folgenden Gründen verborgen sein:

  • Eine Importrichtlinie wird der Route abgelehnt.

  • Der nächste Hop kann mithilfe der aktuellen indirekten Next Hop-Auflösungsregel nicht gelöst werden. Da Routingprotokolle wie interne BGP (IBGP) Routinginformationen über indirekt verbundene Routen senden können, ist Junos OS auf Routen von Intra-AS-Routing-Protokollen (OSPF, IS-IS, RIP und statisch) angewiesen, um den am besten direkt angebundenen Next Hop zu lösen. Der Routing-Engine führt eine Routenauflösung durch, um den am besten verbundenen Next Hop zu bestimmen, und installiert die Route zum Packet Forwarding Engine.

  • Ein dämpfendes Richtlinien-Maßnahmen dämmt die Route ein.

  • Der AS Pfad enthält illegale oder ungültige Confederations-Attribute.

  • Die Next Hop-Adresse ist die Adresse des lokalen Routinggeräts.

  • Der AS Pfad enthält illegale oder ungültige Transitattribute.

  • Der AS ist leer. Dies gilt nur für EBGP. Bei IBGP ist ein leerer AS normal.

  • Der AS Pfad enthält eine Null.

  • Die nächste Hop-Adresse ist eine Multicast-Adresse.

  • Die nächste Hop-Adresse ist eine lokale IPv6-Adresse.

  • Das Routen-Präfix oder der nächste Hop ist eine Martian-Adresse.

  • Die LDP-Sitzung (Label Distribution Protocol) schlägt fehl. Die empfangenen Routen werden erst dann in der Routingtabelle installiert, wenn der Peer-Router die LDP-Sitzung neu einleitet.

Prüfung von Routen in der Weiterleitungstabelle

Zweck

Wenn Probleme auftreten, z. B. Verbindungsprobleme, müssen Sie möglicherweise die Routen in der Weiterleitungstabelle prüfen, um sicherzustellen, dass der Routingprotokollprozess die richtigen Informationen in die Weiterleitungstabelle übermittelt hat.

Aktion

Geben Sie den folgenden Befehl für den Junos OS CLI Betriebsmodus ein, um die in der Weiterleitungstabelle installierten Routen anzuzeigen:

Beispielausgabe

Befehlsname

Bedeutung

Die Beispielausgabe zeigt die Präfixe auf Netzwerkebene und ihre nächsten Hops, die in der Weiterleitungstabelle installiert sind. Die Ausgabe enthält die gleichen Next-Hop-Informationen wie im show route detail Befehl (die Adresse des nächsten Hops und der Schnittstellenname). Weitere Informationen umfassen den Zieltyp, den Next-Hop-Typ, die Anzahl der Referenzen auf diesen nächsten Hop und einen Index in eine interne Next-Hop-Datenbank. (Die interne Datenbank enthält weitere Informationen, die vom Packet Forwarding Engine zur Gewährleistung der korrekten Einkapselung von an die Schnittstelle gesendeten Paketen verwendet werden. Auf diese Datenbank kann nicht für Benutzer zugegriffen werden.

Ausführliche Informationen über die Bedeutung der verschiedenen Flags und Typen von Feldern finden Sie im Benutzerhandbuch Routing-Richtlinien, Firewall-Filter und Traffic-Policer.

Beispiel: Überschreiben der Standardrichtlinien BGP Routing-Richtlinien der PTX-Paketübertragungs-Router

In diesem Beispiel wird veranschaulicht, wie die Standard-Routing-Richtlinie von Paketweiterleitungs-Routern wie den Standardrichtlinien der PTX-Serie Paketübertragungs-Router.

Anforderungen

In diesem Beispiel ist Junos OS Version 12.1 oder höher erforderlich.

Überblick

Standardmäßig installieren die Router der PTX-Serie keine BGP in der Weiterleitungstabelle.

Für Router der PTX-Serie hat die Konfiguration des Zustands mit der Aktion nicht das übliche Ergebnis, das es auf anderen Routing Junos OS from protocols bgpthen accept hat. Mit der folgenden Routing-Richtlinie auf Routern der PTX-Serie werden BGP nicht in der Weiterleitungstabelle installiert.

Keine BGP werden in der Weiterleitungstabelle installiert. Das ist das erwartete Verhalten.

In diesem Beispiel wird gezeigt, wie die Aktion then install-to-fib verwendet wird, um die Standard-Routingrichtlinie BGP effektiv zu außer Kraft zu setzen.

Konfiguration

CLI-Konfiguration

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

Installation ausgewählter BGP Routen in der Weiterleitungstabelle

Schritt-für-Schritt-Verfahren

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

So installieren Sie ausgewählte BGP Routen in der Weiterleitungstabelle:

  1. Konfigurieren Sie eine Liste von Präfixen zur Installation in der Weiterleitungstabelle.

  2. Konfigurieren Sie die Routing-Richtlinie, und wenden Sie die Präfixliste als Bedingungen an.

  3. Wenden Sie die Routing-Richtlinie auf die Weiterleitungstabelle an.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die Befehle show policy-optionsshow routing-options eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

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

Überprüfung

Stellen Sie sicher, dass die Konfiguration ordnungsgemäß funktioniert.

Sicherstellen, dass die ausgewählte Route in der Weiterleitungstabelle installiert ist

Zweck

Stellen Sie sicher, dass die konfigurierte Richtlinie die Standardrichtlinie überschreibt.

Aktion

Geben Sie im Betriebsmodus den Befehl show route forwarding-table ein.

Bedeutung

Diese Ausgabe zeigt, dass die Route zu 66.0.0.1/32 in der Weiterleitungstabelle installiert ist.

Protokollieren BGP Statusübergangsereignisse

Zweck

Border Gateway Protocol (BGP) zeigen, dass ein Netzwerkproblem vor sich geht und protokolliert und untersucht werden muss.

Aktion

Um die BGP Statusereignisse im Systemprotokoll zu protokollieren, führen Sie die folgenden Schritte aus:

  1. Gehen Sie im Konfigurationsmodus zu der folgenden Hierarchieebene:

  2. Konfigurieren Sie das Systemprotokoll:

  3. Konfiguration überprüfen:

  4. Commit-Konfiguration:

Bedeutung

Protokollmeldungen von Status BGP von Übergangsereignissen reichen aus, um die meisten Probleme BGP Sitzungen zu diagnostizieren. Tabelle 3 listet die sechs Zustände einer Sitzung BGP auf und beschreibt sie.

Tabelle 3: Sechs Zustände einer BGP Sitzung

BGP Status

Beschreibung

Idle

Das ist der erste Verbindungsstatus. BGP warten auf eine Startveranstaltung, die von einem Administrator initiiert wurde. Die Startveranstaltung kann die Einrichtung einer Sitzung BGP durch Routerkonfiguration oder die Erneuterkung einer vorhandenen Sitzung sein. Nach dem Startereignis wird BGP Ressourcen initialisiert, ein Verbindung-Wiederholungs-Timer zurückgesetzt, eine TCP-Transportverbindung initiiert und beginnt mit dem Abhören von Verbindungen, die von Remote-Peers initiiert wurden. BGP dann in einen Status Connect über.

Wenn Fehler auftreten, BGP auf den Status Idle zurück.

Connect

BGP wartet, bis die Transportprotokollverbindung abgeschlossen ist. Wenn die TCP-Transportverbindung erfolgreich ist, wird der Status auf OpenSent .

Wenn die Transportverbindung nicht erfolgreich ist, wird der Status auf Active .

Wenn der Timer für den Verbindungs-Wiederholungsversuch abgelaufen ist, bleibt der Status im Status, der Timer wird zurücksetzen und eine Connect Transportverbindung wird eingeleitet.

Bei anderen Veranstaltungen geht der Status auf Idle zurück.

Active

BGP versuchen, einen Peer zu erwerben, indem er eine Transportprotokollverbindung initiiert.

Ist dies erfolgreich, dann wird der Status auf OpenSent .

Wenn der Timer für den Verbindungs-Wiederholungsversuch abläuft, startet BGP den Connect-Timer neu und bleibt auf dem Connect Status. BGP weiterhin auf eine Verbindung, die von einem anderen Peer initiiert werden kann. Der Status kann im Falle anderer Ereignisse, wie z. Idle B. eines Stopp-Ereignisses, wieder auf das System zurückkommen.

Im Allgemeinen ist ein Nachbarstatus-Flip-Flopping ein Hinweis darauf, dass es ein Problem mit der ConnectActive TCP-Transportverbindung gibt. Ein solches Problem kann durch viele TCP-Rückübertragungen oder das Unvermögen eines Nachbarn verursacht werden, die IP-Adresse seines Peers zu erreichen.

OpenSent

BGP erhält eine offene Nachricht vom Peer. Im Status vergleicht BGP seine autonome Systemnummer (AS) mit der AS-Anzahl seines Peers und erkennt, ob der Peer zum selben AS (internen BGP) oder zu einem anderen OpenSent AS (externer BGP) gehört.

Die offene Nachricht wird als Ungung geprüft. Wenn Fehler auftreten, z. B. eine fehlerhafte Versionsnummer einer inakzeptablen AS, wird BGP eine Fehlermeldung gesendet. Idle

Bei anderen Fehlern, wie Ablauf des Hold-Timer oder eines Stopp-Ereignisses, werden BGP mit dem entsprechenden Fehlercode gesendet und in den Zustand Idle zurückfällt.

Wenn keine Fehler auftreten, werden BGP-Nachrichten gesendet und den Keepalive-Timer zurückgesetzt. In diesem Zustand wird die Hold-Time ausgehandelt. Wenn die Hold Time 0 beträgt, werden hold- und keepalive Timer nicht neu gestartet.

Wenn eine TCP-Transporttrennung erkannt wird, wird der Status wieder auf Active .

OpenConfirm

BGP warten auf eine Keepalive- oder Benachrichtigung.

Wenn ein Keepalive empfangen wird, wird der Status Established und die Nachbar-Aushandlung ist abgeschlossen. Wenn das System eine Aktualisierung oder Keepalive-Nachricht empfängt, startet er den Hold Timer neu (wenn die ausgehandelte Hold Time nicht 0 ist).

Wenn eine Benachrichtigung empfangen wird, heißt der Status Idle wieder.

Das System sendet periodische Keepalive-Nachrichten zu einer vom Keepalive Timer festgelegten Rate. Im Fall einer Benachrichtigung über die Trennung des Transports oder als Reaktion auf ein Stopp-Ereignis wird der Status wieder Idle angezeigt. Als Reaktion auf andere Ereignisse sendet das System eine Benachrichtigung mit einem Finite-State-Machine (FSM)-Fehlercode und geht zurück Idle zu.

Established

Dies ist der letzte Status bei der Nachbar-Aushandlung. In diesem Status BGP Ackets mit ihren Peers aktualisieren, und der Hold Timer wird nach Erhalt einer Aktualisierung oder Keepalive-Nachricht neu gestartet, wenn nicht auf Null festgelegt ist.

Wenn an das System eine Benachrichtigung gesendet wird, wird der Status nicht mehr Idle angezeigt.

Aktualisierungsmeldungen werden auf Fehler geprüft, z. B. fehlende Attribute, mehrfache Attribute und so weiter. Wenn Fehler gefunden werden, wird eine Benachrichtigung an den Peer gesendet. Der Status wird dann auf Idle zurück gesendet.

BGP kann auf den Zeitpunkt zurück gehen, an dem der Hold-Timer abläuft, eine Trennungsbenachrichtigung vom Transportprotokoll empfangen wird, ein Stopp-Ereignis empfangen wird oder in Reaktion auf ein anderes Idle Ereignis.

Für ausführlichere BGP Protokollpaketinformationen konfigurieren Sie BGP-spezifische Ablaufverfolgung. Weitere Informationen finden Sie in der Checkliste für die Nachverfolgung von Fehlerbedingungen.

Konfiguration BGP-spezifischen Optionen

Zweck

Wenn unerwartete Ereignisse oder Probleme auftreten oder Sie Probleme bei der BGP der Einrichtung diagnostizieren möchten, können Sie detailliertere Informationen anzeigen, indem Sie für bestimmte Ereignisse BGP. Sie können die Ablaufverfolgung auch für einen bestimmten Peer BGP oder eine Peergruppe konfigurieren. Weitere Informationen finden Sie im Konfigurationshandbuch für Junos System-Grundlagen.

Detaillierte Informationen BGP Protokoll anzeigen

Aktion

Um BGP Protokollinformationen im Detail anzuzeigen, führen Sie die folgenden Schritte aus:

  1. Gehen Sie im Konfigurationsmodus zu der folgenden Hierarchieebene:

  2. Konfigurieren Sie den Flag zur Anzeige detaillierter BGP Protokollmeldungen:

  3. Konfiguration überprüfen:

    Zum Beispiel:

  4. Commit-Konfiguration:

  5. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an:

    Zum Beispiel:

Bedeutung

Tabelle 4 Listen Sie für bestimmte BGP Und zeigt Beispielausgabe für einige der Flags an. Sie können die Ablaufverfolgung auch für einen bestimmten Peer BGP Peer oder eine Peergruppe konfigurieren. Weitere Informationen finden Sie im Konfigurationshandbuch für Junos System-Grundlagen.

Tabelle 4: BGP-Protokoll-Tracing-Flags

Tracing-Flags

Beschreibung

Beispielausgabe

aspath

AS des regulären Ausdrucksvorgänges

Nicht verfügbar.

damping

Damping Operations

Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.1.0 Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.2.0 Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.3.0

keepalive

BGP-Nachrichten

Nov 28 17:09:27 bgp_send: sending 19 bytes to 10.217.5.101 (External AS 65471) Nov 28 17:09:27 Nov 28 17:09:27 BGP SEND 10.217.5.1+179 -> 10.217.5.101+52162 Nov 28 17:09:27 BGP SEND message type 4 (KeepAlive) length 19 Nov 28 17:09:28 Nov 28 17:09:28 BGP RECV 10.217.5.101+52162 -> 10.217.5.1+179 Nov 28 17:09:28 BGP RECV message type 4 (KeepAlive) length 19

open

BGP Pakete

Nov 28 18:37:42 bgp_send: sending 37 bytes to 10.217.5.101 (External AS 65471) Nov 28 18:37:42 Nov 28 18:37:42 BGP SEND 10.217.5.1+179 -> 10.217.5.101+38135 Nov 28 18:37:42 BGP SEND message type 1 (Open) length 37

packets

Alle BGP-Protokollpakete

Sep 27 17:45:31 BGP RECV 10.0.100.108+179 -> 10.0.100.105+1033 Sep 27 17:45:31 BGP RECV message type 4 (KeepAlive) length 19 Sep 27 17:45:31 bgp_send: sending 19 bytes to 10.0.100.108 (Internal AS 100) Sep 27 17:45:31 BGP SEND 10.0.100.105+1033 -> 10.0.100.108+179 Sep 27 17:45:31 BGP SEND message type 4 (KeepAlive) length 19 Sep 27 17:45:31 bgp_read_v4_update: receiving packet(s) from 10.0.100.108 (Internal AS 100)

update

Pakete aktualisieren

Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813 Nov 28 19:05:24 BGP SEND message type 2 (Update) length 53 Nov 28 19:05:24 bgp_send: sending 65 bytes to 10.217.5.101 (External AS 65471) Nov 28 19:05:24 Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813 Nov 28 19:05:24 BGP SEND message type 2 (Update) length 65 Nov 28 19:05:24 bgp_send: sending 55 bytes to 10.217.5.101 (External AS 65471)

Diagnose BGP Probleme bei der Einrichtung von Sitzungen

Zweck

Um die Probleme BGP Sitzungseinrichtung nachverfolgungen zu können.

Aktion

Um die Probleme BGP Sitzungseinrichtung nachverfolgungen zu können, befolgen Sie die folgenden Schritte:

  1. Gehen Sie im Konfigurationsmodus zu der folgenden Hierarchieebene:

  2. Konfigurieren BGP offene Nachrichten:

  3. Konfiguration überprüfen:

    Zum Beispiel:

  4. Commit-Konfiguration:

  5. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an:

    Zum Beispiel:

Konfiguration IS-IS-spezifischen Optionen

Zweck

Wenn unerwartete Ereignisse oder Probleme auftreten oder Sie probleme bei der IS-IS von Adjacency-Einrichtungsproblemen diagnostizieren möchten, können Sie detailliertere Informationen anzeigen, indem Sie für bestimmte Ereignisse IS-IS.

Gehen Sie folgendermaßen vor, um die IS-IS Konfiguration folgender Optionen zu konfigurieren:

Anzeige detaillierter IS-IS Protokollinformationen

Aktion

Befolgen Sie die folgenden Schritte, um IS-IS Nachrichten im Detail zu verfolgen:

  1. Konfigurieren Sie den Flag, um detaillierte IS-IS Protokollmeldungen anzuzeigen.

  2. Konfiguration überprüfen.

    Zum Beispiel:

  3. Commit für die Konfiguration.

  4. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an.

    Zum Beispiel:

Bedeutung

Tabelle 5 Listen Sie Tracing-Flags auf, die spezifisch für IS-IS können, und zeigt Beispieldaten für einige der Flags an.

Tabelle 5: IS-IS-Protokoll-Tracing-Flags

Tracing-Flags

Beschreibung

Beispielausgabe

csn

Vollständige Sequenznummer PDU (CSNP)

Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/0.0Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/1.0

Mit detail Option.

Nov 28 20:06:08 Sending L2 CSN on interface so-1/1/1.0Nov 28 20:06:08 LSP abc-core-01.00-00 lifetime 1146Nov 28 20:06:08 sequence 0x1c4f8 checksum 0xa1e9Nov 28 20:06:08 LSP abc-core-02.00-00 lifetime 411Nov 28 20:06:08 sequence 0x7435 checksum 0x5424Nov 28 20:06:08 LSP abc-brdr-01.00-00 lifetime 465Nov 28 20:06:08 sequence 0xf73 checksum 0xab10Nov 28 20:06:08 LSP abc-edge-01.00-00 lifetime 1089Nov 28 20:06:08 sequence 0x1616 checksum 0xdb29Nov 28 20:06:08 LSP abc-edge-02.00-00 lifetime 1103Nov 28 20:06:08 sequence 0x45cc checksum 0x6883

hello

Hallo Paket

Nov 28 20:13:50 Sending PTP IIH on so-1/1/1.0Nov 28 20:13:50 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:53 Received PTP IIH, source id abc-core-02 on so-1/1/1.0Nov 28 20:13:57 Sending PTP IIH on so-1/1/0.0Nov 28 20:13:58 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:59 Sending PTP IIH on so-1/1/1.0

lsp

Link-State-PDUs (LSPs)

Nov 28 20:15:46 Received L2 LSP abc-edge-01.00-00, interface so-1/1/0.0Nov 28 20:15:46 from abc-core-01Nov 28 20:15:46 sequence 0x1617, checksum 0xd92a, lifetime 1197Nov 28 20:15:46 Updating L2 LSP abc-edge-01.00-00 in TEDNov 28 20:15:47 Received L2 LSP abc-edge-01.00-00, interface so-1/1/1.0Nov 28 20:15:47 from abc-core-02Nov 28 20:15:47 sequence 0x1617, checksum 0xd92a, lifetime 1197

lsp-generation

Link-State-PDU-Generation-Pakete

Nov 28 20:21:24 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x682Nov 28 20:21:27 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:21:27 Rebuilt L1 fragment abc-edge-03.00-00, size 59Nov 28 20:31:52 Regenerating L2 LSP abc-edge-03.00-00, old sequence 0x689Nov 28 20:31:54 Rebuilding L2, fragment abc-edge-03.00-00Nov 28 20:31:54 Rebuilt L2 fragment abc-edge-03.00-00, size 256Nov 28 20:34:05 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x683Nov 28 20:34:08 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:34:08 Rebuilt L1 fragment abc-edge-03.00-00, size 59

packets

Alle IS-IS-Protokollpakete

Nicht verfügbar.

psn

Partielle Sequence Number PDU (PSNP)-Pakete

Nov 28 20:40:39 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:40:39 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:35 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:35 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:49 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9becNov 28 20:42:49 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9bec

spf

Berechnung des kürzesten Pfads (Shortest Path First, SPF)

Nov 28 20:44:01 Scheduling SPF for L1: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L1: ReconfigNov 28 20:44:01 Scheduling SPF for L2: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L2: ReconfigNov 28 20:44:02 Running L1 SPFNov 28 20:44:02 L1 SPF initialization complete: 0.000099s cumulative timeNov 28 20:44:02 L1 SPF primary processing complete: 0.000303s cumulative timeNov 28 20:44:02 L1 SPF result postprocessing complete: 0.000497s cumulative timeNov 28 20:44:02 L1 SPF RIB postprocessing complete: 0.000626s cumulative timeNov 28 20:44:02 L1 SPF routing table postprocessing complete: 0.000736s cumulative time

Anzeige der gesendeten oder empfangenen IS-IS-Protokollpakete

Um die Ablaufverfolgung für nur gesendete oder empfangene IS-IS-Protokollpakete zu konfigurieren, führen Sie die folgenden Schritte aus:

  1. Konfigurieren Sie den Flag so, dass gesendete, empfangene oder beide gesendete und empfangene Pakete angezeigt werden.

    oder

    oder

  2. Konfiguration überprüfen.

    Zum Beispiel:

    oder

    oder

  3. Commit für die Konfiguration.

  4. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an.

    Zum Beispiel:

Detaillierte IS-IS Verbindungsstatus-PDUs

Führen Sie IS-IS folgenden Schritte aus, um Details zu den Verbindungsstatus-PDUs zu analysieren:

  1. Konfigurieren IS-IS offenen Nachrichten.

  2. Konfiguration überprüfen.

    Zum Beispiel:

  3. Commit für die Konfiguration.

  4. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an.

    Zum Beispiel:

Konfiguration OSPF-spezifischer Optionen

Zweck

Wenn unerwartete Ereignisse oder Probleme auftreten oder Sie Probleme bei der Nachbar-Einrichtung OSPF, können Sie detailliertere Informationen anzeigen, indem Sie für bestimmte Anforderungen OSPF.

Gehen Sie folgendermaßen vor, um die OSPF Konfiguration folgender Optionen zu konfigurieren:

Diagnose OSPF Probleme bei der Einrichtung von Sitzungen

Aktion

Befolgen Sie die folgenden Schritte, um OSPF Nachrichten im Detail zu verfolgen:

  1. Gehen Sie im Konfigurationsmodus zu der folgenden Hierarchieebene:

  2. Konfigurieren OSPF Hallo-Nachrichten:

  3. Konfiguration überprüfen:

    Zum Beispiel:

  4. Commit-Konfiguration:

  5. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an:

    Zum Beispiel:

Bedeutung

Tabelle 6 listen OSPF Flags auf und präsentieren Beispielausgabe für einige der Flags.

Tabelle 6: OSPF-Protokoll-Tracing-Flags

Tracing-Flags

Beschreibung

Beispielausgabe

database-descripttion

Alle Datenbankbeschreibungspakete

Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:44:55 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:44:55 OSPF sent DbD (2) -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:44:55 Version 2, length 32, ID 10.0.0.6, area 0.0.0.0 Dec 2 15:44:55 checksum 0xf76b, authtype 0 Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0xa009eee, mtu 4470 Dec 2 15:44:55 OSPF rcvd DbD 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:44:55 Version 2, length 32, ID 10.10.134.12, area 0.0.0.0 Dec 2 15:44:55 checksum 0x312c, authtype 0 Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0x2154, mtu 4470

error

OSPF fehleranfällige Pakete

Dec 2 15:49:34 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:49:44 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:49:54 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:50:04 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:50:14 OSPF packet ignored: no matching interface from 172.16.120.29

event

OSPF und Statuswechsel

Dec 2 15:52:35 OSPF interface ge-2/2/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-3/1/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-3/2/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-4/2/0.0 state changed from DR to DR Dec 2 15:53:21 OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:53:21 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Down to Init Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from ExStart to Exchange Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full

flooding

Verbindungsstatus-Flooding-Pakete

Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/0.0 Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/1.0 Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood

Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood

hello

Hallo Pakete

Dec 2 15:57:25 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/1/0.0) Dec 2 15:57:25 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:25 checksum 0xe43f, authtype 0 Dec 2 15:57:25 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:25 dead_ivl 40, DR 10.218.0.1, BDR 0.0.0.0 Dec 2 15:57:25 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:57:25 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0 Dec 2 15:57:25 checksum 0x99b8, authtype 0 Dec 2 15:57:25 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:25 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 15:57:27 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/2/0.0) Dec 2 15:57:27 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:27 checksum 0xe4a5, authtype 0 Dec 2 15:57:27 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:27 dead_ivl 40, DR 10.116.0.1, BDR 0.0.0.0 Dec 2 15:57:28 OSPF rcvd Hello 10.10. 10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 15:57:28 Version 2, length 48, ID 10.10.134.11, area 0.0.0.0 Dec 2 15:57:28 checksum 0x99b9, authtype 0 Dec 2 15:57:28 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:28 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

lsa-ack

Linkstatus-Bestätigungspakete

Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:00:11 Version 2, length 44, ID 10.10 .134.11, area 0.0.0.0 Dec 2 16:00:11 checksum 0xcdbf, authtype 0 Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:00:11 Version 2, length 144, ID 10.10. 134.12, area 0.0.0.0 Dec 2 16:00:11 checksum 0x73bc, authtype 0 Dec 2 16:00:16 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:00:16 Version 2, length 44, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:00:16 checksum 0x8180, authtype 0

lsa-request

Verbindungsstatus-Anforderungspakete

Dec 2 16:01:38 OSPF rcvd LSReq 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:01:38 Version 2, length 108, ID 10.10.134.11, area 0.0.0.0 Dec 2 16:01:38 checksum 0xe86, authtype 0

lsa-update

Aktualisierungspakete für den Verbindungsstatus

Dec 2 16:09:12 OSPF built router LSA, area 0.0.0.0 Dec 2 16:09:12 OSPF built router LSA, area 1.0.0.0 Dec 2 16:09:12 OSPF built router LSA, area 2.0.0.0 Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:09:13 checksum 0x8047, authtype 0 Dec 2 16:09:13 adv count 7 Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:09:13 checksum 0x8047, authtype 0 Dec 2 16:09:13 adv count 7

packets

Alle OSPF Pakete

Nicht verfügbar.

packet-dump

Inhalte ausgewählter Pakettypen löschen

Nicht verfügbar.

spf

SPF-Berechnungen

Dec 2 16:08:03 OSPF full SPF refresh scheduled Dec 2 16:08:04 OSPF SPF start, area 1.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000525s Dec 2 16:08:04 Stub elapsed time 0.000263s Dec 2 16:08:04 OSPF SPF start, area 2.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000253s Dec 2 16:08:04 Stub elapsed time 0.000249s Dec 2 16:08:04 OSPF SPF start, area 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 OSPF add LSA Router 10.10. 134.11 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/0.0 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.10.134.12 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0

Analysieren OSPF von Link-State-Werbepaketen im Detail

Aktion

Um die OSPF von Link-State-Werbepaketen im Detail zu analysieren, befolgen Sie die folgenden Schritte:

  1. Gehen Sie im Konfigurationsmodus zu der folgenden Hierarchieebene:

  2. Konfiguration OSPF Link-State-Pakete:

  3. Konfiguration überprüfen:

    Zum Beispiel:

  4. Commit-Konfiguration:

  5. Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an:

    Zum Beispiel: