https://blog.hjc.im/linux-and-lacp-lag.html

先把博客优化好再来吧

博客在 Vultr 美国东部，没啥好优化的，反正大陆地区肯定打不开。

好像能打开……

能打开

补充图片版
//i.v2ex.co/5J53dgr2.jpeg

分析的不错，可以写邮件去邮件列表骂

写的不错！

LACP drIver 不难修改 可以试着打一个 local 补丁做一个 workaround 试试

大佬啊！

是能打开的

看完了，所以就是 Google 开发人员天才操作的锅了(＃°Д°)

虽然看的迷迷糊糊，不是很懂，但也看明白了楼主意思，确实很用心，给楼主点赞。

好有趣

为啥不试试 bond0 或者 bond6 配置呢。。

不太了解 LACP，不过比较好奇为什么这么久这个 bug 才有人发现...
如果第一个引入绑定到偶数端的优化可有可无的话，为什么没人提出将其作为一个可选参数？这样是否需要这个优化用户可以自己决定，比如只有用户确认自己所有设备都是支持这个优化没有坑的时候再开启。

balance-rr 会导致数据包出现一些乱序，TCP 不喜欢这种。alb 模式只能对不同 host 进行负载均衡，对同一 host 上的不同连接无法均衡，并且我的 NAS 网卡不支持这种模式。
我个人猜测关注两台 Linux 机器多连接互相通讯时的总带宽大小的客户可能比较少，可能双口网卡服务器的客户更多的是关注多 VM 之类的负载均衡的性能，或者是很多个 client 的并发性能，也就是使用 layer2/3 的 hash 或者干脆不用 LACP 的人大概比较多。

这个问题本质是 2 层设备 too smart, 依赖 4 层软件的行为。做了破坏抽象的事就要承受破坏抽象的后果


因为这个根本就不算是 bug 算是一个小问题
而且只有楼主这种实际上是比较不普遍的且不典型的场景才有这个问题

服务器与服务器之间的大带宽通讯也算是一个比较现实的需求了，如果是用 Windows 做 NAS 还会自动开启 SMB multil channel，自动创建多个连接在多个链路之间负载均衡。连微软这种在 server 技术上相对比较保守的企业都有实现相关的功能，我觉得这个场景不能算不普遍不典型。


其实就是不普遍不典型。
因为你能看到的需求和场合太有限。
说的不是 LACP 技术，这只是链路聚合的一部分。
你遇到的这个问题是链路聚合的普遍问题，不只是 LACP 和 linux 内核网络处理
我确信你说的完全正确，而且是你所在场合里所遇到的，你感觉会很多的问题
你有没有深入想过，为什么只有 LINUX 的处理机制才会这么魔改导致你更麻烦的问题，而所有的网络设备都不处理这种问题？因为只有你站在 linux 简单内部模型这一端，这才是个像你认为的那样的比例很大的问题，他们才会在不能碰标准的情况下自己魔改优化自己的小问题

而做网络结构设计，链路聚合（ PC ET LA ）都不是你这么用的，也不是考虑你这种需求而做的。不会为了适应你这种乐观估计连百万分之一都不够的需求场景。
喝了点酒，有点迷糊，表述不太清晰，可能没太说明白…… 要不等我清醒了 TG 你加我一对一我给你多说说。

现在迷迷糊糊，绞尽脑汁总结细一点 你试着理解一下
链路聚合技术
在微观领域的设计只能用于链路可靠性保障和 HA 报障，不要考虑叠加带宽
在宏观领域应用可考虑叠加带宽，但是要充分结合业务模型用最保守的方式设计分担数
甚至需要采样设计

我也觉得你这种观念比较正确，通过聚合来叠加带宽感觉不是很靠谱

加一层免费的 cdn 就行了

只看懂了一小部分，无法发表有建设性评论。
只好来撺掇楼主转投 TrueNAS （即将和 FreeNAS 合并），BSD 内核才是 Unix 正统（又来 troll ）
放弃 Linux 吧 (doge)

已转投，果然 FreeBSD 的 LACP 就没这种破事，随手配一下就能跑满 20G，好评。