华为H3C实战 | 第36章 BRAS 排错专题

📚 本系列共 43 篇（第 36 / 43 篇）　·　第五卷 BRAS 与认证计费篇 —— 大规模用户接入

← 上一篇：第 35 章 BRAS 用户策略与 QoS 　下一篇：第 37 章 校园网综合案例 →

本章导读：BRAS 排错不靠背命令，靠固定顺序：先定类（拨不上/认证不过/上不了网/老掉线/慢），再收证据，只改一处，改完复测。本章把 Part E 前五章的坑集中成一张总故障树。

本章结构：

• 36.1 排错方法论与总览 —— 五类问题总框架、三条排错纪律、“先问三个问题"的分诊表和六种情形速查
• 36.2 用户上不了线：PPPoE 卡在哪个阶段 —— 按报文定位，附一份完整现场实录
• 36.3 认证失败：RADIUS 不通 / 属性不匹配 / 域不匹配 —— 三问定位法 + 域不匹配专项排查
• 36.4 地址池耗尽
• 36.5 能拨号但上不了网 —— 最后一公里问题按序排查
• 36.6 频繁掉线 —— 四种掉线类型及区分方法
• 36.7 能上网但慢 / 策略没生效 —— 华为侧限速不生效专用检查法
• 36.8 常见告警与设备资源问题 —— 不凭空猜告警名，按影响面分类看
• 36.9 六个真实故障场景的完整复盘
• 36.10 排错证据收集清单 —— 十五分钟证据包、建立基线、现场沟通话术
• 36.11 排错命令速查表
• 36.12 新手踩坑与注意事项
• 36.13 本章小结

重点提示：接到报障先查 36.1.4 的分诊表，六种情形直接跳到对应节，比翻命令快得多；不确定卡在哪一类时老老实实从 36.2 往后排，别跳级猜。要打 400 前先按 36.10 采齐证据包，并先备份配置再动手（36.1.3 纪律二）。 关联章节：BRAS 组网与概念见第 31 章；PPPoE 报文选路见第 32 章；认证与 RADIUS 报文见第 33 章；IPoE 三态模型见第 34 章；限速与策略位置见第 35 章。

36.1 排错方法论与总览

36.1.1 先讲方法，再讲命令（通俗版）

排错这件事，新手和老手的差距不在会不会敲命令，而在有没有章法。

新手排错像这样：用户说上不了网 → 先重启 → 不行 → 改配置 → 还不行 → 再改 → 越改越乱 → 最后把配置改回去，问题可能自己好了，也可能更糟。

老手排错像这样：先确定问题在哪一层 → 收集证据 → 形成假设 → 验证假设 → 只改一处 → 复测。

本章不给你一堆命令让你背，而是给你一套固定的排查顺序。这套顺序的价值在于：无论遇到什么问题，你都知道下一步该看哪里。

36.1.2 BRAS 排错的总框架

BRAS 的问题千奇百怪，但归到底只有五类，按「用户能不能上网」这条主线排列：

   ┌──────────────────────────────────────────────────────┐
   │  第一类：用户连拨号都拨不起来（PPPoE 建不起来）        │  → 35.2
   │  第二类：拨起来了但认证不过                            │  → 35.3
   │  第三类：认证过了但拿不到地址 / 上不了网                │  → 35.4、35.5
   │  第四类：能上网但老掉线 / 不稳定                        │  → 35.6
   │  第五类：能上网但慢 / 策略没生效                        │  → 35.7
   └──────────────────────────────────────────────────────┘

这个顺序本身就是排查顺序：不要跳级。用户说「上不了网」，你不确定他卡在哪一类，就从第一类开始往后排。用「逐步往下走」的方式定位，比「猜一个问题去验证」快得多也稳得多。

36.1.3 三条必须遵守的排错纪律

排错时最容易犯的不是技术错误，是操作纪律错误。这三条必须守住：

纪律一：一次只改一个变量。 如果你同时改了共享密钥、改了域、又重启了设备，问题好了你不知道是哪一项起的作用，问题没好你也不知道该回滚哪一项。一次改一处，改完立即复测。

纪律二：改之前先备份配置。

# 华为：备份当前配置到本地
save
# 或者把配置导出到文件

# H3C：备份配置
save force

现场最惨的事故是「改了半天没改好，原配置也丢了」。

纪律三：先看现象证据，再动配置。 「用户说上不了网」不是证据，是描述。真正的证据是：display access-user 有没有他、display aaa online-fail-record 写的什么、接口 up 没 up。没有证据就改配置，等于蒙。

36.1.4 一张「先问三个问题」的分诊表

每次接到报障，先问三个问题，能瞬间缩小范围：

三问组合出来的六种情形：

这张表是本章的入口，遇到问题先查表，比翻命令快得多。

36.2 用户上不了线：PPPoE 卡在哪个阶段

36.2.1 方法：先确定卡在哪个报文

第 32 章讲过 PPPoE 的上线流程。排错时不要猜，要看计数：

# 华为：查看 PPPoE 报文统计
display pppoe statistics

# 排错前先清零，便于观察当前状态
reset pppoe statistics slot 1

判断逻辑（这张表是本节的核心）：

36.2.2 现象→排查命令→定位→处置

现象一：所有用户都卡在「正在查找服务器」（收不到 PADO）。

排查命令：

# 1. 看子接口是否 up
display interface brief | include GigabitEthernet1/0/2

# 2. 看子接口有没有绑 VT
display current-configuration interface GigabitEthernet1/0/2.1

# 3. 看有没有收到 PADI
display pppoe statistics

# 4. 看 VLAN 绑定
display current-configuration interface GigabitEthernet1/0/2.1

定位：

现象二：部分用户卡在找服务器，而且是在用户集中上线的时段（比如晚上、开学第一天）。

排查命令：

# 1. 看是不是 PADI 被限速了（H3C）
display current-configuration | include padi-limit

# 2. 看会话数是否接近上限
display access-user | count

# 3. 看 CPU（控制面是否过载）
display cpu-usage

定位：大量用户同时拨号 → PADI 洪水 → 触发 PADI 限速或控制面过载。

处置：

• 短期：调高 PADI 限速阈值（H3C pppoe-server padi-limit）。
• 长期：启用「接入延迟」让用户错峰接入（H3C pppoe-server access-delay），或提高单板规格。

现象三：用户能收到 PADO 但选了别的服务器（有多个 BRAS 时）。

排查：确认 BRAS 上的 AC 名配置。

# 华为：查看 AC 名
display current-configuration interface Virtual-Template1 | include ac-name

# H3C：AC 名配置
display current-configuration interface GigabitEthernet3/1/1.1 | include ac-name

处置：让不同 BRAS 用不同的 AC 名/服务名，并在客户端指定；或让用户端只接受特定的服务名。

现象四：会话数已达上限，新用户建不起来。

# 华为：看 BAS 接口的用户数限制
display current-configuration interface GigabitEthernet1/0/2.1 | include limit

# 看当前在线总数
display access-user | count

处置：调高 access-ip-limit（华为）或 pppoe-server session-limit（H3C），但要注意不要超过单板规格。

36.2.3 一个完整的现场排查实录

假设用户报「整栋宿舍楼都拨不上号」。按框架走：

   第1步 三问：
     全部用户（整栋楼）→ 系统性问题
     突然不好 → 查最近变更
     老用户？——都掉了

   第2步 看接口：
     display interface brief
     → 子接口 up，上行口 up，物理正常

   第3步 看计数：
     reset pppoe statistics slot 1
     （等30秒）
     display pppoe statistics
     → PADI 在涨，PADO 不涨

   第4步 缩小范围：
     BRAS 收到了 PADI 但没回 PADO
     → 问题在 BRAS 侧，不在接入层

   第5步 查 BRAS 侧为什么没回：
     display current-configuration interface GigabitEthernet1/0/2.1
     → user-vlan 正常，pppoe-server bind 正常
     display access-user | count
     → 会话数远超接口配置的上限！
     
   第6步 定位：接口 access-ip-limit 配置过小，或者会话数真的爆满

   第7步 处置：
     - 确认是配置太小 → 调大 limit
     - 确认是容量不足 → 分流到第二台 BRAS / 扩容

这个实录体现的方法就是：用计数把范围从「整栋楼」缩小到「BRAS 的某个接口参数」。没有计数，你可能会去查交换机、查光模块，白费两小时。

36.3 认证失败：RADIUS 不通 / 属性不匹配 / 域不匹配

36.3.1 方法：三问定位认证问题

认证问题的排查核心是第 33 章讲的三问，这里落地成操作步骤：

   Q1 服务器收到报文了吗？
      方式：在服务器上开 freeradius -X，看有没有输出
      
   Q2 回的是 Accept 还是 Reject？
      方式：看 -X 输出末尾的 Sent Access-xxx
      
   Q3 BRAS 能执行 Accept 吗？
      方式：看 display access-user 里用户状态与属性

36.3.2 现象→排查命令→定位→处置

现象一：所有用户认证失败，服务器日志一条记录都没有。

这是共享密钥问题或网络问题的典型特征。

# 1. 确认服务器可达
ping -a <BRAS源地址> <RADIUS服务器>

# 2. 确认 BRAS 认为服务器状态
display radius-server

# 3. 确认 BRAS 用的源地址
display radius-server configuration

# 4. 服务器侧用 -X 观察
#    freeradius -X

定位与处置：

「共享密钥」的排查技巧：不要靠肉眼比对，直接把服务器上的 secret 复制成 BRAS 上的一样的字符串（或在两边都临时改成一个简单的测试密钥），测通了再换回正式密钥。肉眼比对经常会漏掉首尾空格。

现象二：部分用户认证失败。

# 1. 查失败记录，确定失败的用户和原因
display aaa online-fail-record

# 2. 服务器侧看具体是哪个属性没匹配上
#    freeradius -X

定位：

域后缀不匹配是最常见的「部分用户失败」原因。 举例：

   BRAS 上发出去的用户名：user1@isp_dorm
   服务器 users 文件里配的：  "user1"  Cleartext-Password := "pass1"
                                                  ↑ 没有域后缀
   → 匹配不上 → notfound → 认证失败

处置：要么服务器上加上域后缀，要么用正则匹配（FreeRADIUS 支持 DEFAULT 或正则），要么在 BRAS 上去掉域名再发给服务器（部分设备支持「去掉域名」的配置）。

现象三：认证成功但用户上不了网（属性问题）。

# 1. 看用户状态
display access-user username user1@isp_dorm

# 2. 看用户拿到的 IP
#    如果 IP 是空的，说明地址分配失败

# 3. 看地址池
display ip pool name pool_dorm

定位：

「Framed-Pool 指向不存在的池」是一个很隐蔽的坑：服务器返回 Framed-Pool = "pool_vip"，但 BRAS 上根本没有名为 pool_vip 的池。此时认证成功，但地址分配失败，用户上不来。排查时要先查这个池在不在。

现象四：单个用户突然怎么都上不来，其他人都好。

# 1. 查是否有僵尸会话占着
display access-user username user1@isp_dorm

# 2. 有僵尸会话 → 踢掉
cut access-user username user1@isp_dorm

# 3. 查这个用户的历史失败记录
display aaa online-fail-record

# 4. 确认是不是这个用户的 Framed-IP-Address 被别人占了

僵尸会话产生的三种原因：用户异常断电（没发 PADT）、网络中断（BRAS 检测不到）、BRAS 主备切换。处置就是踢掉它，让它重新上线。

36.3.3 域不匹配的专属排查

域问题有个特点：用户能拨上号、认证也可能通过，但用的是错误的域，导致地址池不对、策略不对。

# 1. 看用户实际属于哪个域
display access-user username user1@isp_dorm

# 2. 看域的状态与绑定
display domain isp_dorm

# 3. 对比：这个域是否是你期望的那个

三种域错配的典型表现：

「用户走了默认域」是最常见的域问题，也是为什么第 32 章反复强调必须显式配置默认域。

36.4 地址池耗尽

36.4.1 现象

用户能通过认证，但卡在「正在获取 IP 地址」，或者认证记录显示「地址分配失败」。

这是 BRAS 里最容易误判的问题——因为现象看起来像认证问题，实际是地址不够。

36.4.2 排查与处置

# 1. 看地址池使用情况（最关键的一条命令）
display ip pool name pool_dorm

关键字段：

如果 idle 为 0：

# 2. 看是谁占着地址（是否有僵尸占位）
display ip pool name pool_dorm used

# 3. 看在线用户数，对比池容量
display access-user | count

# 4. 查是否有大量用户但池子很小（规划错误）

处置方案按优先级：

扩容的具体做法（华为）：既然 section 必须与网关同网段，扩容就分两种情况。

情况一：原网段还有没用完的地址（比如池里只放了 .2~.254，但网关掩码是 /23，还有半个网段空着）——直接加 section，仍在同网段内：

# 进入地址池
ip pool pool_dorm

# 追加一个地址段（与网关 10.200.10.1/23 同网段，合法）
section 1 10.200.11.2 10.200.11.254

commit

情况二：整个网段都用完了——不能靠加 section 解决，必须换更大的网段或新建池：

# 做法A：把整个池换成更大的网段（推荐，规划干净）
# 注意：换网段后所有用户都要重新上线拿新地址
ip pool pool_dorm
undo section 0
undo gateway 10.200.10.1 255.255.255.0
gateway 10.200.8.1 255.255.252.0
section 0 10.200.8.2 10.200.11.254
commit

# 做法B：新建一个池 + 新建一个域，把用户分流过去
# （适合不能中断现有用户的情况）

⚠ 千万别照抄网上的「给池子加个别的网段」——按官方约束那是配不进去的。判断方法很简单：看你的 gateway 掩码覆盖了多大范围，section 就必须落在那个范围内。 已核实（这条很重要，直接决定你能不能这么扩容）：NE40E 官方《Configuring an IPv4 Address Pool and an Address Pool Group》原文—— 「A maximum of 256 address segments can be configured in an address pool. An address segment contains at most 65536 IP addresses. The address segments cannot overlap each other. section and gateway ip-address { mask | mask-length } must be in the same network segment.」

所以结论是：

• 一个池可以配多个 section（最多 256 个），但所有 section 必须与网关在同一个网段内；
• 不能给一个池加「另一个网段」的 section——那样配不进去；
• 因此 section 1 10.200.11.2 10.200.11.254 这种跨网段加段是行不通的（上面那个示例仅用于说明"想加第二个网段"的意图，实际会被拒绝）。要扩到别的网段，必须新建一个池 + 新建一个域，或者把原网关的掩码放大。

URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/（User Access → IPv4 Address Management → Configuring an IPv4 Address Pool and an Address Pool Group）

更稳妥的扩容思路：如果原来的 /24 不够用，最干净的做法是直接换成一个更大的网段（如 /22），而不是在池里堆 section。代价是所有用户要重新上线拿新地址，但规划干净。

36.5 能拨号但上不了网

36.5.1 这是「最后一公里」问题

用户拨号成功、认证成功、拿到 IP，但打不开任何网页。这个现象在 BRAS 排错里极为常见，而且原因往往特别简单。

36.5.2 按顺序排查

# 第1步：用户路由存在吗？
display ip routing-table <用户IP>
# 期望：能看到 /32 的 UNR 路由

# 第2步：BRAS 能 ping 通用户吗？
ping -a <上行口IP> <用户IP>
# 通 → 二层和转发没问题

# 第3步：上游学到用户路由了吗？
# 在核心设备上：display ip routing-table <用户网段>
# 看不到 → import-route unr 没配

# 第4步：DNS 下发了吗？
display ip pool name pool_dorm
# 看 dns-server 字段是否为空

排查表：

「能 ping 通 IP 但打不开网页」= DNS 问题，这是个经典鉴别点。让用户 ping 114.114.114.114（如果能用），通了但打不开网页，就是 DNS。

36.6 频繁掉线

36.6.1 掉线的四种类型

   ① 探测超时掉线：BRAS 探测不到用户 → 判定掉线
   ② 会话老化掉线：空闲太久被踢
   ③ 强制下线：RADIUS 发 CoA 踢人 / 欠费
   ④ 链路掉线：物理链路闪断

36.6.2 排查与处置

# 1. 看用户的在线时长（普遍很短就是频繁掉线）
display access-user domain isp_dorm
# 看 Online time 字段

# 2. 看探测参数
display current-configuration interface Virtual-Template1 | include keepalive

# 3. 看是否有强制下线记录
display aaa online-fail-record

排查表：

「手机锁屏后掉线」是 IPoE 场景的经典问题：手机为省电会切断网络，BRAS 探测不到就判定掉线。处置是把在线检测的超时时间调长，或改用「有流量即在线」的检测方式。

36.7 能上网但慢 / 策略没生效

这部分内容在第 35 章已详细讲过，这里只给排查顺序：

# 1. 用户身上有策略吗？
display access-user username user1@isp_dorm

# 2. 域绑定了吗？
display domain isp_dorm

# 3. 实测速率（必须实测，不能只看配置）

36.7.1 「慢」的六种可能，怎么逐个排除

用户说「网速慢」是 BRAS 排错里最含糊的报障，因为它可能根本不是 BRAS 的问题。按排查成本从低到高排：

关键判断技巧：让用户测速，并对比「标称带宽」和「实测带宽」：

   实测 ≈ 标称 → 正常，用户以为慢是因为期望值不同
   实测 ≈ 标称的一半左右 → 典型的上下行配反或单速配置问题
   实测 ≈ 标称的 1/1000 → 限速单位配错
   实测很低但波动大 → 链路质量或丢包问题
   实测和标称都低，且所有用户都低 → 上游瓶颈

这个对照表能在一分钟内把「慢」定性，避免上来就扎进 BRAS 里翻配置。

36.7.2 限速不生效的华为专用检查法

华为 UCL 方案链路长，第 35 章讲了六环检查表，这里给一个在现场用起来更快的倒查法：

   从用户往配置倒着查：
   
   ① display access-user username xxx
      → 看这个用户身上有没有用户组 / 策略字段
      → 有 → 策略已下发，问题在策略内容本身（数值、方向）
      → 没有 → 往下
   
   ② display domain isp_xxx
      → User-group-name 是否为空
      → 为空 → 域没绑用户组（八成是这个）
      → 有 → 往下
   
   ③ display user-group
      → 用户组是否存在
      → 不存在 → 域里绑了个不存在的组（很少见但会发生）
      → 存在 → 往下
   
   ④ 查 UCL、分类器、行为、策略是否有断链

为什么要倒着查？ 因为排错的目标是「找到第一个断点」。正向查（从用户组一路往用户查）会看一堆没问题的配置，浪费时间；倒查则在第一个不通的地方就停下，直接命中。

36.8 常见告警与设备资源问题

36.8.1 先讲清楚：不要凭空猜告警名

BRAS 设备的告警名非常具体而且与版本强相关。本书不会给出任何未核实的告警名称，因为猜错的告警名会让你在设备的告警手册里根本查不到，反而误导。

正确的做法是：从设备上看到真实告警，再去查对应版本的告警手册。所以本节教的是「怎么看告警、怎么归类」，而不是「背告警名」。

36.8.2 怎么看告警

# 华为：查看当前告警
display alarm active

# 华为：查看告警历史
display alarm history

# 华为：查看日志
display logbuffer

# H3C：查看告警与日志
display alarm
display logbuffer

已核实的 NE40E 告警查询命令（出自 NE40E V800R023C10《Maintaining Fault Management》）：

命令	作用
display alarm active	查看当前活动告警
display alarm history	查看历史告警
display alarm information [ name <alarm-name> ]	查看告警配置信息
display alarm statistics [ name <alarm-name> ]	查看告警统计

URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/（System Management → Maintaining Fault Management）

H3C 侧通用的 display alarm 本书未取到 CR16000 官方原文，仍建议以设备 ? 为准。

36.8.3 告警按影响面分类（这才是排错需要的分类）

不管告警名叫什么，按影响面分类才有助于决策：

最应该先看的是「资源耗尽类」，因为它最容易被忽略，但影响面最大。

36.8.4 资源类问题的排查路径

① CPU 高

# 看 CPU 历史曲线（判断是突发还是持续）
display cpu-usage history

# 看各进程占用
display cpu-usage

判断逻辑：

   CPU 高 + 流量正常 → 处理协议/控制面报文的压力
       ├─ 大量 PADI/PPP 报文 → 攻击 或 用户反复重拨 → 查 PPPoE 统计
       ├─ 路由协议震荡 → 查路由邻居日志
       └─ SNMP 轮询过频 → 调低轮询频率
   
   CPU 高 + 流量也高 → 转发面压力（通常由硬件转发，不该打满 CPU）
       └─ 查是否有大量报文需要上送 CPU（如 ACL 未命中）

关键判断：如果已经在线的用户能上网，但新用户上不来 + CPU 高，这几乎可以肯定就是控制面被攻击或被打满（第 31 章讲过的分诊原则）。

② 内存高

# 华为：查看内存
display memory-usage

内存持续上涨通常是表项泄漏，需要记录趋势并联系厂商。不要靠重启解决——重启只能临时缓解，根因还在。

③ 会话/表项满

# 看当前在线用户数
display access-user | count

# 对比单板规格

如果接近规格上限，就是容量问题，需要扩容或分流。

④ 温度/风扇

# 华为：查看设备温度与风扇状态
display temperature
display fan

温度过高会触发保护性降频，表现是性能下降但不报错。这是最隐蔽的一类问题——设备没坏，但就是慢。

36.8.5 安全类问题的识别

BRAS 是网络的入口，也是攻击的主要目标。识别安全攻击有几个稳定的指纹：

PADI 洪水的识别最关键：它的典型表现是第 31 章讲的分诊原则——老用户能上网，新用户上不来，CPU 高。因为 PADI 是控制面报文，打满的是控制面，不影响已经在线的用户数据转发。

一旦确认是攻击，可用的处置手段（按副作用从小到大）：

   ① 启用 PADI 限速（H3C: pppoe-server padi-limit）——立即生效，副作用小
   ② 启用用户阻断（H3C: pppoe-server connection chasten）——封掉高频请求者
   ③ 启用 PPP 认证失败阻断（ppp authentication chasten）——防暴力破解
   ④ 在上游设备做流量清洗——需要其他设备配合

注意：这些防护参数本身也可能造成误伤。PADI 限速设得太低，正常用户集中上线也会被限。防护参数要在「攻击能挡住」和「正常用户不被误伤」之间找平衡，建议在正常业务量下先观察基线，再按 2~3 倍基线设限。

36.8.6 一个具体的资源类排查实录

假设现象：晚上 8 点开始，新用户大面积拨不上号，但已经在线的人上网正常，9 点半自己好了。

按框架：

   第1步 三问：
     全部用户（新用户）→ 系统性
     突然不好，且每天同一时段 → 时间相关性
     老用户正常，新用户不上 → 控制面问题（30章分诊原则）

   第2步 看资源：
     display cpu-usage history
     → CPU 在 8 点冲到 90%+，9 点半回落
     
   第3步 看是什么在吃 CPU：
     display cpu-usage
     → 找到 PPP/认证相关进程占用高
     
   第4步 看报文统计：
     display pppoe statistics
     → PADI 计数暴涨
     
   第5步 定位：
     晚上 8 点是用网高峰，大量用户同时上线/重拨
     → 控制面处理不过来 → 新用户上不了
    
   第6步 处置：
     短期：启用接入延迟错峰、调高 PADI 限速
     长期：扩容 / 分流到多台 BRAS / 提高单板规格

这个案例的关键在于第 1 步就锁定了「控制面」，后面所有排查都是围绕这一点去取证的。如果没有分诊原则，你可能会去查 RADIUS、查地址池，全都白查。

36.9 六个真实故障场景的完整复盘

前面讲了方法和单点排查，这里给六个完整场景，每个都按「现象 → 排查过程 → 根因 → 处置 → 经验」写。这些场景覆盖了现场 80% 的实际故障类型。

36.9.1 场景一：开学第一天，宿舍区大面积拨号失败

现象：开学第一天上午 9 点开始，某栋宿舍楼的学生集体反映拨号失败，其他楼栋正常。

排查过程：

   ① 分诊三问
     部分用户（一栋楼）→ 区域性问题
     突然发生，时间点明确 → 与并发量有关
     其他楼栋正常 → BRAS 整体没挂

   ② 看 BRAS 全局
     display access-user | count
     → 总数在正常范围，不是全局容量问题

   ③ 看该楼对应的子接口与VLAN
     display interface brief | include GigabitEthernet1/0/2
     → 子接口 up

   ④ 看 PPPoE 统计
     reset pppoe statistics slot 1
     display pppoe statistics
     → PADI 涨、PADO 涨、PADR 涨、PADS 不涨

   ⑤ 定位到"会话建不上"
     → 查该子接口的会话数与限制
     display current-configuration interface GigabitEthernet1/0/2.1 | include limit
     → access-ip-limit 300

   ⑥ 查实际在线数
     display access-user domain isp_dorm_a | count
     → 312

根因：该楼栋子接口的 access-ip-limit 配的是 300，但实际住了 400 多人（暑期扩招了一栋新宿舍）。学生集中入住后，在线上限 300 被占满，第 301 个开始全部建不上会话。

处置：

• 紧急：把 access-ip-limit 调到 600（同时确认单板规格够），重新 commit。学生立即恢复。
• 长期：按实际入住人数重新规划，并把所有楼栋的 limit 统一核对一遍。

经验：access-ip-limit 这类「限额」配置，在人员变动时是最容易被遗忘的老配置。开学、换宿舍、扩招都是它的暴露时机。建议每学期开学前主动核对一次。

36.9.2 场景二：换了 RADIUS 服务器后，全部用户认证失败

现象：运维把 RADIUS 服务器从 10.200.1.10 换成了新服务器 10.200.1.11，改完配置后所有用户认证失败。BRAS 上看起来配置都对。

排查过程：

   ① 分诊三问
     全部用户 → 系统性问题
     刚做过变更 → 高度可疑是变更导致
     老用户也掉 → 影响面全

   ② 看 BRAS 侧服务器状态
     display radius-server
     → 新服务器显示 Down / 不可达

   ③ 但 ping 是通的
     ping -a 10.200.0.2 10.200.1.11
     → 通！

   ④ 关键判断：能 ping 通但 RADIUS 不可达
     → 不是网络层问题，是 UDP 层问题

   ⑤ 在新服务器上开调试
     freeradius -X
     → 完全没有任何日志输出

   ⑥ 查 BRAS 的源地址
     display radius-server configuration
     → 源接口没配！
     → BRAS 用出口接口地址作为源，而出口地址是 10.200.0.6
     
   ⑦ 查新服务器的 clients.conf
     → 里面只写了旧的 BRAS 源地址 10.200.0.2
     → 新服务器不认识 10.200.0.6 这个客户端

根因：BRAS 没有配置 radius-server source interface，源地址使用出口接口地址（10.200.0.6）；而新 RADIUS 服务器的 clients.conf 里只登记了旧的 BRAS 地址 10.200.0.2。服务器把来自未知客户端的报文直接丢弃，连日志都不留。

处置：

# 配置固定的源接口（这是根治手段）
radius-server source interface LoopBack0
commit

同时在服务器 clients.conf 中加入 BRAS 的 LoopBack 地址。

经验：这个故障的迷惑性在于「ping 通」。ping 通只证明 IP 层可达，完全不代表 UDP 1812 可达、更不代表服务器认这个客户端。换 RADIUS 服务器时，第一件事就是核对源地址与 clients.conf 是否匹配。

36.9.3 场景三：整个校区能拨号，但打不开网页

现象：用户全部能拨号成功、能拿到 IP，但打开任何网页都超时。用户 ping 网关能通，ping 外网 IP 也能通。

排查过程：

   ① 分诊三问
     全部用户 → 系统性
     突然不好 → 查变更
     
   ② 用户能 ping 通外网 IP，但打不开网页
     → 典型 DNS 问题特征
     
   ③ 查 BRAS 下发的 DNS
     display ip pool name pool_dorm
     → dns-server 字段为空！
     
   ④ 但以前是好的，为什么现在是空的？
     → 查最近变更
     → 发现昨天有同事重建过地址池（删了重建）
     → 重建时漏了 dns-server 配置
     
   ⑤ 同时确认：用户端手动设 DNS 能上网
     → 验证了判断

根因：地址池被重建时漏配 dns-server，用户通过 IPCP 拿不到 DNS 服务器地址，无法解析域名。

处置：

# 补配 DNS
ip pool pool_dorm
dns-server 10.200.1.53
commit

配置生效后需让用户重新拨号（因为 DNS 是在 IPCP 阶段下发的）。

经验：「能 ping 通 IP、打不开网页」是 DNS 问题的标准指纹。这个故障的教训是「重建对象时容易漏参数」——改配置前先 display current-configuration 记下原有参数，重建后逐项对比。

36.9.4 场景四：单个 VIP 用户每天固定时间掉线一小时

现象：某学院院长反映，每天下午 3 点到 4 点网络断开，其他时间正常。其他用户都正常。

排查过程：

   ① 分诊三问
     单个用户 → 用户侧或账号问题
     每天固定时间 → 与某种周期性事件有关
     其他人正常 → 不是 BRAS 整体问题

   ② 查该用户的在线状态
     display access-user username dean@isp_vip
     → 有时查得到，有时查不到
     → 掉线时确实不在线

   ③ 查失败记录
     display aaa online-fail-record
     → 能看到该用户频繁的失败记录
     → 失败原因：会话数超限 / 同账号已有会话

   ④ 查是不是有僵尸会话
     display access-user username dean@isp_vip
     → 查到两个会话！同一个用户名，两个不同的 MAC
     
   ⑤ 定位：有人在用院长的账号
     → 两个 MAC 一个是院长的电脑，另一个是某个学生的设备
     → 学生盗用账号在下午茶时间上网
     → 一个账号只允许一个会话，所以院长被踢

根因：账号被盗用。院长的账号被学生知道，学生在下午固定时段用这个账号上网，导致院长被挤下线。

处置：

• 立即：改密码，并把旧会话踢掉（cut access-user）。
• 长期：启用「单账号单会话」限制 + 账号异常登录告警；考虑启用 MAC 绑定。

经验：「单个用户 + 固定时间 + 有规律」这三个特征凑在一起，要高度怀疑账号盗用或设备冲突。查「同一用户名下有几个会话」是识别盗用的有效手段。

36.9.5 场景五：某台 BRAS 上所有用户上网都很慢，但带宽监控正常

现象：整台 BRAS 下的用户都反映网速慢、打开网页卡，但带宽监控显示链路利用率只有 20%。

排查过程：

   ① 分诊三问
     全部用户 → 系统性
     一直不好（最近几天逐渐变差）→ 渐进性问题，不是突然故障
     能上网但慢 → 不是通了断的问题

   ② 带宽正常但都慢 → 怀疑资源类问题
     display cpu-usage history
     → CPU 长期在 60%~70%，不算特别高
     
   ③ 查会话/表项
     display access-user | count
     → 在线用户数与平时相当
     
   ④ 查温度（最容易忽略的一项）
     display temperature
     → 温度接近告警阈值！
     
   ⑤ 查风扇
     display fan
     → 有两个风扇转速偏低/故障
     
   ⑥ 定位：风扇故障 → 散热不足 → 温度升高 → 设备保护性降频
     → 转发性能下降 → 所有用户都慢

根因：机柜风扇故障导致散热不良，设备触发保护性降频，转发性能下降。

处置：

• 立即：更换故障风扇，清理机柜灰尘，检查机房空调。
• 短期：加大机柜通风。

经验：「带宽正常、CPU 不算高、但所有人都慢」这类问题，一定要查温度。设备降频不会报错，只会「悄悄地变慢」，这是最难查的一类故障。建议把 display temperature 加入日常巡检项。

36.9.6 场景六：配了限速，但用户测速跑满带宽

现象：给某个学生用户配了 100M 限速，但用户实测能跑到 1Gbps（跑满了接入端口）。

排查过程：

   ① 分诊三问
     单个用户 → 该用户的策略问题
     一直不好 → 配置问题
     
   ② 查用户身上有没有策略
     display access-user username student1@isp_dorm
     → 用户组字段为空！
     
   ③ 说明策略根本没应用到这个用户
     
   ④ 查域绑定
     display domain isp_dorm
     → User-group-name 字段为空
     
   ⑤ 定位：域没有绑定用户组，所以整套 UCL 策略从未生效
     
   ⑥ 进一步查：用户组、ACL、分类器、行为、策略都配了
     但少了"域里绑定用户组"这一步
     → 前面所有配置都是孤儿对象

根因：UCL 策略的完整链路是「用户组 → ACL → 分类器 → 行为 → 策略 → 应用到 UCL → 域绑定用户组」。最后一步「域绑定用户组」漏了，导致整条链路没有生效，且设备没有任何告警。

处置：

# 补上域绑定
aaa
domain isp_dorm
user-group ug_student
commit

经验：华为的 UCL 方案最容易「配了一堆但没生效」，因为没有强制的完整性检查。第 35 章给的那张六环检查表就是为这个准备的。配完 UCL，一定要回到 display access-user 确认用户身上真的看到了策略字段。

36.10 排错证据收集清单

排错时最有价值的动作是在问题复现的当下收集证据。问题一旦过去，很多证据就消失了（比如在线用户、会话表、瞬时 CPU）。所以建议养成「先收证据再动手」的习惯。

36.10.1 十五分钟证据包

遇到故障，先花 5 分钟把下面这份「证据包」收齐，再动手改任何配置：

# ===== 第一组：设备状态 =====
display version
display device
display cpu-usage
display memory-usage
display temperature

# ===== 第二组：接口与链路 =====
display interface brief
display interface GigabitEthernet1/0/2

# ===== 第三组：用户与会话 =====
display access-user | count
display aaa online-fail-record

# ===== 第四组：地址与路由 =====
display ip pool name pool_dorm
display ip routing-table statistics

# ===== 第五组：PPPoE 报文 =====
display pppoe statistics

# ===== 第六组：日志与告警 =====
display logbuffer
display alarm active

为什么要收全六组？ 因为 BRAS 的故障常常是「连锁反应」，单看一组看不出因果。举例：

   只看"用户上不了线" → 可能是认证问题
   收全证据后：
     CPU 90% + PADI 暴涨 + 在线用户数正常
     → 立刻能判断是"控制面被攻击/过载"，不是认证问题

证据包的价值在于：它把「猜」变成了「比」。 收集到的每一组数据，拿去和正常基线比，异常项自然浮现。

36.10.2 建立你自己的基线

上面那份证据包，必须在设备正常时就跑一遍并记录，形成「基线」。没有基线，你看到 CPU 60% 不知道该判好还是判坏。

建议每台 BRAS 单独建一份基线档案，新设备上线时记录，之后每季度更新一次。这份档案在故障判断时的价值，远超任何一本命令手册——因为排错本质上是「找异常」，而异常是相对基线而言的。

36.10.3 现场沟通话术（同样是排错能力）

技术之外，还得会问。把用户的描述翻译成技术线索，是排错效率的分水岭：

追问的价值：把「网断了」追问到「拨号卡在正在获取 IP 地址」，你就已经直接跳到了 35.4 节的排查路径，省掉前面所有环节。

36.11 排错命令速查表

把本章所有命令汇总，现场可直接查：

36.11.1 H3C 侧已核实的对应命令（本轮补充）

上一张表里标「按版本」的 H3C 命令，本轮已核实了其中几条关键的，补在下面。这些是能直接拿去用的：

这两条对第 35.2 节的「报文计数分诊法」特别有用，因为它们把华为那套方法完整对应到了 H3C 上：

# H3C：查看 PPPoE 协商报文统计（对比 PADI/PADO/PADR/PADS 的收发与丢弃计数）
display pppoe-server packet statistics slot 3

官方输出长这样，字段直接对应四个发现报文：

PPPoE Server packet statistics in slot 3:
RECV_PADI_PKT       : 10        DISCARD_PADI_PKT : 0
SEND_PADO_PKT       : 10
RECV_PADR_PKT       : 10        DISCARD_PADR_PKT : 0
SEND_PADS_PKT       : 10
RECV_PADT_PKT       : 9         DISCARD_PADT_PKT : 0
SEND_PADT_PKT       : 9

注意它比华为多了一组 DISCARD_xxx_PKT（丢弃计数）——这个字段非常有价值：如果 RECV_PADI_PKT 在涨而 SEND_PADO_PKT 不涨、同时 DISCARD_PADI_PKT 也在涨，说明是 PADI 被限速或防攻击策略丢掉了，直接命中根因，不用再往下猜。

第二条更能直接定位「卡在第几阶段」，因为 display pppoe-server session summary 会印出每个会话的状态：

# H3C：看会话状态（State 字段直接告诉你卡在哪一步）
display pppoe-server session summary interface gigabitethernet 3/1/1

Total PPPoE sessions: 2

  Ethernet interface: GE3/1/1                 Session ID: 1
  PPP index: 0x140000105                      State: PADR_RCVD
  Remote MAC: 00e0-1500-7100                  Local MAC: 00e0-1400-7300

  Ethernet interface: GE3/1/1                 Session ID: 2
  PPP index: 0x150000105                      State: OPEN
  Remote MAC:00e0-1600-7200                   Local MAC: 00e0-1400-7300

对照第 35.2 节的故障树读这个输出：

上一张表里仍未核实的 H3C 命令（display alarm、display logbuffer、display ip pool 等通用命令）属于全网通识命令，本书未逐条取到 CR16000 官方原文，实施前仍建议以设备 ? 帮助二次确认。区分「已核实」和「通识但未取原文」这两档，是这一轮核实最重要的诚实。

36.12 新手踩坑与注意事项

1. 不先分诊就开始改配置——先问「全部还是个别、一直还是突然」，能省一半时间。
2. 同时改多个变量——改完不知道是哪项起的作用，问题复现时也无法定位。
3. 改配置前不备份——现场最惨的事故。
4. 只看「用户说上不了网」就动手——那不是证据。先看 display access-user。
5. 把地址池耗尽误判成认证问题——最典型的方向性错误。认证通过但拿不到地址，先查池。
6. 忘了华为的 commit——配置看起来对但没生效，第一反应查提示符有没有 ~。
7. 共享密钥靠肉眼比对——首尾空格肉眼看不出来，复制粘贴才可靠。
8. 查 RADIUS 时不看服务器状态——H3C 服务器被标记不可用时，请求根本发不出去，查服务器日志永远查不到。
9. 「能 ping 通 IP 但打不开网页」直接上 BRAS 查——九成是 DNS，先查 dns-server 有没有下发。
10. 重启解决内存泄漏——临时缓解，根因还在，下次更严重。
11. 温度告警当小事——高温触发降频，表现是「莫名其妙的性能下降」。
12. 不记录排错过程——同一类故障第二次遇到时又从头查。

36.13 本章小结

• 排错的核心不是背命令，是有固定顺序：先分诊 → 定位到层 → 取证 → 假设 → 只改一处 → 复测。
• 三问分诊法：全部还是个别？一直还是突然？老用户正常吗？三问能瞬间缩小范围。
• PPPoE 排错靠报文计数（display pppoe statistics），PPPoE 涨到 PADS 说明链路层 OK，转查认证。
• 认证排错靠三问：服务器收到了吗？回 Accept 还是 Reject？BRAS 能执行吗？
• 地址池耗尽是最容易误判的问题：认证通过但拿不到地址，先查 idle。
• 能拨号但上不了网，按「用户路由 → BRAS ping 用户 → 上游路由 → DNS」顺序查。
• 频繁掉线先分类型：探测超时、空闲老化、强制下线、链路掉线。
• 资源类告警（CPU/内存/温度）最容易被忽略，但影响面最大。CPU 高 + 老用户正常 + 新用户不上 = 控制面问题。
• 告警名不要猜，从设备上看到真实告警再查手册。

适用版本：华为 NE40E V800R023C10 系列；H3C CR16000-F Release 795x。注意：本章 H3C 侧的具体排查命令多数未能逐条核实，正文与速查表已明确标注，现场使用前必须以设备版本命令参考核对。

自测题

1. 用户报「上不了网」，你应该先问哪三个问题？
2. display pppoe statistics 显示 PADI 在涨但 PADO 不涨，说明什么？
3. 认证成功但用户卡在获取 IP 地址，最应该先查什么？
4. 用户能 ping 通 IP 但打不开网页，最可能是什么问题？
5. 「CPU 高、老用户能上网、新用户上不来」，最可能的定位是什么？

1. ①是全部用户还是个别用户；②是一直不好还是突然不好；③老用户是否正常（其他功能是否正常）。这三问能快速区分系统性问题、配置问题、变更问题与用户侧问题。
2. 说明 BRAS 收到了用户的 PADI 请求但没有回 PADO。可能原因包括：接口没有绑定 VT、PADI 被限速、会话数已达上限、单板资源不足。问题在 BRAS 侧，不在接入层。
3. 先查地址池：display ip pool name <pool>，看 idle 字段是否为 0（耗尽），以及 used 与总容量。其次检查域是否绑定了地址池。
4. 最可能是 DNS 问题（未下发 DNS 服务器地址，或下发的 DNS 不可达）。此外也可能是 ACL 拦截了 53 端口、或上游 DNS 服务器故障。
5. 最可能是控制面（Control Plane）被打满或过载，例如遭受 PADI 洪水攻击、大量用户同时重拨、或路由协议震荡。因为老用户的数据转发走转发面，不受控制面影响；而新用户上线需要控制面处理认证和会话创建。

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