Showing How to Compare Reflector BMP Feeds, Client Control‑Plane State, and Installed Forwarding Entries to Prove Whether Missing Alternates Are True Path Hiding, Policy Suppression, or Downstream Installation Drift

By Tariq Hassan – Observability & Telemetry Lead, Network Systems

Introduction to Reflector BMP Feeds

BGP Monitoring Protocol (BMP) exports BGP peer state and routing information from a router to one or more monitoring stations. A reflector BMP feed originates from a BGP route‑reflector (RR) or a collector that mirrors the RR’s view. Unlike a feed taken directly from an edge router, a reflector feed shows the logical BGP topology after the RR’s route‑selection and reflection policies have been applied, but before any local outbound filtering or hardware‑installation steps on downstream routers.

Why Reflector BMP Feeds Are Useful for Alternate‑Path Analysis

Because the reflector does not perform the final forwarding‑plane installation step, any divergence between the reflector BMP view and the forwarding entries on a downstream router must stem from one of three layers:

1. Control‑plane decision (true path hiding via BGP best‑path rules).
2. Policy suppression (outbound route‑maps, prefix‑lists, or neighbor‑specific filters applied after the RR).
3. Downstream installation drift (failure to program the selected path into hardware/FIB).

BMP Message Structure Relevant to Analysis

A BMP message consists of a BMP header followed by one or more BGP messages.

Note: BMP does not carry the router’s local BGP process state (e.g., bgp bestpath tie‑breaker logs) nor the outcome of any outbound filter applied after the RR. Those must be obtained from the client router’s control‑plane telemetry or logs.

Understanding Client Control‑Plane State

The client control‑plane state comprises the data structures a router uses to decide which routes to install into its forwarding plane. Modern network operating systems expose this state via model‑driven telemetry (gNMI/gNOI) or traditional CLI show commands.

Core Components

Intended state lives in the configuration datastore; rendered state is the output of the routing protocol engine after inbound filters and BGP decision (Loc‑RIB); applied state is the result after outbound policies (RIB‑Out); observed state is what actually ends up in the forwarding plane (FIB/TCAM).

Making Control‑Plane State Comparable to BMP

1. Normalize timestamps – Align the BMP Timestamp with the control‑plane snapshot time (obtained via a gNMI Subscribe with mode: ON_CHANGE or a periodic Get).
2. Strip local‑only attributes – The RR does not see the client’s locally‑set LOCAL_PREF or WEIGHT (if the vendor uses a proprietary weight). Ignore or map them to a common representation.
3. Account for inbound filtering – If the client applies inbound prefix‑lists or route‑maps, the Adj‑RIB‑In seen by the RR may contain more prefixes than the client’s Loc‑RIB. The difference is inbound policy suppression.
4. Convert NLRI to a canonical key – Use (prefix, length, next-hop, AS_PATH, MED, LOCAL_PREF, COMMUNITIES) as a tuple for diffing. Sort communities for deterministic comparison.
5. Handle path‑explosion – In large topologies the Loc‑RIB may contain many equal‑cost paths (ECMP). The RR may reflect only one path per neighbor (depending on its bgp bestpath settings). Account for this when checking for “missing alternates”.

Signal Gap: Control‑plane telemetry rarely exposes the reason a path was rejected by the BGP decision process (e.g., “LOCAL_PREF lower than best”). You must infer this by comparing attribute values; if per‑path attribute history is unavailable, you can only prove that a path is absent, not why it was hidden.

Analyzing Installed Forwarding Entries

The forwarding plane stores the applied state after outbound policy and installation of selected routes into the hardware forwarding Information Base (FIB) or Ternary Content‑Addressable Memory (TCAM).

Types of Installed Forwarding Entries

Exposing Forwarding‑Plane State

• gNMI paths – e.g., /openconfig-platform:components/component/forwarding-table/ipv4/unicast/routes/route (OpenConfig) or vendor‑specific equivalents (/cisco-ios-xr:ipv4-route).
• CLI – show ip route, show route, show forwarding-table, show mpls forwarding, show tcam utilization.
• Telemetry pipelines – sFlow, IPFIX, or Inband Network Telemetry (INT) can hint at forwarding decisions but do not give the full FIB.

Required Data for Comparison

1. Consistent key – Same tuple used for the RIB (prefix/length, next-hop, AS_PATH, MED, LOCAL_PREF, COMMUNITIES). Forwarding entries usually lack BGP attributes; enrich them by joining with the control‑plane Loc‑RIB (or RIB‑Out) on next‑hop and prefix to pull in the attributes.
2. Installation timestamp – Some platforms export a last-modified timestamp per FIB entry (e.g., OpenConfig /state/last-change). If unavailable, rely on the collection time of the telemetry snapshot.
3. Hardware‑resource counters – TCAM utilization, number of active entries, pending install failures. These are essential to distinguish installation drift from a control‑plane decision.

Signal Gap: The forwarding plane does not retain the BGP AS_PATH or COMMUNITIES after route resolution; you must reconstruct them from the control‑plane state. If control‑plane telemetry is delayed or sampled, you may incorrectly attribute a missing FIB entry to installation drift when it is actually a transient control‑plane update.

Comparing Reflector BMP Feeds and Client Control‑Plane State

Methodology

1. Collect synchronized snapshots

   • BMP – Pull a time‑windowed dump from the reflector (e.g., using bgpdump or a BMP collector that writes to Kafka).
   • Control‑plane – Issue a gNMI Get on the Loc‑RIB (or Adj‑RIB‑In if you want to see inbound filtering) at the same wall‑clock time (use NTP/PTP synchronized clocks).
   • Forwarding – Issue a gNMI Get on the FIB (or run show ip route via SSH) within the same second.

2. Normalize each dataset

   • Convert all timestamps to UTC epoch milliseconds.
   • For each route, build a canonical key:

     key = (prefix, len, next-hop, as_path_sorted, med, local_pref, communities_sorted)

   • Strip any locally‑significant attributes (e.g., Cisco weight, Juniper local-preference if not transmitted in BMP).
   • For BMP, keep only routes where Peer Type = client (to match the downstream router’s perspective).

3. Compute set differences

   • BMP‑only = routes present in BMP but absent in Loc‑RIB → inbound policy suppression or RR reflection filtering.
   • Loc‑RIB‑only = routes present in Loc‑RIB but absent in BMP → asymmetric learning (e.g., client learned via another peer).

Interpreting the Differences

Determining the Root Cause: True Path Hiding, Policy Suppression, or Downstream Installation Drift

After obtaining the three datasets (BMP, Loc‑RIB/RIB‑Out, FIB), follow this decision flow:

1. Is the route present in the Loc‑RIB?

   • No → The RR never advertised it to the client (or the client filtered it inbound). Check inbound prefix‑lists/route‑maps on the client → Policy suppression (inbound).
   • Yes → Continue.

2. Is the route present in the RIB‑Out (if exported)?

   • No → Outbound policy on the client removed it → Policy suppression (outbound).
   • Yes → Continue.

3. Is the route present in the FIB?

   • No → The control plane selected the route, but hardware failed to install it → Downstream installation drift (check TCAM utilization, install‑fail counters).
   • Yes → Route is installed → No missing alternate.

4. If the route is present in Loc‑RIB and RIB‑Out but absent from FIB and TCAM is healthy, examine BGP attributes:

   • Compare the route’s attributes (LOCAL_PREF, MED, AS_PATH length) with the best‑path entry in Loc‑RIB.
   • If another path has a strictly better attribute per the BGP decision process, the missing alternate is true path hiding (BGP best‑path rule).

Example CLI Commands (Vendor‑agnostic)

# 1. Pull BMP dump from reflector (using a collector that writes to file)
bgpdump -m /var/log/bmp/collector.bmp -t 2025-09-24T12:00:00Z -w 60s > /tmp/bmp_snapshot.txt

# 2. gNMI Get for Loc‑RIB (OpenConfig)
gnmi_get -addr <router>:9339 -path "/bgp/rib/loc-rib" -timeout 10s > /tmp/loc_rib.json

# 3. gNMI Get for FIB (OpenConfig)
gnmi_get -addr <router>:9339 -path "/openconfig-platform:components/component/forwarding-table/ipv4/unicast/routes/route" -timeout 10s > /tmp/fib.json

# 4. Show TCAM utilization (example for Cisco IOS-XR)
show tcam utilization

# 5. Show pending install failures (example for Juniper)
show route forwarding-table | match pending

Adjust the gNMI paths and CLI commands to match your NOS and telemetry stack.

Conclusion

By synchronizing reflector BMP feeds, client control‑plane state, and forwarding‑plane entries, and then normalizing them to a common route key, you can objectively distinguish whether a missing alternate path is due to:

• True path hiding – BGP best‑path selection deliberately hid the route.
• Policy suppression – Inbound or outbound filters removed the route before installation.
• Downstream installation drift – The control plane selected the route, but the hardware failed to program it.

This methodology provides a repeatable, observable‑driven approach to troubleshooting BGP path‑selection anomalies and validating that your network’s data plane matches the intended control‑plane decisions.