BGP

Capturado em 28/07/2026 a partir de um CE desta implantação. sitecli/capture-manifest.json registra qual nó, e scripts/capture-sitecli.sh --check reverifica a superfície de comandos contra um CE ativo.

O CE executa o FRR para BGP. Nesta topologia, ele faz peering com as duas instâncias do Azure Route Server, anuncia o VIP e aprende o prefixo da VNet.

show-ip-bgp-summary

Comece por aqui. Uma única tela informa se o peering está ativo e por quanto tempo ele tem estado estável.

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

Leia State/PfxRcd primeiro. Um número é a contagem de prefixos recebidos e significa que a sessão está estabelecida; qualquer outra coisa — Active, Connect, Idle — é uma sessão que não está ativa. Up/Down mostra por quanto tempo o estado atual durou, portanto uma sessão que fica sendo reiniciada exibe um valor suspeitosamente pequeno.

O vrf id aqui não é o que o rt espera

Esta saída informa vrf-id 3. Essa é a numeração do FRR. O plano de dados Argo usa um id de tabela separado, e passar o número do FRR para rt --dump retorna No such file or directory, o que parece um nó quebrado em vez de um argumento errado.

show-ip-bgp

A tabela completa, com a seleção do melhor caminho visível.

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

* é uma rota válida, > o melhor caminho selecionado, = um membro de multipath. Na captura acima, o prefixo aprendido da VNet 10.0.0.0/16 tem dois caminhos — um por cada instância do Route Server — marcados como *= e *>: um melhor caminho mais um membro de multipath, de modo que o nó distribui a carga do seu tráfego de retorno entre as duas instâncias. O VIP 10.250.0.10/32 tem um único caminho *> porque este nó o origina.

O multipath de custo igual da demo não é visível nesta saída

show-ip-bgp é a tabela de um único nó. O ECMP que esta implantação demonstra são vários CEs diferentes anunciando o mesmo /32, e ele é programado do lado do Azure — portanto nenhuma tabela BGP de um único CE pode mostrá-lo, e a ausência de um marcador de multipath no VIP aqui não é uma falha. Comprove isso a partir dos peerings do Route Server ou da tabela de rotas efetiva do cliente; ambos estão na página de verificação.

show-ip-bgp-neighbors

Detalhe por vizinho: capacidades negociadas, timers, contadores de mensagens e o motivo do último reset.

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

Recorra a ele quando o resumo mostrar uma sessão instável e você precisar saber o motivo. Last reset e sua razão são as linhas úteis.

Ainda não há saída capturada nesta página

Esta captura não pode ser comitada até que f5-sales-demo/docs-control#795 seja mesclado. O FRR escreve uma palavra incorretamente em sua linha de Graceful Restart, e o codespell rejeita o arquivo.

Corrigir o texto capturado faria esta documentação descrever uma saída que nunca ocorreu, então isso está sendo corrigido no upstream. Execute o comando contra o seu próprio nó nesse meio-tempo.

show-ip-bgp-neighbors-advertised-route

O que este nó está informando aos seus peers, em contraste com o que ele conhece.

{"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 é o comando para “o VIP não está alcançável a partir da VNet”. Se o VIP estiver ausente aqui, o problema está neste nó e nenhuma análise do peer vai ajudar.

A saída repete um bloco bgp neighbor: por peer, portanto nesta topologia você obtém os mesmos dois prefixos duas vezes — uma para cada instância do Route Server. Isso não é uma renderização duplicada: é o que confirma que o nó está anunciando para ambas. Um bloco presente para um peer e ausente ou curto para o outro é o caso interessante.