使用CGMP和生成樹拓撲更改重建組播條目

簡介

本檔案將討論Cisco Group Management Protocol(CGMP)如何在Cisco Catalyst交換器和Cisco IOS®路由器上運作，以在發生跨距樹狀目錄拓撲變更後重建CGMP的多點傳送專案。

必要條件

需求

思科建議您瞭解以下主題：

• 交換機、路由器和組播的基本操作

• 生成樹、CGMP和網際網路組管理協定(IGMP)的基本操作

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• Catalyst 3550版本12.1(9)EA1c

• Catalyst 2900/3500XL版本12.0(5)WC3b

• Catalyst 4000監督器引擎III版本12.1(11b)EW

• Catalyst 4000監督器引擎I/II版本7.2(2)

• Catalyst 6500監督器引擎Cisco IOS軟體版本12.1(11b)EX

• Catalyst 6500 Catalyst OS(CatOS)版本7.2(2)

• Catalyst 5500 CatOS版本4.5(13a)

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

CGMP和拓撲更改

本節逐步介紹在使用CGMP的VLAN上偵測到跨距樹狀目錄拓撲變更時，會發生什麼以及可能會發生什麼問題，以便限制多點傳播流量在所有連線埠上泛洪。如以下範例所示，本檔案所述的網路包含一台路由器、一台交換機和四台PC:

• 埠1 — 接收器PC 1

• 埠2 — 接收器PC 2

• 埠3 — 接收器PC 3

• 埠4 — 不是接收器PC 4

• 埠5 — 其他交換機（此交換機上沒有接收器或路由器）

• 埠48 — 運行IGMP和CGMP的Cisco IOS路由器

在本檔案中，假設接收方PC使用IGMP，且交換器執行CGMP。Cisco IOS路由器運行IGMP和CGMP，後者接收來自不同介面上影片伺服器的組播流。此介面傳送到IP組播組239.100.100.100。

穩定狀態

所有裝置啟動後，接收方PC已傳送組239.100.100.100的IGMP加入消息後，它們都將由CGMP新增到MAC地址01-00-5e-64-64表示的相應第2層組。

此清單顯示交換器上哪些連線埠（以粗體突出顯示）會接收通過Cisco IOS路由器的多點傳播流。

• 埠1 — 接收器PC 1

• 埠2 — 接收器PC 2

• 埠3 — 接收器PC 3

• 埠4 — 不是接收器PC 4

• 埠5 — 其他交換機（此交換機上沒有接收器或路由器）

• 埠48 — 運行IGMP和CGMP的Cisco IOS路由器

注意：Cisco IOS路由器也新增到組播組中，但由於它是源，所以它不會收到自己的資料包。

在每個查詢間隔內，Cisco IOS路由器都會傳送IGMP一般查詢（傳送到組播組224.0.0.1，因此會泛洪到所有其他元件）。 發生這種情況時，所有接收方開始為239.100.100.100組構建IGMP報告。接收器將此報告傳送回IP組播組239.100.100.100，第2層MAC地址為01-00-5E-64-64-64。由於此報告被傳送到組地址，因此所有接收器都會接收其他接收器傳送的報告，以及由第一個接收器傳送回的報告。這將觸發其他接收方PC取消其此組的報告。這意味著只為該組傳送一條CGMP加入消息，該消息帶有最先響應的PC的源MAC地址。這會持續很長時間，並且所有接收方PC都會收到影片廣播。

拓撲更改期間和之後

此時，另一台交換機在網路中觸發拓撲更改。根據CGMP規範，在收到拓撲更改後，交換機將清除通過CGMP獲知的所有組播條目。來自路由器的多點傳播流量會湧向交換器上的所有連線埠。

此清單顯示交換器上哪些連線埠（以粗體突出顯示）會接收通過Cisco IOS路由器的多點傳播流：

• 埠1 — 接收器PC 1

• 埠2 — 接收器PC 2

• 埠3 — 接收器PC 3

• 埠4 — 不是接收器PC 4

• 埠5 — 其他交換機（此交換機上沒有接收器或路由器）

• 埠48 — 運行IGMP和CGMP的Cisco IOS路由器

當流量湧向所有埠時，接收方PC不會發現任何差異，它們會繼續接收影片廣播。但是，由於流量會湧向所有埠，因此PC 4不是接收方，而另一台交換機現在也接收組播流，儘管它們沒有請求。此過程會一直持續，直到Cisco IOS路由器再次發出其定期IGMP一般查詢為止。在Cisco IOS路由器上，此設定的預設值為60秒（配置了IP IGMP查詢間隔）。

拓撲更改通知後兩個IGMP常規查詢

當Cisco IOS路由器發出其第一個IGMP一般查詢時，所有接收方PC都開始構建其239.100.100.100組的IGMP報告。其中一個（在本檔案中，它是PC 3）是第一個發回其IGMP報告的。由於交換機上尚未構建組播條目，因此所有PC都會收到該條目，其他接收方PC會取消其IGMP報告。Cisco IOS路由器收到該報告，然後傳送帶有接收方PC 3的源地址的後續CGMP加入消息。

交換機再次為組01-00-5e-64-64-64建立組播條目，並將埠3新增到該條目，因為這是CGMP加入資料包中的源地址。由於連線埠5是多點傳送路由器連線埠，因此也會新增到多點傳送群組中。因此，只有接收機PC3接收影片流，而PC1和PC2上的影片流保持靜止。

此清單顯示交換器上哪些連線埠（以粗體突出顯示）會接收通過Cisco IOS路由器的多點傳播流：

• 埠1 — 接收器PC 1

• 埠2 — 接收器PC 2

• 埠3 — 接收器PC 3

• 埠4 — 不是接收器PC 4

• 埠5 — 其他交換機（此交換機上沒有接收器或路由器）

• 埠48 — 運行IGMP和CGMP的Cisco IOS路由器

在IGMP查詢間隔結束時，Cisco IOS路由器傳送另一個IGMP常規查詢。收到查詢後，所有接收方PC都會為239.100.100.100組生成報告。但是，這次只有接收方PC 3和Cisco IOS路由器才收到來自其他PC的報告。（路由器埠會自動新增到每個組播組。）

由於接收機PC1和PC2沒有看到來自任何其他接收機的報告，因此它們都傳送自己的報告。隨後，Cisco IOS路由器發出包含各台PC的源MAC地址的CGMP加入消息，因此，它們將被新增並開始通過Cisco IOS路由器再次接收組播流。

此清單顯示交換器上哪些連線埠（以粗體突出顯示）會接收通過Cisco IOS路由器的多點傳播流：

• 埠1 — 接收器PC 1

• 埠2 — 接收器PC 2

• 埠3 — 接收器PC 3

• 埠4 — 不是接收器PC 4

• 埠5 — 其他交換機（此交換機上沒有接收器或路由器）

• 埠48 — 運行IGMP和CGMP的Cisco IOS路由器

組態已回復到原始穩定狀態，一切重新正常運作。這是所發生情況的細分：

1. 發生拓撲更改。

   提示：當主機埠中未啟用portfast時，每次主機重新啟動或連線到該埠/斷開該埠時，鏈路狀態的更改都會觸發VLAN中的拓撲更改通知。如果在拓撲更改時啟用了CGMP調試，則會顯示以下調試消息：

   CGMP SHIM: got short age timer

2. 所有埠均開始泛洪。

3. 傳送第一個IGMP常規查詢。

4. 泛洪停止。

5. 並非所有接收機都接收該多播流。

6. 第二個IGMP常規查詢被發出。

7. 新增所有接收器並再次接收組播流。

CGMP增強功能

由於PC的一分鐘（預設IGMP查詢間隔）組播流丟失並非總是可接受的，因此對運行CGMP的路由器和交換機進行了一些增強。

交換機和路由器之間的通訊

由於路由器是第3層裝置，因此通常不知道會發生生成樹和拓撲更改，所以網路中需要交換機向路由器發出此拓撲更改警報。定義了IGMP全域性休假消息以處理此問題。

此IGMP全域性離開消息是交換機可以傳輸的IGMP離開，請求離開組0.0.0.0。

為了確保路由器不超載IGMP全域性離開消息，當拓撲更改結束時，只有生成樹域中的根交換機負責傳送此IGMP全域性離開消息。

路由器行為

當路由器在執行Cisco IOS軟體的介面上收到此IGMP全域離開訊息時，會識別該介面上已發生跨距樹狀目錄拓撲變更，並執行以下操作來嘗試限制多點傳送接收者的多點傳送流量損失：

1. 在收到IGMP全域性離開消息後傳送CGMP批處理加入消息。路由器發出一則CGMP加入消息，其中自己的MAC地址作為該介面的IGMP快取中每個組播組的使用者源地址。通過傳送這些CGMP自加入消息，CGMP交換機自動為每個組建立一個條目，其中僅包含路由器埠。

   此清單顯示在CGMP批處理加入之後本文檔中使用的網路。僅將Cisco IOS路由器新增到組播組，如粗體所示。

   注意：雖然在本檔案的先前範例中，接收來自多點傳送路由器的流量的連線埠以粗體顯示，但此範例顯示交換器上新增到多點傳送群組的所有連線埠。

   • 埠1 — 接收器PC 1

   • 埠2 — 接收器PC 2

   • 埠3 — 接收器PC 3

   • 埠4 — 不是接收器PC 4

   • 埠5 — 其他交換機（此交換機上沒有接收器或路由器）

   • 埠48 — 運行IGMP和CGMP的Cisco IOS路由器

2. 傳送IGMP常規查詢。所有接收方都收到此IGMP常規查詢，並為他們加入的每個組生成報告。由於CGMP交換機已經為每個組建立了組播條目，並且只有路由器作為接收器，因此所有報告都只傳送到路由器。路由器發出後續的CGMP加入消息，將所有接收器新增到相應的組。

   在所有接收方已經傳送回其IGMP報告，並且路由器已經傳送了相應的CGMP加入消息後，所有接收方都應該被新增回組播組。

3. 10秒後（預設IGMP max-response-time），將傳送另一個IGMP常規查詢，以確保已新增所有接收器。重複此步驟幾次，以確保所有接收器重新加入組播組。

   所有本應新增到組播組的埠都已新增，如以下示例中粗體所示：

   • 埠1 — 接收器PC 1

   • 埠2 — 接收器PC 2

   • 埠3 — 接收器PC 3

   • 埠4 — 不是接收器PC 4

   • 埠5 — 其他交換機（此交換機上沒有接收器或路由器）

   • 埠48 — 運行IGMP和CGMP的Cisco IOS路由器

Catalyst交換器行為

在Catalyst交換器的範圍內，它們的行為存在一些差異。每台支援CGMP的交換機都按照本檔案CGMP和拓撲更改一節中所述的方式運行。但是，並非在所有平台上都實施了CGMP增強功能。下表列出Catalyst交換器及其對CGMP的回應方式：

	CGMP交換器	CGMP路由器	當生成樹通訊協定(STP)根時傳送全域性離開
執行Cisco IOS軟體的Catalyst 6500	否	Y	Y
執行CatOS的Catalyst 6500	否	否	否
Catalyst 5500、Catalyst 2926/2926G	Y	否	Y
Catalyst 4000監督器引擎I/II、Catalyst 2948G/2980G、Catalyst 4912G	Y	否	Y
Catalyst 4000/4500監督器引擎III/IV	否	Y	Y
Catalyst 2900XL/3500XL	Y	否	Y
Catalyst 2940	否	否	否
Catalyst 2950	否	否	否
Catalyst 2970	否	否	否
Catalyst 3550	否	Y	Y
Catalyst 3750	否	Y	Y

註：在搭載Supervisor引擎III/IV的Catalyst 4000/4500上，有關拓撲變更和CGMP的行為是可設定的。發出此命令，以將Catalyst 4000設定為當它不是生成樹根時傳送或不傳送IGMP全域離開訊息：

• ip igmp snooping tcn query solicit

注意：發出命令的此「no」形式以禁用它：

• no ip igmp snooping tcn query solicit

相關資訊

• 瞭解擴充樹通訊協定拓撲變更
• 園區網路中的組播：CGMP和IGMP監聽
• 在執行Catalyst OS的Catalyst交換器上，使用相同VLAN上的來源和接收器限制多點傳播流量
• Catalyst 4000 Cisco IOS軟體配置指南：瞭解和配置IGMP監聽
• 生成樹技術支援頁
• LAN 產品支援頁面
• LAN 交換支援頁面
• 技術支援與文件 - Cisco Systems