綁定模式=5 是針對 MAC 抖動的解決方案嗎？
有兩個相互連接的 Cisco WS-2950T。
通過第一個交換機上的一個 GBIC 埠連接綁定介面的第一個NIC，並且通過第二個交換機上的一個 GBIC 埠連接綁定介面的第二個NIC。
當然，兩台交換機只在一個介面上看到綁定 MAC 地址（例如，它是第一個交換機上的 GBIC），並且綁定介面的所有傳入流量都通過這個 GBIC。
但在“mode=5”中，所有傳出流量都分佈在所有建立綁定的介面之間。在這種情況下，數據包將從第二個交換機丟棄，無論如何都會通過第一個交換機？或者該部門將工作？
在模式 5 或 balance-tlb 模式下，傳出流量使用它離開的從介面的 MAC 地址，而不是使用綁定介面的地址。
通常，綁定的 MAC 用於所有流量，這可能會導致給定交換機上的兩個埠之間的 MAC 抖動情況 - 您的每個交換機都會看到以綁定的 MAC 作為源的傳入流量，兩者都來自與設備的直接連接，並從交叉連接到另一台交換機。
傳輸負載平衡模式通過平衡介面之間的出站流量來避開此問題，但使用介面的 MAC 地址作為出站流量的來源。如果子網中的其他節點（尤其是路由器）不介意這種行為，那麼它工作得很好——通常不會有問題，但我可以想像一些限制性的路由器安全設置會受到攻擊。
綁定介面將採用其從屬介面之一的 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:1eth1 的 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並且，所有來自 eth2 的流量來源，MAC 為
:35.所以，是的 - 假設您不關心入站流量的負載平衡，balance-tlb 模式似乎在出站流量的交換機安全負載平衡和入站流量的故障轉移方面做得很好。
如果您的路由器不關心多個源 MAC 為單個 IP 發送流量，並且不會被無償的 ARP 故障轉移所冒犯，那麼您應該好好去！