Servidores Windows 2008 R2 Enviando Solicitações Arp para IPs fora da Sub-rede

Question

Ao executar uma captura de pacote em meus roteadores, vejo alguns dos meus servidores enviando solicitações ARP para IPs que existem fora de sua rede.

Por exemplo, se minha rede for:

Network: 8.8.8.0/24  
Gateway: 8.8.8.1 (MAC: 00:21:9b:aa:aa:aa)  
Example Server: 8.8.8.20 (MAC:  00:21:9b:bb:bb:bb)

Ao executar uma captura na interface que possui 8.8.8.1, vejo solicitações como:

Sender Mac: 00:21:9b:bb:bb:bb 
Sender IP: 8.8.8.20
Target MAC: 00:21:9b:aa:aa:aa
Target IP: 69.63.181.58

Alguém já viu esse comportamento antes? Meu entendimento do ARP é que os pedidos só devem sair para os IPs dentro da sub-rede ... Estou confuso em minha compreensão do ARP? Se eu não estou confuso, alguém viu esse comportamento?

Além disso, eles parecem acontecer em rajadas e isso não acontece quando eu faço algo como pingar um IP fora da rede.

Atualização:
Em resposta às perguntas de Ian. Eu não estou executando nada como o Hyper-V. Eu tenho várias interfaces, mas apenas uma está ativa (usando o agrupamento de failover do BACS). A máscara de sub-rede é 255.255.255.0 (mesmo que fosse algo diferente, não explicaria um IP como 69.63.181.58).

Quando executo o MS Network Monitor ou o wireshark, não vejo essas solicitações ARP. O que acontece é que, na captura do roteador, vejo uma explosão de cerca de 10 solicitações de IPs fora da rede a partir da máquina host. Na própria máquina usando wireshark ou NetMon, vejo uma enxurrada de respostas ARP para todas as máquinas na rede. No entanto, não vejo solicitações na captura solicitando essas respostas.

Assim, parece que talvez esteja atualizando o cache do arp, mas incluindo IPs que estão fora da rede. Além disso, quando isso acontece, o NetMon não mostra as solicitações ARP?

    

Answer 1

Se você não visualizar as solicitações ARP no Wireshark / Netmon, duas fontes adicionais para os quadros ARP poderão ser o BASP (Teaming Driver) da Broadcom e o gerenciamento de rede OEM (DRAC da Dell e iLo da HP, por exemplo).

O driver de agrupamento da Broadcom inclui um recurso chamado "LiveLink" que usa quadros ARP para verificar conexões de rede a sistemas remotos (consulte link ). Se o usuário definir um probe LiveLink para um endereço IP fora da sub-rede local, o BASP gerará um ARP para esse endereço. É claro que, se o endereço for falso, a equipe deve indicar uma falha em uma ou mais NICs usadas na equipe.

Os servidores corporativos geralmente têm uma porta Ethernet dedicada para gerenciamento. Servidores de menor custo podem aproveitar a porta LOM e enviar tráfego pelo mesmo conector RJ-45 que o Windows. Se o recurso de gerenciamento do servidor estiver habilitado, mas não configurado corretamente, ele poderá gerar ARPs fora da sub-rede IP usada pelo host. Esses quadros ARP também seriam invisíveis para o Wireshark / Netmon. A maioria das soluções de gerenciamento também funciona enquanto o sistema está desligado, portanto, se você continuar a ver os ARPs gerados por um sistema quando ele estiver desligado, a função de gerenciamento poderá ser a fonte.

    

Answer 2

Sua compreensão do ARP está correta. Um host não deve ARP para um endereço IP que não esteja em sua sub-rede local, pois ele deve saber que o endereço IP não é local e, portanto, deve saber que os dados precisam ser enviados para o gateway padrão. A única vez que vi isso foi com um host infectado com malware.

    

Answer 3

A pergunta óbvia é: Qual é a sua configuração de rede? Você tem várias interfaces? Você tem hyper-v ou vmware em seu servidor?

Em qualquer caso, sua compreensão do arp é de fato correta. Um erro de configuração de rede parece ser a explicação mais provável.

Tente instalar o MSNetmon no seu servidor e capturar o tráfego arp. Deve dar uma indicação de onde está vindo. Em todas as probabilidades, será sistema e não algum processo de malware. Se for um malware, como mencionado acima, ele deverá identificá-lo rapidamente.