1pm ba000003 寬帶協(xié)議原理 issue2.0

1、寬帶協(xié)議原理—中國鐵通定制,,Page 2,學習完此課程，您將會：掌握PPP協(xié)議的基本原理和交互過程掌握PPPOE協(xié)議的基本原理和交互過程掌握Radius協(xié)議的基本原理和交互過程掌握DHCP協(xié)議的基本原理和交互過程掌握802.1X認證原理,目 標,Page 3,第1章 PPP協(xié)議第2章 PPPOE協(xié)議第3章 Radius協(xié)議第4章 DHCP協(xié)議第5章 802.1X原理,內容介紹,Page 4,PPP協(xié)議簡介,PPP協(xié)

2、議提供了一種標準的方式在點對點的鏈路上傳輸多種網(wǎng)絡層協(xié)議的數(shù)據(jù)報。,PPP協(xié)議與協(xié)議棧的對應關系,,PPP協(xié)議,Page 5,PPP協(xié)議的特點,支持點到點的連接，不同于X.25、frame relay等數(shù)據(jù)鏈路層協(xié)議，具有CHAP、PAP驗證協(xié)議，更好的保證了網(wǎng)絡的安全性。PPP的物理層既支持數(shù)據(jù)為8位和無奇偶校驗的異步模式，還支持面向比特位的同步鏈接，如frame relay必須為同步電路。PPP有針對不同網(wǎng)絡層的網(wǎng)絡控制協(xié)議，如

3、大家熟知的IPCP, IPXCP。同樣類似于SLIP協(xié)議，它也允許雙方協(xié)商是否對報文首部進行壓縮。,Page 6,PPP協(xié)議的三組件,多協(xié)議數(shù)據(jù)報的封裝方式PPP協(xié)議的鏈路控制協(xié)議LCPPPP協(xié)議的網(wǎng)絡控制協(xié)議NCP,Page 7,PPP的數(shù)據(jù)幀格式,,,,,,,,校驗,標志,標志,地址,信息域,控制,協(xié)議域,1B,1B,2B,缺省1500B,7E,FF,03,1B,2B,1B,7E,Page 8,,,,校驗,IP數(shù)據(jù)報文,0x00

4、21,,,,校驗,LCP數(shù)據(jù)報文,0xC021,,,,校驗,NCP數(shù)據(jù)報文,0x8021,協(xié)議域長度為2個字節(jié)，主要用來指明信息域中使用的協(xié)議類型。該域的結構與ISO3309地址域擴展機制一致。,PPP數(shù)據(jù)幀所承載的幾種常見的報文,Page 9,LCP報文,可選，由配置決定,PPP狀態(tài)轉移圖,Page 10,,,信息域,協(xié)議域,,標識域,,,代碼域,長度域,,數(shù)據(jù),,長度域,,類型域,,數(shù)據(jù),,,,,PPP封裝格式,LCP數(shù)據(jù)報文的封裝

5、格式,LCP數(shù)據(jù)報文中配置參數(shù)選項的封裝格式,0xC021,LCP協(xié)議數(shù)據(jù)報文的格式,Page 11,LCP協(xié)議數(shù)據(jù)報文的分類,鏈路配置報文用來建立和配置一條鏈路，主要包括Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject報文 鏈路終止報文用來終止一條鏈路，主要包括Terminate-Request和Terminate-Reply報文 鏈路維護報文用

6、來管理和調試鏈路，主要包括Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request,Page 12,,0x01,,,,,,,,,,,,,,,,,,,,,,,,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,Configure-Request,Configure-Ack,Configure-Nak,C

7、onfigure-Reject,Terminate-Request,Terminate-Reply,Code-Reject,Protocol-Reject,Echo-Request,Echo-Reply,Discard-Request,Reserved,LCP協(xié)議數(shù)據(jù)報文的種類,Page 13,鏈路配置報文（一）,Page 14,鏈路配置報文（二）,二次交互（1）,,,2,Config-Request,Config-Nak,路由器A,路

8、由器B,,3,,4,Config-Request,Config-Ack,,,,1,Page 15,二次交互（2）,,,,1,,2,Config-Request,Config-Reject,路由器A,路由器B,,3,,4,Config-Request,Config-Ack,鏈路配置報文（三）,,Page 16,多次交互,,,,1,,2,Config-Request,Config-Reject,路由器A,路由器B,,3,,4,Config-

9、Request,Config-Nak,,5,6,Config-Request,Config-Ack,,鏈路配置報文（四）,,Page 17,Terminate-RequestTerminate-Reply,鏈路終止報文,Page 18,,用戶名/密碼,接收/拒絕,,PPP封裝,路由器A,路由器B,被驗證方,驗證方,PAP認證（兩次握手）,Page 19,,回應,接收/拒絕,,PPP封裝,路由器A,路由器B,挑戰(zhàn),被驗證方,驗證方,C

10、HAP認證（三次握手）,Page 20,NCP協(xié)議的分類,IPCPIPXCPAppleTalk,Page 21,點對點通信設備均設置了IP地址,路由器B,路由器A,192.168.0.1,192.168.0.2,IPCP靜態(tài)地址協(xié)商,Page 22,IPCP動態(tài)地址協(xié)商,路由器A,192.168.0.2,點對點通信的一方設置了IP地址，而另一方則通過從對端獲取IP地址,Page 23,小結,PPP協(xié)議的三組件包括PPP協(xié)議的封裝方式

11、、LCP協(xié)議和NCP協(xié)議 PPP協(xié)議是數(shù)據(jù)鏈路層協(xié)議，它的數(shù)據(jù)幀封裝格式非常類似于HDLC PPP協(xié)議可通過協(xié)議域來區(qū)分數(shù)據(jù)域中凈載荷的數(shù)據(jù)類型 PPP協(xié)議通過LCP協(xié)議完成數(shù)據(jù)鏈路的配置和測試 PPP協(xié)議通過NCP協(xié)議完成點對點通信設備之間網(wǎng)絡層通信所需參數(shù)的配置,Page 24,小結,PAP（密碼認證協(xié)議）認證是二次握手，它是直接在網(wǎng)絡上傳送明文的用戶名和密碼，因此這種協(xié)議安全性不高 CHAP（挑戰(zhàn)性握手認證協(xié)議

12、）認證是三次握手，它只在網(wǎng)絡上傳送驗證方和被驗證方的主機名，而并不傳送密碼，因此相比之下CHAP比PAP更安全 PPP協(xié)議缺省的MRU是1500，而對于通信的雙方可根據(jù)實際需要對MRU進行協(xié)商,Page 25,小結,PPP協(xié)議的狀態(tài)轉移圖包括鏈路不可用階段、鏈路建立階段、認證階段、網(wǎng)絡層協(xié)議階段和鏈路終止階段 LCP協(xié)議依據(jù)報文的功能可分為鏈路配置報文、鏈路終止報文和鏈路維護報文 LCP協(xié)議的鏈路配置報文主要是用來協(xié)商一些可

13、選的配置參數(shù)選項 LCP協(xié)議的鏈路終止報文主要是用來終止一條PPP鏈路 LCP協(xié)議的鏈路維護報文主要是用來測試和調試PPP鏈路 NCP協(xié)議主要負責網(wǎng)絡層配置參數(shù)選項的協(xié)商，它包括"靜態(tài)協(xié)商"和"動態(tài)協(xié)商",Page 26,第1章 PPP協(xié)議第2章 PPPOE協(xié)議第3章 Radius協(xié)議第4章 DHCP協(xié)議第5章 802.1X原理,內容介紹,Page 27,PPPOE協(xié)議概述,

14、PPP協(xié)議要求進行通信的雙方之間是點到點的關系，不適于廣播型的以太網(wǎng)和另外一些多點訪問型的網(wǎng)絡，于是就產生了PPPOE協(xié)議(Point-to-Point Protocol Over Ethernet)。它不僅為使用橋接以太網(wǎng)接入的用戶提供了一種寬帶接入手段，同時還能提供方便的接入控制和計費。每個接入用戶均建立一個獨一無二PPP的會話，因此會話建立之前必需知道遠端訪問集中設備的MAC地址，PPPOE協(xié)議可通過發(fā)現(xiàn)協(xié)議來獲取到。,Page

15、28,發(fā)現(xiàn)階段,PPPOE協(xié)議分為發(fā)現(xiàn)階段和PPP會話階段。當主機希望開始一個PPPOE會話時，它首先要執(zhí)行一個發(fā)現(xiàn)過程來識別對方的MAC地址，然后建立一個唯一的PPPOE會話ID。PPPOE使用一個發(fā)現(xiàn)協(xié)議來解決這個問題，它是基于客戶/服務器模型的。由于以太網(wǎng)的廣播特性，在這個過程中主機(客戶)能發(fā)現(xiàn)所有的訪問集中器(服務器)，并選擇其中一個，根據(jù)所獲信息在兩者之間建立點對點的連接。當一個PPP會話被建立起來之后，就完成了PPPOE的

16、整個發(fā)現(xiàn)階段。,Page 29,會話階段,PPPOE的會話階段開始后，主機和訪問集中器之間就依據(jù)PPP協(xié)議傳送PPP數(shù)據(jù)，進行PPP的各項協(xié)商和數(shù)據(jù)傳輸。在這一階段傳輸?shù)臄?shù)據(jù)包中必須包含在發(fā)現(xiàn)階段確定的會話標識并保持不變。正常情況下，會話階段的結束是由PPP協(xié)議控制完成的，但在PPPOE中定義了一個PADT 包用來結束會話，主機或者訪問集中器可以在PPP會話開始后的任何時候通過發(fā)送這個數(shù)據(jù)包來結束會話。,Page 30,以太網(wǎng)的幀格式,

17、Page 31,,,,,,目的地址,源地址,(6字節(jié)),(6字節(jié)),幀類型域,<=1500字節(jié),凈載荷,幀校驗,(4字節(jié)),以太網(wǎng)幀格式,(2字節(jié)),以太網(wǎng)廣播(PADI)/單播地址,PPPOE發(fā)現(xiàn)階段,PPPOE會話階段,,,,,,,以太網(wǎng)單播地址,主機以太網(wǎng)地址,主機以太網(wǎng)地址,0x8863,0x8864,數(shù)據(jù)區(qū),數(shù)據(jù)區(qū),數(shù)據(jù)幀校驗,數(shù)據(jù)幀校驗,PPPOE發(fā)現(xiàn)階段以太網(wǎng)幀格式,PPPOE會話階段以太網(wǎng)幀格式,PPPOE的幀格式

18、（一）,Page 32,,,,,,,版本,類型,代碼,會話ID,長度,凈載荷,4,4,8,16,16,,,發(fā)現(xiàn)階段承載一些標記,會話階段承載PPP數(shù)據(jù)報文,PPPOE的幀格式（二）,Page 33,TAG,,,,標記類型,16,標記長度,16,標記值,0x0000,,,,,,,,,,,,,0x0102,0x0104,0x0110,0x0101,0x0103,0x0105,0x0201,End-of-list,AC-Name,AC-Coo

19、kie,Relay-Session-ID,,,,,Service-Name,Service-Name-Error,Host-Uniq,Verdor-Specific,,,,0x0202,0x0203,AC-System-Error,,Generic-Error,PPPOE的幀格式（三）,Page 34,PPPOE發(fā)現(xiàn)階段數(shù)據(jù)報文分類,PADI(PPPOE發(fā)現(xiàn)初始報文) 09 PADO(PPPOE

20、發(fā)現(xiàn)提供報文) 07 PADR(PPPOE發(fā)現(xiàn)請求報文) 19 PADS(PPPOE發(fā)現(xiàn)會話確認報文) 65 PADT(PPPOE發(fā)現(xiàn)終止報文) a7,Page 35,以太網(wǎng),1,2,3,,,,目標地址為廣播地址0xffffffff，源地址為主機的以太網(wǎng)地址。ETHER_TYPE值為0x8863，碼值為0

21、x09，SESSION-ID為0x0000。TAG_TYPE：有且僅有一個Service-Name表明主機請求的服務。任何數(shù)量的其他TAG_TYPE。 PADI報文長度不能超過1484個字節(jié)，為Relay-Session-Id TAG留空間。,PADI報文,Page 36,PADI報文,Page 37,以太網(wǎng),1,2,3,,,,,,,,,,,,,,,,目標地址為主機以太網(wǎng)地址。源地址為接入集中器的以太網(wǎng)地址。ETHER_TYPE值為0x

22、8863，碼值為0x07，SESSION-ID為0x0000，TAG_TYPE：必須有一個含有接入集中器名字的AC-Name TAG，必須有一個與收到的PADI相同的Service-Name TAG和任意數(shù)量的其他Service- Name TAG表明集中器可以提供的服務。,PADO報文,Page 38,PADO報文,Page 39,以太網(wǎng),1,2,3,,目標地址為接入集中器的以太網(wǎng)地址，源地址為主機的以太網(wǎng)地址。 ETHER_TYPE

23、值為0x8863，碼值為0x19，SESSION-ID為0x0000，TAG_TYPE： 必須有一個類型為Service-Name的TAG向集中器指明請求的服務，可以有任意數(shù)量的其他TAG。,PADR報文,Page 40,PADR報文,Page 41,以太網(wǎng),1,2,3,,,,,,目標地址為主機的 以太網(wǎng)地址，源地址為接入集中器的以太網(wǎng)地址。 ETHER_TYPE值為0x8863，碼值為0x65，SESSION-ID為集中器指定的唯一的

24、標識一個PPPOE會話的值，TAG_ TYPE：包含一個類型為Service-Name的TAG，表明集中器提供給這個會話的服務，可以包含任意數(shù)量的其他TAG。,PADS報文,Page 42,PADS報文,Page 43,這個數(shù)據(jù)包可以在會話建立起來之后的任何時間由主機或集中器發(fā)出。目的地址為單一的以太網(wǎng)地址。 ETHER_TYPE值為0x8863，碼值為0xa7，SESSION-ID為要終止的會話的SESSION-ID。不要求有TAG。

25、,PADT報文,Page 44,PADT報文,Page 45,,,,,,,,,,,,,PPP凈載荷,目的地址（0-3）,目的地址（4-5）,源地址（0-1）,源地址（2-5）,幀類型=0x8864,版本=0x1,類型=0x1,代碼=0x00,會話ID=0x1234,長度=0x????,PPP協(xié)議ID=0xC021,PPPOE協(xié)議數(shù)據(jù)包中承載PPP的LCP報文,一旦PPPOE會話建立起來之后，主機與接入器之間就開始依據(jù)PPP協(xié)議傳送PPP

26、數(shù)據(jù)，所有的以太網(wǎng)幀都是單一地址的。此時，ETHER_TYPE值為0x8864，碼值為0x00，SESSION-ID在整個會話過程中保持不變。PPPOE有效負載域里包含一個PPP數(shù)據(jù)包。,會話階段的PPPOE數(shù)據(jù)報文格式,Page 46,小結,PPPOE協(xié)議包括PPPOE的發(fā)現(xiàn)階段和PPPOE的會話階段 PPPOE的數(shù)據(jù)報文是被承載在以太網(wǎng)的數(shù)據(jù)域中進行傳送的 PPPOE的發(fā)現(xiàn)階段會遇到PADI、PADO、PADR和PADS

27、這四種報文 PPPOE中的PADT報文是用來終止一條會話的 PPPOE在發(fā)現(xiàn)階段時，以太網(wǎng)協(xié)議域的值為0x8863 PPPOE在會話階段時，以太網(wǎng)協(xié)議域的值為0x8864,Page 47,第1章 PPP協(xié)議第2章 PPPOE協(xié)議第3章 Radius協(xié)議第4章 DHCP協(xié)議第5章 802.1X原理,內容介紹,,Page 48,概述,,Page 49,Radius：Remote Authentication Di

28、al In User Service客戶端負責將認證等信息按照協(xié)議的格式通過UDP包送到服務器，同時對服務器返回的信息解釋處理。,認證端口號：1645/ 1812計費端口號：1646/1813,Radius的作用,Page 50,RADIUS的客戶端通常運行于接入服務器（NAS）上，RADIUS服務器通常運行于一臺工作站上，一個RADIUS服務器可以同時支持多個RADIUS客戶（NAS）。RADIUS的服務器上存放著大量的信息，

29、接入服務器（NAS）無須保存這些信息，而是通過RADUIS協(xié)議對這些信息進行訪問。這些信息的集中統(tǒng)一的保存，使得管理更加方便，而且更加安全。RADIUS服務器可以作為一個代理，以客戶的身份同其他的RADIUS服務器或者其他類型的驗證服務器進行通信。用戶的漫游通常就是通過RADIUS代理實現(xiàn)的。,Client/Server結構,Page 51,NAS?Radius認證計費過程,Page 52,MD5是一個算法，它的輸入是一段內存中的數(shù)

30、值，輸出是一個16字節(jié)的摘要，它的運算是單向的，即從輸出推算不出輸入。,不好意思，我只會把您的手表變成兔子，變不回去了……,MD5,MD5算法,Page 53,包加密16字節(jié)的驗證字（authenticator）用于對包進行簽名口令加密MD5算法對口令進行加密,網(wǎng)絡安全,Page 54,稱共享密鑰（key）為Key；16字節(jié)的認證請求驗證字(Authenticator)為Auth；將口令(Password)分割成16字節(jié)一段（

31、最后一段不足16字節(jié)時用0補齊），為p1、p2等；加密后的口令塊為c(1)、c(2)等。下面運算中b1、b2為中間值： b1 = MD5(Key + Auth) c(1) = p1 xor b1 b2 = MD5(Key + c(1)) c(2) = p2 xor b2 …… …… …… bi = MD5(Key+ c(i-1))

32、 c(i) = pi xor bi那么加密后的口令為c(1)+c(2)+...+c(i)。,口令的加密,Page 55,包的簽名與加密：包的簽名指的是RADIUS包中16字節(jié)的Authenticator，我們稱其為“驗證字”。認證請求包RequestAuth=Authenticator，認證請求包的驗證字是一個不可預測的16字節(jié)隨機數(shù)。這個隨機數(shù)將用于口令的加密。認證響應包ResponseAuth = MD5(C

33、ode+ID+Length+Authenticator+Attributes+Key)。記費請求包RequestAcct = MD5(Code+ID+Length+16ZeroOctets+Attributes+Key)。記費響應包ResponseAcct = MD5(Code+ID+Length+RequestAcct+Attributes+Key)。,包的簽名與加密,Page 56,我查……我驗……,本地認證——PAP

34、,Page 57,Secret Password = MD5（Chap ID + Password + challenge）,我查……我算……我驗……,本地認證——CHAP,Page 58,如果用戶配置了RADIUS驗證，其PAP驗證過程如下：,采用PAP驗證：用戶以明文的形式把用戶名和他的密碼傳遞給NAS。NAS把用戶名和加密過的密碼放到驗證請求包的相應屬性中傳遞給RADIUS服務器，根據(jù)RADIUS服務器的返回結果來決定是否允許

35、用戶上網(wǎng)。,用戶名、密碼,放行,遠端PAP認證,Page 59,Secret password =Password XOR MD5（Challenge ＋ Key）(Challenge就是Radius報文中的Authenticator),我查……我算……我驗……,遠端認證（Radius）——PAP,Page 60,遠端PAP認證,Page 61,Secret password = MD5（Chap ID + Password +

36、challenge）,我查……我算……我驗……,遠端認證（Radius）——CHAP,Page 62,遠端CHAP認證,Page 63,Radius是一種流行的AAA協(xié)議，同時其采用的是UDP協(xié)議傳輸模式，AAA協(xié)議在協(xié)議棧中位置如下：,Radius協(xié)議,,Radius協(xié)議在協(xié)議棧中的位置,Page 64,為什么使用UDP？ NAS和RADIUS服務器之間傳遞的一般是幾十至上百個字節(jié)長度的數(shù)據(jù)，用戶可以容忍幾秒到十幾秒的驗證等

37、待時間。當處理大量用戶時服務器端采用多線程，UDP簡化了服務器端的實現(xiàn)過程。 TCP是必須成功建立連接后才能進行數(shù)據(jù)傳輸?shù)模@種方式在有大量用戶使用的情況下實時性不好。 當向主用服務器發(fā)送請求失敗后，還要必須向備用的服務器發(fā)送請求。于是RADIUS要有重傳機制和備用服務器機制，它所采用的定時，TCP不能很好的滿足。,Radius協(xié)議選擇UDP作為傳輸層協(xié)議,Page 65,Radius協(xié)議包結構,Page 66,Code

38、：包類型；1字節(jié)；指示RADIUS包的類型。Identifier：包標識；1字節(jié)；用于匹配請求包和響應包，同一組請求包和響應包的Identifier應相同。Length：包長度；2字節(jié)；整個包的長度。Authenticator：驗證字；16字節(jié)；用于對包進行簽名。,Radius協(xié)議包各個域解釋,Page 67,1 Access-Request——請求認證過程 2 Access-Acc

39、ept——認證響應過程 3 Access-Reject——認證拒絕過程 4 Accounting-Request——請求計費過程 5 Accounting-Response——計費響應過程,code域,Page 68,NAS,Radius Server與NAS在全網(wǎng)中的位置,Page 69,1、RADIUS的通信是用“請求 - 響應”方式進行的，即：客戶

40、發(fā)送一個請求包，服務器收到包后給予響應。2、RADIUS協(xié)議采用的是UDP協(xié)議，數(shù)據(jù)包可能會在網(wǎng)絡上丟失，如果客戶沒有收到響應，那么可以重新發(fā)送該請求包。多次發(fā)送之后如果仍然收不到響應，RADIUS客戶可以向備用的RADIUS服務器發(fā)送請求包。,NAS?Radius認證計費過程,Page 70,內容介紹,第1章 PPP協(xié)議第2章 PPPOE協(xié)議第3章 Radius協(xié)議第4章 DHCP協(xié)議第5章 802.1X原理,Page 7

41、1,引入,本章節(jié)主要通過對設備終端動態(tài)從主機獲得IP地址的過程分析,來說明網(wǎng)絡是如何動態(tài)的分配其所有的地址資源。,Page72,目 錄,4.1 使用DHCP的原因4.2 DHCP原理4.3 DHCP工作流程舉例,Page 73,,什么是DHCP,DHCP (Dynamic Host Configuration Protocol)是一種動態(tài)的向Internet終端提供配置參數(shù)的協(xié)議。在終端提出申請之后，DHCP可以向終端提供IP地址

42、、網(wǎng)關、DNS服務器地址等參數(shù)。,,,提出申請,分配地址等參數(shù),DHCP Server,Client,IP地址池,Page 74,DHCP在協(xié)議棧中的位置,DHCP是Bootstrap協(xié)議的一種擴展,基于UDP協(xié)議,客戶端的端口號是68,服務器的端口號是67。,Page 75,DHCP的必要性,在大型網(wǎng)絡中，如果每臺終端的地址都是由不同的使用這來分配，那么就很容易出現(xiàn)地址相同的情況。,192.168.0.1,192.168.0.2,19

43、2.168.0.1,地址沖突了,Page 76,DHCP的必要性,在TCP/IP網(wǎng)絡上，每臺工作站在訪問網(wǎng)絡及其資源之前，都必須進行基本的網(wǎng)絡配置，一些主要參數(shù)諸如IP地址，子網(wǎng)掩碼，缺省網(wǎng)關，DNS等必不可少，還可能需要一些附加的信息如IP管理策略之類。在大型網(wǎng)絡中，確保所有主機都擁有正確的配置是一件的相當困難的管理任務，尤其對于含有漫游用戶和筆記本電腦的動態(tài)網(wǎng)絡更是如此。經常有計算機從一個子網(wǎng)移到另一個子網(wǎng)以及從網(wǎng)絡中移出。手動配

44、置或重新配置數(shù)量巨大的計算機可能要花很長時間，而IP主機配置過程中的錯誤可能導致該主機無法與網(wǎng)絡中的其他主機通信。因此，需要有一種機制來簡化IP地址的配置，實現(xiàn)IP的集中式管理。而IETF（Internet網(wǎng)絡工程師任務小組）設計的動態(tài)主機配置協(xié)議（DHCP，Dynamic Host Configuration Protocol）正是這樣一種機制。,Page 77,采用DHCP的好處,減少錯誤 通過配置DHCP，把手工配置IP地址所

45、導致的錯誤減少到最低程度，例如已分配的IP地址再次分配給另一設備所造成的地址沖突等將大大減少。減少網(wǎng)絡管理TCP/IP配置是集中化和自動完成的，不需要網(wǎng)絡管理員手工配置。網(wǎng)絡管理員能集中定義全局和特定子網(wǎng)的TCP/IP配置信息。使用DHCP選項可以自動給客戶機分配全部范圍的附加TCP/IP配置值?？蛻魴C配置的地址變化必須經常更新，比如遠程訪問客戶機經常到處移動，這樣便于它在新的地點重新啟動時，高效而又自動地進行配置。同時大部分路由器

46、能轉發(fā)DHCP配置請求，這就減少了在每個子網(wǎng)設置DHCP服務器的必要，除非有其它原因要這樣做。,Page 78,,,,,,,,DHCP的結構,DHCP采用客戶機/服務器結構。DHCP服務器擁有一個IP地址池，當任何啟用DHCP的客戶機登錄到網(wǎng)絡時，可從它那里租借一個IP地址，不使用的IP地址就自動返回地址池，供再分配。,,,,,,,,,,,,,提出申請,分配地址等參數(shù),地址釋放,Client,Server,Page 79,DHCP的責任

47、,保證任何IP地址在同一時刻只能由一臺DHCP客戶機所使用DHCP應當可以給用戶分配永久固定的IP地址DHCP應當可以同用其他方法獲得IP地址的主機共存(如手工配置IP地址的主機)DHCP服務器應當向現(xiàn)有的BOOTP客戶端提供服務,Page 80,DHCP的責任,考慮到成本,無需每個子網(wǎng)都配備一臺DHCP服務器,所以DHCP協(xié)議應當可以通過路由器或者BOOTP代理透傳。,,DHCP Server,Client,IP地址池,,

48、,DHCP報文,DHCP報文,Page 81,DHCP的責任,當一臺DHCP客戶機重新啟動時,在允許的情況下,它應當獲得和上次相同的地址和配置,,,DHCP Server,192.168.0.1,IP地址池,Reboot,192.168.0.1,Page 82,DHCP的責任,當一臺DHCP服務器重新啟動時,在允許的情況下,它應當給每一臺DHCP客戶機分配和上次相同的地址,,,DHCP Server,192.168.0.1,IP地址池,

49、Reboot,192.168.0.1,Page83,目 錄,4.1 使用DHCP的原因4.2 DHCP原理4.3 DHCP工作流程舉例,Page 84,DHCP服務器,保留的地址池（地址池段1）（地址池段2）……,分配的地址(網(wǎng)絡地址1，硬件地址1） 分配的IP地址1(網(wǎng)絡地址2，硬件地址2） 分配的IP地址2…….,DNS服務器地址WINS服務器地址……,Page 85,DHCP客戶機,Page 86,,

50、,,,,,,,地址申請流程,,,,,,,,,Client,Server,,,,,,,,,,,,,,,,,,DHCPDISCOVER,,DHCPOFFER,,REQUEST,,DHCPACK,Page 87,DHCP的報文種類,DHCPDISCOVER —— 客戶機廣播發(fā)現(xiàn)可用的DHCP服務器DHCPOFFER —— 服務器響應客戶機的DHCPDISCOVER報文,并向客戶機提供各種的配置參數(shù)DHCPREQUEST —— a)客戶機

51、向服務器申請地址及其他配置參數(shù) b)客戶機重新啟動后確認原來的地址及其他配置參數(shù)的正確性 c)客戶機向服務器申請延長地址及其他配置參數(shù)的使用期限DHCPACK —— 服務器向客戶機發(fā)送所需分配的地址及其他配置參數(shù),Page 88,DHCP的報文種類,DHCPNAK —— 服務器通知客戶機,其申請的地址無效,或者已經超期DHCPDECLINE —— 客戶機通知服務器,其分配的地址已經被其他設備所使用DHCPRELEASE —

52、— 客戶機放棄其所使用的地址,Page 89,DHCP的有限狀態(tài)機,INIT,INIT-REBOOT,REBOOTING,SELECTING,REQUESING,REBINGING,BOUND,RENEWING,,,,,,DHCPNAK/Restart,DHCPNAK/Discard offer,,DHCPREQUEST,,,DHCPACK (not accept)/Send DHCPDECLINE,,,DHCPDISCOVER,

53、,,Select offer/send DHCPREQUEST,,,,,DHCPOFFER/Collect replies,,DHCPACK/Record lease, set timer T1, T2,,,,,DHCPOFFER/Discard offer,,,DHCPACK/Record lease, set timer T1, T2,,,,,DHCPOFFER,DHCPACK,DHCPNAK/Discard,,T1

54、expires/Send DHCPREQUEST to leasing server,,DHCPACK/Record lease ,set timer T!,T2,,,T2 expires/Broadcast DHCPREQUEST,,,,DHCPNAK/Halt network,Page 90,DHCP報文的格式,Page 91,DHCP報文的格式,Op:操作碼 (1=bootrequest ,2=bootreply)Ht

55、ype: 硬件地址類型 (1=10mb ethernet)Hlen: 硬件地址長度 (ethernet 為10)Hops: 客戶機設置為0,當使用多個DHCP Relay時可變Xid: 傳輸ID,在同服務器的交互中,由客戶機所選擇Secs: 客戶機所使用的地址,在最近一次地址獲取/地址更新后所經過的時間Flags: 最左邊一位是廣播位,其余各位置0,Page 92,DHCP報文的格式,Client IP address: 客戶

56、機在BOUND,RENEW或REBINDING狀態(tài)所使用,可以用來回應ARP請求報文Your IP address: 服務器給客戶機分配的IP地址Server IP address: bootstrap中使用的下一臺服務器的地址,由服務器在DHCPOFFER,DHCPACK中使用Gateway IP address: 使用的DHCP Relay的地址Client hardware address: 客戶機硬件地址Server

57、name: 服務器名字,缺省為空File: 啟動文件的名字,在DHCPOFFER報文中給出全名Options: 根據(jù)不同的報文而定,Page 93,DHCPDISCOVER/DHCPINFORM報文的格式,Page 94,DHCPREQUEST報文的格式,Page 95,DHCPDECLINE/DHCPRELEASE報文的格式,Page 96,DHCPOFFER報文的格式,Page 97,DHCPACK報文的格式,Page 98,D

58、HCPOFFER報文的格式,Page 99,,DHCP流程,客戶機在本網(wǎng)段內廣播DHCPDISCOVER報文已發(fā)現(xiàn)網(wǎng)絡中的DHCP服務器,DHCP Relay可將此報文廣播到其他的網(wǎng)段,,,,,,,,,,網(wǎng)絡1,網(wǎng)絡2,DHCPDISCOVER,,Page 100,DHCP流程,服務器向客戶機回應請求,并給出一個可用的IP地址。此地址并非真的被分配。但在給出此地之前，應當用ICMP ECHO REQUEST報文進行檢查。,,,,,網(wǎng)絡1

59、,,DHCPOFFER（192.168.0.1),,,,ICMP (192.168.0.1),Page 101,DHCP流程,如果收到多個DHCPOFFER報文,DHCP客戶機會根據(jù)報文的內容從其中選擇一個給與響應。如果客戶機之前曾經獲得過一個IP地址，她會將此地址寫在DHCPREQUEST報文的OPTIONS域的“REQUESTD IP ADDRESS”中發(fā)給服務器,,,,,網(wǎng)絡1,,DHCPREQUEST（192.168.0.1

60、),Reboot,192.168.0.1,Page 102,DHCP流程,當收到DHCPREQUEST報文后,服務器將客戶機的網(wǎng)絡的(網(wǎng)絡地址,硬件地址)同分配的IP地址綁定,在將IP地址發(fā)送給客戶機,,,,,網(wǎng)絡1,,DHCPACK（192.168.0.1),保留的地址池（地址池段1）（地址池段2）……,分配的地址(網(wǎng)絡地址1，硬件地址1） 分配的IP地址1…….,DNS服務器地址WINS服務器地址……,Page

61、 103,DHCP流程,當收到DHCPREQUEST報文后,如果發(fā)現(xiàn)其申請的地址無法被分配,則用DHCPNAK報文回應,,,,,網(wǎng)絡1,,DHCPNAK,,DHCPREQUEST(192.168.0.1),192.168.0.1已經被另外一臺設備所使用了,Page 104,DHCP流程,客戶機收到DHCPACK報文后,再對所有的參數(shù)進行一次最后的檢查,如果發(fā)現(xiàn)由地址沖突存在,則使用DHCPDECLINE報文回復服務器,,,,,網(wǎng)絡1

62、,,DHCPACK（192.168.0.1),,192.168.0.1,,DHCPDECLINE,Page 105,DHCP流程,如果客戶機放棄現(xiàn)在使用的IP地址,則她使用DHCPRELEASE報文通知服務器,服務器將此地址回收以備下次使用。,,,,,網(wǎng)絡1,,DHCPRELEASE,Page 106,DHCP流程,當客戶機的地址到達50%租用期（T1）時，客戶機進入RENEW狀態(tài)，使用DHCPREQUEST報文續(xù)約；當客戶機的地址

63、到達87.5%租用期（T2）時，客戶機進入REBINDING狀態(tài)，使用DHCPREQUEST報文續(xù)約；,,,,,網(wǎng)絡1,,DHCPREQUEST,Page107,目 錄,4.1 使用DHCP的原因4.2 DHCP原理4.3 DHCP工作流程舉例,Page 108,DHCP流程舉例,,,,,,10.77.2.1,10.77.11.10,客戶機,服務器,DHCP-RELAY,Page 109,DHCP流程舉例,Page 110,DH

64、CP流程舉例,Page 111,DHCP流程舉例,Page 112,DHCP流程舉例,Page 113,DHCP流程舉例,Page 114,DHCP流程舉例,Page 115,DHCP流程舉例,Page 116,本章主要通過對DHCP報文結構及流程的介紹,希望大家能夠建立起對DHCP協(xié)議的清晰概念,,小結,Page 117,第1章 PPP協(xié)議第2章 PPPOE協(xié)議第3章 Radius協(xié)議第4章 DHCP協(xié)議第5章 802.1X

65、原理,內容介紹,,Page118,前 言,IEEE802.1X標準是基于端口的網(wǎng)絡接入控制。該協(xié)議提供一系列的對接入到局域網(wǎng)中某個端口的設備進行基于端口的認證和授權方法，并禁止未通過認證和授權的設備和用戶對該端口的訪問。,Page119,目 錄,5.1 802.1X工作原理5.2 EAP和EAPOL5.3 802.1X協(xié)議運行過程5.4 802.1X配置實例,Page120,為什么需要802.1X？,,交換機,,,,Int

66、ernet,只要有物理連接，就提供所有服務,PCA,PCB,PCC,,,路由器,數(shù)據(jù)服務器,太容易訪問網(wǎng)絡資源了,Page121,802.1X的作用,,交換機,,,,Internet,沒通過驗證，就不提供服務,PCA,PCB,PCC,,,路由器,數(shù)據(jù)服務器,為什么我的網(wǎng)卡不能正常工作？,,,Page122,系統(tǒng)角色,Page123,受控端口和非受控端口,,,驗證者系統(tǒng),,,非受控端口,受控端口,,,,,未被授權的端口,,,LAN,

67、,,驗證者系統(tǒng),,,非受控端口,受控端口,,,,,授權的端口,,,LAN,Page124,端口控制模式,Page125,工作原理,,,,,請求者系統(tǒng),請求者PAE,,,驗證者系統(tǒng),,,驗證者PAE,LAN,驗證服務器系統(tǒng),驗證服務器,驗證者系統(tǒng)提供的服務,,承載在高層協(xié)議中的EAP報文,,,,,未被授權的端口,,Page126,目 錄,5.1 802.1X工作原理5.2 EAP和EAPOL5.3 802.1X協(xié)議運行過程5.

68、4 802.1X配置實例,Page127,EAP報文格式,Page128,請求和回應報文,用于驗證的信息,Page129,成功和無效報文,沒有Type和Type-Data字段,Page130,EAPOL報文格式,Version,Type,Packet Body Length,Packet Body ...,EAP報文被封裝在此字段內,Page131,EAPOL報文類型,Page132,EAPOL報文的二層報文頭,Page133,目 錄