PPPoE調(diào)試信息說明

1、2022-3-6PPPoE 的英文是Point-to-Point Protocol over Ethernet，中文意思是以太網(wǎng)上的PPP。PPPoE協(xié)議提供了在廣播式的網(wǎng)絡(luò)（如以太網(wǎng)）中多臺主機(jī)連接到遠(yuǎn)端的訪問集中器（訪問集中器也稱為寬帶接入服務(wù)器）上的一種標(biāo)準(zhǔn)。Page 3PPPoE服務(wù)器設(shè)備提供了PPPoE服務(wù)器的功能，支持動態(tài)分配IP地址，提供多種認(rèn)證方式，和防火墻配合，可以對內(nèi)部網(wǎng)絡(luò)提供安全保障，適用于校園、智能小區(qū)等通過以太網(wǎng)接入Internet的組網(wǎng)應(yīng)用。 。PPPoE客戶端局域網(wǎng)內(nèi)所有主機(jī)通過同一個PPPoE會話傳送數(shù)據(jù)，主機(jī)上不用安裝PPPoE客戶端撥號軟件，而且同一個局域網(wǎng)

2、中的所有主機(jī)可以共享一個帳號。Page 4以太網(wǎng)的幀格式Page 5Destination_address域以太網(wǎng)單播目的地址或者以太網(wǎng)廣播地址（0 xFFFFFFFF）。在Discovery數(shù)據(jù)包中，該域的值是以太網(wǎng)廣播地址。在PPPoE會話流量中，該域必須是Discovery階段已經(jīng)確定的通信對方的單播地址。Source_address域源設(shè)備的以太網(wǎng)MAC地址。Ethernet_Type域當(dāng)值為0 x8863時表示Discovery階段當(dāng)值為0 x8864時表示PPPoE會話階段Page 6Payload域VER：長度是4比特。PPPoE規(guī)范的本版本必須設(shè)置為0 x01。Type：長度是

3、4比特。PPPoE規(guī)范的本版本必須設(shè)置為0 x01。Code：長度是8比特。其定義在后面的Discovery和PPPoE會話中分別指定。Session_ID：長度是16比特。是一個網(wǎng)絡(luò)字節(jié)序的無符號值。其值在后面Discovery數(shù)據(jù)包中定義。Length：長度是16比特。該值是PPPoE的Payload長度。它不包括以太網(wǎng)頭部和PPPoE頭部的長度。Payload：PPPoE的Payload，包含0個或多個Tag。Page 7PPPoE會話建立過程分為以下兩個階段：Discovery階段：地址發(fā)現(xiàn)階段PPPoE Session階段：PPPoE會話階段為了在以太網(wǎng)上建立點到點連接，每一個PPP

4、oE會話必須知道通信對方的以太網(wǎng)地址，并建立一個唯一的會話標(biāo)識符。PPPoE通過地址發(fā)現(xiàn)協(xié)議查找對方的以太網(wǎng)地址。Page 8PPP鏈路的建立是通過一系列的協(xié)商完成的：LCP除了用于建立、拆除和監(jiān)控PPP數(shù)據(jù)鏈路，還主要進(jìn)行鏈路層參數(shù)的協(xié)商，如MRU、驗證方式NCP主要用于協(xié)商在該數(shù)據(jù)鏈路上所傳輸?shù)臄?shù)據(jù)包的格式與類型，如IP地址lPPPPPP鏈路建立過程：鏈路建立過程：Page 9PPP鏈路建立過程的簡單描述如下：1、PPP協(xié)議運(yùn)行總是以Dead階段開始和結(jié)束。通常處在這個狀態(tài)的時間很短，僅僅是檢測到硬件設(shè)備后（即硬件連接狀態(tài)為Up）就進(jìn)入Establish階段。 2、在Establish階段

5、，PPP鏈路進(jìn)行LCP協(xié)商。協(xié)商內(nèi)容包括工作方式是SP（Single-link PPP）還是MP（Multilink PPP）、最大接收單元MRU、驗證方式、魔術(shù)字（magic number）和異步字符映射等選項。LCP協(xié)商成功后進(jìn)入Opened狀態(tài)，表示底層鏈路已經(jīng)建立。3、如果配置了驗證，將進(jìn)入Authenticate階段，開始CHAP或PAP驗證。如果沒有配置驗證，則直接進(jìn)入Network階段。Page 10PPP鏈路建立過程的簡單描述如下： 4、對于Authenticate階段，如果驗證失敗，進(jìn)入Terminate階段，拆 除鏈路，LCP狀態(tài)轉(zhuǎn)為Closed。如果驗證成功，進(jìn)入Netw

6、ork階段，此時LCP狀態(tài)仍為Opened，而NCP狀態(tài)從Initial轉(zhuǎn)到Starting。 5 5、在Network階段，PPP鏈路進(jìn)行NCP協(xié)商，NCP協(xié)商包括IPCP（IP Control Protocol）、MPLSCP（MPLS Control Protocol）等協(xié)商。IPCP協(xié)商主要包括雙方的IP地址。通過NCP協(xié)商來選擇和配置一個網(wǎng)絡(luò)層協(xié)議。只有相應(yīng)的網(wǎng)絡(luò)層協(xié)議協(xié)商成功后（相應(yīng)協(xié)議的NCP協(xié)商狀態(tài)為Opened），該網(wǎng)絡(luò)層協(xié)議才可以通過這條PPP鏈路發(fā)送報文。例如：IPCP協(xié)商通過后，這條PPP鏈路才可以承載IP報文。Page 11PPP鏈路建立過程的簡單描述如下： 6、 N

7、CP協(xié)商成功后，PPP鏈路將一直保持通信。PPP運(yùn)行過程中，可以隨時中斷連接，物理鏈路斷開、認(rèn)證失敗、超時定時器時間到、管理員通過配置關(guān)閉連接等動作都可能導(dǎo)致進(jìn)入鏈路進(jìn)入Terminate階段 7 7、進(jìn)入Terminate階段后且資源釋放完，即進(jìn)入Dead階段。Page 12Discovery階段基本原理當(dāng)主機(jī)開始通過PPPoE接入服務(wù)器時，它必須先識別接入端的以太網(wǎng)MAC地址，建立PPPoE的Session_ID。這就是Discovery階段的目的。Discovery階段由四個過程組成。完成之后通信雙方都會知道PPPoE的Session_ID以及對方以太網(wǎng)地址，它們共同確定了唯一的PPPo

8、E會話共分為四個階段Page 131.主機(jī)在本以太網(wǎng)內(nèi)廣播一個PADI（PPPoE Active Discovery Initial）報文，在此報文中包含主機(jī)想要得到的服務(wù)類型信息。Page 142.以太網(wǎng)內(nèi)的所有服務(wù)器收到這個PADI報文后，將其中請求的服務(wù)與自己能提供的服務(wù)進(jìn)行比較，可以提供此服務(wù)的服務(wù)器發(fā)回PADO（PPPoE Active Discovery Offer）報文。Page 153.主機(jī)可能收到多個服務(wù)器的PADO報文，主機(jī)將依據(jù)PADO的內(nèi)容，從多個服務(wù)器中選擇一個，并向它發(fā)回一個會話請求報文PADR（PPPoE Active Discovery Request)。Pag

9、e 164.服務(wù)器產(chǎn)生一個唯一的會話標(biāo)識，標(biāo)識和主機(jī)的這段PPPoE會話。并把此會話標(biāo)識通過會話確認(rèn)報文PADS（PPPoE Active Discovery Session-confirmation）發(fā)回給主機(jī)，如果沒有錯誤，雙方進(jìn)入PPPoE Session階段Page 17PPPoE會話（PPPoE Session）開始后，PPP報文作為PPPoE幀的凈荷，封裝在以太網(wǎng)幀發(fā)送到對端。這時所有的以太網(wǎng)數(shù)據(jù)包都是單播的。Ethernet_Type域設(shè)置為0 x8864。PPPoE的Code必須設(shè)置為0 x00。PPPoE會話的Session_ID不允許發(fā)生改變，必須是Discovery階段所

10、指定的值。PPPoE的Payload包含一個PPP幀。PPP幀的開始字段是PPP Protocol-ID。Page 18從主機(jī)發(fā)送到接入服務(wù)器的PPP LCP數(shù)據(jù)包示例圖進(jìn)入PPPoE Session階段后，主機(jī)或服務(wù)器任何一方都可發(fā)PADT報文通知對方結(jié)束PPPoE會話。 Page 19PPPoE Client當(dāng)AR設(shè)備將PPPoE作為一種WAN（Wide Area Network）接入方式時，AR充當(dāng)PPPoE Client的角色，BRAS（Broadband Remote Access Server）作為PPPoE Server。Page 20PPPoE Server AR1200設(shè)備提

11、供了PPPoE Server的功能，支持動態(tài)分配IP地址，提供本地認(rèn)證、RADIUS/HWTACACS等多種認(rèn)證方式，適用于校園、智能小區(qū)等通過以太網(wǎng)接入Internet的組網(wǎng)應(yīng)用。Page 21PPPoE Client 與PPPoE Server互通簡單場景。Page 23RouterAGE0/0/0RouterBGE0/0/1PPPoE ClientPPPoE Server測試過程中很重要的一部分是配置DCC，然后綁定物理接口。Page 24# # dialer-rule dialer-rule dialer-rule 1 ip permit dialer-rule 1 ip permit

12、 # #interface Dialer1interface Dialer1 link-protocol ppp link-protocol ppp ip address ppp-negotiate ip address ppp-negotiate dialer user user2 dialer user user2 dialer-group 1 dialer-group 1 dialer bundle 1 dialer bundle 1 # #interface GigabitEthernet0/0/0/interface GigabitEthernet0/0/0/ pppoe-clien

13、t dial-bundle-number 1 pppoe-client dial-bundle-number 1# #通過虛擬接口模板與物理接口綁定完成Server配置。Page 25# # ip pool pool1 ip pool pool1# #ip pool pool1ip pool pool1 network 192.168.10.10 mask 255.255.255.0 network 192.168.10.10 mask 255.255.255.0 gateway-list 192.168.10.1 gateway-list 192.168.10.1# #interface V

14、irtual-Template1interface Virtual-Template1 remote address pool pool1 remote address pool pool1 ip address 192.168.10.10 255.255.255.0 ip address 192.168.10.10 255.255.255.0# #interface GigabitEthernet0/0/1interface GigabitEthernet0/0/1 pppoe-server bind Virtual-Template 1 pppoe-server bind Virtual-

15、Template 1# #PPPoE Client該用例測試設(shè)備PPPoE Client功能測試方法設(shè)備上配置PPPoE Client功能，通過創(chuàng)建Dialer口與物理接口進(jìn)行綁定。然后配置PPPoE Server端，檢查撥號狀態(tài)是否成功。Page 27PPPoE Server該用例測試設(shè)備PPPoE Server功能測試方法設(shè)備上配置PPPoE Server功能，通過創(chuàng)建虛擬接口模板與物理接口進(jìn)行綁定。然后配置PPPoE Client端，檢查撥號狀態(tài)是否成功。Page 28在配置各設(shè)備后發(fā)現(xiàn)PPPoE 用戶無法撥入，請使用下面的故障診斷流程，如圖所示。Page 30Page 31主要檢查思路

16、：檢查虛擬接口模板是否配置正確。 檢查是否分配到IP 地址。 l其他檢查思路：其他檢查思路：檢查鏈路是否建立成功 檢查網(wǎng)絡(luò)側(cè)是否有回應(yīng)報文檢查路由器是否拒絕呼叫 檢查數(shù)據(jù)通道協(xié)議是否UpPage 32實際組網(wǎng)lPPPoE Client PPPoE Client 與與PPPoE ServerPPPoE Server互通簡單場景?；ネê唵螆鼍?。Page 33RouterAGE0/0/0RouterBGE0/0/1PPPoE ClientPPPoE ServerPage 34PPPPPP標(biāo)準(zhǔn)幀格式校驗標(biāo)志標(biāo)志地址信息域控制協(xié)議域協(xié)議域1字節(jié)缺省1500字節(jié)7EFF037E1字節(jié)1字節(jié)1/2字節(jié)2/4

17、字節(jié)1字節(jié)q標(biāo)志域：標(biāo)志域：每個幀采用一個標(biāo)志序列開始和結(jié)束，其為二進(jìn)序列01111110（0 x7e）。所有實現(xiàn)連續(xù)檢查這個標(biāo)志，該標(biāo)志用作幀同步。q地址域：地址域：一個單一的字節(jié)，包含二進(jìn)制序列11111111（0 xff），表示所有節(jié)點地址，必須總是被識別和接收。q控制域：控制域：缺省為0 x03，表示用戶數(shù)據(jù)傳輸采用無序號幀。q協(xié)議域協(xié)議域：由一個或兩個字節(jié)組成，標(biāo)識封裝在報文的信息域里的數(shù)據(jù)報類型。 q信息域：信息域：是0個或更多的字節(jié)，包含數(shù)據(jù)報信息。包含填充但不包含協(xié)議域在內(nèi)信息域的最大長度，稱為最大接收單元（MRU），默認(rèn)值是1500字節(jié)。q填充域：填充域：在傳輸?shù)臅r候，信息域

18、會被填充若干字節(jié)以達(dá)到MRU。每個協(xié)議負(fù)責(zé)根據(jù)實際信息的大小確定填充的字節(jié)數(shù)。q幀校驗序列域：幀校驗序列域：缺省為16比特（兩個字節(jié)），也可以根據(jù)應(yīng)用，通過LCP協(xié)商為32比特。FCS域計算的范圍覆蓋了地址、控制、協(xié)議、信息和填充域的全部比特。填充域常見協(xié)議字段編碼q常見協(xié)議字段編碼00210021Internet Protocol-IPInternet Protocol-IP002bNovell IPX0023OSI NPDU(Network Protocol Data Unit) Protocol0281MPLS unicast packet0283MPLS multicast packe

19、t002dVan Jacobson Compressed TCP/IP002fVan Jacobson Uncompressed TCP/IP80218021Internet Protocol Control Protocol-IPCPInternet Protocol Control Protocol-IPCP802bNovell IPX Control Protocol8023OSI Control Protocol8281MPLS Control Protocol8031Bridging NCC021C021Link Control Protocol-LCPLink Control Pr

20、otocol-LCPC023C023Password Authentication Protocol-Password Authentication Protocol-認(rèn)證階段用到認(rèn)證階段用到C223C223Challenge Handshake Authentication Protocol-Challenge Handshake Authentication Protocol-認(rèn)證階段用到認(rèn)證階段用到Page 35Page 36LCP控制報文類型LCP報文類型由代碼域標(biāo)識：鏈路維護(hù)報文(管理調(diào)試鏈路)鏈路配置報文(建立和配置鏈路)鏈路終結(jié)報文(終止鏈路)0 x01 Configure-Re

21、quest0 x02 Configure-Ack0 x03 Configure_Nak0 x04 Configure-Reject0 x05 Terminate-Request0 x06 Terminate-Reply0 x07 Code-Reject0 x08 Protocol-Reject0 x09 Echo-Request0 x0A Echo-Reply0 x0B Discard-Request0 x0C Identification0 x0D Time-RemainingPage 37NCP控制報文格式標(biāo)識域代碼域代碼域長度域 數(shù)據(jù)1字節(jié)1字節(jié)2字節(jié)標(biāo)志地址控制協(xié)議域校驗標(biāo)志0 x7E

22、0 xFF0 x037E0 x8021 Internet Protocol Control Protocol0 x8023 OSI Control Protocol0 x8281 MPLS Control Protocol此處提到的NCP的報文格式和LCP報文格式一致，不同報文類型對應(yīng)的數(shù)據(jù)域的格式不同。0 x01 Configure-Request0 x02 Configure-Ack0 x03 Configure_Nak0 x04 Configure-Reject0 x05 Terminate-Request0 x06 Terminate-Reply0 x07 Code-RejectNCP

23、支持的報文類型：PPP 測試診斷方法 可以通過如下命令查看ppp協(xié)商的整個過程 debugging ppp all interface * *的選?。?如果是server端則為Virtual-Template接口，如果是撥號端則為dialer接口。 通過這條Debug信息，可以將PPP的協(xié)議報文打印出來，看報文交互有沒有問題 備注： 目前我們的調(diào)試信息是有時間限制的，時間一到就不在打印調(diào)試信息，所以有時候可能有疑問，怎么沒有PPP報文了，在用戶視圖下通過這條命令可以設(shè)置調(diào)試信息的關(guān)閉時間，設(shè)置為0則不關(guān)閉debugging timeout ? integer The time in minut

24、es when the debug will be sto pped debugging timeout 下面介紹ppp的具體打印信息，如果遇到異常的打印信息，請參考異常信息FAQPage 38PPPoE定位一指禪 Page 39協(xié)商階段協(xié)商階段Check pointCheck point備注備注具體協(xié)商過程具體協(xié)商過程LCPLCP : acksent - opened LCP建鏈成功LCP協(xié)商具體過程認(rèn)證階段CHAP : WaitAAA - ServerSuccess 或者PAP : WaitAAA - ServerSuccess 認(rèn)證成功認(rèn)證階段過程N(yùn)CPIPCP : ackrcvd -

25、ackrcvd - opened opened IPCP協(xié)商成功IPCP協(xié)商過程鏈路維持階段code EchoReply(0a)EchoReply(0a)鏈路心跳正常鏈路心跳檢測過程LCP定位一指禪Page 40協(xié)商具體階協(xié)商具體階段段Check pointCheck point備注備注具體階段具體階段異常錯誤檢異常錯誤檢索索initial - starting LCP : initial - starting 協(xié)商過程FAQstarting-reqsentLCP : starting - reqsent協(xié)商過程reqsent-acksentLCP : reqsent - acksent 協(xié)商

26、過程acksent-openedLCP : acksent - opened LCP協(xié)商完成協(xié)商過程認(rèn)證階段定位一指禪協(xié)商具體階段協(xié)商具體階段Check pointCheck point備注備注具體階段具體階段異常錯誤檢索異常錯誤檢索Initial - SendChallenge CHAP : Initial - CHAP : Initial - SendChallenge SendChallenge 或者或者Initial - Initial - ServerListen ServerListen 認(rèn)證過程FAQSendChallenge - WaitAAA CHAP : CHAP : Se

27、ndChallenge - SendChallenge - WaitAAA WaitAAA 或者或者PAP : ServerListen PAP : ServerListen - WaitAAA - WaitAAA 認(rèn)證過程WaitAAA - ServerSuccessCHAP : WaitAAA - CHAP : WaitAAA - ServerSuccess ServerSuccess 或者或者PAP : WaitAAA - PAP : WaitAAA - ServerSuccessServerSuccess認(rèn)證成功認(rèn)證過程Page 41IPCP定位一指禪協(xié)商具體階段協(xié)商具體階段Check

28、 pointCheck point備注備注具體階段具體階段異常錯誤檢索異常錯誤檢索initial - starting IPCP : initial - initial - starting starting 開始過程FAQstarting - reqsent IPCP : starting - starting - reqsent reqsent 請求階段reqsent - ackrcvd reqsent - reqsent - ackrcvd ackrcvd 確認(rèn)階段ackrcvd - opened IPCP : ackrcvd - ackrcvd - opened opened IPCP

29、協(xié)商成功IPCP協(xié)商成功Page 42鏈路維護(hù)定位一指禪協(xié)商具體階段協(xié)商具體階段Check pointCheck point備注備注具體階段具體階段異常錯誤檢索異常錯誤檢索EchoRequest(09)-發(fā)送心發(fā)送心跳檢測報文跳檢測報文code EchoRequestEchoRequest(09)(09)發(fā)送心跳報文發(fā)送心跳報文FAQEchoReply(0a)-EchoReply(0a)-發(fā)送心跳回發(fā)送心跳回復(fù)報文復(fù)報文code EchoReply(0EchoReply(0a),a),發(fā)送心跳報文發(fā)送心跳報文Page 43PPP LCP交互流程Page 442次交互兩種情況：p第一次交互中，接

30、收方不認(rèn)可Config-Request報文中部分配置參數(shù)選項中的值，則回送Config-Nak報文，攜帶希望的配置參數(shù)選項內(nèi)容；p第二次交互中，發(fā)送方重新發(fā)送一個Config-Request報文，將第一次交互中對方不認(rèn)可的選項信息值修改為可以認(rèn)可的內(nèi)容。p第一次交互中，接收方無法識別Config-Request報文中部分配置參數(shù)選項，則回送Config-Reject報文，攜帶無法識別的內(nèi)容；p第二次交互中，發(fā)送方重新發(fā)送一個Config-Request報文，將第一次交互中對方無法識別的選項信息刪除。p接收方對接收到的Config-Request報文攜帶的所有配置項內(nèi)容均認(rèn)可，則回應(yīng)一個Conf

31、ig-Ack報文。p Config-Ack報文中唯一修改的內(nèi)容就是代碼域。正常的正常的LCPLCP交互過程交互過程需要重新協(xié)商的需要重新協(xié)商的LCPLCP交互過程交互過程PPP LCP階段（Server 側(cè)）LCP階段： Jan 20 2011 14:44:37.380.2+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP Open Event state initial /LCP 初始狀態(tài)為 initial Jan 20 2011 14:44:37.380.3+08:00 AR2220 PPP/7/debug2: P

32、PP State Change: Virtual-Template47:0 LCP : initial - starting initial - starting 觀察點觀察點1 1 Jan 20 2011 14:44:37.380.4+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP Lower Up Event state starting /收到up事件后變?yōu)閟tarting Jan 20 2011 14:44:37.380.5+08:00 AR2220 PPP/7/debug2: PPP State Chang

33、e: Virtual-Template47:0 LCP : starting - reqsent starting - reqsent 觀察點觀察點2 2： Jan 20 2011 14:44:37.380.6+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output LCP(c021) Pkt, Len 23 State reqsent, code ConfReq(01)ConfReq(01), id 1, len 19 MRU(1), len 4, val 05d4 AuthProto(3), len 5, CHA

34、P c22305 MagicNumber(5), len 6, val 0d928bd0 /starting狀態(tài)就LCP報文協(xié)商參數(shù) Page 45lLCP階段：階段：首先打開連接，然后確定相關(guān)通信參數(shù)(包括MTU、compress type、及鏈路認(rèn)證類型。鏈路設(shè)置完后確認(rèn)幀，然后是可選的鏈路質(zhì)量確認(rèn)階段，LCP確定鏈路質(zhì)量在鏈路建立階段，PPP協(xié)議通過LCP報文進(jìn)行鏈路的建立和協(xié)商過程。此時LCP報文作為PPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中，PPP數(shù)據(jù)幀的協(xié)議域的值固定填充0 xC021。在鏈路建立階段的整個過程中信息域的內(nèi)容是變化的，它包括很多種類型的報文，所以這些報文也要通過相

35、應(yīng)的字段來區(qū)分。Code域代碼域的長度為一個字節(jié)，主要是用來標(biāo)識LCP數(shù)據(jù)報文的類型。在鏈路建立階段，接收方接收到LCP數(shù)據(jù)報文。當(dāng)其代碼域的值無效時，就會向?qū)Χ税l(fā)送一個LCP的代碼拒絕報文（Code-Reject報文）。常見code值code值報文類型0 x01Configure-Request0 x02Configure-Ack0 x03Configure-Nak0 x04Configure-Reject0 x05Terminate-Request0 x06Terminate-Ack0 x07Code-Reject0 x08Protocol-Reject0 x09Echo-Request0

36、 x0AEcho-Reply0 x0BDiscard-Request0 x0CReserved常見code值 PPP LCP階段 Jan 20 2011 14:44:37.410.2+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP RCR+(Receive Config Good Request) Event state reqsent /發(fā)出LCPrequest請求則狀態(tài)變?yōu)閞eqsent Jan 20 2011 14:44:37.410.1+08:00 AR2220 PPP/7/debug2: PPP Packe

37、t: Virtual-Template47:0 Input LCP(c021) Pkt, Len 18 State reqsent, code ConfReq(01), ConfReq(01), id 1, len 14 MRU(1), len 4, val 012c MagicNumber(5), len 6, val 0f600dcc /收到對端發(fā)過來的LCP請求 Jan 20 2011 14:44:37.410.3+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output LCP(c021) Pkt, Len 1

38、8 State reqsent, code ConfAck(02), ConfAck(02), id 1, len 14 MRU(1), len 4, val 012c MagicNumber(5), len 6, val 0f600dcc /針對對端的LCP請求發(fā)出LCP回應(yīng)報文 Jan 20 2011 14:44:37.410.4+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 LCP : reqsent - acksent reqsent - acksent 觀察點觀察點2 2：發(fā)出發(fā)出ackack報文，

39、狀態(tài)變?yōu)閳笪?，狀態(tài)變?yōu)閍cksentPage 46PPP LCP階段 Jan 20 2011 14:44:37.410.5+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Input LCP(c021) Pkt, Len 23 State acksent, code ConfAck(02), ConfAck(02), id 1, len 19 MRU(1), len 4, val 05d4 AuthProto(3), len 5, CHAP c22305 MagicNumber(5), len 6, val 0d928bd

40、0 /收到對端的LCP回應(yīng)報文 Jan 20 2011 14:44:37.410.6+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 LCP RCA(Receive Config Ack) Event state acksent Jan 20 2011 14:44:37.410.7+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 LCP : acksent - opened acksent - opened 觀察點4：收到ack報文，LCP狀

41、態(tài)變?yōu)閛penedPage 47異常信息FAQPPP link was closed because the status of the physical layer was Down./PPP link was closed because the status of the physical layer was Down./物理層物理層DownDown 檢查接口下得相關(guān)配置和物理連接。LCP negotiation failed because the result cannot be accepted.LCP negotiation failed because the result c

42、annot be accepted. LCP協(xié)商結(jié)果不可接受（一般是由于認(rèn)證協(xié)商未完成）PPP negotiated again because PPP received a Code-Reject packet. PPP negotiated again because PPP received a Code-Reject packet. 這是LCP中二次協(xié)商的過程，由于接收端不認(rèn)識ConfigRequest中某些選項，此是中間過程，可不關(guān)注。PPP negotiated again because PPP received a Configure-Nak packet. PPP negot

43、iated again because PPP received a Configure-Nak packet. LCP二次協(xié)商收到一個Configure-Nak報文，此是中間過程，可不關(guān)注。PPP negotiated again because PPP received Configure-Ack packet. PPP negotiated again because PPP received Configure-Ack packet. LCP二次協(xié)商收到一個Configure-Ack報文，此是中間過程，可不關(guān)注。LCP negotiated again because LCP rece

44、ived Configure-Request packet. LCP negotiated again because LCP received Configure-Request packet. LCP二次協(xié)商收到一個Configure-Request報文，此是中間過程，可不關(guān)注。Please encapsulate PPP first. Please encapsulate PPP first. 此為ppp協(xié)議一致性問題，請檢查ppp的配置。The interface does not exist. The interface does not exist. 請檢查相關(guān)的接口配置。Page

45、 48認(rèn)證階段 Jan 20 2011 14:44:37.420.1+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 : Enter Authenticate Phase ! /進(jìn)入認(rèn)證階段 Jan 20 2011 14:44:37.420.2+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 CHAP Initial Event state Initial Jan 20 2011 14:44:37.420.3+08:00 AR2220 PPP/7/debu

46、g2: PPP Event: Virtual-Template47:0 CHAP Server Lower Up Event state Initial Jan 20 2011 14:44:37.420.4+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output CHAP(c223) Pkt, Len 25 State Initial, code Challenge(01code Challenge(01), id 1, len 21 Value_Size: 16 Value: fc 9b 56 e1 53 e3 a

47、6 26 1b 54 e5 e2 a1 ed 90 87 Name: /作為認(rèn)證方發(fā)出挑戰(zhàn)報文 Jan 20 2011 14:44:37.420.5+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 CHAP : Initial - SendChallenge : Initial - SendChallenge 觀察點觀察點1 1： Jan 20 2011 14:44:37.420.6+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Inpu

48、t CHAP(c223) Pkt, Len 27 State SendChallenge, code Response(02), code Response(02), id 1, len 23 Value_Size: 16 Value: fa c0 4f 2d 45 e3 22 52 65 0 54 27 32 d4 8a c9 Name: zx /收到對端的回應(yīng)報文，包含用戶名和加密后的密碼 Page 49認(rèn)證階段 Jan 20 2011 14:44:37.420.7+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 CHA

49、P Receive Response Event state SendChallenge Jan 20 2011 14:44:37.420.8+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 CHAP : SendChallenge - SendChallenge - WaitAAA WaitAAA 觀察點觀察點2 2：將用戶名密碼發(fā)到將用戶名密碼發(fā)到AAA AAA Jan 20 2011 14:44:37.420.9+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-

50、Template47:0 CHAP AAA Result Event state WaitAAA Jan 20 2011 14:44:37.420.10+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 CHAP : WaitAAA - WaitAAA - ServerSuccess ServerSuccess 觀察點觀察點3 3：AAAAAA返回成功返回成功 Jan 20 2011 14:44:37.420.11+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Te

51、mplate47:0 Output CHAP(c223) Pkt, Len 20 State ServerSuccess, code SUCCESS(03), code SUCCESS(03), id 1, len 16 Message: Welcome to . /發(fā)出認(rèn)證成功的報文給對端Page 50l驗證方?jīng)]有配置用戶名的驗證方?jīng)]有配置用戶名的CHAPCHAP驗證過程如下：驗證過程如下：l1. 1.驗證方主動發(fā)起驗證請求，驗證方向被驗證方發(fā)送一驗證方主動發(fā)起驗證請求，驗證方向被驗證方發(fā)送一些隨機(jī)產(chǎn)生的報文（些隨機(jī)產(chǎn)生的報文（ChallengeChallenge）l2. 2.驗證方接到驗證

52、方得驗證請求后，利用報文驗證方接到驗證方得驗證請求后，利用報文IDID，缺，缺省的省的CHAPCHAP密碼和密碼和MD5MD5算法對該隨機(jī)報文進(jìn)行加密，講算法對該隨機(jī)報文進(jìn)行加密，講生成的密文和自己的用戶名發(fā)回驗證方（生成的密文和自己的用戶名發(fā)回驗證方（ResponseResponse）；）；l3. 3.驗證方用自己保存的被驗證方密碼和驗證方用自己保存的被驗證方密碼和MD5MD5算法對原隨算法對原隨機(jī)報文加密，比較機(jī)報文加密，比較2 2者的密文，根據(jù)比較結(jié)果返回不同者的密文，根據(jù)比較結(jié)果返回不同的響應(yīng)（的響應(yīng)（Acknowledge or Not AcknowledgeAcknowledge

53、or Not Acknowledge）lCHAPCHAP只在網(wǎng)絡(luò)上傳輸用戶名，而并不傳輸用戶口令只在網(wǎng)絡(luò)上傳輸用戶名，而并不傳輸用戶口令( (準(zhǔn)確地講準(zhǔn)確地講, ,它不直接傳輸口令它不直接傳輸口令, ,傳輸?shù)氖怯脗鬏數(shù)氖怯肕D5MD5算法將口算法將口令與一隨機(jī)報文令與一隨機(jī)報文IDID一起計算的結(jié)果一起計算的結(jié)果), ),因此它的安全性要因此它的安全性要比比PAPPAP高高. .異常情況FAQPPP link was closed because CHAP authentication failed. /CHAP認(rèn)證失敗 檢查chap配置的認(rèn)證密碼是否正確PPP link was closed

54、 because PAP authentication failed. /PAP認(rèn)證失敗 檢查pap認(rèn)證配置是否正確PPP link was closed because PAP protocol was rejected. /PAP認(rèn)證協(xié)商被拒絕 檢查pap認(rèn)證的配置是否正確authentication failed and PPP link was closed because CHAP was disabled on the peer./對端未設(shè)置CHAP認(rèn)證賬號 請配置對端的chap認(rèn)證用戶名和密碼authentication failed and PPP link was close

55、d because PAP was disabled on the peer. /對端未設(shè)置PAP認(rèn)證賬號 請檢查兩邊PAP配置是否在正確。PPP link was closed because the CHAP protocol was rejected. 請檢查client和server的chap配置（比如如果server配了認(rèn)證為chap，而client沒有配置chap認(rèn)證帳號） The encrypted password is invalid. 請檢查CHAP密碼配置。Page 51IPCPIPCP階段： Jan 20 2011 14:44:37.420.12+08:00 AR222

56、0 PPP/7/debug2: PPP Event: Virtual-Template47:0 : Ask peers IP address Jan 20 2011 14:44:37.420.13+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 : Get Peers IP address 21.0.15.253 Jan 20 2011 14:44:37.420.14+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 IPCP Open Event stat

57、e initial Jan 20 2011 14:44:37.420.15+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 IPCP : initial - starting IPCP : initial - starting 觀察點觀察點1 1：進(jìn)進(jìn)入IPCP協(xié)商階段 Jan 20 2011 14:44:37.420.16+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 IPCP Lower Up Event state starting

58、Jan 20 2011 14:44:37.420.17+08:00 AR2220 PPP/7/debug2: PPP State Change: Virtual-Template47:0 IPCP : starting - reqsent IPCP : starting - reqsent 觀察點觀察點2 2 Jan 20 2011 14:44:37.420.18+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output IPCP(8021) Pkt, Len 14 State reqsent, code ConfRe

59、q(01), id 1, len 10 IP Address(3), len 6, val 2f2f2f2f /發(fā)送ipcp請求報文，攜帶本端ip地址 Page 52IPCP Jan 20 2011 14:44:37.420.19+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Input IPCP(8021) Pkt, Len 26 State reqsent, code ConfReq(01), id 1, len 22 IP Address(3), len 6, val 00000000 /收到對端的ipcp請求報文

60、，攜帶地址為0.0.0.0 Jan 20 2011 14:44:37.420.20+08:00 AR2220 PPP/7/debug2: PPP Event: Virtual-Template47:0 IPCP RCR-(Receive Config Bad Request) Event state reqsent Jan 20 2011 14:44:37.420.21+08:00 AR2220 PPP/7/debug2: PPP Packet: Virtual-Template47:0 Output IPCP(8021) Pkt, Len 20 State reqsent, code Con