Estouro de tabela de vizinhos em hosts Linux relacionados a bridging e ipv6

Nota: Eu já tenho uma solução alternativa para esse problema (conforme descrito abaixo), portanto, essa é apenas uma pergunta de "desejo de saber".

Eu tenho uma configuração produtiva com cerca de 50 hosts, incluindo blades executando o xen 4 e equallogics fornecendo iscsi. Todos os xen dom0s são quase simples no Debian 5. A configuração inclui várias pontes em cada dom0 para suportar redes xen bridged. No total, existem entre 5 e 12 pontes em cada dom0, atendendo a uma vlan cada. Nenhum dos hosts tem o roteamento ativado.

Em um determinado momento, movemos uma das máquinas para um novo hardware, incluindo um controlador RAID, e instalamos um kernel 3.0.22 / x86_64 upstream com patches xen. Todas as outras máquinas rodam o debian xen-dom0-kernel.

Desde então, notamos em todos os hosts da instalação os seguintes erros a 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.

A tabela arp (arp -n) nunca mostrou mais do que 20 entradas em cada máquina. Tentamos os ajustes óbvios e aumentamos a

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

valores. Finalmente, para 16384 entradas, mas sem efeito. Nem mesmo o intervalo de ~ 2 minutos mudou, o que me levou a concluir que isso não tem relação alguma. O tcpdump não mostrou tráfego ipv4 incomum em nenhuma interface. A única descoberta interessante do tcpdump foram os pacotes IPv6 que explodiram 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

que colocou em minha mente que o problema talvez estivesse relacionado ao ipv6, pois não temos serviços ipv6 nessa configuração.

A única outra dica foi a coincidência da atualização do host com o início dos problemas. Desliguei o host em questão e os erros desapareceram. Posteriormente, derrubei as pontes no host e, quando derrubei (ifconfig down), uma em 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

Os erros foram embora novamente. Como você pode ver, a ponte não possui endereço IPv4 e seu único membro é eth0.2159; portanto, nenhum tráfego deve atravessá-la. A ponte e a interface .2159 / .2157 / .2158, que são em todos os aspectos idênticas, exceto a vlan à qual estão conectadas, não tiveram efeito quando retiradas. Agora desabilitei o ipv6 em todo o host via sysctl net.ipv6.conf.all.disable_ipv6 e reiniciei. Depois disso, mesmo com a ponte br-vlan2159 ativada, nenhum erro ocorre.

Todas as idéias são bem-vindas.

Acredito que seu problema seja causado por um bug do kernel que foi corrigido net-next.

A espionagem de difusão seletiva é desativada quando a ponte é inicializada devido a um erro ao tentar refazer a tarefa da tabela. A espionagem IGMP impede que a ponte encaminhe todas as respostas de consulta multicast HBH ICMPv6, o que resulta na tabela vizinha preenchendo os ff02::vizinhos das respostas multicast que ela não deve ver (tente ip -6 neigh show nud all).

A solução adequada é a tentativa de reativar bisbilhotando como: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. A alternativa é aumentar os limites gc da tabela vizinha ao número de hosts no domínio de broadcast.

O patch está aqui .

qual é o retorno de ip route show cache table allquando você está enfrentando esse erro?

arp -nou ip neigh showmostrará apenas algumas das entradas no cache.

ip route show cache table all será muito mais detalhado (e incluirá muitas entradas relacionadas à v6).

Tentamos os ajustes óbvios e aumentamos o / proc / sys / net / ipv4 / neigh / default / gc_thresh *

Você fez o mesmo para o ipv6? que resolveu o problema para nós

Tchau,

- creis