网络故障处理案例分析

早上九点零七分，网络运维群炸了。故障财务部打来电话说报销系统打不开，处理紧接着销售部说CRM卡成白屏，案例最后连公司内部的分析考勤打卡都开始转圈。我端着还没喝完的网络咖啡冲进机房，心里清楚——这绝不是故障单个应用的问题。

先看核心交换机，处理CPU占用率才12%，案例流量图平滑得像条直线。分析再查防火墙会话数，网络数值跳到平时的故障三倍还不止。奇怪的处理是，这些连接大多指向同一个IP段——公司新上的案例视频会议服务器。谁会在上班时间开这么多视频？分析我随手抓了台办公电脑抓包，结果吓了一跳：数据包里全是TCP重传，源地址和目标地址居然指向同一个网卡。

问题出在广播风暴上。新部署的视频会议系统默认开启了VLAN Trunking，但交换机端口配置没跟上，导致BPDU报文在二层网络里死循环。更糟的是，这台服务器接在财务部那台老旧交换机上，那台设备撑不住这种流量，直接进入CPU过载状态，开始丢弃所有非关键帧。

解决过程不复杂，但得手快。先把视频会议服务器的网口强制改成access模式，剥离trunk标签，广播包立刻少了一半。再登录那台老交换机，清掉所有动态MAC地址表，风暴源头算是掐断了。整个过程花了四十分钟，期间财务部大姐每隔五分钟就过来问一次“好了没”，我只能盯着屏幕上的ping值从2000ms慢慢降回1ms。

事后复盘，根因其实是个低级配置失误——安装视频会议系统的外包商根本不懂网络，他们只是按说明书把服务器接上，默认配置里的trunk模式在办公网里就是个定时炸弹。但更深层的问题是，公司没有网络变更审批流程，任何设备都能随便接入生产网段。

这事让我想起上个月那起更隐蔽的故障。某天下午邮件系统间歇性抽风，查了两小时才发现是有人偷偷在会议室装了台无线路由器，DHCP地址池和公司核心网段冲突。你永远猜不到办公室里藏了多少“野生”网络设备。

处理完这次事故，我在机房贴了张纸：任何网络设备接入前必须登记IP和端口。但说实话，制度只能防住守规矩的人。真正管用的，是给自己留好应急通道——比如那台老交换机虽然性能差，但它的console口永远连着笔记本，关键时刻能直接登录进去敲命令。这习惯救了我三次了。

网络故障处理最怕的不是技术难，而是找不到源头。广播风暴、IP冲突、环路，这些名词听着专业，本质都是网络里的“噪音”太多。你得像老中医把脉一样，先看整体流量有没有异常脉搏，再顺着线索一步步摸到病灶。急不得，但也不能慢——因为全公司几百号人都在等着你按下那个“恢复”键。