doc/user/bmp.rst

   1 .. _bmp:
   2
   3 ***
   4 BMP
   5 ***
   6
   7 :abbr:`BMP` (BGP Monitoring Protocol, :rfc:`7854`) is used to send monitoring
   8 data from BGP routers to network management entities.
   9
  10 Implementation characteristics
  11 ==============================
  12
  13 The `BMP` implementation in FRR has the following properties:
  14
  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.
  18
  19 - the following statistics codes are implemented:
  20
  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
  29
  30   Note that stat items 3, 4 and 5 are specified to count updates, but FRR
  31   implements them as prefix-based counters.
  32
  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
  37   mirrored.
  38
  39 - **route monitoring** is available for IPv4 and IPv6 AFIs, unicast and
  40   multicast SAFIs.  Other SAFIs (VPN, Labeled-Unicast, Flowspec, etc.) are not
  41   currently supported.
  42
  43 - monitoring peers that have BGP **add-path** enabled on the session will
  44   result in somewhat unpredictable behaviour.  Currently, the outcome is:
  45
  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
  53     BMP sessions.
  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
  56     messages.
  57
  58 - monitoring peers with :rfc:`5549` extended next-hops has not been tested.
  59
  60 Starting BMP
  61 ============
  62
  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.
  66
  67 Configuring BMP
  68 ===============
  69
  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
  72 setup.
  73
  74 There is one option that applies to the BGP instance as a whole:
  75
  76 .. index:: bmp mirror buffer-limit(0-4294967294)
  77 .. clicmd:: [no] bmp mirror buffer-limit(0-4294967294)
  78
  79    This sets the maximum amount of memory used for buffering BGP messages
  80    (updates, keepalives, ...) for sending in BMP Route Mirroring.
  81
  82    The buffer is for the entire BGP instance; if multiple BMP targets are
  83    configured they reference the same buffer and do not consume additional
  84    memory.  Queue overhead is included in accounting this memory, so the
  85    actual space available for BGP messages is slightly less than the value
  86    configured here.
  87
  88    If the buffer fills up, the oldest messages are removed from the buffer and
  89    any BMP sessions where the now-removed messages were still pending have
  90    their **entire** queue flushed and a "Mirroring Messages Lost" BMP message
  91    is sent.
  92
  93    BMP Route Monitoring is not affected by this option.
  94
  95 All other configuration is managed per targets:
  96
  97 .. index:: bmp targets NAME
  98 .. clicmd:: [no] bmp targets NAME
  99
 100    Create/delete a targets group.  As implied by the plural name, targets may
 101    cover multiple outbound active BMP sessions as well as inbound passive
 102    listeners.
 103
 104    If BMP sessions have the same configuration, putting them in the same
 105    ``bmp targets`` will reduce overhead.
 106
 107 BMP session configuration
 108 -------------------------
 109
 110 Inside a ``bmp targets`` block, the following commands control session
 111 establishment:
 112
 113 .. index:: bmp connect HOSTNAME port (1-65535) {min-retry MSEC|max-retry MSEC}
 114 .. clicmd:: [no] bmp connect HOSTNAME port (1-65535) {min-retry MSEC|max-retry MSEC}
 115
 116    Add/remove an active outbound BMP session.  HOSTNAME is resolved via DNS,
 117    if multiple addresses are returned they are tried in nondeterministic
 118    order.  Only one connection will be established even if multiple addresses
 119    are returned.  ``min-retry`` and ``max-retry`` specify (in milliseconds)
 120    bounds for exponential backoff.
 121
 122 .. warning::
 123
 124    ``ip access-list`` and ``ipv6 access-list`` are checked for outbound
 125    connections resulting from ``bmp connect`` statements.
 126
 127 .. index:: bmp listener <X:X::X:X|A.B.C.D> port (1-65535)
 128 .. clicmd:: [no] bmp listener <X:X::X:X|A.B.C.D> port (1-65535)
 129
 130    Accept incoming BMP sessions on the specified address and port.  You can
 131    use ``0.0.0.0`` and ``::`` to listen on all IPv4/IPv6 addresses.
 132
 133 .. clicmd:: [no] ip access-list NAME
 134 .. clicmd:: [no] ipv6 access-list NAME
 135
 136    Restrict BMP sessions to the addresses allowed by the respective access
 137    lists.  The access lists are checked for both passive and active BMP
 138    sessions.  Changes do not affect currently established sessions.
 139
 140 BMP data feed configuration
 141 ---------------------------
 142
 143 The following commands configure what BMP messages are sent on sessions
 144 associated with a particular ``bmp targets``:
 145
 146 .. index:: bmp stats [interval (100-86400000)]
 147 .. clicmd:: [no] bmp stats [interval (100-86400000)]
 148
 149    Send BMP Statistics (counter) messages at the specified interval (in
 150    milliseconds.)
 151
 152 .. index:: bmp monitor AFI SAFI <pre-policy|post-policy>
 153 .. clicmd:: [no] bmp monitor AFI SAFI <pre-policy|post-policy>
 154
 155    Perform Route Monitoring for the specified AFI and SAFI.  Only IPv4 and
 156    IPv6 are currently valid for AFI, and only unicast and multicast are valid
 157    for SAFI.  Other AFI/SAFI combinations may be added in the future.
 158
 159    All BGP neighbors are included in Route Monitoring.  Options to select
 160    a subset of BGP sessions may be added in the future.
 161
 162 .. index:: bmp mirror
 163 .. clicmd:: [no] bmp mirror
 164
 165    Perform Route Mirroring for all BGP neighbors.  Since this provides a
 166    direct feed of BGP messages, there are no AFI/SAFI options to be
 167    configured.
 168
 169    All BGP neighbors are included in Route Mirroring.  Options to select
 170    a subset of BGP sessions may be added in the future.