doc: update bmp doc for adj-rib-out, ecmp, and loc-rib

Signed-off-by: Maxence Younsi <[email protected]>
mxyns · Nov 28, 2023 · 4234476 · 4234476
1 parent da78495
commit 4234476
Show file tree

Hide file tree

Showing 3 changed files with 70 additions and 81 deletions.
diff --git a/bgpd/bgp_bmp.c b/bgpd/bgp_bmp.c
@@ -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;

diff --git a/doc/developer/bmp.rst b/doc/developer/bmp.rst
@@ -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.
diff --git a/doc/user/bmp.rst b/doc/user/bmp.rst
@@ -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:
@@ -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
@@ -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.
 
@@ -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
@@ -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.