On 8/16/24 20:43, Frode Nordahl wrote: > 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.
Hmm. I'm not sure this analysis is correct. The fc00::3 address in the test is fully virtual, so it doesn't depend on the kernel networking stack or anything like that. As Paolo pointed out in his reply, we do wait for IP addresses on kernel interfaces mostly because of DAD. However, there should be no DAD for fc00::3 as it is not assigned to any interface. And we're pre-populating the neighbor cache manually for this address as well. So, the ping should actually always come through on a first attempt. The issue with this test might be with the revalidation cycle. We first send a few packets with action NORMAL that installs a few datapath flows that match on MAC addresses only. Then we change OpenFlow rules to match on IPs, but we're not waiting for datapath flows to be updated. The ping may still be hitting the previous datapath flow and being forwarded without the address modification. So, my guess is that we should add a revalidator/wait call instead. We do so in a few other tests that change OF rules. This way old datapath flows will be removed and the first ping packet should hit the new OpenFlow rules with the header modification. Could you try that in your setup? Best regards, Ilya Maximets. > > 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> > --- > 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 > ]) _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
