RP的選舉

1 static RP selection 靜態， 公有方法，支援pimv1 pimv2

2 BSR bootstrap router 公有方法，只支援pimv2

3 AUT0 rp cisco 私有，支援PIMV1 PIMV2

1 static

ip pim rp-address 4.4.4.4 全網所有路由器都要配置

命令格式

Ip pim rp-address [rp ip address ] [acl num] [override]

1 static RP 不需要依賴於任何的組播路由協議，而是手動的在路由器上配置，

2 該命令在全網所有的組播路由器上都需要手動配置，包括RP自己本身

3 RP地址所在的介面不需要執行組播路由協議，靜態的無所謂，是手動指定的

4 ACL用於限制RP為哪些組地址進行服務，//如果什麼都不加那就代表為所有組服務

5 override 用於讓static RP 優於動態RP， （預設情況下是）auto>BSR> static

6 static RP 無法設定備份RP，同一個組只能設定一個可以工作的RP，

Show ip pim rp mapping //檢視RP表項

clear ip pim rp-mapping //清空重建 RP表項

R2(config)#ip pim rp-address 2.2.2.2 1 override
R2(config)#access
 
-list 1 per 239.1.1.1

此時就代表了R2這臺RP，只會對239.1.1.1 這個組有效

那麼此時讓PC加組，但不是加的這個組

pc(config-if)#ip igmp join-group 224.1.1.1

再用源去傳送資料

可以說，這輩子都別想通了，

源向224.1.1.1 ,239.1.1.1 都發送了流量，但就是不通，為什麼？

很好理解吧，

組成員想要的是224.1.1.1 ,而此時RP路由器需要指定的組是239.1.1.1

肯定是不可以的，因為都沒有在一個組內，肯定不OK呀，

其實手動靜態的RP，配置和理解 起來都很簡單、對吧，但和靜態路由一樣，很容易出錯

2 BSR 自動選舉

Boot strap router

主動申請我想當BSR

Ip pim bsr-candidate [int] [hash mask length] [priority value]

1 BSR 介面必須要執行PIMV2， 依賴於224.0.0.13這個地址來進行選舉的

2 BSR 介面與RP介面中可以相同

3 hash mask length 用於完成C-RP的輪詢選擇，預設是0 即沒有輪詢

4 priority value 用於設定該BSR的優先順序，便於多個BSR之間開啟主備關係。

兩種角色

BSR 自舉路由器,負責收集RP資訊的

CRP candidate 候選者RP,就是想當RP的裝置

BSR的工作過程

需要先設定某一臺的某一個介面設定為BSR，當然這個介面要開啟PIMv2 可以有多個，實現備份，當然也可以 BSR 和CRP共用，一個介面身兼數職，都沒有問題

1 BSR週期性的產生bootstrap message （60S/次）,傳送給自己的所有鄰居，鄰居收到後，幫助BSR產生相同的訊息通告給各自己的鄰居，從而使得訊息能到達全網，

2 CRP在收到訊息後，獲了BSR的資訊，因此產生單播的CRP advertisementmessage 傳送給BSR,BSR收到後在bootstrap message當加新增CRP 資訊發給全網組播路由器

3 C-RP-advertisement Iith週期性的從CRP傳送到BSR,預設週期為60S，如果150S內BSR沒有收到該CRP的下一個通告，則BSR認為該CRP已經死了，在後續的BSR訊息中將刪除該CRP的資訊，

4 因為BSR的所有訊息都依賴於PIMV2 message 因此BSR只支援PIMV2

其實就如圖所示的這麼一個過程。

如何保證全網都知道RP是誰呢？因為傳送的地址是224.0.0.13，是所有執行PIMV2的路由器都可以監聽的

BSR的主要作用就是負責收集所有的CRP資訊，然後再將這些資訊通告給全網路由器，就是採集資訊用的

BSR訊息的產生

1 有兩個原因，一是固定的週期性更新，大概60S/次，二是觸發更新，即收到了CRP-advertisement 後立刻傳送下一個BSR message

2 在BSR message 裡可以攜帶一個組的多個CRP 資訊，BSR不會幫助其它組播路由器完成選擇過程，而是全網組播路由器收到訊息後，按照共同的規則來選擇

3 BSR的對於CRP資訊的獲知，資訊源是CRP，但是其它組播路由器對於CRP資訊的獲知，）源是BSR，（這句話也很好理解 ，因為CRP會以單播的形式傳送通告訊息給BSR，而只有BSR才會將攜帶了CRP資訊的bootstrap訊息泛洪全網）

例項

我們讓R3成為BSR 並且是通過BSR 的方式進行配置的

R3(config)#ip pim bsr-candidate loopback 1 

然後它就會向外傳送bootstrap 訊息，傳送源是23.0.0.3 目標地址是224.0.0.13PIMv2 的組播地址

而現在並沒有RP 給它回覆，

而且當R2收到這個bootstrap 訊息之後也會進行向外擴散

源是12.0.0.2 目標是224.0.0.13 BSR 是3.3.3.3 ，多麼的無私啊~（眼自己毛關係都沒有）

現在年R1成為RP ,

並且是自己的環回口(注意，此時的Loopback 介面也必須要開啟Pimv2)

ip pim rp-candidate lo 1

可以加group-list 就沒是ACL ,來限制為哪些組轉發流量

Interval 延時

Priority 優先順序

當然也可以什麼都不加

輸入完成後，R1會馬上回復BSR 一個訊息，candidate-rp-advertisement 訊息，說 RP是1.1.1.1 組是224.0.0.0/4

並且是以單播形式發的，看目標地址是多少？3.3.3.3對吧，直接發給的BSR

而BSR收到這個訊息之後，會繼續再向外發送一個bootstrap訊息，並且這個訊息中包含了RP的資訊

RP 0 就是代表第一個，這是老外的一個思維

hold time 是150

此時來看一下 rp mapping

在R1上可以看到，RP 是1.1.1.1

另外這個information 的源是3.3.3.3 ，是一個bootstrap訊息，

並且此時可以讓PC加組，就會形成*,G表項

S,G表項呢？

只有當產生組播資料時，才會產生S,G表項

多臺BSR選舉

BSR可以有多臺，並且他們會根據priority 的值來選舉出誰是主BSR

越大越優，取值範圍是0-255

現在R2啥也不是，我們讓它成為主BSR，把priority 設定為100, 比R3的0 要大，來看下效果

R2(config)#ip pim bsr-candidate lo 1 0 100

可以看到，原有的BSR現在變成的2.2.2.2

BSR 的選舉規則

1 首先比較BSR priority 選擇優先順序最大的做為主BSR，預設優先順序為0

2 如果priority 相同，則直接 比較BSR介面IP ,選擇地址大的做為主BSR

3 一旦選出主BSR，備份BSR 則不再發送BSR message

4 如果120S內沒有收到主BSR 發出的訊息，則備份BSR 接替開始工作

R2發出自己的bootstrap訊息，

優先順序為100

那麼R3，也就是原有的BSR收到這個訊息後會做出怎樣的動作呢？

收到由R2 發來的這個訊息，並沒有看到有什麼反應，而是直接將這個主權拱手相讓了，

因為priority 真的比不過人家

CRP的選舉

CRP也可以有多臺，但是他們對比的是優先順序越小越優，預設是0

那這樣兒的話，我們先把R1的priority 改大一些，

再將R2 設定的CRP

來看看效果

R1(config)#ip pim rp-candidate lo 1 priority 10
R2(config)#ip pim rp-candidate lo 1   //後面不加引數 ，預設就是0

R1上再檢視RP，現在就是2.2.2.2 了，

但是在rp mapping 中可以看到兩個

R3上可以收到來自於R2發往224.0.0.13的組播bootstrap訊息，

顯示了此時有兩個RP

0 ——2.2.2.2

1 ——1.1.1.1

但此時需要注意的是，

現在的RP 是2.2.2.2 不再是1.1.1.1 了

那麼R2就是共享樹的頂端，

也就意味著R1將看不到*，G表項，在沒有收到組播資料時，

CRP的選舉原則

1 針對相同的CRP才能進行比較選擇,為相同的組播地址提供服務的RP

2 首先比較CRP priority 選擇優先順序小的一方做為主RP，優先順序預設是0

3 當優先順序相同時，比較HASH 運算結果，選擇結果大的一方做為主RP

4 HASH執行需要 用到的3個變數，[C-RP, GROUP , HASH mash length長度]

1) 當hash mask length 為0 時，等於整個組地址都不能與hash 運算,此時hash結果只取決於RP地址本身，因此每個組選擇的RP都是相同的，

2) 當hash mask length 不為0 時，G 地址被掩碼掩蓋的bits 需要參與hash 運算，此時hash 結果既受到RP地址的影響，也受到了G地址的影響，因此導致了不同的組地址可能自動選擇不同的CRP,，使CRP之間既能備份又能分攤

3) 檢查方法，show ip pim rp-hash [group address]

Hash 掩碼長度

說白了0-32位的掩碼，有多少位掩碼需要進行hash 運算

如224.1.1.1 /32就是32位需要能與運算

Rp ,group 掩碼長度 三個值一起進行hash 運算

而如果掩碼長度為0時，那麼也就意味著所有的組都沒有意義，所有的組不參與hash 運算，每個組都一樣。RP為所有的組服務就可以了

可以看到現在的mask 是0.0.0.0 是0 時，組根本就不參與hash

也就意味著所有的組都是一樣的hash

而現在我們將掩碼長度改為32,看效果

優先順序我不動，直接改BSR的掩碼長度即可

R3(config)#ip pim bsr-candidate lo 1 32

//設定掩碼長度一定是在設定BSR時設定

首先，看到兩個不同的組，他們的掩碼長度都是32位的，也就意味著32位的掩碼都需要進行hash運算，而這個運算結果肯定也是不一樣的，

並且，地址不同，RP的身份也有可能不相同，

如圖1 顯示的是R2 為224.1.1.0 做為RP服務

圖2 中顯示的是R1 為224.1.1.10 做為RP服務

這也就實現了分攤

不同的RP 形成不同的共享樹頂端，形成不同的*,G表項

此時如果將掩碼長度設定為31位呢？

那就是每兩個連續的地址使用一個RP，

0,1 2,3 4,5 兩個地址共用一個RP

這一點如果不明白的話，可以回看一下子網掩碼劃分，回顧一下去吧~

但是需要注意的是組播中沒有網路地址和 廣播的概念，所以0算是第一個

Auto RP

1 Auto RP 的工作依靠真正的組播資料包來完成資訊的互動，不依賴於任何的message ，因此auto RP 既支援PIMV1也支援PIMv2

2 Auto RP工作依賴於兩個組地址224.0.1.39 和224.0.1.40

3 以上兩個組地址不是保留組播地址，因此可以為其構建組播路由表項，並且轉發組播資料

4 構建組播路由表要麼是依靠dense mode , 要麼是依靠sparse mode 規則

而此時因為RP資訊本就不存在，因此組播路由表在構建時只能依靠dense mode

Auto RP 的兩種角色

1 MA （mapping agent 對映代理）--類似BSR裡的BSR

2 CRP 候選者 RP

工作原理

由MA來收集CRP 資訊，

另外MA既負責收集資訊，還負責選舉CRP

這一點和BSR裡的BSR不一樣，只能收集，

可以說權力大大的

1 所有的CRP都會把自己的訊息傳送到224.0.1.39這個組播地址，

2 誰能監聽這一個組呢？只有MA可以監聽，

3 收到了這些CRP的訊息之後，MA負責選舉，選出來一個最優的，然後傳送到224.0.1.40

4 所有的CRP都會監聽這個224.0.1.40，

從而完成整個過程

224.0.1.40，這個地址還記得嗎？

所有的組播路由表中都會預設存在著這麼一個玩意，

今天終於見到了，就是幹這個用的。明白了吧

熟悉吧，嘿嘿~

首先，想要往這兩個組地址裡傳送資料，再由於我們現在是spares 模式，就必須要有RP

而我現在就是要選擇PR,

那要怎麼辦呢？

矛盾了是吧~

解決方法有

三種

第一種

全網組播路由器單獨為224.0.1.39 和224.0.1.40 設定靜態RP 用sparse mode 來構建組播路由錶轉發這兩個組的資料

Ip pim rp-address x.x.x.x 10 override

Access-list 10 per 224.0.1.39

Access-list 10 per 224.0.1.40

但這樣寫就太麻煩 了，

並且沒有辦法為這兩個組進行備份

第二種

全網組播路由器介面全部執行ip pim sparse-dense-mode 用dense mode 來構建組播路由錶轉發這兩個組的資料(這什麼意思呢，如果此時有RP就用sparse 發資料，如果沒有RP就用DENSE模式泛洪資料),先用sparse 後用dense

但是如果此時RP失效後，肯定使用DENSE 模式，而DENSE 模式最大的特點就是泛洪，

如何保證不泛洪呢？

這時需要 另外一條命令 no ip pim dm-falback 防止這種情況的發生

防止從SPARSE 回退到DENSE 模式，防止泛洪，即便是斷網。

第三種

全網所有組播路由器介面 全部執行ip pim sparse-mode 並且全域性設定命令

ip pim autorp listener

該命令可以讓所有的介面自動對224.0.1.39 和224.0.1.40按照dense mode 來構建組播路由表

該命令在某些IOS環境下屬於隱藏命令

我們先使用第三種，來看一下

R1(config)#ip pim autorp listener
R2(config)#ip pim autorp listener
R3(config)#ip pim autorp listener

這條命令和auto-rp的選舉沒有真正關係，它的作用就是構建組播路由表，來實現可以向224.0.1.39和224.0.1.40傳送資料用的。僅此而已

然後我們將R2做為RP

輸入一條命令

R2(config)#ip pim send-rp-announce lo 1 scope 10

前面的ip pim send-rp-announce 不變，後面是指定介面，

再後面的scope 指的是跳數，

按圖中所示，如果說你將跳數設定為4跳，那麼右側下方的CRP2將無法收到訊息

這樣一來，就無法保證全網路由器都收到這個訊息了，就無法構建表項了

所以儘可能的將這個值設定的大一些即可，不成就直接255，一勞永逸了

輸入完命令之後，就可以抓包看到這個訊息

由crp 2.2.2.2 向224.0.1.39傳送一個rp announcement 訊息，RP是2.2.2.2 o 224.0.0.0組提供服務，並且這個訊息是基於UDP的，埠號496

並且此時所有的路由器上已經有了*,G表項

但為什麼oil 是Null 呢？

因為下面沒有接收者啊~

好，現在我們讓R3配置成MA

R3(config)#ip pim send-rp-discovery lo 1 scope 255

注意，LO 1 介面必須啟用pim 並且是sparse 模式的

當R3被配置為MA後，接收到了R2發來的announcement 訊息後，會給予回覆一個 rp mapping 訊息

說的是什麼呢？

RP 是2.2.2.2 為224.0.0.0/4所有的組播地址服務

注意，這不是給2.2.2.2 單播回覆的，而是向224.0.1.40這個地址傳送的，

由於現在只有2.2.2.2 一個RP，所以現在看不到選舉的內容

可以說現在根據這兩個組地址就構建了*,G和S,G.

現在讓PC加組，224.1.1.1

然後分析一下*,G表項是什麼樣的？

R3有沒有？

肯定有，

*,224.1.1.1

In – f0/0 連線著RP,RP是R2
oil – f0/1 因為F0/1口收到了組成員發來的 IGMP report 訊息

R2有沒有？

肯定也有

*.224.1.1.1

In- null 因為自己就是RP

OIL- F0/1 收到了*,G 的join訊息

此時讓R1也成為RP 傳送announsement 訊息

但是R3 MA 對映代理收到這個訊息後，會向224.0.1.40地址傳送一個訊息rp mapping

這個訊息是已經選舉完成的。

還是R2是主RP

MA 可以有多個

RP 也可以有多個

RP選舉原則

很簡單，

直接比較IP地址的大小，誰的地址大，誰就是主RP

主RP 如果在181秒之內不向MA產生下一個資料包，則宣佈該RP失效

MA選舉原則

MA不存在選舉，如果有多個MA，那麼他們將一同工作，都是提供相同的服務，負責收集並且選舉CRP的

我們來驗證一下CRP的選舉，現在將R1的lo1 介面IP地址改為10.10.10.10，來看看RP的身份是否會變

看來是沒有問題的，就是得等一段時間，要等它的這個訊息傳送週期完成才OK

PS

AUTO RP 相比較BSR 收斂速度要慢，並且沒有RP輪詢機制

AUTO RP 對於組播模式有一定的要求 和規則

AUTO RP 可以支援PIMV1 還支援PIMV2

--------------------------------------------------

CCIE成長之路 ---梅利