BGP

Capturado el 2026-07-28 desde un CE de esta implementación. sitecli/capture-manifest.json registra qué nodo, y scripts/capture-sitecli.sh --check vuelve a verificar la superficie de comandos contra un CE en vivo.

El CE ejecuta FRR para BGP. En esta topología establece peering con las dos instancias de Azure Route Server, anuncia la VIP y aprende el prefijo de la VNet.

show-ip-bgp-summary

Empiece aquí. Una sola pantalla le indica si el peering está activo y cuánto tiempo ha permanecido estable.

{"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

Lea primero State/PfxRcd. Un número es la cantidad de prefijos recibidos y significa que la sesión está establecida; cualquier otro valor — Active, Connect, Idle — corresponde a una sesión que no está activa. Up/Down muestra cuánto ha durado el estado actual, de modo que una sesión que se reinicia constantemente muestra un valor sospechosamente pequeño.

El vrf id que aparece aquí no es el que rt necesita

Esta salida informa vrf-id 3. Esa es la numeración de FRR. El plano de datos de Argo utiliza un identificador de tabla distinto, y pasar el número de FRR a rt --dump devuelve No such file or directory, lo que parece un nodo averiado en lugar del argumento incorrecto.

show-ip-bgp

La tabla completa, con la selección de la mejor ruta 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

* es una ruta válida, > la mejor ruta seleccionada, = un miembro de multipath. En la captura anterior, el prefijo aprendido de la VNet 10.0.0.0/16 tiene dos rutas —una a través de cada instancia de Route Server— marcadas como *= y *>: una mejor ruta más un miembro de multipath, por lo que el nodo reparte la carga de su tráfico de retorno entre ambas instancias. La VIP 10.250.0.10/32 tiene una única ruta *> porque este nodo la origina.

El multipath de coste igual de la demostración no es visible en esta salida

show-ip-bgp es la tabla de un solo nodo. El ECMP que demuestra esta implementación consiste en varios CE distintos anunciando el mismo /32, y se programa en el lado de Azure — por lo que la tabla BGP de ningún CE individual puede mostrarlo, y la ausencia de un marcador de multipath en la VIP aquí no constituye un fallo. Compruébelo en su lugar desde los peerings del Route Server o desde la tabla de rutas efectiva del cliente; ambas opciones están en la página de verificación.

show-ip-bgp-neighbors

Detalle por vecino: capacidades negociadas, temporizadores, contadores de mensajes y el motivo del último reinicio.

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

Recurra a él cuando el resumen muestre una sesión inestable y necesite saber por qué. Last reset y su motivo son las líneas útiles.

Todavía no hay salida capturada en esta página

Esta captura no puede confirmarse hasta que se integre f5-sales-demo/docs-control#795. FRR escribe mal una palabra en su línea de Graceful Restart, y codespell rechaza el archivo.

Corregir el texto capturado haría que esta documentación describiera una salida que nunca ocurrió, así que se está corrigiendo aguas arriba en su lugar. Mientras tanto, ejecute el comando contra su propio nodo.

show-ip-bgp-neighbors-advertised-route

Lo que este nodo está comunicando a sus peers, en contraposición a lo que conoce.

{"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

Este es el comando para «la VIP no es alcanzable desde la VNet». Si la VIP no aparece aquí, el problema está en este nodo y no servirá de nada examinar el peer.

La salida repite un bloque bgp neighbor: por cada peer, de modo que en esta topología obtiene los mismos dos prefijos dos veces — una vez por cada instancia de Route Server. No se trata de una representación duplicada: es lo que confirma que el nodo está anunciando a ambos. El caso interesante es un bloque que está presente para un peer y ausente o incompleto para el otro.