Linux多网卡负载均衡需据目标选方案：带宽叠加用bonding mode=0/4（需交换机聚合）、高可用用mode=1、免交换机双向负载用mode=6、多ISP分流用策略路由+多路由表。
Linux 多网卡负载均衡没有“一键开启”的通用方案，必须先明确目标：你要的是带宽叠加（如两块千兆卡跑出接近2Gbps），还是故障自动切换，或是多出口分流（比如走不同ISP）？选错路径，配置完流量照样只走一张卡。
nmcli team 配置最容易踩坑的四个点
如果你用的是 RHEL 7+/CentOS 7+/银河麒麟等主流发行版，nmcli 是首选，但直接抄命令几乎必失败：
-
nmcli connection down必须先执行——哪怕接口显示disconnected，只要它还关联着某个连接（如"System ens33"），后续加team-slave就会报device is already managed - 创建
team主接口时，config参数里的 JSON 必须用单引号包裹，且runner.name字段不能漏：比如主备写成'{"runner": {"name": "activebackup"}}'，少个r（写成activebackup）就静默失败 -
master指的是主连接的con-name（不是ifname），添加 slave 时写master team0，前提是创建 team 时用了con-name team0；若你写的是con-name myteam，这里就必须同步改成master myteam -
teamd守护进程只在第一个team-slaveup时启动——所以顺序只能是：nmcli connection up team0-ens33→nmcli connection up team0-ens34→nmcli connection up team0；先up team0，teamd不拉起，整个 team 接口永远unmanaged
bonding mode=6（balance-alb）为什么比 mode=0/4 更适合普通环境
mode=6 是唯一不需要交换机配合、又能实现收发双向负载的模式，特别适合虚拟机、测试环境或交换机不支持 LACP 的场景：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 发送流量按源/目的 IP+端口哈希分发到不同物理口，接收流量通过 ARP 协商让对端把响应包发到当前活跃口，避免乱序
- 不用改交换机配置，插上线就能用；而
mode=0（balance-rr）和mode=4（802.3ad）都要求交换机端口聚合，否则可能丢包或 MAC 抖动 - 纯无线网卡不支持
mode=6——内核会拒绝加载，报错Unsupported device type for mode=6 - 配置时
BONDING_OPTS必须包含miimon=100（链路检测间隔），否则故障切换延迟高达数分钟；primary=参数可选，但建议指定一块网卡为默认出口，避免初始路由混乱
策略路由才是真·多出口负载均衡的解法
当两张网卡连的是不同子网甚至不同 ISP（如 eth0 走电信、eth1 走联通），靠 bonding 绑定没用——bonding 要求所有成员口在同一二层网络。这时必须用策略路由 + 多路由表：
- 每张网卡配独立路由表（如
tab_eth0、tab_eth1），各自加default via X.X.X.1 dev eth0 - 用
ip rule add from 192.168.10.100 table tab_eth0指定源 IP 查哪张表，不能只靠ip route add default——Linux 默认只查main表，不加规则等于白配 - 要实现“轮询式”负载（比如 HTTP 请求交替走两个出口），得结合
iptables -t mangle打 fwmark，再用ip rule add fwmark 1 table tab_eth0分流，否则所有流量仍走第一条匹配规则 - 记得关掉反向路径过滤：
sysctl -w net.ipv4.conf.all.rp_filter=0，否则跨表回包会被丢弃，SSH 都连不上
真正难的不是敲几行命令，而是搞清你的物理拓扑：两张网卡是不是接在同一台交换机？IP 是否同网段？对端设备是否可控？这些决定了该用 team、bonding 还是策略路由——选错模型，后面所有参数调得再细也没用。
