Назад | Перейти на главную страницу

Потеря связи с машинами VLan и VSphere

Я столкнулся с очень странной ситуацией с некоторыми виртуальными машинами в моей установке vSphere, и я не могу понять, что происходит.

Изначально я работаю с 192.168.9.0/24 сеть, где 192.168.9.254 это DHCP-сервер, 192.168.9.43 это шлюз, 192.168.9.82 это моя рабочая станция (она получила свой IP от DHCP-сервера) и 192.168.9.15 для моего коллеги.
Это работает нормально, и каждая машина в этой сети может работать с другими, все они могут пинговать друг друга, а также остальной мир через шлюз.

Установлен кластер VSphere 6.5 с тремя хостами, 192.168.9.1, 192.168.9.2 и 192.168.9.3 статические адреса соответственно. Эти машины работают под управлением ESXi версии 6.0.0, 3380124, и каждая имеет четыре сетевых адаптера, подключенных к паре стековых коммутаторов Dell N1524, причем указанные коммутаторы подключены к 192.168.9.0/24 сеть. В этом кластере есть Production сеть, которая привязана к сетевым адаптерам каждого хоста, поэтому виртуальные машины получают свои IP-адреса из 192.168.9.254 DHCP. Это также отлично работает, но из-за увеличения использования виртуальных машин диапазон IP-адресов, обслуживаемый DHCP-сервером, теперь довольно переполнен, до такой степени, что некоторые обычные пользователи не могут получить IP-адрес, если они прибывают в после полудня.

Чтобы избежать этого, я добавил новую группу портов на vSwitch для каждого хоста и дал этим группам портов одно и то же имя (VLAN) и то же значение VLAN, равное 42.
Физические коммутаторы Dell были перенастроены, чтобы разрешить использование этой VLAN вместе со стандартной по умолчанию на портах, к которым подключены сетевые адаптеры от хостов (режим магистрали). Я решил, что эта VLAN будет 10.10.10.0/24 сеть, чтобы его можно было легко отличить от обычной сети, поэтому коммутатор 10.10.10.252 статический IP-адрес в этой VLAN.

Затем я создал виртуальную машину Windows 2012 с двумя интерфейсами, один на Production (192.168.9.110), один на VLAN (10.10.10.254) и активировал роль RRAS, чтобы эта машина теперь действовала как шлюз между 10.10.10.0/24 и остальной мир.
Я создал вторую виртуальную машину Windows 2012 с одним интерфейсом на VLAN со статикой 10.10.10.253 адрес и назвал его MDC. Я активировал роли контроллера домена, DHCP и DNS. DHCP обслуживает аренду в 10.10.10.50 - 10.10.10.200 диапазон, в то время как DNS просто перенаправляет на DNS из 192.168.9.0/24 сеть

Затем я создал две виртуальные машины, одну на первом хосте, вместе с MDC и шлюзом, и одну на третьем хосте отдельно, обе подключены к VLAN сеть. Поскольку подключение работало нормально, я решил переместить существующие виртуальные машины из Temporary папку в VLAN сеть, используя эту команду PowerCLI:

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
Machine4_H3 (10.10.10.50)
Machine5_H3 (10.10.10.51)

И вот здесь я получаю очень странные результаты, когда дело доходит до сетевого подключения, как внутри VLAN и при подключении к внешнему миру:

Перед проведением этих тестов я убедился, что брандмауэры отключены на всех машинах, а также запустил arp -a на MDC, чтобы увидеть, был ли конфликт MAC-адресов и нет ли дубликатов. Машины в 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.51), Я вижу запрос PING, затем ответ PING, но Machine5_H3 жалуется, что не получил никакого ответа. Если я сделаю наоборот, я увижу запрос от 192.168.9.82 но шлюз никогда не видит ответа.

Таким образом, я считаю, что некоторые пакеты где-то сброшены, и мой главный подозреваемый - коммутатор (10.10.10.252), но я не уверен, что могу сделать, чтобы подтвердить эту теорию.

Агрегация каналов изначально была активирована на стеке коммутаторов DELL, но из-за этого возникали проблемы с подключением наших рабочих станций к виртуальным машинам, имеющим IP-адреса в 192.168.9.0/24 сеть, поэтому мы его выключили.
Однако изменение этого параметра в стеке коммутаторов ничего не изменило в описанной выше ситуации.

Должно быть, я сделал что-то не так или пропустил некоторые детали конфигурации, но я не могу понять, что это такое, и был бы признателен за любое предложение, которое поможет решить то, что для меня является загадкой.

Следуя комментарию Zac67, мы проверили конфигурацию объединения сетевых адаптеров на всех трех хостах и ​​обнаружили, что первые два использовали параметр «Маршрут на основе хэша IP», а третий хост использовал «Маршрут на основе исходного виртуального порта».

Затем мы устанавливаем для третьего хоста то же значение, что и другие, и читаем предупреждение, связанное с первым параметром, в котором говорится: «Агрегация каналов должна быть настроена на физическом коммутаторе».

Таким образом, мы вернулись к коммутатору и повторно активировали агрегацию каналов для соответствующих портов, но это сделало все подключение нестабильным, машины в 192.168.9.0/24 сеть стала частично недоступной, хотя это ничего не изменило для тех, кто 10.10.10.0/24 сеть.

Поэтому мы решили пойти противоположным путем и отключили агрегацию каналов на коммутаторах и использовали параметр «Маршрут на основе исходного виртуального порта» на всех трех хостах.

Это позволило вернуть нормальное поведение для 192.168.9.0/24 сеть и лучшая связь для 10.10.10.0/24 сеть. Я говорю лучше, потому что некоторые машины все еще были недоступны, а именно те, Host3 который даже не мог связаться с DHCP-сервером для получения IP-адреса.
Используя Wireshark для наблюдения за трафиком, мы обнаружили, что широковещательные сообщения ARP иногда фильтруются, что объясняет, почему некоторые машины не могут общаться друг с другом, но все же не дает нам никаких подсказок о возможном решении.

После того, как мы застряли на этом пару недель, не надеясь найти ответ, мы пригласили консультантов, которые в первую очередь помогли установить инфраструктуру, и они сказали нам две вещи:

  1. LACP несовместим с VLAN
  2. VLAN 42 был запрещен на одном из портов коммутатора

Таким образом, обеспечение того, чтобы конфигурация вообще не использовала LACP и снятие ограничения на порт, позволило получить полностью рабочую ситуацию.

Теперь нам остается задаться вопросом, как нам удалось запретить VLAN 42 только для одного порта коммутатора.

Что касается несовместимости LACP и VLAN, нам никогда не приходило в голову, что это может быть источником наших проблем, но теперь, когда они рассказали нам об этом, кажется, что это хорошо известная проблема при объединении коммутаторов DELL в стек, но я не смог найти окончательного ответа по этому вопросу. Но так как без него работает, то меня все устраивает.