在Linux中绑定接口时切换洪泛

                                  + -------- +
                                  | 主机A |
                                  + ---- + --- +
                                      |  eth0（AA：AA：AA：AA：AA：AA）
                                      |
                                      |
                                 + ---- + ----- +
                                 | 开关1 |  （二层/ 3）
                                 + ---- + ----- +
                                      |
                                 + ---- + ----- +
                                 | 开关2 |
                                 + ---- + ----- +
                                      |
                           + ---------- + ---------- +
 + ------------------------- + Switch 3 + -------------------- ----- +
 |  + ---- + ----------- + ---- + |
 |  |  |  |
 |  |  |  |
 |  eth0（B0：B0：B0：B0：B0：B0）|  |  eth4（B4：B4：B4：B4：B4：B4）|
 |  + ---- + ----------- + ---- + |
 |  | 主机B |  |
 |  + ---- + ----------- + ---- + |
 |  eth1（B1：B1：B1：B1：B1：B1）|  |  eth5（B5：B5：B5：B5：B5：B5）|
 |  |  |  |
 |  |  |  |
 + ------------------------------ + + ----------------- ------------- +

拓扑概述
- 主机A有一个网卡。
- 主机B有四个使用balance-alb模式绑定的NIC。
- 两台主机都运行RHEL 6.0，并且都在同一个IPv4子网上。
stream量分析
- 主机A正在使用某个SQL数据库应用程序向主机B发送数据。
- 从主机A到主机B的stream量：源int / MAC为eth0 / AA：AA：AA：AA：AA：AA，目的地int / MAC为eth5 / B5：B5：B5：B5：B5：B5。
- 从主机B到主机A的stream量：源int / MAC为eth0 / B0：B0：B0：B0：B0：B0，目的地int / MAC为eth0 / AA：AA：AA：AA：AA：AA。
- 一旦build立了TCP连接，主机B就不会再发送出eth5的帧。
- eth5的MAC地址从Switch 1和Switch 2的桥表中过期。
- 交换机1继续从主机A接收发往B5：B5：B5：B5：B5：B5的帧。
- 因为交换机1和交换机2不再有B5：B5：B5：B5：B5的桥接表项，它们会将帧从同一VLAN上的所有端口（当然除外）中泛滥出去。
复制
- 如果从连接到交换机1或2的工作站ping主机B，则B5：B5：B5：B5：B5：B5将重新进入网桥表，并停止洪泛。
- 五分钟后（默认网桥表超时），恢复泛洪。
题
- 很明显，在主机B上，帧到达eth5并退出eth0。这似乎是好的，因为这是Linux绑定algorithmdevise要做的 – 平衡传入和传出的stream量。但是由于交换机停止接收具有eth5的源MAC的帧，所以它从桥表中超时，导致洪泛。
- 这是正常的吗？为什么没有更多的框架来自eth5？是否因为没有其他stream量正在进行（唯一的连接是来自主机A的单个大数据传输）？

我研究了很久，还没有find答案。文档指出，在使用Linux接口绑定的模式6（balance-alb）时，不需要更改开关。发生这种行为，因为主机B不会发送任何进一步的数据包的eth5，而在正常情况下，预计它会？一个解决scheme是设置一个cron作业，ping主机B，以防止桥表项出现超时，但这似乎是一个肮脏的黑客攻击。

是的 – 这是预期的。 NIC绑定到主机，单播泛滥，已经遇到一个相当普遍的问题。正如您已经注意到的那样，正在观察交换机上针对所讨论的硬件地址的定时器，因为没有来自这些地址的帧。

以下是一般选项 –

1.）更长的地址表超时。在混合的L2 / L3交换机上，ARP和CAM定时器应该相互靠近（CAM定时器运行几秒钟）。不pipeconfiguration的其余部分如何，这个build议都是成立的。在L2交换机上，定时器通常可以设置得更长，而没有太多的问题。也就是说，除非完全禁用定时器，否则如果没有从其他地址获取某种stream量，则最终将返回相同的情况。

2.）您可以硬编码交换机上的MAC地址（不幸的是，图中的所有交换机）。由于多种原因，这显然不是最佳的。

3.）将Linux端的绑定模式更改为使用通用源MAC（即802.3ad / LACP）的绑定模式。如果您的交换机支持，这有很多的运营优势。

4.）通过每个界面的cron作业生成免费的arps 。您可能需要在各种接口上使用一些虚拟IP来防止振荡条件（即主机的IP通过各种硬件地址循环）。

5.）如果是交通问题，就去10GE吧！（抱歉 – 必须把它扔到那里）

LACP路由可能是最常见和最可支持的，并且交换机可能被configuration为在各个链路之间均衡地平均进入服务器的stream量。如果没有，我认为无偿的arp选项将是最容易整合的。