我们有连接到HP2912al的HP 2510G交换机networking进行汇聚。 我们已经注意到，一旦mac-cache-timeout过期，长时间运行的连接（如MySQL数据库转储）就会开始泛滥到所有networking端口。 对目标IP进行“arping”操作会阻止泛洪（回到端口到端口），直到高速caching超时再次到期。
我可以理解为什么单向UDPstream量会发生这种情况，但是我为什么会发生TCP丢失。 我认为来自接收机的ACK会导致Procurve刷新其caching中的MAC地址。 相反，他们似乎只从ARP学习。
有任何想法吗？
您在这里处理的根本问题是MAC入口超时，并且不会导致单播泛滥。 在这种情况下，有几件事值得怀疑：
MAC表stream失。 如果在交换机的冲突域中有太多主机，则当正在使用的条目超时时，可以获得MAC表stream失。 这通常发生在通过交换机连接两个主要networking来中继大量VLAN时。
STP变化会导致泛滥。 在STP（configuration相同ID的交换机…）和不稳定的链路中configuration错误会导致高速caching清理和意外泛洪。
如果运行802.1q并且没有对称设置，则可以让交换机在错误的VLAN上学习目标。 这将导致交换机最终忘记进入并开始洪泛。 随着应答出现在不同的VLAN上，交换机将保持洪泛。
你有一个不对称的路由情况。 如果你的路由是不对称的，而且没有任何stream量，你可以很容易地在MAC表中超时。 例如，在下图中，从路由器1到路由器2的stream量通过交换机1，从路由器2到交换机1的stream量通过交换机2。 在这种情况下，你可能会被host3淹没。
host1 | Router1 | | Switch1 Switch2 - Host3 | | Router2 | host2 纯粹的单向stream量。 在这种情况下，您需要增加mac table ttl，以便操作系统（如果configuration为发送任何内容）中的快速arps保持表格清新，甚至可以很难configuration转发。 请注意，纯粹的单向stream量是非常罕见的。 MYSQL转储不应该是单向的。 我只在非对称路由的情况下才看到这一点。
作为一个权宜之计，我build议部署arpd（或类似的）提供亲切的arps和停止洪水。 它应该和ARPPing有相同的效果（你已经发现可以暂时解决问题）。 但是你真的应该debugging这个。
我的第一站是validation路由是否确实是对称的，因为非对称路由问题似乎是最有可能的。
另外，请查看关于校园networking中的单播洪水的思科文档，这是相当不错的。