The transmitted AS value in te tx open message of the peer up loc-rib
message is set to 0. Actually, it should reflect the AS value of the
current BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When forging BMP open message, the BGP router-id of tx open message of
the BMP LOC-RIB peer up message is always set to 0.0.0.0, whatever the
configured value of 'bgp router-id'.
Actually, when forging a peer up LOC-RIB message, the BGP router-id
value should be taken from the main BGP instance, and not from the peer
bgp identifier. Fix this by refreshing the router-id whenever a peer up
loc-rib message should be sent.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
With recent BMP code, on a standard BMP config, the peer up and peer
down messages related to a BGP peer are sent twice, whereas they should
be send only once.
Fix this by better controlling the condition.
Fixes: f8a6933111 ("bgpd: bmp, handle imported bgp instances for peer up/down events")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
su_local and su_remote in the peer can change based upon
if we are initiating the remote connection or receiving it.
As such we need to treat it as a property of the connection.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Modify the bmp_eor() function to send end of rib messages for each peer
of the current BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If an imported BGP is configured after BGP updates have been
received, then BMP will not detect those updates in the
monitor messages.
Syncronisation is also needed for separate instances.
For each imported bgp instance, syncronisation is re-done
for monitored afi/safis for ALL available instances.
- upon configuring an afi/safi (as previously)
- when configuring an imported view
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Move the end of rib processing code of a given BGP instance in a
separate function. This code prepares the next commit, it avoids
having the following warning:
> WARNING: Too many leading tabs - consider code refactoring
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0)
> ==837617==The signal is caused by a READ memory access.
> ==837617==Hint: address points to the zero page.
> #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149
> #1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
> #2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
> #3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
> #4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
> #5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
> #6 0x7f738981c193 in hook_call_if_up lib/if.c:57
> #7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
> #8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
> #9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
> #10 0x7f738998078d in event_call lib/event.c:1996
> #11 0x7f7389848933 in frr_run lib/libfrr.c:1232
> #12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
> #13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
> #14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
> #15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When a BGP instance is created or becomes valid, and when a parameter
is updated (router-id, route distinguisher), the peer up messages other
than loc rib peer up messages, are sent. Add a test that controls if
peer down and peer up messages are sent accordingly with correct route
distinguisher values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When unconfiguring an imported BGP instance, a peer down
should be sent to notify BMP collector that the BGP instance
is leaving.
Add a test that controls the presence of the peer down loc-rib
message.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the emission of a loc-rib peer up event for an imported bgp instance
when vrf state changes. Add a test to control in the BMP collector
that the peer up message is the one from that BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the emission of a loc-rib peer up event for an imported bgp instance
at route-id reconfiguration. Add a test to control in the BMP collector
that the peer up message is the one from that BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the emission of a loc-rib peer up event for an imported bgp instance
at import-vrf configuration. Add a test to control in the BMP collector
that the peer up message is the one from that BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Only the BMP statistics of the current BGP instance are handled.
Extend the transmission of BMP statistics for imported BGP instances.
- Separate the bmp_stats() function in two, and pass the bgp
instance to process its bgp peers, as a separate parameter.
- Pass the BGP peers from imported instances as parameter
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When a BMP target comes up, only the peer up events of the
current BGP instance are sent.
- Apply the peer up event for external peers that are imported
by the BMP target.
- handle the peer up event when an imported vrf is
configured in a target.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Modify the bmp_mirror() function to export the route update information
to all BMP instances importing it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Modify the bmp_process() function to export the route update information
to all BMP instances importing it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Only the peer transition events of the local BGP instance where BMP
is configured, were handled.
Add the support for peers from imported BGP instances:
- Add an internal API bmp_send_bt() function to handle stream
emission per bmp target
- Modify the BMP peer transition code to export the peer status
notifications to all BMP instances importing it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Upon route update, the list of available BGP instances that
import the BGP instance where this updates comes from, is checked.
For each eligible BGP instance, the route update is sent.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Separate the bmp_route_update() function in two, by passing
the bgpbmp structure to the internal function instead of
the bgp instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a configuration command to import BGP information from
another BGP instance. Specifically, it should be possible for
a user to have a BMP instance configured on the default VRF,
and be able to import the VRF information from the other BGP
VRF instances.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Some BMP actions require to get the bgp instance of the
given peer. Instead of considering that the BGP BMP instance
is the BGP instance of the peer, let us use directly the
peer->bgp pointer.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
At startup, if bmp loc-rib is enabled, the peer_id of the
loc-rib per peer header message has the route distinguisher set to 0:0.
Actually, the route distinguisher has been updated after the peer up
message is sent, and the information is not refreshed.
Create a hook API to handle route distinguisher config events: pre and
post configuration. Use that hook in BMP module to send peer down, and
peer up events when necessary.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
At startup, if bmp loc-rib is enabled, the peer_id of the
loc-rib per peer header message has the router-id set to 0.0.0.0.
Actually, the router-id has been updated after the peer up
message is sent, and the information is not refreshed.
Create a hook API to handle router id events: withdraw and
updates. Use that hook in BMP module to send peer down, and
peer up events when necessary.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no need to create the bgp bmp instance, while there
is no bmp target to send data to.
Rewrite the code by using bgp_bmp_find() API instead.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following memory leak can be observed when turning off and on the
BGP vrf interface.
> ==706056==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
> #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
> #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
> #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
> #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
> #4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
> #5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
> #6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
> #7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
> #8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
> #9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
> #10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
> #11 0x7fbf5f18078d in event_call lib/event.c:1996
> #12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
> #13 0x562740c0cae1 in main bgpd/bgp_main.c:557
> #14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
> #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
> #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
> #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
> #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
> #4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
> #5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
> #6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
> #7 0x7fbf5f18078d in event_call lib/event.c:1996
> #8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
> #9 0x562740c0cae1 in main bgpd/bgp_main.c:557
> #10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Fix this by freeing the previous open_tx and open_rx contexts before
setting up the new one. Also at deletion of peer, free the open_rx
context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When a BGP listener configured with BMP receives the first BGP
IPv6 update from a connected BGP IPv6 peer, the BMP collector
receives a withdraw post-policy message.
> {"peer_type": "route distinguisher instance", "policy": "post-policy",
> "ipv6": true, "peer_ip": "192:167::3", "peer_distinguisher": "444:1",
> "peer_asn": 65501, "peer_bgp_id": "192.168.1.3", "timestamp":
> "2024-10-29 11:44:47.111962", "bmp_log_type": "withdraw", "afi": 2,
> "safi": 1, "ip_prefix": "2001::1125/128", "seq": 22}
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:167::3", "peer_distinguisher": "444:1",
> "peer_asn": 65501, "peer_bgp_id": "192.168.1.3", "timestamp":
> "2024-10-29 11:44:47.111963", "bmp_log_type": "update", "origin":
> "IGP", "as_path": "", "afi": 2, "safi": 1, "nxhp_ip": "192:167::3",
> "nxhp_link-local": "fe80::7063:d8ff:fedb:9e11", "ip_prefix": "2001::1125/128", "seq": 23}
Actually, the BGP update is not valid, and BMP considers it as a
withdraw message. The BGP upate is not valid, because the nexthop
reachability is unknown at the time of reception, and no other
BMP message is sent.
Fix this by re-sending a BMP post update message when nexthop
tracking becomes successfull. Generalise the re-sending of
messages when nexthop tracking changes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp_2 vrf test, peer vrf up/down events from the pre
and post policy are received with a wrong peer distinguisher value.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:168::2", "peer_distinguisher": "0:0",
> "peer_asn": 65502, "peer_bgp_id": "192.168.0.2", "timestamp":
> "2024-10-16 21:59:53.111962", "bmp_log_type": "peer up", "local_ip":
> "192:168::1", "local_port": 179, "remote_port": 50836, "seq": 5}
RFC7854 mentions in 4.2 that if the peer is a "RD Instance Peer", it is
set to the route distinguisher of the particular instance the peer
belongs to.
Fix this by modifying the BMP client, update the peer distinguisher
value by filling the peer distinguisher in the bmp_peerstate function.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:168::2", "peer_distinguisher": "444:1",
> "peer_asn": 65502, "peer_bgp_id": "192.168.0.2", "timestamp":
> "2024-10-16 21:59:53.111962", "bmp_log_type": "peer up", "local_ip":
> "192:168::1", "local_port": 179, "remote_port": 50836, "seq": 5}
Add a test to check that peer_distinguisher value is not 0:0 when an
RD instance is set.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp_2 vrf test, peer up/down events from the pre
and post policy are received with a wrong peer type value
> {"peer_type": "global instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-16 21:59:53.111962",
> "bmp_log_type": "peer up", "local_ip": "192.168.0.1", "local_port": 179,
> "remote_port": 50710, "seq": 4}
RFC7854 defines RD instance peer type, and later in 4.2 requests that
the peer distinguisher value be set to non zero value when the peer type
is not global. This is the case for peer vrf instances.
Fix this by modifying the BMP client, update the peer type
value by updating the peer type value when sending peer up/down messages.
Add a check in the bgp_bmp_2 test to ensure that peer type is correctly
set.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:168::2", "peer_distinguisher": "0:0",
> "peer_asn": 65502, "peer_bgp_id": "192.168.0.2", "timestamp":
> "2024-10-16 21:59:53.111962", "bmp_log_type": "peer up", "local_ip":
> "192:168::1", "local_port": 179, "remote_port": 50836, "seq": 5}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp_2 vrf test, peer route messages from the pre
and post policy are received with a wrong peer distinguisher value.
> {"peer_type": "route distinguisher instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
RFC7854 mentions in 4.2 that if the peer is a "RD Instance Peer", it is
set to the route distinguisher of the particular instance the peer
belongs to.
Fix this by modifying the BMP client:
- update the peer distinguisher value by unlocking the filling of the peer distinguisher in the function.
This change impacts monitoring messages.
- add the peer distinguisher computation for mirror messages
- modify the bgp_bmp_2 vrf test, update the peer_distinguisher value
> {"peer_type": "route distinguisher instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "444:1", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp_2 vrf test, peer route messages from the pre
and post policy are received with a wrong peer type value
> {"peer_type": "global instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
In addition to global instance peers, RFC7854 defines RD instance peers.
This value can be used for peers which are on a BGP VRF instance, for
example with an L3VPN setup.
When configuring a BGP VRF instance, the peer type should be seen as an
RD instance peer.
Fix this by modifying the BMP client:
- update the peer type for vrf mirror and monitoring messages
- modify bgp_bmp_2 vrf test to control the peer_type value
> {"peer_type": "route distinguisher instance", "policy": "pre-policy", "ipv6": false,
> "peer_ip": "192.168.0.2", "peer_distinguisher": "0:0", "peer_asn": 65502,
> "peer_bgp_id": "192.168.0.2", "timestamp": "2024-10-31 08:19:58.111963",
> "bmp_log_type": "update", "origin": "IGP", "as_path": "65501 65502",
> "bgp_nexthop": "192.168.0.2", "ip_prefix": "172.31.0.15/32", "seq": 15}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
All BMP peer up/down messages send a 0:0 peer distinguisher.
This will not be ok when adding RD instance type.
Add code to get the peer distinguisher value.
- modify the API to pass the BGP instance instead of BMP.
- implement error cases with an unknown vrf identifier or a
peer type with local type value.
- handle the error return of the API; consequently, handle
the bmp_peerstate() error return in the calling functions.
There is no functional change, as the peer type value is
either loc-rib or global, both cases are already handled.
The next commit will handle the RD instance case.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If a given L3VRF instance requests a peer distinguisher
for a peer up/down message, the AFI_UNSPEC afi parameter
will be used; no RD is chosen for this AFI.
Fix this by priorizing the AFI_IP value before the AFI_IP6
value. For instance, a router with both RD set for each
address-family, peer up/down messages will be sent with the
RD set to the one for AFI_IP.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_bmp test, peer_up message from the loc-rib
are received with a wrong peer type.
> {"peer_type": "global instance", "policy": "pre-policy", "ipv6": false, "peer_ip": "0.0.0.0",
> "peer_distinguisher": "0:0", "peer_asn": 0, "peer_bgp_id": "0.0.0.0",
> "timestamp": "2024-10-16 21:59:53.111963", "bmp_log_type": "peer up", "local_ip": "0.0.0.0",
> "local_port": 0, "remote_port": 0, "seq": 1}
RFC9069 mentions in 5.1 that peer address must be set to 0.0.0.0,
and the peer_type value must be set to 3. Today, the value set
is 0 (global instance). This is wrong.
Fix this by modifying the BMP client, update the peer type value to
loc-rib on peer up messages.
Modify the current BMP test, by checking the peer up messages for the
0.0.0.0 IP address (which is the value used for loc-rib).
> {"peer_type": "loc-rib instance", "is_filtered": false, "policy": "loc-rib",
> "peer_distinguisher": "0:0", "peer_asn": 65501, "peer_bgp_id": "192.168.0.1",
> "timestamp": "2024-10-16 21:59:53.111963", "bmp_log_type": "peer up", "local_ip": "0.0.0.0",
> "local_port": 0, "remote_port": 0, "seq": 1}
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
At startup, there is no peer up message for loc-rib instance peer.
Instead, a global peer up message with address 0.0.0.0 is sent.
Such message is wrong, violates the RFC and should be dropped by
a strict collector. Actually, the peer type message sent is wrong,
and should be set to LOC-RIB peer type.
Fix this by changing the peer type of peer up message to either
loc-rib or global instance peer type.
Fixes: 035304c25a ("bgpd: bmp loc-rib peer up/down for vrfs")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Currently the AIGP is always incremented when a route with the
attribute is advertised. That is incorrect when the nexthop is
unchanged, as is commonly the case in route reflection.
Adjust the AIGP for propagation only when the nexthop is set
to ourselves.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
added bmp bgp peer for vrfs
added peer up vrf in bmp peer up state
added vrf state in bmpbgp
added safe bmp_peer_sendall : bmp_peer_sendall_safe
changed bgp_open_send to call new bgp_open_make
bgp_open_make creates a bgp open packet, now used in bmp for peer up vrf
added hook and call to bgp instance state
vrf peer state is recomputed when interfaces (including vrf itf) go up / down
and when it gets created or removed
Link: e48ba38070
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
