Monitoring BGP Parameters Using BMP

Abstract

The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment, termination, and route updates. Without BMP, manual queries are required to obtain BGP operational status.¶

This document defines extensions to the BMP Initiation Message to enable a BGP Monitoring Station (BMS) to discover optional BGP capabilities supported by the monitored network device, capabilities currently enabled, and default configuration parameters.¶

1. Introduction

The Border Gateway Protocol (BGP) [RFC4271] is a dynamic routing protocol operating across Autonomous Systems (AS). BGP supports a variety of optional parameters [RFC5492], such as IPv4/IPv6 Unicast, Multiprotocol Extensions, Route Refresh, Outbound Route Filtering (ORF), Graceful Restart, and 4-octet AS number support. Different BGP software implementations may support different subsets of these capabilities. Furthermore, a network device typically does not enable all supported capabilities globally, but rather activates them based on specific deployment requirements.¶

The BGP Monitoring Protocol (BMP) [RFC7854] facilitates the monitoring of BGP operational states, peer relationship lifecycles, and route updates. By connecting a router to a monitoring station, network operators can passively track BGP statistics, improving network monitoring efficiency and enabling real-time detection of operational anomalies.¶

In existing BMP implementations, when a BGP session is established, peers negotiate optional capabilities via BGP OPEN messages. The BMP Peer Up Notification message reports these negotiated, currently active capabilities to the BMS.¶

However, reporting only active capabilities is insufficient for advanced network management and optimization. To effectively optimize multi-vendor environments and troubleshoot interoperation issues, a BMS often needs visibility into *all* BGP capabilities supported by each monitored device, as well as its default configuration parameters.¶

2. Terminology

This memo makes use of the terms defined in [RFC7854].¶

• BMP: BGP Monitoring Protocol.¶

• BMS: BGP Monitoring Station.¶

• Initiation Message: Reports to the monitoring server such information as the router vendor, software version, and device-level BGP capabilities.¶

3. Use Cases

1. BGP Optional Parameters Supported vs. Enabled: Standard BMP Peer Up notifications report only currently enabled capabilities. If all supported capabilities (both enabled and disabled) are reported to the BMS, operators gain a comprehensive view of the device's software and hardware feature readiness. For instance, if Graceful Restart (GR) is not currently enabled on a specific peer, the OPEN message omits it. However, if the BMS knows that both peers actually support GR, it can prompt or automatically trigger an operational change to enable GR, thereby enhancing network stability.¶

2. BGP Default Behavior Parameters in Multi-Vendor Environments: In multi-vendor networks, default configurations and behaviors often differ significantly, which can lead to unexpected interoperation issues. A prime example is the default protocol preference (administrative distance) assigned to BGP routes: Vendor A might assign a default preference of 255 to eBGP, iBGP, and local BGP routes, whereas Vendor B assigns 20 for eBGP, and 200 for iBGP and local routes. Moreover, if a value like 255 is unrecognized or out-of-range for Vendor B, routes with such values may be dropped. Visibility into these default parameters via BMP allows the BMS to proactively detect and mitigate misconfigurations or preference mismatches.¶

4. Extension of BMP Initiation Message

As described in Section 4.3 of [RFC7854], the Initiation Message provides a means for the monitored router to inform the monitoring station of its vendor, software version, and other global attributes.¶

The Initiation Message consists of the common BMP header followed by two or more Information TLVs (Section 4.4 of [RFC7854]). This document defines three new Information TLV types to carry BGP optional parameters and default behavior parameters:¶

• Type = TBD1: Optional Parameters Supported¶

• Type = TBD2: Optional Parameters Enabled¶

• Type = TBD3: Default Behavior Parameters¶

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
|  Parm. Type   | Parm. Length  |  Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

       Figure 1: BGP Optional Parameters Information 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
+-------------------------------+-------------------------------+
|       Default Beh. Type       |         Def Beh. Length       |
+-------------------------------+-------------------------------+
|                     Default Beh. Value (variable)             |
~                                                               ~
+---------------------------------------------------------------+

       Figure 2: Default Behavior Parameters sub-TLV

5. Security Considerations

The extensions defined in this document report static device capabilities and default configurations via BMP Initiation Messages. Since BMP sessions may traverse public or untrusted networks, the security considerations outlined in [RFC7854] apply. Specifically, operators SHOULD secure BMP sessions using transport-layer security (such as TCP MD5, TCP Authentication Option (TCP-AO), or IPsec/TLS encapsulation) to prevent unauthorized interception or spoofing of device configuration and capability profiles.¶

6. IANA Considerations

This document requests IANA to assign new TLV types within the "BMP Initiation Message Information TLVs" registry established by [RFC7854]:¶

• TBD1: Optional Parameters Supported¶

• TBD2: Optional Parameters Enabled¶

• TBD3: Default Behavior Parameters¶

Additionally, IANA is requested to establish a new registry for "BMP Default Behavior Parameter Sub-TLV Types" under the BMP parameters registry:¶

• TBD4 through TBD13 as defined in Section 4.3.¶

8. References