diff --git a/bgpd/bgp_bmp.c b/bgpd/bgp_bmp.c index 0c764a3f2699..c0a11b1cf57d 100644 --- 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 index 1c0e4b045426..269cbafd29a5 100644 --- 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 index f95c091d7e16..a642144096a5 100644 --- 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.