Skip to content

Commit

Permalink
doc: update bmp doc for adj-rib-out, ecmp, and loc-rib
Browse files Browse the repository at this point in the history 
Signed-off-by: Maxence Younsi <[email protected]>
  • Loading branch information
@mxyns
mxyns committed Nov 29, 2023
1 parent 1180b29 commit 2597d3f
Show file tree
Hide file tree
Showing 3 changed files with 70 additions and 81 deletions.
2 changes: 1 addition & 1 deletion bgpd/bgp_bmp.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2244,7 +2244,7 @@ static void bmp_wrfill(struct bmp *bmp, struct pullwr *pullwr)
zlog_info("bmp: Startup timeout expired, time since startup is %" PRIu32
"ms", timeout_ms);
bmp->state = BMP_PeerUp;

/* start BMP_PeerUp mode now */
bmp_wrfill(bmp, pullwr);
break;
Expand Down
55 changes: 23 additions & 32 deletions doc/developer/bmp.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,46 +4,37 @@
BMP
***

RFC 7854
========
RFC 7854: BMP Adj-RIB-In
========================
Missing features (non exhaustive):
- Per-Peer Header

- Peer Type Flag
- Peer Distingsher

- Peer Up

- Peer Down
- Reason codes (according to TODO comments in code)

Peer Type Flag and Peer Distinguisher can be implemented easily using RFC 9069's base code.

RFC 9069
========
RFC 9069: BMP Local-RIB
=======================
Everything that isn't listed here is implemented and should be working.
Missing features (should be exhaustive):

- Per-Peer Header

- Timestamp

- set to 0
- value is now saved `struct bgp_path_info -> locrib_uptime`
- needs testing

- Peer Up/Down

- VRF/Table Name TLV
- Peer Down Only
- Reason code (bc not supported in RFC 7854 either)

- code for TLV exists
- need better RFC understanding
RFC8671: BMP Adj-RIB-Out
========================
Adj-RIB-Out pre-policy uses tricks to work because we soft-reconfiguration outbound does not exist.
So what we do is we call the BGP function (subgroup_announce_check) which decides whether to announce or not to peers,
while ignoring the outbound policy + some conditions specific to Adj-RIB-Out Post-policy.
This allows us to guess whether the route would've been in Adj-RIB-Out Pre-policy or not. However, we cannot compute
all pre-policy stats as a consequence.

- Peer Down Only
Everything that isn't listed here is implemented and should be working.

- Reason code (bc not supported in RFC 7854 either)
- Per-Peer Header
- Timestamp: not recorded, set to 0

- Statistics Report
- Stats
- adj-rib-out pre-policy counters (cannot be done since adj-rib-out pre-policy is not saved)

- Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.
- 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.
ECMP Support
============
The RX Add-Path ID is exported for Adj-RIB-In Pre/Post-policy and Local-RIB.
The TX Add-Path ID is exported for Adj-RIB-Out Pre/Post-policy.
94 changes: 46 additions & 48 deletions doc/user/bmp.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,8 @@ Implementation characteristics

The `BMP` implementation in FRR has the following properties:

- only the :rfc:`7854` features are currently implemented. This means protocol
version 3 without any extensions. It is not possible to use an older draft
- :rfc:`7854`, :rfc:`9069`, :rfc:`8671` features are currently implemented. This means protocol
version 3 without Local-RIB and Adj-RIB-Out Monitoring support. It is not possible to use an older draft
protocol version of BMP.

- the following statistics codes are implemented:
Expand All @@ -23,8 +23,14 @@ The `BMP` implementation in FRR has the following properties:
- 3: count of **prefixes** with loop in cluster id
- 4: count of **prefixes** with loop in AS-path
- 5: count of **prefixes** with loop in originator
- 7: count of routes in adj-rib-in (pre-policy)
- 8: count of routes in local-rib
- 9: count of routes per afi/safi in adj-rib-in (pre-policy)
- 10: count of routes per afi/safi in local-rib
- 11: count of updates subjected to :rfc:`7607` "treat as withdrawal"
handling due to errors
- 15: count of routes in adj-rib-out post-policy
- 17: count of routes per afi/safi in adj-rib-out post-policy
- 65531: *experimental* count of prefixes rejected due to invalid next-hop

Note that stat items 3, 4 and 5 are specified to count updates, but FRR
Expand All @@ -40,20 +46,11 @@ The `BMP` implementation in FRR has the following properties:
EVPN and VPN SAFIs. Other SAFIs (VPN, Labeled-Unicast, Flowspec, etc.) are not
currently supported.

- monitoring peers that have BGP **add-path** enabled on the session will
result in somewhat unpredictable behaviour. Currently, the outcome is:

- monitoring peers that have BGP **add-path** enabled on will have the following behaviour:
- route mirroring functions as intended, messages are copied verbatim
- the add-path ID is never included in route monitoring messages
- if multiple paths were received from a peer, an unpredictable path is
picked and sent on the BMP session. The selection will differ for
pre-policy and post-policy monitoring sessions.
- as long as any path is present, something will be advertised on BMP
sessions. Only after the last path is gone a withdrawal will be sent on
BMP sessions.
- updates to additional paths will trigger BMP route monitoring messages.
There is no guarantee on consistency regarding which path is sent in these
messages.
- the add-path ID is always included in route monitoring messages
- routes from peers without add-path have the "default" 0 path-id included
- the received path-id will be included for Adj-RIB-In and Local-RIB

- monitoring peers with :rfc:`5549` extended next-hops has not been tested.

Expand Down Expand Up @@ -198,7 +195,7 @@ associated with a particular ``bmp targets``:
a subset of BGP sessions may be added in the future.

BMP Troubleshooting
-------------
-------------------


When encountering problems with BMP, it may be interesting to know the current
Expand All @@ -210,35 +207,36 @@ state of the latter.
configured modes, global settings, ...

.. code-block:: frr
BMP Module started at Fri Feb 24 13:05:50 2023

BMP state for BGP VRF default:

Route Mirroring 0 bytes (0 messages) pending
0 bytes maximum buffer used

Startup delay : 10000ms

Targets "my_targets":
Route Mirroring disabled
Route Monitoring IPv4 unicast rib-out pre-policy rib-out post-policy
Listeners:

Outbound connections:
remote state timer local
----------------------------------------------------------------------
99.99.99.99:12345 Up 99.99.99.99:12345 00:00:04 (unspec)

1 connected clients:
remote uptime state MonSent MirrSent MirrLost ByteSent ByteQ ByteQKernel
---------------------------------------------------------------------------------------------------------------
99.99.99.99:12345 00:00:04 Startup-Wait 0 0 0 61 0 0
::

Here we have a single BGP instance running on VRF default. No specific mirroring settings but a
startup delay of 10000ms.
This instance has a single target with rib-out pre-policy and post-policy monitoring, no mirroring.
This target has a single session open with client 99.99.99.99 on port 12345 which is in state Startup-Wait.
This session will start sending monitoring messages as soon as the current time is
"Fri Feb 24 13:05:50 2023" + 10000ms = "Fri Feb 24 13:06:00 2023" which explains why it is in
Startup-Wait mode and has not sent Monitoring Messages yet.
BMP Module started at Fri Feb 24 13:05:50 2023
BMP state for BGP VRF default:
Route Mirroring 0 bytes (0 messages) pending
0 bytes maximum buffer used
Startup delay : 10000ms
Targets "my_targets":
Route Mirroring disabled
Route Monitoring IPv4 unicast rib-out pre-policy rib-out post-policy
Listeners:
Outbound connections:
remote state timer local
----------------------------------------------------------------------
99.99.99.99:12345 Up 99.99.99.99:12345 00:00:04 (unspec)
1 connected clients:
remote uptime state MonSent MirrSent MirrLost ByteSent ByteQ ByteQKernel
---------------------------------------------------------------------------------------------------------------
99.99.99.99:12345 00:00:04 Startup-Wait 0 0 0 61 0 0
Here we have a single BGP instance running on VRF default. No specific mirroring settings but a
startup delay of 10000ms.
This instance has a single target with rib-out pre-policy and post-policy monitoring, no mirroring.
This target has a single session open with client 99.99.99.99 on port 12345 which is in state Startup-Wait.
This session will start sending monitoring messages as soon as the current time is
"Fri Feb 24 13:05:50 2023" + 10000ms = "Fri Feb 24 13:06:00 2023" which explains why it is in
Startup-Wait mode and has not sent Monitoring Messages yet.

0 comments on commit 2597d3f

Please sign in to comment.