linux系统一般由什么组成 linux系统中一般用什么命令查看网络接口状态

最准的Linux Bonding状态检查方式是直接读取/proc/net/bonding/bond0，该文件由内核bonding驱动实时生成，包含Bonding Mode、MII Status、Active Slave等关键字段，不依赖用户状态工具；若文件不存在，需先确认bonding模块是否加载及bond0接口是否已启用。

直接看 /proc/net/bonding/ 是最准的

Linux的bonding 驱动把所有聚合接口的实时状态写进/proc/net/bonding/下的文件，比如bond0就对应/proc/net/bonding/bond0。这个路径输出是内核仿真数据，不依赖用户状态工具或NetworkManager状态，只要bonding模块加载、bond接口up了，就一定有内容。

执行：cat /proc/net/bonding/bond0

你会看到类似这样的关键字段：Bonding Mode: 显示实际有效的模式（如 802.3ad 或 active-backup）MII Status: 每个从接口的传输物理层状态（up/down）Link Failure Count: 该从接口历史断连次数，非零值说明曾出过仓库Active Slave: 当前真正转发的接口（mode=1 下尤其重要）

如果报错 没有这样的文件或目录，说明或者没有加载绑定模块（lsmod | grep bond），或者bond接口根本没启用（ip link show bond0看是否且状态UP）。ip link show bond0能快速确认聚合接口现在

重点看三行接口是否名后中间的状态UP：表示内核已启用该 bondlink/ether 后的 MAC 地址：正常情况下应该为某个从机的 MAC（mode=1）或由bonding自生成（mode=4）形成的链路层绑定：这是bonding接口的明确标识，普通宽带卡不会出现这个词

如果只看到state DOWN，即使配置文件写对了，也说明 ifup bond0 或 nmcli 连接 up bond0 没执行，或者slave 初始化尚未 up。用 ethtool 设备 bond0 查 LACP 协商细节

当使用 mode=4（802.3ad/LACP）时，ethtool 是唯一能告诉你“LACP 是否真通了”的工具。会显示对端交换机是否响应、聚合组 ID 是否匹配、端口是否进入聚合状态。

CentOS Linux 7.9.2009

CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业服务器历史上仍然可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛着称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全修复修复风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。下载

运行：ethtool bond0

重点关注：Bond模式：应为802.3ad，不是balance-xor或其他别名检测到链接伙伴：必须是yes，否则LACP握手失败从属接口：eth0下的链接检测到： 和 MII Status:：两个都得是 up 没有 “LACPDU timeout” 或 “No LACPDU returned” 类错误信息

注意：ethtool 对 mode=1 不显示 LACP 相关字段，别以为它坏了——mode=1 根本不用 LACP。nmcli dev 只反映 NetworkManager 管理视角

如果你用 nmcli 配置的 bond（比如 nmcli 连接添加类型 bond ...），那 nmcli dev 会上市 bond0 并标出连接状态。但它不验证底层绑定驱动是否真正在工作。

常见错误点：已连接，但 cat /proc/net/bonding/bond0 报错：说明 NM 认为连上了，其实内核绑定没起来（比如 Slave 报错配置漏了 MASTER=bond0）显示已断开，但 ip link show bond0 是 UP：显示说明 NM 没有接管这个接口（可能是手动用 ifup 启的，或者配置里写了 Managed=no）nmcli dev 不显示 Slave 中断状态，只显示它们是非托管或断开连接，不能代替 /proc/net/bonding/

真正可靠的聚合状态，永远以 /proc/net/bonding/ 为准；其余命令只是辅助定位哪一层生长问题。