Я столкнулся с очень странной ситуацией с некоторыми виртуальными машинами в моей настройке 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.254DHCP. Это также работает просто отлично, но из-за увеличения использования виртуальных машин диапазон IP-адресов, обслуживаемый DHCP-сервером, теперь довольно переполнен, до такой степени, что некоторые обычные пользователи не могут получить IP-адрес, если они приходят днем.
Чтобы избежать этого, я добавил новую группу портов на vSwitch для каждого хоста и дал этим группам портов одно и то же имя ( VLAN) и одно и то же значение VLAN, равное 42.
Физические коммутаторы Dell были перенастроены, чтобы разрешить эту VLAN вместе с 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 и Gateway, и одну на третьем хосте отдельно, обе подключены к сети 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)
Машина1_H1 ( 10.10.10.64)
Машина2_H1 ( 10.10.10.57)
Хост 2
Машина3_H2 ( 10.10.10.65)
Хост 3
Машина4_H3 ( 10.10.10.50)
Машина5_H3 ( 10.10.10.51)
И вот тут я получаю очень странные результаты, когда дело касается сетевого подключения, как внутри, так VLANи при подключении к внешнему миру:
- MDC может пинговать всех, кроме коммутатора (
10.10.10.252) - Шлюз может пинговать всех, кроме Machine5_H3
- Machine1_H1 может пинговать всех, кроме Machine3_H2
- Machine2_H1 может пинговать всех, кроме коммутатора (
10.10.10.252) - Machine3_H2 может пинговать всех, кроме Host 1 и Machine1_H1
- Machine4_H3 может пинговать всех, кроме
192.168.9.43,192.168.9.15и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)
Я убедился, что брандмауэры отключены на всех машинах, прежде чем проводить эти тесты, а также запустил arp -aMDC, чтобы проверить, нет ли конфликта 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, поэтому мы ее отключили.
Однако изменение этой настройки на стеке коммутаторов ничего не изменило в вышеописанной ситуации.
Должно быть, я что-то сделал не так или упустил какие-то детали конфигурации, но я не могу понять, что именно, и буду признателен за любые предложения, которые помогут мне решить эту загадку.
решение1
После комментария 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 иногда фильтруются, что объясняет, почему некоторые машины не могут общаться друг с другом, но все еще не дает нам никаких подсказок о возможном решении.
Провозившись с этой проблемой пару недель без всякой надежды найти ответ, мы обратились к консультантам, которые изначально помогали устанавливать инфраструктуру, и они сказали нам две вещи:
- LACP несовместим с VLAN
- VLAN 42 был запрещен на одном из портов коммутатора
Таким образом, обеспечение того, чтобы конфигурация вообще не использовала LACP, и снятие ограничения на порт позволили добиться полностью рабочей ситуации.
Теперь нам остается только гадать, как нам удалось запретить VLAN 42 только на одном порту коммутатора.
Что касается несовместимости LACP и VLAN, нам никогда не приходило в голову, что это может быть источником наших проблем, но теперь, когда они рассказали нам об этом, похоже, это известная проблема при стекировании коммутаторов DELL, но я не смог найти никакого определенного ответа на этот счет. Но поскольку все работает без этого, меня все устраивает.