RFC 7854

BGP Monitoring Protocol (BMP)

📅 published June 2016, from ietf

BGP Monitoring Protocol (BMP) 🦋

Okay bestie, let's get into RFC 7854! 💖 It's a Standards Track spec from June 2016 (ISSN 2070-1721). Its authors are J. Scudder (Ed.) from Juniper Networks, R. Fernando from Cisco Systems, and S. Stuart from Google, and the title block doesn't list anything it obsoletes or updates. It's not the first word on the topic, just the first standard for it. 🌸

Abstract ✨

Okay so this doc defines the BGP Monitoring Protocol (BMP), which lets you monitor BGP sessions. 👀 BMP is meant to be a super convenient way to grab route views. Before BMP showed up, people basically screen scraped to get that info, which was the most common approach, and honestly giving it "screen scraping" energy is so real. 💀 The design goals are to keep BMP simple, useful, easy to implement, and minimally service affecting. And the big plot twist: BMP is not suitable for use as a routing protocol. 🙅‍♀️

Status of This Memo

This is an Internet Standards Track document. 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG). 🫶 If you want more on Internet Standards, check out Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7854. 🍓

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, bestie, because they spell out your rights and restrictions for this doc. 📜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without getting an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🌈

Table of Contents 📚

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview of BMP Operation . . . . . . . . . . . . . . . . . .   4
     3.1.  BMP Messages  . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Connection Establishment and Termination  . . . . . . . .   5
     3.3.  Lifecycle of a BMP Session  . . . . . . . . . . . . . . .   6
   4.  BMP Message Format  . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Common Header . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Per-Peer Header . . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Initiation Message  . . . . . . . . . . . . . . . . . . .  10
     4.4.  Information TLV . . . . . . . . . . . . . . . . . . . . .  10
     4.5.  Termination Message . . . . . . . . . . . . . . . . . . .  11
     4.6.  Route Monitoring  . . . . . . . . . . . . . . . . . . . .  12
     4.7.  Route Mirroring . . . . . . . . . . . . . . . . . . . . .  12
     4.8.  Stats Reports . . . . . . . . . . . . . . . . . . . . . .  13
     4.9.  Peer Down Notification  . . . . . . . . . . . . . . . . .  16
     4.10. Peer Up Notification  . . . . . . . . . . . . . . . . . .  17
   5.  Route Monitoring  . . . . . . . . . . . . . . . . . . . . . .  18
   6.  Route Mirroring . . . . . . . . . . . . . . . . . . . . . . .  19
   7.  Stat Reports  . . . . . . . . . . . . . . . . . . . . . . . .  19
   8.  Other Considerations  . . . . . . . . . . . . . . . . . . . .  20
     8.1.  Multiple Instances  . . . . . . . . . . . . . . . . . . .  20
     8.2.  Locally Originated Routes . . . . . . . . . . . . . . . .  20
   9.  Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     10.1.  BMP Message Types  . . . . . . . . . . . . . . . . . . .  21
     10.2.  BMP Peer Types . . . . . . . . . . . . . . . . . . . . .  21
     10.3.  BMP Peer Flags . . . . . . . . . . . . . . . . . . . . .  22
     10.4.  BMP Statistics Types . . . . . . . . . . . . . . . . . .  22
     10.5.  BMP Initiation Message TLVs  . . . . . . . . . . . . . .  23
     10.6.  BMP Termination Message TLVs . . . . . . . . . . . . . .  23
     10.7.  BMP Termination Message Reason Codes . . . . . . . . . .  23
     10.8.  BMP Peer Down Reason Codes . . . . . . . . . . . . . . .  24
     10.9.  Route Mirroring TLVs . . . . . . . . . . . . . . . . . .  24
     10.10. BMP Route Mirroring Information Codes  . . . . . . . . .  24
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  25
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     12.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1. Introduction ✨

Okay so tons of researchers and network operators want to see what's in a router's BGP Routing Information Bases (RIBs), plus the protocol updates the router is getting. 👑 The standard protocol mechanisms just can't do this monitoring job, and before BMP the only option was screen scraping. 😭

BMP gives you ongoing access to a peer's Adj-RIB-In, plus a periodic dump of certain stats the monitoring station can analyze. 💅 Basically, BMP is what you get when you multiplex together the messages from all the monitored BGP sessions. It's giving "one inbox for everything" 🧚

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🎀 These are the official keywords, so they're the ones you have to pay attention to!

2. Definitions 🌸

  • Adj-RIB-In: As defined in [RFC4271], "The Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers." This is also referred to as the pre-policy Adj-RIB-In in this document. 🍓
  • Post-Policy Adj-RIB-In: The result of applying inbound policy to an Adj-RIB-In, but prior to the application of route selection to form the Loc-RIB. ✨

3. Overview of BMP Operation 🦋

3.1. BMP Messages

Here are the messages BMP provides, bestie:

  • Route Monitoring (RM): Used to provide an initial dump of all routes received from a peer, plus an ongoing mechanism that sends the incremental routes advertised and withdrawn by a peer to the monitoring station. 📬
  • Peer Down Notification: A message sent to indicate that a peering session has gone down, with info about the reason for the session disconnect. 💀
  • Stats Reports (SR): An ongoing dump of statistics the monitoring station can use as a high-level indication of the activity going on in the router. 📊
  • Peer Up Notification: A message sent to indicate that a peering session has come up. It includes info about the data exchanged between the peers in their OPEN messages, as well as info about the peering TCP session itself. On top of being sent whenever a peer transitions to the Established state, a Peer Up Notification is also sent for each peer in the Established state when the BMP session itself comes up. 🌈
  • Initiation: A way for the monitored router to tell the monitoring station its vendor, software version, and so on. 🧸
  • Termination: A way for the monitored router to tell the monitoring station why it's closing a BMP session. 👋
  • Route Mirroring: A way for the monitored router to send verbatim duplicates of messages as they were received. It can be used to exactly mirror a monitored BGP session, and it can also be used to report malformed BGP Protocol Data Units (PDUs). 🪞

3.2. Connection Establishment and Termination

Okay, the big one: BMP runs over TCP. 🔌 All the options are controlled by configuration on the monitored router. No BMP message is ever sent from the monitoring station to the monitored router, so the router is the one talking and the station is the one listening. The monitored router MAY take steps to stop the monitoring station from sending data (for example, by half-closing the TCP session or setting its window size to 0), or it MAY silently discard any data the monitoring station sends. 🙈

A router can be watched by one or more monitoring stations. For each (router and monitoring station) pair, one party is active when it comes to TCP session establishment, and the other party is passive. Which one is active and which is passive is controlled by configuration. 🎭

The passive party is configured to listen on a particular TCP port, and the active party is configured to connect to that port. If the active party can't connect to the passive party, it keeps retrying on a schedule. Retries MUST be subject to some variety of backoff. Exponential backoff with a default initial backoff of 30 seconds and a maximum of 720 seconds is suggested. ⏳ Patience is a whole vibe.

The router MAY restrict the set of IP addresses it will accept connections from. It SHOULD restrict the number of simultaneous connections it will allow from a given IP address. The default value for this restriction SHOULD be 1, though an implementation MAY let you disable this restriction in configuration. The router MUST also restrict the rate at which sessions can be established. A suggested default is an establishment rate of 2 sessions per minute. 🚦 Boundaries are iconic.

A router (or management station) MAY implement logic to detect redundant connections, like the ones that could happen if both parties are configured to be active, and it MAY elect to terminate those redundant connections. A Termination reason code is defined for this purpose. ✂️

Once a connection is established, the router sends messages over it. There's no initialization or handshaking phase. Messages are simply sent as soon as the connection is up. 🚀 No small talk, just vibes and data.

If the monitoring station wants to end or restart BMP processing, it simply drops the connection. 👋🏼 Bye bye, no drama.

3.3. Lifecycle of a BMP Session ✨

okay so a router gets configured to talk BMP to one or more monitoring stations 🖥️. It MAY be set up to send monitoring info for only a subset of its BGP peers 🎀. If it isn't, all BGP peers are assumed to be monitored, so everyone's invited to the party 🥳.

A BMP session starts when the active party (either the router or the management station, whichever one the configuration says) successfully opens a TCP session (the "BMP session") 🦋. Once it's up, the router starts sending BMP messages. It MUST begin by sending an Initiation message 💌. Then it sends a Peer Up message over the BMP session for each of its monitored BGP peers that's in the Established state 🌸. After that, it follows up with the contents of its Adj-RIBs-In (pre-policy, post-policy, or both, see Section 5) wrapped up in Route Monitoring messages 📦. Once it has sent all the routes for a given peer, it MUST send an End-of-RIB message for that peer. When End-of-RIB has gone out for each monitored peer, the initial table dump is complete ✅. (A monitoring station that only wants to gather a table dump could close the connection once it has gathered an End-of-RIB or Peer Down message corresponding to each Peer Up message 🙈.)

After the initial table dump, the router sends incremental updates encapsulated in Route Monitoring messages 💅. It MAY periodically send Stats Reports or even new Initiation messages, depending on configuration 📊. If any new monitored BGP peer becomes Established, a matching Peer Up message is sent 🆙. If any BGP peers that got Peer Up messages transition out of the Established state, the matching Peer Down messages are sent 📉.

A BMP session ends when the TCP session carrying it is closed for any reason 🥀. The router MAY send a Termination message before closing the session 👋.

4. BMP Message Format 🎀

4.1. Common Header

the common header shows up in all BMP messages 🫶. The rest of the data in a BMP message depends on the Message Type field in the common header 🧠.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+
  |    Version    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Message Length                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Msg. Type   |
  +---------------+
  • Version (1 byte): Indicates the BMP version. This is set to '3' for all messages defined in this specification. ('1' and '2' were used by draft versions of this document.) Version 0 is reserved and MUST NOT be sent. 🚫
  • Message Length (4 bytes): Length of the message in bytes (including headers, data, and encapsulated messages, if any) 📏.
  • Message Type (1 byte): This identifies the type of the BMP message. A BMP implementation MUST ignore unrecognized message types upon receipt 🙉.
    • Type = 0: Route Monitoring
    • Type = 1: Statistics Report
    • Type = 2: Peer Down Notification
    • Type = 3: Peer Up Notification
    • Type = 4: Initiation Message
    • Type = 5: Termination Message
    • Type = 6: Route Mirroring Message

4.2. Per-Peer Header

the per-peer header comes right after the common header for most BMP messages 💁‍♀️. The rest of the data still depends on the Message Type field in the common header, same as before 🔁.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Peer Type   |  Peer Flags   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Peer Distinguisher (present based on peer type)       |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Peer Address (16 bytes)                       |
  ~                                                               ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Peer AS                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Peer BGP ID                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Timestamp (seconds)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Timestamp (microseconds)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Peer Type (1 byte): Identifies the type of peer. Currently, three types of peers are identified 🏷️:
    • Peer Type = 0: Global Instance Peer
    • Peer Type = 1: RD Instance Peer
    • Peer Type = 2: Local Instance Peer
  • Peer Flags (1 byte): These flags give you more info about the peer 🚩. The flags are defined as follows:
                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |V|L|A| Reserved|
                         +-+-+-+-+-+-+-+-+
  • The V flag indicates that the Peer address is an IPv6 address. For IPv4 peers, this is set to 0 🌐.
  • The L flag, if set to 1, indicates that the message reflects the post-policy Adj-RIB-In (i.e., its path attributes reflect the application of inbound policy). It is set to 0 if the message reflects the pre-policy Adj-RIB-In. Locally sourced routes also carry an L flag of 1. See Section 5 for further detail. This flag has no significance when used with route mirroring messages (Section 4.7) 🪞.
  • The A flag, if set to 1, indicates that the message is formatted using the legacy 2-byte AS_PATH format. If set to 0, the message is formatted using the 4-byte AS_PATH format [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH information as received from its peer, or it MAY choose to reformat all AS_PATH information into a 4-byte format regardless of how it was received from the peer. In the latter case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be sent in the BMP UPDATE message. This flag has no significance when used with route mirroring messages (Section 4.7) 🧩.
  • The remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt 🔒.
  • Peer Distinguisher (8 bytes): Routers today can have multiple instances (example: Layer 3 Virtual Private Networks (L3VPNs) [RFC4364]). This field is present to tell apart peers that belong to one address domain from the ones in another 🗂️.

If the peer is a "Global Instance Peer", this field is zero-filled. If the peer is a "RD Instance Peer", it is set to the route distinguisher of the particular instance the peer belongs to. If the peer is a "Local Instance Peer", it is set to a unique, locally defined value. In all cases, the effect is that the combination of the Peer Type and Peer Distinguisher is enough to disambiguate peers whose other identifying info might overlap 💖.

  • Peer Address: The remote IP address associated with the TCP session over which the encapsulated PDU was received. It is 4 bytes long if an IPv4 address is carried in this field (with the 12 most significant bytes zero-filled), and 16 bytes long if an IPv6 address is carried in this field 🌍.
  • Peer AS: The Autonomous System number of the peer from which the encapsulated PDU was received. If a 16-bit AS number is stored in this field [RFC6793], it should be padded with zeroes in the 16 most significant bits 🔢.
  • Peer BGP ID: The BGP Identifier of the peer from which the encapsulated PDU was received 🪪.
  • Timestamp: The time when the encapsulated routes were received (one may also think of this as the time when they were installed in the Adj-RIB-In), expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). If zero, the time is unavailable. Precision of the timestamp is implementation-dependent ⏰.

4.3. Initiation Message 💌

the initiation message is how the monitored router tells the monitoring station about itself, like its vendor, software version, and so on 🪪✨. An initiation message MUST be sent as the first message after the TCP session comes up 🥇. An initiation message MAY be sent at any point after that, if a change on the monitored router makes it worthwhile 🔄.

The initiation message is made of the common BMP header followed by two or more Information TLVs (Section 4.4) with info about the monitored router. The sysDescr and sysName Information TLVs MUST be sent, and any others are optional 💁‍♀️. The string TLV MAY be included multiple times 🧵.

4.4. Information TLV 🏷️

the Information TLV is used by the Initiation (Section 4.3) and Peer Up (Section 4.10) messages 🫶.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Information Type     |       Information Length      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Information (variable)                        |
  ~                                                               ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Information Type (2 bytes): Type of information provided. Defined types are 🗃️:
    • Type = 0: String. The Information field contains a free-form UTF-8 string whose length is given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with a null (or any other particular) character. The Information Length field gives its termination. If multiple strings are included, their ordering MUST be preserved when they are reported 🧶.
    • Type = 1: sysDescr. The Information field contains an ASCII string whose value MUST be set to be equal to the value of the sysDescr MIB-II [RFC1213] object 📝.
    • Type = 2: sysName. The Information field contains an ASCII string whose value MUST be set to be equal to the value of the sysName MIB-II [RFC1213] object 🏠.
  • Information Length (2 bytes): The length of the following Information field, in bytes 📏.
  • Information (variable): Information about the monitored router, according to the type 💅.

4.5. Termination Message 🎀

okay so the termination message is how a monitored router says "bye, here's why" before it leaves the session 👋 Sending it is RECOMMENDED, but the monitoring station always has to be ready for the session to just drop with no message at all 💀 Once the router sends one, it MUST close the TCP session and send nothing else. And the monitoring station MUST close the TCP session after it gets one too 🫶

The message is the common BMP header followed by one or more TLVs that explain the reason for the termination:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Information Type     |       Information Length      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Information (variable)                        |
  ~                                                               ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown 🧚

  • Information Type (2 bytes): this tells you what kind of info is in there. The defined types are:
    • Type = 0: String 📝 The Information field holds a free-form UTF-8 string, and its length comes from the Information Length field. Including this TLV is optional, so it's a nice-to-have. It MAY be used to give extra detail for any of the defined reasons, and Multiple String TLVs MAY be included in the message.
    • Type = 1: Reason 🚪 The Information field has a 2-byte code for why the connection got terminated. Some reasons come with extra TLVs. Including this TLV is REQUIRED, no skipping allowed. The defined reasons are:
      • Reason = 0: Session administratively closed. The session might be re-initiated 🔁
      • Reason = 1: Unspecified reason 🤷‍♀️
      • Reason = 2: Out of resources. The router has used up the resources it had for the BMP session 🪫
      • Reason = 3: Redundant connection. The router has figured out this connection is a duplicate of another one 👯
      • Reason = 4: Session permanently administratively closed, will not be re-initiated. The monitoring station should slow down (potentially all the way to 0) how often it tries to reconnect to the monitored router 🛑
  • Information Length (2 bytes): the length of the Information field that comes next, in bytes.
  • Information (variable): info about the monitored router, depending on the type 💜

4.6. Route Monitoring 🌸

Route Monitoring messages do two jobs: they handle the initial sync of the ADJ-RIBs-In, and they keep watching the ADJ-RIB-In state after that. They're state-compressed, which is a whole vibe we'll unpack more in Section 5 🦋

Following the common BMP header and per-peer header is a BGP Update PDU ✨

4.7. Route Mirroring 🪞

Route Mirroring messages are for copying messages verbatim, exactly as they were received 👀 One use is mirroring one or more monitored BGP sessions exactly, without state compression. Another use is mirroring messages that got treated-as-withdraw [RFC7606], which is super handy for debugging 🔍 Mirrored messages may be sampled, or they may be lossless. The Messages Lost information code exists so losses can be flagged 🚨 Section 6 has more detail on all of this.

Following the common BMP header and per-peer header is a set of TLVs with info about a message or a bunch of messages. Each TLV is made of a 2-byte type code, a 2-byte length field, and a variable-length value. Including any given TLV is OPTIONAL, however at least one TLV SHOULD be included, because otherwise, honestly, why send the message at all? 🙃 The defined TLVs are:

  • Type = 0: BGP Message 📦 A BGP PDU. This PDU may or may not be an Update message. If the BGP Message TLV shows up in a Route Mirroring message, it MUST occur last in the list of TLVs.
  • Type = 1: Information 🏷️ A 2-byte code with info about the mirrored message or message stream. The defined codes are:
    • Code = 0: Errored PDU. The contained message was found to have some error that made it unusable, so it got treated-as-withdraw [RFC7606]. A BGP Message TLV MUST also occur in the TLV list.
    • Code = 1: Messages Lost. One or more messages may have been lost. For example, this could happen if an implementation runs out of buffer space for queuing mirroring messages 😬

A Route Mirroring message may be sent any time it would be legal to send a Route Monitoring message ⏰

4.8. Stats Reports 📊

Stats Reports (SR) messages carry info the monitoring station can use to spot interesting events happening on the router 👀✨

Sending SR messages could be timer triggered or event driven, like when something significant happens or a threshold gets hit ⏲️ This specification doesn't put any timing restrictions on when or on what event these reports have to go out. That's up to the implementation to decide on timing. However, configuration control should be provided for the timer and/or threshold values 🎛️ This document only specifies the form and content of SR messages, so that's the scope here 📜

Following the common BMP header and per-peer header is a 4-byte field that tells you how many counters are in the stats message. Each counter is encoded as a TLV:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Stats Count                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Each counter is laid out like this:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Stat Type             |          Stat Len             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Stat Data                              |
  ~                                                               ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Stat Type (2 bytes): defines what kind of statistic is in the Stat Data field 🏷️
  • Stat Len (2 bytes): defines how long the Stat Data field is 📏

This specification defines the following statistics. A BMP implementation MUST ignore unrecognized stat types when it receives them, and it likewise MUST ignore unexpected data in the Stat Data field 🙈

Stats are either counters or gauges. These definitions follow the examples in Section 3.2.3.3 of [RFC1155] and Section 4 of [RFC2856], respectively 🤓

  • 32-bit Counter 🔢 This is a non-negative integer that keeps going up until it hits its maximum, then wraps around and starts counting from 0 again. Its maximum value is 2^32-1 (4294967295 decimal).
  • 64-bit Gauge 🎚️ This is a non-negative integer that can go up or down, but it never goes past a maximum or below a minimum. The maximum can't be bigger than 2^64-1 (18446744073709551615 decimal), and the minimum can't be smaller than 0. When the info being modeled is greater than or equal to the maximum, the gauge sits at its maximum. When the info is smaller than or equal to the minimum, it sits at its minimum. If the info drops back below the maximum (or climbs above the minimum), the 64-bit Gauge goes down (or up) with it 📈📉

The stat types are:

  • Stat Type = 0: (32-bit Counter) Number of prefixes rejected by inbound policy 🚫
  • Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix advertisements 👯
  • Stat Type = 2: (32-bit Counter) Number of (known) duplicate withdraws 👯
  • Stat Type = 3: (32-bit Counter) Number of updates invalidated due to CLUSTER_LIST loop 🔁
  • Stat Type = 4: (32-bit Counter) Number of updates invalidated due to AS_PATH loop 🔁
  • Stat Type = 5: (32-bit Counter) Number of updates invalidated due to ORIGINATOR_ID 🔁
  • Stat Type = 6: (32-bit Counter) Number of updates invalidated due to AS_CONFED loop 🔁
  • Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In 🛣️
  • Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB 🛣️
  • Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge 🧩
  • Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge 🧩
  • Stat Type = 11: (32-bit Counter) Number of updates subjected to treat-as-withdraw treatment [RFC7606] 🪄
  • Stat Type = 12: (32-bit Counter) Number of prefixes subjected to treat-as-withdraw treatment [RFC7606] 🪄
  • Stat Type = 13: (32-bit Counter) Number of duplicate update messages received 👯

Okay, the current spec only defines 4-byte counters and 8-byte gauges as "Stat Data", but that doesn't stop future versions from adding fancier TLV-type "Stat Data" (for example, one that can carry prefix-specific data). That's a glow-up waiting to happen ✨ SR messages are optional. However, if an SR message is transmitted, at least one statistic MUST be carried in it 💅

4.9. Peer Down Notification 🙈

okay so this message is how BMP says "heads up, that peering session just ended" 💀 it's basically the breakup text of BGP sessions 😭 it's used to indicate that a peering session was terminated.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |    Reason     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Data (present if Reason = 1, 2 or 3)               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

so the Reason field tells you why the session closed, and there are five possible vibes 🌈 here they are:

  • Reason 1: The local system closed the session. Following the Reason is a BGP PDU containing a BGP NOTIFICATION message that would have been sent to the peer. 🎀
  • Reason 2: The local system closed the session, and no notification message was sent. Following the reason code is a 2-byte field containing the code corresponding to the Finite State Machine (FSM) Event that caused the system to close the session (see Section 8.1 of [RFC4271]). Two bytes both set to 0 are used to indicate that no relevant Event code is defined. 🧚
  • Reason 3: The remote system closed the session with a notification message. Following the Reason is a BGP PDU containing the BGP NOTIFICATION message as received from the peer. 💜
  • Reason 4: The remote system closed the session without a notification message. This includes any unexpected termination of the transport session, so in some cases both the local and remote systems might consider this to apply. 😭
  • Reason 5: Information for this peer will no longer be sent to the monitoring station for configuration reasons. This does not, strictly speaking, indicate that the peer has gone down, but it does indicate that the monitoring station will not receive updates for the peer. 🦋

the big thing to remember is that a Peer Down message implicitly withdraws all routes that were associated with the peer in question 🫶 a BMP implementation MAY omit sending explicit withdraws for such routes. so you don't have to spam withdraws, it's giving efficiency ✨

4.10. Peer Up Notification 🌸

the Peer Up message is the opposite energy 🥹 it's used to indicate that a peering session has come up (i.e., has transitioned into the Established state). after the common BMP header and per-peer header, the body looks like this:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Local Address (16 bytes)                      |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Local Port            |        Remote Port            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Sent OPEN Message                          |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Received OPEN Message                        |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Information (variable)                        |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

here's the tea on each field 🍓

  • Local Address: The local IP address associated with the peering TCP session. It is 4 bytes long if an IPv4 address is carried in this field, as determined by the V flag (with the 12 most significant bytes zero-filled), and 16 bytes long if an IPv6 address is carried in this field. 🌈
  • Local Port: The local port number associated with the peering TCP session, or 0 if no TCP session actually exists (see Section 8.2). 🔥
  • Remote Port: The remote port number associated with the peering TCP session, or 0 if no TCP session actually exists (see Section 8.2). (The remote address can be found in the Peer Address field of the fixed header.) 💅
  • Sent OPEN Message: The full OPEN message transmitted by the monitored router to its peer. 🎀
  • Received OPEN Message: The full OPEN message received by the monitored router from its peer. 🎀
  • Information: Information about the peer, using the Information TLV (Section 4.4) format. Only the string type is defined in this context, and it may be repeated. Inclusion of the Information field is OPTIONAL. Its presence or absence can be inferred by inspection of the Message Length in the common header. 🧚

5. Route Monitoring 📡

okay this section is giving "full snapshot, then live updates" 🦋 once the BMP session is up and it's in normal operating mode, Route Monitoring messages give you a snapshot of the Adj-RIB-In of each monitored peer. they do this by sending all the routes stored in the Adj-RIB-In of those peers using standard BGP Update messages, wrapped up in Route Monitoring messages. there is no requirement on the ordering of messages in the peer dumps 🤷‍♀️ when the initial dump is completed for a given peer, this MUST be indicated by sending an End-of-RIB marker for that peer (as specified in Section 2 of [RFC4724], plus the BMP encapsulation header). see also Section 9 🌸

a BMP speaker may send pre-policy routes, post-policy routes, or both. the choice might come down to implementation constraints, because it's possible that a BGP implementation may not store, for example, routes that have been filtered out by policy 🙈 Pre-policy routes MUST have their L flag clear in the BMP header (see Section 4), and post-policy routes MUST have their L flag set. if an implementation sends both, it's effectively multiplexing two update streams onto the BMP session, and the streams are told apart by their L flags 👑

if the implementation can tell when routes were received, it MAY provide that information in the BMP Timestamp field. otherwise, the BMP Timestamp field MUST be set to 0, which means time is not available ⏰

ongoing monitoring works by propagating route changes in BGP Update PDUs and forwarding those PDUs to the monitoring station, again using RM messages 💖 when a change occurs to a route, such as an attribute change, the router must update the monitoring station with the new attribute. as discussed above, it MAY generate either an update with the L flag clear, an update with it set, or two updates, one with the L flag clear and the other with the L flag set. when a route is withdrawn by a peer, a corresponding withdraw is sent to the monitoring station. the withdraw MUST have its L flag set to correspond to that of any previous announcement. if the route in question was previously announced with the L flag both clear and set, the withdraw MUST similarly be sent twice, with the L flag clear and set. multiple changed routes MAY be grouped into a single BGP UPDATE PDU when feasible, exactly as in the standard BGP protocol 🫶

it's important to note that RM messages are not replicated messages received from a peer 🚨 (route mirroring (Section 6) is provided if this is required.) while the router should attempt to generate updates promptly, there is a finite amount of time that could elapse between reception of an update, the generation of an RM message, and its transmission to the monitoring station. if there are state changes in the interim for that prefix, it is acceptable that the router generate the final state of that prefix to the monitoring station. this is sometimes known as "state compression" 🧠 the actual PDU generated and transmitted to the station might also differ from the exact PDU received from the peer, for example, due to differences between how different implementations format path attributes 🎀

6. Route Mirroring 🪞

route Mirroring messages are provided for two main reasons. 💅

first, they let an implementation operate in a mode that gives a full-fidelity view of all messages received from its peers, without state compression. as we noted in Section 5, BMP's normal operational mode cannot provide this 🙈 implementors are strongly cautioned that without state compression, an implementation could require unbounded storage to buffer messages queued to be mirrored. Route Mirroring is unlikely to be suitable for implementation in conventional routers, and its use is NOT RECOMMENDED except in cases where implementors have carefully considered the tradeoffs. those tradeoffs include router resource exhaustion, the potential to interfere with the transmission or reception of BGP UPDATE messages, and the slowing of routing convergence. 😭

⚠️ heads up: mirroring without state compression can eat storage without limit, so think it through before you touch it 💀

the second reason is error reporting and diagnosis 🔍 when Revised Error Handling for BGP UPDATE messages [RFC7606] is in use, a router can process BGP messages that are determined to contain errors without resetting the BGP session. such messages MAY be mirrored. the buffering used for such mirroring SHOULD be limited. if an errored message can't be mirrored because of buffer exhaustion, a message with the "Messages Lost" code SHOULD be sent to indicate this. (this implies that a buffer should be reserved for this use.) 🧚

7. Stat Reports 📊

as outlined above, SR messages are used to monitor specific events and counters on the monitored router. one type of monitoring could be finding out whether there are an undue number of route advertisements and withdraws happening (churn) on the monitored router. another metric is evaluating the number of looped AS_PATHs on the router 🔁

while this document proposes a small set of counters to begin with, the authors envision that this list may grow in the future with new applications that require BMP-style monitoring. ✨ future-proof energy 🌈

8. Other Considerations 🧩

8.1. Multiple Instances 🎀

some routers may support multiple instances of the BGP protocol, for example as "logical routers" or through some other facility. the BMP protocol relates to a single instance of BGP, so if a router supports multiple BGP instances, it should also support multiple BMP instances (one per BGP instance). different BMP instances SHOULD generate Initiation Messages that are distinct from one another, for example by using distinguishable sysNames or by including instance-identifying information in a string TLV 🏷️

8.2. Locally Originated Routes 🏠

some consideration is needed for routes originated into BGP by the local router, whether because of redistribution from another protocol or for some other reason 🤔

these routes can be modeled as having been sent by the router to itself, which puts the router's own address in the Peer Address field of the header. it is RECOMMENDED that, when doing so, the router use the same address it has used as its local address for the BMP session. since in this case no transport session actually exists, the Local and Remote Port fields of the Peer Up message MUST be set to 0. clearly, the OPEN Message fields of the Peer Up message will equally not have been transmitted physically, but they should represent the relevant capabilities of the local router 💜

also, recall that the L flag is used to indicate locally sourced routes, see Section 4.2. 🦋

9. Using BMP ✨

Okay so once the BMP session is up, route monitoring starts dumping the current snapshot AND sending incremental changes at the same time 💅

It's totally fine for these two to happen concurrently 🫶 If the initial dump visits a route and then a withdraw comes in, that withdraw gets forwarded to the monitoring station, which has to correlate it and reflect the deletion of that route in its internal state. A monitoring station needs to support this no matter what, bestie 🔥

If the router gets a withdraw for a prefix before the peer dump procedure gets to that prefix, the router cleans that route out of its internal state and does not forward it to the monitoring station 🙈 So in that case the monitoring station may receive a bogus withdraw, which it can safely ignore 💀

10. IANA Considerations 🍓

IANA has created registries for the following BMP parameters, which are organized in a new group "BGP Monitoring Protocol (BMP) Parameters" 🌸

10.1. BMP Message Types

This document defines seven message types for transferring BGP messages between cooperating systems (Section 4) 💜

  • Type 0: Route Monitoring
  • Type 1: Statistics Report
  • Type 2: Peer Down Notification
  • Type 3: Peer Up Notification
  • Type 4: Initiation
  • Type 5: Termination
  • Type 6: Route Mirroring

Type values 0 through 127 MUST be assigned using the "Standards Action" policy, and values 128 through 250 using the "Specification Required" policy defined in [RFC5226]. Values 251 through 254 are Experimental, and value 255 is Reserved.

10.2. BMP Peer Types

This document defines three types of peers for purposes of interpreting the Peer Distinguisher field (Section 4.2) 🦋

  • Peer Type = 0: Global Instance Peer
  • Peer Type = 1: RD Instance Peer
  • Peer Type = 2: Local Instance Peer

Peer Type values 0 through 127 MUST be assigned using the "Standards Action" policy, and values 128 through 250 using the "Specification Required" policy, defined in [RFC5226]. Values 251 through 254 are Experimental, and value 255 is Reserved.

10.3. BMP Peer Flags

This document defines three bit flags in the Peer Flags field of the per-peer header (Section 4.2) 🧚 The bits are numbered from 0 (the high-order, or leftmost, bit) to 7 (the low-order, or rightmost, bit):

  • Flag 0: V flag
  • Flag 1: L flag
  • Flag 2: A flag

Flags 3 through 7 are unassigned. The registration procedure for the registry is "Standards Action".

10.4. BMP Statistics Types

This document defines fourteen statistics types for statistics reporting (Section 4.8) 📊

  • Stat Type = 0: Number of prefixes rejected by inbound policy
  • Stat Type = 1: Number of (known) duplicate prefix advertisements
  • Stat Type = 2: Number of (known) duplicate withdraws
  • Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST loop
  • Stat Type = 4: Number of updates invalidated due to AS_PATH loop
  • Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID
  • Stat Type = 6: Number of updates invalidated due to a loop found in AS_CONFED_SEQUENCE or AS_CONFED_SET
  • Stat Type = 7: Number of routes in Adj-RIBs-In
  • Stat Type = 8: Number of routes in Loc-RIB
  • Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In
  • Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB
  • Stat Type = 11: Number of updates subjected to treat-as-withdraw
  • Stat Type = 12: Number of prefixes subjected to treat-as-withdraw
  • Stat Type = 13: Number of duplicate update messages received

Stat Type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.

10.5. BMP Initiation Message TLVs

This document defines three types for information carried in the Initiation message (Section 4.3) 🌈

  • Type = 0: String
  • Type = 1: sysDescr
  • Type = 2: sysName

Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is reserved.

10.6. BMP Termination Message TLVs

This document defines two types for information carried in the Termination message (Section 4.5) 👑

  • Type = 0: String
  • Type = 1: Reason

Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.

10.7. BMP Termination Message Reason Codes

This document defines five types for information carried in the Termination message (Section 4.5) Reason code 🎀

  • Type = 0: Administratively closed
  • Type = 1: Unspecified reason
  • Type = 2: Out of resources
  • Type = 3: Redundant connection
  • Type = 4: Permanently administratively closed

Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.

10.8. BMP Peer Down Reason Codes

This document defines five types for information carried in the Peer Down Notification (Section 4.9) Reason code, and reserves one further type 🌙

  • Type = 0 is Reserved.
  • Type = 1: Local system closed, NOTIFICATION PDU follows
  • Type = 2: Local system closed, FSM Event follows
  • Type = 3: Remote system closed, NOTIFICATION PDU follows
  • Type = 4: Remote system closed, no data
  • Type = 5: Peer de-configured

Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and values 0 and 65535 are Reserved.

10.9. Route Mirroring TLVs

This document defines two types for information carried in the Route Mirroring message (Section 4.7) 🪞

  • Type = 0: BGP Message
  • Type = 1: Information

Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.

10.10. BMP Route Mirroring Information Codes

This document defines two types for information carried in the Route Mirroring Information (Section 4.7) code 🫧

  • Type = 0: Errored PDU
  • Type = 1: Messages Lost

Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.

11. Security Considerations 🔐

Okay, this section is SERIOUS, bestie. Read it twice 😭

This document defines a mechanism to get a full dump of, or continuously monitor, a BGP speaker's BGP routes, including received BGP messages. That's a capability that could let an outside party see information they otherwise couldn't get 👀 For example, although it's hard to treat BGP routes on the public Internet as confidential, BGP is also used in private contexts, like L3VPN [RFC4364]. Another example: a clever attacker might be able to figure out the content of the monitored router's import policy by comparing the pre-policy routes exposed by BMP with the post-policy routes exported in BGP 🕵️‍♀️

Implementations of this protocol SHOULD require manual configuration of the monitored and monitoring devices 🛠️

Unless a transport that provides mutual authentication is used, an attacker could pretend to be the monitored router and trick a monitoring station into accepting false information. Or they could pretend to be a monitoring station and get unauthorized access to BMP data 😱 Unless a transport that provides confidentiality is used, a passive or active attacker could access or tamper with the BMP data in flight 💀

Where the security considerations outlined above are a concern, users of this protocol should use IPsec [RFC4303] in tunnel mode with pre-shared keys 🔒

12. References 📚

12.1. Normative References

12.2. Informative References

Acknowledgements 🫶

Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens, Pierre Francois, Jeffrey Haas, John Ioannidis, John Kemp, Mack McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker, and the members of the GROW working group for their comments 💖

Authors' Addresses 💌

okay bestie, last stop! here's who wrote this thing and how to reach them 🫶

John Scudder (editor) is the editor, so he's the main one holding the pen 🖊️✨ He's at Juniper Networks:

John Scudder (editor)
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
United States

Email: jgs@juniper.net

Rex Fernando is from Cisco Systems 🦋:

Rex Fernando
Cisco Systems
170 W. Tasman Dr.
San Jose, CA  95134
United States

Email: rex@cisco.com

Stephen Stuart is from Google 🌈:

Stephen Stuart
Google
1600 Amphitheatre Parkway
Mountain View, CA  94043
United States

Email: sstuart@google.com

three brilliant minds, one protocol, zero chill 💖 👑

📦 where this page comes from