我在使用Linux，QEmu和VMware ESX进行第2层桥接networkingconfiguration时遇到问题。 这个configuration在一个小的孤立的networking上运行良好，但是一旦引入到我们的大公司networking中，networking层出现问题。
我使用Ubuntu 12.04.2和QEmu 1.5.2的服务器版本，通过qemu-system-sparc模拟SPARC主机。 下面显示了我试图实现的configuration，其中显示了IP分配的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创build的，VMware通过一个物理网卡连接它们。
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
在隔离networking和企业networking中，ARP数据包都是通过网桥连接的， 192.168.1.102对于192.168.1.102有正确的ARP信息，反之亦然。 在隔离的networking上，主机可以相互ping通，并且跨桥接的应用层连接看起来都很好。
但是，在公司networking上，当从主机192.168.1.103 ping到192.168.1.102 ，ping数据包通过网桥向外发送到192.168.1.102 。 然后， 192.168.1.102主机尝试发送ICMP应答，这个应答永远不会回到192.168.1.103主机。
192.168.1.102上的ARPcaching似乎是正确的，IP地址192.168.1.103映射到:56 MAC地址。 但是，如果我在Ubuntu机器的eth1接口上运行tcpdump，则会看到来自192.168.1.103主机的ICMP请求，但是看不到回复（尽pipe它们在离开时是192.168.1.102从那台机器上的eth0倾倒出来）。
尽pipeSTP在公司networking上运行，但STP已closures。 brctl showstp br0的输出显示了即使在公司networking上也要进行转发的网桥。
任何想法，为什么这不是在一个更大，更复杂的networking工作，但孤立地工作？ 我们的公司networking上的交换机能否以某种方式损坏MAC地址表？
此问题的解决scheme是在VMware ESX虚拟交换机上启用混杂模式，如此处所述。 物理交换机和Ubuntunetworking接口都安装正确，但是VMware阻止传入stream量到达eth1接口。