Estou tendo um problema com uma configuração de rede em ponte da camada 2 usando Linux, QEmu e VMware ESX. A configuração funciona bem em uma pequena rede isolada, mas uma vez introduzida em nossa grande rede corporativa, surgem problemas na camada de rede.
Estou usando a edição do servidor do Ubuntu 12.04.2 e do QEmu 1.5.2 construídos a partir da fonte, emulando um host SPARC com o qemu-system-sparc. A configuração que estou tentando atingir é mostrada abaixo com os IPs mostrados onde os IPs são atribuídos e o último byte dos endereços MAC mostrados para as diferentes 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
As interfaces eth0 e eth1 são criadas por meio do VMware, que as conecta por meio de uma única NIC física.
O arquivo /etc/network/interfaces para a máquina Ubuntu é mostrado abaixo.
# 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
Tanto na rede isolada quanto na rede corporativa, os pacotes ARP passam pela cadeia de pontes, e 192.168.1.102 tem informações corretas de ARP para 192.168.1.103 e vice-versa. Na rede isolada, os hosts podem fazer ping uns aos outros e tudo parece bem com as conexões da camada de aplicativos na ponte.
No entanto, na rede corporativa, ao efetuar ping do host 192.168.1.103 para 192.168.1.102 , o pacote de ping faz isso passar pelas pontes para 192.168.1.102 . Em seguida, o host 192.168.1.102 tenta enviar a resposta do ICMP, que nunca volta para o host 192.168.1.103 .
O cache ARP em 192.168.1.102 parece correto, com o endereço IP de 192.168.1.103 mapeando para o endereço :56 MAC. No entanto, se eu executar o tcpdump na interface eth1 da máquina Ubuntu, vejo as solicitações ICMP saindo do host 192.168.1.103 , mas não vejo as respostas voltando (apesar do fato de elas estarem deixando 192.168.1.102 quando descartado de eth0 nessa máquina).
Eu tenho o STP desativado, embora esteja sendo executado na rede corporativa. A saída de brctl showstp br0 mostra a ponte a ser encaminhada mesmo quando na rede corporativa.
Alguma ideia de por que isso não está funcionando em uma rede maior e mais sofisticada, mas funciona isoladamente? O nosso equipamento de comutação na rede corporativa poderia ter tabelas de endereço MAC corrompidas?
A solução para esse problema foi ativar o modo promíscuo no comutador virtual VMware ESX, conforme descrito aqui . O switch físico e as interfaces de rede do Ubuntu foram configurados corretamente, mas a VMware estava impedindo que o tráfego de entrada chegasse à interface eth1 .
Tags qemu bridge link-layer