☰

Linuxイーサネットブリッジを介してパケットが移動しない

tag-icon • tag-icon linux debian networking ethernet bridge
Linuxイーサネットブリッジを介してパケットが移動しない

eth0とeth1はブリッジされたDebian 8.3システムを設定しようとしましたが、ブリッジを介してパケットを取得できませんでした。現在、eth0はDHCPサーバーを含む他の多くのホストと一緒にLANに接続されています。 Eth1は通常のスイッチに接続され、マシンに接続されます。

これは私の/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 側から出ると推定されるパケットが表示されます。しかし、tcpdumpでは、これらのパケットがeth1から出ていると主張しても、eth1のどのホストでもそれを見ることはできません。すべてのパケットをネットワークに接続します。それらを。

eth1に接続されているテストシステムに固定IP 172.16.1.112を提供すると、ブリッジホスト（172.16.1.111）からping応答が得られなくなります。スイッチに接続されている他のホストは、172.16.1.111要求を持つarpを作成するテストホストを表示できますが、ブリッジホストのeth1でtcpdumpを実行すると、着信arp要求は表示されません。

ネットワークブリッジのすべてを削除し、eth1にIP 192.168.200.1を割り当て、テストマシンのIPをeth1に192.168.200.2として挿入してから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は何も返しません。

インターフェイス設定のbr0セクションに「bridge_fd 0」と「bridge_maxwait 1」も追加しました。

eth0とeth1の行を変更したところ、eth0が接続されている場所がbr0がpingに応答する場所のようです。数分間Pingを送信した後も、まだトラフィックが入っていません。

問題をさらに調査するために、/etc/udev/rules.d/70-pertant-net.rulesでmacアドレスを置き換えることで、eth0が現在eth1になり、eth1に古いeth0 macアドレスがあります。再起動後も、br0にはまだeth0のMAC（現在eth1）があり、これは着信パケットを受け入れる唯一の側です。 br0をeth0またはeth1以外の3番目のMACアドレスに設定できますか？

答え1

これは非常に古い質問ですが、他の人に役立ちます。

誤って設定すると、Linux ブリッジがパケットをドロップする可能性があります。私も同じ問題がありましたが、次の情報を使用して問題を解決できました。

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

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

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

答え2

構成がおおよそ正しいようです（つまり、大きな問題は見えません）。

ただし、スパニングツリー遅延値がありません。これは、ブリッジが開始後15秒（デフォルト）でパケットを転送しないことを意味します。bridge_fdインターフェイス設定に加えて修正されました。0他の関連ブリッジがない場合はこの値を使用し、ネットワークにループが発生する可能性がある場合はより大きい値を使用してください。

また、値を追加するときは、ブリッジの初期化中に続行する前に待つ必要がある最大時間を短くすることをお勧めします。一般的bridge_maxwaitに、それより1秒長く設定すれば十分であることがわかりました。bridge_fd

bridge_fd 0
bridge_maxwait 1

関連情報