Ilya Maximets <[email protected]> writes: > On 8/5/22 20:32, Aaron Conole wrote: >> Ilya Maximets <[email protected]> writes: >> >>> The permanent neighbor entry for fc00::1 is added into a wrong >>> namespace, so in order to reply to a ping from at_ns1, the >>> address of fc00::1 has to be discovered. >> >> This is strange - how did it end up in wrong namespace? Is it a race >> with the veth setup? I guess we could possibly fix that? > > We have: > NS_CHECK_EXEC([at_ns0], [ip -6 neigh add fc00::1 lladdr e4:11:22:33:44:55 dev > p0]) > > But it should be: > NS_CHECK_EXEC([at_ns1], [ip -6 neigh add fc00::1 lladdr e4:11:22:33:44:55 dev > p1]) > > because fc00::1 is an IP of p0 in at_ns0. There is no point adding the > entry to the namespace where it is directly accessible.
Ugh, I glanced at the NS setup block too quickly and missed that. > We could just fix that, but I re-worked the test a little bit instead. Makes sense to me. Acked-by: Aaron Conole <[email protected]> >> >> Also, there are some other conntrack tests that seem to have a similar >> if/address setup pattern, allowing ND in only one direction - have we >> seen them fail as well? >> >>> Interfaces are attached >>> to OVS and we're removing flows that can forward ND requests >>> after initial setup. In case ND request wasn't sent and replied >>> before that, at_ns1 will not be able to discover fc00:1 and won't >>> reply to pings. >>> >>> It's hard to catch this condition while running tests locally, >>> but for some reason our CI is failing consistently. >>> >>> Fix the issue by removing all the unnecessary permanent entries >>> and just allowing all the normal traffic to flow through the >>> low priority OVS flow, so all addresses can be discovered. >>> >>> Also adding one more wait to avoid occasional drops of the very >>> first packet. >>> >>> Fixes: 2ff43c78c685 ("packets: Re-calculate IPv6 checksum only for first >>> frag upon modify.") >>> Signed-off-by: Ilya Maximets <[email protected]> >>> --- >>> tests/system-traffic.at | 14 +++++++++----- >>> 1 file changed, 9 insertions(+), 5 deletions(-) >>> >>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at >>> index 53ae80f4e..33108c5ab 100644 >>> --- a/tests/system-traffic.at >>> +++ b/tests/system-traffic.at >>> @@ -237,17 +237,21 @@ 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]) >>> -NS_CHECK_EXEC([at_ns0], [ip -6 neigh add fc00::2 lladdr e4:11:22:33:44:54 >>> dev p0]) >>> -NS_CHECK_EXEC([at_ns0], [ip -6 neigh add fc00::1 lladdr e4:11:22:33:44:55 >>> 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]) >>> >>> -AT_CHECK([ovs-ofctl del-flows -OOpenFlow15 br0]) >>> -AT_CHECK([ovs-ofctl add-flow -OOpenFlow15 br0 >>> in_port=ovs-p0,ipv6,ipv6_dst=fc00::3,ipv6_src=fc00::1,actions=set_field:fc00::2-\>ipv6_dst,ovs-p1]) >>> -AT_CHECK([ovs-ofctl add-flow -OOpenFlow15 br0 >>> in_port=ovs-p1,ipv6,ipv6_dst=fc00::1,ipv6_src=fc00::2,actions=set_field:fc00::3-\>ipv6_src,ovs-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 >>> +priority=100,in_port=ovs-p1,ipv6,ipv6_src=fc00::2,ipv6_dst=fc00::1,actions=set_field:fc00::3->ipv6_src,ovs-p0 >>> +priority=0,actions=NORMAL >>> +]) >>> + >>> +AT_CHECK([ovs-ofctl del-flows br0]) >>> +AT_CHECK([ovs-ofctl add-flows br0 flows.txt]) >>> >>> 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 [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
