企业官网建设流程全解析

断网不可怕，可怕的是它自己会好。这句话我在这些年做网络运维的过程中反复验证过——凡是"断了又自己恢复""用户说卡了几秒钟""你去的时候一切正常"这类报障，排查难度往往是持续故障的三五倍。你到现场时设备灯全绿，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 错误计数这类指标来抓。

第三种是整网短暂泛洪。某个地方发生了拓扑变更（TC，Topology 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 周期性断网问题速查表

排查到后半程我基本上会拿着下面这张表过一遍，把没验证的方向逐个打勾或者划掉。这张表你可以直接拿去改改用在项目里。

6.2 我踩过的几个坑

第一个坑：只看数值不看趋势。前面提过，历史遗留的 CRC 计数会误导你。我早期一度看到某端口有几十个 CRC 就下结论说物理层坏了，结果换完线毛病还在，那几十个错误其实是半年前插拔留下的。后来养成习惯，任何计数类指标，先清零再看增长。

第二个坑：忽略用户描述的"别的楼层也卡"。这句话在第一天的报障记录里其实就有，但我当时没在意，是后来排查范围卡住的时候才回头翻出来。它其实是把排查从接入层上升到生成树域的关键钥匙。用户描述里往往藏着最精准的线索，只是被埋在一堆"上不了网""是不是运营商的问题"里，你得有耐心去淘。

第三个坑：用了第三方光模块不做定期体检。第三方兼容模块成本低、备货快，在预算紧张的园区网里非常普遍，但它们的老化曲线比原厂陡，四五年后需要重点关注。我后来在几个大项目里都加了定期巡检，用脚本定期采集display transceiver diagnosis，把光功率偏低的模块提前列出来换掉，避免这类故障反复发生。

第四个坑：把"生成树配置"当成了一劳永逸的事。很多网络交付完之后，接入端口是不是边缘端口、桥优先级有没有统一、BPDU 保护有没有开，从来没人复查。直到出了故障才发现一大半端口都是默认配置。这块的加固成本极低，收效却很明显，建议每个项目交付时都做一次专项核查。

第五个坑：日志从没落过盘。故障两周期之后，原来的日志早被冲掉了，光靠现场抓 logbuffer 很难凑出完整证据链。后来我在所有关键设备上配了info-center loghost，把日志实时发到日志服务器，现在任何间歇性故障发生，都会有完整的时间轴可以回溯。这个改动花不了多少钱，但对排查效率的提升是数量级的。

第六个坑：太快下结论给用户"观察观察"。我早期遇到过类似案例，因为现场一切正常，就跟用户说"再看看，可能是终端问题"，结果两周后用户拿着电话录音和视频来找我们，场面很被动。现在的做法是，只要用户报的是"周期性自愈型"故障，我宁可当天就把基线采完，也不给"观察一下"这种含糊答复。

最后再分享一个我在实际运维里一直用的习惯：只要接到周期性断网的报障，我会在建单的同时让现场同事或用户做一个动作——用一部一直开着的手机对着交换机面板录一段视频，直到故障发生。这招听起来有点土，但极其有效，因为端口灯闪灭的瞬间、风扇转速变化、模块指示灯异常，这些信息是任何日志都给不了的，而它往往能在排查最卡壳的时候给你决定性的一击。