BGP

Aufgezeichnet am 28.07.2026 von einer CE dieses Deployments. sitecli/capture-manifest.json hält fest, welcher Knoten es war, und scripts/capture-sitecli.sh --check verifiziert die Befehlsoberfläche erneut gegen eine laufende CE.

Die CE betreibt FRR für BGP. In dieser Topologie betreibt sie Peering mit den zwei Azure-Route-Server-Instanzen, kündigt die VIP an und lernt das VNet-Präfix.

show-ip-bgp-summary

Beginnen Sie hier. Ein Bildschirm zeigt Ihnen, ob das Peering aktiv ist und wie lange es bereits stabil ist.

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

Lesen Sie zuerst State/PfxRcd. Eine Zahl ist die Anzahl der empfangenen Präfixe und bedeutet, dass die Sitzung etabliert ist; alles andere — Active, Connect, Idle — ist eine Sitzung, die nicht aktiv ist. Up/Down zeigt, wie lange der aktuelle Zustand angehalten hat, sodass eine Sitzung, die sich ständig zurücksetzt, einen verdächtig kleinen Wert anzeigt.

Die vrf id hier ist nicht die, die rt erwartet

Diese Ausgabe meldet vrf-id 3. Das ist die Nummerierung von FRR. Die Argo-Datenebene verwendet eine separate Tabellen-ID, und wenn man die Nummer von FRR an rt --dump übergibt, ergibt das No such file or directory, was wie ein defekter Knoten aussieht statt wie das falsche Argument.

show-ip-bgp

Die vollständige Tabelle mit sichtbarer Best-Path-Auswahl.

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

* ist eine gültige Route, > der ausgewählte Best Path, = ein Multipath-Mitglied. In der obigen Aufzeichnung hat das gelernte VNet-Präfix 10.0.0.0/16 zwei Pfade — einen über jede Route-Server-Instanz — markiert mit *= und *>: ein Best Path plus ein Multipath-Mitglied, sodass der Knoten seinen Rückverkehr über beide Instanzen verteilt. Die VIP 10.250.0.10/32 hat einen einzelnen *>-Pfad, weil dieser Knoten sie originiert.

Das Equal-Cost-Multipath der Demo ist in dieser Ausgabe nicht sichtbar

show-ip-bgp ist die Tabelle eines Knotens. Das ECMP, das dieses Deployment demonstriert, besteht aus mehreren verschiedenen CEs, die dasselbe /32 ankündigen, und es wird auf der Azure-Seite programmiert — daher kann die BGP-Tabelle keiner einzelnen CE es zeigen, und das Fehlen einer Multipath-Markierung an der VIP hier ist kein Fehler. Weisen Sie es stattdessen über die Route-Server-Peerings oder die effektive Routing-Tabelle des Clients nach; beides finden Sie auf der Verifizierungsseite.

show-ip-bgp-neighbors

Details pro Nachbar: verhandelte Capabilities, Timer, Nachrichtenzähler und der Grund für den letzten Reset.

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

Greifen Sie darauf zurück, wenn die Zusammenfassung eine flappende Sitzung zeigt und Sie wissen müssen, warum. Last reset und der zugehörige Grund sind die nützlichen Zeilen.

Noch keine aufgezeichnete Ausgabe auf dieser Seite

Diese Aufzeichnung kann nicht committet werden, bis f5-sales-demo/docs-control#795 eingegangen ist. FRR schreibt ein Wort in seiner Graceful-Restart-Zeile falsch, und codespell weist die Datei ab.

Aufgezeichneten Text zu korrigieren würde bedeuten, dass diese Dokumentation eine Ausgabe beschreibt, die niemals aufgetreten ist, daher wird es stattdessen upstream behoben. Führen Sie den Befehl in der Zwischenzeit gegen Ihren eigenen Knoten aus.

show-ip-bgp-neighbors-advertised-route

Was dieser Knoten seinen Peers mitteilt, im Gegensatz zu dem, was er weiß.

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

Dies ist der Befehl für „die VIP ist aus dem VNet nicht erreichbar“. Wenn die VIP hier fehlt, liegt das Problem an diesem Knoten und kein Blick auf den Peer wird helfen.

Die Ausgabe wiederholt einen bgp neighbor:-Block pro Peer, sodass Sie in dieser Topologie dieselben zwei Präfixe zweimal erhalten — einmal für jede Route-Server-Instanz. Das ist kein doppeltes Rendering: Es bestätigt, dass der Knoten an beide ankündigt. Der interessante Fall ist ein Block, der für einen Peer vorhanden und für den anderen fehlend oder zu kurz ist.