![QEmu 的第 2 层桥接网络问题](https://linux22.com/image/803376/QEmu%20%E7%9A%84%E7%AC%AC%202%20%E5%B1%82%E6%A1%A5%E6%8E%A5%E7%BD%91%E7%BB%9C%E9%97%AE%E9%A2%98.png)
我在使用 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
映射到:56
MAC 地址。但是,如果我在eth1
Ubuntu 机器的接口上运行 tcpdump,我会看到 ICMP 请求从主机发出192.168.1.103
,但没有看到回复回来(尽管它们192.168.1.102
在从该机器上转储时会离开eth0
)。
尽管 STP 在公司网络上运行,但我已将其关闭。输出brctl showstp br0
显示网桥即使在公司网络上也处于转发状态。
知道为什么这在更大更复杂的网络上不起作用,但在孤立的情况下却有效吗?我们公司网络上的交换设备是否可能以某种方式损坏了 MAC 地址表?
答案1
解决此问题的方法是按照说明在 VMware ESX 虚拟交换机上启用混杂模式这里。物理交换机和 Ubuntu 网络接口都设置正确,但 VMware 阻止传入流量到达该eth1
接口。