Esse é um problema tão incomum e tão “tosco” digamos assim, mas que porém gera uma certa dor de cabeça ao admin de rede.
Vou contar uma história para ilustrar do que estou falando.
Decidimos clonar uma maquina virtual que continha um servidor de aplicação em produção e funcional. Até ai tudo tranquilo! Vamos clonar a maquina mudamos seus endereçamentos e vida que segue.
Foi o que realmente achamos que aconteceria. Clonamos a maquina e com o server principal OFF nesse momento, simplesmente mudamos os IPs e endereços MAC da maquina clone, OK deveria tudo funcionar normalmente, e funcionou. clap, clap, clap… pouco tempo depois começaram os problemas, o servidor principal começou a perder comunicação com a rede subitamente.
O servidor Principal (Produção) tinha o IP 128.1.4.3 e para o novo servidor atribuímos o IP 128.1.4.5
Então, o que foi que aconteceu? Porque o servidor Principal simplesmente perdia conexão com a rede subitamente? Foi ai que começou a caçada e que acabamos descobrindo que o nosso vilão nessa história era o ARP e as consultas geradas por ele.
Em algum momento nós subimos os dois servidores juntos e ainda com o mesmo endereço MAC atribuído aos dois servidores.
Mas não basta agora desligar um dos servidores e mudar o seu endereço MAC, pois é… eu também pensei que esse seria o caminho lógico, mas não foi o que aconteceu.
Um dos nossos roteadores na rede armazenou em sua tabela de consulta ARP o IP do novo servidor o 128.1.4.5 e cada vez que ele consultava a rede via broadcast o servidor Produção recebia a pergunta e derrubava subitamente a comunicação de rede, isso acredito que por que com a duplicidade de MAC os hosts não sabiam para onde a comunicação deveria ser entregue.
Abaixo a imagem mostra o momento em que o nosso roteador perguntava via broadcast sobre o endereçamento dos IPs 128.1.4.3 e 128.1.4.5 e como a resposta provavelmente era o mesmo endereço, perdíamos a comunicação.
Já na imagem abaixo é possível ver a resposta do servidor para uma pergunta ARP vinda de um equipamento que não o nosso roteador (uma estação qualquer) e a resposta ARP de forma tranquila pois a tabela da estação que perguntava não armazenou o IP “falho” 128.1.4.5 apenas o “quente” o que realmente estava em funcionamento.
https://www.orionscache.com/2014/01/clearing-arp-and-dns-cache-in-linux/
https://linux-audit.com/how-to-clear-the-arp-cache-on-linux/
Estes dois links acima são artigos que podem auxiliar na solução do problema tendo em vista que demonstrando comandos que manipulam e limpam a tabela ARP.
Este artigo tem a intenção de servir de base para pesquisas futuras em problemas relacionados, não tenho a intenção aqui de dar todas as respostas ao problema, por isso uso aqui algumas palavras como “deveria”, “poderia”, “provável”. Apenas conto essa história de forma resumida para servir de base para pesquisas futuras e para nortear em um problema que é muito incomum.
