网口状态这件事我见过太多同事栽在同一个坑里业务报障说网络不通上去ip link show eth0一看明明显示state UP于是理直气壮地回复网口是好的结果问题根本没解决。追根究底是把软件层 up/down 和物理层 up/down 混为一谈了。这两个状态在 Linux 里是完全独立的两回事判断方法也不一样今天就把这层窗户纸捅破。这篇内容适合所有和 Linux 网络打交道的人——运维工程师、网络管理员、嵌入式开发甚至刚入门的小白。搞懂之后你会发现所谓灯亮着却 ping 不通 网线插着却没链路这类现象本质上就是两层状态不对齐。下面从概念讲到命令再到实战排查和避坑经验一次说透。1. 网口状态的两层含义软件层 up/down 与物理层 up/down1.1 软件层状态内核里的“开关”软件层 up/down在 Linux 里对应的是网络设备在内核协议栈层面的运行状态。你执行ip link set eth0 up或ifconfig eth0 up就是把这个开关打开执行ip link set eth0 down、ifconfig eth0 down或者驱动加载失败、接口被系统禁用就是把它关上。这个开关决定的是内核是否允许该接口参与数据收发。接口 down 的时候内核不会通过它收发任何报文不会响应 ARP不会运行 OSPF路由表里涉及这个接口的路由也基本处于不可用状态。你可以把软件层 up 理解成物业把单元门打开放行了住户能不能正常进出那还得看楼里有没有电梯、外面路有没有修好——这就是物理层的活儿了。有个细节值得提一下软件层 up 这个动作本身是不会去探测网线是否插着的。即使你根本没插网线只要ip link set eth0 up内核也会老老实实把接口置为 up它会用一套链路检测机制去感知物理层状态但感知结果不影响门开没开。所以你会看到一种现象网线被拔了ip link show仍然显示state UP只是在 flags 里多了一个NO-CARRIER。很多新手看UP就以为一切正常其实是理解错了。1.2 物理层状态线缆上的“载波”物理层 up/down指的是网卡底层的 PHY 芯片有没有检测到链路上的载波carrier。对电口来说PHY 芯片会持续和对端设备交换链路脉冲信号检测到信号、完成协商速率、双工就认为链路建立物理层 up信号丢失、协商失败物理层就 down。对光口来说就看有没有收到合法的光信号收光功率正常且信号有效物理层才 up。再打一个比方物理层 up/down 是门前那条路通不通。路通不通不取决于你把门开没开。物理层 down 的典型原因很直观网线没插好、线序不对、线缆损坏对端设备断电、端口被 shutdown、端口故障劣质水晶头导致接触不良接触电阻偏大光口没插光纤、光模块故障、光纤收发器故障光信号衰减过大链路预算不够物理层的状态不受ip link set up/down影响。你软件层 down 了只要网线还插着、对端端口还开着PHY 芯片照样能感知到链路信号。这个不受影响是理论情况实际有些驱动的实现会连带把 PHY 也关掉后面我会专门说这个坑。1.3 两层状态怎么组合网络才算真正可用写这篇文章最核心的目的就是让你明白软件层 up/down 和物理层 up/down 是两个独立变量可以组合出四种状态只有一种是真的网络可用。软件层物理层现象是否可用upup网线正常、接口开启、链路协商成功可用updown网线断/对端设备关机接口仍显示 up但没有载波不可用downup网线插着、链路正常但接口被人为关闭不可用downdown接口被关 网线也断了不可用我遇到最高频的误判就集中在第二行软件层 up、物理层 down却只看到state UP就下了网络没问题的结论。排查网络问题的时候请用两条腿走路一个命令看软件层一个命令看物理层缺一不可。2. 判断两类状态的关键命令2.1 ip link show一条命令看懂两个层ip link show是 Linux 下查看接口状态最常用的命令没有之一。看一个典型输出$ ip link show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000尖括号里的 flags 才是重点UP软件层已启用。对应你执行过ip link set eth0 up。LOWER_UP物理层链路已建立驱动向内核报告检测到了载波。凡是插着网线、协商正常的接口都会带这个标志。NO-CARRIER物理层链路丢失。网线被拔、对端关机、光信号丢失时会出现本质是内核收到驱动上报的 carrier 丢失事件。注意NO-CARRIER出现时一定同时存在UP软件层还开着因为接口 down 的时候内核根本不维护 carrier 状态。state UP那一列是内核根据 flags 计算出的 operstate 报告值。如果 flags 里有UPoperstate 大概率是up但这只代表软件层状态不能代表物理链路。所以下次看到state UP先别高兴瞟一眼有没有LOWER_UP再下结论。网线拔掉的瞬间输出会变成这样2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000有人会觉得奇怪state UP后面为什么没有LOWER_UP因为软件层开关还开着但物理层已经没有载波了。这一行就把两层状态展示得明明白白软件层 UP、物理层 DOWN。2.2 ethtool物理层状态最直接的证据ethtool是网卡驱动的调校和诊断工具查物理层状态时它给出的信息最直接。跑一下$ ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Link detected: yes不同内核版本输出格式会有差异但Link detected这一行稳定存在Link detected: yes物理层 upLink detected: no物理层 downSpeed和Duplex也能给你额外线索。Link detected: yes但Speed显示Unknown!、Duplex显示Unknown!往往说明协商异常或不完整虽说是物理层 up但实际链路质量堪忧跑起来丢包率高、速度上不去。通常是网线线序不对特别是交叉线用在现代交换机上、线缆过长或质量差。判断物理层状态我最推荐ethtool因为它直接和 PHY 芯片对话不看内核协议栈的脸色比通过ip link show间接判断更准确。不过要注意较新的内核5.x 之后对ethtool的输出做了重构原来的Settings for eth0可能变成一个分段式的界面甚至用ethtool eth0时部分内容挪到了ethtool enp3s0与ethtool --phy enp3s0等子命令里。Link detected在基础输出里依然保留这点没变。2.3 sysfs 属性适合脚本判断的底层接口如果你写监控脚本、巡检程序不想解析命令行文本可以直接读 sysfs 暴露的内核属性$ cat /sys/class/net/eth0/operstate up $ cat /sys/class/net/eth0/carrier 1operstate对应软件层和协议层的综合状态取值常见有up、down、unknown、dormant等。一般up表示接口上一级链路管理已启用。carrier物理层载波状态1表示有载波0表示无载波。直接对应 PHY 检测到的链路信号是判断物理层 up/down 的底层证据。这两个文件有一个非常重要的使用限制我必须在这里强调当接口处于软件层 down 状态时carrier文件的值是不可信的通常为 0。因为内核在接口 down 时不会维护 carrier 状态。所以脚本里先判断operstate再读carrier不要一上来就cat carrier拿 0 当作网线断了的结论。还有一个权限细节/sys/class/net/eth0/carrier在部分发行版上默认只有 root 可读普通用户cat会被拒绝。建议脚本用 root 执行或者用sudo降权运行。operstate一般普通用户可读。2.4 老命令 ifconfig 里对应的是什么虽然ip命令已经取代ifconfig但老系统、嵌入式环境里ifconfig仍然高频出现而且很多老运维第一反应就是ifconfig eth0。它的输出里同样藏了两层信息$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0c:29:xx:xx:xx inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fexx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12345 errors:0 dropped:0 overruns:0 frame:0 TX packets:6789 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1234567 (1.1 MiB) TX bytes:890123 (869.5 KiB)第二行UP BROADCAST RUNNING MULTICAST中UP软件层 upRUNNING物理层链路 up等价于ip link里的LOWER_UP如果只有UP没有RUNNING说明接口开着但物理链路丢了TX 统计里的carrier:0也值得注意它表示发送数据时发生过 carrier 错误的次数。如果这个数字持续增长驱动层面已经报告了大量传输失败往往伴随物理层断断续续。ifconfig在嵌入式 Linux 和旧版 CentOS 里还很常见因此会看的同学建议就把UP和RUNNING两个词的组合记死别只看UP。3. 网口故障排查实操从现象到定位3.1 四步定位法遇到网口不通、ping 不通、业务报障这类问题我总结了一套固定的四步排查法按顺序执行基本不会漏判查物理层ethtool eth0 | grep Link detected确认有没有链路。再看一眼Speed是否异常。查软件层ip link show eth0确认 flags 里有没有UP、有没有LOWER_UP区分NO-CARRIER。查 IP 配置ip addr show eth0确认接口上有没有正确配置 IP掩码、广播地址是否合理。查连通性ping网关、ping对端地址同时配合ip -s link show eth0看 RX/TX 统计判断是不是只有单方向通。这套流程的顺序是有讲究的先看物理层因为物理层 down 是最底层的故障什么协议都救不回来再看软件层因为软件层 down 意味着内核压根不干活然后才是 IP 配置和连通性属于更高层次的问题。为了方便对照我把典型现象和对应处理列成一张速查表现象查看命令判断要点处理方向ethtool显示Link detected: noethtool eth0物理层 down检查网线、对端端口、光模块、交换机配置ip link有UP但无LOWER_UPip link show eth0软件层 up物理层 down大概率网线脱落或对端端口关闭ip link显示state DOWNip link show eth0软件层 downip link set eth0 up或检查驱动是否有异常有UP、有LOWER_UP、没 IPip addr show eth0IP 层配置缺失配置 IP检查 DHCP 或静态配置有 IP、ping 不通网关ip route show、抓包路由或防火墙问题检查默认路由、防火墙、ARP 学习情况3.2 案例一网线脱落软件层还在 up某次线上巡检一台 Dell 服务器的数据库实例提示主备同步异常。远程登上去第一眼ip link show bond0显示5: bond0: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000bond0 整体软件层 up、物理层 up看起来一切正常。但它是两个物理口绑的 mode 1主备模式真正干活的只有一个 ens1f0。于是再看$ ip link show ens1f0 3: ens1f0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000真相大白ens1f0拉了无载波。到机房一看尾纤松动脱落重插之后$ ethtool ens1f0 | grep Link Link detected: yes同步恢复正常。这个案例最能说明问题看一眼 bond0 整体状态不够得拆到物理口。而NO-CARRIERUP的组合就是网线/光纤掉了最典型的信号。3.3 案例二对端交换机 shutdown本端灯却还亮着另一种常见情况是物理链路状态并不是本端插没插线这么简单它还取决于对端端口状态。有次客户说跨机房的专线不通本侧是 Linux 服务器对端是运营商接入设备。本端ethtool显示Link detected: no但光纤两端的光模块灯都在闪物理连接从肉眼看不出来断点。打了一圈电话运营商那边排查发现接入交换机那个 trunk 口被后台自动 shutdown 了网关设备安全策略触发。端口 shutdown 之后交换机不再发出协商信号本端 PHY 自然检测不到载波。这种情况和网线拔了从本端看没有任何区别都是Link detected: no、NO-CARRIER。可出现在让人误以为是线路物理中断实际上问题在对端逻辑配置。所以排查物理层 down 的时候一定要记住物理层 up/down 不止取决于本端插没插线还取决于对端是否在正常发出信号。网线、光纤、对端设备电口/光口全部都是物理链路的一部分。3.4 一个简单的多网口检测脚本如果服务器有多个网口手动一条条ethtool太磨叽写个脚本一次性输出所有网口的两层状态非常实用。下面这个脚本我放在生产环境跑了很久简单可靠#!/bin/bash for dev in /sys/class/net/*; do name$(basename $dev) [ $name lo ] continue oper$(cat $dev/operstate 2/dev/null) carrier$(cat $dev/carrier 2/dev/null) echo $name: operstate$oper carrier$carrier done执行结果类似ens33: operstateup carrier1 ens38: operstateup carrier0 docker0: operstatedown carrier0脚本里lo被忽略因为回环接口没有物理层概念。docker0这类虚拟网桥虽然也有operstate和carrier但含义和物理网口不完全一致判断时注意区分。如果一个网口operstateup但carrier0那基本可以锁定物理链路有问题如果operstatedown而carrier0不能据此判断网线状态需要先用ip link set dev up把接口拉起来再判断。更精细的做法是用ip -j link show输出 JSON再用jq解析比如$ ip -j link show ens33输出里直接包含operstate: up、link/ether和 flag 列表脚本解析起来更干净。不过ip -j需要高版本 iproute2老系统不一定支持生产环境建议先确认版本。4. 常见疑难场景与经验避坑4.1 ip link set down 之后carrier 还能信吗前面提到过一个大坑接口软件层 down 之后/sys/class/net/eth0/carrier文件会变成 0。这时候你不能得出网线没插的结论。我实测过几台不同厂商的服务器Intel I350 网卡ip link set eth0 down之后ethtool eth0仍然能读到Link detected: yes因为 PHY 还在工作驱动也还保留了一定的诊断能力。某些 Realtek 板载网卡接口 down 之后ethtool甚至会直接报错读不了链路状态必须通过网口物理 LED 判断。部分完整关闭 PHY 的驱动接口 down 后 PHY 连同网卡一起休眠物理链路检测全部失效。所以判断物理层状态的最佳前提是接口处于软件层 up 状态。遇到接口被 down 了但想确认网线状态的场景先把接口拉起来再查别拿 down 状态下的 carrier 值较真。这条经验在写自愈脚本时尤其重要——脚本如果检测到carrier0就发告警但忽略了对端接口是 down 的可能会刷一堆误报。4.2 NO-CARRIER 标志到底在说什么NO-CARRIER是内核网络设备驱动上报 carrier 丢失后在接口 flags 里设置的标志。它有一个隐含的信息这个接口曾经有过载波现在丢了。如果接口从来没插过网线上电启动后第一次ip link set up某些驱动会直接置NO-CARRIER但如果插拔过网线驱动就会记录事件并更新标志。看到NO-CARRIER的时候排查重点应该是载波是什么时候丢的、为什么丢的。常用辅助手段是看dmesg$ dmesg | tail -50里面有link down、link up的日志能显示载波丢失和恢复的时间点。比如e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Down e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex这两行日志之间的时间差就是你网线断开或对端故障的窗口。这个比单纯看最终状态要有用得多因为最终状态只能告诉你现在断了日志能告诉你是五分钟前断的、重新恢复过没有。4.3 虚拟网口和光口物理层判断要换思路桥接接口bridge、绑定接口bond、VLAN 子接口这类虚拟接口本身没有 PHY 芯片没有物理层 up/down概念。它们的 carrier 状态通常继承自底层物理口或者由内核根据成员状态计算。比如 bond0 在 mode 1 主备模式下只要有一个物理成员 upbond0 整体就维持 up在 mode 4LACP下要求活动成员协商成功bond0 才 up。排查虚拟接口的时候别在 bond0 或者 br0 上纠结carrier直接下钻到成员物理口。bonding有个/proc/net/bonding/bond0文件能看到每个成员口的状态$ cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: ens1f0 MII Status: up Speed: 10000 Mbps Duplex: Full Link Failure Count: 1 Slave Interface: ens1f1 MII Status: up Speed: 10000 Mbps Duplex: Full Link Failure Count: 0这个文件里的MII Status就是每个物理口的物理链路状态比从 sysfs 逐个翻更直观。顺带说一句/proc/net/bonding/bond0还记录Link Failure Count如果这个数字不断增长说明物理链路在反复抖动基本可以判断是网线接触不良或者光模块劣化。光口SFP/SFP/QSFP和电口有本质区别电口检测的是双绞线上的脉冲信号光口检测的是光模块接收到的光功率和信号锁定状态。光口物理层 up 的必要条件是光模块安装到位供电正常光纤两端都插好且收发方向正确A 端发要接到 B 端收对端光模块工作正常正在发光收光功率在模块灵敏度范围之内ethtool eth0对光口同样显示Link detected但建议再看两个诊断值$ ethtool -m eth0这个命令读取光模块的 DOM 诊断信息。重点关注Laser output power发光功率和Receiver signal optical power收光功率。如果收光功率低于模块阈值比如 -20dBm 以下即使Link detected: yes链路稳定性也很差可能出现间歇性通断。这点是电口没有的诊断维度。4.4 ethtool -p 闪灯找物理位置最后分享一个机房实践利器。几十台服务器梭在机柜里标了主机名有时候也分不清对应哪个物理网口这时候用ethtool -p让某个接口的 LED 闪起来物理定位最快$ ethtool -p ens33 30ens33对应的网口 LED 会闪烁 30 秒机柜里一眼就能找到。配合前面的脚本接口名把逻辑接口和物理位置对上再去做网线整理和维护效率能提高不少。这个功能依赖驱动支持绝大多数主流网卡都能用少数虚拟接口或老驱动不支持遇到报错别纠结多换几个口试。我个人在实际操作中还有一个习惯把软件层 UP 物理层 UP这两个条件写进所有网络监控脚本里作为互锁条件任何一个不满足就触发告警。因为只看任何单一指标都可能被误导而两个指标都看会发现很多看起来没问题的隐患。哪怕是Link detected: yes看着很稳的接口也建议定期看看ethtool -S eth0里的rx_errors、tx_errors、rx_crc_errors等计数器这些值才是物理链路真实健康状况的长期反映。
网口状态这件事我见过太多同事栽在同一个坑里业务报障说网络不通上去ip link show eth0一看明明显示state UP于是理直气壮地回复网口是好的结果问题根本没解决。追根究底是把软件层 up/down 和物理层 up/down 混为一谈了。这两个状态在 Linux 里是完全独立的两回事判断方法也不一样今天就把这层窗户纸捅破。这篇内容适合所有和 Linux 网络打交道的人——运维工程师、网络管理员、嵌入式开发甚至刚入门的小白。搞懂之后你会发现所谓灯亮着却 ping 不通 网线插着却没链路这类现象本质上就是两层状态不对齐。下面从概念讲到命令再到实战排查和避坑经验一次说透。1. 网口状态的两层含义软件层 up/down 与物理层 up/down1.1 软件层状态内核里的“开关”软件层 up/down在 Linux 里对应的是网络设备在内核协议栈层面的运行状态。你执行ip link set eth0 up或ifconfig eth0 up就是把这个开关打开执行ip link set eth0 down、ifconfig eth0 down或者驱动加载失败、接口被系统禁用就是把它关上。这个开关决定的是内核是否允许该接口参与数据收发。接口 down 的时候内核不会通过它收发任何报文不会响应 ARP不会运行 OSPF路由表里涉及这个接口的路由也基本处于不可用状态。你可以把软件层 up 理解成物业把单元门打开放行了住户能不能正常进出那还得看楼里有没有电梯、外面路有没有修好——这就是物理层的活儿了。有个细节值得提一下软件层 up 这个动作本身是不会去探测网线是否插着的。即使你根本没插网线只要ip link set eth0 up内核也会老老实实把接口置为 up它会用一套链路检测机制去感知物理层状态但感知结果不影响门开没开。所以你会看到一种现象网线被拔了ip link show仍然显示state UP只是在 flags 里多了一个NO-CARRIER。很多新手看UP就以为一切正常其实是理解错了。1.2 物理层状态线缆上的“载波”物理层 up/down指的是网卡底层的 PHY 芯片有没有检测到链路上的载波carrier。对电口来说PHY 芯片会持续和对端设备交换链路脉冲信号检测到信号、完成协商速率、双工就认为链路建立物理层 up信号丢失、协商失败物理层就 down。对光口来说就看有没有收到合法的光信号收光功率正常且信号有效物理层才 up。再打一个比方物理层 up/down 是门前那条路通不通。路通不通不取决于你把门开没开。物理层 down 的典型原因很直观网线没插好、线序不对、线缆损坏对端设备断电、端口被 shutdown、端口故障劣质水晶头导致接触不良接触电阻偏大光口没插光纤、光模块故障、光纤收发器故障光信号衰减过大链路预算不够物理层的状态不受ip link set up/down影响。你软件层 down 了只要网线还插着、对端端口还开着PHY 芯片照样能感知到链路信号。这个不受影响是理论情况实际有些驱动的实现会连带把 PHY 也关掉后面我会专门说这个坑。1.3 两层状态怎么组合网络才算真正可用写这篇文章最核心的目的就是让你明白软件层 up/down 和物理层 up/down 是两个独立变量可以组合出四种状态只有一种是真的网络可用。软件层物理层现象是否可用upup网线正常、接口开启、链路协商成功可用updown网线断/对端设备关机接口仍显示 up但没有载波不可用downup网线插着、链路正常但接口被人为关闭不可用downdown接口被关 网线也断了不可用我遇到最高频的误判就集中在第二行软件层 up、物理层 down却只看到state UP就下了网络没问题的结论。排查网络问题的时候请用两条腿走路一个命令看软件层一个命令看物理层缺一不可。2. 判断两类状态的关键命令2.1 ip link show一条命令看懂两个层ip link show是 Linux 下查看接口状态最常用的命令没有之一。看一个典型输出$ ip link show eth0 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000尖括号里的 flags 才是重点UP软件层已启用。对应你执行过ip link set eth0 up。LOWER_UP物理层链路已建立驱动向内核报告检测到了载波。凡是插着网线、协商正常的接口都会带这个标志。NO-CARRIER物理层链路丢失。网线被拔、对端关机、光信号丢失时会出现本质是内核收到驱动上报的 carrier 丢失事件。注意NO-CARRIER出现时一定同时存在UP软件层还开着因为接口 down 的时候内核根本不维护 carrier 状态。state UP那一列是内核根据 flags 计算出的 operstate 报告值。如果 flags 里有UPoperstate 大概率是up但这只代表软件层状态不能代表物理链路。所以下次看到state UP先别高兴瞟一眼有没有LOWER_UP再下结论。网线拔掉的瞬间输出会变成这样2: eth0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000有人会觉得奇怪state UP后面为什么没有LOWER_UP因为软件层开关还开着但物理层已经没有载波了。这一行就把两层状态展示得明明白白软件层 UP、物理层 DOWN。2.2 ethtool物理层状态最直接的证据ethtool是网卡驱动的调校和诊断工具查物理层状态时它给出的信息最直接。跑一下$ ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Link detected: yes不同内核版本输出格式会有差异但Link detected这一行稳定存在Link detected: yes物理层 upLink detected: no物理层 downSpeed和Duplex也能给你额外线索。Link detected: yes但Speed显示Unknown!、Duplex显示Unknown!往往说明协商异常或不完整虽说是物理层 up但实际链路质量堪忧跑起来丢包率高、速度上不去。通常是网线线序不对特别是交叉线用在现代交换机上、线缆过长或质量差。判断物理层状态我最推荐ethtool因为它直接和 PHY 芯片对话不看内核协议栈的脸色比通过ip link show间接判断更准确。不过要注意较新的内核5.x 之后对ethtool的输出做了重构原来的Settings for eth0可能变成一个分段式的界面甚至用ethtool eth0时部分内容挪到了ethtool enp3s0与ethtool --phy enp3s0等子命令里。Link detected在基础输出里依然保留这点没变。2.3 sysfs 属性适合脚本判断的底层接口如果你写监控脚本、巡检程序不想解析命令行文本可以直接读 sysfs 暴露的内核属性$ cat /sys/class/net/eth0/operstate up $ cat /sys/class/net/eth0/carrier 1operstate对应软件层和协议层的综合状态取值常见有up、down、unknown、dormant等。一般up表示接口上一级链路管理已启用。carrier物理层载波状态1表示有载波0表示无载波。直接对应 PHY 检测到的链路信号是判断物理层 up/down 的底层证据。这两个文件有一个非常重要的使用限制我必须在这里强调当接口处于软件层 down 状态时carrier文件的值是不可信的通常为 0。因为内核在接口 down 时不会维护 carrier 状态。所以脚本里先判断operstate再读carrier不要一上来就cat carrier拿 0 当作网线断了的结论。还有一个权限细节/sys/class/net/eth0/carrier在部分发行版上默认只有 root 可读普通用户cat会被拒绝。建议脚本用 root 执行或者用sudo降权运行。operstate一般普通用户可读。2.4 老命令 ifconfig 里对应的是什么虽然ip命令已经取代ifconfig但老系统、嵌入式环境里ifconfig仍然高频出现而且很多老运维第一反应就是ifconfig eth0。它的输出里同样藏了两层信息$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0c:29:xx:xx:xx inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fexx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12345 errors:0 dropped:0 overruns:0 frame:0 TX packets:6789 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1234567 (1.1 MiB) TX bytes:890123 (869.5 KiB)第二行UP BROADCAST RUNNING MULTICAST中UP软件层 upRUNNING物理层链路 up等价于ip link里的LOWER_UP如果只有UP没有RUNNING说明接口开着但物理链路丢了TX 统计里的carrier:0也值得注意它表示发送数据时发生过 carrier 错误的次数。如果这个数字持续增长驱动层面已经报告了大量传输失败往往伴随物理层断断续续。ifconfig在嵌入式 Linux 和旧版 CentOS 里还很常见因此会看的同学建议就把UP和RUNNING两个词的组合记死别只看UP。3. 网口故障排查实操从现象到定位3.1 四步定位法遇到网口不通、ping 不通、业务报障这类问题我总结了一套固定的四步排查法按顺序执行基本不会漏判查物理层ethtool eth0 | grep Link detected确认有没有链路。再看一眼Speed是否异常。查软件层ip link show eth0确认 flags 里有没有UP、有没有LOWER_UP区分NO-CARRIER。查 IP 配置ip addr show eth0确认接口上有没有正确配置 IP掩码、广播地址是否合理。查连通性ping网关、ping对端地址同时配合ip -s link show eth0看 RX/TX 统计判断是不是只有单方向通。这套流程的顺序是有讲究的先看物理层因为物理层 down 是最底层的故障什么协议都救不回来再看软件层因为软件层 down 意味着内核压根不干活然后才是 IP 配置和连通性属于更高层次的问题。为了方便对照我把典型现象和对应处理列成一张速查表现象查看命令判断要点处理方向ethtool显示Link detected: noethtool eth0物理层 down检查网线、对端端口、光模块、交换机配置ip link有UP但无LOWER_UPip link show eth0软件层 up物理层 down大概率网线脱落或对端端口关闭ip link显示state DOWNip link show eth0软件层 downip link set eth0 up或检查驱动是否有异常有UP、有LOWER_UP、没 IPip addr show eth0IP 层配置缺失配置 IP检查 DHCP 或静态配置有 IP、ping 不通网关ip route show、抓包路由或防火墙问题检查默认路由、防火墙、ARP 学习情况3.2 案例一网线脱落软件层还在 up某次线上巡检一台 Dell 服务器的数据库实例提示主备同步异常。远程登上去第一眼ip link show bond0显示5: bond0: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000bond0 整体软件层 up、物理层 up看起来一切正常。但它是两个物理口绑的 mode 1主备模式真正干活的只有一个 ens1f0。于是再看$ ip link show ens1f0 3: ens1f0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000真相大白ens1f0拉了无载波。到机房一看尾纤松动脱落重插之后$ ethtool ens1f0 | grep Link Link detected: yes同步恢复正常。这个案例最能说明问题看一眼 bond0 整体状态不够得拆到物理口。而NO-CARRIERUP的组合就是网线/光纤掉了最典型的信号。3.3 案例二对端交换机 shutdown本端灯却还亮着另一种常见情况是物理链路状态并不是本端插没插线这么简单它还取决于对端端口状态。有次客户说跨机房的专线不通本侧是 Linux 服务器对端是运营商接入设备。本端ethtool显示Link detected: no但光纤两端的光模块灯都在闪物理连接从肉眼看不出来断点。打了一圈电话运营商那边排查发现接入交换机那个 trunk 口被后台自动 shutdown 了网关设备安全策略触发。端口 shutdown 之后交换机不再发出协商信号本端 PHY 自然检测不到载波。这种情况和网线拔了从本端看没有任何区别都是Link detected: no、NO-CARRIER。可出现在让人误以为是线路物理中断实际上问题在对端逻辑配置。所以排查物理层 down 的时候一定要记住物理层 up/down 不止取决于本端插没插线还取决于对端是否在正常发出信号。网线、光纤、对端设备电口/光口全部都是物理链路的一部分。3.4 一个简单的多网口检测脚本如果服务器有多个网口手动一条条ethtool太磨叽写个脚本一次性输出所有网口的两层状态非常实用。下面这个脚本我放在生产环境跑了很久简单可靠#!/bin/bash for dev in /sys/class/net/*; do name$(basename $dev) [ $name lo ] continue oper$(cat $dev/operstate 2/dev/null) carrier$(cat $dev/carrier 2/dev/null) echo $name: operstate$oper carrier$carrier done执行结果类似ens33: operstateup carrier1 ens38: operstateup carrier0 docker0: operstatedown carrier0脚本里lo被忽略因为回环接口没有物理层概念。docker0这类虚拟网桥虽然也有operstate和carrier但含义和物理网口不完全一致判断时注意区分。如果一个网口operstateup但carrier0那基本可以锁定物理链路有问题如果operstatedown而carrier0不能据此判断网线状态需要先用ip link set dev up把接口拉起来再判断。更精细的做法是用ip -j link show输出 JSON再用jq解析比如$ ip -j link show ens33输出里直接包含operstate: up、link/ether和 flag 列表脚本解析起来更干净。不过ip -j需要高版本 iproute2老系统不一定支持生产环境建议先确认版本。4. 常见疑难场景与经验避坑4.1 ip link set down 之后carrier 还能信吗前面提到过一个大坑接口软件层 down 之后/sys/class/net/eth0/carrier文件会变成 0。这时候你不能得出网线没插的结论。我实测过几台不同厂商的服务器Intel I350 网卡ip link set eth0 down之后ethtool eth0仍然能读到Link detected: yes因为 PHY 还在工作驱动也还保留了一定的诊断能力。某些 Realtek 板载网卡接口 down 之后ethtool甚至会直接报错读不了链路状态必须通过网口物理 LED 判断。部分完整关闭 PHY 的驱动接口 down 后 PHY 连同网卡一起休眠物理链路检测全部失效。所以判断物理层状态的最佳前提是接口处于软件层 up 状态。遇到接口被 down 了但想确认网线状态的场景先把接口拉起来再查别拿 down 状态下的 carrier 值较真。这条经验在写自愈脚本时尤其重要——脚本如果检测到carrier0就发告警但忽略了对端接口是 down 的可能会刷一堆误报。4.2 NO-CARRIER 标志到底在说什么NO-CARRIER是内核网络设备驱动上报 carrier 丢失后在接口 flags 里设置的标志。它有一个隐含的信息这个接口曾经有过载波现在丢了。如果接口从来没插过网线上电启动后第一次ip link set up某些驱动会直接置NO-CARRIER但如果插拔过网线驱动就会记录事件并更新标志。看到NO-CARRIER的时候排查重点应该是载波是什么时候丢的、为什么丢的。常用辅助手段是看dmesg$ dmesg | tail -50里面有link down、link up的日志能显示载波丢失和恢复的时间点。比如e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Down e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex这两行日志之间的时间差就是你网线断开或对端故障的窗口。这个比单纯看最终状态要有用得多因为最终状态只能告诉你现在断了日志能告诉你是五分钟前断的、重新恢复过没有。4.3 虚拟网口和光口物理层判断要换思路桥接接口bridge、绑定接口bond、VLAN 子接口这类虚拟接口本身没有 PHY 芯片没有物理层 up/down概念。它们的 carrier 状态通常继承自底层物理口或者由内核根据成员状态计算。比如 bond0 在 mode 1 主备模式下只要有一个物理成员 upbond0 整体就维持 up在 mode 4LACP下要求活动成员协商成功bond0 才 up。排查虚拟接口的时候别在 bond0 或者 br0 上纠结carrier直接下钻到成员物理口。bonding有个/proc/net/bonding/bond0文件能看到每个成员口的状态$ cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: ens1f0 MII Status: up Speed: 10000 Mbps Duplex: Full Link Failure Count: 1 Slave Interface: ens1f1 MII Status: up Speed: 10000 Mbps Duplex: Full Link Failure Count: 0这个文件里的MII Status就是每个物理口的物理链路状态比从 sysfs 逐个翻更直观。顺带说一句/proc/net/bonding/bond0还记录Link Failure Count如果这个数字不断增长说明物理链路在反复抖动基本可以判断是网线接触不良或者光模块劣化。光口SFP/SFP/QSFP和电口有本质区别电口检测的是双绞线上的脉冲信号光口检测的是光模块接收到的光功率和信号锁定状态。光口物理层 up 的必要条件是光模块安装到位供电正常光纤两端都插好且收发方向正确A 端发要接到 B 端收对端光模块工作正常正在发光收光功率在模块灵敏度范围之内ethtool eth0对光口同样显示Link detected但建议再看两个诊断值$ ethtool -m eth0这个命令读取光模块的 DOM 诊断信息。重点关注Laser output power发光功率和Receiver signal optical power收光功率。如果收光功率低于模块阈值比如 -20dBm 以下即使Link detected: yes链路稳定性也很差可能出现间歇性通断。这点是电口没有的诊断维度。4.4 ethtool -p 闪灯找物理位置最后分享一个机房实践利器。几十台服务器梭在机柜里标了主机名有时候也分不清对应哪个物理网口这时候用ethtool -p让某个接口的 LED 闪起来物理定位最快$ ethtool -p ens33 30ens33对应的网口 LED 会闪烁 30 秒机柜里一眼就能找到。配合前面的脚本接口名把逻辑接口和物理位置对上再去做网线整理和维护效率能提高不少。这个功能依赖驱动支持绝大多数主流网卡都能用少数虚拟接口或老驱动不支持遇到报错别纠结多换几个口试。我个人在实际操作中还有一个习惯把软件层 UP 物理层 UP这两个条件写进所有网络监控脚本里作为互锁条件任何一个不满足就触发告警。因为只看任何单一指标都可能被误导而两个指标都看会发现很多看起来没问题的隐患。哪怕是Link detected: yes看着很稳的接口也建议定期看看ethtool -S eth0里的rx_errors、tx_errors、rx_crc_errors等计数器这些值才是物理链路真实健康状况的长期反映。
