VPN üzerinden PIM-SM: BSR, RP eşlemesi ve RPF yollarını denetleyin

Tünel ayakta, unicast ping'ler içinden geçiyor ve alıcı hâlâ siyah ekran gösteriyor. Bir PIM-SM kurulumunda bu belirti neredeyse her zaman dört denetim yolundan birinin kırık olduğu ve veri yolunun hiçbir zaman sorun olmadığı anlamına gelir. Aşağıdaki listeyi sırayla işleyin ve başarısız olan ilk adımda durun, çünkü sonraki her adım bir öncekine bağlıdır. Bu beş denetimi bir taslak dosyada tutuyorum ve bir multicast şikâyeti geldiğinde terminale yapıştırıyorum; bu da tanılamanın tahmine dönüşmesini önlüyor.

Tünelden değil, alıcıdan başlayın

Grubu hiç istememiş bir alıcı hiçbir yönlendiricide durum oluşturmaz, bu yüzden başka herhangi bir şeyi incelemeden önce alıcıya bakan segmentte katılımın bulunduğunu doğrulayın. Cisco tarzı platformlarda son atlama yönlendiricisinde show ip igmp groups katılan grupları onları duyan arayüzün yanında yazdırır. Grup bu çıktıda yoksa tünel bir dikkat dağıtıcıdır: istek erişim anahtarında, ana makinenin soketinde ya da querier bulunmayan bir VLAN'da öldü.

Gördüğüm eksik katılımların çoğunu iki sıradan neden açıklıyor: ana makine ile yönlendirici arasındaki IGMP sürüm uyuşmazlığı ve yönlendirme yapmayan bir anahtara düşen querier seçimi. Üçüncüsü daha incedir: grup katılmış ama yanlış VLAN'da, çünkü ana makinede iki ağ kartı var ve uygulama yanlış olana bağlanmış. IPv6 alıcıları MLD ile aynı sorunu yaşar ve orada show ipv6 mld groups aynı soruya yanıt verir. Bunların hiçbiri tünele dokunarak düzeltilmez ve sıranın önemi tam olarak bundandır.

Katılım görünür olduğunda PIM'in hem alıcıya bakan arayüzde hem de buluşma noktasına giden arayüzde etkin olduğunu doğrulayın. IGMP üyeliği olan ama yukarı akış arayüzünde PIM olmayan bir yönlendirici grubu yerel bir tabloda tutar ve hiçbir yere bir şey göndermez.

BSR kümesi karşı tarafa ulaşıyor mu?

Bootstrap Router iletileri tek bir PIM alanı içinde atlama atlama ilerler ve tünelden geçerken kırılan yön tam olarak budur. Aday RP'ler duyurularını seçilmiş BSR'ye unicast ile gönderir, bu yüzden RP'den BSR'ye uzanan bölüm çalışan bir tünelde genellikle değişmeden kalır. Diğer yöndeki Bootstrap iletisi akışı her ara arayüzde PIM etkin olmasına ve hiçbir şeyin iletileri sınırda durdurmamasına bağlıdır. RFC 5059 bu dağıtımı ve onu kısaltmasına izin verilen yönetimsel kapsam sınırlarını tanımlar.

ip pim bsr-border deyimi, 103 protokolünü filtreleyen bir ACL ya da multicast taşıyamayan ilke tabanlı bir IPsec tüneli, her biri akışı keserken unicast bozulmadan kalır. Arızanın gerçekte bir erişilebilirlik sorunu olduğu hâlde RP sorunu gibi görünmesine yol açan tam olarak bu bileşimdir ve bu yüzden BSR durumunu RP yapılandırmasından önce okurum.

Uzak taraftaki yönlendiricide show ip pim bsr-router seçilmiş BSR'yi ve öğrenilen RP kümesini belirtir; çıktı boşsa uzak taraf kendi alanında oturuyordur ve hiçbir RP yapılandırması ikisini uzlaştırmaz. Tünelin iki yanındaki show ip pim rp mapping çıktısında grup aralıklarını ve RP adreslerini karşılaştırın. Yalnızca yerel olarak var olan bir eşleme yanlış yerde biten ortak bir ağaç üretir ve alıcı sonsuza kadar bekler.

RP eşlemesini tünelin iki yanında aynı hâle getirin

Statik RP, BSR ve anycast-RP aynı soruya üç yanıttır ve bunları tünel üzerinden karıştırmak hiçbir zaman yakınsamayan bir alan inşa etmenin güvenilir yoludur. Baş uç BSR kullanıyorsa ve şube başka bir adrese işaret eden statik bir ip pim rp-address kullanıyorsa, şube ortak ağacını alıcının var olduğunu bilmeyen bir RP'ye doğru kurar. Eşleme hem grup aralığında hem de adreste aynı olmalıdır, çünkü daha belirgin aralık daha geniş olanı yener.

Anycast-RP tam olarak iki sitenin tek bir RP adresini paylaşabilmesi için vardır ve burada anılmayı hak eder çünkü «aynı RP»nin anlamını değiştirir. Tek bir adres duyuran iki RP tasarım gereği tutarlıdır; aynı aralık için farklı adresler duyuran iki RP ise, her site tek başına ne kadar sağlıklı görünürse görünsün, tutarlı değildir.

232.0.0.0/8 içindeki kaynağa özgü multicast için RP'ye hiçbir zaman başvurulmaz, bu yüzden boş bir RP eşlemesi otomatik olarak arıza değildir. Hiç gerekli olmayan bir RP'nin peşine düşmeden önce uygulamanın hangi hizmet modelini kullandığına karar verin.

RPF aramasını kaynağa doğru okuyun

PIM ağacı unicast yolunu tersine çevirerek kurar, bu yüzden önemli olan denetim kaynağa geri giden rotadır ya da ortak ağaç için RP'ye geri giden rotadır. Yönlendiricinin yukarı akış saymadığı bir arayüze gelen katılım düşürülür ve nedeni tünel arızası olarak değil RPF arızası olarak günlüğe yazılır. Tünel üzerinden varsayılan rotası ve WAN üzerinden daha belirgin rotası olan bir şube yönlendiricisinde, kaynağa yalnızca tünel üzerinden ulaşılabilse bile RPF arayüzü kolayca WAN olabilir. Bir katılımın sessizce düşürülmesinin tek en yaygın nedeni budur.

show ip rpf 192.0.2.10 seçilen arayüzü, sonraki atlamayı ve kararı üreten rotayı yazdırır; bu genellikle uyuşmazlığı görmek için yeterlidir. ip mroute 192.0.2.0 255.255.255.0 tunnel0 gibi statik bir multicast rotası o önek için unicast aramasını geçersiz kılar ve multicast topolojisi unicast topolojisinden gerçekten farklı olduğunda bu meşru bir düzeltmedir. Ona belgelenmesi gereken bir yapılandırma olarak davranın, olay sırasında uygulanıp sonra unutulan bir yama olarak değil.

Katılımı ping ile değil komutlarla doğrulayın

Ping unicast'ın çalıştığını kanıtlar, bunu zaten biliyordunuz. Uçtan uca doğrulama, katılımı, eşlemeyi, komşuyu ve ağacı bu sırayla gösteren bir dizidir ve her komut farklı bir soruyu yanıtlar.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Gerçek bir gelen arayüze ve boş olmayan giden listesine sahip dolu bir (S,G) girdisi, denetim düzleminin işini bitirdiği anlamına gelir. Gelen arayüzü Null olarak okunan bir girdi ya da sürekli artan RPF failed etiketli bir sayaç, tünele değil önceki bölüme işaret eder.

Beş komutun hepsi doğru görünüyorsa ve alıcı hâlâ hiçbir şey görmüyorsa, geriye kalan şüpheli tünelin kendi ilkesidir: unicast yönlendirme protokolüne izin veren ama PIM, IGMP ya da grubun trafiğine izin vermeyen bir kripto ACL veya güvenlik duvarı kuralı. İlke tabanlı bir IPsec tünelinde multicast hiç taşınmaz, bu yüzden yanıt bir filtre istisnası değil GRE ya da VTI tasarımıdır. Bir şeyi değiştirmeden önce beş denetimden hangisinin başarısız olduğunu yazın, sonra yalnızca o katmanı değiştirin.