☰

在 Linux 中绑定接口时进行交换机泛洪

tag-icon • tag-icon linux networking cisco redhat switch
在 Linux 中绑定接口时进行交换机泛洪 
                                 +--------+
                                 | 主持人 A |
                                 +----+---+
                                     | eth0（AA:AA:AA:AA:AA:AA:AA）
                                     |
                                     |
                                +----+-----+
                                | 交换机 1 | （第 2/3 层）
                                +----+-----+
                                     |
                                +----+-----+
                                | 开关 2 |
                                +----+-----+
                                     |
                          +----------+----------+
+-------------------------+ 开关 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 有一个 NIC。
    • 主机 B 有四个 NIC，使用 balance-alb 模式绑定。
    • 两台主机均运行 RHEL 6.0，并且位于同一个 IPv4 子网上。
  • 流量分析
    • 主机 A 正在使用某些 SQL 数据库应用程序向主机 B 发送数据。
    • 从主机 A 到主机 B 的流量：源 int/MAC 是 eth0/AA:AA:AA:AA:AA:AA，目标 int/MAC 是 eth5/B5:B5:B5:B5:B5:B5。
    • 从主机 B 到主机 A 的流量：源 int/MAC 是 eth0/B0:B0:B0:B0:B0:B0，目标 int/MAC 是 eth0/AA:AA:AA:AA:AA:AA。
    • 一旦建立 TCP 连接，主机 B 就不会再通过 eth5 发送任何帧。
    • eth5 的 MAC 地址在交换机 1 和交换机 2 的桥接表中均已过期。
    • 交换机 1 继续接收来自主机 A 的目的地为 B5:B5:B5:B5:B5:B5 的帧。
    • 由于交换机 1 和交换机 2 不再具有 B5:B5:B5:B5:B5:B5 的桥接表条目，它们会将帧从同一 VLAN 上的所有端口泛洪出去（当然，除了它进入的端口）。
  • 复制
    • 如果从连接到交换机 1 或 2 的工作站 ping 主机 B，则 B5:B5:B5:B5:B5:B5 将重新进入桥接表，并且泛洪停止。
    • 五分钟后（默认桥接表超时），泛洪恢复。
  • 问题
    • 很明显，在主机 B 上，帧到达 eth5 并从 eth0 退出。这似乎没问题，因为这就是 Linux 绑定算法的设计目的 - 平衡传入和传出流量。但由于交换机停止接收源 MAC 为 eth5 的帧，因此它会超时超出桥接表，从而导致泛洪。
    • 这是正常的吗？为什么没有更多的帧来自 eth5？是不是因为根本没有其他流量在进行（唯一的连接是来自主机 A 的单个大数据传输）？

我研究了这个问题很长时间，但还是没有找到答案。文档指出，使用 Linux 接口绑定模式 6（balance-alb）时不需要更改交换机。出现这种情况是因为主机 B 不再从 eth5 发送任何数据包，而在正常情况下，它会这样做吗？一种解决方案是设置一个 cron 作业，ping 主机 B 以防止桥接表条目超时，但这似乎是一种肮脏的黑客行为。

答案1

是的 - 这是意料之中的事。您遇到了 NIC 绑定到主机的一个相当常见的问题，即单播泛洪。正如您所注意到的，交换机上针对相关硬件地址的计时器没有观察到来自这些地址的帧。

以下是常规选项 -

1.) 更长的地址表超时。在混合 L2/L3 交换机上，ARP 和 CAM 计时器应该彼此接近（CAM 计时器运行时间长几秒钟）。无论其余配置如何，此建议都适用。在 L2 交换机上，计时器通常可以设置得更长而不会出现太多问题。也就是说，除非您完全禁用计时器，否则如果没有来自其他地址的某种流量来源，您最终会回到相同的情况。

2.) 您可以在相关交换机上硬编码 MAC 地址（不幸的是，图中所有交换机都是如此）。这显然不是最佳选择，原因有很多。

3.) 将 Linux 端的绑定模式更改为使用公共源 MAC（即 802.3ad/LACP）的模式。如果您的交换机支持此功能，则这将带来很多操作优势。

4.) 生成无偿的阿普斯通过每个接口的 cron 作业。您可能需要在各个接口上设置一些虚拟 IP，以防止出现振荡情况（即主机的 IP 在各个硬件地址之间循环）。

5.) 如果是流量问题，就换成 10GE！（抱歉 - 不得不说这个）

LACP 路由可能是最常见且最受支持的，交换机可能可以配置为在各个链路上相当均匀地平衡到服务器的入站流量。如果做不到这一点，我认为免费 arp 选项将是最容易集成的。

相关内容