[s.lobanov]

Берётся ESXi 5.0, запускается 2 виртуалки(linux), eth0 гостей подключен к стандартному vmware свитчу, vlan 4095 (пропуск тегированного трафика)

 

vm1:

vconfig add eth0 100

ifconfig eth0.100 1.1.1.1 up

vconfig add eth0 101

ifconfig eth0.101 hw ether 00:11:22:33:44:55

ifconfig eth0.101 2.1.1.1 up

 

vm2:

vconfig add eth0 100

ifconfig eth0.100 1.1.1.2 up

vconfig add eth0 101

ifconfig eth0.101 2.1.1.2 up

 

Теперь с vm1 запускаем:

ping 1.1.1.2 - OK

ping 2.1.1.2 - 100% loss

 

На vm2 смотрим tcpdump'ом что происходит, когда с vm1 запущен ping 1.1.1.2. tcpdump говорит, что arp запрос с eth-адреса 00:11:22:33:44:55 в vlan 101 приходит, отправляется ответ на этот arp unicast'ом на адрес 00:11:22:33:44:55, ответ не доходит(это видно, запустив tcpdump на vm1)

 

Как я понимаю, стандартный esxi свитч не изучает мак-адреса, а формирует свою таблицу статически(исходя из конфигурации подключенных vm), а unknown unicast не коммутирует как broadcast. Это так? Кто-нибудь пробовал использовать 2 мак-адреса на одном физическом интерфейсе на esxi? (в разных сабах или macvlan)

 

Если это так, то использование виртуальной Cisco Nexus вместо стандартного свитча спасёт? (оно изучает мак-адреса со сторону guest-машин?)

[pliskinsad]

Да, свитч в vmware не изучает мак адреса.

Решить проблему можно изменив security настройки в свойствах виртуального свитча, либо включить для него promiscuous mode.

http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp#securing_an_esx_configuration/c_securing_virtual_switch_ports.html

Вот статья про security свитчей, внизу описание крутилок и зачем и как крутить.

[s.lobanov]

Настройки security по умолчанию accept (кроме promis).

Собственно сегодня был найден workaround в виде создания стандартного виртуального свитча для каждого линка между guest-машинами и включением promiscuous mode на этих свитчах. Теперь между guest-машины как будто бы прямой линк