键合mode=5是对抗MAC拍打的解决方案吗？

Question

有两个是相互关联的思科WS-2950 T。

第一开关上的一个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

单元1‘S MAC匹配键接口，它是“主”，所以它得到入站流量。

而且，为了确认一下：

root@test1:~# cat /sys/class/net/bond1/bonding/mode
balance-tlb 5

root@test1:~# cat /sys/class/net/bond1/bonding/active_slave
eth1

好吧，那么..。这是负载平衡吗？下面是来自另一个节点的情况，发送常量pings：

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抖动警告，但这是意料之中的，没什么好担心的。

接口MACs将从以下几个方面进行更改：

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模式似乎在切换安全负载平衡出站流量和入站流量故障转移方面做得很好。

如果您的路由器不关心多个源MACs为单个IP发送流量，并且不会被不必要的ARP故障转移所冒犯，那么您应该是好的！