In some cases BGP can be monitoring the same prefix
in both the nexthop and import check tables. If this
is the case, when unregistering one bnc from one table
make sure we are not still registered in the other
Example of the problem:
r1(config-router)# address-family ipv4 uni
r1(config-router-af)# no network 192.168.100.41/32
r1(config-router-af)# exit
r1# show bgp import-check-table
Current BGP import check cache:
r1# show bgp nexthop
Current BGP nexthop cache:
192.168.100.41 valid [IGP metric 0], #paths 1, peer 192.168.100.41
if r1-eth0
Last update: Wed Dec 6 11:01:40 2023
BGP now believes it is only watching 192.168.100.41 in the nexthop
cache, but zebra doesn't have anything:
r1# show ip import-check
VRF default:
Resolve via default: on
r1# show ip nht
VRF default:
Resolve via default: on
So if anything happens to the route that is being matched for
192.168.100.41 bgp is no longer going to be notified about this.
The source of this problem is that zebra has dropped the two different
tables into 1 table, while bgp has 2 tables to track this. The solution
to this problem (other than the rewrite that is being done ) is to have
BGP have a bit of smarts about looking in both tables for the bnc and
if found in both don't send the delete of the prefix tracking to zebra.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is no support for dumping multiple paths for the same prefix.
The current implementation only takes the first available entry.
Fix this by walking over the list of available paths, ordered by peer.
The nlri index is set gradually for each path.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
This is already handled above, no need to do here, because we could have an
overrun situation where len > 64 and we do out-of-bound actions.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
Release memory associated with `bgp->confed_peers` in the `bgp_free`
function to ensure proper cleanup. This fix prevents memory leaks related
to `confed_peers`.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_confederation_astype.test_bgp_confederation_astype/r2.asan.bgpd.15045
=================================================================
==15045==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f5666787b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f56661867c7 in qrealloc lib/memory.c:112
#2 0x55a3b4736a40 in bgp_confederation_peers_add bgpd/bgpd.c:681
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0x7f5666720538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
#1 0x7f5666186898 in qstrdup lib/memory.c:117
#2 0x55a3b4736adb in bgp_confederation_peers_add bgpd/bgpd.c:687
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Avoids calling VRF/interface/... handlers in library code more than
once. It's kinda surprising that this hasn't been blowing up already
for the VNC code, luckily these handlers are (mostly?) idempotent.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... and use it instead of fiddling with the `.synchronous` field.
(Make it const while at it.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace `struct list *` with `DLIST(if_connected, ...)`.
NB: while converting this, I found multiple places using connected
prefixes assuming they were IPv4 without checking:
- vrrpd/vrrp.c: vrrp_socket()
- zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(),
irdp_advert_off()
(these fixes are really hard to split off into separate commits as that
would require going back and reapplying the change but with the old list
handling)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When bgp is shutting down, it calls bgp_fsm_change_status
on everything including a self peer, which goes through
and cleans the tables of the self peer data structures
as if it's a real peer. Add a bit of code to just
not do the work at all. This allows unlocks to flow
a bit further and for the self peer to be deleted
on shutdown.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The MTYPE_BGP memory type was being over used as
both the handler for the bgp instance itself as
well as memory associated with name strings.
Let's separate out the two.
Signed-off-by: Donald Sharp <sharpd@nvidia.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 following route-map set rules events are destroyed with
the 'match_destroy' API whereas there is a 'set_destroy' API
available.
Fix this for the following set commands:
> set distance
> set extcommunity rt
> set extcommunity nt
> set extcommunity color
> set extcommunity soo
Fixes: 48cb7ea99d ("bgpd: North-bound implementation for bgp rmaps")
Fixes: c9a2561444 ("bgpd: Implement Node Target Extended Communities")
Fixes: b80ebc2d8c ("bgpd: add colored extended communities support")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
INTERFACE_NAMSIZ is just a redefine of IFNAMSIZ and IFNAMSIZ
is the standard for interface name length on all platforms
that FRR currently compiles on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
To avoid USE:
```
==587645==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000074050 at pc 0x55b34337d96c bp 0x7ffda59bb4c0 sp 0x7ffda59bb4b0
READ of size 8 at 0x604000074050 thread T0
0 0x55b34337d96b in bgp_attr_flush bgpd/bgp_attr.c:1289
1 0x55b34368ef85 in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:111
2 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
3 0x7f7d41cdf81c in event_call lib/event.c:1980
4 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
5 0x55b343371e22 in main bgpd/bgp_main.c:510
6 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
7 0x55b3433769fd in _start (/usr/lib/frr/bgpd+0x2e29fd)
0x604000074050 is located 0 bytes inside of 40-byte region [0x604000074050,0x604000074078)
freed by thread T0 here:
#0 0x7f7d4207540f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122
1 0x55b343396afd in community_free bgpd/bgp_community.c:41
2 0x55b343396afd in community_free bgpd/bgp_community.c:28
3 0x55b343397373 in community_intern bgpd/bgp_community.c:458
4 0x55b34337bed4 in bgp_attr_intern bgpd/bgp_attr.c:967
5 0x55b34368165b in bgp_advertise_attr_intern bgpd/bgp_advertise.c:106
6 0x55b3435277d7 in bgp_adj_out_set_subgroup bgpd/bgp_updgrp_adv.c:587
7 0x55b34368f36b in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:125
8 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
9 0x7f7d41cdf81c in event_call lib/event.c:1980
10 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
11 0x55b343371e22 in main bgpd/bgp_main.c:510
12 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7f7d42075a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
1 0x7f7d41c3c28e in qcalloc lib/memory.c:105
2 0x55b3433976e8 in community_dup bgpd/bgp_community.c:514
3 0x55b34350273a in route_set_community bgpd/bgp_routemap.c:2589
4 0x7f7d41c96c06 in route_map_apply_ext lib/routemap.c:2690
5 0x55b34368f2d8 in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:107
6 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
7 0x7f7d41cdf81c in event_call lib/event.c:1980
8 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
9 0x55b343371e22 in main bgpd/bgp_main.c:510
10 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
```
And also a crash:
```
(gdb) bt
0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
1 0x00007ff3b7048ce0 in core_handler (signo=6, siginfo=0x7ffc8cf724b0, context=<optimized out>)
at lib/sigevent.c:246
2 <signal handler called>
3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
4 0x00007ff3b6bb8859 in __GI_abort () at abort.c:79
5 0x00007ff3b6c2326e in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7ff3b6d4d298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
6 0x00007ff3b6c2b2fc in malloc_printerr (
str=str@entry=0x7ff3b6d4f628 "double free or corruption (fasttop)") at malloc.c:5347
7 0x00007ff3b6c2cc65 in _int_free (av=0x7ff3b6d82b80 <main_arena>, p=0x555c8fa70a10, have_lock=0)
at malloc.c:4266
8 0x0000555c8da94bd3 in community_free (com=0x7ffc8cf72e70) at bgpd/bgp_community.c:41
9 community_free (com=com@entry=0x7ffc8cf72e70) at bgpd/bgp_community.c:28
10 0x0000555c8da8afc1 in bgp_attr_flush (attr=attr@entry=0x7ffc8cf73040) at bgpd/bgp_attr.c:1290
11 0x0000555c8dbc0760 in bgp_conditional_adv_routes (peer=peer@entry=0x555c8fa627c0,
afi=afi@entry=AFI_IP, safi=SAFI_UNICAST, table=table@entry=0x555c8fa510b0, rmap=0x555c8fa71cb0,
update_type=UPDATE_TYPE_ADVERTISE) at bgpd/bgp_conditional_adv.c:111
12 0x0000555c8dbc0b75 in bgp_conditional_adv_timer (t=<optimized out>)
at bgpd/bgp_conditional_adv.c:301
13 0x00007ff3b705b84c in event_call (thread=thread@entry=0x7ffc8cf73440) at lib/event.c:1980
14 0x00007ff3b700bf98 in frr_run (master=0x555c8f27c090) at lib/libfrr.c:1214
15 0x0000555c8da85f05 in main (argc=<optimized out>, argv=0x7ffc8cf736a8) at bgpd/bgp_main.c:510
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The function aspath_remove_private_asns was using an aspath to perform some operation and didnt free it after usage leading to the leak below.
***********************************************************************************
Address Sanitizer Error detected in bgp_remove_private_as_route_map.test_bgp_remove_private_as_route_map/r2.asan.bgpd.27074
=================================================================
==27074==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b44cc in aspath_dup bgpd/bgp_aspath.c:689
#3 0x562b62f48498 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
#4 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#5 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#6 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#7 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#8 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#9 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#10 0x7fd0a463322a in event_call lib/event.c:1970
#11 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#12 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#13 0x7fd0a35b8c86 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 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b44cc in aspath_dup bgpd/bgp_aspath.c:689
#3 0x562b62f48498 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
#4 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#5 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#6 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#7 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#8 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#9 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#10 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#11 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#12 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#13 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#14 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#15 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#16 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#17 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#18 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#19 0x7fd0a463322a in event_call lib/event.c:1970
#20 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#21 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#22 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b313f in aspath_make_str_count bgpd/bgp_aspath.c:551
#3 0x562b630b3ecf in aspath_str_update bgpd/bgp_aspath.c:659
#4 0x562b630b88b7 in aspath_prepend bgpd/bgp_aspath.c:1484
#5 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#6 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#7 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#8 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#9 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#11 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#12 0x7fd0a463322a in event_call lib/event.c:1970
#13 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#14 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#15 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b313f in aspath_make_str_count bgpd/bgp_aspath.c:551
#3 0x562b630b3ecf in aspath_str_update bgpd/bgp_aspath.c:659
#4 0x562b630b88b7 in aspath_prepend bgpd/bgp_aspath.c:1484
#5 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#6 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#7 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#8 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#9 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#11 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#12 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#13 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#14 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#15 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#16 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#17 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#18 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#19 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#20 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#21 0x7fd0a463322a in event_call lib/event.c:1970
#22 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#23 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#24 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b280d in assegment_new bgpd/bgp_aspath.c:105
#3 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#4 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#5 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#6 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#7 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#8 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#9 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#12 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#13 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#14 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#15 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#16 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#17 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#18 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#19 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#20 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#21 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#22 0x7fd0a463322a in event_call lib/event.c:1970
#23 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#24 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#25 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b280d in assegment_new bgpd/bgp_aspath.c:105
#3 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#4 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#5 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#6 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#7 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#8 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#9 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#12 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#13 0x7fd0a463322a in event_call lib/event.c:1970
#14 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#15 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#16 0x7fd0a35b8c86 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 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b2879 in assegment_data_new bgpd/bgp_aspath.c:83
#3 0x562b630b2879 in assegment_new bgpd/bgp_aspath.c:108
#4 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#5 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#6 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#7 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#8 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#9 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#13 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#14 0x7fd0a463322a in event_call lib/event.c:1970
#15 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#16 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#17 0x7fd0a35b8c86 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 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b2879 in assegment_data_new bgpd/bgp_aspath.c:83
#3 0x562b630b2879 in assegment_new bgpd/bgp_aspath.c:108
#4 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#5 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#6 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#7 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#8 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#9 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#13 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#14 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#15 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#16 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#17 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#18 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#19 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#20 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#21 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#22 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#23 0x7fd0a463322a in event_call lib/event.c:1970
#24 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#25 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#26 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 416 byte(s) leaked in 16 allocation(s).
***********************************************************************************
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
CID 1570969 Overrun
/bgpd/bgp_snmp_bgp4v2.c: 534 in bgp4v2PathAttrLookup()
/bgpd/bgp_snmp_bgp4v2.c: 575 in bgp4v2PathAttrLookup()
/bgpd/bgp_snmp_bgp4v2.c: 514 in bgp4v2PathAttrLookup()
>>> CID 1570969: (OVERRUN)
>>> Overrunning array "bgp->rib" of 4 64-byte elements at element index 4 (byte offset 319) using index "afi" (which evaluates to 4).
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Let's use the natural data structure in bgp for the prefix display
instead of a bunch of places where we call a translator function.
The %pBD does this and actually ensures data is correct.
Also fix a few spots in bgp_zebra.c where the cast to a NULL
pointer causes the catcher functionality to not work and fix
the resulting crash that resulted.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I recieve the following error with GCC 9.4.0:
```
In file included from /usr/include/string.h:495,
from ./lib/zebra.h:23,
from bgpd/bgp_snmp_bgp4v2.c:7:
In function ‘memset’,
inlined from ‘bgp4v2PathAttrLookup’ at bgpd/bgp_snmp_bgp4v2.c:605:3,
inlined from ‘bgp4v2PathAttrTable’ at bgpd/bgp_snmp_bgp4v2.c:747:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10: error: ‘__builtin_memset’ offset [9, 20] from the object at ‘paddr’ is out of the bounds of referenced subobject ‘_v4_addr’ with type ‘struct in_addr’ at offset 4 [-Werror=array-bounds]
71 | return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Add guard for `zlog_debug` when bgpd is not connected to zebra
or zebra does not know the bgp instance.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
With a BGP configuration with ipv4 peering, and ipv6 peering, an snmpwalk
is stopped while walking over the bgp4v2NlriTable
snmpwalk -c TEST -v2c -On -Ln 1.1.1.2 .1.3.6.1.3.5.1.1.4
[...]
.1.3.6.1.3.5.1.1.4.1.2.1.2.32.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 = Gauge32: 13380
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0 = Gauge32: 0
>= .1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0
The walk stopped because the index used in the NlriTable entries is
decrementing, and this is against the snmp specifications. Also, the
computed index is wrong, and does not match the provided
draft-ietf-idr-bgp4-mibv2-1 specification.
Fix this by computing a valid index, and by finding out the next
consecutive prefix.
The resulting changes do not break the walk, and the output is changed:
root@dut-vm:~# snmpwalk -v 2c -c public -Ln -On localhost 1.3.6.1.3.5.1.1.9.1
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = Hex-STRING: 0A C8 00 00
.1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = Hex-STRING: 0A F4 00 00
Fixes: c681e937d7 (bgpd: Implement SNMP
BGP4V2-MIB (bgp4V2NlriTable), part 1)
Fixes: 2ce69011c4 (bgpd: Implement SNMP
BGP4V2-MIB (bgp4V2NlriTable), part 2)
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
We send this capability for iBGP peers by default. Recently OAD support was
merged, and we should adopt sending the capability according to OAD as well.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
We shouldn't set it blindly once the packet is received, but first we have to
do some sanity checks.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The headers associated with netlink code
really only belong in those that need it.
Move these headers out of lib/zebra.h and
into more appropriate places. bgp's usage
of the RT_TABLE_XXX defines are probably not
appropriate and will be cleaned up in future
commits.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
use CHECK_FLAG
fix comment spaces
change zlog_debug to zlog_warn
safeguard on updated_route
added doc/developer/bmp.rst to subdir.am
other qol changes
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
changed result type of bmp_get_peer_distinguisher to int
added result pointer parameter to bmp_get_peer_distinguisher
bmp_get_peer_distinguisher returns 0 means the result is valid else
error occured do not use result
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
moved loc-rib uptime field "bgp_rib_uptime" to struct bgp_path_info_extra for memory concerns
moved logic into bgp_route_update's callback bmp_route_update
written timestamp in per peer header
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
bgp_afi_node_lookup calls bgp_node_lookup which locks the node, unlocking it safely after function is finished
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
TODOs that are done/un-necessary now deleted
refactored bmp_route_update to use a modified bmp_process_one function call instead of duplicating similar code
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
cleaner implementation and use of the new get peer distinguisher function
can be now used for other cases of RFC7854 that are not supported atm
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
added time_t field to bgp_path_info
set value before bgp dp hook is called
value not set in the msg yet, testing and double checking is needed before
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set timestamp to 0 for loc rib monitoring messages as path selection time is not available atm
this is temporary and tv is meant to be set to the path selection/install time at some point
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
vrf_id_to_name is used for display values only and returns "Unknown" when the vrf is not found
doing a manual lookup and not providing any tlv when the vrf is not found should be better
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set field peer bgp id to the peer's remote id in every case except loc-rib (RFC9069 case) in which we put the bgp instance's router-id if available or 0-filled if not available
set field peer asn to local primary bgp asn in case of loc-rib instance (RFC9069) else it's set to the peer's asn
set field peer address to 0 in loc-rib instance (RFC9069 case) and to the peer's address in other cases
had to pass struct bgp reference to bmp_per_peer_hdr to access router-id and such, but it's always safely accessed when used
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
added afi/safi monitoring synchronisation for loc-rib
added peer_type_flag to bmp_eor signature, only set to BMP_PEER_TYPE_LOC_RIB and to 0 in other cases like it was before
updated tracelog to include peer_type_flag value
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set peer distinguisher to vrf id temporarily until i find out how to use the rd set for export on the vrf instance associated to this bgp instance
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
set peer type flag to 3 for loc rib monitoring
leave to 0 in other cases like before, even though RFC7854 tells us to set it to 0 1 or 2 depending on the case global/rd/local instance
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
...so that multiple functions can be subscribed.
The create/destroy hooks are renamed to real/unreal because that's what
they *actually* signal.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
If we receive MP_UNREACH_NLRI, we should stop handling remaining NLRIs if
no mandatory path attributes received.
In other words, if MP_UNREACH_NLRI received, the remaining NLRIs should be handled
as a new data, but without mandatory attributes, it's a malformed packet.
In normal case, this MUST not happen at all, but to avoid crashing bgpd, we MUST
handle that.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Treat-as-withdraw, otherwise if we just ignore it, we will pass it to be
processed as a normal UPDATE without mandatory attributes, that could lead
to harmful behavior. In this case, a crash for route-maps with the configuration
such as:
```
router bgp 65001
no bgp ebgp-requires-policy
neighbor 127.0.0.1 remote-as external
neighbor 127.0.0.1 passive
neighbor 127.0.0.1 ebgp-multihop
neighbor 127.0.0.1 disable-connected-check
neighbor 127.0.0.1 update-source 127.0.0.2
neighbor 127.0.0.1 timers 3 90
neighbor 127.0.0.1 timers connect 1
!
address-family ipv4 unicast
neighbor 127.0.0.1 addpath-tx-all-paths
neighbor 127.0.0.1 default-originate
neighbor 127.0.0.1 route-map RM_IN in
exit-address-family
exit
!
route-map RM_IN permit 10
set as-path prepend 200
exit
```
Send a malformed optional transitive attribute:
```
import socket
import time
OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")
KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")
UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff002b0200000003c0ff00010100eb00ac100b0b001ad908ac100b0b")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(100)
s.close()
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
It's been for a while disabled by default, but this seems reasonable to flip it.
We had `bgp enforce-first-as` as a global BGP knob to enable/disable this
behavior globally, later we introduced `enforce-first-as` per neighbor, with disabled
by default. Now let's enable this by default by bringing a global `bgp enforce-first-as`
command back.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In zebra, the import check table and the nexthop check tables
were combined. This leaves an issue where when bgp happens
to have a tracked address in both the import check table
and the nexthop track table that are the same address.
When the the item is removed from one table the call
to remove it from zebra removes tracking for the other
table.
Combine the two tables together and keep track where
they came from for processing in bgpd.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is no command to choose to send or not the bgp4-mibv2 traps.
Since the MIB bgp4-mibv2 notification are redundant with MIB RFC4273
we added a command:
- [no] bgp snmp traps bgp4-mibv2
By default, the bgp4-mibv2 traps will be disabled, to prevent from
redundancy.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
This commit add the support of traps for bgp4-mibv2.
It is conformant to draft-ietf-idr-bgp4-mibv2-11.
The following traps are supported:
- bgp4V2EstablishedNotification
- bgp4V2BackwardTransitionNotification
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
There is no cli command to prevent the router to send traps
implemented in the rfc4273. If not done, when introducing
the traps from bgp4v2mib, traps will be send for each of
the two mibs: there will be redundancy in the sent information.
Add a new command:
- [no] bgp snmp traps rfc4273
Using this command will allow or not the notification of
the following traps:
- bgpEstablishedNotification
- bgpBackwardTransNotification
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
If we send a crafted BGP UPDATE message without mandatory attributes, we do
not check if the length of the path attributes is zero or not. We only check
if attr->flag is at least set or not. Imagine we send only unknown transit
attribute, then attr->flag is always 0. Also, this is true only if graceful-restart
capability is received.
A crash:
```
bgpd[7834]: [TJ23Y-GY0RH] 127.0.0.1 Unknown attribute is received (type 31, length 16)
bgpd[7834]: [PCFFM-WMARW] 127.0.0.1(donatas-pc) rcvd UPDATE wlen 0 attrlen 20 alen 17
BGP[7834]: Received signal 11 at 1698089639 (si_addr 0x0, PC 0x55eefd375b4a); aborting...
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_backtrace_sigsafe+0x6d) [0x7f3205ca939d]
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_signal+0xf3) [0x7f3205ca9593]
BGP[7834]: /usr/local/lib/libfrr.so.0(+0xf5181) [0x7f3205cdd181]
BGP[7834]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980) [0x7f3204ff3980]
BGP[7834]: /usr/lib/frr/bgpd(+0x18ab4a) [0x55eefd375b4a]
BGP[7834]: /usr/local/lib/libfrr.so.0(route_map_apply_ext+0x310) [0x7f3205cd1290]
BGP[7834]: /usr/lib/frr/bgpd(+0x163610) [0x55eefd34e610]
BGP[7834]: /usr/lib/frr/bgpd(bgp_update+0x9a5) [0x55eefd35c1d5]
BGP[7834]: /usr/lib/frr/bgpd(bgp_nlri_parse_ip+0xb7) [0x55eefd35e867]
BGP[7834]: /usr/lib/frr/bgpd(+0x1555e6) [0x55eefd3405e6]
BGP[7834]: /usr/lib/frr/bgpd(bgp_process_packet+0x747) [0x55eefd345597]
BGP[7834]: /usr/local/lib/libfrr.so.0(event_call+0x83) [0x7f3205cef4a3]
BGP[7834]: /usr/local/lib/libfrr.so.0(frr_run+0xc0) [0x7f3205ca10a0]
BGP[7834]: /usr/lib/frr/bgpd(main+0x409) [0x55eefd2dc979]
```
Sending:
```
import socket
import time
OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")
KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")
UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff003c0200000014ff1f001000040146464646460004464646464646664646f50d05800100010200ffff000000")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(1000)
s.close()
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add the 'redistribute table-direct' command under the bgp address-family
node. Handle the table-direct support wherever needed in the BGP code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If we have a prefix-list with one entry, and after some time we append a prefix-list
with some more additional entries, conditional advertisement is triggered, and the
old entries are suppressed (because they look identical as sent before).
Hence, the old entries are sent as withdrawals and only new entries sent as updates.
Force re-sending all BGP updates for conditional advertisement. The same is done
for route-refresh, and/or soft clear operations.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
For instance, it's not possible to resend FQDN capability without resetting
the session, so let's create some more elegant way to do that.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add an ability to enable/disable ORF capability dynamically without tearing
down the session.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If BGP starts with a l3vpn configuration, the 'pending' value
of the 'show bgp labelpool summary' command is set to 128,
whereas the 'pending' value is 0 if the l3vpn configuration is
applied after.
with no config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger: 1
> InUse: 1
> Requests: 0
> LabelChunks: 1
> Pending: 0
> Reconnects: 1
with config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger: 1
> InUse: 1
> Requests: 0
> LabelChunks: 1
> Pending: 128
> Reconnects: 1
When BGP configuration is applied at startup, the label request fails,
because the zapi connection with zebra is not yet up. At zebra
up event, the label request is done again, succeeds, decrements the
'pending_count' value in 'bgp_lp_event_chunk() function, then sets
the 'pending_count' value to the 'labels_needed' value.
This method was correct when label requests were asyncronous: the
'pending_count' value was first set, then decremented. In syncronous
label requests, the operations are swapped.
Fix this by incrementing the expected 'labels_needed' value instead.
Fixes: 0043ebab99 ("bgpd: Use synchronous way to get labels from Zebra")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A label chunk is used by BGP for L3VPN or LU purposes,
by picking up labels from that chunk; but when those
labels are release, the label chunks are never released.
The below configuration sequence shows that the label
chunks are not released.
> router bgp 65500
> bgp router-id 1.1.1.1
> !
> address-family ipv4 unicast
> label vpn export auto
> rd vpn export 55:1
> rt vpn both 55:1
> export vpn
> import vpn
> [..]
> no label vpn export auto
> [..]
> # show bgp labelpool summary
> [..]
> LabelChunks: 1
> Pending: 128
> [..]
The '128' value stands for the default label chunk size,
which is not released after unconfiguration.
Fix this by checking after each label release, that
the label chunk is still used. If not, release it.
Reset the 'next_chunksize' value to the default value.
Fixes: 955bfd984f ("bgpd: dynamic mpls label pool")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP always asks zebra for a chunk of MPLS label even if it doesn't need it.
Fix this by correcting the rounding up "labels_needed" formula.
Fixes: 80853c2ec7 ("bgpd: improve labelpool performance at scale")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Today, when configuring BGP L3VPN mpls, the operator may
use that command to hardset a label value:
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> label vpn export <hardset_label_value>
Today, BGP uses this value without checks, leading to potential
conflicts with other control planes like LDP. For instance, if
LDP initiates with a label chunk of [16;72] and BGP also uses the
50 label value, a conflict arises.
The 'label manager' service in zebra oversees label allocations.
While all the control plane daemons use it, BGP doesn't when a
hardset label is in place.
This update fixes this problem. Now, when a hardset label is set for
l3vpn export, a request is made to the label manager for approval,
ensuring no conflicts with other daemons. But, this means some existing
BGP configurations might become non-operational if they conflict with
labels already allocated to another daemon but not used.
note: Labels below 16 are reserved and won't be checked for consistency
by the label manager.
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The original 'bgp label vpn export' code is confusing,
the 'no form' actions are mixed with the positive form.
Fix this by rewriting the code.
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>
Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Instead of scaling the bandwith to something between 1 and 100, just
send down the bandwidth Available for the link.
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
BGP is storing outgoing updates in a couple of different
fifo's. This is to ensure proper packet packing of
all bgp_dests that happen to use the same attribute.
How it's all put together currently: On initial update
BGP walks through all the bgp_dest's in a table. For each
path being sent a bgp_advertise is created. This bgp_advertise
is placed in fifo order on the bgp_synchronize->update queue.
The bgp_advertise has a pointer to the bgp_advertise_attr which
is associated iwth the actual attribute that is being sent to
it's peer. In turn this bgp_advertise is placed in a fifo off
of the bgp_advertise_attr structure. As such as we have paths
that share an attribute, the path/dest is placed on the
bgp_syncrhonize->update fifo as well as being placed on the fifo
associated with the advertised attribute.
On actual creation of a packet. The first item in the
bgp_synchronize->update fifo is popped. The bgp_advertise_attr
pointer is grabbed, we fill out the nlri part of the bgp packet
and then walk the bgp_advertise_attr fifo to place paths/dests in
the packet. As each path/dest is placed in the packet it is removed
from both the bgp_synchronize->update fifo and the bgp_advertise_attr
fifo.
The whole point of this change is to switch the *next, *prev
pointers in the bgp_advertise structure with a typesafe data
structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
At each EBGP boundary, BGP path attributes are modified as per [RFC4271], which includes stripping any IBGP-only attributes.
Some networks span more than one autonomous system and require more flexibility in the propagation of path attributes. It is worth noting that these multi-AS networks have a common or single administrative entity. These networks are said to belong to One Administrative Domain (OAD). It is desirable to carry IBGP-only attributes across EBGP peerings when the peers belong to an OAD.
This document defines a new EBGP peering type known as EBGP-OAD, which is used between two EBGP peers that belong to an OAD. This document also defines rules for route announcement and processing for EBGP-OAD peers.
https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Changing Addpath type, and or disabling RX (receiving) flag, we can do this
without tearing down the session, and using dynamic capabilities.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When we have RX/TX flags, but received only TX, we should clear RX flag, to avoid
receiving additional paths.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
