网络运维 on Zero Day Notes

一次OSPF路由震荡导致跨机房业务间歇性中断的排查实录

Sun, 05 Jul 2026 07:00:00 +0000

问题背景

周一早晨8:15，IT运维组值班手机开始收到一连串业务投诉——总部办公区（DC-A）用户访问部署在分支机房（DC-B）的ERP系统时，页面每隔5~8分钟就会出现约30秒的"卡死"现象：页面加载超时、报表查询报错、部分用户甚至看到502 Bad Gateway。受影响用户约180人，集中在财务和采购部门，这两个部门对ERP依赖度最高，故障紧急度评级P1。

DC-A与DC-B之间通过10Gbps专线互联，核心交换机之间建立OSPF Area 0邻接关系，各机房内部使用Area 1/2。两机房BGP使用各自AS号（65001/65002），通过OSPF学习对方的互联地址作为BGP下一跳。正常情况下，OSPF邻接稳定，BGP路由下一跳始终可达，跨机房流量畅通无阻。

故障持续时间约2小时，期间ERP服务本身运行正常（DC-B内部用户无任何异常），问题明确指向跨机房网络层面。

故障现象

监控层面：Zabbix采集的ERP前端响应时间曲线呈现明显的周期性尖刺——基线200ms，每5~8分钟突然飙至3000ms以上，持续约30秒后回落。对应时段，Grafana上的跨机房TCP连接数从稳态的120条骤降至0，HTTP 5xx错误率同步跳升。

用户层面：财务部张经理反馈"9:00打开应付账款页面卡了半分钟，刷新后又好了，过几分钟又卡"；采购部多人报告提交采购单时超时报错。

网络层面：在DC-A核心交换机（CE6850-01）上持续观察BGP路由表，发现DC-B侧的172.16.0.0/16网段路由在反复出现和消失：

<CE6850-01> display bgp routing-table 172.16.0.0
  Network          NextHop        Med  LocPrf  Pref  Path
*  172.16.0.0/16   10.0.0.2       0    100     255  65002 I
  // 30秒后路由消失
<CE6850-01> display bgp routing-table 172.16.0.0
  // No entry found
  // 再过20秒路由恢复

BGP路由的下一跳10.0.0.2是DC-B核心交换机的互联地址，通过OSPF学习。当OSPF邻接断开时，10.0.0.2的路由消失，BGP判定下一跳不可达，撤销172.16.0.0/16路由；OSPF邻接恢复后，下一跳重新可达，BGP路由重新生效。这正是典型的"OSPF驱动BGP路由震荡"模式。

排查过程

第一步：确认故障范围与定性

第一时间在DC-A核心交换机上Ping DC-B互联地址：

<CE6850-01> ping 10.0.0.2 repeat 100
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255
  Request timeout
  Request timeout
  Request timeout
  Request timeout
  Request timeout
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255

Ping结果呈现周期性超时——连续5~6个包超时后恢复，与业务监控的尖刺周期吻合。用大包测试进一步确认：

1
2

<CE6850-01> ping 10.0.0.2 size 4000 repeat 50
  // 大包丢包率高达40%，小包丢包率仅8%

小包丢包率远低于大包，这提示物理层可能存在误码问题——小包CRC校验通过的几率更高，大包更容易被误码破坏。

第二步：检查OSPF邻接状态

<CE6850-01> display ospf peer
  Area 0.0.0.0
    Neighbor 10.0.0.2, Interface GE1/0/1
      State: Full  -> 正常时
    // 故障时段观察
    Neighbor 10.0.0.2, Interface GE1/0/1
      State: Init  -> 邻接断开
      State: ExStart -> 正在重建
      State: Full  -> 重新建立

开启OSPF事件调试进一步观察邻接变化细节：

<CE6850-01> debugging ospf event
  OSPF/Event: Nbr 10.0.0.2 state changed: Full -> Down (Receive bad hello seq)
  OSPF/Event: Nbr 10.0.0.2 state changed: Down -> Init (Hello received)
  OSPF/Event: Nbr 10.0.0.2 state changed: Init -> 2-Way (2-Way received)
  OSPF/Event: Nbr 10.0.0.2 state changed: 2-Way -> ExStart (Negotiation done)
  OSPF/Event: Nbr 10.0.0.2 state changed: ExStart -> Exchange (DB exchange)
  OSPF/Event: Nbr 10.0.2 state changed: Exchange -> Full (Adjacency done)

OSPF邻接从Full断到Down再到恢复Full，整个过程约25~30秒，与业务中断时长一致。关键信息是Receive bad hello seq——收到了错误的Hello报文序列号，说明Hello报文在传输过程中被损坏。

第三步：检查物理接口状态

这是最关键的一步。查看互联端口GE1/0/1的统计信息：

<CE6850-01> display interface GE1/0/1
  GE1/0/1 current state: UP
  Last 300 seconds input rate: 854 bits/sec, 3 packets/sec
  Last 300 seconds output rate: 1236 bits/sec, 5 packets/sec
  Input:
    Total packets: 94782
    CRC errors: 3847           <-- 异常！正常应接近0
    Frame errors: 0
    Overrun: 0
  Output:
    Total packets: 94521
    CRC errors: 0
    Collision: 0

CRC错误计数3847，而且每分钟还在增长约50~60个！端口当前状态是UP（没有进入error-disable），但持续增长的CRC误码意味着大量报文在物理层被损坏——OSPF Hello报文、DD报文、LS Update报文都可能被CRC校验失败丢弃，导致邻接关系反复中断。

查看DC-B侧的对应端口，同样有CRC计数增长：

1
2

<CE6850-02> display interface GE1/0/1
  Input CRC errors: 3612       <-- 对端也在涨

双向CRC错误都在增长，基本排除了单端交换机端口硬件故障的可能性，指向中间的物理链路——光纤本身或接头。

第四步：排查光纤链路

DC-A与DC-B之间10G专线通过ODF（光纤配线架）跳接，路径为：CE6850-01 GE1/0/1 → LC光纤 → ODF-A M3/V3 → 室内光缆 → ODF-B M3/V3 → LC光纤 → CE6850-02 GE1/0/1。

先在交换机上开启光功率监测：

<CE6850-01> display interface GE1/0/1 transceiver
  Rx Power: -14.2 dBm     <-- 偏低！10G LR正常范围 -6~-20dBm，但已接近下限
  Tx Power: -2.1 dBm      <-- 正常
  Rx Loss: 12.1 dB        <-- 光衰偏大

<CE6850-02> display interface GE1/0/1 transceiver
  Rx Power: -13.8 dBm
  Tx Power: -2.3 dBm

两端收光功率均偏低约3dBm，光衰偏大。15km LR模块正常光衰应在6~8dB，实测12dB明显偏高。这说明链路中存在额外的光损耗点。

第五步：定位光损耗点

联系机房驻场同事到ODF架现场检查。同事反馈：ODF-A侧M3/V3端口的LC适配器内积有明显灰尘，尾纤插入时感觉松动。用光纤端面检测仪（Fiber Microscope）观察该适配器：

适配器内芯有黑色颗粒污染物
尾纤端面也有轻微划痕和灰尘

这就是CRC误码的物理根因——适配器污染导致光纤端面之间存在空气间隙和散射，部分光信号在接头处被反射和散射（高回波损耗+高插入损耗），接收端收到的光信号功率偏低且带有失真，导致CRC校验失败。

同事用光纤清洁笔（One-Click Cleaner）清洁适配器内芯和尾纤端面后，重新插接：

1
2
3

<CE6850-01> display interface GE1/0/1 transceiver
  Rx Power: -6.8 dBm       <--恢复正常范围！
  Rx Loss: 6.8 dB           <--光衰恢复正常

同时CRC计数停止增长，Ping大包测试丢包率归零：

1
2

<CE6850-01> ping 10.0.0.2 size 4000 repeat 100
  100 packets transmitted, 100 received, 0% loss

OSPF邻接立即恢复稳定：

1
2

<CE6850-01> display ospf peer
  Neighbor 10.0.0.2, State: Full  (stable for 15 min)

BGP路由恢复稳定，ERP访问恢复正常，故障解除。从发现CRC异常到清洁光纤接头，整个过程约40分钟。

解决方案

紧急止血

清洁光纤接头：用One-Click Cleaner清洁ODF-A M3/V3适配器内芯和对应尾纤端面，重新插接后光功率恢复正常，CRC误码消失
重置接口计数器：执行reset counters interface GE1/0/1清零CRC计数，便于后续观察是否复发

根治措施

更换退化适配器：ODF-A M3/V3的LC适配器因长期插拔和污染，内部陶瓷套管已有轻微磨损，更换为新的LC双芯适配器
更换受损尾纤：端面有划痕的尾纤更换为新尾纤，旧尾纤端面划痕无法修复
OSPF稳定性增强：调整OSPF Hello间隔和死亡间隔，增加邻接容错能力：

interface GE1/0/1
  ospf timer hello 15        // 从默认10秒改为15秒，减少Hello报文频率
  ospf timer dead 60         // 从默认40秒改为60秒，给邻接更多恢复窗口
  ospf authentication-mode md5 1 cipher XXXXXX  // 增加认证防止非法报文干扰

BGP震荡抑制：配置BGP路由衰减（route dampening），防止震荡路由反复注入转发表：

1
2

bgp 65001
  route-dampening half-life-reachable 15 half-life-unreachable 15 reuse 750 suppress 2000 max-suppress-time 60

物理层监控：在Zabbix添加CRC计数器监控项，设置阈值告警：

1
2
3

监控项: snmp.get[ifInErrors.{#IFINDEX}]  // CRC错误计数
触发器: CRC错误增量 > 50/分钟 → P2告警
触发器: CRC错误增量 > 200/分钟 → P1告警

光功率监控：通过SNMP采集光模块收发功率，设置偏差告警：

1
2
3

监控项: optical.rxpower[GE1/0/1]
触发器: Rx Power < -10dBm → P2告警（光衰偏高预警）
触发器: Rx Power < -18dBm → P1告警（即将断光）

根因分析

本次故障的根本原因是ODF光纤适配器内芯污染导致的光信号衰减和失真，进而引发CRC误码→OSPF报文丢弃→邻接断建→BGP下一跳可达性波动→路由震荡→业务间歇中断，形成了一条从物理层到应用层的完整故障传导链。

适配器污染的原因有二：

日常维护不规范：机房ODF架近期有其他业务割接施工（周三新增一条2.5G专线），施工人员在ODF架操作时拔插了相邻M3/V3端口的尾纤用于测试，插回时未清洁端面，将手指油脂和灰尘带入适配器内芯
缺乏端面清洁SOP：团队光纤操作规范中没有"插接前必须清洁端面"的强制要求，日常巡检也不检查ODF适配器清洁度

光功率从-6.8dBm退化到-14.2dBm（增加了约7dB损耗），恰好是污染适配器造成的额外插入损耗。这个损耗水平尚在光模块接收灵敏度范围内（-20dBm），所以端口没有down，但信号质量已经劣化到足以产生大量CRC错误——这就是"端口UP但业务断"的典型场景。

预防措施

光纤操作SOP：制定并强制执行《ODF光纤操作规范》——任何拔插光纤操作必须先用One-Click Cleaner清洁端面和适配器，操作前后用端面检测仪确认清洁度。将此规范纳入变更管理流程，割接方案必须包含光纤清洁步骤
ODF适配器防护：空闲端口必须安装防尘帽，施工结束后检查相邻端口防尘帽是否完好。ODF架门保持关闭，减少灰尘侵入
物理层监控体系：将CRC错误计数和光模块功率纳入核心监控，设置分级告警阈值。CRC错误是物理层故障的"早期信号"——远比端口down更早出现，做到故障预警而非故障后才发现
光纤巡检制度化：每季度对所有ODF架做一次光功率测试+端面检测，记录光衰基线数据。光衰异常增长>2dB的链路标记为"需维护"，安排清洁或更换
OSPF/BGP震荡防护：核心互联链路OSPF参数适当放宽（Hello 15秒、Dead 60秒），为物理层短暂抖动提供缓冲窗口；BGP开启route dampening，抑制震荡路由对转发表的反复冲击
跨机房业务连续性增强：评估增加DC-A到DC-B的第二条互联链路（冗余路径），当主链路OSPF震荡时流量自动切换到备用链路，消除单链路故障对业务的影响

总结

这次故障的教训是：物理层的微小退化可以引发网络层的大规模震荡。一个ODF适配器里几粒灰尘，让光衰增加7dB，CRC误码飙升，最终导致180人的ERP服务反复中断2小时。

排查的关键转折点是在接口统计中发现CRC错误计数持续增长——如果只看端口状态（UP），永远找不到根因。这也提醒我们，网络监控不能只盯着"端口UP/DOWN"和"带宽利用率"，CRC错误、光功率这些物理层指标同样是核心监控项，而且往往能提前预警。

OSPF→BGP的震荡传导机制也值得牢记：当BGP下一跳依赖OSPF路由时，OSPF邻接的任何抖动都会直接传导到BGP路由层。在核心互联设计中，要么让BGP下一跳不依赖OSPF（比如用直连地址做下一跳），要么给OSPF足够的容错参数，要么开启BGP dampening抑制震荡——三条防线缺一不可。

最后，光纤端面清洁这个看似琐碎的操作，实际上是机房物理层可靠性的基础。一根未清洁的尾纤，可能就是下一次P1故障的起点。

一次FortiGate HA主备切换因会话同步不完整导致业务大规模中断的排查实录

Thu, 02 Jul 2026 07:00:00 +0000

问题背景

我们公司总部机房出口部署了两台 FortiGate 600E 防火墙，以 Active-Passive 模式组成 HA 双机热备集群，承载全公司约 1800 人的互联网访问、总部-分支 IPSec VPN 隧道（6 条）、以及 ERP/OA 等业务系统的对外发布。这套 HA 集群已经稳定运行两年多，期间也经历过两次计划内主备切换（固件升级），均未出现异常。

周三上午 9:15，正值上班高峰期，监控平台突然弹出大量告警——6 条 VPN 隧道状态全部变为 Down，ERP 系统外部访问超时，OA 系统邮件收发中断。与此同时，多个分支机构电话涌入，报告无法访问总部内网资源。整个业务中断持续了约 40 分钟，影响了近 800 名在线用户的正常工作，紧急程度极高。

故障现象

故障发生时，现象非常明确且集中：

1. VPN 隧道全部中断

6 条总部到分支的 IPSec VPN 隧道在 9:15 同时从 Phase 2 Up 变为 Down，FortiGate VPN Monitor 页面显示隧道状态为 “Tunnel Down”，但 Phase 1 仍在协商中。各分支的 FortiGate 日志中出现大量：

1
2

ike: IPSec SA negotiation failed: payload malformed
ike: phase 2 negotiation failed due to timeout

2. ERP 和 OA 系统外部连接中断

Nginx 日志中 9:15 之后请求量骤降至零，直到 9:55 才开始恢复。Grafana 监控图上 TCP 连接数从 2300+ 瞬间跌至 12（仅剩防火墙自身管理连接）。

3. 内部用户互联网访问短暂中断后恢复

内部员工的互联网访问在 9:15 中断了约 30 秒后恢复，但所有需要维持长连接的应用（SSH 会话、WebSocket 推送、SIP 语音通话）全部断开，需要重新建立连接。

4. FortiGate HA 状态异常

登录防火墙管理界面后发现：原主设备（FG-600E-01）已变为 Standby，原备设备（FG-600E-02）已变为 Active。HA 切换确实发生了，但业务并未如预期无缝恢复。

关键日志片段（备机升级为 Active 后）：

ha: HA member 1 (FG-600E-01) status changed to standby
ha: HA member 2 (FG-600E-02) status changed to active
ha: HA failover triggered by: member 1 heartbeat lost
ha: Session sync incomplete: 48213/112340 sessions synced (43%)

最后一行日志格外引人注目——会话同步只完成了 43%，意味着超过 6 万条活跃会话在切换时丢失了。

排查过程

第一步：确认 HA 切换原因

首先搞清楚为什么会发生 HA 切换。登录原主设备（现在是 Standby）查看日志：

1
2
3

system: Thermal shutdown triggered: temperature threshold exceeded (65°C > 55°C)
system: Fan 1 status: failed, Fan 2 status: failed
system: HA heartbeat lost, member transitioning to standby

主设备的两个风扇同时故障，导致设备温度超过阈值触发热保护关机。这是个硬件故障，HA 切换本身是正确的保护行为。

在 FortiGate CLI 上进一步确认：

# execute ha peer status
HA Peer Status:
  Member 1 (FG-600E-01): Standby, heartbeat: OK, uptime: 0d 0h 45m (recovered)
  Member 2 (FG-600E-02): Active, heartbeat: OK, uptime: 2y 178d

# get system status
Hostname: FG-600E-01
HA Health Status: Standby
Temperature: 42°C (recovered after fan replacement by auto-restart)

主设备在温度恢复正常后自动重启并重新加入了 HA 集群（作为 Standby），但此时业务中断已经发生了。

第二步：深入分析会话同步率为什么只有 43%

这是核心问题。正常情况下，Active-Passive HA 的会话同步应该是实时进行的——主设备上每建立一条新会话，都会同步到备设备。我们检查了 HA 配置：

# show system ha
config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set session-pickup enable
    set session-pickup-connectionless enable
    set override-disable
    set priority 100 (主) / 50 (备)
end

session-pickup enable 是开着的，session-pickup-connectionless enable 也开着（UDP 等 UDP 类会话也会同步）。配置看起来没问题。

但关键参数我们漏掉了：session-sync-dev 和 ha-session-sync-frequency。

继续查看完整配置：

# show system ha full-configuration
config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set hbdev-vlan-id 0
    set hbdev-peerip 0.0.0.0
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-sync-dev "ha1"    <-- 仅用一条心跳线同步会话
    set ha-session-sync-frequency 50    <-- 每50ms同步一批
    set override-disable
    set priority 100
end

发现了两个问题：

session-sync-dev 仅指定了 ha1——会话同步只通过一条心跳线传输，而我们有两条心跳线（ha1 和 ha2），第二条只用来传心跳，没用来传会话数据。
ha-session-sync-frequency 设为 50ms——这意味着每 50ms 才同步一批会话更新。在高并发场景下（112340 条活跃会话），50ms 的间隔会导致同步队列积压。

第三步：计算会话同步吞吐量瓶颈

FortiGate HA 会话同步的工作机制是：主设备每隔 ha-session-sync-frequency 毫秒，将这段时间内新增/变更的会话打包发送到备设备。每批最大传输约 256 条会话更新（取决于底层 TCP 窗口和 MTU）。

我们来算一下：

同步频率：50ms → 每秒 20 批
每批上限：约 256 条
每秒最大同步速率：20 × 256 = 5120 条/秒

但在上班高峰期，新会话建立速率是多少？我们从监控数据中提取：

1
2
3

# 从 FortiGate 的 session 统计看
Active sessions at 09:14: 112340
New sessions per second (average 09:00-09:15): ~18000

每秒新增约 18000 条会话，但同步速率上限只有 5120 条/秒——同步速率远低于会话创建速率，差距约 3.5 倍。

这意味着在高峰期，主设备上大量会话根本来不及同步到备设备。当切换发生时，备设备上的会话表只是"最近同步过来的那部分"，而不是完整的活跃会话集合。

此外还有一个问题：FortiGate 的会话同步是增量同步，不是全量同步。主设备只在会话建立时发送一次同步消息，后续的状态变更（如 TCP 序列号更新、窗口大小变化）不会再同步。所以即使同步速度够快，长连接的中间状态信息也是缺失的。

第四步：验证心跳通道带宽

两条心跳线分别连接在不同端口上：

1
2

ha1: port3 (1Gbps RJ45)
ha2: port4 (1Gbps RJ45)

心跳线用的是千兆端口，但 session-sync-dev 只指定了 ha1，意味着所有会话同步数据只走 port3 一条链路。实际测量 port3 在高峰期利用率：

1
2
3

# fnsysctl ifconfig port3
port3: TX packets 847320, TX bytes 634MB (09:00-09:15)
port3: RX packets 823100, RX bytes 618MB

15 分钟内 TX 634MB → 平均速率约 7Mbps。对于千兆链路来说带宽远没有用满，但问题不在带宽，而在同步频率太低导致每批数据量不够。

如果把 ha-session-sync-frequency 从 50ms 改为 1ms（最小值），每秒同步频率从 20 批提升到 1000 批，同步速率上限变为 1000 × 256 = 256000 条/秒，远超高峰期新增速率。同时如果把 session-sync-dev 改为同时使用 ha1 和 ha2，吞吐量还能翻倍。

第五步：检查历史切换记录

排查到这里，不禁要问：之前两次计划内切换为什么没出问题？我们查看 HA 事件历史：

# execute ha history
1. 2024-03-15 02:00 - Planned failover (firmware upgrade), session sync: 98.7%
2. 2025-01-10 03:00 - Planned failover (firmware upgrade), session sync: 99.2%
3. 2026-07-02 09:15 - Unplanned failover (thermal shutdown), session sync: 43%

前两次切换都是在凌晨低峰期进行的（凌晨 2-3 点），活跃会话只有约 3000 条，同步完全来得及。而这次切换发生在早高峰，活跃会话 11 万条，同步速率跟不上，就暴露了这个长期存在的隐患。

本质上是：配置在低峰期"够用"，但高峰期不够用，平时根本发现不了。

第六步：查看备机切换后的会话重建情况

备机成为 Active 后，丢失的会话需要由客户端重新建立。我们统计了业务恢复时间线：

时间	事件	活跃会话数
09:15	HA 切换完成	48213（同步过来的）
09:16	VPN Phase 1 重新协商开始	48500
09:20	6 条 VPN 隧道恢复 4 条	52300
09:30	VPN 全部恢复	61200
09:55	业务连接基本恢复	108000
10:20	会话数恢复到正常水平	112000+

从 48213 恢复到正常水平用了约 1 小时，但核心业务（VPN、ERP）在 40 分钟后才基本可用。原因是 VPN 隧道的 IKE 协商需要多轮密钥交换，加上分支 FortiGate 的 DPD（Dead Peer Detection）检测间隔为 30 秒，隧道重建有较长的等待窗口。

解决方案

紧急止血（已完成）

HA 切换已经发生，无法回滚。业务通过自然重连逐步恢复，VPN 隧道在 DPD 触发后自动重建。40 分钟后业务基本恢复，这是本次故障的实际恢复时间。

配置优化（根治）

1. 提升会话同步频率

将 ha-session-sync-frequency 从 50ms 改为 1ms（最小值），大幅提升同步吞吐量：

# FortiGate CLI
config system ha
    set ha-session-sync-frequency 1
end

修改后，同步速率上限从 5120 条/秒提升到 256000 条/秒，完全覆盖高峰期 18000 条/秒的创建速率。

2. 会话同步使用双心跳通道

将 session-sync-dev 改为同时使用 ha1 和 ha2，使会话同步数据可以走两条链路，提供冗余和更高吞吐：

1
2
3

config system ha
    set session-sync-dev "ha1" "ha2"
end

3. 启用 TCP 会话状态同步

FortiGate 7.0+ 版本支持更精细的 TCP 状态同步，可以通过以下配置启用：

config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expected enable     # 启用 expected-session 同步
end

4. 优化 HA 心跳参数

config system ha
    set hb-interval 500    # 心跳间隔从默认2s改为500ms
    set hb-lost-threshold 3  # 丢失3次心跳判定故障（1.5秒而非6秒）
end

这样主设备故障时备机能更快检测到并切换，减少中断窗口。

5. VPN 階道 DPD 间隔优化

各分支 FortiGate 的 DPD 检测间隔从 30 秒改为 5 秒：

# 各分支 FortiGate
config vpn ipsec phase1-interface
    edit "HQ-VPN"
        set dpd on
        set dpd-retryinterval 5
        set dpd-retrycount 3
    next
end

隧道中断后能在 15 秒内检测到并触发重建，而不是等 90 秒。

6.风扇故障修复

联系 FortiGate TAC 更换主设备的两个故障风扇，同时对备设备也做预防性检查。FortiGate 600E 的风扇模块是可插拔的，更换后设备温度恢复正常。

完整优化后的 HA 配置

config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set hb-interval 500
    set hb-lost-threshold 3
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expected enable
    set session-sync-dev "ha1" "ha2"
    set ha-session-sync-frequency 1
    set override-disable
    set priority 100
end

根因分析

本次故障的根本原因是 HA 会话同步配置未针对高峰期负载进行优化，形成了"低峰期够用、高峰期不够用"的隐性缺陷。

具体分解：

同步频率过低：ha-session-sync-frequency = 50ms 导致每秒最多同步 5120 条会话，而高峰期每秒新增约 18000 条，差距 3.5 倍。大量会话在主设备上建立但来不及同步到备设备。
同步通道单线传输：session-sync-dev 仅指定 ha1，没有利用第二条心跳线 ha2 的带宽，浪费了冗余资源。
增量同步机制局限：FortiGate 的会话同步只传递会话建立事件，不传递中间状态变更。即使同步速度够快，长连接在切换后的状态信息（TCP 序列号、窗口等）也是不完整的，可能导致部分连接虽然"存在"但无法继续正常通信。
风扇硬件故障是触发因素：两台风扇同时失效导致主设备过热保护关机，触发非计划切换。但风扇故障只是导火索，真正的爆炸点是长期存在的会话同步瓶颈。
缺乏高峰期验证：前两次计划切换都在凌晨低峰期进行，同步率 98%+ 给了团队"HA 配置没问题"的错误信心。从未在高峰期做过 HA 切换演练。

预防措施

1. HA 配置基线标准化

将上述优化后的 HA 配置纳入 FortiGate 标准配置模板，所有新部署和现有集群统一升级。特别关注三个关键参数：

参数	原值	优化值	说明
ha-session-sync-frequency	50ms	1ms	同步频率最大化
session-sync-dev	ha1	ha1+ha2	双通道冗余
hb-interval	2000ms	500ms	快速故障检测

2. 建立 HA 同步率监控

在 Zabbix 中新增 FortiGate HA 同步率监控项：

# FortiGate SNMP/CLI 获取同步会话数
fnsysctl cat /proc/ha_stats | grep "sessions_synced"

# 对应的 Zabbix Item
# Type: SNMP or External Check
# Key: fortigate.ha.session.sync.rate
# Expression: sessions_synced / active_sessions_total * 100
# Trigger: sync rate < 80% for 5 minutes → P1 alert

同步率低于 80% 立即告警，让运维在切换发生前就知道同步不完整。

3. 定期高峰期 HA 演练

每季度一次，在上班高峰期（上午 9-10 点）执行计划内 HA 切换演练，验证：

会话同步率是否 ≥ 95%
VPN 阧道重建时间是否 ≤ 30 秒
业务恢复时间是否 ≤ 60 秒
监控告警是否正常触发

演练流程：提前通知全员 → 手动触发主备切换 → 记录恢复时间 → 回切并验证。

4. 硬件健康监控

FortiGate 600E 支持通过 SNMP 获取风扇状态和温度：

# Zabbix Item
fgFanStatus[port3]  # 风扇运行状态
fgSysTemperature    # 设备温度
# Trigger: fan failed OR temperature > 50°C → P2 alert

风扇故障能在切换前被发现，避免非计划切换。

5. FortiGate 固件升级

当前版本 FortiOS 7.0.13，7.2 版本改进了 HA 会话同步机制（支持更高效的批量同步和 TCP 状态同步）。计划在下个维护窗口升级到 7.2.6。

6. 文档和 SOP 更新

更新以下运维文档：

FortiGate HA 配置标准模板：包含所有优化参数
HA 故障应急预案：明确切换后 5 分钟内检查同步率、10 分钟内评估业务影响
HA 演练 SOP：季度演练流程和验收标准
硬件巡检清单：增加风扇状态、温度、电源冗余检查项

总结

这次故障让我深刻认识到一个教训：HA 双机热备 ≠ 业务零中断，配置"能跑"不等于配置"可靠"。

两年多来 HA 一直"正常工作"，是因为前两次切换恰好在低峰期，同步瓶颈从未被暴露。当真正的非计划切换发生在高峰期时，11 万条会话只同步了 43%，业务中断 40 分钟。这就像一辆车平时在市区 30km/h 没问题，上了高速才发现刹车不够力。

几个关键教训：

HA 配置必须按高峰期负载设计，同步速率要远大于高峰期会话创建速率，留足余量。
HA 演练必须在高峰期做，低峰期演练只能验证切换流程，不能验证业务连续性。
会话同步率必须纳入持续监控，不能等到切换时才发现同步不完整。
硬件故障（风扇、电源、磁盘）是 HA 切换的最常见触发因素，预防性硬件监控比事后切换恢复更重要。

FortiGate HA 的会话同步是个容易被忽视的配置细节，很多团队只关注 session-pickup enable 是否打开，却忽略了同步频率、同步通道、TCP 状态同步这些影响实际同步效果的关键参数。希望这篇排查记录能帮助同行们重新审视自己的 HA 配置，别等到故障发生才追悔莫及。

一次RADIUS服务器EAP-TLS证书过期导致全公司802.1X认证大规模掉线的排查实录

Tue, 30 Jun 2026 07:00:00 +0000

问题背景

公司办公网采用 802.1X 认证，无线和有线全部走 FreeRADIUS + Microsoft AD CS 颁发的 EAP-TLS 客户端证书，三年前由前同事搭建，当时写了个 openssl 一键生成脚本签了 10 年期的自建 CA，所有终端的根证书、FreeRADIUS 服务器证书、客户端证书全部挂在这棵 CA 下。

2026 年 6 月 28 日上午 9 点 47 分开始，全公司 8 栋办公楼先后出现大规模无线断连和有线认证失败，研发部门、客服中心、工厂车间反馈最为集中。Zabbix 上 AP 的认证成功率从 99.6% 直线掉到 23%，无线控制器每秒钟有 400+ 重新认证请求堆积。我们的 2000+ 员工终端、IoT 设备、IP 电话几乎全部受影响，初步估计单是业务停滞损失每小时就在十万级别。事故发生前一周，刚好有同事反馈"Windows 提示网络证书有问题"，但当时没人在意——这就是典型的预警被忽视引发的连锁反应。

故障现象

9 点 47 分开始，IT 群开始密集弹消息：

【研发2部-工位A12】电脑右下角弹"无法连接到网络 WiFi"
【研发2部-工位A13】重连失败，提示"无法验证服务器身份"
【客服中心】IP电话全部掉线，话机显示注册失败
【6楼车间】扫码枪连不上AP，无法作业
【财务部】连有线网提示"无法完成身份验证"

无线场景：手机和笔记本弹出"无法验证服务器身份 / Unable to verify server identity"，但 SSID 还是能搜到，点击连接后直接失败
有线场景：插了网线的工位弹出黄色感叹号，登录界面反复弹出要求输入域账号但怎么输都通不过
IoT 设备：IP 电话、扫码枪、门禁设备、打印机几乎全部离线

抓包看无线控制器上的 Radius 报文：

[FreeRADIUS log] (5) eap_tls: ERROR: TLS Alert read:fatal:certificate unknown
[FreeRADIUS log] (5) eap_tls: ERROR: TLS_accept: Failed in unknown state
[FreeRADIUS log] (5) eap: ERROR: Failed continuing EAP TLS (13) session
[FreeRADIUS log] (5)     [eap] = reject
[FreeRADIUS log] (5)   [authz] = reject
[FreeRADIUS log] (5) Auth: (5) Login incorrect (eap_tls: Failed to verify certificate):
[FreeRADIUS log] (5) } # server outer-eappeap-inner-tls { ... }

而前一天最后一次成功的认证日志时间戳是 6 月 27 日 23:58:14。问题集中在上午 9 点 47 分之后，所有终端都无法完成 EAP-TLS 握手。

排查过程

第一阶段：现场确认范围

第一反应是 Radius 服务挂了，先用 SSH 登入两台 FreeRADIUS 节点查看服务状态：

# radius01 和 radius02 是 FreeRADIUS 主备集群
ssh radius01 "systemctl status freeradius | head -20"
# ● freeradius.service - FreeRADIUS multi-protocol policy server
#    Active: active (running) since Mon 2024-01-15 14:22:08 CST
# 一切正常

ssh radius01 "radtest test test 127.0.0.1 0 testing123"
# Received Access-Reject
# 嗯,本机 PAP 测试也失败

这个 PAP 测试失败很关键——这意味着不是网络问题、不是设备问题，是 FreeRADIUS 本身拒绝认证。如果 Radius 进程崩溃、配置错误，至少本地 radtest 应该成功。

第二阶段：定位具体错误原因

打开 FreeRADIUS 的详细日志模式：

1
2
3

ssh radius01 "radiusd -X 2>&1 | tee /tmp/radius-debug.log" &
# 模拟一次无线认证
radtest user@corp password 10.1.1.100 0 testing123

详细日志关键片段：

(1) eap_tls: ERROR: SSL says error 10 : certificate has expired
(1) eap_tls: ERROR: TLS Alert write:fatal:certificate expired
(1) eap: ERROR: Failed continuing EAP TLS (13) session
(1)     [eap] = reject

根因锁定：RADIUS 服务器上 EAP-TLS 链路用的证书已经过期。这个证书就是 FreeRADIUS 服务器证书，是当年用自建 CA 签的，签发 10 年有效期，已经在 6 月 28 日 00:00:00 过期。

第三阶段：确认所有关联证书状态

接下来要查清楚：到底过期了哪几张证书，根 CA 有没有一起过期：

ssh radius01 "ls -la /etc/freeradius/certs/"
# total 64
# -rw-r--r-- 1 root root 2151 Jun 15 2024 ca.pem       # CA 根证书
# -rw-r--r-- 1 root root 2200 Jun 15 2024 server.pem   # Radius 服务器证书
# -rw-r--r-- 1 root root 2151 Jun 15 2024 server.crt

# 查看每张证书的过期时间
for cert in /etc/freeradius/certs/{ca,server}.pem; do
  echo "=== $cert ==="
  openssl x509 -in $cert -noout -dates -subject -issuer
done

输出：

=== /etc/freeradius/certs/ca.pem ===
notBefore=Jun 15 14:22:08 2024 GMT
notAfter =Jun 15 14:22:08 2034 GMT        # 根 CA 还有 8 年
subject= /CN=Corp Internal CA
issuer=  /CN=Corp Internal CA            # 自签根

=== /etc/freeradius/certs/server.pem ===
notBefore=Jun 15 14:22:08 2024 GMT
notAfter =Jun 15 14:22:08 2026 GMT        # 昨天 00:00 过期！
subject= /CN=radius.corp.example.com
issuer=  /CN=Corp Internal CA            # 由上面这个 CA 签发

一目了然：根 CA 还在有效期，但服务器证书是 2 年前生成时签了 2 年（前面写的 10 年期是 CA 本身），server.pem 在 6 月 28 日 00:00 过期。我之前对脚本记忆有误，所以忽视了 Server 证书本身的 2 年有效期。

更糟糕的是，这个 server.pem 同时被三处使用：

FreeRADIUS 主配置文件 /etc/freeradius/eap.conf 和 mods-available/eap
FreeRADIUS 的客户端工具（用于向 AD CS 申请证书的 SCEP 接口）
AD CS 上挂的 Web Enrollment / OCSP 服务也用了同一张证书做 SSL 绑定

第四阶段：紧急止血

完全处理需要重新签发服务器证书、推送新的 CA/服务器证书到 2000+ 终端，过程需要数小时。在此之前先用 OpenSSL 临时续签一张短期证书：

# 在 radius01 上生成 CSR，向自建 CA 申请一张 30 天短期证书用于止血
cd /etc/freeradius/certs
openssl req -new -key server.key -out server.csr \
  -subj "/CN=radius.corp.example.com" \
  -addext "subjectAltName=DNS:radius.corp.example.com,DNS:radius01.corp.example.com,IP:10.1.1.100"

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -out server.pem -days 30 \
  -sha256 -extfile <(printf "subjectAltName=DNS:radius.corp.example.com,DNS:radius01.corp.example.com,IP:10.1.1.100")

然后重启 FreeRADIUS：

ssh radius02 "systemctl restart freeradius"
ssh radius01 "systemctl restart freeradius"
# 重新测试
radtest test test 127.0.0.1 0 testing123
# Received Access-Accept

但这只是 FreeRADIUS 这一端，终端上的根 CA 信任链没变——终端有之前手工导入的根 CA，CA 还在有效期，EAP-TLS 客户端对服务器证书的校验会校验 issuer 链 + 过期时间。新签的 30 天证书由同一个 CA 签发，CA 链没变，所以理论上已部署过 CA 根证书的终端不需要重新安装 CA。

可是事实是无线终端还是连不上！继续抓 FreeRADIUS 详细日志：

1
2

(1) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose
(1) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate

新问题！原因是脚本里签证书时没加 extendedKeyUsage=serverAuth 扩展：

# 第一次签发的命令
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -out server.pem -days 30 -sha256
# 没有 extfile 参数

正确的签发方式需要加 EKU 扩展：

cat > /tmp/extfile.cnf <<'EOF'
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:radius.corp.example.com, DNS:radius01.corp.example.com, IP:10.1.1.100
EOF

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -out server.pem -days 30 \
  -sha256 -extfile /tmp/extfile.cnf

再次重启后 FreeRADIUS 正常签出 Received Access-Accept，已信任 CA 根证书的终端陆续恢复。

第五阶段：长期解决 - 自动化证书轮换

30 天临时证书只是续命。要根治，必须做完整的自动化证书轮换：

1. 用 AD CS 替代自建 OpenSSL 签发

# radius01 申请新证书时使用 certreq
$inf = @"
[Version]
Signature = "`$Windows NT`$"
[NewRequest]
Subject = "CN=radius.corp.example.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1  ; Server Authentication
OID = 1.3.6.1.5.5.7.3.2  ; Client Authentication
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns= radius.corp.example.com&"
_continue_ = "dns= radius01.corp.example.com&"
_continue_ = "ipaddress= 10.1.1.100&"
[RequestAttributes]
CertificateTemplate = RadiusServerTemplate
"@
$inf | Out-File -Encoding ASCII C:\radius01.inf
certreq -new C:\radius01.inf C:\radius01.req
certreq -submit C:\radius01.req C:\radius01.cer
certreq -accept C:\radius01.cer

2. 写 cron 自动化续签 + 部署

#!/bin/bash
# /usr/local/sbin/radius-cert-renew.sh
# 每 30 天提前 60 天轮换，确保证书永远不会过 60 天有效期
DAYS_BEFORE_EXPIRY=60
CERT_PATH="/etc/freeradius/certs/server.pem"
THUMBPRINT=$(openssl x509 -in $CERT_PATH -noout -fingerprint -sha256 | cut -d= -f2)
EXPIRY=$(openssl x509 -in $CERT_PATH -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -gt $DAYS_BEFORE_EXPIRY ]; then
  echo "[OK] 证书还有 $DAYS_LEFT 天，无需续签"
  exit 0
fi

echo "[WARN] 证书还有 $DAYS_LEFT 天，开始续签流程"

# 1. 备份旧证书
cp -a $CERT_PATH ${CERT_PATH}.bak-$(date +%Y%m%d)
cp -a /etc/freeradius/certs/server.key /etc/freeradius/certs/server.key.bak-$(date +%Y%m%d)

# 2. 通过 certreq 申请（需要 winexe 调 Windows 端 certreq）
winexe -U corp\\admin%password //radius01 "cmd /c certreq -enroll -machine RadiusServerTemplate" 2>/dev/null
# 把新证书导出到 Linux
smbclient //radius01/c$ -U corp\\admin%password -c "cd \ProgramData\Microsoft\Crypto\RSA\MachineKeys; ls" > /dev/null
# ...省略实际取回流程

# 3. 重启 FreeRADIUS
systemctl restart freeradius

# 4. 验证
sleep 5
radtest test test 127.0.0.1 0 testing123 && echo "[OK] 续签完成并通过测试"

3. 终端侧：使用 SCEP/NDES 自动注册

旧流程是 IT 同事手工给每台电脑装 CA 根证书，效率低且容易漏装。改用 NDES + Intune SCEP：

# Intune SCEP 策略自动向 AD CS 申请客户端证书并推送
# 设备配置 - 配置文件 - SCEP 证书
# 证书类型: 设备
# Subject Name Format: CN={{DeviceId}},CN={{AAD_Device_ID}}
# SAN: URI={{DeviceId}}
# Key Usage: KeyEncipherment, DigitalSignature
# Key Size: 2048
# Hash Algorithm: SHA-2
# Extended Key Usage: 1.3.6.1.5.5.7.3.2  (Client Auth)
# SCEP Server URLs: https://ndes.corp.example.com/certsrv/mscep/mscep.dll

解决方案

最终落地的方案分三层：

止血阶段（T+0 ~ 30 分钟）：在 FreeRADIUS 上用 OpenSSL + 自建 CA 临时签发 30 天带 extendedKeyUsage=serverAuth,clientAuth 和 subjectAltName 的服务器证书，重启服务后约 70% 已部署 CA 根证书的终端自动恢复，剩下 30% 是历史装机从未导入过 CA 的工位机，由现场 IT 同事手工导入。

短期修复（T+1 ~ 2 周）：将 FreeRADIUS 证书切到 AD CS 颁发的 5 年期 RadiusServerTemplate 证书（受 5 年 CA 模板限制），由 certreq 自动续签脚本每 30 天检查并续签，提前 60 天主动轮换，避免再出现凌晨过期无人值守的情况。

长期根治（T+1 ~ 2 月）：

CA 侧：把自建 OpenSSL CA 整个迁移到企业 AD CS，使用 5 年期 SubCA 模板并启用 autoenroll，所有 2000+ 终端通过 GPO 自动注册 RootCA 信任
客户端侧：IoT 设备、扫码枪、IP 电话改为 SCEP 自动注册客户端证书，免去手工导入
监控侧：在 Zabbix 上添加对 /etc/freeradius/certs/*.pem 的扫描，所有证书剩余有效期 < 90 天的都触发告警，证书清单每周发邮件给安全组
流程侧：建立"证书生命周期"维基页面，所有证书的签发日期、到期日期、负责人、轮换 SOP 一目了然，离到期 90/60/30/7 天分别触发不同级别告警

根因分析

深挖下来，这次事故有四个相互独立的根因叠加：

EAP-TLS 服务器证书的有效期被脚本写死成 2 年，而前同事把这个脚本注释为"自建 CA 10 年期"，导致后续接手的人（包括我）误以为整套体系都是 10 年一换
没有任何证书过期监控，Zabbix 监控的是 Radius 服务进程存活、AP 认证成功率，但没人意识到"证书"也是一种需要监控的资源
历史装机太松散，CA 根证书在客户端没有强制 GPO 推送，部分工位机是当年实习生手工装的，证书已经丢/坏，并且这个状态在 AP 重新认证时才暴露
缺乏证书全生命周期管理流程，没有 PKI 文档、没有续签 SOP、没有 SCEP/NDES 这种"证书可以自动过期和续签"的设计，本质上还是手工运维的思路在管理 CA

预防措施

基于这次踩坑，建立了下面这套预防体系：

1. 证书全生命周期管理系统

# 每周日凌晨 3 点扫描所有 Radius/网关证书，邮件给安全组
#!/bin/bash
# /usr/local/sbin/cert-watchdog.sh
RECIPIENT="security-team@corp.example.com"
WARN_DAYS=90
CRITICAL_DAYS=30
CERT_DIRS=("/etc/freeradius/certs" "/etc/nginx/ssl" "/etc/strongswan/ipsec.d")

REPORT=""
for dir in "${CERT_DIRS[@]}"; do
  for cert in $dir/*.pem $dir/*.crt; do
    [ -f "$cert" ] || continue
    EXPIRY=$(openssl x509 -in "$cert" -noout -enddate 2>/dev/null | cut -d= -f2)
    [ -z "$EXPIRY" ] && continue
    DAYS_LEFT=$(( ($(date -d "$EXPIRY" +%s) - $(date +%s)) / 86400 ))
    SUBJECT=$(openssl x509 -in "$cert" -noout -subject | cut -d= -f2-)
    if [ $DAYS_LEFT -lt $CRITICAL_DAYS ]; then
      REPORT+="[CRITICAL] $cert 剩 ${DAYS_LEFT} 天 - $SUBJECT\n"
    elif [ $DAYS_LEFT -lt $WARN_DAYS ]; then
      REPORT+="[WARN] $cert 剩 ${DAYS_LEFT} 天 - $SUBJECT\n"
    fi
  done
done

if [ -n "$REPORT" ]; then
  echo -e "证书过期预警:\n$REPORT" | mail -s "【证书过期预警】$(date +%Y-%m-%d)" $RECIPIENT
fi

2. Zabbix 自定义监控项

# /etc/zabbix/zabbix_agentd.d/cert_expiry.conf
UserParameter=cert.expiry[*],openssl x509 -in $1 -noout -enddate 2>/dev/null | cut -d= -f2 | xargs -I{} date -d "{}" +%s
# 触发器: 当 cert.expiry[/etc/freeradius/certs/server.pem] - now() < 7776000 (90天) 时触发 warning
#          < 2592000 (30天) 时触发 high
#          < 604800 (7天) 时触发 disaster

3. 终端 GPO 强制信任企业 CA

Computer Configuration
  → Policies
    → Windows Settings
      → Security Settings
        → Public Key Policies
          → Certificate Services Client - Auto-Enrollment
            ☑ 自动注册证书
            ☑ 续签过期的证书
            ☑ 更新正在使用的证书

4. SCEP/NDES 自动客户端证书

所有域内电脑和受管移动设备通过 Intune SCEP 自动向 AD CS 申请客户端证书，证书有效期 1 年自动续签，永久不需要 IT 同事手工介入。

5. 红蓝对抗演练

每季度模拟"把 Radius server.pem 替换为已过期证书"，演练运维团队的应急响应速度和流程顺畅度，确保事故响应的肌肉记忆。

总结

这次事故最深的教训，是证书这种"非生命体"资源在大多数运维同学的监控盲区里。它不像磁盘、CPU、内存那样有常规的仪表盘告警，往往只在过期那一刻才"砰"地炸出来，但影响范围却是公司级别的。

回头看，EAP-TLS 体系的设计原则应该是"证书全生命周期"——从 CA 设计、模板、签发、续签、客户端分发、信任链维护到过期监控，每一步都要有自动化兜底。任何依赖"人工记得去续签"的设计，最终都会在某个凌晨、某个长假、某个新人接手的时刻翻车。

我们这次虽然用 30 天临时证书快速止血，没有出现业务数据丢失，但这种"凭证类"的故障本应通过前置的告警 + 自动续签 + 监控来彻底规避。建议所有使用 802.1X / EAP-TLS / HTTPS 证书 / IPsec 证书的团队，都把"证书全生命周期管理"作为年度安全审计的必查项，并且把 Zabbix / Prometheus 对证书过期天数的监控当作 P0 级别来对待——这绝不是"锦上添花"，而是"救命的最后一道防线"。

一次交换机物理环路导致整栋楼广播风暴瘫痪的排查实录

Mon, 29 Jun 2026 07:00:00 +0000

问题背景

某周一上午9:15，正是全员打卡上班的高峰时段，IT服务台电话瞬间被打爆——6楼整层约120台终端全部断网，OA系统、邮件、ERP一律打不开，连本地文件共享都无法访问。与此同时，5楼和7楼也开始零星报障，部分终端时断时续。

这是一栋12层的办公大楼，核心交换机是两台华为S12700做CSS集群，每层楼一台华为S5735-L48T4X-A做接入，上行10G光纤到核心，接入交换机之间没有横向互联。6楼接入交换机是SW-F6-01，负责6楼全部48个信息点。网络拓扑很标准：核心—接入两层架构，按理说不该出现环路。但事实是——6楼瘫痪了，而且速度极快，从第一个报障电话到整层断网，不到3分钟。

紧急程度：P1——整个楼层业务中断。

故障现象

从监控系统和现场排查来看，故障表现非常典型：

1. 终端侧现象

所有6楼终端Ping网关10.6.254.1丢包率95%以上，偶尔通一个包延迟高达2000ms+
DHCP无法获取地址，已有IP的终端ARP表混乱，网关MAC频繁跳变
部分终端右下角网络图标黄色感叹号，提示"未识别的网络"

2. 交换机侧现象

登录SW-F6-01，CPU利用率飙到99%，命令行响应极慢，display cpu-usage需要30秒才返回
display interface brief看到多个端口流量异常：G0/0/1到G0/0/48中有十几个端口出方向流量持续跑到线速（1000Mbps）
display mac-address表项数量从正常的200条暴涨到64000条（MAC表容量上限），且MAC地址在端口之间疯狂漂移
核心交换机CSS集群CPU也达到78%，6楼VLAN对应的VLANIF接口入方向流量达到8Gbps（正常不到200Mbps）

3. 日志关键信息

SW-F6-01上持续刷出以下日志：

%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/5 to GE0/0/22, lasted 2 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/22 to GE0/0/5, lasted 1 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address ffff-ffff-ffff in VLAN 206 has flapped from GE0/0/5 to GE0/0/22

核心交换机日志：

1
2

%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.
%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.

MAC地址在GE0/0/5和GE0/0/22之间反复跳变，且出现了全F的广播MAC漂移——这是典型的二层环路广播风暴特征。

排查过程

第一步：确认故障范围

先通过核心交换机确认故障边界。登录核心CSS集群，查看各VLAN接口流量：

<CORE-SW> display interface Vlanif 206
Vlanif206 current state: UP
Line protocol current state: UP
Description: 6F-Office-VLAN
Input bandwidth utilization: 98%    ← 正常应 <5%
Output bandwidth utilization: 3%
Input: 8234567 packets/sec, 8.2 Gbps
Output: 12345 packets/sec, 12 Mbps

VLAN 206（6楼办公VLAN）入方向流量8.2Gbps，而上行10G链路带宽的80%+都被这些垃圾流量吃掉了。其他楼层VLAN流量正常。

结论：故障范围锁定在6楼VLAN 206，且是二层广播风暴。

第二步：判断环路类型

广播风暴的常见原因有三：物理环路、ARP风暴攻击、蠕虫病毒扩散。通过以下特征快速判断：

特征	物理环路	ARP攻击	蠕虫病毒
MAC漂移	两个端口间高频往复	分散，无规律	分散
广播包占比	>95%	ARP包为主	混合流量
全F广播MAC漂移	有	无	偶尔
流量对称性	两个端口双向跑满	单向为主	不定

SW-F6-01的MAC漂移集中在GE0/0/5和GE0/0/22两个端口之间，且双向流量都跑到线速——典型物理环路特征。

第三步：定位环路端口

在SW-F6-01上执行MAC漂移检测，获取精确的环路端口对：

[SW-F6-01] display mac-address flapping
Flapping VLAN 206:
MAC Address    From/To        Flapping Time
00e0-fc12-3456 GE0/0/5  -> GE0/0/22    2026-06-29 09:17:32
00e0-fc12-3456 GE0/0/22 -> GE0/0/5     2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/5  -> GE0/0/22    2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/22 -> GE0/0/5     2026-06-29 09:17:34

MAC地址只在GE0/0/5和GE0/0/22之间跳变，环路就出在这两个端口之间。

第四步：确认物理连接

通过网管系统查看GE0/0/5和GE0/0/22的端口描述信息：

[SW-F6-01] display interface GE0/0/5
GigabitEthernet0/0/5 current state: UP
Description: 6F-MeetingRoom-A

[SW-F6-01] display interface GE0/0/22
GigabitEthernet0/0/22 current state: UP
Description: 6F-MeetingRoom-A-2

两个端口都连着6楼A会议室。联系行政确认：A会议室有6个信息点，4个墙面面板+2个地插。今天早上8:50有一个供应商来会议室做产品演示，需要联网，自行从地插拉了一根网线插到墙面上——他把同一台交换机下的两个端口用一根网线连了起来。

地插（GE0/0/22）——网线——墙面面板（GE0/0/5），物理环路就这样形成了。

第五步：检查STP状态——为什么环路没有自动阻断？

这是最关键的问题。按照我们的网络标准，所有接入交换机都应该启用MSTP，环路应该被STP自动阻断。查看MSTP状态：

[SW-F6-01] display stp interface GE0/0/5 brief
Port           Role   State
GE0/0/5        -      -

[SW-F6-01] display stp interface GE0/0/22 brief
Port           Role   State
GE0/0/22       -      -

端口STP角色显示为空——说明STP根本没在这两个端口上生效。进一步检查全局MSTP配置：

1
2

[SW-F6-01] display stp global
MSTP is disabled globally.

MSTP全局未启用！ 这才是问题的根源——去年6楼交换机因硬件故障更换，新交换机上线时是用的初始配置模板，模板里漏掉了stp enable全局命令。虽然端口下有stp edged-port enable的配置，但全局STP未开启，端口级的STP配置等于白搭。

第六步：紧急止血

必须立即打断环路。有两种方案：

方案A：直接shutdown环路端口——风险低，见效最快 方案B：全局启用STP——在广播风暴期间启用STP，STP报文可能被淹没在风暴中无法正常收发，收敛时间不可控

选择方案A，先shutdown再处理根因：

[SW-F6-01] interface GE0/0/5
[SW-F6-01-GE0/0/5] shutdown
[SW-F6-01-GE0/0/5] quit
[SW-F6-01] interface GE0/0/22
[SW-F6-01-GE0/0/22] shutdown
[SW-F6-01-GE0/0/22] quit

Shutdown后10秒，CPU从99%降到12%，MAC表项从64000条降到180条，6楼网络在30秒内完全恢复。

解决方案

1. 紧急恢复（已完成）

shutdown环路端口，网络恢复正常。通知会议室供应商正确使用单口连接。

2. 根治——全局启用MSTP

在SW-F6-01上启用MSTP并配置最佳实践参数：

# 全局启用MSTP
[SW-F6-01] stp mode mstp
[SW-F6-01] stp enable

# 配置MSTP域（与核心交换机保持一致）
[SW-F6-01] stp region-configuration
[SW-F6-01-mst-region] region-name HQ-OFFICE
[SW-F6-01-mst-region] revision-level 1
[SW-F6-01-mst-region] instance 1 vlan 201 to 210
[SW-F6-01-mst-region] active region-configuration
[SW-F6-01-mst-region] quit

# 核心交换机作为根桥
[SW-F6-01] stp instance 0 root secondary
[SW-F6-01] stp instance 1 root secondary

# 优化STP收敛参数
[SW-F6-01] stp timer hello 2
[SW-F6-01] stp timer forward-delay 15
[SW-F6-01] stp timer max-age 20

3. 接入端口安全加固

对所有接入端口启用BPDU Guard和边缘端口，防止终端侧引入环路：

# 批量配置接入端口
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] stp edged-port enable
[SW-F6-01-port-group] stp bpdu-protection enable
[SW-F6-01-port-group] quit

# 上行端口保持默认STP参与（不设为边缘端口）
[SW-F6-01] interface XGE0/0/1
[SW-F6-01-XGE0/0/1] undo stp edged-port
[SW-F6-01-XGE0/0/1] quit

BPDU Guard的作用：如果有人在边缘端口上接入了一台交换机（发了BPDU），端口会立即err-down，阻断环路产生。这是防止终端侧环路的最有效手段。

4. 开启环路检测（Loop Detection）作为双保险

即使STP启用，也配置环路检测作为补充防护：

[SW-F6-01] loop-detect enable
[SW-F6-01] loop-detect interval 5
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] loop-detect action shutdown
[SW-F6-01-port-group] quit

5. 全网排查STP状态

对全部12台接入交换机逐一检查MSTP是否全局启用：

1
2

# 在每台接入交换机上执行
display stp global

发现除了SW-F6-01，SW-F9-01和SW-F11-01也是MSTP全局关闭的——这两台也是去年硬件更换时遗漏的。立即补上相同的MSTP配置。

根因分析

这次故障的根本原因是双重防护缺失：

1. 直接原因：会议室供应商用一根网线连接了同一台交换机下的两个接入端口，形成物理环路，触发广播风暴。

2. 根本原因：SW-F6-01（以及SW-F9-01、SW-F11-01）的MSTP协议全局未启用。去年这三台交换机因硬件故障更换，上线时使用的初始配置模板遗漏了stp enable全局命令。虽然端口下配置了stp edged-port enable，但在全局STP关闭的情况下，端口级STP配置不会生效，等于形同虚设。

3. 管理原因：交换机上线缺少配置合规检查流程。新设备上线后只有Ping通网关的连通性验证，没有协议级检查（如STP状态、LLDP邻居、端口安全策略等），导致配置遗漏长期潜伏。

预防措施

1. 配置基线检查自动化

编写Python脚本，通过NETCONF/SSH批量巡检所有接入交换机的关键配置项，纳入每日自动巡检：

#!/usr/bin/env python3
"""接入交换机配置基线巡检脚本"""
import paramiko
import csv

CHECK_LIST = [
    ("STP全局状态", "display stp global", "MSTP is enabled"),
    ("Loop Detection", "display loop-detect", "Loop detect is enabled"),
    ("NTP同步状态", "display ntp-service status", "clock is synchronized"),
    ("SSH版本", "display ssh server status", "SSH version : 2.0"),
    ("SNMPv3", "display snmp-agent group", "v3"),
]

def check_switch(host, username, password):
    results = []
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(host, username=username, password=password)
    for name, cmd, expected in CHECK_LIST:
        stdin, stdout, stderr = ssh.exec_command(cmd)
        output = stdout.read().decode()
        ok = expected in output
        results.append((name, "PASS" if ok else "FAIL"))
    ssh.close()
    return results

# 批量巡检并输出报告...

将巡检结果接入企业微信告警，任何一台交换机的STP状态变为disabled，5分钟内通知网络组。

2. 交换机上线SOP完善

新增交换机上线检查清单中的必检项：

检查项	命令	期望结果
MSTP全局启用	`display stp global`	MSTP is enabled
MSTP域配置	`display stp region-configuration`	Region与核心一致
BPDU Guard	`display stp bpdu-protection`	至少48个边缘端口启用
环路检测	`display loop-detect`	Loop detect is enabled
端口安全	`display port-security`	已配置

上线后必须由第二人复核并签字确认。

3. 会议室信息点管理

会议室信息点在面板上标注编号，与交换机端口一一对应
地插面板贴上醒目标签：“请勿将网线连接两个网络面板”
非IT人员需要联网时，统一联系IT前台，由IT人员协助接线
对会议室端口启用端口安全（限制MAC地址数量为2个），减少环路风险

4. 网络监控增强

在Zabbix中新增以下监控项：

接入交换机CPU利用率 >70% 触发告警
接入交换机MAC表项数量超过阈值的80%触发告警
单端口出方向流量持续超过800Mbps超过30秒触发告警
STP拓扑变更通知（TCN）次数监控，单台交换机5分钟内超过3次触发告警

总结

这次故障的教训非常深刻：防护机制配置了不等于生效了。端口下写了stp edged-port enable，但全局STP没开，等于白搭。就像买了保险但没激活保单，出事了才发现根本赔不了。

网络运维中，以下几点值得铭记：

全局开关优先于端口配置——STP、DHCP Snooping、环路检测等功能都有全局开关，配置时一定要先确认全局是否启用。这不仅是华为设备的特点，思科、H3C、锐捷等厂商也是同样的逻辑。
配置合规检查要自动化——人工检查永远有遗漏，尤其是批量设备上线的时候。脚本巡检+告警推送，才是可靠的保障。
物理环路是最暴力的故障——一个简单的双头插线操作，就能在几秒内让一台48口交换机的CPU跑到100%，MAC表打满，三层设备也跟着遭殃。二层环路的影响范围和扩散速度远超大多数网络故障，必须把STP当成本命技能来维护。
BPDU Guard是终端接入的最后一道防线——接入端口设为边缘端口+BPDU Guard，一旦有终端侧设备发BPDU就自动err-down，简单粗暴但极其有效。

最终，从故障发生到网络恢复，用时约18分钟。其中5分钟是确认故障范围，3分钟是定位环路端口，2分钟是检查STP状态，1分钟shutdown止血。如果STP正常启用，这个环路从产生到被自动阻断只需要几秒钟，用户甚至不会感知到——这才是网络协议应有的价值。

排查工具备忘：display mac-address flapping、display stp global、display cpu-usage、display interface brief是二层环路排查的四件套，建议熟记。

一次IPSec VPN隧道因MTU不匹配导致ERP系统远程访问异常的排查实录

Fri, 26 Jun 2026 07:00:00 +0000

问题背景

公司在全国有8个分支机构，均通过FortiGate防火墙与总部建立IPSec VPN隧道，日常办公依赖总部的SAP ERP系统进行订单录入、库存查询和财务审批。周一上午9点，华南分公司的30多名员工集中登录ERP系统时，纷纷反馈页面加载极慢——登录界面要等2-3分钟才能显示，进入后点击菜单经常卡死超时，只能反复刷新碰运气。

奇怪的是，Ping总部的服务器完全正常，延迟稳定在15ms左右，traceroute也每一跳都通畅。其他通过VPN访问的服务（如邮件OA）虽然也有点慢，但不像ERP这样完全不可用。网络监控平台上VPN隧道状态显示绿灯"Connected"，流量统计正常，没有任何告警。问题持续了整个上午，严重影响了华南分公司的业务运转，紧急程度极高——财务月结审批被迫延迟，客户订单无法及时录入。

故障现象

故障的表现非常"诡异"，具有典型的MTU问题特征——小包通、大包不通：

现象一：Ping正常但ERP不可用

从华南分公司Ping总部ERP服务器10.10.1.100，100字节的小包100%成功，延迟15ms；但当Ping包大小超过1400字节时：

C:\Users\zhao> ping 10.10.1.100 -l 100 -n 10
Reply from 10.10.1.100: bytes=100 time=15ms TTL=62

C:\Users\zhao> ping 10.10.1.100 -l 1500 -n 10
Request timed out.
Request timed out.
Ping statistics for 10.10.1.100:
    Packets: Sent = 10, Received = 0, Lost = 10 (100% loss)

现象二：ERP登录页面加载极慢或超时

浏览器访问https://erp.company.com时，登录页的HTML框架能加载出来（小数据包），但包含CSS/JS资源的大响应体经常卡在"传输中"状态，最终浏览器报ERR_CONNECTION_TIMED_OUT。

现象三：SSH大文件传输失败

通过SSH从华南服务器向总部scp一个50MB的备份文件，传输开始后几秒就卡死：

1
2
3

$ scp backup.tar.gz admin@10.10.1.50:/tmp/
backup.tar.gz                                    0%    0KB   --:-- ETA
# 卡住不动，最终Connection reset by peer

但小文件（几KB的配置文件）可以正常传输。

现象四：TCP连接建立正常但数据传输中断

用Wireshark在华南分公司的客户端抓包，可以看到TCP三次握手顺利完成，客户端发送HTTP GET请求后，服务器回复了第一个数据包（SYN+ACK后的初始窗口），但当服务器连续发送多个满载（满1460字节）的TCP段时，客户端迟迟收不到后续数据，最终触发TCP重传，重传若干次后连接被reset。

关键发现：抓包中看不到任何ICMP Fragmentation Needed消息，说明IP分片所需的通知被某处拦截了。

排查过程

第一步：确认问题范围——是否只影响华南分公司

第一时间联系其他7个分支，发现华东分公司（同样通过IPSec VPN接入）也反馈ERP访问缓慢，但华北分公司（通过专线接入，不走VPN）完全没有问题。这个对比非常关键——专线正常、VPN异常，问题锁定在VPN隧道层面。

第二步：排除ERP服务器本身的问题

直接在总部内网访问ERP服务器，响应迅速，没有任何异常。检查ERP服务器的系统负载、数据库连接池、Web服务器线程池，全部在正常范围内。确认问题不在服务器端。

第三步：排除VPN隧道连通性问题

VPN隧道状态在FortiGate监控面板上显示为绿色"Up"，路由表正确，Ping小包100%通过。初步排除隧道本身断裂的可能。但注意到隧道接口的MTU配置——FortiGate上VPN隧道接口默认MTU值：

# 总部 FortiGate (FGT-HQ)
FGT-HQ # diagnose netlink interface list vpn-tunnel-HN
Name: vpn-tunnel-HN
  MTU: 1436
  Type: IPSec
  Status: up

# 华南 FortiGate (FGT-HN)
FGT-HN # diagnose netlink interface list vpn-tunnel-HQ
Name: vpn-tunnel-HQ
  MTU: 1436
  Type: IPSec
  Status: up

隧道MTU为1436，这是因为IPSec ESP封装会占用额外头部空间（ESP头8字节 + ESP尾2字节 + ICV 12字节 + 外层IP头20字节 = 42字节，1500-42=1458…但实际FortiGate的默认值是1436，预留了更多空间给可能的UDP封装和NAT-T）。隧道MTU本身看起来没有异常。

第四步：用路径MTU探测定位关键问题

使用Linux的tracepath命令进行路径MTU探测：

# 从华南Linux服务器探测到总部ERP
$ tracepath 10.10.1.100
1?: [LOCAL] 10.20.1.10                          mtu=1500
2:  10.20.1.1 (华南FG内网口)                      mtu=1500
3:  no reply
4:  10.10.1.1 (总部FG内网口)                      mtu=1436  ← 链路MTU突降!
5:  10.10.1.100 (ERP服务器)                       mtu=1436

关键发现：数据包经过VPN隧道后，路径MTU从1500降到了1436。这意味着从ERP服务器发往华南客户端的TCP数据包如果满载1460字节，在经过VPN隧道时会被封装成超过1500字节的IP包，需要分片。

第五步：检查TCP MSS协商

查看FortiGate防火墙的TCP MSS配置：

# 华南 FortiGate
FGT-HN # show full-configuration | grep -i mss
    set tcp-mss-sender 0
    set tcp-mss-receiver 0
    # 隧道接口未配置MSS协商

MSS值为0表示"未设置"——FortiGate不会在TCP SYN/SYN-ACK中主动修改MSS值。这意味着TCP连接建立时，ERP服务器（在1500 MTU的内网环境中）会在SYN-ACK中通告MSS=1460（MTU 1500 - 40字节IP+TCP头），华南客户端同理也在SYN中通告MSS=1460。

这就是问题所在：双方协商的MSS=1460，但数据实际要经过MTU=1436的VPN隧道。ERP服务器按MSS=1460发送满载TCP段，封装后IP包总长 = 1460 + 40(IP头) + 42(IPSec封装) = 1542字节，超过了出接口MTU 1500！这要么需要IP分片，要么被丢弃。

第六步：验证——为什么Ping小包通但大包不通

ICMP Echo Request小包（100字节）加上IPSec封装后仍远小于1500，无需分片，顺利通过。但1500字节的Ping包（IP层已达1500）加上IPSec封装后变成1542字节，超过了物理接口MTU，需要分片。

第七步：为什么没有ICMP Fragmentation Needed反馈

正常情况下，当路由器发现出接口MTU不足以转发不分片的包，且包的DF(Don’t Fragment)位为1时，应该返回ICMP Type 3 Code 4（Fragmentation Needed and DF Set）消息，通知发送方降低包大小。但我们在抓包中完全没看到这类ICMP消息！

进一步排查发现两个原因：

FortiGate的IPS策略拦截了ICMP Fragmentation Needed消息——查看IPS Sensor配置，发现有一条默认规则ICMP.DOS.FRGNeeded将其标记为"Drop"，这是误将路径MTU发现的必要ICMP消息当作DOS攻击了。
ERP服务器的Linux内核默认在TCP包中设置DF位——Linux的net.ipv4.tcp_df默认行为倾向于设置DF位以避免分片带来的性能损失。当DF=1的TCP包在VPN封装后超MTU且被FortiGate丢弃时，本应返回ICMP Fragmentation Needed，但被IPS拦截了。

双重打击：服务器设置了DF位禁止分片 → FortiGate需要返回ICMP通知 → IPS策略把ICMP通知拦截了 → 服务器永远不知道自己发的包太大 → 只能不断重传同样大小的包 → 连接卡死。

第八步：确认根因链路

完整的因果链路：

IPSec隧道封装增加42字节开销 → 隀道MTU从1500降到1436
TCP MSS协商未适配隧道MTU → 双方协商MSS=1460（应为1396）
ERP服务器按MSS=1460发送满载TCP段 → IPSec封装后超物理接口MTU
TCP包DF位=1 → 不能分片，由FortiGate丢弃
FortiGate IPS策略拦截ICMP Fragmentation Needed → 发送方收不到PMTU通知
服务器不断重传超大的TCP段 → 连接永远无法完成数据传输
小包（<1436-40=1396字节）不受影响 → Ping小包正常、ERP小响应体能加载

解决方案

紧急止血（5分钟内生效）

方案一：在FortiGate隧道接口上启用TCP MSS协商

这是最标准的修复方式，在VPN隧道接口上设置MSS Sender和MSS Receiver值，让FortiGate在TCP SYN/SYN-ACK经过隧道时自动修改MSS值，将其限制在隧道MTU允许的范围内：

# 华南 FortiGate
config system interface
    edit "vpn-tunnel-HQ"
        set tcp-mss-sender 1396
        set tcp-mss-receiver 1396
    next
end

# 总部 FortiGate
config system interface
    edit "vpn-tunnel-HN"
        set tcp-mss-sender 1396
        set tcp-mss-receiver 1396
    next
end

MSS值计算：隧道MTU 1436 - 40(IP头+TCP头) = 1396。设置后，FortiGate会在TCP SYN经过隧道接口时将MSS Option从1460修改为1396，确保双方协商出的最大段大小不超过隧道承载能力。

修改后立即生效，无需重启隧道，已有连接会在下次TCP握手时使用新MSS值。

方案二：释放IPS对ICMP Fragmentation Needed的拦截

同时修复IPS策略，放行必要的PMTU Discovery ICMP消息：

# 总部 FortiGate IPS Sensor配置
config firewall ips-policy
    edit "default-ips"
        config rule
            edit 1
                set name "allow-pmtu-icmp"
                set signature "ICMP.DOS.FRGNeeded"
                set status disable
                set log enable
                set action pass
            next
        end
    next
end

将ICMP.DOS.FRGNeeded规则从Drop改为Pass，确保路径MTU发现的ICMP消息能正常传递。这是TCP PMTU Discovery机制正常工作的必要条件。

验证修复效果

修改后从华南分公司测试：

# Ping大包测试
C:\Users\zhao> ping 10.10.1.100 -l 1500 -n 10
Reply from 10.10.1.100: bytes=1500 time=16ms TTL=62
Reply from 10.10.1.100: bytes=1500 time=16ms TTL=62
# 100%成功！

# ERP访问测试——登录页面3秒内完整加载，菜单点击秒级响应

# SCP大文件传输测试
$ scp backup.tar.gz admin@10.10.1.50:/tmp/
backup.tar.gz                                   100%   50MB  12.8MB/s   00:03
# 正常完成！

全量修复——所有分支机构VPN隧道

紧急修复华南后，立即对所有8个分支的VPN隧道接口统一配置MSS：

# 批量配置脚本（总部侧）
for tunnel in vpn-tunnel-HN vpn-tunnel-HD vpn-tunnel-HB vpn-tunnel-HX vpn-tunnel-HW vpn-tunnel-HN2 vpn-tunnel-HS vpn-tunnel-HNE; do
    config system interface
        edit "$tunnel"
            set tcp-mss-sender 1396
            set tcp-mss-receiver 1396
        next
    end
done

并在每台分支FortiGate上同样配置对应的隧道接口。

根因分析

问题的根本原因是 IPSec VPN隧道的MTU开销未被TCP层感知和适配，叠加 IPS策略误杀PMTU Discovery的ICMP消息，形成了"黑盒"效应：

核心根因一：TCP MSS未适配隧道MTU

IPSec ESP封装会在原始IP包外增加约42字节的头部开销，导致物理链路上可承载的有效载荷从1500字节降到约1458字节（考虑NAT-T UDP封装则更低）。但TCP层在握手时协商的MSS是基于直连网段MTU 1500计算得出的1460，完全不知道中间有一个MTU更低的隧道。FortiGate的隧道接口默认未开启MSS协商修改功能（tcp-mss-sender/receiver=0），导致这个信息鸿沟无法自动弥合。

核心根因二：IPS拦截ICMP Fragmentation Needed阻断PMTU发现

RFC 1191定义的Path MTU Discovery机制本应作为MSS协商的后备方案——当TCP包因DF位无法分片而被中间路由器丢弃时，路由器应返回ICMP Type 3 Code 4消息通知发送方降低包大小。但FortiGate的IPS默认规则将此类ICMP消息标记为潜在DOS攻击并丢弃，使得PMTU Discovery机制完全失效。

两个根因叠加：TCP不知道隧道MTU限制（MSS过大），又无法通过ICMP得知自己发的包太大（PMTU Discovery被阻断），导致发送方陷入"盲重传"的死循环。

预防措施

1. 标准化VPN隧道TCP MSS配置

制定VPN隧道配置标准，所有新建隧道接口必须设置MSS值：

# FortiGate VPN隧道MSS配置标准
tcp-mss-sender = 隧道MTU - 40
tcp-mss-receiver = 隧道MTU - 40
# 常见值：
#   IPSec ESP (无NAT-T)：MTU=1458 → MSS=1418
#   IPSec ESP (NAT-T/UDP封装)：MTU=1436 → MSS=1396

将此标准纳入VPN隧道配置Checklist，新建或修改隧道时强制执行。

2. IPS策略优化——放行PMTU Discovery ICMP

在所有FortiGate的IPS Sensor中，将以下ICMP规则从默认的Drop改为Pass或至少Disable：

ICMP.DOS.FRGNeeded (Type 3 Code 4 - Fragmentation Needed)
ICMP.Info.SourceQuench (Type 4 - Source Quench，虽已废弃但部分设备仍使用)

这些ICMP消息是IP网络正常运行的必要组成部分，误杀它们会导致PMTU Discovery失效，远比所谓的DOS风险危害更大。

3. 定期路径MTU探测巡检

编写自动化巡检脚本，每周对所有VPN隧道执行路径MTU探测：

#!/bin/bash
# pmtu_check.sh - VPN隧道路径MTU巡检
BRANCHES=("10.20.1.0/24 华南" "10.30.1.0/24 华东" ...)
HQ_ERP="10.10.1.100"
ALERT_THRESHOLD=1400

for branch in "${BRANCHES[@]}"; do
    network=$(echo $branch | awk '{print $1}')
    name=$(echo $branch | awk '{print $2}')
    gw=$(echo $network | sed 's/0\/24/1/')
    
    # 从分支网关探测路径MTU
    pmtu=$(tracepath -n $HQ_ERP 2>&1 | grep "pmtu" | tail -1 | awk '{print $NF}')
    
    if [ "$pmtu" -lt "$ALERT_THRESHOLD" ]; then
        echo "[ALERT] $name 隧道路径MTU异常: $pmtu (期望 >= $ALERT_THRESHOLD)"
    else
        echo "[OK] $name 隧道路径MTU正常: $pmtu"
    fi
done

当路径MTU低于阈值时自动告警，防止MSS配置被意外修改或隧道MTU因封装方式变化而降低。

4. 网络变更流程纳入MTU审查

在FortiGate配置变更审批流程中加入MTU/MSS审查环节：

新增VPN隧道 → 必须检查MSS配置
更改IPSec封装方式（如从ESP改为ESP+UDP封装）→ 重新计算MSS值
修改IPS策略 → 检查是否影响PMTU Discovery ICMP放行
更换ISP或链路类型 → 测试路径MTU是否变化

5. 文档化MTU计算方法

编写内部网络运维手册中的MTU计算章节，记录所有VPN隧道的：

隧道名称	封装方式	预留开销	隧道MTU	MSS值	物理接口MTU
vpn-HN	ESP+NAT-T	64字节	1436	1396	1500
vpn-HD	ESP	42字节	1458	1418	1500

让每位运维工程师都能快速查阅和计算正确的MSS值。

总结

这次故障的排查给我留下了深刻的教训：

教训一：Ping通不代表网络通。 Ping只是ICMP小包测试，它能证明链路可达，但完全不能证明大包传输能力。在涉及VPN隧道的故障排查中，必须用不同大小的Ping包（ping -l 1500）或tracepath进行路径MTU探测，才能发现隐藏的MTU问题。

教训二：MTU/MSS不匹配是VPN环境的"经典杀手"。 IPSec封装带来的MTU缩减是必然的、可计算的，但TCP层对此毫不知情。如果不主动在隧道接口配置MSS协商修改，就等于让TCP盲目发送超大数据包，轻则分片降速，重则完全卡死。这是VPN运维的基本功课，不能等出事了才补。

教训三：IPS策略不能一刀切地拦截ICMP。 安全策略的"拦截一切ICMP"看似防御了ICMP-based DOS攻击，实则破坏了PMTU Discovery这一网络基础机制。安全与可用必须平衡，对于RFC定义的必要ICMP消息（Fragmentation Needed、Time Exceeded等），必须放行。

教训四：故障排查要善于利用"小包通、大包不通"这个特征。 当你发现小请求能成功但大数据传输失败，或者Ping通但应用不通，第一反应就应该是检查MTU/MSS。这个特征太过典型，不必浪费时间去查服务器性能、应用日志、路由表——直接从MTU入手往往能最快定位。

最终，一个1436的隧道MTU和未设置的MSS参数，加上一条过于激进的IPS规则，三者合力制造了一个"Ping正常但业务瘫痪"的经典假象。修复只需两行配置，但理解它需要整个IP/TCP栈的知识。运维不只是改配置，更是理解协议。

一次BGP双线接入因AS-PATH策略错误导致业务流量全部走错运营商的排查实录

Tue, 23 Jun 2026 06:55:12 +0000

问题背景

总部机房采用"电信+联通"双线BGP接入架构，核心交换机与两家运营商建立eBGP邻居，通过AS-PATH属性和route-map实现流量调度——默认走电信、联通作为备份，特定网段走联通做负载。某周一下午14:30左右，研发同事反映访问部署在阿里云华东节点的多个API接口（用户中心、订单查询、支付回调）出现持续性卡顿，单次请求从正常的80ms飙升到500ms以上，短信网关、第三方支付回调更是出现间歇性超时。客服部门同步反馈多名用户投诉"支付完成但订单状态未更新"。

故障现象

通过Zabbix监控看到关键业务指标异常：

14:32:01  Gateway-IP-Monitor  WARN  核心交换机到阿里云华东(47.110.x.x)延迟 412ms (基线 35ms)
14:32:01  BGP-Session-Monitor  INFO  eBGP 电信邻居 10.10.1.1 Established  (Up 87d 4h)
14:32:01  BGP-Session-Monitor  INFO  eBGP 联通邻居 10.10.2.1 Established  (Up 87d 4h)
14:32:15  Zabbix-Trapper        CRIT  HTTP 业务探测 api.example.com 5xx 告警 (连续3次)
14:32:30  Zabbix-Trapper        CRIT  支付回调响应时间 > 5s (SLA违约)

在核心交换机上查看路由表：

<Switch> display bgp routing-table ipv4 unicast brief
Total Number of Routes: 412,387
Network            NextHop        MED     LocPrf  PrefVal  Path/Ogn

*  47.110.0.0/16     10.10.2.1      0       100     0        4134  ?
*  47.110.0.0/16     10.10.1.1      0       100     0        4134 100 200 ?

诡异的事情出现了：阿里云华东段（47.110.0.0/16）的两条路由都被打上了"无效标记"（问号?），其中电信链路（AS4134 → AS100 → AS200）多了一段莫名其妙的AS-PATH"100 200"，而正常情况下电信学到该网段的AS-PATH应该只显示"4134"或"4134 100"。

排查过程

第一步：确认BGP邻居状态正常

两条eBGP邻居均显示Established，消息收发计数没有异常抖动，说明TCP连接、Keepalive、BGP Open报文一切正常，问题出在路由策略层。

第二步：检查入方向route-map

display current-configuration | include route-map 找到关键策略段：

route-map FROM-TELECOM-IN permit 10
 description Accept legitimate telecom routes
 match as-path 10
!
route-map FROM-TELECOM-IN deny 20
 description Reject transit routes
 match as-path 20
!
ip as-path 10 permit ^(4134_)+$
ip as-path 20 permit _100_200_

看到as-path 20那行瞬间明白问题所在——正则_100_200_会匹配任何包含"100 200"两个相邻AS的路径，包括电信运营商内部传递过来的真实路由。当时我们调度的逻辑是"拒绝任何包含私有AS号100、200的路径"，但忘记了一个事实：电信骨干网在传递某些跨网段路由时，会在AS-PATH中插入"100 200"作为内部标记（这是中国电信AS4134的私有AS号，用于内部选路标记）。

第三步：验证猜想

在核心交换机上抓取近期BGP Update报文，过滤AS-PATH含"100 200"的路由前缀数量：

1
2
3

<Switch> display bgp update-peer-group 10.10.1.1 statistics
...
Prefix count with AS-PATH matched _100_200_: 287,341

近30万条合法路由被这条正则误杀，全部进了BGP RIB-in的"待丢弃"队列，对端却还以为邻居都正常、路由都通告了。

第四步：检查本地注入的BGP路由

为防止出现路由黑洞，运维A同事把核心交换机的LoopBack0（10.255.0.1/32）通过network命令注入BGP，这条命令的下一跳指向10.10.1.1（电信），触发了一段被错误拒绝的AS-PATH。

<Switch> display bgp routing-table 10.255.0.1
BGP local router ID is 10.255.0.1
Status codes: * - valid, > - best, d - damped, h - history,
              s - suppressed, S - stale, i - internal, b - backup
Origin: i - IGP, e - EGP, ? - incomplete

Total Number of Routes: 0

连自己的LoopBack都没被优选——所有从电信学到的路由都被route-map打上"无效"标记，对端联通的路由因为local-preference默认100而进入主表，但很多明细网段联通链路延迟本来就高，导致从核心出去的流量"全跑联通"。

第五步：与运营商侧核对

拨通电信大客户经理电话，对方工程师确认他们在上周末升级了AS4134的出口策略，会在AS-PATH中插入"100 200"作为新引入的BGP选路标记。也就是说不止我们这端，所有走电信BGP接入的企业客户都受到了影响——只是我们这条正则写得太严格。

第六步：临时止血

先把误杀的AS-PATH正则屏蔽掉，恢复路由：

`1`	`no ip as-path 20`

60秒后，路由表刷新，47.110.0.0/16的两条路由恢复正常选路，业务延迟从412ms回到35ms基线。

解决方案

长期方案：改用AS-PATH长度作为判定标准

“100 200"只是运营商内部标记，不能简单粗暴作为业务流的甄别依据。改为基于AS-PATH长度做拒绝：

1
2
3

ip as-path 10 permit ^(4134_)+$
ip as-path 20 permit _(6451[2-9]|6553[0-5])_
ip as-path 30 permit ^[0-9]+$  ! 只允许单一AS的路由（对端直连段）

只拒绝真正属于RFC 6996保留私有AS号的路径，避免误伤。

给route-map加日志计数

route-map FROM-TELECOM-IN deny 20
 description Reject private AS
 match as-path 20
 set traffic-index 99

配合流量监控，一旦被拒绝的路由条目激增立即告警。

增加BGP邻居级监控

在Zabbix上对每个BGP邻居的关键指标做模板化：

指标	告警阈值
收到的BGP路由前缀数	±20% baseline
AS-PATH 拒绝计数	> 0
Update 报文频率	> 1000/分钟
BGP邻居翻动次数	> 0/小时

关键配置变更走代码评审

这条ip as-path 20 permit _100_200_是去年一个临时调试遗留的命令，没有走严格的code review，从那之后就一直在线上跑了——是典型的"运行久了就以为是正确的"陷阱。

根因分析

直接原因：去年临时调试写的ip as-path 20 permit _100_200_正则没有清理，该正则的本意是拒绝经过某些对等AS的路由，但因为AS-PATH正则下划线表示"任意字符串边界”，_100_200_实际匹配的是"含100和200这两个相邻AS号的所有路径"。

深层原因：电信AS4134骨干网升级后，在跨网传递路由时会在AS-PATH中追加"100 200"作为内部标记，这本来是合法的BGP属性，但与我们的策略冲突，导致近30万条路由被误判无效。

运营原因：路由策略类变更缺乏变更评审、回归测试、监控告警机制，“上线即正确"的惯性思维让这条命令在线上跑了8个多月，直到电信骨干网升级才暴露出问题。

预防措施

1. 路由策略变更必须走变更窗口

所有涉及route-map、ip as-path、ip community-list、ip prefix-list的变更，必须在业务低峰期执行，且必须经过至少一名网络架构师评审，并保留前后配置对比。

2. 部署"路由沙盒”

搭建一个隔离的BGP测试环境，使用Bird或FRRouting跑一个真实环境的镜像，配置变更先在沙盒里跑24小时观察，再上生产。

3. 完善BGP监控体系

每分钟采集BGP邻居的Received/Active Routes数量
对AS-PATH regex匹配做计数器
任何route-map的deny规则都应配WELF/Syslog上报

4. 与运营商建立常态化沟通机制

每次运营商侧骨干网升级、AS号调整、出口策略变化，都应在第一时间拿到变更通知单，评估对自有路由策略的影响。

5. 路由策略配置文件纳入Git管理

把核心交换机的配置按以下目录结构纳入Git：

network-config/
├── core-sw-01/
│   ├── bgp.conf
│   ├── route-map.conf
│   └── changelog.md
├── core-sw-02/
└── README.md

每次配置变更都走commit-msg规范，“为什么要这样配"的业务背景要写在commit信息里，避免半年后回看一脸懵。

总结

这次故障给我们最深的教训是：网络策略的"误拒绝"比"误允许"更隐蔽。误允许会立刻有告警（被拒绝的路由完全消失、流量中断），而误拒绝会让路由"看起来还在”（实际被打上无效标记），却悄悄把流量引到错误的路径上，影响业务却难以第一时间定位。

后续我们把"路由策略变更必须配监控"写进了运维SOP：任何新增的deny规则、任何修改的正则表达式、任何调整的local-preference，都必须配套一条监控项，且这条监控的告警接收人是这次变更的提交人本人——谁改的，谁兜底。

BGP是互联网的"神经系统"，容不得半点马虎。

一次FortiGate防火墙策略配置错误导致内网DNS解析失败的排查实录

Fri, 15 Aug 2025 20:00:00 +0000

一、问题背景

2026年5月中旬，公司新收购的一家分公司完成网络改造，核心交换机升级为华为S7706，出口防火墙替换为FortiGate 100F，由我负责整体网络运维支持。改造完成后前三天网络运行正常，但从第四天开始，陆续有员工反映"网页打开很慢"、“有些网站完全打不开”、“微信能发消息但图片加载很慢”。

由于分公司没有专职网络工程师，问题上报到总部后由我远程协助排查。初期怀疑是ISP链路问题，联系运营商测速后确认出口带宽正常，100M专线上下行均达标，问题指向内网。

影响范围逐渐扩大，到第二天已有约40%的员工反映网络异常，部分关键业务系统（如ERP、OA）访问也出现间歇性超时，情况比较紧急。

二、故障现象

通过远程桌面连接到分公司的一台运维跳板机，我进行了以下几项基础测试，汇总故障现象如下：

1. 网络连通性测试

ping 8.8.8.8 通，延迟约12ms，无丢包；ping www.baidu.com 间歇性超时，大约30%的ICMP包被丢弃，且延迟波动极大（12ms~3000ms）。

2. DNS解析测试

使用 nslookup 测试内网DNS服务器（由AD域控兼做DNS，IP为192.168.10.10）：

C:\> nslookup www.baidu.com 192.168.10.10
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.

多次尝试后偶尔能解析成功，但响应时间普遍超过5秒。换成公共DNS（114.114.114.114）测试，现象一致。

3. HTTP/HTTPS访问测试

用curl测试HTTP访问：

1
2

C:\> curl -w "%{time_total}\n" -o /dev/null -s http://www.baidu.com
5.237

首次访问耗时超过5秒，后续复用连接后有所改善，但刷新页面后问题复现。

4. 关键观察

有一个重要现象：使用IP地址直接访问的业务系统（如 http://10.10.1.20）完全正常，延迟稳定；而使用域名访问的系统（如 http://oa.company.com）则间歇性超时。这进一步将问题范围缩小到DNS解析环节。

三、排查过程

第一步：确认DNS服务器本身是否正常

首先排除DNS服务器（AD域控）自身故障的可能性。远程登录到域控服务器，检查DNS服务状态：

1
2
3

PS> Get-Service DNS
Status   Name   DisplayName
Running  DNS    DNS Server

DNS服务运行正常。进一步检查DNS日志，发现大量"Event ID 4013"和"Event ID 3150"的警告日志，提示"DNS服务器无法解析外部域名，转发器超时"。

查看DNS转发器配置，发现配置了四个转发器：

202.96.128.86（本地运营商DNS）
114.114.114.114
8.8.8.8
8.8.4.4

看起来配置没有问题，但为什么解析会超时？

第二步：抓包分析DNS流量

在域控服务器上启动Wireshark，过滤DNS流量（UDP 53端口），然后进行解析测试：

`1`	`C:\> nslookup www.google.com 192.168.10.10`

抓包结果发现了关键线索：

域控向外网转发DNS查询时，发出的UDP包目标端口53，但完全没有收到响应包
域控随后尝试TCP 53重试，同样没有响应
整个过程中，域控本身可以ping通所有转发器IP，网络层是通的

这说明DNS查询包在出去的路上被丢了，而不是DNS服务器本身的问题。

第三步：检查FortiGate防火墙策略

分公司新上线的FortiGate 100F是本次网络改造的新增设备，重点怀疑对象。通过FortiCloud远程登录FortiGate管理界面，检查防火墙策略。

FortiGate的策略配置相对复杂，新上线时由实施工程师配置，我之前只做了基础验收测试。逐条检查策略，发现了一条当时为"临时测试"创建的策略，规则如下：

Policy ID: 5
Name: DNS_OUT_TEST
Source: all
Destination: all
Service: DNS
Action: DENY
Schedule: always
Log: disable

这条策略的意图是"临时禁止某个测试用的DNS流量"，但配置时Source设成了all，导致所有出站DNS流量（UDP/TCP 53）都被这条策略匹配并丢弃了。

更糟糕的是，这条DENY策略的序列号是5，排在所有ALLOW策略之前（FortiGate策略是自上而下匹配的）。也就是说，任何出站DNS流量在到达后面的ALLOW策略之前，先被这条策略拦截了。

第四步：验证猜测

为了验证是不是这条策略的问题，我先记录当前策略配置，然后临时禁用Policy ID 5，再进行DNS解析测试：

C:\> nslookup www.baidu.com 192.168.10.10
Server:  dc01.company.com
Address:  192.168.10.10

Non-authoritative answer:
Name:    www.a.shifen.com
Addresses:  110.242.68.4
            110.242.68.3
Aliases:  www.baidu.com

解析成功，响应时间不到100ms！进一步测试网页访问、业务系统访问，全部恢复正常。

第五步：追溯策略来源

联系当时负责实施的工程师，了解到这条策略是他做DNS代理测试时创建的，测试完后忘记删除了。由于FortiGate的策略匹配是顺序制的，这条DENY策略插在策略列表靠前的位置，导致所有DNS出站流量被静默丢弃。

之所以前三天没有暴露问题，是因为当时客户端DNS缓存尚未过期，且部分员工使用的是浏览器内置的DNS over HTTPS（DoH），绕过了系统DNS设置，所以问题有延迟才集中爆发。

四、解决方案

问题的根因已经明确，解决步骤如下：

1. 删除错误的测试策略

登录FortiGate，删除Policy ID 5：

1
2
3

config firewall policy
    delete 5
end

2. 优化DNS流量策略

原来策略列表中，DNS出站流量依赖一条"any to any"的通用放行策略，不够精细。新建专用策略，明确允许内网DNS出站：

config firewall policy
    edit 0
        set name "DNS_OUTBOUND"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "RFC1918"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "DNS" "DNS-TCP"
        set logtraffic all
    next
end

关键点：

明确指定了源接口（internal）和目的接口（wan1）
服务明确限定为DNS（UDP 53）和DNS-TCP（TCP 53）
开启全量日志，便于后续排查

3. 优化DNS服务器转发器配置

原先DNS转发器配置了四个，其中8.8.8.8和8.8.4.4从分公司网络访问延迟较高（分公司出口是电信专线，访问Google DNS需要绕路）。优化后的转发器列表：

优先级	DNS服务器	说明
1	202.96.128.86	本地电信DNS，延迟最低
2	114.114.114.114	国内公共DNS，备用
3	内网根提示	直接迭代查询，最后兜底

4. 在FortiGate上启用DNS过滤的安全功能

FortiGate有内置的DNS过滤功能，可以阻断恶意域名解析。在优化后的策略上启用了此功能：

config firewall policy
    edit 10
        set dnsfilter-profile "default"
    next
end

五、根因分析

本次故障的根本原因是FortiGate防火墙策略配置错误，具体可以拆解为以下几个层面：

直接原因：一条Source为"all"的DNS DENY策略被错误地保留在策略列表中，且序列号靠前，导致所有出站DNS流量被静默丢弃。

间接原因：

策略审查缺失：新设备上线的策略清单没有经过严格的Code Review式审查，测试策略未及时清理
缺乏策略变更管理：FortiGate策略的增删改没有走变更流程，实施工程师可以随意添加策略
监控覆盖不足：FortiGate的DNS流量被DENY的日志没有开启（原策略Log设置为disable），导致无法通过日志快速发现问题
DNS解析超时表现不直观：客户端DNS解析超时后会有重试，ICMP ping通但HTTP慢，这种"半通不通"的现象容易引导排查方向偏离

六、预防措施

针对本次故障暴露的问题，制定了以下预防措施：

1. 建立防火墙策略变更管理流程

所有FortiGate策略变更必须满足：

变更前填写《防火墙策略变更申请表》，注明策略用途、源目地址、服务端口、有效期
测试策略必须设置明确的有效期（通过FortiGate的schedule功能实现自动过期）
变更后由第二人复核策略列表

2. 启用关键策略的日志功能

所有DENY类策略必须开启日志（set logtraffic all），以便在日志中心（FortiAnalyzer或FortiCloud）中监控被拦截的流量，快速发现问题。

3. 部署网络监控告警

在监控系统中增加以下告警项：

DNS解析成功率低于95%时告警
FortiGate策略命中次数异常（如某条DENY策略突然有大量命中）时告警
内网到外网DNS服务器的延迟超过100ms时告警

具体实现可以用Prometheus + Blackbox Exporter做DNS探测，告警推送到企业微信。

4. 标准化新设备上线检查清单

制作了《FortiGate上线检查清单》，包含以下关键检查项：

所有测试策略已清理或设置过期时间
策略序列号经过合理性审查（宽策略在前，窄策略在后）
DENY策略均开启日志
DNS、NTP等关键基础服务的策略已明确配置
保存配置（execute backup）

七、总结

这是一次典型的"配置残留"引发的网络故障。FortiGate作为状态检测防火墙，策略匹配顺序是自上而下，一条配置不当的DENY策略所产生的破坏力，不亚于一次DDoS攻击。

几个值得记取的教训：

测试策略必须有过期机制。FortiGate支持schedule设置策略有效期，所有临时测试策略都应该用这个功能，而不是依赖"记得删除"
DNS是网络的基础中的基础。DNS出问题时的表现非常具有迷惑性——ping IP通但域名不通，很容易被误判为应用层问题
抓包是最直接的排查手段。在本次故障中，Wireshark抓包看到的"有去无回"现象，是锁定问题方向的关键
策略变更要有审计。FortiGate的config revision功能可以定期自动备份配置，建议开启

网络运维工作中，“最小化变更影响"和"可回溯性"是两个核心原则。这次故障如果配置备份和策略审计做到位，本可以在5分钟内定位问题，而不需要花费近2个小时逐步排查。

本文所有IP地址、域名均已脱敏处理，技术细节基于真实案例整理。

一次DHCP地址池耗尽导致大面积断网的排查实录

Thu, 27 Mar 2025 08:00:00 +0000

问题背景

周一早上 9 点，刚到办公室坐下，内部沟通群里就开始炸了——整层楼的员工纷纷反馈"连不上网"“网页打不开"“钉钉掉线”。我们公司办公区大约 200 人，分布在两个楼层，通过核心交换机连接到上联防火墙出口。网络拓扑相对简单：核心交换机做 DHCP Server，每个 VLAN 对应一个子网，地址池按楼层划分。

我作为网络运维负责人，第一时间意识到这不是个别用户的问题，而是大面积故障。好在服务器区域使用的是静态 IP，不受 DHCP 影响，核心业务系统还在正常运行。但办公网的瘫痪意味着 200 人无法工作，紧急程度属于 P1 级别——必须 30 分钟内恢复。

故障现象

用户反馈的具体表现如下：

新接入设备无法获取 IP：部分刚开机或重新连接的电脑显示"正在获取网络地址”，持续等待后最终提示"无 Internet 连接"，ipconfig /all 显示 IP 为 0.0.0.0。
已在线设备部分正常：之前已经拿到 IP 且租期未过期的设备暂时还能上网，但网络明显变慢， ping 内网网关偶尔出现 50-200ms 的异常延迟。
DHCP 请求超时：在受影响的终端上抓包，可以看到 DHCP Discover 包正常发出，但始终没有收到 DHCP Offer 回应。

关键信息：

核心交换机（华为 S5735-L48T4X）上配置了 VLAN 10（一楼）和 VLAN 20（二楼）的 DHCP 地址池
VLAN 10 地址池：192.168.10.100 - 192.168.10.250，共 151 个地址
VLAN 20 地址池：192.168.20.100 - 192.168.20.250，共 151 个地址
楼层实际办公电脑数量：一楼约 90 台，二楼约 110 台

排查过程

第一步：确认 DHCP 服务状态

登录核心交换机，首先检查 DHCP Server 是否正常运行：

<HX-Switch> display dhcp server statistics
  DHCP Server Statistics:
    Request Received     : 4238
    Offer Sent           : 151
    Ack Sent             : 151
    Discover Received    : 4087
    Offer Failed         : 3936

关键发现：Offer Failed 达 3936 次！ 这意味着交换机收到了大量 DHCP Discover 请求，但无法回复 Offer。这几乎可以确定是地址池出了问题。

第二步：检查地址池使用情况

继续查看地址池的分配状态：

<HX-Switch> display dhcp server ip-in-use pool vlan10
  IP Address       Hardware Address   Lease Expired   Status
  192.168.10.100   00e0-4c68-01a2    2026/06/20 18:00  Used
  192.168.10.101   00e0-4c68-03b5    2026/06/20 18:00  Used
  ...（省略中间）
  192.168.10.250   a860-b117-55c3    2026/06/20 18:00  Used
  Total : 151    Used : 151    Idle : 0

1
2

<HX-Switch> display dhcp server ip-in-use pool vlan20
  Total : 151    Used : 151    Idle : 0

地址池 100% 占用，零空闲！ VLAN 10 和 VLAN 20 的 302 个地址全部被分配。但实际办公电脑只有约 200 台，多出来的 100 多个地址被谁占走了？

第三步：分析 DHCP 租约表

导出完整租约表进行详细分析。我用 Python 脚本处理交换机输出的 MAC-IP 映射：

`1`	`<HX-Switch> display dhcp server ip-in-use pool vlan10 all`

拿到全部 151 条记录后，我重点关注 MAC 地址的前缀（OUI），用来识别设备类型：

MAC 前缀	设备类型	数量
00e0-4c	Realtek（PC 网卡）	68
a860-b1	Apple（iPhone/Mac）	42
dc:a6:32	Raspberry Pi	12
88:15:44	智能家居/IoT 设备	15
ac:de:48	私有 MAC（随机化）	14

发现了！42 台 iPhone + 15 台 IoT 设备 + 12 台 Raspberry Pi + 14 台随机化 MAC 设备 = 83 台非办公设备，它们占用了大量 DHCP 地址。这些是员工个人手机、测试设备以及不明 IoT 设备。

VLAN 20 的情况更严重：二楼有 110 台办公电脑，地址池只有 151 个，被 48 台手机和一堆 IoT 设备挤占后，留给办公电脑的只有不到 100 个——根本不够用。

第四步：定位非法设备的接入端口

接下来需要找到这些非办公设备是从哪些端口接入的。在交换机上查询 MAC 地址表：

<HX-Switch> display mac-address dynamic vlan 10
  MAC Address      VLAN  Port          Type
  a860-b117-55c3   10    GE0/0/15     Dynamic
  a860-b117-66d4   10    GE0/0/15     Dynamic
  a860-b117-78e1   10    GE0/0/15     Dynamic
  ...（多个 Apple MAC 均从 GE0/0/15 学习到）
  dc:a6-32-01-ab   10    GE0/0/22     Dynamic
  dc:a6-32-01-cd   10    GE0/0/22     Dynamic
  88:15:44-xx      10    GE0/0/28     Dynamic

发现规律：

GE0/0/15：会议室区域的大屏和员工手机大量接入（一个端口下挂 AP，AP 下连接了数十个无线设备）
GE0/0/22：研发测试区的交换机下联了 12 台 Raspberry Pi
GE0/0/28：茶水间区域的 IoT 设备（智能灯控、温湿度传感器等）

根本问题很清楚了：无线 AP 没做 MAC 过滤，任何人都可以用手机连上办公 Wi-Fi 拿到 IP；研发区随意接入测试设备；IoT 设备也混在办公 VLAN 里。

第五步：查看 DHCP 租期配置

再看一下租期设置：

1
2
3

<HX-Switch> display dhcp server pool vlan10
  Pool Name      : vlan10
  Lease Day      : 1    Hour : 0    Minute : 0

租期 1 天！ 手机连上 Wi-Fi 后拿到的 IP 要 24 小时才会过期释放，即使手机离开了网络，地址也一直被占着。这进一步加剧了地址池耗尽的问题。

解决方案

紧急恢复（5 分钟内实施）

第一步：清除非法设备的 DHCP 租约，立即释放被占用的地址：

<HX-Switch> system-view
# 批量释放非办公MAC的租约
<HX-Switch> reset dhcp server ip-in-use mac-address a860-b117-55c3 pool vlan10
<HX-Switch> reset dhcp server ip-in-use mac-address a860-b117-66d4 pool vlan10
# ...（按MAC前缀批量清除所有Apple/iOS设备的租约）
<HX-Switch> reset dhcp server ip-in-use pool vlan10 conflict
# 清除冲突地址

由于手动一条条清太慢，我用了更高效的方法——缩短租期到 1 小时，让所有现有租约快速过期：

<HX-Switch> dhcp server ip-pool vlan10
<HX-Switch-vlan10> lease day 0 hour 1 minute 0
<HX-Switch> dhcp server ip-pool vlan20
<HX-Switch-vlan20> lease day 0 hour 1 minute 0

这样 1 小时后所有设备的租约都会到期需要重新续租，到那时我们再通过端口安全策略拦截非法设备。

第二步：临时扩大地址池，缓解当前压力：

<HX-Switch> dhcp server ip-pool vlan10
<HX-Switch-vlan10> network 192.168.10.0 mask 255.255.254.0
# 地址范围从 .100-.250 扩大到 .1-.510（实际可用约 500）
<HX-Switch> dhcp server ip-pool vlan20
<HX-Switch-vlan20> network 192.168.20.0 mask 255.255.254.0

将子网掩码从 /24 改为 /23，地址池翻倍，确保即使有手机接入也不会耗尽。

注意：扩大子网后需要同步更新上联防火墙的路由和 NAT 规则。

约 3 分钟后，用户开始陆续恢复网络连接。紧急恢复完成。

根治方案（当天下午实施）

1. VLAN 隔离——IoT 和访客设备独立网段

<HX-Switch> vlan 30  # IoT专用VLAN
<HX-Switch-vlan30> dhcp server ip-pool iot
<HX-Switch-iot> network 192.168.30.0 mask 255.255.255.0
<HX-Switch-iot> lease day 0 hour 0 minute 30  # IoT设备租期30分钟
<HX-Switch-iot> gateway-list 192.168.30.1

<HX-Switch> vlan 40  # 访客Wi-Fi VLAN
<HX-Switch-vlan40> dhcp server ip-pool guest
<HX-Switch-guest> network 192.168.40.0 mask 255.255.255.0
<HX-Switch-guest> lease day 0 hour 2 minute 0  # 访客租期2小时
<HX-Switch-guest> gateway-list 192.168.40.1

无线 AP 配置双 SSID：Office-WiFi（仅办公设备，绑定 VLAN 10/20）和 Guest-WiFi（访客/手机，绑定 VLAN 40），通过 802.1X 认证区分合法办公设备。

2. 端口安全——限制接入设备数量

<HX-Switch> interface GE0/0/15  # 会议室端口
<HX-Switch-GE0/0/15> port-security enable
<HX-Switch-GE0/0/15> port-security max-mac-num 5  # 最多5台设备
<HX-Switch-GE0/0/15> port-security protect-action shutdown  # 超限则关闭端口

<HX-Switch> interface GE0/0/22  # 研发测试区
<HX-Switch-GE0/0/22> port-security enable
<HX-Switch-GE0/0/22> port-security max-mac-num 20  # 研发区允许较多设备
<HX-Switch-GE0/0/22> port-security protect-action restrict  # 超限仅丢弃新MAC

3. DHCP 租期优化

办工 VLAN：租期从 1 天调整为 8 小时（足够一个工作日，下班后地址自动释放）
IoT VLAN：租期 30 分钟（IoT 设备重启频繁，短租期避免地址浪费）
访客 VLAN：租期 2 小时（访客停留时间有限）

4. DHCP Snooping 防护

<HX-Switch> dhcp snooping enable
<HX-Switch> vlan 10
<HX-Switch-vlan10> dhcp snooping enable
<HX-Switch> interface GE0/0/1  # 上联口（信任口）
<HX-Switch-GE0/0/1> dhcp snooping trust

防止非法 DHCP Server 干扰，同时记录 DHCP 绑定表便于审计。

根因分析

问题的根本原因有三层：

网络架构设计缺陷：所有设备（办公电脑、手机、IoT、测试设备）混在同一个 VLAN 里，没有按设备类型做网络隔离。地址池按"办公电脑数量"规划，完全忽略了无线 AP 下挂的手机和 IoT 设备。
DHCP 租期过长：1 天的租期导致设备断开连接后 IP 仍然被占用长达 24 小时。手机这种高流动性设备（连上 Wi-Fi 就拿 IP，离开后 IP 一直不释放）是地址池耗尽的最大推手。
无线网络缺乏准入控制：办公 Wi-Fi 无认证无过滤，任何人的手机都可以随意接入，等于给 DHCP 地址池开了一个无底洞。

三层因素叠加：架构上没有隔离 → 准入上没有限制 → 租期上没有优化 → 地址池被挤爆。

预防措施

基于这次故障，我们制定了以下长期预防措施：

1. 定期巡检 DHCP 地址池利用率

编写巡检脚本，每小时采集地址池利用率并推送监控：

import paramiko
import re

def check_dhcp_pool(switch_ip, pool_name):
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(switch_ip, username='admin', password='xxx')
    cmd = f'display dhcp server ip-in-use pool {pool_name}'
    output = ssh.exec_command(cmd)[1].read().decode()
    # 解析 Total / Used / Idle
    match = re.search(r'Total\s*:\s*(\d+)\s*Used\s*:\s*(\d+)\s*Idle\s*:\s*(\d+)', output)
    if match:
        total, used, idle = int(match.group(1)), int(match.group(2)), int(match.group(3))
        utilization = used / total * 100
        if utilization > 85:
            send_alert(f'DHCP池 {pool_name} 利用率 {utilization:.1f}%，空闲仅 {idle} 个')
    ssh.close()

# 定时巡检所有地址池
for pool in ['vlan10', 'vlan20', 'iot', 'guest']:
    check_dhcp_pool('10.0.0.1', pool)

2. VLAN 规划标准化

新建网络区域必须遵循 VLAN 隔离原则：

办工设备 VLAN：仅允许通过 802.1X 认证的设备接入
IoT 设备 VLAN：单独隔离，ACL 限制只能访问特定服务器
访客 VLAN：独立 SSID，ACL 限制只能访问 Internet，禁止访问内网资源

3. 地址池容量预留

地址池规划时预留 50% 以上冗余。例如 200 台办公设备，地址池至少 300 个地址。同时预留一个备选子网，在紧急扩容时可快速启用。

4. 无线网络准入强化

办工 Wi-Fi 启用 802.1X 企业认证，绑定 AD 域账号
访客 Wi-Fi 启用 Web 认证（短信验证码或临时账号）
定期审计无线 AP 的关联终端列表，清理异常设备

5. 建立变更审批流程

任何人接入非办公设备（测试服务器、IoT 设备等）必须提前提交网络变更申请，运维团队评估 VLAN 归属和地址池容量后才允许接入。

总结

这次故障从发现到紧急恢复用了约 15 分钟，根治方案在当天下午完成。最大的教训是：网络规划不能只看"有多少台电脑"，要看"有多少台设备会连上来"。

在移动办公时代，每个员工至少有一台手机会连 Wi-Fi，加上各种 IoT 设备和测试设备，实际接入数往往是办公电脑数的 1.5-2 倍。如果地址池按电脑数来规划，必然会被挤爆。

另一个关键认知是：DHCP 租期不是越大越好。长租期在设备稳定的场景（服务器、固定工位）是好实践，但在高流动性场景（手机、访客）就是灾难。不同类型的设备要用不同的租期策略。

最后，网络隔离是最基本的防护——把办公、IoT、访客分到不同 VLAN，不仅仅是为了安全，也是为了资源管理。当你发现一个 VLAN 的地址池快满时，至少不会拖垮其他 VLAN 的正常设备。

一次NTP时间同步异常导致Kerberos认证全部失效的排查实录

Mon, 14 Jul 2025 09:15:00 +0000

问题背景

某周一上午 9 点左右，公司 IT 服务台接到多起投诉：员工无法访问共享文件夹（\\fileserver\share），访问内网系统提示"用户名或密码不正确"，即使重新输入正确密码仍无法登录。部分员工的 Outlook 也无法连接 Exchange，提示需要重新输入密码。

受影响人数约 60 人，分布在不同楼层，但有一个共同点：周末期间他们的电脑一直保持开机状态（服务器机房和少量长期开机的办公室电脑）。

故障现象

访问共享文件夹报错：登录失败：目标账户名不正确
Outlook 提示凭据错误，无法连接 Exchange
部分系统登录时报：此计算机上的时钟与主域控制器上的时钟不同步
klist 命令查看 Kerberos 票据，显示无法获取票据：KRB5KRB_AP_ERR_SKEW: Clock skew too great

排查过程

第一步：注意到时间错误提示

一位细心的用户截图发给 IT，截图中包含了一行小字：此计算机上的时钟与主域控制器上的时钟不同步。这个提示是关键线索。

在一台受影响的机器上查看系统时间：

`1`	`w32tm /query /status`

输出：

Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x00000000
Last Successful Sync Time: 7/11/2025 11:30:45 PM
Source: time.windows.com
Poll Interval: 17 (131072s)

关键发现：Last Successful Sync Time 是 7月11日（周五晚上），已经 3 天没有同步！

再看当前时间与域控的差异：

`1`	`net time \\dc01`

输出：

1
2

Current time at \\DC01 is 7/14/2025 9:23:15 AM
The command completed successfully.

而本机时间：

time /t

`1`	`09:17:42`

本机时间 09:17，DC 时间 09:23，差了约 6 分钟，超过了 Kerberos 允许的最大时间偏差（5 分钟）。

第二步：Kerberos 时间敏感性原理

Kerberos 协议要求客户端和 KDC（Key Distribution Center，通常是域控）之间的时间差不超过 5 分钟（由 MaxClockSkew 参数控制，默认值 5 分钟）。这是 Kerberos 防止重放攻击的安全机制。

当时间偏差超过 5 分钟时：

客户端申请 Kerberos 票据（TGT）时，KDC 会拒绝请求，返回 KRB5KRB_AP_ERR_SKEW
所有依赖 Kerberos 的服务认证失败，包括：共享文件夹访问、Exchange、域控登录、GPO 应用等

第三步：追查 NTP 同步失败的原因

受影响的机器理论上应该从域控同步时间（域成员机器默认时间源是域控）。检查这些机器为什么没有同步：

`1`	`w32tm /query /configuration`

输出发现这台机器的 NTP 源被手动配置为了 time.windows.com（外网 NTP 服务器），而不是使用域的自动配置（NT5DS，从域层次结构同步）。

继续查看其他受影响机器，发现大部分受影响机器的 NTP 配置有问题，要么被手动改过，要么因为某个组策略没有正常应用而导致 NTP 源配置不正确。

进一步查看域控本身的 NTP 配置：

1
2

# 在 DC01 上执行
w32tm /query /status

Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Last Successful Sync Time: 7/11/2025 11:28:13 PM
Source: ntp.aliyun.com

域控本身也没有同步！ 域控的上游 NTP 服务器（ntp.aliyun.com）从周五晚上开始就无法访问了。

第四步：排查为什么 NTP 服务器不可达

`1`	`ping ntp.aliyun.com`

`1`	`Request timeout for icmp_seq 0`

无法 ping 通。检查防火墙日志，发现周六白天运维团队在做例行防火墙策略清理时，误删了一条允许 UDP 123（NTP 协议端口）出站的规则，导致所有机器无法向外部 NTP 服务器同步时间。

由于周末无人值班，这个问题持续了 2 天多，域控的时间逐渐漂移，到周一早上已经偏差 6 分钟，触发了 Kerberos 认证失败。

完整的故障链： 防火墙误删 UDP 123 规则 → NTP 同步失败 → 域控时间漂移 → 域成员机器时间偏差超 5 分钟 → Kerberos 认证失败 → 大量服务不可访问

解决方案

第一步：恢复防火墙 NTP 规则

在 FortiGate 防火墙上重新添加允许出站 UDP 123 的规则：

策略 → 允许出站 NTP
Source: Internal_Network
Destination: All
Service: NTP (UDP 123)
Action: Accept

第二步：强制域控同步时间

1
2

# 在 PDC（主域控制器）上执行
w32tm /resync /force

等待同步完成：

`1`	`w32tm /query /status`

验证 Last Successful Sync Time 更新为当前时间。

第三步：强制受影响机器同步

在受影响机器上：

# 先停止 W32Time 服务
net stop w32time

# 注册并重新配置为域同步
w32tm /unregister
w32tm /register

# 重启服务
net start w32time

# 强制同步
w32tm /resync /force

# 验证
w32tm /query /status
net time \\dc01

第四步：通过 GPO 批量修复

对于大量受影响机器，通过 PowerShell 远程批量执行：

$computers = (Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=company,DC=com").Name
Invoke-Command -ComputerName $computers -ScriptBlock {
    Stop-Service w32time -Force
    w32tm /unregister
    w32tm /register
    Start-Service w32time
    w32tm /resync /force
}

处理完成后，相关 Kerberos 错误消失，服务全部恢复正常。

根因分析

根本原因是防火墙变更管理不规范，例行清理操作误删了 NTP 出站规则，且该变更没有经过充分测试和验证，也没有回滚计划。NTP 时间同步失败属于"慢性"故障，不会立即触发告警，而是在时间漂移积累到一定程度后才爆发。

次要原因是缺乏 NTP 同步状态的监控，如果有监控在 NTP 同步失败时立即告警，可以在几小时内发现并修复，而不是等到周一早高峰才被动发现。

预防措施

1. NTP 同步状态监控

在 Zabbix 中添加监控项，监控关键服务器（尤其是域控）的时间同步状态和时间偏差，超过 60 秒偏差时告警：

1
2

# Zabbix Agent 自定义 UserParameter
UserParameter=ntp.offset,w32tm /query /status | grep "Phase Offset" | awk '{print $3}'

2. 防火墙变更双人复核

所有防火墙策略变更必须经过运维负责人审核，变更后验证关键服务（DNS、NTP、AD认证）的可用性。

3. 保留 NTP 备用内网服务器

在内网部署一台 NTP 服务器作为备用，即使出口 NTP 不可达，内网机器也可以从内网 NTP 服务器同步时间。

总结

NTP 是 AD 域环境中"沉默的基础设施"，平时无人关注，一旦出问题却能引发连锁反应。这次事故让我们深刻认识到：越是基础的服务，越需要完善的监控。时钟同步听起来不重要，但在 Kerberos 的世界里，6 分钟的时差就能让整个认证体系瘫痪。

一次办公区无线网络间歇性断连的排查实录

Tue, 07 Nov 2023 11:00:00 +0000

问题背景

近期（大约持续了两周）公司办公区的员工陆续通过工单反馈，说 WiFi 连接很不稳定，主要表现是：

视频会议（腾讯会议、Teams）经常卡顿、掉线
手机和笔记本有时会突然断开 WiFi，重连后几分钟又断
部分区域信号格数显示满格，但实际网速极慢

受影响的主要是 3 楼办公区（约 80 名员工），4 楼相对较少。公司无线网络使用 Aruba 无线控制器（AC）统一管理约 30 台 AP，全部部署在室内天花板。

故障现象

3 楼员工 WiFi 连接不稳定，视频会议频繁卡顿
Windows 任务栏 WiFi 图标有时显示感叹号（受限连接）
手机 WiFi 速度测试：下载约 1-3 Mbps（预期应有 50+ Mbps）
但有线接入的员工完全不受影响，排除上联网络问题

排查过程

第一步：确认问题范围

先用有线和无线各自进行网速测试，有线稳定在 100Mbps 左右，无线只有 2-5Mbps，明确是无线侧的问题。

再确认问题时间规律：工单记录显示，问题主要出现在 9:30-11:30 和 14:00-16:00，正好是员工视频会议的密集时段，早晚时段没有明显问题。

第二步：通过 Aruba AC 查看无线环境

发现 1：AP 3F-01 和 AP 3F-02 关联的设备数量异常多

正常每台 AP 关联设备 20-30 个，而 3F-01 和 3F-02 分别关联了 65 和 58 个设备，远超设计容量。

发现 2：2.4GHz 频段使用率极高

进入 RF（无线射频）监控页面，查看频谱使用情况：

2.4GHz 频段：信道 6 的利用率达到 87%
5GHz 频段：各信道利用率均在 30% 以下

大量设备（尤其是老旧手机和打印机）扎堆连接 2.4GHz，而 5GHz 频段相对空闲。

第三步：扫描无线环境，寻找干扰源

在 Aruba AC 上启用 AM（Air Monitor）模式，对 3 楼进行无线环境扫描，查看附近 AP 的信道分布情况：

扫描结果发现，在信道 6 上，除了我们自己部署的 AP 外，还检测到了 4 个非授权的 SSID：

SSID: TP-LINK_XXXX   信道: 6   RSSI: -65dBm   厂商: TP-Link
SSID: TP-LINK_YYYY   信道: 6   RSSI: -72dBm   厂商: TP-Link
SSID: ChinaNet-ZZZZ  信道: 6   RSSI: -68dBm   厂商: Huawei
SSID: Mi_AABB        信道: 1   RSSI: -71dBm   厂商: Xiaomi

同一频段上存在多个非授权 AP（来自员工自带的路由器或隔壁邻居的家用 WiFi），与我们的 AP 形成同频干扰。

第四步：现场定位非法 AP

通过 Aruba 的 RSSI 强度信息和楼层平面图，大致定位了信号强度最强的两台非授权 AP 来源：

TP-LINK_XXXX（RSSI -65dBm）：信号来自 3 楼东侧某个角落
ChinaNet-ZZZZ（RSSI -68dBm）：信号来自楼下或相邻建筑

到 3 楼东侧排查，在一个储物间里发现了一台员工私自安装的 TP-Link 路由器，他是因为自己工位信号不好，就从家里带了一个路由器来增强信号，接在了墙上的网络接口上，结果反而加剧了干扰。

第五步：分析同频干扰原理

2.4GHz 频段总带宽有限，常用的不重叠信道只有 3 个：1、6、11。当多个 AP 同时使用信道 6 时，它们的信号会相互干扰，设备需要等待信道空闲才能发送数据（CSMA/CA 机制），信道越拥挤，等待时间越长，表现为网速慢、延迟高。

我们的 3F-01、3F-02 都在信道 6，加上 4 个外部 AP 也在信道 6，7 个发射源共享一个 20MHz 宽的信道，效率极低。

解决方案

第一步：移除非法 AP

拔除储物间里员工私装的 TP-Link 路由器，并通知该员工不得私自接入未授权网络设备。告知全体员工相关规定。

第二步：重新规划 2.4GHz 信道分配

重新梳理 3 楼所有 AP 的信道规划：

将同一楼层相邻 AP 分配到不同的不重叠信道（1、6、11 错开分配）
减少信道 6 上的 AP 数量

AP 3F-01  →  信道 1
AP 3F-02  →  信道 11
AP 3F-03  →  信道 6
AP 3F-04  →  信道 1
...（相邻不同信道，避免重叠）

第三步：开启频段引导（Band Steering）

在 Aruba AC 上启用 Band Steering 功能，将支持 5GHz 的设备自动引导到 5GHz 频段：

在 Aruba 管理界面：Configuration → SSID → Advanced → Band Steering → Enable

Band Steering 工作原理：对于同时支持 2.4GHz 和 5GHz 的设备，AP 在 2.4GHz 上延迟响应 Probe Request，促使设备转向 5GHz 关联。

第四步：调整 AP 发射功率

部分 AP 发射功率设置过高，导致信号覆盖区域重叠，加剧同频干扰。将相邻 AP 的发射功率适当降低：

在 Aruba RF Plan 中，将 3 楼各 AP 的 2.4GHz 最大发射功率从 23dBm 调整至 17dBm，覆盖半径缩小，减少同频重叠区域。

第五步：效果验证

调整完成后，次日早上进行测试：

3 楼 AP 2.4GHz 信道 6 利用率从 87% 下降到 41%
各 AP 关联设备数量均匀分布，3F-01 从 65 台降至 28 台
无线下载速度测试：从 2-5Mbps 提升至 45-80Mbps
视频会议测试：连续 1 小时无断线，质量正常

根因分析

根本原因有两个：

同频干扰：3 楼 2.4GHz 频段信道 6 上存在大量 AP（包括外部非授权 AP），信道竞争激烈，设备需长时间等待信道空闲，导致网速下降。
负载不均衡：2.4GHz 频段承载了过多设备，而 5GHz 相对空闲，缺少频段引导机制将设备均衡分流。

预防措施

1. 定期无线环境扫描

每月通过 Aruba AM 或 Wi-Fi Analyzer 扫描一次，及时发现新增的非法 AP 和信道干扰。

2. 非法 AP 检测与告警

开启 Aruba Wireless Intrusion Protection（WIP）功能，自动检测并告警非授权设备接入。

3. 员工教育

通过邮件或公告明确：不得在公司网络上自行接入个人路由器、交换机等设备，违者按公司 IT 使用规范处理。

4. 定期审查 AP 规划

公司扩建或改建后，应重新审查 AP 布点和信道规划，不能使用初始规划一成不变。

总结

无线网络故障相比有线往往更难直接定位，因为很多干扰因素"看不见摸不着"。这次故障的关键排查步骤是借助无线控制器的 RF 监控和频谱扫描功能，量化了信道利用率，并找到了隐藏的非法 AP 干扰源。

经验总结： 对于无线网络性能问题，要重点检查信道规划是否合理、是否存在同频干扰、5GHz 是否被充分利用。同时，员工私接设备的问题在企业网络中极为普遍，需要从技术手段（WIDS）和管理手段双管齐下。

一次核心交换机STP风暴导致全楼网络瘫痪的排查实录

Wed, 08 Jun 2022 14:20:00 +0000

问题背景

某周三下午 14:20 左右，公司全楼约 300 名员工突然反映网络中断，表现为无法访问内网系统、互联网全部断开。影响持续约 25 分钟，直到网络恢复正常。

公司网络架构为三层设计：核心层（H3C S7503 核心交换机 ×2，堆叠）、汇聚层（各楼层汇聚交换机）、接入层（各区域接入交换机）。出口通过核心交换机直连防火墙接入互联网。

事故期间 IT 监控告警系统收到大量告警：核心交换机 CPU 使用率达到 100%，大量接口出现 CRC 错误。

故障现象

全楼用户无法访问内外网，ping 内网网关均超时
核心交换机 SSH 无法登录（CPU 负载过高导致管理面板无响应）
监控系统显示核心交换机上行接口流量在故障期间突然暴增至满带宽
各楼层汇聚交换机日志中出现大量 MAC 地址表抖动告警：

%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
（以上日志每秒出现数十条）

核心交换机 CPU 告警日志：

`1`	`%SYSTEM-3-CPU_OVERLOAD: CPU utilization reached 100%`

排查过程

第一步：现场快速响应

接到告警后立即赶到机房，此时核心交换机 SSH 已经无法连接，只能通过 Console 口连接。Console 口可以登录，但响应非常慢，输入命令后需要等几秒才有回显。

第二步：查看当前 CPU 状态

1
2
3

<H3C-Core> display cpu-usage
Slot 1:
CPU Usage: 100%

CPU 持续 100%，正常运维操作受阻。先查看进程占用：

1
2
3

<H3C-Core> display process cpu
Process  CPU%  Process Name
STP      89%   Spanning Tree Protocol

STP 进程占用了 89% 的 CPU，几乎可以确认是生成树相关问题。

第三步：查看 STP 状态

<H3C-Core> display stp brief
 MST ID  Port                     Role  STP State    Protection
  0      GE1/0/1                  DSGN  FORWARDING   NONE
  0      GE1/0/2                  DSGN  FORWARDING   NONE
  0      GE1/0/12                 ROOT  FORWARDING   NONE
  ...

注意到 GE1/0/12 这个接口频繁出现拓扑变更通知（TCN），正常情况下 STP 拓扑是稳定的，不应该持续触发 TCN。

第四步：定位问题接口

查看 GE1/0/12 接口详情：

<H3C-Core> display interface GigabitEthernet 1/0/12
GigabitEthernet1/0/12 current state: UP
Input bandwidth utilization : 99.8%
Output bandwidth utilization: 99.7%

接口带宽利用率接近 100%，流量极不正常。

查看该接口连接的设备：

<H3C-Core> display lldp neighbor interface GigabitEthernet 1/0/12
Neighbor index  :1
Chassis ID      :5c-dd-70-xx-xx-xx
Port ID         :GigabitEthernet1/0/1
TTL             :120s
System name     :SW-Floor3-Access

该接口连接的是三楼的接入交换机。再查看三楼接入交换机的 MAC 地址表变化情况（通过另一条管理路径连上汇聚交换机，再 telnet 到接入交换机）：

1
2
3

[SW-Floor3-Access] display mac-address learning
MAC address learning: enabled
MAC entries: 8764 (normal: 256)

MAC 表条目高达 8764！正常一台接入交换机最多几百条，出现这么多条目强烈说明有广播风暴，MAC 地址表在不断刷新。

第五步：找到广播风暴源头

在三楼接入交换机上，查看各接口的流量情况，发现有两个接口的 In/Out 流量都异常高：

GE1/0/23：In 95% / Out 94%
GE1/0/24：In 96% / Out 95%

立刻到现场查看这两个接口连接的是什么设备。

发现问题所在：三楼的一个会议室，一台 5 口的 TP-Link 哑交换机（无管理接口）将它的两个口分别插到了接入交换机的 GE1/0/23 和 GE1/0/24，形成了一个环路！

经询问，是当天下午有人觉得会议室网口不够用，就从库房找了一台旧的哑交换机接上，并且为了多用几个口，把两根网线都插到了楼层接入交换机上（一根接到 23 口，另一根接到 24 口），然后把会议室的网线也接到哑交换机上。这台哑交换机没有 STP 支持，直接形成了二层环路。

第六步：验证并处理

立即拔掉哑交换机上的一根网线，断开环路。

几秒钟后，核心交换机 CPU 开始下降：

1
2
3

CPU Usage: 67%  (30 seconds later)
CPU Usage: 24%  (60 seconds later)
CPU Usage:  8%  (90 seconds later)

全楼网络逐渐恢复，SSH 可以正常登录。

解决方案

立即处理：

移除会议室哑交换机，或只保留一根网线连接到楼层交换机
对接入交换机的 GE1/0/23 和 GE1/0/24 端口开启 BPDU Guard 和 Port Fast（如接入层交换机支持）

接入交换机端口配置（以 H3C 为例）：

1
2
3

[SW-Floor3-Access] interface GigabitEthernet 1/0/23
[SW-Floor3-Access-GE1/0/23] stp edged-port enable
[SW-Floor3-Access-GE1/0/23] stp bpdu-protection enable

stp edged-port enable 将该端口设为边缘端口（快速进入转发状态），stp bpdu-protection 确保一旦收到 BPDU 就关闭端口，防止哑交换机引发环路。

对所有接入端口（下联终端的端口）批量开启保护：

`1`	`[SW-Floor3-Access] stp bpdu-protection`

此命令在全局开启 BPDU Guard，适用于所有已配置为边缘端口的接口。

根因分析

此次事故的根本原因是未经授权的网络设备接入，且接入的是不支持 STP 的哑交换机，直接造成二层环路。环路导致广播风暴，大量 STP TCN 帧充斥网络，核心交换机 STP 进程持续处理拓扑变更请求，CPU 飙至 100%，正常数据转发能力丧失，全楼断网。

预防措施

1. 端口安全配置（核心）

所有接入端口启用 BPDU Guard 和 Port Fast，一旦检测到非法接入的交换机就自动关闭端口：

1
2

# 全局开启接入端口保护
stp bpdu-protection

2. 端口 MAC 地址绑定

对固定位置的终端，绑定 MAC 地址，防止未知设备接入：

1
2
3

port-security enable
port-security max-mac-count 1
port-security violation restrict

3. 用户权限管控

制定规定：任何人不得自行增减或调整网络设备，需求须提交 IT 工单处理。

4. 监控告警细化

完善接入层交换机的 STP 拓扑变更告警，发现 TCN 频繁触发时立即通知运维人员，缩短响应时间。

总结

这次事故对我们的提醒是：二层网络的风险往往来自"无害"的小设备。一台十几块钱的哑交换机就能让全楼断网 25 分钟，损失的是几百人的工作效率。

对于 IT 运维来说，不仅要把核心网络设备管理好，接入层的安全策略同样不可忽视。BPDU Guard、Port Security 这些配置看起来很基础，但往往是防止意外事故的关键防线。

另外，员工的安全意识培训也很必要——让大家知道"随便接交换机"可能会带来什么后果。