Estouro de tabela de vizinhos em hosts do Linux relacionados a pontes e ipv6

Question

Observação: eu já tenho uma solução alternativa para esse problema (conforme descrito abaixo), portanto, essa é apenas uma questão de "quero saber".

Eu tenho uma configuração produtiva com cerca de 50 hosts, incluindo blades rodando xen 4 e equallogics fornecendo iscsi. Todos os xen dom0s são quase totalmente Debian 5. A configuração inclui várias pontes em cada dom0 para suportar a rede de bridges xen. No total, existem entre 5 e 12 pontes em cada dom0 que atendem uma vlan cada. Nenhum dos hosts tem 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 executam o debian xen-dom0-kernel.

Desde então, notamos em todos os hosts na configuraçã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 de 20 entradas em cada máquina. Nós tentamos os ajustes óbvios e levantamos o

/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 leva à conclusão de que isso é totalmente não relacionado. O tcpdump não mostrou nenhum tráfego ipv4 incomum em qualquer interface. A única descoberta interessante do tcpdump foram pacotes ipv6 explodindo em:

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 a idéia em minha mente que o problema talvez estivesse relacionado ao ipv6, já que 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. Eu desliguei o host em questão e os erros desapareceram. Então eu subseqüentemente abaixei as pontes no host e quando eu tirei (ifconfig down) uma ponte particularmente:

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 bridge não tem endereço ipv4 e seu único membro é eth0.2159 , então nenhum tráfego deve atravessá-la. Ponte e interface .2159 / .2157 / .2158 que são em todos os aspectos idênticos, além da vlan a que estão conectados, não tiveram efeito quando derrubado. Agora eu desabilitei o ipv6 em todo o host via sysctl net.ipv6.conf.all.disable_ipv6 e reiniciei. Depois disso, mesmo com a bridge br-vlan2159 ativada, nenhum erro ocorrerá.

Todas as ideias são bem-vindas.

    

Answer 1

Eu acredito que seu problema é por causa de um bug do kernel que foi corrigido em net-next .

A espionagem multicast fica desativada quando a ponte é inicializada devido a um erro ao tentar refazer a tabela. O snooping IGMP impede que a ponte encaminhe todas as respostas de consultas multicast do HBH ICMPv6, o que faz com que a tabela do vizinho seja preenchida com ff02:: vizinhos de respostas multicast que não deve ser vista (tente ip -6 neigh show nud all ). / p>

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

O patch é aqui .

    

Answer 2

qual é o retorno de ip route show cache table all quando você está com esse erro?

arp -n ou ip neigh show mostrará apenas algumas das entradas no cache.

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

We tried the obvious tweaks and raised the /proc/sys/net/ipv4/neigh/default/gc_thresh*

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

Tchau,

creis