1. 故障现场不是全断是“挑人”断网1.1 现象描述与时间规律我在一家差不多三百人的企业里做网络运维平时绝大多数故障都能在半小时内定位。但这次碰到的问题老实说到现在我也没敢说彻底根治只是把影响面压到了可控范围。事情是这样的行政楼三层办公区大概五十多个有线终端从某一天开始陆陆续续有人反馈“网断了”“上不了内网”但奇怪的是隔壁工位的人完全正常。我一开始以为是某个交换机端口坏了结果过去一看断网的终端分布在不同的交换机端口上而且不是一起断是隔一阵子断一批每次持续几分钟到十几分钟自己又恢复。最典型的时段是上午十点左右和下午三点左右。这两个时间点正好是公司考勤打卡、邮件收发和业务系统访问的高峰期。刚开始我怀疑是带宽被占满但看了核心交换机的流量图峰值流量并不高连百分之四十都不到。更让人头疼的是重启网卡或者禁用再启用本地连接马上能恢复但过半小时可能又犯。这种“时好时坏”的故障最熬人因为你蹲在电脑前等半天它偏偏不犯了你一走它又开始掉链子。我花了整整三天做基础排查期间把能换的硬件都换了一遍问题依旧。后来我意识到这大概率不是某个设备坏了而是系统性的间歇性故障只是表现出来的方式是“部分终端”。后来跟同行交流发现这种案例在企业里其实不少见只是很少有人愿意把“没搞定”的过程写出来。我这次就把这个案例完整复盘一下既有排查思路也有我踩过的坑。1.2 受影响终端分布观察为了让问题可量化我先拉了一张受影响终端清单然后把它们的位置在楼层平面图上标了出来。这一标发现了第一个有价值的规律受影响的终端集中在三排工位分别接在三台接入交换机上但同一台交换机上也有大量正常终端。也就是说不是某一台交换机整体故障也不是某一根网线的问题因为我把故障终端和正常终端的网线互换过故障并不会跟着网线走而是继续留在原来的工位上。这个“挑工位”而不是“挑设备”的现象让我一度怀疑是工位的墙插面板或者地面信息盒有问题。我拆开过几个墙插面板重新打过水晶头和模块甚至把故障工位的网线直接换成一条临时明线绕过墙面布线接到交换机上。结果呢临时明线的情况下故障出现的概率明显降低但并没有完全消失。这说明墙内链路有隐患但不是唯一原因。后来我又观察了更长时间发现一个更隐蔽的规律同时断网的终端数量一般不超过七八台而且几乎都是同一网段内的IP。我们办公网是按楼层划分VLAN的三层办公区是一个独立的VLAN地址池大约两百个。断网终端拿到的IP地址段比较集中大概在同一个C段的后半段。这让我开始怀疑问题可能出在DHCP分配、ARP解析或者某个网关相关环节上。为了把“部分终端”这个特征吃透我做了下面这个对比表记录异常终端和正常终端在设备型号、接入方式、IP地址、所属交换机等维度上的差异对比项异常终端正常终端终端品牌联想、戴尔混合同样混合操作系统Windows 10/11 都有同样接入方式墙插面板转网线同样所属接入交换机三台不同型号同交换机也有正常IP地址段集中在地址池后半段前半段居多是否使用USB转网卡少数使用极少数网卡节能选项开启部分开启看完这张表我基本排除了终端品牌和操作系统版本的干扰。真正的差异点只剩下两个一个是IP地址段分布一个是物理链路经过的布线路径。这两个差异点成了后面所有排查的核心线索。2. 第一轮排查从网线到交换机基本排除单点硬件2.1 物理链路排查与替换测试做网络故障排查我习惯按OSI模型从下往上走因为物理层的问题往往最容易被忽略。第一轮排查我做了以下几件事用福禄克测试仪测了故障工位的墙插到配线架之间的链路包括长度、衰减、串扰结果基本达标。注意是“基本”有几根线在近端串扰的值偏高但没到不合格的程度。把故障终端的原网线换成六类成品跳线故障依旧。把故障工位的信息模块重新压接故障出现的频率有所下降但没根除。把接入交换机到配线架的跳线也换了甚至把故障终端换到另一台交换机上测试跨VLAN后问题依然存在。这种“什么都换了还是会犯”的情况让我意识到问题可能不在静态链路本身而是在动态交互环节。也就是说问题很可能不是“断开”的物理故障而是“干扰”或“协议层面”的故障。物理层虽然发现了轻微串扰但不足以导致几十台终端同时间歇性掉线。真正让我头疼的是这种间歇性故障没法用测试仪复现因为仪器一接上去链路就恢复正常了。2.2 交换机侧的异常迹象既然物理链路没有被完全排除但也不是唯一变量我开始把注意力放到接入交换机上。登录交换机后我先检查了所有与故障终端相连的端口发现几个共同特征端口CRC错误计数在故障发生前后会显著增加但平时为零。端口链路状态并没有变为Down一直是Up但接口下的“input errors”和“output errors”有零星增长。日志里出现了不少“Duplicate address”记录也就是IP地址冲突。交换机CPU利用率平时不到百分之五但故障时段会突然跳到百分之七八十持续几分钟后回落。当时我第一反应是有环路。因为环路会导致广播报文在二层无限转发交换机CPU飙升终端上网自然时断时续。但我检查了STP生成树协议状态所有端口都是正常的Forwarding或者Designated没有任何Blocking端口异常切换的痕迹。而且如果是环路通常不会只影响部分终端而是整台交换机甚至整个VLAN都会瘫痪。为了确认是不是广播风暴我在交换机上用镜像端口把上联口和几个故障端口的流量同时镜像出来用Wireshark抓包。抓了半小时正好碰到一次故障窗口没抓到广播风暴但抓到了大量的TCP重传和ARP请求风暴。奇怪的是这些ARP请求都是正常的询问“谁是192.168.x.1”并没有出现大量伪造MAC或者ARP洪泛的迹象。不过有一个细节引起了我的注意故障终端在断网前的几十秒内会频繁向外发送DHCP Discover报文然后放弃现有IP重新获取地址。这很不正常。一台正常工作的电脑获取到IP之后不会无缘无故去重新DHCP除非网卡认为自己的地址失效了或者收到了DHCP NAK。也就是说终端“主动”放弃了IP而不是网络没有响应。3. 第二轮排查抓包看到一堆重传但没抓到“凶手”3.1 端口镜像与持续抓包为了蹲到故障发生的完整过程我在接入交换机上配置了端口镜像把故障终端所在端口和上联口同时复制到监控口用笔记本跑Wireshark做了整整两天的持续抓包。这里要吐槽一下用普通笔记本跑长时间抓包文件会很大我建议用dumpcap按时间切分文件或者直接用支持滚动写入的工具否则后期分析会非常痛苦。我也是在这段时间把手机上的Tabby终端工具用了起来直接从笔记本SSH到交换机上看实时状态不用来回跑机房确实省了很多事。Tabby这种终端工具在排查网络问题时最大的价值不是好看而是可以同时保存多个SSH会话还能把日志直接记录到本地文件。后来做长时间观测全靠它把交换机的syslog和终端日志串在一起。第二天的中午总算抓到一次完整故障过程。时序大概是这样的故障前约30秒某台终端发出一个DHCP Discover。DHCP服务器正常回应Offer。终端发出Request但服务器没回ACK接着终端又发了一次Request。大约两秒后终端直接放弃原有IP把自己设成169.254.x.xWindows自动私有地址。整个VLAN里同时有四五台终端也发生类似行为。又过了大约20秒终端重新获取到IP网络恢复。也就是说这些终端是“自己把自己弄断的”核心问题在于DHCP交互的ACK阶段丢失了响应。但DHCP服务器是Windows Server日志里并没有显示这个时段的租约异常。我只能怀疑是中间某个环节把DHCP ACK报文悄悄丢弃了。3.2 从ARP和DHCP日志中发现的交集因为怀疑DHCP ACK被丢我开始查网络里有没有可能存在某种过滤机制比如交换机上的DHCP Snooping或者防火墙对UDP 67/68端口的策略。检查下来接入交换机并没有开启DHCP Snooping核心的防火墙策略也放行了DHCP流量。然后我又查了DHCP服务器上的地址冲突日志发现故障终端在掉线前都收到过DHCP NAK。触发NAK的原因是服务器认为该IP已经被其他设备占用。但问题来了这些IP不可能被占用因为我查过ARP表那些地址在故障时段并没有对应到其他MAC。唯一的解释是服务器端检测到了某种冲突信号或者服务器自身在某些时刻出现误判。这个阶段我做了很多假设也排除掉很多方向。为了梳理思路我整理了一张排查记录表记录每个阶段的疑点和验证结果排查方向验证方式结论网线/模块物理故障福禄克测试、换线、重做水晶头有轻微串扰但非唯一原因交换机端口故障更换端口、查看CRC统计端口有零星错包但动态变化二层环路检查STP状态、抓广播包未发现环路广播风暴端口镜像抓包未出现广播风暴DHCP交互问题抓包确认DHCP ACK丢失确认故障时DHCP ACK未到达终端IP地址冲突查询服务器日志、ARP表出现NAK但未找到真实冲突者电源/接地问题万用表测工位电源、地线电压发现部分工位零地电压偏高但规律不明显这张表做到这里我已经清楚问题的表象是DHCP异常但底层触发条件还没找到。老实说“部分终端”这个特征一度让我怀疑是某些工位的供电质量问题因为电源不良确实会导致网卡工作不稳定但几乎不可能在局域网里引发DHCP ACK的丢弃。为了验证电源干扰我拿万用表测了故障工位的零地电压发现确实比正常工位高一些但那段时间是否恰好与故障时段重合无法证明。3.3 从“隔着配线架的串扰”到“地址池后半段”的联想在我快要绕晕的时候一个偶然的对比让我有了新思路。我把故障终端和正常终端的IP对调强制固定临时在网卡里设置静态IP发现原本正常的终端如果设置成故障地址段IP也会开始断网而原本故障的终端设置成正常地址段的静态IP居然稳定了很多。这说明问题不仅和物理位置有关还和IP地址本身有强关联。这个发现让“地址池后半段”从统计数据变成了一个关键变量。为什么同一个VLAN里前半段IP稳定后半段IP就容易出问题我第一反应是IP地址管理表有问题比如某台设备占用了后半段地址或者核心交换机上的某个ACL访问控制列表误伤了后半段。我仔细查了核心交换机上的所有ACL、VLAN接口配置和DHCP中继配置把所有可能跟“后半段”相关的条目都过了一遍结果干干净净。后来我干脆把DHCP地址池范围改了一下让原本冲突的地址段避开故障率确实下来了但没有消失。也就是说IP地址段是“放大器”不是“根因”。到这里我已经隐约觉得问题可能不是传统网络设备的故障而是某种和环境、终端底层状态相关的偶发因素。但当时手上没有足够证据只能继续往下挖。4. 怀疑从“网络设备”转向“终端自身特性”4.1 为什么“部分终端”这个特征是最大线索回头看整个排查过程最容易误导人的其实就是“部分终端”。我一开始把它理解成“个别设备有问题”所以反复换终端、换端口做了一堆无用功。后来意识到“部分”可能只是一个结果真正的原因是这些终端在某个属性上存在交集。什么交集呢通过对比我发现所有频繁掉线的终端网卡驱动版本都比较旧并且在设备管理器里都开启了“允许计算机关闭此设备以节约电源”的选项。这个选项默认在笔记本上是开启的但在台式机上很多人不会去动它。问题就出在这里当网卡进入节能状态后系统为了省电会暂时断开链路。正常来说断开后网卡会立刻唤醒并重新协商但如果网卡和交换机之间的EEE节能以太网协议配合不好重新协商就可能失败。我把这些机器的电源管理选项全部关掉禁用网卡的“环保节能”和“EEE”功能同时把网卡驱动更新到官网最新版。操作完之后掉线频率确实下降了一大截。但这还不能解释DHCP ACK丢失的问题。后来我推测可能是网卡在节能唤醒过程中驱动栈的TCP/IP协议栈出现短暂“卡死”导致DHCP ACK到达时没有被上层正确接收所以表现为“服务器没回包”。这种问题单纯看交换机和服务器日志是看不出来的。4.2 节能以太网与网卡驱动的坑在这里我想多说一句很多网管一看到“部分终端间歇性断网”第一反应就是杀毒软件冲突、IP冲突、ARP攻击很少会去检查网卡的电源管理策略。但实际项目中因为Windows默认开启网卡节能导致的问题真的不少。尤其是当交换机开启EEE802.3az后如果网卡驱动实现有bug低功耗模式唤醒时会出现几秒到几十秒的“假死”表现就是断网、掉IP、要重启网卡才能恢复。我后来把接入交换机上的EEE功能也全局关掉了用命令把绿色以太网特性停用然后让故障终端持续运行。结果很直观掉线次数从每天五六次降到了一天最多一两次。但注意还是有偶发。这说明节能以太网只是把问题放大底层的诱因还没完全消失。还有一个细节就是USB转网卡。我们公司有几台终端用的是USB 3.0转RJ45网卡这几台掉线频率明显高于内置网卡的机器。USB网卡本身对电源波动敏感如果工位USB口供电不稳或者主机处于睡眠唤醒状态USB网卡重连的等待时间很长。这类设备我最后直接建议用户更换成内置PCIe网卡问题基本解决。4.3 无法复现验证的尴尬排查到这一步我已经有一个比较完整的假说环境因素电源/静电触发网卡底层异常网卡节能和EEE又放大了异常最终在DHCP协议层面表现为掉线。但问题在于我没有办法让故障按需复现。它一天只出现几次每次只有几分钟而且很多时候我人在现场它又安静得像无事发生。为了验证我在终端上设置了计划任务每30秒记录一次网络连通性和IP地址持续一周。结果发现掉线前的最后一条日志网络还是通的然后下一跳就直接变成了169.254.x.x中间没有丢包过程。这说明不是先“断”再“重连”而是网卡直接判定自己的IP无效主动释放并重新获取。这更符合“网卡驱动异常”而不是“物理链路中断”的特征。如果非要彻底验证可能需要换上不同型号的网卡或整机来对照测试但这在真实办公环境中很难做到。一是办公电脑不能随便拆二是用户不能中断工作。所以直到今天我也不敢说找到了根因只能说把概率降到了很低。5. 没搞定的复盘卡在了哪儿5.1 最大障碍问题复现周期太长、窗口太短这个case里最影响排查效率的不是技术难度而是故障窗口太短。它不会像网络环路那样持续报警也不会像某个设备宕机一样症状固定而是飘忽不定有时候一天都没事有时候半天出现三次。这种间歇性故障靠人工在场“蹲”效率极低必须靠自动化手段长时间采样。当时我们网络监控系统只盯着设备存活和端口流量没有针对终端ARP表、DHCP日志、客户端IP变化做关联分析导致大量关键证据在故障发生时没有被留存下来。比如我后来想查“故障发生时有多少个DHCP Discover”因为没有集中日志只能靠抓包文件一个一个翻效率极低。这也是为什么我一直强调间歇性故障排查的前提是提前把日志和流量留好否则故障发生时你只能干瞪眼。5.2 应急缓解措施与实际效果虽然没有做到根治但最终我们通过组合措施把故障从“影响办公”压到了“偶发一两次”的程度。具体做了这几件事全局关闭交换机上的EEE节能以太网功能。通过组策略批量推送关闭Windows网卡的“允许计算机关闭此设备以节约电源”选项。更新所有受影响终端的有线网卡驱动统一为厂商最新版。禁用网卡驱动里的“环保节能”和“减震”相关选项不同厂商叫法不同。调整DHCP地址池避开之前冲突频发的IP段。使用USB转网卡的终端统一换成内置PCIe网卡。这些操作做完之后连续观察了两周故障终端数量从每天数十次下降到每周一两起且再也没有出现多台终端同时掉线的情况。但说实话这个结果并不让我满意因为我知道底层诱因还在只是被抑制住了。如果那天某个条件发生变化比如工位上多了大功率电器或者交换机固件更新改变了EEE行为问题可能还会回来。5.3 如果重新来我会这样布置监控经过这次折腾我给自己定了一条规矩遇到“部分终端间歇性故障”不要先问“哪里坏了”而是先问“我能不能把故障发生前后的数据完整记录下来”。为此我把下面这套监控部署方案整理了出来供同行参考监控项工具/手段目的终端IP变化历史组策略记录dhcplease事件转发至syslog还原掉线前的IP获取过程接入交换机端口统计SNMP周期采集CRC/errors/ discards发现物理层隐性错误ARP表快照核心交换机定时备份ARP表排查IP冲突和ARP异常DHCP服务器日志集中日志平台接入确认是否下发ACK/NAK关键终端连通性探针Python脚本每30秒ping记录时序捕捉断网精确时间点镜像口持续抓包dumpcap按时间切分保留最近7天需要时回溯故障窗口这些并不需要多高级的设备核心就是“长时间、可回溯”。如果能提前部署好再把交换机syslog和DHCP服务器日志关联起来这种间歇性故障的定位时间可以压缩到小时级而不是像我这次一样前后折腾了一周多。最后再说一个小经验遇到“没搞定”的网络问题一定不要瞒着用户硬扛。我后来直接告诉业务部门这个故障根因还在查但我们已经采取了缓解措施让他们遇到情况及时反馈。这样反而获得了理解也收集到了更多有效样本。网络运维这种事不怕问题奇怪就怕你手里的数据不够拍脑袋下结论才是最大的坑。
