公司内网“又”断了。
领导在工作群里连发三条消息，语气从“麻烦看一下”变成了“到底怎么回事”。你背着螺丝刀和笔记本冲进弱电间，熟练地把核心交换机重启了一遍。五分钟后，网络恢复了，你长舒一口气。但你知道，这已经是这个月第六次“重启治百病”了。明天或者后天，同样的断线、同样的延迟跳变，大概率还会再来一遍。
如果你也身处这种循环，这篇内容就是给你写的。作为一个在运维圈子里摸爬滚打多年的老手，我可以直说：公司内网频繁断线、延迟忽高忽低，绝大多数时候并不是交换机“脑子有病”，而是底层某个环节正在劣化或者已经被破坏了。重启交换机，等于把火灾报警器按掉，而不是去把火灭了。
真正靠谱的做法，是把问题按物理层、链路层、网络层、应用层逐层剥开，找到根因，一次性解决。这篇文章我会先把最常见的5大底层故障讲透，再给出一套可以直接照着做的分层排查流程，最后附上几个真实案例复盘。内容偏实战，适合网络运维、桌面运维和兼职管网络的同学们直接“抄作业”。
1. 先别急着重启：公司内网“断流”背后的真实逻辑
1.1 为什么“重启交换机”治标不治本
很多运维同行遇到网络故障，第一反应就是重启。这个习惯从一个侧面说明：重启确实有效，尤其是在交换机的表项状态发生异常的时候。交换机长期运行，MAC地址表、ARP表、STP状态、端口缓存这些内部数据会不断累积，一旦某个表项错乱或者缓存池被打满，转发行为就会变得诡异。这时候重启，等于让所有状态“清零重来”，表面上看问题确实消失了。
但问题在于：如果故障的根源是光纤老化、双工不匹配、环路未消除这类底层问题，重启只是把症状暂时压下去。过几个小时或者过一两天，同样的数据积累到临界点，故障又会重新冒头。我见过一家公司，核心交换机每周五下午必断一次，运维每周五都去重启，坚持了一个多月，最后发现是机柜空调坏了、交换机长期高温运行导致芯片时序不稳定。重启一百次，都不如把空调修好。
所以，处理内网故障的第一原则不是“怎么恢复”，而是“为什么会坏”。先收集日志和现象，再动手处置，这才是稳定的运维习惯。下面这篇文章讲的所有内容，都是围绕“先诊断、后恢复”这个逻辑展开的。
1.2 一个看似“交换机故障”的真实案例：双工协商的陷阱
有一次，某公司设计部十几个人集中反馈“网很慢，传大文件经常失败”。桌面运维去看了，电脑网卡显示连接正常，IP也能获取到，ping网关小包不丢，但一传文件就掉线。重启用户交换机后，好了一个上午，下午又犯。
当时谁都没往双工模式上想，都觉得可能是某台电脑的网卡出了问题。后来我用串口线登录到接入交换机，查看那台交换机的端口统计，发现连接设计部的几个端口上CRC错误计数高得吓人，而且一直在涨。再检查端口协商状态，发现交换机端是1000M全双工，而用户电脑的USB转网卡只有100M半双工。
问题一下就清楚了：一端在全双工跑，另一端在老旧半双工模式下工作，数据传输时频繁发生冲突，交换机只能不断重传，表现出来就是“延迟忽高忽低、传大文件必断”。处理方式并不复杂，把用户端的USB网卡驱动更新，强制设置成100M全双工和交换机保持一致，问题彻底消失。
这个案例说明，内网故障往往不是“交换机坏了”，而是两端设备协商不一致。这种问题，重启交换机永远无法根治。
2. 5大底层故障，运维必须烂熟于心
2.1 底层故障一：物理介质劣化，数据在“线”上跑不动
物理层是所有网络通信的基石，恰恰也是很多运维最忽视的一层。公司内网的物理介质主要包括双绞线、光纤、水晶头、信息模块、光模块等。这些东西在弱电井和天花板上常年不动，一旦劣化，表现往往很有迷惑性。
常见场景包括：六类线被当成超五类线压接、水晶头接触不良、光纤熔接点积灰、光模块长期高温老化、线缆弯曲半径过小导致光信号衰减过大。某些情况下，劣质网线在短距离内能通，但传输质量和抗干扰能力极差。尤其是办公区改造时留下的“飞线”，被桌椅压、被脚踩、被老鼠啃，都会造成链路不稳定。
症状上，物理层劣化通常表现为：ping网关延迟时好时坏、特定时间段丢包率升高、端口频繁UP/DOWN、交换机端口计数里CRC错误和FCS错误持续增长。注意，这种问题重启交换机完全没有作用，因为问题根本不在交换机内部。
排查方向上，优先检查网线两端水晶头是否松动、氧化，使用网络测试仪验证线序和通断，然后用光功率计测试光纤链路的光衰减值是否在合理范围。对于光模块，可以直接登录交换机查看光模块的电压、温度和接收光功率。如果接收光功率接近甚至低于灵敏度阈值，就需要清洁光纤接头或者更换模块。
2.2 底层故障二：双工与速率不匹配，端口在“半推半就”
双工模式不匹配是内网延迟波动的经典隐形杀手。现代交换机默认开启自动协商，大多数终端设备也默认自动协商。理论上来讲，两者应该能自动协商到一致状态。但现实中，总有一些特殊情况会破坏这个平衡：老旧打印机网卡、USB转网卡、虚拟机网卡、某些工业设备，它们的自动协商实现并不标准，或者干脆被某位同事手动固定成了半双工。
两端速率和双工不一致时，工作在半双工的一端会频繁检测到冲突，它的处理机制是退避重发，导致数据包上行延迟骤增。而全双工一端并不参与冲突检测，它只会发现对端响应极慢、大量包超时重传。最终表现就是：连接建立没问题、小包ping正常、一旦有持续大流量就延迟飙升甚至掉包。
排查这种问题，不需要抓包分析，直接查看交换机接口状态就能发现端倪。如果端口显示“A Full, 1000”而终端实际只有“100 Half”，基本可以确定是双工协商不一致。处理上，先把终端网卡驱动和固件升级，然后尽量让两端都回到自动协商模式；如果设备太老不支持，就在两端手动设置相同的速率和双工。
这里有个容易被忽略的细节：强制设置双工模式时，一定记得把速率也固定下来。只固定双工、不固定速率，有些设备还会在速率协商上出幺蛾子。
2.3 底层故障三：广播风暴与二层环路，让交换机“原地空转”
二层环路引起的广播风暴，是让整片网络瞬间瘫痪的最常见原因。典型触发场景是：某位同事在工位上私自接了一台小交换机，又把两根网线同时插到墙上面板，形成了物理环路。一旦有广播帧进入环路，交换机之间就会无限转发，广播报文像滚雪球一样暴涨。
很多人以为环路只会在核心网络存在，其实办公区里用户私接的小交换机才是最危险的环路源。广播风暴出现时，最明显的特征是：全网或者某个VLAN内的所有终端上网奇慢，ping网关延迟从1ms直接跳到几百甚至上千ms，交换机的CPU使用率飙升，端口流量统计里广播包占比超过50%。
处理环路的第一件事不是找根源，而是先“止损”。如果知道环路大概率在某个汇聚区域，可以先把那台接入交换机的上联口shutdown，或者直接拔掉上联网线，让广播风暴停止扩散。然后在接入交换机上登录，逐个查看端口流量，找到广播流量异常暴涨的端口，顺着网线找到源头设备。
从长效解决方案来说，必须在所有交换机上开启并正确配置STP/RSTP。核心思路是：启用STP后，即使有人私接形成环路，交换机会自动阻塞冗余端口，从机制上消除广播风暴的可能。另外就是把接入交换机上连接办公区终端的端口配置成边缘端口，并启用BPDU保护，防止用户私接交换机把环路风险引入核心。
2.4 底层故障四：MAC地址表异常与ARP欺骗
MAC地址表是二层交换机的转发依据，端口漂移则是它的典型异常状态。当同一台设备的MAC地址频繁在交换机的不同端口上出现，交换机的MAC地址表就会不断刷新，造成帧转发方向混乱，数据包被送错端口，协议协商反复中断，网络表现就是“时通时不通”。
导致端口漂移的原因主要有两类：一是物理环路，二层环路导致交换机从一个端口收到源MAC相同的帧、又从另一个端口收到同一MAC的帧；二是用户私接无线路由器或者扩展器，设备在多个接入点之间来回切换，MAC地址跟着在多个端口间跳变。
ARP欺骗则发生在三层。攻击者伪造网关的MAC地址，向网段内广播虚假ARP响应，导致终端设备的ARP缓存被改写。终端把发往网关的流量全部转发到攻击者那里，轻则上网卡顿、延迟剧增，重则数据被截获、内网完全瘫痪。
排查这类问题时，登录交换机查看MAC地址表的动态变化是第一步。重点关注同一个MAC是否出现在多个端口，或者频繁在不同端口间横跳。对于ARP问题，可以在终端上通过arp -a查看网关IP对应的MAC地址是否和真实网关一致，如果不一致，基本就是ARP欺骗。处置上，先断掉异常终端，再在交换机端口上做MAC地址绑定或者开启DHCP Snooping、DAI等防护特性。
2.5 底层故障五：交换机的“暗病”——电源、温度、固件
很多运维只关注交换机的转发性能和配置，忽略了它作为一台电子设备本身的“身体健康”。交换机运行在机房或弱电间里，这些环境往往散热不佳，夏天温度轻松超过40度。长期高温运行会导致交换芯片时序不稳定、光模块光功率漂移、端口误码率上升。
温度问题的隐蔽之处在于，它不是瞬间崩溃，而是性能逐步劣化。比如交换机工作温度升高后，丢包率从0.01%慢慢升到1%，用户感知就是“网络越来越卡”。等到某个临界点，芯片过热保护启动，端口才会批量宕掉。这时候重启交换机，温度短暂降下来，一切恢复正常；等到温度再次升高，问题重新出现。这不就是“断线——重启——恢复——再断线”的死循环吗？
除了温度，电源和固件也是大坑。电源老化后纹波增大，会造成交换机不定期重启、端口瞬间断开，时间点完全随机。固件方面，一些老版本存在内存泄漏问题，运行一段时间后内存耗尽，转发性能骤降。最典型的表现是交换机的CPU使用率缓慢爬升，到80%以上后开始频繁丢包。
排查这些暗病，需要运维养成看系统日志和性能指标的习惯。定期登录交换机执行show logging、show environment、show process cpu命令，观察温度、电压、风扇转速、CPU利用率和日志告警。建议在核心和汇聚交换机上配置SNMP，接入Prometheus或者Zabbix这类监控系统，设置温度和CPU利用率的告警阈值。等故障出现再查温度，往往已经晚了。
3. 分层排查教程：从底层往上，一套能直接抄的操作流程
下面这套流程，是我处理内网故障时固定走的路子。整个流程的核心思路是“从物理到逻辑、从接入到核心、从交换到终端”，一步不漏地缩小问题范围。以某公司办公区为例，故障描述为：工作日10点到15点之间，30台电脑频繁掉线，ping网关延迟从1ms波动到200ms，重启接入交换机后恢复1小时左右再复发。
3.1 第1步：记录现象，圈定边界
动手之前，先在5分钟内回答下面几个问题：
- 故障范围是全网还是某个区域？如果是某个VLAN或某台接入交换机下的终端，问题大概率集中在二层和物理链路。
- 故障时间是否有规律？固定出现在每天某个时段，多半和温度、设备负载或者定时任务有关。
- 是丢包还是延迟高？延迟稳定升高，可能和带宽拥塞、双工不匹配有关；随机丢包，大概率是物理链路或者环路问题。
- 有线上网有问题，还是Wi-Fi也有问题？如果只有有线出问题，排查重心应该放在接入交换机上；无线也有问题，则可能涉及网关和上游链路。
这些信息决定了你的排查起点。没有这些边界信息，就贸然在核心交换机上翻配置，效率很低，还容易误操作影响生产。
3.2 第2步：物理层排除
物理层检查是整个流程里成本最低、收益最高的一步，千万不要跳过去。
先用网线测试仪测一下问题区域几条核心链路的网线线序是否正常，看水晶头有没有松动。如果涉及光纤链路，用光功率计测试收发光功率。对交换机上的光纤模块，登录交换机查看模块温度、电压和接收光功率。
同时重点检查交换机的端口错误计数。登录接入交换机，进入问题端口所在的接口视图，查看CRC、FCS、Runt等错误计数是否持续增长。如果某个端口错误计数快速增长，基本可以确定这根链路存在物理层问题。接下来可以尝试用一根确认完好的网线替换测试，看看故障是否消失。
物理层问题的特点是：只要链路质量还在阈值之上，网络就能正常工作；一旦接近或者低于阈值，丢包和延迟问题就会随机出现。所以即使仪器没测出问题，但只要端口错误计数异常，也要把网线或者模块换掉验证。更换的成本很低，不要犹豫。
3.3 第3步：链路层核查
物理层排除了，接下来把目光放到交换机的二层转发状态上。
先在接入交换机上执行命令查看MAC地址表。重点看有没有MAC地址频繁在不同端口之间漂移。如果有，优先怀疑环路或者用户私接设备。顺着异常端口的网线找过去，大概率能找到一台私接的小交换机或者无线路由器。
接着检查STP状态。执行命令查看所有端口的STP角色和状态，确认根桥是哪台设备、有没有端口长期处于Learning或者Blocking状态。如果发现端口频繁在Forwarding和Blocking之间切换，这就是拓扑不稳定，通常意味着物理环路存在或者STP配置错误。
最后，查看端口广播包流量。登录交换机查看端口流量统计，如果某个端口广播包速率异常高，甚至占到总流量的30%以上，说明这个端口下面存在广播风暴的苗头。这时候可以先把这个端口shutdown，观察整个网络是否恢复，如果恢复，就慢慢细化到具体主机。
3.4 第4步：网络层与应用层联合验证
链路层没有明显异常，下一步就是确认三层转发和终端侧情况。
在终端上先ping网关，观察延迟和丢包。如果ping网关正常但访问服务器慢，再用tracert/pathping分段定位，看到底是哪一跳开始延迟变大。如果每一跳都正常但业务还是卡，问题就可能在应用层，比如DNS解析慢、服务器网卡软中断过高、数据库连接池打满等。
同时检查是否发生IP地址冲突。内网频繁断线一个容易被忽略的原因是有人手动配置了静态IP，和DHCP地址池里的机器冲突。冲突时，一台能上网，另一台就会频繁掉线，重启也没用，因为对方在线。排查方法是登录接入交换机查ARP表，看同一个IP是否对应多个不同的MAC地址。
应用层的验证可以借助抓包工具。在问题终端上抓一段时间的包，观察是否有大量TCP重传、重复ACK、零窗口通知。TCP重传率高，通常意味着物理链路质量差或者中间设备处理不过来；大量零窗口，则说明接收端应用程序处理能力不足，跟网络本身关系不大。
3.5 排查命令速查手册（复制即用）
为了方便各位直接上手，我把排查过程中最常用的命令整理成了表格。以Cisco和华为两个主流品牌为例，命令差异不大，对照着敲就行。
| 排查目标 | Cisco命令 | 华为命令 |
|---|---|---|
| 查看端口状态和协商模式 | show interfaces status | display interface brief |
| 查看端口错误计数 | show interfaces counters errors | display interface counters error |
| 查看MAC地址表 | show mac address-table | display mac-address |
| 查看STP状态 | show spanning-tree | display stp brief |
| 查看端口流量统计 | show interfaces counters | display interface counters |
| 查看CPU利用率 | show process cpu | display cpu-usage |
| 查看温度和电源状态 | show environment | display environment |
| 查看系统日志 | show logging | display logbuffer |
| 查看ARP表 | show arp | display arp |
这些命令的组合使用，能覆盖绝大多数二层和三层故障的排查需求。别忘了，执行命令时一定要看清楚设备名称和端口编号，确认自己连的是哪台设备，避免在核心交换机上误操作造成业务中断。
4. 现场实战：两个高频故障的完整复盘
4.1 案例一：光纤链路光功率劣化导致间歇性断线
某分公司反映，与总部之间的专线每隔两三天就会断一次，每次持续十几分钟又自动恢复，重启两端路由器无效。总部监控平台显示专线接口的流量在断线前会先出现小幅丢包，然后接口彻底Down掉。
排查时登录分公司的出口路由器，查看光模块状态，发现接收光功率在-19dBm左右，已经非常接近模块的灵敏度阈值-20dBm。光模块虽然还能工作，但光功率余量太小，只要光纤轻微弯折，接收光功率就会瞬间掉到阈值以下，导致链路闪断。
处理过程：先清洁光纤两端接头，重新插拔后，光功率恢复到-13dBm；随后检查整个光纤走线，发现机柜顶部的光纤被一扎线缆压住，弯曲半径过小。把光纤重新布放，让弯曲半径符合要求。处理后一个月内，专线再没出现过断线。这个案例告诉我们，链路闪断时不要急着怀疑路由器配置，先看看光模块的光功率读数。
4.2 案例二：办公区私接小交换机引发全网广播风暴
某天上午10点半，公司内网整体卡顿，ping网关延迟从正常1ms飙升到500ms，所有业务系统加载缓慢。登录核心交换机，发现CPU利用率高达95%，端口流量统计里广播包速率异常高。
我先在核心交换机上把几个区域的汇聚接口逐个shutdown，当关闭三层会议室那台接入交换机的上联口时，网络瞬间恢复。初步确认问题在三层会议室的下联网络中。
登录那台接入交换机，逐端口查看广播流量，找到广播包速率极高的一个端口，顺着网线查过去，发现会议室角落一台小交换机上同时插了两根网线，分别接到了墙上的两个信息面板，形成了二层环路。拔掉其中一根网线后，整片网络彻底恢复。事后检查发现，这台小交换机的STP默认关闭，因而无法自动阻塞冗余端口。最后的整改措施是：全网开启RSTP，接入端口启用BPDU保护，同时把未使用的墙面信息面板全部在交换机侧shutdown。
4.3 从失败中总结的几条“保命”经验
上面的案例处理起来还算顺利，但我也踩过不少坑。第一次遇到广播风暴时，我花了大半个小时在核心交换机上翻配置，完全没意识到问题可能出在办公区某个角落的小交换机上，白白延长了业务中断时间。后来我给自己定了一条规矩：遇到大范围掉线，先看端口流量和CPU，再有针对性地去查环路和广播包，不要一上来就怀疑配置错误。
还有一次处理光模块问题，我忽略了光纤接头清洁这个步骤，直接换了新的光模块，结果问题依旧。后来才发现是光纤端面被灰尘污染，清洁之后光功率就恢复正常了。从那以后，我再也不先换模块，而是先清洁再测试。
5. 常见问题速查表与避坑指南
5.1 常见问题速查表
排查现场时间紧，有一个速查表能省不少力气。我根据自己的经验整理了几个高频问题的现象与思路，照着排查比临场发挥靠谱得多。
| 现象 | 可能原因 | 优先检查项 |
|---|---|---|
| 固定时间断线，重启后恢复 | 设备温度过高、定时任务 | 环境温度、设备日志、CPU利用率 |
| 延迟高但ping小包不丢 | 双工协商不一致、带宽拥塞 | 端口协商模式、端口流量趋势 |
| 大范围掉线、全网卡顿 | 二层环路、广播风暴 | 广播包速率、STP状态、CPU利用率 |
| 某台电脑频繁掉线 | 双工协商不一致、IP冲突 | 端口错误计数、交换机ARP表 |
| 传大文件失败，小包正常 | MTU不一致、物理链路质量差 | ping -f大包测试、端口错误计数 |
| 随机丢包，时好时坏 | 光纤衰减过大、网线老化 | 光模块光功率、端口CRC错误 |
| 中招后只有特定区域故障 | 接入层设备故障、私接设备 | 线路走向、接入交换机端口状态 |
5.2 一定要绕开的“经验陷阱”
排查内网故障，最怕先入为主。第一个陷阱是“上次是这个故障，这次肯定也是”，网络环境每天都在变，新设备、新布线、私接的小路由器都会改变故障模型，每次都要当成新问题来查。
第二个陷阱是过度依赖重启。重启是恢复手段，不是诊断手段。每次都重启，就等于每次都把故障日志和现场状态清空了，排查难度翻倍。遇到问题，先保存日志再重启，这是专业运维最后的底线。
第三个陷阱是只修终端、不看链路。不少桌面运维同事习惯先换电脑网卡、重装驱动，来回折腾几个小时，结果问题其实出在墙壁里的网线上。终端表现再怎么换系统也没用，链路线路本身才是根因。排查顺序一定要从物理层开始，逐层往上，这是效率最高的路径。
第四个陷阱是忽视监控建设。没有监控，每次故障都是“盲人摸象”；有了监控，端口流量、光模块功率、CPU温度这些指标一目了然。就算现在公司规模小，也建议至少部署一套开源监控系统，把核心交换机和服务器都纳进来。一次部署的投入，远比连续加班排查故障的成本低。
干了这么久运维，我最大的体会是：内网故障并不可怕，可怕的是用“先重启、再换个设备试试”这种原始方法反复折腾。网络是一个层层嵌套的系统，物理层、链路层、网络层、应用层，每一层都有自己的症状，也有自己的排查工具。花点时间把这套分层排查的思路练熟，遇到任何“频繁断线、延迟忽高忽低”的问题，你都可以不再慌张，而是像医生问诊那样，按照症状、体征、检查、诊断的流程一步步找到真正的病灶。希望在下次网络出问题的时候，你能用这套方法，一口咬住问题的七寸，而不是又一次熟练地重启交换机。
工程补充：私接设备与 ARP 欺骗的工程防护口径
- 私接两类危害：私接小交换机最容易造成环路广播风暴（整网时通时断、端口指示灯狂闪）；私接小路由器会开二级 DHCP，让部分终端拿到错误网关，表现为”能连上、上不去网”。
- 广播风暴防护：接入交换机开启 STP/RSTP 并对用户口启用 BPDU 保护；客房与办公用户端口做端口隔离，限制终端间二层互访，把私接环的影响关在接入端口。
- ARP 防护组合：DHCP Snooping 建立绑定表，联动动态 ARP 检测（DAI），伪造网关 MAC 的报文直接被丢弃；服务器、打印机等固定终端补静态绑定。
- 地址枯竭旁证：终端显示 169.254.x.x 说明 DHCP 没拿到地址——先查地址池使用率与租期（手机密集场景把默认 8 天租期改 1~4 小时），再查私接 DHCP 冲突与 relay 配置。
- 未用端口治理：闲置端口统一进黑洞 VLAN 并 shutdown，配线间理线后贴端口对照表，私接行为才可追溯、可定位。
收口：频繁掉线的排查先分清”广播风暴型”（全网卡、CPU 高）与”ARP 欺骗型”（个别网段掉线、网关 MAC 跳变）；酒店客网以 VLAN 隔离加 Snooping/DAI 组合为主，治理生效后再逐段放行，不要边防护边保留私接。
相关阅读
本文为转载作品。版权归原作者所有；本站仅作技术学习与方案参考，如涉侵权请联系我们删除。
评论 0
还没有评论，来抢沙发吧。