Solicitações de Arp com IP de origem ímpar ficam sem resposta

Question

Estou tendo um servidor com problemas de conectividade de rede que eu presumo provir de problemas com o tratamento do protocolo arp.

Digamos que a topologia de rede seja a seguinte:

• rede 192.168.106.0, máscara de rede 255.255.255.0
• roteador em 192.168.106.1
• "servidor de problemas" em 192.168.106.2
• outro servidor em 192.168.106.3

Agora, assuma que o "servidor de problemas" pode ficar em silêncio na rede por períodos de tempo suficientes para que a entrada de arp no roteador expire.

Quando alguém de fora desta rede tenta se conectar ao "servidor de problemas", todas as tentativas são encerradas. As conexões de dentro da rede para o "servidor de problemas" são bem-sucedidas.

Se o próprio "problema servidor" tentar se conectar a algum outro endereço fora da rede, a conexão será bem-sucedida - e depois disso, também as conexões de fora da rede para o "servidor problemático" serão bem-sucedidas por algum tempo. Além disso, as conexões do "servidor de problemas" para "outro servidor" estão ok.

Olhando para o tráfego arp no caso em que o "servidor problemático" ficou em silêncio por um longo tempo, posso ver solicitações arp na rede para o endereço "problem server", mas o endereço "tell" é o endereço de rede (192.168.106.0) em vez do endereço do roteador (192.168.106.1) - e é isso que eu suponho ser a razão para este problema: por alguma razão o roteador tem um endereço de resposta errado em suas requisições arp.

O "outro servidor" permanece acessível, mas aí eu assumo o motivo de ele fazer conexões com frequência fora da rede local e, assim, impedir que a entrada de arp no roteador expire.

Quaisquer comentários / sugestões?

Os servidores em questão estão executando o Linux (CentOS 5.x?) e estão executando como VMs dentro do VMWare ESXi (5.0?) (vou verificar / preencher os detalhes da versão assim que eu voltar ao trabalho na segunda-feira). A marca / modelo do roteador é desconhecida para mim.

Respostas a perguntas, descobertas adicionais

Desculpas por demorar a devolver isso.

Infelizmente, minha visibilidade para o lado da rede (qualquer coisa além da própria plataforma VMWare) é severamente limitada.

Com base nos pacotes de solicitação arp do roteador, ele é um produto da Juniper (adivinhando pelo endereço MAC do solicitante).

Esta é uma rede pequena, portanto, considere a topologia como roteador, switch e um único servidor VMWare que hospeda várias máquinas virtuais.

Quanto ao originador dos pedidos de arp estranhos, praticamente tem que ser o gateway de rede: eles só aparecem quando tento conectar-me à máquina "problema" de fora da rede - e param quando a tentativa atinge o tempo limite ou é cancelado. Uma pequena esquisitice é que o endereço MAC nessas requisições não é o mesmo que é visto para o roteador na tabela arp do servidor depois de estabelecer uma conexão de saída. No entanto, tanto o endereço MAC presente nessas solicitações "ímpares" quanto o endereço MAC mostrado na tabela arp do servidor têm uma OUI do Juniper-assigner.

Então, um achado possivelmente relacionado; parece que o Linux não responderá às requisições arp onde o endereço "tell" é o endereço de rede, enquanto o Windows (pelo menos o Vista) faz. Isso eu não pude testar no ambiente real do problema, mas com meus próprios brinquedos em casa.

Além disso, parece que não estou completamente sozinho com esse problema; uma experiência semelhante pode ser encontrada aqui: alpacapowered.wordpress.com

    

Answer 1

Hoje trouxe uma interessante mudança de situação.

Eventualmente, as coisas se resumem em duas coisas:

O roteador da Juniper, ou na verdade um sistema de firewalls em cluster, de alguma forma perdeu a sincronização da configuração entre as partes do cluster. Como resultado, nem todas as partes do cluster FW tinham uma configuração atualizada, e isso resultou em solicitações erradas do arp (sim, as solicitações de arp ruins se originaram do roteador / firewall).

O aplicativo de gerenciamento do firewall também se comportou mal, tentando forçar uma configuração diferente da correta para pelo menos parte do cluster de firewall.

Não tenho detalhes sobre o que foi feito para o firewall em si, nem para o aplicativo de gerenciamento, mas o resultado final é que agora o endereço "tell" nas solicitações arp é o endereço IP do roteador (.1 de a descrição original), em vez do endereço de rede (.0).

E para estes ("who-has ... tell ... .1") arp solicita que o servidor Linux responda exatamente como deveria, e as conexões de entrada funcionam bem, mesmo depois de qualquer rastreio do endereço do servidor foi perdido do cache de arp do roteador.

    

Answer 2

Eu encontrei exatamente o mesmo problema. Descobriu-se que alguém definiu o valor do manage-ip para o endereço de sub-rede:

Cluster:name(M)-> get config | inc aggregate10.200 set interface aggregate10.200 ip x.x.x.x.225/28 ... set interface aggregate10.200 manage-ip x.x.x.224 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Para corrigir:

unset interface aggregate10.200 manage-ip

Este foi um erro de configuração no nosso caso.