目  录

1 PPP配置

1.1 PPP协议简介

1.1.1 PPP简介

1.2 配置PPP

1.2.1 配置PAP验证

1.2.2 配置CHAP验证

1.2.3 配置MS-CHAP或MS-CHAP-V2验证

1.2.4 PPP协商参数

1.2.5 PPP计费统计功能

1.3 PPP的显示和维护

1.4 PPP常见错误配置举例

1.4.1 链路始终不能转为up状态

1.4.2 物理链路不能转为up状态

2 PPPoE配置

2.1 PPPoE简介

2.1.1 PPPoE

2.1.2 PPPoE Server

2.2 配置PPPoE Server

2.3 PPPoE显示和维护

2.4 PPPoE典型配置举例

2.4.1 PPPoE Server典型配置举例

1 PPP配置

1.1  PPP协议简介

1.1.1  PPP简介

PPP（Point to Point Protocol）协议是在点到点链路上承载网络层数据包的一种链路层协议，由于它能够提供用户验证、易于扩充，并且支持同/异步通信，因而获得广泛应用。

PPP定义了一整套的协议，包括链路控制协议（LCP）、网络层控制协议（NCP）和验证协议（PAP、CHAP、MS-CHAP和MS-CHAP-V2）。

·              链路控制协议（Link Control Protocol，LCP）：主要用来建立、拆除和监控数据链路。

·              网络控制协议（Network Control Protocol，NCP）：主要用来协商在该数据链路上所传输的数据包的格式与类型。

·              用于网络安全方面的验证协议族PAP、CHAP、MS-CHAP和MS-CHAP-V2。

1. PAP验证

PAP（Password Authentication Protocol）验证为两次握手验证，密码为明文，PAP验证的过程如下：

(1)      被验证方发送用户名和密码到验证方；

(2)      验证方根据本端用户表查看是否有此用户以及密码是否正确，然后返回不同的响应（Acknowledge or Not Acknowledge）。

图1-1 PAP验证示意图

PAP不是一种安全的验证协议。当验证时，口令以明文方式在链路上发送，并且由于完成PPP链路建立后，被验证方会不停地在链路上反复发送用户名和口令，直到身份验证过程结束，所以不能防止攻击。

2. CHAP验证

CHAP（Challenge-Handshake Authentication Protocol）验证为三次握手验证，密码为密文（密钥）。

CHAP单向验证是指一端作为验证方，另一端作为被验证方。双向验证是单向验证的简单叠加，即两端都是既作为验证方又作为被验证方。在实际应用中一般只采用单向验证。

CHAP单向验证过程分为两种情况：验证方配置了用户名和验证方没有配置用户名。推荐使用验证方配置用户名的方式，这样可以对验证方的身份进行确认。

·              验证方配置了用户名的CHAP验证过程如下：

(1)      验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（Challenge），并同时将本端的用户名附带上一起发送给被验证方；

(2)      被验证方接到验证方的验证请求后，根据此报文中验证方的用户名在本端的用户表查找该用户对应的密码，如果在用户表找到了与验证方用户名相同的用户，便利用报文ID、此用户的密钥（密码）和MD5算法对该随机报文进行加密，将生成的密文和被验证方自己的用户名发回验证方（Response）；

(3)      验证方用自己保存的被验证方密码和MD5算法对原随机报文加密，比较二者的密文，根据比较结果返回不同的响应（Acknowledge or Not Acknowledge）。

·              验证方没有配置用户名的CHAP验证过程如下：

(1)      验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（Challenge）；

(2)      被验证方接到验证方的验证请求后，利用报文ID、缺省的CHAP密码和MD5算法对该随机报文进行加密，将生成的密文和自己的用户名发回验证方（Response）；

(3)      验证方用自己保存的被验证方密码和MD5算法对原随机报文加密，比较二者的密文，根据比较结果返回不同的响应（Acknowledge or Not Acknowledge）。

图1-2 CHAP验证示意图

3. MS-CHAP验证

MS-CHAP（Microsoft CHAP）验证为三次握手验证，密码为密文（密钥）。

MS-CHAP与CHAP的不同之处在于：

·              MS-CHAP采用的加密算法是0x80。

·              MS-CHAP支持重传机制。

MS-CHAP验证的过程如下：

(1)      验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（Challenge）；

(2)      被验证方接到验证方的验证请求后，将报文中验证方的随机报文（Challenge）、自己的密钥（密码）用0x80算法加密，将生成的密文和自己的用户名发回验证方（Response）；

(3)      验证方收到被验证方的响应报文后，根据报文中被验证方的用户名在本端的用户表查找对应的密码，然后利用自己保存的随机报文（Challenge）、查到的被验证方密码用0x80算法加密，将生成的密文与被验证方响应报文中的密文进行比较，根据比较结果返回不同的响应（Acknowledge or Not Acknowledge）：

·              如果验证成功，成功报文（Acknowledge）中携带欢迎信息。

·              如果验证失败，失败报文（Not Acknowledge）中携带错误码、是否重传标记、新生成的随机报文（Challenge）。

(4)      被验证方收到验证方的成功报文，则验证成功。

(5)      被验证方收到验证方的失败报文后，如果失败报文中重传标记R为1，被验证方将收到报文中的随机报文（Challenge）、自己的密钥（密码）用0x80算法加密，将生成的密文和自己的用户名发回验证方，验证方根据收到的重传响应报文重新进行验证；如果失败报文中重传标记R为0，则验证失败，直接拆链。验证方允许被验证方重传3次。

4. MS-CHAP-V2验证

MS-CHAP-V2（Microsoft CHAP Version 2）验证为三次握手验证，密码为密文（密钥）。

MS-CHAP-V2与CHAP的不同之处在于：

·              MS-CHAP-V2采用的加密算法是0x81。

·              MS-CHAP-V2通过报文捎带的方式实现了双向验证。

·              MS-CHAP-V2支持重传机制和修改密码机制。

MS-CHAP-V2验证的过程如下：

(1)      验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（Challenge）；

(2)      被验证方收到验证方的验证请求后，将报文中对端的随机报文（Challenge）、自己生成的随机报文（Peer-Challenge，用于对验证方进行验证）、自己的用户名和密钥（密码）用0x81算法加密，将生成的密文和自己的用户名发回验证方（Response）；

(3)      验证方收到被验证方的响应报文后，将报文中被验证方产生的随机报文（Peer-Challenge）、自己保存的随机报文（Challenge）、报文中被验证方的用户名、自己保存的被验证方密码用0x81算法加密，将生成的密文与被验证方响应报文中的密文进行比较，根据比较结果返回不同的响应（Acknowledge or Not Acknowledge）：

·              如果验证成功，成功报文（Acknowledge）中还携带对被验证方捎带验证的响应密文，该密文是根据收到报文中的被验证方用户名、自己保存的被验证方密钥（密码）、收到报文中被验证方的密文、收到报文中被验证方产生的随机报文（Peer-Challenge）、自己保存的随机报文（Challenge）用0x81算法加密生成的。

·              如果验证失败，失败报文（Not Acknowledge）中携带错误码、是否重传标记、新生成的随机报文（Challenge）。

(4)      被验证方收到验证方的成功报文后，将自己的用户名、密钥（密码）、验证方随机报文（Challenge）、被验证方随机报文（Peer-Challenge）、自己保存的上次发送给验证方的密文用0x81算法加密，将生成的密文与验证方报文中的密文进行比较，如果匹配，验证成功，如果不匹配，直接拆链。

(5)      被验证方收到验证方的失败报文后：

·              如果失败报文中的错误码是密码过期，被验证方将用户输入的新密码、收到报文中的随机报文（Challenge）、自己生成的随机报文（Peer-Challenge）、自己的用户名用0x81算法加密，将生成的密文和加密后的新密码发回验证方（Change password），验证方根据新密码信息重新进行验证；

·              如果失败报文中重传标记R为1，被验证方将收到报文中的随机报文（Challenge）、自己生成的随机报文（Peer-Challenge）、自己的用户名和密钥（密码）用0x81算法加密，将生成的密文和自己的用户名发回验证方，验证方根据收到的重传响应报文重新进行验证；如果失败报文中重传标记R为0，直接拆链。验证方允许被验证方重传3次。

5. PPP运行过程

PPP运行过程（参见下图）如下：

(1)      在开始建立PPP链路时，先进入到Establish阶段。

(2)      在Establish阶段PPP链路进行LCP协商，协商内容包括工作方式（是SP还是MP）、验证方式和最大传输单元等。LCP协商成功后进入Opened状态，表示底层链路已经建立。

(3)      如果配置了验证（远端验证本地或者本地验证远端）则进入Authenticate阶段，开始PAP、CHAP、MS-CHAP或MS-CHAP-V2验证。

(4)      如果验证失败进入Terminate阶段，拆除链路，LCP状态转为Down；如果验证成功就进入Network协商阶段（NCP），此时LCP状态仍为Opened，而IPCP状态从Initial转到Request。

(5)      NCP协商支持IPCP协商，IPCP协商主要包括双方的IP地址。通过NCP协商来选择和配置一个网络层协议。只有相应的网络层协议协商成功后，该网络层协议才可以通过这条PPP链路发送报文。

(6)      PPP链路将一直保持通信，直至有明确的LCP或NCP帧关闭这条链路，或发生了某些外部事件（例如用户的干预）。

图1-3 PPP运行流程图

有关PPP的详细说明，请参考RFC 1661。

1.2  配置PPP

1.2.1  配置PAP验证

1. 配置验证方

表1-1 配置验证方

2. 配置被验证方

表1-2 配置PAP验证的被验证方

1.2.2  配置CHAP验证

CHAP验证分为两种：验证方配置了用户名和验证方没有配置用户名。

1. 验证方配置了用户名

(1)      配置验证方

表1-3 配置验证方

(2)      配置被验证方

表1-4 配置被验证方

2. 验证方没有配置用户名

(1)      配置验证方

表1-5 配置验证方

(2)      配置被验证方

表1-6 配置被验证方

1.2.3  配置MS-CHAP或MS-CHAP-V2验证

表1-7 配置MS-CHAP或MS-CHAP-V2验证的验证方

1.2.4  PPP协商参数

1. PPP协商参数介绍

可以配置的PPP协商参数包括：

·              协商超时时间间隔

·              协商IP地址

·              协商DNS地址

(1)      协商超时时间间隔

在PPP协商过程中，如果在这个时间间隔内没有收到对端的应答报文，则PPP将会重发前一次发送的报文。超时时间间隔可选范围为1秒到10秒。

(2)      协商IP地址

协商IP地址的方式有两种：

·              配置设备作为Client端：若本端接口封装的链路层协议为PPP但还未配置IP地址，而对端已有IP地址时，可为本端接口配置IP地址可协商属性，使本端接口接受PPP协商产生的由对端分配的IP地址。该配置主要用于在通过ISP访问Internet时，得到由ISP分配的IP地址。

·              配置设备作为Server端：若是设备作为Server为对端设备分配IP地址，则应首先在域视图或系统视图下配置本地IP地址池，指明地址池的地址范围，然后在接口视图下指定该接口使用的地址池。

(3)      协商DNS地址

设备在进行PPP地址协商的过程中可以进行DNS地址协商，此时设备既可以配置为接收对端分配的DNS地址，也可以配置为向对方提供DNS地址。一般情况下，当PC与设备通过PPP协议相连时（通常为PC机拨号连接设备），设备应为对端设备指定DNS地址，这样PC就可以通过域名直接访问Internet；当设备通过PPP协议连接运营商的接入服务器时，设备应配置为被动接收或主动请求对端指定DNS地址，这样设备就可以使用接入服务器分配的DNS来解析域名。

2. 配置协商超时时间间隔

表1-8 配置协商超时时间间隔

3. 配置PPP协商IP地址

(1)      配置Client端

表1-9 配置Client端

(2)      配置Server端

对于不需要进行认证的PPP用户，Server端的配置方式如下：

表1-10 配置Server端（对于不需要进行认证的PPP用户）

对于需要进行认证的PPP用户，Server端的配置方式如表1-11所示，定义地址池所使用的域就是配置进行PPP认证时指定的域：

表1-11 配置Server端（对于需要进行认证的PPP用户）

4. 配置DNS服务器地址协商

(1)      配置Client端

表1-12 配置Client端

(2)      配置Server端

表1-13 配置Server端

1.2.5  PPP计费统计功能

1. PPP计费统计功能介绍

PPP协议可以为每条PPP链路提供基于流量的计费统计功能，具体统计内容包括出入两个方向上流经本链路的报文数和字节数。AAA应用模块可以获取这些流量统计信息用于计费控制使用。

2. 配置PPP计费统计功能

表1-14 配置PPP计费统计功能

1.3  PPP的显示和维护

在完成上述配置后，在任意视图下执行display命令可以显示PPP配置后的运行情况，通过查看显示信息验证配置的效果。

在用户视图下执行reset命令可以清除相应的统计信息。

表1-15 PPP、MP及PPP链路效率机制的显示和维护

1.4  PPP常见错误配置举例

1.4.1  链路始终不能转为up状态

1. 故障现象

PPP验证失败，链路始终不能转为up状态。

2. 故障分析

可能是由于PPP验证参数配置不正确，导致PPP验证失败。

3. 故障排除

打开PPP的调试开关，会看到LCP协商成功并转为up状态后进行PAP或CHAP协商，然后LCP转为down状态，则需要修改PPP验证参数的配置，保证验证方可以通过被验证方的验证。

1.4.2  物理链路不能转为up状态

1. 故障现象

物理链路始终是down状态。

2. 故障分析

物理链路始终是down状态，可能有以下原因：

·              接口没有被激活；

·              接口被管理员down掉；

·              物理接口已通，但是链路协商没有通过。

3. 故障排除

可以执行display interface命令来查看接口当前状态，判断故障原因，从而采取相应的方法使物理链路up。

接口有五种状态：

serial number is administratively down, line protocol is down：表示该接口被管理员down。

serial number is down, line protocol is down：表示该接口没有被激活或物理层没有转为up状态。

Virtual-template number is down, line protocol is spoofing up：表示该接口是拨号口，没有呼通。

serial number is up, line protocol is up：表示该接口链路协商即LCP协商已通过。

serial number is up, line protocol is down：表示该接口已激活，但链路协商仍没有通过。

2 PPPoE配置

2.1  PPPoE简介

2.1.1  PPPoE

PPPoE是Point-to-Point Protocol over Ethernet的简称，它可以通过一个远端接入设备为以太网上的主机提供因特网接入服务，并对接入的每个主机实现控制、计费功能。由于很好地结合了以太网的经济性及PPP良好的可扩展性与管理控制功能，PPPoE被广泛应用于小区组网等环境中。

PPPoE协议采用Client/Server方式，它将PPP报文封装在以太网帧之内，在以太网上提供点对点的连接。

PPPoE有两个阶段：Discovery阶段和PPP Session阶段，具体如下：

·              Discovery阶段

当一个主机开始PPPoE进程的时候，它必须先识别接入端的以太网MAC地址，建立PPPoE的Session ID。这就是Discovery阶段的目的。

Discovery阶段结束时服务器和主机之间就确定了PPPoE会话的Session ID，双方进入PPPoE Session阶段。

·              PPP Session阶段

当PPPoE进入Session阶段后PPP报文就可以作为PPPoE帧的净荷封装在以太网帧发到对端，Session ID必须是Discovery阶段确定的ID，MAC地址必须是对端的MAC地址，PPP报文从Protocol ID开始。在Session阶段，主机或服务器任何一方都可发PADT（PPPoE Active Discovery Terminate）报文通知对方结束本Session。

关于PPPoE的详细介绍，可以参考RFC 2516。

2.1.2  PPPoE Server

设备提供了PPPoE Server的功能，支持动态分配IP地址，提供本地认证、RADIUS/TACACS+等多种认证方式，配合访问包过滤防火墙及状态防火墙，可以对内部网络提供安全保障，适用于校园、智能小区等通过以太网接入Internet的组网应用。

这种组网方式需要在用户Host上安装PPPoE客户端拨号软件。

2.2  配置PPPoE Server

PPPoE Server可以配置在物理以太网接口上，也可以配置在由ADSL接口生成的虚拟以太网接口上。

表2-1 配置PPPoE Server

2.3  PPPoE显示和维护

在完成上述配置后，在任意视图下执行display命令可以显示PPPoE配置后的运行情况，通过查看显示信息验证配置的效果。

表2-2 PPPoE显示和维护

2.4  PPPoE典型配置举例

2.4.1  PPPoE Server典型配置举例

1. 组网需求

如图2-1所示，Client运行PPPoE Client，通过AC接入到Internet。AC作为PPPoE Server，配置本地认证，并通过地址池为用户分配IP地址。

2. 组网图

AC通过Vlan-interface 1接口连接以太网，Vlan-interface 2接口连接Internet。

图2-1 PPPoE Server典型配置举例组网图

3. 配置步骤

(1)      方案一：CHAP验证

# 增加一个PPPoE用户。

<AC> system-view

[AC] local-user user1

[AC-luser-user1] password simple pass1

[AC-luser-user1] service-type ppp

[AC-luser-user1] quit

# 配置虚拟模板参数。

[AC] interface virtual-template 1

[AC-Virtual-Template1] ppp authentication-mode chap domain system

[AC-Virtual-Template1] ppp chap user user1

[AC-Virtual-Template1] remote address pool 1

[AC-Virtual-Template1] ip address 1.1.1.1 255.0.0.0

[AC-Virtual-Template1] quit

# 配置PPPoE Server。

[AC] interface Vlan-interface1

[AC-Vlan-interface1] pppoe-server bind virtual-template 1

[AC-Vlan-interface1] quit

# 在系统缺省的ISP域system下，配置域用户使用本地认证方案。

[AC] domain system

[AC-isp-system] authentication ppp local

# 增加一个本地IP地址池（9个IP地址）

[AC-isp-system] ip pool 1 1.1.1.2 1.1.1.10

(2)      方案二：MS-CHAP验证

# 增加一个PPPoE用户。

<AC> system-view

[AC] local-user user1

[AC-luser-user1] password simple pass1

[AC-luser-user1] service-type ppp

[AC-luser-user1] quit

# 配置虚拟模板参数。

[AC] interface virtual-template 1

[AC-Virtual-Template1] ppp authentication-mode ms-chap domain system

[AC-Virtual-Template1] remote address pool 1

[AC-Virtual-Template1] ip address 1.1.1.1 255.0.0.0

[AC-Virtual-Template1] quit

# 配置PPPoE Server。

[AC] interface Vlan-interface1

[AC-Vlan-interface1] pppoe-server bind virtual-template 1

[AC-Vlan-interface1] quit

# 在系统缺省的ISP域system下，配置域用户使用本地认证方案。

[AC] domain system

[AC-isp-system] authentication ppp local

# 增加一个本地IP地址池（9个IP地址）

[AC-isp-system] ip pool 1 1.1.1.2 1.1.1.10

(3)      验证结果

这样，以太网上各主机安装PPPoE客户端软件后，配置好用户名和密码（此处为user1和pass1）就能使用PPPoE协议，通过AC接入到Internet。