Visibilité des routes BGP et analyse des chemins

1. Démo BGP

La démo BGP générée se charge automatiquement. Elle contient 13 routeurs, 22 sessions BGP et deux réflecteurs de routes aux capacités BMP volontairement différentes.

1. Vérifiez que la topologie de démonstration générée est présente ; aucun import ni chargement manuel n’est requis.
2. Ouvrez la Vue générale et vérifiez que la superposition BGP est visible. Elle est activée par défaut ; la commande permet de la masquer et de la rétablir.
3. Repérez les routeurs dont les Router ID sont 123.123.100.100 (RFC 7854) et 123.123.101.101 (RFC 7854 + RFC 9069 + RFC 8671). Ces RFC indiquent les RIB reçues par Topolograph via BMP depuis chaque réflecteur de routes.

La topologie IGP reste le graphe de base. La superposition BGP ajoute les sessions sans remplacer la connectivité OSPF.

2. Sessions BGP

Utilisez les deux représentations : la table permet un filtrage précis des sessions BGP, tandis que la superposition graphique montre la position de la session sélectionnée dans la topologie.

1. Ouvrez Sessions BGP et filtrez la colonne peer ip sur 123.123.31.31.
2. Vérifiez que 123.123.31.31 (PE31) possède une session BGP, avec 123.123.100.100 (RR1), et aucune avec 123.123.101.101 (RR2).
3. Revenez à la Vue générale et repérez la même adjacence entre PE et 123.123.100.100 (RR1) dans la superposition BGP.

La table Sessions BGP filtrée concrétise la limite RFC 7854 : 123.123.31.31 (PE31) possède une seule session observée, vers 123.123.100.100 (RR1).

Ce PE31, avec une seule session BGP, illustre la limite RFC 7854 utilisée plus loin dans le runbook.

3. Vue RIB

Une session BMP établie avec un réflecteur de routes ne donne pas automatiquement accès à la table de chaque client du RR. Une session BMP capable d’exporter la Loc-RIB offre la vue la plus précise de l’état de la table de routage. Topolograph peut aussi s’appuyer sur des hypothèses explicites lorsque certaines informations manquent. Par exemple, l’état RIB d’un équipement peut être déduit de l’Adj-RIB-Out post-policy RFC 8671 d’un speaker BMP voisin dirigé vers cet équipement, même sans session BMP avec l’équipement lui-même.

Couverture des RFC BMP et incidence sur le calcul de chemin

Routeurs du réseau de démonstration et visibilité des informations de routage

RR2 exporte via BMP les données Adj-RIB-Out post-policy uniquement pour certains voisins BGP. C’est valide : la surveillance BMP Adj-RIB-Out se configure par voisin BGP et famille d’adresses, même si BGP conserve une Adj-RIB-Out pour chaque voisin établi.

4. Routes BGP

Commencez par la table Routes BGP du graphe entier avant de vous limiter à un routeur. Vous pouvez y examiner et filtrer toutes les données de route de la démo.

1. Ouvrez la table du graphe, sélectionnez Routes BGP et conservez le mode Live.
2. Utilisez les colonnes prefix, bmp source, bmp ribs, peer ip et les attributs de chemin pour trouver les routes à examiner.

La table Live plein écran ci-dessous présente les Routes BGP du graphe entier.

La table Routes BGP présente les routes collectées pour tout le graphe.

5. Vue des routes dans la fiche de l’équipement

Le nombre de routes dans la fiche montre la vue RIB de ce routeur : soit sa Loc-RIB reçue via une session BMP avec lui, soit l’Adj-RIB-Out post-policy reçue via une session BMP avec un équipement voisin.

1. Cliquez sur PE14 dans le graphe et repérez la section BGP de sa fiche.
2. Vérifiez que Routes vaut 4 et lisez l’explication : RR2 a annoncé ces routes à ce routeur via RFC 8671.
3. Lisez la ventilation RIB. Adj-RIB-Out post-policy décrit la RIB exportée par RR2 ; du point de vue de PE14, ces quatre annonces constituent son Adj-RIB-In déduite.
4. La ligne Adj-RIB-Out (post) 4 est incluse dans Routes : c’est l’Adj-RIB-Out de RR2 vers PE14, utilisée comme Adj-RIB-In déduite de PE14.

Cette fiche montre la vue RIB de PE14 : quatre routes Adj-RIB-Out post-policy reçues de RR2 via BMP.

La fiche PE14 montre quatre routes, RR2 comme source BMP et Adj-RIB-Out post-policy comme RIB. Routes n’inclut ni les routes annoncées par PE14 à RR2 ni les observations BMP inutilisées pour la vue RIB de PE14.

6. Filtrage, tri et pagination des routes d’un nœud

Ouvrez la table depuis la fiche ; elle conserve le périmètre RIB sélectionné pour PE14.

1. Cliquez sur Routes 4 pour PE14. Vérifiez que le volet contient exactement 100.30.0.0/24, 10.100.31.0/24, 2001:db8:123:123:30:30::/96 et 2001:db8:100:31::/64.
2. Filtrez prefix sur 100.30.0.0/24. Les lignes et le compteur doivent passer de 4 à 1.
3. Effacez le filtre et examinez les autres attributs séparément : local pref = 250 conserve deux routes VPN, afi = 2 deux routes IPv6 et med = 20 deux routes de PE30.
4. Effacez les filtres et vérifiez le retour des quatre routes de PE14. L’effacement ne doit pas supprimer le périmètre établi par la fiche.
5. Cliquez sur un en-tête triable tel que prefix, nexthop, local pref ou med. Les clics alternent ordre croissant, décroissant et absence de tri ; les adresses sont triées comme telles, pas comme du texte.
6. Utilisez Rows per page pour les grandes tables. La démo ne comporte qu’une page ici, donc les commandes précédente et suivante restent désactivées.

La table conserve le périmètre PE14 et ajoute le filtre de préfixe, ne laissant qu’une route.

La ligne filtrée montre RR2 comme source bmp et Adj-RIB-Out post-policy comme RIB observée.

7. Sélection du meilleur chemin

Pour chaque préfixe, la démo illustre un critère. Commencez par AS_PATH : comparez les attributs candidats, construisez la route depuis RR2 et vérifiez le prochain saut BGP sélectionné.

Exemple pilote : AS_PATH l’emporte

1. Filtrez Routes BGP sur 198.18.2.0/24.
2. Comparez les candidats : tous deux ont Local Preference 100, Origin IGP et MED 10. PE30 annonce AS_PATH 65010 65011 65012 ; PE14 annonce AS_PATH 65010.
3. Passez en mode de chemin BGP / VPN. Choisissez RR2 comme Router, global comme VPN or global table et 198.18.2.0/24 comme To, puis Build a path.
4. Dans Route resolution, vérifiez que la première ligne est BGP sur RR2 avec PE14 comme prochain saut. Les autres lignes résolvent ce saut via IGP.

Sélectionnez le formulaire BGP / VPN et saisissez RR2, la table globale et ce préfixe.

Dans Route resolution, la première ligne montre RR2 sélectionnant PE14 comme prochain saut BGP ; les suivantes proviennent des données OSPF.

Les candidats post-policy diffèrent par la longueur AS_PATH, tandis que Local Preference, Origin et MED sont à égalité. La route depuis RR2 sélectionne PE14 comme prochain saut BGP ; les lignes IGP montrent son accessibilité.

Autres exemples de sélection du meilleur chemin

Critères supplémentaires de sélection

La démo présente les six critères du tableau. Elle n’illustre pas la préférence eBGP sur iBGP, le coût IGP vers le prochain saut, l’âge de la route, la longueur de cluster-list ni l’adresse du voisin BGP.

8. Comparaison de l’état des routes entre deux instants

Live montre l’état actuel. Compare évalue l’état à T0 et T1.

1. Ouvrez la table Routes BGP du graphe entier et passez de Live à Compare.
2. Conservez la fenêtre par défaut d’une heure entre T0 et T1 créée avec la démo, puis cliquez sur Run.
3. La table montre une route ajoutée, 100.14.210.0/24 ; changed at contient l’heure de son dernier changement avant T1.
4. added signifie absente à T0 et présente à T1 ; withdrawn, présente à T0 et absente à T1 ; changed, présente aux deux instants avec des attributs différents. Les événements après T1 sont exclus.
5. Revenez à Live pour l’état actuel.

La comparaison montre l’écart entre les extrémités de la fenêtre, pas un journal chronologique.

Pour l’intervalle par défaut, 100.14.210.0/24 a l’état added et MED 80 à T1.

Événements BGP individuels

Events utilise le même volet et la même période, mais conserve chaque observation de route et de peer au lieu de les réduire à un écart T0-T1.

1. Passez de Compare à Events et conservez une période couvrant les changements de la démo.
2. Cliquez sur Run et vérifiez l’ajout d’une route, un événement peer down et une modification de route pour 100.14.210.0/24.
3. Utilisez event, kind, prefix, peer source, peer target et at pour distinguer les changements de route des changements de session.

Events répertorie chronologiquement la route ajoutée, l’événement peer-down puis la route modifiée avec MED 80.

Events montre les trois observations dans l’ordre. Contrairement à Compare, il conserve les événements intermédiaires même si l’état final est inchangé.

9. Résolution du prochain saut BGP via OSPF

BGP choisit la route ; OSPF fournit l’accessibilité vers le prochain saut BGP sélectionné. La vue montre explicitement ce relais.

1. En mode Standard / IGP, utilisez PE30 comme source et 100.14.0.0/24 comme destination.
2. Examinez la ligne BGP sélectionnée et identifiez PE14 comme prochain saut.
3. Ouvrez Route resolution et lisez de gauche à droite : la première ligne est BGP, avec une distance administrative de 200 et PE14 comme prochain saut.
4. Poursuivez sur les cinq lignes IGP de distance administrative 110 qui résolvent physiquement l’accessibilité de PE30 à PE14.

La table sépare le choix de route BGP des sauts IGP qui rendent son prochain saut accessible.

Le prochain saut BGP pointe vers PE14 ; le reste de la route est construit à partir des données OSPF.

10. Vue ne permettant pas de construire un chemin

Filtrez sur PE31. Topolograph montre les routes reçues de PE31 par RR1, mais RFC 7854 seule ne révèle ni la route installée par PE31 ni ce que RR1 lui a annoncé.

1. Ouvrez Routes BGP et filtrez peer ip sur PE31. Adj-RIB-In (pre) et (post) montrent les routes reçues de PE31 par RR1, pas la table de PE31.
2. Ouvrez le formulaire BGP / VPN et sélectionnez Router PE31. Il avertit que sa table n’est pas observée et interdit de construire un chemin avec les données BGP.
3. Comparez PE31 et PE15 : pour PE15, Topolograph utilise la Loc-RIB de RR2 et suppose explicitement que RR2 lui a annoncé la route et que PE15 a appliqué sa politique entrante.

Topolograph ne construit pas de chemin lorsque les données BMP disponibles ne décrivent pas la table de l’équipement sélectionné. Pour lever cette limite, fournissez sa Loc-RIB via RFC 9069 ou son Adj-RIB-Out post-policy par voisin via RFC 8671.