成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

組網基礎之深入解析二層組播

網絡 網絡管理
所謂二層組播,即數據幀的轉發是面向二層的,根據組播MAC地址來決定數據幀的轉發方向,而三層組播,即所謂的IP組播,則根據三層組播地址,即組播IP地址來進行數據幀的轉發。

二層組播相關協議包括IGMPGMRP協議。讓我們從分析組播MAC地址開始,逐步而深入的了解二層組播。

組播MAC地址

所謂組播MAC地址,是一類邏輯的MAC地址,該MAC地址代表一個組播組,所有屬于該組的成員都接收以該組對應的組播MAC地址為目的地址的數據幀。

注意的是,組播MAC地址是一個邏輯的MAC地址,也就是說,在網絡上,沒有一個設備的MAC地址是一個組播MAC地址。組播MAC地址跟單播MAC地址(物理MAC地址)的區別是,組播MAC地址六個字節中,***字節(第六字節)的***位為1,而單播MAC地址則為0,如下圖所示:

為了更進一步了解組播的概念,我們先從MAC層的數據幀接收過程說起。

MAC層數據幀的接收

在網卡的內部保留一張接收地址列表(可以理解為一個可讀寫的隨機存儲器),其中至少有兩個MAC地址,即網卡的物理MAC地址和全1的廣播MAC地址。每當計算機想接收一個組播數據,也就是說要加入一個組播組,那么上層軟件會給網絡層一個通知,網絡層做完自己的處理后,也會發一個通知給數據鏈路層,于是,數據鏈路層根據網絡層想加入的組播組的組地址(一般是一個組播的IP地址),根據一定的規則映射為一個組播的MAC地址,然后把該MAC地址加入接收地址列表。

每當數據鏈路層接收到一個數據幀的時候,就提取該數據幀的幀頭,找出目的MAC地址,跟接收地址列表中的地址項目比較,如果在列表中遇到一個地址,跟該數據幀的目的MAC地址是相同的,就停止比較,接收該數據幀,并把該數據幀放到上層協議對應的接收隊列中;如果在整個接收列表中沒有找到一個匹配的MAC地址,則丟棄該數據幀。

現假設接收到的數據幀是發給自己的單播數據幀,于是該數據幀的目的MAC地址就是自己的硬件地址。數據鏈路層接收到該數據幀,跟接收列表中的地址比較,***次比較就會通過,因為接收地址列表中的***個MAC地址就是自己的硬件地址。所以在任何情況下,發給自己的數據幀一定能接收下來;

假設接收到的數據幀是一個廣播數據幀,則在比較的時候,***一項是匹配的,因為接收地址列表中肯定包含一個廣播的MAC地址,這樣就保證了任何廣播數據報都會被正確接收;

假設上層軟件想接收組播組G的數據,經過一番映射到數據鏈路層之后,數據鏈路層會在自己的接收數據列表中添加一項組播組G對應的MAC地址,假設為MAC_G,當計算機接收到一個數據幀,該數據幀的目的地址為MAC_G的時候,該數據幀會被接收并傳遞到上層,因為接收列表中有一項MAC_G記錄。

組播轉發表

在前面交換機的轉發方式一節中講到,交換機在轉發組播數據包的時候,也是根據一個轉發表來進行的,但跟單播轉發表不同的是,該組播轉發表對應的出口不是一個元素/端口,而是一組元素/端口,即一個出口列表。在轉發數據的時候,交換機根據組播數據幀的目的組播地址查找組播轉發表,如果在組播轉發表中查不到相應的轉發項,則把該組播數據幀當做廣播數據幀處理,向所有端口上轉發該數據幀(如果實現了VLAN,則僅僅向接收端口所屬同一個VLAN的端口上轉發);如果能查找到一個結果,則結果肯定是一個接口列表,于是,交換機把這個組播數據報復制成許多份,每份提交到一個出接口,從而完成數據的交換。

需要注意的是,這個組播轉發項不像單播那樣,是通過學習的方式獲得的(在處理單播數據的時候,交換機每轉發一個數據幀,會進行相應的學習過程,學習到一個單播轉發項),而是通過一些二層的組播協議獲得的,這些流行的組播協議有IGMP(Internet Group Management Protocol, 因特網組管理協議),GMRP(GARP Multicast Register Protocol,GARP組播注冊協議,GARP- General Attribute Registration Protocol)等。下面部分詳細解釋每一種二層組播協議。

二層組播協議

 

上面我們提到,用于轉發組播數據幀的組播轉發項不是通過學習獲得的,而是通過一些其他的組播協議,比如IGMP窺探,GMRP等協議獲得的。至于為什么不能通過學習獲得,是因為學習過程是分析一個數據幀的源地址,但組播地址在任何情況下不可能出現在源地址的位置(因為組播MAC地址是一個邏輯的MAC地址,網絡上沒有一個終端的MAC地址是一個組播MAC地址)。

下面我們分析二層組播協議,這些協議在構建組播網絡的時候,有不可替代的重要地位。尤其是將來的流媒體應用會很廣泛,在這種情況下,二層的組播將是必然的要求。

IGMP協議

 

在講述IGMP窺探之前,先看一下IGMP協議,理解了IGMP協議,IGMP窺探就很容易了。

一般情況下,組播數據是從路由器的上游流下來的,而組播的接收端一般位于路由器的下游,典型的情況是,路由器通過一個以太網口連接企業網,另外通過一個串口連接Internet。組播數據源,比如流媒體服務器一般位于Internet上,組播數據流通過路由器到達企業網上的數據接收端。這種情況下,流媒體服務器是長時間工作的,也就是說,一天24小時,一周7天都在不停的發送媒體流信息,相當于電視頻道。但企業網絡中的數據接收端卻不是這樣,只有有限的時間接收端才接收數據,其他時間都是不接收數據的。這樣,在企業網上沒有數據接收端的時候,如果路由器也把大量的媒體流信息發到企業網內部,必然會浪費大量的資源,理想的情況是,如果企業網上沒有數據接收端,則路由器就不轉發媒體流,但如果只要有一個接收端,路由器就必須把媒體流引入企業網。這樣必須有一種機制來保證路由器對企網上的數據接收端有一個清楚的了解,什么時候網絡上有數據接收端,什么時候沒有數據接收端,這種機制就是IGMP協議。

從上面的分析中,我們可以看出IGMP協議是數據接收端和路由器之間的交互協議,數據接收端使用該協議來通知路由器,自己是否想接收組播數據流。如果想接收的話,接收哪個組播組的數據流。

一般情況下,存在兩種類型的IGMP消息:組成員報告和組成員查詢,其中組成員報告消息由計算機發出,用來告訴路由器,自己想加入某個組播組,而組成員查詢消息則由路由器發出,用來查詢網絡上是否存在相應組的成員。一個指導性的原則是,只要網絡上有組播組的數據接收端,不管該接收端的數量是多少,路由器必須把該組播組的數據轉發到網絡上。

IGMP消息也是通過組播地址發出的,在IGMP加入消息中,該組播地址(IGMP消息的目的地址)就是該計算機想加入的組播組的組地址。比如,計算機想加入224.0.0.2這個組播組,則該計算機發出的IGMP加入消息的目的IP地址就是224.0.0.2。這樣當路由器接收到該組播消息后,就知道網絡上有一個主機,該主機想接收到組播組224.0.0.2的數據,于是,每當從上游接收到目的地址是該組地址的數據的時候,就把該數據包向企業網上轉發。

還有一類消息就是組播組成員查詢消息。在IGMP協議***版中,沒有規定主機的離開消息,即如果一個主機不想接收某一組播組的數據了,它也不會通過某種消息通知路由器,而是靜悄悄的離開該組播組。這樣如果路由器不采取某種措施來掌握網絡上組播組接收端的數目情況,就會產生問題,假設網絡上所有的主機都不想接收組播數據了,根據IGMP協議***版,這些主機不會通知路由器,而是不做任何處理。這樣路由器不知道這些原來接收組播數據的主機現在已經不接收數據了,而且還以為網絡上有一大批的接收端,于是仍源源不斷的發送組播數據,這樣必然浪費帶寬。而引入了組成員查詢消息后,路由器可以每隔一段時間發出該消息,用來查詢網絡上還有沒有主機在接收組播數據。注意的是,該查詢消息跟成員加入消息一樣,采用的目的IP地址也是查詢的組的組播IP地址。假設路由器想查詢245.2.2.1這樣一個組播組是否還有成員,發出的查詢消息的目的IP地址就是245.2.2.1。當網絡上接收該組播組數據的成員接收到這個查詢消息后,就發出一個響應,該響應還是一個組播組成員加入消息。這樣只要路由器接收到一個這樣的響應,它就知道網絡上必然還有終端在接收數據,于是不能停止轉發。但路由器發出查詢消息后,一段時間內沒有接收到任何響應,它就判斷網絡上沒有了數據接收端,于是停止轉發組播數據。

到此為止,IGMP協議的一些細節已經介紹完畢,接下來介紹IGMP窺探。需要注意的是,IGMP協議是三層協議,而IGMP窺探則是二層組播協議,但它利用了IGMP的三層特性。注意,IGMP協議是運行在交換機上的一種協議,它使用該協議來形成轉發組播數據的組播轉發表。

下面是啟動了IGMP窺探的交換機工作過程:

(1) 交換機從每個端口上監聽接收到的數據幀,如果是單播數據幀就按照通常的轉發方式進行轉發,是組播數據幀則進行下一步處理;

(2) 如果接收到的數據幀是組播數據幀,則分析該組播數據幀的協議類型字段,看是否是IP協議,如果不是,則按照通常的方式轉發(這時候可能查詢組播轉發表轉發,如果沒有查到結果,則向所有端口上轉發);(3) 如果是IP協議數據,則進一步判斷該數據是不是一個IGMP加入消息或IGMP查詢消息。如果不是,則進行通常的組播數據發送,否則轉下一步;

(4) 如果是一個IGMP加入或查詢消息,則該交換機就可以判斷,在接收到該數據幀的端口上一定連接一個組播數據接收端,該接收端想接收IGMP加入消息中目的地址所在的組播組數據。于是,交換機就檢查組播轉發項,看對應的組播MAC地址有沒有在組播轉發項中出現。如果出現了,則把接收到該數據幀的接口加入組播轉發項對應的接口集合,如果沒有出現,說明該組播轉發項還沒有創建,于是創建一個組播轉發項,該轉發項的組播地址是IGMP消息的目的IP地址的影射MAC地址,接口列表初始化為接收到該數據幀的接口,接下來繼續按照通常的過程轉發該數據幀。

到此為止,IGMP窺探的具體工作過程已經明了,可以看出,這種協議***的一個缺點就是效率較低,交換機需要分析每個組播數據幀,看該數據幀是否是組播數據幀,如果是,繼續看是否是IP數據幀,如果是,繼續看是否是IGMP加入消息等等。

GMRP協議

 

當主機不支持IGMP協議的時候就無法實現窺探。我們考慮能不能開發一種專門的針對組播的協議,該協議可以高效的完成其他組播協議完成的任務。

這就是GMRP協議。該協議需要計算機網卡和交換機一起工作,因此需要計算機網卡的支持。由于該協議是一個較新的協議,故大多數網卡都沒有支持,但作為一種標準的協議,將來的網絡設備都會支持。

該協議的運行過程很簡單,想接收組播數據的計算機只要告訴連接的交換機,它想接收哪個組的組播數據即可。交換機接收到通知后,就創建相應的組播轉發項,把接收到組播請求的端口加入組播轉發項中。當計算機不再想接收組播數據了,只簡單的告訴交換機就可以了,交換機接收到通知后,就從組播轉發項中把相應的端口刪除掉。

總結

 

二層組播的一些基礎概念就講解完了,在這些內容中,組播MAC地址,組播和單播數據的接收過程以及三種組播協議是重點。這些內容也是學習后續內容(比如三層組播路由協議)的基礎,在實際中,這些組播概念也是應用得最多的。  

【編輯推薦】

  1. 如何實現端口靜態添加組播MAC地址
  2. 淺談無線網絡實施MAC地址欺騙
  3. Cisco IOS:了解以太網MAC地址
  4. 思科交換機設置技巧:MAC地址
責任編輯:佚名 來源: 論壇轉載
相關推薦

2011-03-09 17:33:53

2011-04-13 13:56:00

組播CGMPIGMP

2018-11-04 05:00:36

組網技術二層網絡數據中心

2009-12-16 14:28:53

路由交換技術

2010-01-07 16:15:57

二層交換機

2011-06-01 10:39:32

交換

2011-06-01 10:39:25

IP交換

2011-06-01 10:39:40

交換網橋交換機

2011-06-01 09:27:03

交換

2011-06-01 10:39:36

交換交換機根橋

2011-03-09 15:13:26

組播MAC地址

2010-01-11 17:35:07

二層交換機三層交換機

2011-04-19 11:27:40

VLAN

2011-03-14 17:50:34

PIM-DM

2010-08-05 13:04:05

路由器

2011-03-14 17:38:31

PIM-SM

2011-08-04 16:49:32

二層交換分組移動回程

2013-01-17 16:11:11

數據中心交換機網絡虛擬化

2012-11-01 11:02:44

2025-05-29 08:15:00

網絡網絡排障二層網絡
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 欧美日韩综合一区 | av在线免费网| 亚洲激情自拍偷拍 | 男女羞羞网站 | 手机看片1| 无码一区二区三区视频 | 久久久精品一区二区三区 | jlzzxxxx18hd护士| 日日干日日 | 久久丝袜视频 | 亚洲福利在线观看 | 亚洲一区二区视频 | 中文字幕av在线一二三区 | 黄色成人国产 | 国产精品69毛片高清亚洲 | 国产区视频在线观看 | 国产成人高清视频 | 国产专区在线 | 欧美日韩亚洲系列 | 久久久精品在线 | 在线欧美一区二区 | 欧美一区二区三区免费在线观看 | 午夜视频一区二区 | 亚洲免费高清 | 欧美一极视频 | 99热在这里只有精品 | 欧美1页 | 国产伦精品一区二区三区照片91 | 欧美一区2区三区3区公司 | 免费观看黄a一级视频 | 美女高潮网站 | 91精品久久久久 | 欧美国产日本一区 | 精品99久久久久久 | 国产成人精品一区二区三区四区 | 精品视频在线一区 | 国产精品高潮呻吟久久aⅴ码 | 人人干人人干人人 | 精品国产乱码久久久久久闺蜜 | 日韩精品久久久久 | 一区精品视频在线观看 |