實驗拓撲

實驗需求

網絡拓撲、IP地址規劃如上圖所示；

R1、R2、R3、R4運行OSPF協議，打通網絡的單播路由；

R1、R2、R3、R4同時也是組播路由器，運行PIM-DM；

接收者加入組播組224.1.1.1，在R4上觀察IGMP信息；

組播源開始向組播組224.1.1.1發送組播數據，觀察Assert現象、Prune現象。

實驗步驟及配置

R1、R2、R3、R4完成接口IP地址的配置，并運行OSPF。R1的配置如下：

[R1]interfaceGigabitEthernet0/0/0
[R1-GigabitEthernet0/0/0]ipaddress10.1.12.124
[R1]interfaceGigabitEthernet0/0/1
[R1-GigabitEthernet0/0/1]ipaddress10.1.134.124
[R1]ospf1router-id1.1.1.1
[R1-ospf-1]area0
[R1-ospf-1-area-0.0.0.0]network10.1.12.10.0.0.0
[R1-ospf-1-area-0.0.0.0]network10.1.134.10.0.0.0
[R1-ospf-1-area-0.0.0.0]quit
[R1-ospf-1]quit

R2的配置如下：

[R2]interfaceGigabitEthernet0/0/0
[R2-GigabitEthernet0/0/0]ipaddress10.1.12.224
[R2]interfaceGigabitEthernet0/0/1
[R2-GigabitEthernet0/0/1]ipaddress10.1.23.224
[R2]interfaceGigabitEthernet0/0/2
[R2-GigabitEthernet0/0/2]ipaddress10.10.10.25424
[R2]ospf1router-id2.2.2.2
[R2-ospf-1]area0
[R2-ospf-1-area-0.0.0.0]network10.1.12.20.0.0.0
[R2-ospf-1-area-0.0.0.0]network10.1.23.20.0.0.0
[R2-ospf-1-area-0.0.0.0]network10.10.10.2540.0.0.0
[R2-ospf-1-area-0.0.0.0]quit
[R2-ospf-1]silent-interfaceGigabitEthernet0/0/2#G0/0/2口未連接OSPF路由器
[R2-ospf-1]quit

R3的配置如下：

[R3]interfaceGigabitEthernet0/0/0
[R3-GigabitEthernet0/0/0]ipaddress10.1.23.324
[R3]interfaceGigabitEthernet0/0/1
[R3-GigabitEthernet0/0/1]ipaddress10.1.134.324
[R3]ospf1router-id3.3.3.3
[R3-ospf-1]area0
[R3-ospf-1-area-0.0.0.0]network10.1.23.30.0.0.0
[R3-ospf-1-area-0.0.0.0]network10.1.134.30.0.0.0
[R3-ospf-1-area-0.0.0.0]quit
[R3-ospf-1]quit

R4的配置如下：

[R4]interfaceGigabitEthernet0/0/0
[R4-GigabitEthernet0/0/0]ipaddress10.1.134.424
[R4]interfaceGigabitEthernet0/0/1
[R4-GigabitEthernet0/0/1]ipaddress10.1.1.25424
[R4]ospf1router-id4.4.4.4
[R4-ospf-1]area0
[R4-ospf-1-area-0.0.0.0]network10.1.134.40.0.0.0
[R4-ospf-1-area-0.0.0.0]network10.1.1.2540.0.0.0
[R4-ospf-1-area-0.0.0.0]quit
[R4-ospf-1]silent-interfaceGigabitEthernet0/0/1
[R4-ospf-1]quit

R1、R2、R3及R4部署PIM-DM

R1的配置如下：

[R1]multicastrouting-enable#激活組播路由功能
[R1]interfaceGigabitEthernet0/0/0
[R1-GigabitEthernet0/0/0]pimdm#在接口上激活PIM密集模式
[R1]interfaceGigabitEthernet0/0/1
[R1-GigabitEthernet0/0/1]pimdm

R2的配置如下：

[R2]multicastrouting-enable#激活組播路由功能
[R2]interfaceGigabitEthernet0/0/0
[R2-GigabitEthernet0/0/0]pimdm#在接口上激活PIM密集模式
[R2]interfaceGigabitEthernet0/0/1
[R2-GigabitEthernet0/0/1]pimdm
[R2]interfaceGigabitEthernet0/0/2
[R2-GigabitEthernet0/0/2]pimdm

R3的配置如下：

[R3]multicastrouting-enable#激活組播路由功能
[R3]interfaceGigabitEthernet0/0/0
[R3-GigabitEthernet0/0/0]pimdm#在接口上激活PIM密集模式
[R3]interfaceGigabitEthernet0/0/1
[R3-GigabitEthernet0/0/1]pimdm

R4的配置如下：

[R4]multicastrouting-enable#激活組播路由功能
[R4]interfaceGigabitEthernet0/0/0
[R4-GigabitEthernet0/0/0]pimdm#在接口上激活PIM密集模式
[R4]interfaceGigabitEthernet0/0/1
[R4-GigabitEthernet0/0/1]igmpenable#在接口上激活IGMP

完成配置后，首先做個查看：

[R2]displaypimneighbor
VPN-Instance:publicnet
TotalNumberofNeighbors=2
NeighborInterfaceUptimeExpiresDr-PriorityBFD-Session
10.1.12.1GE0/0/0000800371N
10.1.23.3GE0/0/1002000251N

上面輸出的是R2的PIM鄰居，可以看到R2有兩個PIM鄰居，分別是R1及R2。確保所有的PIM路由器兩兩之間都建立起鄰居關系。

3.完成PC及組播源的配置

本實驗可以使用eNSP來模擬并且能夠直觀的看到實驗現象。在使用eNSP進行組播實驗時，組播接收者采用”終端“設備中的PC來模擬，而組播源則使用”終端“ 設備中的MCS來模擬：

組播接收者（PC）的IP地址配置如下：

組播源的IP地址配置如下：

現在，各臺設備都已經就緒了，我們主要分析以下幾個內容：

4.組成員加入組播組224.1.1.1

現在讓組播接收者加入一個用于測試的組播組224.1.1.1，一般組播接收者就是我們的電腦或者其他便攜設備，例如視頻的業務，在電腦上安裝一個視頻客戶端，打開客戶端進行簡單的操作就會觸發電腦發送IGMP成員關系報告，宣稱自己所要加入的組播組。

在eNSP中，PC作為組播接收者的配置如下，切換到組播選項卡，源IP填寫PC的IP地址10.1.1.1 ,目的IP地址填寫組播組地址224.1.1.1：

點擊“加入“按鈕，PC即開始發送IGMP成員關系報告消息申請加入組播組224.1.1.1。現在在最后一跳路由器R4上查看：

[R4]displayigmpgroup
InterfacegroupreportinformationofVPN-Instance:publicnet
GigabitEthernet0/0/1(10.1.1.254):
Total1IGMPGroupreported
GroupAddressLastReporterUptimeExpires
224.1.1.110.1.1.100140057

R4已經發現了組播組224.1.1.1內有一個組播成員10.1.1.1，但是由于現在R4還沒有收到組播數據，所以自然沒有組播數據轉發給接收者。

5.組播源開始發送組播數據觀察擴散過程、Assert機制

現在組播源開始向組播組224.1.1.1發送組播數據。在eNSP上模擬組播源的設備做如下操作（開始測試前，確保電腦上已安裝媒體播放器：VLC media player）：

在配置界面中切換到組播源選項卡，在文件路徑處選擇電腦中的一個視頻文件（FLV、MP4等格式），在組播組IP地址中填入224.1.1.1。點擊運行按鈕，這個組播源便開始播放視頻，視頻播放的過程中組播源會持續地向224.1.1.1這個組播地址發送組播流量，如果網絡配置正確的話，組播接收者（PC）能夠收到這些組播流量，并且在本地開始同步播放視頻。在eNSP中，當組播源開始播放視頻時，可以在組播接收者處點擊“啟動VLC“按鈕：

VLC啟動后，就能開始在接收者處看到正在播放的視頻：

上面的截圖中，左圖是組播源正在播放中的視頻，而右圖則是組播接收者處正在同步播放的視頻，這就是組播業務的直觀體現。

現在我們來分析一下數據流量的轉發過程。視頻開始播放時，組播流量開始從組播源泛洪出來，組播數據到達第一跳路由器R2，則R2創建組播路由表項（10.10.10.10，224.1.1.1）：

displaymulticastrouting-table
MulticastroutingtableofVPN-Instance:publicnet
Total1entry
00001.(10.10.10.10,224.1.1.1)
Uptime:0005
UpstreamInterface:GigabitEthernet0/0/2
Listof2downstreaminterface
1:GigabitEthernet0/0/1
2:GigabitEthernet0/0/0

在該表項中，上行接口朝向源，所以就是GE0/0/2口，而在開始時由于運行的是PIM-DM模式，因此R2將GE0/0/1及GE0/0/0接口都添加到下行接口列表中，然后將組播數據從GE0/0/0口和 GE0/0/1口都轉發下去。

隨后R1及R3都會收到R2轉發下來的組播數據，同樣的他們也是創建一個組播路由表項，然后將所有接口（除了RPF接口）都添加到下行接口列表中，并開始向下行接口發送數據數據。

在這個過程中，R1及R3都會向自己的GE0/0/1口轉發組播流量，一旦雙方在自己的GE0/0/1口上收到（10.10.10.10,224.1.1.1）組播組的數據時，他們就知道在這個LAN中有兩臺組播路由器在轉發數據，這將觸發Assert機制，R1及R3都去發送Assert消息，在R1或R2的GE0/0/1口上抓包可以看到：

看一下R1發送的Assert消息：

可以看到報文里包含組播組地址、源地址、優先級和度量值。R3發出的Assert消息類似，由于此時R1及R3都是通過OSPF學習到10.10.10.0/24網絡的，并且metric相等都是2，因此接口IP地址大的路由器，也就是R3會Assert勝出，由它繼續向10.1.134.0/24網絡來轉發組播組224.1.1.1的數據。

如此一來R1就不需要組播數據了，因此它會向上行接口發送一個Prune剪枝消息，將自己從組播樹上剪除，R1的組播路由表就變成：

[R1]displaymulticastrouting-table
MulticastroutingtableofVPN-Instance:publicnet
Total1entry
00001.(10.10.10.10,224.1.1.1)
Uptime:0019
UpstreamInterface:GigabitEthernet0/0/0

從上面的輸出可以看到，R1的（10.10.10.10,224.1.1.1）組播表項沒有下行接口。

R2的組播表項就變成：

[R2]displaymulticastrouting-table
MulticastroutingtableofVPN-Instance:publicnet
Total1entry
00001.(10.10.10.10,224.1.1.1)
Uptime:0027
UpstreamInterface:GigabitEthernet0/0/2
Listof1downstreaminterface
1:GigabitEthernet0/0/1

（10.10.10.10,224.1.1.1）表項中，下行接口列表只有一個接口了，也就是GE0/0/1口。這是因為它收到了R1發過來的剪枝消息。

R4在收到組播數據后，也是創建一個組播表項：

[R4]displaymulticastrouting-table
MulticastroutingtableofVPN-Instance:publicnet
Total1entry
00001.(10.10.10.10,224.1.1.1)
Uptime:0041
UpstreamInterface:GigabitEthernet0/0/0
Listof1downstreaminterface
1:GigabitEthernet0/0/1

然后將組播數據從GE0/0/1口轉發出去，如此一來接收者也就收到組播數據了。因此，最終網絡穩定下來之后，組播流量的傳輸路徑是這樣的：

6.組播成員離組、觀察Prune剪枝過程

現在，組播源仍然在不斷的發送組播流量，我們讓接收者離開組播組224.1.1.1。

由于接收者一旦離開組播組，R4的GE0/0/1口上關于224.1.1.1的組播組就沒有成員了，因此它將接口GE0/0/1從自己的（10.10.10.10,224.1.1.1）組播表項的下行接口列表中去除，如此一來下行接口列表也就空了，R4知道自己不再需要224.1.1.1的組播數據，于是它向上行接口GE0/0/0發一個Prune剪枝消息，請求將自己從組播樹上剪除。

R3收到這個剪枝消息后，將自己的GE0/0/1口從（10.10.10.10,224.1.1.1）組播表項的下行接口列表中去除，然后它發現接口列表空了，于是也發現自己不再需要組播數據了，因此向上行接口發送Prune消息，此刻R3的組播路由表如下：

displaymulticastrouting-table
MulticastroutingtableofVPN-Instance:publicnet
Total1entry
00001.(10.10.10.10,224.1.1.1)
Uptime:0020
UpstreamInterface:GigabitEthernet0/0/0
R2收到R3發出的Prune消息后，其組播表如下：
displaymulticastrouting-table
MulticastroutingtableofVPN-Instance:publicnet
Total1entry
00001.(10.10.10.10,224.1.1.1)
Uptime:0004
UpstreamInterface:GigabitEthernet0/0/2

下行接口列表為空，因此直接將源發送過來的組播數據丟棄，不從任何接口轉發。

7.組播成員再次加組，觀察Graft嫁接過程

經過前面的步驟，雖然組播源仍然在不斷的向224.1.1.1發送組播數據，但是由于網絡中不存在任何的組成員，因此組播流量被R2直接丟棄。

現在我們再次讓組播接收者加入組播組224.1.1.1。PC發送IGMP成員關系報文，R4在收到這個報告之后意識到接口GE0/0/1下出現了組播組224.1.1.1的成員，于是將GE0/0/1接口添加到（10.10.10.10,224.1.1.1）表項的下行接口列表中，并向R3發送一個嫁接Graft消息：

這個消息是一個單播包，R3收到之后將接口GE0/0/1添加到組播表項的下行接口列表，并向R4回送一個Graft-ACK報文以作確認。同時R3向自己的上行PIM鄰居R2發送一個Graft消息。R2在收到這個消息的時候，也是將收到該消息的接口GE0/0/2添加到（10.10.10.10,224.1.1.1）表項的下行接口列表，隨后開始向該接口轉發224.1.1.1的組播流量。自此，組播樹又重新構建完成。

審核編輯：湯梓紅