Назад | Перейти на главную страницу

Проблема с сетевым мостом уровня 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-адресов?

Решением этой проблемы было включение неразборчивого режима на виртуальном коммутаторе VMware ESX, как описано Вот. Физический коммутатор и сетевые интерфейсы Ubuntu были настроены правильно, но VMware препятствовала тому, чтобы входящий трафик когда-либо попадал на eth1 интерфейс.