BGP Monitoring Protocol (BMP)
updated by
Extracted elements (31)
BMP was deliberately designed as a unidirectional push protocol (router to monitoring station only) with no handshaking phase to keep it simple, easily implemented, and minimally service-affecting. Prior to BMP, obtaining route views required screen scraping.
Route Monitoring messages use 'state compression': if multiple route changes occur before a message is transmitted, the router may send only the final state of a prefix. This means RM messages are not verbatim replicas of received BGP PDUs; Route Mirroring was added separately for implementations requiring full-fidelity message replay.
The A flag in the Per-Peer Header indicates whether AS_PATH is encoded in legacy 2-byte format (A=1) or 4-byte format (A=0, per RFC 6793). A BMP speaker MAY propagate AS_PATH as received or reformat to 4-byte; if reformatting, AS4_PATH or AS4_AGGREGATOR attributes SHOULD NOT be included in the BMP UPDATE message.
A BMP implementation MUST ignore unrecognized message types upon receipt, and MUST likewise ignore unrecognized stat types and unexpected data in the Stat Data field of Stats Reports.
BMP operates over TCP. No BMP message is ever sent from the monitoring station to the monitored router; the monitored router MAY take steps to prevent the monitoring station from sending data or MAY silently discard any data sent by the monitoring station.
For locally originated routes, since no transport session exists, the Local and Remote Port fields of the corresponding Peer Up message MUST be set to 0.
If the active party is unable to connect to the passive party, it periodically retries the connection. Retries MUST be subject to some variety of backoff; exponential backoff with a default initial value of 30 seconds and a maximum of 720 seconds is suggested.
If the router cannot provide receive-time information for routes, the BMP Timestamp field MUST be set to 0 to indicate that time is not available.
In the Initiation message, the sysDescr and sysName Information TLVs MUST be sent; all other TLV types are optional.
Once a router has sent a Termination message it MUST close the TCP session without sending any further messages. Likewise, the monitoring station MUST close the TCP session after receiving a Termination message.
Once it has sent all routes for a given peer, the router MUST send an End-of-RIB message for that peer; when End-of-RIB has been sent for each monitored peer, the initial table dump has completed.
Pre-policy routes MUST have the L flag clear in the BMP per-peer header; post-policy routes MUST have the L flag set. When a route is withdrawn, the withdraw MUST carry the same L flag value(s) as any previous announcement of that route.
Route Mirroring without state compression could require unbounded storage; its use is NOT RECOMMENDED except in cases where implementors have carefully considered the tradeoffs including router resource exhaustion and potential interference with BGP UPDATE transmission.
The router MUST restrict the rate at which BMP sessions may be established. It SHOULD also restrict the number of simultaneous connections from a given IP address, with a default of 1.
Upon a BMP session coming up, the router MUST begin by sending an Initiation message, then Peer Up messages for all monitored peers in the Established state, then the Adj-RIBs-In content encapsulated in Route Monitoring messages.
Version 0 in the BMP Common Header is reserved and MUST NOT be sent. All messages defined in this specification use Version 3.
The Peer Distinguisher (8 bytes in the Per-Peer Header) disambiguates peers across multiple router instances: zero-filled for Global Instance Peers, set to the VPN route distinguisher for RD Instance Peers, and set to a locally defined unique value for Local Instance Peers.
The Peer Down Notification carries a 1-byte Reason code (1=local closed with NOTIFICATION PDU, 2=local closed with FSM event code, 3=remote closed with NOTIFICATION PDU, 4=remote closed without notification, 5=peer de-configured) and optional data. A Peer Down implicitly withdraws all routes for that peer.
The Peer Flags field (1 byte) in the Per-Peer Header carries three defined flags: V (bit 0) indicates IPv6 peer address; L (bit 1) indicates post-policy Adj-RIB-In when set (pre-policy when clear); A (bit 2) indicates legacy 2-byte AS_PATH format when set. Remaining bits MUST be transmitted as 0.
IANA created 'BGP Monitoring Protocol (BMP) Parameters' registry group with BMP Message Types (0–6 defined; 0–127 Standards Action, 128–250 Specification Required, 251–254 Experimental, 255 Reserved) and BMP Peer Types (0–2 defined; same policy ranges).
IANA created registries for BMP Termination Message TLVs (Type 0=String, Type 1=Reason), BMP Termination Message Reason Codes (0=administratively closed, 1=unspecified, 2=out of resources, 3=redundant connection, 4=permanently closed), and BMP Peer Down Reason Codes (1–5 defined, 0 reserved).
IANA created registries for Route Mirroring TLVs (Type 0=BGP Message, Type 1=Information) and BMP Route Mirroring Information Codes (Code 0=Errored PDU, Code 1=Messages Lost), as well as BMP Peer Flags (Flags 0–2 defined, 3–7 unassigned, Standards Action policy).
IANA created the BMP Statistics Types registry with 14 defined types (0–13) covering inbound policy rejections, duplicate prefixes/withdraws, loop detections (CLUSTER_LIST, AS_PATH, ORIGINATOR_ID, AS_CONFED), and RIB size gauges (Adj-RIB-In, Loc-RIB, per-AFI/SAFI). Values 0–32767 Standards Action, 32768–65530 Specification Required.
BMP exposes the full contents of a router's BGP RIB and received messages, including routes in private contexts such as L3VPN. An attacker could infer the monitored router's import policy by comparing pre-policy routes exposed by BMP against post-policy routes exported in BGP. Implementations SHOULD require manual configuration of monitored and monitoring devices.
Without mutual-authentication transport, an attacker could masquerade as the monitored router to inject false BMP data or as the monitoring station to gain unauthorized access. Without confidentiality, BMP data is vulnerable to interception or tampering. IPsec in tunnel mode with pre-shared keys is recommended where these risks are a concern.
BMP session lifecycle: (1) TCP connect → send Initiation → send Peer Up per established BGP peer → send Route Monitoring (initial table dump) → send End-of-RIB per peer; (2) ongoing: incremental Route Monitoring, Peer Up on new sessions, Peer Down on teardowns, optional Stats Reports; (3) optional Termination message → TCP close.
The BMP Common Header contains: Version (1 byte, set to 3 for this spec), Message Length (4 bytes, total length including headers and encapsulated messages), and Message Type (1 byte identifying Route Monitoring=0, Statistics Report=1, Peer Down=2, Peer Up=3, Initiation=4, Termination=5, Route Mirroring=6).
The Information TLV used by Initiation and Peer Up messages consists of Information Type (2 bytes), Information Length (2 bytes), and variable-length Information field. Defined types: 0=String (UTF-8), 1=sysDescr (ASCII, equals MIB-II sysDescr), 2=sysName (ASCII, equals MIB-II sysName).
The Peer Up Notification contains: Local Address (16 bytes), Local Port (2 bytes), Remote Port (2 bytes), full Sent OPEN message, full Received OPEN message, and optional Information TLVs.
The Per-Peer Header contains: Peer Type (1 byte), Peer Flags (1 byte with V/L/A bits), Peer Distinguisher (8 bytes), Peer Address (16 bytes), Peer AS (4 bytes), Peer BGP ID (4 bytes), and Timestamp (seconds 4 bytes + microseconds 4 bytes since Unix epoch, zero if unavailable).
The Stats Report body contains a 4-byte Stats Count field followed by TLV-encoded counters, each with a 2-byte Stat Type, 2-byte Stat Len, and variable Stat Data field (32-bit counters for event counts, 64-bit gauges for RIB sizes).