☰

QEMU/KVM/libvirt macvtap VEPA 不工作-ARP 请求未转发

tag-icon • tag-icon linux kvm-virtualization libvirt arp
QEMU/KVM/libvirt macvtap VEPA 不工作-ARP 请求未转发

嗨，我在主机上的两个虚拟机之间使用 VEPA 模式的 macvtap 时，一直难以让客户网络正常工作。我花了几个小时（几天）在谷歌上搜索，却毫无收获。这种网络配置真的有效吗？

我使用 KVM 管理器通过添加 NIC、选择网络源“macvtap”、源模式 VEPA、设备模型：virtio 创建了 vtap。

配置如下（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

主机 NIC 连接到 cisco nexus 9000，我已将其配置为反射中继 802.1Qbg。

在 vm2-62 上，当我尝试 ping 172.15.62.105 时，出现目标主机不可达的情况。

当我在主机上使用 tcpdump 时，我可以看到来自 vm2-62 的 ARP 请求，该请求正在寻找 172.15.62.105 (vm3-62) 的 mac。我可以在 macvtap0、bond1.62 和 bond1 上看到该请求，但在 macvtap1 上看不到。

如果我手动在 vm3-62 和 vm2-62 上添加 ARP 条目，ping 可以正常工作，所以我认为交换机上的反射中继配置正确。

看起来要么是交换机没有反弹 ARP 请求，要么我需要在 Linux 中做一些事情来使 bond1.62 将 ARP 请求转发到 macvtap1。

有什么想法吗？ 。

谢谢

仅供参考，如果有人确实遇到这个问题并可能有见解，我想补充一下，我也尝试过这篇文章中的建议：

https://superuser.com/questions/944678/how-to-configure-macvtap-to-let-it-pass-multicast-packet-correctly/1501508#1501508

手动并在 /etc/libvirt/hook/qemu 中执行“ip link set dev macvtap0 allmulticast on”，然后使用 virsh edit 将“interface type='direct' trustGuestRxFilters='yes'”添加到 vn 文件中。

答案1

我确实弄清了这个问题，问题出在开关上。

因此问题在于交换机（Cisco Nx9000 系列）没有将 ARP 请求反弹回去。但问题不止于此，我的系统连接到 VXLAN 网络中，并且我已将 L2 VTEP 配置为启用了 arp 抑制。当禁用该功能时，交换机会将 ARP 反射回它应该所在的同一端口，并且一切正常。我与 Cisco 工程师合作，他们同意 VTEP 也应该在 ARP 抑制开启时反射 ARP（在这种情况下，VTEP 应该响应 ARP 请求）。但当要求 VTEP 软件将广播发送回它到达的接口时，它似乎会感到困惑。无论如何，思科表示他们正在寻找解决方案，同时解决方法是禁用 arp 抑制。

相关内容