在devisenetworking拓扑时，有什么理由不依赖LACP？ 我的意思是L2 切换到虚拟机pipe理程序连接，所以它是虚拟机的聚合stream量累积的地方。 我们正在讨论5 x 1 GbE LACP绑定。
我不同意我的同事。 他说： “为什么我们应该在整个安装过程中增加另一层开销？这只是另一个潜在的失败点。” 而且他总体上对链路聚合持怀疑态度。 我认为在802.3ad模式下的linux bonding驱动是可靠和不错的select。
他还认为，我们不需要它，因为在我们的环境中不会有这么大的stream量，简单的1 GbE就足够了。 我们高中有大约100个PC客户端和大约10台服务器在我们的局域网中。
所以当我们不知道我们需要LACP的天气时，我们处于这种情况。 关于networkingstream量的一些额外的数据可能会很好，但我认为检索有意义的数字是一个挑战。 所以依靠直觉就容易多了 ，只是说：“ 是的 ，我们希望LACP，因为交通。 或者“ 不 ，因为它不可靠，我们也不需要它”。
有什么build议么？
说实话，LACP的诞生正是为了解决由LAG（链路聚合组）造成的危险问题。
在直接连接的接口之间使用时，LAG不是危险的。 在这样的设置中，基本上任何networking问题都可以追踪到一个没有链路的端口 – 自动指示交换机停止发送stream量到断开的端口。
但是，如果其他设备位于启用LAG的交换机和聚合Gbit端口之间，则可能会出现其他一些逻辑问题，由于转发交换机没有关于这些暂时性问题的信息（它将继续盲目地将stream量发送到断开/有问题的端口）。
为了解决这个问题，LACP被定义为：它使用基于心跳的系统来不断地监视聚合的端口，并且当心跳过多时自动断开连接。
简而言之：如果configuration正确，我看不到使用LACP的问题。 唯一要考虑的是你不可避免地有一个稍微复杂的configuration来跟踪/pipe理。
是的，我相信LACP。 我比其他所有链路汇聚方法更喜欢LACP，因为它非常可靠，灵活，是IEEE标准，所以供应商互通是有保证的。
如果您认为您的虚拟机每秒可以处理超过1 GB的stream量（这很容易实现），那么您希望负载均衡。 唯一的负载平衡模式（在Linux上）适用于您的模式2（balance-xor）或模式4（LACP）。 模式2使用与模式4相同的平衡，只是没有恒定的心跳到交换机。