The BGP Operations dashboard gives a fabric-wide view of BGP session health and recovery. It scores how many sessions are established and how cleanly sessions recover after a failure, lines up BGP update activity with BGP and link events, and narrows a problem to a pod, role, and peer. Use it to decide whether the fabric needs investigation and whether a BGP problem started with a link failure.
Persona Use Cases
|
Persona |
Primary Use Case |
|---|---|
|
Network Engineers |
Confirm that BGP sessions are established across the fabric, find sessions that are down or flapping, and tell a routing problem apart from the link failure that caused it. |
|
System Administrators / SREs |
Track session health and recovery over time, and identify the peer and switch to escalate. |
|
Performance Engineers |
Check that sessions recover quickly and stop generating route updates after a failure, so slow convergence isn't mistaken for a workload problem. |
Before You Begin
-
Import the dashboard. It is part of the Reference Configuration Package: import
minerva-configs/dashboards/user-tenant/bgp/bgp_operations_views_filtered.jsonas described in Import Dashboards. The file includes the dashboard and all the views it uses. -
Assign roles to your switches. The pod and role heatmaps, the event charts, and the session tables include only switches that have a role. See Assign Device Roles and Groups.
-
Make sure your switches meet the requirements for BGP session modeling. See BGP Sessions in Topology.
Dashboard Overview
The dashboard is organized into five sections, in top-down triage order:
-
Fabric Scores: session counts, health and convergence scores, and 24-hour down and flap counts.
-
Event Sequence: BGP update activity next to BGP and link events.
-
Pod and Role Focus: heatmaps that narrow a problem to a pod and switch role.
-
Affected Sessions: the sessions that weren't established in the last 24 hours.
-
Recovery Proof: one row for each completed recovery, slowest first.
Use the dashboard filters to narrow the views by pod, role, plane, device, VRF, peer ID, or peer IP.
Fabric Scores
Check this section first to see whether the fabric needs investigation.
Current BGP Sessions: The number of BGP peers that reported in the last five minutes.
Current BGP Session Health (0–100): The percentage of sessions that are currently established, based on the last five minutes. A session counts only after it has been seen established at least once, so sessions that have never come up don't lower the score.
BGP Downs (24h) and BGP Flaps (24h): The number of BGP down and flap events in the last 24 hours.
Session Health History (24h): The health score over the last 24 hours. Use it to see whether a drop is new or has persisted, and to confirm that the score recovers after you fix a problem.
BGP Convergence Score (0–100): How quickly and cleanly sessions recovered after going down. A recovery is complete when the session is established again and route updates have gone quiet. Faster recoveries score higher, and a recovery that doesn't settle in time scores 0. If no session recovered during the selected time range, no score is shown, rather than a 0.
Event Sequence
Compare these two charts to decide where a fault started.
BGP and Link Signals — RX/TX UPDATE Activity: The number of BGP update messages received and sent per peer, in five-minute intervals. A burst of updates usually follows a session going down or coming back up.
BGP and Link Signals — BGP Down/Flap and Link Down/Flap: BGP down, BGP flap, link down, and link flap events over the last 24 hours. If a link down or flap comes just before a BGP event, the link is the likely cause. If there is no link event, investigate the BGP configuration and control plane.
Pod and Role Focus
BGP RX UPDATE Activity by Pod and Role and BGP TX UPDATE Activity by Pod and Role: Heatmaps of received and sent update messages, with pods on one axis and switch roles on the other. A bright cell shows which pod and role are generating the most routing churn. Only switches with an assigned role appear.
Affected Sessions
Observed Non-Established BGP Sessions (24h): Every session that was seen in a state other than established in the last 24 hours, with its role, device, VRF, peer ID, peer IP, interface addresses, AS number, peer type, and state. Use it to identify the exact peer after narrowing the scope above, then find the session in Topology to see both ends.
Recovery Proof
BGP Recovery Evidence — Slowest First: One row per completed recovery, with the slowest recoveries at the top. Each row shows the session, when it went down (startTime), when updates went quiet after it came back up (endTime), the total recovery time (duration), and the recovery's score.
Last updated: