On Sun, Aug 11, 2019 at 12:30 PM Darrell Ball <dlu...@gmail.com> wrote: > > I did some further testing and ran into another issue; in this case, one, I > did not expect. > > I added an additional sending of packets at the end of the test after this > check: > > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl > ]) > > Below is new code > > dnl Do it again > dnl Send ICMP and UDP traffic > NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.2 | FORMAT_PING], > [0], [dnl > 3 packets transmitted, 3 received, 0% packet loss, time 0ms > ]) > AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 "in_port=1 > packet=50540000000a50540000000908004500001c000000000011a4cd0a0101010a0101020001000200080000 > actions=resubmit(,0)"]) > > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | sort], [0], > [dnl > icmp,orig=(src=10.1.1.1,dst=10.1.1.2,id=<cleared>,type=8,code=0),reply=(src=10.1.1.2,dst=10.1.1.1,id=<cleared>,type=0,code=0),zone=5 > udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=<cleared>,dport=<cleared>),reply=(src=10.1.1.2,dst=10.1.1.1,sport=<cleared>,dport=<cleared>),zone=5 > ]) > > dnl Wait until the timeout expire. > dnl We intend to wait a bit longer, because conntrack does not recycle the > entry right after it is expired. > sleep 5 > > AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl > ]) > > The test fails bcoz the second time with short timeouts, the conntrack > entries are not cleanup up quickly > > @@ -0,0 +1,2 @@ > +icmp,orig=(src=10.1.1.1,dst=10.1.1.2,id=<cleared>,type=8,code=0),reply=(src=10.1.1.2,dst=10.1.1.1,id=<cleared>,type=0,code=0),zone=5 > +udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=<cleared>,dport=<cleared>),reply=(src=10.1.1.2,dst=10.1.1.1,sport=<cleared>,dport=<cleared>),zone=5 > > > > On Tue, Aug 6, 2019 at 12:16 PM Darrell Ball <dlu...@gmail.com> wrote: >> >> >> >> On Tue, Aug 6, 2019 at 11:07 AM Yi-Hung Wei <yihung....@gmail.com> wrote: >>> >>> On Tue, Aug 6, 2019 at 10:21 AM Darrell Ball <dlu...@gmail.com> wrote: >>> > >>> > >>> > I did some more testing and found a similar problem as in V1. >>> > >>> > This test can be run successfully once and then fails after that. >>> > Maybe you want to look into that. It is probably related to: >>> > >>> > dball@ubuntu:~/openvswitch/ovs$ lsmod | grep nf >>> > . >>> > nfnetlink_cttimeout 16384 1 >>> > . >>> > >>> > Darrell >>> > >>> >>> Thanks for trying out the test. I can not reproduce the issue that >>> you mentioned on my local VM. >>> >>> Can you provide your kernel version and system-kmod-testsuite.log? >>> >>> Thanks, >>> >>> -Yi-Hung >> >> >> >> Here it is: >> >> dball@ubuntu:~/ovs$ uname -a >> Linux ubuntu 4.4.0-119-generic #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018 >> x86_64 x86_64 x86_64 GNU/Linux >> Thanks for reporting the issue. I am able to reproduce in similar set up. It should be resolved in v3.
Thanks, -Yi-Hung _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
