Introduction

The BGP Monitoring Protocol (BMP), standardized by the IETF, was designed to go beyond what traditional BGP sessions provide. Instead of exposing only the single best path selected by a router, BMP allows exporting routes at multiple stages of the routing pipeline. This breadth is a game changer for inter-domain monitoring: it reveals non-preferred and filtered paths that would otherwise remain invisible.

In this post, we’ll explore how BMP allows us to significantly enrich our dataset, giving us a clearer view of the Internet and increasing the chances of detecting critical events such as hijacks, route leaks, and reachability gaps. We’ll also discuss the types of information BMP reveals, and how network operators can contribute their data to the community through bgproutes.io.


Today: data collection via standard BGP sessions


Most public BGP route-collection platforms peer with routers over BGP and receive only the router’s best-path routes. That’s the case, for instance, with RIPE RIS and RouteViews.

The usual pipeline in a BGP router
Figure 1 — The usual pipeline in a BGP router.

The limitation is that a router actually learns many candidate paths from its neighbors (and possibly local routes), applies per-neighbor import policies, and then selects a single best path per prefix to install and advertise (Figure 1). By observing only this final choice, we miss the alternate paths and the filtered announcements—which can represent a vast amount of valuable information, especially when a router peers with many neighbors.

🧊 It’s like an iceberg: the visible tip are the best and permitted paths, while a much larger part remains hidden beneath the surface.

Collecting routes via a BGP session results in visibility gaps
Figure 2 — Collecting routes via a BGP session results in visibility gaps.

To illustrate, consider the example in Figure 2. A BGP router has three peers and is also connected to a collection platform through BGP to contribute routing data. Peer 1 (P1) announces prefixes 1.0.0.0/24 and 2.0.0.0/24 (simplified here as 1/24 and 2/24) with AS paths 1 6 2 and 1 6 8, respectively. P2 announces prefixes 1/24 and 3/24, while P3 announces 2/24 and 3/24. The router applies inbound filters that reject routes for prefix 1/24 when learned from P1, as well as any routes from P2 containing AS5 in the AS path.

After running the BGP decision process, the router announces only three routes to the collection platform—one best route per prefix in its RIB. In reality, it had received six distinct routes, meaning that half of the available information is lost before it ever reaches the collector.

⚠️ This loss has real consequences: for example, if the route to 3/24 announced by P3 were a hijack, it would never appear in the collected data, possibly leaving the community unable to detect it.



BMP to the rescue


Unlike a standard BGP session, BMP can export routes at multiple stages of the BGP processing pipeline inside the router. Specifically, as defined in RFC 7854 and RFC 9069:

  • Pre-Policy Adj-RIB-In (adj_in_pre): contains the raw routing information received from peers, before any inbound policy is applied.
  • Post-Policy Adj-RIB-In (adj_in_post): the result of applying inbound policies to the Adj-RIB-In, but before the BGP decision process selects the best path.
  • Loc-RIB (loc_rib): the set of routes that remain after the decision process, i.e. the best paths chosen by the router.
  • Pre-Policy Adj-RIB-Out (adj_out_pre): the view of routes before outbound policies are applied. This often mirrors the Loc-RIB but can include additional routes depending on peering configuration.
  • Post-Policy Adj-RIB-Out (adj_out_post): the final set of routes actually sent to each peer after outbound policies are applied.

Throughout this post, we’ll refer to these stages as BMP feed types.

A BGP router
Figure 3 — A BGP router exporting routes via BMP

Now, let’s revisit the earlier example—this time with the router exporting its routes via a BMP session instead of a plain BGP session. In the diagram (pink areas), each BMP feed type is mapped to its corresponding stage in the router’s pipeline.

A BMP session can be configured to export one or more feed types. In this example, we assume the router exports only the adj_in_pre feed type, which is often the most valuable for inter-domain BGP data collection (we’ll explain why later). In that case, the collection platform receives all routes as they arrive from the three peers—before any filters are applied or the best path is selected by the BGP decision process. This means the platform now collects all six routes originally received by the router.

✅ This is useful: the community gains visibility into events that would otherwise remain hidden with standard BGP-based collection. For example, the hijacked route announced by P3 can now be detected—and its impact prevented.



Connect your router to bgproutes.io with BMP and start contribute data


Convinced that BMP provides much richer visibility than a plain BGP session? Ready to share your data with the community to help build more accurate BGP monitoring tools? The good news is that setting up a BMP connection with bgproutes.io is straightforward.

Step #1: Submit your connection details

Once authenticated with your PeeringDB account, simply click on the “Start peering with us!” button (top-right corner). This opens the form shown in Figure 4.

First, select BMP. Then choose the VM you want to connect to—we recommend the one with the lowest latency. For BGP, lower latency improves timestamp accuracy. For BMP, timestamps are set by the router itself, so latency is not an issue. Next, provide the IP address from which your router will establish the BMP session; we will use it to open the BMP port for that IP in our infrastructure. Finally, specify the ASN the router belongs to, as this—together with the IP you provided—helps us map the session to your ASN.

With some routers (e.g., FRRouting), it is not possible to select which peers’ routes are exported: BMP exports data for all peers (such as P1, P2, and P3 in Figure 3). However, for privacy or policy reasons you may want more control. The form therefore allows you to specify a list of ASNs whose data should not be collected. For example, in the scenario of Figure 3, if you exclude P1’s ASN, only routes from P2 and P3 will be collected.

Our system also automatically discards all data coming from peers with the same AS number specified in the form, as we do not collect routes received via iBGP.

Once the form is completed, click Submit and then Confirm. Our infrastructure will automatically prepare to connect to your router via BMP.

The final step is to configure your router. bgproutes.io listens on port 45678 for BMP sessions.

Note that connecting to bgproutes.io via BGP is still possible if you prefer.

BMP connection form
Figure 4 — The BMP connection form

Step #2: Configure BMP on your router

The good news is that BMP is fairly well supported—and support is improving over time. Configuration is usually straightforward, though the exact syntax and available feed types may vary across vendors. Here are two examples:

router bgp X
 bmp targets bmp1
  bmp connect 185.216.75.11 port 45678 min-retry 100 max-retry 10000 # 185.216.75.11 is the IP of one of our VMs.
  bmp stats 30000 # Interval at which to send statistics 
  bmp monitor ipv4 unicast pre-policy
  bmp monitor ipv6 unicast pre-policy
  bmp monitor ipv4 unicast loc-rib
  bmp monitor ipv6 unicast loc-rib
FRRouting. This configuration enables BMP for all peers and exports data for BMP feed types adj_in_pre (shown as pre-policy) and loc_rib for both IPv4 and IPv6. 
router bgp X
 neighbor X.X.X.X
  remote-as Y
  description ...
  bmp-activate server 1  # With Cisco, it must be explicitly specified when data for a peer should be exported through BMP
  address-family ipv4 unicast

bmp server 1
 host 185.216.75.11 port 45678 # 185.216.75.11 is the IP of one of our VMs.
 update-source ... # Specify the source IP/interface for the BMP session
 stats-reporting-period 60
Cisco. With Cisco, peers for which to export data over BMP must be explicitly specified. That’s why the command bmp-activate server 1 is required inside each neighbor X.X.X.X section of the BGP configuration.

BMP feed type recommendation

bgproutes.io supports all BMP feed types. However, for inter-domain route collection we highly recommend exporting the Pre-Policy Adj-RIB-In (adj_in_pre) feed type. This feed provides the full set of routes learned from peers, before any filtering or path selection, making it the most informative view. The adj_in_post feed can also be useful, though it may miss some routes that were filtered earlier in the process. The loc_rib feed is essentially equivalent to what a regular BGP session would reveal and therefore adds little beyond existing collection methods. Finally, the adj_out_pre and adj_out_post feeds are not recommended, as they introduce redundancy, hide non-preferred or filtered routes, and may enable users to infer your routing policies.

👉 In short: for the most valuable contribution, configure your router to export Pre-Policy Adj-RIB-In (adj_in_pre) for all you peers, if possible.




Monitor your sessions through the bgproutes.io interface


Once you have configured a BMP (or BGP) session, you can access the Your VPs page (top right — the button appears when clicking on the head icon) to view the details of all your sessions with bgproutes.io.

BMP information available in the "Your VPs" page
Figure 5 — Your BMP sessions as shown in the "Your VPs" page.

In addition to your BGP sessions (not shown in Figure 5), the page lists all your BMP sessions and displays the ASN and IP address on your side of the connection, as well as the IP address used by bgproutes.io. The page also shows the number of vantage points derived from each BMP session. In this example, the BMP session provides 10 vantage points, which can be explored in detail by clicking the “View the VPs” button.

Beyond your own BMP sessions, the page also displays BMP-derived vantage points that export routes from your AS but are not operated by your ASN. This happens, for example, when one of your neighbors configures a BMP session with bgproutes.io and exports routes it receives from your AS.

If you want to delete a BMP session, you can do so by clicking the “Delete” button, which removes the session from our infrastructure. Alternatively, you can simply deactivate the session on your router.




Data Access


At bgproutes.io, we follow a clear data-sharing policy: the data we collect is—and will remain—publicly available. Our goal is to make this platform genuinely useful for the community.

You can access the data using three interfaces:

  • MRT Archive — All collected routes are stored in an MRT archive at mrt.bgproutes.io, similar to what RIPE RIS or RouteViews provide. We also maintain the pybgproutesmrt Python library to make downloading, parsing, and processing this data straightforward with just a few lines of code.

  • Real-time Stream — Subscribe to our WebSocket server at wss://websocket.bgproutes.io to receive live BGP updates as they happen. With our pybgprouteslive Python library, you can get started in just a few lines of code.

  • 🚀API — Probably the most convenient option: our API gives you on-demand access to historical data (currently up to 7 days, soon to be extended to several months). The API (running at api.bgproutes.io) is nearly real-time (about a one-minute delay) and extremely fast—you can query data from hundreds of vantage points in seconds. This is the ideal way to fetch exactly the slice of data you need, without the overhead of processing large MRT dumps full of unrelated routes. We recommend using our pybgproutespi Python library to query the API easily with few lines of Python code.

No matter which access method you choose, the data is consistent across sources. Besides, whether it comes from traditional BGP sessions or from BMP-enabled routers, we provide the same core information: vantage points, BGP updates and RIB dumps.

Defining Vantage Points in BGP vs. BMP

When a router contributes data through a BGP session, the connected router itself is treated as a vantage point. Simple enough.

With BMP, things are different. A BMP-enabled router cannot be considered a single vantage point in the same way, because it provides a broader view than a plain BGP session. To keep our data-access interfaces consistent regardless of the source, we use the following approach:

  • BGP sessions → the router is the vantage point.
  • BMP sessions → each peer of the BMP-exporting router (e.g., P1, P2, P3 in Figures 1–4) is treated as a separate vantage point. For example, the BMP session in Figure 2 yields three vantage points. We say the exporting router is the parent of all VPs inferred from that BMP session.

For each BMP-derived vantage point, the updates and RIB entries include the usual BGP attributes, along with an additional feed type field. This distinction is crucial when a router exports multiple feed types through BMP, ensuring we can always identify the stage of the pipeline the data comes from.



How to Use the API


Here’s a quick overview of how to retrieve data effectively through our API—whether it comes from BGP or BMP vantage points.
For full details of all endpoints and parameters, and how to create an API key, please refer to our API documentation.
➡️ In our infrastructure, each BGP and BMP vantage point is assigned a unique ID, which is used to reference that VP when querying the API.

Endpoint: vantage_points

The vantage_points endpoint returns all the vantage points from which the platform collects data.
Recall that bgproutes.io doesn’t just rely on its own vantage points, but also aggregates data from RIPE RIS, RouteViews, PCH, and CGTF.

A simple request looks like this:

curl -X GET "https://api.bgproutes.io/vantage_points" \
     -H "accept: application/json" -H "x-api-key: test-key"
The response separates BGP and BMP vantage points. Each vantage point has an ID, and is described with metadata such as its IP, ASN, country, organization, and (for BMP) additional fields like the parent router ASN, parent IP, and feed types.

The vantage_points endpoint also supports powerful filtering options. For example, you can:

  • return only VPs from a specific country,
  • select VPs where the RIB size exceeds a given threshold,
  • or use the peering_protocol parameter to restrict results to either BGP or BMP VPs.
{
  "seconds": 0.0070421695709228516,
  "bytes": 68484,
  "data": {
    "bgp": [
      {
        "id": 1,
        "ip": "1.1.1.1",
        "asn": 10,
        "is_active": true,
        "source": "bgproutes.io",
        "rib_size_v4": 900000,
        "rib_size_v6": 0,
        "org_name": "Test Org",
        "org_country": "FR",
        "country": "FR"
      },
      ...
    ],
    "bmp": [
      {
        "id": 1,
        "ip": "1.1.1.1",
        "asn": 10,
        "is_active": true,
        "source": "bgproutes.io",
        "rib_size_v4": 900000,
        "rib_size_v6": 0,
        "org_name": "ISPX",
        "org_country": "FR",
        "country": "FR",
        "bmp_info": {
          "parent_asn": 56,
          "parent_ip": "34.32.1.1",
          "feed_types": [0, 1]
        }
      }
      ...
    ]
  }
}

Endpoint: rib

Once you have retrieved your vantage points, you can query their RIB at any point in time within the data retention window using the rib endpoint.

A simple request looks like this: In this example, we query the RIB for one BGP vantage point (ID 1) and two BMP vantage points (IDs 2 and 3), at a specific date, and restricted to the prefixes 8.0.10.0/16 and 8.0.0.0/24. 
curl -X GET "https://api.bgproutes.io/rib?\
    vp_bgp_ids=1&\
    vp_bmp_ids=2,3&\
    date=YOUR_DATE_HERE&\
    exact_prefix_match=8.0.10.0/16,8.0.0.0/24"\
     -H "accept: application/json" \
     -H "x-api-key: test-key"

The response contains two main parts:

  • Status information for each requested vantage point, indicating whether data was available at the specified time (e.g., a VP might be down or not exist).
  • The RIB data itself, returned as a list of entries per requested prefix. Each entry includes the AS path, communities, and the feed type (last field, represented as an integer—see our documentation for the mapping).
{
  "seconds": 0.0037958621978759766,
  "bytes": 24355,
  "info": {
    "bgp": {
      "1": "up"
    },
    "bmp": {
      "2": {
        "0": "up",
        "1": "ignored"
      },
      "3": {
        "0": "down"
      }
    }
  },
  "data": {
    "bgp": {
        "1": {
            "8.0.10.0/16": ["131477 3333 140096 3491 4637 1221", "123:245 3231:1242", -1],
            "8.0.0.0/24": ["131477 65511 140096 3333 9680 3462", "2345:234 2345: 233", -1],
            ...
        }
    },
    "bmp": {
        "2": {
            "8.0.10.0/16": ["156 789984 546 1263", "", 0],
            "8.0.0.0/24": ["156 789984 546 1263", "", 0],
            ...
        }
    }
  }
}

These two endpoints support many parameters, allowing you to build highly flexible queries. Our API also provides two additional endpoints: updates and topology. For details, see our full documentation.


Summary


Achieving high vantage point coverage is a real challenge. Convincing networks to connect to a collection platform and share their data is often daunting, and only a fraction agree to do so. In our quest for broader vantage point coverage, BMP opens new opportunities: a single BMP connection can deliver an order of magnitude more data compared to a single BGP session. We believe this is the right path forward.

Below is a table highlighting the advantages of BMP compared to standard BGP sessions for BGP routes collection.

BMPBGP
🔶 Supported by most routers, but not all (e.g., MikroTik)✅ Supported by all routers
✅ Simple to configure a session✅ Very simple to configure a session
✅ One session can provide data for dozens of vantage points❌ One session provides data for only one vantage point
✅ Provides all routes, including filtered or non-preferred ones❌ Only provides the non-filtered best routes

Since collecting inter-domain BGP data via BMP is still relatively new, we know there is still much to explore and understand. That’s why we will continue sharing our findings on social media (LinkedIn) and at operational conferences. And we’d love your feedback!
For any questions or comments, you can also contact us at contact@bgproutes.io.

Acknowledgements

We thank Randy Bush and Alarig Le Lay for agreeing to set up a testing BMP session with bgproutes.io, which allowed us to validate our implementation.