From: Hajime Tazaki <tazaki@sfc.wide.ad.jp>
To: kafai@fb.com
Cc: netdev@vger.kernel.org, hannes@stressinduktion.org,
steffen.klassert@secunet.com, davem@davemloft.net,
yangyingliang@huawei.com, shengyong1@huawei.com,
Kernel-team@fb.com
Subject: Re: [PATCH net-next 3/5] ipv6: Stop /128 route from disappearing after pmtu update
Date: Sun, 03 May 2015 09:19:47 +0900 [thread overview]
Message-ID: <m2bni2tsv0.wl@sfc.wide.ad.jp> (raw)
In-Reply-To: <20150502232040.GB2731450@devbig242.prn2.facebook.com>
Hello Martin,
thank you for your quick reply.
At Sat, 2 May 2015 16:20:40 -0700,
Martin KaFai Lau wrote:
> > - how to reproduce it
> >
> > the test is simply sending an IPv6 packet to a node on the
> > same subnet to verify the connectivity (e.g., ping6
> > 2001:1::2 from 2001:1::1) and echo packets didn't get back.
> >
> > reverting this commit fixes the issue.
> >
> > please take a look at it: I'm glad to know if this only
> > happens in my local environment.
> Thanks for reporting.
>
> I cannot reproduce in my environment.
(snip)
> 15:58:34.658150 6a:aa:e6:a1:ce:f9 > 52:54:00:12:34:56, ethertype IPv6 (0x86dd), length 118: 2001:1::2 > 2001:1::1: ICMP6, echo request, seq 5, length 64
> 15:58:34.658275 52:54:00:12:34:56 > 6a:aa:e6:a1:ce:f9, ethertype IPv6 (0x86dd), length 118: 2001:1::1 > 2001:1::2: ICMP6, echo reply, seq 5, length 64
>
> I suspect there is a RTF_LOCAL route getting a ICMPv6 too-big packet.
>
> Can you provide a tcpdump at both ends? Also, the output of
> the 'ip -6 a' and 'ip -6 r show'.
- tcpdump -vvv
09:00:00.200000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:1 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
source link-address option (1), length 8 (1): 00:00:00:00:00:01
0x0000: 0000 0000 0001
09:00:00.401092 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:2 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
source link-address option (1), length 8 (1): 00:00:00:00:00:02
0x0000: 0000 0000 0002
09:00:01.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 1
09:00:02.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 2
09:00:03.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 3
09:00:04.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 4
09:00:04.200000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:1 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
source link-address option (1), length 8 (1): 00:00:00:00:00:01
0x0000: 0000 0000 0001
09:00:04.401092 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:2 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
source link-address option (1), length 8 (1): 00:00:00:00:00:02 0x0000: 0000 0000 0002
(snip)
- 'ip -6 a' at the ping6 sender
7: sim0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:1::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::200:ff:fe00:1/64 scope link
valid_lft forever preferred_lft forever
- 'ip -6 r show' at the ping6 sender
2001:1::/64 dev sim0 proto kernel metric 256
fe80::/64 dev sim0 proto kernel metric 256
# the results of ip command on receiver side are almost
similar.
I found that the test uses non-ARP interface between nodes:
if I changed the interface to 'non-NOARP' NIC, the issue has
gone away without the revert.
I'm using the following scenario: just FYI.
https://gist.github.com/thehajime/26be8606ddbb924f357c
> Also, can you try the following change which is a partial revert. If ping goes
> through again, can you capture the 'ip -6 show' on both sides quickly after the
> test.
>
> Thanks,
> --Martin
>
> diff --git i/net/ipv6/route.c w/net/ipv6/route.c
> index 3522711..60212d4 100644
> --- i/net/ipv6/route.c
> +++ w/net/ipv6/route.c
> @@ -1124,7 +1124,7 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
> struct rt6_info *rt6 = (struct rt6_info *)dst;
>
> dst_confirm(dst);
> - if (mtu < dst_mtu(dst) && (rt6->rt6i_flags & RTF_CACHE)) {
> + if (mtu < dst_mtu(dst) && rt6->rt6i_dst.plen == 128) {
> struct net *net = dev_net(dst->dev);
>
> rt6->rt6i_flags |= RTF_MODIFIED;
this partial revert didn't change my situation.
-- Hajime
next prev parent reply other threads:[~2015-05-03 0:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 20:03 [PATCH net-next 0/5] ipv6: Stop /128 route from disappearing after pmtu update Martin KaFai Lau
2015-04-28 20:03 ` [PATCH net-next 1/5] ipv6: Consider RTF_CACHE when searching the fib6 tree Martin KaFai Lau
2015-04-28 20:03 ` [PATCH net-next 2/5] ipv6: Extend the route lookups to low priority metrics Martin KaFai Lau
2015-04-28 20:03 ` [PATCH net-next 3/5] ipv6: Stop /128 route from disappearing after pmtu update Martin KaFai Lau
2015-05-02 22:41 ` Hajime Tazaki
2015-05-02 23:20 ` Martin KaFai Lau
2015-05-03 0:19 ` Hajime Tazaki [this message]
2015-05-03 1:00 ` Martin KaFai Lau
2015-05-03 1:03 ` Martin KaFai Lau
2015-05-03 14:26 ` Hajime Tazaki
2015-05-03 3:38 ` Martin KaFai Lau
2015-05-03 14:29 ` Hajime Tazaki
2015-05-03 19:01 ` Martin KaFai Lau
2015-05-04 0:29 ` Martin KaFai Lau
2015-05-04 1:11 ` Hajime Tazaki
2015-04-28 20:03 ` [PATCH net-next 4/5] ipv6: Stop rt6_info from using inet_peer's metrics Martin KaFai Lau
2015-04-28 20:03 ` [PATCH net-next 5/5] ipv6: Remove DST_METRICS_FORCE_OVERWRITE and _rt6i_peer Martin KaFai Lau
2015-05-02 1:01 ` [PATCH net-next 0/5] ipv6: Stop /128 route from disappearing after pmtu update David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2bni2tsv0.wl@sfc.wide.ad.jp \
--to=tazaki@sfc.wide.ad.jp \
--cc=Kernel-team@fb.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=shengyong1@huawei.com \
--cc=steffen.klassert@secunet.com \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).