Endereço MAC incorreto do Windows preenchendo a tabela ARP

Question

Recentemente, tenho enfrentado problemas em que endereços MAC incorretos estão preenchendo as tabelas arp de algumas VMs do Windows em execução na nuvem de um provedor de nuvem. Por exemplo, se eu executar ping em 10.1.2.3, algumas VMs do Windows mostrarão um endereço MAC diferente da maioria das outras VMs. O resultado é que essas poucas VMs do Windows não podem atingir 10.1.2.3, mas o restante das VMs (Windows e Linux) pode alcançá-lo.

Depois de executar as capturas de pacotes, a origem dos endereços MAC incorretos parece ser MS-NLB-PhysServer-XX_, que está incluído emlista publicada do wireshark. Porém, não estou executando nenhum tipo de MS-NLB e, portanto, é muito confuso saber qual é essa fonte. Meu provedor de nuvem diz que não vem deles. Minhas perguntas são:

1. Existe uma boa maneira de identificar o dispositivo de origem com base em seu endereço MAC se eu não for o proprietário desse dispositivo? ou seja, estou me perguntando se isso vem dos balanceadores de carga do nosso provedor de nuvem.
2. Quais são os motivos pelos quais este dispositivo de origem teria endereços MAC incorretos que está enviando para outros dispositivos? ou seja, por que ele tem o endereço MAC errado para 10.1.2.3 e outras interfaces de rede recém-criadas?
3. Quais são os motivos pelos quais apenas um subconjunto de VMs obtém endereços MAC incorretos dessa fonte e outras VMs na mesma sub-rede obtêm endereços MAC bons de outras fontes?

Answer 1

Também encontramos isso, está acontecendo em nossos nós do Windows EKS após a reinicialização. Temos nós que ingressam em um domínio para GMSA, o que requer uma reinicialização, portanto, essas instâncias perceberam o problema imediatamente.

Abri um tíquete de suporte e a solução alternativa fornecida é fazer com que um script de desligamento execute o seguinte

powershell.exe /c "get-hnsendpoint | remove-hnsendpoint"
exit

A saída foi considerada importante porque evita o desligamento por um período de tempo.

Usei esta resposta como base para automatizar este processo -https://stackoverflow.com/a/47709154

Answer 2

Se você não possui o outro dispositivo, presumo que seja porque ele está em uma rede totalmente diferente, o que significaria que você não verá o endereço MAC, mas aquele no dispositivo mais próximo de você que encaminhará o tráfego para esse outro dispositivo final. dispositivo.

Lembre-se de que a comunicação ponta a ponta não acontece na camada de enlace de dados (ou seja, camada 2).

O cenário mais provável aqui pode ser que seu roteamento esteja configurado incorretamente emalgunsde suas VMs e no nível do sistema operacional, em vez da tabela de rotas de rede do seu provedor de nuvem ... ou eles estão em redes diferentes (talvez sub-rede AWS?) e têm tabelas de rotas diferentes.

Answer 3

Adicionando isso como uma resposta também.

Vários provedores de nuvem têm umbastantevisão peculiar de networking e lidar com isso de uma forma que um profissional de networking acharia simplesmente ultrajante; no entanto, é assim que funcionam e temos que lidar com isso.

No Azure, os endereços MAC simplesmente não fazem sentido; todas as entradas da tabela ARP apontam sempre para 12-34-56-78-9a-bc, porque toda a rede do Azure é tratada na camada IP e o ARP não existe nem funciona; uma VM do Azure não pode simplesmente gritar "Eu tenho este endereço IP" (também conhecido como "ARP gratuito"), porque a plataforma do Azure precisa saber sobre isso para rotear o tráfego para essa VM. O clustering do Azure funciona de uma maneira tão estranha que você precisa colocar um balanceador de carga muito incomum na frente do seu cluster.

Sinceramente, não sei como isso funciona na AWS, mas acho que é tão estranho, se não pior.