web-dev-qa-db-ja.com

パケットがLinuxイーサネットブリッジを通過しない

Eth0とeth1をブリッジしてdebian 8.3マシンをセットアップしようとしていますが、パケットをブリッジを通過させることができません。現在、eth0はDHCPサーバーを含む他の多くのホストとLANに接続されています。 Eth1は通常のスイッチに接続され、1台のマシンが接続されています。

これは私の/ etc/network/interfacesです:

iface eth0 inet manual
iface eth1 inet manual

allow-hotplug br0
auto br0
iface br0 inet static
        bridge_ports eth0 eth1
        address 172.16.1.111
        netmask 255.255.0.0
        broadcast 172.16.255.255
        gateway 172.16.1.254
        dns-servers 172.16.1.1

/ proc/sys/net/ipv4/ip_forwardは1に設定されます。

Eth1ネットワークに接続されたテストマシンで実行されているtcpdumpによると、テストマシンはDHCP要求を送信していますが、ブリッジホストで実行されているtcpdumpによると、そのような要求は受信していません。

Eth1に接続されたスイッチに接続された別のホストも、テストマシンが実際にDHCP要求を送信していることを確認できますが、ブリッジホストでtcpdumpを実行すると、着信DHCP要求が表示されません。

ブリッジホストのeth1でtcpdumpを実行すると、ネットワークのeth0側から発信されたと思われるパケットがeth1から送信されることがわかりますが、tcpdumpがそれらのパケットがeth1を出ていると主張しているにもかかわらず、eth1のネットワーク上のホストは、それら。

Eth1に接続されたテストマシンに静的IP 172.16.1.112を指定すると、ブリッジホスト(172.16.1.111)からのping応答が得られません。スイッチに接続された別のホストは、テストホストがarp who-has 172.16.1.111要求を送信しているのを確認できますが、ブリッジホストのeth1で実行されているtcpdumpは、着信arp要求を示していません。

ブリッジをまとめて削除した場合、eth1に192.168.200.1のIPを割り当て、テストマシンをeth1に接続して192.168.200.2のIPを割り当て、ping、ssh、その他すべてが機能し、物理的に何も問題がないことを示しますネットワーク接続。また、両方のインターフェースで「ifconfig ethx promisc up」を実行しても解決しませんでした。

Ifconfigから:

br0       Link encap:Ethernet  HWaddr 00:22:19:d5:48:a5  
          inet addr:172.16.1.111  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::222:19ff:fed5:48a5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1789546 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7077 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:89574606 (85.4 MiB)  TX bytes:1096756 (1.0 MiB)

eth0      Link encap:Ethernet  HWaddr 00:22:19:d5:48:a5  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1796423 errors:0 dropped:6430 overruns:0 frame:0
          TX packets:7124 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:123614592 (117.8 MiB)  TX bytes:1159358 (1.1 MiB)
          Interrupt:16 

eth1      Link encap:Ethernet  HWaddr 00:22:19:d5:48:a6  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:6437 errors:0 dropped:6435 overruns:0 frame:0
          TX packets:1782083 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1737578 (1.6 MiB)  TX bytes:121076196 (115.4 MiB)
          Interrupt:17

他の場所はebtablesについて話しました、これは私が持っているものです:

root@face:~# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

そして、iptables:

# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*mangle
:PREROUTING ACCEPT [160073:12825881]
:INPUT ACCEPT [125398:10762899]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2598:515898]
:POSTROUTING ACCEPT [2598:515898]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*filter
:INPUT ACCEPT [125467:10767745]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2631:519386]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016
# Generated by iptables-save v1.4.21 on Fri Mar 25 12:07:16 2016
*nat
:PREROUTING ACCEPT [59097:4965900]
:INPUT ACCEPT [24420:2902790]
:OUTPUT ACCEPT [513:27017]
:POSTROUTING ACCEPT [513:27017]
COMMIT
# Completed on Fri Mar 25 12:07:16 2016

brctlもの:

root@face:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.002219d548a5       no              eth0
                                                        eth1
root@face:~# bridge link show
2: eth0 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4 
3: eth1 state UP : <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19 
root@face:~# 

私は何かばかげたことを見逃しているに違いありませんが、それが何であるかはわかりません。何が悪いのですか?

編集:確かに、上記で貼り付けたiptables-saveダンプが実行中のiptables構成全体であったことを確認できます。再起動後、iptables-saveは何も返しません。

また、 "bridge_fd 0"と "bridge_maxwait 1"をインターフェース設定のbr0セクションに追加しましたが、変更後の再起動から約10分経過しましたが、トラフィックはどこにも届きません。

私はeth0とeth1のコードを入れ替えましたが、eth0が接続されているところはどこでも、br0がpingに応答するように見えます。数分のpingの後、トラフィックはまだ通り抜けていません。

問題をさらに調査するために、/ etc/udev/rules.d/70-persistent-net.rulesのMACアドレスを交換して、eth0がeth1になり、eth1が以前のeth0 MACアドレスを持つようにしました。再起動後、br0にはまだeth0のMacがあり、現在はeth1になっています。これは、着信パケットを確認する唯一のサイドです。 br0をeth0またはeth1以外の3番目のMACアドレスに設定できますか?

5
richd

これはかなり古い質問ですが、他の人に役立つかもしれません。

Linuxブリッジは、正しく構成されていない場合、パッケージをドロップする可能性があります。私にも同様の問題があり、次の情報で解決できました:

つまり、ブリッジを構成するオプションがあります。

# do not query iptables for package routing
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

# no additional processing for multicast packages
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_querier
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
3
smilee89

設定はおおまかに正しいように見えます(つまり、大幅な問題はありません)。

ただし、スパニングツリー遅延の値がありません。つまり、ブリッジは起動されてから15秒間(デフォルト値)パケットを転送しません。 bridge_fdをインターフェース構成に追加して修正します。他の関連するブリッジがない場合は値0を使用し、ネットワークにループがある可能性がある場合は値を大きくします。

また、値を追加している間は、ブリッジの初期化中に進む前に待機する最大時間を短縮することをお勧めします。通常、bridge_maxwaitbridge_fdの値よりも1秒長く設定することで十分であることがわかりました。

bridge_fd 0
bridge_maxwait 1
2
roaima