How BMP Works: Real-Time BGP Route Monitoring Without CLI Scraping

BGP Monitoring Protocol (BMP) is a protocol defined in RFC 7854 that provides a structured, real-time mechanism for collecting BGP routing data from production routers without establishing a BGP session, scraping CLI output, or polling SNMP MIBs. BMP allows a router to stream its full Adj-RIB-In (the raw routes received from each peer, before and after policy), along with peer session state changes and statistical reports, to an external monitoring station over a persistent TCP connection. This gives network operators and route collection platforms -- including BGP looking glasses, security analytics systems, and traffic engineering tools -- unprecedented visibility into BGP routing dynamics as they happen, rather than minutes or hours after the fact.

Before BMP existed, operators who wanted to inspect what a router was receiving from its BGP peers had three options, all of them painful. They could log into the router's CLI and run show ip bgp neighbors X.X.X.X received-routes -- a manual, non-scalable process that puts load on the router's control plane. They could poll the bgp4-MIB via SNMP, which only exposes aggregate counters and peer state, not the actual routes. Or they could set up a dedicated iBGP session from the router to a route collector, which requires BGP configuration changes on the production router, consumes memory for an additional BGP neighbor, and still only delivers post-policy routes unless you configure the session with specific export policies. BMP was designed to solve all of these problems with a single, lightweight protocol purpose-built for route monitoring.

Why BMP Exists: The Problem with Existing Approaches

To understand BMP's design decisions, you need to understand why the older approaches fail at scale.

Screen scraping -- parsing CLI output from routers -- is fragile, vendor-specific, and puts load on the router's management plane. Each vendor has a different output format, different commands, and different quirks. Cisco IOS, IOS-XR, Junos, and EOS all format BGP table output differently. When a vendor updates its software, the output format can change and break your parsing scripts. Worse, every show command executed on a router consumes CPU cycles on the route processor, and walking the entire BGP table via CLI on a router with 900,000+ prefixes can take minutes and cause measurable control-plane impact.

SNMP polling via the bgp4-MIB (RFC 4273) provides structured data, but the MIB was never designed for full route table export. It exposes peer state (bgpPeerState), the number of established peers, and limited per-peer statistics, but walking the bgp4PathAttrTable to retrieve actual routes is extremely slow over SNMP (each route requires multiple GETNEXT/GETBULK operations) and puts significant CPU load on the router's SNMP agent. A full table walk via SNMP on a router with a full internet routing table can take 30+ minutes and generate millions of SNMP packets.

Dedicated iBGP sessions to route collectors (the approach used by projects like RouteViews and RIPE RIS) work but have operational overhead. Each monitoring session requires BGP configuration on the production router, consumes memory for the peer's RIB, and participates in the router's BGP update processing. More critically, a standard iBGP session only exports post-policy routes -- the routes the router has decided to use after applying import policies. If you want to see what the router's peers are actually advertising (pre-policy), you need either soft-reconfiguration inbound (which doubles memory usage) or route-refresh capability (which only gives you a snapshot, not a continuous stream).

BMP solves these problems by defining a simple, unidirectional protocol that runs alongside the router's BGP process. The router pushes data to the BMP station -- the station never sends commands or queries back. This means BMP cannot affect the router's routing decisions, cannot inject routes, and adds minimal overhead to the control plane. The router simply mirrors the BGP data it already has in memory to the BMP station over TCP.

BMP vs. Legacy BGP Monitoring Approaches Production Router BGP process, Adj-RIB-In, Loc-RIB, Adj-RIB-Out 900K+ prefixes Legacy Approaches CLI Scraping Fragile, vendor-specific SNMP bgp4-MIB Slow walks, no full RIB iBGP to Collector Post-policy only, config churn BMP (RFC 7854) BMP Station OpenBMP / pmacct / SNAS Receives all RIB data TCP push Pre- and post-policy RIB Unidirectional (read-only) Real-time streaming Minimal router overhead BMP replaces fragile, high-overhead legacy monitoring with a purpose-built streaming protocol

BMP Message Types

BMP defines six message types, each serving a specific role in the monitoring lifecycle. All BMP messages share a common header: a 1-byte version field (currently 3), a 4-byte message length, and a 1-byte message type. The simplicity of this framing is intentional -- BMP is designed to be trivial to parse at line rate.

Initiation Message (Type 5)

Sent once when the router first connects to the BMP station. The Initiation message contains informational TLVs (Type-Length-Value tuples) that identify the router: a sysDescr string (the same value exposed via SNMP's sysDescr.0), a sysName, and optionally a free-form string with additional information. This message lets the BMP station identify which router has connected without any out-of-band configuration. If a router reconnects after a TCP failure, the station can match the new connection to the existing router identity using these fields.

Peer Up Notification (Type 3)

Sent when a BGP peer transitions to the Established state, or for all currently-established peers when the BMP session is first set up. Each Peer Up message contains a Per-Peer Header that identifies the peer (peer IP address, peer AS, peer BGP ID, whether the peer is a pre-policy or post-policy monitoring target, the L3 VPN/VRF distinguisher if applicable, and a 64-bit timestamp). The message body includes the BGP OPEN messages exchanged between the router and the peer -- both the sent OPEN and the received OPEN. This is critical information: the OPEN messages reveal the negotiated capabilities (4-byte ASNs, multiprotocol extensions, add-path, graceful restart parameters) and the hold time, which the BMP station can use to correctly interpret subsequent Route Monitoring messages.

Peer Down Notification (Type 2)

Sent when a BGP peer session terminates. The message includes a reason code indicating why the session went down:

This level of detail is invaluable for debugging BGP session flaps. Instead of correlating syslog timestamps with show ip bgp summary output, the BMP station receives a machine-parseable record of exactly why and when each session went down, including the actual BGP NOTIFICATION message with its error code and subcode.

Route Monitoring (Type 0)

The core of BMP. Route Monitoring messages carry actual BGP UPDATE messages -- announcements and withdrawals -- as received from (or sent to) a BGP peer. Each Route Monitoring message wraps a standard BGP UPDATE inside a BMP header with the Per-Peer Header identifying which peer the update came from and whether it represents pre-policy or post-policy state.

When a BMP session is first established, the router dumps its entire Adj-RIB-In for each monitored peer as a series of Route Monitoring messages. This initial "table dump" gives the BMP station a complete snapshot of the routing table. After the dump completes, the router sends incremental Route Monitoring messages for every BGP UPDATE it receives -- in real time. The BMP station thus has a continuously-updated mirror of the router's Adj-RIB-In, tracking every route advertisement and withdrawal as it happens.

The fact that Route Monitoring messages contain raw BGP UPDATEs means the BMP station sees everything the router sees: the full AS path, all BGP communities (including large and extended communities), the NEXT_HOP, MULTI_EXIT_DISC, LOCAL_PREF, aggregator, and any other path attributes. No information is lost in translation -- BMP is not summarizing or abstracting the data, it is mirroring the actual protocol messages.

Statistics Report (Type 1)

Periodic statistical summaries about the router's BGP processing. Stats Reports contain a set of counter TLVs, each identified by a 16-bit stat type. Defined statistics include:

Stats Reports are typically sent at a configurable interval (every 5-60 seconds) and provide a lightweight way to monitor BGP health without parsing every Route Monitoring message. A sudden spike in rejected prefixes (Stat 0) or duplicate advertisements (Stat 1) is an immediate signal that something is wrong -- possibly a BGP hijack, a peer misconfiguration, or a route leak.

Route Mirroring (Type 6)

Route Mirroring is the most specialized BMP message type. While Route Monitoring carries parsed BGP UPDATEs for routes the router has processed and installed, Route Mirroring captures raw BGP messages -- including malformed or unrecognized messages that the router would normally discard. This is critical for debugging interoperability issues and for forensic analysis: if a peer sends a BGP message that the router cannot parse, the Route Monitoring stream would simply not include it (since no route was installed), but Route Mirroring captures the raw bytes for offline analysis.

Route Mirroring also captures BGP KEEPALIVE and other non-UPDATE messages, providing a complete record of the BGP session's wire protocol. This makes it useful for protocol conformance testing and for investigating subtle BGP implementation bugs.

Adj-RIB-In: Pre-Policy vs. Post-Policy

One of BMP's most important capabilities is the ability to expose both pre-policy and post-policy views of the Adj-RIB-In. This distinction is fundamental to understanding BGP operations and is something no other monitoring approach provides cleanly.

The Adj-RIB-In pre-policy contains every route received from a peer, exactly as advertised, before the router's import policy has been applied. This includes routes that will ultimately be rejected by the router's route filters -- routes with invalid RPKI origin validation, routes matching a deny filter, routes with excessively long AS paths, or routes for prefixes the router has been configured to ignore. Seeing pre-policy data is essential for security monitoring: you need to know what your peers are sending you, not just what you are accepting.

The Adj-RIB-In post-policy shows routes after import policy has been applied -- the routes that survived filtering and are candidates for the BGP best path selection process. This view corresponds to what a standard iBGP route collector session would see.

The Per-Peer Header in every BMP message includes a flag (the "L" bit) that indicates whether the message represents pre-policy or post-policy data. A BMP station can receive both views simultaneously, enabling powerful analytics: "Peer X is advertising 1,200 routes for prefixes that match our deny list -- that is 3x the normal rate, which might indicate the peer has been compromised or misconfigured."

Loc-RIB Monitoring (RFC 9069)

The original BMP specification (RFC 7854) focused on Adj-RIB-In -- the routes received from peers. RFC 9069 extends BMP to also export the Loc-RIB -- the router's local routing information base, containing the best paths selected by the BGP decision process. This is the set of routes the router actually uses for forwarding and (for eBGP speakers) advertises to its own peers.

Loc-RIB monitoring fills an important gap. With only Adj-RIB-In data, a BMP station can see what routes the router received, but not which route won the best path selection for each prefix. The Loc-RIB view shows exactly which paths the router selected and why -- including the LOCAL_PREF, MED, IGP metric to the next-hop, and other tie-breaking attributes. This is essential for traffic engineering analysis: understanding why traffic takes a particular path requires knowing the winner of the best path selection, not just the candidates.

RFC 9069 also introduces a Peer Up message for the Loc-RIB itself, using a special "Loc-RIB instance" peer type. The Peer Up message for a Loc-RIB includes information about the router's BGP configuration -- the router ID, the cluster ID (if the router is a route reflector), and the address families the Loc-RIB covers. When a route in the Loc-RIB changes (because a better path was selected, or the current best path was withdrawn), the router sends a Route Monitoring message with the Loc-RIB peer type, containing the new best path or the withdrawal.

The BMP Session Lifecycle

A BMP session starts when the router opens a TCP connection to the configured BMP station (typically on port 11019, the IANA-assigned port for BMP, though any port can be used). The direction of the TCP connection is a key design decision: the router initiates the connection to the station, not the other way around. This means the station does not need to know about the router in advance, and firewalls only need to allow outbound connections from the router. Some implementations also support a "passive" mode where the station listens and the router connects, or an "active" mode where the station initiates the TCP connection to the router.

Once the TCP connection is established, the session proceeds through these phases:

  1. Initiation: The router sends an Initiation Message identifying itself.
  2. Peer Up dump: For each currently-established BGP peer that is configured for BMP monitoring, the router sends a Peer Up Notification.
  3. RIB dump: For each monitored peer, the router sends the complete Adj-RIB-In (pre-policy, post-policy, or both) as a series of Route Monitoring messages. On a router with a full internet routing table from multiple peers, this initial dump can consist of millions of Route Monitoring messages and take several minutes to complete.
  4. Steady-state streaming: After the initial dump, the router sends incremental updates -- Route Monitoring messages for every BGP UPDATE received, Peer Up/Down notifications for session state changes, and periodic Stats Reports.

If the TCP connection to the BMP station drops, the router buffers messages (up to a configurable limit) and attempts to reconnect. When the connection is re-established, the router performs a fresh initial dump to resynchronize the station's state. There is no delta/diff mechanism -- the station must rebuild its view from the full dump on every reconnection. This simplifies the protocol at the cost of increased bandwidth during reconnection events.

BMP Stations and Collectors

A BMP station (or collector) is the software that receives, parses, stores, and analyzes BMP data from routers. Several open-source and commercial BMP station implementations exist:

OpenBMP is the most widely deployed open-source BMP collector. Developed by Cisco engineers and released as an open-source project, OpenBMP parses BMP messages, stores the data in Apache Kafka topics and PostgreSQL/TimescaleDB, and provides REST APIs for querying. OpenBMP can handle data from hundreds of routers simultaneously, processing millions of Route Monitoring messages per second. It normalizes the raw BMP data into structured tables: a peer state table, a RIB table (with one row per prefix per peer), a prefix update history table, and an AS path analysis table.

pmacct (specifically the pmbmpd daemon) is a versatile network data collection framework that includes BMP support. pmacct can receive BMP data and export it to multiple backends -- Kafka, RabbitMQ, Elasticsearch, and flat files -- making it a flexible building block for custom monitoring pipelines. It is particularly popular in research environments and at IXPs where BMP data needs to feed into existing data analysis infrastructure.

GoBMP is a lightweight BMP receiver written in Go, designed as a Kafka producer. It parses BMP messages and publishes structured JSON to Kafka topics, where downstream consumers can process the data for various use cases. GoBMP's simplicity and low resource requirements make it suitable for edge deployments and lab environments.

RIPE RIS (Routing Information Service) uses BMP as one of its primary data collection mechanisms. RIS route collectors, deployed at major Internet exchange points worldwide, receive BGP data via BMP from participating networks and make it available through the RIS Live streaming API and RISwhois lookup service. When you query a BGP looking glass that uses RIS data, you are indirectly consuming data that was collected via BMP.

BMP Collection and Analysis Pipeline BGP Routers Edge Router 1 Edge Router 2 Core Router Route Reflector BMP/TCP BMP Collector OpenBMP / pmacct Parse, normalize, stream Kafka / Message Bus Consumers Route Analytics AS path analysis, prefix tracking Security Monitoring Hijack detection, RPKI validation Traffic Engineering Best path analysis, Loc-RIB Historical Archive TimescaleDB, Elasticsearch BMP stream (TCP) Kafka distribution

BMP on the Wire: Protocol Details

BMP runs over TCP, which provides reliable, ordered delivery. Unlike SNMP (which uses UDP) or NetFlow (also UDP), BMP guarantees that every message arrives and arrives in order. This is a deliberate choice: losing a route withdrawal could leave the BMP station with a stale route in its RIB, creating a false view of the routing table. TCP's reliability eliminates this class of errors.

The BMP common header is minimal:

BMP Common Header (6 bytes):
  Version:      1 byte  (currently 3)
  Message Length: 4 bytes (including the header)
  Message Type:  1 byte  (0-6)

Per-Peer Header (42 bytes, present in types 0-3):
  Peer Type:     1 byte  (0=Global, 1=RD Instance, 2=Local)
  Peer Flags:    1 byte  (V=IPv6, L=post-policy, A=Adj-RIB-Out)
  Peer Distinguisher: 8 bytes (VPN RD, or zero)
  Peer Address:  16 bytes (IPv4-mapped or IPv6)
  Peer AS:       4 bytes  (4-byte ASN)
  Peer BGP ID:   4 bytes  (BGP router ID)
  Timestamp:     8 bytes  (seconds + microseconds)

The Per-Peer Header is 42 bytes and appears in Route Monitoring, Statistics Report, Peer Up, and Peer Down messages. It uniquely identifies the BGP peer and the monitoring context (pre/post-policy, address family, VRF) for each message. The timestamp in the Per-Peer Header records when the BGP event occurred on the router, not when the BMP message was sent -- this is important for accurate event ordering when the BMP station processes messages from multiple routers with different network latencies.

BMP vs. BGP Session Tap

A common question is how BMP compares to simply tapping the BGP session between two routers -- either by port-mirroring the TCP session or by inserting a transparent BGP proxy between them. BMP is fundamentally different from a session tap in several important ways:

Use Cases: Why Operators Deploy BMP

Route Analytics and Visibility

The primary use case for BMP is comprehensive route visibility. Network operators deploy BMP to answer questions like: "What routes are we receiving from each transit provider? How do those routes differ before and after policy? How many prefixes from each peer are we actually accepting? How does the Adj-RIB-In from each peer change over time?" These questions are fundamental to capacity planning, cost optimization (transit vs. peering economics), and troubleshooting reachability issues.

With BMP data flowing into a time-series database, operators can build dashboards showing BGP table growth trends, per-peer prefix counts, community distribution, and AS path length histograms. They can alert on anomalies: "Peer X just started advertising 50,000 new prefixes in the last 5 minutes" or "Our total Adj-RIB-In grew by 10% in an hour." This kind of trend analysis is impossible with point-in-time CLI queries and prohibitively expensive with SNMP polling.

BGP Hijack and Route Leak Detection

BMP's real-time streaming of pre-policy routes makes it a powerful tool for detecting BGP hijacks and route leaks. A security monitoring system connected to a BMP feed can compare incoming route announcements against known-good baselines: if a prefix is suddenly announced with a different origin AS, or if an AS appears in the path that has never been seen there before, the system can raise an alert within seconds.

The pre-policy view is particularly important for security monitoring. A well-configured router will filter hijacked routes via RPKI ROV or prefix-list filters, so post-policy data would not show the attack. But the pre-policy Adj-RIB-In shows everything the peer is sending, including malicious announcements that the router correctly rejects. This lets the security team detect that an attack is underway even though their network is protected -- and alert the operators of the victimized network.

RPKI Validation Monitoring

BMP data enables operators to monitor RPKI deployment and validation effectiveness across their network. By comparing pre-policy routes against the RPKI ROA database, a BMP-fed analytics platform can report: what percentage of received routes have valid ROAs, how many RPKI-invalid routes are being received from each peer, and whether those invalid routes are being correctly filtered by the router's import policy (verified by comparing pre-policy vs. post-policy state).

Internet Exchange Point Route Servers

IXP route servers are ideal BMP deployment targets. A route server at a major IXP might peer with hundreds of networks, making it a natural aggregation point for BGP data. By enabling BMP on the route server, the IXP operator gets complete visibility into what every participant is advertising, which routes the route server is accepting and distributing, and how policy is being applied. Several large IXPs (including DE-CIX, AMS-IX, and LINX) use BMP for internal monitoring and for contributing data to global routing analysis projects.

Network Automation and SDN

BMP feeds provide the real-time routing state data that SDN controllers and network automation systems need to make intelligent decisions. A controller that receives BMP data from all edge routers has a complete view of the network's BGP state and can programmatically adjust routing policy, shift traffic between transit providers, or trigger failover procedures based on observed routing changes. This is more reliable than polling: the controller sees events as they happen, not on a 5-minute polling cycle.

Router Configuration Examples

Configuring BMP on a router is straightforward. Here are examples for the major platforms:

! Cisco IOS-XR
bmp server 1
  host 10.0.0.100 port 11019
  description "BMP to OpenBMP collector"
  update-source Loopback0
  initial-delay 30
  stats-reporting-period 60
  !
router bgp 64500
  neighbor 192.0.2.1
    bmp-activate server 1

# Juniper Junos
routing-options {
    bmp {
        station collector1 {
            station-address 10.0.0.100;
            station-port 11019;
            local-address 10.0.0.1;
            connection-mode active;
            statistics-timeout 60;
            route-monitoring {
                pre-policy;
                post-policy;
            }
        }
    }
}

# Arista EOS
router bgp 64500
  neighbor 192.0.2.1 bmp
  !
  bmp station 1
    url 10.0.0.100 port 11019
    local-interface Loopback0
    stats-reporting-period 60

Note the simplicity: in most cases, enabling BMP requires defining a BMP station (IP address and port) and activating it on the desired BGP neighbors. The router handles the initial RIB dump, incremental updates, reconnection logic, and message framing automatically. There is no need to configure BGP export policies, create peer groups, or modify the router's forwarding behavior in any way.

Scalability Considerations

BMP generates significant data volume. A router with 10 eBGP peers, each providing a full internet routing table (~950,000 prefixes as of 2024), will produce an initial dump of roughly 10 million Route Monitoring messages per BMP session establishment -- about 3-5 GB of raw BMP data. In steady state, the global BGP table experiences roughly 5-15 million UPDATE messages per day, and each update on each monitored peer generates a BMP Route Monitoring message.

Scalability strategies for BMP deployments include:

BMP in the Route Collection Ecosystem

BMP has become a key building block in the global routing data collection infrastructure that powers BGP looking glasses and routing security services. RIPE NCC's RIS project uses BMP alongside traditional BGP sessions for route collection. The data feeds from RIS are used by researchers, network operators, and security teams worldwide to analyze BGP routing dynamics, detect anomalies, and measure the growth of the internet routing table.

The relationship between BMP and traditional route collection via BGP sessions is complementary. BGP sessions to route collectors (as used by RouteViews) provide post-policy routes from the collector's perspective. BMP provides pre-policy and post-policy routes from the monitored router's perspective. Both views are valuable: the route collector's BGP session shows what routes are propagating across the internet, while BMP shows what individual routers are receiving from their peers before any filtering is applied.

For operators building their own monitoring infrastructure, the typical architecture combines BMP for real-time BGP data collection with NetFlow/sFlow for traffic flow analysis and SNMP for device health metrics. BMP tells you what routes exist; NetFlow tells you how much traffic each route carries; SNMP tells you whether the router processing those routes is healthy. Together, these three protocols provide a comprehensive view of network operations.

BMP Extensions and Future Development

The IETF's GROW (Global Routing Operations) working group continues to develop BMP extensions. Active work includes:

See It in Action

BMP is the protocol that makes modern BGP monitoring possible. Every time you query a BGP looking glass and see the routes advertised for a prefix, the AS paths through the internet, or the origin validation status of a route, you are likely looking at data that was collected via BMP from route collectors peered at internet exchange points around the world. The pre-policy visibility that BMP provides is what enables route collection projects to capture the full picture of BGP routing -- including the advertisements that routers filter and reject.

Use the god.ad BGP Looking Glass to explore BGP routing data collected from global route collectors. Look up any IP address or autonomous system to see the BGP routes, AS paths, and origin validation status -- the kind of data that BMP was designed to collect and stream in real time.

See BGP routing data in real time

Open Looking Glass
More Articles
What is BGP? The Internet's Routing Protocol Explained
What is an Autonomous System (AS)?
What is a BGP Looking Glass?
How to Look Up an IP Address's BGP Route
Understanding BGP AS Paths
What is RPKI? Securing BGP Routing