[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2e9e485e-c400-3463-9095-013c5ae1df85@gmail.com>
Date: Fri, 20 Dec 2019 09:14:09 -0700
From: David Ahern <dsahern@...il.com>
To: Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org
Cc: Julian Anastasov <ja@....bg>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Guillaume Nault <gnault@...hat.com>,
David Miller <davem@...emloft.net>,
Pablo Neira <pablo@...filter.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Alexey Kodanev <alexey.kodanev@...cle.com>
Subject: Re: [PATCHv4 net 0/8] disable neigh update for tunnels during pmtu
update
On 12/19/19 8:25 PM, Hangbin Liu wrote:
> When we setup a pair of gretap, ping each other and create neighbour cache.
> Then delete and recreate one side. We will never be able to ping6 to the new
> created gretap.
>
> The reason is when we ping6 remote via gretap, we will call like
>
> gre_tap_xmit()
> - ip_tunnel_xmit()
> - tnl_update_pmtu()
> - skb_dst_update_pmtu()
> - ip6_rt_update_pmtu()
> - __ip6_rt_update_pmtu()
> - dst_confirm_neigh()
> - ip6_confirm_neigh()
> - __ipv6_confirm_neigh()
> - n->confirmed = now
>
> As the confirmed time updated, in neigh_timer_handler() the check for
> NUD_DELAY confirm time will pass and the neigh state will back to
> NUD_REACHABLE. So the old/wrong mac address will be used again.
>
> If we do not update the confirmed time, the neigh state will go to
> neigh->nud_state = NUD_PROBE; then go to NUD_FAILED and re-create the
> neigh later, which is what IPv4 does.
>
> We couldn't remove the ip6_confirm_neigh() directly as we still need it
> for TCP flows. To fix it, we have to pass a bool parameter to
> dst_ops.update_pmtu() and only disable neighbor update for tunnels.
>
seems reasonable to me.
Acked-by: David Ahern <dsahern@...il.com>
Powered by blists - more mailing lists