☰

Linux 容器桥接过滤 ARP 回复

tag-icon • tag-icon linux bridge lxc
Linux 容器桥接过滤 ARP 回复

我使用的是内核 3.0，并且配置了一个 Linux 容器，该容器桥接到主机中的 Tap 接口。这是桥接配置：

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

我的问题是，这个网桥丢弃了来自 ns3-mesh-tap-1 接口的 ARP 回复。相反，如果我静态填充 ARP 表并直接 ping 一切正常，所以这一定是与 ARP 有关的事情。

我在相关文章中读到过类似的问题，也尝试过其中解释的解决方案，但似乎没有任何效果。具体来说：

~$ 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 和 ebtables。

iptables FORWARD 已全部设置为接受：

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

桥接接口设置为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

网桥学习到的 mac 是正确的（使用 brctl showmacs 检查）。

任何有关我做错什么的见解都将不胜感激。

此致

丹尼尔

答案1

我终于解决了这个问题。事情的原因是，在桥后面，我有一个有问题的网状网络，它将 ARP 请求重新广播回它来自的以太网段，这使得桥将该源地址分配给不同的端口，因此当 ARP 回复回来时，桥没有将其转发到正确的端口。

相关内容