Débordement de table de voisin sur les hôtes Linux liés au pontage et à ipv6

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.

Je crois que votre problème est dû à un bogue du noyau qui a été corrigé net-next.

L'espionnage de multidiffusion est désactivé lorsque le pont est initialisé en raison d'un bogue essayant de ressasser la table. L'espionnage IGMP empêche le pont de transmettre chaque réponse de requête de multidiffusion HBH ICMPv6, ce qui entraîne le remplissage de la table des ff02::voisins avec les voisins des réponses de multidiffusion qu'il ne devrait pas voir (essayer ip -6 neigh show nud all).

La solution appropriée consiste à tenter de réactiver fouiner comme: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. L'alternative est de rendre les seuils gc de la table voisine supérieurs au nombre d'hôtes dans le domaine de diffusion.

Le patch est là .

quel est le retour ip route show cache table alllorsque vous rencontrez cette erreur?

arp -nou ip neigh shown'affichera que certaines des entrées du cache.

ip route show cache table all sera beaucoup plus détaillé (et inclura beaucoup d'entrées liées à la v6).

Nous avons essayé les ajustements évidents et augmenté le / proc / sys / net / ipv4 / neigh / default / gc_thresh *

Avez-vous fait de même pour ipv6? qui a résolu le problème pour nous

Au revoir,

- creis