☰

与桥接和 IPv6 相关的 Linux 主机邻居表溢出

tag-icon • tag-icon linux networking ipv6 arp
与桥接和 IPv6 相关的 Linux 主机邻居表溢出

注意：我已经找到了解决此问题的方法（如下所述），所以这只是一个“想知道”的问题。

我有一个高效的设置，其中有大约 50 台主机，包括运行 xen 4 的刀片和提供 iscsi 的 equallogics。所有 xen dom0 几乎都是普通的 Debian 5。该设置包括每个 dom0 上的多个桥接器以支持 xen 桥接网络。总共每个 dom0 上有 5 到 12 个桥接器，每个桥接器服务一个 VLAN。所有主机均未启用路由。

有一次，我们将其中一台机器移到了包括 raid 控制器的新硬件上，因此我们安装了带有 xen 补丁的上游 3.0.22/x86_64 内核。所有其他机器都运行 debian xen-dom0-kernel。

从那时起，我们注意到设置中的所有主机每隔约 2 分钟就会出现以下错误：

[55888.881994] __ratelimit: 908 callbacks suppressed
[55888.882221] Neighbour table overflow.
[55888.882476] Neighbour table overflow.
[55888.882732] Neighbour table overflow.
[55888.883050] Neighbour table overflow.
[55888.883307] Neighbour table overflow.
[55888.883562] Neighbour table overflow.
[55888.883859] Neighbour table overflow.
[55888.884118] Neighbour table overflow.
[55888.884373] Neighbour table overflow.
[55888.884666] Neighbour table overflow.

arp 表 (arp -n) 在每台机器上显示条目数从未超过 20 条。我们尝试了一些明显的调整，并提高了

/proc/sys/net/ipv4/neigh/default/gc_thresh*

值。最后为 16384 个条目，但没有效果。甚至约 2 分钟的间隔都没有变化，这让我得出结论，这完全不相关。tcpdump 在任何接口上都没有显示不常见的 ipv4 流量。tcpdump 唯一有趣的发现是 ipv6 数据包像以下这样爆发：

14:33:13.137668 IP6 fe80::216:3eff:fe1d:9d01 > ff02::1:ff1d:9d01: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:9d01, length 24
14:33:13.138061 IP6 fe80::216:3eff:fe1d:a8c1 > ff02::1:ff1d:a8c1: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:a8c1, length 24
14:33:13.138619 IP6 fe80::216:3eff:fe1d:bf81 > ff02::1:ff1d:bf81: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:bf81, length 24
14:33:13.138974 IP6 fe80::216:3eff:fe1d:eb41 > ff02::1:ff1d:eb41: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:eb41, length 24

这让我想到问题可能与 ipv6 有关，因为我们在此设置中没有 ipv6 服务。

唯一的其他提示是主机升级与问题开始的时间巧合。我关闭了有问题的主机，错误消失了。然后我随后关闭了主机上的桥接器，当我关闭（ifconfig down）一个特定的桥接器时：

br-vlan2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:120 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:5286 (5.1 KiB)  TX bytes:726 (726.0 B)

eth0.2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1801 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:126228 (123.2 KiB)  TX bytes:1464 (1.4 KiB)

bridge name bridge id       STP enabled interfaces
...
br-vlan2158     8000.0026b9fb162c   no      eth0.2158
br-vlan2159     8000.0026b9fb162c   no      eth0.2159

错误又消失了。正如您所见，该网桥没有 ipv4 地址，它的唯一成员是eth0.2159因此任何流量都不应穿过它。桥和接口.2159/.2157/.2158除了它们所连接的 VLAN 之外，它们在所有方面都完全相同，关闭后没有任何影响。现在我通过 sysctl 禁用了整个主机上的 ipv6net.ipv6.conf.all.disable_ipv6并重新启动。此后即使使用桥接br-vlan2159启用后不会发生任何错误。

欢迎任何想法。

答案1

我相信您的问题是由于已修补的内核错误造成的net-next。

由于尝试重新散列表的错误，初始化网桥时多播侦听会被禁用。IGMP 侦听会阻止网桥转发每个 HBH ICMPv6 多播查询回复，这会导致邻居表被ff02::多播回复的邻居填满，而这本应如此不是参见（尝试ip -6 neigh show nud all）。

正确的解决方法是尝试重新启用监听，例如：echo 1 > /sys/class/net/eth0/bridge/multicast_snooping。另一种方法是使邻居表 gc 阈值大于广播域中的主机数量。

该补丁这里。

答案2

ip route show cache table all当您遇到此错误时返回什么？

arp -n或者ip neigh show仅显示缓存中的某些条目。

ip route show cache table all将会更加详细（并且将包括很多与 v6 相关的条目）。

我们尝试了一些明显的调整，并提高了 /proc/sys/net/ipv4/neigh/default/gc_thresh*

您对 ipv6 做了同样的事情吗？这为我们解决了问题

再见，

-- 克里斯

相关内容