Desbordamiento de tabla vecina en hosts Linux relacionados con bridging e ipv6

Nota: Ya tengo una solución para este problema (como se describe a continuación), por lo que esta es solo una pregunta de "querer saber".

Tengo una configuración productiva con alrededor de 50 hosts, incluidos blades con xen 4 e equallogics que proporcionan iscsi. Todos los domos xen son casi simples Debian 5. La configuración incluye varios puentes en cada dom0 para admitir redes en puente xen. En total hay entre 5 y 12 puentes en cada dom0 que dan servicio a una vlan cada uno. Ninguno de los hosts tiene habilitado el enrutamiento.

En un momento dado, trasladamos una de las máquinas a un nuevo hardware que incluye un controlador RAID y, por lo tanto, instalamos un kernel 3.0.22 / x86_64 ascendente con parches xen. Todas las otras máquinas ejecutan debian xen-dom0-kernel.

Desde entonces notamos en todos los hosts en la configuración los siguientes errores cada ~ 2 minutos:

[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 tabla arp (arp -n) nunca mostró más de alrededor de 20 entradas en cada máquina. Probamos los ajustes obvios y elevamos el

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

valores. Finalmente hasta 16384 entradas pero sin efecto. Ni siquiera el intervalo de ~ 2 minutos cambió, lo que me llevó a la conclusión de que esto no tiene ninguna relación. tcpdump no mostró tráfico ipv4 infrecuente en ninguna interfaz. El único hallazgo interesante de tcpdump fueron los paquetes ipv6 que explotaron como:

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

lo que me hizo pensar que el problema puede estar relacionado con ipv6, ya que no tenemos servicios de ipv6 en esta configuración.

La única otra pista fue la coincidencia de la actualización del host con el comienzo de los problemas. Apagué el host en cuestión y los errores desaparecieron. Luego, derribé los puentes en el host y cuando derribé (ifconfig down) un puente en particular:

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

Los errores desaparecieron nuevamente. Como puede ver, el puente no tiene dirección ipv4 y su único miembro es eth0.2159, por lo que no debe cruzar el tráfico. El puente y la interfaz .2159 / .2157 / .2158 que son idénticos en todos los aspectos, aparte de la vlan a la que están conectados, no tuvieron ningún efecto cuando se desmontaron. Ahora deshabilité ipv6 en todo el host a través de sysctl net.ipv6.conf.all.disable_ipv6 y reinicié . Después de esto, incluso con el puente br-vlan2159 habilitado, no se producen errores.

Cualquier idea es bienvenida.

Creo que su problema se debe a un error del kernel que se parchó net-next.

La indagación de multidifusión se deshabilita cuando el puente se inicializa debido a un error que intenta rehacer la tabla. IGMP snooping detiene el puente de reenvío de todos los HBH ICMPv6 respuesta consulta de multidifusión, lo que da como resultado la tabla de vecinos se llena de ff02::vecinos de las respuestas de multidifusión que se debe no ver (TRY ip -6 neigh show nud all).

La solución correcta es intentar volver a habilitar snooping como: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. La alternativa es hacer que los umbrales gc de la tabla vecina sean más grandes que el número de hosts en el dominio de difusión.

El parche está aquí .

¿Cuál es el retorno de ip route show cache table allcuando experimentas este error?

arp -no ip neigh showsolo mostrará algunas de las entradas en el caché.

ip route show cache table all será mucho más detallado (e incluirá muchas entradas relacionadas con v6).

Probamos los ajustes obvios y planteamos / proc / sys / net / ipv4 / neigh / default / gc_thresh *

¿Hiciste lo mismo para ipv6? eso resolvió el problema para nosotros

Adiós,

- creis