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>
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>
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>
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>
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>
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>
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>
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: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
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>
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>
`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>
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>
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: 27f4deed0a ("bgpd: update the mpls entry to handle return traffic")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The bmnc pointer is never null. Do not keep the test
on the pointer.
Fixes: 1069425868 ("bgpd: allocate label bound to received mpls vpn routes")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
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>
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>
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>
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>
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>
The label per nexthop attributes take 24 bytes per bgp path
entry on AMD64 platform, and are only used for unicast paths.
The current patch-set introduces a similar attributes, but that
will be used only for l3vpn paths. To gain some memory on the
bgp_path_info structure in the next commit, do some changes.
Create an 'mplsvpn' union structure that will either include the
label per nexthop structs for ipv4 paths, or the l3vpn paths
structures. The 'label_nexthop_cache' and the 'label_nh_thread'
attributes of the 'bgp_path_info' structure are moved into an
union under a new structure called 'bgp_mplsvpn_label_nh_blnc'.
The flags attribute of 'bgp_path_info' is increased from 16 bits
to 32 bits, and the BGP_PATH_MPLSVPN_LABEL_NH flag is added to
know the 'mplsvpn' usage.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In the context of the ASBR facing an EBGP neighbor, or
facing an IBGP neighbor where the BGP updates received
are re-advertised with a modified next-hop, a new local
label will be re-advertised too, to replace the original
one.
Create a binding table, in the form of a hash list, from the
original labels to the new labels. Since labels can be the
same on several routers, set the next-hop and the label as
the keys. Add the needed API functions to manage the hash
list.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The label allocation per next-hop functionality is calling
the 'bgp_find_or_add_nexthop()' method using the SAFI_MPLS_VPN
safi parameter, whereas the call is supposed to apply to
unicast paths.
Fix this by using the SAFI_UNICAST safi parameter in the call.
Simplify the vpn_leak_from_vrf_get_per_nexthop_label() API by
removing the safi parameter from the function.
Fixes: 577be36a41 ("bgpd: add support for l3vpn per-nexthop label")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Create a bgp_labels_same() function that does the
same operations as the static function labels_same from
bgp_mplsvpn.c.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
It is impossible for the blnc statement to ever be NULL at
line 1470 as that the if statement at 1453 guarantees it
to be set to something.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A timer attribute is added for each label nexthop entry, in order
to know when the last change occured.
The timer value will be used for troubleshooting by a show
command in the next commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The label allocation per nexthop mode requires to use a nexthop
tracking context. For redistributed routes, a nexthop tracking
context is created, and the resolution helps to know the real
nexthop ip address used. The below configuration example has
been used:
> vrf vrf1
> ip route 172.31.0.14/32 192.0.2.14
> ip route 172.31.0.15/32 192.0.2.12
> ip route 172.31.0.30/32 192.0.2.30
> exit
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> redistribute static
> label vpn export per-nexthop
> [..]
The static routes are correctly imported in the BGP IPv4 RIB.
Contrary to label allocation per vrf mode, some nexthop tracking
are created/or reused:
> # show bgp vrf vrf1 nexthop
> 192.0.2.12 valid [IGP metric 0], #paths 3, peer 192.0.2.12
> if r1-eth1
> Last update: Fri Jan 13 15:49:42 2023
> 192.0.2.14 valid [IGP metric 0], #paths 1
> if r1-eth1
> Last update: Fri Jan 13 15:49:42 2023
> 192.0.2.30 valid [IGP metric 0], #paths 1
> if r1-eth1
> Last update: Fri Jan 13 15:49:51 2023
> [..]
This results in having a BGP VPN route for each of the static
routes:
> # show bgp ipv4 vpn
> [..]
> Route Distinguisher: 444:1
> *> 172.31.0.14/32 192.0.2.14@9< 0 32768 ?
> *> 172.31.0.15/32 192.0.2.12@9< 0 32768 ?
> *> 172.31.0.30/32 192.0.2.30@9< 0 32768 ?
> [..]
Without that patch, only the redistributed routes that rely on a
pre-existing nexthop tracking context could be exported.
Also, a command in the code about redistributed routes is modified
accordingly, to explain that redistribute routes may be submitted
to nexthop tracking in the case label allocation per next-hop is
used.
note:
VNC routes have been removed from the redistribution,
because of a test failure in the bgp_l3vpn_to_bgp_direct test.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP MPLSVPN next hop label allocation was using only the next-hop
IP address. As MPLSVPN contexts rely on bnc contexts, the real
nexthop interface is known, and the LSP entry to enter can apply
to the specific interface. To illustrate, the BGP service is able
to handle the following two iproute2 commands:
> ip -f mpls route add 105 via inet 192.0.2.45 dev r1-eth1
> ip -f mpls route add 105 via inet 192.0.2.46 dev r1-eth2
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit introduces a new method to associate a label to
prefixes to export to a VPNv4 backbone. All the methods to
associate a label to a BGP update is documented in rfc4364,
chapter 4.3.2. Initially, the "single label for an entire
VRF" method was available. This commit adds "single label
for each attachment circuit" method.
The change impacts the control-plane, because each BGP update
is checked to know if the nexthop has reachability in the VRF
or not. If this is the case, then a unique label for a given
destination IP in the VRF will be picked up. This label will
be reused for an other BGP update that will have the same
nexthop IP address.
The change impacts the data-plane, because the MPLs pop
mechanism applied to incoming labelled packets changes: the
MPLS label is popped, and the packet is directly sent to the
connected nexthop described in the previous outgoing BGP VPN
update.
By default per-vrf mode is done, but the user may choose
the per-nexthop mode, by using the vty command from the
previous commit. In the latter case, a per-vrf label
will however be allocated to handle networks that are not directly
connected. This is the case for local traffic for instance.
The change also include the following:
- ECMP case
In case a route is learnt in a given VRF, and is resolved via an
ECMP nexthop. This implies that when exporting the route as a BGP
update, if label allocation per nexthop is used, then two possible
MPLS values could be picked up, which is not possible with the
current implementation. Actually, the NLRI for VPNv4 stores one
prefix, and one single label value, not two. Today, RFC8277 with
multiple label capability is not yet available.
To avoid this corner case, when a route is resolved via more than one
nexthop, the label allocation per nexthop will not apply, and the
default per-vrf label will be chosen.
Let us imagine BGP redistributes a static route using the `172.31.0.20`
nexthop. The nexthop resolution will find two different nexthops fo a
unique BGP update.
> r1# show running-config
> [..]
> vrf vrf1
> ip route 172.31.0.30/32 172.31.0.20
> r1# show bgp vrf vrf1 nexthop
> [..]
> 172.31.0.20 valid [IGP metric 0], #paths 1
> gate 192.0.2.11
> gate 192.0.2.12
> Last update: Mon Jan 16 09:27:09 2023
> Paths:
> 1/1 172.31.0.30/32 VRF vrf1 flags 0x20018
To avoid this situation, BGP updates that resolve over multiple
nexthops are using the unique per-vrf label.
- recursive route case
Prefixes that need a recursive route to be resolved can
also be eligible for mpls allocation per nexthop. In that
case, the nexthop will be the recursive nexthop calculated.
To achieve this, all nexthop types in bnc contexts are valid,
except for the blackhole nexthops.
- network declared prefixes
Nexthop tracking is used to look for the reachability of the
prefixes. When the the 'no bgp network import-check' command
is used, network declared prefixes are maintained active,
even if there is no active nexthop.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A timer attribute is added for each label nexthop entry, in order
to know when the last change occured.
The timer value will be used for troubleshooting by a show
command in the next commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The label allocation per nexthop mode requires to use a nexthop
tracking context. For redistributed routes, a nexthop tracking
context is created, and the resolution helps to know the real
nexthop ip address used. The below configuration example has
been used:
> vrf vrf1
> ip route 172.31.0.14/32 192.0.2.14
> ip route 172.31.0.15/32 192.0.2.12
> ip route 172.31.0.30/32 192.0.2.30
> exit
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> redistribute static
> label vpn export per-nexthop
> [..]
The static routes are correctly imported in the BGP IPv4 RIB.
Contrary to label allocation per vrf mode, some nexthop tracking
are created/or reused:
> # show bgp vrf vrf1 nexthop
> 192.0.2.12 valid [IGP metric 0], #paths 3, peer 192.0.2.12
> if r1-eth1
> Last update: Fri Jan 13 15:49:42 2023
> 192.0.2.14 valid [IGP metric 0], #paths 1
> if r1-eth1
> Last update: Fri Jan 13 15:49:42 2023
> 192.0.2.30 valid [IGP metric 0], #paths 1
> if r1-eth1
> Last update: Fri Jan 13 15:49:51 2023
> [..]
This results in having a BGP VPN route for each of the static
routes:
> # show bgp ipv4 vpn
> [..]
> Route Distinguisher: 444:1
> *> 172.31.0.14/32 192.0.2.14@9< 0 32768 ?
> *> 172.31.0.15/32 192.0.2.12@9< 0 32768 ?
> *> 172.31.0.30/32 192.0.2.30@9< 0 32768 ?
> [..]
Without that patch, only the redistributed routes that rely on a
pre-existing nexthop tracking context could be exported.
Also, a command in the code about redistributed routes is modified
accordingly, to explain that redistribute routes may be submitted
to nexthop tracking in the case label allocation per next-hop is
used.
note:
VNC routes have been removed from the redistribution,
because of a test failure in the bgp_l3vpn_to_bgp_direct test.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP MPLSVPN next hop label allocation was using only the next-hop
IP address. As MPLSVPN contexts rely on bnc contexts, the real
nexthop interface is known, and the LSP entry to enter can apply
to the specific interface. To illustrate, the BGP service is able
to handle the following two iproute2 commands:
> ip -f mpls route add 105 via inet 192.0.2.45 dev r1-eth1
> ip -f mpls route add 105 via inet 192.0.2.46 dev r1-eth2
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit introduces a new method to associate a label to
prefixes to export to a VPNv4 backbone. All the methods to
associate a label to a BGP update is documented in rfc4364,
chapter 4.3.2. Initially, the "single label for an entire
VRF" method was available. This commit adds "single label
for each attachment circuit" method.
The change impacts the control-plane, because each BGP update
is checked to know if the nexthop has reachability in the VRF
or not. If this is the case, then a unique label for a given
destination IP in the VRF will be picked up. This label will
be reused for an other BGP update that will have the same
nexthop IP address.
The change impacts the data-plane, because the MPLs pop
mechanism applied to incoming labelled packets changes: the
MPLS label is popped, and the packet is directly sent to the
connected nexthop described in the previous outgoing BGP VPN
update.
By default per-vrf mode is done, but the user may choose
the per-nexthop mode, by using the vty command from the
previous commit. In the latter case, a per-vrf label
will however be allocated to handle networks that are not directly
connected. This is the case for local traffic for instance.
The change also include the following:
- ECMP case
In case a route is learnt in a given VRF, and is resolved via an
ECMP nexthop. This implies that when exporting the route as a BGP
update, if label allocation per nexthop is used, then two possible
MPLS values could be picked up, which is not possible with the
current implementation. Actually, the NLRI for VPNv4 stores one
prefix, and one single label value, not two. Today, RFC8277 with
multiple label capability is not yet available.
To avoid this corner case, when a route is resolved via more than one
nexthop, the label allocation per nexthop will not apply, and the
default per-vrf label will be chosen.
Let us imagine BGP redistributes a static route using the `172.31.0.20`
nexthop. The nexthop resolution will find two different nexthops fo a
unique BGP update.
> r1# show running-config
> [..]
> vrf vrf1
> ip route 172.31.0.30/32 172.31.0.20
> r1# show bgp vrf vrf1 nexthop
> [..]
> 172.31.0.20 valid [IGP metric 0], #paths 1
> gate 192.0.2.11
> gate 192.0.2.12
> Last update: Mon Jan 16 09:27:09 2023
> Paths:
> 1/1 172.31.0.30/32 VRF vrf1 flags 0x20018
To avoid this situation, BGP updates that resolve over multiple
nexthops are using the unique per-vrf label.
- recursive route case
Prefixes that need a recursive route to be resolved can
also be eligible for mpls allocation per nexthop. In that
case, the nexthop will be the recursive nexthop calculated.
To achieve this, all nexthop types in bnc contexts are valid,
except for the blackhole nexthops.
- network declared prefixes
Nexthop tracking is used to look for the reachability of the
prefixes. When the the 'no bgp network import-check' command
is used, network declared prefixes are maintained active,
even if there is no active nexthop.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
