板块11 · 故障排查与维护方法论
板块11 · 故障排查与维护方法论
目标：把前十个板块的配置、协议和验证能力，收敛为“可复现、可回退、可归档”的故障处理与维护体系。
定位：【ZCIP】要求“处理复杂故障”，强调在既定网络中识别多变量、完成跨层定位；【ZCIE】要求“指导处理综合复杂故障”，还要能组织协作、控制风险、复盘并沉淀标准。两者的分水岭不在会不会配，而在有没有方法论。
使用原则：现场先止血、再定位；实验先备份、再变更；结论先看证据、再看经验。本文的命令仅为排障表达示例，实际语法、视图和对象名必须依型号和软件版本用?确认。
11_1 故障处理总体方法论
本节要解决什么问题：同样的现象，有人五分钟定位，有人折腾一天，差别在方法论。本节给出七步流程与四种定位方法。
11_1_1 方法论的三层价值
【ZCIA】需要按照流程完成“查状态—看配置—做验证”的基本动作；【ZCIP】要能把终端、接入、汇聚、核心、出口和应用端串成端到端路径；【ZCIE】则进一步把人员分工、变更窗口、回退条件和组织改进纳入同一套方法。技术点相同，价值层级不同：前者是命令执行，后者是故障治理。
方法论并非束缚现场发挥，而是防止三类常见失控：
- 目标失控：没有确认业务影响就开始深挖协议，导致故障窗口持续扩大。
- 操作失控：缺少基线、备份和回退点，一次“试探”演变为二次故障。
- 结论失控：只看单一现象就认定根因，修复后未验证又留下隐患。
因此，任何复杂故障都应同时回答五个问题：谁受影响、哪一段路径、何种变更后、当前可否恢复、恢复后如何证明根因。五问不全，就不应急于下结论。
11_1_2 标准故障处理流程（七步）
┌───────────────────────┐
│ 1. 故障受理 │ 记录现象、影响范围、发生时间、联系人、变更历史
└──────────┬────────────┘
▼
┌───────────────────────┐
│ 2. 信息收集 │ 拓扑、配置、日志、告警、统计、最近操作、业务基线
└──────────┬────────────┘
▼
┌───────────────────────┐
│ 3. 故障定位 │ 分层/分段/对比/替换；建立假设、逐条验证
└──────────┬────────────┘
▼
┌───────────────────────┐
│ 4. 影响控制 │ 优先止血：隔离、切换、回退、限速；同步通报
└──────────┬────────────┘
▼
┌───────────────────────┐
│ 5. 故障排除 │ 采用最小影响方案；每次只变一个变量
└──────────┬────────────┘
▼
┌───────────────────────┐
│ 6. 验证恢复 │ 功能、性能、冗余、业务；观察期不少于 30 分钟
└──────────┬────────────┘
▼
┌───────────────────────┐
│ 7. 复盘归档 │ 时间线、根因、改进、知识库、跟踪责任人
└───────────────────────┘
七步不是机械流水。若业务正在持续恶化，第 4 步可以提前到第 2 步；若已有可靠回退点，第 5 步应优先选择回退而不是现网实验。但第 6 步不能省：没有验证的恢复只是暂时不报错。
受理阶段要拿到“最小故障描述”：受影响的对象（IP、VLAN、业务、区域）、正常到异常的时间点、是否全员/全业务/间歇性、最近一次变更是什么。模糊报障“网络不通”至少应拆成：是否 DHCP 失败、是否网关不可达、是否跨网段失败、是否有线无线同时异常。
信息收集要区分快照与增量：配置、版本、拓扑、时间戳是快照；端口计数、CPU、会话数、日志是增量。查看增量前先记录初始值，或显式执行清零后再复现，否则无法判断错误是历史遗留还是当前增长。
11_1_3 第一原则：先恢复后根治
现场铁律：
① 业务中断时，第一目标是恢复业务，不是立即证明根因。
② 优先采用影响最小、可逆、已验证的手段：切备用路径、禁用可疑端口、回退配置。
③ 恢复前保留证据：配置、日志、统计、抓包、截图、时间戳；恢复后再分析。
④ 严禁在业务高峰期做试探性、多变量、无回退方案的操作。
⑤ 已经发生二次故障时，立即停止新增变更，回到最后一个已知良好状态。
典型反例：
用户在报障，工程师一边 ping，一边连续改 VLAN、STP、限速和 MTU。
结果原问题未解决，又引入 MAC 漂移、聚合不同步、回程路由错误。
正确动作：
已知良好备用路径存在 → 先切换；
单端口疑似风暴源 → 先 disable；
变更后立刻异常 → 先 rollback；
业务恢复后 → 测试环境或维护窗口复现 → 定位根因。
“先恢复”不等于“乱恢复”。 有效止血须满足四个条件：动作可逆、影响范围可预期、具备回退命令、有人负责观察。直接重启核心设备通常不是第一选择；直接删除生产配置更不可取。
【踩坑】最常见的反面教材是把 shutdown 当根因修复。端口关闭后广播下降只能证明该端口与异常现象相关，尚不能证明它是故障源。下一步仍需检查对端、环路路径、配置差异和历史统计，否则同类故障会在下一次变更中复发。
11_1_4 四种定位方法
| 方法 | 核心思路 | 适用场景 | 操作要点 | 示例 |
|---|---|---|---|---|
| 分层法 | 从物理层向应用层逐层证伪 | 所有复杂故障 | 每层先查状态、再查配置、最后看统计 | 先看端口 up，再查 VLAN、MAC、路由 |
| 分段法 | 把端到端路径切成小段 | 完全不通、长路径 | 从近到远，或从中间向两边 | PC→接入→汇聚→核心→出口 |
| 对比法 | 比较正常与异常的相同维度 | 局部故障、批量设备 | 同型号、同版本、同业务才可比 | 正常端口与故障端口的速率、VLAN、统计 |
| 替换法 | 替换可疑部件或配置对象 | 物理层、兼容性问题 | 每次只替换一个变量 | 换光模块、跳线、端口、电源、配置片段 |
四种方法通常组合使用。分层法决定“查什么层”，分段法决定“查哪一段”，对比法快速缩小对象，替换法消除怀疑。专家与新手的差异，不在于知道更多命令，而在于能根据证据及时排除分支。
对比法的有效前提是“可比性”。 不能拿跨机房、跨版本、跨业务模型的端口直接比较。至少应核对：设备型号、软件版本、端口类型、协商方式、VLAN/PVID、对端设备、限速和风暴抑制、ACL/QoS、链路聚合状态。
11_1_5 分层排查模板（可背、可用）
第 1 层 物理层
检查：port up/down、光功率、线缆、模块、速率、双工、电源风扇
命令：show port <id>、show port <id> statistics、show transceiver（依型号）
正常指纹：up、协商一致、无持续错包、收发均有计数
典型故障：线缆断、模块坏、单纤异常、双工不匹配、光功率越界
第 2 层 数据链路层
检查：VLAN 成员与 PVID、MAC 表、STP 角色、聚合、环路检测
命令：show vlan、show port <id>、show fdb、show stp、show lacp
正常指纹：MAC 稳定、无漂移、STP 角色稳定、聚合 Selected 完整
典型故障：PVID 错、VLAN 未透传、环路、MAC 漂移、边缘端口误配
第 3 层 网络层
检查：接口 IP、直连可达、路由表、ARP/ND、ACL、NAT、TTL
命令：show ipport / show ip interface brief、show iproute、show arp
正常指纹：直连互通、去程回程都有、ARP 完整、无异常丢弃
典型故障：缺回程路由、ACL 拦截、地址池耗尽、TTL/MTU 异常
第 4 层 传输层
检查：TCP/UDP 端口开放、会话状态、重传、窗口、连接限制
命令：telnet/nc 测试、会话统计、抓包、镜像
正常指纹：握手完成、无大量重传、端口可达
典型故障：防火墙拦截、服务未启动、连接表耗尽、端口冲突
第 5-7 层 应用层
检查：DNS、认证、应用协议、证书、客户端配置、服务器负载
命令：dig/nslookup、应用日志、抓包、客户端复现
正常指纹：请求与响应成对、时延稳定、错误码明确
典型故障：DNS 错配、认证失败、版本兼容、服务器限流
分层模型的意义是“逐层排除”，不是机械逐层执行。对于全网瘫痪，应从二层环路和物理层开始；对于单业务异常，可直接从应用层往下交叉验证；对于跨网段不通，则优先验证三层双向可达。
| OSI 层级 | 检查内容 | 常用手段与命令 |
|---|---|---|
| 应用层（7） | DNS、认证、业务程序 | 抓包看请求/响应是否成对、错误码 |
| 表示层（6） | 编码、加密、证书 | 证书有效期与算法兼容性核对 |
| 会话层（5） | 会话保持与超时 | 会话表项、连接复用检查 |
| 传输层（4） | TCP/UDP、端口、重传 | telnet 探测端口、会话统计、抓包看重传 |
| 网络层（3） | IP、路由、ARP、ACL | show iproute、show arp、ACL 命中计数 |
| 链路层（2） | VLAN、MAC、STP、LACP | show vlan、show fdb、show stp、show lacp |
| 物理层（1） | 端口、光模块、线缆 | show port、光功率、替换法 |
分层模型的意义是"逐层排除"，不是机械逐层执行。 全网瘫痪优先从物理层与二层环路开始；单业务异常可直接从应用层往下交叉验证；跨网段不通则优先验证三层双向可达。
11_1_6 证据收集与变更控制基线
故障现场必须保留五类证据：
| 证据 | 收集内容 | 用途 |
|---|---|---|
| 配置 | 当前运行配置、启动配置、差异 | 判断是否配置漂移、可否回退 |
| 状态 | 端口、协议、CPU、内存、会话、表项 | 判断当前异常点 |
| 统计 | 清零前后计数、错包、丢包、带宽 | 判断增长量和影响端口 |
| 日志 | 系统日志、协议日志、操作日志 | 建立时间线 |
| 业务 | ping、应用拨测、抓包、用户描述 | 证明恢复与根因 |
每次现场变更应遵循“四个一”：一份备份、一个回退、一条验证、一人复核。 修改命令不宜直接敲入生产配置，应先准备文本、明确插入位置、预测正常输出，再逐条提交。一次修改多个变量会让“修复”失去证明力：即使业务恢复，也无法确认究竟是哪项动作有效。
【ZCIE】指导复杂故障时，还应明确指挥关系：谁负责收集证据、谁负责与业务方沟通、谁拥有配置变更权、谁判定回退。多人同时登录、各自尝试，是最典型的组织型二次故障。
11_2 排障命令树（按现象索引）
本节要解决什么问题：方法要变成肌肉记忆，就得按现象建索引。本节给出五类高频现象的命令决策树。
11_2_1 统一使用约定
【正常转向】看到该结果后，可排除当前分支，进入下一层。
【异常转向】看到该结果后，停止横向扩展，先验证当前对象。
【止血优先】出现广播风暴、CPU 打满、主备双主时，先隔离再分析。
【清零原则】统计判断前先记录基线；可复现环境执行 clear，生产环境记录初值。
命令中的 体系A 与 体系B 仅为常见风格示例。不同版本中，VLAN、STP、聚合、镜像等命令可能采用不同对象名或视图；执行前用 ? 确认，禁止凭记忆盲敲。
11_2_2 现象一：终端完全不通
┌─ show port <id> 端口是否 up？
│ 【正常】up、协商稳定、无 err-disable
│ 【异常】down / err-disable → 查线缆、模块、对端、电源；可替换法
│
├─ show port <id> 速率双工是否两端一致？
│ 【正常】两端 auto-auto 或同速率同双工
│ 【异常】一端 auto 一端 fixed → 统一协商策略
│
├─ clear statistics → wait → show statistics 错包是否增长？
│ 【正常】CRC/Align/Collision 不增长
│ 【异常】CRC 增长 → 物理层；Collision → 半双工/双工不一致
│
├─ show vlan、show port <id> VLAN 成员、Tag/Untag、PVID 是否正确？
│ 【正常】链路两端 VLAN 透传一致，untag 端口 PVID 与业务一致
│ 【异常】缺成员、PVID 错 → 出现“半通”
│
├─ show fdb port <id> 是否学到合法 MAC？
│ 【正常】单播 MAC 稳定、数量合理
│ 【异常】学不到 → 端口安全/MAC 限制/链路单向/对端未转发
│
├─ ping 网关 二层通但三层是否通？
│ 【正常】网关稳定响应
│ 【异常】不通 → 查网关、ARP、VLAN、IP 地址、ACL
│
├─ show iproute（本端 + 对端） 去程与回程路由是否都存在？
│ 【正常】双向均有精确或默认路由
│ 【异常】缺回程 → 补静态路由或动态路由通告
│
└─ 抓包/镜像 终端是否发包？网络是否回包？
【正常】请求与响应成对
【异常】只有请求 → 沿路径查 MAC/IP/ACL；只有响应 → 查回程
判定顺序比命令数量更重要。 若端口 down，继续查 STP 和路由没有意义；若端口 up 但 MAC 学不到，查 ACL 和三层路由意义也不大。每一层都应以“该层已正常”为转向条件，而不是把全部命令执行一遍。
11_2_3 现象二：网络慢 / 丢包
┌─ show port <id> statistics 错包与丢弃
│ 【正常】无 CRC、Align、Drop 持续增长
│ ├─ CRC 增长 → 物理层（模块/线缆/光功率）
│ ├─ Drop 增长 → 拥塞、策略或限速
│ └─ 无明显错包 → 问题可能在其他设备，向上游/对端分段
│
├─ 入向 vs 出向带宽对比 是否拥塞？
│ 【正常】利用率未接近端口带宽且无明显突发
│ 【异常】某方向打满 → QoS/队列/限速是否生效
│
├─ show stp、show fdb 是否有环路/漂移？
│ 【正常】根桥稳定、MAC 不漂移
│ ├─ STP 拓扑频繁变 → 查边缘端口/BPDU/单向链路
│ └─ MAC 漂移 → 环路或私接设备
│
├─ broadcast/multicast 占比 是否存在风暴？
│ 【正常】占比低且稳定
│ 【异常】广播占比异常 → 隔离可疑端口，再开 STP/环路检测
│
├─ MTU 检查 小包通、大包不通？
│ 【正常】大包 ping 与业务均正常
│ 【异常】DF 大包失败 → 逐跳查 MTU、隧道、分片/DF
│
└─ traceroute + 长 ping 哪一跳开始丢包？
【正常】每跳稳定
【异常】固定跳异常 → 查该设备队列、ACL、链路；随机跳 → 多路径/负载分担
慢与丢包并非同一问题。慢通常是带宽、队列、CPU、MTU、应用处理或路径不对称；丢包则还需要关注错包、拥塞、ACL、TTL 和会话表。若大包失败而小包成功，应优先把 MTU 设为独立假设，而不是继续调整路由。
11_2_4 现象三：全网瘫痪（最紧急）
【0-5 分钟：止血】
① 尝试管理登录；无法登录时准备 Console/带外接入
② 查看 CPU、内存、端口流量、广播/丢弃计数
③ 找出异常增长最快的端口/VLAN/协议
④ set port <id> disable 或物理隔离可疑链路
⑤ 通知业务方，记录当前时间与操作
【5-15 分钟：定位】
⑥ show stp 根桥是否正确、端口角色是否震荡
⑦ show fdb MAC 漂移模式 → 推断环路位置
⑧ show loopdetect 是否有端口被判定成环
⑨ 检查近期变更：接入设备、跳线、端口、配置模板
⑩ 核对端口描述、标签、拓扑与现场实际连接
【15-30 分钟：加固与恢复】
⑪ 逐步恢复非可疑端口，避免一次性全开
⑫ 启用 STP、边缘端口、BPDU 保护；确认范围后启用环路检测
⑬ 业务验证：关键网关、代表性终端、核心应用
⑭ 观察不少于 30 分钟，确认无拓扑震荡
【后续】
⑮ 根因分析、复盘、更新模板
⑯ 完善端口描述、拓扑、告警与巡检
全网瘫痪的第一动作不是“show run”。 应先用最少命令确认异常聚集点：哪台设备 CPU 高、哪个端口流量异常、哪个 VLAN 的 MAC 漂移。若已经明确风暴源，隔离端口通常比全网启用新协议更快、更可控。
【踩坑】批量开启 STP 或环路检测时，必须预先排除上行口、聚合口和跨设备路径。否则防环机制本身可能把正常冗余链路阻塞，将局部故障放大为整楼/整网故障。
11_2_5 现象四：组播/IPTV 异常
┌─ show igmp snooping 全局是否 enable？
│ 【正常】业务 VLAN 已在监听表
│ 【异常】disable → 组播泛洪，尤其高峰明显
│
├─ show igmp snooping vlan <id> 目标 VLAN 是否监听？
│ 【正常】VLAN、版本、抑制参数符合设计
│ 【异常】未加入 → 显式添加业务 VLAN
│
├─ show igmp snooping vlan <id> host 成员表项、组地址
│ 【正常】机顶盒 Join 后出现对应 (S,G)/(*,G)
│ 【异常】无成员 → 查终端、上行路由端口、过滤规则
│
├─ show igmp snooping vlan <id> router 路由端口是否存在？
│ 【正常】能识别组播源方向
│ 【异常】无 router port → 查 PIM/IGMP querier/Trunk 透传
│
├─ show igmp filter 是否误过滤？
│ 【正常】业务组地址未被过滤
│ 【异常】规则命中 → 调整过滤策略
│
├─ show port <id> statistics 端口丢包、带宽、优先级
│ 【正常】无丢包、组播流量受控
│ 【异常】出向满速 → Snooping/CAC/QoS 检查
│
└─ 抓包（igmp 过滤） 机顶盒 Join、交换机转发
【正常】Join 到路由端口、组播仅到成员口
【异常】只有 Join 无响应 → 上游/querier；全端口泛洪 → Snooping
组播“部分卡顿”和“全部卡顿”的排查方向不同。单用户卡顿优先查机顶盒、接入端口、成员表和带宽；全部用户卡顿往往意味着 Snooping 未生效、路由端口缺失、组播源异常或 VLAN 未端到端透传。
【验证】修复后不能只 ping 通，要同时满足：成员表项存在、非成员口不再收到业务组播、关键频道连续播放、高峰出口带宽未溢出。
11_2_6 现象五：冗余倒换异常
┌─ show vrrp 主备状态、虚拟 IP、优先级
│ 【正常】一主一备，无双主
│ ├─ 双主 → 查通告路径、链路、认证、VLAN、track
│ └─ 双备 → 查优先级、抢占、互联可达
│
├─ show vrrp + track 上行/链路跟踪是否正确？
│ 【正常】上行故障时主降优先级，备接管
│ 【异常】未联动 → 补充 track 与延迟
│
├─ show lacp aggregator/neighbors 聚合成员、Selected 状态
│ 【正常】两端成员一致、Selected
│ 【异常】Unselected → 速率/双工/VLAN/聚合模式不一致
│
├─ show stp instance <id> 根桥、端口角色、保护
│ 【正常】角色稳定、无 TC 震荡
│ 【异常】根桥漂移 → 优先级/边缘端口/BPDU 保护
│
├─ show bfd session BFD 会话、参数
│ 【正常】Up、检测时间两端匹配
│ 【异常】Down/参数不一致 → 查链路、间隔、认证、联动
│
├─ show iproute 主备路由是否符合设计？
│ 【正常】主路径优先，备路径可达
│ 【异常】路由未收敛 → 查 IGP/BGP、cost、FRR、track
│
└─ 实测倒换：shutdown 主链路，长 ping 中断时长、回切行为
【正常】中断在业务容忍范围内，无双主/黑洞
【异常】超时/丢包过多 → 优化检测、收敛与切换策略
冗余系统最容易被误判为“配置好了”，但真正的能力标准是实测倒换。未做倒换测试的 VRRP、聚合和路由保护，只能证明控制面存在，不能证明业务连续。
11_3 典型故障案例库
本节要解决什么问题：案例是方法论最好的注解。本节收录多个真实场景，每个都按现象、排查、根因、处理、沉淀展开。
11_3_0 案例阅读方法
每个案例均按 现象 → 排查 → 根因 → 解决 → 沉淀 → 反思 展开。“反思”不是事后批评，而是明确：如果当时先做哪一项，能把多长时间的试错压缩为定向验证。建议学习阶段将每个案例复现为实验，记录真实输出，而不是只阅读结论。
11_3_1 案例一：PVID 漏配导致的“半通”
【现象】
新接入一台交换机，业务 VLAN10 中部分终端能上网，部分不能；同一 VLAN 内
部分终端可以互访，跨网段访问不稳定。
【排查】
① show port 5 → 端口 up，速率双工正常
② show vlan 10 → port 5 在 VLAN10 成员列表中，模式为 untag
③ show port 5 → pvid = 1，而非预期的业务 PVID 10
④ 从终端长 ping 网关 → 部分源 MAC 无法在正确 VLAN 内被学习
【根因】
只执行 set vlan 10 add port 5 untag，漏执行 set port 5 pvid 10。
出方向：交换机按 VLAN10 成员关系剥离 tag，转发看似正常；
入方向：终端报文被端口打上 PVID1，进入错误广播域 → 单向或半通。
【解决】
体系A：
zte(cfg)#set port 5 pvid 10
体系B：
ZXR10(config)#interface gei_1/5
ZXR10(config-if)#switchport pvid 10
【沉淀】
① untag 成员关系与 PVID 必须成对配置、成对验收；
② 开局模板应写成“vlan 成员 + pvid + description”原子片段；
③ 验收必须同时测“同 VLAN、跨 VLAN、网关、回程”。
【反思】
如果先在拓扑中区分“Tag 上行口”和“untag 接入口”，并对每个接入口做
“show vlan + show pvid”一键检查，5 分钟内即可发现，而不必逐终端替换。
“半通”往往是双向处理不对称的第一信号。 PVID、路由去程/回程、NAT 内外方向、ACL in/out 都属于这一类。排查时应主动问：请求走的是哪条路径，响应回来时是否仍是同一逻辑对象。
11_3_2 案例二：双工不匹配导致的“时通时断”
【现象】
某服务器访问时快时慢，ping 有规律性丢包，大文件传输极慢；业务峰值更高。
【排查】
① clear port 3 statistics → 复现 1 分钟 → show port 3 statistics
② Late Collision、Alignment 错误持续增长
③ show port 3 → 交换机侧 1000M/Full 手工锁定
④ 服务器侧为 auto → 实际回退为半双工或低速率
【根因】
一端锁定、一端自协商，导致双工认知不一致；全双工侧不感知碰撞，
半双工侧产生冲突和错包，形成间歇丢包与重传。
【解决】
两端统一为 auto（推荐，支持自协商时）；或两端统一手工锁定相同速率/双工。
修改前必须确认对端可同时变更，避免一端先改造成短时中断。
【沉淀】
① 速率与双工两端必须一致；
② 服务器、存储、老旧设备优先纳入协商策略表；
③ “三步清零法”：clear → 复现 → show；只看增量。
【反思】
如果先比对两端协商结果而非反复 ping，10 秒内即可定位；
若服务器正在承载生产业务，应优先采用可灰度、可回退的接口组策略。
【验证】修复后执行连续大包测试与统计观察：Late Collision/Alignment 应停止增长，吞吐稳定，CPU 软中断不应异常。
11_3_3 案例三：私接交换机引发的广播风暴
【现象】
整层楼网络变慢，接入交换机 CPU 飙升至 90%+，部分终端无法访问网关。
【排查】
① show port 1-24 statistics → port 12 广播包速率异常高
② show fdb → 多个 MAC 在 port 12 与其他端口间漂移
③ show stp → STP 未启用
④ 现场查 port 12 → 用户私接家用交换机，且形成环路
【处理】
① set port 12 disable 立即止血
② 逐台接入开启 STP
③ 边缘端口 + BPDU Guard
④ 恢复 port 12 并持续观察
【解决（示意）】
体系A：
zte(cfg)#set port 12 disable
zte(cfg)#set stp enable
zte(cfg)#set stp edge-port add port 1-24
zte(cfg)#set stp port 1-24 bpdu-guard enable
体系B：
ZXR10(config)#spanning-tree enable
ZXR10(config)#interface range gei_1/1-24
ZXR10(config-if-range)#spanning-tree portfast
ZXR10(config-if-range)#spanning-tree bpduguard enable
【沉淀】
① 边缘端口 + BPDU 保护是接入层标配；
② 闲置端口 disable、加入 Guest VLAN 或 MAC 限制；
③ 端口描述与现场标签必须一致。
【反思】
如果接入层开局模板默认包含 STP/BPDU Guard/风暴抑制，现场只需定位端口；
省下的不是几分钟，而是从“全网慢”到“单端口隔离”的事故等级下降。
11_3_4 案例四：回程路由缺失（三层排障第一坑）
【现象】
新增业务网段 192.168.50.0/24，用户能 ping 通本地网关，
但访问服务器 10.0.10.100 不通；反向也无法 ping 用户。
【排查】
① 用户 ping 网关 → 通，说明二层与网关基本正常
② 核心 show iproute → 存在到 10.0.10.0/24 的去程路由
③ 服务器侧 ping 用户 → 不通
④ 服务器网关 show iproute → 没有 192.168.50.0/24 的回程路由
【根因】
只配去程，未配回程；“有去无回”使响应报文无法回到源网段。
【解决】
在服务器网关补静态路由，或将新网段纳入动态路由通告；同时核对明细路由、
下一跳、路由过滤和 ACL。回退方案是预先保存原路由表。
【沉淀】
① 三层排障必查双向路由；
② 建立网段—网关—通告方式—对端回程的路由矩阵；
③ ping 不通时，先问“对端能不能回来”。
【反思】
如果变更前先画“源→目的→回程”三段箭头，并在两端同时采集路由表，
可避免把单向可达误判为全网问题。
去程与回程必须被视为两个独立事实。 ACL、防火墙、源地址转换同样会造成“单向不可达”。因此验证时至少进行正向、反向、源接口指定三层测试。
11_3_5 案例五：IGMP Snooping 未开导致 IPTV 全网卡顿
【现象】
IPTV 上线后，晚高峰所有用户卡顿，宽带上网也变慢；接入端口流量接近满速。
【排查】
① show igmp snooping → disable（常见缺省关闭）
② show port 1-24 statistics → 各端口出向流量均接近满速
③ 抓包确认每个端口均收到大量未订阅频道组播流
【根因】
未开 IGMP Snooping，组播在 VLAN 内泛洪；接入链路被全频道流量占满。
【解决】
① set igmp snooping enable
② set igmp snooping add vlan <业务VLAN>
③ 验证：show igmp snooping vlan <id> host 出现成员表项
④ 抓包确认未加入端口不再收到对应组播流
【沉淀】
① 组播业务上线前，Snooping 是必须项；
② 同时规划 querier、路由端口、CAC、QoS；
③ 上线验收采用“频道加入/离开/换台/高峰带宽”四项。
【反思】
如果上线 checklist 中有“组播是否泛洪”这一项，故障在方案评审即可发现；
不必等到用户投诉后才从满速端口反推。
11_3_6 案例六：MSTP 区域不一致导致 VLAN 时通时断
【现象】
部分 VLAN 间歇性不通，STP 拓扑频繁变化，部分路径偶发阻塞。
【排查】
① 全网点对点 show stp / show spanning-tree
② 发现一台接入交换机 region name 拼写错误
（示例：ZTE-CAMPUS 误写为 ZTE-CAMUPS）
③ 核对 revision、VLAN 映射 → 三要素不一致
【根因】
MSTP 区域三要素（名称、版本号、VLAN 映射）不一致，该设备被视为不同区域；
跨区域只能走 CIST，预期的多实例负载/阻塞设计失效，部分 VLAN 转发异常。
【解决】
① 统一 region 名称、版本、映射；建议复制粘贴，不手工输入
② 必要时 reset/重启 STP 进程，并在维护窗口执行
③ 逐设备 show 比对，先核心后接入，避免中间过渡状态放大
【沉淀】
① 区域配置纳入版本基线；
② 上线前点对点比对三要素；
③ 变更前保存每台设备的 MSTP 摘要。
【反思】
如果先对比正常区域与异常区域的三要素，而不是逐个端口查 STP 状态，
定位时间可从数十分钟压缩到一次 show 比对。
11_3_7 案例七：VRRP 双主导致的地址冲突
【现象】
用户上网时断时续，日志大量 IP 地址冲突告警；网关 ping 时通时断。
【排查】
① 两台核心 show vrrp → 两台均显示 Master
② 查核心互联链路 → 聚合组中一条链路故障
③ 抓包/统计发现 VRRP 通告报文哈希到故障链路
④ Backup 收不到通告，等待超时后升主 → 双主
【根因】
VRRP 通告路径存在单点；主备间可达性依赖的链路状态与上行 track 不一致。
【解决】
① 修复聚合组故障成员，恢复多路径可达
② 为 VRRP 配置独立心跳链路，或增加备份通告路径
③ 配置上行 track、合理优先级与抢占延时，避免震荡
④ 实测主链路/上行故障倒换
【沉淀】
① 冗余设计不能让“控制通告路径”成为单点；
② 聚合成员、链路、BFD/ Track 状态必须可验证；
③ 双主告警必须纳入一级监控。
【反思】
如果变更聚合后立即做“shutdown 一条成员链路 + VRRP 状态”测试，
故障不会等到业务高峰期才暴露。
11_3_8 案例八：单向光纤引发的“幽灵环路”
【现象】
某汇聚与接入链路每隔几小时出现一次短暂广播风暴，持续数十秒后自行恢复；
日志中 STP 拓扑频繁变化，白天难复现，常规 ping 无明显异常。
【排查】
① show port statistics → 无明显 CRC 增长，初步排除常规物理错包
② show stp → 该端口角色反复变化（Designated ↔ Forwarding）
③ 启用 BPDU 调试：
debug spantree bpdu-rx
debug spantree bpdu-tx
→ bpdu-tx 持续有输出：本端在发送
→ bpdu-rx 长时间无输出：本端未收到对端 BPDU
④ 更换跳线、模块、清洁光口后，bpdu-rx 恢复计数
【根因】
单向链路：光纤收发一芯故障或模块单向老化。
本端收不到对端 BPDU，STP 认为对端失效 → 端口进入 Forwarding；
对端仍可收到本端报文 → 形成单向转发环路。
链路偶发恢复时环路暂时消失，故呈现“间歇性风暴”。
【处理】
① 更换光纤跳线、光模块，清洁光口；按替换法逐件确认
② 修复后验证：bpdu-rx、bpdu-tx 均有稳定计数
③ 关键端口启用 Loop Guard / UDLD（依型号和版本支持情况确认）
④ STP 收不到 BPDU 时保持阻塞，避免盲目转发
【沉淀】
① “间歇性风暴 + 无 CRC 报错”是单向链路的典型指纹；
② 常规 ping 未必暴露单向链路，尤其只验证一个方向时；
③ debug spantree bpdu-rx/tx 的“只发不收”是直接判据；
④ 关键链路预防：Loop Guard + UDLD + 光功率基线 + 双向计数。
【反思】
如果先按“周期性风暴”建立 24 小时统计和 BPDU 计数基线，
而不是一出现风暴就全局重启 STP，可更快锁定单链路；
但 debug 仅限维护窗口或明确必要性时使用，注意日志量和控制面影响。
汇聚交换机 接入交换机
┌──────────────┐ TX 光 ┌──────────────┐
│ │──────────────▶│ │
│ 正常发送 │ │ 能收到 │
│ 收不到 │◀── 故障光纤 ──│ 仍在发送 │
│ │ （RX 无） │ │
└──────────────┘ └──────────────┘
结果：本端认为对端失效，端口 Forwarding；对端仍收到本端帧 → 单向环路
11_3_9 案例九：环路检测误开在上行口导致整楼断网
【现象】
接入交换机完成配置后，下联全部用户同时断网；上行口物理灯正常，
但业务不通。
【排查】
① 登录交换机，show port → 上行口状态为 block，而非 down
② show loopdetect port 23 → isLoop=Yes、isBlock=Yes
③ 查配置：开局模板批量把 loopdetect 应用到 port 1-24
④ 上行口 23/24 也包含在内
【根因】
上行口发出的环路探测报文，经核心或其他路径被转发回来；
环路检测误判为“本端口成环”，将上行口阻塞。
上行口一 block，整台交换机所有下联用户断网。
【处理】
① 立即关闭上行口环路检测：set loopdetect port 23-24 disable
② 确认用户恢复，检查无其他阻塞端口
③ 修正模板：环路检测只开面向终端的 1-22
④ 保留变更回退脚本并复核端口范围
【解决（示意）】
体系A：
zte(cfg)#set loopdetect port 23-24 disable
zte(cfg)#show loopdetect
体系B：命令对象与接口范围依版本确认，原则是明确排除上行/互联口。
【沉淀】
① 环路检测只开面向终端的接入端口；
② 上行口、核心互联口、聚合口、跨设备 Trunk 一律排除；
③ 批量范围（如 1-24）是高危误配源，必须逐段确认；
④ 端口 description/byname 是最后防线。
【反思】
如果模板写成“用户口 list + 上行口排除 list”，并在提交前 grep 一次上行口，
5 秒即可预防；这是典型“配置可语法正确、逻辑却致命”的案例。
11_3_10 案例十：MTU 不一致导致大包业务随机失败
【现象】
某跨机房业务小文件、SSH、短请求正常，但数据库同步、备份和文件上传经常中断；
路径中间经过隧道或运营商链路。
【排查】
① 小包 ping 全路径正常
② 指定 DF=1、逐步增大 ICMP 载荷测试 → 超过某值后失败
③ 逐跳 show interface mtu / 检查隧道 MTU
④ 抓包发现中间设备丢弃 DF 大包，无正常分片回显或 ICMP 不可达策略受限
【根因】
路径 MTU 不一致：服务器、交换机、隧道接口 MTU 设计未统一；
大于路径最小 MTU 的报文被丢弃，TCP 重传和上层超时导致业务失败。
【解决】
① 统一规划以太网、VLAN、隧道 MTU 基线；
② 对确需大包的路径确保 DF 允许分片或启用 PMTUD；
③ 防火墙/ACL 策略确认不丢弃必要的 ICMP 不可达；
④ 在维护窗口逐步变更，避免一次性修改所有接口。
【沉淀】
① 拓扑中应维护“链路—隧道—VLAN—接口 MTU”矩阵；
② 验收必须含大包、长流、并发三项；
③ “小包通大包不通”优先假设 MTU，而不是路由。
【反思】
如果变更前对整条路径做一次 MTU 扫描，无需等数据库告警即可发现断点；
同时避免为了“解决一个业务”盲目全局改 9000。
11_4 巡检与变更管理体系
本节要解决什么问题：排障是被动的，巡检与变更管理才是主动的。本节把「少出事」拆成可执行的清单。
11_4_1 三级维护体系
| 级别 | 周期 | 主要内容 | 执行者 | 产出 |
|---|---|---|---|---|
| 日常巡检 | 每日 | 自动采集、告警、关键性能、备份状态 | 运维/自动化 | 巡检报告、异常单 |
| 定期维护 | 每月/季度 | 配置备份验证、容量、安全策略、冗余演练 | 运维工程师 | 维护报告、整改项 |
| 专项维护 | 按需 | 升级、容量改造、架构优化、应急演练 | 高级工程师 | 方案、评审、演练记录 |
巡检的目的不是“证明设备活着”，而是识别偏离基线的变化。版本、运行时长、端口 flap、MAC 漂移、路由数量、CPU 基线、备份成功率都应做趋势比较。
11_4_2 每日巡检清单
【设备健康】
□ show version 版本、运行时长；异常重启/切换须追查
□ CPU/内存利用率 超过设计阈值即关注，而非只看是否 100%
□ 温度、风扇、电源 冗余电源状态、告警
□ 日志与告警 严重告警、认证失败、端口 err-disable
【端口与链路】
□ show port up/down、err-disable、flap
□ show port statistics 错包、丢包、广播占比；建议先记录基线
□ TopN 带宽端口 接近阈值时分析突增业务
□ 光功率 超出范围即列入替换计划
【二层】
□ show stp 根桥、TC、端口角色、保护
□ show fdb MAC 数量、漂移、老化异常
□ show lacp 聚合 Selected 成员完整
□ show loopdetect 是否存在 block 端口；误开范围检查
【三层】
□ show iproute 路由数量、默认路由、邻居变化
□ show arp ARP 数量、异常表项
□ show vrrp 主备状态、track
【业务】
□ show igmp snooping 组播成员、路由端口
□ 关键业务拨测 网关、DNS、核心应用、跨区路径
11_4_3 定期维护清单
月度：
□ 配置备份 + 恢复抽验（至少 1 台）
□ 日志分析、告警收敛、资产信息更新
□ 带宽/CPU/会话趋势分析
□ ACL、账号、SSH/管理面策略复核
季度：
□ VRRP/LACP/路由冗余倒换演练
□ 环路、核心故障应急流程演练
□ 端口描述、标签、拓扑核对
□ 版本与补丁评估、备件/光模块盘点
年度：
□ 容量规划与扩容评估
□ 架构优化、单点排查
□ 运维文档、拓扑、密码托管、回退库更新
11_4_4 配置备份策略
备份三原则：
① 定时：每次变更后必须备份；无变更时至少每周一次
② 异地：备份文件存放于独立服务器/对象存储，禁止仅留设备本地
③ 可恢复：定期抽验恢复；未验证的备份不等于可用备份
命名规范：
<设备名>_<日期>_<变更单号>.cfg
示例：CORE-01_20260903_CHG-2026-0088.cfg
备份内容建议：
- running-config / startup-config
- 版本、补丁、license 信息
- 端口与光模块信息
- 路由表、ARP/FDB 基线（用于恢复后对比）
- 变更前后差异 diff
【ZCIE】备份本身也应纳入验证：随机抽取设备，在隔离环境中恢复配置，确认版本兼容、启动无报错、关键协议正常。只 copy 文件而不验证恢复，无法证明备份可用于真实故障。
11_4_5 变更管理流程
┌────────────────┐
│ ① 变更申请 │ 目的、范围、影响、时间窗口、关联告警
└───────┬────────┘
▼
┌────────────────┐
│ ② 方案评审 │ 技术可行性、风险、依赖、回退、业务确认
└───────┬────────┘
▼
┌────────────────┐
│ ③ 预备份 │ 配置、状态、业务基线；生成差异计划
└───────┬────────┘
▼
┌────────────────┐
│ ④ 实施 │ 脚本化、逐条确认、记录实际输出
└───────┬────────┘
▼
┌────────────────┐
│ ⑤ 验证 │ 功能、性能、冗余、业务；对照验收矩阵
└───────┬────────┘
▼
┌────────────────┐
│ ⑥ 观察 │ 不少于 30 分钟；关键变更延长观察
└───────┬────────┘
▼
┌────────────────┐
│ ⑦ 回退/关闭 │ 触发条件达成即回退；关闭后归档
└────────────────┘
回退不是失败，而是控制风险的正常分支。 每次变更都应预先定义：回退触发条件（业务异常、关键协议 down、统计异常）、回退命令、回退责任人、回退时限。没有回退方案的变更，不应进入生产窗口。
11_4_6 变更记录与回退模板
【变更编号】CHG-XXXX-XX
【标题】为接入交换机接入新业务 VLAN，并调整上行 Trunk
【变更等级】P2 / 低风险 / 影响一个接入域
【变更窗口】业务低峰期，预计 30 分钟；回退时限 10 分钟
【执行人】 【复核人】 【业务确认人】
【变更前状态】
- 当前配置备份：ACC-12_YYYYMMDD_pre.cfg
- 关键基线：show vlan、show stp、show lacp、ping 基线、业务拨测
【操作步骤】
步骤1（可逆）：在测试端口验证 VLAN/PVID 配置
步骤2（可逆）：上行口增加业务 VLAN，逐条确认
步骤3（需观察）：接入端口加入业务 VLAN
步骤4：验证
【验证矩阵】
- 新业务 DHCP、网关、跨网段、DNS
- 原有业务无丢包、无新增 MAC 漂移
- 上行 Trunk 仅允许预期 VLAN
- STP/LACP/VRRP 状态不变
【回退触发条件】
- 原有业务丢包或中断
- 上行口 err-disable / STP block 异常
- 新业务 10 分钟内无法验证通过
【回退步骤】
1. 恢复上行口原始 Trunk 配置
2. 将接入端口移出新 VLAN
3. 加载 ACC-12_YYYYMMDD_pre.cfg（仅在严重异常时使用）
4. 复核 show、ping、业务拨测
【变更后记录】
- 实际开始/结束时间
- 与预期差异
- 是否触发回退：是 / 否
- 遗留问题与跟踪人
11_5 复盘模板与笔记方法
本节要解决什么问题：复盘模板用久了，就是将来答辩的素材库。本节给出模板并说明每一栏为什么必须填。
11_5_1 故障复盘的核心不是追责
复盘的目标是建立可复用的因果链：触发条件是什么、为何没在测试期发现、现有监控哪里漏报、哪些措施能防止同类问题。有效的复盘必须包含时间线、证据、直接原因、根本原因、改进项和验证项；缺少任何一项，都会退化为“改了配置”的流水账。
【故障编号】INC-XXXX-XX
【等级】P1/P2/P3 【影响范围】区域、业务、用户数（估算即可）
【发生时间】 【恢复时间】 【总耗时】
【处理人】 【复核人】
【一、故障现象】
- 用户/监控系统最初报告什么？
- 哪些对象正常、哪些异常？
- 是否间歇性、是否随变更发生？
【二、时间线（按时间顺序，禁止倒推改写）】
HH:MM 事件/操作/证据
HH:MM 登录设备，CPU 85%，广播异常
HH:MM 定位 port 12，执行 set port 12 disable
HH:MM 业务恢复，开始保留证据
HH:MM 根因验证、加固、复盘
【三、处理过程】
- 采用的方法：分层/分段/对比/替换
- 每一步假设、证据、结论
- 哪些操作有效、哪些无效、哪些是试探
【四、根因分析】
直接原因：导致现象的最近一层原因
根本原因：流程、模板、监控、设计层面的原因
关联因素：变更、容量、版本、人员、文档
【五、解决方案】
- 应急止血
- 临时措施
- 永久措施
【六、改进项】
| 编号 | 改进项 | 责任人 | 截止时间 | 验证方式 |
| ---- | ------ | ------ | -------- | -------- |
| 1 | | | | |
【七、知识沉淀】
- 一句话结论
- 关联知识点/命令/案例
- 是否纳入开局模板、巡检、监控、演练
【八、答辩/教学价值】
- 现场关键判断点
- 容易误判的分支
- 可复用的证据与命令
11_5_2 巡检记录表
【巡检日期】 【巡检人】 【设备范围】
【巡检类型】日常 / 月度 / 季度 / 专项
| 维度 | 检查项 | 正常标准 | 实际结果 | 结论 |
| ---- | ------ | -------- | -------- | ---- |
| 设备 | 版本、运行时长、CPU、内存 | 无异常重启、未超阈值 | | OK/异常 |
| 电源风扇 | 冗余状态 | 无告警 | | |
| 端口 | up/down、err-disable、错包 | 无新增异常 | | |
| 二层 | STP/FDB/LACP/loopdetect | 角色稳定、无漂移 | | |
| 三层 | 路由/ARP/VRRP | 主备正常、双向可达 | | |
| 业务 | IPTV/语音/关键应用 | 拨测通过 | | |
| 备份 | 配置/状态/差异 | 成功且可恢复 | | |
【异常摘要】
【待办事项】
【下次巡检重点】
11_5_3 变更与回退记录模板
【变更编号】CHG-XXXX
【状态】草稿 / 评审中 / 执行中 / 验证 / 已关闭 / 已回退
【风险等级】低 / 中 / 高
【背景与目标】一句话说明为什么改、业务收益
【影响范围】设备、VLAN、路由、用户、依赖系统
【前置条件】权限、窗口、备件、备份、人员
【变更步骤】1. 2. 3. ……（含命令）
【验证清单】功能/性能/冗余/业务
【回退条件】明确可量化的触发标准
【回退步骤】明确、可执行、已评审
【关闭标准】验证通过、观察完成、文档更新
11_5_4 【笔记方法】为什么坚持用模板就是将来答辩的素材库
答辩不是背诵命令清单，而是呈现“见过问题—收集证据—控制风险—形成结论”的能力。每一份带时间线、真实输出和根因的复盘，都是可用于答辩的第一手材料。相反，只有“STP 要开启”这类结论，无法证明候选人具备复杂故障处理能力。
建议建立三类长期资产：
- 故障库：现象指纹、证据命令、根因、修复、预防。
- 变更库：每次生产操作的差异、验证、回退、遗留问题。
- 实验库：故意构造的故障、预期输出、真实输出、差异分析。
【模板使用纪律】
① 故障发生即建时间线，不等恢复后回忆；
② 粘贴真实 show/log/抓包摘要，不重写“理想输出”；
③ 每个案例至少写一条“下次先做 X”；
④ 每季把重复根因提炼为巡检项或开局基线；
⑤ 答辩前以“现象—证据—决策—结果”重讲一遍。
11_5_5 【案例故事】反复改配置，把单点故障做成二次事故
那天凌晨，接入层报告某业务 VLAN 间歇性丢包。我第一反应不是看统计增量，而是连续改了 PVID、STP 边缘端口和限速，心想“总有一个能命中”。结果丢包没消失，聚合口反而因一端速率被误改而 Unselected，故障从单个 VLAN 扩散到整台接入交换机。
我立刻停止新增操作，回退到变更前配置，业务在两分钟内恢复。随后只做三件事：先 clear port statistics，再让现场以固定频率 ping；发现 port 12 的广播计数每分钟增长约 40 万，其他端口几乎不变。show fdb 显示同一 MAC 在 port 12 与 uplink 间来回漂移。此时才确认，根因仍是私接设备形成环路，而不是我之前猜测的 PVID。
clear port 12 statistics
sleep 60
show port 12 statistics
show fdb | include <漂移MAC>
这次让我记住一条纪律：现场每 10 分钟没有新证据，就回看最近一次变更。 之后我把“变更前保存差异、每次只变一个变量、异常即回退”写进自己的故障处理清单。原来以为快速试错效率高，实际是把可定位的单点问题，升级成无法归因的复合故障。
11_5_6 【案例故事】抓包定位 MTU：小包能通不代表路径完整
某次跨机房备份任务总在传输大文件时中断。起初我反复检查路由和 ACL，因为 32 字节 ping 全通，TCP 短连接也正常。业务方已准备更换服务器，我坚持先做一次大包扫描。
从源端向目的端递增 ICMP 载荷，并设置 DF。测试结果在 1472 字节以下稳定，超过后全部失败。接着在源、接入、核心、目的四点的镜像口同时抓包，发现中间隧道接口 MTU 为 1500，而承载 VLAN 的 MTU 规划不一致，DF 报文无法通过。
ping -s 1472 -M do <目的IP> # 通
ping -s 1500 -M do <目的IP> # 不通
修复不是盲目全局改成巨帧，而是先把相关接口、隧道和服务器网卡的 MTU 基线对齐，并在维护窗口逐段验证。之后连续传输测试不再中断。这个案例沉淀为我的标准验收项：任何跨机房链路，必须同时测小包、最大预期业务包、并发长流。 小包成功只能证明控制面与基本转发可达，不能证明完整路径支持业务报文。
11_6 【验证】故障修复后的统一验收
本节要解决什么问题：修完不等于修好。本节给出故障修复后的统一验收清单，避免「配置变了但根因还在」。
11_6_1 验证原则
验证必须从“命令看起来成功”升级为“业务证据闭环”。每项验证都应预先定义预期字段；只有正常、异常两种结果，不应出现“大致正常”。涉及冗余和性能的场景，还应做故障注入与持续观察。
11_6_2 验证命令矩阵
| 验证命令 | 预期结果/关键字段 | 不符时的排查方向 |
|---|---|---|
show port <id> |
up、双工/速率稳定、无 err-disable | 线缆、模块、对端、电源、协商策略 |
show port <id> statistics |
CRC/Align/Collision/Drop 不增长 | 清零后复现；物理层、拥塞、策略、双工 |
show transceiver（依型号） |
收发光功率在规格范围、温度正常 | 跳线、模块、清洁度、单纤、端口 |
show vlan + 端口 PVID |
成员关系、Tag/Untag、PVID 一致 | 漏配成员、PVID 错、Trunk 透传不全 |
show fdb |
MAC 稳定、无异常漂移、数量合理 | 环路、私接、端口安全、镜像误配 |
show stp / show spanning-tree |
根桥符合设计、角色稳定、无频繁 TC | 区域三要素、边缘端口、BPDU、单向链路 |
show lacp / show smartgroup |
成员全 Selected、两端一致 | 速率双工、聚合模式、VLAN、负载策略 |
show iproute |
去程、回程、默认路由完整 | 静态路由、IGP/BGP 通告、过滤、下一跳 |
show arp / show ip arp |
网关、对端 ARP 完整且不异常老化 | 代理 ARP、VLAN、端口安全、ARP 限速 |
show vrrp |
一主一备、track 正确、无双主 | 通告路径、优先级、认证、上行 track |
show igmp snooping vlan <id> |
host/router 表项正确、组地址匹配 | Snooping 使能、querier、过滤、VLAN 透传 |
ping <网关> + ping <远端> |
双向稳定、无丢包或符合 SLA | 按分层法从近到远分段 |
traceroute |
每跳稳定，路径符合设计 | 多路径、ACL、TTL、逐跳队列 |
大包 ping -M do |
最大业务包可通过 | MTU、隧道、分片策略、DF |
shutdown 主链路 + 长 ping |
中断时长达标、无双主/黑洞 | BFD、track、优先级、切换策略 |
| 抓包/镜像 | 请求与响应成对、无异常重传 | 会话状态、ACL、服务、MTU、CPU |
11_6_3 观察期与验收边界
- 普通单端口修复：至少观察 10 分钟，覆盖一个业务周期。
- 二层环路、STP、组播修复：至少观察 30 分钟，确认无 TC 震荡、MAC 漂移、风暴复发。
- 冗余与核心变更：完成倒换、回切两轮实测，且业务长测通过。
- 容量与性能变更：在业务高峰期或模拟峰值下复测，不能只在工作日低峰验收。
【验证】观察期内至少要回答：异常计数是否归零、协议角色是否稳定、用户是否确认业务恢复、监控是否出现延迟告警。四者缺一，不建议关闭故障单。
11_7 排障思维进阶（【ZCIE】）
本节要解决什么问题：到 ZCIE 层级，考的是在信息不完整时如何推进。本节讲假设驱动、证据链与决策取舍。
11_7_1 从“会排障”到“能指导排障”
| 层次 | 主要表现 | 关键能力 |
|---|---|---|
| 初级 | 按文档逐条尝试命令 | 熟悉基本命令、能复现现象 |
| 中级 | 按分层法系统排查 | 建立假设、读取证据、控制变量 |
| 高级 | 从现象反推根因 | 协议原理、影响预测、跨层关联 |
| 专家 | 指导综合复杂故障 | 组织分工、标准设计、资产沉淀 |
专家级不是“知道最多命令”，而是能把复杂问题拆成可并行验证的子问题，并阻止团队做出高风险动作。指导者要明确：先做什么能最快止血、哪一项证据能一次排除最大分支、何时必须回退。
专家级思维的三个特征：
- 从原理出发，不从命令出发：遇到组播问题，先想“组播为什么需要 Snooping、如何建立出端口”，再查命令。
- 关注次生影响：每一条变更前评估对环路、冗余、地址规划、ACL、QoS 和业务的影响。
- 沉淀为组织资产：每次故障输出“现象—证据—根因—解决—预防”，并转成巡检项、开局基线和演练科目。
11_7_2 高频根因 Top 10 与预防机制
| 排名 | 根因 | 典型指纹 | 预防机制 |
|---|---|---|---|
| 1 | 配置错误（漏配/错配） | 变更后立即异常、局部半通 | 标准化模板、双人复核、diff |
| 2 | 物理层问题 | down、CRC、光功率异常 | 施工规范、光功率基线、替换法 |
| 3 | 双工/速率不匹配 | Collision、Align 增长 | 协商策略统一、服务器台账 |
| 4 | 二层环路/单向链路 | 广播风暴、MAC 漂移、TC | STP+BPDU Guard+环路检测+Loop Guard |
| 5 | 路由缺失/回程错误 | 单向通、网关可达远端不可达 | 路由矩阵、双向验证 |
| 6 | 冗余机制未验证 | 双主、倒换超时 | 倒换演练、track/BFD 验收 |
| 7 | 容量不足 | 高峰丢包、队列满 | 趋势监控、容量评估 |
| 8 | ACL/策略方向错误 | 特定流失败、计数不匹配 | 策略评审、命中统计、测试 |
| 9 | 版本/兼容性 | 升级后异常、协议不一致 | 兼容性矩阵、灰度升级 |
| 10 | 安全事件/私接 | 未知 MAC、异常流量 | 接入控制、监控、端口安全 |
Top 5 通常占据大量现场故障。它们的共同点是：都能通过标准模板、自动巡检和变更复核预防。因此，成熟的维护体系比“高手临时救火”更可靠。
11_7_3 复杂故障指挥卡
1. 谁在受影响？ → 明确范围，避免扩大操作
2. 最后一次正常是什么？ → 建立时间锚点
3. 最近变更是什么？ → 70% 以上现场问题与变更相关（经验值）
4. 异常聚集在哪里？ → CPU、端口、VLAN、协议、设备
5. 能否立即回退？ → 有回退先回退，无回退先隔离
6. 一次只验证一个假设 → 否则无法归因
7. 修复后如何证明？ → 验证矩阵 + 观察期
8. 下次如何预防？ → 巡检项/模板/监控/演练
11_8 应急演练设计（【ZCIE】答辩素材）
本节要解决什么问题：应急演练把「会排障」变成「随时能排障」，也是答辩时最有说服力的素材。
11_8_1 五大演练场景
| 场景 | 演练动作 | 验证目标 | 关键指标 |
|---|---|---|---|
| 单链路故障 | 拔出聚合一条成员链路 | LACP 切换与哈希不受影响 | 业务无中断/丢包阈值 |
| 单板/端口故障 | shutdown 关键上行口 | STP/路由收敛 | 恢复时间、拓扑稳定 |
| 核心设备宕机 | 关闭主用核心 | VRRP/路由切换 | 中断时长、双主检查 |
| 广播风暴 | 构造二层环路 | BPDU 保护、风暴抑制 | 爆炸半径、影响时长 |
| 配置误操作 | 回放典型误配置 | 备份恢复、回退流程 | 恢复成功率、RTO |
演练闭环：
设计场景 → 定义成功标准 → 记录基线 → 执行注入 → 实时观察
→ 采集证据 → 恢复 → 复盘 → 更新模板 → 再次演练
11_8_2 演练记录模板
【演练名称】核心主备切换与回切演练
【环境】测试环境 / 生产低峰窗口
【参与角色】指挥、操作、观察、业务确认、复盘
【基线】
- show vrrp / show lacp / show stp
- ping 基线、业务拨测、CPU/内存基线
- 备份配置、差异记录
【步骤与实时数据】
T0 开始；记录基线
T1 注入故障（关闭主用核心上行）
T2 记录告警、VRRP 切换、路由收敛
T3 业务拨测；统计丢包数、切换时长
T4 恢复主用；观察回切是否稳定
T5 二次验证、清理测试状态
【结果】
- 实测中断时长：
- 是否双主：否 / 是
- 是否符合 SLA：
- 监控是否完整覆盖：
【问题与改进】
- 发现监控盲区 → 责任人/期限
- 发现回退脚本缺失 → 责任人/期限
答辩价值：能拿出真实演练数据、时间线和改进闭环，比复述“STP 会阻塞端口”更能证明具备综合复杂故障处理能力。学习阶段建议至少完成三次完整演练，并覆盖一次回退场景。
11_9 考点速记
- 故障处理七步：受理 → 信息收集 → 定位 → 影响控制 → 排除 → 验证恢复 → 复盘归档。
- 第一原则：先恢复业务，后根治问题；恢复动作必须可逆、可验证。
- 四种定位方法：分层法、分段法、对比法、替换法。
- 分层模板：物理层 → 数据链路层 → 网络层 → 传输层 → 应用层。
- 三步清零法：
clear statistics→ 复现 →show statistics；只看增量。 - 三层第一坑：有去无回（缺回程路由）；验证必须双向。
- 二层第一坑：untag 成员关系与 PVID 未成对。
- 全网瘫痪：先止血（disable/隔离），再定位；先查风暴源、漂移和近期变更。
- 备份三原则：定时、异地、可恢复；必须演练恢复。
- 变更七步：申请 → 评审 → 备份 → 实施 → 验证 → 观察 → 回退准备。
- 防环三层保险：STP 预防 → 环路检测兜底 → 风暴抑制限速；上行口不得误开检测。
- MSTP 区域三要素：名称、版本号、VLAN 映射；必须逐字符比对。
- VRRP 必须实测倒换，防止通告路径单点导致双主。
- “间歇性风暴 + 无 CRC” 是单向链路指纹；
debug spantree bpdu-rx/tx只发不收即判单向。 - 环路检测误开上行口可致整楼断网；批量端口范围必须逐段复核。
- 组播业务：Snooping、querier、路由端口、CAC、QoS 缺一不可；验收不能只 ping。
- MTU 问题典型特征：小包通、大包失败；需逐跳检查接口、隧道、VLAN 和 DF。
- 【ZCIE】核心不只是定位，而是组织协作、风险控制、验证闭环和知识沉淀。
浙公网安备 33010602011771号