web-dev-qa-db-ja.com

Linuxでインターフェースを結合するときにフラッディングを切り替える

 + -------- + 
 |ホストA | 
 + ---- + --- + 
 | eth0（AA：AA：AA：AA：AA：AA）
 | 
 | 
 + ---- + ----- + 
 |スイッチ1 | （layer2/3）
 + ---- + ----- + 
 | 
 + ---- + ----- + 
 |スイッチ2 | 
 + ---- + ----- + 
 | 
 + ---------- + ------- --- + 
 + ------------------------- +スイッチ3+ ----------- -------------- + 
 | + ---- + ----------- + ---- + | 
 | | | | 
 | | | | 
 | eth0（B0：B0：B0：B0：B0：B0）| | eth4（B4：B4：B4：B4：B4：B4）| 
 | + ---- + ----------- + ---- + | 
 | |ホストB | | 
 | + ---- + ----------- + ---- + | 
 | eth1（B1：B1：B1：B1：B1：B1）| | eth5（B5：B5：B5：B5：B5：B5）| 
 | | | | 
 | | | | 
 + ------------------------------ + + ----------- ------------------- +
  • トポロジの概要
    • ホストAには単一のNICがあります。
    • ホストBには、balance-albモードを使用して結合された4つのNICがあります。
    • 両方のホストがRHEL6.0を実行し、両方が同じIPv4サブネット上にあります。
  • トラフィック分析
    • ホストAは、SQLデータベースアプリケーションを使用してホストBにデータを送信しています。
    • ホストAからホストBへのトラフィック：ソースint/MACはeth0/AA：AA：AA：AA：AA：AA、宛先int/MACはeth5/B5：B5：B5：B5：B5：B5です。
    • ホストBからホストAへのトラフィック：ソースint/MACはeth0/B0：B0：B0：B0：B0：B0、宛先int/MACはeth0/AA：AA：AA：AA：AA：AAです。
    • TCP接続が確立されると、ホストBはそれ以上フレームをeth5に送信しません。
    • Eth5のMACアドレスは、スイッチ1とスイッチ2の両方のブリッジテーブルから期限切れになります。
    • スイッチ1は、ホストAからB5：B5：B5：B5：B5：B5宛てのフレームを引き続き受信します。
    • スイッチ1とスイッチ2にはB5：B5：B5：B5：B5：B5のブリッジテーブルエントリがなくなったため、同じVLAN（1つを除く）のすべてのポートからフレームをフラッディングします。もちろん、それはやって来ました）。
  • 複製
    • スイッチ1または2のいずれかに接続されているワークステーションからホストBにpingを実行すると、B5：B5：B5：B5：B5：B5がブリッジテーブルに再び入り、フラッディングが停止します。
    • 5分後（デフォルトのブリッジテーブルタイムアウト）、フラッディングが再開されます。
  • 質問
    • ホストBでは、フレームがeth5に到着し、eth0から出るのは明らかです。 Linuxボンディングアルゴリズムは、着信トラフィックと発信トラフィックのバランスを取るように設計されているため、これは問題ないようです。ただし、スイッチはeth5の送信元MACでフレームの受信を停止するため、ブリッジテーブルからタイムアウトになり、フラッディングが発生します。
    • これは正常ですか？ eth5から発信されたフレームがこれ以上ないのはなぜですか？他のトラフィックが発生していないためですか（唯一の接続はホストAからの単一の大規模なデータ転送です）？

私はこれを長い間研究してきましたが、答えは見つかりませんでした。ドキュメントには、Linuxインターフェイスボンディングのモード6（balance-alb）を使用する場合、スイッチを変更する必要はないと記載されています。この動作は、ホストBがeth5からそれ以上パケットを送信しないために発生しますが、通常の状況では送信されると予想されますか？ 1つの解決策は、ホストBにpingを実行してブリッジテーブルエントリがタイムアウトしないようにするcronジョブを設定することですが、これは汚いハックのようです。

linuxnetworkingciscoredhatswitch
2
John Philips

はい-これは予想されます。 NICホストへのボンディング、ユニキャストフラッディングで、かなり一般的な問題が発生しました。ご指摘のとおり、問題のハードウェアアドレスのスイッチのタイマーは、これらのアドレスから送信されたフレームがないためです。観察されています。

一般的なオプションは次のとおりです-

1.）アドレステーブルのタイムアウトが長くなります。混合L2/L3スイッチでは、ARPタイマーとCAMタイマーを互いに近づける必要があります（CAMタイマーは数秒長く実行されます）。この推奨事項は、残りの構成に関係なく有効です。 L2スイッチでは、タイマーは通常、あまり問題なく長く設定できます。とはいえ、タイマーを完全に無効にしない限り、他のアドレスからの何らかのトラフィックソーシングがなければ、最終的には同じ状況に戻ります。

2.）問題のスイッチ（残念ながら、図のすべてのスイッチ）にMACアドレスをハードコーディングすることができます。これは、いくつかの理由で明らかに最適ではありません。

3.）Linux側のボンディングモードを、共通ソースMACを使用するモード（802.3ad/LACPなど）に変更します。スイッチがサポートしている場合、これには多くの操作上の利点があります。

4.）各インターフェイスからcronジョブを介して gratuitous arps を生成します。発振状態を防ぐために、さまざまなインターフェイスにダミーIPが必要になる場合があります（つまり、ホストのIPがさまざまなハードウェアアドレスを循環します）。

5.）トラフィックの問題の場合は、10GEにアクセスしてください。 （申し訳ありません-そこにそれを投げなければなりませんでした）

LACPルートはおそらく最も一般的でサポート可能であり、スイッチは、さまざまなリンク間でサーバーへのインバウンドトラフィックのバランスをかなり均等にするように構成できます。それに失敗すると、Gratuitousarpオプションを統合するのが最も簡単になると思います。

2
rnxrx