☰

ブリッジトラフィックが一部のポートに到達しません。

tag-icon • tag-icon linux networking bridge tunneling
ブリッジトラフィックが一部のポートに到達しません。

L2TPv3を介して2つのホスト間にトンネルがあります。トンネルの各端は、他のインターフェイスと同様にブリッジに属します。リモートブリッジには追加のDHCPサーバーがあり、ローカルブリッジにはDHCPクライアントがあります。これをテストするために、ホストシステムにvethペアを作成しました。半分はブリッジに依存し、残りの半分は新しいネットワーク名前空間に配置されました。次に、名前空間の残りの半分でDHCPクライアントを起動します。このように：

ip netns add test
ip link add test1 type veth peer test2
ip link set test2 netns test up
ip link set test1 master tunnel_bridge up
ip netns exec test dhclient -d test2

これはすべて期待どおりに機能します。 test2 インターフェイスの DHCP リースが取得され設定されます。 Tunnel_bridgeインターフェイスですでに実行されているDHCPクライアントもアドレスを取得します。

これで、L2TPv3トンネルをVxLANトンネルに置き換えようとしています。 VxLANにピアが2つしかない理由はありませんが、この場合はあります。 VxLANは、静的フラッディングを含むユニキャストで構成されています。

これで、ブリッジ間のトラフィックが良好になります。ローカルブリッジはDHCPを介してアドレスを取得し、リモートブリッジをpingできます。ただし、DHCP サーバーの DHCP 応答は、ローカル ブリッジからスレーブ インターフェイスに伝播されません。ブリッジにイーサネットポート、vethインターフェイス、WiFi APを追加してみました。それぞれの場合、tcpdump は、DHCP 要求がローカルブリッジに移動し、トンネルを介してリモートブリッジに移動し、応答がトンネルを介してローカルブリッジに到達するが、要求が行われたインターフェイスには到達しないことを示します。

どちらのブリッジもSTPがオンになっています（ただし、オフにすることも試みました）。 /sys/class/net/tunnel_bridge/bridge/nf_call_arptablesそして/sys/class/net/tunnel_bridge/bridge/nf_call_iptables両方0。すべてのiptableは空で、デフォルトポリシーはに設定されていますACCEPT。すべてのebtableが空です。 brctl showstpすべてのポートが転送状態にあることを示します。

私が知る限り、ただ機能する構成と機能しない構成の違いは、L2TPv3 トンネルを VxLAN トンネルに置き換えることです。これは、トラフィックがブリッジから別のインターフェイスに伝播する方法にどのような影響を与えますか？また何を確認できますか？

編集するここで答えの一部は、VxLANがトンネルに到着したパケットを元のブリッジに再エコーするということです。そのため、元のDHCP要求がブリッジに到着し、トンネルに入り、次にブリッジに到着する冗長フレームを表示します。これにより、ブリッジはMACアドレスを見つけることができるポートのアイデアを更新します。これは、応答が要求が行われたポートではなくVxLANトンネルに戻されることを意味します。設定brctl setageing tunnel_bridge 0により、ブリッジはすべてのパケットをすべてのブリッジポートにフラッディングし、「動作」します。しかし、これは確かに理想的なものではありません。 VxLANトンネルがこれを行っているという直接的な証拠はありませんが、VxLANがL2TPv3に置き換えられると、すべてがうまく機能するというだけです。 VxLANトンネリングがなぜこれを行うのかわかりません。

ベストアンサー1

ここでの問題は実際にはVxLANの問題です。 VxLANトンネルのリモート側にあるfdbにブロードキャストエントリを追加する自動プロセスがあります（たとえばbridge fdb append 00:00:00:00:00:00 dst <remote ip> dev vxlan1、このプロセスも誤って追加されました）。地元のVxLANエンドポイントとして機能するIPアドレス。

したがって、vethインターフェイスからDHCP要求が送信されると、vethインターフェイスのMACアドレス（DHCPフレームのソースMAC）のユニキャストfdbエントリがブリッジのポート転送テーブルに追加されます。これにより、フレームがすべてのブリッジポートにフラッディングされます。 VxLAN インターフェイスはフレームをリモートでトンネリングしますが、返品自分に送ってください。フレームを「受信」すると、ブリッジにコピーされ、ブリッジは、VxLAN ポートに到着する対応する MAC アドレスのフレームをチェックし、それに応じてポート転送テーブルを更新し、VxLAN ポートを veth インターフェイスに到達する方法として記録します。 MACアドレス。

DHCP応答が到着すると、ブリッジはそれを確認し、vethインターフェイスのMACアドレスを確認し、ポート転送テーブルを照会し、VxLANポートで見た最後のMACを確認し、それをVxLANポートに送信します。それは決してベス港に達しません。

私にとってこの四半期のポイントは、ブリッジのエージング時間を0に設定するとブリッジが浸水するため、問題が「解決」されることです。すべて配達すべてポート。おそらく追加のfdbエントリを見つける必要があります。

おすすめ記事