Mitigando Erro de Kernel: Neighbour Table Overflow

Desmistificando o erro kernel: Neighbour Table Overflow

[ Hits: 6.280 ]

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

Debian 3.1 (Sarge) - Atualizando pacotes para unstable e compilando um novo kernel

Instalando o Slackware com suporte HT - SMP

Compilando kernel 2.6.11 no Slackware 10

Compilando kernel 2.6 no Slackware 11

Recompilando o Kernel

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts