☰

QEmu 的第 2 层桥接网络问题

tag-icon • tag-icon bridge qemu link-layer
QEmu 的第 2 层桥接网络问题

我在使用 Linux、QEmu 和 VMware ESX 进行第 2 层桥接网络配置时遇到了问题。该配置在小型独立网络上运行良好，但一旦引入我们的大型企业网络，网络层就会出现问题。

我使用的是 Ubuntu 12.04.2 服务器版本和 QEmu 1.5.2，它们使用 qemu-system-sparc 从源代码构建，模拟 SPARC 主机。我尝试实现的配置如下所示，其中显示了分配 IP 的位置，并显示了不同接口的 MAC 地址的最后一个字节。

    le0 (on QEmu hosted machine)
    192.168.1.103
    :56
    |
    tap0 (on Ubuntu machine)
    :7e                         
    |
    br0 (on Ubuntu machine)
    :19
    |
    eth1        eth0    (eth1 and eth0 on Ubuntu machine)
                192.168.1.100
    :19         :0f
    |           |
===========================
    Corporate Network
===========================
        |
        eth0
        192.168.1.102
        :84

eth0和接口eth1都是通过 VMware 创建的，它通过单个物理 NIC 将它们连接起来。

Ubuntu 机器的文件/etc/network/interfaces如下所示。

# The loopback network interface
auto lo
iface lo inet loopback

auto eth1
iface eth1 inet manual

auto tap0
iface tap0 inet manual
    pre-up tunctl -u my-user -t tap0
    up ip link set tap0 up

auto br0
iface br0 inet manual
    bridge_ports tap0 eth1
    bridge_fd 15
    bridge_hello 2
    bridge_maxage 20
    bridge_stp off
    bridge_waitport 60
    bridge_pathcost eth1 32768
    bridge_maxwait 0

# The primary network interface
auto eth0
iface eth0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    gateway 192.168.1.1

在隔离网络和公司网络中，ARP 数据包都通过了桥接链，并192.168.1.102具有正确的 ARP 信息，192.168.1.103反之亦然。在隔离网络上，主机可以相互 ping，并且跨桥接的应用层连接一切正常。

然而，在公司网络上，当从主机 ping192.168.1.103到时192.168.1.102，ping 数据包会通过网桥向外发送192.168.1.102。192.168.1.102主机随后尝试发送 ICMP 回复，但该回复永远不会返回到主机192.168.1.103。

上的 ARP 缓存192.168.1.102似乎正确，IP 地址192.168.1.103映射到:56MAC 地址。但是，如果我在eth1Ubuntu 机器的接口上运行 tcpdump，我会看到 ICMP 请求从主机发出192.168.1.103，但没有看到回复回来（尽管它们192.168.1.102在从该机器上转储时会离开eth0）。

尽管 STP 在公司网络上运行，但我已将其关闭。输出brctl showstp br0显示网桥即使在公司网络上也处于转发状态。

知道为什么这在更大更复杂的网络上不起作用，但在孤立的情况下却有效吗？我们公司网络上的交换设备是否可能以某种方式损坏了 MAC 地址表？

答案1

解决此问题的方法是按照说明在 VMware ESX 虚拟交换机上启用混杂模式这里。物理交换机和 Ubuntu 网络接口都设置正确，但 VMware 阻止传入流量到达该eth1接口。

相关内容