在linux上使用nmcli配置lacp聚合链路需先创建mode为802-3ad的bond接口；2. 将物理网卡eno1和eno2添加为bond-slave并指定master为bond0；3. 为bond0配置静态或dhcp的ip地址；4. 激活mybond连接以启动聚合链路；5. 通过cat /proc/net/bonding/bond0验证lacp状态和成员接口信息；6. lacp能实现智能负载均衡和链路冗余，依赖交换机端也配置lacp模式；7. 常见问题包括交换机配置不匹配、物理链路未up、负载均衡策略不当及networkmanager行为异常；8. 不同bonding模式如balance-rr、active-backup、balance-xor、balance-tlb和balance-alb适用于不同场景，802.3ad在支持lacp的环境中是兼顾性能与可靠性的首选方案。
在Linux系统上构建网络接口聚合链路，特别是使用LACP协议实现负载均衡，核心在于将多块物理网卡逻辑上捆绑成一个单一的接口。这不仅能提升网络的可用性——即使一块网卡失效，连接也能保持——还能在理论上增加带宽，并通过LACP（Link Aggregation Control Protocol，802.3ad）智能地在多条链路上分配流量，从而达到负载均衡的目的。这背后需要服务器端和网络交换机端的紧密协作与正确配置。
解决方案
在Linux上配置LACP聚合链路，我通常倾向于使用
nmcli
工具，它在现代发行版中表现出色且管理方便。
准备工作： 确保你的Linux系统安装了
network-manager
和
network-manager-tui
（可选，但图形化配置有时有用）。识别出你想要聚合的物理网卡接口名称，比如
eno1
和
eno2
。这些接口在配置前不应该有IP地址。
创建Bond接口：首先，创建一个新的bond接口。这个接口将是你的逻辑聚合链路。
nmcli connection add type bond con-name mybond ifname bond0 mode 802-3ad
这里，
con-name
是连接的名称，
ifname
是接口的名称（我习惯用
bond0
），
mode 802-3ad
明确指定了LACP模式。
添加物理接口作为Slave：接下来，把你的物理网卡添加到这个bond接口作为成员（slave）。
nmcli connection add type bond-slave con-name eno1-slave ifname eno1 master bond0nmcli connection add type bond-slave con-name eno2-slave ifname eno2 master bond0
注意，这里
con-name
是为每个slave连接起的名称，
ifname
是实际的物理网卡名，
master bond0
指定了它们属于哪个bond接口。
配置Bond接口的IP地址：现在，为
bond0
接口配置IP地址。你可以选择静态IP或DHCP。
静态IP：
nmcli connection modify mybond ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8 8.8.4.4"
DHCP：
nmcli connection modify mybond ipv4.method auto
激活连接：最后，激活你的
mybond
连接。
nmcli connection up mybond
此时，
eno1
和
eno2
会自动被激活并加入
bond0
。
验证：检查bond状态是一个关键步骤。
cat /proc/net/bonding/bond0
你会看到LACP状态、成员接口的状态（
MII Status
应该是
up
，
Link Aggregation Group
应该有值），以及负载均衡策略等信息。同时，使用
ip a show bond0
可以查看
bond0
的IP地址。
为什么LACP是首选：深入理解聚合链路的优势
当我思考网络链路聚合时，LACP（802.3ad）几乎总是我的首选，而不是简单的
active-backup
或
balance-rr
。这背后有几个非常实际的原因。首先，它提供了一种智能的负载均衡机制。不同于某些简单模式可能只做轮询或仅仅提供冗余，LACP会与交换机进行协商，共同决定如何分配流量。这意味着交换机也能参与到流量的哈希计算中来，通常基于源/目的MAC、IP或端口号，从而实现更细粒度的流量分布，避免了某些链路过载而另一些空闲的情况。
其次，冗余性是LACP的另一个巨大优势。如果聚合链路中的某条物理链路发生故障，LACP协议会检测到这个变化，并自动将流量从故障链路移除，转移到健康的链路上，而应用程序几乎不会察觉到中断。这种自愈能力对于高可用性服务至关重要。我曾经遇到过一些老旧服务器，网卡驱动偶尔会“抽风”，LACP在这种情况下就成了救命稻草。
最后，LACP提供了一个双向的健康检查。它不仅仅是服务器单方面地认为链路是好的，而是通过发送和接收LACPDU（LACP Data Units）与交换机持续通信。如果LACPDU停止交换，那么链路就会被认为是失效的。这种机制比简单的链路状态检测更可靠，能够发现一些更深层次的网络问题，比如线缆虽然插着但实际无法通信的情况。当然，这要求你的网络交换机也支持并正确配置了LACP（通常称为EtherChannel、Port-Channel或LAG）。如果交换机不支持，或者配置不匹配，那么LACP就无法正常工作，聚合链路可能表现异常或根本无法建立。这通常是我排查LACP问题时首先检查的地方：服务器配置对了，交换机那边呢？
LACP配置中的常见陷阱与排查策略
在实际部署LACP聚合链路时，我发现一些常见的“坑”和对应的排查方法。这东西看起来简单，但细节决定成败。
MCP官网
Model Context Protocol（模型上下文协议）
51 查看详情 
一个最常见的陷阱是交换机配置不匹配。你可能在Linux服务器上配置了
mode 802-3ad
，但交换机端口组却配置成了静态链路聚合（比如思科的
channel-group X mode on
）或者根本没有配置聚合。LACP是动态协商的，如果交换机没有配置成LACP模式（通常是
mode active
或
mode passive
），那么两边就无法建立起LACP会话。我的经验是，如果
cat /proc/net/bonding/bond0
输出中LACP状态显示
AD State: LACP_INACTIVE
或者
Aggregator ID
不对劲，那八成是交换机的问题。解决办法就是检查并确保交换机端口组也配置了LACP模式，并且是与服务器端兼容的模式（通常是
active
）。
另一个问题是物理网卡状态。有时候，网线没插好，或者网卡驱动有问题，导致物理接口本身就没有
link up
。在加入bond之前，确保每个物理接口都能独立地
link up
。你可以用
ip link show enoX
来检查
state UP
。如果物理链路本身就不通，那LACP再怎么协商也没用。
负载均衡策略的误解也常导致性能不如预期。LACP模式下，真正的负载均衡是由交换机和服务器共同决定的。Linux bonding驱动的
xmit_hash_policy
参数（比如
layer2
、
layer2+3
、
layer3+4
）会影响服务器端出站流量的哈希计算。但入站流量的负载均衡则完全取决于交换机的哈希算法。如果你发现流量集中在某一条链路上，即使LACP状态是健康的，也可能是交换机的哈希算法不够理想，或者你的流量模式（比如大量单一大流）不适合当前的哈希策略。这时，尝试调整交换机的哈希策略（如果支持的话），或者改变Linux端的
xmit_hash_policy
（
nmcli connection modify mybond bond.options "xmit_hash_policy=layer2+3"
）可能会有所帮助。
最后，NetworkManager的“小脾气”。虽然我推荐
nmcli
，但有时NetworkManager在处理bond接口时会有一些奇怪的行为，尤其是在早期版本中。比如，你可能需要先
down
掉物理接口，再
up
bond接口，或者在修改bond配置后，彻底重启NetworkManager服务（
systemctl restart NetworkManager
）才能让更改生效。当然，这只是偶尔出现的情况，但知道有这个可能性，在排查时就能多一个思路。
超越LACP：理解不同的负载均衡策略及其应用场景
当我们谈论LACP时，实际上我们是在讨论
802.3ad
这个特定的bonding模式。但Linux bonding驱动提供了多种负载均衡策略，每种都有其独特的适用场景和局限性。理解这些，能帮助我们更好地选择适合自己网络环境的方案。
balance-rr
(Round-Robin)： 这种模式会将数据包按顺序轮流从每个可用接口发送出去。它的优点是能最大化聚合带宽，因为每个包都可能走不同的路径。但缺点也很明显：它可能会导致数据包乱序到达目的地，这对于TCP等需要有序传输的协议来说，会引入额外的重传和延迟。所以，我通常不会在通用IP网络中使用它，除非是对乱序不敏感的特定应用，或者是在一个非常受控的、低延迟的二层网络环境中。
active-backup
： 这是最简单也最常见的模式之一。只有一个接口是活动的，其他接口处于备份状态。当活动接口失效时，备份接口会立即接管。这种模式提供了出色的冗余性，但没有负载均衡能力——流量始终只走一条链路。我会在那些不需要额外带宽，但对可用性要求极高的场景下使用它，比如管理网络接口，或者连接到不支持LACP的旧交换机。
balance-xor
(XOR Policy)： 这种模式会根据源MAC地址与目的MAC地址的异或运算结果来选择发送接口。它能保证特定源-目的MAC对的流量始终走同一条链路，从而避免乱序。但它的负载均衡效果取决于流量的分布，如果大部分流量都流向同一个目标，那么负载均衡效果可能不佳。它不需要交换机支持LACP，只需要交换机将这些端口配置在同一个VLAN中即可。
802.3ad
(LACP)： 这就是我们前面重点讨论的模式。它通过LACP协议与交换机协商，根据源/目的MAC、IP、端口等信息进行哈希运算来分配流量。这是我最推荐的模式，因为它提供了良好的负载均衡和冗余，同时避免了乱序问题。但它要求交换机也支持并配置LACP。
balance-tlb
(Transmit Load Balancing)： 这种模式不需要交换机支持LACP。它根据每个接口的负载来动态分配出站流量。入站流量只通过一个接口接收，如果该接口失效，则由另一个接口接管。它在不依赖交换机的情况下提供了出站负载均衡，但入站仍是单点。
balance-alb
(Adaptive Load Balancing)： 类似于
balance-tlb
，但它在
balance-tlb
的基础上增加了入站负载均衡的能力，通过ARP操作动态调整MAC地址来引导入站流量。这通常需要网卡支持，且在某些网络环境下可能引发ARP缓存问题。
在选择这些策略时，我总是会问自己：我最看重的是什么？是最大化带宽、高可用性、还是避免乱序？我的网络交换机支持什么？这些问题的答案，往往就能指引我做出正确的选择。对于大多数现代数据中心环境，如果交换机支持，
802.3ad
无疑是兼顾性能和可靠性的最佳实践。
以上就是如何构建Linux网络接口聚合链路 使用LACP协议实现负载均衡的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/445781.html
微信扫一扫 
支付宝扫一扫 
