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.

11. EVPN : où se trouve un hôte, quelles feuilles portent un VNI, déplacements de MAC

La démo contient aussi une fabrique BGP EVPN/VXLAN capturée sur le lab 13-hosts-demo-bgp : les feuilles 123.14.14.14, 123.15.15.15, 123.123.30.30 et 123.123.31.31, chacune avec son router ID comme VTEP, le L2VNI 1010 sur les quatre et le L2VNI 1020 sur 123.123.30.30 et 123.123.31.31, et la VRF tenant1 avec le L3VNI 5000. Les deux route reflectors l'exportent par BMP.

Quelles feuilles portent un VNI

1. Passez en mode de chemin BGP / VPN et laissez Router vide. VPN or global table liste alors tous les VNI et VRF de la fabrique.
2. Choisissez 65000:1020 · VNI 1020. Le graphe met en évidence 123.123.30.30 et 123.123.31.31, et le formulaire indique « Feuilles portant ce VPN : 2 ».
3. Cliquez sur « Colorer l'underlay » pour peindre le chemin IGP entre ces feuilles : les liens qui transportent le VNI 1020 entre ses VTEP.

Où se trouve un hôte

1. Choisissez 123.15.15.15 comme Router et tenant1 comme VPN or global table.
2. Saisissez 10.10.20.13 dans To. La carte sous le formulaire affiche le VTEP 123.123.31.31, le VNI 1020, le L3VNI 5000 et la MAC de l'hôte 00:c1:ab:00:00:03.
3. Cliquez sur Build a path. Le chemin IGP de 123.15.15.15 au VTEP 123.123.31.31 est peint : l'hôte n'existe que dans l'overlay, le chemin s'arrête donc à son VTEP.

123.15.15.15 porte le VNI 1010 mais pas le VNI 1020 : il atteint donc cet hôte par la VRF tenant1 (symmetric IRB, L3VNI 5000), et non par le VNI.

Une MAC s'est-elle déplacée

1. Choisissez 123.123.101.101 comme Router et 65000:1010 · VNI 1010 comme VPN or global table.
2. Saisissez la MAC 00:c1:ab:00:00:01 dans To. La carte affiche son VTEP actuel 123.15.15.15 et le dernier déplacement, 123.14.14.14 → 123.15.15.15, avec son heure.
3. Un déplacement, c'est la MAC qui quitte un VTEP et apparaît sur un autre. La même MAC annoncée par plusieurs VTEP sous un même ESI relève du multihoming, pas d'un déplacement.

Un hôte en multihoming

1. Gardez Router 123.123.101.101 et le VNI 1010, et saisissez 00:c1:ab:00:00:02 dans To.
2. La carte liste deux VTEP, 123.123.30.30 et 123.123.31.31, et l'ESI 03:44:38:39:ff:00:01:00:00:01 : l'hôte est relié aux deux feuilles par un seul Ethernet Segment.
3. Cliquez sur Build a path. Les chemins vers les deux VTEP sont peints en même temps. Si une feuille tombe, l'autre dessert toujours le segment ; la feuille qui transmet le trafic broadcast (le designated forwarder) est choisie sur les feuilles et n'est pas visible par BMP.

Sous-réseaux d'une VRF

1. Ouvrez Graph table, sélectionnez BGP Routes et filtrez la colonne evpn route type sur 5.
2. La table liste les routes IP Prefix de la VRF tenant1 : 10.10.10.0/24 depuis les quatre feuilles et 10.10.20.0/24 depuis 123.123.30.30 et 123.123.31.31, chacune avec le L3VNI 5000 et sa feuille comme VTEP.

Chaque réponse provient des données BMP des route reflectors, rattachées au graphe OSPF : un VTEP est la feuille qui porte ce router ID, et un chemin vers un hôte s'arrête à son VTEP.