华为H3C实战 | 第15章 PPP 与 PPPoE

📚 本系列共 43 篇（第 15 / 43 篇）　·　第二卷 路由与广域网篇 —— 让数据找到路

← 上一篇：第 14 章 NAT 与地址转换 　下一篇：第 16 章 IPv6 基础配置与地址自动配置 →

本章导读：一根线、两台机器，先"寒暄"、再"核工牌"、最后"交换名片"——这套规矩就是 PPP。PPPoE 把这套电话礼仪搬到了以太网上，你家光猫拨号拿到的地址就是这么来的。本章既讲路由器当 PPPoE 服务器，也讲当客户端去对接运营商。

本章结构：

• 15.1 功能原理与业务场景 —— PPP 三件套（LCP 协商参数 / PAP-CHAP 认证 / NCP-IPCP 分配地址），以及 PPPoE 的发现 + 会话两阶段
• 15.2 华为设备配置详解 —— PPPoE 服务器端模板、客户端模板，PAP 与 CHAP 的配置差异、CHAP 的单向与双向、MP 骨架，对接运营商的实战要点，以及 15.2.6 一个完整的可视化拨号过程（分四个时间点看状态）
• 15.3 H3C 设备配置详解 —— H3C 的 ppp pap/chap、虚拟模板与逐行讲解
• 15.4 命令对照表 —— 两家并排
• 15.5 配置验证 —— display pppoe-client session、display interface Virtual-Template，附小微接入组网的完整验收清单
• 15.6 排错与故障树 —— 分层往下：物理层 → 发现阶段（关键分水岭）→ PPP 协商（LCP 卡住多半是认证方式不一致）
• 15.7 新手踩坑 —— 物理口没挂进拨号组、PAP/CHAP 两端不一致
• 15.8 本章小结 —— 要点清单 + 自测题

重点提示：拨号失败别一上来查认证，先用 15.2.6 的四个时间点判断"卡在哪一步"：有 PADI 无 PADO 是服务器侧或二层不通，有 PADO 无 PADR 多半是客户端物理口没挂进拨号组。然后在 15.6 对应分支往下查。 关联章节：PPP 链路之上的静态/默认路由见第 10 章；出口 NAT 见第 14 章；PPPoE 在运营商侧的大规模应用（BRAS）见第 32 章；PPPoE 用户的认证计费见第 33 章。

15.1 功能原理与业务场景

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

几十年前，两台机器相隔几十公里，中间只有一根电话线。这根线上能传的就只有 0 和 1，可要通数据，光有"线"远远不够——双方得先商量"咱俩用什么速度说话"“你说方言还是我说普通话"“互相报个名字核对一下身份"“最后再定一下我给你分哪个地址”。这一整套"先握手、再对话"的规矩，就是点对点协议（PPP，Point-to-Point Protocol）[2]。

PPP 像两个人打电话前的开场白，分三步：先说话探探路（建立链路），再核对身份（认证），最后商量好用什么语言聊天（网络层协商）。等这些都齐了，才开始真正传数据。

PPPoE（Point-to-Point Protocol over Ethernet）[7] 是把这套电话礼仪搬到以太网上。以太网本来是一群人挤在一个房间里互相喊话（广播），可运营商想让每个用户都像"单独一条电话线"一样接入，于是搞了个中间层：先用以太网做一次"找对象"的广播，双方配好之后，在以太网帧里装 PPP 的会话。这就是家庭宽带拨号的原理——你家光猫拨号拿到的地址，就是 PPPoE 协商出来的。

15.1.2 在网络里怎么落地（设计视角）

PPP 有三个组成部分，对应三件事：

PPP 的协商是"分层串行"的：LCP 不成功，认证不会开始；认证不通过，IPCP 不会开始；IPCP 不完成，链路就没有 IP 地址、业务不通。这个顺序是排错的总纲——从下往上查，别跳。

PPP 跑在什么物理链路上并不重要，早期是串口和 E1，现在常见的是以太网（那就套一层 PPPoE）。下图是一条典型的 PPPoE 拨号链路，从家里的小路由器拨到运营商：

  内网 PC                    家庭/小微出口（PPPoE Client）        运营商 BRAS（PPPoE Server）
 192.168.10.0/24                  Dialer 口                     虚拟模板/地址池
      |                                |                                |
      | 上网流量 ------------------->   |                                |
      |                                | PADI 广播找服务器  -----------> |
      |                                | <----------- PADO 单播应答       |
      |                                | PADR 请求会话    -------------> |
      |                                | <-------------------- PADS 分配会话ID
      |                                | LCP 协商        --------------> |
      |                                | <--------------------- LCP 协商 |
      |                                | CHAP 认证       --------------> |
      |                                | <--------------------- CHAP 挑战 |
      |                                | IPCP 请求地址   --------------> |
      |                                | <------------------ 分配公网地址 |
      | <---- 源地址经 NAT 转换后出网    |                                |

这里有两个容易忽略的细节。第一，PPPoE 的"发现阶段"用的是以太网广播，所以拨号口和以太网口必须在同一个二层广播域里；一旦中间隔了三层设备，PADI 连门都出不去，拨号会一直卡在"发送 PADI”。第二，拨号拿到的地址是运营商分配的，常变，所以出口设备不能用静态路由式的思路去规划，默认路由要靠协商结果自动生成为指向 Dialer 口的默认路由。

PPPoE 报文的以太网类型也值得记一下，抓包时一眼能认出：发现阶段用 0x8863，会话阶段用 0x8864。看到 0x8863 说明还在找服务器/建会话，看到 0x8864 说明会话已建立但在跑 PPP 协商或数据。

为什么要认证。运营商靠认证计费，企业总部靠认证控制分支接入。PAP 是明文传用户名密码，被截获就能复用；CHAP 是"挑战-响应”，服务器发一个随机数，客户端用密码结合随机数算一个摘要发回去，服务器自己也算一遍比对。所以 CHAP 全程不传明文密码，安全性更高。现代配置一律用 CHAP，PAP 只在对接极老的设备时用。

PAP 与 CHAP 的握手过程对照。理解这两个协议的差别，光看"明文/密文"四个字是不够的，得看报文怎么走：

  PAP（两次握手，密码明文）                 CHAP（三次握手，密码不出门）
  ---------------------------              ---------------------------
  Client              Server               Client              Server
    | 用户名+密码  -->   |                    |                   |
    |                  |                    | <---- 挑战(随机数) |
    |  <-- 通过/拒绝    |                    | 摘要=MD5(密码+挑战)|
    |                  |                    | ---- 用户名+摘要 -> |
    |                  |                    | <---- 通过/拒绝    |

PAP 的风险很直接：只要有人在链路上抓包，用户名和密码立刻暴露，之后攻击者可以冒充这个用户拨号。CHAP 的密码从不出现在报文里，只传摘要，而且挑战值每次都不同，抓到的摘要也没法重放。这就是"现代配置一律用 CHAP"的根本原因。

PPPoE 适合什么场景，不适合什么场景。这是设计时最该想清楚的问题：

一句话总结：PPPoE 的强项是"用一条共享的以太网，给每个用户造出一条独立的、可认证可计费的逻辑链路"，凡是需要这个特性的就适合，不需要的就不该硬上。

适用版本：华为 VRP V200R019 及以上（AR6000 系列）；H3C Comware V7（R2610 及以上）。

15.2 华为设备配置详解

15.2.1 命令行基础速览（本章会用到的那几条）

华为的 PPPoE 分两种角色，配置思路完全不同：做服务器端是把物理口绑到虚拟模板上，由虚拟模板统一管理会话参数；做客户端是要建一个 Dialer 口，把物理口"借"给 Dialer 用。前者像"开了一家营业厅"，后者像"装了一部电话"。

15.2.2 完整配置模板：PPPoE 服务器端（华为 AR）

场景：一台 AR6140-16G4XG 作为小办公区的接入网关（PPPoE Server），下行 GigabitEthernet0/0/1 接二层交换机，下面挂几十台需要拨号的小路由器。要给拨号用户分配的地址段是 172.16.1.0/24。

# 进入系统视图
system-view
sysname HUAWEI

# 配置拨号用户地址池
ip pool PPPOE_POOL
 network 172.16.1.0 mask 255.255.255.0
 gateway-list 172.16.1.1
 dns-list 114.114.114.114
 quit

# 创建虚拟模板，统一管理所有拨号会话的参数
interface Virtual-Template 1
 ip address 172.16.1.1 255.255.255.0
 ppp authentication-mode chap
 remote address pool PPPOE_POOL
 quit

# 本地用户，给拨号客户端认证用
aaa
 local-user branch01 password irreversible-cipher Branch@2024
 local-user branch01 service-type ppp
 quit

# 下行以太口绑定虚拟模板，并开启 PPPoE 服务
interface GigabitEthernet0/0/1
 pppoe-server bind virtual-template 1
 quit

save

15.2.3 完整配置模板：PPPoE 客户端（华为 AR）

场景：一台小路由器要拨号连到上面的服务器，拿到地址后才能把内网流量转出去。

# 定义拨号规则：匹配所有 IPv4 流量即触发拨号
# 注意：华为是先 dialer-rule 进视图，再在视图里写规则（两句）
dialer-rule
dialer-rule 1 ip permit
quit

# 建 Dialer 接口，作为拨号成功后的逻辑三层接口
interface Dialer 1
 link-protocol ppp
 ppp chap user branch01
 ppp chap password cipher Branch@2024
 ip address ppp-negotiate
 dialer user branch
 dialer bundle 1
 dialer-group 1
 quit

# 把 WAN 物理口挂进拨号组 1
interface GigabitEthernet0/0/1
 pppoe-client dial-bundle-number 1
 quit

# 内网地址与 NAT（上网出口）
interface GigabitEthernet0/0/2
 ip address 192.168.10.1 255.255.255.0
 quit
acl number 2000
 rule 5 permit source 192.168.10.0 0.0.0.255
 quit
interface Dialer 1
 nat outbound 2000
 quit

save

15.2.4 逐行讲解

CHAP 的单向与双向。上面模板做的是单向认证：服务器验证客户端。如果要求互相验证，服务器端虚拟模板也要配 ppp chap user 和 ppp chap password，客户端侧要开 ppp authentication-mode chap 并要求对端报名字。双向认证的排错难度翻倍，因为"是谁验证谁"的方向搞反了，现象是"我这边显示认证失败、对端显示认证通过"。定位办法是看两边的 display interface Dialer 和 display ppp interface，找出哪一侧报 LCP 阶段失败。

PAP 与 CHAP 的配置差异。用 PAP 时命令换成 ppp authentication-mode pap，客户端侧对应的凭据命令是 ppp pap local-user，语义是"我发给对端的用户名密码"，与 CHAP 的 ppp chap user 位置对称但名字不同，很容易抄错。PAP 的安全性问题在于密码明文传输，只在对接老旧设备时使用。

下面这段是把上面的 CHAP 模板改造成 PAP 的完整对照，方便你迁移老设备时直接套：

# 服务器端：把认证方式从 chap 改成 pap
interface Virtual-Template 1
 ppp authentication-mode pap
 quit

# 客户端：PAP 的凭据命令与 CHAP 不同名
interface Dialer 1
 ppp pap local-user branch01 password cipher Branch@2024
 quit

对照 CHAP 版本会发现，唯一的区别就是 ppp chap user+ppp chap password 变成了合并成一行的 ppp pap local-user ... password ...，以及服务器端的 authentication-mode 参数。这个"外形几乎一样、语义完全不同"的特点，是 PPP 配置最容易出错的地方——抄了一行，通不了，还看不出哪里不对。

多链路 PPP（MP）的配置骨架。当一条链路带宽不够，可以用多链路把两条物理链路捆成一个逻辑通道，带宽相加。华为侧的思路是建一个 MP-Group 逻辑接口，把物理口都挂进去。

命令写法已按华为官方配置指南核实，注意两个细节：接口命令是 interface mp-group（全小写），物理口上是 ppp mp mp-group <编号>：

# 创建 MP-Group 逻辑接口，统一配置 IP 与认证
interface mp-group 1/0/1
 ip address 172.16.2.1 255.255.255.0
 ppp authentication-mode chap
 quit

# 把两条串口链路都挂进同一个 MP-Group
interface Serial 1/0/0
 link-protocol ppp
 ppp mp mp-group 1/0/1
 quit
interface Serial 1/0/1
 link-protocol ppp
 ppp mp mp-group 1/0/1
 quit

三个必须知道的限制（都是华为官方原文）：

出处：华为 NetEngine AR5700, AR6700, AR8000 V600R025C10 配置指南-广域网接入配置 （原文：创建MP-Group接口，并进入MP-Group接口视图。interface mp-group number；将当前串行接口加入指定的MP-Group接口，使该串口工作在MP方式。ppp mp { interface-type interface-number | interface-name }；配置举例 [DeviceA-Serial1/0/1:1] ppp mp mp-group 1/0/1）、华为 配置MP-Group接口（AR100/120/150/160）

⚠ 版本差异：上面例子里的接口编号 1/0/1 是官方示例的槽位编号，实际填写取决于你的设备槽位与 E1 通道化后的串口编号（官方示例中 E1 的 channel-set 1 timeslot-list 1-15 会生成 Serial 1/0/1:1 这类接口），照抄前先 display interface brief 看你设备上的真实接口名。

15.2.5 PPPoE 客户端对接运营商的实战要点

大多数读者第一次接触 PPPoE 客户端，不是给自家设备做服务器，而是自己当客户端去拨运营商。这种场景下有几个"运营商才有的规矩"，照着做能少被客服绕圈：

第一，账号密码形如 宽带账号@服务后缀。运营商的 BRAS 靠后缀判断用户属于哪个业务域、限速策略套哪一套。把后缀删掉去拨，往往认证直接失败。所以填 ppp chap user 时要完整照抄开户单上的账号，包括 @ 后面的部分。

第二，运营商侧一般不允许双向认证。也就是说，你只需要配 ppp chap user + ppp chap password 主动报名字，不需要在 Dialer 口上开 ppp authentication-mode chap 去验证对端。多加这一行，常见结果是 LCP 阶段反复重协商、拨号迟迟不成功。

第三，别自己指定 IP。运营商给的是动态地址，必须 ip address ppp-negotiate，写死地址会与对端的地址分配冲突。同理，默认路由也不要手工写死下一跳，拨通后指向 Dialer 口的默认路由才是正确形态。

第四，光猫桥接还是路由，决定拨号口接在哪。如果光猫已经拨号（光猫做路由），那你的设备只需要从光猫拿 DHCP 地址，根本不用 PPPoE；只有光猫桥接时，才由你的设备拨号。这一点最容易被搞混——看到"PPPoE 拨不上"先问一句"光猫是什么模式"。

第五，VLAN 的问题。有些运营商的接入方式是"PPPoE over VLAN"，即拨号报文需要带某个 VLAN Tag 才能被 BRAS 收到。这种情况下要在物理口下面建子接口、打上对应 VLAN 再拨号。如果拨号一直没回应、而线、账号都对，就要怀疑这一层。

15.2.6 一个完整的可视化拨号过程（跑一遍心里就有数了）

新手学 PPPoE 最大的痛苦是"看不到中间状态"，只能看到一个最终结果：通或不通。其实把 display 命令按时间顺序打出来，就能"看见"拨号是怎么一步步起来的。下面是同一个 Dialer 口在四个时间点的输出对比：

时间点一：刚配好、还没拨号。此时 Dialer 口存在但没有链路：

Dialer1 current state : DOWN
Line protocol current state : DOWN
Internet Address is 0.0.0.0/0

Internet Address 是 0.0.0.0 说明 IPCP 还没有分配地址，符合预期。

时间点二：有流量触发了拨号，正在发现阶段。到客户端会话表里看：

 SID  State      Intf     Dialer
 1    PadiShip   GE0/0/1  1

PadiShip 表示客户端已经发了 PADI，正在等服务器回应。如果这个状态停留超过几秒，基本可以断定 PADO 没回来——服务器侧或二层有问题。

时间点三：PPP 协商中。会话状态变成 PppUp 之前可能出现 PADR 已发的阶段，此时 PPP 已经开始跑了，去 Dialer 口上能看到 LCP、IPCP 的分阶段状态。

时间点四：拨通。会话表里 State 为 PppUp，Dialer 口上：

Dialer1 current state : UP
Line protocol current state : UP
Internet Address is 172.16.1.2/32

四个时间点对照下来，你会发现"拨号"其实是一个可以逐帧观察的过程，而不是一个黑盒。这就是本章反复强调"按层排查"的意义。

15.3 H3C 设备配置详解

H3C Comware V7 的 PPPoE 配置与华为高度同构，主要差异在虚拟模板接口名、地址池命令和拨号口的参数顺序上。

服务器端配置（H3C MSR3610-X1）：

# 进入系统视图
system-view
sysname H3C

# 配置拨号用户的地址池
ip pool PPPOE_POOL
 network 172.16.1.0 mask 255.255.255.0
 gateway-list 172.16.1.1
 dns-list 114.114.114.114
 quit

# 创建虚拟模板，管理会话参数
interface Virtual-Template 1
 ip address 172.16.1.1 255.255.255.0
 ppp authentication-mode chap
 remote address pool PPPOE_POOL
 quit

# 本地用户，service-type 要包含 ppp
local-user branch01 class network
 password simple Branch@2024
 service-type ppp
 quit

# 下行以太口绑定虚拟模板
interface GigabitEthernet1/0/1
 pppoe-server bind virtual-template 1
 quit

save force

客户端配置（H3C MSR3610-X1 作拨号侧）：

# 定义拨号访问组 1 及其触发条件：所有 IPv4 流量都允许触发拨号
dialer-group 1 rule ip permit

# 建 Dialer 接口
interface Dialer 1
 link-protocol ppp
 ppp chap user branch01
 ppp chap password cipher Branch@2024
 ip address ppp-negotiate
 dialer bundle enable
 dialer-group 1
 quit

# WAN 物理口挂进拨号组
interface GigabitEthernet1/0/1
 pppoe-client dial-bundle-number 1
 quit

# 内网口与 NAT
interface GigabitEthernet1/0/2
 ip address 192.168.10.1 255.255.255.0
 quit
acl basic 2000
 rule 5 permit source 192.168.10.0 0.0.0.255
 quit
interface Dialer 1
 nat outbound 2000
 quit

save force

H3C 侧的三个差异点：

第一，本地用户必须区分 class。H3C 的 local-user 默认建的是 manage 类用户（管登录的），拨号认证用的必须是 network 类（管接入的）。不写 class network，用户建了也认证不过，这是 H3C 独有的一大坑。

第二，password simple / password cipher 与华为的 irreversible-cipher 写法不同。H3C 里 simple 表示明文存储（配置回显里能看到）、cipher 表示加密存储。生产环境一律用 cipher。上面模板为了演示用了 simple，实际部署要换掉。

第三，拨号触发规则与 bundle 的写法两家完全不同，这是抄配置最容易翻车的地方：

H3C 的 pppoe-client dial-bundle-number N 里的 N 必须与 Dialer 接口编号相同（官方原文：该 Dialer bundle 的序号 number 需要与 Dialer 接口的编号相同），而不是与某个"bundle 编号"对应——因为 H3C 的 dialer bundle enable 本身不带编号。

出处：H3C 08-PPPoE配置 （原文示例：[AP] dialer-group 1 rule ip permit / [AP-Dialer1] dialer bundle enable / [AP-Dialer1] dialer-group 1 / [AP-Vlan-interface1] pppoe-client dial-bundle-number 1）

⚠ 版本差异：H3C V5 里 pppoe-server bind virtual-template 与 pppoe-client dial-bundle-number 的参数格式与 V7 基本一致，但 V5 没有 class network 的概念，配置回显也不同。做 V5 老设备迁移时要逐条对照。

15.3.1 H3C 逐行讲解

把上面两段 H3C 模板逐行拆开看，重点标出与华为不同、容易踩的地方：

对照下来能发现一个规律：PPPoE 的配置骨架两家几乎一模一样，真正的差异全在"外围的认证与用户体系"上。华为走的是 aaa 视图 + local-user + service-type ppp；H3C 走的是 local-user class network + password + service-type ppp。所以华为转 H3C 的人，最容易在"用户建了但认证不过"上卡住——差的就是 class network 这一个词。

H3C 侧一个值得单记的点：虚拟模板与物理口的绑定关系。H3C 的 pppoe-server bind virtual-template 挂在以太口视图下，含义是"这个物理口上所有 PPPoE 会话都由虚拟模板 1 的参数管理"。如果设备上有多个下行口要给不同网段的用户分地址，就需要建多个虚拟模板、每个口绑不同的模板。这个"模板隔离"的思路与华为完全一致，是 PPPoE 部署的基本功。

15.4 华为 / H3C 命令对照表

15.5 配置验证

排 PPPoE 有一条黄金顺序：先看发现阶段，再看 PPP 会话，最后看业务。三个层次的命令分开用。

第一步，确认服务器收到了会话请求。在服务器端：

display pppoe-server session all

期望看到每个拨号用户一条会话，State 为 PppUp，并且带分配到的 IP：

 SID  Intf    State    OIntf      IPAddr          MAC
 1    VT1     PppUp    GE0/0/1    172.16.1.2      00e0-fc12-3456

State 常见的值有 Idle、PadiShip、PppUp 等，十六进制地看：会话没起来时是 Idle，正在协商 PPP 时看得到中间状态，只有 PppUp 才算拨通。

第二步，客户端侧看会话建立情况：

display pppoe-client session summary

期望 State 为 Up，并且 Dialer 列能看到对应的 Dialer 接口编号。如果 State 一直是 Down，说明发现阶段就没过，去查二层可达性和服务器有没有开服务。

第三步，看 PPP 链路状态与地址。客户端上：

display interface Dialer 1

期望看到 Line protocol current state : UP、LCP opened、IPCP opened，并且 Internet Address is 172.16.1.2/32 之类由对端分配的地址：

Dialer1 current state : UP
Line protocol current state : UP
Internet Address is 172.16.1.2/32
Physical is Dialer, baudrate 64000 bps

如果 Line protocol 是 DOWN，看括号里写的阶段：LCP 阶段的 Down 说明链路参数协商不上；IPCP 阶段的 Down 说明认证过了但地址没协商成（最常见是服务器没配 remote address pool）。

第四步，看默认路由有没有自动生成。PPPoE 拨通后通常会生成一条指向 Dialer 口的默认路由：

display ip routing-table

期望能看到 0.0.0.0/0 Static ... Dialer1。如果这条没有，说明拨号虽然通了但路由没起来，需要手工补一条 ip route-static 0.0.0.0 0.0.0.0 Dialer 1。

H3C 侧验证命令基本一一对应：

display pppoe-server session
display pppoe-client session summary
display interface Dialer 1
display ip routing-table

15.5.1 一个小微接入组网的完整验证清单

把本章所有验证点串成一个"小微办公区拨号接入"的验收清单。组网：一台 AR 做 PPPoE 服务器兼出口，下面挂 5 台小路由器拨号，每个小路由后面带一个办公室。

按下面的顺序逐条打勾，全部通过才算交付：

这张表的用法是"从服务器往客户端、从下往上"逐条过。哪一步断了，问题就锁定在那一层，不用再往前找。比如第 3 项过了、第 4 项没过，问题一定在客户端侧；第 6 项过了、第 7 项没过，就是路由没生成，跟拨号过程无关。这就是把"玄学拨号"变成"工程验收"的方法。

15.6 排错与故障树

PPPoE 排错的分层原则和 PPP 一模一样，从下往上：

拨号拨不上
 ├─ 1. 物理层通不通？
 │   ├─ display interface Brief 看物理口是否 UP
 │   └─ 电口光口本身坏 / 双工不匹配 → 查速率双工
 ├─ 2. 发现阶段过不过？（关键分水岭）
 │   ├─ 抓包看不到 PADI → 客户端根本没发，检查 pppoe-client 配置
 │   ├─ 有 PADI 无 PADO → 服务器没开服务 / 二层不达 / 服务器绑错模板
 │   ├─ 有 PADO 无 PADR → 客户端问题，多数是物理口没挂进拨号组
 │   └─ 有 PADR 无 PADS → 服务器处理不过来 / 会话数上限
 ├─ 3. PPP 协商过不过？
 │   ├─ LCP 卡住 → 认证方式不一致（一边 CHAP 一边 PAP）
 │   ├─ 认证失败 → 用户名密码错 / service-type 没配 / H3C 没分 class
 │   └─ IPCP 卡住 → 服务器没配 remote address pool 或地址池耗尽
 └─ 4. 起来了但又断？
     ├─ 会话老化 / 空闲超时 → 调 dialer idle-timeout
     ├─ 地址池耗尽 → display ip pool
     └─ 认证服务器（RADIUS）不通 → 看 AAA 侧配置

抓包定位发现阶段。PPPoE 问题靠猜是猜不出来的，必须看报文。设备上不做镜像的话，最便宜的招是看会话状态机的中间值——如果 display pppoe-client session summary 里能看到会话从 Idle 短暂跳到 PadiShip 又掉回 Idle，就说明客户端发了 PADI 但没收到 PADO。这个中间状态比"一直 Down"信息量大得多。

一个容易忽略的现象：拨号成功了却"看起来没通"。拨通后内网 PC 上不了网，先别怀疑 PPPoE。按这个顺序查：一是 Dialer 口有没有 NAT 规则，二是内网有没有默认路由指向 Dialer 口，三是 PC 的网关是不是指到了路由器内网口。因为 PPPoE 只是把"外层链路"接通了，内网到外网的地址转换与路由是另外两件事。

另一个隐蔽问题：MTU。PPPoE 在以太网帧里封装 PPP，帧头多占了 8 个字节，所以 PPPoE 的 MTU 是 1492 而不是 1500。有些应用发大包时会触发分片或 PMTUD 失败，表现为"网页能开、大文件下载卡、VPN 连不上"。处理办法是在 Dialer 口上调整 TCP MSS 上限。这一点和 13 章 NAT 里的 MTU 问题是一脉相承的。

三个现场案例，把故障树走一遍。

案例一：拨号一直不通，服务器那边一条会话都没有。先登服务器 display pppoe-server session all，发现完全空白，说明连 PADI 都没到。再查服务器物理口是否 up、pppoe-server bind 有没有配在正确的口上。这个案例 90% 的原因是对端设备的下行口接错了——线插在了另一个物理口上，或者服务器绑模板绑到了上行口。定位技巧是看服务器接口的收包计数，display interface GigabitEthernet0/0/1 里的 Input 包数如果在拨号时增长，说明报文到了这个口；不增长说明线/口不对。

案例二：服务器能看到会话，状态 PppUp，但客户端 Dialer 口没有地址。这类问题必然出在 IPCP 阶段。去服务器端查地址池：display ip pool，如果显示"已分配数量 = 池总量"，就是池子满了；如果显示池里的网段与虚拟模板接口 IP 不在同一网段，客户端拿不到可从同一网段使用的地址，也会表现为拿不到地址。第二种错误极隐蔽——虚拟模板配 ip address 172.16.1.1 24，地址池却写成 network 10.0.0.0，两边都对得上语法，就是不通。

案例三：拨上了、内网也能 ping 通网关，但打不开网页。这个案例最考验分层思维。拨号链路、地址分配都没问题，问题在链路之外。按顺序查：Dialer 口有没有 nat outbound（没有的话内网源地址带着 192.168.x.x 出去，运营商丢包）；内网有没有默认路由指向 Dialer；PC 网关是否指对。三个逐个排除，通常一条就能定位。

一个排错心得：PPPoE 排错最忌讳"改配置碰运气"。因为每次拨号尝试都只给一个"通/不通"的二元结果，改一次配置重试一次，跟抽奖没区别。正确做法是把每一层单独验证：先证明物理层通（接口 up）、再证明发现阶段通（会话表能到 PppUp）、再证明 IPCP 通（Dialer 有地址）、再证明业务通（NAT + 路由 + 网关）。分层验证过的配置才叫"配通了"，否则只是"碰巧通了"。

15.7 新手踩坑与注意事项

1. 拨号组编号不一致——dialer bundle 1 与物理口 pppoe-client dial-bundle-number 1 是一对，一个写 1 一个写 2 就永远拨不上，而且不报错。
2. 服务端漏掉地址池——remote address pool 不配，客户端 IPCP 阶段拿不到地址，“拨上又断"的经典原因。
3. 本地用户没配服务类型——华为要 service-type ppp，H3C 还要 class network，两处都配才认证得过。
4. CHAP 用户名理解反了——ppp chap user 是"我向对方报的名字”，不是"对方的名字"，写反了认证必然失败。
5. 把 ip address ppp-negotiate 与静态地址混用——两者互斥，拨号场景只能用前者。
6. NAT 配在物理口上——拨号场景的地址在 Dialer 口上，NAT 必须配 Dialer 口。
7. PPPoE 拨号口与服务器不在同一广播域——PADI 是二层广播，隔了三层就过不去。
8. 忘配拨号触发规则——华为漏 dialer-rule 1 ip permit、H3C 漏 dialer-group 1 rule ip permit，Dialer 口永远不主动拨号。
9. PPPoE 的 MTU 是 1492 不是 1500——大包不通先怀疑 MTU，别死磕拨号过程。
10. 密码用 simple 存——H3C 的 password simple 在配置回显里是明文的，生产环境一律 cipher。

15.8 本章小结

• PPP 分三层：LCP 建链、认证核身、NCP/IPCP 拿地址，必须按顺序走通，排错也必须按这个顺序从下往上查。
• PAP 明文传密码、两次握手；CHAP 挑战响应、三次握手、不传明文，现代配置一律用 CHAP。
• PPPoE = 以太网上跑 PPP，分发现阶段（PADI/PADO/PADR/PADS，以太网类型 0x8863）和会话阶段（0x8864）。
• 服务器端核心是"物理口绑虚拟模板 + 虚拟模板管认证与地址池"；客户端核心是"Dialer 口管参数 + 物理口挂进拨号组"。
• 华为与 H3C 主体命令高度同构，主要差异在本地用户的 class network、拨号触发规则（dialer-rule 1 ip permit vs dialer-group 1 rule ip permit）、dialer bundle 带不带编号、以及密码存储关键字。
• 验证按"服务器会话 → 客户端会话 → Dialer 接口 → 默认路由"四步走。

一张纸记牢本章。把本章压缩成三段，贴在工位上就够用：

第一段"是什么"：PPP 是电话线上的礼仪（LCP 建链 → 认证 → IPCP 拿地址），PPPoE 是把这套礼仪搬到以太网上（先 PADI/PADO/PADR/PADS 找到对象，再跑 PPP）。

第二段"怎么配"：服务器端 = 地址池 + 虚拟模板（认证 + remote address pool）+ 物理口 bind；客户端端 = dialer-rule + Dialer 口（CHAP 凭据 + ppp-negotiate + bundle + group）+ 物理口 dial-bundle-number；最后在 Dialer 口上补 NAT。

第三段"怎么查"：display pppoe-server session all 看有没有会话，display pppoe-client session summary 看客户端状态，display interface Dialer 1 看 LCP/IPCP 与地址，display ip routing-table 看默认路由，display nat outbound 看出口转换。哪一条对不上，问题就在那一层。

最后再强调一次分层思维。本章看起来讲的是两个协议，实际上训练的是一种通用的排障能力：把一条链路的建立过程拆成可以单独验证的若干层，每层都有明确的状态标志和观测命令。学会了这个套路，以后遇到 IPSec、SSL VPN、甚至 BGP 邻居建不起来，都能照搬同一套"先下后上、先建后配"的思路。这才是本章最值钱的东西。

自测题

1. PPP 的协商顺序是什么？如果认证阶段失败，IPCP 会不会开始？
2. ppp chap user branch01 这行命令里的 branch01 是"谁的名字"？
3. PPPoE 的发现阶段有哪四个报文，各自作用是什么？
4. 拨号成功后内网 PC 上不了网，按顺序应该查哪三件事？
5. 为什么 PPPoE 链路的 MTU 通常配成 1492？

1. LCP 建立链路 → 认证（PAP/CHAP）→ NCP/IPCP 协商网络层。认证失败则链路终止，IPCP 不会开始。
2. 是"本端向对端报上去的用户名"，必须与对端（服务器）本地保存的用户名一致。
3. PADI（客户端广播找服务器）、PADO（服务器单播回应）、PADR（客户端请求会话）、PADS（服务器分配 Session ID）。
4. 一是 Dialer 口有没有配 NAT；二是内网有没有指向 Dialer 口的默认路由；三是 PC 网关是否正确指向路由器内网接口。
5. 因为 PPPoE 在以太网帧中额外封装了 8 字节的 PPPoE 头，以太网 MTU 1500 减去 8 就是 1492。

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