有两个是互连的思科WS-2950T。
第一台交换机上的一个GBIC端口连接一个绑定接口的第一个网卡， 第二台交换机上的一个GBIC端口连接一个绑定接口的第二个网卡。
当然，两台交换机只能在一个接口上看到绑定的MAC地址（例如第一台交换机上的GBIC），绑定接口的所有入站stream量都要经过这个GBIC。
但在“mode = 5”中，所有出站stream量都在所有形成绑定的接口之间分配。 在这种情况下，数据包将从第二个交换机丢弃，反正会通过第一个交换机？ 还是该部门将工作？
在模式5或balance-tlb模式下，出站stream量使用它所离开的从接口的MAC地址，而不是使用绑定接口的地址。
通常情况下，绑定的MAC用于所有的stream量，这可能会导致给定交换机上两个端口之间的MAC振荡状况 – 您的每台交换机都会看到绑定的MAC作为源进入stream量，无论是直接连接到设备，并从交叉连接到另一个交换机。
传输负载均衡模式通过平衡接口之间的stream量出口来避开这个问题，但是通过使用接口的MAC地址作为出站stream量的来源。 如果你的子网中的其他节点（特别是路由器）不介意这种行为，那么它工作得很好 – 通常没有问题，但我可以想象一些限制性的路由器安全设置冒犯了。
绑定接口将采用其从属接口之一的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与绑定接口相匹配，它是“主”，所以它获得了入站stream量。
而且，只是为了确认：
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中入站stream量的故障转移更为基础。 当接口被检测为closures时，绑定接口的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
..到eth1后，这个：
eth1 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:3f eth2 Link encap:Ethernet HWaddr 00:0c:29:3d:f7:35
而且，来自eth2的所有stream量来源，MAC为:35 。
所以，是的 – 假设您不关心入站stream量的负载平衡，balance-tlb模式似乎在出站stream量的交换安全负载平衡和入站stream量故障转移方面做得非常出色。
如果您的路由器不关心为单个IP发送stream量的多个源MAC，也不会因无故障ARP故障转移而感到愤怒，那么您应该很好！