I am having a problem with a layer 2 bridged network configuration using Linux, QEmu, and VMware ESX. The configuration works fine on a small isolated network, but once introduced into our large corporate network, problems arise in the network layer.
I am using the server edition of Ubuntu 12.04.2 and QEmu 1.5.2 built from source emulating a SPARC host with qemu-system-sparc. The configuration I am trying to achieve is shown below with IPs shown where IPs are assigned and the last byte of the MAC addresses shown for the different interfaces.
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
The eth0 and eth1 interfaces are both created through VMware, which bridges them through a single physical NIC.
The /etc/network/interfaces file for the Ubuntu machine is shown below.
# 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
In both the isolated network and the corporate network ARP packets make it through the chain of bridges, and 192.168.1.102 has correct ARP information for 192.168.1.103 and vice versa. On the isolated network, the hosts can ping each other, and all seems well with application layer connections across the bridge.
However, on the corporate network, when pinging from the host 192.168.1.103 to 192.168.1.102 the ping packet makes it outward through the bridges to 192.168.1.102. The 192.168.1.102 host then attempts to send the ICMP reply, which never makes it back to the 192.168.1.103 host.
The ARP cache on 192.168.1.102 seems correct, with the IP address of 192.168.1.103 mapping to the :56 MAC address. However, if I run tcpdump on the eth1 interface of the Ubuntu machine I see the ICMP requests coming out from the 192.168.1.103 host, but don't see the replies coming back in (despite the fact that they are leaving 192.168.1.102 when dumped from eth0 on that machine).
I have STP off, though it is running on the corporate network. The output of brctl showstp br0 shows the bridge to be forwarding even when on the corporate network.
Any idea why this isn't working on a larger and more sophisticated network, but does work in isolation? Could our switching gear on the corporate network somehow have corrupt MAC address tables?
