Estou usando o kernel 3.0 e configurei um contêiner do Linux que é conectado a uma interface de toque no meu computador host. Esta é a configuração da ponte:
:~$ brctl show bridge-1
bridge name bridge id STP enabled interfaces
bridge-1 8000.9249c78a510b no ns3-mesh-tap-1
vethjUErij
Meu problema é que esta bridge está soltando as respostas do ARP que vêm da interface ns3-mesh-tap-1. Em vez disso, se eu preencher estaticamente as tabelas ARP e pingar diretamente tudo funciona, então tem que ser algo relacionado ao ARP.
Li sobre problemas semelhantes em posts relacionados e tentei com as soluções explicadas, mas nada parece funcionar. Especificamente:
~$ grep net.bridge /etc/sysctl.conf
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0
arptables e ebtables não estão instalados.
O iptables FORWARD está pronto para aceitar:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
As interfaces em ponte são definidas como PROMISC:
~$ ifconfig
ns3-mesh-tap-1 Link encap:Ethernet HWaddr 1a:c7:24:ef:36:1a
...
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
vethjUErij Link encap:Ethernet HWaddr aa:b0:d1:3b:9a:0a
....
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
Os macs aprendidos pela bridge estão corretos (verificados com brctl showmacs).
Qualquer insight sobre o que estou fazendo de errado seria muito apreciado.
Atenciosamente
Daniel
Eu finalmente consegui resolver o problema. O que estava acontecendo é que por trás da ponte eu tinha uma rede de malha com bugs que estava retransmitindo a solicitação ARP de volta para o segmento Ethernet de onde ela vinha, o que fazia a ponte atribuir esse endereço de origem a uma porta diferente e, portanto, quando o ARP resposta estava voltando a ponte não encaminhou para a porta adequada.