企业官网建设流程全解析

1. 深夜告警：当S5700交换机开始"丢包"

那天晚上11点半，我正敷着面膜追剧，手机突然像催命符一样震动起来。运维监控系统弹出一连串告警：核心机房的S5700-28P-LI汇聚交换机CPU利用率飙到98%，下联的二十多台服务器全部失联。同事在微信群里已经炸锅："完了完了，财务系统月底结账卡死了！""VPN连不上生产环境！"

第一反应和所有网工一样——硬件故障。毕竟这台服役5年的老将最近总闹脾气，风扇噪音大得像拖拉机。但当我远程登录交换机时，发现管理界面还能操作，只是不断刷出两行刺眼的日志：

%May 13 21:05:23:819 2023 HUAWEI STP/4/STP_DISCARDING:The port has been set to discarding state... %May 13 21:05:25:112 2023 HUAWEI STP/4/STP_TOPOLOGY_CHANGE:Bridge topology change detected...

这两个关键词立刻让我汗毛直立：discarding状态和拓扑变更。就像老司机看到仪表盘上同时亮起机油灯和发动机灯，这绝对不是简单重启能解决的问题。

2. STP协议：网络世界的交通警察

要理解这个故障，得先搞懂**STP（生成树协议）**的工作原理。想象一个没有红绿灯的十字路口，所有车辆（数据包）都在疯狂转圈——这就是二层网络出现物理环路时的场景。STP就像个智能交警，通过阻塞特定端口（相当于设置红灯）来逻辑上切断环路。

为什么会有环路？常见原因包括：

• 冗余设计：为了防止单点故障，我们会用多条线路连接交换机
• 误操作：菜鸟运维把两根网线插在同一台交换机的两个端口上
• 设备异常：某些网络设备故障后开始疯狂泛洪广播包

当STP检测到环路时，会立即把问题端口置为discarding状态（相当于封路），阻止数据包进入环路。但副作用是——这个端口下的所有设备都会"失联"。

3. 破案三部曲：从告警到根因

3.1 第一步：STP拓扑速诊

连上交换机后，我第一时间敲下黄金命令：

<HUAWEI> dis stp brief

输出结果像张X光片，清晰显示各个端口的状态：

Port Role STP State Protection Gig0/0/1 ALTERNATE DISCARDING NONE Gig0/0/2 ROOT FORWARDING NONE

关键发现：Gig0/0/1端口被STP强制阻塞，而且角色是ALTERNATE（备用端口）。这说明网络中存在另一个更优路径，STP选择阻塞当前端口来避免环路。

3.2 第二步：LLDP邻居侦查

接下来用邻居发现协议"抄家底"：

<HUAWEI> dis lldp neighbor brief

返回信息让我瞳孔地震：

Local Interface Neighbor Device Neighbor Interface Gig0/0/1 ACCESS-SWITCH Gig0/0/24 Gig0/0/2 CORE-SWITCH Gig0/0/10

正常情况下，Gig0/0/1应该连接核心交换机，现在却接了个接入层交换机！相当于本该直通高速公路的入口，被接到了乡间小道上。

3.3 第三步：物理链路追凶

带着打印出来的LLDP信息冲到机房，顺着网线摸查发现：某个实习生把两台接入交换机用网线背靠背直连了（还得意地说"这样传输更快"）。这就形成了典型的物理环路：

[核心交换机]----[S5700]----[接入交换机A]====[接入交换机B] （违规直连线）

4. 止血与预防：运维人的自我修养

拔出那根罪恶的网线后，监控大屏上的流量曲线立刻恢复正常。但作为老司机，我还做了这些加固操作：

1. 边缘端口防护：在所有接入端口开启BPDU保护

[SW] stp edged-port enable [SW] stp bpdu-protection

2. 拓扑变更监控：配置SNMP trap实时捕获STP事件
3. 物理端口管理：启用接口描述模板

interface GigabitEthernet0/0/1 description TO-CORE-SWITCH-PORT10

这次故障给我最深的教训是：90%的"硬件故障"都是配置问题。下次再看到discarding状态告警，不妨按这个检查清单操作：

1. 查看dis stp brief确认阻塞端口
2. 用dis lldp neighbor排查异常连接
3. 检查最近是否有网络变更记录
4. 最后才考虑重启或更换设备

凌晨两点走出机房时，保安大爷笑着问我："又救火啊？"我晃了晃手里那根惹祸的蓝色网线："逮到只捣乱的小老鼠。"