绑定模式=5 是防止 MAC 摆动的解决方案吗？

Question

有两个是互连的Cisco WS-2950T。

通过在一个GBIC端口第一开关连接的第一NIC接合界面，以及通过所述一个GBIC端口第二开关连接的第二键合界面的NIC。

当然，两台交换机仅在一个接口上看到绑定 MAC 地址（例如，第一个交换机上是 GBIC ），所有绑定接口的传入流量都通过此 GBIC。

但是在“mode=5”中，所有传出流量都分布在所有建立绑定的接口之间。在这种情况下，数据包将从第二个交换机丢弃，无论如何都会通过第一个交换机？或者这个部门会工作？

Answer 1

在模式 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: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

而且，所有流量都来自 eth2，MAC 为:35.

所以，是的 - 假设您不关心入站流量的负载平衡，balance-tlb 模式似乎在出站流量的交换机安全负载平衡和入站流量的故障转移方面做得非常出色。

如果您的路由器不关心为单个 IP 发送流量的多个源 MAC，并且不会因无故 ARP 故障转移而受到冒犯，那么您应该很高兴！