Auf dieser Seite
Fehlerbehebung bei BGP-Sitzungen
Checkliste zur Überprüfung des BGP-Protokolls und der Peers
Zweck
Tabelle 1 stellt Links und Befehle zur Verfügung, um zu überprüfen, ob das Border Gateway Protocol (BGP) auf einem Router von Juniper Networks in Ihrem Netzwerk korrekt konfiguriert ist, die IBGP-Sitzungen (Internal Border Gateway Protocol) und externe Border Gateway Protocol (EBGP) richtig eingerichtet sind, die externen Routen korrekt angekündigt und empfangen werden und der BGP-Pfadauswahlprozess ordnungsgemäß funktioniert.
Aktion
Aufgaben |
Befehl oder Aktion |
|---|---|
| BGP-Peers überprüfen | |
|
|
|
|
|
|
|
|
| Prüfung von BGP-Routen und Routenauswahl | |
|
|
|
|
|
|
|
|
| Untersuchen von Routen in der Weiterleitungstabelle |
|
BGP-Peers überprüfen
Zweck
Vorausgesetzt, dass alle Router für BGP korrekt konfiguriert sind, können Sie überprüfen, ob IBGP- und EBGP-Sitzungen ordnungsgemäß eingerichtet sind, externe Routen korrekt angekündigt und empfangen werden und der BGP-Pfadauswahlprozess ordnungsgemäß funktioniert.
Abbildung 1 veranschaulicht ein Beispiel für eine BGP-Netzwerktopologie, die in diesem Thema verwendet wird.
Das Netzwerk besteht aus zwei direkt verbundenen ASs, die aus externen und internen Peers bestehen. Die externen Peers sind direkt über eine gemeinsam genutzte Schnittstelle verbunden und führen EBGP aus. Die internen Peers sind über ihre Loopback -Schnittstellen (lo0) über IBGP verbunden. AS 65001 wird mit OSPF und AS 65002 wird IS-IS als zugrunde liegende IGP ausgeführt. IBGP-Router müssen nicht direkt verbunden werden, die zugrunde liegende IGP ermöglicht es Nachbarn, sich gegenseitig zu erreichen.
Die beiden Router in AS 65001 enthalten jeweils einen EBGP-Link zu AS 65002 (R2 und R4) über die sie aggregierte Präfixe ankündigen: 100.100.1.0 100.100.3.0 100.100.4.0und 100.100.2.0. R1R5 Außerdem injizieren mehrere Exit Discriminator (MED) Werte von 5 bzw. 10 für einige Routen.
Die internen Router in beiden ASs verwenden eine Full-Mesh-IBGP-Topologie. Ein Full-Mesh ist erforderlich, da die Netzwerke keine Konföderationen oder Routenreflektoren verwenden, sodass alle über IBGP erlernten Routen nicht an andere interne Nachbarn verteilt werden. Wenn R3 beispielsweise eine Route von R2gelernt wird, R3 wird diese Route R6 nicht verteilt, da die Route über IBGP gelernt wurde, so R6 dass eine direkte BGP-Verbindung zum R2 Lernen der Route erforderlich ist.
In einer Full-Mesh-Topologie verteilt nur der Router an der Grenze, der externe BGP-Informationen empfängt, diese Informationen an andere Router innerhalb seines AS. Der empfangende Router verteilt diese Informationen nicht an andere IBGP-Router in seiner eigenen AS.
Aus Sicht von AS 65002 sollten folgende Sitzungen angeboten werden:
Die vier Router in AS 65002 sollten über IBGP-Sitzungen miteinander eingerichtet sein.
R2sollte eine EBGP-Sitzung mitR1.R4sollte eine EBGP-Sitzung mitR5.
Führen Sie die folgenden Schritte aus, um BGP-Peers zu überprüfen:
- BGP auf einem internen Router überprüfen
- BGP auf einem Border-Router überprüfen
- Angekündigte BGP-Routen überprüfen
- Überprüfen, ob eine bestimmte BGP-Route auf Ihrem Router empfangen wird
BGP auf einem internen Router überprüfen
Zweck
So überprüfen Sie die BGP-Konfiguration eines internen Routers.
Aktion
Um die BGP-Konfiguration eines internen Routers zu überprüfen, geben Sie den folgenden Cli-Befehl (Command-Line Interface) von Junos OS ein:
user@host> show configuration
Die folgende Beispielausgabe ist für eine BGP-Konfiguration auf R3:
Beispielausgabe
Befehlsname
user@R3> show configuration
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.2/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.3/32;
}
family iso {
address 49.0002.1000.0000.0003.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.3;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.3;
neighbor 10.0.0.2;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
user@R6> show configuration |
[Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.2/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
}
family iso {
address 49.0003.1000.0000.0006.00;
}
}
}
}
routing-options {
[Output truncated...]
router-id 10.0.0.6;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.6;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
Bedeutung
Die Beispielausgabe zeigt eine grundlegende BGP-Konfiguration auf Routern R3 und R6. Die lokale AS (65002) und eine Gruppe (internal) sind auf beiden Routern konfiguriert. R3 Sie verfügt über drei interne Peers – 10.0.0.410.0.0.2und 10.0.0.6–, die auf [protocols bgp group group] Hierarchieebene enthalten sind. R6 Außerdem gibt es drei interne Peers: 10.0.0.2, 10.0.0.3und 10.0.0.4. Das zugrunde liegende IGP-Protokoll ist Intermediate System-to-Intermediate System (IS-IS), und die relevanten Schnittstellen sind für die Ausführung von IS-IS konfiguriert.
Beachten Sie, dass in dieser Konfiguration die Router-ID manuell konfiguriert wird, um doppelte Router-ID-Probleme zu vermeiden.
BGP auf einem Border-Router überprüfen
Zweck
So überprüfen Sie die BGP-Konfiguration eines Border-Routers.
Aktion
Um die BGP-Konfiguration eines Border-Routers zu überprüfen, geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein:
user@host> show configuration
Beispielausgabe
Befehlsname
Die folgende Beispielausgabe ist für eine BGP-Konfiguration auf zwei Border-Routern, R2 und R4 von AS 65002:
user@R2> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.2/30;
}
family iso;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.2/32;
}
family iso {
address 49.0002.1000.0000.0002.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.2;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
export next-hop-self;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
}
group toR1 {
type external;
import import-toR1;
peer-as 65001;
neighbor 10.1.12.1;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
policy-options {
policy-statement next-hop-self {
term change-next-hop {
from neighbor 10.1.12.1;
then {
next-hop self;
}
}
}
policy-statement import-toR1 {
term 1 {
from {
route-filter 100.100.1.0/24 exact;
}
then {
local-preference 200;
}
}
}
user@R4> show configuration
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.1/30;
}
family iso;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.45.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.2/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.4/32;
}
family iso {
address 49.0001.1000.0000.0004.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.4;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.4;
export next-hop-self;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.6;
}
group toR5 {
type external;
peer-as 65001;
neighbor 10.1.45.2;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
policy-options {
policy-statement next-hop-self {
term change-next-hop {
from neighbor 10.1.45.2;
then {
next-hop self;
}
}
}
Bedeutung
Die Beispielausgabe zeigt eine grundlegende BGP-Konfiguration auf Routern R2 und R4. Beide Router verfügen über den AS (65002) auf [routing-options] Hierarchieebene. Jeder Router umfasst zwei Gruppen auf [protocols bgp group group] Hierarchieebene. Externe Peers sind in der externen Gruppe enthalten, entweder toR1 oder toR5, je nach Router. Interne Peers sind in der internal Gruppe enthalten. Das zugrunde liegende IGP-Protokoll ist IS-IS auf beiden Routern, und die entsprechenden Schnittstellen sind für die Ausführung von IS-IS konfiguriert.
Beachten Sie, dass in der Konfiguration auf beiden Routern die Router-ID manuell konfiguriert wird, um Probleme mit der Router-ID zu vermeiden, und die Anweisung ist enthalten, um Probleme mit der next-hop-self BGP-Erreichbarkeit zu vermeiden.
Angekündigte BGP-Routen überprüfen
Zweck
Sie können festlegen, ob eine bestimmte, von Ihnen konfigurierte Route einem Nachbarn angeboten wird.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um die Routinginformationen zu überprüfen, während sie für die Ankündigung für den angegebenen BGP-Nachbarn vorbereitet wurden:
user@host> show route advertising-protocol bgp neighbor-address
Beispielausgabe
Befehlsname
user@R2> show route advertising-protocol bgp 10.0.0.4\ inet.0: 20 destinations, 22 routes (20 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 Self 5 200 65001 I * 100.100.2.0/24 Self 5 100 65001 I * 100.100.3.0/24 Self 100 65001 I * 100.100.4.0/24 Self 100 65001 I
Bedeutung
Die Beispielausgabe zeigt die angekündigten BGP-Routen zum R2 Nachbarn 10.0.0.4 (R4). Von den insgesamt 22 Routen in der inet.0 Routing-Tabelle sind 20 aktive Ziele. Es sind hidden keine Routen im hold-down Status. Routen befinden sich im hold-down Status, bevor sie für aktiv erklärt werden, und Routen, die von einer Routingrichtlinie abgelehnt werden, können in den hidden Status platziert werden. Die angezeigten Informationen spiegeln die Routen wider, die die Routingtabelle in das BGP-Routingprotokoll exportiert hat.
Überprüfen, ob eine bestimmte BGP-Route auf Ihrem Router empfangen wird
Zweck
Zeigen Sie die Routing-Informationen an, wenn sie durch einen bestimmten BGP-Nachbarn empfangen und vom lokalen Router dem Nachbarn angekündigt werden.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um zu überprüfen, ob eine bestimmte BGP-Route auf Ihrem Router empfangen wird:
user@host> show route receive-protocol bgp neighbor-address
Beispielausgabe
Befehlsname
user@R6> show route receive-protocol bgp 10.0.0.2 inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 10.0.0.2 5 200 65001 I * 100.100.2.0/24 10.0.0.2 5 100 65001 I 100.100.3.0/24 10.0.0.2 100 65001 I 100.100.4.0/24 10.0.0.2 100 65001 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) user@R6> show route receive-protocol bgp 10.0.0.4 inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.3.0/24 10.0.0.4 100 65001 I * 100.100.4.0/24 10.0.0.4 100 65001 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Bedeutung
Die Beispielausgabe zeigt vier BGP-Routen von R2 und zwei von R4. Von den vier Routen von R2sind nur zwei in der Routing-Tabelle aktiv, wie durch das Sternchen (*) angegeben, während beide Routen, von R4 denen empfangen wird, in der Routing-Tabelle aktiv sind. Alle BGP-Routen kamen über AS 65001.
Prüfung von BGP-Routen und Routenauswahl
Zweck
Sie können den BGP-Pfadauswahlprozess untersuchen, um den einzelnen aktiven Pfad zu bestimmen, wenn BGP mehrere Routen zu demselben Zielpräfix empfängt.
Das Netzwerk in Abbildung 2 zeigt, dass R1 und R5 kündigt die gleichen aggregierten Routen an R2 und R4, was zu zwei Routen zum selben Zielpräfix führt R2 und R4 empfängt. Bei der Routenauswahl wird R2R4 bestimmt, welche der beiden empfangenen BGP-Routen aktiv ist und den anderen internen Routern (R3 und R6).
Bevor der Router eine BGP-Route installiert, muss er sicherstellen, dass das BGP-Attribut next-hop erreichbar ist. Wenn der BGP next Hop nicht aufgelöst werden kann, wird die Route nicht installiert. Wenn eine BGP-Route in der Routing-Tabelle installiert ist, muss sie einen Pfadauswahlprozess durchlaufen, wenn mehrere Routen zu demselben Zielpräfix vorhanden sind. Der BGP-Pfadauswahlprozess verläuft in der folgenden Reihenfolge:
Die Routenpräferenz in der Routing-Tabelle wird verglichen. Wenn beispielsweise eine OSPF- und eine BGP-Route für ein bestimmtes Ziel vorhanden ist, wird die OSPF-Route als aktive Route ausgewählt, da die OSPF-Route eine Standardeinstellung von 110 hat, während die BGP-Route eine Standardeinstellung von 170 hat.
Routen werden nach lokalen Vorlieben verglichen. Die Route mit der höchsten lokalen Präferenz wird bevorzugt. Beispiel: Überprüfen der Auswahl lokaler Einstellungen.
Das AS-Pfad-Attribut wird ausgewertet. Der kürzere AS-Pfad wird bevorzugt.
Der Ursprungscode wird ausgewertet. Der niedrigste Ursprungscode wird bevorzugt (
I (IGP) < E (EGP) < ? (Incomplete)).Der MED-Wert wird ausgewertet. Wenn eine der Routen von demselben benachbarten AS aus angekündigt wird, wird standardmäßig der niedrigste MED-Wert bevorzugt. Das Fehlen eines MED-Wertes wird als MED von 0 interpretiert. Ein Beispiel finden Sie unter Überprüfen der Routenauswahl für multiplen Exit Discriminator.
Der Pfad wird bewertet, ob er durch EBGP oder IBGP gelernt wird. EBGP-erlernte Routen werden gegenüber IBGP-erlernten Routen bevorzugt. Ein Beispiel finden Sie unter Prüfen der EBGP-über-IBGP-Auswahl.
Wenn die Route von IBGP gelernt wird, wird die Route mit den niedrigsten IGP-Kosten bevorzugt. Ein Beispiel finden Sie unter Überprüfen der IGP-Kostenauswahl. Der physische Next Hop zum IBGP-Peer wird nach den folgenden drei Regeln installiert:
Nachdem BGP die
inet.0Routing-Tabellen untersuchtinet.3hat, wird der physische nächste Hop der Route mit der niedrigsten Präferenz verwendet.
Wenn die Voreinstellungswerte in der
inet.0Routing-Tabelle und in deninet.3Routing-Tabellen eine Bindeverbindung sind, wird der physische nächste Hop der Route in derinet.3Routing-Tabelle verwendet.
Wenn in derselben Routingtabelle eine Einstellungsverbindung vorhanden ist, wird der physische nächste Hop der Route mit mehr Pfaden installiert.
Das Routing-Reflexions-Clusterlisten-Attribut wird ausgewertet. Die Clusterliste mit der kürzesten Länge wird bevorzugt. Routen ohne Clusterliste haben eine Clusterlistenlänge von 0.
Die Router-ID wird ausgewertet. Bevorzugt wird die Route vom Peer mit der niedrigsten Router-ID (normalerweise die Loopback-Adresse).
Der Peer-Adresswert wird untersucht. Der Peer mit der niedrigsten Peer-IP-Adresse wird bevorzugt.
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um den einzelnen aktiven Pfad zu bestimmen, wenn BGP mehrere Routen zu demselben Zielpräfix empfängt:
user@host> show route destination-prefix < detail >
Die folgenden Schritte veranschaulichen den inaktiven Grund, der angezeigt wird, wenn BGP mehrere Routen zu demselben Zielpräfix empfängt und eine Route als einzelner aktiver Pfad ausgewählt wird:
- Prüfen der Auswahl lokaler Präferenzen
- Prüfen der Routenauswahl für Multiple Exit Discriminator
- Prüfung der EBGP-über-IBGP-Auswahl
- IGP-Kostenauswahl prüfen
Prüfen der Auswahl lokaler Präferenzen
Zweck
So prüfen Sie eine Route, um festzustellen, ob die lokale Präferenz die Auswahlkriterien für den einzelnen aktiven Pfad ist.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um zu prüfen, ob die lokale Präferenz die Auswahlkriterien für den einzelnen aktiven Pfad ist:
user@host> show route destination-prefix < detail >
Beispielausgabe
Befehlsname
user@R4> show route 100.100.1.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.1.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-201
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:22:34 Metric: 5 Metric2: 10
Task: BGP_65002.10.0.0.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 200
Router ID: 10.0.0.2
BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <Ext>
Inactive reason: Local Preference
Local AS: 65002 Peer AS: 65001
Age: 2w0d 1:28:31 Metric: 10
Task: BGP_65001.10.1.45.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
Bedeutung
Die Beispielausgabe zeigt, dass R4 zwei Instanzen der 100.100.1.0 Route empfangen wurden: one from 10.0.0.2 (R2) und einer von 10.1.45.2 (R5). R4 wählte den Pfad von R2 als seinen aktiven Pfad, wie durch das Sternchen (*) angezeigt. Die Auswahl basiert auf dem lokalen Voreinstellungswert, der Localpref im Feld enthalten ist. Der Pfad mit der höchsten lokalen Präferenz wird bevorzugt. In diesem Beispiel ist der Pfad mit dem höheren lokalen Vorzugswert der Pfad von R2, 200.
Der Grund, aus dem die Route nicht R5 ausgewählt wird, ist in diesem Fall Local Preferenceim Inactive reason Feld.
Beachten Sie, dass die beiden Pfade aus demselben benachbarten Netzwerk stammen: AS 65001.
Prüfen der Routenauswahl für Multiple Exit Discriminator
Zweck
So prüfen Sie eine Route, um festzustellen, ob med die Auswahlkriterien für den einzelnen aktiven Pfad ist.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um zu prüfen, ob med die Auswahlkriterien für den einzelnen aktiven Pfad ist:
user@host> show route destination-prefix < detail >
Beispielausgabe
Befehlsname
user@R4> show route 100.100.2.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.2.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:32:01 Metric: 5 Metric2: 10
Task: BGP_65002.10.0.0.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Not Best in its group
Local AS: 65002 Peer AS: 65001
Age: 2w0d 1:37:58 Metric: 10
Task: BGP_65001.10.1.45.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
Bedeutung
Die Beispielausgabe zeigt, dass R4 zwei Instanzen der 100.100.2.0 Route empfangen wurden: eine von 10.0.0.2 (R2) und eine von 10.1.45.2 (R5). R4 wählten den Pfad von R2 als aktive Route aus, wie durch das Sternchen (*) angezeigt. Die Auswahl basiert auf dem im Metric: Feld enthaltenen MED-Wert. Der Pfad mit dem niedrigsten MED-Wert wird bevorzugt. In diesem Beispiel ist der Pfad mit dem niedrigsten MED-Wert (5) der Pfad von R2. Beachten Sie, dass die beiden Pfade aus demselben benachbarten Netzwerk stammen: AS 65001.
Der Grund dafür, dass der inaktive Pfad nicht ausgewählt wird, wird im Inactive reason: Feld angezeigt, in diesem Fall Not Best in its group. Die Formulierung wird verwendet, weil junos OS standardmäßig den Prozess der deterministischen MED-Auswahl verwendet.
Prüfung der EBGP-über-IBGP-Auswahl
Zweck
So prüfen Sie eine Route, um festzustellen, ob EBGP über IBGP als Auswahlkriterien für den einzelnen aktiven Pfad ausgewählt wurde.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um eine Route zu prüfen, um festzustellen, ob EBGP über IBGP als Auswahlkriterien für den einzelnen aktiven Pfad ausgewählt wurde:
user@host> show route destination-prefix < detail >
Beispielausgabe
Befehlsname
user@R4> show route 100.100.3.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.3.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <Active Ext>
Local AS: 65002 Peer AS: 65001
Age: 5d 0:31:25
Task: BGP_65001.10.1.45.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <NotBest Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Local AS: 65002 Peer AS: 65002
Age: 2:48:18 Metric2: 10
Task: BGP_65002.10.0.0.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
Bedeutung
Die Beispielausgabe zeigt, dass R4 zwei Instanzen der 100.100.3.0 Route empfangen wurden: one from 10.1.45.2 (R5) und einer von 10.0.0.2 (R2). R4 wählte den Pfad von R5 als seinen aktiven Pfad, wie durch das Sternchen (*) angezeigt. Die Auswahl basiert auf einer Präferenz für Routen, die von einem EBGP-Peer gelernt wurden, über Routen, die von 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 Local As felder und Peer As überprüfen. Die Route von R5 zeigt beispielsweise, dass der lokale AS 65002 und der Peer AS 65001 ist, was anzeigt, dass die Route von einem EBGP-Peer empfangen wird. Die Route von R2 zeigt, dass sowohl der lokale als auch der Peer AS 65002 lautet, was anzeigt, dass er von einem IBGP-Peer empfangen wird.
Der Grund dafür, dass der inaktive Pfad nicht ausgewählt wird, wird im Inactive reason Feld angezeigt, in diesem Fall Interior > Exterior > Exterior via Interior. Der Wortlaut dieses Grundes zeigt die Reihenfolge der Einstellungen, die angewendet werden, wenn dieselbe Route von zwei Routern empfangen wird. Die Route, die von einer streng internen Quelle (IGP) empfangen wird, wird zuerst bevorzugt, die Route, die von einer externen Quelle (EBGP) empfangen wird, wird als Nächstes bevorzugt, und jede Route, die von einer externen Quelle stammt und intern empfangen wird (IBGP) wird zuletzt bevorzugt. Daher werden EBGP-Routen über IBGP-Routen als aktiver Pfad ausgewählt.
IGP-Kostenauswahl prüfen
Zweck
So prüfen Sie eine Route, um festzustellen, ob EBGP über IBGP als Auswahlkriterien für den einzelnen aktiven Pfad ausgewählt wurde.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um eine Route zu prüfen, um festzustellen, ob EBGP über IBGP als Auswahlkriterien für den einzelnen aktiven Pfad ausgewählt wurde:
user@host> show route destination-prefix < detail >
Beispielausgabe
Befehlsname
user@R6> show route 100.100.4.0 detail
inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden)
100.100.4.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.4
Next hop: 10.1.46.1 via so-0/0/1.0, selected
Protocol next hop: 10.0.0.4 Indirect next hop: 864c000 276
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:16:11 Metric2: 10
Task: BGP_65002.10.0.0.4+4120
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.4
BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.46.1 via so-0/0/1.0, selected
Next hop: 10.1.36.1 via so-0/0/3.0
Protocol next hop: 10.0.0.2 Indirect next hop: 864c0b0 278
State: <NotBest Int Ext>
Inactive reason: IGP metric
Local AS: 65002 Peer AS: 65002
Age: 2:16:03 Metric2: 20
Task: BGP_65002.10.0.0.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
Bedeutung
Die Beispielausgabe zeigt, dass R6 zwei Instanzen der 100.100.4.0 Route empfangen wurden: one from 10.0.0.4 (R4) und einer von 10.0.0.2 (R2). R6 wählte den Pfad von R4 als aktive Route, wie durch das Sternchen (*) angezeigt. Die Auswahl basiert auf der IGP-Metrik, die Metric2 im Feld angezeigt wird. Die Route mit der niedrigsten IGP-Metrik wird bevorzugt. In diesem Beispiel ist der Pfad mit dem niedrigsten IGP-Wert der Pfad von R4, mit einem IGP-Metrikwert von 10, während der Pfad von R2 eine IGP-Metrik von 20 hat. Beachten Sie, dass die beiden Pfade aus demselben benachbarten Netzwerk stammen: AS 65001.
Der Grund, warum der inaktive Pfad nicht ausgewählt wurde, wird im Inactive reason Feld angezeigt, in diesem Fall IGP metric.
Checkliste zur Überprüfung der BGP-Ebene
Problem
Beschreibung
Diese Checkliste enthält die Schritte und Befehle zur Überprüfung der BGP-Konfiguration des Multiprotocol Label Switching (MPLS)-Netzwerks. Die Checkliste enthält Links zu einem Überblick über die BGP-Konfiguration und detaillierteren Informationen zu den Zur Konfiguration von BGP verwendeten Befehlen. (Siehe Tabelle 2.)
Lösung
Aufgaben |
Befehl oder Aktion |
|---|---|
| Überprüfen der BGP-Ebene | |
|
|
|
|
|
|
|
|
|
|
Die folgende Befehlsreihenfolge behebt das in diesem Thema beschriebene spezifische Problem:
|
|
|
Überprüfen der BGP-Ebene
Zweck
Nachdem Sie den Label-Switched Path (LSP) konfiguriert und festgestellt haben, dass er aktiviert ist, BGP konfiguriert und festgestellt haben, dass Sitzungen eingerichtet werden, stellen Sie sicher, dass BGP den LSP zur Weiterleitung des Datenverkehrs verwendet.
Abbildung 3 veranschaulicht die BGP-Ebene des mehrschichtigen MPLS-Modells.
Wenn Sie die BGP-Ebene überprüfen, stellen Sie sicher, dass die Route vorhanden und aktiv ist, und vor allem stellen Sie sicher, dass der nächste Hop der LSP ist. Es gibt keinen Sinn, die BGP-Ebene zu überprüfen, es sei denn, der LSP ist eingerichtet, da BGP den MPLS-LSP zur Weiterleitung des Datenverkehrs verwendet. Wenn das Netzwerk auf BGP-Ebene nicht funktioniert, funktioniert der LSP nicht wie konfiguriert.
Abbildung 4 veranschaulicht das in diesem Thema verwendete MPLS-Netzwerk.
Das dargestellte Netzwerk ist eine vollständig vermaschte Konfiguration, in Abbildung 4 der jede direkt angeschlossene Schnittstelle Pakete empfangen und an jede andere ähnliche Schnittstelle senden kann. Der LSP in diesem Netzwerk ist so konfiguriert, dass er vom Eingangs-Router R1über den Transit-Router R3bis zum Ausgangsrouter R6läuft. Darüber hinaus ist ein Reverse LSP so konfiguriert, dass er von R6 bis R3 zu R1läuft und so bidirektionalen Datenverkehr erzeugt.
Das In-Kreuz Abbildung 4 zeigt an, wo BGP nicht verwendet wird, um den Datenverkehr über den LSP weiterzuleiten. Mögliche Gründe dafür, dass der LSP nicht richtig funktioniert, sind, dass die Ziel-IP-Adresse des LSP nicht dem BGP-nächsten Hop entspricht oder dass BGP nicht richtig konfiguriert ist.
Führen Sie die folgenden Schritte aus, um die BGP-Ebene zu überprüfen:
- Überprüfen, ob BGP-Datenverkehr den LSP verwendet
- BGP-Sitzungen überprüfen
- Überprüfen der BGP-Konfiguration
- Prüfung von BGP-Routen
- Überprüfen der empfangenen BGP-Routen
- Ergreifen geeigneter Maßnahmen zur Lösung des Netzwerkproblems
- Überprüfen Sie erneut, ob der BGP-Datenverkehr den LSP verwendet
Überprüfen, ob BGP-Datenverkehr den LSP verwendet
Zweck
Auf dieser Ebene des Fehlerbehebungsmodells sind BGP und der LSP möglicherweise nicht aktiv, aber BGP-Datenverkehr verwendet den LSP möglicherweise nicht, um den Datenverkehr weiterzuleiten.
Aktion
Um zu überprüfen, ob BGP-Datenverkehr den LSP verwendet, geben Sie den folgenden Cli-Modus-Befehl (Command-Line Interface) von Junos OS vom Eingangsrouter ein:
user@host> traceroute hostname
Beispielausgabe
Befehlsname
user@R1> traceroute 100.100.6.1 traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets 1 10.1.13.2 (10.1.13.2) 0.653 ms 0.590 ms 0.543 ms 2 10.1.36.2 (10.1.36.2) 0.553 ms !N 0.552 ms !N 0.537 ms !N user@R6> traceroute 100.100.1.1 traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets 1 10.1.36.1 (10.1.36.1) 0.660 ms 0.551 ms 0.526 ms 2 10.1.13.1 (10.1.13.1) 0.568 ms !N 0.553 ms !N 0.536 ms !N
Bedeutung
Die Beispielausgabe zeigt, dass BGP-Datenverkehr den LSP nicht verwendet, folglich werden MPLS-Label nicht in der Ausgabe angezeigt. Anstatt den LSP zu verwenden, verwendet BGP-Datenverkehr das Interior Gateway Protocol (IGP), um die BGP-Adresse des nächsten HopS zu erreichen LSP-Ausgangsadresse für R6 und R1. Junos OS verwendet standardmäßig LSPs für BGP-Datenverkehr, wenn der BGP-nächste Hop der LSP-Ausgangsadresse entspricht.
BGP-Sitzungen überprüfen
Zweck
Zeigen Sie Zusammenfassungsinformationen zu BGP und seinen Nachbarn an, um zu bestimmen, ob Routen von Peers im autonomen System (AS) empfangen werden. Wenn eine BGP-Sitzung eingerichtet wird, tauschen die Peers Aktualisierungsnachrichten aus.
Aktion
Um zu überprüfen, ob BGP-Sitzungen verfügbar sind, geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl vom Eingangsrouter ein:
user@host> show bgp summary
Beispielausgabe 1
Befehlsname
user@R1> show bgp summary Groups: 1 Peers: 6 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.3 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.4 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.5 65432 11257 11260 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.6 65432 4 4572 0 1 3d 21:46:59 Active 10.1.36.2 65432 11252 11257 0 0 3d 21:46:49 1/1/0 0/0/0
Beispielausgabe 2
Befehlsname
user@R1> show bgp summary Groups: 1 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65432 64 68 0 0 32:18 0/0/0 0/0/0 10.0.0.3 65432 64 67 0 0 32:02 0/0/0 0/0/0 10.0.0.4 65432 64 67 0 0 32:10 0/0/0 0/0/0 10.0.0.5 65432 64 67 0 0 32:14 0/0/0 0/0/0 10.0.0.6 65432 38 39 0 1 18:02 1/1/0 0/0/0
Bedeutung
Die Beispielausgabe 1 zeigt, dass ein Peer (Ausgangsrouter 10.0.0.6 ) nicht eingerichtet ist, wie durch das Down Peers: 1 Feld angegeben. Die letzte Spalte (State|#Active/Received/Damped) zeigt, dass der Peer 10.0.0.6 aktiv ist, was anzeigt, dass er nicht eingerichtet ist. Alle anderen Peers werden anhand der Anzahl der aktiven, empfangenen und gedämpften Routen ermittelt. Für Peer 10.0.0.2 bedeutet beispielsweise, 0/0/0 dass in der Routingtabelle keine BGP-Routen aktiv oder empfangen waren und keine BGP-Routen gedämpft wurden; 1/1/0 für Peer 10.1.36.2 bedeutet, dass eine BGP-Route aktiv war und in der Routing-Tabelle empfangen wurde, und keine BGP-Routen gedämpft wurden.
Wenn die Ausgabe des show bgp summary Befehls eines Eingangsrouters anzeigt, dass ein Nachbar ausfällt, überprüfen Sie die BGP-Konfiguration. Informationen zum Überprüfen der BGP-Konfiguration finden Sie unter Überprüfen der BGP-Konfiguration.
Die Beispielausgabe 2 zeigt die Ausgabe des Eingangs-Routers R1 nach den BGP-Konfigurationen R1 und R6 wurde in "Ergreifen der geeigneten Maßnahmen zur Lösung des Netzwerkproblems" korrigiert. Alle BGP-Peers werden eingerichtet und eine Route ist aktiv und empfangen. Es wurden keine BGP-Routen gedämpft.
Wenn aus der Ausgabe des show bgp summary Befehls hervorgeht, dass ein Neighbor aktiv ist, Pakete aber nicht weitergeleitet werden, prüfen Sie nach empfangenen Routen vom Ausgangsrouter. Informationen zum Überprüfen des Ausgangsrouters auf empfangene Routen finden Sie unter Überprüfen empfangener BGP-Routen.
Überprüfen der BGP-Konfiguration
Zweck
Damit BGP auf dem Router ausgeführt werden kann, müssen Sie die lokale AS-Nummer definieren, mindestens eine Gruppe konfigurieren und Informationen zu mindestens einem Peer in der Gruppe (die IP-Adresse und AS-Nummer des Peers) einschließen. Wenn BGP Teil eines MPLS-Netzwerks ist, müssen Sie sicherstellen, dass der LSP mit einer Ziel-IP-Adresse konfiguriert ist, die dem BGP-nächsten Hop entspricht, damit BGP-Routen mit dem LSP als nächster Hop für diese Routen installiert werden können.
Aktion
Geben Sie zum Überprüfen der BGP-Konfiguration den folgenden Junos OS CLI-Betriebsmodus-Befehl ein:
user@host> show configuration
Beispielausgabe 1
Befehlsname
user@R1> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.1/30;
}
family iso;
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.15.1/30;
}
family iso;
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.13.1/30;
}
family iso;
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
family iso {
address 49.0004.1000.0000.0001.00;
}
}
}
}
routing-options {
[...Output truncated...]
route 100.100.1.0/24 reject;
}
router-id 10.0.0.1;
autonomous-system 65432;
}
protocols {
rsvp {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R1-to-R6 {
to 10.0.0.6; <<< destination address of the LSP
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; <<< missing local-address statement
group internal {
type internal;
neighbor 10.0.0.2;
neighbor 10.0.0.5;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
neighbor 10.0.0.3;
neighbor 10.1.36.2; <<< incorrect interface address
}
}
isis {
level 1 disable;
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface all {
level 2 metric 10;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0; {
passive
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
Beispielausgabe 2
Befehlsname
user@R6> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.56.2/30;
}
family iso;
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.2/30;
}
family iso;
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.26.2/30;
}
family iso;
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
address 127.0.0.1/32;
}
family iso {
address 49.0004.1000.0000.0006.00;
}
}
}
}
routing-options {
[...Output truncated...]
route 100.100.6.0/24 reject;
}
router-id 10.0.0.6;
autonomous-system 65432;
}
protocols {
rsvp {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R6-to-R1 {
to 10.0.0.1; <<< destination address of the reverse LSP
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
inactive: interface so-0/0/2.0;
interface so-0/0/3.0;
}
bgp {
group internal {
type internal;
export send-statics; <<< missing local-address statement
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.5;
neighbor 10.0.0.1;
neighbor 10.1.13.1; <<< incorrect interface address
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface lo0.0 {
passive;
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.6.0/24 exact;
}
then accept;
}
}
}
Bedeutung
Die Beispielausgabe zeigt die BGP-Konfigurationen auf Eingangs- R1 und Ausgangsrouter R6. Beide Konfigurationen zeigen den lokalen AS (65432), eine Gruppe (internal) und sechs Peers konfiguriert. Das zugrunde liegende Innere Gateway-Protokoll ist IS-IS, und die entsprechenden Schnittstellen sind für die Ausführung von IS-IS konfiguriert.
In dieser Konfiguration wird der RID manuell konfiguriert, um doppelte RID-Probleme zu vermeiden, und alle mit BGP konfigurierten Schnittstellen enthalten die family inet Anweisung auf der Hierarchieebene [edit interfaces type-fpc/pic/port unit logical-unit-number].
Die Beispielausgabe für Eingangs- und Ausgangsrouter R1R6 zeigt, dass in der BGP-Protokollkonfiguration die local-address Anweisung für die interne Gruppe fehlt. Wenn die local-address Anweisung konfiguriert ist, werden BGP-Pakete von der lokalen Router-Loopback (lo0)-Schnittstellenadresse weitergeleitet, die die Adresse ist, an die BGP-Peers peering. Wenn die local-address Anweisung nicht konfiguriert ist, werden BGP-Pakete von der ausgehenden Schnittstellenadresse weitergeleitet, die nicht mit der Adresse übereinstimmt, mit der BGP-Peers peering, und BGP wird nicht angezeigt.
Auf dem Eingangsrouter sollte die IP-Adresse (10.0.0.1) in der local-address Anweisung die gleiche sein wie die Adresse, die für den LSP auf dem Ausgangsrouter (R6) in der to Anweisung auf der Hierarchieebene [edit protocols mpls label-switched-path lsp-path-name] konfiguriert wurde. BGP verwendet diese Adresse, die mit der LSP-Adresse identisch ist, um BGP-Datenverkehr über den LSP weiterzuleiten.
Darüber hinaus umfasst die BGP-Konfiguration R1 zwei IP-Adressen für R6, eine Schnittstellenadresse (10.1.36.2) und eine Loopback -Schnittstellenadresse (lo010.0.0.6), was dazu führt, dass die LSP-Zieladresse () nicht mit der BGP-Next-Hop-Adresse übereinstimmt10.0.0.6 (10.1.36.2). Die BGP-Konfiguration auf R6 umfasst auch zwei IP-Adressen für R1, eine Schnittstellenadresse (10.1.13.1) und eine Loopback-Schnittstellenadresse (lo0), was dazu führt, dass die Reverse-LSP-Zieladresse (10.0.0.1) nicht mit der BGP-Next-Hop-Adresse übereinstimmt (10.1.13.1).
Da in dieser Instanz die local-address Anweisung in den BGP-Konfigurationen beider Router fehlt und die LSP-Zieladresse nicht mit der BGP-Next-Hop-Adresse übereinstimmt, verwendet BGP den LSP nicht zur Weiterleitung des Datenverkehrs.
Prüfung von BGP-Routen
Zweck
Sie können den BGP-Pfadauswahlprozess untersuchen, um den einzelnen aktiven Pfad zu bestimmen, wenn BGP mehrere Routen zum gleichen Ziel empfängt. In diesem Schritt untersuchen wir den Reverse LSP R6-to-R1und machen R6 den Eingangsrouter für diesen LSP.
Aktion
Um BGP-Routen und Routenauswahl zu untersuchen, geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein:
user@host> show route destination-prefix detail
Beispielausgabe 1
Befehlsname
user@R6> show route 100.100.1.1 detail
inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden)
100.100.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.1.13.1
Next hop: via so-0/0/3.0, selected
Protocol next hop: 10.1.13.1 Indirect next hop: 8671594 304
State: <Active Int Ext>
Local AS: 65432 Peer AS: 65432
Age: 4d 5:15:39 Metric2: 2
Task: BGP_65432.10.1.13.1+3048
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: I
Localpref: 100
Router ID: 10.0.0.1
Beispielausgabe 2
Befehlsname
user@R6> show route 100.100.1.1 detail
inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden)
100.100.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.1
Next hop: via so-0/0/3.0 weight 1, selected
Label-switched-path R6-to-R1
Label operation: Push 100000
Protocol next hop: 10.0.0.1 Indirect next hop: 8671330 301
State: <Active Int Ext>
Local AS: 65432 Peer AS: 65432
Age: 24:35 Metric2: 2
Task: BGP_65432.10.0.0.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: I
Localpref: 100
Router ID: 10.0.0.1
Bedeutung
Die Beispielausgabe 1 zeigt, dass der BGP next Hop (10.1.13.1) nicht gleich der LSP-Zieladresse (10.0.0.1) in der to Anweisung auf Hierarchieebene [edit protocols mpls label-switched-path label-switched-path-name] entspricht, wenn die BGP-Konfiguration von R6 und R1 falsch ist.
Die Beispielausgabe 2, die nach der Korrektur der Konfigurationen auf R1 und R6 vorgenommen wurde, zeigt, dass der BGP-nächste Hop (10.0.0.1) und die LSP-Zieladresse (10.0.0.1) identisch sind, was anzeigt, dass BGP den LSP zur Weiterleitung von BGP-Datenverkehr verwenden kann.
Überprüfen der empfangenen BGP-Routen
Zweck
Zeigen Sie die vom Router R6empfangenen Routing-Informationen an, den Eingangsrouter für den Reverse LSP R6-to-R1.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl ein, um zu überprüfen, ob eine bestimmte BGP-Route auf dem Ausgangsrouter empfangen wird:
user@host> show route receive protocol bgp neighbor-address
Beispielausgabe 1
Befehlsname
user@R6> show route receive-protocol bgp 10.0.0.1 inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden) <<< missing route inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) __juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Beispielausgabe 2
Befehlsname
user@R6> show route receive-protocol bgp 10.0.0.1 inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 10.0.0.1 100 I inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) __juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Bedeutung
Die Beispielausgabe 1 zeigt, dass der Eingangsrouter R6 (Reverse LSP R6-to-R1) keine BGP-Routen in die inet.0 Routingtabelle empfängt, wenn die BGP-Konfigurationen von R1 und R6 nicht korrekt sind.
Beispielausgabe 2 zeigt eine BGP-Route, die nach den BGP-Konfigurationen in der inet.0 Routing-Tabelle installiert wurde, und R6 sie wurde mithilfe von Ergreifen der geeigneten Maßnahmen zur Lösung des NetzwerkproblemsR1 korrigiert.
Ergreifen geeigneter Maßnahmen zur Lösung des Netzwerkproblems
Problem
Beschreibung
Die geeignete Aktion hängt von der Art des Problems ab, die Sie isoliert haben. In diesem Beispiel wird eine konfigurierte statische Route R2 aus der Hierarchieebene [routing-options] gelöscht. Andere geeignete Maßnahmen können folgendes umfassen:
Lösung
Überprüfen Sie die Konfiguration des lokalen Routers und bearbeiten Sie sie gegebenenfalls.
Fehlerbehebung für den zwischengeschalteten Router.
Überprüfen Sie die Remote-Host-Konfiguration und bearbeiten Sie sie gegebenenfalls.
Fehlerbehebung bei Routing-Protokollen.
Identifizieren Sie weitere mögliche Ursachen.
Geben Sie die folgenden Junos OS CLI-Befehle ein, um das Problem in diesem Beispiel zu beheben:
[edit]
user@R2# delete routing-options static route destination-prefix
user@R2# commit and-quit
user@R2# show route destination-prefix
Beispielausgabe
[edit]
user@R2# delete routing-options static route 10.0.0.5/32
[edit]
user@R2# commit and-quit
commit complete
Exiting configuration mode
user@R2> show route 10.0.0.5
inet.0: 22 destinations, 24 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32 *[BGP/170] 3d 20:26:17, MED 5, localpref 100
AS path: 65001 I
> to 10.1.12.1 via so-0/0/0.0
Bedeutung
Die Beispielausgabe zeigt die statische Route, die aus der Hierarchie [routing-options] gelöscht wurde und die neue Konfiguration zugesagt wurde. Die Ausgabe für den show route Befehl zeigt nun die BGP-Route als bevorzugte Route an, wie durch das Sternchen angezeigt (*).
Überprüfen Sie erneut, ob der BGP-Datenverkehr den LSP verwendet
Zweck
Nachdem Sie die entsprechende Maßnahme zur Behebung des Fehlers ergriffen haben, muss der LSP erneut überprüft werden, um zu bestätigen, dass BGP-Datenverkehr den LSP verwendet und dass das Problem auf der BGP-Ebene gelöst wurde.
Aktion
Um zu überprüfen, ob BGP-Datenverkehr den LSP verwendet, geben Sie den folgenden Junos OS CLI-Betriebsmodus-Befehl vom Eingangsrouter ein:
user@host> traceroute hostname
Beispielausgabe
Befehlsname
user@R1> traceroute 100.100.6.1
traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets
1 10.1.13.2 (10.1.13.2) 0.858 ms 0.740 ms 0.714 ms
MPLS Label=100016 CoS=0 TTL=1 S=1
2 10.1.36.2 (10.1.36.2) 0.592 ms !N 0.564 ms !N 0.548 ms !N
user@R6> traceroute 100.100.1.1
traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets
1 10.1.36.1 (10.1.36.1) 0.817 ms 0.697 ms 0.771 ms
MPLS Label=100000 CoS=0 TTL=1 S=1
2 10.1.13.1 (10.1.13.1) 0.581 ms !N 0.567 ms !N 0.544 ms !N
Bedeutung
Die Beispielausgabe zeigt, dass MPLS-Label verwendet werden, um Pakete über den LSP weiterzuleiten. In der Ausgabe enthalten ist ein Label-Wert (MPLS Label=100016), der Time-to-Live-Wert (TTL=1) und der Stack-Bit-Wert (S=1).
Das MPLS Label Feld wird verwendet, um das Paket an einen bestimmten LSP zu identifizieren. Es handelt sich um ein 20-Bit-Feld mit einem maximalen Wert von (2^^20-1), etwa 1.000.000.
Der Time-to-Live -Wert (TTL) enthält eine Begrenzung der Anzahl der Hops, die dieses MPLS-Paket durch das Netzwerk reisen kann (1). Es wird bei jedem Hop dekrementiert, und wenn der TTL-Wert unter einen fällt, wird das Paket verworfen.
Der untere Wert des Stack-Bits (S=1) zeigt an, dass das letzte Label im Stack ist und dass diesem MPLS-Paket ein Label zugeordnet ist. Die MPLS-Implementierung im Junos OS unterstützt eine Stacktiefe von 3 auf den Routern der M-Serie und bis zu 5 auf den Routing-Plattformen der T-Serie. Weitere Informationen zum MPLS-Label-Stacking finden Sie unter RFC 3032, MPLS Label Stack Encoding.
MPLS-Label werden in der Beispielausgabe angezeigt, da der traceroute Befehl an ein BGP-Ziel ausgegeben wird, bei dem der nächste BGP-Hop für diese Route die LSP-Ausgangsadresse ist. Das Junos OS verwendet standardmäßig LSPs für BGP-Datenverkehr, wenn der BGP-nächste Hop der LSP-Ausgangsadresse entspricht.
Wenn der nächste BGP-Hop nicht gleich der LSP-Ausgangsadresse ist, verwendet der BGP-Datenverkehr den LSP nicht, und folglich werden MPLS-Label nicht in der Ausgabe für den traceroute Befehl angezeigt, wie in der Beispielausgabe in Check BGP Sessions angegeben.
Anzeige gesendeter oder empfangener BGP-Pakete
Aktion
Führen Sie die folgenden Schritte aus, um die Ablaufverfolgung für gesendete oder empfangene BGP-Protokollpakete zu konfigurieren:
Wechseln Sie im Konfigurationsmodus zur folgenden Hierarchieebene:
[edit] user@host# edit protocol bgp traceoptions
Konfigurieren Sie das Flag, um gesendete, empfangene oder beide gesendete und empfangene Paketinformationen anzuzeigen:
[edit protocols bgp traceoptions] user@host# set flag update sendoder
[edit protocols bgp traceoptions] user@host# set flag update receive
oder
[edit protocols bgp traceoptions] user@host# set flag update
Konfiguration überprüfen:
user@host# show
Zum Beispiel:
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send;
oder
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update receive;
oder
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send receive;
Konfiguration festlegen:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameZum Beispiel:
[edit protocols bgp traceoptions] user@host# run show log bgplog Sep 13 12:58:23 trace_on: Tracing to "/var/log/bgplog" started Sep 13 12:58:23 BGP RECV flags 0x40 code ASPath(2): <null> Sep 13 12:58:23 BGP RECV flags 0x40 code LocalPref(5): 100 Sep 13 12:58:23 BGP RECV flags 0xc0 code Extended Communities(16): 2:10458:3 [...Output truncated...]
Untersuchen von Routen in der Weiterleitungstabelle
Zweck
Wenn Probleme auftreten, z. B. Konnektivitätsprobleme, müssen Sie möglicherweise die Routen in der Weiterleitungstabelle überprüfen, um zu überprüfen, ob der Routingprotokollprozess die richtigen Informationen in die Weiterleitungstabelle weitergeleitet hat.
Aktion
Geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein, um den Satz der in der Weiterleitungstabelle installierten Routen anzuzeigen:
user@host> show route forwarding-table
Beispielausgabe
Befehlsname
user@R2> show route forwarding-table Routing table: inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 10 1 10.0.0.2/32 intf 0 10.0.0.2 locl 256 1 10.0.0.3/32 user 1 10.1.23.0 ucst 282 4 so-0/0/1.0 10.0.0.4/32 user 1 10.1.24.0 ucst 290 7 so-0/0/3.0 10.0.0.6/32 user 1 10.1.24.0 ucst 290 7 so-0/0/3.0 10.1.12.0/30 intf 1 ff.3.0.21 ucst 278 6 so-0/0/0.0 10.1.12.0/32 dest 0 10.1.12.0 recv 280 1 so-0/0/0.0 10.1.12.2/32 intf 0 10.1.12.2 locl 277 1 10.1.12.3/32 dest 0 10.1.12.3 bcst 279 1 so-0/0/0.0 10.1.23.0/30 intf 0 ff.3.0.21 ucst 282 4 so-0/0/1.0 10.1.23.0/32 dest 0 10.1.23.0 recv 284 1 so-0/0/1.0 10.1.23.1/32 intf 0 10.1.23.1 locl 281 1 10.1.23.3/32 dest 0 10.1.23.3 bcst 283 1 so-0/0/1.0 10.1.24.0/30 intf 0 ff.3.0.21 ucst 290 7 so-0/0/3.0 10.1.24.0/32 dest 0 10.1.24.0 recv 292 1 so-0/0/3.0 10.1.24.1/32 intf 0 10.1.24.1 locl 289 1 10.1.24.3/32 dest 0 10.1.24.3 bcst 291 1 so-0/0/3.0 10.1.36.0/30 user 0 10.1.23.0 ucst 282 4 so-0/0/1.0 10.1.46.0/30 user 0 10.1.24.0 ucst 290 7 so-0/0/3.0 100.100.1.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.2.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.3.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.4.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 [...Output truncated...]
Bedeutung
Die Beispielausgabe zeigt die Präfixe auf Netzwerkebene und deren nächste Hops, die in der Weiterleitungstabelle installiert sind. Die Ausgabe enthält die gleichen Next-Hop-Informationen wie im show route detail Befehl (Next-Hop-Adresse und Schnittstellenname). Weitere Informationen umfassen den Zieltyp, den Next-Hop-Typ, die Anzahl der Verweise auf diesen nächsten Hop und einen Index in eine interne Next-Hop-Datenbank. (Die interne Datenbank enthält zusätzliche Informationen, die von der Packet Forwarding Engine verwendet werden, um eine ordnungsgemäße Kapselung von Paketen zu gewährleisten, die über eine Schnittstelle gesendet werden. Auf diese Datenbank kann der Benutzer nicht zugreifen.
Detaillierte Informationen zur Bedeutung der verschiedenen Flags und Typenfelder finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Beispiel: Überschreiben der Standard-BGP-Routing-Richtlinie auf Paketübertragungs-Routern der PTX-Serie
Dieses Beispiel zeigt, wie sie die Standard-Routing-Richtlinie auf Paketübertragungsroutern wie den Paketübertragungs-Routern der PTX-Serie außer Kraft setzt.
Anforderungen
Für dieses Beispiel ist Junos OS Version 12.1 oder höher erforderlich.
Überblick
Standardmäßig installieren die Router der PTX-Serie keine BGP-Routen in der Weiterleitungstabelle.
Bei Routern der PTX-Serie hat die Konfiguration der from protocols bgp Bedingung mit der then accept Aktion nicht das übliche Ergebnis wie auf anderen Junos OS-Routing-Geräten. Mit der folgenden Routing-Richtlinie auf Routern der PTX-Serie werden BGP-Routen nicht in der Weiterleitungstabelle installiert.
user@host# show policy-options
policy-statement accept-no-install {
term 1 {
from protocol bgp;
then accept;
}
}
user@host# show routing-options
forwarding-table {
export accept-no-install;
}
user@host> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 2
In der Weiterleitungstabelle sind keine BGP-Routen installiert. Das ist das erwartete Verhalten.
Dieses Beispiel zeigt, wie Sie mithilfe der then install-to-fib Aktion die Standard-BGP-Routingrichtlinie effektiv außer Kraft setzen.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.
set policy-options prefix-list install-bgp 66.0.0.1/32 set policy-options policy-statement override-ptx-series-default term 1 from prefix-list install-bgp set policy-options policy-statement override-ptx-series-default term 1 then load-balance per-prefix set policy-options policy-statement override-ptx-series-default term 1 then install-to-fib set routing-options forwarding-table export override-ptx-series-default
Installation ausgewählter BGP-Routen in der Weiterleitungstabelle
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der 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:
Konfigurieren Sie eine Liste der zu installierenden Präfixe in der Weiterleitungstabelle.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Konfigurieren Sie die Routing-Richtlinie und wenden Sie die Präfixliste als Bedingung an.
[edit policy-options policy-statement override-ptx-series-default term 1] user@host# set from prefix-list install-bgp user@host# set then install-to-fib user@host# set then load-balance per-prefix
Wenden Sie die Routingrichtlinie auf die Weiterleitungstabelle an.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie die show policy-options befehle eingeben show routing-options . Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show policy-options
prefix-list install-bgp {
66.0.0.1/32;
}
policy-statement override-ptx-series-default {
term 1 {
from {
prefix-list install-bgp;
}
then {
load-balance per-prefix;
install-to-fib;
}
}
}
user@host# show routing-options
forwarding-table {
export override-ptx-series-default;
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen der Installation der ausgewählten Route in der Weiterleitungstabelle
Zweck
Stellen Sie sicher, dass die konfigurierte Richtlinie die Standardrichtlinie überschreibt.
Aktion
Geben Sie im Betriebsmodus den show route forwarding-table Befehl ein.
user@host> show route forwarding-table destination 66.0.0.1
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
66.0.0.1/32 user 0 indr 2097159 3
ulst 2097156 2
5.1.0.2 ucst 574 1 et-6/0/0.1
5.2.0.2 ucst 575 1 et-6/0/0.2
Bedeutung
Diese Ausgabe zeigt, dass die Route zu 66.0.0.1/32 in der Weiterleitungstabelle installiert ist.
Protokoll von BGP-Statusübergangsereignissen
Zweck
Border Gateway Protocol (BGP)-Statusübergänge weisen auf ein Netzwerkproblem hin, das protokolliert und untersucht werden muss.
Aktion
Führen Sie die folgenden Schritte aus, um BGP-Statusübergangsereignisse im Systemprotokoll zu protokollieren:
Wechseln Sie im Konfigurationsmodus zur folgenden Hierarchieebene:
[edit] user@host# edit protocol bgpKonfigurieren Sie das Systemprotokoll:
user@host# set log-updown
Konfiguration überprüfen:
user@host# show
Konfiguration festlegen:
user@host# commit
Bedeutung
Protokollmeldungen von BGP-Zustandsübergangsereignissen reichen aus, um die meisten BGP-Sitzungsprobleme zu diagnostizieren. Tabelle 3 listet die sechs Zustände einer BGP-Sitzung auf und beschreibt sie.
BGP-Status |
Beschreibung |
|---|---|
Idle |
Dies ist der erste Zustand einer Verbindung. BGP wartet auf ein Startereignis, das von einem Administrator initiiert wird. Das Startereignis kann die Einrichtung einer BGP-Sitzung durch Routerkonfiguration oder das Zurücksetzen einer vorhandenen Sitzung sein. Nach dem Startereignis initialisiert BGP seine Ressourcen, setzt einen Timer für die Verbindung zurück, initiiert eine TCP-Transportverbindung und fängt an, auf Verbindungen zu lauschen, die von Remote-Peers initiiert wurden. BGP wechselt dann in einen Connect Status. Wenn Fehler auftreten, fällt BGP auf den Idle Status zurück. |
Connect |
BGP wartet, bis die Transportprotokollverbindung abgeschlossen ist. Wenn die TCP-Transportverbindung erfolgreich ist, wechselt der Status zu OpenSent. Wenn die Transportverbindung nicht erfolgreich ist, wechselt der Status zu Active. Wenn der Timer zur Verbindungswiesholung abgelaufen ist, bleibt der Status im Connect Zustand, der Timer wird zurückgesetzt und eine Transportverbindung wird initiiert. Bei jedem anderen Ereignis geht der Status zurück zu Idle. |
Active |
BGP versucht, einen Peer zu erwerben, indem eine Transportprotokollverbindung initiiert wird. Wenn dies erfolgreich ist, wechselt der Status zu OpenSent. Wenn der Timer für die Verbindungswiesaufnahme abläuft, startet BGP den Verbindungs-Timer neu und fällt auf den Connect Status zurück. BGP lauscht weiterhin auf eine Verbindung, die von einem anderen Peer initiiert werden kann. Bei anderen Ereignissen, wie z. B. einem Stopp-Ereignis, kann der Status wieder Idle zurückgehen. Im Allgemeinen ist ein Flip-Flopping zwischen Connect und Active ein Hinweis darauf, dass ein Problem mit der TCP-Transportverbindung liegt. Ein solches Problem kann durch viele TCP-Weiterverbreitungen oder die Unfähigkeit eines Nachbarn verursacht werden, die IP-Adresse seines Peers zu erreichen. |
OpenSent |
BGP erhält eine offene Nachricht von seinem Peer. OpenSent Im Status vergleicht BGP seine Autonome Systemnummer (AS) mit der AS-Nummer seines Peers und erkennt, ob der Peer zum selben AS (internes BGP) oder zu einem anderen AS (externes BGP) gehört. Die offene Nachricht wird auf Korrektheit geprüft. Im Falle von Fehlern, z. B. einer fehlerhaften Versionsnummer eines inakzeptablen AS, sendet BGP eine Fehlermeldung und geht zurück an Idle. Bei anderen Fehlern, z. B. Ablauf des Hold-Timers oder eines Stopp-Ereignisses, sendet BGP eine Benachrichtigungsnachricht mit dem entsprechenden Fehlercode und fällt auf den Idle Status zurück. Wenn keine Fehler auftreten, sendet BGP Keepalive-Nachrichten und setzt den Keepalive Timer zurück. In diesem Zustand wird die Wartezeit ausgehandelt. Wenn die Haltezeit 0 ist, werden die Hold-and-Keepalive-Timer nicht neu gestartet. Wenn eine TCP-Transportverbindung erkannt wird, fällt der Status zurück auf Active. |
OpenConfirm |
BGP wartet auf eine Keepalive- oder Benachrichtigungsnachricht. Wenn ein Keepalive empfangen wird, wird Establishedder Status, und die Nachbarn-Aushandlung ist abgeschlossen. Wenn das System eine Aktualisierungs- oder Keepalive-Nachricht erhält, startet es den Hold-Timer neu (vorausgesetzt, die ausgehandelte Haltezeit ist nicht 0). Wenn eine Benachrichtigungsnachricht empfangen wird, fällt der Status zurück auf Idle. Das System sendet regelmäßig Keepalive-Meldungen in der geschwindigkeit, die vom Keepalive Timer festgelegt wurde. Im Falle einer Benachrichtigung zur Unterbrechung des Transports oder als Reaktion auf ein Stopp-Ereignis fällt der Status zurück auf Idle. Als Antwort auf andere Ereignisse sendet das System eine Benachrichtigungsnachricht mit einem FSM-Fehlercode (Finite State Machine) und geht zurück zu Idle. |
Established |
Dies ist der letzte Status in der Nachbarn-Aushandlung. In diesem Zustand aktualisiert BGP-Austausch ackets mit seinen Peers, und der Hold-Timer wird beim Erhalt eines Updates oder einer Keepalive-Nachricht neu gestartet, wenn er nicht auf Null festgelegt ist. Wenn das System eine Benachrichtigung erhält, fällt der Status zurück auf Idle. Aktualisierungsnachrichten werden auf Fehler geprüft, z. B. fehlende Attribute, doppelte Attribute usw. Wenn Fehler gefunden werden, wird eine Benachrichtigung an den Peer gesendet, und der Status fällt zurück auf Idle. BGP geht zurück zu Idle dem Zeitpunkt, an dem der Hold Timer abläuft, eine Disconnect-Benachrichtigung vom Transportprotokoll empfangen wird, ein Stop-Ereignis empfangen wird oder als Antwort auf ein anderes Ereignis. |
Um detailliertere BGP-Protokollpaketinformationen zu erhalten, konfigurieren Sie die BGP-spezifische Ablaufverfolgung. Weitere Informationen finden Sie in der Checkliste zur Nachverfolgung von Fehlerbedingungen .
Konfiguration BGP-spezifischer Optionen
Zweck
Wenn unerwartete Ereignisse oder Probleme auftreten oder wenn Sie Probleme mit der BGP-Einrichtung diagnostizieren möchten, können Sie detailliertere Informationen anzeigen, indem Sie BGP-spezifische Optionen konfigurieren. Sie können auch die Ablaufverfolgung für einen bestimmten BGP-Peer oder eine bestimmte Peer-Gruppe konfigurieren. Weitere Informationen finden Sie im Konfigurationshandbuch für junos Systemgrundsätze.
- Detaillierte BGP-Protokollinformationen anzeigen
- Diagnose von Problemen bei der Einrichtung von BGP-Sitzungen
Detaillierte BGP-Protokollinformationen anzeigen
Aktion
Führen Sie die folgenden Schritte aus, um BGP-Protokollinformationen im Detail anzuzeigen:
Wechseln Sie im Konfigurationsmodus zur folgenden Hierarchieebene:
[edit] user@host# edit protocol bgp traceoptions
Konfigurieren Sie das Flag, um detaillierte BGP-Protokollmeldungen anzuzeigen:
[edit protocols bgp traceoptions] user@host# set flag update detail
Konfiguration überprüfen:
user@host# show
Zum Beispiel:
[edit protocols bgp traceoptions] user@host# show flag update detail;
Konfiguration festlegen:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameZum Beispiel:
[edit protocols bgp traceoptions] user@pro5-a# run show log bgp Sep 17 14:47:16 trace_on: Tracing to "/var/log/bgp" started Sep 17 14:47:17 bgp_read_v4_update: receiving packet(s) from 10.255.245.53 (Internal AS 10458) Sep 17 14:47:17 BGP RECV 10.255.245.53+179 -> 10.255.245.50+1141 Sep 17 14:47:17 BGP RECV message type 2 (Update) length 128 Sep 17 14:47:17 BGP RECV flags 0x40 code Origin(1): IGP Sep 17 14:47:17 BGP RECV flags 0x40 code ASPath(2): 2 Sep 17 14:47:17 BGP RECV flags 0x80 code MultiExitDisc(4): 0 Sep 17 14:47:17 BGP RECV flags 0x40 code LocalPref(5): 100 Sep 17 14:47:17 BGP RECV flags 0xc0 code Extended Communities(16): 2:10458:1 [...Output truncated...]
Bedeutung
Tabelle 4 listet BGP-spezifische Ablaufverfolgungs-Flags auf und zeigt Eine Beispielausgabe für einige der Flags an. Sie können auch die Ablaufverfolgung für einen bestimmten BGP-Peer oder eine bestimmte Peer-Gruppe konfigurieren. Weitere Informationen finden Sie im Konfigurationshandbuch für junos Systemgrundsätze.
Tracing-Flags |
Beschreibung |
Beispiel-Ausgabe |
|---|---|---|
aspath |
Vorgänge im AS-Pfad mit regulären Ausdrücken |
Nicht verfügbar. |
damping |
Dämpfungsoperationen |
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-Keepalive-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 |
Offene 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 von Problemen bei der Einrichtung von BGP-Sitzungen
Zweck
Zur Verfolgung von Problemen bei der Einrichtung von BGP-Sitzungen.
Aktion
Führen Sie die folgenden Schritte aus, um Probleme bei der Einrichtung von BGP-Sitzungen nachzuverfolgen:
Wechseln Sie im Konfigurationsmodus zur folgenden Hierarchieebene:
[edit] user@host# edit protocol bgpKonfigurieren von offenen BGP-Nachrichten:
[edit protocols bgp] user@host# set traceoptions flag open detail
Konfiguration überprüfen:
user@host# show
Zum Beispiel:
[edit protocols bgp] user@host# show traceoptions { file bgplog size 10k files 10; flag open detail; }Konfiguration festlegen:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host#run show log filenameZum Beispiel:
[edit protocols bgp] user@hotst# run show log bgplog
Sep 17 17:13:14 trace_on: Tracing to "/var/log/bgplog" started Sep 17 17:13:14 bgp_read_v4_update: done with 201.0.0.2 (Internal AS 10458) received 19 octets 0 updates 0 routes Sep 17 17:13:15 bgp_read_v4_update: receiving packet(s) from 201.0.0.3 (Internal AS 10458) Sep 17 17:13:15 bgp_read_v4_update: done with 201.0.0.3 (Internal AS 10458) received 19 octets 0 updates 0 routes Sep 17 17:13:44 bgp_read_v4_update: receiving packet(s) from 201.0.0.2 (Internal AS 10458) [...Output truncated...]
Konfigurieren Sie IS-IS-spezifische Optionen
Zweck
Wenn unerwartete Ereignisse oder Probleme auftreten oder wenn Sie Probleme mit der IS-IS-Adjacency-Einrichtung diagnostizieren möchten, können Sie detailliertere Informationen anzeigen, indem Sie IS-IS-spezifische Optionen konfigurieren.
Gehen Sie folgendermaßen vor, um IS-IS-Optionen zu konfigurieren:
- Anzeigen detaillierter IS-IS-Protokollinformationen
- Anzeige von gesendeten oder empfangenen IS-IS-Protokollpaketen
- Detaillierte Analyse von IS-IS Link-State PDUs
Anzeigen detaillierter IS-IS-Protokollinformationen
Aktion
Führen Sie die folgenden Schritte aus, um IS-IS-Nachrichten im Detail zu verfolgen:
Konfigurieren Sie das Flag, um detaillierte IS-IS-Protokollmeldungen anzuzeigen.
[edit protocols isis traceoptions] user@host# set flag hello detail
Überprüfen Sie die Konfiguration.
user@host# show
Zum Beispiel:
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello detail;
Commit der Konfiguration.
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an.
user@host# run show log filenameZum Beispiel:
user@host# run show log isislog
Nov 29 23:17:50 trace_on: Tracing to "/var/log/isislog" started Nov 29 23:17:50 Sending PTP IIH on so-1/1/1.0 Nov 29 23:17:53 Sending PTP IIH on so-1/1/0.0 Nov 29 23:17:54 Received PTP IIH, source id abc-core-01 on so-1/1/0.0 Nov 29 23:17:54 from interface index 11 Nov 29 23:17:54 max area 0, circuit type l2, packet length 4469 Nov 29 23:17:54 hold time 30, circuit id 6 Nov 29 23:17:54 neighbor state up Nov 29 23:17:54 speaks IP Nov 29 23:17:54 area address 99.0008 (1) Nov 29 23:17:54 IP address 10.10.10.29 Nov 29 23:17:54 4396 bytes of total padding Nov 29 23:17:54 updating neighbor abc-core-01 Nov 29 23:17:55 Received PTP IIH, source id abc-core-02 on so-1/1/1.0 Nov 29 23:17:55 from interface index 12 Nov 29 23:17:55 max area 0, circuit type l2, packet length 4469 Nov 29 23:17:55 hold time 30, circuit id 6 Nov 29 23:17:55 neighbor state up Nov 29 23:17:55 speaks IP Nov 29 23:17:55 area address 99.0000 (1) Nov 29 23:17:55 IP address 10.10.10.33 Nov 29 23:17:55 4396 bytes of total padding Nov 29 23:17:55 updating neighbor abc-core-02
Bedeutung
Tabelle 5 listet Ablaufverfolgungs-Flags auf, die spezifisch für IS-IS konfiguriert werden können, und zeigt eine Beispielausgabe für einige der Flags an.
Tracing-Flags |
Beschreibung |
Beispiel-Ausgabe |
|---|---|---|
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 der 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 |
PsNP-Pakete (Partial Sequence Number PDU) |
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 |
Shortest Path-First (SPF)-Berechnungen |
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 |
Siehe auch
Anzeige von gesendeten oder empfangenen IS-IS-Protokollpaketen
Gehen Sie folgendermaßen vor, um die Ablaufverfolgung nur für gesendete oder empfangene IS-IS-Protokollpakete zu konfigurieren:
Konfigurieren Sie das Flag, um gesendete, empfangene oder beide gesendete und empfangene Pakete anzuzeigen.
[edit protocols isis traceoptions] user@host# set flag hello send
oder
[edit protocols isis traceoptions] user@host# set flag hello receive
oder
[edit protocols isis traceoptions] user@host# set flag hello
Überprüfen Sie die Konfiguration.
user@host# show
Zum Beispiel:
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send;
oder
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello receive;
oder
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send receive;
Commit der Konfiguration.
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an.
user@host# run show log filenameZum Beispiel:
user@host# run show log isislog Sep 27 18:17:01 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:01 ISIS periodic xmit to 01:80:c2:00:00:14 (IFL 2) Sep 27 18:17:03 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:04 ISIS periodic xmit to 01:80:c2:00:00:14 (IFL 2) Sep 27 18:17:06 ISIS L2 hello from 0000.0000.0008 (IFL 2) absorbed Sep 27 18:17:06 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:06 ISIS L1 hello from 0000.0000.0008 (IFL 2) absorbed
Siehe auch
Detaillierte Analyse von IS-IS Link-State PDUs
Führen Sie die folgenden Schritte aus, um IS-IS Link-State-PDUs im Detail zu analysieren:
Konfigurieren Sie offene IS-IS-Nachrichten.
[edit protocols isis traceoptions] user@host# set flag lsp detail
Überprüfen Sie die Konfiguration.
user@host# show
Zum Beispiel:
[edit protocols isis traceoptions] user@host# show file isislog size 5m world-readable; flag error; flag lsp detail;
Commit der Konfiguration.
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an.
user@host# run show log filenameZum Beispiel:
user@host# run show log isislog Nov 28 20:17:24 Received L2 LSP abc-core-01.00-00, interface so-1/1/0.0 Nov 28 20:17:24 from abc-core-01 Nov 28 20:17:24 sequence 0x1c4f9, checksum 0x9fea, lifetime 1199 Nov 28 20:17:24 max area 0, length 426 Nov 28 20:17:24 no partition repair, no database overload Nov 28 20:17:24 IS type 3, metric type 0 Nov 28 20:17:24 area address 99.0908 (1) Nov 28 20:17:24 speaks CLNP Nov 28 20:17:24 speaks IP Nov 28 20:17:24 dyn hostname abc-core-01 Nov 28 20:17:24 IP address 10.10.134.11 Nov 28 20:17:24 IP prefix: 10.10.10.0/30 metric 1 up Nov 28 20:17:24 IP prefix: 10.10.10.4/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.56/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.52/30 metric 1 up Nov 28 20:17:24 IP prefix: 10.10.10.64/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.20/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.28/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.44/30 metric 5 up Nov 28 20:17:24 IP prefix 10.10.10.0 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 1 Nov 28 20:17:24 IP prefix 10.10.10.4 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.56 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.52 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 1 Nov 28 20:17:24 IP prefix 10.10.10.64 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.20 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.28 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.44 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbors: Nov 28 20:17:24 IS neighbor abc-core-02.00 Nov 28 20:17:24 internal, metrics: default 1 [...Output truncated...] Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbor abc-brdr-01.00 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbor abc-core-02.00, metric: 1 Nov 28 20:17:24 IS neighbor abc-esr-02.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-03.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-01.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-02.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-brdr-01.00, metric: 5 Nov 28 20:17:24 IP prefix: 10.10.134.11/32 metric 0 up Nov 28 20:17:24 IP prefix: 10.11.0.0/16 metric 5 up Nov 28 20:17:24 IP prefix: 10.211.0.0/16 metric 0 up Nov 28 20:17:24 IP prefix 10.10.134.11 255.255.255.255 Nov 28 20:17:24 internal, metrics: default 0 Nov 28 20:17:24 IP prefix 10.11.0.0 255.255.0.0 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.211.0.0 255.255.0.0 Nov 28 20:17:24 internal, metrics: default 0 Nov 28 20:17:24 Updating LSP Nov 28 20:17:24 Updating L2 LSP abc-core-01.00-00 in TED Nov 28 20:17:24 Analyzing subtlv's for abc-core-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-esr-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-03.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-01.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-brdr-01.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Scheduling L2 LSP abc-core-01.00-00 sequence 0x1c4f9 on interface so-1/1/1.0
Siehe auch
Konfiguration OSPF-spezifischer Optionen
Zweck
Wenn unerwartete Ereignisse oder Probleme auftreten oder wenn Sie Probleme mit der OSPF-Nachbarneinrichtung diagnostizieren möchten, können Sie detailliertere Informationen anzeigen, indem Sie OSPF-spezifische Optionen konfigurieren.
Gehen Sie folgendermaßen vor, um OSPF-Optionen zu konfigurieren:
- Diagnose von OSPF-Sitzungseinrichtungsproblemen
- Analysieren Sie OSPF Link-State Advertisement Packets im Detail
Diagnose von OSPF-Sitzungseinrichtungsproblemen
Aktion
Führen Sie die folgenden Schritte aus, um OSPF-Nachrichten im Detail zu verfolgen:
Wechseln Sie im Konfigurationsmodus zur folgenden Hierarchieebene:
[edit] user@host# edit protocols ospf traceoptions
Konfigurieren Sie OSPF Hallo Nachrichten:
[edit protocols ospf traceoptions] user@host# set flag hello detail
Konfiguration überprüfen:
user@host# show
Zum Beispiel:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail;
Konfiguration festlegen:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameZum Beispiel:
user@host# run show log ospf
Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0 Dec 2 16:14:24 checksum 0xf01a, authtype 0 Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:24 OSPF sent Hello (1) -> 224.0.0.5 (so-1/1/2.0) Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0 Dec 2 16:14:24 checksum 0xf01a, authtype 0 Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:26 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:14:26 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:14:26 checksum 0x99b8, authtype 0Dec 2 16:14:26 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 ec 2 16:14:26 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:29 OSPF rcvd Hello 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:14:29 Version 2, length 48, ID 10.108.134.11, area 0.0.0.0 Dec 2 16:14:29 checksum 0x99b9, authtype 0Dec 2 16:14:29 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 16:14:29 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Bedeutung
Tabelle 6 listet OSPF-Ablaufverfolgungsflaggen auf und zeigt Eine Beispielausgabe für einige der Flags an.
Tracing-Flags |
Beschreibung |
Beispiel-Ausgabe |
|---|---|---|
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-Fehlerpakete |
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-Statusübergänge |
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 |
Link-State-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.1010.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 15:57:28 Version 2, length 48, ID .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 |
Pakete zur Bestätigung des Verbindungsstatus |
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 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 |
Dumpen der Inhalte ausgewählter Pakettypen |
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.10.10134.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 .134.12 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0 |
Analysieren Sie OSPF Link-State Advertisement Packets im Detail
Aktion
Führen Sie die folgenden Schritte aus, um OSPF-Verbindungsstatus-Ankündigungspakete im Detail zu analysieren:
Wechseln Sie im Konfigurationsmodus zur folgenden Hierarchieebene:
[edit] user@host# edit protocols ospf traceoptions
Konfigurieren von OSPF-Linkstatuspaketen:
[edit protocols ospf traceoptions] user@host# set flag lsa-update detail
Konfiguration überprüfen:
user@host# show
Zum Beispiel:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail; flag lsa-update detail;
Konfiguration festlegen:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameZum Beispiel:
user@host# run show log ospf
Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) ec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:23:47 checksum 0xcc46, authtype 0 Dec 2 16:23:47 adv count 6 Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:23:47 checksum 0xcc46, authtype 0 Dec 2 16:23:47 adv count 6