IGMP協議原理與配置-有解無憂

組播架構

最后一條去選擇接收者的話要如何選擇，要根據什么協議這些都是需要一個具體規定的協議吧此時我們就需要用到IGMP了

IGMP（Internet Group Management Protocol）因特網組管理協議（是去管理IP組播成員的協議——接收者）是TCP/IP協議族中負責IP組播成員管理的協議，它用來在接收者和與其直接相鄰的組播路由器（最后一條路由器）之間建立、維護組播組成員關系，

接收端如何接受組播資料

接收者與路由器間需要交換哪些資訊？
接收者需宣告自己要接收哪個組的資料，
路由器需了解哪些組播組存在接收者，

人工配置這些資訊，有哪些問題？

實時性差，
靈活性差，
作業量大、易出錯，

IGMP

IGMP協議運行于主機與組播路由器之間，

IGMP協議的作用：

主機側：通過IGMP協議向路由器通告組成員關系，
路由器側：通過IGMP協議維護組成員關系，

IGMP V1的作業機制

普遍組查詢與回應，
回應抑制機制，

最后一條路由器會周期性地向子網內所有主機發送成員關系查詢資訊（60s）查詢哪些組存在
收到查詢資訊之后，主機會發送IGMP成員關系報告，表示希望加入組播組

此時假設RTA發了一個G1的查詢資訊下來，此時我三個主機都會收到這個查詢資訊，這個時候我各自的主機都會生成一個隨機時間（0-10s），假設A是4s，B是5s，C是6s，這個時候A就會在倒計時4s之內給RTA回復一個希望加入G1的回復資訊，此時B也在到技術吧，但是此時是不是沒有G2的查詢資訊，那此時B在這個時間段內就不會發送回復資訊，等倒計時結束之后會發送一個自己想要加入G2組的資訊，最后C在4s過去之后偵聽到A向RTA發送了一個想要加入G1組的資訊，那此時C就知道了我們里面有G1組了，我就不需要再發送IGMP報告了，因為對于RTA而言我只需要知道下面有一個G1組就可以了不需要知道哪個是屬于哪個組，所以C不用再發了

所以C不去發送IGMP報文我們就稱之為回應抑制機制

IGMP V1成員加入

主機申請加組，

新接入主機Client D想加入組播組G3，為了快速接收組播資料，不等待普遍組查詢報文，而立即發送G3的成員報告報文，RTA收到成員報告報文后，了解到本網段內出現了組播組G3的成員，一旦有G3的組播資料到達RTA，將向該網段轉發，

V1組成員離開

靜默離開

IGMPv1沒有專門定義離開組訊息，

當Client離開組播組時，將不會再對普遍組查詢報文做出回應，假設所有Client退出組播組，Client將不再對普遍組查詢報文進行回應，由于網段上不存在組播組的其他成員，RTA不會收到任何成員報告報文，則在一定時間（130秒=60*2+10，即組成員關系超時時間=IGMP普遍查詢訊息發送間隔 × 健壯系數 + 最大查詢回應時間）后，洗掉對應的組播轉發項，

查詢器選舉

RTA和RTB都是最后一跳路由器，兩個人都會發普遍組查詢報文，但是此時就會出現一個問題，對于ABC而言要回復誰

多臺路由器同時連接到同一接收端網路時，只需要有一臺路由器進行IGMP的查詢，

IGMPv1無查詢路由器選舉機制，其依賴于組播路由協議（PIM）在末端網路中選舉一個查詢器，

所以會存在多臺查詢器

IGMP V2（默認是使用版本2）

改進：

1.組成員離開

向224.0.0.2發送一個leave報文
發完之后RTA會給G2組地址發送一個特定組查詢（查詢2次，周期是1s）
要是兩次之后都沒收到回復，那就說明G2已經確定離開了（這里就2s吧，但是V1里面需要130s吧是不是優化很多）

在其他時間還是會60s發送普通組查詢

2.查詢器選舉

會有一個獨立的查詢器選舉機制
RTA與RTB都會接收到對方的普遍查詢組查詢
會依循IP地址最小的就會成為查詢器
在非查詢器上都會有定時器的（時間可以自己定制），一旦超過定時器的時間沒收到查詢器的查詢報文，就會重置查詢器

IGMPV1和V2比較

IGMPv1報文：

版本：包含IGMP版本標識，因此設定為1，
型別：普遍組查詢（0x11），成員關系報告（0x12），
組地址：普遍組查詢報文中，組地址為0；成員關系報告報文中，組地址為成員想要加入的組播組的地址，

IGMPv2報文：IGMPv2報文與IGMPv1報文略有不同，它取消了版本欄位，增加了最大回應時間欄位，

型別：相比于IGMPv1，IGMPv2新增了兩種報文：
- 特定組查詢報文（0x11）：查詢器向共享網段內指定組播組發送的查詢報文，用于查詢該組播組是否存在成員，
- 成員離開報文（0x17）：成員離開組播組時主動向路由器發送的報文，用于宣告自己離開了某個組播組，
最大回應時間：表示主機回應查詢回傳報告的最大時間，
- 對于普遍組查詢，最大回應時間默認為10秒，
- 對于特定組查詢，最大回應時間默認為1秒，
組地址：
- 普遍組查詢報文中，組地址設定為0，
- 特定組查詢報文中，組地址為需要查詢的組地址，
- 在成員報告或離開組的訊息中，組地址為需要報告或離開的組地址，

SSM模型中的新需求

只接收特定源發送的組播資料，

IGMPV3是去適用于特點源組播資料的

IGMPV3作業機制

周期性的發送查詢報文
客戶端都會發送成員關系報告，會指出希望加入或拒絕默寫組播的資料

include：收的
exclude：不收的

版本比較

二層中組播資料轉發的問題

組播資料在二層被泛洪，造成：

網路資源浪費，
存在安全隱患，

主機加入組播組需要向上游設備發送IGMP成員報告，這樣上游設備才可以將組播報文發送給主機，由于IGMP報文是封裝在IP報文內，屬于三層協議報文，而二層設備不處理報文的三層資訊，所以主機加組的程序二層設備并不知道，而且通過對資料鏈路層資料幀的源MAC地址的學習也學不到組播MAC地址（資料幀的源MAC地址不會是組播MAC地址），

這樣當二層設備在接收到一個目的MAC地址為組播MAC地址的資料幀時，在MAC地址表中就不會找到對應的表項，那么這時候，它就會采用廣播方式發送組播報文，這樣一來不但對網路資源造成的極大浪費而且影響網路安全，

交換機轉發資料幀的行為：