长 TCP 会话上的 HP Procurve MAC 缓存超时

Question

我们有一个 HP 2510G 交换机网络连接回 HP2912al 以进行聚合。我们已经注意到，一旦 mac-cache-timeout 到期，像 MySQL 数据库转储这样的长时间运行的连接就会开始泛滥到所有网络端口。对目标 IP 执行“arping”会停止泛洪（返回端口到端口），直到缓存超时再次到期。

我可以理解为什么单向 UDP 流量会发生这种情况，但我不知道为什么它会发生在 TCP 上。我认为来自接收机器的 ACK 会导致 Procurves 刷新其缓存中的 MAC 地址。相反，他们似乎只从 ARP 中学习。

有任何想法吗？

Answer 1

您在这里处理的根本问题是MAC条目超时并且没有及时更新，从而导致单播泛洪。在这种情况下，有几点值得怀疑：

1. MAC表搅动。如果交换机的冲突域中有太多主机，则当正在使用的条目超时时，您可能会发生 MAC 表混乱。当您通过交换机汇聚大量 VLAN 以连接两个主要网络时，通常会发生这种情况。

2. STP 变化往往会导致洪水。STP 中的错误配置（具有相同 ID 的交换机...）和不稳定的链路可能会导致缓存清除和意外泛洪。

3. 如果您运行 802.1q 并且没有对称设置，则交换机可能会获知错误 VLAN 上的目标。这将导致交换机最终忘记该条目并开始泛洪。当回复来自不同的 VLAN 时，交换机将继续泛洪。

4. 您遇到了不对称路由情况。如果您的路由是不对称的并且没有流量反向传输，您可以轻松地使 MAC 表中的条目超时。例如下图中，从Router1到Router 2的流量经过Switch1，从Router2到Router1的流量经过Switch2。在这种情况下，您将面临 host3 被淹没的风险。

      host1
       |
      Router1
     |      |
   Switch1  Switch2 - Host3
     |      |
      Router2
       |
      host2
   

5. 纯单向流量。在这种情况下，您需要足够增加 mac 表 ttl，以便来自操作系统的免费 arp（如果配置为发送任何）保持表最新，甚至硬配置转发。请注意，纯单向流量非常罕见。MYSQL 转储不应是单向的。我只在非对称路由的情况下看到过这种情况。

作为权宜之计，我建议部署 arpd（或类似的）来提供慷慨的 arp 并阻止洪水泛滥。它应该与 ARPPing 具有相同的效果（您发现它暂时解决了问题）。但你确实应该调试这个。

我的第一站是验证路由是否确实始终对称，因为非对称路由问题似乎最有可能。

另外，请查看有关园区网络中单播泛洪的思科文档，该文档非常好。