-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pguibert6WIND
force-pushed
the
bmp_import_vrf_view
branch
5 times, most recently
from
December 17, 2024 20:41
5c31cba
to
ca848dd
Compare
some memory leak issues yet. |
pguibert6WIND
force-pushed
the
bmp_import_vrf_view
branch
3 times, most recently
from
December 20, 2024 14:46
2c3d360
to
dbf848c
Compare
ci:rerun unrelated |
pguibert6WIND
force-pushed
the
bmp_import_vrf_view
branch
2 times, most recently
from
December 30, 2024 14:15
d2a22d3
to
848ef57
Compare
This pull request is partially based on #17733. |
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Modify the bmp_process() function to export the route update information to all BMP instances importing it. Signed-off-by: Philippe Guibert <[email protected]>
Modify the bmp_mirror() function to export the route update information to all BMP instances importing it. Signed-off-by: Philippe Guibert <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
The bgpbmp parameter is not used. Instead the bgp pointer, and the vrf state are used. Signed-off-by: Philippe Guibert <[email protected]>
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 <[email protected]>
…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 <[email protected]>
…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 <[email protected]>
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 <[email protected]>
…ram changed 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 <[email protected]>
> 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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Modify the bmp_eor() function to send end of rib messages for each peer of the current BGP instance. Signed-off-by: Philippe Guibert <[email protected]>
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 <[email protected]>
Add the bmp import-vrf-view command on the bmp user guide. Signed-off-by: Philippe Guibert <[email protected]>
pguibert6WIND
force-pushed
the
bmp_import_vrf_view
branch
from
January 7, 2025 14:37
848ef57
to
9f2932d
Compare
ci:rerun unrelated |
ci:rerun issue unrelated |
ci:rerun unrelated |
riw777
approved these changes
Jan 14, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).