Mitigando Erro de Kernel: Neighbour Table Overflow

Desmistificando o erro kernel: Neighbour Table Overflow

[ Hits: 2.026 ]

Por: Gustavo Henrique Esser em 11/06/2019


O problema



Se você chegou até este artigo, tenho absoluta certeza que você se deparou com o este erro "kernel: Neighbour Table Overflow", mas fique tranquilo que iremos desmistificar este problema.

O erro trata-se de um alerta de estouro no limite da tabela ARP. As consequências disto e a lentidão, ou até mesmo perda de pacotes, tornando as conexões de rede com esta máquina instável ou até inacessível.

Para começarmos a entender este problema, na tabela ARP do Kernel Linux tem um tamanho máximo que está definido dentro do arquivo /proc/sys/net/ipv4/neigh/default/gc_thresh3.

E como era de se esperar, se tem um tamanho máximo, ao ultrapassarmos este limite ela vai estourar.

O cache ARP do kernel Linux armazena um endereço MAC para cada endereço IP que não é roteado. Isto é, em uma sub-rede configurada na placa de rede de um servidor. Isso é necessário para que os pacotes de dados que não são enviados ao roteador possam ser transmitidos diretamente via quadros Ethernet. Logicamente, o endereço IP do roteador (gateway) também é armazenado no cache do ARP.

Solução temporária

Solução temporária, caso não possa reiniciar seu servidor.

Os comandos abaixo vão resolver o seu problema, porém, você está somente adiando o erro:

# echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
# echo 32768 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
# echo 65535 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

Os 3 comandos acima vão alterar os valores das entradas para o máximo possível na tabela ARP. Para entendermos cada uma das variáveis, segue uma explicação abaixo.
  • gc_thresh1: O número mínimo de entradas no cache do ARP. O processo de limpeza do kernel não excluirá entradas do cache do ARP, desde que esse número seja reduzido.
  • gc_thresh2: O número máximo "soft" de entradas no cache do ARP. O processo de limpeza do kernel permite tantas entradas no cache ARP por 5 segundos, depois começa a remover as entradas mais antigas.
  • gc_thresh3: O número máximo "rígido" de entradas no cache do ARP. O processo de eliminação é executado permanentemente se houver mais do que entradas suficientes no cache do ARP.

Os valores padrão de cada uma das 3 variáveis, são:

No IPv4:
  • net.ipv4.neigh.default.gc_thresh1 = 128
  • net.ipv4.neigh.default.gc_thresh2 = 512
  • net.ipv4.neigh.default.gc_thresh3 = 1024

No IPv6:
  • net.ipv6.neigh.default.gc_thresh1 = 128
  • net.ipv6.neigh.default.gc_thresh2 = 512
  • net.ipv6.neigh.default.gc_thresh3 = 1024

Esses valores padrão são razoáveis e suficientes na maioria dos casos. No entanto, em configurações de rede especiais ou quando o ocorrer o erro em questão, pode ser necessário aumentar manualmente o cache do ARP.

Veremos à solução definitiva.

Solução Definitiva

A solução definitiva é alteramos o valor de forma permanente, com base no tamanho da nossa tabela ARP ou com base na sua necessidade.

Para sabermos quantos endereços temos naquele momento na tabela, basta usar o comando:

# arp -n

Ou, para obter apenas a quantidade use:

# arp -an|wc -l

Obs.: em nenhuma circunstância, você deve configurar os valores para serem desnecessariamente grandes, porque você perderá RAM (isso também é valido para sistemas com vários GB de RAM.)

Para que você mantenha os valores de forma permanente, é preciso editar o arquivo de configuração do sysctl e definir os valores.

Usando o editor de texto, edite o arquivo /etc/sysctl.conf e adicione as seguintes linhas de acordo com a sua necessidade:

net.ipv4.neigh.default.gc_thresh3 = 2048
net.ipv4.neigh.default.gc_thresh2 = 1024
net.ipv4.neigh.default.gc_thresh1 = 512

Feito a alteração, você pode recarregar as configurações com o comando:

# sysctl -p

Feito os passos acima, caso você reinicie seu servidor, os parâmetros adicionados às variáveis não serão perdidos.

Referências


Espero ter esclarecido o problema.

Fico à disposição.
Gustavo Henrique Esser

   

Páginas do artigo
   1. O problema
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Slackware com kernel 2.6.10 - passo a passo

Debian Lenny com Kernel 2.6.28 + Layer7 + Firewall

Recompilando o Kernel no Ubuntu Linux 9.04

Recompilando kernel 2.6 no Debian Lenny

Controle de tráfego utilizando HTB no Debian Sarge

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts