summaryrefslogtreecommitdiffstats
path: root/zebra/interface.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* zebra: remove duplicated codeIgor Ryzhov2023-09-171-10/+2
| | | | | | The same thing is done in zebra_if_update_link a couple of lines above. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* zebra: fix link update for veth interfacesJafar Al-Gharaibeh2023-09-141-2/+0
| | | | Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
* lib,zebra: add tx queuelen to interface structMark Stapp2023-09-011-2/+5
| | | | | | | | Add the txqlen attribute to the common interface struct. Capture the value in zebra, and distribute it through the interface lib module's zapi messaging. Signed-off-by: Mark Stapp <mjs@labn.net>
* zebra: Prevent protodown_rc from going BzonkasDonald Sharp2023-08-211-0/+6
| | | | | | | | | | | | | | | | The code that handles the protodown_rc setting for VRRP interfaces in zebra is sending a interface to be set into a protodown state *before* the interface has been learned by the kernel. Resulting in crashes when the data plane sends the ctx back to us saying hey man you are uncool. Additionally change the protodown code to refuse to send any protodown_rc codes *until* the interface has actually been learned about from the kernel. Ticket: 3582375 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #14223 from donaldsharp/interface_fiesMark Stapp2023-08-181-0/+6
|\ | | | | zebra: Fix crashes in interface change
| * zebra: Fix crashes in interface changeDonald Sharp2023-08-171-0/+6
| | | | | | | | | | | | | | | | Upon some internal testing some crashes were found. This fixes the several crashes and normalizes the code to be closer in it's execution pre and post changes to use the data plane. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: Delete the 'mbr_zifs' list in the if_zebra_delete_hook functionKeelan102023-08-121-0/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit addresses a memory leak issue detected by ASan associated with the member lists (mbr_zifs) of bond interfaces. Previously, the member lists were not properly deleted during interface deletion, leading to memory leaks. A call to list_delete() is made when interface is deleted. The ASan leak log for reference: ``` ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047:Direct leak of 80 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- #0 0x7fe7a5b9d037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#1 0x7fe7a57431ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#2 0x7fe7a571833c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#3 0x55c1b87a7525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#4 0x55c1b86e044d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#5 0x55c1b870fbcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#6 0x55c1b86e0cc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#7 0x55c1b86e8b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#8 0x55c1b8817a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#9 0x55c1b8817e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#10 0x55c1b8717b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#11 0x7fe7a5231d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- #0 0x7fe7a5b9d037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#1 0x7fe7a57431ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#2 0x7fe7a571843d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#3 0x7fe7a5718780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#4 0x55c1b87a6fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#5 0x55c1b86f177d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#6 0x55c1b86e0d51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#7 0x55c1b86e8b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#8 0x55c1b8817a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#9 0x55c1b8817e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#10 0x55c1b8717b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- FRRouting#11 0x7fe7a5231d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047- ./bgp_evpn_mh.test_evpn_mh/torm12.zebra.asan.662047-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s). -- ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918:Direct leak of 80 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- #0 0x7fd8c357f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#1 0x7fd8c31251ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#2 0x7fd8c30fa33c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#3 0x56101df23525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#4 0x56101de5c44d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#5 0x56101de8bbcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#6 0x56101de5ccc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#7 0x56101de64b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#8 0x56101df93a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#9 0x56101df93e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#10 0x56101de93b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#11 0x7fd8c2c13d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- #0 0x7fd8c357f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#1 0x7fd8c31251ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#2 0x7fd8c30fa43d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#3 0x7fd8c30fa780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#4 0x56101df22fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#5 0x56101de6d77d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#6 0x56101de5cd51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#7 0x56101de64b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#8 0x56101df93a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#9 0x56101df93e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#10 0x56101de93b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- FRRouting#11 0x7fd8c2c13d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918- ./bgp_evpn_mh.test_evpn_mh/torm21.zebra.asan.663918-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s). -- ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815:Direct leak of 80 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- #0 0x7ff74228b037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#1 0x7ff741e311ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#2 0x7ff741e0633c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#3 0x56535dceb525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#4 0x56535dc2444d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#5 0x56535dc53bcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#6 0x56535dc24cc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#7 0x56535dc2cb27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#8 0x56535dd5ba77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#9 0x56535dd5be76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#10 0x56535dc5bb38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#11 0x7ff74191fd09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- #0 0x7ff74228b037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#1 0x7ff741e311ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#2 0x7ff741e0643d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#3 0x7ff741e06780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#4 0x56535dceafdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#5 0x56535dc3577d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#6 0x56535dc24d51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#7 0x56535dc2cb27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#8 0x56535dd5ba77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#9 0x56535dd5be76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#10 0x56535dc5bb38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- FRRouting#11 0x7ff74191fd09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815- ./bgp_evpn_mh.test_evpn_mh/torm11.zebra.asan.660815-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s). -- ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685:Direct leak of 40 byte(s) in 1 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- #0 0x7fb3bf09f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#1 0x7fb3bec451ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#2 0x7fb3bec1a33c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#3 0x559e90ee6525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#4 0x559e90e1f44d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#5 0x559e90e4ebcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#6 0x559e90e1fcc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#7 0x559e90e27b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#8 0x559e90f56a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#9 0x559e90f56e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#10 0x559e90e56b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#11 0x7fb3be733d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- #0 0x7fb3bf09f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#1 0x7fb3bec451ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#2 0x7fb3bec1a43d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#3 0x7fb3bec1a780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#4 0x559e90ee5fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#5 0x559e90e3077d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#6 0x559e90e1fd51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#7 0x559e90e27b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#8 0x559e90f56a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#9 0x559e90f56e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#10 0x559e90e56b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- FRRouting#11 0x7fb3be733d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685- ./bgp_evpn_mh.test_evpn_mh/hostd12.zebra.asan.667685-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s). -- ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560:Direct leak of 40 byte(s) in 1 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- #0 0x7faab58d4037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#1 0x7faab547a1ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#2 0x7faab544f33c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#3 0x5599ef7e5525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#4 0x5599ef71e44d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#5 0x5599ef74dbcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#6 0x5599ef71ecc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#7 0x5599ef726b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#8 0x5599ef855a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#9 0x5599ef855e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#10 0x5599ef755b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#11 0x7faab4f68d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- #0 0x7faab58d4037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#1 0x7faab547a1ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#2 0x7faab544f43d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#3 0x7faab544f780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#4 0x5599ef7e4fdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#5 0x5599ef72f77d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#6 0x5599ef71ed51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#7 0x5599ef726b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#8 0x5599ef855a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#9 0x5599ef855e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#10 0x5599ef755b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- FRRouting#11 0x7faab4f68d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560- ./bgp_evpn_mh.test_evpn_mh/hostd22.zebra.asan.670560-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s). -- ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413:Direct leak of 80 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- #0 0x7fc5e175f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#1 0x7fc5e13051ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#2 0x7fc5e12da33c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#3 0x55e090b90525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#4 0x55e090ac944d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#5 0x55e090af8bcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#6 0x55e090ac9cc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#7 0x55e090ad1b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#8 0x55e090c00a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#9 0x55e090c00e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#10 0x55e090b00b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#11 0x7fc5e0df3d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- #0 0x7fc5e175f037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#1 0x7fc5e13051ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#2 0x7fc5e12da43d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#3 0x7fc5e12da780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#4 0x55e090b8ffdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#5 0x55e090ada77d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#6 0x55e090ac9d51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#7 0x55e090ad1b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#8 0x55e090c00a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#9 0x55e090c00e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#10 0x55e090b00b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- FRRouting#11 0x7fc5e0df3d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413- ./bgp_evpn_mh.test_evpn_mh/torm22.zebra.asan.665413-SUMMARY: AddressSanitizer: 128 byte(s) leaked in 4 allocation(s). -- ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024:Direct leak of 40 byte(s) in 1 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- #0 0x7fe5c2019037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#1 0x7fe5c1bbf1ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#2 0x7fe5c1b9433c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#3 0x557ad92d0525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#4 0x557ad920944d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#5 0x557ad9238bcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#6 0x557ad9209cc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#7 0x557ad9211b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#8 0x557ad9340a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#9 0x557ad9340e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#10 0x557ad9240b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#11 0x7fe5c16add09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- #0 0x7fe5c2019037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#1 0x7fe5c1bbf1ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#2 0x7fe5c1b9443d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#3 0x7fe5c1b94780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#4 0x557ad92cffdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#5 0x557ad921a77d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#6 0x557ad9209d51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#7 0x557ad9211b27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#8 0x557ad9340a77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#9 0x557ad9340e76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#10 0x557ad9240b38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- FRRouting#11 0x7fe5c16add09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024- ./bgp_evpn_mh.test_evpn_mh/hostd21.zebra.asan.669024-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s). -- ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551:Direct leak of 40 byte(s) in 1 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- #0 0x7f1fc2399037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#1 0x7f1fc1f3f1ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#2 0x7f1fc1f1433c in list_new lib/linklist.c:49 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#3 0x559cd8f0b525 in zebra_l2if_update_bond zebra/zebra_l2.c:223 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#4 0x559cd8e4444d in netlink_interface zebra/if_netlink.c:1203 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#5 0x559cd8e73bcf in netlink_parse_info zebra/kernel_netlink.c:1183 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#6 0x559cd8e44cc1 in interface_lookup_netlink zebra/if_netlink.c:1273 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#7 0x559cd8e4cb27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#8 0x559cd8f7ba77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#9 0x559cd8f7be76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#10 0x559cd8e7bb38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#11 0x7f1fc1a2dd09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551:Indirect leak of 48 byte(s) in 2 object(s) allocated from: ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- #0 0x7f1fc2399037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#1 0x7f1fc1f3f1ee in qcalloc lib/memory.c:105 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#2 0x7f1fc1f1443d in listnode_new lib/linklist.c:71 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#3 0x7f1fc1f14780 in listnode_add lib/linklist.c:92 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#4 0x559cd8f0afdf in zebra_l2_map_slave_to_bond zebra/zebra_l2.c:168 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#5 0x559cd8e5577d in zebra_if_update_all_links zebra/interface.c:1150 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#6 0x559cd8e44d51 in interface_lookup_netlink zebra/if_netlink.c:1303 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#7 0x559cd8e4cb27 in interface_list zebra/if_netlink.c:2419 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#8 0x559cd8f7ba77 in zebra_ns_enable zebra/zebra_ns.c:113 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#9 0x559cd8f7be76 in zebra_ns_init zebra/zebra_ns.c:205 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#10 0x559cd8e7bb38 in main zebra/main.c:399 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- FRRouting#11 0x7f1fc1a2dd09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551- ./bgp_evpn_mh.test_evpn_mh/hostd11.zebra.asan.666551-SUMMARY: AddressSanitizer: 88 byte(s) leaked in 3 allocation(s). ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
* zebra, yang: add an mpls leaf to interfacePhilippe Guibert2023-08-101-14/+7
| | | | | | | | | | The yang NB API does not handle the mpls configuration on its leaf. Add an mpls leaf to stick to the mpls configuration. - true or false to mean if config - not defined, means no config. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: fix 'no mpls' command by using 'mpls disable' insteadPhilippe Guibert2023-08-101-5/+12
| | | | | | | | | | | | The 'no mpls' command wrongly assumes the user wants to disable the mpls handling on the interface whereas this is just a config knob that should mean 'I don't care with mpls'. Fix this by adding a 'disable' option to the mpls command. Fixes: 39ffa8e8e856 ("zebra: Add a `mpls enable` interface node command") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: Fix wrong vrf change procedureanlan_cs2023-07-131-9/+9
| | | | | | | | | | | | | | | | | | | Currently the vrf change procedure for the deleted interface is after its deletion, it causes problem for upper daemons. Here is the problem of `bgp`: After deletion of one **irrelevant** interface in the same vrf, its `ifindex` is set to 0. And then, the vrf change procedure will send "ZEBRA_INTERFACE_DOWN" to `bgpd`. Normally, `bgp_nht_ifp_table_handle()` should igore this message for no correlation. However, it wrongly matched `ifindex` of 0, and removed the related routes for the down `bnc`. Adjust the location of the vrf change procedure to fix this issue. Signed-off-by: anlan_cs <vic.lan@pica8.com>
* Merge pull request #13958 from opensourcerouting/fix/coverityDonald Sharp2023-07-111-5/+18
|\ | | | | Coverity fixes
| * zebra: Guard printing an error by checking if VRF is not NULLDonatas Abraitis2023-07-101-4/+10
| | | | | | | | | | | | | | Check if vrf_lookup_by_id() didn't return a NULL before dereferencing in flor_err(). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
| * zebra: Check if ifp is not NULL in zebra_if_update_ctx()Donatas Abraitis2023-07-101-0/+7
| | | | | | | | | | | | Use the same logic as zebra_if_netconf_update_ctx(). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
| * zebra: Do not check ifp for NULLDonatas Abraitis2023-07-101-1/+1
| | | | | | | | | | | | It's already checked at the bottom of the function. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* | Merge pull request #13964 from pguibert6WIND/mpls_againRuss White2023-07-111-0/+5
|\ \ | |/ |/| zebra: fix mpls config on ifaces created post frr
| * zebra: fix mpls config on ifaces created post frrPhilippe Guibert2023-07-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mpls configuration does not work when an interface is created after having applied the frr configuration. The below scenario illustrates: > root@dut:~# modprobe mpls > root@dut:~# zebra & > [..] > dut(config)# interface ifacenotcreated > dut(config-if)# mpls enable > dut(config-if)# Ctrl-D > root@dut:~# ip li show ifacenotcreated > Device "ifacenotcreated" does not exist. > root@dut:~# ip li add ifacenotcreated type dummy > 0 Fix this by forcing the mpls flag when the interface is detected. > root@dut:~# cat /proc/sys/net/mpls/conf/ifacenotcreat/input > 1 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | zebra: Use zebra dplane for RTM link and addrDonald Sharp2023-07-051-12/+766
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) Move the reads of link and address information into the dplane b) Move the startup read of data into the dplane as well. c) Break up startup reading of the linux kernel data into multiple phases. As that we have implied ordering of data that must be read first and if the dplane has taken over some data reading then we must delay initial read-in of other data. Fixes: #13288 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: Add code to get/set interface to pass up from dplaneDonald Sharp2023-07-051-0/+1
|/ | | | | | | | | | | | 1) Add a bunch of get/set functions and associated data structure in zebra_dplane to allow the setting and retrieval of interface netlink data up into the master pthread. 2) Add a bit of code to breakup startup into stages. This is because FRR currently has a mix of dplane and non dplane interactions and the code needs to be paused before continuing on. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #13545 from idryzhov/remove-bond-slaveDonatas Abraitis2023-06-231-3/+0
|\ | | | | zebra: remove ZEBRA_IF_BOND_SLAVE interface type
| * zebra: remove ZEBRA_IF_BOND_SLAVE interface typeIgor Ryzhov2023-05-211-3/+0
| | | | | | | | | | | | | | | | It is never actually used in the code. Closes #13532. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* | zebra: clarify interface-level mpls configMark Stapp2023-06-121-3/+5
| | | | | | | | | | | | | | We have both interface-level configuration to enable mpls, and runtime mpls status. They need to be distinct. Signed-off-by: Mark Stapp <mjs@labn.net>
* | lib, zebra: Ensure that the ifp->node existsDonald Sharp2023-05-281-0/+3
|/ | | | | | | | | On removal, ensure that the ifp->node is set to a null pointer so that FRR does not use data after freed. In addition ensure that the ifp->node exists before attempting to free it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Fix missing VRF flaganlan_cs2023-05-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. No any configuration in FRR, and `ip link add vrf1 type vrf ...`. Currently, everything is ok. 2. `ip link del vrf1`. `zebra` will wrongly/redundantly notify clients to add "vrf1" as a normal interface after correct deletion of "vrf1". ``` ZEBRA: [KMXEB-K771Y] netlink_parse_info: netlink-listen (NS 0) type RTM_DELLINK(17), len=588, seq=0, pid=0 ZEBRA: [TDJW2-B9KJW] RTM_DELLINK for vrf1(93) <- Wrongly as normal interface, not vrf ZEBRA: [WEEJX-M4HA0] interface vrf1 vrf vrf1(93) index 93 is now inactive. ZEBRA: [NXAHW-290AC] MESSAGE: ZEBRA_INTERFACE_DELETE vrf1 vrf vrf1(93) ZEBRA: [H97XA-ABB3A] MESSAGE: ZEBRA_INTERFACE_VRF_UPDATE/DEL vrf1 VRF Id 93 -> 0 ZEBRA: [HP8PZ-7D6D2] MESSAGE: ZEBRA_INTERFACE_VRF_UPDATE/ADD vrf1 VRF Id 93 -> 0 <- ZEBRA: [Y6R2N-EF2N4] interface vrf1 is being deleted from the system ZEBRA: [KNFMR-AFZ53] RTM_DELLINK for VRF vrf1(93) ZEBRA: [P0CZ5-RF5FH] VRF vrf1 id 93 is now inactive ZEBRA: [XC3P3-1DG4D] MESSAGE: ZEBRA_VRF_DELETE vrf1 ZEBRA: [ZMS2F-6K837] VRF vrf1 id 4294967295 deleted OSPF: [JKWE3-97M3J] Zebra: interface add vrf1 vrf default[0] index 0 flags 480 metric 0 mtu 65575 speed 0 <- Wrongly add interface ``` `if_handle_vrf_change()` moved the interface from specific vrf to default vrf. But it doesn't skip interface of vrf type. So, the wrong/redundant add operation is done. Note, the wrong add operation is regarded as an normal interface because the `ifp->status` is cleared too early, so it is without VRF flag ( `ZEBRA_INTERFACE_VRF_LOOPBACK` ). Now, ospfd will initialize `ifp->type` to `OSPF_IFTYPE_BROADCAST`. 3. `ip link add vrf1 type vrf ...`, add "vrf1" again. FRR will be with wrong display: ``` interface vrf1 ip ospf network broadcast exit ``` Here, zebra will send `ZEBRA_INTERFACE_ADD` again for "vrf1" with correct `ifp->status`, so it will be updated into vrf type. But it can't update `ifp->type` from `OSPF_IFTYPE_BROADCAST` to `OSPF_IFTYPE_LOOPBACK` because it had been already configured in above step 2. Two changes to fix it: 1. Skip the procedure of switching VRF for interfaces of vrf type. It means, don't send `ZEBRA_INTERFACE_ADD` to clients when deleting vrf. 2. Put the deletion of this flag at the last. It means, clients should get correct `ifp->status`. Signed-off-by: anlan_cs <vic.lan@pica8.com>
* Merge pull request #12959 from leonshaw/fix/zif-link-nsidJafar Al-Gharaibeh2023-04-111-8/+15
|\ | | | | zebra: Add link_nsid to zebra interface
| * zebra: Add link_nsid to zebra interfaceXiao Liang2023-03-081-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create VRF and interfaces: ip netns add vrf1 ip link add veth1 index 100 type veth ip link add link veth1 veth1.200 type vlan id 200 ip link set veth1.200 netns vrf1 ip -n vrf1 link add veth2 index 100 type veth After reloading zebra, "show interface veth1.200" shows wrong parent interface: test# show interface veth1.200 Interface veth1.200 is down ... Parent interface: veth2 This is because veth1.200 and veth1 are in different netns, and veth2 happens to have the same ifindex as veth1, in the same netns of veth1.200. When looking for parent, link-ifindex 100 should be looked up within link-netns, rather than that of the child interface. Add link_nsid to zebra interface, so that the <link_nsid, link_ifindex> pair can uniquely identify the link interface. Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
* | *: Convert THREAD_XXX macros to EVENT_XXX macrosDonald Sharp2023-03-241-2/+2
| | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | *: Convert a bunch of thread_XX to event_XXDonald Sharp2023-03-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Convert these functions: thread_getrusage thread_cmd_init thread_consumed_time thread_timer_to_hhmmss thread_is_scheduled thread_ignore_late_timer Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | *: Convert thread_add_XXX functions to event_add_XXXDonald Sharp2023-03-241-6/+6
| | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | *: Rename `struct thread` to `struct event`Donald Sharp2023-03-241-1/+1
|/ | | | | | | | | Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #12780 from opensourcerouting/spdx-license-idDonald Sharp2023-02-171-16/+1
|\ | | | | *: convert to SPDX License identifiers
| * *: auto-convert to SPDX License IDsDavid Lamparter2023-02-091-16/+1
| | | | | | | | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* | Merge pull request #12494 from louis-6wind/ext_admin_groupOlivier Dugeon2023-02-151-24/+177
|\ \ | | | | | | lib,zebra,isisd: add support for extended admin group RFC7308
| * | lib,yang,zebra: add extended admin-group supportLouis Scalbert2023-02-101-24/+177
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the support of Extended Admin-Group (RFC7308) to the zebra interface link-params Traffic-Engineering context. Extended admin-groups can be configured with the affinity-map: > affinity-map blue bit-position 221 > int eth-rt1 > link-params > affinity blue > exit-link-params Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* | zebra: clang-format style fixesStephen Worley2023-02-141-1/+1
| | | | | | | | | | | | clang-format style fixes Signed-off-by: Stephen Worley <sworley@nvidia.com>
* | zebra: Add ifdump vty json extension for vxlan/vniSharath Ramamurthy2023-02-141-66/+59
| | | | | | | | | | | | This patch adds dump for vxlan/vni for vxlan devices in if_dump_vty_json Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
* | zebra: Bug fixes in fdb read for flooded traffic and remote fdb cleanup upon ↵Sharath Ramamurthy2023-02-141-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vni removal This patch addresses following issues, - When the VLAN-VNI mapping is configured via a map and not using individual VXLAN interfaces, upon removal of a VNI ensure that the remote FDB entries are uninstalled correctly. - When VNI configuration is performed using VLAN-VNI mapping (i.e., without individual VXLAN interfaces) and flooded traffic is handled via multicast, the multicast group corresponding to the VNI needs to be explicitly read from the bridge FDB. This is relevant in the case of netlink interface to the kernel and for the scenario where a new VNI is provisioned or comes up. Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
* | zebra: Bug fixes in vtysh doc string, mcast group handling and vni deletion ↵Sharath Ramamurthy2023-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | handling with single vxlan device This patch addresses following bug fixes - Fix vtysh doc string in "show evpn access-vlan..." command - Multicast group handling was little complex. This change avoids calling multiple functions and directly calls the zebra_vxlan_if_update_vni for mcast group updates. - When a vlan-vni map is removed, the removed vni deletion was happening in FRR with SVD config. This was resulting in stale vni and not resulting propagation of the vni deletion. During vni cleanup (zebra_vxlan_if_vni_clean) zebra_vxlan_if_vni_del was called for vni delete which is not correct. We should be calling zebra_vxlan_if_vni_entry_del for the given vni entry. Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
* | zebra: Refactoring changes for zebra_evpn_map_vlan zebra_evpn_from_svi and ↵Sharath Ramamurthy2023-02-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zl3vni_from_svi Today to find the vni for a given (vlan, bridge) we walk over all interfaces and filter the vxlan device associated with the bridge. With multiple vlan aware bridge changes, we can derive the vni directly by looking up the hash table i.e. the vlan_table of the associated (vlan, bridge) which would give the vni. During vrf_terminate() call zebra_l2_bridge_if_cleanup if the interface that we are removing is of type bridge. In this case, we walk over all the vlan<->access_bd association and clean them up. zebra_evpn_t is modified to record (vlan, bridge) details and the corresponding vty is modified to print the same. zevpn_bridge_if_set and zl3vni_bridge_if_set is used to set/unset the association. Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
* | zebra: multiple vlan aware bridge datastructure changes and vxlan device ↵Sharath Ramamurthy2023-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iftype derivation from netlink This change set introduces data structure changes required for multiple vlan aware bridge functionality. A new structure zebra_l2_bridge_if encapsulates the vlan to access_bd association of the bridge. A vlan_table hash_table is used to record each instance of the vlan to access_bd of the bridge via zebra_l2_bridge_vlan structure. vxlan iftype derivation: netlink attribute IFLA_VXLAN_COLLECT_METADATA is used to derive the iftype of the vxlan device. If the attribute is present, then the vxlan interface is treated as single vxlan device, otherwise it would default to traditional vxlan device. zebra_vxlan_check_readd_vtep, zebra_vxlan_dp_network_mac_add/del is modified to be vni aware. mac_fdb_read_for_bridge - is modified to be (vlan, bridge) aware Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
* | zebra: data structure changes for single vxlan deviceSharath Ramamurthy2023-02-141-53/+115
|/ | | | | | | | | | | | | | This changeset introduces the data structure changes needed for single vxlan device functionality. A new struct zebra_vxlan_vni_info encodes the iftype and vni information for vxlan device. The change addresses related access changes of the new data structure fields from different files zebra_vty is modified to take care of the vni dump information according to the new vni data structure for vxlan devices. Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
* zebra: fix possible null dereferenceRafael Zalamena2023-01-191-1/+2
| | | | | | | | | | | | | | Don't attempt to dereference `ifp` directly if it might be null: there is a check right before this usage: `ifp ? ifp->info : NULL`. In this context it should be safe to assume `ifp` is not NULL because the only caller of this function checks that for this `ifindex`. For consistency we'll check for null anyway in case this ever changes (and with this the coverity scan warning gets silenced). Found by Coverity Scan (CID 1519776) Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
* zebra: use real MTYPEs for various objectsMark Stapp2022-12-051-1/+2
| | | | | | | Don't use MTYPE_TMP for many things in zebra: add specific mem types. Signed-off-by: Mark Stapp <mjs@labn.net>
* zebra: Use `mpls enable`, not `mpls` when generating a configDonatas Abraitis2022-11-281-1/+1
| | | | | | | If we enable MPLS for an interface via sysctl, we should write `mpls enable`, not `mpls`. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* zebra: traffic control state managementSiger Yang2022-11-221-3/+8
| | | | | | | This allows Zebra to manage QDISC, TCLASS, TFILTER in kernel and do cleaning jobs when it starts up. Signed-off-by: Siger Yang <siger.yang@outlook.com>
* Merge pull request #12196 from opensourcerouting/xref-vtyshDonald Sharp2022-11-031-2/+0
|\ | | | | *: rewrite `extract.pl` using `xref` infra
| * build, vtysh: extract vtysh commands from .xrefDavid Lamparter2022-10-261-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than running selected source files through the preprocessor and a bunch of perl regex'ing to get the list of all DEFUNs, use the data collected in frr.xref. This not only eliminates issues we've been having with preprocessor failures due to nonexistent header files, but is also much faster. Where extract.pl would take 5s, this now finishes in 0.2s. And since this is a non-parallelizable build step towards the end of the build (dependent on a lot of other things being done already), the speedup is actually noticeable. Also files containing CLI no longer need to be listed in `vtysh_scan` since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL` checks are equally obsolete. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* | lib,zebra: do not enable link-params when a link-params command failsLouis Scalbert2022-10-171-21/+62
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | A given interface has no enabled link-params context. If a link-params configuration command fails, the link-params is wrongly enabled: > r4(config-link-params)# no enable > r4(config-link-params)# delay > (0-16777215) Average delay in micro-second as decimal (0...16777215) > r4(config-link-params)# delay 50 min 300 max 500 > Average delay should be comprise between Min (300) and Max (500) delay > r4(config-link-params)# do sh run zebra > (...) > interface eth-rt1 > link-params > enable > exit-link-params link-params are enabled if and only if the interface structure has a valid link_params pointer. Before checking the command validity, if_link_params_get() is called to retrieve the link-params pointer. However, this function initializes the pointer if it is NULL. Only use if_link_params_get() to retrieve the pointer to avoid confusion. In command setting functions, initialize the link_params pointer if needed only after the validation of the command. Fixes: 16f1b9e ("Update Traffic Engineering Support for OSPFD") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* zebra: add tc netlink and dplane opsSiger Yang2022-08-101-0/+3
| | | | | | | | This commit implements necessary netlink encoders for traffic control including QDISC, TCLASS and TFILTER, and adds basic dplane operations. Co-authored-by: Stephen Worley <sworley@nvidia.com> Signed-off-by: Siger Yang <siger.yang@outlook.com>
* zebra: Don't install connected routes multiple times into FRRDonald Sharp2022-08-081-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When moving an interface between vrf's we do not need to install the connected routes multiple times. eva# show ip route vrf all Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure VRF BLUE: C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:10 VRF default: K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:00:10 C>* 192.168.119.0/24 is directly connected, enp39s0, 00:00:10 eva# exit sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link add GREEN type vrf table 11000 sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set GREEN up sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set dummy7 master GREEN sharpd@eva ~/f/t/topotests (multiple_connected_installs)> vtysh Hello, this is FRRouting (version 8.4-dev). Copyright 1996-2005 Kunihiro Ishiguro, et al. eva# show ip route vrf all Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure VRF GREEN: C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:05 VRF default: K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:01:03 C>* 192.168.119.0/24 is directly connected, enp39s0, 00:01:03 eva# exit sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set dummy7 nomaster sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo vtysh -c "show ip route vrf all" Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure VRF default: K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:22 C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:08 C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:22 sharpd@eva ~/f/t/topotests (multiple_connected_installs)> @ 11 0:-* 5h50m 0.06 24x1.9GHz 31.4G26% 426G70% 2022-08-08 13:49:24 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Add a `mpls enable` interface node commandDonald Sharp2022-08-081-0/+24
| | | | | | | | | | | | | | | | | Allow individual interfaces to turn on/off the mpls subsystem for it in linux. sharpd@eva:~/frr9$ sudo sysctl -a | grep enp39s0 | grep mpls net.mpls.conf.enp39s0.input = 0 sharpd@eva:~/frr9$ vtysh -c "conf" -c "int enp39s0" -c "mpls enable" sharpd@eva:~/frr9$ sudo sysctl -a | grep enp39s0 | grep mpls net.mpls.conf.enp39s0.input = 1 sharpd@eva:~/frr9$ vtysh -c "conf" -c "int enp39s0" -c "no mpls enable" sharpd@eva:~/frr9$ sudo sysctl -a | grep enp39s0 | grep mpls net.mpls.conf.enp39s0.input = 0 sharpd@eva:~/frr9$ Signed-off-by: Donald Sharp <sharpd@nvidia.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-19 12:19:21 +0100