前面十几篇讲的都是「怎么配」。这一篇讲「出问题了怎么办」——这是实际工作里花时间最多的部分。

先定思路，再动手

网络故障排除的三种思路与按 OSI 分层的检查清单
▲ 三种排错思路，以及那张最该背下来的检查清单
思路做法什么时候用
自下而上物理层 → 应用层，逐层确认故障现象是「完全不通」
自上而下应用层 → 物理层「部分能用、时好时坏」这类现象
分而治之从网络层切入，ping 一下先切掉一半可能有经验的工程师首选

为什么「分而治之」效率最高？因为一次 ping 就能把问题范围砍掉一半：

一次 ping 切掉一半
终端 ping 网关
  ├─ 通 → 问题在网关之上（路由 / 出口 / 上层网络）
  └─ 不通 → 问题在网关之下（接入链路 / VLAN / 终端本身）

再往上 ping 出口、ping 公网 DNS，每 ping 一次就切掉一层
★ 整个过程 30 秒，比逐层翻配置快得多

那张检查清单

按 OSI 分层，每层问几个问题。把它背下来，80% 的故障能自己定位：

层问什么看什么命令
物理接口 Up 吗？光功率正常吗？两端速率/双工一致吗？display interface / display transceiver
链路VLAN 对吗？ARP 学到没有？MAC 表有吗？STP 状态正常吗？display arp / display mac-address / display stp
网络路由有吗？ping 通网关吗？ACL 挡了吗？NAT 生效吗？display ip routing-table / display acl
传输端口通吗？会话建了吗？display firewall session table / telnet
应用DNS 对吗？服务起来了吗？证书过期了吗？nslookup / display dns
变更最近改了什么？配置备份 diff
对比和正常的设备/链路差在哪？配置 diff

实战经验：「最近改了什么」这一条的命中率最高。很多故障不需要逐层查——问一句「什么时候开始的、之前动过什么」，答案就出来了。所以运维规范里，变更记录比任何排错技巧都值钱。

网络管理的四大手段

手段做什么典型工具
SNMP周期性采集设备指标（CPU、内存、接口流量、温度）Zabbix / Prometheus + SNMP Exporter
NetStream / NetFlow统计流级别的信息（谁和谁在通信、占多少带宽）NetStream 采集器
端口镜像把流量复制一份给分析设备（抓包、IDS、审计）Wireshark、NPM 系统
Syslog / Telemetry日志集中收集；Telemetry 做高频指标推送ELK / 日志平台

端口镜像：抓包前必须做的一步

这是排错里最有力的手段。在交换机上把要观察的流量复制一份到指定端口，然后接一台装了 Wireshark 的电脑：

huawei · 端口镜像
# ① 指定观察端口（接分析设备的口）
observe-port 1 interface GigabitEthernet0/0/24

# ② 在业务口上镜像
interface GigabitEthernet0/0/1
 port-mirroring to observe-port 1 both        # both = 收和发都镜像
 # inbound / outbound 也可以只镜像一个方向

# ③ 镜像 VLAN 的所有流量
vlan 10
 mirror to observe-port 1 inbound

# ★ 注意事项：
#   镜像口带宽要够 —— 镜像 10G 流量到一个 1G 口会丢包
#   镜像会占用设备 CPU 和背板带宽，生产环境别长期开着

几个真实故障的定位过程

案例一：能 ping 通但网页打不开

现象 → 定位
现象：ping 8.8.8.8 正常，但浏览器打不开任何网站
思路：ping 通 = 网络层没问题 → 往上查

排查：
  ① nslookup www.example.com  → 解析失败！
  ② 检查 DNS 配置 → 配的 DNS 服务器地址写错了一位
  ③ 改成正确的 DNS → 恢复正常

★ 结论：ping 通但打不开，第一反应查 DNS，不是查网络
★ 因为 ping 用的是 IP，跳过了 DNS 这一环

案例二：小包通、大包不通

现象 → 定位
现象：能登录网页、能发消息，但一传文件就断
思路：小包通、大包不通 = 典型的 MTU / MSS 问题

排查：
  ① ping -s 1400 目标地址  → 通
  ② ping -s 1500 目标地址  → 不通
  ③ 说明路径 MTU 在 1400~1500 之间

常见原因：
  · 隧道封装（GRE / IPSec / PPPoE）导致 MTU 变小
  · 中间有设备 MTU 配小了
  · PMTUD（路径 MTU 发现）被防火墙挡了 ICMP

解法：在隧道接口上配 tcp adjust-mss，或者把 MTU 调小

案例三：偶发丢包、时好时坏

现象 → 定位
现象：网络时好时坏，重启设备就好一阵
排查顺序：
  ① display cpu-usage / display memory-usage  → 看是否过载
  ② display logbuffer | include ERROR         → 看有没有硬件告警
  ③ display interface | include error         → 看接口 CRC/丢包计数
  ④ display transceiver verbose               → 光功率是否临界
  ⑤ 检查 STP 拓扑变化：display stp topology-change

★ "重启就好" 通常指向：内存泄漏、表项溢出、CPU 过载
★ 接口有 CRC 错误增长 = 物理链路质量差（光衰、水晶头、网线）

运维规范：比技巧更重要

规范为什么
变更前备份配置出问题能秒回滚。save 之前先 display current-configuration 存一份
记录变更内容与时间故障回溯的唯一线索
变更窗口与回滚方案业务高峰期不动网；想清楚「不行怎么退」
双人复核配错一条 ACL 就能断网，有人复核能避免大半事故
自动化巡检定期收集配置和状态，做 diff——能提前发现别人偷改的配置

华为常用诊断命令速查

huawei · 排错命令
# 接口与物理
display interface brief                 # ★ 一眼看所有接口状态
display interface GigabitEthernet0/0/1  # 详细（含 error/discard 计数）
display transceiver verbose             # 光模块功率、温度

# 二层
display arp all
display mac-address
display vlan
display stp brief

# 三层
display ip routing-table
display ip routing-table 10.1.1.0 verbose   # 看某条路由的来源和优先级
display ospf peer / display bgp peer

# 会话与策略
display firewall session table
display acl 3000

# 设备状态
display cpu-usage
display memory-usage
display logbuffer                        # ★ 日志缓冲区
display health                           # 硬件健康状态

# 抓包
capture-packet interface GigabitEthernet0/0/0 destination file cap.cap
display capture-packet file cap.cap

# 诊断
display diagnostic-information           # ★ 一键收集所有诊断信息（给厂商报障用）

一句话总结：排错先定思路（分而治之最快），再按层问问题，永远先问「最近改了什么」。工具上端口镜像和 diagnostic-information 是最有力的两件；流程上变更备份和记录比任何技巧都重要。

📌 本篇整理自 2024–2025 的「数通」学习笔记（HCIE-Datacom 方向）

合并了原始笔记中「网络管理 / 网络运维 / 网络故障排除」三页。
原笔记以命令罗列为主，本文重排成「思路 → 清单 → 工具 → 案例 → 规范」的结构，并补上了三个典型故障的完整定位过程。
配置命令保留华为 VRP 原样。