Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to import BMP information from a separate BGP instance #17639

Open
wants to merge 34 commits into
base: master
Choose a base branch
from

Conversation

pguibert6WIND
Copy link
Member

Ability to import BMP information from a separate BGP instance.
This also includes the handling of BGP instance updates:
router-id reconfiguration or route-distinguisher reconfiguration are causes that need to reset the identity of that BGP instance (as the BGP identity is defined by BMP peer distinguisher and BMP peer type).

@pguibert6WIND pguibert6WIND force-pushed the bmp_import_vrf_view branch 5 times, most recently from 5c31cba to ca848dd Compare December 17, 2024 20:41
@pguibert6WIND pguibert6WIND marked this pull request as draft December 17, 2024 20:54
@pguibert6WIND
Copy link
Member Author

some memory leak issues yet.

@pguibert6WIND pguibert6WIND force-pushed the bmp_import_vrf_view branch 2 times, most recently from a7a1021 to 2c3d360 Compare December 19, 2024 16:11
The following ASAN error can be seen.

> ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20
>     #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198
>     FRRouting#1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common
> /sanitizer_stacktrace.h:122
>     FRRouting#2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074
>     FRRouting#3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78
>     FRRouting#4 0x7f3d7a03f330 in qfree lib/memory.c:130
>     FRRouting#5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982
>     FRRouting#6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#14 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#15 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#17 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#19 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4)
>
> 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71)
> freed by thread T0 here:
>     #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
>     FRRouting#1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981
>     FRRouting#2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47
>     FRRouting#3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287
>     FRRouting#4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777
>     FRRouting#5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140
>     FRRouting#6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764
>     FRRouting#7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003
>     FRRouting#8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062
>     FRRouting#9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228
>     FRRouting#10 0x7f3d7a107b53 in vty_command lib/vty.c:625
>     FRRouting#11 0x7f3d7a109902 in vty_execute lib/vty.c:1388
>     FRRouting#12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400
>     FRRouting#13 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#15 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
>     #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194
>     FRRouting#3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236
>     FRRouting#4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479
>     FRRouting#5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88
>     FRRouting#6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936
>     FRRouting#7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299
>     FRRouting#8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286
>     FRRouting#9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275
>     FRRouting#10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561
>     FRRouting#11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624
>     FRRouting#12 0x7f3d7a0f848b in event_call lib/event.c:2019
>     FRRouting#13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x560ae29e0037 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A memory leak happens when reconfiguring an already configured route
distinguisher on an L3VPN BGP instance. Fix this by freeing the previous
route distinguisher.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following warning can be seen:
> In file included from ./bgpd/bgp_trace.h:21,
>                  from bgpd/bgp_io.c:27:
> bgpd/bgp_io.c: In function ‘read_ibuf_work’:
> bgpd/bgp_io.c:202:53: warning: passing argument 1 of ‘lttng_ust_tracepoint_cb_frr_bgp___packet_read’ from incompatible pointer type [-Wincompatible-pointer-types]
>   202 |         frrtrace(2, frr_bgp, packet_read, connection->peer, pkt);
>       |                                           ~~~~~~~~~~^~~~~~
>       |                                                     |
>       |                                                     struct peer *
> bgpd/bgp_io.c:202:9: note: in expansion of macro ‘frrtrace’
>   202 |         frrtrace(2, frr_bgp, packet_read, connection->peer, pkt);
>       |         ^~~~~~~~
> In file included from ./bgpd/bgp_trace.h:21,
>                  from bgpd/bgp_io.c:27:
> ./bgpd/bgp_trace.h:57:43: note: expected ‘struct peer_connection *’ but argument is of type ‘struct peer *’
>    57 |         TP_ARGS(struct peer_connection *, connection, struct stream *, pkt),
>       |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~

Use the appropriate connection parameter when calling the trace.

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>
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
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
>     FRRouting#5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
>     FRRouting#8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#11 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#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
>     FRRouting#1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
>     FRRouting#3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
>     FRRouting#4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
>     FRRouting#5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
>     FRRouting#6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
>     FRRouting#7 0x7fbf5f18078d in event_call lib/event.c:1996
>     FRRouting#8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
>     FRRouting#9 0x562740c0cae1 in main bgpd/bgp_main.c:557
>     FRRouting#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>
Add a test where, when the vrf interface is flapping, a peer up message
is sent. This test, when used with ASAN, detects the memory leak of the
open_tx and open_rx messages of the loc-rib.

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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The peer distinguisher format was badly displayed when a per peer
header is sent with an IP:AS2B format.

>  {"peer_type": "loc-rib instance", "is_filtered": false, "policy": "loc-rib",
> "peer_distinguisher": "None:2", ...

The IP header is incorrectly read. Fix it.

> {"peer_type": "loc-rib instance", "is_filtered": false, "policy": "loc-rib",
> "peer_distinguisher": "3.3.3.5:2", ...

Fixes: 875511c ("topotests: add basic bmp collector")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test with a new peer defined in a VRF, and where
the BGP updates are imported in the BMP instance of the
default BGP instance.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following memory leak is observed when running bgp_bmp test.

> ==614841==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 81 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101
>     FRRouting#2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207
>     FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247
>     FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476
>     FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526
>     FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547
>     FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89
>     FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305
>     FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393
>     FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99
>     FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626
>     FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 64 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     FRRouting#1 0x7f0e9ec77235 in qcalloc lib/memory.c:106
>     FRRouting#2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 6 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814
>     FRRouting#3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493
>     FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Indirect leak of 5 byte(s) in 1 object(s) allocated from:
>     #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
>     FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118
>     FRRouting#2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443
>     FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855
>     FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147
>     FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003
>     FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062
>     FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228
>     FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626
>     FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389
>     FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408
>     FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996
>     FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232
>     FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555
>     FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s).

Fix this by freeing the missing memory block that helps building the
open message to send to remote bmp collector.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The bgpbmp parameter is not used. Instead the bgp pointer, and
the vrf state are used.

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>
Add a test to control the value of the peer bgp id of loc-rib peer up
messages when the bgp router-id is reconfigured.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
…outer-id changes

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>
…rf flaps

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>
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>
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.

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
>     FRRouting#1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149
>     FRRouting#2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520
>     FRRouting#3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566
>     FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
>     FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234
>     FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57
>     FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203
>     FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671
>     FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624
>     FRRouting#10 0x7f738998078d in event_call lib/event.c:1996
>     FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232
>     FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557
>     FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>     FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392
>     FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234)

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>
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>
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>
Add a test that controls that the configuration of an imported
BGP instance triggers a re-syncronisation.
Ensure that changing an attribute like route distinguisher
triggers also a re-syncronisation.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the bmp import-vrf-view command on the bmp user guide.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
@pguibert6WIND pguibert6WIND marked this pull request as ready for review December 20, 2024 14:47
@pguibert6WIND
Copy link
Member Author

ci:rerun unrelated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant