web-dev-qa-db-ja.com

ボンディングモード= 5はMACフラッピングに対する解決策ですか？

相互接続された2つのCisco WS-2950Tがあります。

firstスイッチの1つのGBICポートによって、firstNICのボンディングに接続されましたインターフェイス、およびsecondスイッチの1つのGBICポートによってsecondNICインターフェースの結合。

もちろん、両方のスイッチは、1つのインターフェイス（たとえば、firstスイッチのGBIC）とすべてでのみボンディングMACアドレスを認識します。 ）ボンディングインターフェイスの着信トラフィックは、このGBICを通過します。

ただし、「mode = 5」では、すべての送信トラフィックが、結合を行うすべてのインターフェイス間で分散されます。この場合、パケットはsecondスイッチからドロップされ、とにかくfirstスイッチ？それとも部門は機能しますか？

linuxciscoswitchbondingmac-address
7
jurijcz

モード5またはbalance-tlbモードでは、発信トラフィックは、ボンドインターフェイスのアドレスを使用する代わりに、離脱するスレーブインターフェイスのMACアドレスを使用します。

通常、ボンドのMACはすべてのトラフィックに使用されるため、特定のスイッチの2つのポート間でMACフラッピング状態が発生する可能性があります。各スイッチは、デバイスへの直接接続の両方から、ボンドのMACを送信元として入力トラフィックを認識します。 、およびクロスコネクトから他のスイッチへ。

送信ロードバランシングモードは、インターフェイス間の送信トラフィックのバランスをとることによってこの問題を回避しますが、インターフェイスのMACアドレスを送信トラフィックのソースとして使用します。サブネット内の他のノード（特にルーター）がこの動作を気にしない場合は、問題なく動作します。通常は問題はありませんが、ルーターの制限的なセキュリティ設定が問題になることは想像できます。

ボンドインターフェースは、そのスレーブインターフェースの1つのMACアドレスを取得します。

root@test1:~# ifconfig
bond1     Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:35
          inet addr:192.168.100.25  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe3d:f735/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

eth1      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:35
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1

eth2      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:3f
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1

eth1のMACはボンドインターフェースと一致します。これは「プライマリ」であるため、インバウンドトラフィックを取得しています。

そして、確認のために：

root@test1:~# cat /sys/class/net/bond1/bonding/mode
balance-tlb 5

root@test1:~# cat /sys/class/net/bond1/bonding/active_slave
eth1

わかりました、それで..それはロードバランシングですか？一定のpingを送信して、別のノードからどのように見えるかを次に示します。

root@test2:~# tcpdump -e -n -i eth0 proto 1
20:33:08.094078 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 38, length 64
20:33:08.094549 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 38, length 64
20:33:09.094052 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 39, length 64
20:33:09.094520 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 39, length 64
20:33:10.094078 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 40, length 64
20:33:10.094540 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 40, length 64

それはすべて正常に見えます-eth1が応答しています。次に、プロンプトなしでスイッチがあります。要求の宛先MACと応答の送信元MACが一致しなくなったことに注意してください。

20:33:11.094084 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 41, length 64
20:33:11.094614 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 41, length 64
20:33:12.094059 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 42, length 64
20:33:12.094531 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 42, length 64
20:33:13.094086 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35, ethertype IPv4 (0x0800), length 98: 192.168.100.40 > 192.168.100.25: ICMP echo request, id 5810, seq 43, length 64
20:33:13.094581 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6, ethertype IPv4 (0x0800), length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply, id 5810, seq 43, length 64

一定のpingを監視し、ソース間の切り替えは、ボンドインターフェイスの負荷の評価に基づいて任意に続行されます。これは、10秒ごとに再評価されているようです。

モード5でのインバウンドトラフィックのフェイルオーバーは、はるかに基本的です。インターフェイスがダウンしていることが検出されると、ボンドインターフェイスのMACがライブインターフェイスに移動されます。これにより、スイッチログでMACフラッピング警告が発生することがよくありますが、これは予想されることです。心配する必要はありません。

インターフェイスMACは次のように変更されます。

eth1      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:35
eth2      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:3f

..to、eth1を削除した後、これ：

eth1      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:3f
eth2      Link encap:Ethernet  HWaddr 00:0c:29:3d:f7:35

そして、MACが:35のeth2からのすべてのトラフィックソース。

つまり、そうです。インバウンドトラフィックのロードバランシングを気にしない場合、balance-tlbモードは、アウトバウンドトラフィックのスイッチセーフロードバランシングとインバウンドトラフィックのフェイルオーバーという優れた機能を果たすようです。

ルーターが単一のIPのトラフィックを送信する複数の送信元MACを気にせず、不必要なARPフェイルオーバーに腹を立てない場合は、問題ないはずです。

5
Shane Madden