我的networking上有一个单播洪泛问题，当我将一些软件移动到虚拟客户机时，这个问题就开始了。 看起来与这里报告的非常相似： 在Linux中绑定接口时切换洪泛 。 这个问题可以追溯到2012年…所以也许现在有一个更好的解决scheme，也许在Linux / KVM方面。
在下面，我将尝试解释我执行的体系结构和故障排除步骤。 我希望有人能给我一些提示，也许一个解决scheme！ 提前致谢！
Linux主机与PROXMOX 4.1和几个Windows虚拟机。
主机有4个Gbit以太网接口（MAC地址为A，B，C和D），用balance-tlb方法绑定。
然后绑定到虚拟机。 因此每个VM都有自己的MAC地址（MAC地址为X，Y，Z，…）。
托pipe在虚拟机上的软件与现场的许多设备进行交互。
服务器连接到瞻博networking交换机，然后连接到广泛的思科networking。 一切都是二级。
在思科networking上，我不时看到单播风暴。 看来，他们开始每5分钟或其倍数。 我分析了stream量，我发现突然间，从交换机的所有物理端口（在同一个VLAN上）复制了某些设备到某个虚拟机的stream量（反之亦然）。 几秒钟之后，问题就解决了。
阅读思科文档（关于单播泛滥和MAC“老化时间”），以及上述链接，我发现这个问题可能是由于虚拟机的MAC地址在networking上并不经常出现，所以在一定的“老化时间”，交换机开始转发这样的stream量到所有端口，直到他们发现主机在哪里。
我在networking上连接了一台笔记本电脑，并开始从一台虚拟机上ping它。 我嗅闻笔记本电脑上的数据包。
从这我可以看到：
来自虚拟机的ARP请求，使用自己的MAC地址作为MAC源（比如说X）
从笔记本电脑的ARP回复，使用MAC源地址（L）和目的地址（MAC地址（X））作为MAC源，
来自虚拟机的ping请求，使用绑定的物理以太网端口（A，B，C，D，以及它们中的三个之间的不时切换）的MAC地址之一作为MAC源，并且作为MAC目的地L
从笔记本电脑的ping回复，使用作为MAC源L和作为MAC目的地的虚拟机MAC地址（X）
基本上，似乎除了第一个ARP请求之外，虚拟机从来没有出现在具有自己的MAC地址（X）的笔记本电脑上，而总是以A，B，C或D（随时间变化）出现。 但是，笔记本电脑总是响应X.
我读到，在balance-tlb模式下，stream量从不同的接口stream出，这取决于负载。 但是，我认为这种行为与虚拟机出现在networking上的物理接口的源MAC地址一起使用的事实可能会产生我报告的问题。
如果这是正确的，是否有人知道是否有办法始终强制使用VM自己的MAC地址进行每一个通信？ （例如，它已经发生了ARP请求）或者也许解决scheme是在别的地方？
我以为我可以设置Windows虚拟机每隔3分钟重置ARP表…但是这对我来说似乎有点太蛮横… 🙂
再次感谢任何帮助！
编辑：我确认，如果在洪水事件我快速login到相应的虚拟机，并发出ARP表重置，我看到来自虚拟机的新ARP请求（告诉自己的MAC地址到networking），风暴立即停止。
Balance-tlb（模式5）和balance-alb（模式6）不适用于虚拟网桥。 它们可以引起广播环路，在某些情况下它们将数据包重写为源MAC，模式6通过devise截获ARP。
您需要在没有交换机configuration的情况下使用主动备份（模式1），或者在交换机configuration下使用balance-xor（模式2）或802.3ad（模式4）。
您也可以使用交换机configuration使用循环（模式0）或广播（模式3），但这些对TCPstream的性能不利。
https://en.wikipedia.org/wiki/Unicast_flood您的:::::::“”“”可能会导致ARP定时器长于交换机上的地址caching超时…..“”“”“试着设置你的KVMpipe理程序主机和VM主机，ARP定时器比交换机本身要短，请通过物理以太网端口连接，请让我们知道你发现了什么。我们，谢谢。