Donald Sharp [Wed, 5 Jul 2023 13:28:50 +0000 (09:28 -0400)]
ospf6d: Convert ospf6_lsa_unlock to a better api
Make the ospf6_lsa_unlock take the same parameters
that the ospf_lsa_unlock does to make it consistent
and to also ensure that no-one can make the mistake
of getting the pointer cleared up.
Mark Stapp [Wed, 28 Jun 2023 19:33:57 +0000 (15:33 -0400)]
tests: add route-install test using NHRP tunnel
Add a test-case to the NHRP test that installs routes over the
NHRP tunnel endpoint routes. This confirms that zebra will use
NHRP routes when validating incoming routes from other daemons
(sharpd in this test).
Mark Stapp [Wed, 28 Jun 2023 12:11:41 +0000 (08:11 -0400)]
zebra: use NHRP routes as valid in nexthop check
Treat NHRP-installed routes as valid, as if they were
CONNECTED routes, when checking candidate routes'
nexthops for validity. This allows use of NHRP by an
IGP, for example, that doesn't normally want recursive
nexthop resolution.
Donald Sharp [Mon, 10 Jul 2023 14:40:38 +0000 (10:40 -0400)]
bgpd: Fix table manager to use the synchronous client
bgp_zebra_tm_connect calls bgp_zebra_get_table_range which
just used the global zclient. Which of course still had
us exposing the global zclient to read and drop important
data from zebra. This fixes commit 787c61e03c760ffdb422bfc44c72d83fb451e0c8
Donald Sharp [Mon, 10 Jul 2023 14:40:38 +0000 (10:40 -0400)]
bgpd: Fix table manager to use the synchronous client
bgp_zebra_tm_connect calls bgp_zebra_get_table_range which
just used the global zclient. Which of course still had
us exposing the global zclient to read and drop important
data from zebra. This fixes commit 787c61e03c760ffdb422bfc44c72d83fb451e0c8
David Schweizer [Mon, 10 Jul 2023 13:46:05 +0000 (15:46 +0200)]
tests: fix BGP delayopen timer expiration test
The changes allow the test to correctly pass in case the connection
between two peers is be established in less than 0.5 seconds after the
delayopen timer expires.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
Donald Sharp [Mon, 3 Jul 2023 20:12:16 +0000 (16:12 -0400)]
tests: bgp_flowspec expand timings
Attempt to set the hold time in the bgp flowspec exabgp
config. In addition it was noticed that upstream bgp_flowspec
tests are still not negotiating peering within the time frame
specified. This is because the first tcp packet is missed
and no keepalive/hold time are negotiated and exabgp will
not attempt a reconnect for quite some time. Make this
test slower when things go south.
Donald Sharp [Sat, 1 Jul 2023 17:30:12 +0000 (13:30 -0400)]
tests: isis_tilfa_topo1 fails sometimes due to insufficient time
The isis_tilfa_topo1 test is failing because insufficient time was
given for isis to converge on the system under system load. Extend
the time and decrease the hello-interval timers to give it more
of a chance to converge.
Donald Sharp [Sat, 1 Jul 2023 17:27:52 +0000 (13:27 -0400)]
tests: zebra_rib route-map run times fixup
I have a local test run where the sharp route-map usage
was being checked for 5 seconds. I saw usages going up
for each 1 second check and the 5th one was at 497 out
of 500. Looks like the system was really loaded. Let's
give it more time to coalesce under heavy load.
Donald Sharp [Thu, 29 Jun 2023 19:12:57 +0000 (15:12 -0400)]
tests: Look for zlog_backtrace in ci system
There are parts of our daemons that upon certain types
of errors that a zlog_backtrace is auto-generated.
It is desirable for this to be caught and have the
test auto-failed.
Issue: #13787 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgpd: Get 1 or 2 octets for Sub-TLV length (Tunnel Encap attr)
The total number of octets of the Sub-TLV Value field. The Sub-TLV Length field
contains 1 octet if the Sub-TLV Type field contains a value in the range from
0-127. The Sub-TLV Length field contains two octets if the Sub-TLV Type field
contains a value in the range from 128-255.
Chirag Shah [Sat, 8 Jul 2023 20:17:12 +0000 (13:17 -0700)]
tools: fix ospf area stub summary in frr-reload
OSPFv2 no area x stub no-summary only resets
'no-summary' config. From frr-reload if the config
line 'area x stub no-summary' is removed then
it needs to remove completely. Before this change
it took two frr-roload to remove the config which is
inconsistent behavior.
Fix is to frr-reload to add extra line to delete
'no area x stub'.
router ospf
ospf router-id 6.6.6.6
area 0.0.0.1 stub no-summary
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
area 0.0.1.2 stub no-summary
exit
changed frr.conf:
router ospf
ospf router-id 6.6.6.6
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
exit
Lines To Delete
===============
router ospf
no area 0.0.0.1 stub <<<< newly added
router ospf vrf sym_1
no area 0.0.1.2 stub <<<< newly added
router ospf
no area 0.0.0.1 stub no-summary
router ospf vrf sym_1
no area 0.0.1.2 stub no-summary
After fix new running-config post reload:
i
router ospf
ospf router-id 6.6.6.6
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
exit
Before fix running-config post 1st reload:
router ospf
ospf router-id 6.6.6.6
area 0.0.0.1 stub
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
area 0.0.1.2 stub
exit
Chirag Shah [Sat, 8 Jul 2023 01:19:54 +0000 (18:19 -0700)]
bgpd: fix evpn zclient_send_message return code
In scaled EVPN route sync from bgp to zebra, return
code can be ZCLIENT_SEND_BUFFERED which was treated
as error and leads to route install/uninstall failure.
Following error logs were seen:
2023-07-07T17:05:59.640899+03:00 vtep12 bgpd[15305]: [WYBZ0-MM8F1][EC 33554471] 0: Failed to uninstall EVPN IMET route in VNI 478
2023-07-07T17:05:59.640913+03:00 vtep12 bgpd[15305]: [Y5VKN-9BV7H][EC 33554471] default (0): Failed to uninstall EVPN [3]:[0]:[32]:[27.0.0.5]
route from VNI 465 IP table
2023-07-07T17:05:59.640927+03:00 vtep12 bgpd[15305]: [WYBZ0-MM8F1][EC 33554471] 0: Failed to uninstall EVPN IMET route in VNI 465
2023-07-07T17:05:59.640940+03:00 vtep12 bgpd[15305]: [Y5VKN-9BV7H][EC 33554471] default (0): Failed to uninstall EVPN [3]:[0]:[32]:[27.0.0.5]
route from VNI 173 IP table
Once source VTEP withdraws, DUT VTEP still has stale entries
root@vtep12:mgmt:~# bridge -d -s fdb show | grep 27.0.0.5 | wc -l
12990
After fix:
Once source VTEP withdraws, DUT VTEP still is able to delete entries
root@vtep12:mgmt:/home/cumulus# bridge -d -s fdb show | grep 27.0.0.5 |
wc -l
0
Zapi stats:
Client: bgp
[32/133]
------------------------
FD: 76
Connect Time: 00:26:17
Nexthop Registry Time: 00:26:11
Nexthop Last Update Time: 00:23:31
Client will Not be notified about it's routes status
Last Msg Rx Time: 00:21:33
Last Msg Tx Time: 00:23:31
Last Rcvd Cmd: ZEBRA_REMOTE_MACIP_ADD
Last Sent Cmd: ZEBRA_NEXTHOP_UPDATE
zebra: Fix crash when `dplane_fpm_nl` fails to process received routes
When `dplane_fpm_nl` receives a route, it allocates memory for a dplane
context and calls `netlink_route_change_read_unicast_internal` without
initializing the `intf_extra_list` contained in the dplane context. If
`netlink_route_change_read_unicast_internal` is not able to process the
route, we call `dplane_ctx_fini` to free the dplane context. This causes
a crash because `dplane_ctx_fini` attempts to access the intf_extra_list
which is not initialized.
To solve this issue, we can call `dplane_ctx_route_init`to initialize
the dplane route context properly, just after the dplane context
allocation.
(gdb) bt
#0 0x0000555dd5ceae80 in dplane_intf_extra_list_pop (h=0x7fae1c007e68) at ../zebra/zebra_dplane.c:427
#1 dplane_ctx_free_internal (ctx=0x7fae1c0074b0) at ../zebra/zebra_dplane.c:724
#2 0x0000555dd5cebc99 in dplane_ctx_free (pctx=0x7fae2aa88c98) at ../zebra/zebra_dplane.c:869
#3 dplane_ctx_free (pctx=0x7fae2aa88c98, pctx@entry=0x7fae2aa78c28) at ../zebra/zebra_dplane.c:855
#4 dplane_ctx_fini (pctx=pctx@entry=0x7fae2aa88c98) at ../zebra/zebra_dplane.c:890
#5 0x00007fae31e93f29 in fpm_read (t=) at ../zebra/dplane_fpm_nl.c:605
#6 0x00007fae325191dd in thread_call (thread=thread@entry=0x7fae2aa98da0) at ../lib/thread.c:2006
#7 0x00007fae324c42b8 in fpt_run (arg=0x555dd74777c0) at ../lib/frr_pthread.c:309
#8 0x00007fae32405ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9 0x00007fae32325a2f in clone () from /lib/x86_64-linux-gnu/libc.so.6
zebra: Abstract `dplane_ctx_route_init` to init route without copying
The function `dplane_ctx_route_init` initializes a dplane route context
from the route object passed as an argument. Let's abstract this
function to allow initializing the dplane route context without actually
copying a route object.
This allows us to use this function for initializing a dplane route
context when we don't have any route to copy in it.
In the function ospf_lsa_translated_nssa_new the newly created lsa is lock however, the return lsa from ospf_lsa_new already has a lock. Therefore removing the addition lock resolve the leak below.
Direct leak of 640 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16004f60 in ospf_lsa_new ../ospfd/ospf_lsa.c:186
#3 0x561a160051a1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:205
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16011cfb in ospf_translated_nssa_refresh ../ospfd/ospf_lsa.c:2152
#8 0x561a16014bb2 in ospf_external_lsa_install ../ospfd/ospf_lsa.c:2871
#9 0x561a1601596b in ospf_lsa_install ../ospfd/ospf_lsa.c:3076
#10 0x561a16168b3c in ospf_flood ../ospfd/ospf_flood.c:482
#11 0x561a160462f8 in ospf_ls_upd ../ospfd/ospf_packet.c:2115
#12 0x561a1604c66c in ospf_read_helper ../ospfd/ospf_packet.c:3198
#13 0x561a1604c88e in ospf_read ../ospfd/ospf_packet.c:3229
#14 0x7f294efd6c33 in event_call ../lib/event.c:1995
#15 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#16 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#17 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Direct leak of 640 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16004f60 in ospf_lsa_new ../ospfd/ospf_lsa.c:186
#3 0x561a160051a1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:205
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16010e10 in ospf_translated_nssa_originate ../ospfd/ospf_lsa.c:2034
#8 0x561a16136559 in ospf_abr_translate_nssa ../ospfd/ospf_abr.c:668
#9 0x561a161383da in ospf_abr_process_nssa_translates ../ospfd/ospf_abr.c:968
#10 0x561a1613f9b8 in ospf_abr_nssa_task ../ospfd/ospf_abr.c:2054
#11 0x561a161402e5 in ospf_abr_task_timer ../ospfd/ospf_abr.c:2168
#12 0x7f294efd6c33 in event_call ../lib/event.c:1995
#13 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#14 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#15 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 180 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16005a43 in ospf_lsa_data_new ../ospfd/ospf_lsa.c:296
#3 0x561a160051b1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:206
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16011cfb in ospf_translated_nssa_refresh ../ospfd/ospf_lsa.c:2152
#8 0x561a16014bb2 in ospf_external_lsa_install ../ospfd/ospf_lsa.c:2871
#9 0x561a1601596b in ospf_lsa_install ../ospfd/ospf_lsa.c:3076
#10 0x561a16168b3c in ospf_flood ../ospfd/ospf_flood.c:482
#11 0x561a160462f8 in ospf_ls_upd ../ospfd/ospf_packet.c:2115
#12 0x561a1604c66c in ospf_read_helper ../ospfd/ospf_packet.c:3198
#13 0x561a1604c88e in ospf_read ../ospfd/ospf_packet.c:3229
#14 0x7f294efd6c33 in event_call ../lib/event.c:1995
#15 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#16 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#17 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 180 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16005a43 in ospf_lsa_data_new ../ospfd/ospf_lsa.c:296
#3 0x561a160051b1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:206
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16010e10 in ospf_translated_nssa_originate ../ospfd/ospf_lsa.c:2034
#8 0x561a16136559 in ospf_abr_translate_nssa ../ospfd/ospf_abr.c:668
#9 0x561a161383da in ospf_abr_process_nssa_translates ../ospfd/ospf_abr.c:968
#10 0x561a1613f9b8 in ospf_abr_nssa_task ../ospfd/ospf_abr.c:2054
#11 0x561a161402e5 in ospf_abr_task_timer ../ospfd/ospf_abr.c:2168
#12 0x7f294efd6c33 in event_call ../lib/event.c:1995
#13 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#14 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#15 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.1.1, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.1.1, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
bgpd: Show neighbors software version if description is not set
Also, this is visible only if `capability software-version` is enabled.
Example:
```
r1# show ip bgp summary
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.1.1, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
topotests: label per nexthop ipv6 test adds add a while loop for mpls table
The bgp_vpnv6_per_nexthop_label tests only check to see if the mpls labels
are installed one time. Test runs show that all but one label is installed.
More than likely the test has asked for data while zebra is still installing
it. the mpls_label_check functions must check this result multiple times as
that system may be under heavy load.
A loop is introduced in order to let zebra check the mpls table.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: Free nexthop in bgp_mplsvpn_nh_label_bind_free
`bmnc->nh` was not properly freed, leading to a memory leak.
The commit adds a check to ensure that the `bmnc->nh` member variable is freed if it exists.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_vpnv4_asbr.test_bgp_vpnv4_asbr/r2.asan.bgpd.6382
Direct leak of 720 byte(s) in 5 object(s) allocated from:
#0 0x7f6a80d02d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x55c9afd7c81c in qcalloc lib/memory.c:105
#2 0x55c9afd9166b in nexthop_new lib/nexthop.c:358
#3 0x55c9afd93aaa in nexthop_dup lib/nexthop.c:843
#4 0x55c9afad39bb in bgp_mplsvpn_nh_label_bind_register_local_label bgpd/bgp_mplsvpn.c:4259
#5 0x55c9afb1c5e9 in bgp_mplsvpn_handle_label_allocation bgpd/bgp_route.c:3239
#6 0x55c9afb1c5e9 in bgp_process_main_one bgpd/bgp_route.c:3339
#7 0x55c9afb1d2c1 in bgp_process_wq bgpd/bgp_route.c:3591
#8 0x55c9afe33df9 in work_queue_run lib/workqueue.c:266
#9 0x55c9afe198e2 in event_call lib/event.c:1995
#10 0x55c9afd5fc6f in frr_run lib/libfrr.c:1213
#11 0x55c9af9f6f00 in main bgpd/bgp_main.c:505
#12 0x7f6a7f55ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x7f6a80d02d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x55c9afd7c81c in qcalloc lib/memory.c:105
#2 0x55c9afd91ce8 in nexthop_add_labels lib/nexthop.c:536
#3 0x55c9afd93754 in nexthop_copy_no_recurse lib/nexthop.c:802
#4 0x55c9afd939fb in nexthop_copy lib/nexthop.c:821
#5 0x55c9afd93abb in nexthop_dup lib/nexthop.c:845
#6 0x55c9afad39bb in bgp_mplsvpn_nh_label_bind_register_local_label bgpd/bgp_mplsvpn.c:4259
#7 0x55c9afb1c5e9 in bgp_mplsvpn_handle_label_allocation bgpd/bgp_route.c:3239
#8 0x55c9afb1c5e9 in bgp_process_main_one bgpd/bgp_route.c:3339
#9 0x55c9afb1d2c1 in bgp_process_wq bgpd/bgp_route.c:3591
#10 0x55c9afe33df9 in work_queue_run lib/workqueue.c:266
#11 0x55c9afe198e2 in event_call lib/event.c:1995
#12 0x55c9afd5fc6f in frr_run lib/libfrr.c:1213
#13 0x55c9af9f6f00 in main bgpd/bgp_main.c:505
#14 0x7f6a7f55ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 736 byte(s) leaked in 7 allocation(s).
***********************************************************************************
```
The `bgp_vrf->vrf_prd_pretty` string was not properly freed, leading to a memory leak.
This commit resolves the memory leak by freeing the memory allocated for `bgp_vrf->vrf_prd_pretty` before returning from the function.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in evpn_type5_test_topo1.test_evpn_type5_topo1/e1.asan.bgpd.17689
Direct leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x7fdd94fc0538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
#1 0x55e28d9c4c6c in qstrdup lib/memory.c:117
#2 0x55e28d6c0d27 in evpn_configure_vrf_rd bgpd/bgp_evpn_vty.c:2297
#3 0x55e28d6c0d27 in bgp_evpn_vrf_rd bgpd/bgp_evpn_vty.c:6271
#4 0x55e28d94c155 in cmd_execute_command_real lib/command.c:994
#5 0x55e28d94c622 in cmd_execute_command lib/command.c:1053
#6 0x55e28d94ca99 in cmd_execute lib/command.c:1221
#7 0x55e28da6d7d4 in vty_command lib/vty.c:591
#8 0x55e28da6dc6e in vty_execute lib/vty.c:1354
#9 0x55e28da7644d in vtysh_read lib/vty.c:2362
#10 0x55e28da616e2 in event_call lib/event.c:1995
#11 0x55e28d9a7a65 in frr_run lib/libfrr.c:1213
#12 0x55e28d63ef00 in main bgpd/bgp_main.c:505
#13 0x7fdd93883c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 15 byte(s) leaked in 1 allocation(s).
***********************************************************************************
```
Donald Sharp [Thu, 27 Apr 2023 03:02:09 +0000 (23:02 -0400)]
zebra: Use zebra dplane for RTM link and addr
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>
Donald Sharp [Thu, 20 Apr 2023 12:51:42 +0000 (08:51 -0400)]
zebra: Add code to get/set interface to pass up from dplane
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.
Donald Sharp [Thu, 13 Apr 2023 20:43:27 +0000 (16:43 -0400)]
zebra: Remove duplicate function for netlink interface changes
Turns out FRR has 2 functions one specifically for startup
and one for normal day to day operations. There were only
a couple of minor differences from what I could tell, and
where they were different the after startup functionality should
have been updated too. I cannot figure out why we have 2.
Non-startup handling of bonds appears to be incorrect
so let's fix that. Additionally the speed was not
properly being set in non-startup situations.
Donald Sharp [Thu, 27 Apr 2023 03:25:27 +0000 (23:25 -0400)]
zebra: Rename vrf_lookup_by_tableid to zebra_vrf_lookup..
Rename the vrf_lookup_by_id function to zebra_vrf_lookup_by_id
and move to zebra_vrf.c where it nominally belongs, as that
we need zebra specific data to find this vrf_id and as such
it does not belong in vrf.c
Sai Gomathi N [Tue, 4 Jul 2023 08:55:33 +0000 (01:55 -0700)]
pimd,pim6d: Query-interval should be greater than quer max response time
According to RFC 2236 Section 8.3
The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval].
As Maximum Response Delay refers to the maximum time interval within which an IGMP or MLD router
should respond to a query message. If both are equal, then both may expire at the same time.
So Query Interval must be greater than the query max response time.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
projects / matthieu / frr.git / log