断网不可怕可怕的是它自己会好。这句话我在这些年做网络运维的过程中反复验证过——凡是断了又自己恢复用户说卡了几秒钟你去的时候一切正常这类报障排查难度往往是持续故障的三五倍。你到现场时设备灯全绿ping 畅通接口计数看着也很干净用户还会用一种是不是我记错了的眼神看着你。可回去之后第二天电话又来了说同一时间又断了一次。这篇文章要聊的就是这样一个典型的周期性断网案例一台 H3C 交换机每隔二十分钟左右断一次持续几秒钟后自动恢复用户侧感受是网页转圈、视频卡顿、远程桌面掉线重连。我会把这个案例从最初的报障、信息收集、命令抓取、线索排除一直到最终定位和处置整个链条完整摊开讲一遍。文中涉及的排查思路适用于大部分基于 H3C也部分适用于其他厂商的接入层、汇聚层交换机场景无论你是刚接手园区网的运维新人还是带过几年项目想复盘方法论的老手应该都能从里面挑出能直接抄作业的部分。需要先说明一点这类周期性自愈的故障根因分布其实很广——光模块劣化、网线接触不良、环路引发的生成树震荡、双上行聚合配置不一致、ARP 冲突、DHCP 地址池耗尽、甚至机房里空调启停导致的温度波动都可能造成类似现象。所以本文重点不只是给结论更是把怎么一步步把范围收窄的推理过程讲清楚这样下次你遇到的根因虽然可能和我这个不一样排查路径也能复用。1. 周期性断网又自己好了为什么这类故障最难查1.1 自动恢复把案发现场擦干净了做网络排查的人最怕的不是设备彻底挂掉而是它挂一下又活过来。彻底挂掉的设备你随便敲几条命令都能看到红灯、告警、日志证据就摆在那儿。而自愈型故障最大的麻烦在于它把现场证据擦得干干净净——等你走到机柜前故障窗口早就过去了接口是 up 的CPU 是正常的日志要么被后来的正常日志冲掉了要么根本没开日志落盘。我在这个案例里遇到的第一个障碍就是这个。用户上午十点报的障我十点半到现场一看设备运行时间、端口状态、CPU 占用全部正常。这时候如果你直接打开display interface看一眼没有错包就下结论说没问题、可能是用户网络问题那基本等于把问题往后推过两天它还会再来。所以应对这类故障第一原则不是急于找答案而是先想办法把证据留下来。具体做法包括把日志缓冲区调大、把关键日志发到日志服务器、把端口计数清零后放着等它复发、甚至直接在汇聚层或核心层开个长 ping 观察丢包时间点。这些都是先兜网再抓鱼的动作看起来慢实际是唯一能走通的路。1.2 先把断网拆成三种完全不同的故障用户嘴里的断网是一个极其含糊的词。拆开来看至少对应三种截然不同的现象而它们对应的排查方向完全不一样。第一种是链路真的 down 了。接口物理状态从 up 变成 down再变回 up这段时间该端口下挂的所有终端都上不了网。这种故障在display logbuffer里会留下Physical state on the interface xxx changed to down这样的记录定性最直接。第二种是链路没 down但流量丢了。接口物理层一直是 up但链路质量劣化出现误码导致部分报文被丢弃。用户感觉到的是卡顿、丢包、某些页面打不开而 ping 大包或者 TCP 重传会有明显异常。这种故障最阴险因为接口状态一切正常只能靠 CRC 错误计数这类指标来抓。第三种是整网短暂泛洪。某个地方发生了拓扑变更TCTopology Change生成树协议通知全网的交换机刷新 MAC 地址表导致大量未知单播在 VLAN 内泛洪。这时候不只是出事的那栋楼其他楼层的用户也会感到网络卡了一下。用户往往会描述成整个楼层都断了几秒但实际上是全网范围的一次短促抖动。我在案例前期做的最重要的一件事就是反复问用户一个问题你确定只是你们这层断还是隔壁楼层也在同一时间卡这个问题的答案直接把排查范围从一个接入交换机扩大到了整个生成树域。后来证明正是这个泛洪特征帮我们把嫌疑锁定到了生成树相关的事件上。1.3 上机之前要先把三个基线立起来进入机房之前我习惯先给自己立三个基线避免被现场现象带偏。第一个基线是时间基线故障发生的精确时间点。用户说上午大概十点断的没用你得问出10:07 左右断的大概持续了五六秒这种精度。理想情况下最好让用户在故障发生时立刻用手机记一个时间或者用一条常驻的 ping 记录丢包时间戳。有了精确时间你才能在日志里用时间窗口去筛否则几千条日志翻起来纯属大海捞针。第二个基线是范围基线故障影响到了哪些设备、哪些楼层、哪些业务。是单个终端、单个交换机下挂的所有终端、还是多个交换机同时受影响。这个决定了你从哪一层开始查。第三个基线是规律基线故障周期的稳定性。是严格每 20 分钟一次还是随机发生是工作日高峰期才断还是夜里也断。周期性越规律越倾向于指向某个定时机制或环境因素——比如设备定时任务、SNMP 轮询、生成树定时器、空调定时启停等等。这三点立不住后面所有排查都是盲人摸象。2. 现场信息收集在故障复发前把网兜住2.1 问用户的六个问题问对了省一半时间信息收集阶段我一般会用一套固定问题清单去引导用户避免他们说一堆情绪性描述但什么都不在点上。这六个问题按顺序问下来基本能把故障画像勾勒出来。第一故障什么时候开始的。是今天突然出现还是最近几天才有还是持续了一两周。如果和某次变更、某次设备搬迁、某次施工有关那就是重大线索。第二多久一次每次多久。周期是 20 分钟还是 2 小时每次是 3 秒还是 30 秒这两个参数后续能帮你反推很多逻辑。比如 3 到 8 秒这种量级基本能排除掉 802.1D 传统生成树收敛要 30 到 50 秒而更像 RSTP/MSTP 的快速收敛加上端口物理恢复时间。第三是全体断还是个别断。同一个交换机下挂的所有人都断还是只有某几个工位断。第四有没有固定规律。是不是整点、是不是每天某个时段、是不是和某个操作同步。第五断的时候设备指示灯有没有变化。这个问题用户往往答不上来但如果有人能观察到端口灯闪灭一下那基本就锁定物理层了。第六最近有没有新增设备或改动。新装的小交换机、新拉的网线、新接的摄像头、新上的 AP这些都是环路的常见来源。2.2 上机后第一批必抓的命令清单到现场之后不管你多着急先别急着敲reset。第一批命令的目的不是找问题而是把当前正常状态完整存档作为后续对比的参照。我会按这个顺序抓一遍先display version记录设备型号、软件版本和运行时间版本缺陷和长时间运行都是潜在嫌疑再display device看板卡和电源状态然后display interface brief把全部端口的 up/down 状态快速扫一遍特别留意有没有处于 down 状态但业务上应该是 up 的端口。接着是重点display logbuffer reverse从最新往前看日志找有没有 up/down、TC、STP、聚合相关的记录display stp brief看生成树各端口角色是否稳定display link-aggregation verbose确认所有聚合口两端配置一致最后display cpu-usage和display memory看设备资源。这套抓下来大概五六分钟但它是你和故障赛跑的本钱。因为这些命令的输出都是当下正常的快照你需要它来和故障发生时的状态做对比。同时如果发现日志缓冲区太小默认往往只有几百条几分钟就冲满了立刻调大或者直接配置日志发到外部服务器。2.3 设备时钟对不上日志就白看了这个细节很多人会忽略但它极其重要。如果交换机的系统时间和实际时间不一致你在日志里按时间窗口筛选就会完全错位。我曾经遇到过一次用户说 14:30 断的结果设备时钟慢了 47 分钟我在正确的时间窗口里翻了半天什么都没找到最后才发现是时钟问题。所以上机之后第一件事应该是display clock核对时间。如果偏差大就通过clock datetime手工校正或者更规范一点配置ntp-service enable加上ntp-service unicast-server 你的NTP服务器地址让设备自动同步。多个设备的时钟统一到同一个时间源是分布式故障排查的基础——你才能把核心、汇聚、接入三层的日志按同一根时间轴拼起来看否则全是碎片。这一点在很多老机房尤其明显设备可能运行了三五年从没同步过时间各台之间差几分钟到几十分钟不等出了问题回溯日志简直是灾难。3. 从日志、计数器和生成树里挖出线索3.1 logbuffer 的正确读法从后往前抓时间簇display logbuffer是这类故障的第一现场但大多数人查日志的方式是错的——他们从头往后翻找带有 error、down 关键词的行。正确做法是从后往前先定位时间簇。所谓时间簇就是日志在某个时间点上密集出现的一段。设备平时日志是很稀疏的可能几分钟才蹦一条。而故障发生时往往会在几秒内刷出十几条甚至几十条日志。你要找的就是这种突然密集的段落因为那才是故障的指纹。在这个案例里我按用户给的 10:07 这个时间点往前推两分钟开始搜很快就看到了这样的模式先是某个端口changed to down紧接着是一串Topology change、TCN received之类的记录几秒后又出现changed to up。非常清晰——物理口闪断 生成树拓扑变更这两件事同时出现方向基本就定了。提示logbuffer 默认容量有限故障周期又长很容易被日常日志冲掉。排查期间建议先把 buffer 调大info-center logbuffer size或者配置info-center loghost把日志实时发到服务器上让证据不再丢失。3.2 端口错包计数CRC 才是物理层的第一证人物理层故障里最快能抓到证据的指标就是 CRC 错误。CRC 校验失败意味着链路上传输的帧在到达时内容已经损坏绝大多数情况下是物理介质出问题——光纤脏了、模块劣化、网线太长、接头松动、电磁干扰。H3C 上看这个指标用display interface GigabitEthernet1/0/49在输出里找到 Errors 相关的段落看 CRC、Giants、Runts、Jabbers 这几个计数。关键是不能只看数值要看增长趋势。因为一个运行了几年的端口历史上有几百个 CRC 错误太正常了那可能是当年某次插拔造成的跟当前故障无关。正确姿势是reset counters interface GigabitEthernet1/0/49先清零然后等一个故障周期再看。如果清零后二十分钟内 CRC 从 0 涨到了几百甚至上千那基本就实锤了——这个端口在持续误码链路质量不合格。反过来如果清零后一个周期过去 CRC 还是 0你就可以基本把这个端口排除掉。还有一个容易忽略的点光模块的数字诊断信息。用display transceiver diagnosis interface GigabitEthernet1/0/49可以读到实时收发光功率、工作温度、电压、偏置电流。其中接收光功率RX power如果接近模块灵敏度的下限链路就会进入时好时坏的临界状态典型表现就是偶发误码和间歇性 up/down。案例里的真凶就藏在这里。3.3 TC 报文统计全网泛洪留下的指纹生成树协议里有一个非常关键的概念拓扑变更TC。当网络里某个链路发生变化STP 会通知整个生成树域域内所有交换机都会把 MAC 地址表的老化时间从默认 300 秒临时缩短到 15 秒转发延迟这会导致大量在世的 MAC 表项被提前老化后续流量触发的就是未知单播泛洪。短则一两秒长则十几秒全网都会感觉到卡顿。H3C 上用display stp tc-bpdu statistics可以看到每个端口收发 TC/TCN 报文的累计数量。这个命令的价值在于对比——正常稳定的接入交换机几个小时内 TC 计数应该是两位数以内甚至更低。如果某个端口的 TC 计数在短时间内飙升到几千上万那说明它一直在参与拓扑变更的传递附近一定有反复 up/down 的链路或者配置错误。案例里我在 A 栋的汇聚交换机上跑这条命令看到上联口的 TCN 计数在一天内累积了两万多次这就是一个非常刺眼的信号——网络一直在震荡只是大多数时候用户在忙别的没注意。4. 逐层收敛把可能性排成队再逐个验证4.1 物理层光模块、跳线、供电和环境温度排查到这一步最应该优先验证的是物理层理由很简单——它最容易验证而且故障率最高。你别一上来就怀疑生成树配置、怀疑 ARP 攻击那些是验证成本很高的方向。物理层里我一般按这个顺序查光模块型号是否匹配、是否第三方兼容、收发光功率是否在范围内、有没有告警、跳线是否插紧、弯曲半径是否过小、有没有被压在机柜门下面、端口有没有氧化、是不是长期没插拔导致接触不良、供电和环境电源模块有没有告警、风扇是否正常、机柜温度是否过高。display transceiver alarm interface这条命令会直接列出光模块当前的告警如果接收光功率低于告警阈值它会明确告诉你。而display transceiver interface能看到模块的厂商、序列号、生产日期——第三方兼容模块用的是很多价格便宜但劣化速度往往比原厂快运行四五年之后出现问题的概率明显上升。案例里的这个模块就是第三方兼容的已运行四年多。4.2 环路与广播风暴最常见也最容易被误判一说到周期性断网很多人的第一反应是环路。环路确实是园区网最常见的故障源之一但它有个特点——真环路往往表现为持续性问题而不是周期性。如果用户私接的小交换机形成了物理环路正常情况下 STP 会立刻把其中一个端口阻塞掉网络会恢复只有在拓扑发生变化的瞬间才会短暂泛洪。所以周期性这个特征反而说明可能不是稳定的环路而是某个链路在反复震荡诱发了反复的拓扑变更。这两者的区别很重要因为处置方式完全不一样真环路要去找到那台私接设备并拆掉震荡要去解决链路本身的不稳定性。验证是否有环路可以用display stp brief看各端口角色正常接入交换机上应该只有一个根端口加若干指定端口如果出现了大量阻塞端口同时存在的情况就要警惕。再看display mac-address mac-move有没有 MAC 地址在两个端口之间反复漂移这也是环路的典型特征。4.3 生成树震荡与根桥抢占生成树本身配置不当也会造成周期性抖动最典型的是根桥抢占。如果你在网络里配置了多个优先级相同或者配置不当的桥某些设备重启或者链路恢复时会触发根桥重新选举整个生成树域都会重新收敛一遍。还有一个高频错误是双上行链路配置不一致一端做了链路聚合另一端没做或者做聚合的一端是静态聚合另一端是动态 LACP。这种情况下协议报文对不上聚合口状态会在 up 和 down 之间反复跳每次跳变都可能触发拓扑变更。再一个就是接入端口忘记配置边缘端口edged-port。接终端的端口如果没设成边缘端口终端关机、网卡休眠、插拔网线都会产生 TC 报文传给上游让整个生成树域跟着刷新。一个几百人的办公区每天开关机几百次累积起来的 TC 数量非常可观。4.4 三层侧ARP 冲突、DHCP 耗池、IP 地址打架如果物理层和二层都干净那就要往三层看了。三层侧的周期性故障主要有这么几类。ARP 冲突局域网里两台设备配了同一个 IP会持续互相抢答 ARP导致该 IP 对应的通信时断时续同时网关侧的 ARP 表项会反复刷新。表现就是某些机器时通时不通用display arp可以看到同一个 IP 对应两个 MAC 的情况。DHCP 地址池耗尽地址池不够用的时候新接入的终端拿不到地址用户表现为连上了但上不了网。但这种一般不是周期性除非终端数量本身有潮汐规律比如上班时间集中接入。网关 ARP 学习被攻击某些异常终端高频发送 ARP 报文把网关的 ARP 学习表冲击得很厉害表现为整个网段通信质量下降。这类问题要看display cpu-usage里 ARP 相关的任务占用。4.5 设备自身CPU、内存、温度和版本缺陷最后不要忘了设备自己。交换机也是机器也会出问题。周期性断网有时候就是设备某个软件模块定时出 bug或者资源耗尽触发了保护机制。要看的指标包括display cpu-usage看 CPU 是否有周期性尖峰display memory看内存是否在缓慢增长内存泄漏的典型表现display environment看设备温度部分型号支持display fan和display power看风扇电源display alarm看有没有硬件告警。还有一个容易被忽视的是软件版本缺陷。H3C 的某些版本确实存在已知的 bug会对特定版本的设备造成周期性异常。这种情况最稳妥的验证方式是对照官方的版本说明看当前版本是否在已修复列表里。如果设备版本很老且故障现象比较诡异、逻辑上解释不通升级版本往往比继续深挖更划算。5. 一次真实案例的完整还原每20分钟断3秒的A栋3楼5.1 环境和故障画像先说下环境。这是一个典型的园区网核心是一台 H3C S7506E 做三层网关下面两台 S5560 堆叠做汇聚再往下就是各楼层的 S5130 系列接入交换机。A 栋 3 楼有一台 S5130下挂大约 60 个工位终端加几台 IP 电话上行是单条千兆光纤直连汇聚没有做双上行冗余。故障画像也很清晰从大约两周前开始3 楼的用户每隔 20 到 40 分钟会经历一次短暂断网持续 3 到 8 秒然后自动恢复。最奇怪的是同一时间 A 栋别的楼层用户也会感觉到卡一下但只有 3 楼是真正断的。我们内部把它称为整网打嗝。一开始大家猜是环路、是 ARP 攻击甚至有同事怀疑是园区核心的某个策略定时生效但都没找到证据。故障持续了两周用户投诉越来越多。5.2 按时间轴推进的排查记录第一天上午我到现场之后先做了基础存档把版本、接口状态、生成树、聚合都抓了一遍同时确认了设备时钟当时快了 6 分钟。然后请用户在下次故障发生时立刻打电话给我。当天上午 11:23 用户打来电话说刚断我立刻抓display logbuffer从后往前看果然在 11:22 附近看到了密集的日志簇Physical state on the interface GigabitEthernet1/0/49 changed to down加上一串 TC 相关的记录8 秒后又有一条changed to up。端口 1/0/49 正是那台 S5130 的上联口。初步结论上联物理口间歇性闪断触发全网拓扑变更。第一天下午我对这个端口做了三件事第一reset counters interface GigabitEthernet1/0/49清零计数第二display transceiver diagnosis interface GigabitEthernet1/0/49读光模块诊断第三display transceiver alarm interface看告警。诊断结果有点意思接收光功率是-24.3 dBm。这个数字如果是长距离单模模块1000BASE-LX正常应该在 -3 到 -20 dBm 之间-24.3 已经明显低于典型灵敏度下限了。而且模块温度是 58 度偏高。告警里显示 RX power low 相关的提示。为了对照我顺手读了汇聚侧对应端口的诊断接收光功率是 -6.2 dBm非常正常。问题出在接入侧的下行接收方向——也就是汇聚发出来的光到接入这头衰减过大或者被模块本身接收能力拖累了。第二天我等了一个完整的故障周期再去看计数发现 1/0/49 的 CRC 从 0 涨到了 300 多输入方向的 error 也在增长。至此物理层误码的结论已经非常明确。同时我还用display stp tc-bpdu statistics做了统计汇聚上联口的 TCN 累积数在过去 24 小时里增加了一万九千多次和断网频率高度吻合。排查过程中我还顺手排除了几个方向display stp root显示根桥是核心没有震荡display link-aggregation verbose显示所有聚合口状态正常没有配置不一致display mac-address mac-move没有明显漂移display cpu-usage正常。环路、聚合不一致、三层冲突全部排除。5.3 定位结果与处置动作根因明确接入交换机 S5130 上联口的光模块劣化接收光功率长期处于临界值附近随环境温度波动链路进入间歇性误码和闪断状态。每次闪断触发拓扑变更导致 VLAN 内 MAC 表刷新和全楼泛洪形成用户感知的周期性断网。处置动作分两步。第一步更换光模块。换完之后复读诊断接收光功率从 -24.3 dBm 恢复到-6.2 dBm与汇聚侧对称温度也降到了 41 度。同时把对应的光纤跳线也换了一根避免跳线本身有折损。第二步做加固。虽然根因是模块但这次故障暴露出的一个端口闪断导致全楼泛洪的问题本身也值得处理。我在所有的接入端口上统一配置了stp edged-port接终端和 AP 的端口全部设为边缘端口这样终端开关机不会再产生 TC 报文在上联口上配套开启stp bpdu-protection防止误接设备引发的异常同时把全网的 STP 模式统一确认为 MSTP并规定所有接入交换机的桥优先级统一配置为较高的值避免接入设备意外成为根桥。处置之后我们观察了整整一周故障没有复现。用户侧反馈也很好打嗝现象消失了。6. 速查表与避坑心得6.1 周期性断网问题速查表排查到后半程我基本上会拿着下面这张表过一遍把没验证的方向逐个打勾或者划掉。这张表你可以直接拿去改改用在项目里。排查方向关键命令观察指标典型判断端口物理抖动display logbuffer reverseLink up/down 记录有 up/down 即物理层嫌疑链路误码display interfaceCRC、Runts、Giants清零后一个周期内增长明显光模块质量display transceiver diagnosisRX/TX power、温度RX 接近灵敏度下限即临界光模块告警display transceiver alarm告警条目有 low power 告警直接实锤生成树震荡display stp tc-bpdu statisticsTC/TCN 计数短时间飙升到几千以上根桥抢占display stp root根桥信息根桥是否稳定不切换聚合不一致display link-aggregation verbose成员口状态两端模式不一致要修正MAC 漂移display mac-address mac-move漂移记录有记录警惕环路设备资源display cpu-usage、display memoryCPU/内存曲线周期性尖峰或持续上升硬件告警display alarm、display fan、display power告警条目有告警优先处理时钟对齐display clock时间偏差偏差大直接导致日志错位6.2 我踩过的几个坑第一个坑只看数值不看趋势。前面提过历史遗留的 CRC 计数会误导你。我早期一度看到某端口有几十个 CRC 就下结论说物理层坏了结果换完线毛病还在那几十个错误其实是半年前插拔留下的。后来养成习惯任何计数类指标先清零再看增长。第二个坑忽略用户描述的别的楼层也卡。这句话在第一天的报障记录里其实就有但我当时没在意是后来排查范围卡住的时候才回头翻出来。它其实是把排查从接入层上升到生成树域的关键钥匙。用户描述里往往藏着最精准的线索只是被埋在一堆上不了网是不是运营商的问题里你得有耐心去淘。第三个坑用了第三方光模块不做定期体检。第三方兼容模块成本低、备货快在预算紧张的园区网里非常普遍但它们的老化曲线比原厂陡四五年后需要重点关注。我后来在几个大项目里都加了定期巡检用脚本定期采集display transceiver diagnosis把光功率偏低的模块提前列出来换掉避免这类故障反复发生。第四个坑把生成树配置当成了一劳永逸的事。很多网络交付完之后接入端口是不是边缘端口、桥优先级有没有统一、BPDU 保护有没有开从来没人复查。直到出了故障才发现一大半端口都是默认配置。这块的加固成本极低收效却很明显建议每个项目交付时都做一次专项核查。第五个坑日志从没落过盘。故障两周期之后原来的日志早被冲掉了光靠现场抓 logbuffer 很难凑出完整证据链。后来我在所有关键设备上配了info-center loghost把日志实时发到日志服务器现在任何间歇性故障发生都会有完整的时间轴可以回溯。这个改动花不了多少钱但对排查效率的提升是数量级的。第六个坑太快下结论给用户观察观察。我早期遇到过类似案例因为现场一切正常就跟用户说再看看可能是终端问题结果两周后用户拿着电话录音和视频来找我们场面很被动。现在的做法是只要用户报的是周期性自愈型故障我宁可当天就把基线采完也不给观察一下这种含糊答复。最后再分享一个我在实际运维里一直用的习惯只要接到周期性断网的报障我会在建单的同时让现场同事或用户做一个动作——用一部一直开着的手机对着交换机面板录一段视频直到故障发生。这招听起来有点土但极其有效因为端口灯闪灭的瞬间、风扇转速变化、模块指示灯异常这些信息是任何日志都给不了的而它往往能在排查最卡壳的时候给你决定性的一击。