Remarque: J'ai déjà une solution de contournement pour ce problème (comme décrit ci-dessous), il ne s'agit donc que d'une question "à savoir".
J'ai une configuration productive avec environ 50 hôtes, y compris des lames exécutant xen 4 et des équalogiques fournissant iscsi. Tous les dom0 xen sont presque Debian 5. La configuration comprend plusieurs ponts sur chaque dom0 pour prendre en charge les réseaux pontés xen. Au total, il y a entre 5 et 12 ponts sur chaque dom0 desservant un vlan chacun. Aucun des hôtes n'a le routage activé.
À un moment donné, nous avons déplacé l'une des machines vers un nouveau matériel comprenant un contrôleur RAID et nous avons donc installé un noyau 3.0.22 / x86_64 en amont avec des correctifs xen. Toutes les autres machines exécutent debian xen-dom0-kernel.
Depuis lors, nous avons remarqué sur tous les hôtes de la configuration les erreurs suivantes toutes les ~ 2 minutes:
[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.
La table arp (arp -n) n'a jamais montré plus de 20 entrées sur chaque machine. Nous avons essayé les ajustements évidents et augmenté la
/proc/sys/net/ipv4/neigh/default/gc_thresh*
valeurs. Finalement à 16384 entrées mais sans effet. Même l'intervalle de ~ 2 minutes n'a pas changé, ce qui m'amène à la conclusion que ce n'est absolument pas lié. tcpdump n'a montré aucun trafic ipv4 inhabituel sur aucune interface. La seule découverte intéressante de tcpdump était des paquets ipv6 éclatant comme:
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
ce qui a placé l'idée dans mon esprit que le problème peut être lié à ipv6, car nous n'avons aucun service ipv6 dans cette configuration.
Le seul autre indice était la coïncidence de la mise à niveau de l'hôte avec le début des problèmes. J'ai éteint l'hôte en question et les erreurs ont disparu. Ensuite, j'ai par la suite supprimé les ponts sur l'hôte et lorsque j'ai supprimé (ifconfig down) un pont en particulier:
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
Les erreurs ont de nouveau disparu. Comme vous pouvez le voir, le pont ne contient aucune adresse ipv4 et son seul membre est eth0.2159, donc aucun trafic ne doit le traverser. Le pont et l'interface .2159 / .2157 / .2158 qui sont dans tous les aspects identiques à l'exception du vlan auquel ils sont connectés n'ont eu aucun effet lors de leur retrait. Maintenant, j'ai désactivé ipv6 sur tout l'hôte via sysctl net.ipv6.conf.all.disable_ipv6 et redémarré. Après cela, même avec le pont br-vlan2159 activé, aucune erreur ne se produit.
Toutes les idées sont les bienvenues.
echo 1 > /sys/class/net/br0/bridge/multicast_snooping
.