華為培訓(xùn)PPP協(xié)議和PPP0E協(xié)議

1、課程 BA000003PPP協(xié)議和 PPP0E 協(xié)議ISSUE1.0Huawei TechnologiesBA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0目錄課程說明課程介紹課程目標(biāo)第1章 概述第2章 PPP協(xié)議第3章 PPPOE 協(xié)議附錄 縮略詞表4874課程說明BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0課程說明課程介紹本教材為寬帶產(chǎn)品工程師培訓(xùn)公共課程。本課程介紹 PPP協(xié)議和 PPPOE協(xié)議。課程目標(biāo)完成本課程學(xué)習(xí)，學(xué)員能夠：了解SLIP 協(xié)議的基本原理。掌握PPP 協(xié)議的基本原理。掌握LCP 協(xié)議和 NCP 協(xié)議數(shù)據(jù)報(bào)文的交換過程。掌握PP

2、POE 協(xié)議的基本原理。第 1 章 概述BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第1章 概述內(nèi)容提要SLIP 協(xié)議PPP協(xié)議PPPOE協(xié)議第 1 章 概述BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0SLIP協(xié)議的定義定義：SLIP是在串行線路IP上數(shù)據(jù)對(duì)報(bào)進(jìn)行封裝的簡(jiǎn)單協(xié)議。SLIP數(shù)據(jù)幀格式：IP數(shù)據(jù)報(bào)文END 字符SLIP 數(shù)據(jù)幀SLIP 的全稱是 Serial Line IP ，出現(xiàn)在 80 年代中期，并被使用在 BSD UNIX 主機(jī)和 SUN 的工作站上。因?yàn)?SLIP 簡(jiǎn)單好用，所以后來被大量使用在線路 速率從 1200bps 到

3、 19.2Kbps 的專用線路和撥號(hào)線路上互連主機(jī)和路由器， 到目前為止仍有大部分 UNIX 主機(jī)保留對(duì)該協(xié)議的支持。在 80 年代末 90 年 代初期，被廣泛用于家庭中每臺(tái)有 RS232 串口的計(jì)算機(jī)和調(diào)制解調(diào)器連接到Internet 。SLIP 的幀格式由 IP 包加上 END 字符組成。通過在被發(fā)送 IP 數(shù)據(jù)報(bào)的尾部增加特殊的 END 字符（ 0xC0 ）從而形成一個(gè) 簡(jiǎn)單的 SLIP 的數(shù)據(jù)幀，而后該幀會(huì)被傳送到物理層進(jìn)行發(fā)送。為了防止線路 噪聲被當(dāng)成數(shù)據(jù)報(bào)的內(nèi)容在線路上傳輸，通常發(fā)送端在被傳送數(shù)據(jù)報(bào)的開始 處也傳一個(gè) END 字符。如果線路上的確存在噪聲，則該數(shù)據(jù)報(bào)起始位置的 EN

4、D 字符將結(jié)束這份錯(cuò)誤的報(bào)文，這樣當(dāng)前正確的數(shù)據(jù)報(bào)文就能正確的傳送 了，而前一個(gè)含有無意義報(bào)文的數(shù)據(jù)幀會(huì)在對(duì)端的高層被丟棄。END 是判斷一個(gè) SLIP 幀是否結(jié)束的標(biāo)志。如果要傳送的 IP 包中正好有一個(gè) 字符 0xc0 要傳送，為了避免它被當(dāng)作 END 字符，要用連續(xù)的兩個(gè)字節(jié) 0xdb 和 0xdc 來代替它。如果要傳送的是 0xdb ，那么就用連續(xù)傳輸兩個(gè)字節(jié) 0xdb 和 0xdd 來代替它。第 1 章 概述BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0SLIP協(xié)議的缺點(diǎn)（一）IPSLIP 鏈路IPX路由器 AAppleTalkIPIPX路由器 BAppleTa

5、lkSLIP 只支持 IP 協(xié)議，對(duì) IPX 等缺乏支持。 并且， 由于幀格式中沒有類型字段， 致使如果一條串行線路如果用于 SLIP ，就不能同時(shí)使用其它協(xié)議。第 1 章 概述BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0SLIP協(xié)議的缺點(diǎn)（二）有誤SLIP 不提供糾錯(cuò)機(jī)制，錯(cuò)誤只能依靠上層協(xié)議實(shí)現(xiàn)。第 1 章 概述BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0SLIP協(xié)議的缺點(diǎn)（三）路由器 A路由器 BSLIP 鏈路192.168.0.2/24192.168.0.1/24路由器 B的互連 IP 是多少？打個(gè)電話問問我的地址是 192.168.0.

6、2/24 ，那你的地址是多少？還要通過這么原始的方式來獲知對(duì)方的 IP 地址SLIP 幀的封裝格式非常簡(jiǎn)單，通信雙方無需在數(shù)據(jù)報(bào)發(fā)送前協(xié)商任何配置參 數(shù)選項(xiàng)（在 PPP 協(xié)議中需協(xié)商配置參數(shù)選項(xiàng)） ，所以雙方 IP 層通信前必需先 獲知對(duì)方的 IP 地址，才能進(jìn)行網(wǎng)絡(luò)層的通信，否則鏈路層發(fā)送的數(shù)據(jù)幀在被送到對(duì)方網(wǎng)絡(luò)層時(shí)將無法進(jìn)行轉(zhuǎn)發(fā)。正是由于上面的諸多缺點(diǎn)，導(dǎo)致了 SLIP 很快的被后面要講的 PPP 協(xié)議所替代。第 1 章 概述BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0小節(jié)SLIP 是一種僅能在點(diǎn)對(duì)點(diǎn)的鏈路上封裝 IP數(shù)據(jù)報(bào)的協(xié)議SLIP的幀格式為IP數(shù)據(jù)報(bào)c0SL

7、IP不支持 IP地址的協(xié)商第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第 2章 PPP 協(xié)議內(nèi)容提要第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP協(xié)議簡(jiǎn)介PPP協(xié)議的定義：PPP協(xié)議提供了一種標(biāo)準(zhǔn)的方式在點(diǎn)對(duì)點(diǎn)的鏈路上傳輸多種 網(wǎng)絡(luò)層協(xié)議的數(shù)據(jù)報(bào)。PPP協(xié)議與協(xié)議棧的對(duì)應(yīng)關(guān)系應(yīng)用層 表示層 會(huì)話層 傳輸層PPP協(xié)議網(wǎng)絡(luò)層 數(shù)據(jù)鏈路層物理層第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP協(xié)議的特點(diǎn)支持點(diǎn)到點(diǎn)的連接，不同于 X.25 、 frame relay 等數(shù)據(jù)

8、鏈路層協(xié)議，具有 CHAP、PAP驗(yàn)證協(xié)議，更好的保證了網(wǎng)絡(luò)的安 全性。PPP的物理層既支持?jǐn)?shù)據(jù)為 8位和無奇偶校驗(yàn)的異步模式，還支持面向比特位的同步鏈接，如 frame relay 必須為同步電 路。PPP有針對(duì)不同網(wǎng)絡(luò)層的網(wǎng)絡(luò)控制協(xié)議，如大家熟知的IPCP, IPXCP 。同樣類似于 SLIP協(xié)議，它也允許雙方協(xié)商是否 對(duì)報(bào)文首部進(jìn)行壓縮。10BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP協(xié)議的三組件多協(xié)議數(shù)據(jù)報(bào)的封裝方式PPP 協(xié)議的鏈路控制協(xié)議 LCPPPP 協(xié)議的網(wǎng)絡(luò)控制協(xié)議 NCP第2章 PPP協(xié)議)鏈路控制協(xié)議、 NCPPPP 協(xié)議主要包括三部分： L

9、CP(Link Control Protocol( Network Control Protocol )和 PPP 的擴(kuò)展協(xié)議(如 隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)帶寬已不再是瓶頸，所以 用也就越來越少，因此往往人們?cè)跀⑹?PPP 協(xié)議時(shí)經(jīng)常會(huì)忘記它的存在。Multilink Protocol ）。 PPP 擴(kuò)展協(xié)議的應(yīng)11BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.00x03 。PPP的數(shù)據(jù)幀格式7EFF037E標(biāo)志地址控制協(xié)議域信息域校驗(yàn) 標(biāo)志1B1B1B2B缺省 1500B2B 1B第2章 PPP協(xié)議我們?cè)谔峒?PPP 協(xié)議的報(bào)文封裝格式時(shí)， 不可不先提一下 HDLC

10、協(xié)議。HDLC 也是最常用的數(shù)據(jù)鏈路層協(xié)議，它是從 SDLC 協(xié)議衍進(jìn)過來的，許多常用的 數(shù)據(jù)鏈路層協(xié)議的封裝方式都是基于 HDLC 的封裝格式的， 同樣 PPP 協(xié)議也 不例外，它也采用了 HDLC 的定界幀格式。以下為對(duì) PPP 數(shù)據(jù)幀封裝格式的一點(diǎn)說明：0x7E 。每一個(gè) PPP 數(shù)據(jù)幀均是以一個(gè)標(biāo)志字節(jié)起始和結(jié)束的，該字節(jié)為緊接在起始標(biāo)志字節(jié)后的一個(gè)字節(jié)是地址域，該字節(jié)為 0xFF 。我們熟知網(wǎng)絡(luò) 是分層的，且對(duì)等層之間進(jìn)行相互通信，而下層為上層提供服務(wù)。當(dāng)對(duì)等層 進(jìn)行通信時(shí)首先需獲知對(duì)方的地址，而對(duì)不同的網(wǎng)絡(luò)，在數(shù)據(jù)鏈路層則表現(xiàn) 為需要知道對(duì)方的 MAC 地址、 X.121 地址、

11、ATM 地址等； 在網(wǎng)絡(luò)層則表現(xiàn)為 需要知道對(duì)方的 IP 地址、 IPX 地址等；而在傳輸層則需要知道對(duì)方的協(xié)議端 口號(hào)。例如如果兩個(gè)以太網(wǎng)上的主機(jī)希望能夠通信的話，首先發(fā)送端需獲知 對(duì)端的 MAC 地址。但由于 PPP 協(xié)議是被運(yùn)用在點(diǎn)對(duì)點(diǎn)的鏈路上的特殊性， 它不像廣播或多點(diǎn)訪問的網(wǎng)絡(luò)一樣，因?yàn)辄c(diǎn)對(duì)點(diǎn)的鏈路就可以唯一標(biāo)示對(duì)方， 因此使用 PPP 協(xié)議互連的通信設(shè)備的兩端無須知道對(duì)方的數(shù)據(jù)鏈路層地址， 所以該字節(jié)已無任何意義，按照協(xié)議的規(guī)定將該字節(jié)填充為全1 的廣播地址。同地址域一樣， PPP 數(shù)據(jù)幀的控制域也沒有實(shí)際意義，按照協(xié)議的規(guī)定通信 雙方將該字節(jié)的內(nèi)容填充為12第2章 PPP協(xié)議BA

12、000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0數(shù)據(jù)幀中信息域所承載的數(shù)據(jù)報(bào)文的內(nèi)容。協(xié)議域的內(nèi)容 的地址擴(kuò)展機(jī)制所給出的規(guī)定。 該機(jī)制規(guī)定協(xié)議域所填充 也即是要求低字節(jié)的最低位為 “1，”高字節(jié)的最低位為 “0。”PPP 數(shù)據(jù)幀的協(xié)議域字段不符合上述規(guī)定，則接收端會(huì) 那么接收端會(huì)向發(fā)送端發(fā)送一個(gè) Protocol-Reject就 PPP 協(xié)議本身而言，我們最關(guān)心的內(nèi)容應(yīng)該是它的協(xié)議域和信息域。協(xié)議 域可用來區(qū)分 PPP 必須依據(jù) ISO 3309 的內(nèi)容必須為奇數(shù)， 如果當(dāng)發(fā)送端發(fā)送的認(rèn)為此數(shù)據(jù)幀是不可識(shí)別的， 報(bào)文，在該報(bào)文尾部將完整地填充被拒絕的報(bào)文。信息域缺省時(shí)最大長(zhǎng)度

13、不能超過 1500 字節(jié)，其中包括填充域的內(nèi)容， 1500 字節(jié)大小等于 PPP 協(xié)議中配置參數(shù)選項(xiàng) MRU (Maximum Receive Unit )的 缺省值，在實(shí)際應(yīng)用當(dāng)中可根據(jù)實(shí)際需要進(jìn)行信息域最大封裝長(zhǎng)度選項(xiàng)的協(xié) 商。信息域如果不足 1500 字節(jié)時(shí)可被填充，但不是必須的，如果填充則需通 信雙方的兩端能辨認(rèn)出有用與無用的信息方可正常通信。說明：MRU 表示本端接收到的選項(xiàng)使用默認(rèn)值 (1500PPP 數(shù)據(jù)幀的數(shù)據(jù)域的最大值。 通常情況下這個(gè)參數(shù)字節(jié)) ，因此在 Config-Request 報(bào)文中雙方都不會(huì)攜帶這個(gè)配置參數(shù)選項(xiàng)。當(dāng)在某些特殊應(yīng)用中，可能會(huì)使用到小于1500 字節(jié)或

14、大于 1500 字節(jié)的情況，這時(shí)在 Config-Request 報(bào)文就會(huì)攜帶要協(xié)商的MRU 配置參數(shù)選項(xiàng)值。CRC 校驗(yàn)域主要是對(duì) PPP 數(shù)據(jù)幀傳輸?shù)恼_性進(jìn)行檢測(cè)的， 當(dāng)然在數(shù)據(jù)幀中 引入了一些傳輸?shù)谋ＷC機(jī)制是好的，但可以反過來說，同樣我們會(huì)引入更多 的開銷，這樣可能會(huì)增加應(yīng)用層交互的延遲。13第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP數(shù)據(jù)幀所承載的幾種常見的報(bào)文0x0021IP數(shù)據(jù)報(bào)文校驗(yàn)0xC021LCP 數(shù)據(jù)報(bào)文校驗(yàn)0x8021NCP 數(shù)據(jù)報(bào)文 校驗(yàn)協(xié)議域長(zhǎng)度為 2個(gè)字節(jié)，主要用來指明信息域中使用的協(xié) 議類型。該域的結(jié)構(gòu)與 ISO3

15、309 地址域擴(kuò)展機(jī)制一致。為了能適應(yīng)復(fù)雜多變的網(wǎng)絡(luò)環(huán)境， PPP 協(xié)議提供了一種鏈路控制協(xié)議來配置 和測(cè)試數(shù)據(jù)通信鏈路，它能用來協(xié)商 PPP 協(xié)議的一些配置參數(shù)選項(xiàng)；處理不 同大小的數(shù)據(jù)幀；檢測(cè)鏈路環(huán)路、一些鏈路的錯(cuò)誤；終止一條鏈路。PPP 的網(wǎng)絡(luò)控制協(xié)議根據(jù)不同的網(wǎng)絡(luò)層協(xié)議可提供一族網(wǎng)絡(luò)控制協(xié)議 (NCP) ， 常用的有提供給 TCP/IP 網(wǎng)絡(luò)使用的 IPCP 網(wǎng)絡(luò)控制協(xié)議； 提供給 SPX/IPX 網(wǎng) 絡(luò)使用的 IPXCP 網(wǎng)絡(luò)控制協(xié)議等。最為常用的是 IPCP 協(xié)議，當(dāng)點(diǎn)對(duì)點(diǎn)的兩 端進(jìn)行 NCP 參數(shù)配置協(xié)商時(shí)，主要是用來通信雙方的網(wǎng)絡(luò)層地址。14第2章 PPP 協(xié)議BA000003

16、 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP狀態(tài)轉(zhuǎn)移圖鏈路不可用階段LCP報(bào)文鏈路建立階段失敗鏈路終止階段網(wǎng)絡(luò)層協(xié)議階段驗(yàn)證階段可選，由配置決定數(shù)據(jù)通信設(shè)備（在本文中指路由器）的兩端如果希望通過 PPP 點(diǎn)的通信， 無論哪一端的設(shè)備都需發(fā)送 LCP 數(shù)據(jù)報(bào)文來配置鏈路 一旦 LCP 的配置參數(shù)選項(xiàng)協(xié)商完后， 通信的雙方就會(huì)根據(jù) LCP 中所協(xié)商的認(rèn)證配置參數(shù)選項(xiàng)來決定鏈路兩端設(shè)備所采用的認(rèn)證方式。 缺省情況下雙方是不進(jìn)行認(rèn)證的，而直接進(jìn)入到 NCP 配置參數(shù)選項(xiàng)的協(xié)商， 直至所經(jīng)歷的幾個(gè)配置過程全部完成后，點(diǎn)對(duì)點(diǎn)的雙方就可以開始通過已建 立好的鏈路進(jìn)行網(wǎng)絡(luò)層數(shù)據(jù)報(bào)文的傳送了，整個(gè)

17、鏈路就處于可用狀態(tài)。只有 當(dāng)任何一端收到 LCP 或 NCP 的鏈路關(guān)閉報(bào)文時(shí) （一般而言協(xié)議是不要求 NCP 有關(guān)閉鏈路的能力的，因此通常情況下關(guān)閉鏈路的數(shù)據(jù)報(bào)文是在 LCP 協(xié)商階 段或應(yīng)用程序會(huì)話階段發(fā)出的）；物理層無法檢測(cè)到載波或管理人員對(duì)該鏈 路進(jìn)行關(guān)閉操作，都會(huì)將該條鏈路斷開，從而終止 協(xié)議整個(gè)鏈路過程需經(jīng)歷階段的狀態(tài)轉(zhuǎn)移圖說明：協(xié)議建立點(diǎn)對(duì) （測(cè)試鏈路） 。 配置請(qǐng)求報(bào)文 協(xié)議PPP 會(huì)話。以下是 PPP在點(diǎn)對(duì)點(diǎn)鏈路的配置、維護(hù)和終止過程中， PPP需經(jīng)歷以下幾個(gè)階段：PPP 鏈路都需從這個(gè)階段鏈路不可用階段。有時(shí)也稱為物理層不可用階段， 開始和結(jié)束。當(dāng)通信雙方的兩端檢測(cè)到物理線

18、路激活（通常是檢測(cè)到鏈路上 有載波信號(hào)） 時(shí)，就會(huì)從當(dāng)前這個(gè)階段躍遷至下一個(gè)階段 （即鏈路建立階段） 。 先簡(jiǎn)單提一下鏈路建立階段，在這個(gè)階段主要是通過 LCP 協(xié)議進(jìn)行鏈路參數(shù) 的配置， LCP 在此階段的狀態(tài)機(jī)也會(huì)根據(jù)不同的事件發(fā)生變化。當(dāng)處于在鏈 路不可用階段時(shí)， LCP 的狀態(tài)機(jī)是處于 initial （初始化狀態(tài)）或 starting （準(zhǔn)15第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0備啟動(dòng)狀態(tài)），一旦檢測(cè)到物理線路可用，則 LCP 的狀態(tài)機(jī)就要發(fā)生改變。 當(dāng)然鏈路被斷開后也同樣會(huì)返回到這個(gè)階段，往往在實(shí)際過程中這個(gè)階段所 停留的時(shí)間是很短

19、的，僅僅是檢測(cè)到對(duì)方設(shè)備的存在。鏈路建立階段。是 PPP 協(xié)議最關(guān)鍵和最復(fù)雜的階段。該階段主要是發(fā)送一些 配置報(bào)文來配置數(shù)據(jù)鏈路，這些配置的參數(shù)不包括網(wǎng)絡(luò)層協(xié)議所需的參數(shù)。 當(dāng)完成數(shù)據(jù)報(bào)文的交換后，則會(huì)繼續(xù)向下一個(gè)階段躍遷，該下一個(gè)階段既可 是驗(yàn)證階段，也可是網(wǎng)絡(luò)層協(xié)議階段，下一階段的選擇是依據(jù)鏈路兩端的設(shè) 備配置的（通常是由用戶來配置，但對(duì) NAS 或 BAS 設(shè)備的 PPP 模塊缺省就 需要支持 PAP 或 CHAP 中的一種認(rèn)證方式）。在此階段 LCP 的狀態(tài)機(jī)會(huì)發(fā) 生兩次改變，前面我們說了當(dāng)鏈路處于不可用階段時(shí)，此時(shí) LCP 的狀態(tài)機(jī)處 于 initial 或 starting ，當(dāng)檢

20、測(cè)到鏈路可用時(shí)， 則物理層會(huì)向鏈路層發(fā)送一個(gè) UP 事 件 ， 鏈 路 層 收 到 該 事 件 后 ， 會(huì) 將 LCP 的 狀 態(tài) 機(jī) 從 當(dāng) 前 狀 態(tài) 改 變 為 Request-Sent （ 請(qǐng)求發(fā)送狀態(tài)） ，根據(jù)此時(shí)的狀態(tài)機(jī) LCP 會(huì)進(jìn)行相應(yīng)的動(dòng)作， 也即是開始發(fā)送 Config-Request 報(bào)文來配置數(shù)據(jù)鏈路，無論哪一端接收到了 Config-Ack 報(bào)文時(shí)， LCP 的狀態(tài)機(jī)又要發(fā)生改變， 從當(dāng)前狀態(tài)改變?yōu)?opened 狀態(tài)，進(jìn)入 Opened 狀態(tài)后收到 Config-Ack 報(bào)文的一方則完成了當(dāng)前階段， 應(yīng)該向下一個(gè)階段躍遷。同理可知，另一端也是一樣的，但須注意的一點(diǎn)是

21、 在鏈路配置階段雙方是鏈路配置操作過程是相互獨(dú)立的。如果在該階段收到 了非 LCP 數(shù)據(jù)報(bào)文，則會(huì)將這些報(bào)文丟棄。驗(yàn)證階段。多數(shù)情況下的鏈路兩端設(shè)備是需要經(jīng)過認(rèn)證后才進(jìn)入到網(wǎng)絡(luò)層協(xié) 議階段，缺省情況下鏈路兩端的設(shè)備是不進(jìn)行認(rèn)證的。在該階段支持 PAP 和 CHAP 兩種認(rèn)證方式，驗(yàn)證方式的選擇是依據(jù)在鏈路建立階段雙方進(jìn)行協(xié)商 的結(jié)果。然而，鏈路質(zhì)量的檢測(cè)也會(huì)在這個(gè)階段同時(shí)發(fā)生，但協(xié)議規(guī)定不會(huì) 讓鏈路質(zhì)量的檢測(cè)無限制的延遲驗(yàn)證過程。在這個(gè)階段僅支持鏈路控制協(xié)議、 驗(yàn)證協(xié)議和質(zhì)量檢測(cè)數(shù)據(jù)報(bào)文，其它的數(shù)據(jù)報(bào)文都會(huì)被丟棄。如果在這個(gè)階 段再次收到了 Config-Request 報(bào)文，則又會(huì)返回到鏈路

22、建立階段。網(wǎng)絡(luò)層協(xié)議階段。 一旦 PPP 完成了前面幾個(gè)階段， 每種網(wǎng)絡(luò)層協(xié)議 （ IP、IPX 和 AppleTalk ）會(huì)通過各自相應(yīng)的網(wǎng)絡(luò)控制協(xié)議進(jìn)行配置，每個(gè) NCP 協(xié)議可 在任何時(shí)間打開和關(guān)閉。 當(dāng)一個(gè) NCP 的狀態(tài)機(jī)變成 Opened 狀態(tài)時(shí)，則 PPP 就可以開始在鏈路上承載網(wǎng)絡(luò)層的數(shù)據(jù)包報(bào)文了。如果在個(gè)階段收到了 Config-Request 報(bào)文，則又會(huì)返回到鏈路建立階段。網(wǎng)絡(luò)終止階段， PPP 能在任何時(shí)候終止鏈路。當(dāng)載波丟失、授權(quán)失敗、鏈路 質(zhì)量檢測(cè)失敗和管理員人為關(guān)閉鏈路等情況均會(huì)導(dǎo)致鏈路終止。鏈路建立階 段可能通過交換 LCP 的鏈路終止報(bào)文來關(guān)閉鏈路，當(dāng)鏈路關(guān)閉

23、時(shí)，鏈路層會(huì) 通知網(wǎng)絡(luò)層做相應(yīng)的操作，而且也會(huì)通過物理層強(qiáng)制關(guān)斷鏈路。對(duì)于 NCP 協(xié) 議，它是沒有也沒有必要去關(guān)閉 PPP 鏈路的。16第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0LCP 協(xié)議數(shù)據(jù)報(bào)文的格式PPP封裝格式項(xiàng)的封裝格式0xC021 。LCP 數(shù)據(jù)報(bào)文是在鏈路建立階段被交換的，它作為 PPP 的凈載荷被封裝在 PPP 數(shù)據(jù)幀的信息域中。在鏈路建立階段的整個(gè)過程中信息域的內(nèi)容是在變 化的，它包括很多種類型的報(bào)文，所以這些報(bào)文也要通過相應(yīng)的字段來區(qū)分， PPP 數(shù)據(jù)幀的協(xié)議域固定填充 代碼域的長(zhǎng)度為一個(gè)字節(jié)，主要是用來標(biāo)識(shí) LCP 數(shù)據(jù)報(bào)文的

24、類型的。在鏈路 建立階段時(shí)，接收方收到 LCP 數(shù)據(jù)報(bào)文的代碼域無法識(shí)別時(shí)，就會(huì)向?qū)Χ税l(fā) 送一個(gè) LCP 的代碼拒絕報(bào)文（ Code-Reject 報(bào)文）。標(biāo)識(shí)域也是一個(gè)字節(jié)，其目的是用來匹配請(qǐng)求和響應(yīng)報(bào)文。一般而言在進(jìn)入 鏈路建立階段時(shí)，通信雙方無論哪一端都會(huì)連續(xù)發(fā)送幾個(gè)配置請(qǐng)求報(bào)文 （ Config-Request 報(bào)文），而這幾個(gè)請(qǐng)求報(bào)文的數(shù)據(jù)域可能是完全一樣的， 而僅僅是它們的標(biāo)識(shí)域不同罷了。通常一個(gè)配置請(qǐng)求報(bào)文的 ID 是從 0x01 開 始逐步加 1 的，當(dāng)對(duì)端接收到該配置請(qǐng)求報(bào)文后，無論使用何種報(bào)文（回應(yīng) 報(bào)文可能是 Config-Ack 、Config-Nak 和 Config

25、-Reject 三種報(bào)文中的一種） 來 回應(yīng)對(duì)方， 但必須要求回應(yīng)報(bào)文中的 ID（標(biāo)識(shí)域） 要與接收?qǐng)?bào)文中的 ID 一致， 當(dāng)通信設(shè)備收到回應(yīng)后就可以將該回應(yīng)與發(fā)送時(shí)的進(jìn)行比較來決定下一步的 操作。長(zhǎng)度域的內(nèi)容 = 總字節(jié)數(shù)據(jù)（代碼域 +標(biāo)志域 +長(zhǎng)度域+數(shù)據(jù)域）。長(zhǎng)度域所指 示字節(jié)數(shù)之外的字節(jié)將被當(dāng)作填充字節(jié)而忽略掉，而且該域的內(nèi)容不能超過 MRU 的值。17BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第2章 PPP協(xié)議數(shù)據(jù)域的內(nèi)容依據(jù)不同 LCP 數(shù)據(jù)報(bào)文的內(nèi)容也是不一樣的。18第 2章 PPP 協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.

26、0LCP協(xié)議數(shù)據(jù)報(bào)文的分類鏈路配置報(bào)文用來建立和配置一條鏈路，主要包括 Configure-Request 、 Configure-Ack 、 Configure-Nak 和Configure-Reject 報(bào)文鏈路終止報(bào)文用來終止一條鏈路，主要包括 Terminate-Request 和 Terminate-Relpy 報(bào)文鏈路維護(hù)報(bào)文 用來管理和調(diào)試鏈路，主要包括 Code-Reject 、 ProtocolReject 、Echo-Request 、 Echo-Reply 和 Discard-Request 報(bào) 文190x01Configure-Request0x07Code-Rejec

27、t0x02Configure-Ack0x08Protocol-Reject0x03Configure-Nak0x09Echo-Request0x04Configure-Reject0x0AEcho-Reply0x05Terminate-Request0x0BDiscard-Request0x06Terminate-Reply0x0CReservedBA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第2章 PPP協(xié)議LCP 協(xié)議數(shù)據(jù)報(bào)文的種類20第 2章 PPP 協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報(bào)文舉例假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一

28、個(gè) Config-Request報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 0208 02 0D 03 06 7E從報(bào)文中可以看出這個(gè)配置請(qǐng)求報(bào)文包括5個(gè)配置參數(shù)選項(xiàng)。當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該回應(yīng)一個(gè) Config-Ack 報(bào)文，報(bào)文內(nèi)容 如下： 7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 020D 03 06 7E 該報(bào)文中唯一修改的內(nèi)容就是代碼域（ 02表示是 Config-

29、Ack 報(bào)文），標(biāo)識(shí) 域與原報(bào)文中的一樣。21第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0配置參數(shù)選項(xiàng)的種類0x01Maximum- Recive-Unit0x05Magic-Number0x02Async-ControlCharacter-Map0x06Reserved0x03AuthenticationProtocol0x07Protocol-Field-Compression0x04Quality-Protocol0x08Address-And-Control-Field-Compression鏈路配置報(bào)文與其它兩類報(bào)文有著明顯的區(qū)別，它主要是用

30、來協(xié)商鏈路的配 置參數(shù)選項(xiàng)的，因此這種報(bào)文的數(shù)據(jù)域還要攜帶許多配置參數(shù)選項(xiàng)的。Config-Request 報(bào)文并鏈 路 配置 報(bào)文 主要 包 括 Config-Request 、 Config-Ack 、 Config-Nak 和 Config-Reject 四種報(bào)文。當(dāng)通信雙方需要建立鏈路時(shí)，無論哪一方都需要發(fā)送 攜帶每一端自已所希望協(xié)商的配置參數(shù)選項(xiàng)。當(dāng)接收方收到 Config-Request 報(bào)文時(shí)，會(huì)在剩下的三種類型的報(bào)文中選擇一 種來響應(yīng)對(duì)方的請(qǐng)求報(bào)文，到底選擇哪種報(bào)文來響應(yīng)對(duì)方需依據(jù)以下兩個(gè)條 件： 不能完全識(shí)別配置參數(shù)選項(xiàng)的類型域，我們知道一個(gè) Config-Request 報(bào)

31、文中 會(huì)同時(shí)攜帶多個(gè)配置參數(shù)選項(xiàng)，而對(duì)于一個(gè)支持 PPP 協(xié)議的通信設(shè)備也不一 定會(huì)支持上表中所有列出的配置選項(xiàng)，即使支持，也可能在實(shí)際應(yīng)用中關(guān)閉 掉某些選項(xiàng)功能。（例如：當(dāng)使用 PPP 協(xié)議通信的一端可能將一些無用的配 置選項(xiàng)都關(guān)閉了，而僅支持 0x01 和 0x03 兩個(gè)配置參數(shù)選項(xiàng)，因此當(dāng)對(duì)方發(fā) 送的 Config-Request 報(bào)文中含有 0x04 配置選項(xiàng)時(shí)，對(duì)于本端而言這個(gè)配置 參數(shù)選項(xiàng)就無法識(shí)別，也即是不支持這個(gè)配置參數(shù)選項(xiàng)的協(xié)商）。如果能支持完全識(shí)別配置參數(shù)選項(xiàng)，但接收端也可能不認(rèn)可 Config-Request報(bào)文中配置參數(shù)選項(xiàng)數(shù)據(jù)域中的內(nèi)容（例如：當(dāng)一端發(fā)送魔術(shù)字配置參數(shù)

32、選22第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0項(xiàng)中的魔術(shù)字為全 0 ，而對(duì)端認(rèn)為應(yīng)該為其它值， 這種情況就屬于不支持配置 參數(shù)選項(xiàng)中的內(nèi)容）。所以依據(jù)上面的兩個(gè)條件，我們就可以明確在回應(yīng)對(duì)方配置請(qǐng)求報(bào)文時(shí)，采 用何種報(bào)文回應(yīng)。23第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報(bào)文舉例假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè) Config-Request報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 0208

33、02 0D 03 06 7E從報(bào)文中可以看出這個(gè)配置請(qǐng)求報(bào)文包括5個(gè)配置參數(shù)選項(xiàng)。當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該回應(yīng)一個(gè) Config-Ack 報(bào)文，報(bào)文內(nèi)容 如下： 7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 020D 03 06 7E 該報(bào)文中唯一修改的內(nèi)容就是代碼域（ 02表示是 Config-Ack 報(bào)文），標(biāo)識(shí) 域與原報(bào)文中的一樣。Config-AckConfig-Ack 報(bào)文 當(dāng)配置請(qǐng)當(dāng)接收 Config-Request 報(bào)文的一端能識(shí)別發(fā)送過來的所有配置參數(shù)選項(xiàng)且認(rèn) 可所有配置參

34、數(shù)選項(xiàng)數(shù)據(jù)域的內(nèi)容時(shí)，接收端將會(huì)給對(duì)端回一個(gè) 報(bào)文并將配置請(qǐng)求報(bào)文中的配置參數(shù)選項(xiàng)原封不動(dòng)的放置在 的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項(xiàng)的順序）。求報(bào)文的發(fā)送端收到 Config-Ack 報(bào)后，則會(huì)從當(dāng)前階段進(jìn)入到下一個(gè)階段。24BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第2章 PPP協(xié)議25第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報(bào)文舉例假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè) Config-Request報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 0

35、0 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E該數(shù)據(jù)報(bào)文中有下劃線的配置參數(shù)選項(xiàng)的內(nèi)容為對(duì)端不認(rèn)可的。 當(dāng)對(duì)端正確接收到了該報(bào)文后，發(fā)現(xiàn)類型域?yàn)?x02的配置參數(shù)選項(xiàng)可識(shí)別，但該配置參數(shù)選項(xiàng)數(shù)據(jù)域的內(nèi)容不認(rèn)可，應(yīng)發(fā)送一個(gè) Config-Nak 報(bào)文且該報(bào)文中 將攜帶希望的配置參數(shù)選項(xiàng)內(nèi)容，報(bào)文內(nèi)容如下：7E FF 03 C0 21 03 01 00 0A 02 06 00 0E 00 00 7E該報(bào)文中返回的值已經(jīng)被更改，且當(dāng)發(fā)端收到該報(bào)文后會(huì)重新發(fā)送一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 C0 21 01 04 00 17

36、 02 06 00 0E 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E仔細(xì)觀察是不是新的配置請(qǐng)求報(bào)文與老的配置請(qǐng)求的報(bào)文 ID 不一樣。當(dāng)接收 Config-Request 報(bào)文的一端能識(shí)別發(fā)送端所發(fā)送過來的所有配置參數(shù) 選項(xiàng)，但對(duì)部分配置參數(shù)選項(xiàng)數(shù)據(jù)域中的內(nèi)容不認(rèn)可時(shí)，接收端將會(huì)給對(duì)端 回應(yīng)一個(gè) Config-Nak 報(bào)文，該報(bào)文中只攜帶不認(rèn)可的配置參數(shù)選項(xiàng)，而這些 配置參數(shù)選項(xiàng)的數(shù)據(jù)內(nèi)容為本端希望的值。然而當(dāng)接收端收到 Config-Nak 報(bào) 文后， 會(huì)重新發(fā)送 Config-Request 報(bào)文， 而這個(gè) Config-Request

37、報(bào)文與上一 次所發(fā)送的 Config-Request 報(bào)文區(qū)別在于那些被對(duì)端不認(rèn)可的配置參數(shù)選項(xiàng) 的 內(nèi) 容 被 填 寫 到 剛 剛 協(xié) 商 完 后 再 次 發(fā) 送 的 Config-Request 報(bào) 文 中 （ Config-Nak 報(bào)文發(fā)送回來的那些配置參數(shù)選項(xiàng)）。26BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第 2 章 PPP 協(xié)議27第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報(bào)文舉例假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè) Config-Request報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 C0 21 01 01 00

38、 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 0208 02 0D 03 06 7E下劃線所表示的配置參數(shù)選項(xiàng)為對(duì)端不可識(shí)別的。 當(dāng)對(duì)端正確接收到了該報(bào)文后，發(fā)現(xiàn)類型域?yàn)?0x02 的配置參數(shù)選項(xiàng)不識(shí) 別，應(yīng)該回應(yīng)一個(gè) Config-Reject報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 C0 21 04 01 00 0A 02 06 00 0A 00 00 7EConfig-Request報(bào)文，該報(bào)文如果被原發(fā)送端接收后，又會(huì)重新發(fā)送一個(gè)報(bào)文內(nèi)容如下：7E FF 03 C0 21 01 04 00 1105 06 00 0B 42 CB 07 02 08 0

39、2 0D 03 06 7E 這時(shí)我們能看到，類型域?yàn)?02的配置選項(xiàng)在下一次的請(qǐng)求報(bào)文中被刪除了。當(dāng)接收 Config-Request 報(bào)文的一端不能識(shí)別所有的發(fā)送端發(fā)送過來的配置參 數(shù)選項(xiàng)時(shí)，此時(shí)接收端將會(huì)向?qū)Χ嘶匾粋€(gè) Config-Reject 報(bào)文，該報(bào)文中的數(shù) 據(jù)域只攜帶那些不能識(shí)別的配置參數(shù)選項(xiàng)（當(dāng)配置參數(shù)選項(xiàng)的類型域不識(shí)別 時(shí) ） 。 當(dāng) 對(duì) 端 接 收 到 Config-Reject 報(bào) 文 后 ， 同 樣 會(huì) 再 次 發(fā) 送 一 個(gè) Config-Request 報(bào)文，這個(gè)配置請(qǐng)求報(bào)文與上一次發(fā)送的區(qū)別在于將不可識(shí) 別的那些配置參數(shù)選項(xiàng)給刪除了。28第2章 PPP協(xié)議BA000

40、003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.029第2章 PPP 協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報(bào)文（四）Config-Request2Config-Reject3Config-Request4Config-Nak5Config-Request6Config-Ack路由器 A多次交互路由器 B鏈路配置階段也可能要經(jīng)過幾次協(xié)商后才能完成，但這與點(diǎn)對(duì)點(diǎn)兩端的設(shè)備 有著密切的聯(lián)系。對(duì)于 PPP 的兩個(gè)端點(diǎn)而言，兩者是獨(dú)立完成各自的配置參 數(shù)選項(xiàng)的協(xié)商過程的。30鏈路終止報(bào)文Terminate-RequestTerminate-Reply第

41、2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路終止報(bào)文分為 Terminate-Request 和 Terminate-Reply 兩種報(bào)文。 LCP 報(bào)文中提供了一種機(jī)制來關(guān)閉一個(gè)點(diǎn)對(duì)點(diǎn)的連接，想要關(guān)斷鏈路的一端會(huì)持 續(xù)發(fā)送 Terminate-Request 報(bào)文，直到收到一個(gè) Terminate-Reply 為止。 接收 端 一 旦 收 到 了 一 個(gè) Terminate-Request 報(bào) 文 后 ， 必 須 回 應(yīng) 一 個(gè) Terminate-Reply 報(bào)文，同時(shí)等待對(duì)端先將鏈路斷開后，再完成本端的所有斷 開的操作。LCP 的鏈路終止報(bào)文的

42、數(shù)據(jù)域與鏈路配置報(bào)文的數(shù)據(jù)域不一樣，鏈路終止報(bào) 文中無需攜帶各配置參數(shù)選項(xiàng)。對(duì)于鏈路終止報(bào)文也同樣需要 ID 一致，當(dāng)接 收到 Terminate-Reply 報(bào)文才會(huì)做鏈路終止操作。31BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第2章 PPP協(xié)議Quality-Protocol 報(bào)文等。 對(duì)于 PPP 協(xié)議本身它是不要求協(xié)商魔術(shù)字的， 在雙方不協(xié)商魔術(shù)字的情況下，某些 么只能是將魔術(shù)字的內(nèi)容填充為全 結(jié)果。0；反之，則填充為配置參數(shù)選項(xiàng)協(xié)商后的中都是需要進(jìn)行協(xié)商的，它被放在魔術(shù)字是在 LCP 的 Config-Request 報(bào)文中被協(xié)商的， 并且可被一些其它類型

43、的 LCP 數(shù) 據(jù) 報(bào) 文 所 使 用 ， 如 Echo-Request 、 Echo-Reply 報(bào) 文 和 如果 LCP 的數(shù)據(jù)報(bào)文需要使用魔術(shù)字時(shí)，那魔術(shù)字在目前所有的設(shè)備當(dāng)Config-Request 的配置選項(xiàng)參數(shù)中進(jìn)行發(fā)送，而且需要由自身的通信設(shè)備獨(dú) 立產(chǎn)生，協(xié)議為了避免雙方可能產(chǎn)生同樣的魔術(shù)字，從而導(dǎo)致通信出現(xiàn)不必 要的麻煩，因此要求由設(shè)備采用一些隨機(jī)方法產(chǎn)生一個(gè)獨(dú)一無二的魔術(shù)字。 一般來說魔術(shù)字的選擇會(huì)采用設(shè)備的系列號(hào)、網(wǎng)絡(luò)硬件地址或時(shí)鐘。雙方產(chǎn) 生相同魔術(shù)字的可能性不能說是沒有的，但應(yīng)盡量避免，通常這種情況是發(fā) 產(chǎn)在相同廠商的設(shè)備進(jìn)行互連時(shí)，因?yàn)橐粋€(gè)廠商所生產(chǎn)的設(shè)備產(chǎn)生魔術(shù)字

44、的 方法是一樣的。我們知道魔術(shù)字產(chǎn)生的作用是用來幫助檢測(cè)鏈路是否存在環(huán)路，當(dāng)接收端收 到 一 個(gè) Config-Request 報(bào) 文 時(shí) ， 會(huì) 將 此 報(bào) 文 與 上 一 次 所 接 收 到 的 Config-Request 進(jìn)行比較，如果兩個(gè)報(bào)文中所含的魔術(shù)字不一致的話，表明 鏈路不存在環(huán)路。但如果一致的話，接收端認(rèn)為鏈路可能存在環(huán)路，但不一 定存在環(huán)路，還需進(jìn)一步確認(rèn)。此時(shí)接收端將發(fā)送一個(gè) Config-Nak 報(bào)文，并 在該報(bào)文中攜帶一個(gè)重新產(chǎn)生的魔術(shù)字，而且此時(shí)在未接收到任何32第 2章 PPP 協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0Config-

45、Request 或 Config-Nak 報(bào) 文 之 前 ， 接 收 端 也 不 會(huì) 發(fā) 送 任 何 的Config-Request 報(bào)文。這時(shí)我們假設(shè)可能會(huì)有以下兩種情況發(fā)生：1. 鏈路實(shí)際不存在環(huán)路，而是由于對(duì)方在產(chǎn)生魔術(shù)字時(shí)與接收端產(chǎn)生的一 致，但實(shí)際這種情況出現(xiàn)的概率是很小的。當(dāng) Config-Nak 被對(duì)端接收到 后，應(yīng)該發(fā)送一個(gè) Config-Request 報(bào)文（此報(bào)文中的魔術(shù)字為 Nak 報(bào)文 中的），當(dāng)對(duì)端接收到后，與上次比較，由于接收端已經(jīng)在 Nak 報(bào)文中 產(chǎn)生了一個(gè)不同的魔術(shù)字，此時(shí)接收端收到的 Config-Request 報(bào)文中的 魔術(shù)字與上次配置請(qǐng)求報(bào)文中不一樣，

46、所以接收端可斷定鏈路不存在環(huán) 路。2. 鏈路實(shí)際上確實(shí)存在環(huán)路，一段時(shí)間后 Config-Nak 報(bào)文會(huì)返回到發(fā)送該 報(bào)文的同一端。這時(shí)接收端比較這個(gè) Config-Nak 報(bào)文與上一次發(fā)出去的 一樣，因此鏈路存在環(huán)路的可能性又增大了。我們知道當(dāng)一端收到了一 個(gè) Config-Nak 報(bào)文時(shí)， 又會(huì)發(fā)送一個(gè) Config-Request 報(bào)文（該報(bào)文中的 魔術(shù)字與 Config-Nak 中的一致），這樣又回到了最初的狀態(tài)，在這條鏈 路上就會(huì)不斷的出現(xiàn) Config-Request 、 Config-Nak 報(bào)文，因此這樣周而 復(fù)始下去，接收端就會(huì)認(rèn)為 PPP 鏈路存在環(huán)路的可能性在不斷增加，當(dāng)

47、 達(dá)到一定數(shù)量級(jí)時(shí)，就可認(rèn)為此鏈路存在環(huán)路。但在實(shí)際應(yīng)用中根據(jù)不同設(shè)備實(shí)現(xiàn) PPP 協(xié)議的方法，我們?cè)阪溌翻h(huán)路檢測(cè)時(shí) 可采用兩種方法。第一種機(jī)制就是如上面所述的，這個(gè)過程不斷地重復(fù)，最 終可能會(huì)給 LCP 狀態(tài)機(jī)發(fā)一個(gè) Down 事件，這時(shí)可能會(huì)使 LCP 的狀態(tài)機(jī)又回 到初始化階段，又開始新一輪的協(xié)商。當(dāng)然對(duì)于某些設(shè)備還會(huì)采用第二種機(jī) 制，就是不產(chǎn)生任何事件去影響當(dāng)前 LCP 的狀態(tài)機(jī)，而是停留在請(qǐng)求發(fā)送狀 態(tài)。但這時(shí)認(rèn)為鏈路有環(huán)路的一端設(shè)備需要不斷的向鏈路上發(fā)送 Echo-Request 報(bào)文來檢測(cè)鏈路環(huán)路是否被解除，當(dāng)接收端收到 Echo-Reply 報(bào)文時(shí)，就認(rèn)為鏈路環(huán)路被解除，從而就

48、可能進(jìn)行后續(xù)的 PPP 的過程。33第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP 協(xié)議也提供了可選的認(rèn)證配置參數(shù)選項(xiàng)，缺省情況下點(diǎn)對(duì)點(diǎn)通信的兩端 是不進(jìn)行認(rèn)證的。 在 LCP 的 Config-Request 報(bào)文中不可一次攜帶多種認(rèn)證配 置選項(xiàng)，必須二者擇其一（ PAP/CHAP ）。一般是在 PPP 設(shè)備互連的設(shè)備上 進(jìn)行配置的，或設(shè)備默認(rèn)支持一個(gè)缺省的認(rèn)證方式（ PAP 是大部分設(shè)備所默 認(rèn)的認(rèn)證方式）。當(dāng)對(duì)端收到該配置請(qǐng)求報(bào)文后，如果支持配置參數(shù)選項(xiàng)中 的認(rèn)證方式，則回應(yīng)一個(gè) Config-Ack 報(bào)文；否則回應(yīng)一個(gè) Config-Nak

49、 報(bào)文， 并附帶上自希望雙方采用的認(rèn)證方式。當(dāng)對(duì)方接收到 Config-Ack 報(bào)文后就可 以開始進(jìn)行認(rèn)證了，而如果收到得是 Config-Nak 報(bào)文，則根據(jù)自身是否支持 Config-Nak 報(bào)文中的認(rèn)證方式來 回應(yīng)對(duì)方，如果支持則 回應(yīng)一個(gè)新 的 Config-Request （并攜帶上 Config-Nak 報(bào)文中所希望使用的認(rèn)證協(xié)議），否 則將回應(yīng)一個(gè) Config-Reject 報(bào)文，那么雙方就無法通過認(rèn)證，從而不可能建 立起 PPP 鏈路。PPP 支持兩種授權(quán)協(xié)議： PAP( Password Authentication Protocol )和 CHAP ( Challenge

50、 Hand Authentication Protocol)。PAP我們所知兩個(gè)設(shè)備在使用 PAP 進(jìn)行認(rèn)證之前，應(yīng)該確認(rèn)那一方是驗(yàn)證方，那 一方是被驗(yàn)證方。實(shí)際上對(duì)于使用 PPP 協(xié)議互連的兩端來說，既可作為認(rèn)證 方，也可作為被認(rèn)證方。但通常情況下， PAP 只使用一個(gè)方向上的認(rèn)證。一 般在兩端設(shè)備使用 PAP 協(xié)議之前，均會(huì)設(shè)備上進(jìn)行一些相應(yīng)的配置，對(duì)于 MA5200IP 接入設(shè)備，它默認(rèn)就作為驗(yàn)證方，但可通過使用命令34BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第2章 PPP協(xié)議Authentication PAP/CHAP 來更改認(rèn)證方式， 而對(duì)于被驗(yàn)證方而言

51、只需設(shè)置用 戶名和密碼即可。PAP 認(rèn)證是兩次握手，在鏈路建立階段，依據(jù)設(shè)備上的配置情況，如果是使 用 PAP 認(rèn)證，則驗(yàn)證方在發(fā)送 Config-Request 報(bào)文時(shí)會(huì)攜帶認(rèn)證配置參數(shù)選 項(xiàng)，而對(duì)于被驗(yàn)證方而言則是不需要，它只需要收到該配置請(qǐng)求報(bào)文后根據(jù) 自身的情況給對(duì)端返回相應(yīng)的報(bào)文。如果點(diǎn)對(duì)點(diǎn)的兩端設(shè)備采用的是 PAP 雙 向認(rèn)證時(shí)，也即是它同時(shí)也作為驗(yàn)證方，則此時(shí)需要在配置請(qǐng)求報(bào)文中攜帶 認(rèn)證配置參數(shù)選項(xiàng)。因此，我們可以總結(jié)一下，如果對(duì)于點(diǎn)對(duì)點(diǎn)的兩個(gè)設(shè)備 在 PPP 鏈路建立的過程中使用的認(rèn)證方式為 PAP 的話，那么驗(yàn)證方在其 Config-Request 報(bào)文中必須含有認(rèn)證配置參

52、數(shù)選項(xiàng)，且該認(rèn)證配置參數(shù)選項(xiàng) 的數(shù)據(jù)域?yàn)?0xC023 。當(dāng)通信設(shè)備的兩端在收到對(duì)方返回的 Config-Ack 報(bào)文時(shí)，就從各自的鏈路建 立階段進(jìn)入到認(rèn)證階段，那么作為被驗(yàn)證方此時(shí)需要向驗(yàn)證方發(fā)送 PAP 認(rèn)證 的請(qǐng)求報(bào)文，該請(qǐng)求報(bào)文攜帶了用戶名和密碼，當(dāng)驗(yàn)證方收到該認(rèn)證請(qǐng)求報(bào) 文后，則會(huì)根據(jù)報(bào)文中的實(shí)際內(nèi)容查找本地的數(shù)據(jù)庫，如果該數(shù)據(jù)庫中有與 用戶名和密碼一致的選項(xiàng)時(shí)，則回向?qū)Ψ椒祷匾粋€(gè)認(rèn)證請(qǐng)求響應(yīng)，告訴對(duì)方 認(rèn)證已通過。反之，如果用戶名與密碼不符，則向?qū)Ψ椒祷仳?yàn)證不通過的響 應(yīng)報(bào)文。如果雙方都配置為驗(yàn)證方，則需要雙方的兩個(gè)單向驗(yàn)證過程都完成 后，方可進(jìn)入到網(wǎng)絡(luò)層協(xié)議階段，否則在一定次的認(rèn)證失敗后，則會(huì)從當(dāng)前 狀態(tài)返回鏈路不可用狀態(tài)。例如：當(dāng)路由器 A （被驗(yàn)證方）收到了路由器 B 的 Config-Ack 報(bào)文后，因?yàn)?是使用 PAP 認(rèn)證，所以作為被驗(yàn)證方的路由器 A 應(yīng)主動(dòng)向驗(yàn)證方 （路由器 B ） 發(fā)送認(rèn)證請(qǐng)求報(bào)文（ PAP Authenticate ），用戶名和密碼均為 163 ，報(bào)文的內(nèi) 容如下：7E FF 03 C0 23 01 01 00 0C 03 31