linux container bridge filters ARP reply

Question

I am using kernel 3.0, and I have configured a linux container that is bridged to a tap interface in my host computer. This is the bridge configuration:

:~$ brctl show bridge-1
bridge name             bridge id               STP enabled     interfaces
bridge-1                8000.9249c78a510b       no              ns3-mesh-tap-1
                                                                vethjUErij

My problem is that this bridge is dropping ARP replies that come from the ns3-mesh-tap-1 interface. Instead, if I statically populate the ARP tables and ping directly everything works, so it has to be something related to ARP.

I have read about similar problems in related posts, and I have tried with the solutions explained therein but nothing seems to work. Specifically:

~$ 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 and ebtables are not installed.

iptables FORWARD is all set to accept:

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

The bridged interfaces are set to 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

The macs learned by the bridge are correct (checked with brctl showmacs).

Any insight on what I am doing wrong would be greatly appreciated.

Best Regards

Daniel

Solution

I finally could solve the problem. What was happening is that behind the bridge I had a buggy mesh network that was re-broadcasting the ARP request back into the ethernet segment where it came from, which made the bridge assign that source address to a different port, and so when the ARP reply was coming back the bridge did not forward it to the proper port.

Comments

[Olipro]

do you have IP addresses configured on the bridge ports or the bridge interface itself? What is the value of net.ipv4.conf.<interface>.arp_filter

[Dani Camps]

Hi, I made some further discovery. The setup I have is the linux container with an eth0 interface, and its correspoding veth peer interface which is vethjUErij. When I first start the lxc then the lxc-eth0 interface and vethjUErij are both in the same port of the bridge, which is correct. However, when I start pinging from the lxc then lxc-eth0 moves to the wrong port of the bridge, this is why the arp reply is not forwarded. I still do not know though why the mac changes port.

[Dan Wood]

So Dani, how did you solve it? I have just the same problem you describe.