summaryrefslogtreecommitdiff
path: root/bgpd/bgp_mplsvpn.c
AgeCommit message (Collapse)Author
2025-02-13bgpd: Fix crash in bgp_labelpoolDonald Sharp
The bgp labelpool code is grabbing the vpn policy data structure. This vpn_policy has a pointer to the bgp data structure. If a item placed on the bgp label pool workqueue happens to sit there for the microsecond or so and the operator issues a `no router bgp...` command that corresponds to the vpn_policy bgp pointer, when the workqueue is run it will crash because the bgp pointer is now freed and something else owns it. Modify the labelpool code to store the vrf id associated with the request on the workqueue. When you wake up if the vrf id still has a bgp pointer allow the request to continue, else drop it. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 14eac319e8ae9314f5270f871106a70c4986c60c)
2024-10-23bgpd: Include structure when removing End.DT46 SIDCarmine Scarpitta
Include SID structure information when removing an SRv6 End.DT46 SID from the forwarding plane. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-10-23bgpd: Include structure when removing End.DT4/6 SIDCarmine Scarpitta
Include SID structure information when removing an SRv6 End.DT4 or End.DT6 SID from the forwarding plane. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-10-23bgpd: Include structure when installing End.DT46 SIDCarmine Scarpitta
Include SID structure information when installing an SRv6 End.DT46 SID in the forwarding plane. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-10-23bgpd: Include structure when installing End.DT4/6 SIDCarmine Scarpitta
Include SID structure information when installing an SRv6 End.DT6 or End.DT4 SID in the forwarding plane. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-08-27bgpd: fix labels static-analyserLouis Scalbert
Fix static-analyser warnings with BGP labels: > $ scan-build make -j12 > bgpd/bgp_updgrp_packet.c:819:10: warning: Access to field 'extra' results in a dereference of a null pointer (loaded from variable 'path') [core.NullDereference] > ? &path->extra->labels->label[0] > ^~~~~~~~~ Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-07-29bgpd: Do not process VRF import/export to/from auto created VRF instancesDonatas Abraitis
Fixes the crash: ``` (gdb) bt 0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:44 1 __pthread_kill_internal (signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:78 2 __GI___pthread_kill (threadid=124583315603008, signo=signo@entry=11) at ./nptl/pthread_kill.c:89 3 0x0000714ed0242476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 4 0x0000714ed074cfb7 in core_handler (signo=11, siginfo=0x7ffe6d9792b0, context=0x7ffe6d979180) at lib/sigevent.c:258 5 <signal handler called> 6 0x000060f55e33ffdd in route_table_get_info (table=0x0) at ./lib/table.h:177 7 0x000060f55e340053 in bgp_dest_table (dest=0x60f56dabb840) at ./bgpd/bgp_table.h:156 8 0x000060f55e340c9f in is_route_injectable_into_vpn (pi=0x60f56dbc4a60) at ./bgpd/bgp_mplsvpn.h:331 9 0x000060f55e34507c in vpn_leak_from_vrf_update (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, path_vrf=0x60f56dbc4a60) at bgpd/bgp_mplsvpn.c:1575 10 0x000060f55e346657 in vpn_leak_from_vrf_update_all (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, afi=AFI_IP) at bgpd/bgp_mplsvpn.c:2028 11 0x000060f55e340c10 in vpn_leak_postchange (direction=BGP_VPN_POLICY_DIR_TOVPN, afi=AFI_IP, bgp_vpn=0x60f56da52070, bgp_vrf=0x60f56da75af0) at ./bgpd/bgp_mplsvpn.h:310 12 0x000060f55e34a692 in vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3737 13 0x000060f55e3d91fc in router_bgp (self=0x60f55e5cbc20 <router_bgp_cmd>, vty=0x60f56e2d7660, argc=3, argv=0x60f56da19830) at bgpd/bgp_vty.c:1601 14 0x0000714ed069ddf5 in cmd_execute_command_real (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, up_level=0) at lib/command.c:1002 15 0x0000714ed069df6e in cmd_execute_command (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, vtysh=0) at lib/command.c:1061 16 0x0000714ed069e51e in cmd_execute (vty=0x60f56e2d7660, cmd=0x60f56dbf07d0 "router bgp 100\n", matched=0x0, vtysh=0) at lib/command.c:1227 17 0x0000714ed076faa0 in vty_command (vty=0x60f56e2d7660, buf=0x60f56dbf07d0 "router bgp 100\n") at lib/vty.c:616 18 0x0000714ed07719c4 in vty_execute (vty=0x60f56e2d7660) at lib/vty.c:1379 19 0x0000714ed07740f0 in vtysh_read (thread=0x7ffe6d97c700) at lib/vty.c:2374 20 0x0000714ed07685c4 in event_call (thread=0x7ffe6d97c700) at lib/event.c:1995 21 0x0000714ed06e3351 in frr_run (master=0x60f56d1d2e40) at lib/libfrr.c:1232 22 0x000060f55e2c4b44 in main (argc=7, argv=0x7ffe6d97c978) at bgpd/bgp_main.c:555 (gdb) ``` Fixes https://github.com/FRRouting/frr/issues/16484 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit 04f9372409a11a59dafbbf8423f0cf832b99cf0e)
2024-06-05bgpd: move labels from extra to extra->labelsLouis Scalbert
Move labels from extra to extra->labels. Labels are now stored in a hash list. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: store number of labels with 8 bitsLouis Scalbert
8 bits are sufficient to store the number of labels because the current maximum is 2. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_num_labels()Louis Scalbert
Add bgp_path_info_num_labels() to get the number of labels stored in a path_info structure. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: num_labels cannot be greater than BGP_MAX_LABELSLouis Scalbert
num_labels cannot be greater than BGP_MAX_LABELS by design. Remove the check and the override. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_labels_same()Louis Scalbert
Add bgp_path_info_labels_same() to compare labels with labels from path_info. Remove labels_same() that was used for mplsvpn only. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_has_valid_label()Louis Scalbert
Add bgp_path_has_valid_label to check that a path_info has a valid label. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: check and set extra num_labelsLouis Scalbert
The handling of MPLS labels in BGP faces an issue due to the way labels are stored in memory. They are stored in bgp_path_info but not in bgp_adj_in and bgp_adj_out structures. As a consequence, some configuration changes result in losing labels or even a bgpd crash. For example, when retrieving routes from the Adj-RIB-in table ("soft-reconfiguration inbound" enabled), labels are missing. bgp_path_info stores the MPLS labels, as shown below: > struct bgp_path_info { > struct bgp_path_info_extra *extra; > [...] > struct bgp_path_info_extra { > mpls_label_t label[BGP_MAX_LABELS]; > uint32_t num_labels; > [...] To solve those issues, a solution would be to set label data to the bgp_adj_in and bgp_adj_out structures in addition to the bgp_path_info_extra structure. The idea is to reference a common label pointer in all these three structures. And to store the data in a hash list in order to save memory. However, an issue in the code prevents us from setting clean data without a rework. The extra->num_labels field, which is intended to indicate the number of labels in extra->label[], is not reliably checked or set. The code often incorrectly assumes that if the extra pointer is present, then a label must also be present, leading to direct access to extra->label[] without verifying extra->num_labels. This assumption usually works because extra->label[0] is set to MPLS_INVALID_LABEL when a new bgp_path_info_extra is created, but it is technically incorrect. Cleanup the label code by setting num_labels each time values are set in extra->label[] and checking extra->num_labels before accessing the labels. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-05-20bgpd, tests: fix route leaking from the default l3vrfLouis Scalbert
Leaked route from the l3VRF are installed with the loopback as the nexthop interface instead of the real interface. > B>* 10.0.0.0/30 [20/0] is directly connected, lo (vrf default), weight 1, 00:21:01 Routing of packet from a L3VRF to the default L3VRF destined to a leak prefix fails because of the default routing rules on Linux. > 0: from all lookup local > 1000: from all lookup [l3mdev-table] > 32766: from all lookup main > 32767: from all lookup default When the packet is received in the loopback interface, the local rules are checked without match, then the l3mdev-table says to route to the loopback. A routing loop occurs (TTL is decreasing). > 12:26:27.928748 ens37 In IP (tos 0x0, ttl 64, id 26402, offset 0, flags [DF], proto ICMP (1), length 84) > 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64 > 12:26:27.928784 red Out IP (tos 0x0, ttl 63, id 26402, offset 0, flags [DF], proto ICMP (1), length 84) > 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64 > 12:26:27.928797 ens38 Out IP (tos 0x0, ttl 63, id 26402, offset 0, flags [DF], proto ICMP (1), length 84) > 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64 Do not set the lo interface as a nexthop interface. Keep the real interface where possible. Fixes: db7cf73a33 ("bgpd: fix interface on leaks from redistribute connected") Fixes: 067fbab4e4 ("bgpd: fix interface on leaks from network statement") Fixes: 8a02d9fe1e ("bgpd: Set nh ifindex to VRF's interface, not the real") Fixes: https://github.com/FRRouting/frr/issues/15909 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-04-18bgpd: do allocate vrf label only when necessaryPhilippe Guibert
Today, with the following bgp instance configured, the local VRF label is allocated even if it is not used. > router bgp 65500 vrf vrf1 > address-family ipv4 unicast > label vpn export allocation-mode per-nexthop > label vpn export auto > rd vpn export 444:1 > rt vpn both 52:100 > export vpn > import vpn The 'show mpls table' indicates that the 16 label value is allocated, but never used in the exported prefixes. > r1# show mpls table > Inbound Label Type Nexthop Outbound Label > ----------------------------------------------------- > 16 BGP vrf1 - > 17 BGP 192.168.255.13 - > 18 BGP 192.0.2.12 - > 19 BGP 192.0.2.11 - Fix this by only allocating new label values when really used. Consequently, only 3 labels will be allocated instead of previously 4. > r1# show mpls table > Inbound Label Type Nexthop Outbound Label > ----------------------------------------------------- > 16 BGP 192.168.255.13 - > 17 BGP 192.0.2.11 - > 18 BGP 192.0.2.12 - Fixes: 577be36a41be ("bgpd: add support for l3vpn per-nexthop label") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-04-01bgpd: Sort the bgp_path_info'sDonald Sharp
Currently bgp_path_info's are stored in reverse order received. Sort them by the best path ordering. This will allow for optimizations in the future on how multipath is done. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-04-01bgpd: Add pi to bgp_processDonald Sharp
This will allow a consistency of approach to adding/removing pi's to from the workqueue for processing as well as properly handling the dest->info pi list more appropriately. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-29bgpd: fix srv6 memory leak detectionPhilippe Guibert
The asan memory leak has been detected: > Direct leak of 16 byte(s) in 1 object(s) allocated from: > #0 0x7f9066dadd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) > #1 0x7f9066779b5d in qcalloc lib/memory.c:105 > #2 0x556d6ca527c2 in vpn_leak_zebra_vrf_sid_update_per_af bgpd/bgp_mplsvpn.c:389 > #3 0x556d6ca530e1 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:451 > #4 0x556d6ca64b3b in vpn_leak_postchange bgpd/bgp_mplsvpn.h:311 > #5 0x556d6ca64b3b in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3751 > #6 0x556d6cb9f116 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3337 > #7 0x7f906685a6b6 in zclient_read lib/zclient.c:4490 > #8 0x7f9066826a32 in event_call lib/event.c:2011 > #9 0x7f906675c444 in frr_run lib/libfrr.c:1217 > #10 0x556d6c980d52 in main bgpd/bgp_main.c:545 > #11 0x7f9065784c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Fix this by freeing the previous memory chunk. Fixes: b72c9e14756f ("bgpd: cli for SRv6 SID alloc to redirect to vrf (step4)") Fixes: 527588aa78b2 ("bgpd: add support for per-VRF SRv6 SID") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-02-14bgpd: update route leak when vrf state changesLouis Scalbert
Locally leaked routes remain active after the nexthop VRF interface goes down. Update route leaking when the loopback or a VRF interface state change is received from zebra. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-02-01bgpd: fix interface on leaks from redistribute connectedLouis Scalbert
In the target VRF's Routing Information Base (RIB), routes that are leaked and originate from the 'redistribute connected' command have their next-hop interface set as the interface from the source VRF. This prevents the IP address of the connected interface from being reachable from the target VRF. > router bgp 5227 vrf r1-cust1 > address-family ipv4 unicast > redistribute connected > rd vpn export 10:1 > rt vpn import 52:100 > rt vpn export 52:101 > export vpn > import vpn > exit-address-family > exit > ! > router bgp 5227 vrf r1-cust4 > address-family ipv4 unicast > network 192.0.2.0/24 > rd vpn export 10:1 > rt vpn import 52:101 > rt vpn export 52:100 > export vpn > import vpn > exit-address-family > exit > ! > vrf r1-cust1 > ip route 192.0.2.0/24 r1-cust4 nexthop-vrf r1-cust4 Extract from the routing table: > VRF r1-cust1: > C>* 172.16.29.0/24 is directly connected, r1-eth4, 00:44:15 > S>* 192.0.2.0/24 [1/0] is directly connected, r1-cust4 (vrf r1-cust4), weight 1, 00:00:30 > > VRF r1-cust4: > B>* 172.16.29.0/24 [20/0] is directly connected, r1-eth4 (vrf r1-cust1), weight 1, 00:00:02 In r1-cust4 VRF, the nexthop interface of 172.16.29.0/24 is r1-eth4, which is unknown in the context. The following ping does not work: > # tcpdump -lnni r1-cust1 'icmp' & > # ip vrf exec r1-cust4 ping -c1 -I 192.0.2.1 172.16.29.1 > PING 172.16.29.1 (172.16.29.1) 56(84) bytes of data. PING 172.16.29.1 (172.16.29.1) from 192.0.2.1 : 56(84) bytes of data. 18:49:20.635638 IP 192.0.2.1 > 172.16.29.1: ICMP echo request, id 15897, seq 1, length 64 18:49:27.113827 IP 192.0.2.1 > 192.0.2.1: ICMP host 172.16.29.1 unreachable, length 92 Fix the issue by setting nh_ifindex to the index of the VRF master interface of the incoming BGP instance. The result is: > VRF r1-cust4: > C>* 192.0.2.0/24 is directly connected, r1-cust5, 00:27:40 > B>* 172.16.29.0/24 [20/0] is directly connected, r1-cust1 (vrf r1-cust1), weight 1, 00:00:08 > # tcpdump -lnni r1-cust1 'icmp' & > # ping -c1 172.16.29.1 -I 192.0.2.1 > PING 172.16.29.1 (172.16.29.1) from 192.0.2.1 : 56(84) bytes of data. > 18:48:32.506281 IP 192.0.2.1 > 172.16.29.1: ICMP echo request, id 15870, seq 1, length 64 > 64 bytes from 172.16.29.1: icmp_seq=1 ttl=64 time=0.050 ms > 18:48:32.506304 IP 172.16.29.1 > 192.0.2.1: ICMP echo reply, id 15870, seq 1, length 64 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-02-01bgpd: fix interface on leaks from network statementLouis Scalbert
Leaked routes from prefixes defined with 'network <prefix>' are inactive because they have no valid nexthop interface. > vrf r1-cust1 > ip route 172.16.29.0/24 192.168.1.2 > router bgp 5227 vrf r1-cust1 > no bgp network import-check > address-family ipv4 unicast > network 172.16.29.0/24 > rd vpn export 10:1 > rt vpn import 52:100 > rt vpn export 52:101 > export vpn > import vpn > exit-address-family > exit > ! > router bgp 5227 vrf r1-cust4 > bgp router-id 192.168.1.1 > ! > address-family ipv4 unicast > network 192.0.2/24 > rd vpn export 10:1 > rt vpn import 52:101 > rt vpn export 52:100 > export vpn > import vpn > exit-address-family > exit Extract from the routing table: > VRF r1-cust1: > S>* 172.16.29.0/24 [1/0] via 192.168.1.2, r1-eth4, weight 1, 00:47:53 > > VRF r1-cust4: > B 172.16.29.0/24 [20/0] is directly connected, unknown (vrf r1-cust1) inactive, weight 1, 00:03:40 Routes imported through the "network" command, as opposed to those redistributed from the routing table, do not associate with any specific interface. When leaking prefix from other VRFs, if the route was imported from the network statement (ie. static sub-type), set nh_ifindex to the index of the VRF master interface of the incoming BGP instance. The result is: > VRF r1-cust4: > B>* 172.16.29.0/24 [20/0] is directly connected, r1-cust1 (vrf r1-cust1), weight 1, 00:00:08 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-01-29bgpd: fix VRF leaking with 'network import-check' (3/4)Louis Scalbert
If 'bgp network import-check' is defined on the source BGP session, prefixes that are defined with the network command cannot be leaked to the other VRFs BGP table even if they are present in the origin VRF RIB if the 'rt import' statement is defined after the 'network <prefix>' ones. When a prefix nexthop is updated, update the prefix route leaking. The current state of nexthop validation is now stored in the attributes of the bgp path info. Attributes are compared with the previous ones at route leaking update so that a nexthop validation change now triggers the update of destination VRF BGP table. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-01-29bgpd: fix VRF leaking with 'network import-check' (1/4)Louis Scalbert
If 'bgp network import-check' is defined on the source BGP session, prefixes that are defined with the network command cannot be leaked to the other VRFs BGP table even if they are present in the origin VRF RIB. Always validate the nexthop of BGP static routes (i.e. defined with the network statement) if 'network import-check' is defined on the source BGP session and the prefix is present in source RIB. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-01-25bgpd: fix VRF leaking with 'no bgp network import-check'Louis Scalbert
BGP static routes are defined using the network statement, e.g.: > router bgp XXX > address-family ipv4 unicast > network 192.168.0.0/24 When "no bgp network import-check" is set, it is impossible to successfully import the static routes into the BGP VPN table. The prefix is present in the table but is not marked as valid. This issue applies regardless of whether or not routes are present in the router's RIB. Always mark as valid the nexthops of BGP static routes when "no bgp network import-check" is set. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-11-29bgpd: Free Memory for SRv6 Functions and Locator ChunksKeelan10
Implement proper memory cleanup for SRv6 functions and locator chunks to prevent potential memory leaks. The list callback deletion functions have been set. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.asan.bgpd.4180 ================================================================= ==4180==ERROR: LeakSanitizer: detected memory leaks Direct leak of 544 byte(s) in 2 object(s) allocated from: #0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f8d1709f238 in qcalloc lib/memory.c:105 #2 0x55d5dba6ee75 in sid_register bgpd/bgp_mplsvpn.c:591 #3 0x55d5dba6ee75 in alloc_new_sid bgpd/bgp_mplsvpn.c:712 #4 0x55d5dba6f3ce in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:758 #5 0x55d5dba6fb94 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:849 #6 0x55d5dba7f975 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:299 #7 0x55d5dba7f975 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3704 #8 0x55d5dbbb6c66 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3164 #9 0x7f8d1716f08a in zclient_read lib/zclient.c:4459 #10 0x7f8d1713f034 in event_call lib/event.c:1974 #11 0x7f8d1708242b in frr_run lib/libfrr.c:1214 #12 0x55d5db99d19d in main bgpd/bgp_main.c:510 #13 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 296 byte(s) in 1 object(s) allocated from: #0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f8d1709f238 in qcalloc lib/memory.c:105 #2 0x7f8d170b1d5f in srv6_locator_chunk_alloc lib/srv6.c:135 #3 0x55d5dbbb6a19 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3144 #4 0x7f8d1716f08a in zclient_read lib/zclient.c:4459 #5 0x7f8d1713f034 in event_call lib/event.c:1974 #6 0x7f8d1708242b in frr_run lib/libfrr.c:1214 #7 0x55d5db99d19d in main bgpd/bgp_main.c:510 #8 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
2023-11-21bgpd, topotests: apply route-map after rt vpn exportPhilippe Guibert
A route-map can be programmed to remove the route-target which has been set with 'rt vpn export' command, but fails to remove it. Fix this by applying the route-map, then considering the resulting extended community-list. Add some tests to catch this issue. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-11-21bgpd: fix bgp node created at withdraw eventPhilippe Guibert
The prefixes unexportation triggers an attempt to create the VPN prefix node if that prefix was not already present. For instance, if a given prefix is not exported because of a route-map filtering, the withdraw process will try to create the node with the 'bgp_afi_node_get()' command. Fix this by replacing this call by the 'bgp_safi_node_lookup()' function. Fixes: ddb5b4880ba8 ("bgpd: vpn-vrf route leaking") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-11-21bgpd: fix export prefixes when rt extcomm set by route-mapPhilippe Guibert
When exporting BGP prefixes, it is necessary to configure the route target extended communities with the following command: > rt vpn export <RouteTarget> But the customer may need to configure the route-target to apply to bgp updates, solely based on a route-map criterium. by using the below route-map configured like that: > route-map vpn export <routemapname> Fix this by allowing to export bgp updates based on the presence of route-targets on either route-map or vpn configured rt. the exportation process is stopped if no route target is available in the ecommunity list. Fixes: ddb5b4880ba8 ("bgpd: vpn-vrf route leaking") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-10-13bgpd: Ecommunity_dup memory leak fixryndia
The shallow copy of attr wasn't freed when there was no valid label for the momentand the function return therefore creating leaks. The leak below are solved by flushing the shallow copy of attr. Address Sanitizer Error detected in bgp_vpnv6_per_nexthop_label.test_bgp_vpnv6_per_nexthop_label/r1.asan.bgpd.13409 ================================================================= ==13409==ERROR: LeakSanitizer: detected memory leaks Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 #14 0x7f62ccb62b8f in event_call lib/event.c:1969 #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #16 0x5623b87e054b in main bgpd/bgp_main.c:510 #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969 #5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #11 0x5623b87e054b in main bgpd/bgp_main.c:510 #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 #14 0x7f62ccb62b8f in event_call lib/event.c:1969 #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #16 0x5623b87e054b in main bgpd/bgp_main.c:510 #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 240 byte(s) in 6 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #11 0x5623b87e054b in main bgpd/bgp_main.c:510 #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 120 byte(s) in 3 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #7 0x7f62ccb62b8f in event_call lib/event.c:1969 #8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #9 0x5623b87e054b in main bgpd/bgp_main.c:510 #10 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 80 byte(s) in 2 object(s) allocated from: #0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f62ccac21c3 in qcalloc lib/memory.c:105 #2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #11 0x5623b87e054b in main bgpd/bgp_main.c:510 #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 #14 0x7f62ccb62b8f in event_call lib/event.c:1969 #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #16 0x5623b87e054b in main bgpd/bgp_main.c:510 #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969 #5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #11 0x5623b87e054b in main bgpd/bgp_main.c:510 #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978 #9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036 #10 0x7f62cca45e54 in cmd_execute lib/command.c:1203 #11 0x7f62ccb6ee20 in vty_command lib/vty.c:591 #12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354 #13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362 #14 0x7f62ccb62b8f in event_call lib/event.c:1969 #15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #16 0x5623b87e054b in main bgpd/bgp_main.c:510 #17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 48 byte(s) in 6 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #11 0x5623b87e054b in main bgpd/bgp_main.c:510 #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 24 byte(s) in 3 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #7 0x7f62ccb62b8f in event_call lib/event.c:1969 #8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #9 0x5623b87e054b in main bgpd/bgp_main.c:510 #10 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 16 byte(s) in 2 object(s) allocated from: #0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100 #2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425 #9 0x7f62ccb62b8f in event_call lib/event.c:1969 #10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213 #11 0x5623b87e054b in main bgpd/bgp_main.c:510 #12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s). *********************************************************************************** Address Sanitizer Error detected in bgp_vpnv4_per_nexthop_label.test_bgp_vpnv4_per_nexthop_label/r1.asan.bgpd.10610 ================================================================= ==10610==ERROR: LeakSanitizer: detected memory leaks Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969 #5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 #11 0x7f81fc007e20 in vty_command lib/vty.c:591 #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 #14 0x7f81fbffbb8f in event_call lib/event.c:1969 #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #16 0x55cdc9af854b in main bgpd/bgp_main.c:510 #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 280 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 #11 0x7f81fc007e20 in vty_command lib/vty.c:591 #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 #14 0x7f81fbffbb8f in event_call lib/event.c:1969 #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #16 0x55cdc9af854b in main bgpd/bgp_main.c:510 #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 240 byte(s) in 6 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 80 byte(s) in 2 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 80 byte(s) in 2 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581 #7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118 #8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105 #2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #7 0x7f81fbffbb8f in event_call lib/event.c:1969 #8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #9 0x55cdc9af854b in main bgpd/bgp_main.c:510 #10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464 #7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 #11 0x7f81fc007e20 in vty_command lib/vty.c:591 #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 #14 0x7f81fbffbb8f in event_call lib/event.c:1969 #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #16 0x55cdc9af854b in main bgpd/bgp_main.c:510 #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547 #7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868 #8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978 #9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036 #10 0x7f81fbedee54 in cmd_execute lib/command.c:1203 #11 0x7f81fc007e20 in vty_command lib/vty.c:591 #12 0x7f81fc0082cb in vty_execute lib/vty.c:1354 #13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362 #14 0x7f81fbffbb8f in event_call lib/event.c:1969 #15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #16 0x55cdc9af854b in main bgpd/bgp_main.c:510 #17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 56 byte(s) in 7 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969 #5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213 #6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341 #7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220 #8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 48 byte(s) in 6 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 16 byte(s) in 2 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348 #5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733 #6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934 #7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104 #8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 16 byte(s) in 2 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005 #5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287 #6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581 #7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118 #8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266 #9 0x7f81fbffbb8f in event_call lib/event.c:1969 #10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #11 0x55cdc9af854b in main bgpd/bgp_main.c:510 #12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100 #2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256 #3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628 #4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692 #5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595 #6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425 #7 0x7f81fbffbb8f in event_call lib/event.c:1969 #8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213 #9 0x55cdc9af854b in main bgpd/bgp_main.c:510 #10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s). *********************************************************************************** Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
2023-10-12bgpd: Remove redundant check for bgp against NULLDonatas Abraitis
bgp_orig is never NULL in the code path, and coverity is angry on this. Let's remove this test at all. Coverity 1566808 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-09-22bgpd: Use proper AFI when dumping information for dampening stuffDonatas Abraitis
Before we called IPv4 for IPv6 dampening info. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-09-20Merge pull request #14442 from mjstapp/fix_no_ctimeDonald Sharp
bgpd, pathd: replace ctime() with ctime_r()
2023-09-19bgpd: replace ctime with ctime_rMark Stapp
No ctime, use ctime_r. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-09-19bgpd: Prevent use after free from coverity's perspectiveDonald Sharp
Prevent a use after free from coverity's perspective. A bgp node may have been freed. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-11bgpd: Ensure that leak_update does not free memory before it is being usedDonald Sharp
The unlock may cause the bgp_process to use dest. Ensure that this does not happen. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-14bgpd: Refactor bgp_static_set/bgp_static_set_safiDonatas Abraitis
Those two functions are very similar, let's get a single one. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-08-08bgpd: bgp_path_info_extra memory optimizationValerian_He
Even if some of the attributes in bgp_path_info_extra are not used, their memory is still allocated every time. It cause a waste of memory. This commit code deletes all unnecessary attributes and changes the optional attributes to pointer storage. Memory will only be allocated when they are actually used. After optimization, extra info related memory is reduced by about half(~400B -> ~200B). Signed-off-by: Valerian_He <1826906282@qq.com>
2023-07-05bgpd: Free nexthop in bgp_mplsvpn_nh_label_bind_freeKeelan10
`bmnc->nh` was not properly freed, leading to a memory leak. The commit adds a check to ensure that the `bmnc->nh` member variable is freed if it exists. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in bgp_vpnv4_asbr.test_bgp_vpnv4_asbr/r2.asan.bgpd.6382 ================================================================= ==6382==ERROR: LeakSanitizer: detected memory leaks Direct leak of 720 byte(s) in 5 object(s) allocated from: #0 0x7f6a80d02d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x55c9afd7c81c in qcalloc lib/memory.c:105 #2 0x55c9afd9166b in nexthop_new lib/nexthop.c:358 #3 0x55c9afd93aaa in nexthop_dup lib/nexthop.c:843 #4 0x55c9afad39bb in bgp_mplsvpn_nh_label_bind_register_local_label bgpd/bgp_mplsvpn.c:4259 #5 0x55c9afb1c5e9 in bgp_mplsvpn_handle_label_allocation bgpd/bgp_route.c:3239 #6 0x55c9afb1c5e9 in bgp_process_main_one bgpd/bgp_route.c:3339 #7 0x55c9afb1d2c1 in bgp_process_wq bgpd/bgp_route.c:3591 #8 0x55c9afe33df9 in work_queue_run lib/workqueue.c:266 #9 0x55c9afe198e2 in event_call lib/event.c:1995 #10 0x55c9afd5fc6f in frr_run lib/libfrr.c:1213 #11 0x55c9af9f6f00 in main bgpd/bgp_main.c:505 #12 0x7f6a7f55ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 16 byte(s) in 2 object(s) allocated from: #0 0x7f6a80d02d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x55c9afd7c81c in qcalloc lib/memory.c:105 #2 0x55c9afd91ce8 in nexthop_add_labels lib/nexthop.c:536 #3 0x55c9afd93754 in nexthop_copy_no_recurse lib/nexthop.c:802 #4 0x55c9afd939fb in nexthop_copy lib/nexthop.c:821 #5 0x55c9afd93abb in nexthop_dup lib/nexthop.c:845 #6 0x55c9afad39bb in bgp_mplsvpn_nh_label_bind_register_local_label bgpd/bgp_mplsvpn.c:4259 #7 0x55c9afb1c5e9 in bgp_mplsvpn_handle_label_allocation bgpd/bgp_route.c:3239 #8 0x55c9afb1c5e9 in bgp_process_main_one bgpd/bgp_route.c:3339 #9 0x55c9afb1d2c1 in bgp_process_wq bgpd/bgp_route.c:3591 #10 0x55c9afe33df9 in work_queue_run lib/workqueue.c:266 #11 0x55c9afe198e2 in event_call lib/event.c:1995 #12 0x55c9afd5fc6f in frr_run lib/libfrr.c:1213 #13 0x55c9af9f6f00 in main bgpd/bgp_main.c:505 #14 0x7f6a7f55ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 736 byte(s) leaked in 7 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
2023-07-04bgpd: free bgp vpn policyryndia
The bgp vpn policy had some attribute not free when the function bgp_free was called leading to memory leak as shown below. ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251:Direct leak of 592 byte(s) in 2 object(s) allocated from: ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #0 0x7f4b7ae92037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #1 0x7f4b7aa96e38 in qcalloc lib/memory.c:105 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #2 0x7f4b7aa9bec9 in srv6_locator_chunk_alloc lib/srv6.c:135 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #3 0x56396f8e56f8 in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:752 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #4 0x56396f8e608a in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:846 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #5 0x56396f8e075d in vpn_leak_postchange bgpd/bgp_mplsvpn.h:259 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #6 0x56396f8f3e5b in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3397 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #7 0x56396fa920ef in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3238 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #8 0x7f4b7abb2913 in zclient_read lib/zclient.c:4134 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #9 0x7f4b7ab62010 in thread_call lib/thread.c:1991 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #10 0x7f4b7aa5a418 in frr_run lib/libfrr.c:1185 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #11 0x56396f7d756d in main bgpd/bgp_main.c:505 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #12 0x7f4b7a479d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251:Direct leak of 32 byte(s) in 2 object(s) allocated from: ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #0 0x7f4b7ae92037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #1 0x7f4b7aa96e38 in qcalloc lib/memory.c:105 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #2 0x56396f8e31b8 in vpn_leak_zebra_vrf_sid_update_per_af bgpd/bgp_mplsvpn.c:386 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #3 0x56396f8e3ae8 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:448 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #4 0x56396f8e09b0 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:271 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #5 0x56396f8f3e5b in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3397 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #6 0x56396fa920ef in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3238 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #7 0x7f4b7abb2913 in zclient_read lib/zclient.c:4134 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #8 0x7f4b7ab62010 in thread_call lib/thread.c:1991 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #9 0x7f4b7aa5a418 in frr_run lib/libfrr.c:1185 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #10 0x56396f7d756d in main bgpd/bgp_main.c:505 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #11 0x7f4b7a479d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251:Direct leak of 32 byte(s) in 2 object(s) allocated from: ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #0 0x7f4b7ae92037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #1 0x7f4b7aa96e38 in qcalloc lib/memory.c:105 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #2 0x56396f8e5730 in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:753 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #3 0x56396f8e608a in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:846 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #4 0x56396f8e075d in vpn_leak_postchange bgpd/bgp_mplsvpn.h:259 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #5 0x56396f8f3e5b in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3397 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #6 0x56396fa920ef in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3238 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #7 0x7f4b7abb2913 in zclient_read lib/zclient.c:4134 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #8 0x7f4b7ab62010 in thread_call lib/thread.c:1991 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #9 0x7f4b7aa5a418 in frr_run lib/libfrr.c:1185 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #10 0x56396f7d756d in main bgpd/bgp_main.c:505 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- #11 0x7f4b7a479d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251- ./bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.bgpd.asan.603251-SUMMARY: AddressSanitizer: 656 byte(s) leaked in 6 allocation(s). Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
2023-06-28bgpd: fix covery 1566055, label table overrunPhilippe Guibert
In case the full label stack is used, there may be a table overrun happening. Avoid it by increasing the size of the table. Fixes: 27f4deed0ac1 ("bgpd: update the mpls entry to handle return traffic") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-06-28bgpd: fix covery scan 1566054 with null pointerPhilippe Guibert
The bmnc pointer is never null. Do not keep the test on the pointer. Fixes: 1069425868d1 ("bgpd: allocate label bound to received mpls vpn routes") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-06-20Merge pull request #13750 from louis-6wind/fix-no-retain-memory-usageRuss White
bgpd: fix memory usage of vpn no retain
2023-06-16bgpd: cleanup un-imported vpn prefix if no retain setLouis Scalbert
After some VRF imports are removed and "no bgp retain route-target all" is set, prefixes that are not imported anymore remain in the BGP table. Parse the BGP table and remove un-imported prefixes in such a case. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2023-06-16bgpd: fix memory usage of vpn no retainLouis Scalbert
By default, bgpd stores all MPLS VPN SAFI prefixes unless the "no bgp retain route-target all" option is used to store only prefixes that are imported into local VRFs. The "no retain" option temporarily uses too much memory, as all prefixes are stored in memory before the deletion of non-imported prefixes is done. Filter out non-imported prefixes before they are set into the BGP adj RIB out. Fixes: a486300b26 ("bgpd: implement retain route-target all behaviour") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2023-06-16bgpd: revert no retain backendLouis Scalbert
Partially revert a486300b26 ("bgpd: implement retain route-target all behaviour") in order to fix a memory consumption issue in the next commit. Fixes: a486300b26 ("bgpd: implement retain route-target all behaviour") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2023-06-16bgpd: add 'show bgp mplsvpn-nh-label-bind' commandLouis Scalbert
There is no 'show command' to use for troubleshooting purposes. Add a new show command to dump the cache entry of the MPLS VPN nexthop label bind cache table. > show bgp [vrf NAME] mplsvpn-nh-label-bind [detail] The below command illustrates its output: > dut# show bgp mplsvpn-nh-label-bind detail > Current BGP mpls-vpn nexthop label bind cache, VRF default > 192.168.1.3, label 102, local label 18 #paths 3 > interface r2-eth1 > Last update: Mon May 22 14:39:42 2023 > Paths: > 1/3 172.31.3.0/24 VRF default flags 0x418 > 1/3 172.31.2.0/24 VRF default flags 0x418 > 1/3 172.31.1.0/24 VRF default flags 0x418 > 192.0.2.1, label 101, local label 19 #paths 1 > interface r2-eth0 > Last update: Mon May 22 14:39:43 2023 > Paths: > 1/3 172.31.0.0/24 VRF default flags 0x418 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-06-16bgpd: update the mpls entry to handle return trafficPhilippe Guibert
When advertising an mpls vpn entry with a new label, the return traffic is redirected to the local machine, but the MPLS traffic is dropped. Add an MPLS entry to handle MPLS packets which have the new label value. Traffic is swapped to the original label value from the mpls vpn next-hop entry; then it is sent to the resolved next-hop of the original next-hop from the mpls vpn next-hop entry. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-06-16bgpd: advertise mpls vpn routes with appropriate labelPhilippe Guibert
The advertised label value from mpls vpn routes is not modified when the advertised next-hop is modified to next-hop-self. Actually, the original label value received is redistributed as is, whereas the new_label value bound in the nexthop label bind entry should be used. Only the VPN entries that contain MPLS information, and that are redistributed between distinct peers, will have a label value to advertise. - no SRv6 attribute - no local prefix - no exported VPN prefixes from a VRF If the advertisement to a given peer has the next-hop modified, then the new label value will be picked up. The considered cases are peers configured with 'next-hop-self' option, or ebgp peerings without the 'next-hop-unchanged' option. Note that the the NLRI format will follow the rfc3107 format, as multiple label values for MPLS VPN NLRIs are not supported (the rfc8277 is not supported). Note also that the case where an outgoing route-map is applied to the outgoing neighbor is not considered in this commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-06-16bgpd: allocate label bound to received mpls vpn routesPhilippe Guibert
Current implementation does not offer a new label to bind to a received VPN route entry to redistribute with that new label. This commit allocates a label for VPN entries that have a valid label, and a reachable next-hop interface that is configured as follows: > interface eth0 > mpls bgp l3vpn-multi-domain-switching > exit An mplsvpn next-hop label binding entry is created in an mpls vpn nexthop label bind hash table of the current BGP instance. That mpls vpn next-hop label entry is indexed by the (next-hop, orig_label) values provided by the incoming updates, and shared with other updates having the same (next-hop, orig_label) values. A new 'LP_TYPE_BGP_L3VPN_BIND' label value is picked up from the zebra mpls label pool, and assigned to the new_label attribute. The 'bgp_path_info' appends a 'bgp_mplsvpn_nh_label_bind' structure to the 'mplsvpn' union structure. Both structures in the union are not used at the same, as the paths are either VRF updates to export, or MPLS VPN updates. Using an union gives a 24 bytes memory gain compared to if the structures had not been in an union (24 bytes compared to 48 bytes). Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>