Frode Nordahl <fnord...@ubuntu.com> writes: > The "ping6 between two ports with header modify" test currently > fails 1 in 25 times on an idle system, and apparently 100% of the > time on a more busy system. > > The failure appears to be caused by the very first packet to a > new destination being dropped. > > Log excerpt: > ping6 -q -c 3 -i 0.3 -W 2 fc00::3 \ > | grep "transmitted" | sed 's/time.*ms$/time 0ms/' > -3 packets transmitted, 3 received, 0% packet loss, time 0ms > +3 packets transmitted, 2 received, 33.3333% packet loss, time 0ms > > The test already primes the neighbour table by waiting for the > first ping to two of the destinations used in the test. > > This patch adds the same wait condition for the third destination > used in the test. > > Having run the test in an endless successful loop for a while > makes it highly probable to have fixed the issue. > > Reported-at: https://launchpad.net/bugs/2077157 > Signed-off-by: Frode Nordahl <fnord...@ubuntu.com> > ---
Hi Frode, Flakiness with ipv6 tests in some cases may depend on dad ([0] summarizes what I found out back then). A while ago I observed a similar problem [1]. I recall that in my local tests where I was able to reproduce the issue I dropped the wait on ping6 as well confirming that nodad alone fixed the issue. For this specific case, I was able to reproduce the issue on a busy system, and it seems that nodad solves the issue (I applied the small diff below) and without requiring the wait-until-ping6. In general the OVS_WAIT_UNIL([... ping6 ...]) might not be needed in any of our tests (whereas nodad is), but of course that would require more tests to confirm it's enough for older kernels as well. Given the above, keeping the wait-until logic, it should be enough to move the first ping6 after adding the flows and turning the dst addr from fc00::2 to fc00::3, but probably keeping three pings is easier to read, so, if you decide to go with this, the patch LGTM. Paolo [0] https://mail.openvswitch.org/pipermail/ovs-dev/2022-January/391115.html [1] https://github.com/openvswitch/ovs/commit/989895501c53468569064e060f15bba3fc8f0cac --- diff --git a/tests/system-traffic.at b/tests/system-traffic.at index 202ff0492..e69926593 100644 --- a/tests/system-traffic.at +++ b/tests/system-traffic.at @@ -234,15 +234,9 @@ AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"]) ADD_NAMESPACES(at_ns0, at_ns1) -ADD_VETH(p0, at_ns0, br0, "fc00::1/96", e4:11:22:33:44:55) -ADD_VETH(p1, at_ns1, br0, "fc00::2/96", e4:11:22:33:44:54) -NS_CHECK_EXEC([at_ns0], [ip -6 neigh add fc00::3 lladdr e4:11:22:33:44:54 dev p0]) - -dnl Linux seems to take a little time to get its IPv6 stack in order. Without -dnl waiting, we get occasional failures due to the following error: -dnl "connect: Cannot assign requested address" -OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) -OVS_WAIT_UNTIL([ip netns exec at_ns1 ping6 -c 1 fc00::1]) +ADD_VETH(p0, at_ns0, br0, "fc00::1/96", e4:11:22:33:44:55, [], nodad) +ADD_VETH(p1, at_ns1, br0, "fc00::2/96", e4:11:22:33:44:54, [], nodad) +NS_CHECK_EXEC([at_ns0], [ip -6 neigh add fc00::3 lladdr e4:11:22:33:44:54 nud perm dev p0]) AT_DATA([flows.txt], [dnl priority=100,in_port=ovs-p0,ipv6,ipv6_src=fc00::1,ipv6_dst=fc00::3,actions=set_field:fc00::2->ipv6_dst,ovs-p1 > tests/system-traffic.at | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/system-traffic.at b/tests/system-traffic.at > index 202ff0492..bb52d2cfb 100644 > --- a/tests/system-traffic.at > +++ b/tests/system-traffic.at > @@ -253,6 +253,8 @@ priority=0,actions=NORMAL > AT_CHECK([ovs-ofctl del-flows br0]) > AT_CHECK([ovs-ofctl add-flows br0 flows.txt]) > > +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::3]) > + > NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -W 2 fc00::3 | FORMAT_PING], > [0], [dnl > 3 packets transmitted, 3 received, 0% packet loss, time 0ms > ]) > -- > 2.45.2 > > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
