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>
Don't auto set the thread->arg pointer. It is private
and should be only accessed through the THREAD_ARG pointer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If we have `end` at the end of the frr.conf, then we never execute
XFRR_end_configuration command, and start/end markers do not work.
This leads to for example waiting BGP configuration parsing thread to hang,
and the peers are in shutdown state until the timer expires.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
convert:
frr_with_mutex(..)
to:
frr_with_mutex (..)
To make all our code agree with what clang-format is going to produce
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The php value is defined in yang but not properly set.
Fixes: 8f6c893629 ("isisd: add segment-routing CLI commands")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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.
The bpf code is the following one:
struct sock_filter code[] = {
{ BPF_RET | BPF_K, 0, 0, 0 },
};
struct sock_fprog p = {
.len = sizeof(code)/sizeof(struct sock_filter),
.filter = code,
};
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:
ip route 2.2.2.2/32 10.126.0.2
vrf vrf2
ip route 2.2.2.2/32 10.126.0.2
!
interface ntfp2
ip address 10.126.0.1/24
!
interface ntfp3 vrf vrf4
ip address 10.126.0.1/24
!
interface ntfp2 vrf vrf1
ip address 10.126.0.1/24
!
interface ntfp2.100 vrf vrf2
ip address 10.126.0.1/24
!
interface ntfp2.200 vrf vrf3
ip address 10.126.0.1/24
!
line vty
!
bfd
peer 10.126.0.2 vrf vrf2
!
peer 10.126.0.2 vrf vrf3
!
peer 10.126.0.2
!
peer 10.126.0.2 vrf vrf4
!
peer 2.2.2.2 multihop local-address 1.1.1.1
!
peer 2.2.2.2 multihop local-address 1.1.1.1 vrf vrf2
transmit-interval 1500
receive-interval 1500
!
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>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
in agentx_events_update the timeout_thr is canceled
on line 88 just above. This already sets the pointer
to NULL. No need to do this again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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()
r1 = tgen.gears["r1"]
r1_snmp = SnmpTester(r1, "10.1.1.1", "public", "2c")
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
On line 16 of this file following sentence has a typo.
> * once done, the updated copy is swapped in in a single
Remove unused "in" from document.
Signed-off-by: alireza <alirezaarzehgar82@gmail.com>
