Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
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 –  Olipro Jun 25 '13 at 4:23
    
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. –  Dani Camps Jun 25 '13 at 17:22

1 Answer 1

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.

share|improve this answer
2  
So Dani, how did you solve it? I have just the same problem you describe. –  user204782 Jan 8 at 15:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.