☰

Ubuntu 服务器和 libvirt 上的桥接器出现奇怪问题；看起来像是 MAC 地址冲突

tag-icon • tag-icon ubuntu networking vlan bridge libvirt
Ubuntu 服务器和 libvirt 上的桥接器出现奇怪问题；看起来像是 MAC 地址冲突

我们已经使用网桥和 libvirt VM 很长时间了（从 Ubuntu 16.04 开始）。最近，我们遇到了网桥问题（在 VLAns 上）。我们尚未确定导致问题出现的条件。有些可以，有些则不行。

问题在于虚拟机无法与上游路由器通信。但是，虚拟机可以与主机上的网桥通信。路由器也可以与主机上的网桥通信。路由器、网桥和虚拟机使用同一子网上的静态 IP 地址。

路由器和主机之间有一个物理以太网连接。网桥在该链路上使用 VLAN。网桥在主机上通常没有 IP 地址 - 我们添加了它以进行调试。

问题似乎是网桥上的 MAC 地址冲突。ARP 请求（广播）双向通过。ARP 响应（不同目的地）到达路由器，但未到达虚拟机（网桥上看不到）。

我们使用 ifupdown（而不是 netplan）。这是出于遗留原因。

VM 是用 创建的virt-install。

一些主机已从 Ubuntu 16.04 升级到 18.04，然后升级到 20.04。其他主机从 18.04 或 20.04 开始。问题似乎更有可能出现在直接安装 20.04 时。它在一台装有 5.4.0-137-generic #154-Ubuntu 的主机上有效，但在另一台装有 5.4.0-146-generic #163-Ubuntu 的主机上无效。但我们不知道这是否一致。

在主机上：

2: wan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 48:21:0b:35:ae:51 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.5/26 brd 172.16.200.63 scope global wan0
       valid_lft forever preferred_lft forever
    inet 172.16.200.6/26 scope global secondary wan0
       valid_lft forever preferred_lft forever
    inet6 fe80::4a21:bff:fe35:ae51/64 scope link 
       valid_lft forever preferred_lft forever

11: wan0.202@wan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP group default qlen 1000
    link/ether 48:21:0b:35:ae:51 brd ff:ff:ff:ff:ff:ff

9: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client state UNKNOWN group default qlen 1000
    link/ether fe:54:00:6c:23:ef brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe6c:23ef/64 scope link 
       valid_lft forever preferred_lft forever

12: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 48:21:0b:35:ae:51 brd ff:ff:ff:ff:ff:ff
    inet 192.168.202.231/24 brd 192.168.202.255 scope global br-client
       valid_lft forever preferred_lft forever
    inet6 fe80::4a21:bff:fe35:ae51/64 scope link 
       valid_lft forever preferred_lft forever

在虚拟机上：

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 52:54:00:6c:23:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.202.234/24 brd 192.168.202.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe6c:23ef/64 scope link 
       valid_lft forever preferred_lft forever

主机上的 libvirt 网络：

 Interface   Type     Source      Model    MAC
--------------------------------------------------------------
 vnet0       bridge   br-client   virtio   52:54:00:6c:23:ef

更新：

主机上的物理接口（wan0）似乎无法处理以虚拟机 MAC 地址为目的地的帧。当目的地是网桥的 MAC 地址时，wan0 上的 tcpdump 会显示 VLAN 帧，但 tcpdump 不会显示以虚拟机 MAC 地址为目的地的任何 VLAN 帧。路由器上的 tcpdump 显示带有虚拟机 MAC 的帧在正确的线路上发送。

VM 的 MAC 地址如何传递到处理来自线路的帧的虚拟交换机？

答案1

您可以尝试以下几件事，首先检查网桥是否允许 MAC 地址，bridge fdb show br-client如果缺少则添加它bridge fdb add 52:54:00:6c:23:ef dev br-client，

还要检查桥接配置，例如此桥接器是用来创建的，wan0但应该wan0.202相应地修复它，然后您可以验证主机、虚拟机等之间的 MAC 冲突...

还要检查主机的 iptables 和 ebtables 规则，以查找虚拟机 MAC 地址的阻止规则。然后，您还可以确保您的网络接口配置为使用正确的源桥和 MAC

<interface type='bridge'>
  <mac address='52:54:00:6c:23:ef'/>
  <source bridge='br-client'/>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

答案2

我们决定升级到 Ubuntu 22.04（反正它即将问世），问题就解决了。VLAN、网桥和 VM 都按预期运行。

#154-Ubuntu我所能猜测的是，在和之间引入了一些细微的错误#163-Ubuntu，并在 Ubuntu 22.04（#76-Ubuntu）中修复了。

不知道确实很令人沮丧，但我们必须继续前进。

相关内容