Message ID | 20191222025116.2897-1-liuhangbin@gmail.com |
---|---|
Headers | show |
Series | disable neigh update for tunnels during pmtu update | expand |
On Sun, Dec 22, 2019 at 10:51:08AM +0800, 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. > No more objection from me (and you already have my Reviewed-by tag). Thanks for your work Hangbin.
From: Hangbin Liu <liuhangbin@gmail.com> Date: Sun, 22 Dec 2019 10:51:08 +0800 > 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. ... Series applied and queued up for -stable, thanks.