Fehlerbehebung bei BGP-Sitzungen
Checkliste für die Verifizierung des BGP-Protokolls und der Peers
Zweck
Tabelle 1 stellt Links und Befehle bereit, mit denen Sie überprüfen können, ob das Border Gateway Protocol (BGP) auf einem Router von Juniper Networks in Ihrem Netzwerk korrekt konfiguriert ist, ob die Sitzungen des internen Border Gateway Protocol (IBGP) und des externen Border Gateway Protocol (EBGP) ordnungsgemäß eingerichtet sind, ob die externen Routen korrekt angekündigt und empfangen wurden und ob der BGP-Pfadauswahlprozess ordnungsgemäß funktioniert.
Was
Aufgaben |
Befehl oder Aktion |
|---|---|
| BGP-Peers verifizieren | |
|
|
|
|
|
|
|
|
| Untersuchen von BGP-Routen und Routenauswahl | |
|
|
|
|
|
|
|
|
| Untersuchen von Routen in der Weiterleitungstabelle |
|
BGP-Peers verifizieren
Zweck
Unter der Annahme, dass alle Router korrekt für BGP konfiguriert sind, können Sie überprüfen, ob IBGP- und EBGP-Sitzungen ordnungsgemäß eingerichtet sind, externe Routen korrekt angekündigt und empfangen werden und ob 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 () über IBGP verbunden.lo0 AS 65001 läuft mit OSPF und AS 65002 mit IS-IS als zugrunde liegendem IGP. IBGP-Router müssen nicht direkt verbunden sein, die zugrunde liegende IGP ermöglicht es den Nachbarn, sich gegenseitig zu erreichen.
Die beiden Router im AS 65001 enthalten jeweils einen EBGP-Link zum AS 65002 ( und ), über den sie aggregierte Präfixe ankündigen:R2R4 ,,, und.100.100.1.0 100.100.2.0 100.100.3.0 100.100.4.0 Außerdem injizieren und für einige Routen mehrere MED-Werte (Exit Discriminator) von 5 bzw. 10.R1R5
Die internen Router in beiden ASs verwenden eine Full-Mesh-IBGP-Topologie. Ein vollständiges Mesh ist erforderlich, da die Netzwerke keine Konföderationen oder Routenreflektoren verwenden, sodass über IBGP erlernte Routen nicht an andere interne Nachbarn verteilt werden. Wenn z. B. eine Route von gelernt wird, wird diese Route nicht an verteilt, da die Route über IBGP gelernt wird und daher eine direkte BGP-Verbindung zum Erlernen der Route erforderlich ist.R3R2R3R6R6R2
In einer Full-Mesh-Topologie verteilt nur der Border-Router, 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 seinem eigenen AS.
Aus Sicht der AS 65002 sollten die folgenden Sitzungen anstehen:
Die vier Router in AS 65002 sollten IBGP-Sitzungen miteinander aufgebaut haben.
sollte eine EBGP-Sitzung mit eingerichtet haben.
R2R1sollte eine EBGP-Sitzung mit eingerichtet haben.
R4R5
Gehen Sie folgendermaßen vor, um BGP-Peers zu verifizieren:
- Überprüfen des BGP auf einem internen Router
- BGP auf einem Border-Router verifizieren
- Überprüfen der angekündigten BGP-Routen
- Stellen Sie sicher, dass eine bestimmte BGP-Route auf Ihrem Router empfangen wird
Überprüfen des BGP auf einem internen Router
Zweck
So überprüfen Sie die BGP-Konfiguration eines internen Routers.
Was
Um die BGP-Konfiguration eines internen Routers zu überprüfen, geben Sie den folgenden CLI-Befehl (Junos OS-Befehlszeilenschnittstelle) ein:
user@host> show configuration
Die folgende Beispielausgabe bezieht sich auf 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 und .R3R6 Auf beiden Routern sind der lokale AS (65002) und eine Gruppe () konfiguriert. verfügt über drei interne Peers—, , und —die auf der Hierarchieebene [] enthalten sind. Verfügt außerdem über drei interne Peers:internalR310.0.0.210.0.0.410.0.0.6protocols bgp group groupR6 , und .10.0.0.210.0.0.310.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 Probleme mit doppelten Router-IDs zu vermeiden.
BGP auf einem Border-Router verifizieren
Zweck
So überprüfen Sie die BGP-Konfiguration eines Border-Routers.
Was
Um die BGP-Konfiguration eines Border-Routers zu überprüfen, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:
user@host> show configuration
Beispielausgabe
Befehlsname
Die folgende Beispielausgabe bezieht sich auf eine BGP-Konfiguration auf zwei Border-Routern, R2 und R4 aus 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 Border-Routern und .R2R4 Bei beiden Routern ist der AS (65002) auf der Hierarchieebene [] enthalten.routing-options Jeder Router verfügt über zwei Gruppen, die auf der Hierarchieebene [] enthalten sind.protocols bgp groupgroup Externe Peers sind in der externen Gruppe enthalten, je nach Router entweder toR1 oder .toR5 Interne Peers werden in dieGruppe aufgenommen. internal Das zugrunde liegende IGP-Protokoll ist IS-IS auf beiden Routern, und die relevanten 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 doppelten Router-IDs zu vermeiden, und die Anweisung enthalten ist, um Probleme mit der BGP-Erreichbarkeit des nächsten Hops zu vermeiden.next-hop-self
Überprüfen der angekündigten BGP-Routen
Zweck
Sie können feststellen, ob eine bestimmte Route, die Sie konfiguriert haben, einem Nachbarn angekündigt wird.
Was
Geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein, um zu überprüfen, wie sie für die Ankündigung an 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 von zu seinem Nachbarn ().R210.0.0.4R4 Von insgesamt 22 Routen in der Routing-Tabelle sind 20 aktive Ziele.inet.0 Es befinden sich keine Routen oder im Staat.hiddenhold-down Routen befinden sich in dem Zustand, bevor sie als aktiv deklariert wurden, und Routen, die von einer Routingrichtlinie abgelehnt wurden, können in diesen Zustand versetzt werden.hold-downhidden Die angezeigten Informationen spiegeln die Routen wider, die die Routing-Tabelle in das BGP-Routing-Protokoll exportiert hat.
Stellen Sie sicher, dass eine bestimmte BGP-Route auf Ihrem Router empfangen wird
Zweck
Zeigen Sie die Routing-Informationen an, wie sie von einem bestimmten BGP-Nachbarn empfangen und vom lokalen Router dem Nachbarn angekündigt werden.
Was
Um zu überprüfen, ob eine bestimmte BGP-Route auf Ihrem Router empfangen wird, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:
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 und zwei von .R2 R4 Von den vier Routen von sind nur zwei in der Routing-Tabelle aktiv, wie durch das Sternchen () gekennzeichnet, während beide Routen, die von empfangen wurden, in der Routing-Tabelle aktiv sind.R2*R4 Alle BGP-Routen liefen über AS 65001.
Untersuchen von BGP-Routen und Routenauswahl
Zweck
Sie können den BGP-Pfadauswahlprozess untersuchen, um den einzelnen, aktiven Pfad zu bestimmen, wenn BGP mehrere Routen zum gleichen Zielpräfix empfängt.
Das Netzwerk in Abbildung 2 zeigt das an und kündigt die gleichen aggregierten Routen an und an, was zu zwei Routen zum gleichen Zielpräfix führt und diese empfängt.R1R5R2R4,R2R4 Der Routenauswahlprozess läuft und bestimmt, welche der beiden empfangenen BGP-Routen aktiv ist und den anderen internen Routern ( und ) angekündigt wird.R2R4 R3R6
Bevor der Router eine BGP-Route installiert, muss er sicherstellen, dass das BGP-Attribut erreichbar ist.next-hop Wenn der nächste BGP-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 zum gleichen Zielpräfix vorhanden sind. Der BGP-Pfadauswahlprozess wird in der folgenden Reihenfolge fortgesetzt:
Die Routenpräferenz in der Routing-Tabelle 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 die Standardeinstellung 110 hat, während die BGP-Route die Standardeinstellung 170 hat.
Routen werden für lokale Präferenzen verglichen. Bevorzugt wird die Route mit der höchsten lokalen Präferenz. Siehe z. B. Untersuchen der Auswahl der lokalen Einstellungen.Fehlerbehebung bei BGP-Sitzungen
Das AS-Pfadattribut 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 aus demselben benachbarten AS angekündigt wird, wird standardmäßig der niedrigste MED-Wert bevorzugt. Das Fehlen eines MED-Werts wird als MED von 0 interpretiert. Ein Beispiel finden Sie unter Untersuchen der Routenauswahl für Mehrfachausgangsdiskriminatoren.Beispiel: Konfigurieren des MED-Attributs, das den Ausstiegspunkt in einem AS bestimmt
Die Route wird dahingehend bewertet, ob sie durch EBGP oder IBGP gelernt wird. EBGP-erlernte Routen werden IBGP-erlernten Routen vorgezogen. Ein Beispiel finden Sie unter Untersuchen der EBGP-über-IBGP-AuswahlFehlerbehebung bei BGP-Sitzungen
Wenn die Route von IBGP gelernt wird, wird die Route mit den niedrigsten IGP-Kosten bevorzugt. Ein Beispiel finden Sie unter Untersuchen der IGP-Kostenauswahl.Fehlerbehebung bei BGP-Sitzungen Der physische nächste Hop zum IBGP-Peer wird gemäß den folgenden drei Regeln installiert:
Nachdem BGP die Routing-Tabellen und untersucht hat, wird der physische nächste Hop der Route mit der niedrigsten Präferenz verwendet.
inet.0inet.3
Wenn die Voreinstellungswerte in der Routing-Tabelle und in der Routing-Tabelle ungleich sind, wird der physische nächste Hop der Route in der Routing-Tabelle verwendet.
inet.0inet.3inet.3
Wenn in derselben Routing-Tabelle eine Präferenzverknüpfung vorhanden ist, wird der physische nächste Hop der Route mit weiteren Pfaden installiert.
Das Clusterlistenattribut für die Routenreflexion wird ausgewertet. Die Clusterliste mit der kürzesten Länge wird bevorzugt. Bei Routen ohne Clusterliste wird davon ausgegangen, dass sie eine Clusterlistenlänge von 0 haben.
Die Router-ID wird ausgewertet. Die Route vom Peer mit der niedrigsten Router-ID wird bevorzugt (in der Regel die Loopback-Adresse).
Der Wert der Peer-Adresse wird untersucht. Der Peer mit der niedrigsten Peer-IP-Adresse wird bevorzugt.
Geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein, um den einzelnen, aktiven Pfad zu bestimmen, wenn BGP mehrere Routen zum gleichen 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 zum gleichen Zielpräfix empfängt und eine Route als einzelner, aktiver Pfad ausgewählt ist:
- Untersuchen der lokalen Präferenzauswahl
- Untersuchen der Routenauswahl für Mehrfachausgangsdiskriminator
- Untersuchen Sie die EBGP-Auswahl über IBGP
- Untersuchen Sie die IGP-Kostenauswahl
Untersuchen der lokalen Präferenzauswahl
Zweck
Untersuchen einer Route, um zu bestimmen, ob die lokale Präferenz das Auswahlkriterium für den einzelnen, aktiven Pfad ist.
Was
Um eine Route zu untersuchen und zu bestimmen, ob die lokale Präferenz das Auswahlkriterium für den einzelnen, aktiven Pfad ist, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:
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 zwei Instanzen der Route empfangen wurden:R4100.100.1.0 eine von () und eine von (). Wählen Sie den Pfad von als aktiven Pfad aus, wie durch das Sternchen (*) gekennzeichnet.10.0.0.2R210.1.45.2R5R4R2 Die Auswahl basiert auf dem lokalen Präferenzwert, der im Feld enthalten ist.Localpref Der Pfad mit der höchsten lokalen Präferenz wird bevorzugt. Im Beispiel ist der Pfad mit dem höheren lokalen Präferenzwert der Pfad von , 200.R2
Der Grund dafür, dass die Route von nicht ausgewählt ist, liegt im Feld, in diesem Fall .R5Inactive reasonLocal Preference
Beachten Sie, dass die beiden Pfade aus demselben benachbarten Netzwerk stammen: AS 65001.
Untersuchen der Routenauswahl für Mehrfachausgangsdiskriminator
Zweck
Untersuchen einer Route, um zu bestimmen, ob die MED das Auswahlkriterium für den einzelnen, aktiven Pfad ist.
Was
Um eine Route zu untersuchen und zu bestimmen, ob MED das Auswahlkriterium für den einzelnen, aktiven Pfad ist, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:
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 zwei Instanzen der Route empfangen wurden:R4100.100.2.0 eine von () und eine von (). Wählen Sie den Pfad von als aktive Route aus, wie durch das Sternchen (*) gekennzeichnet.10.0.0.2R210.1.45.2R5R4R2 Die Auswahl basiert auf dem im Feld enthaltenen MED-Wert.Metric: Der Pfad mit dem niedrigsten MED-Wert wird bevorzugt. Im 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, warum der inaktive Pfad nicht ausgewählt ist, wird im Feld angezeigt, in diesem Fall .Inactive reason:Not Best in its group Die Formulierung wird verwendet, weil das Junos-Betriebssystem standardmäßig den Prozess der deterministischen MED-Auswahl verwendet.
Untersuchen Sie die EBGP-Auswahl über IBGP
Zweck
Untersuchen einer Route, um zu bestimmen, ob EBGP anstelle von IBGP als Auswahlkriterium für den einzelnen, aktiven Pfad ausgewählt ist.
Was
Geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein, um zu ermitteln, ob EBGP anstelle von IBGP als Auswahlkriterium für den einzelnen, aktiven Pfad ausgewählt ist:
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 zwei Instanzen der Route empfangen wurden:R4100.100.3.0 eine von () und eine von (). Wählen Sie den Pfad von als aktiven Pfad aus, wie durch das Sternchen (*) gekennzeichnet.10.1.45.2R510.0.0.2R2R4R5 Die Auswahl basiert auf einer Präferenz für Routen, die von einem EBGP-Peer gelernt wurden, gegenüber Routen, die von einem IBGP gelernt wurden. ist ein EBGP-Peer.R5
Sie können feststellen, ob ein Pfad von einem EBGP- oder IBGP-Peer empfangen wird, indem Sie die Felder und untersuchen.Local As Peer As Beispiel: Die Route von zeigt an, dass der lokale AS 65002 und der Peer-AS 65001 ist, was darauf hinweist, dass die Route von einem EBGP-Peer empfangen wird.R5 Die Route von zeigt, dass sowohl der lokale als auch der Peer-AS 65002 ist, was darauf hinweist, dass er von einem IBGP-Peer empfangen wird.R2
Der Grund, warum der inaktive Pfad nicht ausgewählt ist, wird im Feld angezeigt, in diesem Fall .Inactive reasonInterior > 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 von einer rein internen Quelle (IGP) empfangene Route wird zuerst bevorzugt, die von einer externen Quelle (EBGP) empfangene Route 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 aktiven Pfad ausgewählt.
Untersuchen Sie die IGP-Kostenauswahl
Zweck
Untersuchen einer Route, um zu bestimmen, ob EBGP anstelle von IBGP als Auswahlkriterium für den einzelnen, aktiven Pfad ausgewählt ist.
Was
Geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein, um zu ermitteln, ob EBGP anstelle von IBGP als Auswahlkriterium für den einzelnen, aktiven Pfad ausgewählt ist:
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 zwei Instanzen der Route empfangen wurden:R6 100.100.4.0 eine von () und eine von (). Wählen Sie den Pfad von als aktive Route aus, wie durch das Sternchen (*) gekennzeichnet.10.0.0.4R410.0.0.2 R2R6R4 Die Auswahl basiert auf der IGP-Metrik, die im Feld angezeigt wird.Metric2 Die Route mit der niedrigsten IGP-Metrik wird bevorzugt. Im Beispiel ist der Pfad mit dem niedrigsten IGP-Metrikwert der Pfad von , mit einem IGP-Metrikwert von 10, während der Pfad von eine IGP-Metrik von 20 hat.R4R2 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 Feld angezeigt, in diesem Fall .Inactive reasonIGP metric
Checkliste zur Überprüfung der BGP-Schicht
Problem
Beschreibung
Diese Prüfliste enthält die Schritte und Befehle zum Überprüfen der BGP-Konfiguration des MPLS-Netzwerks (Multiprotocol Label Switching). Die Checkliste enthält Links zu einer Übersicht über die BGP-Konfiguration und detailliertere Informationen zu den Befehlen, die zur BGP-Konfiguration verwendet werden. (Siehe Tabelle 2.)
Lösung
Aufgaben |
Befehl oder Aktion |
|---|---|
| Überprüfen der BGP-Schicht | |
|
|
|
|
|
|
|
|
|
|
Die folgende Befehlsfolge behebt das in diesem Thema beschriebene Problem:
|
|
|
Überprüfen der BGP-Schicht
Zweck
Nachdem Sie den Label-Switched-Pfad (LSP) konfiguriert und festgestellt haben, dass er aktiv ist, und BGP konfiguriert und festgestellt haben, dass Sitzungen eingerichtet werden, stellen Sie sicher, dass BGP den LSP zum Weiterleiten des Datenverkehrs verwendet.
Abbildung 3 veranschaulicht die BGP-Schicht des MPLS-Mehrschichtmodells.
Wenn Sie die BGP-Schicht überprüfen, stellen Sie sicher, dass die Route vorhanden und aktiv ist, und, was noch wichtiger ist, Sie stellen sicher, dass der nächste Hop der LSP ist. Es macht keinen Sinn, die BGP-Schicht zu überprüfen, wenn der LSP nicht eingerichtet ist, da BGP den MPLS-LSP zum Weiterleiten des Datenverkehrs verwendet. Wenn das Netzwerk auf der BGP-Ebene nicht funktioniert, funktioniert der LSP nicht wie konfiguriert.
Abbildung 4 veranschaulicht das in diesem Thema verwendete MPLS-Netzwerk.
Bei dem gezeigten Netzwerk handelt es sich um eine vollständig vermaschte Konfiguration, bei der jede direkt verbundene Schnittstelle Pakete empfangen und an jede andere ähnliche Schnittstelle senden kann.Abbildung 4 Der LSP in diesem Netzwerk ist so konfiguriert, dass er vom Eingangsrouter über den Transitrouter zum Ausgangsrouter ausgeführt wird.R1R3R6 Darüber hinaus ist ein Reverse-LSP so konfiguriert, dass er von bis bis ausgeführt wird, wodurch bidirektionaler Datenverkehr erzeugt wird.R6R3R1
Das in gezeigte Kreuz gibt an, wo BGP nicht zum Weiterleiten des Datenverkehrs über den LSP verwendet wird.Abbildung 4 Mögliche Gründe dafür, dass der LSP nicht ordnungsgemäß funktioniert, sind, dass die Ziel-IP-Adresse des LSP nicht mit dem nächsten BGP-Hop übereinstimmt oder dass BGP nicht ordnungsgemäß konfiguriert ist.
Gehen Sie folgendermaßen vor, um die BGP-Schicht zu überprüfen:
- Überprüfen Sie, ob der BGP-Datenverkehr den LSP verwendet
- Überprüfen von BGP-Sitzungen
- Überprüfen der BGP-Konfiguration
- Untersuchen von BGP-Routen
- Überprüfen der empfangenen BGP-Routen
- Ergreifen geeigneter Maßnahmen zur Lösung des Netzwerkproblems
- Überprüfen Sie, ob der BGP-Datenverkehr den LSP erneut verwendet.
Überprüfen Sie, ob der BGP-Datenverkehr den LSP verwendet
Zweck
Auf dieser Ebene des Fehlerbehebungsmodells sind BGP und LSP möglicherweise aktiv, der BGP-Datenverkehr verwendet den LSP jedoch möglicherweise nicht zum Weiterleiten des Datenverkehrs.
Was
Um zu überprüfen, ob der BGP-Datenverkehr den LSP verwendet, geben Sie den folgenden Befehl für den Betriebsmodus der Junos OS-Befehlszeilenschnittstelle (CLI) 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 der BGP-Datenverkehr nicht den LSP verwendet, sodass MPLS-Bezeichnungen nicht in der Ausgabe angezeigt werden. Anstatt den LSP zu verwenden, verwendet der BGP-Datenverkehr das Interior Gateway Protocol (IGP), um die BGP-Ausgangsadresse für den nächsten Hop des LSP für und zu erreichen.R6R1 Junos OS verwendet standardmäßig LSPs für BGP-Datenverkehr, wenn der nächste BGP-Hop der LSP-Ausgangsadresse entspricht.
Überprüfen von BGP-Sitzungen
Zweck
Zeigen Sie zusammenfassende Informationen über BGP und seine Nachbarn an, um festzustellen, ob Routen von Peers im autonomen System (AS) empfangen werden. Wenn eine BGP-Sitzung eingerichtet wird, tauschen die Peers Aktualisierungsnachrichten aus.
Was
Um zu überprüfen, ob BGP-Sitzungen verfügbar sind, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl 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
Beispielausgabe 1 zeigt, dass ein Peer (Ausgangsrouter ) nicht eingerichtet ist, wie durch das Feld angegeben.10.0.0.6Down Peers: 1 Die letzte Spalte () zeigt an, dass der Peer aktiv ist, was darauf hinweist, dass er nicht eingerichtet ist.State|#Active/Received/Damped10.0.0.6 Alle anderen Peers werden entsprechend der Anzahl der aktiven, empfangenen und gedämpften Routen eingerichtet. for peer gibt beispielsweise an, dass keine BGP-Routen in der Routing-Tabelle aktiv waren oder empfangen wurden und keine BGP-Routen gedämpft wurden. for peer gibt an, dass eine BGP-Route aktiv war und in der Routing-Tabelle empfangen wurde und keine BGP-Routen gedämpft wurden.0/0/010.0.0.21/1/0 10.1.36.2
Wenn die Ausgabe des Befehls eines Eingangsrouters anzeigt, dass ein Nachbar ausgefallen ist, überprüfen Sie die BGP-Konfiguration.show bgp summary Weitere Informationen zum Überprüfen der BGP-Konfiguration finden Sie unter Überprüfen der BGP-Konfiguration.Fehlerbehebung bei BGP-Sitzungen
Beispielausgabe 2 zeigt die Ausgabe des Eingangsrouters nach dem Einschalten der BGP-Konfigurationen, die unter Ergreifen geeigneter Maßnahmen zur Lösung des Netzwerkproblems korrigiert wurden.R1R1R6Fehlerbehebung bei Netzwerkproblemen Alle BGP-Peers sind eingerichtet und eine Route ist aktiv und wird empfangen. Es wurden keine BGP-Routen gedämpft.
Wenn die Ausgabe des Befehls anzeigt, dass ein Nachbar aktiv ist, aber keine Pakete weitergeleitet werden, suchen Sie nach empfangenen Routen vom Ausgangsrouter.show bgp summary Informationen zum Überprüfen des Ausgangsrouters auf empfangene Routen finden Sie unter Überprüfen empfangener BGP-Routen.Fehlerbehebung bei BGP-Sitzungen
Ü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 angeben (IP-Adresse und AS-Nummer des Peers). Wenn BGP Teil eines MPLS-Netzwerks ist, müssen Sie sicherstellen, dass der LSP mit einer Ziel-IP-Adresse konfiguriert ist, die dem nächsten BGP-Hop entspricht, damit BGP-Routen mit dem LSP als nächstem Hop für diese Routen installiert werden können.
Was
Um die BGP-Konfiguration zu überprüfen, geben Sie den folgenden Junos OS CLI-Befehl für den Betriebsmodus 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 dem Eingangsrouter und dem Ausgangsrouter .R1R6 Beide Konfigurationen zeigen den lokalen AS (), eine Gruppe () und sechs konfigurierte Peers an.65432internal Das zugrunde liegende interne Gateway-Protokoll ist IS-IS, und die relevanten Schnittstellen sind für die Ausführung von IS-IS konfiguriert.
In dieser Konfiguration wird die RID manuell konfiguriert, um doppelte RID-Probleme zu vermeiden, und alle mit BGP konfigurierten Schnittstellen enthalten die Anweisung auf der Hierarchieebene [ ].family inetedit interfaces type-fpc/pic/port unitlogical-unit-number
Die Beispielausgabe für den Eingangsrouter und den Ausgangsrouter zeigt, dass in der BGP-Protokollkonfiguration die Anweisung für die interne Gruppe fehlt.R1R6 local-address Wenn die Anweisung konfiguriert ist, werden BGP-Pakete von der Loopback-Schnittstellenadresse () des lokalen Routers weitergeleitet, d. h. von der Adresse, an die BGP-Peers Peering betreiben.local-addresslo0 Wenn die Anweisung nicht konfiguriert ist, werden BGP-Pakete von der ausgehenden Schnittstellenadresse weitergeleitet, die nicht mit der Adresse übereinstimmt, an die BGP-Peers Peering betreiben, und BGP wird nicht aktiviert.local-address
Auf dem Eingangsrouter sollte die IP-Adresse () in der Anweisung mit der Adresse übereinstimmen, die für den LSP auf dem Ausgangsrouter () in der Anweisung auf der Hierarchieebene [] konfiguriert ist.10.0.0.1local-addressR6to edit protocols mpls label-switched-pathlsp-path-name BGP verwendet diese Adresse, die mit der LSP-Adresse identisch ist, um BGP-Datenverkehr über den LSP weiterzuleiten.
Darüber hinaus enthält die BGP-Konfiguration zwei IP-Adressen für , eine Schnittstellenadresse () und eine Loopback-Schnittstellenadresse () ), was dazu führt, dass die LSP-Zieladresse () nicht mit der BGP-Next-Hop-Adresse () übereinstimmt.R1R610.1.36.2lo010.0.0.610.0.0.610.1.36.2 Die BGP-Konfiguration enthält auch zwei IP-Adressen für , eine Schnittstellenadresse () und eine Loopback-Schnittstellenadresse (), was dazu führt, dass die umgekehrte LSP-Zieladresse () nicht mit der BGP-Next-Hop-Adresse () übereinstimmt.R6R110.1.13.1lo010.0.0.110.1.13.1
Da in diesem Fall die 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 zum Weiterleiten des Datenverkehrs.local-address
Untersuchen von BGP-Routen
Zweck
Sie können den BGP-Pfadauswahlprozess untersuchen, um den einzelnen, aktiven Pfad zu bestimmen, wenn BGP mehrere Routen zum selben Ziel empfängt. In diesem Schritt untersuchen wir den umgekehrten LSP und erstellen den Eingangsrouter für diesen LSP.R6-to-R1R6
Was
Um BGP-Routen und Routenauswahl zu untersuchen, geben Sie den folgenden Junos OS CLI-Befehl für den Betriebsmodus 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
Beispielausgabe 1 zeigt, dass der nächste BGP-Hop () nicht mit der LSP-Zieladresse () in der Anweisung auf derHierarchieebene [] übereinstimmt, wenn die BGP-Konfiguration von und falsch ist.10.1.13.110.0.0.1 to edit protocols mpls label-switched-path label-switched-path-nameR6 R1
Beispielausgabe 2, die nach der Korrektur der Konfigurationen auf R1 und R6 erstellt wurde, zeigt, dass der nächste BGP-Hop () und die LSP-Zieladresse () identisch sind, was darauf hinweist, dass BGP den LSP zum Weiterleiten von BGP-Datenverkehr verwenden kann.10.0.0.110.0.0.1
Überprüfen der empfangenen BGP-Routen
Zweck
Zeigen Sie die Routing-Informationen an, die auf dem Router , dem Eingangsrouter für den Reverse-LSP .R6R6-to-R1
Was
Um zu überprüfen, ob eine bestimmte BGP-Route auf dem Ausgangsrouter empfangen wird, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:
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
Beispielausgabe 1 zeigt, dass der Eingangsrouter (Reverse LSP) keine BGP-Routen in die Routing-Tabelle empfängt, wenn die BGP-Konfigurationen von und falsch sind.R6R6-to-R1inet.0R1R6
Beispielausgabe 2 zeigt eine BGP-Route, die in der Routing-Tabelle installiert wurde, nachdem die BGP-Konfigurationen aktiviert und mit Ergreifen geeigneter Maßnahmen zum Beheben des Netzwerkproblems korrigiert wurden.inet.0R1 R6Fehlerbehebung bei Netzwerkproblemen
Ergreifen geeigneter Maßnahmen zur Lösung des Netzwerkproblems
Problem
Beschreibung
Welche Maßnahme am besten geeignet ist, hängt von der Art des isolierten Problems ab. In diesem Beispiel wird eine statische Route, die am konfiguriert ist , aus der Hierarchieebene [] gelöscht.R2 routing-options Weitere geeignete Maßnahmen können Folgendes umfassen:
Lösung
Überprüfen Sie die Konfiguration des lokalen Routers und bearbeiten Sie sie gegebenenfalls.
Beheben Sie Fehler beim zwischengeschalteten Router.
Überprüfen Sie die Remote-Host-Konfiguration, und bearbeiten Sie sie gegebenenfalls.
Fehlerbehebung bei Routing-Protokollen.
Identifizieren Sie weitere mögliche Ursachen.
Um das Problem in diesem Beispiel zu beheben, geben Sie die folgenden Junos OS CLI-Befehle ein:
[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, dass die statische Route aus der []-Hierarchie gelöscht und die neue Konfiguration festgeschrieben wurde.routing-options Die Ausgabe für den Befehl zeigt nun die BGP-Route als bevorzugte Route an, wie durch das Sternchen () angezeigt.show route *
Überprüfen Sie, ob der BGP-Datenverkehr den LSP erneut verwendet.
Zweck
Nachdem Sie die entsprechenden Maßnahmen ergriffen haben, um den Fehler zu beheben, muss der LSP erneut überprüft werden, um zu bestätigen, dass der BGP-Datenverkehr den LSP verwendet und dass das Problem in der BGP-Schicht behoben wurde.
Was
Um zu überprüfen, ob der BGP-Datenverkehr den LSP verwendet, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl 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-Labels verwendet werden, um Pakete über den LSP weiterzuleiten. In der Ausgabe enthalten sind ein Beschriftungswert (), der Time-to-Live-Wert () und der Stack-Bit-Wert ().MPLS Label=100016TTL=1S=1
Das Feld wird verwendet, um das Paket für einen bestimmten LSP zu identifizieren.MPLS Label Es handelt sich um ein 20-Bit-Feld mit einem Maximalwert von (2^^20-1), ungefähr 1.000.000.
Der TTL-Wert (Time-to-Live) enthält eine Begrenzung für die Anzahl der Hops, die dieses MPLS-Paket durch das Netzwerk übertragen kann (1). Sie wird bei jedem Hop dekrementiert, und wenn der TTL-Wert unter eins fällt, wird das Paket verworfen.
Der untere Teil des Stack-Bitwerts () gibt an, dass dies das letzte Label im Stack ist und dass diesem MPLS-Paket ein Label zugeordnet ist.S=1 Die MPLS-Implementierung im Junos-Betriebssystem unterstützt eine Stacking-Tiefe 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-Bezeichnungen werden in der Beispielausgabe angezeigt, da der Befehl an ein BGP-Ziel ausgegeben wird, wobei der nächste BGP-Hop für diese Route die LSP-Ausgangsadresse ist.traceroute Das Junos-Betriebssystem verwendet standardmäßig LSPs für BGP-Datenverkehr, wenn der nächste BGP-Hop der LSP-Ausgangsadresse entspricht.
Wenn der nächste BGP-Hop nicht mit der LSP-Ausgangsadresse übereinstimmt, verwendet der BGP-Datenverkehr nicht den LSP, und folglich werden MPLS-Bezeichnungen nicht in der Ausgabe für den Befehl angezeigt, wie in der Beispielausgabe unter Überprüfen von BGP-Sitzungen angegeben.tracerouteFehlerbehebung bei BGP-Sitzungen
Anzeige gesendeter oder empfangener BGP-Pakete
Was
Gehen Sie folgendermaßen vor, um die Ablaufverfolgung für gesendete oder empfangene BGP-Protokollpakete zu konfigurieren:
Wechseln Sie im Konfigurationsmodus auf folgende Hierarchieebene:
[edit] user@host# edit protocol bgp traceoptions
Konfigurieren Sie das Flag so, dass gesendete, empfangene oder sowohl gesendete als auch empfangene Paketinformationen angezeigt werden:
[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
Überprüfen Sie die Konfiguration:
user@host# show
Hier einige Zahlen zum Generationswechsel:
[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;
Bestätigen Sie die Konfiguration:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameHier einige Zahlen zum Generationswechsel:
[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. Verbindungsprobleme, müssen Sie möglicherweise Routen in der Weiterleitungstabelle untersuchen, um sicherzustellen, dass der Routingprotokollprozess die richtigen Informationen an die Weiterleitungstabelle weitergeleitet hat.
Was
Um den Satz von Routen anzuzeigen, die in der Weiterleitungstabelle installiert sind, geben Sie den folgenden Junos OS CLI-Betriebsmodusbefehl ein:
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 der Netzwerkschicht und ihre nächsten Hops, die in der Weiterleitungstabelle installiert sind. Die Ausgabe enthält die gleichen Next-Hop-Informationen wie im Befehl (die Next-Hop-Adresse und den Schnittstellennamen).show route detail Zu den zusätzlichen Informationen gehören der Zieltyp, der Typ des nächsten Hops, die Anzahl der Verweise auf diesen nächsten Hop und ein Index in einer internen Datenbank für den nächsten Hop. (Die interne Datenbank enthält zusätzliche Informationen, die von der Packet Forwarding Engine verwendet werden, um die ordnungsgemäße Kapselung von Paketen sicherzustellen, die von einer Schnittstelle gesendet werden. Auf diese Datenbank kann der Benutzer nicht zugreifen.
Ausführliche Informationen zur Bedeutung der verschiedenen Flag- und Typenfelder finden Sie im Benutzerhandbuch für Routingrichtlinien, Firewallfilter und Traffic Policers.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-policy/config-guide-policy.html
Beispiel: Überschreiben der standardmäßigen BGP-Routing-Richtlinie auf Paketübertragungs-Routern der PTX-Serie
In diesem Beispiel wird gezeigt, wie die Standardroutingrichtlinie auf Paketübertragungsroutern, wie z. B. den Paketübertragungsroutern der PTX-Serie, außer Kraft gesetzt wird.
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 Bedingung mit der Aktion nicht das übliche Ergebnis, das sie auf anderen Junos OS-Routing-Geräten hat.from protocols bgpthen accept 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. Dies ist das erwartete Verhalten.
In diesem Beispiel wird gezeigt, wie die Aktion verwendet wird, um die standardmäßige BGP-Routing-Richtlinie effektiv außer Kraft zu setzen.then install-to-fib
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein.[edit]
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
Installieren ausgewählter BGP-Routen in der Weiterleitungstabelle
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch.Verwenden des CLI-Editors im Konfigurationsmodushttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
So installieren Sie ausgewählte BGP-Routen in der Weiterleitungstabelle:
Konfigurieren Sie eine Liste von Präfixen, die in der Weiterleitungstabelle installiert werden sollen.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Konfigurieren Sie die Routingrichtlinie, 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 im Konfigurationsmodus Ihre Konfiguration, indem Sie die Befehle und eingeben.show policy-optionsshow routing-options Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, 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, rufen Sie den Konfigurationsmodus auf .commit
Überprüfung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfen, ob die ausgewählte Route in der Weiterleitungstabelle installiert ist
Zweck
Stellen Sie sicher, dass die konfigurierte Richtlinie die Standardrichtlinie außer Kraft setzt.
Was
Geben Sie im Betriebsmodus den Befehl ein.show route forwarding-table
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.
Protokollieren von BGP-Statusübergangsereignissen
Zweck
BGP-Statusübergänge (Border Gateway Protocol) weisen auf ein Netzwerkproblem hin und müssen protokolliert und untersucht werden.
Was
Gehen Sie folgendermaßen vor, um BGP-Statusübergangsereignisse im Systemprotokoll zu protokollieren:
Wechseln Sie im Konfigurationsmodus auf folgende Hierarchieebene:
[edit] user@host# edit protocol bgpKonfigurieren Sie das Systemprotokoll:
user@host# set log-updown
Überprüfen Sie die Konfiguration:
user@host# show
Bestätigen Sie die Konfiguration:
user@host# commit
Bedeutung
Protokollmeldungen von BGP-Statusü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 Status einer Verbindung. BGP wartet auf ein Startereignis, das von einem Administrator initiiert wird. Das Startereignis kann der Aufbau einer BGP-Sitzung durch die Routerkonfiguration oder das Zurücksetzen einer bestehenden Sitzung sein. Nach dem start-Ereignis initialisiert BGP seine Ressourcen, setzt einen Verbindungs-/Wiederholungstimer zurück, initiiert eine TCP-Transportverbindung und beginnt mit der Überwachung von Verbindungen, die von Remote-Peers initiiert wurden. BGP geht dann in einen Status über.Connect Wenn Fehler auftreten, greift BGP auf den Status zurück.Idle |
Connect |
BGP wartet, bis die Verbindung mit dem Transportprotokoll hergestellt wurde. Wenn die TCP-Transportverbindung erfolgreich ist, geht der Zustand in .OpenSent Wenn die Transportverbindung nicht erfolgreich ist, geht der Zustand in .Active Wenn der Timer für die Verbindungswiederholung abgelaufen ist, bleibt der Zustand im Zustand, der Timer wird zurückgesetzt, und eine Transportverbindung wird initiiert.Connect Bei jedem anderen Ereignis geht der Zustand zurück zu .Idle |
Active |
BGP versucht, einen Peer abzurufen, indem es eine Transportprotokollverbindung initiiert. Wenn dies erfolgreich ist, geht der Zustand in .OpenSent Wenn der Verbindungswiederholungstimer abläuft, startet BGP den Verbindungstimer neu und setzt den Status zurück. Connect BGP lauscht weiterhin auf eine Verbindung, die möglicherweise von einem anderen Peer initiiert wird. Der Zustand kann bei anderen Ereignissen, z. B. einem Stopp-Ereignis, wieder verwendet werden.Idle Im Allgemeinen ist ein Switch-Flop zwischen und ein Hinweis darauf, dass ein Problem mit der TCP-Transportverbindung vorliegt. ConnectActive Ein solches Problem kann durch viele TCP-Neuübertragungen oder die Unfähigkeit eines Nachbarn, die IP-Adresse seines Peers zu erreichen, verursacht werden. |
OpenSent |
BGP empfängt eine offene Nachricht von seinem Peer. In diesem Zustand vergleicht BGP seine AS-Nummer (Autonomous System) mit der AS-Nummer seines Peers und erkennt, ob der Peer zum gleichen AS (internes BGP) oder zu einem anderen AS (externes BGP) gehört.OpenSent Die geöffnete Nachricht wird auf Richtigkeit geprüft. Im Falle von Fehlern, wie z. B. einer ungültigen Versionsnummer eines inakzeptablen AS, sendet BGP eine Fehlermeldung und kehrt zu .Idle Bei allen anderen Fehlern, wie z. B. Ablauf des Haltetimers oder einem Stoppereignis, sendet BGP eine Benachrichtigungsmeldung mit dem entsprechenden Fehlercode und greift auf den Zustand zurück. Idle Wenn keine Fehler auftreten, sendet BGP Keepalive-Meldungen und setzt den Keepalive-Timer zurück. In diesem Zustand wird die Haltezeit ausgehandelt. Wenn die Haltezeit 0 ist, werden die Halte- und Keepalive-Timer nicht neu gestartet. Wenn eine TCP-Transportunterbrechung erkannt wird, wird der Status auf zurückgegriffen.Active |
OpenConfirm |
BGP wartet auf eine Keepalive- oder Benachrichtigungsmeldung. Wenn ein keepalive empfangen wird, wird der Zustand zu , und die Nachbaraushandlung ist abgeschlossen.Established Wenn das System eine Aktualisierungs- oder Keepalive-Meldung empfängt, startet es den Haltetimer neu (vorausgesetzt, die ausgehandelte Haltezeit ist nicht 0). Wenn eine Benachrichtigung empfangen wird, wird auf den Status zurückgegriffen. Idle Das System sendet periodisch Keepalive-Nachrichten mit der Rate, die durch den Keepalive-Timer festgelegt wird. Im Falle einer Benachrichtigung über einen Transportabbruch oder als Reaktion auf ein Stoppereignis wird auf den Status zurückgegriffen. Idle Als Reaktion auf andere Ereignisse sendet das System eine Benachrichtigung mit einem FSM-Fehlercode (Finite State Machine) und kehrt zu .Idle |
Established |
Dies ist der letzte Zustand in der Nachbarschaftsverhandlung. In diesem Zustand tauscht BGP Aktualisierungsbestätigungen mit seinen Peers aus, und der Haltetimer wird beim Empfang einer Aktualisierungs- oder Keepalive-Nachricht neu gestartet, wenn er nicht auf Null gesetzt ist. Wenn das System eine Benachrichtigung erhält, fällt der Zustand auf .Idle Aktualisierungsmeldungen werden auf Fehler überprüft, z. B. fehlende Attribute, doppelte Attribute usw. Wenn Fehler gefunden werden, wird eine Benachrichtigung an den Peer gesendet, und der Status wird auf zurückgesetzt.Idle BGP geht zurück zu dem Zeitpunkt, an dem der Haltetimer abläuft, eine Benachrichtigung zum Verbindungsabbruch vom Transportprotokoll empfangen wird, ein Stoppereignis empfangen wird oder als Reaktion auf ein anderes Ereignis.Idle |
Ausführlichere Informationen zu BGP-Protokollpaketen erhalten Sie, indem Sie BGP-spezifisches Tracing konfigurieren. Weitere Informationen finden Sie unter Prüfliste für Tracking Error-Bedingungen .Checkliste für Tracking-Error-Bedingungen
Konfigurieren von BGP-spezifischen Optionen
Zweck
Wenn unerwartete Ereignisse oder Probleme auftreten oder wenn Sie Probleme bei der BGP-Einrichtung diagnostizieren möchten, können Sie detailliertere Informationen anzeigen, indem Sie BGP-spezifische Optionen konfigurieren. Sie können die Ablaufverfolgung auch für einen bestimmten BGP-Peer oder eine bestimmte Peergruppe konfigurieren. Weitere Informationen finden Sie im Konfigurationshandbuch zu den Junos-Systemgrundlagen.
- Detaillierte BGP-Protokollinformationen anzeigen
- Diagnostizieren von Problemen beim Aufbau von BGP-Sitzungen
Detaillierte BGP-Protokollinformationen anzeigen
Was
Gehen Sie folgendermaßen vor, um BGP-Protokollinformationen im Detail anzuzeigen:
Wechseln Sie im Konfigurationsmodus auf folgende Hierarchieebene:
[edit] user@host# edit protocol bgp traceoptions
Konfigurieren Sie das Flag so, dass detaillierte BGP-Protokollmeldungen angezeigt werden:
[edit protocols bgp traceoptions] user@host# set flag update detail
Überprüfen Sie die Konfiguration:
user@host# show
Hier einige Zahlen zum Generationswechsel:
[edit protocols bgp traceoptions] user@host# show flag update detail;
Bestätigen Sie die Konfiguration:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameHier einige Zahlen zum Generationswechsel:
[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 Ablaufverfolgungsflags auf, die für BGP spezifisch sind, und präsentiert eine Beispielausgabe für einige der Flags. Sie können die Ablaufverfolgung auch für einen bestimmten BGP-Peer oder eine bestimmte Peergruppe konfigurieren. Weitere Informationen finden Sie im Konfigurationshandbuch zu den Junos-Systemgrundlagen.
Ablaufverfolgungs-Flags |
Beschreibung |
Beispielausgabe |
|---|---|---|
aspath |
AS-Pfad-Operationen mit regulären Ausdrücken |
Nicht verfügbar |
damping |
Dämpfungsvorgänge |
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) |
Diagnostizieren von Problemen beim Aufbau von BGP-Sitzungen
Zweck
Zum Nachverfolgen von Problemen beim Aufbau von BGP-Sitzungen.
Was
Gehen Sie folgendermaßen vor, um Probleme beim Aufbau von BGP-Sitzungen zu verfolgen:
Wechseln Sie im Konfigurationsmodus auf folgende Hierarchieebene:
[edit] user@host# edit protocol bgpKonfigurieren von BGP-Öffnungsmeldungen:
[edit protocols bgp] user@host# set traceoptions flag open detail
Überprüfen Sie die Konfiguration:
user@host# show
Hier einige Zahlen zum Generationswechsel:
[edit protocols bgp] user@host# show traceoptions { file bgplog size 10k files 10; flag open detail; }Bestätigen Sie die Konfiguration:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host#run show log filenameHier einige Zahlen zum Generationswechsel:
[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 von IS-IS-spezifischen Optionen
Zweck
Wenn unerwartete Ereignisse oder Probleme auftreten oder wenn Sie Probleme bei der Einrichtung von IS-IS-Nachbarschaften 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:
- Detaillierte IS-IS-Protokollinformationen anzeigen
- Anzeige von gesendeten oder empfangenen IS-IS-Protokollpaketen
- IS-IS Link-State-PDUs im Detail analysieren
Detaillierte IS-IS-Protokollinformationen anzeigen
Was
Gehen Sie folgendermaßen vor, um IS-IS-Nachrichten im Detail zu verfolgen:
Konfigurieren Sie das Flag so, dass detaillierte IS-IS-Protokollmeldungen angezeigt werden.
[edit protocols isis traceoptions] user@host# set flag hello detail
Überprüfen Sie die Konfiguration.
user@host# show
Hier einige Zahlen zum Generationswechsel:
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello detail;
Bestätigen Sie die Konfiguration.
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an.
user@host# run show log filenameHier einige Zahlen zum Generationswechsel:
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 Ablaufverfolgungsflags auf, die IS-IS spezifisch konfiguriert werden können, und stellt Beispielausgaben für einige der Flags dar.
Ablaufverfolgungs-Flags |
Beschreibung |
Beispielausgabe |
|---|---|---|
csn |
PDU mit vollständiger Sequenznummer (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 Option.detail 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 |
PDU-Generierungspakete mit Verbindungsstatus |
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 |
PDU-Pakete (PSNP) mit partieller Sequenznummer |
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 |
SPF-Berechnungen (Shortest-Path-First) |
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 so, dass gesendete, empfangene oder sowohl gesendete als auch empfangene Pakete angezeigt werden.
[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
Hier einige Zahlen zum Generationswechsel:
[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;
Bestätigen Sie die Konfiguration.
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an.
user@host# run show log filenameHier einige Zahlen zum Generationswechsel:
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
IS-IS Link-State-PDUs im Detail analysieren
Gehen Sie folgendermaßen vor, um IS-IS-Link-State-PDUs im Detail zu analysieren:
Konfigurieren Sie IS-IS-Öffnungsmeldungen.
[edit protocols isis traceoptions] user@host# set flag lsp detail
Überprüfen Sie die Konfiguration.
user@host# show
Hier einige Zahlen zum Generationswechsel:
[edit protocols isis traceoptions] user@host# show file isislog size 5m world-readable; flag error; flag lsp detail;
Bestätigen Sie die Konfiguration.
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Nachrichten an.
user@host# run show log filenameHier einige Zahlen zum Generationswechsel:
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
Konfigurieren von OSPF-spezifischen Optionen
Zweck
Wenn unerwartete Ereignisse oder Probleme auftreten oder wenn Sie Probleme mit der OSPF-Nachbareinrichtung 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:
- Diagnostizieren von Problemen beim Aufbau von OSPF-Sitzungen
- Detaillierte Analyse von OSPF-Link-State-Ankündigungspaketen
Diagnostizieren von Problemen beim Aufbau von OSPF-Sitzungen
Was
Gehen Sie folgendermaßen vor, um OSPF-Nachrichten im Detail zu verfolgen:
Wechseln Sie im Konfigurationsmodus auf folgende Hierarchieebene:
[edit] user@host# edit protocols ospf traceoptions
Konfigurieren von OSPF-Hello-Nachrichten:
[edit protocols ospf traceoptions] user@host# set flag hello detail
Überprüfen Sie die Konfiguration:
user@host# show
Hier einige Zahlen zum Generationswechsel:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail;
Bestätigen Sie die Konfiguration:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameHier einige Zahlen zum Generationswechsel:
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-Ablaufverfolgungsflags auf und präsentiert eine Beispielausgabe für einige der Flags.
Ablaufverfolgungs-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-fehlerhafte 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-Zustandsü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 Päckchen |
10.10.10.10.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.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 |
10.10 10.10.10.10.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 .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 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 134.12, area 0.0.0.0 Dec 2 16:00:16 checksum 0x8180, authtype 0 |
lsa-request |
Link-State-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 |
Link-State-Update-Pakete |
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 |
Dump des Inhalts ausgewählter Pakettypen |
Nicht verfügbar |
spf |
SPF-Berechnungen |
10.10.10.10.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 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 134.12 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0 |
Detaillierte Analyse von OSPF-Link-State-Ankündigungspaketen
Was
Gehen Sie folgendermaßen vor, um OSPF-Link-State-Ankündigungspakete im Detail zu analysieren:
Wechseln Sie im Konfigurationsmodus auf folgende Hierarchieebene:
[edit] user@host# edit protocols ospf traceoptions
Konfigurieren von OSPF-Link-State-Paketen:
[edit protocols ospf traceoptions] user@host# set flag lsa-update detail
Überprüfen Sie die Konfiguration:
user@host# show
Hier einige Zahlen zum Generationswechsel:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail; flag lsa-update detail;
Bestätigen Sie die Konfiguration:
user@host# commit
Zeigen Sie den Inhalt der Datei mit den detaillierten Meldungen an:
user@host# run show log filenameHier einige Zahlen zum Generationswechsel:
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