通过第一个交换机上的一个GBIC端口连接第一个NIC的绑定接口,并通过第二个交换机上的一个GBIC端口连接第二个NIC的绑定接口.
当然,两个交换机仅在一个接口上看到绑定MAC地址(例如,它在第一个交换机上是GBIC),并且用于绑定接口的所有传入流量都通过该GBIC.
但是在“mode = 5”中,所有传出流量都在所有进行绑定的接口之间分配.在这种情况下,数据包将从第二个交换机丢弃,无论如何将通过第一个交换机？或该部门将工作？
解决方法
通常,绑定的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: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,length 98: 192.168.100.25 > 192.168.100.40: ICMP echo reply,length 64 20:33:09.094052 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35,seq 39,length 64 20:33:09.094520 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6,length 64 20:33:10.094078 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35,seq 40,length 64 20:33:10.094540 00:0c:29:3d:f7:35 > 00:0c:29:46:4f:c6,length 64
这一切看起来都很正常 – eth1正在回应.然后,没有提示,有一个开关 – 注意请求的目标MAC和响应的源MAC不再匹配.
20:33:11.094084 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35,seq 41,length 64 20:33:11.094614 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6,length 64 20:33:12.094059 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35,seq 42,length 64 20:33:12.094531 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6,length 64 20:33:13.094086 00:0c:29:46:4f:c6 > 00:0c:29:3d:f7:35,seq 43,length 64 20:33:13.094581 00:0c:29:3d:f7:3f > 00:0c:29:46:4f:c6,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
在服用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模式似乎在出站流量的交换机安全负载平衡和入站流量的故障转移方面表现出色.
如果您的路由器不关心为单个IP发送流量的多个源MAC,并且不会因无偿ARP故障转移而受到冒犯,那么您应该好好去！
