BGP route visibility and path analysis

1. BGP demo

The generated BGP demo loads automatically. It contains 13 routers, 22 BGP sessions, and two route reflectors with deliberately different BMP capabilities.

1. Confirm that the generated demo topology is present; no upload or manual demo load is required.
2. Open General View and confirm that the BGP overlay is visible. The overlay is enabled by default; the control can hide and restore it.
3. Find the routers with Router IDs 123.123.100.100 (RFC 7854) and 123.123.101.101 (RFC 7854 + RFC 9069 + RFC 8671). These RFCs identify which RIBs Topolograph receives through BMP from each route reflector.

The IGP topology remains the base graph. The BGP overlay adds sessions without replacing OSPF connectivity.

2. BGP sessions

Use both representations: the table provides precise BGP-session filtering, while the graphical BGP-session overlay shows where the selected session sits in the topology.

1. Open BGP Sessions and filter the peer ip column by 123.123.31.31.
2. Confirm that 123.123.31.31 (PE31) has one BGP session, with 123.123.100.100 (RR1), and no BGP session with 123.123.101.101 (RR2).
3. Return to General View and locate the same PE-to-123.123.100.100 (RR1) adjacency in the BGP overlay.

The filtered BGP Sessions table below makes the RFC 7854 limitation case concrete: 123.123.31.31 (PE31) has one observed session, to 123.123.100.100 (RR1).

This 123.123.31.31 (PE31), with one BGP session, demonstrates the RFC 7854 limitation used later in the runbook.

3. RIB view

A BMP session established with a route reflector does not automatically provide a view of every RR client's table. A BMP session capable of exporting Loc-RIB provides the most accurate view of routing-table state. Topolograph can also work with explicit assumptions when some information is unavailable. For example, a device's RIB state can be inferred from a neighboring BMP speaker's RFC 8671 Adj-RIB-Out post-policy toward that device, even when no BMP session is established with the device itself.

BMP RFC coverage and path-calculation meaning

Routers in the demo network and routing-information visibility

123.123.101.101 (RR2) exports Adj-RIB-Out post-policy data through BMP only for selected BGP neighbors. This is valid: BMP Adj-RIB-Out monitoring is configured per BGP neighbor and address family, even though BGP itself maintains an Adj-RIB-Out for every established BGP neighbor.

4. BGP routes

Start from the graph-wide BGP Routes table before narrowing to one router. This is the place to inspect and filter the route data collected for the whole demo.

1. Open Graph table and select BGP Routes. Leave the table in Live mode.
2. Use prefix, bmp source, bmp ribs, peer ip, and path-attribute columns to find the route set you want to investigate.

The full-screen Live table below is the graph-wide BGP Routes view.

The BGP Routes table shows routes collected for the entire graph.

5. Route view in the device form

The route count in the device form shows the RIB view for that router: either its Loc-RIB received through a BMP session with the device, or Adj-RIB-Out post-policy received through a BMP session with a neighboring device.

1. Click 123.14.14.14 (PE14) on the graph and find the BGP section in the device form.
2. Confirm Routes is 4 and read the explanation: the routes were advertised by 123.123.101.101 (RR2) to this router through RFC 8671.
3. Read the RIB breakdown. Adj-RIB-Out post-policy describes 123.123.101.101 (RR2)'s exported RIB; from 123.14.14.14 (PE14)'s perspective these four advertisements are its inferred Adj-RIB-In.
4. The Adj-RIB-Out (post) 4 row is included in Routes: it is 123.123.101.101 (RR2)'s Adj-RIB-Out toward 123.14.14.14 (PE14), used as 123.14.14.14 (PE14)'s inferred Adj-RIB-In.

This form shows the RIB view for 123.14.14.14 (PE14): four routes from Adj-RIB-Out post-policy received through BMP from 123.123.101.101 (RR2).

The device form for 123.14.14.14 (PE14) shows four routes, BMP source 123.123.101.101 (RR2), and RIB Adj-RIB-Out post-policy. Routes does not include routes that 123.14.14.14 (PE14) advertised to 123.123.101.101 (RR2) or other BMP observations not used for 123.14.14.14 (PE14)'s RIB view.

6. Filtering, sorting, and pagination for one node's routes

Open the route table from the device form; the table retains the RIB scope selected for 123.14.14.14 (PE14).

1. Click Routes 4 on 123.14.14.14 (PE14). Confirm the drawer contains exactly 100.30.0.0/24, 10.100.31.0/24, 2001:db8:123:123:30:30::/96, and 2001:db8:100:31::/64.
2. Filter prefix by 100.30.0.0/24. Matching rows and the table counter must both fall from 4 to 1.
3. Clear the prefix filter and inspect other attributes independently: local pref = 250 leaves two VPN routes, afi = 2 leaves two IPv6 routes, and med = 20 leaves two routes from 123.123.30.30 (PE30).
4. Clear filters and confirm all four 123.14.14.14 (PE14) routes return. Clearing a table filter must not remove the device scope established by the form.
5. Click a sortable heading such as prefix, nexthop, local pref, or med. Repeated clicks cycle ascending, descending, and unsorted; address columns use address order, not text order.
6. Use Rows per page for large route tables. The demo has only one page in this node-scoped example, so the previous and next controls correctly remain disabled.

The table below retains the 123.14.14.14 (PE14) scope and adds the prefix filter, leaving one matching route.

The filtered row shows 123.123.101.101 (RR2) as bmp source and Adj-RIB-Out post-policy as the observed RIB.

7. Best-path selection

For each prefix, the demo demonstrates one best-path selection criterion. Start with AS_PATH: compare the candidate attributes, then build the route from 123.123.101.101 (RR2) and verify the selected BGP next hop.

Pilot example: AS_PATH wins

1. Filter BGP Routes by 198.18.2.0/24.
2. Compare the two candidates: both have Local Preference 100, Origin IGP, and MED 10. 123.123.30.30 (PE30) advertises AS_PATH 65010 65011 65012; 123.14.14.14 (PE14) advertises AS_PATH 65010.
3. Switch to BGP / VPN path mode. Set Router to 123.123.101.101 (RR2), VPN or global table to global, and To to 198.18.2.0/24; then select Build a path.
4. In Route resolution, confirm the first row is BGP on 123.123.101.101 (RR2) with next hop 123.14.14.14 (PE14). The remaining rows resolve that selected next hop through IGP.

Next, select the BGP / VPN path form and enter 123.123.101.101 (RR2), the global table, and this prefix.

In Route resolution, the first row shows 123.123.101.101 (RR2) selecting 123.14.14.14 (PE14) as the BGP next hop; the following rows are built from OSPF data.

The post-policy candidates differ in AS_PATH length while Local Preference, Origin, and MED tie. Building the route from 123.123.101.101 (RR2) selects 123.14.14.14 (PE14) as the BGP next hop; the following IGP rows show reachability to that BGP next hop.

Other best-path selection examples

Additional best-path selection criteria

The demo shows the six BGP best-path selection criteria listed in the table above. It does not demonstrate selection of eBGP over iBGP, IGP cost to the next hop, route age, cluster-list length, or BGP neighbor address.

8. Route-state comparison between two instants

Live shows the current route-table state. Compare evaluates route state at T0 and T1.

1. Open the graph-wide BGP Routes table and switch from Live to Compare.
2. Keep the default one-hour T0 to T1 window created when the demo loads, then press Run.
3. The table shows one added route, 100.14.210.0/24; changed at contains the time of its last change before T1.
4. added means the route is absent at T0 and present at T1; withdrawn means it is present at T0 and absent at T1; changed means it is present at both instants but its attributes differ. Events after T1 are outside the comparison.
5. Switch back to Live to open the current route-table state.

The comparison below is the endpoint difference for the default demo window, not a chronological event log.

For the default demo interval, route 100.14.210.0/24 has status added and MED 80 at T1.

Individual BGP events

Events uses the same BGP Routes drawer and time range, but preserves every route and peer observation instead of reducing them to a T0-to-T1 difference.

1. Switch from Compare to Events and keep a time window that covers the demo change burst.
2. Press Run and verify one route add, one peer down event, and one route change for 100.14.210.0/24.
3. Use event, kind, prefix, peer source, peer target, and at to distinguish route changes from BGP-session state changes.

The Events view below lists the observations chronologically: the added route, the peer-down event, then the changed route with MED 80.

Events shows all three observations in order. Unlike Compare, it keeps intermediate events even when the final route state is unchanged.

9. BGP next-hop resolution through OSPF

BGP chooses the route; OSPF supplies reachability to the selected BGP next hop. The path view shows that handoff explicitly.

1. In Standard / IGP path mode, use 123.123.30.30 (PE30) as the source and 100.14.0.0/24 as the destination.
2. Inspect the selected BGP row and identify 123.14.14.14 (PE14) as the BGP next hop.
3. Open Route resolution and read the result from left to right: the first row is BGP with administrative distance 200 and next hop 123.14.14.14 (PE14).
4. Continue through the five IGP rows with administrative distance 110 that physically resolve reachability from 123.123.30.30 (PE30) to 123.14.14.14 (PE14).

The table below separates the single BGP route choice from the IGP hops that make its next hop reachable.

The BGP next hop points to 123.14.14.14 (PE14); the rest of the route is then built from OSPF data.

10. Unbuildable view

Filter for 123.123.31.31 (PE31). Topolograph can show the routes that 123.123.100.100 (RR1) received from 123.123.31.31 (PE31), but RFC 7854 alone does not reveal which route 123.123.31.31 (PE31) installed or what 123.123.100.100 (RR1) advertised back to it.

1. Open BGP Routes and filter the peer ip column by 123.123.31.31. Adj-RIB-In (pre) and Adj-RIB-In (post) show routes that 123.123.100.100 (RR1) received from 123.123.31.31 (PE31), not 123.123.31.31 (PE31)'s routing table.
2. Open the BGP / VPN path form and select Router 123.123.31.31. The form warns that this router's table is not observed and does not allow a path to be built from BGP data.
3. Compare 123.123.31.31 (PE31) with 123.15.15.15 (PE15): for 123.15.15.15 (PE15), Topolograph uses 123.123.101.101 (RR2) Loc-RIB and explicitly assumes that 123.123.101.101 (RR2) advertised the route to 123.15.15.15 (PE15) and 123.15.15.15 (PE15) applied its inbound policy.

Topolograph does not build a path when the available BMP data does not describe the selected device's routing table. To remove this limit, provide the device's Loc-RIB through RFC 9069 or its per-neighbor Adj-RIB-Out post-policy through RFC 8671.