华为H3C实战 | 第39章 典型组网排障实录

📚 本系列共 43 篇（第 39 / 43 篇）　·　第六卷 实战与附录篇 —— 把它们拼起来

← 上一篇：第 38 章 小型办公网从零配置 　下一篇：第 40 章 华为 / H3C 命令速查字典 →

本章导读：真实排障不是"症状→原因→命令"三步走，而是你手上只有一个模糊现象、一堆可能原因和 30 分钟时间压力。本章用五个真实场景演一遍从"不知道往哪查"到"确定是这里"的全过程。

本章结构：

• 39.1 排障的底层方法论 —— 五层分层图、时间线图、复现路径图、先看后改原则、三类"假现象"、以及一条真实的 15 分钟排障时间线
• 39.2 场景一：跨 VLAN 不通
• 39.3 场景二：OSPF 邻居起不来
• 39.4 场景三：AP 不上线
• 39.5 场景四：NAT 后外网访问得了，内网访问不了
• 39.6 场景五：无线网速慢
• 39.7 排障工具箱与检查清单 —— 五个场景的共同模式、常用命令速查、现场必带的五个真相、抓包怎么用
• 39.8 本章小结

重点提示：每个场景的"先怀疑什么"那一小节最值钱，直接看它就能少走一大半弯路；手上的问题不属于这五个场景，先看 39.7.1 提炼的共同模式再套。用户描述不算事实，按 39.1.4 用数据（源 IP、目的 IP、时间点、截图）替换描述后再动手。 关联章节：VLAN 与 trunk 见第 3 章；OSPF 见第 11 章；AP 上线见第 19 章；NAT 见第 14、27 章；无线优化见第 22 章；无线故障全景见第 24 章。

39.1 排障的底层方法论

39.1.1 先讲一个残酷的事实

书上讲排错，通常是「症状 → 原因 → 命令」三步。但真实排障从来不是这个流程。真实的情况是：你手上只有一个模糊的现象，一堆可能的原因，而且你还有 30 分钟的时间压力——因为业务部门在催，老板在群里问，客服电话一直在响。

这一章用五个真实场景，把「不知道往哪查」到「确定是这里」的全过程写出来。每个场景都按同样的七步走：

现象描述 -> 先怀疑什么 -> 逐条用命令验证 -> 定位 -> 根因 -> 修复 -> 验证

中间那步「先怀疑什么」是最值钱的部分。老师傅和新手的差距不在会不会敲命令，而在先查哪一条。新手脑子里有二十个可能原因，从第一个开始逐个试；老师傅脑子里有一张概率排序表，先试最可能的两三个。

39.1.2 三张图，让排障不慌

排障前先把这张「分层图」摆在脑子里。任何网络问题，都可以用这张图减掉一大半的可能性：

[终端] --(1)物理/链路--> [接入交换机] --(2)二层--> [网关/VLANIF]
   |                                                        |
   +---------------(5)应用/策略----------------------------+
                                                            |
                              (3)三层路由 --> [出口] --(4)NAT/防火墙--> [Internet]

第二张图是「时间线图」。问三个问题：什么时候开始坏的？之前改过什么？是不是所有人都坏了？

• 「刚刚开始坏」→ 先查最近改动，八成是刚动的配置。
• 「一直就这样」→ 是设计问题，不是配置问题。
• 「只有一个人坏」→ 先查终端，再查接入端口。
• 「一片人都坏」→ 二层或网关。
• 「全网都坏」→ 出口或核心。

第三张图是「复现路径图」。让用户重演一遍操作：从哪个楼、哪个房间、用什么设备、连什么网络、访问什么地址。90% 的「上网慢」问题，在复现路径里就能看出答案。

39.1.3 排障的第一原则：先看后改

新手最爱做的事是「先改一改试试」。这是最危险的坏习惯，因为在没搞清楚原因的情况下改配置，会：

1. 把真正的问题掩盖掉，变成「时好时坏」。
2. 一次改动引入多个变量，之后的判断全部失效。
3. 在没备份的情况下改错，业务直接中断。

正确顺序是：收集信息 → 缩小范围 → 形成假设 → 设计验证方法 → 改一处 → 验证 → 记录。

39.1.4 排障中最容易被忽略的三类「假现象」

排障难，很多时候不是技术难，而是现象本身是假的。新手如果照单全收用户的描述，方向一开始就偏了。三类最常见的假现象：

处理假现象有一个通用办法：用数据代替描述。让用户提供具体时间、源 IP、目的 IP、失败截图；自己去设备上看日志。用户的描述是「线索」，不是「事实」。

39.1.5 一个真实的排障时间线

为了让「排障方法论」不显得空洞，这里给出一条真实的排障时间线（跨 VLAN 不通那个场景），看看老手实际是怎么走的：

00:00  接到报障：财务室三台电脑打不开办公系统
00:02  问清：只有这三台，财务其它电脑正常 —— 范围缩小到「新装的三个口」
00:04  怀疑：新装位置 -> 新接的接入交换机 -> 大概率是这台交换机的配置问题
00:06  登录新交换机，display interface brief -> 上行口 up
00:07  怀疑：上行 up 但 VLAN 没放通 -> display port vlan active
00:09  发现：上行口放行 VLAN 100，没放 VLAN 20 —— 命中
00:10  复核：同 VLAN 内打印机能通，跨 VLAN 不通，吻合
00:11  改配置：port trunk allow-pass vlan 20
00:13  验证：display port vlan active 确认；PC ping 通办公系统
00:15  记录：把「模板复制不改 VLAN」写进变更记录与检查清单

十五分钟解决，其中真正「敲命令」的时间不到三分钟，剩下全是判断方向。这段过程说明：排障的核心是快速缩小范围，而不是快速敲命令。

39.2 场景一：跨 VLAN 不通

39.2.1 现象描述

某公司财务部新装了三台电脑，网线插在接入交换机 VLAN 20 的口上。用户的反馈是：「内网共享打印机能用，但访问不了办公系统（192.168.10.5），网页也打不开。」

现象拆解：

• 打印机在同一 VLAN 20，能访问 → 二层本 VLAN 内是通的。
• 办公系统在 VLAN 10 → 跨 VLAN 不通。
• 网页也打不开 → 说明去外网也不通，也就是说所有跨网段流量都断了。

39.2.2 先怀疑什么

「同 VLAN 通、跨 VLAN 不通」这个特征非常经典，可能的原因按概率排序：

先查第 1、2 项，因为它们最常见也最好查。

39.2.3 逐条用命令验证

第一验：终端自己的网关配置。 这一条不需要登录设备，直接在 PC 上看：

# Windows 终端：看本机 IP、掩码、网关
ipconfig /all

# Linux 终端：看本机 IP、掩码、网关
ip addr show
ip route show

如果网关是空的，或者填成了 192.168.20.254 但网关实际是 192.168.20.1，那问题立刻定位。在本案例里，PC 的网关是正确填写的 192.168.20.1，排除第 1 项。

第二验：网关是否存在、是否 up。 登录核心交换机看 VLANIF 状态：

# 华为：看 VLANIF 20 的状态与地址
<CORE> display interface Vlanif 20
<CORE> display ip interface brief | include 192.168.20

# H3C：看 VLAN-interface 20 的状态与地址
<CORE> display interface Vlan-interface 20
<CORE> display ip interface brief

输出里 Vlanif20 当前状态如果显示 DOWN，那就是第 2 项原因。本案例输出显示：

Vlanif20 current state : UP
Line protocol current state : UP
Internet Address is 192.168.20.1/24

VLANIF 20 是 up 的，地址也正确。排除第 2 项。但这里要特别注意：VLANIF 是 up 说明这个 VLAN 里至少有一个 up 的端口，那到底是哪个端口？继续往下查。

第三验：接入交换机的上行口是否正确。 在接入交换机上看上行口状态和 trunk 放行：

# 华为接入交换机：看上行口状态与放行的 VLAN
<ACC-FINANCE> display interface GigabitEthernet0/0/24
<ACC-FINANCE> display port vlan active

# H3C 接入交换机
<ACC-FINANCE> display interface GigabitEthernet1/0/24
<ACC-FINANCE> display port trunk

这一步的输出是转折点。本案例中 display port vlan active 显示上行口 GigabitEthernet0/0/24 放行的是 VLAN 100，没有放行 VLAN 20。也就是说：

• VLAN 20 在接入交换机上是通的（本地有 up 的接入口），所以核心上 VLANIF 20 依然是 up 的（因为核心自己也有其他 VLAN 20 的接入）。
• 但从财务接入口进核心的流量，在 trunk 上被丢掉了。

39.2.4 定位

问题定位在两处联动：

1. 接入交换机上行 trunk 没有放行 VLAN 20。
2. 现场同时存在「核心上有其它 VLAN 20 端口」的情况，导致 VLANIF 20 依然 up，这让 VLANIF 的状态检查产生了「假通过」，一度把我引向「ACL」的方向。

复制一下当时的判断过程，新手可以体会一下：

第一反应是「VLANIF 都 up 了，肯定不是 VLAN 的问题」，于是去查了 ACL（display acl 3000），发现没有拦住财务段的规则。然后回头想了想：同 VLAN 能通、跨 VLAN 不通，说明流量上不去三层。于是回到二层，用 display port vlan active 一看，上行口没放 VLAN 20。问题明了。

这段「走了弯路又回来」的过程，恰好说明了分层排查的价值：ACL 在那一步不是重点，因为 ACL 是「放不放」的问题，而现象是「根本到不了」的问题。

39.2.5 根因

新增的财务接入交换机上线时，配置员只复制了「办公区交换机」的模板（模板里放行的是 VLAN 10、100），没有把 VLAN 20 加的放行清单里。这是典型的「模板复制不修改」。

39.2.6 修复

# 华为：上行口补放行 VLAN 20
<ACC-FINANCE> system-view
[ACC-FINANCE] interface GigabitEthernet0/0/24
[ACC-FINANCE-GigabitEthernet0/0/24] port trunk allow-pass vlan 20
[ACC-FINANCE-GigabitEthernet0/0/24] quit
[ACC-FINANCE] save

# H3C：上行口补放行 VLAN 20
<ACC-FINANCE> system-view
[ACC-FINANCE] interface GigabitEthernet1/0/24
[ACC-FINANCE-GigabitEthernet1/0/24] port trunk permit vlan 20
[ACC-FINANCE-GigabitEthernet1/0/24] quit
[ACC-FINANCE] save force

39.2.7 验证

# 1. 确认 trunk 放行清单已包含 VLAN 20
<ACC-FINANCE> display port vlan active

# 2. 在接入上看 MAC 表是否学到了 PC
<ACC-FINANCE> display mac-address vlan 20

# 3. PC 上直接测目标地址
ping 192.168.10.5

三项都通过后，问题解决。

39.2.8 踩坑提示

这个场景真正的教训不是「trunk 要放行 VLAN」这种常识，而是：VLANIF 是 up 不代表路径通。VLANIF 的状态只反映「本设备上该 VLAN 是否存在 up 端口」，不反映「远端流量能不能到」。排错时把它当成一个参考，不要当成判据。

39.3 场景二：OSPF 邻居起不来

39.3.1 现象描述

校园网新加了一台汇聚交换机，和核心之间配置了 OSPF。配置完成后，核心上看不到这台汇聚的路由，汇聚也 ping 不通核心以外的网段。display ospf peer 显示邻居状态卡在 EXSTART（或者干脆没有邻居）。

39.3.2 先怀疑什么

OSPF 邻居起不来，按发生概率从高到低排：

其中，「卡在 EXSTART」这个特征指向 MTU，这是新手最容易忽略的一条，因为无论怎么改 network 语句都不会好。

39.3.3 逐条用命令验证

第一验：邻居到底有没有建立。 先看状态：

# 华为：看 OSPF 邻居简要信息
<CORE> display ospf peer brief

# H3C：看 OSPF 邻居
<CORE> display ospf peer

本案例输出：

Area Id          Interface                        Neighbor id      State
0.0.0.0          Vlanif300                        10.200.100.31    ExStart

状态是 ExStart，不是没有邻居，而是邻居建立协议交互到 DD 报文阶段卡住了。这直接排除了第 1、2、3 项——邻居已经发现并且开始交互了。

第二验：MTU 是否一致。 这是 EXSTART 卡住的头号原因：

# 华为：看两端接口的 MTU
<CORE> display interface Vlanif 300
<AGG-NEW> display interface Vlanif 300

# H3C
<CORE> display interface Vlan-interface 300
<AGG-NEW> display interface Vlan-interface 300

本案例的输出：

CORE:     Maximum Transmit Unit is 1500
AGG-NEW:  Maximum Transmit Unit is 1400

差异出现了：新汇聚的 VLANIF 300 上 MTU 是 1400。这是上一个项目遗留配置（那台设备原来接在 MPLS 链路上）。

第三验：确认是不是 MTU。 最稳的验证方法不是改配置，而是先验证假设——在 OSPF 接口上临时忽略 MTU 检查：

# 华为：接口下忽略 MTU 检查（仅用于验证，不要长期保留）
<CORE> system-view
[CORE] interface Vlanif 300
[CORE-interface-Vlanif300] ospf mtu-ignore
[CORE-interface-Vlanif300] quit

# H3C：同样在接口下
<CORE> system-view
[CORE] interface Vlan-interface 300
[CORE-interface-Vlan-interface300] ospf mtu-ignore
[CORE-interface-Vlan-interface300] quit

配完等 40 秒（OSPF 的死区时间），再看邻居：

<CORE> display ospf peer brief

如果邻居变成 Full，就证明 MTU 就是根因。

39.3.4 定位与根因

定位：新汇聚交换机 VLANIF 300 的 MTU 是 1400，核心是 1500。OSPF 在 EXSTART 阶段用 DD 报文交换 MTU 并协商，不一致时从设备会拒绝继续，邻居卡住。

根因：VLANIF 的 MTU 被历史配置改过，之后没人恢复。这类问题的隐蔽性在于，静态路由、Ping 都正常（因为小包能过），只有需要交互 MTU 的协议才暴露。

39.3.5 修复

正确修复是把 MTU 改回来，而不是长期保留 mtu-ignore（它只是掩盖问题）：

# 华为：恢复 MTU 为 1500，并删除 mtu-ignore
<AGG-NEW> system-view
[AGG-NEW] interface Vlanif 300
[AGG-NEW-Vlanif300] mtu 1500
[AGG-NEW-Vlanif300] undo ospf mtu-ignore
[AGG-NEW-Vlanif300] quit
[AGG-NEW] save

# H3C：同样恢复
[AGG-NEW] interface Vlan-interface 300
[AGG-NEW-Vlan-interface300] mtu 1500
[AGG-NEW-Vlan-interface300] undo ospf mtu-ignore
[AGG-NEW-Vlan-interface300] quit
[AGG-NEW] save force

39.3.6 验证

# 1. 邻居状态是 Full
<CORE> display ospf peer brief

# 2. 路由表里能看到新汇聚宣告的网段
<CORE> display ip routing-table protocol ospf

# 3. 端到端 ping 通新汇聚下的终端网段
<CORE> ping -a 10.200.100.11 192.168.40.1

39.3.7 踩坑提示

ospf mtu-ignore 是个「诊断工具」，不是「修复工具」。长期留着它，会在将来某天因为大包不通而引发更诡异的问题（比如 SSH 能登入但传输大文件失败）。正确的做法是查清为什么 MTU 被改了，然后恢复一致。

这条经验的推广版是：任何“两端不一致”的配置都可能让协议起不来——MTU、Hello 时间、区域 ID、认证、网络类型，全部属于这一类。

39.4 场景三：AP 不上线

39.4.1 现象描述

办公楼新装了 12 台 AP，PoE 交换机上电后，指示灯正常（AP 在闪烁），但 AC 上 display ap all 里只有 3 台在线，另外 9 台一直显示未上线状态。这 9 台装在不同的楼层。

39.4.2 先怀疑什么

AP 不上线有一张标准的检查表，按顺序排：

本案例的「3 台在线 9 台不在线」这个分布很有意思：不是「全部不上线」，说明 AC、DHCP、Option 43 这套基本机制是通的。那么问题大概率在分批的地方——比如不同楼层接的交换机不同。

39.4.3 逐条用命令验证

第一验：AP 有没有拿到 IP。 在核心交换机上看 AP 管理段的 ARP 表：

# 华为：看 AP 管理段有多少 ARP 记录
<CORE> display arp | include 172.16.100

# H3C
<CORE> display arp | include 172.16.100

如果 ARP 表里只有 3 条记录，说明只有 3 台 AP 拿到了地址——问题在 DHCP 这一层，而不是 AC。

第二验：DHCP 地址池和 Option 43。 看地址池状态和配置：

# 华为：看 AP 地址池使用情况
<CORE> display ip pool name ap-mgmt

# 看地址池里是否真的配了 option 43
<CORE> display current-configuration | include option 43

# H3C
<CORE> display dhcp server pool name ap
<CORE> display current-configuration | include option 43

本案例结果：地址池配置正确，option 43 也在。地址池已用 3 个、可用 251 个，根本不是地址池耗尽。

第三验：这 9 台 AP 接在哪台交换机上。 顺着接线表往回找，9 台不上线的 AP 全接在 3 层的 PoE 交换机上。

# 华为：看 PoE 交换机的上行 trunk 与 VLAN 放行
<POE-3F> display interface GigabitEthernet0/0/24
<POE-3F> display port vlan active

# 看 PoE 端口供电与链路
<POE-3F> display poe interface

输出显示：上行 trunk 放行的是 VLAN 40 50 100，但 AP 管理 VLAN 是 100，正确。等等，看起来没问题。继续查。

第四验：从 PoE 交换机上直接 ping AC。

# 在 PoE 交换机上用管理地址作为源去 ping AC
<POE-3F> ping -a 172.16.100.51 172.16.100.2

这一步是本场景的转折点：ping 不通。说明 AP 所在的这台交换机到 AC 之间是不通的，那么 AP 自然拿不到地址（DHCP 报文是广播，靠 DHCP 服务器响应）。

再往上查一层，在核心上看 PoE 交换机所在 VLAN：

<CORE> display vlan 100

发现：核心上 GigabitEthernet0/0/3（接 PoE 交换机的口）没有划进 VLAN 100 的 trunk 放行清单。原来核心上这个口配的是 port trunk allow-pass vlan 40 50，漏了 100。

39.4.4 定位与根因

定位：核心交换机连接 3 层 PoE 交换机的上行口没有放行 AP 管理 VLAN 100，导致那台交换机下的 AP 拿不到 IP，也就没有 CAPWAP。

根因：接入层扩展时只看到了「业务 VLAN」，忘了「AP 管理 VLAN」。因为 1 层的 PoE 交换机是早期配的（那时企业管理网还没独立），所以没问题；3 层的 PoE 交换机和核心口是新加的。

39.4.5 修复

# 华为：核心上行口补放行 VLAN 100
<CORE> system-view
[CORE] interface GigabitEthernet0/0/3
[CORE-GigabitEthernet0/0/3] port trunk allow-pass vlan 40 50 100
[CORE-GigabitEthernet0/0/3] quit
[CORE] save

# H3C
[CORE] interface GigabitEthernet1/0/3
[CORE-GigabitEthernet1/0/3] port trunk permit vlan 40 50 100
[CORE-GigabitEthernet1/0/3] quit
[CORE] save force

39.4.6 验证

# 1. PoE 交换机能 ping 通 AC
<POE-3F> ping -a 172.16.100.51 172.16.100.2

# 2. ARP 表上出现新的 AP 地址
<CORE> display arp | include 172.16.100

# 3. AC 上 AP 逐步上线（需要 1~3 分钟）
<AC1> display ap all

39.4.7 踩坑提示

AP 不上线时，很多人一上来就查 AC 配置。但正确顺序是从 AP 侧往上查：先确认 AP 有没有 IP，再确认有没有 Option 43，再确认到 AC 可不可达，最后才是 AC 的配置。因为 AC 通常只有一台，而 AP 有几十上百台，故障点分布不同——大概率问题在中间链路，而不是 AC 本身。

另一个经验：先用「有几台在线」判断故障范围。3 台在线说明基础机制通；9 台不在线说明是局部的链路问题。这个判断能帮你跳过大半的无效排查。

39.5 场景四：NAT 后外网访问得了，内网访问不了

39.5.1 现象描述

一家公司的出口路由器新换了配置。配完之后出现一个很奇怪的现象：

• 内网 PC 访问外网网站：正常。
• 外网无法访问内网服务器（服务器 IP 192.168.60.10:80）：失败，需要做端口映射。
• 更奇怪的是：内网 PC 用公网地址访问自己的服务器（即通过映射后的公网 IP 100.64.8.2:8080 访问）也失败。

这就是经典问题：NAT Server + 内网访问公网地址（NAT 回流/Hairpin）。

39.5.2 先怀疑什么

「外网访问得了外网、访问不了内网服务器」这个现象，可以拆成两个子问题：

这个场景最典型的根因是NAT 回流（Hairpin NAT）没有配置。原因在于：内网 PC（192.168.10.5）访问 100.64.8.2:8080 时，报文从内网口进、又从内网口出，很多设备的 NAT 只处理「内网 → 外网口」方向的流量，这种「内网口进、内网口出」的流量不走 NAT 处理，导致包根本到不了服务器。

39.5.3 逐条用命令验证

第一验：NAT Server 配置对不对。

# 华为：看 NAT Server 映射
<R1> display nat server

# H3C：看 NAT Server
<R1> display nat server

本案例华为输出显示：

Nat Server Information:
  Interface  : GigabitEthernet0/0/1
  global IP  : 100.64.8.2:8080
  inside IP  : 192.168.60.10:80

映射存在，外网访问理论上应该通。于是继续查为什么外网也不通。

第二验：外网真的能通吗？ 在外部测试，或者用服务端模拟：

# 从外网到公网地址的连通性测试（在外部设备上执行）
ping 100.64.8.2

Ping 通但不代表 8080 通。再从外部测端口：

# Windows 上用 telnet 测端口（需要开启 telnet 客户端）
telnet 100.64.8.2 8080

# Linux 上
nc -zv 100.64.8.2 8080

本案例实测外网 8080 是通的，只是内网访问公网地址不通。那么第 1 个子问题其实已经解决——用户描述有偏差，真正的问题是「内网访问公网映射地址不通」。

这就引出了一个更常见的运维陷阱：用户测试方式不对。很多用户在内网测试时直接用公网地址，但他们的网络架构没配回流，于是误以为映射失败。

39.5.4 定位与根因

定位：NAT Server 配置正确，外网访问正常；内网访问公网映射地址失败的原因是未配置 NAT 回流。

根因有两层：

1. 技术层面：NAT 设备默认只对「内网接口进入、外网接口发出」的流量做 NAT 转换。内网 PC 访问公网 IP 时，报文在内网口进入后，路由决定让它从内网口返回（因为目标是自己映射的地址），整个过程不匹配 NAT 的转换条件。
2. 认知层面：用户不理解为「外网能访问了，怎么内网反而不行」，导致报障方向错误。

39.5.5 修复

方案 A（推荐，最通用）：内网用户直接访问服务器内网地址，不走公网映射。也就是在 DNS 上把服务器的域名解析成内网地址 192.168.60.10，内网用户访问时直接走内网路径。这也是最佳实践——内网流量不要绕公网一圈，既省带宽又快。

方案 B：配置 NAT 回流（Hairpin NAT）。让内网访问公网地址的流量也做转换。这部分命令在两家设备上的形态差异较大，先给出「思路」再给出「按设备核对点位」：

# 思路（不是可直接粘贴的命令）：
# 1) NAT server 映射保持不动
# 2) 增加一条 NAT 策略/规则，把「内网源 -> 公网映射地址」的流量
#    转换为「内网源 -> 服务器内网地址」
# 3) 确保这条规则在有状态检测设备上只匹配一次，避免与安全策略打架

⚠ 版本差异：华为 AR 系列在不同 VRP 版本上对「内部流量回流」的支持方式不同（有的版本通过 nat server 相关参数开启，有的版本需要在 NAT 策略里补充内部转换规则）；H3C MSR 系列是 nat hairpin 类配置。这一段必须以你实际设备版本的《配置指南-NAT》为准，且上线前先在测试环境验证。 ⚠ 待核实：待核实 华为 AR6140 V200R019 开启内网访问公网映射地址（Hairpin NAT）的准确命令形态；H3C MSR3610-X1 Comware V7 的 nat hairpin 命令层级

39.5.6 验证

# 方案 A 的验证：内网 DNS 解析走内网地址
# 内网 PC 上
nslookup server.example.com
ping 192.168.60.10

# 方案 B 的验证：内网访问公网映射地址应能通
telnet 100.64.8.2 8080

# 看 NAT 会话表是否有转换记录
<R1> display nat session all

39.5.7 踩坑提示

这个场景最有价值的提醒是：先确认真实问题，再动手修。用户说「内网访问不了」，真实情况是「内网访问公网地址不通」，而这是一个已知的技术限制（未配回流），不是故障。

排障第一步永远是：让用户复现，并记录精确的源地址、目的地址、端口。不要接受「访问不了」这种模糊描述。

39.6 场景五：无线网速慢

39.6.1 现象描述

会议室装了 2 个 AP，开视频会议时，与会人员抱怨「特别卡、经常断」。测速显示下载速度只有 2Mbps 左右，而 AP 的链路协商速率显示是 866Mbps。同样的 AP，在走廊测速能到 300Mbps。

39.6.2 先怀疑什么

「同一个 AP，位置不同速度差几十倍」，这个特征指向空口质量或干扰，而不是设备性能。可能原因排序：

39.6.3 逐条用命令验证

第一验：AP 的射频与信道。 看 AP 用了什么信道、什么频宽、多少终端：

# 华为：看 AP 的射频状态
<AC1> display ap radio 2.4g all
<AC1> display ap radio 5g all

# 华为：看每个 AP 下的终端数
<AC1> display station all

第二验：是否同频干扰。 看会议室的两个 AP 是否同信道：

# 华为：看射频工作信道
<AC1> display radio 2.4g all
<AC1> display radio 5g all

# H3C：看射频
<AC1> display wlan radio

本案例结果：会议室的 AP1 和 AP2 都在 5G 的 149 信道，而且都开了 80MHz 带宽——两个 AP 同频且带宽重叠，互相干扰。

第三验：终端链路质量。 看终端协商速率与信号强度：

# 华为：看在线终端的详细信息
<AC1> display station ssid Company-Staff

# H3C：看终端
<AC1> display wlan client verbose

在本案例中，终端信号强度 -55dBm（信号其实很好），协商速率只有 72Mbps（说明是 2.4G 单流或老终端）。

第四验：空口利用率。 这一步需要看射频的信道利用率：

# 华为：看 AP 射频的统计信息（信道利用率、重传率）
<AC1> display ap performance-statistics ap-name AP-MEETING-01

# H3C：看射频统计
<AC1> display wlan ap name AP-MEETING-01 radio 1

结果显示信道利用率超过 80%，重传率高——空口已经饱和。

39.6.4 定位与根因

定位：三个叠加因素：

1. 两个会议室 AP 在 5G 相邻信道且开 80MHz，频段重叠互相干扰。
2. 大量终端仍然连在 2.4G（因为 2.4G 覆盖更远、终端不主动切换），而 2.4G 侧干扰严重。
3. 会议场景下终端密度高（20 人在同一个 AP 下），空口容量被分光。

根因：AP 布放与射频参数没有按「高密度会议室」场景调优，用的是默认的「均匀覆盖」参数。

39.6.5 修复

# 华为：把两个会议室 AP 的信道错开，5G 用 40MHz
# 切记：华为 radio 0 = 2.4G，radio 1 = 5G（与 H3C 的 1/2 编号相反）
<AC1> wlan
[AC1-wlan-view] ap-group name meeting
[AC1-wlan-ap-group-meeting] radio 0
[AC1-wlan-ap-group-meeting-radio-0] channel 20mhz 6
[AC1-wlan-ap-group-meeting-radio-0] quit
[AC1-wlan-ap-group-meeting] radio 1
[AC1-wlan-ap-group-meeting-radio-1] channel 40mhz 36
[AC1-wlan-ap-group-meeting-radio-1] quit
[AC1-wlan-ap-group-meeting] quit
[AC1-wlan-view] quit

# 开启频谱导航（引导终端优先连 5G）
<AC1> wlan
[AC1-wlan-view] rrm-profile name rrm1
[AC1-wlan-rrm-prof-rrm1] band-steer
[AC1-wlan-rrm-prof-rrm1] quit
[AC1-wlan-view] quit

# 开启负载均衡，把终端分布到两个 AP
<AC1> wlan
[AC1-wlan-view] ap-group name meeting
[AC1-wlan-ap-group-meeting] load-balance enable
[AC1-wlan-ap-group-meeting] quit
[AC1-wlan-view] quit

⚠ 上述 channel 20mhz 6、band-steer、load-balance 这些命令是华为 V200R019 的典型写法，但 AC 型号与版本不同、参数名可能有差异（例如部分版本用 rrm-profile 或 radio-2g-profile）。务必在设备上用 ? 逐级确认。 ⚠ 待核实：待核实 AC6005 V200R019 上 band-steer / load-balance 的具体命令层级与参数名，以及是否需要在 VAP 模板或 RRM 模板里配置

H3C 侧的等价思路：

# H3C：把两个 AP 的信道与频宽错开
# 切记：H3C radio 1 = 2.4G，radio 2 = 5G（与华为的 0/1 编号相反）
<AC1> wlan ap AP-MEETING-01
[AC1-wlan-ap-AP-MEETING-01] radio 1
[AC1-wlan-ap-AP-MEETING-01-radio-1] channel 20mhz 6
[AC1-wlan-ap-AP-MEETING-01-radio-1] quit
[AC1-wlan-ap-AP-MEETING-01] radio 2
[AC1-wlan-ap-AP-MEETING-01-radio-2] channel 40mhz 36
[AC1-wlan-ap-AP-MEETING-01-radio-2] quit
[AC1-wlan-ap-AP-MEETING-01] quit

# 开启频段导航
<AC1> wlan ap-group default-group
[AC1-wlan-ap-group-default-group] band-navigation enable
[AC1-wlan-ap-group-default-group] quit

39.6.6 验证

# 1. 确认信道已错开
<AC1> display ap radio 5g all

# 2. 看终端是否更多连在 5G
<AC1> display station all

# 3. 会议室现场实测速度（目标 >100Mbps）

39.6.7 踩坑提示

「无线慢」是最难排的问题，因为它牵涉对比多：信号强度、信道、干扰、终端能力、AP 负载、上游有线链路。有一个实用的二分法：

先测有线。 把笔记本直接插到 AP 所在交换机的同一个口，测速。如果有线也只有 2Mbps，那问题在有线侧或上游，跟无线无关。如果有线很快、无线很慢，才是空口问题。

本案例中有线侧正常，所以锁定在空口。这个「先分清问题在有线还是无线」的步骤，能帮你省掉大量时间。

39.7 排障工具箱与检查清单

39.7.1 五个场景的共同模式

回头看这五个场景，它们的排障路径其实高度相似，都是同一个套路：

一个可以背下来的排障口诀：「先分层，再缩小，后验证」。

• 先分层：这个问题在物理、二层、三层、还是应用层？
• 再缩小：有几个终端受影响？一台还是全网？
• 后验证：改之前先想好「改完看什么输出，怎么证明我是对的」。

39.7.2 常用排障命令速查

下面这些命令覆盖了本章所有场景，建议存成便签：

# ===== 华为 =====
# 接口与链路
display interface brief
display interface GigabitEthernet0/0/1
display port vlan active
display transceiver diagnosis interface GigabitEthernet0/0/1

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

# 三层
display ip interface brief
display ip routing-table
display arp

# OSPF
display ospf peer brief
display ospf error

# NAT
display nat session all
display nat server

# 无线
display ap all
display station all
display ap radio 5g all

# 抓包与调试（谨慎使用）
display diagnostic-information

# ===== H3C =====
# 接口与链路
display interface brief
display interface GigabitEthernet1/0/1
display port trunk
display transceiver diagnosis interface GigabitEthernet1/0/1

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

# 三层
display ip interface brief
display ip routing-table
display arp

# OSPF
display ospf peer
display ospf error

# NAT
display nat session verbose
display nat server

# 无线
display wlan ap all
display wlan client
display wlan radio

# 诊断信息
display diagnostic-information

39.7.3 现场必带的「五个真相」

排障时，比命令更重要的是问对问题。这五个问题问完，能省一半时间：

1. 什么时候开始坏的？ 之前有没有人改过网络？
2. 有多少人受影响？ 一个人、一个部门、还是一栋楼？
3. 换个终端/换个口还好吗？ 这能立刻区分「终端问题」和「网络问题」。
4. 具体的源地址、目的地址、端口是什么？ 不接受「访问不了」这种描述。
5. 能复现吗？ 不能复现的问题，先做监控记录，不要盲目改动。

39.7.4 抓包：排障里最有力的一招

命令能告诉你「状态」，抓包能告诉你「真相」。当几种可能都排除不掉时，抓包是最后的裁决手段。抓包要在正确的位置抓：

• 终端侧：确认终端到底有没有发出请求、发出的目的地址对不对。
• 接入交换机上行口：确认流量有没有被 VLAN 或 ACL 拦掉。
• 网关接口：确认流量有没有到达三层。

华为与 H3C 都支持端口镜像（把某个接口的流量复制到另一个接口）和内置抓包：

# 华为：端口镜像（把上行口流量复制到 GE0/0/23，接笔记本用 Wireshark 抓）
<CORE> system-view
[CORE] observe-port 1 interface GigabitEthernet0/0/23
[CORE] interface GigabitEthernet0/0/1
[CORE-GigabitEthernet0/0/1] port-mirroring to observe-port 1 both
[CORE-GigabitEthernet0/0/1] quit

# H3C：端口镜像
<CORE> system-view
[CORE] mirroring-group 1 local
[CORE] mirroring-group 1 mirroring-port GigabitEthernet1/0/1 both
[CORE] mirroring-group 1 monitor-port GigabitEthernet1/0/23

如果设备支持内置抓包（华为部分型号有 capture-packet 类命令、H3C 有 packet-capture 类命令），可以直接抓包后导出到 PC 分析：

# 华为：查看是否支持内置抓包（不同型号差异很大，先看帮助）
<CORE> display diagnostic-information

⚠ 版本差异：内置抓包（capture-packet / packet-capture）在不同型号与版本上的支持情况差异很大，部分设备只有 ACL 统计而没有抓包功能。不要假设设备一定有，先用 ? 或命令帮助确认。 ⚠ 待核实：待核实 华为 S 系列交换机的 capture-packet 命令在 V200R019 的支持范围；H3C Comware V7 的 packet-capture 命令形态

39.7.5 日志与告警：事后排障的唯一证据

很多问题发生时你不在现场。这时候唯一的证据就是日志。所以「日志开关」必须在平时就配好，而不是出事之后才想起来：

# 华为：把日志送到 Syslog 服务器
<CORE> system-view
[CORE] info-center loghost 192.168.1.100

# H3C：把日志送到 Syslog 服务器
<CORE> system-view
[CORE] info-center loghost 192.168.1.100

要有日志的几类事件：接口 up/down、STP 拓扑变化、CPU/内存告警、认证失败、配置变更。尤其是配置变更——如果每次有人登录改配置都留一条记录，上面五个场景里有一半都能在五分钟内定位。

# 华为：看命令历史（VTY 上最近的命令）
<CORE> display history-command all

# H3C：看命令历史
<CORE> display history-command

39.7.6 两次排障的复盘怎么写

排障不只是解决当下，还要防止复发。每解决一个非平凡问题，都应该写一份复盘。复盘的模板固定四段：

1. 现象：谁在什么时候发现了什么（客观事实，不含猜测）
2. 时间线：从报障到修复的每个动作（谁、做了什么、看到了什么）
3. 根因：一句话说清楚「为什么坏」，以及「为什么没被发现」
4. 改进：配置上怎么改、流程上怎么改、监控上怎么加

第 4 段最关键。以本章场景一为例，改进至少有三条：

• 配置侧：把「trunk 放行清单」列成检查表，新交换机上线必须逐项打勾。
• 流程侧：模板复制后必须用 diff 对比两端配置。
• 监控侧：对「某个 VLAN 的 ARP 数量突然归零」设告警，能提前发现类似问题。

39.7.7 一张随身携带的排障决策树

把本章五个场景浓缩成一棵可以贴墙上的决策树：

问题上报
  |
  +-- 一台设备 / 一个端口出问题？ -> 查物理层（链路、光模块、终端配置）
  |
  +-- 一个 VLAN / 一个部门不互访？
  |     +-- 同 VLAN 内通不通？ 不通 -> 二层（VLAN、trunk、STP、MAC）
  |     +-- 同 VLAN 通、跨 VLAN 不通 -> 查网关（VLANIF、默认网关、trunk 放行）
  |
  +-- 内网通、外网不通？
  |     +-- 网关 ping 通外网网关？ 不通 -> 路由（默认路由、OSPF）
  |     +-- 路由通但上不了网 -> NAT（nat outbound、ACL、会话表）
  |     +-- NAT 有会话但仍不通 -> 防火墙策略（区域、方向、源地址是否被 NAT 改过）
  |
  +-- 无线连上但没网？ -> 查 AP 管理 IP、Option 43、业务 VLAN 网关、CAPWAP
  |
  +-- 无线慢？ -> 先测有线：有线也慢查上游，有线快查空口（信道、干扰、终端能力）

这棵树的用法是从上往下走，每走到一个分支都只问一个「是/否」问题。它的价值在于把「二十个可能」压缩成「一条路径」，避免新手在主目录上打转。

39.8 本章小结

五场排障走完，几个最重要的结论：

• 同 VLAN 通、跨 VLAN 不通，先看网关，再看 trunk 放行；VLANIF 是 up 不等于路径通。
• OSPF 卡在 EXSTART，先查 MTU；mtu-ignore 只是诊断工具，不是修复方案。
• AP 不上线，先在 AP 侧查 IP，再查 Option 43，最后才查 AC。
• NAT 回流不是故障而是限制；先确认用户到底测的是什么。
• 无线慢，先测有线；无线问题里「同 AP 不同位置差几十倍」多半是射频参数与干扰。
• 排障三原则：先看后改、一次只改一处、每次改动都记录。

自测题

1. 一个终端能访问同网段的其它终端，但访问不了网关，可能是什么原因？
2. OSPF 邻居状态卡在 EXSTART，为什么常见的排查方向是 MTU 而不是区域号？
3. 如果 20 个 AP 中只有 2 个不上线，你觉得应该先查 AC 还是先查中间链路？为什么？
4. 内网访问公网映射地址失败，有两种解法，分别是什么？哪种更推荐？
5. 无线速度慢，怎么用最快的方式判断问题在有线侧还是无线侧？

1. 优先怀疑终端本身的网关配置（地址填错、掩码错误），其次怀疑接入端口所属 VLAN 与网关不一致，或者接入交换机与网关设备的二层链路未放行该 VLAN。同网段能通说明二层正常，问题出在「到网关的一段」：可能是终端的网关地址错、端口 VLAN 错、或 trunk 没放行。
2. 因为卡在 EXSTART 说明邻居已经发现并进入了数据库描述（DD 报文）交互阶段，区域号不一致会导致邻居根本建立不起来（DOWN 状态或无邻居），所以区域号问题已经被状态本身排除。DD 报文里会协商 MTU，两端不一致时从设备会拒绝继续。
3. 先查中间链路。因为大多数 AP 在线说明 AC、DHCP、Option 43 这套机制是通的；少数 AP 不上线更像是它们所连的交换机或上行链路有问题。排障要优先去「差异点」找原因。
4. 方案一：内网用户直接访问服务器的内网地址（通过内网 DNS 解析），不走公网映射；方案二：配置 NAT 回流（Hairpin NAT）。推荐方案一，因为它更简单、更快（内网流量不绕公网），也不依赖设备特性。
5. 把笔记本直接插到 AP 所在交换机的同一个端口（同一个 VLAN）测速：如果有线也慢，问题在有线侧或上游；如果有线正常，问题才是空口（信道、干扰、终端能力、AP 负载）。

关于本书：《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境， 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材，共 43 章。 全书所有命令尽量有官方出处，查不到的显式标注「待核实」。 返回系列目录