☰

绑定模式 = 5 是否可以解决 MAC 抖动问题？

tag-icon • tag-icon linux cisco switch bonding mac-address
绑定模式 = 5 是否可以解决 MAC 抖动问题？

有两个互联思科 WS-2950T。

通过一个 GBIC 端口第一的开关连接第一的绑定接口的网卡，以及一个 GBIC 端口第二开关连接第二绑定接口的网卡。

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

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

答案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

..关闭 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 故障转移而感到不快，那么您就可以开始了！

相关内容