7 :abbr:`BMP` (BGP Monitoring Protocol, :rfc:`7854`) is used to send monitoring
8 data from BGP routers to network management entities.
10 Implementation characteristics
11 ==============================
13 The `BMP` implementation in FRR has the following properties:
15 - only the :rfc:`7854` features are currently implemented. This means protocol
16 version 3 without any extensions. It is not possible to use an older draft
17 protocol version of BMP.
19 - the following statistics codes are implemented:
21 - 0: count of prefixes rejected
22 - 2: count of duplicate prefix withdrawals
23 - 3: count of **prefixes** with loop in cluster id
24 - 4: count of **prefixes** with loop in AS-path
25 - 5: count of **prefixes** with loop in originator
26 - 11: count of updates subjected to :rfc:`7607` "treat as withdrawal"
27 handling due to errors
28 - 65531: *experimental* count of prefixes rejected due to invalid next-hop
30 Note that stat items 3, 4 and 5 are specified to count updates, but FRR
31 implements them as prefix-based counters.
33 - **route mirroring** is fully implemented, however BGP OPEN messages are not
34 currently included in route mirroring messages. Their contents can be
35 extracted from the "peer up" notification for sessions that established
36 successfully. OPEN messages for failed sessions cannot currently be
39 - **route monitoring** is available for IPv4 and IPv6 AFIs, unicast and
40 multicast SAFIs. Other SAFIs (VPN, Labeled-Unicast, Flowspec, etc.) are not
43 - monitoring peers that have BGP **add-path** enabled on the session will
44 result in somewhat unpredictable behaviour. Currently, the outcome is:
46 - route mirroring functions as intended, messages are copied verbatim
47 - the add-path ID is never included in route monitoring messages
48 - if multiple paths were received from a peer, an unpredictable path is
49 picked and sent on the BMP session. The selection will differ for
50 pre-policy and post-policy monitoring sessions.
51 - as long as any path is present, something will be advertised on BMP
52 sessions. Only after the last path is gone a withdrawal will be sent on
54 - updates to additional paths will trigger BMP route monitoring messages.
55 There is no guarantee on consistency regarding which path is sent in these
58 - monitoring peers with :rfc:`5549` extended next-hops has not been tested.
63 BMP is implemented as a loadable module. This means that to use BMP, ``bgpd``
64 must be started with the ``-M bmp`` option. It is not possible to enable BMP
65 if ``bgpd`` was started without this option.
70 All of FRR's BMP configuration options are located inside the
71 :clicmd:`router bgp ASN` block. Configure BGP first before proceeding to BMP
74 There is one option that applies to the BGP instance as a whole:
76 .. clicmd:: bmp mirror buffer-limit(0-4294967294)
78 This sets the maximum amount of memory used for buffering BGP messages
79 (updates, keepalives, ...) for sending in BMP Route Mirroring.
81 The buffer is for the entire BGP instance; if multiple BMP targets are
82 configured they reference the same buffer and do not consume additional
83 memory. Queue overhead is included in accounting this memory, so the
84 actual space available for BGP messages is slightly less than the value
87 If the buffer fills up, the oldest messages are removed from the buffer and
88 any BMP sessions where the now-removed messages were still pending have
89 their **entire** queue flushed and a "Mirroring Messages Lost" BMP message
92 BMP Route Monitoring is not affected by this option.
94 All other configuration is managed per targets:
96 .. clicmd:: bmp targets NAME
98 Create/delete a targets group. As implied by the plural name, targets may
99 cover multiple outbound active BMP sessions as well as inbound passive
102 If BMP sessions have the same configuration, putting them in the same
103 ``bmp targets`` will reduce overhead.
105 BMP session configuration
106 -------------------------
108 Inside a ``bmp targets`` block, the following commands control session
111 .. clicmd:: bmp connect HOSTNAME port (1-65535) {min-retry MSEC|max-retry MSEC}
113 Add/remove an active outbound BMP session. HOSTNAME is resolved via DNS,
114 if multiple addresses are returned they are tried in nondeterministic
115 order. Only one connection will be established even if multiple addresses
116 are returned. ``min-retry`` and ``max-retry`` specify (in milliseconds)
117 bounds for exponential backoff.
121 ``ip access-list`` and ``ipv6 access-list`` are checked for outbound
122 connections resulting from ``bmp connect`` statements.
124 .. clicmd:: bmp listener <X:X::X:X|A.B.C.D> port (1-65535)
126 Accept incoming BMP sessions on the specified address and port. You can
127 use ``0.0.0.0`` and ``::`` to listen on all IPv4/IPv6 addresses.
129 .. clicmd:: ip access-list NAME
130 .. clicmd:: ipv6 access-list NAME
132 Restrict BMP sessions to the addresses allowed by the respective access
133 lists. The access lists are checked for both passive and active BMP
134 sessions. Changes do not affect currently established sessions.
136 BMP data feed configuration
137 ---------------------------
139 The following commands configure what BMP messages are sent on sessions
140 associated with a particular ``bmp targets``:
142 .. clicmd:: bmp stats [interval (100-86400000)]
144 Send BMP Statistics (counter) messages at the specified interval (in
147 .. clicmd:: bmp monitor AFI SAFI <pre-policy|post-policy>
149 Perform Route Monitoring for the specified AFI and SAFI. Only IPv4 and
150 IPv6 are currently valid for AFI, and only unicast and multicast are valid
151 for SAFI. Other AFI/SAFI combinations may be added in the future.
153 All BGP neighbors are included in Route Monitoring. Options to select
154 a subset of BGP sessions may be added in the future.
156 .. clicmd:: bmp mirror
158 Perform Route Mirroring for all BGP neighbors. Since this provides a
159 direct feed of BGP messages, there are no AFI/SAFI options to be
162 All BGP neighbors are included in Route Mirroring. Options to select
163 a subset of BGP sessions may be added in the future.