QEmu 的第 2 層橋接網路問題

我在使用 Linux、QEmu 和 VMware ESX 進行第 2 層橋接網路配置時遇到問題。該配置在小型隔離網路上執行良好，但一旦引入我們的大型企業網路，網路層就會出現問題。

我正在使用從原始碼建構的 Ubuntu 12.04.2 和 QEmu 1.5.2 伺服器版本，使用 qemu-system-sparc 模擬 SPARC 主機。我試圖實現的配置如下所示，其中顯示了分配 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 創建的，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.102ping 數據包時，它會通過網橋向外發送到192.168.1.102. 然後192.168.1.102主機嘗試發送 ICMP 回复，但該回复永遠不會返回給192.168.1.103主機。

ARP記憶體上192.168.1.102似乎是正確的，將IP地址192.168.1.103映射到:56MAC地址。但是，如果我在 Ubuntu 機器的介面上執行 tcpdump，eth1我會看到來自192.168.1.103主機的 ICMP 請求，但看不到返回的回复（儘管192.168.1.102從那台機器上轉儲時它們會離開eth0）。

我關閉了 STP，儘管它在公司網路上執行。的輸出brctl showstp br0顯示即使在公司網路上也要轉發的網橋。

知道為什麼這不適用於更大、更複雜的網路，而是孤立地工作嗎？我們在公司網路上的交換設備會以某種方式損壞 MAC 地址表嗎？

此問題的解決方案是在 VMware ESX 虛擬交換機上啟用混雜模式，如此處所述。物理交換機和 Ubuntu 網路介面均設置正確，但 VMware 阻止傳入流量進入eth1介面。

引用自：https://serverfault.com/questions/529069