SUR CETTE PAGE
Dépannage des sessions BGP
Checklist pour la vérification du protocole BGP et des pairs
Objet
Le Tableau 1 fournit des liens et des commandes permettant de vérifier si le Border Gateway Protocol (BGP) est correctement configuré sur un routeur Juniper Networks de votre réseau, si les sessions internes du Border Gateway Protocol (IBGP) et extérieures 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.
Mesures à prendre
|
Tâches |
Commande ou action |
|---|---|
| Vérification des homologues BGP | |
|
|
|
|
|
|
|
|
|
|
|
|
| Examen des routes BGP et sélection des routes | |
|
|
|
|
|
|
|
|
|
|
|
|
| Examiner les routes dans la table de transfert |
|
Vérification des homologues BGP
Objet
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.
La figure 1 illustre un exemple de topologie de réseau BGP utilisé dans cette rubrique.
du réseau BGP
Le réseau se compose de deux A directement connectés, composé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 de bouclage (lo0) via IBGP. L’AS 65001 exécute OSPF et l’AS 65002 exécute l’IS-IS en tant qu’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 une liaison EBGP vers l’AS 65002 (R2 et R4) sur laquelle 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. En outre, R1 et R5 injectent des valeurs de discriminant de sortie multiples (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. Les routes apprises via IBGP ne sont donc pas distribuées à d’autres voisins internes. Par exemple, lorsque R3 apprend une route à partir de R2, R3 ne distribue pas cette route à R6 car la route est apprise via IBGP, doit donc R6 avoir une connexion BGP directe à R2 pour 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 à d’autres routeurs IBGP dans son propre AS.
Du point de vue de l’AS 65002, les sessions suivantes devraient être terminées :
-
Des sessions IBGP doivent être établies entre les quatre routeurs de l’AS 65002.
-
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érification du protocole BGP sur un routeur interne
- Vérification du protocole BGP sur un routeur de bordure
- Vérification des routes BGP annoncées
- Vérifiez qu’une route BGP particulière est reçue sur votre routeur
Vérification du protocole BGP sur un routeur interne
Objet
Pour vérifier la configuration BGP d’un routeur interne.
Mesures à prendre
Pour vérifier la configuration BGP d’un routeur interne, entrez la commande CLI Junos OS suivante :
user@host> show configuration
L’exemple de sortie suivant concerne 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;
}
}
Signification
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 R6 de la hiérarchie [ groupprotocols bgp group]. 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 Intermediate System-to-Intermediate System (IS-IS), et les interfaces pertinentes sont configurées pour exécuter IS-IS.
Notez que dans cette configuration, l’ID du routeur est configuré manuellement pour éviter tout problème d’ID de routeur en double.
Vérification du protocole BGP sur un routeur de bordure
Objet
Pour vérifier la configuration BGP d’un routeur de bordure.
Mesures à prendre
Pour vérifier la configuration BGP d’un routeur de bordure, entrez la commande de mode opérationnel Junos OS CLI suivante :
user@host> show configuration
Exemple de sortie
nom_commande
L’exemple de sortie suivant concerne une configuration BGP sur deux routeurs de bordure, R2 et R4 à partir d’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;
}
}
}
Signification
L’exemple de sortie montre une configuration BGP de base sur les routeurs R2 de bordure et R4. L’AS (65002) est inclus dans la hiérarchie [routing-options] des deux routeurs. Chaque routeur possède deux groupes inclus au niveau de la hiérarchie [protocols bgp group group]. Les homologues externes sont inclus dans le groupe externe, soit toR1 , soit toR5, 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 next-hop-self est incluse pour éviter tout problème d’accessibilité du prochain saut BGP.
Vérification des routes BGP annoncées
Objet
Vous pouvez déterminer si une route particulière que vous avez configurée est annoncée à un voisin.
Mesures à prendre
Pour vérifier les informations de routage telles qu’elles ont été préparées pour être publiées sur le voisin BGP spécifié, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
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
Signification
L’exemple de sortie montre les routes BGP annoncées à partir de R2 son voisin, 10.0.0.4 (R4). Sur un total de 22 routes 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 l’état hold-down avant d’être déclarées actives, et les routes rejetées par une politique de routage peuvent être placées dans l’état hidden . Les informations affichées reflètent les routes que la table de routage a exportées vers le protocole de routage BGP.
Vérifiez qu’une route BGP particulière est reçue sur votre routeur
Objet
Affichez les informations de routage telles qu’elles sont reçues par un voisin BGP particulier et annoncées par le routeur local au voisin.
Mesures à prendre
Pour vérifier qu’une route BGP particulière est reçue sur votre routeur, entrez la commande Junos OS CLI mode opérationnel suivante :
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)
Signification
L’exemple de sortie montre quatre routes BGP de R2 et deux de R4. Sur les quatre routes à partir de R2, seules deux sont actives dans la table de routage, comme indiqué par l’astérisque (*), tandis que les deux routes reçues à partir de R4 sont actives dans la table de routage. Toutes les routes BGP passaient par l’AS 65001.
Examen des routes BGP et sélection des routes
Objet
Vous pouvez examiner le processus de sélection du chemin BGP pour déterminer le chemin actif unique lorsque le BGP reçoit plusieurs routes vers le même préfixe de destination.
du réseau BGP
Le réseau de la Figure 2 montre que R1 et R5 annonce les mêmes routes agrégées vers R2 et R4, ce qui entraîne R2 et R4 reçoit deux routes vers le même préfixe de destination. Le processus de sélection de route sur 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 que le routeur n’installe une route BGP, il doit s’assurer que l’attribut BGP next-hop est accessible. Si le saut 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 route BGP a une préférence par défaut de 170.
-
Les itinéraires sont comparés selon les préférences locales. L’itinéraire avec la préférence locale la plus élevée est préféré. Par exemple, voir 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’une des routes est annoncée à 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, consultez Examiner la sélection de route du discriminateur de sortie multiple.
-
La route est évaluée selon qu’elle est apprise par EBGP ou IBGP. Les routes apprises EBGP sont préférées aux routes apprises IBGP. Pour obtenir un exemple, consultez Examiner la sélection EBGP par rapport à IBGP
-
Si la route a été apprise à partir d’IBGP, la route avec le coût IGP le plus bas est préférée. Pour obtenir un exemple, voir Examiner la sélection des coûts IGP. Le saut physique suivant vers l’homologue IBGP est installé selon les trois règles suivantes :
-
-
Une fois que BGP a examiné les
inet.0tables de routage andinet.3, le saut physique suivant de la route avec la préférence la plus faible est utilisé.
-
-
-
Si les valeurs de préférence dans les tables de routage et de
inet.0routageinet.3sont à égalité, le saut physique suivant de la route dans lainet.3table de routage est utilisé.
-
-
-
Lorsqu’une liaison de préférence existe dans la même table de routage, le saut physique suivant de la route avec plus de chemins est installé.
-
-
-
L’attribut de liste de cluster de réflexion de route est évalué. La liste des clusters de longueur la plus courte est préférable. 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é. La route à partir de l’homologue avec l’ID de routeur le plus bas est préférée (généralement l’adresse de bouclage).
-
La valeur de l’adresse homologue est examinée. L’homologue avec l’adresse IP homologue la plus basse est préféré.
Pour déterminer le chemin actif unique lorsque BGP reçoit plusieurs routes vers le même préfixe de destination, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
user@host> show route
destination-prefix
< detail >
Les étapes suivantes illustrent le motif inactif affiché lorsque BGP reçoit plusieurs routes vers le même préfixe de destination et qu’une route est sélectionnée comme chemin actif unique :
- Examinez la sélection des préférences locales
- Examinez la sélection de la route du discriminateur de sortie multiple
- Examinez la sélection EBGP par rapport à IBGP
- Examinez la sélection des coûts de l’IGP
Examinez la sélection des préférences locales
Objet
Examiner une route pour déterminer si la préférence locale est le critère de sélection pour le chemin actif unique.
Mesures à prendre
Pour examiner une route afin de déterminer si la préférence locale est le critère de sélection du chemin actif unique, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
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
Signification
L’exemple de sortie montre que a R4 reçu deux instances de la 100.100.1.0 route : une de 10.0.0.2 (R2) et une de 10.1.45.2 (). R4 a sélectionné le chemin de R2 (R5) 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 à partir de R2, 200.
La raison pour laquelle la route de départ R5 n’est pas sélectionnée 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 la route du discriminateur de sortie multiple
Objet
Examiner une route pour déterminer si la MED est le critère de sélection pour le chemin unique actif.
Mesures à prendre
Pour examiner une route et déterminer si le MED est le critère de sélection pour le chemin actif unique, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
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
Signification
L’exemple de sortie montre que a R4 reçu deux instances de la 100.100.2.0 route : une de 10.0.0.2 (R2) et une de 10.1.45.2 (). R4 a sélectionné le chemin de départR5 comme R2 route active, 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 à partir 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. Ce libellé est dû au fait que Junos OS utilise par défaut le processus de sélection déterministe MED.
Examinez la sélection EBGP par rapport à IBGP
Objet
Examiner une route pour déterminer si EBGP est sélectionné plutôt qu’IBGP comme critère de sélection pour le chemin actif unique.
Mesures à prendre
Pour 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 actif unique, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
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
Signification
L’exemple de sortie montre que a R4 reçu deux instances de la 100.100.3.0 route : une de 10.1.45.2 (R5) et une de 10.0.0.2 (). R4 a sélectionné le chemin de R5 (R2) comme chemin actif, comme indiqué par l’astérisque (*). La sélection est basée sur une préférence pour les routes apprises d’un pair EBGP par rapport aux routes apprises 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 and 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 provient d’un homologue EBGP. La route à partir de R2 indique que l’AS local et pair 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 la même route est reçue 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.
Examinez la sélection des coûts de l’IGP
Objet
Examiner une route pour déterminer si EBGP est sélectionné plutôt qu’IBGP comme critère de sélection pour le chemin actif unique.
Mesures à prendre
Pour 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 actif unique, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
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
Signification
L’exemple de sortie montre que j’ai R6 reçu deux instances de la 100.100.4.0 route : une de 10.0.0.4 (R4) et une de 10.0.0.2 (). R6 a sélectionné le chemin de R4 (R2) comme route active, comme indiqué par l’astérisque (*). La sélection est basée sur la métrique IGP, affichée dans le Metric2 champ. La route avec la métrique IGP la plus basse est préférée. Dans l’exemple, le chemin d’accès avec la valeur de métrique IGP la plus faible est le chemin d’accès de , avec une valeur de R4mé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é est affichée dans le champ, dans ce Inactive reason cas, IGP metric.
Liste de contrôle pour la vérification de la couche BGP
Problème
Descriptif
Cette checklist fournit les étapes et les commandes permettant de vérifier la configuration BGP du réseau MPLS. La checklist 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. (Voir le tableau 2.)
La 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
Objet
Une fois que vous avez configuré le chemin à commutation d’étiquettes (LSP) et déterminé qu’il est opérationnel, configuré BGP et déterminé que des sessions sont établies, assurez-vous que BGP l’utilise pour transférer le trafic.
La figure 3 illustre la couche BGP du modèle MPLS en couches.
BGP
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 ne sert à rien de vérifier la couche BGP si le LSP n’est pas établi, car le 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é.
La figure 4 illustre le réseau MPLS utilisé dans cette rubrique.
BGP
Le réseau illustré à la 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. Dans ce réseau, le LSP est configuré pour s’exécuter du routeur entrant R1 au routeur de sortie R6 en passant par le routeur de transit R3. De plus, un LSP inversé est configuré pour fonctionner de R6 à R3 jusqu’à R1, ce qui crée un trafic bidirectionnel.
La croix illustrée à la Figure 4 indique l’endroit où le 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 le 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érifiez la configuration BGP
- Examiner les routes BGP
- Vérification des routes BGP reçues
- Prendre les mesures appropriées pour résoudre le problème réseau
- Vérifiez que le trafic BGP utilise à nouveau le LSP
Vérifiez que le trafic BGP utilise le LSP
Objet
À ce niveau du modèle de dépannage, le BGP et le LSP peuvent être opérationnels, mais le trafic BGP peut ne pas utiliser le LSP pour transférer le trafic.
Mesures à prendre
Pour vérifier que le trafic BGP utilise le LSP, entrez la commande suivante Junos OS mode opérationnel de l’interface de ligne de commande (CLI) à 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
Signification
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 LSP du saut suivant BGP pour R6 et R1. Par défaut, Junos OS utilise des LSP pour le trafic BGP lorsque le saut suivant BGP est égal à l’adresse de sortie LSP.
Vérifier les sessions BGP
Objet
Affichez des informations récapitulatives sur le protocole BGP et ses voisins pour déterminer si des routes sont reçues des homologues du système autonome (AS). Lorsqu’une session BGP est établie, les pairs échangent des messages de mise à jour.
Mesures à prendre
Pour vérifier que les sessions BGP sont actives, saisissez la commande de mode opérationnel de la CLI de Junos OS suivante à partir du routeur entrant :
user@host> show bgp summary
Exemple de sortie 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
Exemple de sortie 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
Signification
L’exemple de sortie 1 montre qu’un homologue (routeur de sortie 10.0.0.6 ) n’est pas établi, comme indiqué par le champ Homologues inactifs : 1 . La dernière colonne (State|#Active/Received/Damped) indique que peer 10.0.0.6 est actif, ce qui indique qu’il n’est pas établi. Tous les autres pairs sont établis en fonction du nombre de routes actives, reçues et amorties. Par exemple, 0/0/0 pour peer 10.0.0.2 indique qu’aucune route BGP n’a été active ou reçue dans la table de routage, et qu’aucune route BGP n’a été amortie ; 1/1/0 pour l’homologue 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 show bgp summary commande d’un routeur entrant indique qu’un voisin est en panne, vérifiez la configuration BGP. Pour plus d’informations sur la vérification de la configuration BGP, consultez Vérifier la configuration BGP.
L’exemple de sortie 2 montre la sortie du routeur entrant R1 après que les configurations BGP sur R1 et R6 ont été corrigées dans Prise 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, vérifiez 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érifiez la configuration BGP
Objet
Pour que BGP s’exécute sur le routeur, vous devez définir le numéro d’AS local, configurer au moins un groupe et inclure des informations sur au moins un pair dans le 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 saut suivant BGP pour que les routes BGP soient installées avec le LSP comme saut suivant pour ces routes.
Mesures à prendre
Pour vérifier la configuration BGP, entrez la commande de mode opérationnel Junos OS CLI suivante :
user@host> show configuration
Exemple de sortie 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;
}
}
}
Exemple de sortie 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;
}
}
}
Signification
L’exemple de sortie montre les configurations BGP sur le routeur R1 entrant 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 duplication, et toutes les interfaces configurées avec BGP incluent l’instruction family inet au niveau de la hiérarchie [ logical-unit-numberedit interfaces type-fpc/pic/port unit ].
Un exemple de sortie pour le routeur entrant et le R1 routeur de sortie montre que la configuration du R6 protocole BGP ne contient pas l’instruction local-address pour le groupe interne. Lorsque l’instruction est configurée, les local-address paquets BGP sont transférés à partir de l’adresse de l’interface de bouclage (lo0) du routeur local, qui est l’adresse à laquelle les homologues BGP sont appairés. Si l’instruction n’est pas configurée, les local-address paquets BGP sont transférés à partir de l’adresse de l’interface sortante, qui ne correspond pas à l’adresse à 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.
En outre, la configuration BGP activée R1 inclut deux adresses IP pour R6, une adresse d’interface (10.1.36.2) et une adresse d’interface de bouclage (lo0) (10.0.0.6), ce qui fait que l’adresse de destination LSP (10.0.0.6) ne correspond pas à l’adresse de saut suivant BGP (10.1.36.2). La configuration BGP sur R6 comprend é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 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 local-address est manquante dans les configurations BGP des deux routeurs et que l’adresse de destination LSP ne correspond pas à l’adresse de saut suivant BGP, BGP n’utilise pas le LSP pour transférer le trafic.
Examiner les routes BGP
Objet
Vous pouvez examiner le processus de sélection du chemin BGP pour déterminer le chemin actif unique lorsque le BGP reçoit plusieurs routes vers la même destination. Dans cette étape, nous examinons le LSP inverse R6 à R1, faisant de R6 le routeur entrant pour ce LSP.
Mesures à prendre
Pour examiner les routes BGP et leur sélection, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
user@host> show route destination-prefix detail
Exemple de sortie 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
Exemple de sortie 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
Signification
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 la 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érification des routes BGP reçues
Objet
Affichez les informations de routage reçues sur le routeur R6, le routeur entrant pour le LSP inverse R6-à-R1.
Mesures à prendre
Pour vérifier qu’une route BGP particulière est reçue sur le routeur de sortie, entrez la commande de mode opérationnel de la CLI de Junos OS suivante :
user@host> show route receive protocol bgp neighbor-address
Exemple de sortie 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)
Exemple de sortie 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)
Signification
L’exemple de sortie 1 montre que le routeur entrant R6 (inverse LSP R6-to-R1) ne reçoit aucune route BGP dans la table de routage inet.0 lorsque les configurations BGP de R1 et R6 sont incorrectes.
L’exemple de sortie 2 montre une route BGP installée dans la table de routage inet.0 après que les configurations BGP sur R1 et R6 ont été corrigées à l’aide de l’action appropriée pour résoudre le problème réseau.
Prendre les mesures appropriées pour résoudre le problème réseau
Problème
Descriptif
L’action appropriée dépend du type de problème que vous avez isolé. Dans cet exemple, une route statique configurée sur R2 est supprimée du niveau hiérarchique [routing-options]. D’autres actions appropriées pourraient inclure les suivantes :
La 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 de 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
Signification
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 show route commande affiche désormais la route BGP comme route préférée, comme indiqué par l’astérisque (*).
Vérifiez que le trafic BGP utilise à nouveau le LSP
Objet
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.
Mesures à prendre
Pour vérifier que le trafic BGP utilise le LSP, entrez la commande Junos OS CLI operational mode suivante à 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
Signification
L’exemple de sortie montre que les é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 de bit de pile (S = 1).
Le champ Étiquette MPLS est utilisé pour identifier le paquet vers un LSP particulier. Il s’agit d’un champ de 20 bits, avec une valeur maximale de (2^^20-1), environ 1 000 000.
La valeur TTL (Time-to-Live) contient une limite sur le nombre de sauts que ce paquet MPLS peut parcourir sur le réseau (1). Il est décrémenté à chaque saut, et si la valeur TTL tombe en dessous de un, le paquet est ignoré.
La valeur de bit inférieure de la pile (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’empilement d’étiquettes MPLS, consultez RFC 3032, Codage de pile d’étiquettes MPLS.
Les étiquettes MPLS apparaissent dans l’exemple de sortie car la traceroute commande est émise vers une destination BGP où le saut suivant BGP 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
Mesures à prendre
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 routes dans la table de transfert
Objet
Lorsque vous rencontrez des problèmes, tels que des problèmes de connectivité, vous devrez peut-être examiner les routes 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.
Mesures à prendre
Pour afficher l’ensemble des routes installées dans la table de transfert, entrez la commande de mode opérationnel Junos OS CLI suivante :
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...]
Signification
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 show route detail commande (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 la bonne encapsulation des paquets envoyés par 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, consultez le 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 les routeurs de transport de paquets PTX Series
Cet exemple montre comment remplacer la politique de routage par défaut sur les routeurs de transport de paquets, tels que les routeurs de transport de paquets PTX Series.
Exigences
Cet exemple nécessite Junos OS version 12.1 ou ultérieure.
Vue d’ensemble
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 équipements de routage Junos OS. Avec la politique 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. C’est le comportement attendu.
Cet exemple montre comment utiliser l’action then install-to-fib pour remplacer efficacement la politique de routage BGP par défaut.
La configuration
Configuration rapide de la CLI
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-collez les commandes dans le CLI 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 la CLI, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de la CLI de 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 politique 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 politique de routage à la table de transfert.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Résultats
En mode configuration, confirmez votre configuration en entrant les show policy-options commandes and 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, entrez en commit mode configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérification de l’installation de la route sélectionnée dans la table de transfert
Objet
Assurez-vous que la stratégie configurée remplace la stratégie par défaut.
Mesures à prendre
À 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
Signification
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
Objet
Les transitions d’état du Border Gateway Protocol (BGP) indiquent un problème réseau et doivent être enregistrées et examinées.
Mesures à prendre
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 bgp -
Configurez le journal système :
user@host# set log-updown
-
Vérifiez la configuration :
user@host# show
-
Validez la configuration :
user@host# commit
Signification
Les messages de journal des événements de transition d’état BGP suffisent à diagnostiquer la plupart des problèmes de session BGP. Le Tableau 3 répertorie et décrit les six états d’une session BGP.
|
État du BGP |
Descriptif |
|---|---|
|
Inactif |
Il s’agit du premier état d’une connexion. BGP attend un événement de démarrage lancé 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 de démarrage, BGP initialise ses ressources, réinitialise un minuteur de connexion-nouvelle tentative, initie une connexion de transport TCP et commence à écouter les connexions initiées par des pairs distants. BGP passe ensuite à l’état Connect . En cas d’erreur, BGP revient à l’état Inactif . |
|
Connexion |
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 à Actif. Si le minuteur de connexion-nouvelle tentative a expiré, l’état reste à l’état Connexion , le minuteur est réinitialisé et une connexion de transport est initiée. Avec tout autre événement, l’État revient à Idle. |
|
Actif |
BGP tente d’acquérir un homologue en initiant une connexion de protocole de transport. En cas de succès, l’état passe à OpenSent. Si le minuteur de connexion-nouvelle tentative expire, BGP redémarre le minuteur de connexion et revient à l’état Connexion . BGP continue d’écouter une connexion qui peut être initiée à partir d’un autre pair. L’état peut revenir à Idle en cas d’autres événements, tels qu’un événement d’arrêt. En général, un basculement 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 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 OpenSend , le BGP compare son numéro de système autonome (AS) avec le numéro AS de son homologue et reconnaît si l’homologue 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 revient à Idle. Pour toute autre erreur, telle que l’expiration du minuteur d’attente ou un événement d’arrêt, BGP envoie un message de notification avec le code d’erreur correspondant et retombe à l’état Inactif . 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 d’attente est égal à 0, les minuteurs de maintien et de maintien ne sont pas redémarrés. Lorsqu’une déconnexion du transport TCP est détectée, l’état retombe sur Actif. |
|
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 d’attente (en supposant que le temps d’arrêt négocié n’est pas 0). Si un message de notification est reçu, l’état retombe sur Inactif. Le système envoie des messages keepalive périodiques au rythme défini par le minuteur keepalive. En cas de notification de déconnexion du transport ou en réponse à un événement d’arrêt, l’état retombe sur Inactif. 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. |
|
Création |
C’est 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 keepalive lorsqu’il n’est pas défini sur zéro. Si le système reçoit un message de notification, l’état retombe sur Inactif. Les messages de mise à jour sont vérifiés pour détecter les erreurs, telles que les attributs manquants, les attributs en double, etc. Si des erreurs sont détectées, une notification est envoyée à l’homologue et l’état retombe sur Inactif. BGP revient au mode Inactif lorsque le minuteur d’attente expire, qu’une notification de déconnexion est reçue du protocole de transport, qu’un événement d’arrêt est reçu ou en réponse à tout autre événement. |
Pour obtenir des informations plus détaillées sur les paquets du protocole BGP, configurez le suivi spécifique à BGP. Voir Liste de contrôle des conditions d’erreur de suivi pour plus d’informations.
Configurer les options spécifiques à BGP
Objet
En cas d’événements ou de problèmes inattendus, ou si vous souhaitez diagnostiquer des problèmes d’établissement de 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 bases 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
Mesures à prendre
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 afficher des messages détaillés du 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...]
Signification
Le Tableau 4 répertorie les indicateurs de suivi 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 bases du système Junos.
|
Traçage des drapeaux |
Descriptif |
Exemple de sortie |
|---|---|---|
|
aspath |
Opérations d’expression régulière de chemin AS |
Non disponible. |
|
Amortissement |
Opérations d’amortissement |
Nov 28 17:01:12 bgp_damp_change : Changement d’événement Nov 28 17:01:12 bgp_dampen : Amortissement 10.10.1.0 Nov 28 17:01:12 bgp_damp_change : Changement d’événement Nov 28 17:01:12 bgp_dampen : Amortissement 10.10.2.0 Nov 28 17:01:12 bgp_damp_change : Changement d’événement Nov 28 17:01:12 bgp_dampen : Amortissement 10.10.3.0 |
|
keepalive |
Messages keepalive BGP |
Nov 28 17:09:27 bgp_send : envoi de 19 octets à 10..217.5.101 (Externe AS 65471) 28 novembre 17:09:27 28 novembre 17:09:27 BGP ENVOYER 10.217.5.1+179 -> 10.217.5.101+52162 28 novembre 17:09:27 BGP ENVOYER le message type 4 (KeepAlive) longueur 19 novembre 28 17:09:28 BGP RECV 10.217.5.101+52162 -> 10.217.5.1+179 28 novembre 17:09:28 BGP RECV type 4 (KeepAlive) longueur 19 |
|
Ouvrir |
Paquets ouverts BGP |
Nov 28 18:37:42 bgp_send : envoi de 37 octets à 10.217.5.101 (AS externe 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 (Ouvert) longueur 37 |
|
paquets |
Tous les paquets du protocole BGP |
27 septembre 17:45:31 BGP RECV 10.0.100.108+179 -> 10.0.100.105+1033 27 septembre 17:45:31 BGP RECV type de message 4 (KeepAlive) longueur 19 septembre 27 17:45:31 bgp_send : envoi de 19 octets à 10.0.100.108 (AS interne 100) 27 septembre 17:45:31 BGP ENVOI 10.0.100.105+1033 -> 10.0.100.108+179 27 septembre 17:45:31 BGP ENVOYER le message type 4 (KeepAlive) durée 19 septembre 27 17:45:31 bgp_read_v4_update : Paquet(s) de réception à partir de 10.0.100.108 (Internal AS 100) |
|
Mise à jour |
Mettre à jour les paquets |
Nov 28 19:05:24 BGP ENVOYER 10.217.5.1+179 -> 10.217.5.101+55813 28 novembre 19:05:24 BGP SEND message type 2 (Mise à jour) longueur 53 Nov 28 19:05:24 bgp_send : envoi de 65 octets à 10.217.5.101 (AS externe 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 (Mise à jour) durée 65 Nov 28 19:05:24 bgp_send : Envoi de 55 octets à 10.217.5.101 (AS 65471 externe) |
Diagnostiquer les problèmes d’établissement de session BGP
Objet
Pour retracer les problèmes d’établissement de session BGP.
Mesures à prendre
Pour retracer 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 bgp -
Configurer 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 des options spécifiques à IS-IS
Objet
En cas d’événements ou de problèmes inattendus, ou si vous souhaitez diagnostiquer des problèmes d’établissement d’adjacence 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
Mesures à prendre
Pour tracer les messages IS-IS en détail, procédez comme suit :
-
Configurez l’indicateur pour afficher des messages détaillés du 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
Signification
Le 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.
|
Traçage des drapeaux |
Descriptif |
Exemple de sortie |
|---|---|---|
|
CSN |
Numéro de séquence complet PDU (CSNP) |
Nov 28 20:02:48 Envoi de CSN L2 sur l’interface so-1/1/0.028 Nov 28 20:02:48 Envoi de CSN L2 sur l’interface so-1/1/1.0 Avec l’option de détail . Nov 28 20:06:08 Envoi de CSN L2 sur l’interface so-1/1/1.0Nov 28 20:06:08 LSP abc-core-01.00-00 lifetime 1146Nov 28 20:06:08 séquence 0x1c4f8 somme de contrôle 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 séquence 0x45cc somme de contrôle 0x6883 |
|
Bonjour |
Bonjour paquet |
Nov 28 20:13:50 Envoi de PTP IIH le so-1/1/1.0Nov 28 20:13:50 Reçu PTP IIH, source id abc-core-01 le so-1/1/0.0Nov 28 20:13:53 Reçu PTP IIH, source id abc-core-02 le so-1/1/1.0 28 20:13:57 Envoi de PTP IIH le so-1/1/0.0Nov 28 20:13:58 Reçu PTP IIH, identifiant source abc-core-01 le so-1/1/0.028 20:13:59 Envoi de PTP IIH le so-1/1/1.0 |
|
LSP |
PDU à état de lien (LSP) |
Nov 28 20:15:46 Reçu L2 LSP abc-edge-01.00-00, interface so-1/1/0.0Nov 28 20:15:46 de abc-core-01Nov 28 20:15:46 séquence 0x1617, somme de contrôle 0xd92a, durée de vie 1197Nov 28 20:15:46 Mise à jour L2 LSP abc-edge-01.00-00 dans TEDNov 28 20:15:47 Reçu L2 LSP abc-edge-01.00-00, interface so-1/1/1.0Nov 28 20:15:47 de abc-core-02Nov 28 20:15:47 séquence 0x1617, somme de contrôle 0xd92a, durée de vie 1197 |
|
génération LSP |
Paquets de génération de PDU à état de lien |
Nov 28 20:21:24 Régénération L1 LSP abc-edge-03.00-00, ancienne séquence 0x682Nov 28 20:20:21:27 Reconstruction L1, fragment abc-edge-03.00-00Nov 28 20:21:27 Reconstruction du fragment L1 abc-edge-03.00-00, taille 59Nov 28 20:31:52 Régénération L2 LSP abc-edge-03.00-00, ancienne séquence 0x689Nov 28 20:31:54 Reconstruction L2, fragment abc-edge-03.00-00Nov 28 20:31:54 Reconstruction L2 fragment abc-edge-03.00-00, taille 256Nov 28 20:34:05 Régénération L1 LSP abc-edge-03.00-00, ancienne séquence 0x683Nov 28 20:34:08 Reconstruire L1, fragment abc-edge-03.00-00Nov 28 20:34:08 Fragment L1 reconstruit abc-edge-03.00-00, taille 59 |
|
paquets |
Tous les paquets du protocole IS-IS |
Non disponible. |
|
PSN (en anglais) |
Paquets PDU à numéro de séquence partiel (PSNP) |
28 novembre 20:40:39 Reçu L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:40:39 Reçu L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:41:36 Envoi L2 PSN sur l’interface so-1/1/1.0Nov 28 20:41:36 Envoi L2 PSN sur l’interface so-1/1/0.0Nov 28 20:42:35 Reçu 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 séquence 0x68c somme de contrôle 0x746dNov 28 20:42:35 Reçu 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 Envoi de L2 PSN sur l’interface so-1/1/1.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 séquence 0x1c4fb checksum 0x9becNov 28 20:42:49 Envoi de L2 PSN sur l’interface so-1/1/0.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 séquence 0x1c4fb somme de contrôle 0x9bec |
|
SPF |
Calculs SPF (Shortest-path-first) |
Nov 28 20:44:01 Planification du SPF pour L1 : ReconfigNov 28 20:44:01 Planification du SPF multicast pour L1 : ReconfigNov 28 20:44:01 Planification du SPF pour L2 : ReconfigNov 28 20:44:01 Planification du SPF multicast pour L2 : ReconfigNov 28 20:44:02 Exécution de L1 SPFNov 28 20:44:02 L1 Initialisation du SPF terminée : 0,000099s temps cumuléNov 28 20:44:02 L1 Traitement primaire du SPF terminé : 0,000303s temps cumuléNov 28 20:44:02 Post-traitement du résultat SPF L1 terminé : 0.000497s temps cumuléNov 28 20:44:02 L1 SPF RIB post-traitement terminé : 0.000626s temps cumuléNov 28 20:44:02 Post-traitement de la table de routage SPF L1 terminé : 0.000736s temps cumulé |
Voir aussi
Affichage des paquets de protocole IS-IS envoyés ou reçus
Pour configurer le suivi pour les seuls 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 aussi
Analyse détaillée des PDU à état de liaison IS-IS
Pour analyser en détail les PDU à état de lien 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 aussi
Configuration des options spécifiques à l’OSPF
Objet
En cas d’événements ou de problèmes inattendus, ou si vous souhaitez diagnostiquer des problèmes d’établissement voisin 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
- Analysez en détail les paquets d’annonce d’état de lien OSPF
Diagnostiquer les problèmes d’établissement de session OSPF
Mesures à prendre
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
-
Configurer 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
Signification
Le Tableau 6 répertorie les indicateurs de suivi OSPF et présente des exemples de sortie pour certains indicateurs.
|
Traçage des drapeaux |
Descriptif |
Exemple de sortie |
|---|---|---|
|
descripttion de base de données |
Tous les paquets de description de la base de données |
2 décembre 15:44:51 RPD_OSPF_NBRDOWN : OSPF’état du voisin 10.10.10.29 (so-1/1/0.0) est passé de Complet à Down 2 décembre 15:44:51 RPD_OSPF_NBRDOWN : OSPF’état du voisin 10.10.10.33 (so-1/1/1.0) est passé de Complet à Down 2 décembre 15:44:55 RPD_OSPF_NBRUP : OSPF’état du voisin 10.10.10.33 (so-1/1/1.0) est passé de Init à ExStart 2 décembre 15:44:55 OSPF envoyé DbD (2) -> 224.0.0.5 (so-1/1/1.0) 2 décembre 15:44:55 Version 2, longueur 32, ID 10.0.0.6, zone 0.0.0.0 2 déc. 15:44:55 somme de contrôle 0xf76b, authtype 0 déc. 2 déc. 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0xa009eee, mtu 4470 déc. 2 15:44:55 OSPF rcvd DbD 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) 2 déc. 15:44:55 Version 2, longueur 32, ID 10.10.134.12, aire 0.0.0.0 2 déc. 15:44:55 0x312c, authtype 0 déc. 2 15:44:55 options 0x42, I 1, M 1, MS 1, Seq 0x2154, MTU 4470 |
|
Erreur |
Paquets d’erreur OSPF |
Dec 2 15:49:34 Paquet OSPF ignoré : pas d’interface correspondante de 172.16.120.29 Déc 2 15:49:44 Paquet OSPF ignoré : pas d’interface correspondante de 172.16.120.29 Déc 2 15:49:54 Paquet OSPF ignoré : pas d’interface correspondante de 172.16.120.29 Déc 2 15:50:04 Paquet OSPF ignoré : pas d’interface correspondante de 172.16.120.29 Dec 2 15:50:14 Paquet OSPF ignoré : pas d’interface correspondante de 172.16.120.29 |
|
Événement |
Transitions d’état OSPF |
2 décembre 15:52:35 L’état de l’interface OSPF ge-2/2/0.0 est passé de DR à DR 2 décembre 15:52:35 L’état de l’interface OSPF ge-3/1/0.0 est passé de DR à DR 2 décembre 15:52:35 L’état de l’interface OSPF ge-3/2/0.0 est passé de DR à DR 2 décembre 15:52:35 L’état de l’interface OSPF ge-4/2/0.0 est passé de DR à DR 2 décembre 15:53:21 Voisin OSPF 10.10.10.29 (so-1/1/0.0) l’état est passé de Complet à Down 2 décembre 15:53:21 RPD_OSPF_NBRDOWN : L’état du voisin OSPF 10.10.10.29 (so-1/1/0.0) est passé de Complet à Descendant 2 décembre 15:53:21 L’état du voisin OSPF 10.10.10.33 (so-1/1/1.0) est passé de Complet à Descendant 2 décembre 15:53:21 RPD_OSPF_NBRDOWN : L’état du voisin OSPF 10.10.10.33 (so-1/1/1.0) est passé de Complet à Bas 2 décembre 15:53:25 Voisin OSPF 10.10.10.33 (so-1/1/1.0) L’état est passé de Down à Init 2 décembre 15:53:25 Voisin OSPF 10.10.10.33 (so-1/1/1.0) l’état est passé de Init à ExStart 2 décembre 15:53:25 RPD_OSPF__OSPF__ NBRUP : L’état du voisin OSPF 10.10.10.33 (so-1/1/1.0) est passé de Init à ExStart 2 décembre 15:53:25 L’état du voisin OSPF 10.10.10.33 (so-1/1/1.0) est passé de ExStart à Exchange 2 décembre 15:53:25 L’état du voisin OSPF 10.10.10.33 (so-1/1/1.0) est passé d’Exchange à Full Dec 2 15:53:25 RPD_OSPF_NBRUP : L’état du voisin OSPF 10.10.10.33 (so-1/1/1.0) est passé d’Exchange à Full |
|
inondation |
Flooding de paquets d’état de lien |
2 déc. 15:55:21 Résumé LSA d’OSPF 10.218.0.0 10.0.0.6 flooding sur so-1/1/0.0 2 déc. 15:55:21 Résumé LSA d’OSPF 10.218.0.0 10.0.0.6 flooding sur so-1/1/1.0 2 déc. 15:55:21 Résumé LSA d’OSPF 10.218.0.0 10.0.0.6 sur aucun so-1/1/2.0 listes de rexmit, pas d’inondation 2 déc. 15:55:21 Résumé LSA d’OSPF 10.218.0.0 10.0.0.6 sur aucune liste de rexmit so-1/1/3.0, pas d’inondation 2 décembre 15:55:21 Résumé LSA de l’OSPF 10.245.0.1 10.0.0.6 sur aucune liste de rexmit so-1/1/2.0, pas d’inondation 2 décembre 15:55:21 Résumé LSA de l’OSPF 10.245.0.1 10.0.0.6 sur aucune liste de rexmit so-1/1/3.0, pas d’inondation |
|
Bonjour |
Bonjour les paquets |
Dec 2 15:57:25 OSPF envoyé Hello (1) -> 224.0.0.5 (ge-3/1/0.0) Dec 2 15:57:25 Version 2, longueur 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, longueur 48, ID 10.10.134.12, zone 0.0.0.0 Dec 2 15:57:25 checksum 0x99b8, authtype 0 Dec 2 15:57:25 mask 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 envoyé Bonjour (1) -> 224.0.0.5 (ge-3/2/0.0) Dec 2 15:57:27 Version 2, longueur 44, ID 10.0.0.6, aire 2.0.0.0 Dec 2 15:57:27 somme de contrôle 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 Bonjour 10.10. 10.29 -> 224.0.0.5 (so-1/1/0.0) 2 déc. 15:57:28 Version 2, longueur 48, ID 10.10. 134.11, zone 0.0.0.0 2 déc. 15:57:28 somme de contrôle 0x99b9, authtype 0 déc. 2 15:57:28 masque 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 déc. 2 15:57:28 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 |
|
LSA-ACK |
Paquets d’acquittement de l’état des liens |
2 déc. 16:00:11 OSPF rcvd LSAck 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) 2 déc. 2 16:00:11 Version 2, longueur 44, ID 10.10.134.11, aire 0.0.0.0 2 déc. 16:00:11 somme de contrôle 0xcdbf, authtype 0 2 déc. 16:00:11 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) 2 déc. 16:00:11 Version 2, longueur 144, ID 10.10. 134.12, zone 0.0.0.0 2 décembre 16:00:11 somme de contrôle 0x73bc, authtype 0 2 décembre 16:00:16 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) 2 décembre 16:00:16 Version 2, longueur 44, ID 10.10. 134.12, zone 0.0.0.0 2 déc. 16:00:16 somme de contrôle 0x8180, authtype 0 |
|
requête LSA |
Paquets de demande d’état de lien |
2 déc. 16:01:38 OSPF rcvd LSReq 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) 2 déc. 16:01:38 Version 2, longueur 108, ID 10.10. 134.11, zone 0.0.0.0 Dec 2 16:01:38 somme de contrôle 0xe86, authtype 0 |
|
mise à jour LSA |
Paquets de mise à jour de l’état des liens |
Dec 2 16:09:12 OSPF construit routeur LSA, zone 0.0.0.0 Déc 2 16:09:12 OSPF construit routeur LSA, zone 1.1.0.0.0 Dec 2 16:09:12 OSPF construit routeur LSA, zone 2.0.0.0 Dec 2 16:09:13 OSPF envoyé LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:09:13 Version 2, longueur 268, ID 10.0.0.6, aire 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 envoyé LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:09:13 Version 2, longueur 268, ID 10.0.0.6, zone 0.0.0.0 2 déc. 16:09:13 somme de contrôle 0x8047, authtype 0 déc. 2 16:09:13 adv count 7 |
|
paquets |
Tous les paquets OSPF |
Non disponible. |
|
déversement de paquets |
Vider le contenu des types de paquets sélectionnés |
Non disponible. |
|
SPF |
Calculs du SPF |
Déc 2 16:08:03 Rafraîchissement complet du SPF OSPF prévu le 2 décembre 16:08:04 Début du SPF OSPF, zone 1.0.0.0 2 décembre 16:08:04 OSPF ajouter le routeur LSA 10.0.0.6 distance 0 à la liste SPF 2 décembre 16:08:04 temps écoulé SPF 0,000525s 2 décembre 16:08:04 temps écoulé 0,000263s 2 décembre 16:08:04 OSPF SPF début, zone 2.0.0.0 2 décembre 16:08:04 OSPF ajouter le routeur LSA 10.0.0.6 distance 0 à la liste SPF 2 décembre 16:08:04 SPF temps écoulé 0,000253s 2 décembre 16:08:04 Stub temps écoulé 0.000249s Dec 2 16:08:04 OSPF SPF start, area 0.0.0.0 Dec 2 16:08:04 OSPF ajouter LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 OSPF ajouter LSA Router 10.10. 134.11 distance 1 à la liste SPF 2 déc. 16:08:04 IP nexthop so-1/1/0.0 0.0.0.0 déc. 2 16:08:04 OSPF ajouter le routeur LSA 10.10. 134.12 distance 1 à la liste SPF Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0 |
Analysez en détail les paquets d’annonce d’état de lien OSPF
Mesures à prendre
Pour analyser en détail les paquets de publication 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