目  录

1 PPP

1.1 PPP协议简介

1.1.1 PPP简介

1.2 配置PPP

1.2.1 配置PPP

1.2.2 配置PAP验证

1.2.3 配置CHAP验证

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

1.2.5 PPP协商参数

1.3 PPP典型配置举例

1.3.1 PAP单向验证举例

1.3.2 PAP双向验证举例

1.3.3 CHAP单向验证举例

1.4 PPP常见错误配置举例

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

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

1.4.3 IPv6CP协商链路状态为down后不能重协商

 

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验证过程如下：

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

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

(5)     验证方用自己保存的被验证方密码和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-3）如下：

(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  配置PPP

表1-1 配置PPP

操作		命令	说明
进入系统视图		system-view	-
进入指定接口的视图		interface interface-type interface-number	-
配置接口封装的链路层协议		link-protocol { hdlc | ppp }	可选 缺省情况下，接口封装的链路层协议为PPP
配置轮询时间间隔		timer hold seconds	可选 缺省情况下，轮询时间间隔为10秒
配置本地对对端的PPP验证方式	配置PAP验证	请参见1.2.2  配置PAP验证	可选 用户可以同时配置多种验证方式，在LCP验证选择协商过程中，验证方根据用户配置的验证方式顺序逐一与被验证方进行协商，直到协商通过。如果协商过程中，被验证方回应的协商报文中携带了建议使用的验证方式，验证方查找配置中存在该验证方式，则直接使用该验证方式进行验证 缺省情况下，PPP不进行验证
	配置CHAP验证	请参见1.2.3  配置CHAP验证
	配置MS-CHAP或MS-CHAP-V2验证	请参见1.2.4  配置MS-CHAP或MS-CHAP-V2验证
配置PPP协商参数		请参见1.2.5  PPP协商参数	可选

 

 

1.2.2  配置PAP验证

1. 配置验证方

表1-2 配置验证方

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
配置本地验证对端的方式为PAP	ppp authentication-mode pap [ [ call-in ] domain isp-name ]	必选 缺省情况下，PPP协议不进行验证
退回系统视图	quit	-
创建本地用户，并进入本地用户视图	local-user username	必选
设置本地用户的密码	password [ cipher | simple ] password	必选
设置本地用户的服务类型为PPP	service-type ppp	必选
退回系统视图	quit	-
创建一个ISP域，或者进入已创建ISP域的视图	domain isp-name	可选 如果配置ppp authentication-mode时配置了domain isp-name参数，且isp-name不是缺省域system，就必须配置本命令，且本命令需在ppp authentication-mode命令之前进行配置
配置PPP用户使用本地认证方案	authentication ppp local	可选

 

 

2. 配置被验证方

表1-3 配置被验证方

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
配置本地被对端以PAP方式验证时本地发送的PAP用户名和密码	ppp pap local-user username password { cipher | simple } password	必选 缺省情况下，被对端以PAP方式验证时，本地设备发送的用户名和密码均为空

 

1.2.3  配置CHAP验证

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

1. 验证方配置了用户名

(1)     配置验证方

表1-4 配置验证方

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
配置本地验证对端的方式为CHAP	ppp authentication-mode chap [ [ call-in ] domain isp-name ]	必选 缺省情况下，PPP协议不进行验证
配置采用CHAP验证时验证方的用户名	ppp chap user username	必选 在被验证方上为验证方配置的本地用户的用户名必须跟此处配置的一致
退回系统视图	quit	-
为被验证方创建本地用户，并进入本地用户视图	local-user username	必选
设置本地用户的密码	password [ cipher | simple ] password	必选 验证方用户的密码和被验证方用户的密码需要配置成相同
设置本地用户的服务类型为PPP	service-type ppp	必选
退回系统视图	quit	-
创建一个ISP域，或者进入已创建ISP域的视图	domain isp-name	可选 如果配置ppp authentication-mode时配置了domain isp-name参数，且isp-name不是缺省域system，就必须配置本命令，且本命令需在ppp authentication-mode命令之前进行配置
配置PPP用户使用本地认证方案	authentication ppp local	可选

 

 

(2)     配置被验证方

表1-5 配置被验证方

操作		命令	说明
进入系统视图		system-view	-
进入指定接口的视图		interface interface-type interface-number	-
配置采用CHAP验证时被验证方的用户名		ppp chap user username	必选 在验证方上为被验证方配置的本地用户的用户名必须跟此处配置的一致
为验证方设置本地用户以及相应的密码	退回系统视图	quit	-
	创建本地用户，并进入本地用户视图	local-user username	必选
	设置本地用户的密码	password [ cipher | simple ] password	必选
	设置本地用户的服务类型为PPP	service-type ppp	必选

 

 

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

(1)     配置验证方

表1-6 配置验证方

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
配置本地验证对端的方式为CHAP	ppp authentication-mode chap [ [ call-in ] domain isp-name ]	必选 缺省情况下，PPP协议不进行验证
退回系统视图	quit	-
为被验证方创建本地用户，并进入本地用户视图	local-user username	必选
设置本地用户的密码	password { cipher | simple } password	必选
设置本地用户的服务类型为PPP	service-type ppp	必选
退回系统视图	quit	-
创建一个ISP域，或者进入已创建ISP域的视图	domain isp-name	可选 如果配置ppp authentication-mode时配置了domain isp-name参数，且isp-name不是缺省域system，就必须配置本命令，且本命令需在ppp authentication-mode命令之前进行配置
配置PPP用户使用本地认证方案	authentication ppp local	可选

 

 

(2)     配置被验证方

表1-7 配置被验证方

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
配置采用CHAP验证时被验证方的用户名	ppp chap user username	必选 在验证方上为被验证方配置的本地用户的用户名必须跟此处配置的一致
设置缺省的CHAP验证密码	ppp chap password { cipher | simple } password	必选

 

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

 

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

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
配置本地验证对端的方式为MS-CHAP或MS-CHAP-V2	ppp authentication-mode { ms-chap | ms-chap-v2 } [ [ call-in ] domain isp-name ]	必选 缺省情况下，PPP协议不进行验证
退回系统视图	quit	-
为被验证方创建本地用户，并进入本地用户视图	local-user username	必选
设置本地用户的密码	password { cipher | simple } password	必选
设置本地用户的服务类型为PPP	service-type ppp	必选
退回系统视图	quit	-
创建一个ISP域，或者进入已创建ISP域的视图	domain isp-name	可选 如果配置ppp authentication-mode时配置了domain isp-name参数，且isp-name不是缺省域system，就必须配置本命令，且本命令需在ppp authentication-mode命令之前进行配置
配置PPP用户使用本地认证方案	authentication ppp local	可选

 

 

1.2.5  PPP协商参数

1. PPP协商参数介绍

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

·     协商超时时间间隔

·     协商IP地址

(1)     协商超时时间间隔

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

(2)     协商IP地址

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

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

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

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

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

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
配置协商超时时间间隔	ppp timer negotiate seconds	可选 缺省情况下，协商超时时间间隔为3秒

 

3. 配置PPP协商IP地址

(1)     配置Client端

表1-10 配置Client端

操作	命令	说明
进入系统视图	system-view	-
进入指定接口的视图	interface interface-type interface-number	-
设置接口IP地址可协商属性	ip address ppp-negotiate	必选

 

(2)     配置Server端

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

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

操作		命令	说明
进入系统视图		system-view	-
通过使用全局地址池给对端分配地址，或者直接为对端指定IP地址（两者选择其一）	首先定义全局IP地址池，然后在接口上使用全局地址池给PPP用户分配IP地址	ip pool pool-number low-ip-address [ high-ip-address ]	必选 当配置了remote address pool但没有指定pool-number时，缺省使用0号全局地址池
		interface interface-type interface-number
		remote address pool [ pool-number ]
	接口直接为对端指定IP地址	interface interface-type interface-number	必选
		remote address ip-address

 

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

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

操作	命令	说明
进入系统视图	system-view	-
进入指定的域视图	domain domain-name	必选
定义域地址池	ip pool pool-number low-ip-address [ high-ip-address ]	必选
退回系统视图	quit	-
进入指定接口的视图	interface interface-type interface-number	-
使用域地址池给PPP用户分配IP地址	remote address pool [ pool-number ]	必选 若配置该命令时不指定pool-number，则在IP地址协商时依次使用该域下的地址池给用户分配IP地址
配置PPP IPCP不允许对端使用自行配置的固定IP地址	ppp ipcp remote-address forced	可选 缺省情况下，PPP IPCP的IP地址协商情况为本端不具有地址分配的强制性，即设备本端允许对端自行配置地址。当对端明确请求本端分配地址时，本端给对端分配地址；若对端已自行配置IP地址时，本端不再强行给对端分配地址

 

1.3  PPP典型配置举例

1.3.1  PAP单向验证举例

1. 组网需求

如图1-4所示，Switch A和Switch B之间用接口Pos3/1/1互连，要求Switch A用PAP方式验证Switch B，Switch B不需要对Switch A进行验证。

2. 组网图

图1-4 PAP验证、CHAP验证举例组网图

 

3. 配置步骤

(1)     配置Switch A

# 为Switch B创建本地用户。

<SwitchA> system-view

[SwitchA] local-user userb

# 设置本地用户的密码。

[SwitchA-luser-userb] password simple passb

# 设置本地用户的服务类型为PPP。

[SwitchA-luser-userb] service-type ppp

[SwitchA-luser-userb] quit

[SwitchA] interface Pos 3/1/1

# 配置接口封装的链路层协议为PPP。

[SwitchA-Pos3/1/1] link-protocol ppp

# 配置本地验证Switch B的方式为PAP。

[SwitchA-Pos3/1/1] ppp authentication-mode pap domain system

# 配置接口的IP地址。

[SwitchA-Pos3/1/1] ip address 200.1.1.1 16

[SwitchA-Pos3/1/1] quit

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

[SwitchA] domain system

[SwitchA-isp-system] authentication ppp local

(2)     配置Switch B

# 配置接口封装的链路层协议为PPP。

<SwitchB> system-view

[SwitchB] interface Pos 3/1/1

[SwitchB-Pos3/1/1] link-protocol ppp

# 配置本地被Switch A以PAP方式验证时Switch B发送的PAP用户名和密码。

[SwitchB-Pos3/1/1] ppp pap local-user userb password simple passb

# 配置接口的IP地址。

[SwitchB-Pos3/1/1] ip address 200.1.1.2 16

(3)     验证配置结果

通过查看display interface pos 3/1/1信息，接口的物理层和链路层的状态都是up状态，并且PPP的LCP和IPCP都是opened状态，说明链路的PPP协商已经成功，并且Switch A和Switch B可以互相ping通对方。

1.3.2  PAP双向验证举例

1. 组网需求

如图1-4所示，Switch A和Switch B之间用接口Pos3/1/1互连，要求Switch A和Switch B用PAP方式相互验证对方。

2. 配置步骤

(1)     配置Switch A

# 为Switch B创建本地用户。

<SwitchA> system-view

[SwitchA] local-user userb

# 设置本地用户的密码。

[SwitchA-luser-userb] password simple passb

# 设置本地用户的服务类型为PPP。

[SwitchA-luser-userb] service-type ppp

[SwitchA-luser-userb] quit

[SwitchA] interface Pos 3/1/1

# 配置接口封装的链路层协议为PPP。

[SwitchA-Pos3/1/1] link-protocol ppp

# 配置本地验证Switch B的方式为PAP。

[SwitchA-Pos3/1/1] ppp authentication-mode pap domain system

# 配置本地被Switch B以PAP方式验证时Switch A发送的PAP用户名和密码。

[SwitchA-Pos3/1/1] ppp pap local-user usera password simple passa

# 配置接口的IP地址。

[SwitchA-Pos3/1/1] ip address 200.1.1.1 16

[SwitchA-Pos3/1/1] quit

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

[SwitchA] domain system

[SwitchA-isp-system] authentication ppp local

(2)     配置Switch B

# 为Switch A创建本地用户。

<SwitchB> system-view

[SwitchB] local-user usera

# 设置本地用户的密码。

[SwitchB-luser-usera] password simple passa

# 设置本地用户的服务类型为PPP。

[SwitchB-luser-usera] service-type ppp

[SwitchB-luser-usera] quit

[SwitchB] interface Pos 3/1/1

# 配置接口封装的链路层协议为PPP。

[SwitchB-Pos3/1/1] link-protocol ppp

# 配置本地验证Switch A的方式为PAP。

[SwitchB-Pos3/1/1] ppp authentication-mode pap domain system

# 配置本地被Switch A以PAP方式验证时Switch B发送的PAP用户名和密码。

[SwitchB-Pos3/1/1] ppp pap local-user userb password simple passb

# 配置接口的IP地址。

[SwitchB-Pos3/1/1] ip address 200.1.1.2 16

[SwitchB-Pos3/1/1] quit

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

[SwitchB] domain system

[SwitchB-isp-system] authentication ppp local

(3)     验证配置结果

通过查看display interface pos 3/1/1信息，接口的物理层和链路层的状态都是up状态，并且PPP的LCP和IPCP都是opened状态，说明链路的PPP协商已经成功，并且Switch A和Switch B可以互相ping通对方。

1.3.3  CHAP单向验证举例

1. 组网需求

在图1-4中，要求设备Switch A用CHAP方式验证设备Switch B。

2. 配置方法一（验证方配置用户名时以CHAP方式认证对端）

(1)     配置Switch A

# 为Switch B创建本地用户。

<SwitchA> system-view

[SwitchA] local-user userb

# 设置本地用户的密码。

[SwitchA-luser-userb] password simple hello

# 设置本地用户的服务类型为PPP。

[SwitchA-luser-userb] service-type ppp

[SwitchA-luser-userb] quit

[SwitchA] interface Pos 3/1/1

# 配置接口封装的链路层协议为PPP。

[SwitchA-Pos3/1/1] link-protocol ppp

# 配置采用CHAP验证时Switch A的用户名。

[SwitchA-Pos3/1/1] ppp chap user usera

# 配置本地验证Switch B的方式为CHAP。

[SwitchA-Pos3/1/1] ppp authentication-mode chap domain system

# 配置接口的IP地址。

[SwitchA-Pos3/1/1] ip address 200.1.1.1 16

[SwitchA-Pos3/1/1] quit

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

[SwitchA] domain system

[SwitchA-isp-system] authentication ppp local

(2)     配置Switch B

# 为Switch A创建本地用户。

<SwitchB> system-view

[SwitchB] local-user usera

# 设置本地用户的密码。

[SwitchB-luser-usera] password simple hello

# 设置本地用户的服务类型为PPP。

[SwitchB-luser-usera] service-type ppp

[SwitchB-luser-usera] quit

[SwitchB] interface Pos 3/1/1

# 配置接口封装的链路层协议为PPP。

[SwitchB-Pos3/1/1] link-protocol ppp

# 配置采用CHAP验证时Switch B的用户名。

[SwitchB-Pos3/1/1] ppp chap user userb

# 配置接口的IP地址。

[SwitchB-Pos3/1/1] ip address 200.1.1.2 16

3. 配置方法二（验证方没有配置用户名时以CHAP方式认证对端）

(1)     配置Switch A

# 为Switch B创建本地用户。

<SwitchA> system-view

[SwitchA] local-user userb

# 设置本地用户的密码。

[SwitchA-luser-userb] password simple hello

# 设置本地用户的服务类型为PPP。

[SwitchA-luser-userb] service-type ppp

[SwitchA-luser-userb] quit

[SwitchA] interface Pos 3/1/1

# 配置本地验证Switch B的方式为CHAP。

[SwitchA-Pos3/1/1] ppp authentication-mode chap domain system

# 配置接口的IP地址。

[SwitchA-Pos3/1/1] ip address 200.1.1.1 16

[SwitchA-Pos3/1/1] quit

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

[SwitchA] domain system

[SwitchA-isp-system] authentication ppp local

(2)     配置Switch B

# 配置采用CHAP验证时Switch B的用户名。

<SwitchB> system-view

[SwitchB] interface Pos 3/1/1

[SwitchB-Pos3/1/1] ppp chap user userb

# 设置缺省的CHAP验证密码。

[SwitchB-Pos3/1/1] ppp chap password simple hello

# 配置接口的IP地址。

[SwitchB-Pos3/1/1] ip address 200.1.1.2 16

(3)     验证配置结果

通过查看display interface pos 3/1/1信息，接口的物理层和链路层的状态都是up状态，并且PPP的LCP和IPCP都是opened状态，说明链路的PPP协商已经成功，并且Switch A和Switch B可以互相ping通对方。

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状态，可能有以下原因：

·     接口没有被激活；

·     接口被管理员关闭；

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

3. 故障排除

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

接口有如下状态：

·     该接口被管理员关闭，显示如下：

Pos3/1/1 current state: DOWN（Administratively）, Line protocol current state: DOWN

·     该接口没有被激活或物理层没有转为up状态，显示如下：

Pos3/1/1 current state: DOWN, Line protocol current state: DOWN

·     该接口链路协商即LCP协商已通过，显示如下：

Pos3/1/1 current state: UP, Line protocol current state: UP

·     该接口已激活，但链路协商仍没有通过，显示如下：

Pos3/1/1 current state: UP, Line protocol current state: DOWN

1.4.3  IPv6CP协商链路状态为down后不能重协商

1. 故障现象

未使能IPv6的前提下在PPP链路上配置IPv6地址，IPv6CP无法协商链路状态为up，使能IPv6功能后，依旧不能协商链路状态为up。

2. 故障分析

未使能IPv6的前提下，IPv6CP无法协商成功，由于IPv6CP无重协商机制，所以后续再使能IPv6也无法使IPv6CP协商链路状态为up。

3. 故障排除

·     在PPP链路上配置IPv6地址时，建议首先使能系统的IPv6功能，然后再配置IPv6地址。

·     如果IPv6CP协商链路状态为down，可以在接口上执行命令shutdown/undo shutdown使其重新进行协商。