BGP

Captured 2026-08-03 from one CE of this deployment. sitecli/capture-manifest.json records which node, and scripts/capture-sitecli.sh --check re-verifies the command surface against a live CE.

The CE runs FRR for BGP. On this topology it peers with the two Azure Route Server instances, advertises the VIP, and learns the VNet prefix.

show-ip-bgp-summary

Start here. One screen tells you whether peering is up and how long it has been 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

Read State/PfxRcd first. A number is the count of prefixes received and means the session is established; anything else — Active, Connect, Idle — is a session that is not up. Up/Down shows how long the current state has lasted, so a session that keeps resetting shows a suspiciously small value.

The vrf id here is not the one rt wants

This output reports vrf-id 3. That is FRR’s numbering. The Argo data plane uses a separate table id, and passing FRR’s number to rt --dump returns No such file or directory, which looks like a broken node rather than the wrong argument.

show-ip-bgp

The full table, with best-path selection 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

* is a valid route, > the selected best path, = a multipath member. In the capture above the learned VNet prefix 10.0.0.0/16 has two paths — one via each Route Server instance — marked *= and *>: a best path plus a multipath member, so the node load-shares its return traffic over both instances. The VIP 10.250.0.10/32 has a single *> path because this node originates it.

The demo's equal-cost multipath is not visible in this output

show-ip-bgp is one node’s table. The ECMP this deployment demonstrates is several different CEs advertising the same /32, and it is programmed on the Azure side — so no single CE’s BGP table can show it, and the absence of a multipath marker on the VIP here is not a fault. Prove that from the Route Server peerings or the client’s effective route table instead; both are on the verify page.

show-ip-bgp-neighbors

Per-neighbour detail: capabilities negotiated, timers, message counters and the reason for the last reset.

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

Reach for it when the summary shows a session flapping and you need to know why. Last reset and its reason are the useful lines.

No captured output on this page yet

This capture cannot be committed until f5-sales-demo/docs-control#795 lands. FRR misspells a word in its Graceful Restart line, and codespell rejects the file.

Correcting captured text would make this documentation describe output that never occurred, so it is being fixed upstream instead. Run the command against your own node in the meantime.

show-ip-bgp-neighbors-advertised-route

What this node is telling its peers, as opposed to what it knows.

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

This is the command for “the VIP is not reachable from the VNet”. If the VIP is absent here, the problem is on this node and no amount of looking at the peer will help.

The output repeats one bgp neighbor: block per peer, so on this topology you get the same two prefixes twice — once for each Route Server instance. That is not a duplicated render: it is what confirms the node is advertising to both. A block that is present for one peer and missing or short for the other is the interesting case.