* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-08-26 5:26 suy.fnst
2021-08-26 9:36 ` Alexey Kodanev
0 siblings, 1 reply; 12+ messages in thread
From: suy.fnst @ 2021-08-26 5:26 UTC (permalink / raw)
To: ltp
While running mpls02.sh -6 in our slow test box with kernel
version > v5.11, we found the test hangs at ping6 occasionally:
+ grep -q 'invalid option'
+ for size in ${msg_sizes:-"56"}
+ EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1
'>/dev/null'
+ _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f
fd00:23::1 '>/dev/null'
+ local fnc=tst_res
+ shift
+ tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null'
The weird part is that manual ping6 works in the meantime.
Then we found that adding `sleep 1` at end of mpls02.sh/setup() make
the test pass in 100%. Dig depper in the problem, ftrace catched during
the 1 second shows (The test started at [ 3979.485488]):
3981.210701 | 2) kworker-24742 | | addrconf_dad_work() {
3981.210712 | 2) kworker-24742 | | addrconf_dad_completed() {
3981.210712 | 2) kworker-24742 | 0.417 us | addrconf_del_dad_work();
3981.210713 | 2) kworker-24742 | | __ipv6_ifa_notify() {
3981.210716 | 2) kworker-24742 | 1.097 us | inet6_fill_ifaddr();
3981.210730 | 2) kworker-24742 | | ip6_ins_rt() {
3981.210731 | 2) kworker-24742 | | fib6_add() {
In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do
route related jobs in a delayed workqueue . Hence, there is tiny period
we need to wait for it. Adding the `sleep 1` seems suffcient for now.
Signed-off-by: Su Yue <suy.fnst@fujitsu.com>
---
testcases/network/mpls/mpls02.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh
index 2fd3ec5bf4ba..75f5fca32f9a 100755
--- a/testcases/network/mpls/mpls02.sh
+++ b/testcases/network/mpls/mpls02.sh
@@ -35,6 +35,8 @@ setup()
tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo"
tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)"
tst_rhost_run -s -c "ip -f mpls route add 50 dev lo"
+
+ sleep 1
}
do_test()
--
2.30.1 (Apple Git-130)
^ permalink raw reply related [flat|nested] 12+ messages in thread* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 2021-08-26 5:26 [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 suy.fnst @ 2021-08-26 9:36 ` Alexey Kodanev 2021-08-30 6:46 ` suy.fnst 2021-08-30 9:26 ` suy.fnst 0 siblings, 2 replies; 12+ messages in thread From: Alexey Kodanev @ 2021-08-26 9:36 UTC (permalink / raw) To: ltp On 26.08.2021 08:26, suy.fnst@fujitsu.com wrote: > While running mpls02.sh -6 in our slow test box with kernel > version > v5.11, we found the test hangs at ping6 occasionally: > > + grep -q 'invalid option' > + for size in ${msg_sizes:-"56"} > + EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 > '>/dev/null' > + _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f > fd00:23::1 '>/dev/null' > + local fnc=tst_res > + shift > + tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null' > > The weird part is that manual ping6 works in the meantime. > > Then we found that adding `sleep 1` at end of mpls02.sh/setup() make > the test pass in 100%. Dig depper in the problem, ftrace catched during > the 1 second shows (The test started at [ 3979.485488]): > > 3981.210701 | 2) kworker-24742 | | addrconf_dad_work() { > 3981.210712 | 2) kworker-24742 | | addrconf_dad_completed() { > 3981.210712 | 2) kworker-24742 | 0.417 us | addrconf_del_dad_work(); > 3981.210713 | 2) kworker-24742 | | __ipv6_ifa_notify() { > 3981.210716 | 2) kworker-24742 | 1.097 us | inet6_fill_ifaddr(); > 3981.210730 | 2) kworker-24742 | | ip6_ins_rt() { > 3981.210731 | 2) kworker-24742 | | fib6_add() { > > In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do > route related jobs in a delayed workqueue . Hence, there is tiny period > we need to wait for it. Adding the `sleep 1` seems suffcient for now. What is happening in the ping6, it is OK for it to hang on this? Adding nodad to loopback might only change the flags (remove tentative if ifa_flags==IFA_F_NODAD), the delayed dad work should be completed in addrconf_dad_begin() for it anyway... but will it make any difference for ping6 to change the test as below? ip addr add $ip_loc/$mask dev lo nodad tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo nodad" > Signed-off-by: Su Yue <suy.fnst@fujitsu.com> > --- > testcases/network/mpls/mpls02.sh | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh > index 2fd3ec5bf4ba..75f5fca32f9a 100755 > --- a/testcases/network/mpls/mpls02.sh > +++ b/testcases/network/mpls/mpls02.sh > @@ -35,6 +35,8 @@ setup() > tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo" > tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)" > tst_rhost_run -s -c "ip -f mpls route add 50 dev lo" > + > + sleep 1 > } > > do_test() > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 2021-08-26 9:36 ` Alexey Kodanev @ 2021-08-30 6:46 ` suy.fnst 2021-08-30 9:26 ` suy.fnst 1 sibling, 0 replies; 12+ messages in thread From: suy.fnst @ 2021-08-30 6:46 UTC (permalink / raw) To: ltp Hi, Alexey Sorry for late reply and the bad email format. And thanks a lot for your suggestion! It inspire me to find the cause. I'll explain it in V2. -- Su ________________________________________ From: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Sent: Thursday, August 26, 2021 17:36 To: Su, Yue/? ?; ltp@lists.linux.it Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 On 26.08.2021 08:26, suy.fnst@fujitsu.com wrote: > While running mpls02.sh -6 in our slow test box with kernel > version > v5.11, we found the test hangs at ping6 occasionally: > > + grep -q 'invalid option' > + for size in ${msg_sizes:-"56"} > + EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 > '>/dev/null' > + _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f > fd00:23::1 '>/dev/null' > + local fnc=tst_res > + shift > + tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null' > > The weird part is that manual ping6 works in the meantime. > > Then we found that adding `sleep 1` at end of mpls02.sh/setup() make > the test pass in 100%. Dig depper in the problem, ftrace catched during > the 1 second shows (The test started at [ 3979.485488]): > > 3981.210701 | 2) kworker-24742 | | addrconf_dad_work() { > 3981.210712 | 2) kworker-24742 | | addrconf_dad_completed() { > 3981.210712 | 2) kworker-24742 | 0.417 us | addrconf_del_dad_work(); > 3981.210713 | 2) kworker-24742 | | __ipv6_ifa_notify() { > 3981.210716 | 2) kworker-24742 | 1.097 us | inet6_fill_ifaddr(); > 3981.210730 | 2) kworker-24742 | | ip6_ins_rt() { > 3981.210731 | 2) kworker-24742 | | fib6_add() { > > In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do > route related jobs in a delayed workqueue . Hence, there is tiny period > we need to wait for it. Adding the `sleep 1` seems suffcient for now. What is happening in the ping6, it is OK for it to hang on this? Adding nodad to loopback might only change the flags (remove tentative if ifa_flags==IFA_F_NODAD), the delayed dad work should be completed in addrconf_dad_begin() for it anyway... but will it make any difference for ping6 to change the test as below? ip addr add $ip_loc/$mask dev lo nodad tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo nodad" > Signed-off-by: Su Yue <suy.fnst@fujitsu.com> > --- > testcases/network/mpls/mpls02.sh | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh > index 2fd3ec5bf4ba..75f5fca32f9a 100755 > --- a/testcases/network/mpls/mpls02.sh > +++ b/testcases/network/mpls/mpls02.sh > @@ -35,6 +35,8 @@ setup() > tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo" > tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)" > tst_rhost_run -s -c "ip -f mpls route add 50 dev lo" > + > + sleep 1 > } > > do_test() > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 2021-08-26 9:36 ` Alexey Kodanev 2021-08-30 6:46 ` suy.fnst @ 2021-08-30 9:26 ` suy.fnst 2021-09-09 15:53 ` pvorel 1 sibling, 1 reply; 12+ messages in thread From: suy.fnst @ 2021-08-30 9:26 UTC (permalink / raw) To: ltp 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.. Thanks! -- Su ________________________________________ From: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Sent: Thursday, August 26, 2021 17:36 To: Su, Yue/? ?; ltp@lists.linux.it Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 On 26.08.2021 08:26, suy.fnst@fujitsu.com wrote: > While running mpls02.sh -6 in our slow test box with kernel > version > v5.11, we found the test hangs at ping6 occasionally: > > + grep -q 'invalid option' > + for size in ${msg_sizes:-"56"} > + EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 > '>/dev/null' > + _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f > fd00:23::1 '>/dev/null' > + local fnc=tst_res > + shift > + tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null' > > The weird part is that manual ping6 works in the meantime. > > Then we found that adding `sleep 1` at end of mpls02.sh/setup() make > the test pass in 100%. Dig depper in the problem, ftrace catched during > the 1 second shows (The test started at [ 3979.485488]): > > 3981.210701 | 2) kworker-24742 | | addrconf_dad_work() { > 3981.210712 | 2) kworker-24742 | | addrconf_dad_completed() { > 3981.210712 | 2) kworker-24742 | 0.417 us | addrconf_del_dad_work(); > 3981.210713 | 2) kworker-24742 | | __ipv6_ifa_notify() { > 3981.210716 | 2) kworker-24742 | 1.097 us | inet6_fill_ifaddr(); > 3981.210730 | 2) kworker-24742 | | ip6_ins_rt() { > 3981.210731 | 2) kworker-24742 | | fib6_add() { > > In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do > route related jobs in a delayed workqueue . Hence, there is tiny period > we need to wait for it. Adding the `sleep 1` seems suffcient for now. What is happening in the ping6, it is OK for it to hang on this? Adding nodad to loopback might only change the flags (remove tentative if ifa_flags==IFA_F_NODAD), the delayed dad work should be completed in addrconf_dad_begin() for it anyway... but will it make any difference for ping6 to change the test as below? ip addr add $ip_loc/$mask dev lo nodad tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo nodad" > Signed-off-by: Su Yue <suy.fnst@fujitsu.com> > --- > testcases/network/mpls/mpls02.sh | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh > index 2fd3ec5bf4ba..75f5fca32f9a 100755 > --- a/testcases/network/mpls/mpls02.sh > +++ b/testcases/network/mpls/mpls02.sh > @@ -35,6 +35,8 @@ setup() > tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo" > tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)" > tst_rhost_run -s -c "ip -f mpls route add 50 dev lo" > + > + sleep 1 > } > > do_test() > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-09 15:53 ` pvorel 2021-09-10 8:39 ` Alexey Kodanev 0 siblings, 1 reply; 12+ messages in thread From: pvorel @ 2021-09-09 15:53 UTC (permalink / raw) To: suy.fnst; +Cc: ltp 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.. I wonder if test still needs be fixed to work on all setups. Petr > > Thanks! > -- > Su -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-09 15:53 ` pvorel 2021-09-10 8:39 ` Alexey Kodanev 0 siblings, 1 reply; 12+ messages in thread From: pvorel @ 2021-09-09 15:53 UTC (permalink / raw) To: suy.fnst; +Cc: ltp 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.. I wonder if test still needs be fixed to work on all setups. Petr > > Thanks! > -- > Su -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-10 8:39 ` Alexey Kodanev 2021-09-10 9:36 ` Petr Vorel 2021-09-12 3:45 ` suy.fnst 0 siblings, 2 replies; 12+ messages in thread From: Alexey Kodanev @ 2021-09-10 8:39 UTC (permalink / raw) To: pvorel, suy.fnst; +Cc: ltp 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... 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(). -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-10 8:39 ` Alexey Kodanev 2021-09-10 9:36 ` Petr Vorel 2021-09-12 3:45 ` suy.fnst 0 siblings, 2 replies; 12+ messages in thread From: Alexey Kodanev @ 2021-09-10 8:39 UTC (permalink / raw) To: pvorel, suy.fnst; +Cc: ltp 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... 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(). -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-10 9:36 ` Petr Vorel 2021-09-13 11:14 ` Alexey Kodanev 0 siblings, 1 reply; 12+ messages in thread From: Petr Vorel @ 2021-09-10 9:36 UTC (permalink / raw) To: Alexey Kodanev; +Cc: pvorel, suy.fnst, ltp > 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? > 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. Kind regards, Petr -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-10 9:36 ` Petr Vorel 2021-09-13 11:14 ` Alexey Kodanev 0 siblings, 1 reply; 12+ messages in thread From: Petr Vorel @ 2021-09-10 9:36 UTC (permalink / raw) To: Alexey Kodanev; +Cc: pvorel, suy.fnst, ltp > 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? > 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. Kind regards, Petr -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 11:14 ` Alexey Kodanev 2021-09-13 12:28 ` Petr Vorel 0 siblings, 1 reply; 12+ messages in thread From: Alexey Kodanev @ 2021-09-13 11:14 UTC (permalink / raw) To: Petr Vorel; +Cc: pvorel, suy.fnst, ltp 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 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". > >> 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 -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 11:14 ` Alexey Kodanev 2021-09-13 12:28 ` Petr Vorel 0 siblings, 1 reply; 12+ messages in thread From: Alexey Kodanev @ 2021-09-13 11:14 UTC (permalink / raw) To: Petr Vorel; +Cc: pvorel, suy.fnst, ltp 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 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". > >> 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 -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 12:28 ` Petr Vorel 2021-09-13 12:38 ` Alexey Kodanev 0 siblings, 1 reply; 12+ messages in thread From: Petr Vorel @ 2021-09-13 12:28 UTC (permalink / raw) To: Alexey Kodanev; +Cc: suy.fnst, ltp > 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). 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 -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 12:28 ` Petr Vorel 2021-09-13 12:38 ` Alexey Kodanev 0 siblings, 1 reply; 12+ messages in thread From: Petr Vorel @ 2021-09-13 12:28 UTC (permalink / raw) To: Alexey Kodanev; +Cc: suy.fnst, ltp > 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). 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 -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 12:38 ` Alexey Kodanev 2021-09-13 12:55 ` Petr Vorel 0 siblings, 1 reply; 12+ messages in thread From: Alexey Kodanev @ 2021-09-13 12:38 UTC (permalink / raw) To: Petr Vorel; +Cc: suy.fnst, ltp 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. -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 12:38 ` Alexey Kodanev 2021-09-13 12:55 ` Petr Vorel 0 siblings, 1 reply; 12+ messages in thread From: Alexey Kodanev @ 2021-09-13 12:38 UTC (permalink / raw) To: Petr Vorel; +Cc: suy.fnst, ltp 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. -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 12:55 ` Petr Vorel 0 siblings, 0 replies; 12+ messages in thread From: Petr Vorel @ 2021-09-13 12:55 UTC (permalink / raw) To: Alexey Kodanev; +Cc: suy.fnst, ltp > 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 -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-13 12:55 ` Petr Vorel 0 siblings, 0 replies; 12+ messages in thread From: Petr Vorel @ 2021-09-13 12:55 UTC (permalink / raw) To: Alexey Kodanev; +Cc: suy.fnst, ltp > 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 -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-12 3:45 ` suy.fnst 0 siblings, 0 replies; 12+ messages in thread From: suy.fnst @ 2021-09-12 3:45 UTC (permalink / raw) To: Alexey Kodanev, pvorel; +Cc: ltp Hi, Alexey Thanks! It works! Could you send a patch for the fix? You can add my Tested-by: Su Yue <suy.fnst@fujitsu.com> -- Su ________________________________________ From: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Sent: Friday, September 10, 2021 16:39 To: pvorel; Su, Yue/苏 越 Cc: ltp@lists.linux.it Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 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... 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(). -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 @ 2021-09-12 3:45 ` suy.fnst 0 siblings, 0 replies; 12+ messages in thread From: suy.fnst @ 2021-09-12 3:45 UTC (permalink / raw) To: Alexey Kodanev, pvorel; +Cc: ltp Hi, Alexey Thanks! It works! Could you send a patch for the fix? You can add my Tested-by: Su Yue <suy.fnst@fujitsu.com> -- Su ________________________________________ From: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Sent: Friday, September 10, 2021 16:39 To: pvorel; Su, Yue/苏 越 Cc: ltp@lists.linux.it Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 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... 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(). -- Mailing list info: https://lists.linux.it/listinfo/ltp ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-09-13 12:56 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-26 5:26 [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 suy.fnst 2021-08-26 9:36 ` Alexey Kodanev 2021-08-30 6:46 ` suy.fnst 2021-08-30 9:26 ` suy.fnst 2021-09-09 15:53 ` pvorel 2021-09-09 15:53 ` pvorel 2021-09-10 8:39 ` Alexey Kodanev 2021-09-10 8:39 ` Alexey Kodanev 2021-09-10 9:36 ` Petr Vorel 2021-09-10 9:36 ` Petr Vorel 2021-09-13 11:14 ` Alexey Kodanev 2021-09-13 11:14 ` Alexey Kodanev 2021-09-13 12:28 ` Petr Vorel 2021-09-13 12:28 ` Petr Vorel 2021-09-13 12:38 ` Alexey Kodanev 2021-09-13 12:38 ` Alexey Kodanev 2021-09-13 12:55 ` Petr Vorel 2021-09-13 12:55 ` Petr Vorel 2021-09-12 3:45 ` suy.fnst 2021-09-12 3:45 ` suy.fnst
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.