최근에 클라우드 공급자의 클라우드에서 실행되는 일부 Windows VM의 arp 테이블에 잘못된 MAC 주소가 채워지는 문제가 발생했습니다. 예를 들어 10.1.2.3을 ping하면 일부 Windows VM은 대부분의 다른 VM과 다른 MAC 주소를 표시합니다. 결과적으로 이러한 소수의 Windows VM은 10.1.2.3에 도달할 수 없지만 나머지 VM(Windows 및 Linux 모두)은 10.1.2.3에 도달할 수 있습니다.
패킷 캡처를 실행한 후 잘못된 MAC 주소의 소스는 MS-NLB-PhysServer-XX_인 것 같습니다.Wireshark의 게시 목록. 하지만 저는 어떤 종류의 MS-NLB도 실행하고 있지 않으므로 해당 소스가 무엇인지 매우 혼란스럽습니다. 내 클라우드 공급자는 그것이 그들에게서 오는 것이 아니라고 말합니다. 내 질문은 다음과 같습니다
- 해당 장치를 소유하고 있지 않은 경우 MAC 주소를 기반으로 소스 장치를 식별할 수 있는 좋은 방법이 있습니까? 즉, 클라우드 공급자의 로드 밸런서에서 오는 것인지 궁금합니다.
- 이 소스 장치가 다른 장치로 전송하는 잘못된 MAC 주소를 갖는 이유는 무엇입니까? 즉, 10.1.2.3 및 기타 새로 생성된 네트워크 인터페이스에 대해 잘못된 MAC 주소가 있는 이유는 무엇입니까?
- VM의 하위 집합만이 이 소스에서 잘못된 MAC 주소를 얻고 동일한 서브넷의 다른 VM이 다른 소스에서 좋은 MAC 주소를 얻는 이유는 무엇입니까?
답변1
우리도 이 문제를 겪었는데, 재부팅 후 EKS Windows 노드에서 이런 일이 발생합니다. 재부팅이 필요한 GMSA용 도메인에 가입하는 노드가 있으므로 이러한 인스턴스에서는 문제가 즉시 확인되었습니다.
지원 티켓을 열었고 그들이 제공한 해결 방법은 종료 스크립트가 다음을 실행하도록 하는 것입니다.
powershell.exe /c "get-hnsendpoint | remove-hnsendpoint"
exit
종료는 일정 기간 동안 종료 시 중단되는 것을 방지하기 때문에 중요하다고 합니다.
나는 이 답변을 이 프로세스를 자동화하기 위한 기초로 사용했습니다.https://stackoverflow.com/a/47709154
답변2
다른 장치를 소유하고 있지 않다면 완전히 다른 네트워크에 있기 때문이라고 가정합니다. 즉, MAC 주소는 볼 수 없지만 가장 가까운 장치의 주소는 트래픽을 다른 최종 주소로 라우팅합니다. 장치.
종단 간 통신은 데이터 링크 계층(예: 계층 2)에서 발생하지 않는다는 점을 기억하세요.
여기서 가장 가능성이 높은 시나리오는 라우팅이 잘못 설정되었을 수 있습니다.일부클라우드 공급자의 네트워크 라우팅 테이블이 아닌 VM 및 OS 수준에서... 또는 서로 다른 네트워크(아마도 AWS 서브넷?)에 있고 서로 다른 라우팅 테이블을 가지고 있습니다.
답변3
이것을 aswer로도 추가합니다.
여러 클라우드 제공업체가상당히네트워킹에 대한 독특한 관점을 갖고 네트워킹 전문가가 터무니없다고 생각하는 방식으로 이를 처리합니다. 그러나 이것이 그들이 작동하는 방식이므로 우리는 그것을 처리해야 합니다.
Azure에서 MAC 주소는 아무런 의미가 없습니다. 12-34-56-78-9a-bc모든 Azure 네트워킹은 IP 계층에서 처리되고 ARP는 존재하지 않거나 전혀 작동하지 않기 때문에 모든 ARP 테이블 항목은 항상 를 가리킵니다 . Azure VM은 단순히 "이 IP 주소가 있습니다"("무상 ARP"라고도 함)라고 외칠 수 없습니다. Azure 플랫폼이 해당 VM으로 트래픽을 라우팅하려면 IP 주소에 대해 알아야 하기 때문입니다. Azure 클러스터링은 매우 이상한 방식으로 작동하므로 클러스터 앞에 매우 특이한 부하 분산 장치를 배치해야 합니다.
솔직히 이것이 AWS에서 어떻게 작동하는지 모르겠지만 더 나쁘지는 않더라도 이상하다고 생각합니다.