Привет, я изо всех сил пытался заставить работать гостевую сеть при использовании macvtap в режиме VEPA между двумя виртуальными машинами на хосте. Я часами (днями) без всякого удовольствия гуглил. Действительно ли эта сетевая конфигурация работает?
Я создал vtap с помощью KVM Manager, добавив NIC, выбрав сетевой источник «macvtap», исходный режим VEPA, модель устройства: virtio.
Конфигурация выглядит так (MAC-адрес):
vm3-62 vm2-62
---------- ------------
eth1: 172.15.62.105 eth1: 172.15.62.205
(52:54:00:08:9d:8b) (52::54:00:8a:b1:0f)
+ +
| |
\ /
\ host /
macvtap1 macvtap0
(52:54:00:08:9d:8b) (52:54:00:8a:b1:0f)
\ /
\ /
\ /
bond1.62
(98:03:9b:2d:91:a2)
|
bond1
|
NIC port 1 and 2 (active/passive config)
Не уверен, что приведенное выше форматирование будет нормально. Если приведенная выше диаграмма не отформатирована, это jpeg
Сетевая карта хоста подключена к Cisco Nexus 9000, который я настроил для Reflective Relay 802.1Qbg.
На vm2-62, когда я пытаюсь выполнить ping 172.15.62.105, я получаю сообщение Destination Host Unreachable.
Когда я использую tcpdump на хосте, я вижу ARP-запрос от vm2-62, который ищет mac для 172.15.62.105 (vm3-62). Я вижу запрос на macvtap0, на bond1.62 и на bond1, но НЕ на macvtap1.
Если я вручную добавляю записи ARP на vm3-62 и vm2-62, ping работает нормально, поэтому я думаю, что отражающее реле на коммутаторе настроено нормально.
Просто кажется, что либо коммутатор не возвращает запрос ARP, либо мне нужно что-то сделать в Linux, чтобы позволить bond1.62 пересылать запрос ARP на macvtap1.
Есть предположения? .
Спасибо
К вашему сведению, на случай, если кто-то не в силах понять это, я хочу добавить, что я также пробовал предложения из этого сообщения:
"ip link set dev macvtap0 allmulticast on" вручную, а также в / etc / libvirt / hook / qemu, и добавил "interface type = 'direct' trustGuestRxFilters = 'yes'" в vn файл с помощью virsh edit.
Я дошел до сути, и проблема была в переключателе.
Таким образом, проблема оказалась в том, что коммутатор (серия Cisco Nx9000) не возвращал запрос ARP обратно. Но это было еще не все: мои системы подключены к сети VXLAN, и у меня есть L2 VTEP, настроенные с включенным подавлением arp. Когда это отключено, коммутатор действительно отражает ARP обратно на тот же порт, что и предполагалось, и все работает нормально. Я работал с инженерами Cisco, и они согласились, что VTEP также должен отражать ARP, когда включено подавление ARP (предполагается, что VTEP в этом случае отвечает на запросы ARP). Но похоже, что программное обеспечение VTEP сбивается с толку, когда его просят отправить широковещательную передачу обратно через интерфейс, на который она пришла. В любом случае cisco заявляет, что ищет исправление, а пока что обходной путь - отключить подавление arp.