Donald Sharp [Wed, 20 Jul 2022 20:43:17 +0000 (16:43 -0400)]
ospfclient: Ensure ospf_apiclient_lsa_originate cannot accidently write into stack
Even though OSPF_MAX_LSA_SIZE is quite large and holds the upper bound
on what can be written into a lsa, let's add a small check to ensure
it is not possible to do a bad thing.
This wins one of the long standing bug awards. 2003!
Fixes: #11602 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Thu, 21 Jul 2022 19:42:51 +0000 (15:42 -0400)]
bgpd: LL peers need bnc's per peer
FRR should create a bnc per peer. Not have
one's that write over others. Currently when
FRR has multiple Interface based peering, BGP wa
creating a single BNC. This is insufficient in that
we were accidently overwriting the one LL with other
data. This causes issues when there are multiple and
there is weird starting issues with those interfaces
that you are peering over.
Philippe Guibert [Tue, 12 Jul 2022 10:12:01 +0000 (12:12 +0200)]
topotests: add bfd_vrflite_topo1 test
This tests checks that there are no errors when receiving BFD
packets over the various linux vrf interfaces. For example, if
an incoming packet is received by the wrong socket, a VRF
mismatch error would occur, and BFD flapping would be observed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Fri, 3 Jun 2022 14:59:31 +0000 (10:59 -0400)]
bgpd: Convert thread_cancel to THREAD_OFF and use THREAD_ARG
Just convert all uses of thread_cancel to THREAD_OFF. Additionally
use THREAD_ARG instead of t->arg to get the arguement. Individual
files should never be accessing thread private data like this.
Donald Sharp [Fri, 3 Jun 2022 14:43:45 +0000 (10:43 -0400)]
bgpd: Remove various macros that overlap THREAD_OFF
Let's just use THREAD_OFF consistently in the code base
instead of each daemon having a special macro that needs to
be looked at and remembered what it does.
Donald Sharp [Fri, 3 Jun 2022 14:37:34 +0000 (10:37 -0400)]
ripngd: Remove various macros that overlap THREAD_OFF
Let's just use THREAD_OFF consistently in the code base
instead of each daemon having a special macro that needs to
be looked at and remembered what it does.
Donald Sharp [Fri, 3 Jun 2022 14:33:12 +0000 (10:33 -0400)]
ripd: Remove various macros that overlap THREAD_OFF
Let's just use THREAD_OFF consistently in the code base
instead of each daemon having a special macro that needs to
be looked at and remembered what it does.
Donald Sharp [Fri, 3 Jun 2022 14:28:11 +0000 (10:28 -0400)]
ospfd: Remove various macros that overlap THREAD_OFF
Let's just use THREAD_OFF consistently in the code base
instead of each daemon having a special macro that needs to
be looked at and remembered what it does.
bfdd: allow l3vrf bfd sessions without udp leaking
Until now, when in vrf-lite mode, the BFD implementation
creates a single UDP socket and relies on the following
sysctl value to 1:
echo 1 > /proc/sys/net/ipv4/udp_l3mdev_accept
With this setting, the incoming BFD packets from a given
vrf, would leak to the default vrf, and would match the
UDP socket.
The drawback of this solution is that udp packets received
on a given vrf may leak to an other vrf. This may be a
security concern.
The commit addresses this issue by avoiding this leak
mechanism. An UDP socket is created for each vrf, and each
socket uses new setsockopt option: SO_REUSEADDR + SO_REUSEPORT.
With this option, the incoming UDP packets are distributed on
the available sockets. The impact of those options with l3mdev
devices is unknown. It has been observed that this option is not
needed, until the default vrf sockets are created.
To ensure the BFD packets are correctly routed to the appropriate
socket, a BPF filter has been put in place and attached to the
sockets : SO_ATTACH_REUSEPORT_CBPF. This option adds a criterium
to force the packet to choose a given socket. If initial criteria
from the default distribution algorithm were not good, at least
two sockets would be available, and the CBPF would force the
selection to the same socket. This would come to the situation
where an incoming packet would be processed on a different vrf.
if (setsockopt(sd, SOL_SOCKET, SO_ATTACH_REUSEPORT_CBPF, &p, sizeof(p))) {
zlog_warn("unable to set SO_ATTACH_REUSEPORT_CBPF on socket: %s",
strerror(errno));
return -1;
}
Some tests have been done with by creating vrf contexts, and by using
the below vtysh configuration:
The results showed no issue related to packets received by
the wrong vrf. Even changing the udp_l3mdev_accept flag to
1 did not change the test results.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Tue, 19 Jul 2022 17:57:56 +0000 (13:57 -0400)]
zebra: Add some more data to rtadv socket failures
The creation of the rtadv socket can fail but there
is very very little data associated with this event
to let the operator know something has gone terribly
wrong.
Please note if this socket fails to create or fails
the setsockopt's rtadv is basically just really really
messed up. I am not sure what can be done here.
Donald Sharp [Fri, 8 Jul 2022 20:35:51 +0000 (16:35 -0400)]
tests: Make bgp_snmp_mplsl3vpn be more forgiving
I rarely get this failure:
@classname: bgp_snmp_mplsl3vpn.test_bgp_snmp_mplsvpn
@name: test_pe1_converge_evpn
@time: 44.875
@message: AssertionError: BGP SNMP does not seem to be running
assert False
+ where False = <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>>('bgpVersion', '10')
+ where <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>> = <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>.test_oid
"Wait for protocol convergence"
tgen = get_topogen()
assertmsg = "BGP SNMP does not seem to be running"
> assert r1_snmp.test_oid("bgpVersion", "10"), assertmsg
E AssertionError: BGP SNMP does not seem to be running
E assert False
E + where False = <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>>('bgpVersion', '10')
E + where <bound method SnmpTester.test_oid of <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>> = <lib.snmptest.SnmpTester object at 0x7fa8562eb4f0>.test_oid
Under heavy system load a quick test before BGP can fully come up can result in a failed
test. Add some extra time for snmp to come up properly.
currently "show bgp summary" and "sho bgp summary wide" commands
provide a description string until a whitespace is occuring this
respectively with size limits of 20 and 60 chars
now theses two commands are providing strings with all
characters until the last witespace before size limit
zebra: Cleanup the memory from the hash for MPLS stuff
==1595641== 280 (80 direct, 200 indirect) bytes in 1 blocks are definitely lost in loss record 30 of 38
==1595641== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1595641== by 0x493C89C: qcalloc (memory.c:116)
==1595641== by 0x1E8426: lsp_alloc (zebra_mpls.c:1116)
==1595641== by 0x49147F1: hash_get (hash.c:162)
==1595641== by 0x1EC880: mpls_lsp_install (zebra_mpls.c:3192)
==1595641== by 0x1C51BB: zread_vrf_label (zapi_msg.c:3197)
==1595641== by 0x1C6F11: zserv_handle_commands (zapi_msg.c:3863)
==1595641== by 0x24D0F4: zserv_process_messages (zserv.c:523)
==1595641== by 0x498F4CC: thread_call (thread.c:2002)
==1595641== by 0x49253A2: frr_run (libfrr.c:1198)
==1595641== by 0x1A28BA: main (main.c:475)
==1595641==
==1595641== 1,400 (400 direct, 1,000 indirect) bytes in 5 blocks are definitely lost in loss record 35 of 38
==1595641== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1595641== by 0x493C89C: qcalloc (memory.c:116)
==1595641== by 0x1E8426: lsp_alloc (zebra_mpls.c:1116)
==1595641== by 0x49147F1: hash_get (hash.c:162)
==1595641== by 0x1EBD7C: mpls_zapi_labels_process (zebra_mpls.c:2915)
==1595641== by 0x1C35D9: zread_mpls_labels_add (zapi_msg.c:2513)
==1595641== by 0x1C6F11: zserv_handle_commands (zapi_msg.c:3863)
==1595641== by 0x24D0F4: zserv_process_messages (zserv.c:523)
==1595641== by 0x498F4CC: thread_call (thread.c:2002)
==1595641== by 0x49253A2: frr_run (libfrr.c:1198)
==1595641== by 0x1A28BA: main (main.c:475)
bgpd: Add constants for some repetitive CLI strings
"Address Family\n"
"Address Family modifier\n"
Before:
```
donatas-laptop(config-router)# address-family ipv4
<cr>
flowspec Address Family Modifier
labeled-unicast Address Family modifier
multicast Address Family modifier
unicast Address Family Modifier
vpn Address Family modifier
```
After:
```
donatas-laptop(config-router)# address-family
ipv4 Address Family
ipv6 Address Family
l2vpn Address Family
donatas-laptop(config-router)# address-family ipv4
<cr>
flowspec Address Family modifier
labeled-unicast Address Family modifier
multicast Address Family modifier
unicast Address Family modifier
vpn Address Family modifier
```
ldpd: Check if the thread is scheduled before calling for remained time
LDPD crashes when hold time is configured to 65535:
(gdb) bt
0 0x00007f8c3fc224bb in raise () from /lib64/libpthread.so.0
1 0x00007f8c4138a3dd in core_handler () from /lib64/libfrr.so.0
2 <signal handler called>
3 0x00007f8c3fc1ccc0 in pthread_mutex_lock () from /lib64/libpthread.so.0
4 0x00007f8c4139914b in thread_timer_remain_msec () from /lib64/libfrr.so.0
5 0x00007f8c41399209 in thread_timer_remain_second () from /lib64/libfrr.so.0
6 0x000000000040eb19 in adj_to_ctl ()
7 0x0000000000427b38 in ldpe_nbr_ctl ()
8 0x000000000042fd68 in control_dispatch_imsg ()
9 0x00007f8c4139a628 in thread_call () from /lib64/libfrr.so.0
10 0x00000000004265fc in ldpe ()
11 0x000000000040a68f in main ()
==395247== 8,268 (32 direct, 8,236 indirect) bytes in 1 blocks are definitely lost in loss record 199 of 205
==395247== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==395247== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x1FBF63: community_intern (in /usr/lib/frr/bgpd)
==395247== by 0x1FC0C5: community_parse (in /usr/lib/frr/bgpd)
==395247== by 0x1F0B66: bgp_attr_community (in /usr/lib/frr/bgpd)
==395247== by 0x1F4185: bgp_attr_parse (in /usr/lib/frr/bgpd)
==395247== by 0x26BC29: bgp_update_receive (in /usr/lib/frr/bgpd)
==395247== by 0x26E887: bgp_process_packet (in /usr/lib/frr/bgpd)
==395247== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
==361630== 24,780 (96 direct, 24,684 indirect) bytes in 3 blocks are definitely lost in loss record 94 of 97
==361630== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==361630== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1FD3CC: bgp_ca_alias_insert (in /usr/lib/frr/bgpd)
==361630== by 0x2CF8E5: bgp_community_alias_magic (in /usr/lib/frr/bgpd)
==361630== by 0x2C980B: bgp_community_alias (in /usr/lib/frr/bgpd)
==361630== by 0x48E3556: cmd_execute_command_real (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E384B: cmd_execute_command_strict (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3D41: command_config_read_one_line (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3EBA: config_from_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x499065C: vty_read_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4990FF4: vty_read_config (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491CB95: frr_config_read_in (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
==361630==
==361630== 24,780 (96 direct, 24,684 indirect) bytes in 3 blocks are definitely lost in loss record 95 of 97
==361630== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==361630== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1FD39C: bgp_ca_community_insert (in /usr/lib/frr/bgpd)
==361630== by 0x2CF8F4: bgp_community_alias_magic (in /usr/lib/frr/bgpd)
==361630== by 0x2C980B: bgp_community_alias (in /usr/lib/frr/bgpd)
==361630== by 0x48E3556: cmd_execute_command_real (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E384B: cmd_execute_command_strict (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3D41: command_config_read_one_line (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3EBA: config_from_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x499065C: vty_read_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4990FF4: vty_read_config (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491CB95: frr_config_read_in (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
projects / mirror_frr.git / log