PPP_PPPOE協(xié)議培訓(xùn)ppt課件

1、PPP-PPPOE協(xié)議培訓(xùn)固網(wǎng)終端產(chǎn)品部ISSUE 1.0學(xué)習(xí)目的掌握PPP協(xié)議原理和封裝構(gòu)造。熟習(xí)PPP鏈路的建立過程。掌握PPPOE協(xié)議原理和封裝構(gòu)造。熟習(xí)PPPOE報文的交互過程。了解處置PPP/PPPOE相關(guān)問題的方法。學(xué)習(xí)完本課程，您應(yīng)該可以：參考資料 RFC1334、RFC1994Request For Comments, 懇求注解, Internet規(guī)范草案想一想：上述資料的獲取途徑是什么？引入PPP協(xié)議位于OSI七層模型的哪一層？PPPOE協(xié)議位于OSI七層模型的哪一層？他們的區(qū)別和聯(lián)絡(luò)是什么？OSI：Open System Interconnect Reference Mod

2、el 開放式系統(tǒng)互聯(lián)參考模型；ISO： International Organization for Standardization 國際規(guī)范化組織。目錄第一章 PPP協(xié)議第二章 PPPOE協(xié)議第三章 缺點處置及報文分析PPP協(xié)議的特點PPP協(xié)議是數(shù)據(jù)鏈路層協(xié)議。支持點到點的銜接。物理層可以是同步電路或異步電路。支持多種NCP，如IPCP、IPXCP，更好地支持了網(wǎng)絡(luò)層協(xié)議。支持驗證：CHAP、PAP，保證了網(wǎng)絡(luò)的平安性。端對端的對等性，不是client/server方式。PPP：Point-to-Point Protocol 點到點協(xié)議PPP協(xié)議族LCP：鏈路控制協(xié)議，用于建立、配置及測試數(shù)

3、據(jù)鏈路。它允許通訊雙方進展協(xié)商，以確定不同的選項，并完成PPP數(shù)據(jù)鏈路的建立，撤除和監(jiān)控。PAP/CHAP：密碼驗證協(xié)議/訊問握手鑒權(quán)協(xié)議，網(wǎng)絡(luò)平安方面的驗證協(xié)議族。NCP：網(wǎng)絡(luò)控制協(xié)議，支持不同的網(wǎng)絡(luò)層協(xié)議，協(xié)商在該數(shù)據(jù)鏈路上傳輸?shù)臄?shù)據(jù)包的格式與類型。IPCP：NCP最常用的一種，在PPP鏈路上協(xié)商特定的IP參數(shù)，如IP地址，DNS地址。PPP擴展協(xié)議PPP協(xié)議形狀機DeadEstablishAuthenticateNetworkTerminateUpOpenedFailSuccess/NoneClosingDownFailLCPPAP?CHAPIPCPPPP數(shù)據(jù)幀的格式PPP協(xié)議為了消除多

4、協(xié)議數(shù)據(jù)包在點對點鏈路傳輸上發(fā)生歧義，因此采用類似于以太網(wǎng)的定界幀格式來表示PPP封裝的起始點和終了點，PPP的幀格式看上去非常像ISO的HDLC規(guī)范。標(biāo)志域：固定為7E。地址域：固定為FF。控制域：固定為03。協(xié)議域：0021：IP報文；c021：LCP報文； 8021：IPCP報文；c023：PAP； c223：CHAP。校驗標(biāo)志標(biāo)志地址信息域控制協(xié)議域1B1B2B缺省1500B7EFF031B2B1B7E想一想為什么？LCP報文格式校驗標(biāo)志標(biāo)志地址信息域控制協(xié)議域1B1B2B缺省1500B7EFF031B2B1B7ELCP數(shù)據(jù)報文的封裝格式標(biāo)識域代碼域長度域數(shù)據(jù)1B1B2B0 x010

5、x020 x030 x040 x050 x060 x070 x080 x090 x0A0 x0B0 x0CConfigure-RequestConfigure-AckConfigure-NakConfigure-RejectTerminate-RequestTerminate-AckCode-RejectProtocol-RejectEcho-RequestEcho-ReplyDiscard-RequestReservedLCP配置參數(shù)選項格式LCP數(shù)據(jù)報文的封裝格式校驗標(biāo)志標(biāo)志地址信息域控制協(xié)議域1B1B2B缺省1500B7EFF031B2B1B7ELCP數(shù)據(jù)報文中配置參數(shù)選項的封裝格式長度

6、域類型域數(shù)據(jù)1B1B標(biāo)識域代碼域長度域數(shù)據(jù)1B1B2B0 x010 x020 x030 x040 x050 x060 x070 x08Maximum-Recive-UnitAsync-Control-Character-MapAuthentication-ProtocolQuality-ProtocolMagic-NumberAddress-And-Control-Field-CompressionReservedProtocol-Field-CompressionLCP的協(xié)商過程LCP Config_ReqLCP Config_RejLCP Config_ReqLCP Config_NakL

7、CP Config_ReqLCP Config_AckLCP Config_ReqLCP Config_AckAuthentication_ReqAuthentication_AckChallengeAuthentication_ReqAuthentication_AckConfig-req報文里的配置參數(shù)類型不支持時，回reject報文，同時把不支持的屬性在此報文中帶回Config-req報文里的配置參數(shù)類型支持，但值不支持時，回nak報文，同時把此屬性及值在此報文中帶回LCP協(xié)商勝利，呼應(yīng)ack報文LCP協(xié)商是雙向的Pap認(rèn)證過程，認(rèn)證及方式是可選的chap認(rèn)證過程，認(rèn)證及方式是可選的LC

8、P Config-Request & Config-Ack假設(shè)點對點通訊的一端發(fā)送了一個Config-Request報文，報文內(nèi)容如下：當(dāng)對端正確接納到了該報文后，應(yīng)該發(fā)送一個Config-Ack報文，報文內(nèi)容如下：獨一改動的內(nèi)容就是代碼域02表示是Config-Ack報文。LCP Config-Request & Config-Nak該數(shù)據(jù)報文中有下劃線的配置參數(shù)選項的內(nèi)容為對端不認(rèn)可的。當(dāng)對端正確接納到了該報文后，發(fā)現(xiàn)類型域為0 x02的配置參數(shù)選項可識別，但該配置參數(shù)選項數(shù)據(jù)域的內(nèi)容不認(rèn)可，應(yīng)發(fā)送一個Config-Nak報文且該報文中將攜帶希望的配置參數(shù)選項內(nèi)容，報文內(nèi)容如下：該報文中前

9、往的值曾經(jīng)被更改，且當(dāng)發(fā)端收到該報文后會重新發(fā)送一個Config-Request報文，報文內(nèi)容如下：新的配置懇求報文與老的配置懇求的報文ID不一樣。：LCP Config-Request & Config-Reject下劃線所表示的配置參數(shù)選項為對端不可識別的。當(dāng)對端正確接納到了該報文后，發(fā)現(xiàn)類型域為0 x02的配置參數(shù)選項不識別，應(yīng)該回應(yīng)一個Config-Reject報文，報文內(nèi)容如下：該報文假設(shè)被原發(fā)送端接納后，又會重新發(fā)送一個Config-Request報文，報文內(nèi)容如下：How about Code-Reject & Protocol-Reject ?認(rèn)證階段通訊設(shè)備的兩端首先經(jīng)過Co

10、nfig-Request 協(xié)商認(rèn)證方式。驗證方在其Config-Request報文中必需含有認(rèn)證配置參數(shù)選項，不需認(rèn)證的一方就不需攜帶該配置選項。雙方都收到Config-Ack報文時，就會進入到認(rèn)證階段。Code=1Type=03 Authentication-Protocol：PAP認(rèn)證PAP認(rèn)證是兩次握手協(xié)議。被驗證方向驗證方發(fā)送PAP認(rèn)證的懇求報文，攜帶了用戶名和密碼。當(dāng)驗證方收到該認(rèn)證懇求報文后，那么會根據(jù)報文中的實踐內(nèi)容查找本地的數(shù)據(jù)庫，假設(shè)該數(shù)據(jù)庫中有與用戶名和密碼一致的選項時，那么回向?qū)Ψ角巴粋€認(rèn)證經(jīng)過的呼應(yīng)報文。假設(shè)用戶名與密碼不符，那么向?qū)Ψ角巴炞C不經(jīng)過的呼應(yīng)報文。：PA

11、P認(rèn)證懇求報文 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer-ID Length| Peer-Id . +-+-+-+-+-+-+-+-+-+-+-+-+ | P

12、asswd-Length | Password . +-+-+-+-+-+-+-+-+-+-+-+-+-+：Code？1 Authenticate-RequestPAP認(rèn)證應(yīng)對報文 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

13、+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-Length | Message . +-+-+-+-+-+-+-+-+-+-+-+-+-：Code？2 Authenticate-Ack3 Authenticate-NakCHAP認(rèn)證CHAP為三次握手協(xié)議。它只在網(wǎng)絡(luò)上傳送用戶名而不傳送口令，因此平安性比PAP高。首先由驗證方向被驗證方發(fā)送一段隨機的報文，并加上本人的主機名，我們通稱這個過程叫做挑戰(zhàn)。被驗證方運用用戶名所對應(yīng)的密鑰、報文ID和挑戰(zhàn)用Md5加密算法生成應(yīng)對，隨后將應(yīng)對和用戶名送回。驗證方提取被驗證方的用戶名，然后去查找本地的數(shù)據(jù)庫，根據(jù)該用戶名所對應(yīng)的密鑰、保管報

14、文ID和隨機報文用Md5加密算法生成結(jié)果，和剛剛被驗證方所前往的應(yīng)對進展比較，一樣前往經(jīng)過，否那么前往失敗。 ：CHAP認(rèn)證懇求報文：Code？1 Challenge2 Response 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

15、-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Size | Value . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+CHAP認(rèn)證應(yīng)對報文：Code？3 Success4 Failure 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

16、-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message . +-+-+-+-+-+-+-+-+-+-+-+-+-NCP協(xié)議IPCPIPCP控制協(xié)議主要是擔(dān)任完成IP網(wǎng)絡(luò)層協(xié)議通訊所需配置參數(shù)的選項協(xié)商的。IPCP在運轉(zhuǎn)的過程當(dāng)中，主要是完成點對點通訊設(shè)備的兩端IP地址的動態(tài)協(xié)商。 IPCP報文類型只是LCP數(shù)據(jù)報文的一個子集只需LCP代碼域從1到7這七種報文，而且實踐的數(shù)據(jù)

17、報文交換過程中也僅涉及以下幾種：Config-Request、Config-Ack、Config-Nak和Config-Reject代碼域從1到4，而鏈路終止報文普通而言是不在網(wǎng)絡(luò)協(xié)議階段運用的，而且也是不需求的。 校驗標(biāo)志標(biāo)志地址信息域控制協(xié)議域1B1B2B缺省1500B7EFF031B2B1B7E想一想：如何區(qū)分IPCP和LCP報文？8021IPCP的協(xié)商過程IPCP協(xié)商是雙向的，協(xié)商本端的IP地址，普通是VT地址IPCP Config_Req “我是0.0.0.0“不，他是192.168.0.1 IPCP Config_NAKIPCP Config_Req “好，我是192.168.0.

18、1“好，他是192.168.0.1 IPCP Config_ACK“我是1.1.1.1 IPCP Config_ReqIPCP Config_Ack “好，他是1.1.1.1Echo_Req “他還在么“我還在 Echo_replyIPCP的協(xié)商普通就是IP的協(xié)商，也是雙向的經(jīng)過IPCP，客戶端得到IP地址用戶在線后定時握手，握手可以由客戶端發(fā)起，也可以由效力器發(fā)起IPCP 報文示范有下劃線的部分表示本端的IP地址。對端接納到了該報文后，回應(yīng)一個Config-Nak報文：接納方收到該報文后，重新發(fā)送一個Config-Request報文：接納方再次收到發(fā)送方的一個Config-Request報文

19、，此時將回應(yīng)一個Config-Ack報文：請仔細(xì)察看一下這些報文在交互過程中，PPP數(shù)據(jù)幀凈載荷內(nèi)的數(shù)據(jù)報文的類型域和報文ID。 ：思索題Configure-Nak、Configure-Reject、Code-Reject、Protocol-Reject報文都是在什么情況下回應(yīng)？Echo-Request、Echo-Reply除了握手以外，還具備檢測環(huán)路的功能，那么它會攜帶什么配置參數(shù)選項？IPCP協(xié)商時，能否要求兩端IP地址在同一網(wǎng)段？IPCP協(xié)商經(jīng)過后，BAS和CLIENT設(shè)備各自的路由表會發(fā)生什么變化？目錄第一章 PPP協(xié)議第二章 PPPOE協(xié)議第三章 缺點處置及報文分析PPPOE協(xié)議概述

20、PPP 協(xié)議要求進展通訊的雙方之間是點到點的關(guān)系，不適于廣播型的以太網(wǎng)和另外一些多點訪問型的網(wǎng)絡(luò)，于是就產(chǎn)生了PPPOE 協(xié)議(Point-to-Point Protocol Over Ethernet)。PPPOE不僅為運用橋接以太網(wǎng)接入的用戶提供了一種寬帶接入手段，同時還能提供方便的接入控制和計費。每個接入用戶均建立一個獨一無二PPP的會話；會話建立之前必需知道遠端訪問集中設(shè)備的MAC地址。想一想：要在以太網(wǎng)上實現(xiàn)PPP銜接，需求處理哪兩個關(guān)鍵問題？PPPOE的兩個階段發(fā)現(xiàn)階段：一個主機發(fā)現(xiàn)一個接入集中器，發(fā)現(xiàn)AC的MAC；確定會話標(biāo)識Session ID。會話階段：主機和接入集中器之間根

21、據(jù)PPP協(xié)議傳送PPP數(shù)據(jù)，進展PPP的各項協(xié)商和數(shù)據(jù)傳輸。傳輸?shù)臄?shù)據(jù)包中必需包含在發(fā)現(xiàn)階段確定的會話標(biāo)識并堅持不變。PPPOE報文格式發(fā)現(xiàn)階段 VER (4bit) SESSION_ID (2octets) LENGTH (2octets) payload TYPE (4bit) CODE(1octets)DESTINATION_ADDR (6octets) SOURCE_ADDR (6octets) ETHER_TYPE (2octets) payload CHECKSUMTAG_TYPE (2octets)TAG_LENGTH (2octets)TAG_VALUE TAG_TYPE (2

22、octets)TAG_LENGTH (2octets)TAG_VALUE 8863PPPOE報文格式會話階段 VER (4bit) SESSION_ID (2octets) LENGTH (2octets) payload TYPE (4bit) CODE(1octets)DESTINATION_ADDR (6octets) SOURCE_ADDR (6octets) ETHER_TYPE (2octets) payload CHECKSUM8864PPP報文ProtocolInformation?PPPOE報文解析VER：固定為1；TYPE：固定為1；CODE：發(fā)現(xiàn)階段：0 x09PADIP

23、PPOE Active Discovery Initiation0 x07PADOPPPOE Active Discovery Offer 0 x19PADRPPPOE Active Discovery Request 0 x65PADSPAD Session- confirmation 0 xa7PADTPPPOE Active Discovery Terminate 會話階段：0 x00Session ID：PPP會話的獨一標(biāo)識。PPPOE發(fā)現(xiàn)階段常見tag-type值及含義值含義說明0 x0000End-Of-List此TAG之后再無別的TAG。長度域為0。是為了向后兼容，不要求必須使用

24、。0 x0101Service-Name提供了服務(wù)名。可以用它指明服務(wù)的級別或質(zhì)量0 x0102AC-Name指接入設(shè)備的名稱0 x0103Host-Uniq主機產(chǎn)生，響應(yīng)報文不能改變此字段0 x0104AC-CookieAC產(chǎn)生，響應(yīng)報文不能改變此字段0 x0105Verdor-Specific廠家信息，一般不解釋0 x0110Relay-Session-ID中繼設(shè)備產(chǎn)生，AC和主機都不能改變此字段0 x0201Service-Name-Error表示不能支持請求的服務(wù)0 x0202AC-System-ErrorAC在處理主機的請求時出現(xiàn)錯0 x0203Generic-Error當(dāng)出現(xiàn)不可恢

25、復(fù)的錯誤時，并且沒有別的合適的告警TAG時使用PPPOE的交互過程PADI報文目的地址為廣播地址，源地址為主機的MAC地址。ETHER_TYPE值為0 x8863，碼值為0 x09，SESSION-ID為0 x0000。TAG_TYPE：主機標(biāo)識和效力名。PADI報文長度不能超越1484個字節(jié)，為Relay-Session-Id TAG留空間。PADO報文目的地址為主機MAC地址，源地址為AC MAC地址。ETHER_TYPE值為0 x8863，碼值為0 x07，SESSION-ID為0 x0000。TAG_TYPE：AC設(shè)備名、主機標(biāo)識和效力名，添加終了標(biāo)志。PADR報文目的地址為AC MA

26、C地址，源地址為主機MAC地址。ETHER_TYPE值為0 x8863，碼值為0 x19，SESSION-ID為0 x0000。TAG_TYPE：主機標(biāo)識和效力名。PADS報文目的地址為主機 MAC地址，源地址為AC MAC地址。ETHER_TYPE值為0 x8863，碼值為0 x65，SESSION-ID為0 x016B。TAG_TYPE：主機標(biāo)識、效力名和終了標(biāo)志。PADT報文PADT可以由主機或者AC發(fā)送。ETHER_TYPE值為0 x8863，碼值為0 xA7，SESSION-ID為需求終止的PPP會話標(biāo)識：0 x016B。TAG_TYPE：無。當(dāng)發(fā)送或者收到PADT的時候，不允許再運用當(dāng)前這個進程發(fā)送PPP數(shù)據(jù)流量，甚至正常的PPP終止報文也不能被發(fā)送。 思索題AC與PPPOE主機必需處于同一個二層以太網(wǎng)中，對嗎？PPPOE協(xié)議中，建議PPP的MRU為1492，為什么？PPPOE承載Echo-Request、Echo-Reply報文時，以太網(wǎng)類型和CODE域填充的值各是什么？8850接到用戶發(fā)出的PADT報文，會做什么處置？用戶發(fā)