华为H3C实战 | 第32章 BRAS PPPoE 服务器配置

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

← 上一篇：第 31 章 BRAS 定位与组网 　下一篇：第 33 章 AAA 认证与 RADIUS 对接 →

本章导读：PPPoE 让以太网这种广播网冒充成一对一专线，于是才有了一人一账号、一人一地址、一人一会话。本章把 PADI/PADO/PADR/PADS 到 LCP、认证、IPCP 的上线全流程和 BRAS 侧完整配置讲透。

本章结构：

• 32.1 功能原理与业务场景 —— PPPoE 为什么存在、上线九步报文流程图、四个发现报文怎么记、BRAS 侧 VT/域/地址池 /AAA 各在什么位置起作用
• 32.2 华为设备配置详解 —— VT 接口、PPPoE 服务器、地址池、AAA 对接的完整配置模板
• 32.3 H3C 设备配置详解 —— H3C 侧写法与差异标注
• 32.4 华为 / H3C 命令对照表
• 32.5 配置验证 —— 拨号成功后该看到哪些会话与接口状态、地址分配是否正常
• 32.6 排错与故障树 —— “卡在哪个报文"定位法，逐阶段分支
• 32.7 新手踩坑与注意事项
• 32.8 本章小结

重点提示：配之前先背 32.1.2 那张报文表，排错时全靠"用户卡在哪个报文"来定位；上线后一定用 32.5 验地址与计费是否都起来了——能上网但没账单是常见假成功。改 VT 参数必须安排用户重新拨号，原理见第 31 章 31.6。 关联章节：BRAS 定位、VT/VA 与 A/B 面模型见第 31 章；认证与计费的 RADIUS 对接见第 33 章；PPP 与 PPPoE 协议原理见第 15 章。

32.1 功能原理与业务场景

32.1.1 这功能是干嘛的（通俗版）

PPPoE（以太网上的点对点协议，Point-to-Point Protocol over Ethernet）干的事情，一句话：让以太网这种「大喇叭广播」的网络，冒充成一根「一对一专线」。

以太网天生是个广场——所有设备共享一个广播域，谁说话大家都能听见。可 PPP 协议是设计给拨号线路的，它默认「这根线只连着你和我」。这两者本来不兼容。PPPoE 的巧思在于：在以太网帧里先套一层「会话号」，把广场上的每个人临时切出一根虚拟的独占线，然后在线上跑 PPP。

用生活化的说法：小区公共广播系统（以太网）本来是所有人一起听的，PPPoE 相当于给每户人家配一个专属频点，你听你的、我听我的；拨号就是「申请开通频点」，挂断就是「注销频点」。

所以 PPPoE 的三个核心价值是：

• 一人一账号：每个用户独立认证，运营商能按人收费。
• 一人一地址：每个用户独立分配 IP，不像 NAT 后所有人共用一个公网地址。
• 一人一会话：上下线可控、流量可计、欠费可断。

32.1.2 上线全流程：报文是怎么走的

这是本章的骨架，请务必把它读透。PPPoE 用户上线分两大阶段：先是 PPPoE 协商（找服务器、建会话），再是 PPP 协商（认证、分地址）。

  用户(PPPoE Client)                          BRAS(PPPoE Server)
  ─────────────────                          ──────────────────
  ① PADI  ────── 广播「谁是服务器？」──────────→
                          ←────── ② PADO「我是，我的AC名是 xxx」
  ③ PADR  ────── 「那我就选你」──────────────→
                          ←────── ④ PADS「成交，会话号是 0x1234」
     ┌─────────────── PPPoE 会话建立（阶段一结束）───────────────┐
  ⑤ LCP  Configure-Request ────────────────→
                          ←────── LCP  Configure-Ack（协商MRU/认证方式）
  ⑥ CHAP Challenge ←───────────────────────
     CHAP Response ────────────────────────→
                          ←────── CHAP Success（或 Failure）
     （若为 PAP：直接发 PAP Authenticate-Request，等 ACK/NAK）
  ⑦ IPCP Configure-Request（申请IP）────────→
                          ←────── IPCP Configure-Nak（告诉你该用哪个IP）
     IPCP Configure-Request（我接受这个IP）──→
                          ←────── IPCP Configure-Ack
     ┌─────────────── PPP 协商完成，用户可以上网了 ───────────────┐
  ⑧ 上网数据 ◄──────────────────────────────► 转发
  ⑨ 下线：PADT ─────────────────────────────→  销毁会话、回收地址、发计费Stop

四个 PPPoE 报文必须背下来，因为排错时就靠「卡在哪个报文」来定位：

记忆口诀：I 是 Initiation（我先喊），O 是 Offer（你报价），R 是 Request（我下单），S 是 Session（成交），T 是 Terminate（散伙）。

32.1.3 PPP 协商三小步，每步都可能卡

PPPoE 会话建起来之后，PPP 还要走三步，这三步是排错的主战场：

   LCP（链路控制协议）      协商链路参数：MRU、认证方式、魔术字
        ↓
   PAP / CHAP（认证）       你要证明你是你
        ↓
   IPCP（IP控制协议）       分配 IP 地址、DNS、网关

• 卡在 LCP：一般是 VT 没绑到接口、认证方式不匹配、MTU/MRU 协商不上。
• 卡在 PAP/CHAP：账号密码错、RADIUS 不通、域选错、共享密钥不一致。
• 卡在 IPCP：地址池没地址了、池子没绑到域、网关配错。

这个「三小步」和「四大阶段」的对应关系，是第 36 章那棵故障树的理论基础。

32.1.4 设计视角：一个园区网该怎么划

假设你要给一个学校的 8 栋宿舍楼做 PPPoE 接入，规划思路是：

   宿舍楼1~4  VLAN 100-199 ──┐
                              ├─→ GE1/0/2.1  user-vlan 100 199
                                  域 isp_dorm_a  池 pool_dorm_a
   宿舍楼5~8  VLAN 200-299 ──┤
                              ├─→ GE1/0/2.2  user-vlan 200 299
                                  域 isp_dorm_b  池 pool_dorm_b
   上行核心口 GE1/0/1 ───────┴─→ 普通三层口，配IP跑OSPF

四条规划铁律：

1. 一个业务域一段 VLAN：不要一栋楼一个域，域太多管不过来；按「认证策略相同」来分组。
2. 一个域一个池：池子大小按该域并发用户数 × 1.25 估。
3. 子接口不配 IP：只绑 VLAN、绑 VT。
4. 上行口跑路由，并 import-route unr：用户路由是 /32 主机路由，属于 UNR（用户网络路由，User Network Route），必须显式引入到 OSPF，否则核心侧不知道怎么回程。

第 4 条是新手必踩的坑：用户全上线了、BRAS 自己 ping 得通外网、但用户 ping 不通——八成就是没做 import-route unr。

32.1.5 PAP 与 CHAP 到底差在哪（选错会踩坑）

两个认证方式的差别，决定了你后面排错时该看哪里：

   PAP（密码认证协议）                 CHAP（挑战握手认证协议）
   ─────────────────                   ────────────────────
   客户端 ── 用户名+密码(明文) ──→     服务器 ── 挑战随机数 ──→ 客户端
   服务器 ── Accept/Reject ──→        客户端 ── 哈希(密码+随机数) ──→ 服务器
                                      服务器 自己算一遍比对

选型建议：生产环境一律 CHAP。只有当客户端设备太老、只支持 PAP 时，才在 VT 上改 ppp authentication-mode pap。也有一个折中做法是用 auto，让设备自己跟客户端协商——但 auto 的代价是你可能不知道最终用了哪种，排错时反而更难，所以不推荐在大型网络使用。

还有一个容易被忽略的坑：CHAP 的密码在 RADIUS 服务器上必须能以明文形式取到。因为 CHAP 是服务器和客户端各自算哈希，服务器必须拿到原始密码才能算。如果你在 FreeRADIUS 里用 CHAP-Password 类属性配了不可逆的密码存储方式，CHAP 就认证不过。这一点在第 33 章会展开。

32.1.6 一个用户在线时，BRAS 内部发生了什么

把这层说清楚，你就能理解为什么「用户在不在线」和「接口 up 不 up」是两件完全不同的事：

   ┌─────────────── BRAS ───────────────┐
   │ 1. 会话表：User-Name / MAC / IP /     │  ← display access-user 看的是这里
   │    上线时间 / 所属域 / 会话ID         │
   │ 2. 地址池表：哪个 IP 给了谁           │  ← display ip pool 看的是这里
   │ 3. 路由表：该用户的 /32 主机路由      │  ← display ip routing-table 看的是这里
   │ 4. 转发面：会话表项（芯片里）          │  ← 不显示在配置里，但数据走这里
   │ 5. 计费：已用时长、上下行流量          │  ← display access-user 里能看流量
   └─────────────────────────────────────┘

这五张表必须同时存在且一致，用户才真正能上网。任何一个环节缺失，就会出现「看起来在线但用不了」：

**「五表齐备」**这个概念非常好用：以后遇到任何 BRAS 业务异常，先按这五张表逐个查一遍，命中率极高。

32.2 华为设备配置详解

32.2.1 命令行基础速览

本章用到的华为命令集中在「VT」「地址池」「域」「BAS 接口」四类，先给速览，再看完整模板：

# 进入系统视图
system-view

# 建虚拟模板并配 PPP 参数
interface virtual-template 1

# 建本地地址池
ip pool pool_dorm bas local

# 进入 AAA 视图配域
aaa
domain isp_dorm

# 把接口变成 BAS 接口
interface GigabitEthernet1/0/2.1
bas

32.2.2 完整配置模板（可直接照抄）

下面这份配置是完整可运行的，按顺序敲即可。为了清晰，分成六段给出。注意每段末尾都要 commit。

第一段，VT 虚拟模板——定义所有用户的 PPP 协商参数：

# 进入系统视图
system-view

# 建虚拟模板 1（模板号后续被接口绑定）
interface virtual-template 1

# 认证方式 chap：比 pap 安全，密码不在线上明文传输
ppp authentication-mode chap

# 探测：每 60 秒探一次，连续 3 次不应答就认为用户掉线
ppp keepalive interval 60
ppp keepalive retransmit 3

# MTU 设 1492（PPPoE 头部占 8 字节，1500-8=1492）
mtu 1492

# 提交
commit
quit

第二段，地址池——用户从这里领 IP：

# 建 BAS 本地地址池，名字 pool_dorm
ip pool pool_dorm bas local

# 网关地址与掩码（注意：这个网关不落在任何物理接口上）
gateway 10.200.10.1 255.255.255.0

# 可分配地址段：段号 0，从 .2 到 .254
section 0 10.200.10.2 10.200.10.254

# 下发给用户的 DNS
dns-server 10.200.1.53

# 提交
commit
quit

第三段，RADIUS 服务器组与认证计费方案：

# RADIUS 服务器组 rd1
radius-server group rd1
radius-server shared-key-cipher Bras@2024
radius-server authentication 10.200.1.10 1812
radius-server accounting 10.200.1.10 1813
commit
quit

# AAA 视图下建认证方案与计费方案
aaa
authentication-scheme auth_radius
authentication-mode radius
quit
accounting-scheme acct_radius
accounting-mode radius
quit

第四段，域——把上面三样串起来：

# 仍在 aaa 视图内
domain isp_dorm

# 绑定认证方案、计费方案、RADIUS 服务器组
authentication-scheme auth_radius
accounting-scheme acct_radius
radius-server group rd1

# 绑定地址池
ip-pool pool_dorm

# 提交
commit
quit
quit

第五段，接口侧——子接口绑 VLAN 与 VT，并声明为 BAS 接口：

# 进入子接口（面向用户侧）
interface GigabitEthernet1/0/2.1

# 绑定用户侧 VLAN 100~199
user-vlan 100 199

# 提交一次再往下配（VLAN 绑定后视图会切换）
commit

# 把 VT 1 绑到这个子接口，PPPoE 服务器在此启用
pppoe-server bind virtual-template 1

# 提交
commit
quit

# 重新进入子接口，创建 BAS 接口
interface GigabitEthernet1/0/2.1
bas

# 指定接入类型为二层普通用户，并指定默认认证域
access-type layer2-subscriber default-domain authentication isp_dorm

# 提交
commit
quit
quit

第六段，上行路由——让核心侧知道用户在哪里：

# 上行口配 IP（普通三层口，与用户侧完全无关）
interface GigabitEthernet1/0/1
ip address 10.200.0.2 255.255.255.252
commit
quit

# OSPF 里引入 UNR 路由（用户 /32 主机路由就是 UNR）
ospf 1
import-route unr
area 0.0.0.0
network 10.200.0.0 0.0.0.3
commit
quit
quit

# 保存
save

32.2.3 逐行讲解

下面是每条命令的「干什么 / 为什么这么填 / 反例」：

再单独解释几个容易被问到的点：

为什么要设 mtu 1492？ PPPoE 帧在以太网帧上加了 6 字节 PPPoE 头 + 2 字节 PPP 协议字段，共 8 字节。以太网 MTU 是 1500，所以 PPPoE 的可用 MTU 是 1492。如果你保持 1500，超过 1492 的包会因 DF 位被丢弃，表现是网页打一半就卡、大文件下载中断、能 ping 小包 ping 不通大包——这是 PPPoE 最经典的故障。

user-vlan 100 199 和 vlan-type dot1q 100 有什么区别？ 前者是 BAS 的「用户侧 VLAN」模型，用于 PPPoE/IPoE 二层普通用户接入；后者是普通三层子接口的 VLAN 终结，用于三层用户。两个不能混用，文档明确写了「如果子接口已配置 dot1q termination、QinQ termination、QinQ stacking 或 vlan-type dot1q，则不能再配 user-vlan」。

为什么 bas 之前要重新进入子接口？ 因为 user-vlan 命令执行后视图会切换到 xxx-vlan-100-199，需要 quit 回接口视图再操作。这也是上面模板里为什么要 commit 两次、进出两次的原因。

32.2.4 PPPoE 服务器参数（可选但要会）

VT 上还有一组 PPPoE 服务器专属参数，用于和非华为客户端兼容、或者按 AC 名/服务名做区分：

# 进入 VT 视图
interface virtual-template 1

# 设置 AC 名（接入集中器名），客户端可据此选服务器
pppoe-server ac-name BRAS-DORM

# 设置服务名参数
pppoe-server service-name-parameter internet

# 服务名严格匹配模式（默认模糊匹配，严格匹配可防止误连）
pppoe-server service-name-type exact-match

# 配置 PADM/PADN 报文的发送时机（与异厂商客户端对接常需调整）
pppoe-server send padm ipcp

# 配置 MOTM 项分隔符（与异厂商对接兼容性）
pppoe-server motm item delimiter |

commit
quit

# 系统视图下：延迟发送 PADT（配合异厂商设备）
pppoe-server send padt always
commit

对上异厂商客户端时，最常见的问题是「能拨上但对方显示的服务器名不对」，此时调 ac-name 和 service-name 就能解决。

32.2.5 用户会话限制（防私接必备）

一个账号被多人共用（俗称私接）是宽带运营的大问题。华为在 BAS 接口上提供限制手段：

# 进入 BAS 接口
interface GigabitEthernet1/0/2.1
bas

# 限制该接口下最大接入用户数（已核实）
access-ip-limit 1000

commit

已核实：access-ip-limit 是 NE40E 上「限制接入用户数」的命令，其触发后的上线失败计数可用 reset pppoe statistics online-fail-record { slot <slot-id> } 清除——这一对命令在 NE40E 官方《Maintaining PPPoX Access》里成对出现，可以放心用。URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/2b23f28/maintaining-pppox-access

按 VLAN 限制用户数：华为不是用 per-vlan 这种子命令，而是把 VLAN 范围做成 access-limit 的参数（已核实，BAS 接口视图下）：

# 进入 BAS 接口
interface GigabitEthernet1/0/2.1
bas

# 限制该接口总用户数 1000
access-limit 1000

# 限制 VLAN 100~199 范围内、PPPoE 类型用户最多 250 个
access-limit 250 start-vlan 100 end-vlan 199 user-type pppoe

# 也可以用简写形式：按接口总用户数限制
access-ip-limit 1000

commit

已核实语法（官方原文）：「Run access-limit user-number [ start-vlan start-vlan [ end-vlan end-vlan ] ] [ qinq qinq-vlan ] [ user-type { ipoe { ipv4 | ipv6 } | pppoe } ] — The maximum number of users allowed access through the interface is configured.」

所以正确写法是 access-limit <数量> start-vlan <起> end-vlan <止> user-type pppoe，不是 access-limit per-vlan <数量>（后者在 NE40E 上并不存在）。 URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/（User Access → IPoE Access → Configuring IPoEv4 Access → 配置 BAS 接口） 顺便给一个对照：H3C 侧「按 VLAN 限用户数」是明确存在的，官方命令为 pppoe-server session-limit per-vlan <number>（见第 31.3 节），所以这项能力两家都有，只是华为侧的写法本轮未能确证。

32.2.6 查看与维护在线用户

# 看所有在线用户（BRAS 最常用命令）
display access-user

# 看指定域下在线用户
display access-user domain isp_dorm

# 看指定用户名
display access-user username user1@isp_dorm

# 看地址池使用情况（空闲多少、已用多少）
display ip pool name pool_dorm

# 清除 PPPoE 报文统计（排错前先清零，便于观察）
reset pppoe statistics slot 1

display access-user 的输出字段很多，新手容易看晕。挑出真正需要关注的：

32.2.7 会话老化与掉线控制

ppp keepalive 三个参数之间的关系必须搞清楚，否则会陷入「用户老掉线→调参数→掉得更凶」的循环：

   interval 30   retransmit 3   ⇒ 最长 30×3 = 90 秒判定掉线
   
   时间轴：
   T=0    发 Echo-Request
   T=30   没回，重发（第1次）
   T=60   没回，重发（第2次）
   T=90   没回，重发（第3次）→ 仍无应答 ⇒ 判定用户掉线，拆会话

三个参数怎么调，取决于你的网络质量：

参数配得过激的典型症状：用户投诉「每隔十几分钟断一次，重连就好」，而且集中在某几栋楼。这往往不是 BRAS 的问题，而是接入层链路质量差 + keepalive 太急，把临时的丢包判定成了掉线。

# 查看当前 VT 的探测参数
display current-configuration interface Virtual-Template1

# 调整探测参数（改完必须让用户重拨才生效）
interface virtual-template 1
ppp keepalive interval 60
ppp keepalive retransmit 5
commit

注意最后一句注释：VT 参数改了，在线用户不会自动生效，必须重拨。所以调这类参数要挑低峰期，并且提前通告。

32.2.8 用户路由引入的三种做法

前面反复强调 import-route unr，这里把「用户路由怎么让上游知道」这件事说透。用户上线后，BRAS 会生成一条 /32 的主机路由，这条路由的「路由源」标记为 UNR。有三种做法能让上游知道它：

   做法A：OSPF 引入 UNR（最常用）
   ospf 1
    import-route unr
   
   做法B：走 IGP + 路由汇总（大网常用）
   BRAS 把所有用户地址汇总成大网段通告给 CR，CR 只需知道"往 BRAS 走"
   
   做法C：BGP 发布（跨域/多AS场景）
   通过 BGP 把用户网段/汇总路由发布给对端

三者的取舍：

新手通常用做法 A 就够了，但要知道做法 B 才是运营商标准做法——这也是为什么运营商的地址池总是规划成连续大段的原因。

# 做法 A 的完整样子
ospf 1
import-route unr
area 0.0.0.0
network 10.200.0.0 0.0.0.3
commit

如果配了 import-route unr 还是不通，下一步就该查路由策略是否把它过滤掉了——import-route 之后可能还挂着 filter-policy 或者 route-policy，把 UNR 顺手拦了。这在从别的项目抄配置时极常见。

32.2.9 IPv4/IPv6 双栈 PPPoE

现在的新建网络基本都要双栈，华为在 PPPoE 场景下支持双栈用户。配置思路是在 VT 上同时放开 IPv4 和 IPv6 协商，地址分配方式另有专门配置：

# VT 上同时保留 IPv4 与 IPv6 协商能力
interface virtual-template 1
ppp authentication-mode chap
ppp keepalive interval 60
commit
quit

IPv6 地址分配模式（NE40E 支持 5 种，官方原文）：

配套的两个关键命令（域视图下）：

# 进入 AAA 视图，再进域视图
aaa
domain isp_dorm

# 指定该域上线用户的主业务 IP 类型（ipv4 / ipv6 / ipv6-pd 可多选）
# 若该类型地址分配失败，其他 IP 类型的用户也会被强制下线，用户上线失败
user-basic-service-ip-type ipv4 ipv6

# 抑制设备向 IPv6 接入用户发送 RA 报文
ipv6 nd ra halt

# 允许 PPP 双栈用户从单个协议栈下线
ppp address-release separate

commit
quit
quit

已核实：以上出自 NE40E V800R023C10《Configuring PPPoEv6 Access》→「Configuring an Address Assignment Mode」，五种模式的原文表述为「NDRA, DHCPv6 (IA_NA), DHCPv6 (IA_PD), DHCPv6 (IA_NA)+DHCPv6 (IA_PD), and NDRA+DHCPv6 (IA_PD)」。 URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/（User Access → PPPoE Access → Configuring PPPoEv6 Access）

⚠ 两个坑：① user-basic-service-ip-type 配错类型会导致双栈用户整体上线失败（官方明确说「if the IP address of this type fails to be assigned, users of other IP types are forced to go offline」）；② ppp address-release separate 与 any-address-release offline 互斥，不能同时配。

H3C 侧的双栈配置相对直白一些，官方举例里可见用 undo ipv6 nd ra halt 在接口上放开 RA 通告、并用前缀池分配 PD 前缀：

# H3C：在子接口上放开 RA 通告（IPv6 双栈时）
interface GigabitEthernet3/1/1.1
undo ipv6 nd ra halt
pppoe-server bind virtual-template 1
quit

双栈规划的一条实用建议：IPv4 和 IPv6 用不同的地址池规划，但都绑定到同一个域。这样用户一次认证就同时拿到两种地址，计费也在一张单子里。

32.3 H3C 设备配置详解

32.3.1 命令差异先说清楚

H3C 的 PPPoE 配置和华为结构相似、组织不同，三条最重要的差异：

1. 没有独立的「认证/计费方案」层，直接在 ISP 域里一条 authentication ppp radius-scheme rs1 指定。
2. 域绑在 VT 上（ppp authentication-mode chap domain isp1），而华为绑在 BAS 接口上。
3. 没有 BAS 接口这个概念，接口上直接 pppoe-server bind virtual-template 1 就完事。

32.3.2 完整配置模板

同样分五段给出，可直接照抄：

第一段，VT 虚拟模板：

# 进入系统视图
system-view

# 建 VT 1
interface virtual-template 1

# 开启 PPP 计费统计（H3C 需要显式开启）
ppp account-statistics enable

# 认证方式 CHAP，并直接绑定 ISP 域 isp1（H3C 特色：域焊在 VT 上）
ppp authentication-mode chap domain isp1

quit

第二段，RADIUS 方案：

# 建 RADIUS 方案 rs1
radius scheme rs1

# 主认证服务器与主计费服务器
primary authentication 10.200.1.10
primary accounting 10.200.1.10

# 共享密钥（simple 表示明文，另有 cipher 密文写法）
key authentication simple Bras@2024
key accounting simple Bras@2024

quit

第三段，ISP 域与地址池：

# 建 ISP 域 isp1
domain name isp1

# 认证、授权、计费全部走 rs1
authentication ppp radius-scheme rs1
authorization ppp radius-scheme rs1
accounting ppp radius-scheme rs1

# 授权地址池（用户从 pool1 取地址）
authorization-attribute ip-pool pool1

quit

# 建 DHCP 地址池
dhcp server ip-pool pool1

# 网关，并导出路由（让本机能生成到该网段的路由）
gateway-list 10.200.10.1 export-route

# 网段
network 10.200.10.0 mask 255.255.255.0

quit

第四段，子接口做 VLAN 终结并启用 PPPoE：

# 进入三层子接口
interface GigabitEthernet3/1/1.1

# VLAN 终结：外层 vid 101（单层终结，不用 second-dot1q）
vlan-type dot1q vid 101

# 启用 PPPoE server 并绑定 VT 1
pppoe-server bind virtual-template 1

quit

第五段，可选增强：防攻击与会话限制：

# 限制每槽位每秒收到的 PADI 报文数（默认 500，防 PADI 洪水）
pppoe-server padi-limit slot 3 500

# 用户阻断：600 秒内发起 100 次连接请求，封 300 秒
pppoe-server connection chasten 100 600 300

# 单接口最大 PPPoE 会话数
interface GigabitEthernet3/1/1.1
pppoe-server session-limit 2000

# 单 VLAN 最大会话数
pppoe-server session-limit per-vlan 250

# 单 MAC 最大会话数（防一个MAC多拨）
pppoe-server session-limit per-mac 1

quit

# ICMP 快速应答（硬件直接回，保护 CPU）
ip icmp fast-reply enable

# keepalive 报文硬件快速应答（防 DDoS）
ppp keepalive fast-reply enable

# 保存
save force

32.3.3 逐行讲解

H3C 还有一个非常实用的参数集——PPPoE 服务器标签参数，用于和客户端协商：

# 设置 AC 名（客户端可据此选择服务器）
interface GigabitEthernet3/1/1.1
pppoe-server tag ac-name BRAS-A

# 支持 ppp-max-payload 标签，并限定取值范围（解决 MTU 协商问题）
pppoe-server tag ppp-max-payload minimum 1400 maximum 1492

# 用户接入响应延迟（避免大量用户同时上下线冲击）
pppoe-server access-delay 10 even-mac

quit

pppoe-server tag ppp-max-payload 在跨厂商对接导致 MTU 协商失败时特别有用，这是 PPPoE 互操作问题的常见解法。

⚠ 版本差异与硬件门槛：H3C BRAS/PPPoE 功能要求设备运行在 标准模式（standard mode），且仅 CSPEX 单板（CSPEX-1104-E 除外）与 CEPC 单板支持。此外官方文档对 keepalive 有一条明确建议：在「PPPv4 与 IPv6 计费需分开」或「用户通过三层聚合接口/子接口上线」的场景下，VT 上的 keepalive 间隔应不小于 60 秒。

32.3.4 H3C 支持的接口类型与 VLAN 组合

H3C 官方对 PPPoE server 可用的接口类型有明确规定，这决定了你的组网形态：

VLAN 终结的几种写法，对应不同的接入层打标签方式：

# 单层 VLAN：接入层只打一层标签（最常见）
interface GigabitEthernet3/1/1.1
vlan-type dot1q vid 101

# 模糊 QinQ：外层固定 101，内层是 11 到 14 的任意值
interface GigabitEthernet3/1/1.2
vlan-type dot1q vid 101 second-dot1q 11 to 14

# 精确 QinQ：外壳内层都固定
interface GigabitEthernet3/1/1.3
vlan-type dot1q vid 101 second-dot1q 11

这三种写法怎么选，取决于接入交换机：

• 接入机把用户直接划进某个业务 VLAN（单层）→ 用第一种。
• 接入机对每个用户打一层「用户 VLAN」标签，汇聚机再统一套一层「业务外层」标签（QinQ）→ 用第二、三种。QinQ 是运营商和小区的标准做法，因为它能突破 4094 个 VLAN 的上限。

再补充 H3C 官方给出的一条重要提醒：当某个子接口下有大量 PPPoE 用户在线时，不建议在该子接口上配置 VRRP 的控制 VLAN。这是一个典型的「两条特性在同一接口上打架」的例子，文档特意点出来，说明实际现场踩过坑。

32.3.5 H3C 的 PPP 认证支持域与认证方式组合

H3C 在 VT 上配置认证方式时，domain 参数是可选的，但强烈建议显式指定。原因如下：

   不写 domain 的情况：
   ppp authentication-mode chap
   → 用户在 VT 上认证，域靠"用户名里带的 @后缀" 或 全局默认域 决定
   → 一旦用户没打后缀，全部涌向默认域，非常危险

   写了 domain 的情况：
   ppp authentication-mode chap domain isp1
   → 这个 VT 上的所有用户，无论用户名带不带后缀，一律走 isp1
   → 行为确定，便于运维

这个细节和华为的对应关系是：华为在 BAS 接口上写 default-domain authentication isp1，作用完全一样。两家都建议显式指定默认域，只是位置不同——再次印证了「华为按接口分域，H3C 按 VT 分域」这条规律。

32.3.6 H3C 的会话限制四层粒度

H3C 在会话数限制上比华为提供更多粒度，这在实际防私接时很有用：

# 第一层：单接口总会话数
pppoe-server session-limit 2000

# 第二层：单 VLAN 会话数
pppoe-server session-limit per-vlan 250

# 第三层：单 MAC 会话数（默认就是 1，即一个MAC只能一个会话）
pppoe-server session-limit per-mac 1

# 第四层（系统视图）：单槽位总会话数（独立模式）
pppoe-server session-limit slot 3 total 20000

四层的组合逻辑是这样的：

   一个用户要上线，必须同时满足：
   ├── 该接口会话总数 < session-limit
   ├── 该 VLAN 会话总数 < session-limit per-vlan
   ├── 该 MAC 会话数 < session-limit per-mac
   └── 该槽位会话总数 < session-limit slot N total
   任何一个达到上限，新会话就建不起来

注意一个容易忽略的行为（官方文档明确指出）：当配置的上限小于接口上已有的在线会话数时，配置依然能成功下发，不会打断已有用户，但新会话将无法建立。这解释了一个常见困惑：「我明明看到会话数没到上限，怎么还上不去」——如果上限是后来才调低的，可能是在线数已经超过新上限了。

H3C 还提供了一个很贴心的功能——每槽位用户数告警。它的工作方式是这样的：设该槽位允许的最大用户数为 a、告警阈值为 b，则当该槽位用户数超过 a×b 时输出告警信息；用户数回落到正常范围内时，输出告警恢复信息。这个功能让你在容量耗尽之前就收到告警，而不是等用户投诉上门。

这个功能对容量管理很有价值，因为它的计数规则有两个地方和直觉不同，官方文档说得很清楚：

为什么双栈 PPPoE 和双栈 IPoE 的计数不一样？ 因为两者的会话模型不同：PPPoE 是「一个 PPP 会话承载两个协议栈」，而 IPoE 是「IPv4 和 IPv6 各自独立建会话」。这个差异在做容量规划时会直接影响账算不算得平——同一条宽带，用 IPoE 接入占用的规格是 PPPoE 的两倍。如果你的网络从 PPPoE 迁移到 IPoE，按原有规格订购单板可能会不够，这一点在迁移评估阶段就必须算进去。

这一功能对应的两条命令已核实，都是系统视图下的：

# 设置每槽位用户数告警阈值（缺省 100）
slot-user-warning-threshold 80

# 开启每槽位用户数告警 trap（缺省关闭，必须开启才会真正上报告警）
snmp-agent trap enable slot-user-warning-threshold

注意这两条要成对配：只设阈值不开 trap，达到阈值也不会发告警；只开 trap 不设阈值，则用缺省值 100。出处：H3C CR16000-F《14-IPoE configuration》「Configuring the per-slot user count trap feature」，URL：https://www.h3c.com/en/d_202001/1262641_294551_0.htm

32.3.7 H3C 用户阻断与协议报文攻击防范

在一台面向大量用户的 BRAS 上，防攻击配置不是可选项。H3C 官方在 BRAS 配置举例里给出了一整套防护配置，覆盖面比华为章节里讲到的更系统：

其中「用户级协议报文限速」的说明特别值得读一遍，因为它解释了为什么 BRAS 特别需要控制面保护：

   控制面单元（类似 CPU）负责协议解析与计算，
   灵活性强但吞吐能力远低于转发面。
   
   当转发面收到它无法识别或处理的报文时，会上送控制面。
   如果上送速率超过控制面处理能力：
   → 控制面忙于处理"不想要的包"
   → 无法及时处理合法报文
   → 协议性能受影响，甚至业务中断
   
   对策：在上送控制面的方向做流量监管（CAR），
        只放行合理速率内的协议报文。

这段话把第 31 章讲的「控制面 vs 转发面」用到了防护上：攻击 BRAS 的最佳姿势就是把控制面打满，因为控制面一满，新用户建不了会话，而老用户的数据转发（走转发面）完全不受影响——这正好解释了那个经典现象「老用户能上网、新用户上不来」。

理解了这个机理，你就明白为什么防护配置要按「上送控制面的报文」这个维度来设计，而不是简单地按「总流量」来限速。

32.4 华为 / H3C 命令对照表

表格里有几行值得再叮嘱一次，因为它们直接决定了「迁移配置时会不会翻车」：

**第一行「认证方式」**的差异看似只是多写了个 domain，但它背后是两家完全不同的架构选择：华为把「用户在哪个接口上来」决定了他用哪个域，H3C 把「用户在哪个 VT 上协商」决定了他用哪个域。这意味着，如果你要在一个 H3C 网络上做多域规划，就必须建多个 VT（一个 VT 只能带一个域）；而在华为上，一个 VT 可以被多个 BAS 接口复用，每个接口带不同的域。这是做方案时最该先想清楚的一点。

「BAS 接口 vs 无此概念」这一行是本章最重要的一条差异。它不只是命令不同，而是配置组织方式不同：

   华为的配置链路：
   接口 → user-vlan(用户VLAN) → pppoe-server bind(挂VT) → bas(变成BAS接口)
        → access-type layer2-subscriber(声明是二层普通用户) → default-domain(绑域)

   H3C 的配置链路：
   接口 → vlan-type dot1q(VLAN终结) → pppoe-server bind(挂VT)
        （域在 VT 上已经定了，接入类型天生就是 PPPoE）

华为之所以要多一层 bas，是因为同一台设备还要支持 IPoE、802.1X、L2TP 等多种接入方式，必须有人明确告诉设备「这个接口上的人是哪一种」。H3C 在 PPPoE 场景里用「绑了 PPPoE 的接口就是 PPPoE 用户」这个约定省掉了这层。

「引入用户路由」这一行看起来差异巨大，其实本质上只是默认行为不同：华为把用户路由归为 UNR 需要显式引入，H3C 用 gateway-list ... export-route 在配网关时就顺手把路由生成了。但两者都可能出问题——华为是「忘了引入」，H3C 是「忘了写 export-route」。排错时对照检查即可。

32.5 配置验证

配置完成后，按顺序逐层验证。顺序很重要，因为后一层依赖前一层。

第一层，确认 VT 和地址池这两个静态对象已建好：

# 华为：确认地址池信息
display ip pool name pool_dorm

期望输出里应重点看这几个字段：

  Pool-Name      : pool_dorm
  Gateway        : 10.200.10.1       Mask             : 255.255.255.0
  Total Idle     : 253               
  --------------------------------------------------------------------------------------
  ID           start             end         total  used  idle    CFLCT disable reserved static-bind delayed
  --------------------------------------------------------------------------------------
   0           10.200.10.2       10.200.10.254    253     0    253     0       0           0           0       0

判断标准：Gateway 是你在池里配的网关；total 是总数；idle 是空闲数。如果 idle 一直是 0，用户就上不了线——这是地址池耗尽的直接证据。

第二层，确认域绑定是否正确：

# 华为：确认域信息
display domain isp_dorm

期望看到：

  Domain-name                     : isp_dorm
  Domain-state                    : Active
  Authentication-scheme-name      : auth_radius
  Accounting-scheme-name          : acct_radius

Domain-state 必须是 Active，且两个 scheme 名必须与配置一致。这是「体检三件套」。

第三层，让一个真实用户拨号，然后确认会话建立：

# 华为：查看在线用户
display access-user domain isp_dorm

期望看到一个用户条目，关键字段是 IP 地址、MAC、上线时间、所属域。如果这里是空的，说明会话根本没建起来，直接跳第 36 章。

H3C 侧的验证命令：

# H3C：确认 RADIUS 方案状态
display radius scheme rs1

# H3C：确认域配置
display domain name isp1

# H3C：查看在线用户（具体命令名按版本确认）
display ppp access-user

已核实的命令：H3C 查看在线 PPPoE 用户的命令是 display ppp access-user（可带接口参数，如 display ppp access-user interface gigabitethernet 3/1/1）。出处：H3C CR16000-F《12-PPPoE configuration》配置举例的「Verifying the configuration」段，官方输出列包括 Interface / MAC address / IP address / Username / S/C-VLAN / IPv6 PD Prefix / IPv6 address。 URL：https://www.h3c.com/en/d_202001/1262639_294551_0.htm

对比：华为是 display access-user，H3C 是 display ppp access-user——多一个 ppp 前缀，这是跨厂商最容易敲错的查询命令之一。

第四层，验证用户路由与转发是否通（这是「能拨号但上不了网」的分界线）：

# 华为：看路由表里有没有用户的主机路由
display ip routing-table 10.200.10.11

# 华为：从 BRAS 直接 ping 用户地址
ping -a 10.200.0.2 10.200.10.11

如果路由表里能看到 /32 的 UNR 路由，但核心侧看不到，就是 import-route unr 没配。

32.5.1 把配置当成一份「体检表」逐项打勾

实际交付时，建议用下面这张表做验收，一项一项打勾。这张表是按「用户上线流程」的先后顺序排的，前面没勾完就别看后面：

14 项全绿才算真正配通。绝大多数「配了半天的 BRAS 不通」，都能在这 14 项里找到明确的断点。

32.6 排错与故障树

PPPoE 排错的核心方法只有一条：确定卡在哪一步，然后只查那一步。先给主故障树：

   用户拨号失败
        │
        ├─ Q1: 能收到 PADO 吗？
        │      ├─ 收不到 ──→ ①二层不通 ②接口没绑VT ③VLAN没终结 ④PADI被限速
        │      └─ 收到 ──→ Q2
        │
        ├─ Q2: PADS 之后会话建起来了吗？
        │      ├─ 没有 ──→ PADR/PADS 阶段失败，多为会话数超限
        │      └─ 建起来 ──→ Q3
        │
        ├─ Q3: LCP 协商过了吗？
        │      ├─ 没过 ──→ ①VT没绑 ②认证方式不匹配 ③MTU/MRU协商失败
        │      └─ 过了 ──→ Q4
        │
        ├─ Q4: 认证过了吗？
        │      ├─ 没过 ──→ ①账号密码 ②RADIUS不通 ③域错 ④共享密钥  （详见32章）
        │      └─ 过了 ──→ Q5
        │
        └─ Q5: 拿到 IP 了吗？
               ├─ 没拿到 ──→ ①池耗尽 ②域没绑池 ③网关冲突
               └─ 拿到了 ──→ 能上网了吗？
                              └─ 不能 ──→ import-route unr 没配（最高频）

每一行的详细排查：

几个具体场景的完整排查路径：

场景一：全部用户都拨不上号，昨天还好好的。

# 1. 先看是不是控制面被打满了
display cpu-usage history

# 2. 看 PPPoE 报文统计，判断有没有收到 PADI
display pppoe statistics

# 3. 看接口状态
display interface brief | include GigabitEthernet1/0/2

# 4. 看在线用户数是否骤降
display access-user | count

如果 display pppoe statistics 里 PADI 计数在涨但 PADO 没发出去，说明是被限速或会话满了；如果 PADI 计数根本不涨，说明包没到 BRAS，问题在接入层。

场景二：单个用户拨不上号，其他人都好。

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

# 2. 查该用户的在线会话（有没有僵尸会话占着）
display access-user username user1@isp_dorm

# 3. 如果查到僵尸会话，踢掉它
cut access-user username user1@isp_dorm all

# 4. 让用户重拨

「僵尸会话」是单个用户拨不上号的第一嫌疑：用户断网时没正常发 PADT，BRAS 以为他还在线，再次拨号时因为「同账号已有会话」被拒。踢掉旧会话即可。

已核实的 cut access-user 完整参数集（在 AAA 视图下执行，出自 NE40E V800R023C10《Maintaining AAA and User Management》）：

按什么踢	命令
用户名	cut access-user username <name> { all | hwtacacs | local | none | radius | radius-proxy }
域名	cut access-user domain <domain-name>
IP 地址	cut access-user ip-address <ip> [ <end-ip> ] [ vpn-instance <name> ]
MAC 地址	cut access-user mac-address <mac>
接口	cut access-user interface <if> [ odd-mac | even-mac ]
槽位	cut access-user slot <slot-id>
用户 ID	cut access-user user-id <start-num> [ <end-num> ]
地址池	cut access-user ip-pool <pool-name>
RADIUS 服务器组	cut access-user radius-server-group <group-name>
认证方式	cut access-user authen-method <type>

注意两点：① 按用户名踢时，后面那个 { all | radius | ... } 参数是必填的，表示只踢通过哪种认证方式上线的用户，最常用是 all；② 这条命令在 AAA 视图下执行，不是用户视图。 URL：https://support.huawei.com/enterprise/en/doc/EDOC1100367122/（User Access → AAA → Maintaining AAA and User Management）

32.6.1 逐个报文排查：卡在哪个包，就查那一层

上面的故障树是按「用户能看到什么提示」来分诊的，但真正精准的方法是直接看报文。把 PPPoE 的五个报文当成五个检查点，卡在哪个点上，问题就一定在它前后那一层：

   [用户]  ──PADI──→                       
                ←──没有 PADO──  查：①用户VLAN是否到达BRAS ②接口是否 up ③是否绑了VT
                
   [用户]  ──PADR──→
                ←──没有 PADS──  查：①会话数是否超限 ②AC/服务名是否不匹配
                
   [用户]  ──LCP──→
                ←──LCP 不收敛── 查：①认证方式是否一致 ②MRU/MTU 是否协商失败
                
   [用户]  ──CHAP/PAP──→
                ←──认证失败──  查：①账号密码 ②RADIUS 可达 ③共享密钥 ④域
                
   [用户]  ──IPCP──→
                ←──IPCP 失败──  查：①地址池是否有空闲 ②域是否绑池 ③网关是否冲突

对应到实际命令，判断「包到没到」最有效的两句是查统计：

# 华为：查看 PPPoE 报文收发统计（PADI/PADO/PADR/PADS/PADT 各类计数）
display pppoe statistics

# 华为：查看 PPP 层统计（LCP/IPCP 协商相关计数与认证失败计数）
display ppp statistics

判断逻辑非常好记：

这套「计数比对法」比反复抓包快得多，而且不需要用户配合，是现场排障的首选手段。

32.6.2 三张最容易混淆的「在线」证据

排查时经常遇到「用户说没网，但设备显示在线」的扯皮。这时要用三个证据交叉验证：

# 证据一：会话表里有没有他（BRAS 认为他活着）
display access-user username user1@isp_dorm

# 证据二：地址池里这个地址归谁（地址有没有发出去）
display ip pool name pool_dorm used

# 证据三：转发面能不能到（真正的连通性）
ping -a <BRAS上行IP> <用户IP>

三种组合的含义：

这张表能解决 90% 的「他到底在线没在线」的争论，建议收藏。

32.7 新手踩坑与注意事项

1. MTU 不减 8 字节——症状是网页打一半卡死、下载中断，但 ping 小包正常。PPPoE 的 MTU 必须是 1492。
2. 域没绑地址池——症状是认证通过但卡在「获取 IP 地址」。查 display domain 看有没有池绑定。
3. 忘了 import-route unr——症状是用户能拨上号、能拿到 IP、但打不开任何网页。这是「最后一公里」的坑，且极易误判成 DNS 问题。
4. user-vlan 和 vlan-type dot1q 混用——同一子接口上两者互斥，配了后者再配前者会报错。
5. VT 改了参数却期望在线用户生效——已拨上的用户用的是老 VA，模板改了必须让用户重拨。
6. ppp keepalive 设得太急——间隔 5 秒、重传 1 次，弱信号用户会被反复踢下线。建议间隔 ≥30 秒、重传 3 次。
7. 不看 display pppoe statistics 就瞎猜——这个命令能直接告诉你收到了多少 PADI、发了多少 PADO，是分诊的利器。
8. 僵尸会话不清理——单个用户拨不上号，先查有没有残留会话。
9. 在错误的槽位上找 BRAS 功能——华为要先 active bas slot N，别的槽位建不出 BAS 接口。
10. H3C 用非 CSPEX/CEPC 板卡——pppoe-server bind 直接报错，这是硬件限制不是配置问题。

32.8 本章小结

• PPPoE 让以太网冒充点对点专线，实现一人一账号、一人一地址、一人一会话。
• 上线分两大阶段：PPPoE 协商（PADI→PADO→PADR→PADS） 与 PPP 协商（LCP→PAP/CHAP→IPCP）。
• 华为的域绑在 BAS 接口上，H3C 的域绑在 VT 上——这是两家最大的结构性差异。
• 华为需要 bas 接口 + access-type layer2-subscriber 声明接入类型，H3C 没有这个概念。
• 用户 IP 来自地址池，网关是逻辑网关不落接口；用户路由是 /32 UNR 路由，必须用 import-route unr 引入（H3C 用 gateway-list ... export-route）。
• MTU 必须设为 1492；keepalive 参数决定用户会不会被误踢。
• 排错方法论：先定位卡在哪个报文，再只查那一步。

适用版本：华为 NE40E V800R023C10 系列；H3C CR16000-F Release 795x。H3C 侧须运行在标准模式并使用 CSPEX（CSPEX-1104-E 除外）/CEPC 单板。

自测题

1. PPPoE 四个发现报文分别是什么？各自方向？
2. 用户卡在「正在获取 IP 地址」阶段，最应该先查什么？
3. 为什么 PPPoE 的 MTU 要设成 1492 而不是 1500？
4. 华为和 H3C 分别把认证域绑定在哪一层？
5. 用户能拨号、能拿到 IP，但打不开网页，最先怀疑什么配置？

1. PADI（用户→广播，找服务器）、PADO（服务器→用户，我提供服务）、PADR（用户→服务器，我选你）、PADS（服务器→用户，会话确认）。另有 PADT 用于结束会话。
2. 先查地址池 display ip pool name <pool> 的 idle 是否耗尽，再查域是否绑定了地址池（display domain）。
3. PPPoE 在以太网帧上额外占 8 字节（6 字节 PPPoE 头 + 2 字节 PPP 协议字段），以太网 MTU 为 1500，所以可用 MTU 为 1492。保持 1500 会导致大包被丢弃。
4. 华为绑在 BAS 接口上（access-type layer2-subscriber default-domain authentication <domain>）；H3C 绑在 VT 上（ppp authentication-mode chap domain <domain>）。
5. 最先怀疑没有把用户主机路由（UNR）引入到路由协议，即漏配 import-route unr；其次是 DNS 未下发。

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