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

Question

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

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

有任何想法吗？

Answer 1

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

1. MAC 表流失。如果交换机的冲突域中有太多主机，则在使用中的条目超时时，可能会出现 MAC 表流失。这通常发生在通过交换机中继大量 VLAN 以连接两个主要网络时。

2. STP 更改容易导致泛洪。STP 配置错误（具有相同 ID 的交换机...）和不稳定的链接可能会导致清除缓存和意外泛洪。

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

4. 您遇到的是不对称路由情况。如果您的路由是不对称的，并且没有流量反向传输，那么您很容易导致 MAC 表中的条目超时。例如，在下图中，从路由器 1 到路由器 2 的流量经过 Switch1，而从路由器 2 到路由器 1 的流量经过 Switch2。在这种情况下，您可能会面临主机 3 被淹没的风险。

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

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

作为权宜之计，我建议部署 arpd（或类似程序）来提供优雅的 arp 并阻止泛洪。它应该具有与 ARPPing 相同的效果（您发现它可以暂时解决问题）。但您确实应该调试一下。

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

另外，请查看思科文档校园网络中的单播泛洪这非常好。