☰

VLan 및 VSphere 시스템과의 연결 손실

tag-icon • tag-icon networking vmware-vsphere vlan local-area-network vmware-esx
VLan 및 VSphere 시스템과의 연결 손실

vSphere 설정의 일부 가상 머신에서 매우 이상한 상황에 직면했는데 무슨 일이 일어나고 있는지 잘 알 수 없습니다.

원래 저는 DHCP 서버, 게이트웨이, 내 워크스테이션(DHCP 서버에서 IP를 받음) 및 동료용 192.168.9.0/24네트워크를 사용하여 작업하고 있습니다 . 이것은 잘 작동하며 해당 네트워크의 모든 시스템은 다른 시스템과 함께 작동할 수 있습니다. 그들은 모두 게이트웨이를 통해 서로뿐만 아니라 나머지 세계에도 핑을 보낼 수 있습니다.192.168.9.254192.168.9.43192.168.9.82192.168.9.15

192.168.9.1VSphere 6.5 클러스터가 각각 , 192.168.9.2및 192.168.9.3정적 주소를 갖는 3개의 호스트와 함께 설치되었습니다 . 해당 시스템은 ESXi 버전 6.0.0, 3380124를 실행하고 있으며 각 시스템에는 스택형 Dell N1524 스위치 쌍에 연결된 4개의 NIC가 있으며, 해당 스위치는 네트워크에 연결되어 있습니다 192.168.9.0/24. 해당 클러스터에는 Production각 호스트 NIC에 연결된 네트워크가 있으므로 VM은 192.168.9.254DHCP에서 IP를 얻습니다. 이 방법도 잘 작동하지만 VM 사용량이 증가했기 때문에 DHCP 서버가 제공하는 IP 범위가 이제 상당히 혼잡해 일부 일반 사용자가 DHCP 서버에 도착하면 IP 주소를 얻을 수 없는 수준이 되었습니다. 오후.

이를 방지하기 위해 각 호스트에 대해 vSwitch에 새 포트 그룹을 추가하고 해당 포트 그룹에 동일한 이름( VLAN)과 동일한 VLAN 값(42)을 부여했습니다
. Dell 물리적 스위치는 기본 스위치와 함께 해당 VLAN을 허용하도록 재구성되었습니다. 하나는 호스트의 NIC가 연결된 포트에 있습니다(트렁크 모드). 나는 이 VLAN을 일반 네트워크에서 쉽게 인식할 수 있도록 네트워크로 결정하고 10.10.10.0/24스위치에 10.10.10.252해당 VLAN의 고정 IP를 제공했습니다.

Production그런 다음 (192.168.9.110)과 VLAN( ) 에 하나씩 두 개의 인터페이스가 있는 Windows 2012 가상 머신을 생성하고 RRAS 역할을 활성화하여 이 머신이 이제 세계와 나머지 세계 10.10.10.254사이의 게이트웨이 역할을 하도록 했습니다 . 고정 주소를 사용 하여 인터페이스가 하나만 있는 두 번째 Windows 2012 가상 머신을 만들고 이름을 . 도메인 컨트롤러, DHCP 및 DNS 역할을 활성화했습니다. DHCP는 범위 내에서 임대를 제공하는 반면 DNS는 단순히 네트워크 에서 DNS로 전달합니다.10.10.10.0/24
VLAN10.10.10.253MDC10.10.10.50 - 10.10.10.200192.168.9.0/24

그런 다음 MDC 및 게이트웨이와 함께 첫 번째 호스트에 하나, 세 번째 호스트 자체에 하나, 둘 다 네트워크에 연결된 두 개의 가상 머신을 만들었습니다 VLAN. 연결이 제대로 작동하는 것으로 보이므로 다음 PowerCLI 명령을 사용하여 기존 VM을 Temporary폴더에서 네트워크로 이동하기로 결정했습니다 .VLAN

Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -NetworkName VLAN

vmxnet3또한 모든 네트워크 어댑터가 이 명령을 사용 하는지 확인할 기회도 얻었습니다.

Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -Type vmxnet3

연결이 여전히 양호했기 때문에 네트워크에 연결되어 세 호스트 모두에 배치된 또 다른 가상 머신 묶음을 생성하여 VLAN다음 토폴로지를 제공합니다.

호스트 1
MDC ( 10.10.10.253)
게이트웨이 ( 10.10.10.254– 192.168.9.110)
Machine1_H1 ( 10.10.10.64)
Machine2_H1 ( 10.10.10.57)

호스트 2
Machine3_H2( 10.10.10.65)

호스트 3
기계4_H3( 10.10.10.50)
기계5_H3( 10.10.10.51)

VLAN그리고 내부 및 외부 세계에 연결할 때 네트워크 연결과 관련하여 매우 이상한 결과가 나타나는 곳이 바로 여기입니다 .

  • MDC는 스위치( 10.10.10.252) 를 제외한 모든 사람에게 ping을 보낼 수 있습니다.
  • 게이트웨이는 Machine5_H3을 제외한 모든 사람에게 ping을 보낼 수 있습니다.
  • Machine1_H1은 Machine3_H2를 제외한 모든 사람에게 ping을 보낼 수 있습니다.
  • Machine2_H1은 스위치( 10.10.10.252) 를 제외한 모든 사람에게 ping을 보낼 수 있습니다.
  • Machine3_H2는 호스트 1과 Machine1_H1을 제외한 모든 사람에게 ping을 보낼 수 있습니다.
  • 192.168.9.43Machine4_H3는 , 192.168.9.15및 를 제외한 모든 사람을 ping할 수 있습니다 google.fr(이름 확인은 괜찮습니다).
  • Machine5_H3은 192.168.9.254, 192.168.9.82(내 워크스테이션) 및10.10.10.254
  • 내 컴퓨터( 192.168.9.82)는 Machine5_H3( 10.10.10.51) 을 제외한 모든 사람에게 ping을 보낼 수 있습니다.

이 테스트를 수행하기 전에 모든 컴퓨터에서 방화벽이 꺼져 있는지 확인했고, arp -aMAC 주소 충돌이 있는지, 중복이 없는지 확인하기 위해 MDC에서도 실행했습니다. 만약을 대비해 폴더 에 있는 컴퓨터 Temporary도 모두 꺼졌지만 위의 결과에는 아무런 변화가 없었습니다. 안전을 위해 다음 코드 조각을 사용하여 해당 컴퓨터에 대한 새 MAC 주소를 강제로 생성했습니다.

foreach ($VM in (Get-Folder Temporary | Get-VM))
{
  $NetworkAdapter = $VM | Get-NetworkAdapter
  $NetworkAdapter | Set-NetworkAdapter -MacAddress 00:50:56:1a:ff:ff -Confirm:$false
  $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
  $spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
  $spec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
  $spec.deviceChange[0].operation = "edit"
  $spec.deviceChange[0].device = $NetworkAdapter.ExtensionData
  $spec.deviceChange[0].device.addressType = "generated"
  $spec.deviceChange[0].device.macAddress = $null
  $VM.ExtensionData.ReconfigVM_Task($spec)
}

그것은 상황을 바꾸지 않았습니다.

그런 다음 게이트웨이에 Wireshark를 설치하고 트래픽 모니터링을 시작했으며 10.10.10.254해당 시스템과 관련된 모든 트래픽을 볼 수 있었습니다. 예를 들어, 내 워크스테이션( 192.168.9.82)이 Machine5_H3( )에 의해 핑 되면 10.10.10.51PING 요청과 PING 응답을 볼 수 있지만 Machine5_H3은 아무런 응답도 받지 못했다고 불평합니다. 반대로 하면 요청을 볼 수 있지만 192.168.9.82게이트웨이에서는 응답을 볼 수 없습니다.

따라서 나는 일부 패킷이 어딘가에서 삭제되었다고 생각합니다. 주요 용의자는 스위치( 10.10.10.252)이지만 이 이론을 확인하기 위해 무엇을 할 수 있는지 잘 모르겠습니다.

링크 집계는 원래 DELL 스위치 스택에서 활성화되었지만 워크스테이션에서 네트워크에 IP가 있는 VM으로 연결하는 데 문제가 발생하여 192.168.9.0/24이를 껐습니다.
그러나 스위치 스택에서 이 설정을 변경해도 위 상황은 변경되지 않았습니다.

뭔가 잘못했거나 일부 구성 세부 사항을 놓쳤음에 틀림없지만 그것이 무엇인지 알 수 없으며 무엇이 나에게 미스터리인지 해결하는 데 도움이 되는 제안을 주시면 감사하겠습니다.

답변1

Zac67의 의견에 따라 우리는 세 호스트 모두에서 NIC 팀 구성을 확인했으며 처음 두 호스트는 "IP 해시 기반 경로" 매개 변수를 사용하고 세 번째 호스트는 "원래 가상 포트 기반 경로"를 사용하고 있음을 발견했습니다.

그런 다음 세 번째 호스트를 다른 호스트와 동일한 값으로 설정하고 "링크 집계는 물리적 스위치에 설정되어야 합니다"라는 첫 번째 옵션과 관련된 경고를 읽습니다.

따라서 우리는 스위치로 돌아가 적절한 포트에 대한 링크 통합을 다시 활성화했지만 이로 인해 전체 연결이 불안정해졌고 네트워크에 있는 시스템에 192.168.9.0/24대해서는 아무것도 변경되지 않았지만 10.10.10.0/24네트워크의 시스템에 부분적으로 연결할 수 없게 되었습니다.

그래서 우리는 반대 방향으로 가기로 결정하고 스위치에서 링크 집계를 비활성화하고 세 호스트 모두에서 "원래 가상 포트 기반 경로" 옵션을 사용했습니다.

이를 통해 네트워크의 정상적인 동작을 되찾고 192.168.9.0/24네트워크 연결성을 향상할 수 있었습니다 10.10.10.0/24. 일부 컴퓨터는 여전히 연결할 수 없기 때문에 더 나은 말을 하는 것입니다. 즉, Host3IP를 검색하기 위해 DHCP 서버에 연결할 수도 없는 컴퓨터입니다.
Wireshark를 사용하여 트래픽을 관찰한 결과 ARP가 때때로 필터링되는 곳에서 브로드캐스트한다는 사실을 발견했습니다. 따라서 일부 시스템이 서로 통신할 수 없지만 여전히 가능한 솔루션에 대한 단서를 제공하지 못하는 이유를 설명할 수 있습니다.

답을 찾을 희망도 없이 몇 주 동안 이 문제에 매달린 후, 우리는 우선 인프라 설치를 도운 컨설턴트를 데려왔고 그들은 우리에게 두 가지를 말했습니다.

  1. LACP는 VLAN과 호환되지 않습니다.
  2. 스위치 포트 중 하나에서 VLAN 42가 금지되었습니다.

따라서 구성에서 LACP를 전혀 사용하지 않았는지 확인하고 포트에 대한 제한을 제거하여 완전히 작동하는 상황에 도달할 수 있었습니다.

이제 스위치의 한 포트에서만 VLAN 42를 금지할 수 있었던 방법이 궁금합니다.

LACP와 VLAN 비호환성에 관해서는 이것이 문제의 원인이 될 수 있다는 생각은 전혀 하지 못했습니다. 그러나 이제 그들이 이에 대해 이야기한 것을 보니 DELL 스위치를 스태킹할 때 잘 알려진 문제인 것 같지만 확실한 답을 찾을 수 없었습니다. 주제에. 하지만 그것 없이도 작동하기 때문에 나에게는 괜찮습니다.

관련 정보