BGP

Capturé le 28/07/2026 depuis un CE de ce déploiement. sitecli/capture-manifest.json consigne le nœud concerné, et scripts/capture-sitecli.sh --check revérifie la surface de commande sur un CE en fonctionnement.

Le CE exécute FRR pour BGP. Sur cette topologie, il établit un peering avec les deux instances Azure Route Server, annonce le VIP et apprend le préfixe du VNet.

show-ip-bgp-summary

Commencez ici. Un seul écran vous indique si le peering est actif et depuis combien de temps il est stable.

{"command":["show-ip-bgp-summary"]}

Instance 4094:

IPv4 Unicast Summary:
BGP router identifier 10.0.1.4, local AS number 64512 vrf-id 3
BGP table version 3
RIB entries 3, using 480 bytes of memory
Peers 2, using 41 KiB of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
10.0.4.4        4      65515    1063     932        0    0    0 01:17:22            1
10.0.4.5        4      65515    1063     932        0    0    0 01:17:23            1

Total number of neighbors 2

Lisez d’abord State/PfxRcd. Un nombre correspond au nombre de préfixes reçus et signifie que la session est établie ; toute autre valeur — Active, Connect, Idle — indique une session qui n’est pas active. Up/Down indique depuis combien de temps l’état actuel dure, si bien qu’une session qui se réinitialise en permanence affiche une valeur suspectement faible.

Le vrf id indiqué ici n'est pas celui attendu par rt

Cette sortie signale vrf-id 3. Il s’agit de la numérotation de FRR. Le plan de données Argo utilise un identifiant de table distinct, et transmettre le numéro de FRR à rt --dump renvoie No such file or directory, ce qui donne l’impression d’un nœud défaillant plutôt que d’un mauvais argument.

show-ip-bgp

La table complète, avec la sélection du meilleur chemin visible.

{"command":["show-ip-bgp"]}

Instance 4094:
BGP table version is 3, local router ID is 10.0.1.4, vrf id 3
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*= 10.0.0.0/16      10.0.4.4                               0 65515 i
*>                  10.0.4.5                               0 65515 i
*> 10.250.0.10/32   10.0.1.4               255         32768 ?

Displayed  2 routes and 3 total paths

* désigne une route valide, > le meilleur chemin sélectionné, = un membre multichemin. Dans la capture ci-dessus, le préfixe VNet appris 10.0.0.0/16 possède deux chemins — un par instance de Route Server — marqués *= et *> : un meilleur chemin plus un membre multichemin, de sorte que le nœud répartit la charge de son trafic de retour sur les deux instances. Le VIP 10.250.0.10/32 n’a qu’un seul chemin *> car ce nœud en est l’origine.

Le multichemin à coût égal de la démo n'est pas visible dans cette sortie

show-ip-bgp correspond à la table d’un seul nœud. L’ECMP que démontre ce déploiement repose sur plusieurs CE différents annonçant le même /32, et il est programmé du côté Azure — aucune table BGP d’un CE isolé ne peut donc l’afficher, et l’absence de marqueur multichemin sur le VIP ici n’est pas une anomalie. Vérifiez-le plutôt depuis les peerings Route Server ou depuis la table de routage effective du client ; les deux figurent sur la page de vérification.

show-ip-bgp-neighbors

Détail par voisin : capacités négociées, temporisateurs, compteurs de messages et motif de la dernière réinitialisation.

{"command":["show-ip-bgp-neighbors"]}

Utilisez-la lorsque le résumé montre une session instable et que vous devez en connaître la raison. Last reset et son motif sont les lignes utiles.

Aucune sortie capturée sur cette page pour l'instant

Cette capture ne peut pas être validée avant l’intégration de f5-sales-demo/docs-control#795. FRR écrit un mot avec une faute dans sa ligne Graceful Restart, et codespell rejette le fichier.

Corriger le texte capturé conduirait cette documentation à décrire une sortie qui n’a jamais existé ; la correction est donc effectuée en amont. Exécutez la commande sur votre propre nœud en attendant.

show-ip-bgp-neighbors-advertised-route

Ce que ce nœud annonce à ses pairs, par opposition à ce qu’il connaît.

{"command":["show-ip-bgp-neighbors-advertised-route"]}

bgp neighbor:
BGP table version is 3, local router ID is 10.0.1.4, vrf id 3
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0/16      0.0.0.0                                0 65515 i
*> 10.250.0.10/32   0.0.0.0                255         32768 ?

Total number of prefixes 2

bgp neighbor:
BGP table version is 3, local router ID is 10.0.1.4, vrf id 3
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0/16      0.0.0.0                                0 65515 i
*> 10.250.0.10/32   0.0.0.0                255         32768 ?

Total number of prefixes 2

C’est la commande à utiliser pour « le VIP n’est pas joignable depuis le VNet ». Si le VIP est absent ici, le problème se situe sur ce nœud et examiner le pair ne servira à rien.

La sortie répète un bloc bgp neighbor: par pair, si bien que sur cette topologie vous obtenez deux fois les mêmes deux préfixes — une fois pour chaque instance de Route Server. Il ne s’agit pas d’un affichage dupliqué : c’est ce qui confirme que le nœud annonce aux deux. Le cas intéressant est celui d’un bloc présent pour un pair mais absent ou incomplet pour l’autre.