linux – 绑定模式= 5是针对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: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故障转移而受到冒犯,那么您应该好好去！