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

前端之家收集整理的这篇文章主要介绍了Linux主机上的邻居表溢出与桥接和ipv6相关前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
注意:我已经解决了这个问题(如下所述),所以这只是一个“想知道”的问题.

我有一个高效的设置,大约有50个主机,包括运行xen 4的刀片和提供iscsi的equallogics.所有xen dom0s几乎都是普通的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 net.ipv6.conf.all.disable_ipv6在整个主机上禁用了ipv6并重新启动.在此之后,即使启用桥接器br-vlan2159也不会发生错误.

欢迎任何想法.

解决方法

我相信你的问题是因为在net-next中修补了一个内核bug.

由于尝试重新扫描表时出现错误,因此在初始化网桥时会禁用多播侦听. IGMP Snooping阻止网桥转发每个HBH ICMPv6组播查询应答,这会导致邻居表填满来自组播应答的ff02 ::邻居,它们不应该看到(尝试ip-neigh show nud all).

正确的解决方法是尝试重新启用监听,如:echo 1> / SYS /班/网/的eth0 /桥梁/ multicast_snooping.另一种方法是使邻居表gc阈值大于广播域中的主机数.

补丁是here.

猜你在找的Linux相关文章