From mboxrd@z Thu Jan 1 00:00:00 1970 From: Petr Vorel Date: Mon, 13 Sep 2021 14:28:49 +0200 Subject: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 In-Reply-To: <61ea98da-6746-2ad3-c2de-38e148cc9d4c@bell-sw.com> References: <410b2b2d-9633-7a57-527a-1663afe5f631@bell-sw.com> <0acf816462d49d8a6004c87e36b05d1b@suse.de> <8d93deac-eec1-5f87-57a5-c72b2f6e5973@bell-sw.com> <61ea98da-6746-2ad3-c2de-38e148cc9d4c@bell-sw.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it > Hi Petr, > On 10.09.2021 12:36, Petr Vorel wrote: > >> On 09.09.2021 18:53, pvorel wrote: > >>> Hi Su, Alexey, > >>> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote: > >>>> Hi, > >>>> ? I found that it's indeed related to ipv6 DAD as you said. > >>>> Calling > >>>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0` > >>>> or tst_wait_ipv6_dad() at end of the setup both solves the problem. > >>>> However there is one super strange part that the tentative address is > >>>> the local link adress of the ltp_ns_veth1: > >>>> 5: ltp_ns_veth1@if4: mtu 1500 qdisc noqueue > >>>> state UP group default qlen 1000 > >>>> ??? link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0 > >>>> ??? inet 10.0.0.1/24 scope global ltp_ns_veth1 > >>>> ?????? valid_lft forever preferred_lft forever > >>>> ??? inet6 fd00:1:1:1::1/64 scope global nodad > >>>> ?????? valid_lft forever preferred_lft forever > >>>> ??? inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative > >>>> <------------------- > >>>> ?????? valid_lft forever preferred_lft forever > >>>> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue.. > >> Looks like the problem here in the neighbor discovery of fd00:1:1:1::2 > >> using link-local address, and vice verse for the other side. mpls is > >> using the following route with the address: > >> fd00:23::2 encap mpls 60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium > >> so the address there should be in a reachable state... > > Thanks for info! I wonder if it's a bug in mpls or elsewhere. WDYT? > https://github.com/iputils/iputils/issues/300 Ah, thanks for pointing this. > So we should be careful with the flood option in ping, especially > if it is the first test to run after initial test interfaces setup. > For example, for mpls02, it is "icmp tcp udp". Flooding is done with -f or -i 0. IMHO we don't do that in tst_ping(), what am I missing? The bug is about flooding (-i 0) with zero packet size (-s 0, but maybe our use -s 10 would trigger the bug as well). Kind regards, Petr > >> Adding it manually in setup might fix the test as well: > >> ROD ip neigh replace $(tst_ipaddr rhost) lladdr $(tst_hwaddr rhost) dev $(tst_iface) nud reachable > >> tst_rhost_run -s -c "ip neigh replace $(tst_ipaddr) lladdr $(tst_hwaddr) dev $(tst_iface rhost) nud reachable" > >>> I wonder if test still needs be fixed to work on all setups. > >> I think we could set accept_dad to 0 in generic setup of the > >> test interfaces, in tst_net.sh/tst_init_iface(). > > Unless it's a bug we'd hide by setting it, I'd be for this general solution. > > It'd be nice to get it fixed before release. > OK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6020C433F5 for ; Mon, 13 Sep 2021 12:29:05 +0000 (UTC) Received: from picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CD96460F0F for ; Mon, 13 Sep 2021 12:29:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CD96460F0F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux.it Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id 2C4F83C913F for ; Mon, 13 Sep 2021 14:29:02 +0200 (CEST) Received: from in-7.smtp.seeweb.it (in-7.smtp.seeweb.it [IPv6:2001:4b78:1:20::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id 896B43C1DF5 for ; Mon, 13 Sep 2021 14:28:53 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by in-7.smtp.seeweb.it (Postfix) with ESMTPS id 93253200AF5 for ; Mon, 13 Sep 2021 14:28:52 +0200 (CEST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id AAF6A1FFCB; Mon, 13 Sep 2021 12:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1631536131; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ComWva9x0ZTksjLqTBiM6rhYFh9L+xiSx7yncTkT44k=; b=dBV5MS7YMsayLsdl/dzIAgriK0CIJtAi5dVMWlkrNjOtaY/hXN6kA/QI1TDp40iPQWJzfw t2tOtTuV8VAf/z+MHnqJlmH6DGqiHWTdUgVBpJ1mL0xb5f8zP1n1twk5QqhHbn+aOqtSth WfoXsOuZ6d5gzqfl0bSe/UIJHp3w9Ik= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1631536131; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ComWva9x0ZTksjLqTBiM6rhYFh9L+xiSx7yncTkT44k=; b=FDp6gLM+MOq7btqYhYzEC6Rb7eVKVQXVFAXvmEOA9kBwpwbZVewWqxWnqNtPp2cT6VrecQ Cuj3S5Q1/g1Y5PDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 72FE713AA1; Mon, 13 Sep 2021 12:28:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id KmJzGgNEP2FOHwAAMHmgww (envelope-from ); Mon, 13 Sep 2021 12:28:51 +0000 Date: Mon, 13 Sep 2021 14:28:49 +0200 From: Petr Vorel To: Alexey Kodanev Message-ID: References: <410b2b2d-9633-7a57-527a-1663afe5f631@bell-sw.com> <0acf816462d49d8a6004c87e36b05d1b@suse.de> <8d93deac-eec1-5f87-57a5-c72b2f6e5973@bell-sw.com> <61ea98da-6746-2ad3-c2de-38e148cc9d4c@bell-sw.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <61ea98da-6746-2ad3-c2de-38e148cc9d4c@bell-sw.com> X-Virus-Scanned: clamav-milter 0.102.4 at in-7.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Petr Vorel Cc: suy.fnst@fujitsu.com, ltp@lists.linux.it Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Errors-To: ltp-bounces+ltp=archiver.kernel.org@lists.linux.it Sender: "ltp" Message-ID: <20210913122849.8G0h39cRCmt2X3LLfxG_ldti6TNpv8YsbgzxKcFB3Co@z> > Hi Petr, > On 10.09.2021 12:36, Petr Vorel wrote: > >> On 09.09.2021 18:53, pvorel wrote: > >>> Hi Su, Alexey, > >>> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote: > >>>> Hi, > >>>> =A0 I found that it's indeed related to ipv6 DAD as you said. > >>>> Calling > >>>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_da= d=3D0` > >>>> or tst_wait_ipv6_dad() at end of the setup both solves the problem. > >>>> However there is one super strange part that the tentative address is > >>>> the local link adress of the ltp_ns_veth1: > >>>> 5: ltp_ns_veth1@if4: mtu 1500 qdisc noqueue > >>>> state UP group default qlen 1000 > >>>> =A0=A0=A0 link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-ne= tnsid 0 > >>>> =A0=A0=A0 inet 10.0.0.1/24 scope global ltp_ns_veth1 > >>>> =A0=A0=A0=A0=A0=A0 valid_lft forever preferred_lft forever > >>>> =A0=A0=A0 inet6 fd00:1:1:1::1/64 scope global nodad > >>>> =A0=A0=A0=A0=A0=A0 valid_lft forever preferred_lft forever > >>>> =A0=A0=A0 inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative > >>>> <------------------- > >>>> =A0=A0=A0=A0=A0=A0 valid_lft forever preferred_lft forever > >>>> However, there is no place using the address in mpls02 test.>> It ma= kes me wonder how could it be possible to trigger the issue.. > >> Looks like the problem here in the neighbor discovery of fd00:1:1:1::2 > >> using link-local address, and vice verse for the other side. mpls is > >> using the following route with the address: > >> fd00:23::2 encap mpls 60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1= 024 pref medium > >> so the address there should be in a reachable state... > > Thanks for info! I wonder if it's a bug in mpls or elsewhere. WDYT? > https://github.com/iputils/iputils/issues/300 Ah, thanks for pointing this. > So we should be careful with the flood option in ping, especially > if it is the first test to run after initial test interfaces setup. > For example, for mpls02, it is "icmp tcp udp". Flooding is done with -f or -i 0. IMHO we don't do that in tst_ping(), what am I missing? The bug is about flooding (-i 0) with zero packet size (= -s 0, but maybe our use -s 10 would trigger the bug as well). Kind regards, Petr > >> Adding it manually in setup might fix the test as well: > >> ROD ip neigh replace $(tst_ipaddr rhost) lladdr $(tst_hwaddr rhost) de= v $(tst_iface) nud reachable > >> tst_rhost_run -s -c "ip neigh replace $(tst_ipaddr) lladdr $(tst_hwadd= r) dev $(tst_iface rhost) nud reachable" > >>> I wonder if test still needs be fixed to work on all setups. > >> I think we could set accept_dad to 0 in generic setup of the > >> test interfaces, in tst_net.sh/tst_init_iface(). > > Unless it's a bug we'd hide by setting it, I'd be for this general solu= tion. > > It'd be nice to get it fixed before release. > OK -- = Mailing list info: https://lists.linux.it/listinfo/ltp