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

1、課程 BA000003PPP協(xié)議和 PPP0E 協(xié)議ISSUE1.0Huawei TechnologiesBA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0目錄課程說明課程介紹課程目標第1章 概述第2章 PPP協(xié)議第3章 PPPOE 協(xié)議附錄 縮略詞表4874課程說明BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0課程說明課程介紹本教材為寬帶產(chǎn)品工程師培訓(xùn)公共課程。本課程介紹 PPP協(xié)議和 PPPOE協(xié)議。課程目標完成本課程學(xué)習，學(xué)員能夠：了解SLIP 協(xié)議的基本原理。掌握PPP 協(xié)議的基本原理。掌握LCP 協(xié)議和 NCP 協(xié)議數(shù)據(jù)報文的交換過程。掌握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ù)對報進行封裝的簡單協(xié)議。SLIP數(shù)據(jù)幀格式：IP數(shù)據(jù)報文END 字符SLIP 數(shù)據(jù)幀SLIP 的全稱是 Serial Line IP ，出現(xiàn)在 80 年代中期，并被使用在 BSD UNIX 主機和 SUN 的工作站上。因為 SLIP 簡單好用，所以后來被大量使用在線路 速率從 1200bps 到

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

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

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

6、2/24 ，那你的地址是多少？還要通過這么原始的方式來獲知對方的 IP 地址SLIP 幀的封裝格式非常簡單，通信雙方無需在數(shù)據(jù)報發(fā)送前協(xié)商任何配置參 數(shù)選項（在 PPP 協(xié)議中需協(xié)商配置參數(shù)選項） ，所以雙方 IP 層通信前必需先 獲知對方的 IP 地址，才能進行網(wǎng)絡(luò)層的通信，否則鏈路層發(fā)送的數(shù)據(jù)幀在被送到對方網(wǎng)絡(luò)層時將無法進行轉(zhuǎn)發(fā)。正是由于上面的諸多缺點，導(dǎo)致了 SLIP 很快的被后面要講的 PPP 協(xié)議所替代。第 1 章 概述BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0小節(jié)SLIP 是一種僅能在點對點的鏈路上封裝 IP數(shù)據(jù)報的協(xié)議SLIP的幀格式為IP數(shù)據(jù)報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é)議簡介PPP協(xié)議的定義：PPP協(xié)議提供了一種標準的方式在點對點的鏈路上傳輸多種 網(wǎng)絡(luò)層協(xié)議的數(shù)據(jù)報。PPP協(xié)議與協(xié)議棧的對應(yīng)關(guān)系應(yīng)用層 表示層 會話層 傳輸層PPP協(xié)議網(wǎng)絡(luò)層 數(shù)據(jù)鏈路層物理層第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP協(xié)議的特點支持點到點的連接，不同于 X.25 、 frame relay 等數(shù)據(jù)

8、鏈路層協(xié)議，具有 CHAP、PAP驗證協(xié)議，更好的保證了網(wǎng)絡(luò)的安 全性。PPP的物理層既支持數(shù)據(jù)為 8位和無奇偶校驗的異步模式，還支持面向比特位的同步鏈接，如 frame relay 必須為同步電 路。PPP有針對不同網(wǎng)絡(luò)層的網(wǎng)絡(luò)控制協(xié)議，如大家熟知的IPCP, IPXCP 。同樣類似于 SLIP協(xié)議，它也允許雙方協(xié)商是否 對報文首部進行壓縮。10BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0PPP協(xié)議的三組件多協(xié)議數(shù)據(jù)報的封裝方式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 的擴展協(xié)議(如 隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)帶寬已不再是瓶頸，所以 用也就越來越少，因此往往人們在敘述 PPP 協(xié)議時經(jīng)常會忘記它的存在。Multilink Protocol ）。 PPP 擴展協(xié)議的應(yīng)11BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.00x03 。PPP的數(shù)據(jù)幀格式7EFF037E標志地址控制協(xié)議域信息域校驗 標志1B1B1B2B缺省 1500B2B 1B第2章 PPP協(xié)議我們在提及 PPP 協(xié)議的報文封裝格式時， 不可不先提一下 HDLC

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

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

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

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

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

15、309 地址域擴展機制一致。為了能適應(yīng)復(fù)雜多變的網(wǎng)絡(luò)環(huán)境， PPP 協(xié)議提供了一種鏈路控制協(xié)議來配置 和測試數(shù)據(jù)通信鏈路，它能用來協(xié)商 PPP 協(xié)議的一些配置參數(shù)選項；處理不 同大小的數(shù)據(jù)幀；檢測鏈路環(huán)路、一些鏈路的錯誤；終止一條鏈路。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é)議，當點對點的兩 端進行 NCP 參數(shù)配置協(xié)商時，主要是用來通信雙方的網(wǎng)絡(luò)層地址。14第2章 PPP 協(xié)議BA000003

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

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

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

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

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

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

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

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

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

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

26、0LCP協(xié)議數(shù)據(jù)報文的分類鏈路配置報文用來建立和配置一條鏈路，主要包括 Configure-Request 、 Configure-Ack 、 Configure-Nak 和Configure-Reject 報文鏈路終止報文用來終止一條鏈路，主要包括 Terminate-Request 和 Terminate-Relpy 報文鏈路維護報文 用來管理和調(diào)試鏈路，主要包括 Code-Reject 、 ProtocolReject 、Echo-Request 、 Echo-Reply 和 Discard-Request 報 文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ù)報文的種類20第 2章 PPP 協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報文舉例假設(shè)點對點通信的一端發(fā)送了一

28、個 Config-Request報文，報文內(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從報文中可以看出這個配置請求報文包括5個配置參數(shù)選項。當對端正確接收到了該報文后，應(yīng)該回應(yīng)一個 Config-Ack 報文，報文內(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 該報文中唯一修改的內(nèi)容就是代碼域（ 02表示是 Config-

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

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

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

32、選22第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0項中的魔術(shù)字為全 0 ，而對端認為應(yīng)該為其它值， 這種情況就屬于不支持配置 參數(shù)選項中的內(nèi)容）。所以依據(jù)上面的兩個條件，我們就可以明確在回應(yīng)對方配置請求報文時，采 用何種報文回應(yīng)。23第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報文舉例假設(shè)點對點通信的一端發(fā)送了一個 Config-Request報文，報文內(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從報文中可以看出這個配置請求報文包括5個配置參數(shù)選項。當對端正確接收到了該報文后，應(yīng)該回應(yīng)一個 Config-Ack 報文，報文內(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 該報文中唯一修改的內(nèi)容就是代碼域（ 02表示是 Config-Ack 報文），標識 域與原報文中的一樣。Config-AckConfig-Ack 報文 當配置請當接收 Config-Request 報文的一端能識別發(fā)送過來的所有配置參數(shù)選項且認 可所有配置參

34、數(shù)選項數(shù)據(jù)域的內(nèi)容時，接收端將會給對端回一個 報文并將配置請求報文中的配置參數(shù)選項原封不動的放置在 的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項的順序）。求報文的發(fā)送端收到 Config-Ack 報后，則會從當前階段進入到下一個階段。24BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第2章 PPP協(xié)議25第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報文舉例假設(shè)點對點通信的一端發(fā)送了一個 Config-Request報文，報文內(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ù)報文中有下劃線的配置參數(shù)選項的內(nèi)容為對端不認可的。 當對端正確接收到了該報文后，發(fā)現(xiàn)類型域為0x02的配置參數(shù)選項可識別，但該配置參數(shù)選項數(shù)據(jù)域的內(nèi)容不認可，應(yīng)發(fā)送一個 Config-Nak 報文且該報文中 將攜帶希望的配置參數(shù)選項內(nèi)容，報文內(nèi)容如下：7E FF 03 C0 21 03 01 00 0A 02 06 00 0E 00 00 7E該報文中返回的值已經(jīng)被更改，且當發(fā)端收到該報文后會重新發(fā)送一個Config-Request報文，報文內(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仔細觀察是不是新的配置請求報文與老的配置請求的報文 ID 不一樣。當接收 Config-Request 報文的一端能識別發(fā)送端所發(fā)送過來的所有配置參數(shù) 選項，但對部分配置參數(shù)選項數(shù)據(jù)域中的內(nèi)容不認可時，接收端將會給對端 回應(yīng)一個 Config-Nak 報文，該報文中只攜帶不認可的配置參數(shù)選項，而這些 配置參數(shù)選項的數(shù)據(jù)內(nèi)容為本端希望的值。然而當接收端收到 Config-Nak 報 文后， 會重新發(fā)送 Config-Request 報文， 而這個 Config-Request

37、報文與上一 次所發(fā)送的 Config-Request 報文區(qū)別在于那些被對端不認可的配置參數(shù)選項 的 內(nèi) 容 被 填 寫 到 剛 剛 協(xié) 商 完 后 再 次 發(fā) 送 的 Config-Request 報 文 中 （ Config-Nak 報文發(fā)送回來的那些配置參數(shù)選項）。26BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0第 2 章 PPP 協(xié)議27第2章 PPP協(xié)議BA000003 PPP 協(xié)議和 PPP0E 協(xié)議 ISSUE1.0鏈路配置報文舉例假設(shè)點對點通信的一端發(fā)送了一個 Config-Request報文，報文內(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ù)選項為對端不可識別的。 當對端正確接收到了該報文后，發(fā)現(xiàn)類型域為 0x02 的配置參數(shù)選項不識 別，應(yīng)該回應(yīng)一個 Config-Reject報文，報文內(nèi)容如下：7E FF 03 C0 21 04 01 00 0A 02 06 00 0A 00 00 7EConfig-Request報文，該報文如果被原發(fā)送端接收后，又會重新發(fā)送一個報文內(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 這時我們能看到，類型域為 02的配置選項在下一次的請求報文中被刪除了。當接收 Config-Request 報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參 數(shù)選項時，此時接收端將會向?qū)Χ嘶匾粋€ Config-Reject 報文，該報文中的數(shù) 據(jù)域只攜帶那些不能識別的配置參數(shù)選項（當配置參數(shù)選項的類型域不識別 時 ） 。 當 對 端 接 收 到 Config-Reject 報 文 后 ， 同 樣 會 再 次 發(fā) 送 一 個 Config-Request 報文，這個配置請求報文與上一次發(fā)送的區(qū)別在于將不可識 別的那些配置參數(shù)選項給刪除了。28第2章 PPP協(xié)議BA000

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

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

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

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

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

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

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

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

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

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

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

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

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