eNSP中PPPoE配置实战：从拓扑搭建到拨号排错全解析

在日常网络实验里，用eNSP做PPPoE配置算是一个挺有代表性的场景。很多朋友搭了几台路由器，照着命令敲一遍，却发现拨号不上或者拿不到地址，最后只能去网上翻一堆零散帖子，还是没搞清楚问题出在哪。这篇文章我想把整个PPPoE实验从拓扑设计、协议原理、服务端和客户端配置到验证排错的完整过程，拆开揉碎讲一遍，顺便把模拟器和真实设备之间的差异也交代清楚，让大家在eNSP里能一次性把PPPoE跑通，并且真正理解每一步在做什么。

1. 为什么在eNSP里做PPPoE实验，以及拓扑怎么搭

1.1 这个实验能解决什么问题

PPPoE（Point-to-Point Protocol over Ethernet）在现网里最常见的场景就是宽带接入。运营商的OLT设备下面挂着一大堆用户，用户侧通过ADSL或者光纤猫拨号，本质上就是一台PPPoE客户端在向BRAS（宽带远程接入服务器）发起会话。对于网络工程师来说，理解PPPoE的建链过程、认证方式以及路由转发关系，是进入运营商网络或者企业分支接入领域的基础能力。

在真实设备上做这个实验需要两台路由器加一台PC，还要有运营商环境，成本高而且权限难拿到。eNSP模拟器能免费把整个过程还原出来：一台路由器模拟服务端，一台路由器模拟客户端，中间用以太网线互联。跑通了之后，你还能直观看到PADI、PADR、LCP、IPCP这些报文交互，对协议的理解比单纯看书深刻得多。

1.2 模拟器拓扑与设备选型

推荐使用AR系列路由器，分别命名为R1（服务端）和R2（客户端），中间用GigabitEthernet接口相连。拓扑不用复杂，两台设备足够。具体端口规划是这样：

需要注意的点是，eNSP里的PC终端不支持发起PPPoE拨号，所以不能用云主机或者PC去模拟宽带用户。如果你手头只有一台路由器，也没关系，可以在另一台设备上用同样的命令配置，或者用物理机的网卡连接模拟器，但那样会涉及更多配置，不推荐新手一上来就搞。

提示：如果用的是eNSP早期版本，对PPPoE的支持可能不够稳定，建议尽量用较新的版本。我实验时用的是常见的3.x版本，功能上基本够用。

2. PPPoE协议机制：发现阶段与会话阶段到底发生了什么

2.1 发现阶段四步握手

PPPoE的建立过程可以分成两个大阶段：发现阶段（PPPoE Discovery）和会话阶段（PPPoE Session）。发现阶段的核心目标就是让客户端找到服务端的MAC地址，并确定一个会话ID（Session ID）。这个阶段包含四步，很多人配置的时候只管敲命令，不看报文，结果出了问题完全不知道在哪一步卡住。

第一步，客户端发送PADI（PPPoE Active Discovery Initiation）广播报文，目的MAC是全F，这种报文本质上是在问：“这个以太网里有没有PPPoE服务端？你们谁能提供接入服务？”第二步，服务端收到PADI后，如果自身配置了PPPoE服务并且还有资源，就会单播返回一个PADO（PPPoE Active Discovery Offer）报文，意思是“我能提供服务，我的MAC是XX”。第三步，客户端收到PADO后，如果认可这个服务端，就会向这个服务端单播发送PADR（PPPoE Active Discovery Request），正式请求建立会话。第四步，服务端收到PADR后，会分配一个Session ID，并通过PADS（PPPoE Active Discovery Session-confirmation）报文回复给客户端。至此，发现阶段完成，双方进入会话阶段。

在eNSP里，你如果开启设备的抓包功能，可以在接口上看到这四类报文。很多初学者觉得抓包复杂，但其实这里只需要关注报文的源MAC和目的MAC、以及Session ID是否一致就能定位问题。

2.2 会话阶段：LCP认证与IPCP组件

发现阶段结束之后，双方并不是直接就能传IP数据，而是还要在会话里进行PPP链路协商。这个阶段里跑的是真正的PPP协议，并且因为PPP是点对点协议，在两台以太网设备上存在一个“多路访问”的问题，所以PPPoE实际上是把PPP帧封装在以太网帧里，让一对点对点关系变得像直连一样。

会话阶段第一个环节是LCP（Link Control Protocol）协商，用来确认链路基本参数，包括MRU（最大接收单元）、认证协议（PAP或者CHAP）等。LCP协商通过后，服务端会要求客户端进行认证。eNSP里我们常用的认证方式是CHAP，因为它比PAP更安全，密码不会明文传输。认证通过后，进入NCP（网络控制协议）阶段，对于IPv4来说就是IPCP。IPCP负责协商双方的IP地址，通常是由服务端通过地址池为客户端动态分配一个IP地址。

到这里就能理解为什么客户端只需要拨号，不需要手工配置IP地址。整个PPP会话协商完成后，Dialer接口会自动获得一个IP地址，同时还会生成一条默认路由指向对端，这就是“拨号即上网”的原理。

3. 服务端配置手记：虚拟模板、地址池与认证

3.1 服务端地址池与虚拟模板配置

在R1上，我们需要先定义IP地址池，用于给客户端动态分配地址。地址池可以用全局地址池或者接口地址池，这里用全局地址池更直观。假设内部网段规划是192.168.100.0/24，网关不实际存在，而是由服务端在IPCP阶段下发。

先创建地址池，名称为pppoe_pool：

[R1] ip pool pppoe_pool [R1-ip-pool-pppoe_pool] network 192.168.100.0 mask 255.255.255.0 [R1-ip-pool-pppoe_pool] excluded-ip-address 192.168.100.1

注意这里我排除了192.168.100.1，因为服务端侧可能会用到这个地址。你也可以不排除，但建议保留一个管理IP方便排错。

然后配置虚拟模板（Virtual-Template），这是PPPoE Server的核心配置。虚拟模板定义了会话所用的各项参数，它本身不是一个物理接口，而是动态创建会话时的模板。虚拟模板编号可以任意，比如用1：

[R1] interface Virtual-Template 1 [R1-Virtual-Template1] ppp authentication-mode chap [R1-Virtual-Template1] ip address 192.168.100.1 255.255.255.0 [R1-Virtual-Template1] remote address pool pppoe_pool

这里的ip address配的是服务端在PPP链路对端的地址，其实在PPPoE中，这个地址会作为客户端默认网关的下一跳地址。remote address pool指定给客户端分配地址的地址池。

为什么虚拟模板要配置IP地址？因为PPP链路建立后，对端（客户端）需要通过IPCP获得地址，服务端需要有一个自己的IP地址作为链路本地地址，这样双方才能形成一张点对点网络。这个地址也是客户端收到的DNS或者网关相关参数的重要基础。

最后在物理接口GE0/0/0上开启PPPoE服务，绑定虚拟模板：

[R1] interface GigabitEthernet0/0/0 [R1-GigabitEthernet0/0/0] pppoe-server bind virtual-template 1

这个命令的意思是这个物理接口开始响应PPPoE发现报文，并且每收到一个PADR就基于虚拟模板1创建一个动态会话接口。需要说明的是，在eNSP中，物理接口上不需要再配置MPLS或桥接之类的额外内容，绑定虚拟模板后，接口会自动处理PPPoE报文。

3.2 认证方式选择与设备参数

认证方式这里可以用PAP或CHAP。PAP是明文用户名密码，虽然配置简单，但不推荐在现网使用。eNSP实验中我们可以用CHAP，双方需要提前配置相同的用户名和密码。在服务端要用aaa或本地用户方式创建用户：

[R1] aaa [R1-aaa] local-user user1 password irreversible-cipher cipher 123456 [R1-aaa] local-user user1 service-type ppp

如果没有aaa，也可以直接在虚拟模板上调用认证域，但更稳妥的方法是配置aaa本地认证。默认情况下，虚拟模板上的ppp authentication-mode chap会自动关联到aaa认证，所以我们需要确保aaa里存在对应的用户。认证过程是：客户端发送username为user1，服务端用CHAP挑战握手验证密码，验证通过后会话建立。

还有一个容易忽略的参数是MRU（最大接收单元）。默认情况下PPP MRU是1500，但以太网帧的MTU也是1500，加上PPP头部和PPPoE头部，就会导致数据多出8个字节，如果不做调整，分片问题就会很严重。通常我们在两条链路上都配置mtu 1492或者ppp mp mru auto。不过要注意，eNSP里有时候mtu配置不生效，或者默认可以协商到1500，这就需要我们在客户端调整接口MTU。后面会详细说。

4. 客户端拨号配置：dialer接口的联动关系

4.1 配置拨号规则与拨号接口

客户端R2侧的核心是Dialer接口。Dialer接口是一个逻辑拨号接口，它本身不关联具体物理口，而是通过拨号规则来决定什么时候建立会话以及使用什么用户名密码拨号。

先配置用户名和密码（必须与服务端一致）：

[R2] aaa [R2-aaa] local-user user1 password irreversible-cipher cipher 123456 [R2-aaa] local-user user1 service-type ppp

注意这里客户端也需要配置本地用户，因为CHAP认证是双向的？其实在PPPoE中，通常只是服务端认证客户端，但客户端也会在LCP协商中要求认证对端吗？不一定。我们可以在dialer接口上指定PAP或CHAP用户名密码，不依赖aaa。更简单的方法是在Dialer接口下配置：

[R2] interface Dialer 1 [R2-Dialer1] dialer user user1 [R2-Dialer1] dialer password cipher 123456 [R2-Dialer1] dialer bundle 1 [R2-Dialer1] ppp authentication-mode chap [R2-Dialer1] ppp chap user user1 [R2-Dialer1] ppp chap password cipher 123456

有时候dialer password命令和ppp chap password同时需要，华为设备上可以通过这些组合实现CHAP认证中的用户名密码发送。由于不同版本命令有差异，我这里提供一个兼容性更好的配置方式：使用dialer user指定拨号用户名，用dialer password指定密码，然后拨号时设备会按照LCP协商的认证方式发送。

配置dialer接口的IP地址协商方式：

[R2-Dialer1] ip address ppp-negotiate

这表示客户端地址由IPCP动态协商，不手工配置。同时设置MTU：

[R2-Dialer1] mtu 1492

再设置一条缺省路由指向Dialer接口：

[R2] ip route-static 0.0.0.0 0 Dialer 1

4.2 物理口与拨号口的绑定

Dialer接口配置好后，还需要在物理接口GE0/0/0上绑定拨号捆绑编号。拨号捆绑编号需要和Dialer接口的dialer bundle 1一致：

[R2] interface GigabitEthernet0/0/0 [R2-GigabitEthernet0/0/0] pppoe-client dial-bundle-number 1

这行命令的意思是，当物理接口收到PPPoE服务端回应的PADO后，触发Dialer 1发起PADR并进入会话阶段。很多朋友在这里会漏掉pppoe-client这个关键字，以为只需要配置dialer bundle就行，结果物理接口完全没有PPPoE能力。华为设备上，在物理接口必须使用pppoe-client命令明确告知该接口作为PPPoE客户端工作。

选完这些之后，还需要确认物理接口本身不要配置IP地址，也不要配置其他三层协议，因为PPPoE发现阶段是在二层进行的。如果物理接口配置了IP，会导致报文转发异常，拨号永远无法成功。这是模拟器实验中最常见的低级错误。

5. 配置完成后如何验证与排错

5.1 验证拨号会话与获取地址

配置完毕后，在R2上执行display pppoe-client session summary，可以看到一条会话记录，包括客户端MAC、服务端MAC、Session ID、会话状态。如果状态是Up，恭喜你，PPPoE已经建立成功。如果状态是Establishing或Down，则需要排查。

再执行display ip interface brief，查看Dialer1接口是否有IP地址。正常情况下应该看到类似192.168.100.x的地址，并且接口状态为Up。

然后从R2 ping服务端的地址（比如192.168.100.1），能通就说明三层可达。还可以在R2上执行display fib查看默认路由，或者用display ip routing-table确认静态默认路由已经指向Dialer1。

如果需要看更详细的PPP状态，可以执行：

[R2] display pppoe-client session summary [R2] display interface Dialer 1 [R2] display ppp link

这些命令能让你看到LCP状态是否Open、认证状态是否Authenticated、IPCP状态是否Open。如果其中某个环节卡住，就能定位到具体协议阶段。

5.2 常见故障：卡在发现阶段/认证失败/IPCP不协商

我把在eNSP里跑PPPoE最常见的故障归类成三种，每一种都有对应的排查路径。

第一种，客户端一直发PADI但没有收到PADO。原因通常是服务端物理接口没有绑定虚拟模板，或者服务端接口处于shutdown状态。在R1上执行display pppoe-server session all，如果没有任何信息，说明服务端根本没收到PADI。这时候用抓包软件看报文最直接，eNSP的抓包入口可以截获两个接口之间的流量。检查一下服务端物理接口是否启用了PPPoE绑定，以及虚拟模板是否存在。

第二种，发现阶段正常，但认证阶段失败。客户端显示LCP已打开，但在认证后会话被终止。这种问题多半是用户名密码不一致，或者认证方式不匹配。比如服务端配置了CHAP，客户端却用PAP；或者服务端本地用户的服务类型不是PPP。检查命令是：在R1上执行display aaa online-record或display aaa user，查看是否有用户上线记录。如果没有，就是认证没有通过。这里特别提醒：CHAP认证中密码是加密传输的，但eNSP里如果两端配置的密码分别为123456和cipher 123456，有可能因为加密算法不同导致不一致。建议客户端和服务端都使用同样的明文格式，或者都用cipher格式。

第三种，IPCP协商失败，Dialer接口迟迟拿不到地址。这种问题最常见的原因是服务端地址池配置错误，比如地址池名在虚拟模板中写错，或者地址池没有被正确关联。地址池remote address pool必须指向已存在的全局地址池。另外，如果服务端虚拟模板没有配置IP地址，IPCP就无法给客户端下发网关，也会导致拨号成功后无法通信。

经验：在排错之前，先把两台设备的系统时间调到一致。PPPoE的CHAP挑战值依赖于随机数，但LCP的MRU协商、还有某些日志记录会受到系统时间影响。如果你在抓包时看到时间戳诡异，先改设备时钟，可以排除一部分干扰。

6. 几个实用技巧和踩坑心得

6.1 MTU与MSS的联动调整

拨号成功后，默认路由有了，IP也有了，但如果你从客户端去访问服务端后面的某个网段，可能会发现比较大的数据包（比如超过1472字节）不通，而小包正常。这就是MTU的问题。PPPoE头部占8字节，所以链路MTU上限只有1492。但很多时候设备默认协商出来的MRU可能是1500，这就导致实际发送的IP包可能会被丢弃或分片，尤其TCP连接建立时的SYN包和SYN-ACK包如果超过MTU，就会表现为部分网站打不开。

解决办法是在客户端Dialer接口上设置mtu 1492，同时调整TCP全局MSS：

[R2] interface Dialer 1 [R2-Dialer1] mtu 1492 [R2-Dialer1] tcp adjust-mss 1400

tcp adjust-mss会改写TCP握手报文中的MSS选项，使其不超过链路MTU减去IP头和TCP头的大小。这个命令在华为设备上很常用。eNSP里虽然不会真的出现“打不开网页”的问题，但如果你做了QoS实验或者需要测试分片，这个细节就是关键。

6.2 eNSP模拟器特有的坑

很多朋友在eNSP里做PPPoE时，会遇到一个诡异的状况：服务端和客户端都配置正确，但客户端就是拨号不上。检查之后发现，可能是eNSP的某些版本对PPPoE的支持有Bug，尤其是当客户端路由器使用了非默认的Ethernet接口时。解决办法是把接口改为GigabitEthernet，或者把链路速率模式改成自协商。

另外一个模拟器特有的问题是，PPPoE会依赖于GRE或者隧道模块，某些版本在创建虚拟模板时如果不小心打了空格，会导致相似但无法匹配的名字。这种问题非常隐蔽，建议配置完地址池和用户名后，使用display current-configuration查看实际配置，复制命令而不是手敲。

6.3 扩展思考：多客户端场景与计费

实验做完后，可以尝试把服务端配置多个虚拟模板或者使用域来区分不同用户，比如一个服务端同时服务多个vlan的用户。虽然eNSP对多会话支持有限，但你可以试着在R1上创建更多的地址池，并在虚拟模板中使用remote address pool按用户分配。更进一步，你还可以在服务端启用statistics查看每秒收发报文数，这有助于理解PPPoE的会话维持与保活机制。

我个人的体会是，PPPoE实验如果只停留在“配置能通”的层面，价值会打很多折扣。真正有意义的是把报文交互流程看明白，尤其是遇到拨号失败时，用抓包和debug命令去定位是在哪个阶段出问题。这样下次在真实设备上遇到类似问题，你就有了一套靠谱的排查思路，而不是靠运气和百度。

最后再分享一个小技巧：eNSP里完成PPPoE配置后，记得保存配置，否则重启模拟器一切归零。而且如果你想保留实验结果，需要手动导出.txt配置备份。我用这个方法保存过很多次实验拓扑，后续复盘非常方便。