PIM protokolü, bir ağda yönlendiriciler arasında çok noktaya yayın iletimi için bir dizi protokoldür. Komşuluk ilişkileri, dinamik yönlendirme protokollerinde olduğu gibi aynı şekilde oluşturulur. PIMv2, her 30 saniyede bir ayrılmış çok noktaya yayın adresi 224.0.0.13'e (Tüm PIM Yönlendiricileri) Merhaba mesajları gönderir. Mesaj Bekletme Zamanlayıcıları içerir - genellikle 3.5*Merhaba Zamanlayıcısına eşittir, yani varsayılan olarak 105 saniyedir.
PIM iki ana çalışma modunu kullanır: Yoğun ve Seyrek mod. Yoğun modla başlayalım.
Kaynak Tabanlı Dağıtım Ağaçları.
Farklı çok noktaya yayın gruplarından çok sayıda istemci olması durumunda yoğun mod modunun kullanılması tavsiye edilir. Bir yönlendirici çok noktaya yayın trafiği aldığında yaptığı ilk şey, RPF kuralını kontrol etmektir. RPF - bu kural, tek noktaya yayın yönlendirme tablosuyla çok noktaya yayının kaynağını kontrol etmek için kullanılır. Tek noktaya yayın yönlendirme tablosunun sürümüne göre trafiğin bu ana bilgisayarın gizlendiği arayüze ulaşması gerekir. Bu mekanizma, çok noktaya yayın iletimi sırasında meydana gelen döngü sorununu çözer.
R3, çok noktaya yayın mesajından çok noktaya yayın kaynağını (Kaynak IP) tanıyacak ve tek noktaya yayın tablosunu kullanarak R1 ve R2'den gelen iki akışı kontrol edecektir. Tablonun (R1'den R3'e) işaret ettiği arayüzden gelen akış daha da iletilecek ve çok noktaya yayın kaynağına ulaşmak için paketleri S2/0 aracılığıyla göndermeniz gerektiğinden R1'den gelen akış bırakılacaktır.
Soru şu: Aynı metriğe sahip iki eşdeğer rotanız varsa ne olur? Bu durumda yönlendirici bu rotalar arasından bir sonraki atlamayı seçecektir. IP adresi daha yüksek olan kazanır. Bu davranışı değiştirmeniz gerekiyorsa ECMP'yi kullanabilirsiniz. Daha fazla detay .
RPF kuralını kontrol ettikten sonra yönlendirici, paketin alındığı yer dışındaki tüm PIM komşularına çok noktaya yayın paketi gönderir. Diğer PIM yönlendiricileri bu işlemi tekrarlar. Çoklu yayın paketinin kaynaktan son alıcılara kadar izlediği yol, kaynak tabanlı dağıtım ağacı, en kısa yol ağacı (SPT), kaynak ağacı adı verilen bir ağaç oluşturur. Üç farklı isim, herhangi birini seçin.
Bazı yönlendiricilerin bazı çok noktaya yayın akışlarından vazgeçmemesi ve bunu gönderecek kimsenin olmaması, ancak yukarı akış yönlendiricisinin bunu ona göndermesi sorunu nasıl çözülür? Prune mekanizması bunun için icat edildi.
Erik Mesajı.
Örneğin, R2, R3'e çok noktaya yayın göndermeye devam edecek, ancak RPF kuralına göre R3 bunu bırakacaktır. Kanal neden yükleniyor? R3 bir PIM Prune Mesajı gönderir ve R2, bu mesajı aldıktan sonra S0/1 arayüzünü bu akışın giden arayüz listesinden, yani bu trafiğin gönderilmesi gereken arayüzlerin listesinden kaldıracaktır.
Aşağıda PIM Prune mesajının daha resmi bir tanımı yer almaktadır:
PIM Prune mesajı, ikinci yönlendiricinin belirli bir (S,G) SPT'den Prune'un alındığı bağlantıyı kaldırmasına neden olmak için bir yönlendirici tarafından ikinci bir yönlendiriciye gönderilir.
Prune mesajını aldıktan sonra R2, Prune zamanlayıcısını 3 dakikaya ayarlar. Üç dakika sonra, başka bir Prune mesajı alana kadar tekrar trafik göndermeye başlayacaktır. Bu PIMv1'dedir.
Ve PIMv2'ye bir Durum Yenileme zamanlayıcısı eklenmiştir (varsayılan olarak 60 saniye). R3'ten Prune mesajı gönderilir gönderilmez bu zamanlayıcı R3'te başlatılır. Bu zamanlayıcının sona ermesi üzerine R3, bu grup için R3'deki 2 dakikalık Budama Zamanlayıcısını sıfırlayacak bir Durum Yenileme mesajı gönderecektir.
Prune mesajı gönderme nedenleri:
- Çok noktaya yayın paketi RPF kontrolünde başarısız olduğunda.
- Çok noktaya yayın grubu (IGMP Katılımı) talep eden yerel olarak bağlı istemciler olmadığında ve çok noktaya yayın trafiğinin gönderilebileceği PIM komşuları olmadığında (Prune Olmayan Arayüz).
Greft Mesajı.
R3'ün R2'den trafik istemediğini, Prune'u gönderdiğini ve R1'den çok noktaya yayın aldığını düşünelim. Ancak aniden R1-R3 arasındaki kanal düştü ve R3 çok noktaya yayınsız kaldı. R3'deki Budama Zamanlayıcısının süresi dolana kadar 2 dakika bekleyebilirsiniz. 3 dakika uzun bir beklemedir, beklememek için bu S0/1 arayüzünü anında budanmış durumdan R2'ye getirecek bir mesaj göndermeniz gerekir. Bu mesaj bir Graft mesajı olacaktır. Graft mesajını aldıktan sonra R2, Graft-ACK ile yanıt verecektir.
Kuru erik geçersiz kılma.
Bu diyagrama bakalım. R1, iki yönlendiricili bir segmente çok noktaya yayın yayınlar. R3 trafiği alır ve yayınlar, R2 alır ancak trafiği yayınlayacak kimse yoktur. Bu segmentteki R1'e Prune mesajı gönderir. R1'in Fa0/0'ı listeden çıkarması ve bu segmentte yayını durdurması gerekiyor ama R3'e ne olacak? R3 de aynı segmentte, Prune'dan bu mesajı aldı ve durumun trajedisini anladı. R1 yayını durdurmadan önce 3 saniyelik bir zamanlayıcı ayarlar ve 3 saniye sonra yayını durdurur. 3 saniye - bu, R3'ün çok noktaya yayınını kaybetmemek için tam olarak ne kadar süreye sahip olduğudur. Bu nedenle R3 en kısa sürede bu gruba Pim join mesajı gönderir ve R1 artık yayını durdurmayı düşünmez. Aşağıdaki Katıl mesajları hakkında.
Mesajı Onaylayın.
Şu durumu hayal edelim: İki yönlendirici aynı anda bir ağa yayın yapıyor. Kaynaktan aynı akışı alıyorlar ve her ikisi de bunu e0 arayüzünün arkasındaki aynı ağa yayınlıyorlar. Bu nedenle bu ağ için kimin tek yayıncı olacağını belirlemeleri gerekiyor. Bunun için Assert mesajları kullanılır. R2 ve R3, çok noktaya yayın trafiğinin kopyalandığını tespit ettiğinde, yani R2 ve R3 kendilerinin yayınladıkları bir çok noktaya yayın aldıklarında, yönlendiriciler burada bir sorun olduğunu anlar. Bu durumda yönlendiriciler, Yönetim Mesafesini ve çok noktaya yayın kaynağına ulaşılan rota ölçüsünü içeren Assert mesajları gönderir - 10.1.1.10. Kazanan şu şekilde belirlenir:
- AD'si daha düşük olan.
- Eğer AD eşitse, o zaman kim daha düşük metriğe sahip?
- Burada eşitlik varsa o zaman bu multicast'i yayınladıkları ağda IP'si daha yüksek olan kişidir.
Bu oylamanın kazananı Atanmış Yönlendirici olur. Pim Hello ayrıca DR'leri seçmek için de kullanılır. Yazının başında PIM Hello mesajı gösteriliyordu, orada DR alanını görebilirsiniz. Bu bağlantıda en yüksek IP adresine sahip olan kazanır.
Yararlı işaret:
MRUTE Tablosu.
PIM protokolünün nasıl çalıştığına ilk bakıştan sonra, çok noktaya yayın yönlendirme tablosuyla nasıl çalışılacağını anlamamız gerekir. Mroute tablosu, istemcilerden hangi akışların talep edildiğine ve çok noktaya yayın sunucularından hangi akışların aktığına ilişkin bilgileri depolar.
Örneğin, bazı arayüzlerde bir IGMP Üyelik Raporu veya PIM Katılımı alındığında, yönlendirme tablosuna ( *, G ) türünde bir kayıt eklenir:
Bu giriş 238.38.38.38 adresi ile trafik talebi alındığı anlamına gelmektedir. DC bayrağı, çok noktaya yayının Yoğun modda çalışacağı anlamına gelir ve C, alıcının doğrudan yönlendiriciye bağlı olduğu, yani yönlendiricinin IGMP Üyelik Raporu ve PIM Katılımını aldığı anlamına gelir.
(S,G) türünde bir kayıt varsa bu, çok noktaya yayın akışımız olduğu anlamına gelir:
S alanında - 192.168.1.11, çok noktaya yayın kaynağının IP adresini kaydettik, RPF kuralı tarafından kontrol edilecek olan da budur. Sorun varsa yapmanız gereken ilk şey, kaynağa giden rota için tek noktaya yayın tablosunu kontrol etmektir. Gelen Arayüz alanında, çoklu yayının alındığı arayüzü belirtir. Tek noktaya yayın yönlendirme tablosunda, kaynağa giden yol burada belirtilen arayüze başvurmalıdır. Giden Arayüz, çok noktaya yayının nereye yönlendirileceğini belirtir. Boşsa, yönlendirici bu trafik için herhangi bir istek almamıştır. Tüm bayraklar hakkında daha fazla bilgiyi burada bulabilirsiniz .
PIM Seyrek modu.
Seyrek modun stratejisi Yoğun modun tam tersidir. Seyrek mod çok noktaya yayın trafiği aldığında, trafiği yalnızca bu akış için isteklerin olduğu arayüzler üzerinden gönderir; örneğin, bu trafiği talep eden Pim Katılımı veya IGMP Raporu mesajları.
SM ve DM için benzer unsurlar:
- Komşuluk ilişkileri PIM DM'dekiyle aynı şekilde kurulur.
- RPF kuralı çalışır.
- DR seçimi benzerdir.
- Prune Overrides ve Assert mesajlarının mekanizması benzerdir.
Ağda kimin, nerede ve ne tür çoklu yayın trafiğine ihtiyaç duyulduğunu kontrol etmek için ortak bir bilgi merkezine ihtiyaç vardır. Merkezimiz Buluşma Noktası (RP) olacaktır. Bir tür çok noktaya yayın trafiği isteyen veya birisi kaynaktan çok noktaya yayın trafiği almaya başlayan kişi, bunu RP'ye gönderir.
RP çok noktaya yayın trafiği aldığında, bunu daha önce bu trafiği talep eden yönlendiricilere gönderir.
RP'nin R3 olduğu bir topoloji hayal edelim. R1, S1'den trafik alır almaz, bu çok noktaya yayın paketini tek noktaya yayın PIM Kaydı mesajında kapsüller ve RP'ye gönderir. RP'nin kim olduğunu nereden biliyor? Bu durumda statik olarak yapılandırılmıştır, dinamik RP yapılandırmasından daha sonra bahsedeceğiz.
ip pim rp adresi 3.3.3.3
RP bakacak - bu trafiği almak isteyen birinden bilgi var mıydı? Diyelim ki öyle değildi. Daha sonra RP, R1'e bir PIM Register-Stop mesajı gönderecektir; bu, kimsenin bu çok noktaya yayına ihtiyacı olmadığı, kaydın reddedildiği anlamına gelir. R1 çok noktaya yayın göndermeyecek. Ancak çok noktaya yayın kaynak ana bilgisayarı bunu gönderecektir, böylece R1, Kayıt-Durdurmayı aldıktan sonra, 60 saniyeye eşit bir Kayıt Bastırma zamanlayıcısını başlatacaktır. Bu zamanlayıcının süresi dolmadan 5 saniye önce R1, RP'ye Null-Register biti içeren (yani kapsüllenmiş çok noktaya yayın paketi olmayan) boş bir Kayıt mesajı gönderecektir. RP ise şöyle davranacak:
- Alıcı yoksa Kayıt-Durdur mesajıyla yanıt verecektir.
- Alıcılar görünürse, buna hiçbir şekilde yanıt vermeyecektir. 1 saniye içinde kayıt reddi almayan R5 mutlu olacak ve RP'ye kapsüllenmiş çok noktaya yayın içeren bir Kayıt mesajı gönderecektir.
Multicast'ın RP'ye nasıl ulaştığını anlamış gibiyiz, şimdi RP'nin trafiği alıcılara nasıl ulaştırdığı sorusuna cevap vermeye çalışalım. Burada yeni bir kavramın tanıtılması gerekiyor: Kök yol ağacı (RPT). RPT, kökleri RP'ye dayanan, alıcılara doğru büyüyen, her PIM-SM yönlendiricisinde dallanan bir ağaçtır. RP, PIM Katılım mesajlarını alarak bunu oluşturur ve ağaca yeni bir dal ekler. Ve böylece her alt yönlendirici bunu yapar. Genel kural şuna benzer:
- Bir PIM-SM yönlendiricisi, arkasında RP'nin gizlendiği arayüz dışındaki herhangi bir arayüzden PIM Katılım mesajı aldığında, ağaca yeni bir dal ekler.
- PIM-SM yönlendiricisi doğrudan bağlı bir ana bilgisayardan IGMP Üyelik Raporu aldığında da bir dal eklenir.
R5 yönlendiricide 228.8.8.8 grubu için çok noktaya yayın istemcimiz olduğunu hayal edelim. R5, ana bilgisayardan IGMP Üyelik Raporunu alır almaz, RP yönünde bir PIM Katılımı gönderir ve kendisi de ana bilgisayara bakan ağaca bir arayüz ekler. Daha sonra R5, R4'ten PIM Birleştirmesini alır, Gi5/0 arayüzünü ağaca ekler ve RP yönünde PIM Birleştirmesini gönderir. Son olarak RP (R1) PIM join'i alır ve Gi3/0'ı ağaca ekler. Böylece çok noktaya yayın alıcısı kaydedilir. R0-Gi3/0 → R0-Gi4/0 → R1-Gi5/0 köküne sahip bir ağaç oluşturuyoruz.
Bundan sonra R1'e bir PIM Katılımı gönderilecek ve R1, çok noktaya yayın trafiği göndermeye başlayacaktır. Ana bilgisayarın çok noktaya yayın başlamadan önce trafik talep etmesi durumunda RP'nin PIM Katılımı göndermeyeceğine ve R1'e hiçbir şey göndermeyeceğine dikkat etmek önemlidir.
Çoklu yayın gönderilirken aniden ana bilgisayar bunu almak istemeyi bırakırsa, RP Gi0/0 arayüzünde bir PIM Prune alır almaz, hemen doğrudan R1'e bir PIM Register-Stop ve ardından bir PIM Prune gönderecektir. Gi0/1 arayüzü aracılığıyla mesaj. PIM Kaydı-durdurma, tek noktaya yayın aracılığıyla PIM Kaydının geldiği adrese gönderilir.
Daha önce de söylediğimiz gibi, bir yönlendirici diğerine, örneğin R5'ten R4'e PIM Katılımı gönderdiğinde, R4'e bir kayıt eklenir:
Ve R5'in bu zamanlayıcı PIM Katılım mesajlarını sürekli olarak sıfırlaması gereken bir zamanlayıcı başlatılır, aksi takdirde R4 giden listeden çıkarılır. R5 her 60 PIM Katılım mesajını gönderecektir.
En Kısa Yol Ağacı Geçişi.
R1 ile R5 arasına bir arayüz ekleyeceğiz ve bu topolojiyle trafiğin nasıl aktığını göreceğiz.
Trafiğin eski R1-R2-R3-R4-R5 şemasına göre gönderilip alındığını ve burada R1 ile R5 arasındaki arayüzü bağlayıp yapılandırdığımızı varsayalım.
Öncelikle R5 üzerinde tek noktaya yayın yönlendirme tablosunu yeniden oluşturmamız gerekiyor ve artık 192.168.1.0/24 ağına R5 Gi0/2 arayüzü aracılığıyla ulaşılıyor. Artık Gi5/0 arayüzünde çok noktaya yayın alan R1, RPF kuralının karşılanmadığını ve Gi0/2 üzerinden çok noktaya yayın almanın daha mantıklı olacağını anlıyor. RPT ile bağlantısını kesmeli ve En Kısa Yol Ağacı (SPT) adı verilen daha kısa bir ağaç oluşturmalıdır. Bunu yapmak için Gi0/2 aracılığıyla R1'e PIM Katılımı gönderir ve R1, Gi0/2 aracılığıyla çok noktaya yayın göndermeye başlar. Artık R5'in iki kopya almaması için RPT aboneliğinden çıkması gerekiyor. Bunu yapmak için Prune'a kaynak IP adresini belirten ve özel bir bit (RPT-bit) ekleyen bir mesaj gönderir. Bu, bana trafik göndermenize gerek olmadığı anlamına geliyor, burada daha iyi bir ağacım var. RP ayrıca R1'e PIM Prune mesajları gönderir ancak Register-Stop mesajı göndermez. Başka bir özellik: R5, her dakika PIM Register'ı RP'ye göndermeye devam ederken, R1 artık sürekli olarak PIM Prune'u RP'ye gönderecektir. Bu trafiği isteyen yeni insanlar kalmayıncaya kadar RP bunu reddedecektir. R5, RP'ye SPT yoluyla çok noktaya yayın almaya devam ettiğini bildirir.
Dinamik RP araması.
Otomatik RP.
Bu teknoloji Cisco'ya aittir ve pek popüler değildir, ancak hala hayattadır. Otomatik RP işlemi iki ana aşamadan oluşur:
1) RP, ayrılmış adres olan 224.0.1.39'a RP-Duyuru mesajları gönderir ve kendisini herkes için veya belirli gruplar için RP olarak ilan eder. Bu mesaj her dakika gönderilmektedir.
2) Hangi gruplar için hangi RP'nin dinlenmesi gerektiğini belirten RP-Discovery mesajları gönderecek bir RP haritalama aracısı gereklidir. Bu mesaja göre normal PIM yönlendiricileri RP'yi kendileri belirleyecektir. Eşleme Aracısı, RP yönlendiricisinin kendisi veya ayrı bir PIM yönlendiricisi olabilir. RP-Discovery 224.0.1.40 adresine bir dakikalık zamanlayıcı ile gönderilir.
Sürece daha ayrıntılı olarak bakalım:
R3'ü RP olarak yapılandıralım:
ip pim gönder-rp-duyuru geri döngü 0 kapsam 10
Haritalama aracısı olarak R2:
ip pim send-rp-discovery geri döngü 0 kapsam 10
Diğerlerinde ise Auto-RP yoluyla RP bekliyoruz:
ip pim autorp dinleyicisi
R3'ü yapılandırdıktan sonra RP-Announce'ı göndermeye başlayacak:
Ve R2, haritalama aracısını kurduktan sonra RP-Duyuru mesajını beklemeye başlayacaktır. Ancak en az bir RP bulduğunda RP-Discovery göndermeye başlayacaktır:
Bu şekilde normal yönlendiriciler (PIM RP Dinleyici) bu mesajı alır almaz RP'yi nerede arayacaklarını bileceklerdir.
Auto-RP ile ilgili temel sorunlardan biri, RP-Anons ve RP-Keşif mesajlarını alabilmek için 224.0.1.39-40 adreslerine PIM Katılımı göndermeniz, gönderebilmek için ise PIM Katılımının nerede olduğunu bilmeniz gerekmektedir. RP yer alıyor. Klasik tavuk ve yumurta problemi. Bu sorunu çözmek için PIM Seyrek Yoğun Modu icat edildi. Yönlendirici RP'yi bilmiyorsa Yoğun modda çalışır; biliyorsa Seyrek modda çalışır. PIM Seyrek mod ve ip pim autorp dinleyici komutu normal yönlendiricilerin arayüzlerinde yapılandırıldığında, yönlendirici yalnızca Otomatik RP protokolünden (224.0.1.39-40) doğrudan çoklu yayın için Yoğun modda çalışacaktır.
BootStrap Yönlendiricisi (BSR).
Bu işlev Otomatik RP'ye benzer şekilde çalışır. Her RP, haritalama aracısına, haritalama bilgilerini toplayan ve ardından diğer tüm yönlendiricilere bilgi veren bir mesaj gönderir. Süreci Auto-RP'ye benzer şekilde anlatalım:
1) R3'ü RP olmaya aday olarak yapılandırdıktan sonra şu komutla:
ip pim rp-aday geri döngü 0
O zaman R3 hiçbir şey yapmayacak; özel mesajlar göndermeye başlamak için önce bir haritalama aracısı bulması gerekiyor. Böylece ikinci adıma geçiyoruz.
2) R2'yi eşleme aracısı olarak yapılandırın:
ip pim bsr-aday geri döngü 0
R2, kendisini bir haritalama aracısı olarak belirttiği PIM Bootstrap mesajlarını göndermeye başlar:
Bu mesaj PIM protokolünün diğer mesajları için de kullandığı 224.0.013 adresine gönderilir. Onları her yöne gönderiyor ve bu nedenle Auto-RP'deki gibi tavuk ve yumurta sorunu olmuyor.
3) RP, BSR yönlendiricisinden bir mesaj alır almaz, BSR yönlendirici adresine hemen bir tek noktaya yayın mesajı gönderecektir:
Bundan sonra, RP'ler hakkında bilgi alan BSR, bunları çok noktaya yayın yoluyla tüm PIM yönlendiricileri tarafından dinlenen 224.0.0.13 adresine gönderecektir. Bu nedenle, komutun bir analogu ip pim autorp dinleyicisi BSR'de olmayan normal yönlendiriciler için.
Çok Noktaya Yayın Kaynak Keşif Protokolü (MSDP) ile Anycast RP.
Otomatik RP ve BSR, RP üzerindeki yükü şu şekilde dağıtmamıza olanak tanır: Her çok noktaya yayın grubunun yalnızca bir aktif RP'si vardır. Bir çok noktaya yayın grubunun yükünü birkaç RP'ye dağıtmak mümkün olmayacaktır. MSDP bunu, RP yönlendiricilerine 255.255.255.255 maskesiyle aynı IP adresini vererek yapar. MSDP bilgileri şu yöntemlerden birini kullanarak öğrenir: statik, Otomatik RP veya BSR.
Resimde MSDP'li bir Otomatik RP yapılandırmamız var. Her iki RP de Loopback 172.16.1.1 arayüzünde 32/1 IP adresiyle yapılandırılmıştır ve tüm gruplar için kullanılır. RP-Announce ile her iki router da bu adrese başvurarak kendilerini duyurur. Bilgiyi alan Otomatik RP eşleme aracısı, 172.16.1.1/32 adresiyle RP hakkında RP-Discovery'yi gönderir. Yönlendiricilere IGP kullanarak 172.16.1.1/32 ağı hakkında bilgi veriyoruz ve buna göre. Bu nedenle, PIM yönlendiricileri, 172.16.1.1/32 ağına giden yolda sonraki atlama noktası olarak belirtilen RP'den akışları talep eder veya kaydeder. MSDP protokolünün kendisi, RP'lerin çok noktaya yayın bilgileri hakkında mesaj alışverişi yapması için tasarlanmıştır.
Bu topolojiyi düşünün:
Switch6, trafiği 238.38.38.38 adresine yayınlıyor ve şu ana kadar bunu yalnızca RP-R1 biliyor. Switch7 ve Switch8 bu grubu talep etti. R5 ve R4 yönlendiricileri sırasıyla R1 ve R3'e PIM Katılımı gönderecektir. Neden? R13.13.13.13 için 5'e giden rota, tıpkı R1'te olduğu gibi IGP metriğini kullanan R4'e atıfta bulunacaktır.
RP-R1 akışı biliyor ve onu R5'e yayınlamaya başlayacak, ancak R4 akışı göndermeyeceğinden R1 bu konuda hiçbir şey bilmiyor. Bu nedenle MSDP gereklidir. R1 ve R5'te yapılandırıyoruz:
R3.3.3.3'de ip msdp eş 1 bağlantı kaynağı Loopback1
R1.1.1.1'de ip msdp eş 3 bağlantı kaynağı Loopback3
Kendi aralarında bir oturum başlatacaklar ve herhangi bir akış aldıklarında bunu RP komşularına bildirecekler.
RP-R1, Switch6'dan bir akış alır almaz, çok noktaya yayının kaynağı ve hedefi hakkındaki bilgiler olan (S, G) gibi bilgileri içeren tek noktaya yayın MSDP Kaynak-Aktif mesajını hemen gönderecektir. Artık RP-R3, Switch6 gibi bir kaynağın, bu akış için R4'ten bir istek aldığında yönlendirme tablosunun rehberliğinde Switch6'ya PIM Katılımı göndereceğini bildiğine göre. Sonuç olarak, böyle bir PIM Katılımı alan R1, trafiği RP-R3'e göndermeye başlayacaktır.
MSDP TCP üzerinden çalışır, RP'ler canlılığı kontrol etmek için birbirlerine canlı tutma mesajları gönderir. Zamanlayıcı 60 saniyedir.
Keepalive ve SA mesajları herhangi bir alana üyeliği göstermediğinden, MSDP eşlerini farklı alanlara bölme işlevi belirsizliğini koruyor. Ayrıca bu topolojide farklı alanları gösteren bir yapılandırmayı test ettik; performansta hiçbir fark yoktu.
Birisi açıklayabilirse, yorumlarda okumaktan mutluluk duyarım.
Kaynak: habr.com