注意:我已经找到了解决此问题的方法(如下所述),所以这只是一个“想知道”的问题。
我有一个高效的设置,其中有大约 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 做了同样的事情吗?这为我们解决了问题
再见,
-- 克里斯