Linux错误(7)接口处于Down状态不通告IPv6地址变更事件

Linux错误(7)接口处于Down状态不通告IPv6地址变更事件

Author: Once Day Date: 2025年10月29日

漫漫长路才刚刚开始…

全系列文章可参考专栏: Linux实践记录_Once_day的博客-CSDN博客

1. 问题分析

1.1 现象介绍

在linux 4.14内核版本上，接口处于Down状态时，IPv6地址操作不会触发netlink通告，会导致用户空间存在地址残留：

root@linux:~# ip addr add 2001::1/64 dev Ge0_7
root@linux:~# ip addr show dev Ge0_7
20: Ge0_7@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000link/ether 00:d0:f8:22:36:86 brd ff:ff:ff:ff:ff:ffinet6 2001::1/64 scope global tentative valid_lft forever preferred_lft forever

使用ip addr del 2001::1/64 dev Ge0_7删除地址，用ip monitor all监控，发现内核只通过路由删除，没有地址删除事件：

[ROUTE]Deleted unicast 2001::/64 dev Ge0_7 table main proto kernel scope global metric 256 linkdown pref medium

如果地址是在接口UP时配置，在Down时删除，那么无法接收到Addr Delete事件，这对于用户空间处理十分不便。

1.2 分析原因

接口处于DOWN时，接口IPv6地址会处于 tentative 状态，处于重复地址检测的试探状态，是一个临时状态，地址还没有真正启用：

root@linux:~# ip addr show dev Ge0_7
20: Ge0_7@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000link/ether 00:d0:f8:22:36:86 brd ff:ff:ff:ff:ff:ffinet6 2001::1/64 scope global tentative valid_lft forever preferred_lft forever

而内核在通告IPv6地址时，会判断地址的状态，tentative 状态地址不会被通告:

// net/ipv6/addrconf.cstatic void inet6_ifa_notify(int event, struct inet6_ifaddr *ifa)
{struct sk_buff *skb;struct net *net = dev_net(ifa->idev->dev);int err = -ENOBUFS;/* Don't send DELADDR notification for TENTATIVE address,* since NEWADDR notification is sent only after removing* TENTATIVE flag, if DAD has not failed.*/if (ifa->flags & IFA_F_TENTATIVE && !(ifa->flags & IFA_F_DADFAILED) &&event == RTM_DELADDR)return;skb = nlmsg_new(inet6_ifaddr_msgsize(), GFP_ATOMIC);if (!skb)goto errout;......
}

ifa->flags & IFA_F_TENTATIVE和event == RTM_DELADDR条件满足，因此会忽略地址删除通告。

1.3 解决思路

在4.14以后的版本里，这个问题已经被解决，有两个提交与此存在关联：

commit1: f784ad3d79e5be062b19dc36c53413daffeecc5c

ipv6: do not send RTM_DELADDR for tentative addressesRTM_NEWADDR notification is sent when IFA_F_TENTATIVE is cleared from
the address. So if the address is added and deleted before DAD probes
completes, the RTM_DELADDR will be sent for which there was no
RTM_NEWADDR causing asymmetry in notification. However if the same
logic is used while sending RTM_DELADDR notification, this asymmetry
can be avoided.Signed-off-by: Mahesh Bandewar <[e-mail]>

修改如下：

这个提交引入上面的删除tentative地址没有netlink通告的问题。

commit2: a2d481b326c98b6b67eea8a378c858d57ca5ff3d

ipv6: send netlink notifications for manually configured addressesSend a netlink notification when userspace adds a manually configured
address if DAD is enabled and optimistic flag isn't set.
Moreover send RTM_DELADDR notifications for tentative addresses.Some userspace applications (e.g. NetworkManager) are interested in
addr netlink events albeit the address is still in tentative state,
however events are not sent if DAD process is not completed.
If the address is added and immediately removed userspace listeners
are not notified. This behaviour can be easily reproduced by using
veth interfaces:$ ip -b - <<EOF
> link add dev vm1 type veth peer name vm2
> link set dev vm1 up
> link set dev vm2 up
> addr add 2001:db8:a:b:1:2:3:4/64 dev vm1
> addr del 2001:db8:a:b:1:2:3:4/64 dev vm1
EOFThis patch reverts the behaviour introduced by the commit f784ad3d79e5
("ipv6: do not send RTM_DELADDR for tentative addresses")Suggested-by: Thomas Haller <[e-mail]>
Signed-off-by: Lorenzo Bianconi <[e-mail]>
Signed-off-by: David S. Miller <[e-mail]>

修改如下：

第二个提交修复没有tentative地址通告的问题，按照commit2修改linux 4.14 源码即可。