[LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02

[Petr Vorel]

> On 13.09.2021 15:28, Petr Vorel wrote:
> >> 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: <BROADCAST,UP,LOWER_UP> 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).

> Actually, we do have -f option in tst_ping(), in $flood_opt var.
Ah, I'm blind today, thanks :). I wonder if it's really enough for mpls to just
move icmp in TST_TEST_DATA to the end (or just not being first). If it's
working, feel free to add ack from my to the commit message.

Kind regards,
Petr