驗證理論:
PIM協議報文直接采用IP封裝,目的地址224.0.0.13,IP協議號103
PIM上下游接口:
入接口:必須為RPF校驗通過接口,連接RPF鄰居。
(S,G)參考組播源確定
(*,G)參考RP確定
下游接口生成方式:接收到(*,G)加組報告;接收(S,G)加組報告;接收IGMP加組報告
下游接口移除方式:接收到PIM Prune信息;接收到IGMP Leave信息;接收SPT切換產生的(S,G)修剪
PIM DM數據包類型:
PIM-DM工作機制:
1.當一台路由器收到組播報文后,先執行RPF檢查,通過檢查后建立(S,G)表項,然后將報文向所有其他有PIM鄰居或者IGMP接收者的接口泛洪(組播地址224.0.0.13)
2.當最后一跳路由器收到組播包文后,由於其沒有PIM鄰居或沒有IGMP接受者,組播表項下游接口列表為空,路由器會向上游鄰居發送剪枝報文,通知上游鄰居不要再繼續將組播報文轉發下來;上游鄰居收到剪枝報文后,會將收到剪枝報文的接口從其組播表項下有接口列表中減除
3.至此組播分發樹建立成功,后續組播流量參考組播路由條目(即(S,G)表項)進行轉發
4.若之前不在組播網絡中的接收者又上線了,則由最后一跳路由器發送嫁接報文到上游路由器上,上游路由器會將該最后一跳路由器添加進下游接口中並回復確認報文
應用場景:
PIM-DM模式主要用於組成員較少且相對密集的組播網絡中,該模式建立組播分發樹的基本思路是:“擴散——剪枝”,即將組播流量全網擴散,然后剪枝沒有組成員的路徑,最終形成組播分發樹
實驗拓撲:
初始配置:
AR45的0/0/1均未加入ISIS,其余底層打通
AR1-5上使能組播,AR4上0/0/1口加入PIM,AR5上0/0/1口未加入PIM,其余所有接口上配置PIM,以AR1為例:
[AR1]multicast routing-enable
[AR1]int g 0/0/0
[AR1-GigabitEthernet0/0/0]pim dm
[AR1-GigabitEthernet0/0/0]int g 0/0/1
[AR1-GigabitEthernet0/0/1]pim dm
實驗步驟:
第一步:建立鄰居
使能了PIM的路由器之間沒30s交互發送一次hello包,如果在105S的超時時間之前收到鄰居的hello包,就認為鄰居正常
[AR2]dis pim neighbor
VPN-Instance: public net
Total Number of Neighbors = 3
Neighbor Interface Uptime Expires Dr-Priority BFD-Session
155.1.12.1 GE0/0/0 00:05:38 00:01:31 1 N
155.1.23.3 GE0/0/1 00:05:11 00:01:34 1 N
155.1.24.4 GE0/0/2 00:04:34 00:01:41 1 N
查看有哪些接口加入了PIM
[AR2]dis pim interface
VPN-Instance: public net
Interface State NbrCnt HelloInt DR-Pri DR-Address
GE0/0/0 up 1 30 1 155.1.12.2 (local)
GE0/0/1 up 1 30 1 155.1.23.3
GE0/0/2 up 1 30 1 155.1.24.4
第二步:構建組播路由表
在沒有設置組播源之前,沒有組播業務流來提供組播源和組播組的信息,所以組播路由表為空
[AR2]dis pim routing-table
[AR2]
在AR45的0/0/1口上使能IGMPv2
[AR4-GigabitEthernet0/0/1]igmp enable
[AR5-GigabitEthernet0/0/1]igmp enable
此時AR4上是查看組播路由表可以看到(*,G)表項,因為終端加入攜帶了組信息,通過IGMP,AR4可以學習到
PIM-DM模式整個網絡中除了最后一跳路由器之外找不到(*,G)表項。(S,G)表項由組播業務流維護,(*,G)表項由IGMP維護
但是在AR5上,可以看到IGMP Group里面已經有終端了,但是由於沒有使能PIM,下游接口無法學習到,開啟PIM之后正常
不使能PIM無法處理組播流量,組播路由表出不來,所以配置組播時建議所有接口都使能PIM
配置組播源並播放視頻,組播流量自動泛洪給了所有PIM鄰居,這些鄰居收到流量之后根據流量里面的S和G信息構建(S,G)表項。此時就可以看到路由表里面自動生成了(S,G)表項
第三步:剪枝
觸發修剪信息通告的條件:
- 不存在下游接收者
- 不存在PIM鄰居(連接的終端或者是路由器沒有使能pim)
- 非RPF接口接收到組播流量(比如斷言失敗者AR3正常從連接源的接口0/0/1獲取流量,但是如果從連接斷言成功者AR4的接口0/0/0收到了流量就會發送剪枝消息,而斷言失敗的路由器本身也會發送1個剪枝包,所以斷言過程中會發送2個剪枝包)
首先播放視頻觸發組播路由表,然后將PC1離組,此時可以看到AR5向上游發送了剪枝報文
此時AR5上的(S,G)表項還在,但是已經沒有下游接口了。如果一直有組播流量可以到達AR5,那么(S,G)表項可以一直都在,但是如果收不到組播流量了,則(S,G)表項210s超時
此時可以看到AR5選擇的上聯鄰居時155.1.0.4。3,4都可以發送組播包,AR5為什么選擇了AR4呢?這里涉及到斷言機制
接收到下游剪枝消息:
若下游為P2P環境
接收下游設備修剪prune信息,上游響應修剪確認繼續向上修剪
若下游為MA環境
存在3S修剪延遲(等待其他成員join信息(MA網絡交換機廣播組播報文,其他終端收到你的修剪信息,如果他下面還有接受者,那么他會馬上發一個修剪否決)),等待其他下游發送剪枝信息,以確認下游無其他接收者
3S=LAN Delay500ms+剪枝否決2500ms
驗證:
僅將PC1加入組中,設置AR3上10.1.1.0/24的優先級為10使得AR3成為斷言成功者(原因查看第四步斷言機制):
ip ip-prefix NET10 index 10 permit 10.1.1.0 24
#
route-policy SET-PRI permit node 10
if-match ip-prefix NET10
apply preference 10
route-policy SET-PRI permit node 20
#
isis 1
preference route-policy SET-PRI
此時將AR4的0/0/2down掉,然后PC2也加入組中,然后讓PC2離線,抓包,可以看到AR4發送剪枝之后,AR5立刻就反對了,此時AR30/0/0口沒有被修剪
第四步;斷言機制
當一個網段內有多個相連的PIM路由器向該網段轉發組播報文時,需要通過斷言機制(Assert)來保證只有一個PIM路由器向該網段轉發組播報文
通過斷言機制的選舉規則將決定組播路由器的轉發行為:
- 獲勝一方的下游接口稱為Assert Winner,將負責后續對該網段組播報文的轉發
- 落敗一方的下游接口稱為Assert Loser,后續不會對該網段轉發組播報文(這種抑制轉發的狀態將保持assert保持時間,默認180s,assert保持時間超時后,競選失敗的設備會恢復轉發從而觸發新一輪競選),PIM路由器也會將其從(S,G)表象下游接口列表中刪除
PIM路由器在接收到鄰居路由器發送的相同組播報文后,會向該網段發送斷言(Assert)報文,進行Assert選舉。Assert報文內會攜帶到組播源的單播路由前綴,路由優先級與開銷。選舉規則如下:
- 單播路由協議優先級較高者獲勝
- 如果優先級相同,則到組播源的開銷較小者獲勝
- 如果以上都相同,則下游接口IP地址最大者獲勝
當前拓撲中,底層用的是ISIS優先級都是15,到組播源的開銷也都相同。
由於AR4的下游接口地址155.1.0.4大於AR3的下游接口地址155.1.0.3,所以AR4成為winner,向AR5轉發組播流量,AR3上則將AR5從(S,G)表項下游接口列表中刪除。將PC1重新加入組中:
AR34之間互發斷言數據包進行選舉攜帶有協議優先級,到組播源的cost,接口IP地址
AR4勝出之后AR3向AR4發送剪枝報文,另外由於AR3作為失敗者從非RPF端口也就是連接AR4的接口收到了流量,也觸發了一次剪枝,所以發送了2次
此時AR3,5上的組播路由表如下圖
看似沒有問題,但是存在一種這樣的可能性:流量由斷言獲勝的AR4發送,但是AR5不一定認為從AR4發過來的組播流量是正確的。也就是說RPF校驗得出的結論可能與斷言機制得出的結論相悖,此時會出現無法通信的情況
今天上面分析沒有問題是因為恰巧RPF校驗也認為從AR4過來的是正確的
優選RPF路有原則:
- 掩碼最長匹配
- 路由最優優先級
- 組播靜態路由>MBGP路由>單播路由
斷言機制選舉原則:
- 單播路由協議優先級較高者獲勝
- 如果優先級相同,則到組播源的開銷較小者獲勝
- 如果以上都相同,則下游接口IP地址最大者獲勝
手動在AR5上增加組播靜態路由,掩碼增加到25位,希望AR5去往組播源AR3可以RPF選舉獲勝,AR4可以斷言獲勝
開啟視頻構建組播表並抓包后發現,正如所料,AR4斷言獲勝,AR3發送了剪枝包
但是此時的AR5上對於組239.1.1.1的RPF接口卻被修改到了AR4上
[AR5]dis multicast rpf-info 10.1.1.0
VPN-Instance: public net
RPF information about source: 10.1.1.0
RPF interface: GigabitEthernet0/0/0, RPF neighbor: 155.1.0.3
Referenced route/mask: 10.1.1.0/25
Referenced route type: mstatic
Route selection rule: preference-preferred
Load splitting rule: disable
[AR5]dis pim routing-table
VPN-Instance: public net
Total 1 (*, G) entry; 1 (S, G) entry
(10.1.1.1, 239.1.1.1)
Protocol: pim-dm, Flag:
UpTime: 00:05:02
Upstream interface: GigabitEthernet0/0/0
Upstream neighbor: 155.1.0.3
RPF prime neighbor: 155.1.0.4
Downstream interface(s) information:
Total number of downstreams: 1
1: GigabitEthernet0/0/1
Protocol: pim-dm, UpTime: 00:05:02, Expires: -
原因:斷言會修改下一跳的RPF鄰居向斷言結果看齊
第五步:嫁接
當有新成員加入組播組后,組播網絡需要更新組播分發樹,才能將組播數據發往組成員。PIM-DM模式在使用“擴散——剪枝”的方式建立組播分發樹后,通過狀態刷新機制,使下行接口一旦被抑制就無法自動恢復
因此需要一些機制來更新組播分發樹,一般PIM-DM模式更新組播分發樹的方法有兩種:
等待組播路由表超時后,全網重新泛洪,該方法不可控,在現網中無法實現
使用嫁接(Graft)機制,當新成員加組后,主動反向建立組播分發路徑。現網中一般使用嫁接機制來實現新成員加組。
葉子路由器通過IGMP了解到與其相連的用戶網段上,組播組G有新的組成員加入。隨后葉子路由器會基於本地的組播路由器上被狀態刷新機制維護的(S,G)表項向上游發送Graft報文,請求上游路由器恢復相應出接口轉發,(上游路由器)將其添加在(S,G)表項下游接口列表中
前提條件:通過前面的設置使得AR3打敗AR4成為了斷言機制winner,所以到PC1的數據走向是AR1235-》PC1
在AR24之間增加路由器AR6,修改AR6上流量入接口ISIS開銷為1,使得AR4仍然認為0/0/2口到達組播源最近為RPF接口。PC2離組的狀態下再加組
加組之前:
[AR4]dis pim routing-table
VPN-Instance: public net
Total 0 (*, G) entry; 1 (S, G) entry
(10.1.1.1, 239.1.1.1)
Protocol: pim-dm, Flag: ACT
UpTime: 00:00:49
Upstream interface: GigabitEthernet0/0/2
Upstream neighbor: 155.1.46.6
RPF prime neighbor: 155.1.46.6
Downstream interface(s) information: None
加組之后:
AR21之間則沒有剪枝報文
可以看到AR4朝着RPF鄰居AR6單播發送了嫁接報文,AR6向AR4回復嫁接確認的同時將將0/0/1作為下游接口加入到路由表中同時繼續朝着RPF鄰居AR2發送了嫁接報文,然后AR2將接口0/0/2作為下游接口加入到路由表中之后回復了嫁接確認。
總結: 單播朝着RPF鄰居發送,嫁接接收者存在於其他下游接口則停止轉發嫁接信息,反之繼續轉發嫁接信息
第六步:狀態刷新機制
在PIM-DM網絡中,為了避免被裁減的接口因為“剪枝定時器(默認210s)”超時而恢復轉發,離組播源最近的第一跳路由器會周期性地(每隔一秒)觸發State Refresh報文在全網內擴散
收到State Refresh報文的PIM路由器會刷新剪枝定時器的狀態。被裁減接口的下游葉子路由器如果一直沒有組成員加入,該接口將一直處於抑制轉發狀態
將PC2離組之后再AR4的0/0/0口和AR6的0/0/0口抓包:
狀態刷新機制按住下游接口的同時,也維護了沒有接收者的下游路由器上的(S,G)表象:
狀態刷新機制默認開啟,也可以手動配置:
[AR4-GigabitEthernet0/0/0]pim state-refresh-capable
第七步:DM的局限性
中大型組播網絡中由於網絡較大,如果依然使用PIM-DM會遇到許多問題:
- 使用“擴散——剪枝”方式需要全網擴散組播報文,對於網絡有一定沖擊
- 所有組播路由器均需要維護組播路由表,即使該組播路由器無需轉發組播數據
- 對於組成員較為稀疏的網絡,使用“擴散——剪枝”形成組播分發樹的效率不高