根据在youtube上进行itfreetraining的NIC组合教程，在NIC组合模式“dynamic”下，出站stream量使用地址散列法在团队成员之间分配，入站stream量使用超v方法分配。
到目前为止这么好，但我仍然有一些不足之处：
dynamic超V方法如何在非hyper v环境中对入站stream量起作用？ 据我所知，当你在hyper v模式下有多个hyper v vms和一个nic团队时，每个虚拟networking适配器都使用mac地址分配给一个nic团队成员。 但在我看来，这不能适用于非超v的环境，因为没有任何vms分配的stream量。 而且只有一个mac地址。
先谢谢你。
dynamic超V方法如何在非hyper v环境中对入站stream量起作用？
不。
分配有效负载到多个（IP-）端点是不可能的，没有（IP-）端点。 另一方面是在Mac控制器上的TCP连接分布。 只要stream量来自各种渠道（而不是像路由器那样来自单一渠道），这样做通常效果不错。
在我看来，这不能应用于非hyper v的环境，因为没有任何vms分配的stream量。
那就对了。 组队通过多个接口（具有多个MAC地址）分配TCPstream量，但这是在驱动程序中完成的，而不是在IP堆栈中完成的。 你的应用程序不会知道，就像你没有。
而且只有一个mac地址。
…对于每个团队来说，或者是在物理适配器上移动的虚拟团队。
使用开关相关模式（静态和LACP）的dynamic模式是否有意义？
链接聚合与Teaming不同。 例如，LACP不会执行故障切换（默认情况下）。 它只是填充一个链接，然后透明切换到下一个链接。 这里没有涉及的mac地址。 在更高的协议级别上没有连接跟踪，就像在团队中一样。
但是，使用超v方法，入站stream量已经分配。
是。 分配，合并和聚合只是不一样的东西，它们是不可交换的。
例如，如果您希望分发到更多物理适配器的主要stream量源是单一的mac源（大型服务器，其他VM主机，路由器，防火墙…），LACP将是您的唯一select。
这就是为什么大多数公司使用vSphere。 虚拟交换机允许其上行链路根据路由ID /始发端口ID，IP哈希，MAC哈希，LACP和PBR（使用NSX时的基于策略的路由）分配stream量。