web-dev-qa-db-ja.com

LinuxコンテナブリッジフィルターARP応答

カーネル3.0を使用しており、ホストコンピューターのタップインターフェイスにブリッジされるLinuxコンテナーを構成しました。これはブリッジ構成です：

:~$ 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はインストールされていません。

iptablesFORWARDはすべて受け入れるように設定されています。

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で確認）。

私が間違っていることについての洞察は大歓迎です。

宜しくお願いします

ダニエル

linuxbridgelxc
3
Dani Camps

私はついに問題を解決することができました。何が起こっていたのかというと、ブリッジの背後にバグのあるメッシュネットワークがあり、ARP要求を元のイーサネットセグメントに再ブロードキャストしていたため、ブリッジはその送信元アドレスを別のポートに割り当てました。返信が戻ってきましたが、ブリッジは適切なポートに転送しませんでした。

1
Dani Camps