Проблема сетевого соединения уровня 2 с QEmu

У меня проблема с сетевой конфигурацией уровня 2, использующей Linux, QEmu и VMware ESX. Конфигурация прекрасно работает в небольшой изолированной сети, но после ее введения в нашу большую корпоративную сеть возникают проблемы на сетевом уровне.

Я использую серверную версию Ubuntu 12.04.2 и QEmu 1.5.2, созданную из исходного кода, эмулирующую хост SPARC с qemu-system-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, который соединяет их через одну физическую сетевую карту.

/etc/network/interfaces файл для машины с Ubuntu показан ниже.

# 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 и наоборот. В изолированной сети хосты могут проверять связь друг с другом, и все выглядит хорошо с соединениями прикладного уровня через мост.

Однако в корпоративной сети при пинге с хоста 192.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-адрес. Тем не менее, если я запускаю tcpdump на eth1 Интерфейс машины Ubuntu Я вижу запросы ICMP, выходящие из 192.168.1.103 хост, но не вижу ответов, возвращающихся (несмотря на то, что они уходят 192.168.1.102 когда выбрасывается из eth0 на этой машине).

У меня выключен STP, хотя он работает в корпоративной сети. Выход из brctl showstp br0 показывает мост для пересылки даже в корпоративной сети.

Любая идея, почему это не работает в более крупной и сложной сети, но работает в изоляции? Может ли наш коммутатор в корпоративной сети каким-то образом иметь поврежденные таблицы MAC-адресов?