Donald Sharp [Fri, 30 Jun 2023 13:56:51 +0000 (09:56 -0400)]
lib: Add two places we were not counting route-map applied
There were a couple of places where it was possible a route-map
was applied( and DENIED ) but the count for the number of times
the application happen was not incremented.
ryndia [Fri, 30 Jun 2023 11:02:27 +0000 (15:02 +0400)]
ospf6d: unlock lsa
The function ospf6_router_lsa_contains_adj(), ospf6_gr_check_adjs() and ospf6_find_interf_prefix_lsa() iterate through LSDB and lock each LSA. During testing, it was discovered that the lock count did not reach zero upon termination. The stack trace below indicates the leak. To resolve this issue, it was found that unlocking the LSA before returning from the functions solves the problem. This suggests that there was a missing unlock that caused the lock count to remain nonzero.
Direct leak of 400 byte(s) in 2 object(s) allocated from:
#0 0x7fa744ccea37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fa744867562 in qcalloc ../lib/memory.c:105
#2 0x555cdbb37506 in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:710
#3 0x555cdbb375d6 in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x555cdbaf1008 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x555cdbb48ceb in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x555cdbb4ac90 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x555cdbb4aecc in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7fa744950c33 in event_call ../lib/event.c:1995
#9 0x7fa74483b34a in frr_run ../lib/libfrr.c:1213
#10 0x555cdbacf1eb in main ../ospf6d/ospf6_main.c:250
#11 0x7fa7443f9d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fa744cce867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fa744867525 in qmalloc ../lib/memory.c:100
#2 0x555cdbb37520 in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:711
#3 0x555cdbb375d6 in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x555cdbaf1008 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x555cdbb48ceb in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x555cdbb4ac90 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x555cdbb4aecc in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7fa744950c33 in event_call ../lib/event.c:1995
#9 0x7fa74483b34a in frr_run ../lib/libfrr.c:1213
#10 0x555cdbacf1eb in main ../ospf6d/ospf6_main.c:250
#11 0x7fa7443f9d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Direct leak of 2000 byte(s) in 10 object(s) allocated from:
#0 0x7f2c3faeea37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f2c3f68a6d9 in qcalloc ../lib/memory.c:105
#2 0x56431b83633d in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:710
#3 0x56431b83640d in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x56431b7efe13 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x56431b847b31 in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x56431b849ad6 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x56431b849d12 in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7f2c3f773c62 in event_call ../lib/event.c:1995
#9 0x7f2c3f65e2de in frr_run ../lib/libfrr.c:1213
#10 0x56431b7cdff6 in main ../ospf6d/ospf6_main.c:221
#11 0x7f2c3f21dd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 460 byte(s) in 10 object(s) allocated from:
#0 0x7f2c3faee867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f2c3f68a69c in qmalloc ../lib/memory.c:100
#2 0x56431b836357 in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:711
#3 0x56431b83640d in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x56431b7efe13 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x56431b847b31 in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x56431b849ad6 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x56431b849d12 in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7f2c3f773c62 in event_call ../lib/event.c:1995
#9 0x7f2c3f65e2de in frr_run ../lib/libfrr.c:1213
#10 0x56431b7cdff6 in main ../ospf6d/ospf6_main.c:221
#11 0x7f2c3f21dd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Donald Sharp [Sat, 1 Jul 2023 15:18:06 +0000 (11:18 -0400)]
ospf6d: Fix crash because neighbor structure was freed
The loading_done event needs a event pointer to prevent
use after free's. Testing found this:
ERROR: AddressSanitizer: heap-use-after-free on address 0x613000035130 at pc 0x55ad42d54e5f bp 0x7ffff1e942a0 sp 0x7ffff1e94290
READ of size 1 at 0x613000035130 thread T0
#0 0x55ad42d54e5e in loading_done ospf6d/ospf6_neighbor.c:447
#1 0x55ad42ed7be4 in event_call lib/event.c:1995
#2 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#3 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#4 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#5 0x55ad42cf2b19 in _start (/usr/lib/frr/ospf6d+0x248b19)
0x613000035130 is located 48 bytes inside of 384-byte region [0x613000035100,0x613000035280)
freed by thread T0 here:
#0 0x7f57998d77a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
#1 0x55ad42e3b4b6 in qfree lib/memory.c:130
#2 0x55ad42d5d049 in ospf6_neighbor_delete ospf6d/ospf6_neighbor.c:180
#3 0x55ad42d1e1ea in interface_down ospf6d/ospf6_interface.c:930
#4 0x55ad42ed7be4 in event_call lib/event.c:1995
#5 0x55ad42ed84fe in _event_execute lib/event.c:2086
#6 0x55ad42d26d7b in ospf6_interface_clear ospf6d/ospf6_interface.c:2847
#7 0x55ad42d73f16 in ospf6_process_reset ospf6d/ospf6_top.c:755
#8 0x55ad42d7e98c in clear_router_ospf6_magic ospf6d/ospf6_top.c:778
#9 0x55ad42d7e98c in clear_router_ospf6 ospf6d/ospf6_top_clippy.c:42
#10 0x55ad42dc2665 in cmd_execute_command_real lib/command.c:994
#11 0x55ad42dc2b32 in cmd_execute_command lib/command.c:1053
#12 0x55ad42dc2fa9 in cmd_execute lib/command.c:1221
#13 0x55ad42ee3cd6 in vty_command lib/vty.c:591
#14 0x55ad42ee4170 in vty_execute lib/vty.c:1354
#15 0x55ad42eec94f in vtysh_read lib/vty.c:2362
#16 0x55ad42ed7be4 in event_call lib/event.c:1995
#17 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#18 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#19 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
previously allocated by thread T0 here:
#0 0x7f57998d7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x55ad42e3ab22 in qcalloc lib/memory.c:105
#2 0x55ad42d5c8ff in ospf6_neighbor_create ospf6d/ospf6_neighbor.c:119
#3 0x55ad42d4c86a in ospf6_hello_recv ospf6d/ospf6_message.c:464
#4 0x55ad42d4c86a in ospf6_read_helper ospf6d/ospf6_message.c:1884
#5 0x55ad42d4c86a in ospf6_receive ospf6d/ospf6_message.c:1925
#6 0x55ad42ed7be4 in event_call lib/event.c:1995
#7 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#8 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#9 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Add an actual event pointer and just track it appropriately.
Donald Sharp [Fri, 30 Jun 2023 19:21:43 +0000 (15:21 -0400)]
ospf6d: Stop crash in ospf6_write
I'm seeing crashes in ospf6_write on the `assert(node)`. The only
sequence of events that I see that could possibly cause this to happen
is this:
a) Someone has scheduled a outgoing write to the ospf6->t_write and
placed item(s) on the ospf6->oi_write_q
b) A decision is made in ospf6_send_lsupdate() to send an immediate
packet via a event_execute(..., ospf6_write,....).
c) ospf6_write is called and the oi_write_q is cleaned out.
d) the t_write event is now popped and the oi_write_q is empty
and FRR asserts on the `assert(node)` <crash>
When event_execute is called for ospf6_write, just cancel the t_write
event. If ospf6_write has more data to send at the end of the function
it will reschedule itself. I've only seen this crash one time and am
unable to reliably reproduce this at all. But this is the only mechanism
that I can see that could make this happen, given how little the oi_write_q
is actually touched in code.
Chirag Shah [Thu, 29 Jun 2023 16:55:12 +0000 (09:55 -0700)]
tools: fix pim interface config deletion
When no ip pim is performed subsequent pim related
configs under the interface also implicitly deleted.
When doing this via frr-reload requires to remove any
explicit no ip pim <blah> lines so delete list.
Testing Done:
running-config:
interface lo
ip pim
ip pim use-source 6.0.0.1
exit
frr.conf:
remove two pim config lines.
interface lo
exit
Before fix:
2023-06-29 23:44:26,062 INFO: Failed to execute interface lo no ip pim use-source 6.0.0.1
2023-06-29 23:44:26,142 INFO: Failed to execute interface lo no ip pim use-source
2023-06-29 23:44:26,221 INFO: Executed "interface lo no ip pim"
After fix:
Only no ip pim executed and rest of the other lines removed from delete
list.
2023-06-30 01:07:32,618 INFO: Executed "interface lo no ip pim"
anlan_cs [Wed, 28 Jun 2023 04:31:52 +0000 (12:31 +0800)]
pbrd: fix crash with match command
Crash with empty `ip-protocol`:
```
anlan(config-pbr-map)# match ip-protocol
vtysh: error reading from pbrd: Resource temporarily unavailable (11)Warning: closing connection to pbrd because of an I/O error!
```
Donatas Abraitis [Tue, 27 Jun 2023 08:44:10 +0000 (11:44 +0300)]
zebra: Free Zebra client resources
Memory leaks started flowing:
```
AddressSanitizer Topotests Part 0: 15 KB -> 283 KB
AddressSanitizer Topotests Part 1: 1 KB -> 495 KB
AddressSanitizer Topotests Part 2: 13 KB -> 478 KB
AddressSanitizer Topotests Part 3: 39 KB -> 213 KB
AddressSanitizer Topotests Part 4: 30 KB -> 836 KB
AddressSanitizer Topotests Part 5: 0 bytes -> 356 KB
AddressSanitizer Topotests Part 6: 86 KB -> 783 KB
AddressSanitizer Topotests Part 7: 0 bytes -> 354 KB
AddressSanitizer Topotests Part 8: 0 bytes -> 62 KB
AddressSanitizer Topotests Part 9: 408 KB -> 518 KB
```
```
Direct leak of 3584 byte(s) in 1 object(s) allocated from:
#0 0x7f1957b02d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x559895c55df0 in qcalloc lib/memory.c:105
#2 0x559895bc1cdf in zserv_client_create zebra/zserv.c:743
#3 0x559895bc1cdf in zserv_accept zebra/zserv.c:880
#4 0x559895cf3438 in event_call lib/event.c:1995
#5 0x559895c3901c in frr_run lib/libfrr.c:1213
#6 0x559895a698f1 in main zebra/main.c:472
#7 0x7f195635ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
```
Fixes b20acd0 ("bgpd: Use synchronous way to get labels from Zebra")
Keelan10 [Mon, 26 Jun 2023 10:56:26 +0000 (14:56 +0400)]
pimd: Fix memory leak in PIM interface deletion
This commit ensures proper cleanup by deleting the gm_join_list when a PIM interface is deleted. The gm_join_list was previously not being freed, causing a memory leak.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in multicast_mld_join_topo1.test_multicast_mld_local_join/r1.asan.pim6d.28070
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230372180f in list_new lib/linklist.c:49
#3 0x56230361b589 in pim_if_gm_join_add pimd/pim_iface.c:1313
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288
#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 96 byte(s) in 4 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x562303721651 in listnode_new lib/linklist.c:71
#3 0x56230372182b in listnode_add lib/linklist.c:92
#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295
#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326
#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#7 0x562303767280 in nb_callback_create lib/northbound.c:1235
#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#15 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#16 0x5623036c6392 in cmd_execute lib/command.c:1221
#17 0x5623037e75da in vty_command lib/vty.c:591
#18 0x5623037e7a74 in vty_execute lib/vty.c:1354
#19 0x5623037f0253 in vtysh_read lib/vty.c:2362
#20 0x5623037db4e8 in event_call lib/event.c:1995
#21 0x562303720f97 in frr_run lib/libfrr.c:1213
#22 0x56230368615d in main pimd/pim6_main.c:184
#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288
#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f6f in cmd_execute_command lib/command.c:1072
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x562303721651 in listnode_new lib/linklist.c:71
#3 0x56230372182b in listnode_add lib/linklist.c:92
#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295
#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326
#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#7 0x562303767280 in nb_callback_create lib/northbound.c:1235
#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#15 0x5623036c5f6f in cmd_execute_command lib/command.c:1072
#16 0x5623036c6392 in cmd_execute lib/command.c:1221
#17 0x5623037e75da in vty_command lib/vty.c:591
#18 0x5623037e7a74 in vty_execute lib/vty.c:1354
#19 0x5623037f0253 in vtysh_read lib/vty.c:2362
#20 0x5623037db4e8 in event_call lib/event.c:1995
#21 0x562303720f97 in frr_run lib/libfrr.c:1213
#22 0x56230368615d in main pimd/pim6_main.c:184
#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 400 byte(s) leaked in 11 allocation(s).
***********************************************************************************
```
Chirag Shah [Mon, 26 Jun 2023 22:29:59 +0000 (15:29 -0700)]
zebra: fix evpn rmac nh list cmp function
EVPN RMAC (Router MAC) nexthop list compare
function needs to return all values so
the list element can be compared and added/deleted
properly.
Ticket:#3486989
Testing Done:
Originate EVPN Type-5 route with PIP IP and MAC as remote
nexthops.
Change the PIP IP address which triggers nexthop change.
Before fix:
When PIP IP changes RMAC is deleted from remote VTEPs.
TORS1# show evpn next-hops vni 4001 | include 00:02:00:00:00:2d
27.0.0.11 00:02:00:00:00:2d
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
00:02:00:00:00:2d 27.0.0.11
----- Remote VTEP change nexthop IP to 172.16.16.16 -----
TORS1# show evpn next-hops vni 4001 | include 00:02:00:00:00:2d
172.16.16.16 00:02:00:00:00:2d
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
TORS1#
After fix:
RMAC is retained as its nexthop list is not empty,
thus it is not deleted from remote VTEPs.
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
00:02:00:00:00:2d 172.16.16.16
Donald Sharp [Wed, 19 Apr 2023 12:13:18 +0000 (08:13 -0400)]
*: Rearrange vrf_bitmap_X api to reduce memory footprint
When running all daemons with config for most of them, FRR has
sharpd@janelle:~/frr$ vtysh -c "show debug hashtable" | grep "VRF BIT HASH" | wc -l
3570
3570 hashes for bitmaps associated with the vrf. This is a very
large number of hashes. Let's do two things:
a) Reduce the created size of the actually created hashes to 2
instead of 32.
b) Delay generation of the hash *until* a set operation happens.
As that no hash directly implies a unset value if/when checked.
This reduces the number of hashes to 61 in my setup for normal
operation.
add support of color extended community, conforming to RFC 9012.
This extended community will be added to the existing one, RT,SOO
and Node Target. The configuration will be made through the
route-map service.
Christian Hopps [Sun, 25 Jun 2023 12:13:25 +0000 (08:13 -0400)]
tools: less aggressive settings for clang-format
- Reports were that the current settings were choosing to extend beyond 80
columns too often. This change makes that more expensive but still tries
very hard to not break before first open parenthesis of function calls.
Mark Stapp [Wed, 31 May 2023 20:25:15 +0000 (16:25 -0400)]
zebra: support notifications for opaque ZAPI messages
Allow zapi clients to register to be notified when a server
for an opaque message type is present. Zebra maintains these
notification registrations in the same data structures that it
uses for opaque message handling.
Mark Stapp [Wed, 31 May 2023 20:22:16 +0000 (16:22 -0400)]
lib: add notifications for opaque zapi messages
Add a new notification zapi message type. A zapi client
that uses opaque messages can register to be notified
when a server for an opaque type is present.
Mark Stapp [Mon, 29 May 2023 17:04:24 +0000 (13:04 -0400)]
lib, zebra: include source client zapi info in opaque messages
Include the sending zapi client info (proto, instance, and
session id) in each opaque zapi message. Add opaque 'init'
apis for clients who want to encode their opaque data inline,
into the zclient's internal stream buffer. Use these init apis
in the TE/link-state lib code, instead of hand-coding the
zapi opaque header info.
projects / mirror / frr.git / log