Sur cette page
Dépannage des sessions BGP
Liste de vérification du protocole BGP et de ses homologues
But
Tableau 1 fournit des liens et des commandes pour vérifier si le Border Gateway Protocol (BGP) est correctement configuré sur un routeur Juniper Networks de votre réseau, les sessions internes du Border Gateway Protocol (IBGP) et externes du Border Gateway Protocol (EBGP) sont correctement établies, si les routes externes sont annoncées et reçues correctement et si le processus de sélection du chemin BGP fonctionne correctement.
Action
Tâches |
Commande ou action |
|---|---|
| Vérifier les homologues BGP | |
|
|
|
|
|
|
|
|
| Examen des routes BGP et sélection de routes | |
|
|
|
|
|
|
|
|
| Examiner les itinéraires dans la table de transfert |
|
Vérifier les homologues BGP
But
En supposant que tous les routeurs sont correctement configurés pour BGP, vous pouvez vérifier si les sessions IBGP et EBGP sont correctement établies, si les routes externes sont annoncées et reçues correctement, et si le processus de sélection du chemin BGP fonctionne correctement.
Figure 1 illustre un exemple de topologie de réseau BGP utilisée dans cette rubrique.
Le réseau se compose de deux AS directement connectés, constitués d’homologues externes et internes. Les homologues externes sont directement connectés via une interface partagée et exécutent EBGP. Les homologues internes sont connectés via leurs interfaces loopback (lo0) via IBGP. AS 65001 exécute OSPF et AS 65002 exécute IS-IS comme IGP sous-jacent. Les routeurs IBGP n’ont pas besoin d’être directement connectés, l’IGP sous-jacent permet aux voisins de se joindre.
Les deux routeurs de l’AS 65001 contiennent chacun un lien EBGP vers l’AS 65002 (R2 et R4) sur lequel ils annoncent des préfixes agrégés : 100.100.1.0, 100.100.2.0, 100.100.3.0, et 100.100.4.0. De plus, R1 et R5 injectent des valeurs de discriminateur de sortie multiple (MED) de 5 et 10, respectivement, pour certaines routes.
Les routeurs internes des deux AS utilisent une topologie IBGP à maillage complet. Un maillage complet est nécessaire, car les réseaux n’utilisent pas de confédérations ou de réflecteurs de route, de sorte que les routes apprises via IBGP ne sont pas distribuées à d’autres voisins internes. Par exemple, lorsqu’il R3 apprend une route à partir de R2, R3 ne distribue pas cette route àR6, car la route est apprise via IBGP, elle doit donc R6 avoir une connexion BGP directe pour R2 apprendre la route.
Dans une topologie à maillage complet, seul le routeur de bordure recevant des informations BGP externes distribue ces informations aux autres routeurs au sein de son AS. Le routeur récepteur ne redistribue pas ces informations aux autres routeurs IBGP dans son propre AS.
Du point de vue de l’AS 65002, les sessions suivantes devraient être en place :
Les quatre routeurs de l’AS 65002 doivent avoir des sessions IBGP établies les unes avec les autres.
R2doit avoir une session EBGP établie avecR1.R4doit avoir une session EBGP établie avecR5.
Pour vérifier les homologues BGP, procédez comme suit :
- Vérifier BGP sur un routeur interne
- Vérifier BGP sur un routeur de bordure
- Vérifier les routes BGP annoncées
- Vérifiez qu’une route BGP particulière est reçue sur votre routeur
Vérifier BGP sur un routeur interne
But
Permet de vérifier la configuration BGP d’un routeur interne.
Action
Pour vérifier la configuration BGP d’un routeur interne, entrez la commande suivante de l’interface de ligne de commande (CLI) Junos OS :
user@host> show configuration
L’exemple de sortie suivant correspond à une configuration BGP sur R3 :
Exemple de sortie
nom_commande
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;
}
}
Sens
L’exemple de sortie montre une configuration BGP de base sur les routeurs R3 et R6. L’AS local (65002) et un groupe (internal) sont configurés sur les deux routeurs. R3 possède trois homologues internes —10.0.0.2, 10.0.0.4, et 10.0.0.6—inclus au niveau hiérarchique [protocols bgp group group]. R6 possède également trois homologues internes : 10.0.0.2, 10.0.0.3, et 10.0.0.4. Le protocole IGP sous-jacent est IS-IS (Intermediate System-to-Intermediate System), et les interfaces correspondantes sont configurées pour exécuter IS-IS.
Notez que dans cette configuration, l’ID de routeur est configuré manuellement pour éviter tout problème d’ID de routeur en double.
Vérifier BGP sur un routeur de bordure
But
Pour vérifier la configuration BGP d’un routeur de bordure.
Action
Pour vérifier la configuration BGP d’un routeur de bordure, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show configuration
Exemple de sortie
nom_commande
L’exemple de sortie suivant correspond à une configuration BGP sur deux routeurs de bordure, R2 et R4, à partir de l’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;
}
}
}
Sens
L’exemple de sortie montre une configuration BGP de base sur des routeurs R2 de bordure et R4. L’AS (65002) des deux routeurs est inclus au niveau de la hiérarchie [routing-options]. Chaque routeur comporte deux groupes inclus au niveau de la hiérarchie [protocols bgp group group]. Les homologues externes sont inclus dans le groupe externe, soit vers R1 , soit toR5 vers, selon le routeur. Les pairs internes sont inclus dans le internal groupe. Le protocole IGP sous-jacent est IS-IS sur les deux routeurs, et les interfaces correspondantes sont configurées pour exécuter IS-IS.
Notez que dans la configuration sur les deux routeurs, l’ID de routeur est configuré manuellement pour éviter les problèmes d’ID de routeur en double, et l’instruction est incluse pour éviter tout problème d’accessibilité next-hop-self du prochain saut BGP.
Vérifier les routes BGP annoncées
But
Vous pouvez déterminer si un itinéraire particulier que vous avez configuré est annoncé à un voisin.
Action
Pour vérifier les informations de routage telles qu’elles ont été préparées pour publication sur le voisin BGP spécifié, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route advertising-protocol bgp neighbor-address
Exemple de sortie
nom_commande
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
Sens
L’exemple de sortie montre les routes BGP annoncées à partir de R2 leur voisin, 10.0.0.4 (R4). Sur un total de 22 itinéraires dans la inet.0 table de routage, 20 sont des destinations actives. Aucune route n’est hidden ou dans l’état hold-down . Les routes résident dans hold-down l’état avant d’être déclarées actives et les routes rejetées par une stratégie de routage peuvent être placées dans l’état hidden . Les informations affichées reflètent les routes exportées par la table de routage vers le protocole de routage BGP.
Vérifiez qu’une route BGP particulière est reçue sur votre routeur
But
Affichez les informations de routage telles qu’elles sont reçues par l’intermédiaire d’un voisin BGP particulier et annoncées par le routeur local au voisin.
Action
Pour vérifier qu’une route BGP particulière est reçue sur votre routeur, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route receive-protocol bgp neighbor-address
Exemple de sortie
nom_commande
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)
Sens
L’exemple de sortie montre quatre routes BGP à partir de R2 et deux à partir de R4. Sur les quatre routes de R2, seules deux sont actives dans la table de routage, comme indiqué par l’astérisque (*), tandis que les deux routes reçues de sont actives dans la table de R4 routage. Tous les routages BGP passaient par l’AS 65001.
Examen des routes BGP et sélection de routes
But
Vous pouvez examiner le processus de sélection du chemin BGP pour déterminer le chemin unique et actif lorsque BGP reçoit plusieurs chemins vers le même préfixe de destination.
Le réseau dans Figure 2 montre que R1 et R5 annonce les mêmes routes agrégées vers R2 et R4, ce qui se traduit par R2 et R4 la réception de deux routes vers le même préfixe de destination. Le processus de sélection de route est activé R2 et R4 détermine laquelle des deux routes BGP reçues est active et annoncée aux autres routeurs internes (R3 et R6).
Avant d’installer une route BGP, le routeur doit s’assurer que l’attribut BGP next-hop est accessible. Si le tronçon suivant BGP ne peut pas être résolu, la route n’est pas installée. Lorsqu’une route BGP est installée dans la table de routage, elle doit passer par un processus de sélection de chemin s’il existe plusieurs routes vers le même préfixe de destination. Le processus de sélection du chemin BGP se déroule dans l’ordre suivant :
Les préférences de route dans la table de routage sont comparées. Par exemple, s’il existe une route OSPF et une route BGP pour une destination particulière, la route OSPF est sélectionnée comme route active, car la préférence par défaut de la route OSPF est 110, tandis que la préférence par défaut de la route BGP est 170.
Les itinéraires sont comparés en fonction des préférences locales. L’itinéraire avec la préférence locale la plus élevée est préféré. Par exemple, reportez-vous à la section Examiner la sélection des préférences locales.
L’attribut de chemin AS est évalué. Le chemin AS le plus court est préférable.
Le code d’origine est évalué. Le code d’origine le plus bas est préféré (
I (IGP) < E (EGP) < ? (Incomplete)).La valeur MED est évaluée. Par défaut, si l’un des itinéraires est annoncé à partir du même AS voisin, la valeur MED la plus basse est préférée. L’absence d’une valeur MED est interprétée comme une MED de 0. Pour obtenir un exemple, reportez-vous à la section Examiner la sélection d’itinéraire du discriminateur de sortie multiple.
L’itinéraire est évalué pour déterminer s’il est appris par EBGP ou IBGP. Les routes apprises EBGP sont préférées aux routes apprises IBGP. Pour obtenir un exemple, reportez-vous à la section Examiner la sélection EBGP sur IBGP
Si l’itinéraire est appris à partir de l’IBGP, l’itinéraire avec le coût IGP le plus bas est préféré. Pour obtenir un exemple, reportez-vous à la section Examiner la sélection des coûts IGP. Le tronçon physique suivant vers l’homologue IBGP est installé selon les trois règles suivantes :
Une fois que BGP a examiné les tables de routage
inet.0etinet.3, le tronçon physique suivant de la route avec la préférence la plus faible est utilisé.
Si les valeurs de préférence dans le
inet.0et lesinet.3tables de routage sont égales, le tronçon physique suivant de la route dans lainet.3table de routage est utilisé.
Lorsqu’un lien de préférence existe dans la même table de routage, le tronçon physique suivant de l’itinéraire avec plus de chemins est installé.
L’attribut de liste du cluster de réflexion de route est évalué. Il est préférable d’utiliser la liste de clusters la plus courte. Les routes sans liste de clusters sont considérées comme ayant une longueur de liste de clusters de 0.
L’ID du routeur est évalué. Il est préférable d’utiliser la route à partir de l’homologue avec l’ID de routeur le plus bas (généralement l’adresse de bouclage).
La valeur de l’adresse de l’homologue est examinée. L’homologue avec l’adresse IP de l’homologue la plus basse est préféré.
Pour déterminer le chemin unique et actif lorsque BGP reçoit plusieurs routes vers le même préfixe de destination, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route destination-prefix < detail >
Les étapes suivantes illustrent le motif d’inactivité qui s’affiche lorsque BGP reçoit plusieurs routes vers le même préfixe de destination et qu’une route est sélectionnée comme chemin d’accès unique et actif :
- Examinez la sélection des préférences locales
- Examinez la sélection de l’itinéraire du discriminateur de sortie multiple
- Examiner la sélection EBGP sur IBGP
- Examiner la sélection des coûts IGP
Examinez la sélection des préférences locales
But
Examiner un itinéraire afin de déterminer si la préférence locale est le critère de sélection du chemin unique actif.
Action
Pour examiner un itinéraire afin de déterminer si la préférence locale est le critère de sélection du chemin actif unique, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route destination-prefix < detail >
Exemple de sortie
nom_commande
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
Sens
L’exemple de sortie montre que R4 vous avez reçu deux instances de l’itinéraire 100.100.1.0 : l’un de 10.0.0.2 (R2) et l’autre de 10.1.45.2 (R5). R4 a sélectionné le chemin R2 d’accès comme chemin actif, comme indiqué par l’astérisque (*). La sélection est basée sur la valeur de préférence locale contenue dans le Localpref champ. Le chemin avec la préférence locale la plus élevée est préféré. Dans l’exemple, le chemin avec la valeur de préférence locale la plus élevée est le chemin d’accès à partir de R2, 200.
La raison pour laquelle l’itinéraire de R5 n’est pas sélectionné se trouve dans le Inactive reason champ, dans ce cas, Local Preference.
Notez que les deux chemins proviennent du même réseau voisin : AS 65001.
Examinez la sélection de l’itinéraire du discriminateur de sortie multiple
But
Examiner un itinéraire afin de déterminer si le MED est le critère de sélection du chemin unique actif.
Action
Pour examiner un itinéraire afin de déterminer si le MED est le critère de sélection du chemin unique actif, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS :
user@host> show route destination-prefix < detail >
Exemple de sortie
nom_commande
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
Sens
L’exemple de sortie montre que R4 vous avez reçu deux instances de l’itinéraire 100.100.2.0 : l’un de 10.0.0.2 (R2) et l’autre de 10.1.45.2 (R5). R4 sélectionné le chemin R2 d’à partir de comme itinéraire actif, comme indiqué par l’astérisque (*). La sélection est basée sur la valeur MED contenue dans le Metric: champ. Le chemin avec la valeur MED la plus faible est préféré. Dans l’exemple, le chemin avec la valeur MED la plus faible (5) est le chemin de R2. Notez que les deux chemins proviennent du même réseau voisin : AS 65001.
La raison pour laquelle le chemin inactif n’est pas sélectionné est affichée dans le Inactive reason: champ, dans ce cas, Not Best in its group. Cette formulation est utilisée car Junos OS utilise par défaut le processus de sélection MED déterministe.
Examiner la sélection EBGP sur IBGP
But
Examiner une route afin de déterminer si EBGP est sélectionné plutôt qu’IBGP comme critère de sélection pour le chemin unique actif.
Action
Pour examiner un itinéraire afin de déterminer si EBGP est sélectionné plutôt qu’IBGP comme critère de sélection pour le chemin actif unique, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route destination-prefix < detail >
Exemple de sortie
nom_commande
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
Sens
L’exemple de sortie montre que R4 vous avez reçu deux instances de l’itinéraire 100.100.3.0 : l’un de 10.1.45.2 (R5) et l’autre de 10.0.0.2 (R2). R4 a sélectionné le chemin R5 d’accès comme chemin actif, comme indiqué par l’astérisque (*). La sélection est basée sur une préférence pour les routes apprises à partir d’un pair EBGP par rapport aux routes apprises à partir d’un IBGP. R5 est un pair EBGP.
Vous pouvez déterminer si un chemin est reçu d’un homologue EBGP ou IBGP en examinant les Local As champs et Peer As . Par exemple, la route de R5 indique que l’AS local est 65002 et l’AS pair est 65001, ce qui indique que la route est reçue d’un pair EBGP. L’itinéraire de R2 indique que l’AS local et homologue est 65002, ce qui indique qu’il provient d’un homologue IBGP.
La raison pour laquelle le chemin inactif n’est pas sélectionné est affichée dans le Inactive reason champ, dans ce cas, Interior > Exterior > Exterior via Interior. Le libellé de ce motif indique l’ordre des préférences appliquées lorsque le même itinéraire est reçu de deux routeurs. La route reçue d’une source strictement interne (IGP) est préférée en premier, la route reçue d’une source externe (EBGP) est préférée ensuite, et toute route provenant d’une source externe et reçue en interne (IBGP) est préférée en dernier. Par conséquent, les routes EBGP sont sélectionnées plutôt que les routes IBGP comme chemin actif.
Examiner la sélection des coûts IGP
But
Examiner une route afin de déterminer si EBGP est sélectionné plutôt qu’IBGP comme critère de sélection pour le chemin unique actif.
Action
Pour examiner un itinéraire afin de déterminer si EBGP est sélectionné plutôt qu’IBGP comme critère de sélection pour le chemin actif unique, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route destination-prefix < detail >
Exemple de sortie
nom_commande
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
Sens
L’exemple de sortie montre que R6 vous avez reçu deux instances de l’itinéraire 100.100.4.0 : l’un de 10.0.0.4 (R4) et l’autre de 10.0.0.2 (R2). R6 sélectionné le chemin R4 d’à partir de comme itinéraire actif, comme indiqué par l’astérisque (*). La sélection est basée sur la métrique IGP, affichée dans le Metric2 champ. L’itinéraire avec la métrique IGP la plus basse est préféré. Dans l’exemple, le chemin d’accès avec la valeur de métrique IGP la plus basse est le chemin de R4, avec une valeur de métrique IGP de 10, tandis que le chemin d’accès a R2 une métrique IGP de 20. Notez que les deux chemins proviennent du même réseau voisin : AS 65001.
La raison pour laquelle le chemin inactif n’a pas été sélectionné s’affiche dans le champ Inactive reason, dans ce cas, IGP metric.
Liste de contrôle pour la vérification de la couche BGP
Problème
Description
Cette liste de contrôle fournit les étapes et les commandes de vérification de la configuration BGP du réseau MPLS (Multiprotocol Label Switching). La liste de contrôle fournit des liens vers une vue d’ensemble de la configuration BGP et des informations plus détaillées sur les commandes utilisées pour configurer BGP. (Reportez-vous à la section Tableau 2.)
Solution
Tâches |
Commande ou action |
|---|---|
| Vérification de la couche BGP | |
|
|
|
|
|
|
|
|
|
|
La séquence de commandes suivante résout le problème spécifique décrit dans cette rubrique :
|
|
|
Vérification de la couche BGP
But
Une fois que vous avez configuré le chemin de commutation d’étiquettes (LSP) et déterminé qu’il est actif, et configuré BGP et déterminé que des sessions sont établies, assurez-vous que BGP utilise le LSP pour transférer le trafic.
Figure 3 illustre la couche BGP du modèle MPLS en couches.
Lorsque vous vérifiez la couche BGP, vous vérifiez que la route est présente et active et, plus important encore, vous vous assurez que le saut suivant est le LSP. Il est inutile de vérifier la couche BGP si le LSP n’est pas établi, car BGP utilise le LSP MPLS pour transférer le trafic. Si le réseau ne fonctionne pas au niveau de la couche BGP, le LSP ne fonctionne pas comme configuré.
Figure 4 illustre le réseau MPLS utilisé dans cette rubrique.
Le réseau illustré ci-dessous Figure 4 est une configuration entièrement maillée dans laquelle chaque interface directement connectée peut recevoir et envoyer des paquets à toutes les autres interfaces similaires. Le LSP de ce réseau est configuré pour fonctionner depuis le routeur entrant R1, via le routeur de transit R3, jusqu’au routeur de sortie R6. En outre, un LSP inverse est configuré pour s’exécuter de R6 A R3 à R1, créant ainsi un trafic bidirectionnel.
La croix illustrée indique Figure 4 les endroits où BGP n’est pas utilisé pour transférer le trafic via le LSP. Les raisons possibles pour lesquelles le LSP ne fonctionne pas correctement sont que l’adresse IP de destination du LSP n’est pas égale au saut suivant BGP ou que BGP n’est pas configuré correctement.
Pour vérifier la couche BGP, procédez comme suit :
- Vérifiez que le trafic BGP utilise le LSP
- Vérifier les sessions BGP
- Vérifier la configuration BGP
- Examiner les routes BGP
- Vérifier les routes BGP reçues
- Prendre les mesures appropriées pour résoudre le problème de réseau
- Vérifiez que le trafic BGP utilise à nouveau le LSP
Vérifiez que le trafic BGP utilise le LSP
But
À ce niveau du modèle de dépannage, BGP et le LSP peuvent être actifs, mais le trafic BGP peut ne pas utiliser le LSP pour transférer le trafic.
Action
Pour vérifier que le trafic BGP utilise le LSP, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande (CLI) Junos OS à partir du routeur entrant :
user@host> traceroute hostname
Exemple de sortie
nom_commande
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
Sens
L’exemple de sortie montre que le trafic BGP n’utilise pas le LSP, par conséquent, les étiquettes MPLS n’apparaissent pas dans la sortie. Au lieu d’utiliser le LSP, le trafic BGP utilise le protocole IGP (Interior Gateway Protocol) pour atteindre l’adresse de sortie du LSP next-hop BGP pour R6 et R1. La valeur par défaut de Junos OS est d’utiliser des LSP pour le trafic BGP lorsque le saut suivant BGP est égal à l’adresse de sortie LSP.
Vérifier les sessions BGP
But
Affichez des informations récapitulatives sur BGP et ses voisins pour déterminer si les routes sont reçues des homologues dans le système autonome (AS). Lorsqu’une session BGP est établie, les homologues échangent des messages de mise à jour.
Action
Pour vérifier que les sessions BGP sont actives, entrez la commande suivante en mode opérationnel CLI Junos OS à partir du routeur entrant :
user@host> show bgp summary
Sortie de l’échantillon 1
nom_commande
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
Sortie de l’échantillon 2
nom_commande
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
Sens
L’exemple de sortie 1 montre qu’un homologue (routeur de sortie 10.0.0.6 ) n’est pas établi, comme indiqué par le Down Peers: 1 champ. La dernière colonne (State|#Active/Received/Damped) indique que l’homologue 10.0.0.6 est actif, ce qui indique qu’il n’est pas établi. Tous les autres homologues sont établis comme indiqué par le nombre de routes actives, reçues et amorties. Par exemple, 0/0/0 pour homologue 10.0.0.2 indique qu’aucune route BGP n’était active ou reçue dans la table de routage et qu’aucune route BGP n’a été amortie ; 1/1/0 for peer 10.1.36.2 indique qu’une route BGP était active et reçue dans la table de routage, et qu’aucune route BGP n’a été amortie.
Si la sortie de la commande d’un routeur entrant indique qu’un voisin est en panne, vérifiez la show bgp summary configuration BGP. Pour plus d’informations sur la vérification de la configuration BGP, reportez-vous à la section Vérification de la configuration BGP.
L’exemple de sortie 2 montre la sortie du routeur entrant R1 après que les configurations BGP ont été activées R1 et R6 ont été corrigées dans Prendre des mesures appropriées pour résoudre le problème réseau. Tous les homologues BGP sont établis et une route est active et reçue. Aucune route BGP n’a été amortie.
Si la sortie de la show bgp summary commande indique qu’un voisin est actif mais que les paquets ne sont pas transférés, recherchez les routes reçues du routeur de sortie. Pour plus d’informations sur la vérification des routes reçues sur le routeur de sortie, consultez Vérifier les routes BGP reçues.
Vérifier la configuration BGP
But
Pour que BGP s’exécute sur le routeur, vous devez définir le numéro AS local, configurer au moins un groupe et inclure des informations sur au moins un homologue du groupe (l’adresse IP et le numéro AS de l’homologue). Lorsque BGP fait partie d’un réseau MPLS, vous devez vous assurer que le LSP est configuré avec une adresse IP de destination égale au prochain saut BGP pour que les routes BGP soient installées avec le LSP comme prochain tronçon pour ces routes.
Action
Pour vérifier la configuration BGP, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS :
user@host> show configuration
Sortie de l’échantillon 1
nom_commande
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;
}
}
}
Sortie de l’échantillon 2
nom_commande
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;
}
}
}
Sens
L’exemple de sortie montre les configurations BGP sur le routeur entrant R1 et le routeur de sortie R6. Les deux configurations affichent l’AS local (65432), un groupe (internal) et six homologues configurés. Le protocole de passerelle intérieure sous-jacent est IS-IS, et les interfaces correspondantes sont configurées pour exécuter IS-IS.
Dans cette configuration, le RID est configuré manuellement pour éviter tout problème de RID en double, et toutes les interfaces configurées avec BGP incluent l’instruction family inet au niveau de la hiérarchie [edit interfaces type-fpc/pic/port unit logical-unit-number].
L’exemple de sortie pour le routeur entrant R1et le routeur de sortie R6 montre que la configuration du protocole BGP ne contient pas l’instruction local-address pour le groupe interne. Lorsque local-address l’instruction est configurée, les paquets BGP sont transférés à partir de l’adresse de l’interface de bouclage (lo0) du routeur local, qui est l’adresse vers laquelle les homologues BGP sont appairés. Si local-address l’instruction n’est pas configurée, les paquets BGP sont transférés à partir de l’adresse de l’interface sortante, qui ne correspond pas à l’adresse vers laquelle les homologues BGP sont appairés, et BGP n’apparaît pas.
Sur le routeur entrant, l’adresse IP (10.0.0.1) dans l’instruction local-address doit être la même que l’adresse configurée pour le LSP sur le routeur de sortie (R6) dans l’instruction to au niveau de la hiérarchie [edit protocols mpls label-switched-path lsp-path-name]. BGP utilise cette adresse, qui est identique à l’adresse LSP, pour transférer le trafic BGP via le LSP.
De plus, la configuration BGP sur R1 inclut deux adresses IP pour R6, une adresse d’interface (10.1.36.2) et une adresse (10.0.0.6) d’interface de bouclage (lo0), ce qui fait que l’adresse de destination du LSP (10.0.0.6) ne correspond pas à l’adresse de saut suivant BGP (10.1.36.2). La configuration BGP activée R6 inclut également deux adresses IP pour R1, une adresse d’interface (10.1.13.1) et une adresse d’interface de bouclage (lo0), ce qui fait que l’adresse de destination du LSP inverse (10.0.0.1) ne correspond pas à l’adresse de saut suivant BGP (10.1.13.1).
Dans ce cas, étant donné que l’instruction est manquante dans les configurations BGP des deux routeurs et que l’adresse de destination du LSP ne correspond pas à l’adresse de saut suivant BGP, BGP n’utilise local-address pas le LSP pour transférer le trafic.
Examiner les routes BGP
But
Vous pouvez examiner le processus de sélection du chemin BGP pour déterminer le chemin unique et actif lorsque BGP reçoit plusieurs chemins vers la même destination. Dans cette étape, nous examinons le LSP R6-to-R1 inverse , ce qui rend R6 le routeur entrant pour ce LSP.
Action
Pour examiner les routes BGP et la sélection de route, entrez la commande suivante en mode opérationnel de l’interface de ligne de commande Junos OS :
user@host> show route destination-prefix detail
Sortie de l’échantillon 1
nom_commande
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
Sortie de l’échantillon 2
nom_commande
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
Sens
L’exemple de sortie 1 montre que le saut suivant BGP (10.1.13.1) n’est pas égal à l’adresse de destination LSP (10.0.0.1) dans l’instruction to au niveau de la hiérarchie [edit protocols mpls label-switched-path label-switched-path-name] lorsque la configuration BGP de R6 et R1 est incorrecte.
L’exemple de sortie 2, pris après correction des configurations sur R1 et R6, montre que le saut suivant BGP (10.0.0.1) et l’adresse de destination LSP (10.0.0.1) sont identiques, ce qui indique que BGP peut utiliser le LSP pour transférer le trafic BGP.
Vérifier les routes BGP reçues
But
Affichez les informations de routage reçues sur le routeur , le routeur R6entrant pour le LSP R6-to-R1 inverse .
Action
Pour vérifier qu’une route BGP particulière est reçue sur le routeur de sortie, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route receive protocol bgp neighbor-address
Sortie de l’échantillon 1
nom_commande
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)
Sortie de l’échantillon 2
nom_commande
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)
Sens
L’exemple de sortie 1 montre que le routeur entrant R6 (LSP inverseR6-to-R1) ne reçoit aucune route BGP dans la inet.0 table de routage lorsque les configurations BGP de R1 et R6 sont incorrectes.
L’exemple de sortie 2 montre une route BGP installée dans la inet.0 table de routage après que les configurations BGP ont été activées R1 et R6 corrigées à l’aide de l’option Prendre des mesures appropriées pour résoudre le problème réseau.
Prendre les mesures appropriées pour résoudre le problème de réseau
Problème
Description
L’action appropriée dépend du type de problème que vous avez isolé. Dans cet exemple, une route statique configurée le R2 est supprimée du niveau hiérarchique [routing-options]. D’autres mesures appropriées peuvent inclure les suivantes :
Solution
Vérifiez la configuration du routeur local et modifiez-la si nécessaire.
Dépannez le routeur intermédiaire.
Vérifiez la configuration de l’hôte distant et modifiez-la si nécessaire.
Dépanner les protocoles de routage.
Identifiez d’autres causes possibles.
Pour résoudre le problème dans cet exemple, entrez les commandes CLI Junos OS suivantes :
[edit]
user@R2# delete routing-options static route destination-prefix
user@R2# commit and-quit
user@R2# show route destination-prefix
Exemple de sortie
[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
Sens
L’exemple de sortie montre la route statique supprimée de la hiérarchie [routing-options] et la nouvelle configuration validée. La sortie de la commande affiche désormais la show route route BGP comme route préférée, comme indiqué par l’astérisque (*).
Vérifiez que le trafic BGP utilise à nouveau le LSP
But
Après avoir pris les mesures appropriées pour corriger l’erreur, le LSP doit être vérifié à nouveau pour confirmer que le trafic BGP l’utilise et que le problème dans la couche BGP a été résolu.
Action
Pour vérifier que le trafic BGP utilise le LSP, entrez la commande suivante en mode opérationnel CLI Junos OS à partir du routeur entrant :
user@host> traceroute hostname
Exemple de sortie
nom_commande
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
Sens
L’exemple de sortie montre que des étiquettes MPLS sont utilisées pour transférer des paquets via le LSP. La sortie comprend une valeur d’étiquette (MPLS Label=100016), la valeur de durée de vie (TTL=1) et la valeur du bit de pile (S=1).
Ce MPLS Label champ est utilisé pour identifier le paquet d’un LSP particulier. Il s’agit d’un champ de 20 bits, avec une valeur maximale de (2^^20-1), soit environ 1 000 000.
La valeur de durée de vie (TTL) contient une limite sur le nombre de sauts que ce paquet MPLS peut parcourir à travers le réseau (1). Il est décrémenté à chaque saut, et si la valeur TTL tombe en dessous de un, le paquet est rejeté.
La valeur du bit de pile inférieure (S=1) indique qu’il s’agit de la dernière étiquette de la pile et qu’une étiquette est associée à ce paquet MPLS. L’implémentation MPLS dans Junos OS prend en charge une profondeur d’empilage de 3 sur les routeurs de la série M et jusqu’à 5 sur les plates-formes de routage de la série T. Pour plus d’informations sur l’empilage d’étiquettes MPLS, reportez-vous à la RFC 3032, Codage d’empilement d’étiquettes MPLS.
Les étiquettes MPLS apparaissent dans l’exemple de sortie, car la traceroute commande est émise vers une destination BGP où le tronçon BGP suivant pour cette route est l’adresse de sortie LSP. Par défaut, Junos OS utilise des LSP pour le trafic BGP lorsque le saut suivant BGP est égal à l’adresse de sortie LSP.
Si le saut suivant BGP n’est pas égal à l’adresse de sortie LSP, le trafic BGP n’utilise pas le LSP et, par conséquent, les étiquettes MPLS n’apparaissent pas dans la sortie de la traceroute commande, comme indiqué dans l’exemple de sortie dans Vérifier les sessions BGP.
Afficher les paquets BGP envoyés ou reçus
Action
Pour configurer le suivi des paquets de protocole BGP envoyés ou reçus, procédez comme suit :
En mode configuration, accédez au niveau hiérarchique suivant :
[edit] user@host# edit protocol bgp traceoptions
Configurez l’indicateur pour afficher les informations sur les paquets envoyés, reçus ou envoyés et reçus :
[edit protocols bgp traceoptions] user@host# set flag update sendOu
[edit protocols bgp traceoptions] user@host# set flag update receive
Ou
[edit protocols bgp traceoptions] user@host# set flag update
Vérifiez la configuration :
user@host# show
Par exemple :
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send;
Ou
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update receive;
Ou
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send receive;
Validez la configuration :
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés :
user@host# run show log filenamePar exemple :
[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...]
Examiner les itinéraires dans la table de transfert
But
Lorsque vous rencontrez des problèmes, tels que des problèmes de connectivité, vous devrez peut-être examiner les itinéraires dans la table de transfert pour vérifier que le processus du protocole de routage a relayé les informations correctes dans la table de transfert.
Action
Pour afficher l’ensemble des routes installées dans la table de transfert, entrez la commande suivante en mode opérationnel CLI Junos OS :
user@host> show route forwarding-table
Exemple de sortie
nom_commande
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...]
Sens
L’exemple de sortie montre les préfixes de couche réseau et leurs sauts suivants installés dans la table de transfert. La sortie inclut les mêmes informations de saut suivant que dans la commande show route detail (l’adresse du saut suivant et le nom de l’interface). Les informations supplémentaires incluent le type de destination, le type de saut suivant, le nombre de références à ce saut suivant et un index dans une base de données interne de saut suivant. (La base de données interne contient des informations supplémentaires utilisées par le moteur de transfert de paquets pour assurer une encapsulation correcte des paquets envoyés à une interface. Cette base de données n’est pas accessible à l’utilisateur.
Pour plus d’informations sur la signification des différents champs d’indicateurs et de types, reportez-vous au Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.
Exemple : Remplacement de la stratégie de routage BGP par défaut sur PTX Series Routeurs de transport de paquets
Cet exemple montre comment remplacer le stratégie de routage par défaut sur les routeurs de transport de paquets, tels que le PTX Series Routeurs de transport de paquets.
Conditions préalables
Cet exemple nécessite Junos OS version 12.1 ou ultérieure.
Présentation
Par défaut, les routeurs PTX Series n’installent pas de routes BGP dans la table de transfert.
Pour les routeurs PTX Series, la configuration de la from protocols bgp condition avec l’action then accept n’a pas le résultat habituel qu’elle a sur les autres périphériques de routage Junos OS. Avec la stratégie de routage suivante sur les routeurs PTX Series, les routes BGP ne sont pas installées dans la table de transfert.
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
Aucune route BGP n’est installée dans la table de transfert. Il s’agit du comportement attendu.
Cet exemple montre comment utiliser l’action then install-to-fib pour remplacer efficacement la stratégie de routage BGP par défaut.
Configuration
- Configuration rapide de l’interface de ligne de commande
- Installation des routes BGP sélectionnées dans la table de transfert
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.
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 des routes BGP sélectionnées dans la table de transfert
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.
Pour installer les routes BGP sélectionnées dans la table de transfert :
Configurez une liste de préfixes à installer dans la table de transfert.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Configurez la stratégie de routage en appliquant la liste de préfixes comme condition.
[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
Appliquez la stratégie de routage à la table de transfert.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant les commandes show policy-options et show routing-options. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
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;
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérification de l’installation de l’itinéraire sélectionné dans la table de transfert
But
Assurez-vous que la stratégie configurée remplace la stratégie par défaut.
Action
À partir du mode opérationnel, entrez la show route forwarding-table commande.
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
Sens
Cette sortie montre que la route vers 66.0.0.1/32 est installée dans la table de transfert.
Consigner les événements de transition d’état BGP
But
Les transitions d’état du Border Gateway Protocol (BGP) indiquent un problème réseau et doivent être consignées et étudiées.
Action
Pour consigner les événements de transition d’état BGP dans le journal système, procédez comme suit :
En mode configuration, accédez au niveau hiérarchique suivant :
[edit] user@host# edit protocol bgpConfigurez le journal système :
user@host# set log-updown
Vérifiez la configuration :
user@host# show
Validez la configuration :
user@host# commit
Sens
Les messages de journal des événements de transition d’état BGP sont suffisants pour diagnostiquer la plupart des problèmes de session BGP. Tableau 3 répertorie et décrit les six états d’une session BGP.
État du BGP |
Description |
|---|---|
Idle |
Il s’agit du premier état d’une connexion. BGP attend un événement de démarrage initié par un administrateur. L’événement de démarrage peut être l’établissement d’une session BGP via la configuration du routeur ou la réinitialisation d’une session existante. Après l’événement start, BGP initialise ses ressources, réinitialise un minuteur de connexion-nouvelle tentative, lance une connexion de transport TCP et commence à écouter les connexions initiées par des homologues distants. BGP passe alors à l’état Connect . En cas d’erreur, BGP revient à l’état Idle . |
Connect |
BGP attend la fin de la connexion au protocole de transport. Si la connexion de transport TCP réussit, l’état passe à OpenSent. Si la connexion de transport échoue, l’état passe à Active. Si le temporisateur de connexion-nouvelle tentative a expiré, l’état reste dans l’état Connect , le minuteur est réinitialisé et une connexion de transport est initiée. Pour tout autre événement, l’état revient à Idle. |
Active |
BGP tente d’acquérir un homologue en initiant une connexion au protocole de transport. En cas de succès, l’état passe à OpenSent. Si le temporisateur de connexion-nouvelle tentative expire, BGP redémarre le minuteur de connexion et revient à l’état Connect . BGP continue d’écouter une connexion qui peut être initiée à partir d’un autre homologue. L’état peut revenir en Idle arrière en cas d’autres événements, tels qu’un événement d’arrêt. En général, une bascule d’état voisin entre Connect et Active indique qu’il y a un problème avec la connexion de transport TCP. Un tel problème peut être causé par de nombreuses retransmissions TCP ou par l’incapacité d’un voisin à atteindre l’adresse IP de son homologue. |
OpenSent |
BGP reçoit un message ouvert de son homologue. Dans l’état, BGP compare le numéro de son système autonome (AS) avec le numéro AS de son homologue et reconnaît si l’homologue OpenSent appartient au même AS (BGP interne) ou à un autre AS (BGP externe). L’exactitude du message ouvert est vérifiée. En cas d’erreurs, telles qu’un numéro de version incorrect d’un AS inacceptable, BGP envoie un message de notification d’erreur et retourne à Idle. Pour toute autre erreur, telle que l’expiration du minuteur de mise en attente ou un événement d’arrêt, BGP envoie un message de notification avec le code d’erreur correspondant et revient à l’état Idle . S’il n’y a pas d’erreurs, BGP envoie des messages keepalive et réinitialise le minuteur keepalive. Dans cet état, le temps d’attente est négocié. Si le temps de maintien est égal à 0, les temporisateurs de maintien et de maintien en vie ne sont pas redémarrés. Lorsqu’une déconnexion de transport TCP est détectée, l’état revient à Active. |
OpenConfirm |
BGP attend un message keepalive ou de notification. Si un keepalive est reçu, l’état devient Established, et la négociation de voisinage est terminée. Si le système reçoit un message de mise à jour ou de keepalive, il redémarre le minuteur de mise en attente (en supposant que le temps de mise en attente négocié n’est pas égal à 0). Si un message de notification est reçu, l’état revient Idle. Le système envoie des messages keepalive périodiques au débit défini par le minuteur keepalive. Dans le cas d’une notification de déconnexion du transport ou en réponse à un événement d’arrêt, l’état revient à Idle. En réponse à d’autres événements, le système envoie un message de notification avec un code d’erreur FSM (Finite State Machine) et revient à Idle. |
Established |
Il s’agit de l’état final de la négociation de voisinage. Dans cet état, BGP échange des accusés de réception de mise à jour avec ses homologues et le minuteur de mise en attente est redémarré à la réception d’un message de mise à jour ou de rétention lorsqu’il n’est pas défini sur zéro. Si le système reçoit un message de notification, l’état revient à Idle. Les messages de mise à jour sont vérifiés à la recherche d’erreurs, telles que des attributs manquants, des attributs en double, etc. Si des erreurs sont détectées, une notification est envoyée à l’homologue et l’état revient à Idle. BGP revient à l’expiration du minuteur de mise en attente, à la réception d’une notification de déconnexion du protocole de transport, à la réception d’un événement d’arrêt Idle ou à tout autre événement. |
Pour plus d’informations détaillées sur les paquets de protocole BGP, configurez le suivi spécifique au BGP. Pour plus d’informations, reportez-vous à la section Liste de contrôle des conditions d’erreur de suivi .
Configurer les options spécifiques au protocole BGP
But
Lorsque des événements ou des problèmes inattendus se produisent, ou si vous souhaitez diagnostiquer des problèmes d’établissement BGP, vous pouvez afficher des informations plus détaillées en configurant des options spécifiques à BGP. Vous pouvez également configurer le suivi pour un pair BGP ou un groupe d’homologues spécifique. Pour plus d’informations, reportez-vous au Guide de configuration des principes de base du système Junos.
- Afficher des informations détaillées sur le protocole BGP
- Diagnostiquer les problèmes d’établissement de session BGP
Afficher des informations détaillées sur le protocole BGP
Action
Pour afficher les informations du protocole BGP en détail, procédez comme suit :
En mode configuration, accédez au niveau hiérarchique suivant :
[edit] user@host# edit protocol bgp traceoptions
Configurez l’indicateur pour qu’il affiche des messages détaillés sur le protocole BGP :
[edit protocols bgp traceoptions] user@host# set flag update detail
Vérifiez la configuration :
user@host# show
Par exemple :
[edit protocols bgp traceoptions] user@host# show flag update detail;
Validez la configuration :
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés :
user@host# run show log filenamePar exemple :
[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...]
Sens
Tableau 4 répertorie les indicateurs de traçage spécifiques à BGP et présente des exemples de sortie pour certains indicateurs. Vous pouvez également configurer le suivi pour un pair BGP ou un groupe d’homologues spécifique. Pour plus d’informations, reportez-vous au Guide de configuration des principes de base du système Junos.
Drapeaux de traçage |
Description |
Exemple de sortie |
|---|---|---|
aspath |
Opérations sur les expressions régulières de chemin AS |
Non disponible. |
damping |
Opérations d’amortissement |
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 |
Messages persistants BGP |
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 |
Paquets ouverts BGP |
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 |
Tous les paquets de protocole BGP |
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 |
Mettre à jour les paquets |
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) |
Diagnostiquer les problèmes d’établissement de session BGP
But
Pour tracer les problèmes d’établissement de session BGP.
Action
Pour tracer les problèmes d’établissement de session BGP, procédez comme suit :
En mode configuration, accédez au niveau hiérarchique suivant :
[edit] user@host# edit protocol bgpConfigurez les messages ouverts BGP :
[edit protocols bgp] user@host# set traceoptions flag open detail
Vérifiez la configuration :
user@host# show
Par exemple :
[edit protocols bgp] user@host# show traceoptions { file bgplog size 10k files 10; flag open detail; }Validez la configuration :
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés :
user@host#run show log filenamePar exemple :
[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...]
Configurer les options spécifiques à IS-IS
But
Lorsque des événements ou des problèmes inattendus se produisent, ou si vous souhaitez diagnostiquer des problèmes d’établissement de contiguïté IS-IS, vous pouvez afficher des informations plus détaillées en configurant des options spécifiques à IS-IS.
Pour configurer les options IS-IS, procédez comme suit :
- Affichage d’informations détaillées sur le protocole IS-IS
- Affichage des paquets de protocole IS-IS envoyés ou reçus
- Analyse détaillée des PDU à état de liaison IS-IS
Affichage d’informations détaillées sur le protocole IS-IS
Action
Pour tracer les messages IS-IS en détail, procédez comme suit :
Configurez l’indicateur pour afficher des messages détaillés sur le protocole IS-IS.
[edit protocols isis traceoptions] user@host# set flag hello detail
Vérifiez la configuration.
user@host# show
Par exemple :
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello detail;
Validez la configuration.
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés.
user@host# run show log filenamePar exemple :
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
Sens
Tableau 5 répertorie les indicateurs de suivi qui peuvent être configurés spécifiquement pour IS-IS et présente des exemples de sortie pour certains indicateurs.
Drapeaux de traçage |
Description |
Exemple de sortie |
|---|---|---|
csn |
Numéro de séquence complet 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 Avec l’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 |
Bonjour paquet |
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 |
PDU à état de liaison (LSP) |
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 |
Paquets de génération de PDU à état de liaison |
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 |
Tous les paquets de protocole IS-IS |
Non disponible. |
psn |
Paquets PDU à numéro de séquence partiel (PSNP) |
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 |
Calculs de Shortest-path-first (SPF) |
Nov 28 20:44:01 Scheduling SPF for L1: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L1: ReconfigNov 28 20:44:01 Scheduling SPF for L2: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L2: ReconfigNov 28 20:44:02 Running L1 SPFNov 28 20:44:02 L1 SPF initialization complete: 0.000099s cumulative timeNov 28 20:44:02 L1 SPF primary processing complete: 0.000303s cumulative timeNov 28 20:44:02 L1 SPF result postprocessing complete: 0.000497s cumulative timeNov 28 20:44:02 L1 SPF RIB postprocessing complete: 0.000626s cumulative timeNov 28 20:44:02 L1 SPF routing table postprocessing complete: 0.000736s cumulative time |
Voir également
Affichage des paquets de protocole IS-IS envoyés ou reçus
Pour configurer le suivi uniquement pour les paquets de protocole IS-IS envoyés ou reçus, procédez comme suit :
Configurez l’indicateur pour afficher les paquets envoyés, reçus ou les paquets envoyés et reçus.
[edit protocols isis traceoptions] user@host# set flag hello send
Ou
[edit protocols isis traceoptions] user@host# set flag hello receive
Ou
[edit protocols isis traceoptions] user@host# set flag hello
Vérifiez la configuration.
user@host# show
Par exemple :
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send;
Ou
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello receive;
Ou
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send receive;
Validez la configuration.
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés.
user@host# run show log filenamePar exemple :
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
Voir également
Analyse détaillée des PDU à état de liaison IS-IS
Pour analyser en détail les PDU à état de liaison IS-IS, procédez comme suit :
Configurez les messages ouverts IS-IS.
[edit protocols isis traceoptions] user@host# set flag lsp detail
Vérifiez la configuration.
user@host# show
Par exemple :
[edit protocols isis traceoptions] user@host# show file isislog size 5m world-readable; flag error; flag lsp detail;
Validez la configuration.
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés.
user@host# run show log filenamePar exemple :
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
Voir également
Configurer les options spécifiques à OSPF
But
Lorsque des événements ou des problèmes inattendus se produisent, ou si vous souhaitez diagnostiquer des problèmes d’établissement de voisinage OSPF, vous pouvez afficher des informations plus détaillées en configurant des options spécifiques à OSPF.
Pour configurer les options OSPF, procédez comme suit :
- Diagnostiquer les problèmes d’établissement de session OSPF
- Analyser en détail les paquets d’annonce d’état de lien OSPF
Diagnostiquer les problèmes d’établissement de session OSPF
Action
Pour tracer les messages OSPF en détail, procédez comme suit :
En mode configuration, accédez au niveau hiérarchique suivant :
[edit] user@host# edit protocols ospf traceoptions
Configurez les messages Hello OSPF :
[edit protocols ospf traceoptions] user@host# set flag hello detail
Vérifiez la configuration :
user@host# show
Par exemple :
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail;
Validez la configuration :
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés :
user@host# run show log filenamePar exemple :
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
Sens
Tableau 6 répertorie les indicateurs de suivi OSPF et présente des exemples de sortie pour certains indicateurs.
Drapeaux de traçage |
Description |
Exemple de sortie |
|---|---|---|
database-descripttion |
Tous les paquets de description de base de données |
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 |
Paquets ayant généré une erreur OSPF |
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 |
Transitions d’état OSPF |
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 |
Paquets d’inondation à état de lien |
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 |
Bonjour les paquets |
Dec 2 15:57:25 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/1/0.0) Dec 2 15:57:25 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:25 checksum 0xe43f, authtype 0 Dec 2 15:57:25 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:25 dead_ivl 40, DR 10.218.0.1, BDR 0.0.0.0 Dec 2 15:57:25 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:57:25 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0 Dec 2 15:57:25 checksum 0x99b8, authtype 0 Dec 2 15:57:25 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:25 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 15:57:27 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/2/0.0) Dec 2 15:57:27 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:27 checksum 0xe4a5, authtype 0 Dec 2 15:57:27 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:27 dead_ivl 40, DR 10.116.0.1, BDR 0.0.0.0 Dec 2 15:57:28 OSPF rcvd Hello 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 15:57:28 Version 2, length 48, ID 10.10.134.11, area 0.0.0.0 Dec 2 15:57:28 checksum 0x99b9, authtype 0 Dec 2 15:57:28 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:28 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 |
lsa-ack |
Paquets d’accusé de réception d’état de lien |
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 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 .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 |
Paquets de demande d’état de lien |
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 |
Paquets de mise à jour de l’état des liens |
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 |
Tous les paquets OSPF |
Non disponible. |
packet-dump |
Vider le contenu des types de paquets sélectionnés |
Non disponible. |
spf |
Calculs SPF |
Dec 2 16:08:03 OSPF full SPF refresh scheduled Dec 2 16:08:04 OSPF SPF start, area 1.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000525s Dec 2 16:08:04 Stub elapsed time 0.000263s Dec 2 16:08:04 OSPF SPF start, area 2.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000253s Dec 2 16:08:04 Stub elapsed time 0.000249s Dec 2 16:08:04 OSPF SPF start, area 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 OSPF add LSA Router 10.10.134.11 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/0.0 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.10.134.12 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0 |
Analyser en détail les paquets d’annonce d’état de lien OSPF
Action
Pour analyser en détail les paquets d’annonce d’état de lien OSPF, procédez comme suit :
En mode configuration, accédez au niveau hiérarchique suivant :
[edit] user@host# edit protocols ospf traceoptions
Configurez les packages d’état de lien OSPF :
[edit protocols ospf traceoptions] user@host# set flag lsa-update detail
Vérifiez la configuration :
user@host# show
Par exemple :
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail; flag lsa-update detail;
Validez la configuration :
user@host# commit
Affichez le contenu du fichier contenant les messages détaillés :
user@host# run show log filenamePar exemple :
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