目  錄

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使其重新進行協商。