- Katılım
- 15 May 2013
- Konular
- 972
- Mesajlar
- 6,656
- Online süresi
- 2ay 11g
- Reaksiyon Skoru
- 5,350
- Altın Konu
- 314
- Başarım Puanı
- 319
- TM Yaşı
- 12 Yıl 11 Ay 12 Gün
- MmoLira
- 22,230
- DevLira
- 15
Metin2 EP, Valorant VP dahil tüm oyun ürünlerini en uygun fiyatlarla bulabilir, Item ve Karakterlerinizi hızlıca satabilirsiniz. HEMEN TIKLA!
Bu konumda sizlere, PIM Yoğun modu kullanılarak IP çoklu yayınında karşılaşılan en yaygın sorunlar ele alınmaktadır. Bu süreçte, Cisco IOS-XE cihazlarında bulunan çoklu yayına özgü bazı sorun giderme araçlarına da değineceğiz.
Laboratuvar Topolojisi ve Başlangıç Durumu
Başlangıçtaki laboratuvar topolojisi aşağıdaki şemada gösterilmiştir. OSPFv2 kullanarak tam IP erişilebilirliğine sahip olduğumuzu fark edin. Tüm yönlendirici bağlantılarında PIM Yoğun modu yapılandırılmıştır. Kaynak, 239.1.1.1 grubunda çoklu yayın trafiği iletmektedir (239.1.1.1'e ping atılıyor).
Bu topolojiyi, farklı arızaları tanıtıp çözerek her sorun giderme senaryosunda kullanacağız. EVE-NG dosyasını dersin sonunda indirebilirsiniz.
Senaryo 1 - Yönlendiricide çoklu yayın yönlendirmesi etkinleştirilmemiş.
Özellikle sınav ortamlarında IP çoklu yayın ile ilgili en yaygın sorunlardan biri, yol üzerindeki bir yönlendiricinin çoklu yayın yönlendirmesi yapacak şekilde etkinleştirilmemiş olmasıdır.
Tüm Cisco IOS ve IOS-XE yönlendiricilerinde çoklu yayın yönlendirmesinin varsayılan olarak devre dışı bırakıldığını hatırlayın. Yönlendiricinin genel yapılandırma modunda aşağıdaki gibi tek bir CLI komutu yapılandırarak çoklu yayın yönlendirme işlevini etkinleştiriyoruz:
Bir yönlendirici, çoklu yayın yönlendirmesi yapacak şekilde yapılandırılmamışsa, arayüzler arasında çoklu yayın trafiğini iletmez. Bu işlevi etkinleştirme işlemi manuel olduğundan, sınav/test ortamlarında sıklıkla yanlışlıkla unutulur veya kasıtlı olarak yapılandırılmış halde bırakılır.
Yönlendiricilerden birinin IP çoklu yayın yönlendirmesi ile yapılandırılmadığı bir topolojiyi nasıl sistematik olarak giderebileceğimizi görelim.
Sorun Belirtileri
PC2'nin çoklu yayın akışını (10.1.1.1, 239.1.1.1) alamadığı bildirildi.
PC2 gruba katılıyor (239.1.1.1 için IGMP Üyelik raporu gönderiyor)
PC2 kaynak IP adresine ping atabiliyor (tek noktaya yayın erişilebilirliği var)
Sorun Giderme
Unutmayın ki çoklu yayın dağıtım ağacı (MDT) alıcı tarafından başlatılır. Alıcının grup IP adresine katılması ve son atlama yönlendiricisinin kaynağa giden kaynak yol ağacının (SPT) oluşturulmasını başlatması sorumluluğundadır.
Çoklu yayın trafiği kaynaktan alıcılara doğru akar. Bu, veri düzlemidir ve aşağı yönlü yön olarak adlandırılır. Ancak, kontrol düzlemi işlemleri alıcıdan kaynağa doğru ters yönde gerçekleşir. Bu, yukarı yönlü yön olarak adlandırılır. Çoğu sorun veri düzleminden ziyade kontrol düzleminde meydana geldiğinden, sorun gidermenin her zaman alıcıların yerel ağ geçidi yönlendiricisinden yukarı yönlü olarak başlatılması önerilir.
UNUTULMAMALI:
Veri düzlemi aşağı yönlü çalışır.
Kontrol düzlemi yukarı yönlü çalışır.
Başlangıç noktası: LHR
Genel bir kural olarak, sorun gidermeye her zaman alıcı ve son atlama yönlendiricisinden başlarız ve ardından kaynağa doğru yukarı yönlü devam ederiz. Örneğimizde, PC2'nin son atlama yönlendiricisi R8'dir. R8'e giriş yapalım ve neler anlayabileceğimizi görelim.
İlk olarak, alıcının IGMP kullanarak çoklu yayın grup adresine katılıp katılmadığını kontrol ederiz.
PC2'nin 239.1.1.1 adresine başarıyla katıldığını görüyoruz.
Sonraki adım, yönlendiricide çoklu yayın yönlendirmesinin etkin olup olmadığını kontrol etmektir. Bunu doğrulamanın doğrudan ve dolaylı bir yolu vardır. Bunu aşağıdaki komutu kullanarak doğrudan kontrol edebiliriz.
Ancak, bunu yönlendiricinin mroute tablosuna bakarak da kontrol edebiliriz. Çoklu yayın yönlendirmesi etkinleştirilmemişse, mroute tablosu doğrudan "IP Çoklu Yayın İletme etkinleştirilmedi" der.
Bir sonraki adım, LHR'nin yönlendirme tablosunu kontrol etmektir. R8, kaynaktan çoklu yayını alıyorsa, mroute tablosunda bir kaynak-grup çifti (S, G) girişi görmeyi bekleriz.
(S, G) çiftinin olmadığını görüyoruz. Bu nedenle, R8 kaynaktan gelen çoklu yayın akışını almıyor. Çoklu yayın trafiğinin ilk yayılımı son atlama yönlendiricisine ulaşmıyor. Dolayısıyla, kaynak ile son atlama yönlendiricisi arasındaki yolda bir sorun olmalı.
Yukarı Akışa Devam
Peki, nasıl devam edeceğiz? Kaynak IP adresi 10.1.1.1'e giden tekil rotayı izliyoruz. R8'de `show IP route 10.1.1.1` komutunu çalıştırdığımızda, bir sonraki atlama noktasının R6 olduğunu görüyoruz, bu yüzden R6'ya giriş yapıyoruz.
R6'da, öncelikle mroute tablosunda kaynak-grup çifti (10.1.1.1, 239.1.1.1) için bir giriş olup olmadığını kontrol ediyoruz.
Ancak, çoklu yayın yönlendirmesinin etkinleştirilmediğini açıkça görüyoruz. Bunu etkinleştirelim.
Çözüm
R6'da çoklu yayın yönlendirmesini etkinleştiriyoruz.
Şimdi, son atlama yönlendiricisi R8'in mroute tablosunu kontrol edersek, kaynak grup çifti için (S, G) girdisine sahip olduğunu görebiliriz. Ayrıca, çoklu yayını gelen arayüz E0/1 üzerinden aldığını ve giden arayüz E1/0 üzerinden alıcıya gönderdiğini de görebiliriz.
Senaryo 2 - Bir arayüzde PIM etkinleştirilmemiş.
Özellikle sınav ortamında, IP Multicast ile karşılaşılan en yaygın ikinci sorun, MDT boyunca PIM'in etkinleştirilmemiş bir arayüz olmasıdır. IP multicast, IGP çalıştıran tüm bağlantılarda PIM etkinleştirilmiş tek bir unicast yönlendirme alanı içinde dağıtılmalıdır.
Senaryo 2.1 - Bir transit arayüzünde PIM etkinleştirilmemiş.
Sorun Belirtileri
PC2'nin multicast akışını (10.1.1.1, 239.1.1.1) almadığı bildirilmiştir.
Sorun Giderme Adımları
Şekil 2'de gösterilen sorun giderme mantığını izleyerek, son atlama yönlendiricisi R8'e giriş yaparak başlıyoruz. Her zaman yaptığımız ilk şey, 239.1.1.1 grubu için girişleri görmek üzere mroute tablosunu kontrol etmektir.
Yönlendiricinin PIM komşularını ve doğrudan bağlı alıcılarını yansıtan bir (*, G) girişi vardır - e0/1'in PIM komşuluğu varken, e1/0'ın doğrudan bağlı bir alıcısı vardır. Bu nedenle bu iki arayüz OIL'dedir.
Açıkça, (S, G) girişi yoktur, bu da çoklu yayın trafiğinin LHR'ye ulaşmadığı anlamına gelir. Bu nedenle, sorun trafiğin yolunda bir yerdedir. Bu örnekte, çoklu yayın yolunu LHR'den kaynağa doğrudan izleyeceğiz ve yolun nerede kırıldığını göreceğiz. Ardından doğrudan orada kontrol edeceğiz.
mtrace komutunun anlaşılması
Cisco cihazlarında IP çoklu yayın söz konusu olduğunda en kullanışlı sorun giderme araçlarından biri mtrace komutudur. Bu, bir alıcıdan çoklu yayın grubunun kaynağına doğru ters yolu izleyen bir kontrol düzlemi aracıdır. Büyük topolojilerde sorun alanını daraltmak için çok kullanışlıdır. Yüzlerce yönlendiriciye sahip bir ağ düşünün. Her birine giriş yapıp çoklu yayın yönlendirme tablosunu kontrol edemezsiniz. Sorunu birkaç cihaza indirgemeniz ve orada aramanız gerekiyor.
Başarılı bir mtrace örneği aşağıdaki çıktıda gösterilmiştir. mtrace komutuna kaynak IP, hedef IP ve grup IP adreslerini verdiğimize dikkat edin.
Kaynak, çoklu yayın trafiğinin kaynak adresidir. Örneğimizde bu, 10.1.1.1 olacaktır.
Hedef, çoklu yayının alıcısıdır. Örneğimizde bu, PC2 10.10.20.1 olacaktır.
Grup, çoklu yayın grup adresidir. Örneğimizde bu, 239.1.1.1 olacaktır.
Örnek, R8'den kaynağa başarılı bir mtrace işlemini göstermektedir. Çıktının ne gösterdiğini inceleyelim.
0. satır, işlemin alıcı 10.10.20.1 ile başladığını söylüyor.
-1. satır, R8 yönlendiricisini temsil ediyor.
-2. satır, R6 yönlendiricisini temsil ediyor.
-3. satır, R4 yönlendiricisini temsil ediyor.
-4. satır, R2 yönlendiricisini temsil ediyor.
-5. satır, kaynağa başarıyla ulaşabildiğimizi söylüyor.
Bu, alıcıdan kaynağa giden kontrol düzlemi yoludur. Veri düzleminin kontrol düzleminin tam tersi şekilde çalıştığını defalarca söyledik. Bu nedenle, bu çıktıyı aşağıdaki gibi çözebiliriz:
(10.1.1.1, 239.1.1.1) adresinden gelen çoklu yayın trafiği, 10.1.1.253 (kaynağa bağlı R2 arayüzü) tarafından alınır. 10.1.2.1 üzerinden iletilir.
Ardından, trafik 10.1.2.4 (R4) tarafından alınır. 10.1.6.1 üzerinden iletilir.
Ardından, trafik 10.1.6.2 (R6) tarafından alınır. 10.1.8.1 üzerinden iletilir.
Sonrasında, 10.1.8.3 (R8) trafiği alır ve 10.10.20.254 (alıcıya bağlı arayüz) üzerinden iletir.
Aşağıdaki şemayı kullanarak mtrace komutunun nasıl çalıştığını kısaca ele alalım.
Tanı aracının ilk önemli özelliği, IGMP protokolünü kullanmasıdır. Aşağıdaki üç tek yönlü mesajı kullanır:
IGMP Traceroute Sorgusu
IGMP Traceroute İsteği
IGMP Traceroute Yanıtı
mtrace komutunu çalıştırdığımız yönlendirici, dahili bir IGMP Traceroute Sorgusu oluşturur ve bu sorgu bir IGMP Traceroute İsteğine çevrilir. Bu İstek, Şekil 3'te gösterildiği gibi, kaynağa giden en kısa yoldaki bir sonraki yukarı yönlü yönlendiriciye yönlendirilmiş, tek yönlü olarak kapsüllenmiş bir IGMP paketidir. Kaynağa giden en kısa yoldaki her yönlendirici, kaynak ve çoklu yayın grubuyla ilgili yerel çoklu yayın yönlendirme bilgilerini ekler. Ardından, IGMP Traceroute İsteğini yukarı yöne yeniden gönderir. İşlem, IGMP Traceroute İsteği ilk atlama yönlendiricisine (FHR) ulaşana kadar tekrarlanır; bu yönlendirici her şeyi bir IGMP Traceroute Yanıtı'nda özetler ve isteği gönderene geri gönderir. Aşağıdaki ekran görüntüsü, yukarıdaki diyagramda IGMP Traceroute Yanıtını göstermektedir.
Yol üzerindeki bir yönlendirici, bir arıza nedeniyle IGMP Tracert İsteğini yukarı yöne iletemezse, hemen bir Yanıt paketi oluşturur. Bu paket, mtrace başlatıcısına geri iletilir. mtrace komutu, LHR'den kaynağa kadar çoklu yayın yolundaki arızaların hızlı bir şekilde tespit edilmesini sağlar.
Ayrıca, mtrace komutunun yalnızca son atlama yönlendiricisinden, aşağıda gösterildiği gibi, kaynağın IP adresini kullanarak çalıştırılabileceğine dikkat edin:
Laboratuvar örneğine geri dönelim.
mtrace'in ne yaptığını ve nasıl çalıştığını inceledikten sonra, R8'den kaynağa bir mtrace işlemi gerçekleştirelim ve ne gösterdiğine bakalım.
mtrace çıktısı, IP adresi 10.1.6.1 olan bir yönlendiricinin kaynağa giden bir çoklu yayın rotasına sahip olmadığını gösteriyor. Şekil 1'e bakarsanız, bunun R4 yönlendiricisi olduğunu görebilirsiniz. Giriş yapalım ve neler olduğunu görelim.
Açıkçası, R4'ün çoklu yayın grubu için (S, G) girişi vardır, bu da akışı aldığını gösterir. Ancak, alıcıya doğru olan arayüzün giden arayüz listesinde (OIL) olup olmadığını kontrol etmeliyiz.
PC2'ye giden arayüz E0/2'dir. Ancak, dikkat ederseniz, (S, G) girişinin OIL'inde yer almamaktadır. Bu, R4'ün PC2'ye çoklu yayın mesajları göndermediği anlamına gelir. (*, G) girişine dikkat ederseniz, e0/2 OIL'de yer almamaktadır, bu da R4'ün bu arayüzde bir PIM komşusuna sahip olmadığı anlamına gelir. Bu nedenle, öncelikle ethernet 0/2'de PIM'in etkin olup olmadığını kontrol etmek gerekir.
Yukarıdaki komut, PIM etkinleştirilmiş tüm arayüzleri gösterir. Açıkçası, 0/2 numaralı arayüzde PIM etkinleştirilmemiş. Hadi onu yapılandıralım.
Şimdi mroute tablosuna bakarsak, e0/2'nin OIL'de olduğunu görebiliriz.
Senaryo 2.2 - Alıcıya yönelik PIM etkinleştirilmemiş.
Sorun Belirtileri
PC2'nin çoklu yayın akışını (10.1.1.1, 239.1.1.1) almadığı bildirildi.
Sorun Giderme
Bu, sorun gidermesi çok kolay olan çok yaygın bir senaryodur. Her zaman son atlama yönlendiricisinden başlarız. LHR'ye giriş yapıp show IP mroute 239.1.1.1 komutunu çalıştırdığımızda, hemen (*, G) girişi olmadığını görürüz, bu da bağlı alıcı olmadığı anlamına gelir.
Eğer bağlı alıcıların olduğundan eminseniz, bağlı alıcıları görememenizin yalnızca iki nedeni vardır: ya alıcıya doğru PIM/IGMP etkinleştirilmemiştir ya da alıcının kendisi IGMP üyelik raporları göndermez.
Alıcıya doğru arayüzün PIM için etkinleştirilip etkinleştirilmediğini `show IP pim interface` komutuyla doğrulayabilirsiniz.
Senaryo 2.3 - Kaynağa doğru PIM etkinleştirilmemiş.
Sorun Belirtileri
Hem PC1 hem de PC2'nin çoklu yayın akışını (10.1.1.1, 239.1.1.1) almadığı bildirildi.
Sorun Giderme
Bu çok yaygın bir senaryo değil, ancak PIM'in çoklu yayın kaynağı için de etkinleştirilmesi gerektiğini hatırlatmak için burada belirtmemiz gerekiyor. PIM etkinleştirilmemişse, ilk atlama yönlendiricisi çoklu yayını hiç iletmez ve hiçbir alıcı hiçbir şey almaz.
Genellikle, alıcıların hiçbirinin belirli bir kaynaktan çoklu yayın almadığı söylendiğinde, sorunu kaynak segmentine indirgemek kolaydır.
Sorun giderme süreci aynıdır; öncelikle ilk atlama yönlendiricisinin mroute tablosunda bir giriş olup olmadığını kontrol ederiz. Eğer yoksa, bu, yönlendiricinin çoklu yayını alamadığı anlamına gelir çünkü kaynağa doğru olan arayüz PIM için etkinleştirilmemiştir.
Bunu ayrıca `show IP pim interface` komutunu kullanarak da doğrulayabilirsiniz.
Laboratuvar Topolojisi ve Başlangıç Durumu
Başlangıçtaki laboratuvar topolojisi aşağıdaki şemada gösterilmiştir. OSPFv2 kullanarak tam IP erişilebilirliğine sahip olduğumuzu fark edin. Tüm yönlendirici bağlantılarında PIM Yoğun modu yapılandırılmıştır. Kaynak, 239.1.1.1 grubunda çoklu yayın trafiği iletmektedir (239.1.1.1'e ping atılıyor).
Bu topolojiyi, farklı arızaları tanıtıp çözerek her sorun giderme senaryosunda kullanacağız. EVE-NG dosyasını dersin sonunda indirebilirsiniz.
Senaryo 1 - Yönlendiricide çoklu yayın yönlendirmesi etkinleştirilmemiş.
Özellikle sınav ortamlarında IP çoklu yayın ile ilgili en yaygın sorunlardan biri, yol üzerindeki bir yönlendiricinin çoklu yayın yönlendirmesi yapacak şekilde etkinleştirilmemiş olmasıdır.
Tüm Cisco IOS ve IOS-XE yönlendiricilerinde çoklu yayın yönlendirmesinin varsayılan olarak devre dışı bırakıldığını hatırlayın. Yönlendiricinin genel yapılandırma modunda aşağıdaki gibi tek bir CLI komutu yapılandırarak çoklu yayın yönlendirme işlevini etkinleştiriyoruz:
Kod:
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip multicast-routing
R1(config)# end
R1#Bir yönlendirici, çoklu yayın yönlendirmesi yapacak şekilde yapılandırılmamışsa, arayüzler arasında çoklu yayın trafiğini iletmez. Bu işlevi etkinleştirme işlemi manuel olduğundan, sınav/test ortamlarında sıklıkla yanlışlıkla unutulur veya kasıtlı olarak yapılandırılmış halde bırakılır.
Yönlendiricilerden birinin IP çoklu yayın yönlendirmesi ile yapılandırılmadığı bir topolojiyi nasıl sistematik olarak giderebileceğimizi görelim.
Sorun Belirtileri
PC2'nin çoklu yayın akışını (10.1.1.1, 239.1.1.1) alamadığı bildirildi.
PC2 gruba katılıyor (239.1.1.1 için IGMP Üyelik raporu gönderiyor)
PC2 kaynak IP adresine ping atabiliyor (tek noktaya yayın erişilebilirliği var)
Sorun Giderme
Unutmayın ki çoklu yayın dağıtım ağacı (MDT) alıcı tarafından başlatılır. Alıcının grup IP adresine katılması ve son atlama yönlendiricisinin kaynağa giden kaynak yol ağacının (SPT) oluşturulmasını başlatması sorumluluğundadır.
Çoklu yayın trafiği kaynaktan alıcılara doğru akar. Bu, veri düzlemidir ve aşağı yönlü yön olarak adlandırılır. Ancak, kontrol düzlemi işlemleri alıcıdan kaynağa doğru ters yönde gerçekleşir. Bu, yukarı yönlü yön olarak adlandırılır. Çoğu sorun veri düzleminden ziyade kontrol düzleminde meydana geldiğinden, sorun gidermenin her zaman alıcıların yerel ağ geçidi yönlendiricisinden yukarı yönlü olarak başlatılması önerilir.
UNUTULMAMALI:
Veri düzlemi aşağı yönlü çalışır.
Kontrol düzlemi yukarı yönlü çalışır.
Başlangıç noktası: LHR
Genel bir kural olarak, sorun gidermeye her zaman alıcı ve son atlama yönlendiricisinden başlarız ve ardından kaynağa doğru yukarı yönlü devam ederiz. Örneğimizde, PC2'nin son atlama yönlendiricisi R8'dir. R8'e giriş yapalım ve neler anlayabileceğimizi görelim.
İlk olarak, alıcının IGMP kullanarak çoklu yayın grup adresine katılıp katılmadığını kontrol ederiz.
Kod:
R8# sh ip igmp groups 239.1.1.1
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.1 Ethernet1/0 00:34:49 00:02:17 10.10.20.1PC2'nin 239.1.1.1 adresine başarıyla katıldığını görüyoruz.
Sonraki adım, yönlendiricide çoklu yayın yönlendirmesinin etkin olup olmadığını kontrol etmektir. Bunu doğrulamanın doğrudan ve dolaylı bir yolu vardır. Bunu aşağıdaki komutu kullanarak doğrudan kontrol edebiliriz.
Kod:
R8# sh ip multicast
Multicast Routing: enabled
Multicast Multipath: disabled
Multicast Route limit: No limit
Multicast Fallback group mode: Dense
Number of multicast boundaries configured with filter-autorp option: 0
MoFRR: Disabled
Multicast Service-Reflect Capabilities:
Unicast to MulticastAncak, bunu yönlendiricinin mroute tablosuna bakarak da kontrol edebiliriz. Çoklu yayın yönlendirmesi etkinleştirilmemişse, mroute tablosu doğrudan "IP Çoklu Yayın İletme etkinleştirilmedi" der.
Bir sonraki adım, LHR'nin yönlendirme tablosunu kontrol etmektir. R8, kaynaktan çoklu yayını alıyorsa, mroute tablosunda bir kaynak-grup çifti (S, G) girişi görmeyi bekleriz.
Kod:
R8# sh ip mroute 239.1.1.1
IP Multicast Routing Table
<lines omitted for brevity>
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
t - LISP transit group
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:41:45/00:02:23, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Dense, 00:41:17/stopped, flags:
Ethernet1/0, Forward/Dense, 00:41:45/stopped, flags:(S, G) çiftinin olmadığını görüyoruz. Bu nedenle, R8 kaynaktan gelen çoklu yayın akışını almıyor. Çoklu yayın trafiğinin ilk yayılımı son atlama yönlendiricisine ulaşmıyor. Dolayısıyla, kaynak ile son atlama yönlendiricisi arasındaki yolda bir sorun olmalı.
Yukarı Akışa Devam
Peki, nasıl devam edeceğiz? Kaynak IP adresi 10.1.1.1'e giden tekil rotayı izliyoruz. R8'de `show IP route 10.1.1.1` komutunu çalıştırdığımızda, bir sonraki atlama noktasının R6 olduğunu görüyoruz, bu yüzden R6'ya giriş yapıyoruz.
R6'da, öncelikle mroute tablosunda kaynak-grup çifti (10.1.1.1, 239.1.1.1) için bir giriş olup olmadığını kontrol ediyoruz.
Kod:
R6# sh ip mroute
IP Multicast Routing Table
<lines omitted for brevity>
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
t - LISP transit group
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
IP Multicast Forwarding is not enabled.Ancak, çoklu yayın yönlendirmesinin etkinleştirilmediğini açıkça görüyoruz. Bunu etkinleştirelim.
Çözüm
R6'da çoklu yayın yönlendirmesini etkinleştiriyoruz.
Kod:
R6# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R6(config)# ip multicast-routing
R6(config)# endŞimdi, son atlama yönlendiricisi R8'in mroute tablosunu kontrol edersek, kaynak grup çifti için (S, G) girdisine sahip olduğunu görebiliriz. Ayrıca, çoklu yayını gelen arayüz E0/1 üzerinden aldığını ve giden arayüz E1/0 üzerinden alıcıya gönderdiğini de görebiliriz.
Kod:
R8# sh ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag, l - LISP decap ref count contributor
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
t - LISP transit group
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 01:51:25/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Dense, 01:50:57/stopped, flags:
Ethernet1/0, Forward/Dense, 01:51:25/stopped, flags:
(10.1.1.1, 239.1.1.1), 00:00:28/00:02:31, flags: T
Incoming interface: Ethernet0/1, RPF nbr 10.1.8.1
Outgoing interface list:
Ethernet1/0, Forward/Dense, 00:00:28/stopped, flags:Senaryo 2 - Bir arayüzde PIM etkinleştirilmemiş.
Özellikle sınav ortamında, IP Multicast ile karşılaşılan en yaygın ikinci sorun, MDT boyunca PIM'in etkinleştirilmemiş bir arayüz olmasıdır. IP multicast, IGP çalıştıran tüm bağlantılarda PIM etkinleştirilmiş tek bir unicast yönlendirme alanı içinde dağıtılmalıdır.
Senaryo 2.1 - Bir transit arayüzünde PIM etkinleştirilmemiş.
Sorun Belirtileri
PC2'nin multicast akışını (10.1.1.1, 239.1.1.1) almadığı bildirilmiştir.
Sorun Giderme Adımları
Şekil 2'de gösterilen sorun giderme mantığını izleyerek, son atlama yönlendiricisi R8'e giriş yaparak başlıyoruz. Her zaman yaptığımız ilk şey, 239.1.1.1 grubu için girişleri görmek üzere mroute tablosunu kontrol etmektir.
Kod:
R8#sh ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag, l - LISP decap ref count contributor
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
t - LISP transit group
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 06:04:51/00:02:12, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Dense, 06:04:24/stopped, flags:
Ethernet1/0, Forward/Dense, 06:04:51/stopped, flags:Yönlendiricinin PIM komşularını ve doğrudan bağlı alıcılarını yansıtan bir (*, G) girişi vardır - e0/1'in PIM komşuluğu varken, e1/0'ın doğrudan bağlı bir alıcısı vardır. Bu nedenle bu iki arayüz OIL'dedir.
Açıkça, (S, G) girişi yoktur, bu da çoklu yayın trafiğinin LHR'ye ulaşmadığı anlamına gelir. Bu nedenle, sorun trafiğin yolunda bir yerdedir. Bu örnekte, çoklu yayın yolunu LHR'den kaynağa doğrudan izleyeceğiz ve yolun nerede kırıldığını göreceğiz. Ardından doğrudan orada kontrol edeceğiz.
mtrace komutunun anlaşılması
Cisco cihazlarında IP çoklu yayın söz konusu olduğunda en kullanışlı sorun giderme araçlarından biri mtrace komutudur. Bu, bir alıcıdan çoklu yayın grubunun kaynağına doğru ters yolu izleyen bir kontrol düzlemi aracıdır. Büyük topolojilerde sorun alanını daraltmak için çok kullanışlıdır. Yüzlerce yönlendiriciye sahip bir ağ düşünün. Her birine giriş yapıp çoklu yayın yönlendirme tablosunu kontrol edemezsiniz. Sorunu birkaç cihaza indirgemeniz ve orada aramanız gerekiyor.
Başarılı bir mtrace örneği aşağıdaki çıktıda gösterilmiştir. mtrace komutuna kaynak IP, hedef IP ve grup IP adreslerini verdiğimize dikkat edin.
Kod:
R8# mtrace 10.1.1.1 10.10.20.1 239.1.1.1
(source, destination, group)
Type escape sequence to abort.
Mtrace from 10.1.1.1 to 10.10.20.1 via group 239.1.1.1
From source (?) to destination (?)
Querying full reverse path...
0 10.10.20.1
-1 10.10.20.254 ==> 10.1.8.3 PIM [10.1.1.0/24]
-2 10.1.8.1 ==> 10.1.6.2 PIM [10.1.1.0/24]
-3 10.1.6.1 ==> 10.1.2.4 PIM [10.1.1.0/24]
-4 10.1.2.1 ==> 10.1.1.253 PIM_MT [10.1.1.0/24]
-5 10.1.1.1Kaynak, çoklu yayın trafiğinin kaynak adresidir. Örneğimizde bu, 10.1.1.1 olacaktır.
Hedef, çoklu yayının alıcısıdır. Örneğimizde bu, PC2 10.10.20.1 olacaktır.
Grup, çoklu yayın grup adresidir. Örneğimizde bu, 239.1.1.1 olacaktır.
Örnek, R8'den kaynağa başarılı bir mtrace işlemini göstermektedir. Çıktının ne gösterdiğini inceleyelim.
0. satır, işlemin alıcı 10.10.20.1 ile başladığını söylüyor.
-1. satır, R8 yönlendiricisini temsil ediyor.
-2. satır, R6 yönlendiricisini temsil ediyor.
-3. satır, R4 yönlendiricisini temsil ediyor.
-4. satır, R2 yönlendiricisini temsil ediyor.
-5. satır, kaynağa başarıyla ulaşabildiğimizi söylüyor.
Bu, alıcıdan kaynağa giden kontrol düzlemi yoludur. Veri düzleminin kontrol düzleminin tam tersi şekilde çalıştığını defalarca söyledik. Bu nedenle, bu çıktıyı aşağıdaki gibi çözebiliriz:
(10.1.1.1, 239.1.1.1) adresinden gelen çoklu yayın trafiği, 10.1.1.253 (kaynağa bağlı R2 arayüzü) tarafından alınır. 10.1.2.1 üzerinden iletilir.
Ardından, trafik 10.1.2.4 (R4) tarafından alınır. 10.1.6.1 üzerinden iletilir.
Ardından, trafik 10.1.6.2 (R6) tarafından alınır. 10.1.8.1 üzerinden iletilir.
Sonrasında, 10.1.8.3 (R8) trafiği alır ve 10.10.20.254 (alıcıya bağlı arayüz) üzerinden iletir.
Aşağıdaki şemayı kullanarak mtrace komutunun nasıl çalıştığını kısaca ele alalım.
Tanı aracının ilk önemli özelliği, IGMP protokolünü kullanmasıdır. Aşağıdaki üç tek yönlü mesajı kullanır:
IGMP Traceroute Sorgusu
IGMP Traceroute İsteği
IGMP Traceroute Yanıtı
mtrace komutunu çalıştırdığımız yönlendirici, dahili bir IGMP Traceroute Sorgusu oluşturur ve bu sorgu bir IGMP Traceroute İsteğine çevrilir. Bu İstek, Şekil 3'te gösterildiği gibi, kaynağa giden en kısa yoldaki bir sonraki yukarı yönlü yönlendiriciye yönlendirilmiş, tek yönlü olarak kapsüllenmiş bir IGMP paketidir. Kaynağa giden en kısa yoldaki her yönlendirici, kaynak ve çoklu yayın grubuyla ilgili yerel çoklu yayın yönlendirme bilgilerini ekler. Ardından, IGMP Traceroute İsteğini yukarı yöne yeniden gönderir. İşlem, IGMP Traceroute İsteği ilk atlama yönlendiricisine (FHR) ulaşana kadar tekrarlanır; bu yönlendirici her şeyi bir IGMP Traceroute Yanıtı'nda özetler ve isteği gönderene geri gönderir. Aşağıdaki ekran görüntüsü, yukarıdaki diyagramda IGMP Traceroute Yanıtını göstermektedir.
Yol üzerindeki bir yönlendirici, bir arıza nedeniyle IGMP Tracert İsteğini yukarı yöne iletemezse, hemen bir Yanıt paketi oluşturur. Bu paket, mtrace başlatıcısına geri iletilir. mtrace komutu, LHR'den kaynağa kadar çoklu yayın yolundaki arızaların hızlı bir şekilde tespit edilmesini sağlar.
Ayrıca, mtrace komutunun yalnızca son atlama yönlendiricisinden, aşağıda gösterildiği gibi, kaynağın IP adresini kullanarak çalıştırılabileceğine dikkat edin:
Kod:
R8# mtrace 10.1.1.1Laboratuvar örneğine geri dönelim.
mtrace'in ne yaptığını ve nasıl çalıştığını inceledikten sonra, R8'den kaynağa bir mtrace işlemi gerçekleştirelim ve ne gösterdiğine bakalım.
Kod:
R8# mtrace 10.1.1.1 10.10.20.1 239.1.1.1
Type escape sequence to abort.
Mtrace from 10.1.1.1 to 10.10.20.1 via group 239.1.1.1
From source (?) to destination (?)
Querying full reverse path...
0 10.10.20.1
-1 10.10.20.254 ==> 10.1.8.3 PIM [10.1.1.0/24]
-2 10.1.8.1 ==> 10.1.6.2 PIM [10.1.1.0/24]
-3 10.1.6.1 ==> 0.0.0.0 None No routemtrace çıktısı, IP adresi 10.1.6.1 olan bir yönlendiricinin kaynağa giden bir çoklu yayın rotasına sahip olmadığını gösteriyor. Şekil 1'e bakarsanız, bunun R4 yönlendiricisi olduğunu görebilirsiniz. Giriş yapalım ve neler olduğunu görelim.
Kod:
R4# sh ip mroute 239.1.1.1
IP Multicast Routing Table
<lines omitted for brevity>
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
t - LISP transit group
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 06:59:41/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Dense, 06:59:14/stopped, flags:
Ethernet0/0, Forward/Dense, 06:59:14/stopped, flags:
Ethernet1/0, Forward/Dense, 06:59:41/stopped, flags:
(10.1.1.1, 239.1.1.1), 00:00:02/00:03:01, flags: T
Incoming interface: Ethernet0/1, RPF nbr 10.1.3.1*
Outgoing interface list:
Ethernet1/0, Forward/Dense, 00:00:02/stopped, flags:
Ethernet0/0, Prune/Dense, 00:00:02/00:02:59, flags: AAçıkçası, R4'ün çoklu yayın grubu için (S, G) girişi vardır, bu da akışı aldığını gösterir. Ancak, alıcıya doğru olan arayüzün giden arayüz listesinde (OIL) olup olmadığını kontrol etmeliyiz.
Kod:
R4# sh ip route 10.10.20.1
Routing entry for 10.10.20.0/24
Known via "ospf 1", distance 110, metric 30, type intra area
Last update from 10.1.6.2 on Ethernet0/2, 07:00:19 ago
Routing Descriptor Blocks:
* 10.1.6.2, from 10.10.20.254, 07:00:19 ago, via Ethernet0/2
Route metric is 30, traffic share count is 1PC2'ye giden arayüz E0/2'dir. Ancak, dikkat ederseniz, (S, G) girişinin OIL'inde yer almamaktadır. Bu, R4'ün PC2'ye çoklu yayın mesajları göndermediği anlamına gelir. (*, G) girişine dikkat ederseniz, e0/2 OIL'de yer almamaktadır, bu da R4'ün bu arayüzde bir PIM komşusuna sahip olmadığı anlamına gelir. Bu nedenle, öncelikle ethernet 0/2'de PIM'in etkin olup olmadığını kontrol etmek gerekir.
Kod:
R4# sh ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
10.1.3.2 Ethernet0/0 v2/D 1 30 1 10.1.3.2
10.1.2.4 Ethernet0/1 v2/D 3 30 1 10.1.3.1
0.0.0.0 Ethernet0/3 v2/D 0 30 1 0.0.0.0
10.10.10.254 Ethernet1/0 v2/D 0 30 1 10.10.10.254Yukarıdaki komut, PIM etkinleştirilmiş tüm arayüzleri gösterir. Açıkçası, 0/2 numaralı arayüzde PIM etkinleştirilmemiş. Hadi onu yapılandıralım.
Kod:
R4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# int e0/2
R4(config-if)# ip pim dense-mode
*Jul 7 15:35:41.986: %PIM-5-NBRCHG: neighbor 10.1.6.2 UP on interface Ethernet0/2
*Jul 7 15:35:41.988: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 10.1.6.2 on interface Ethernet0/2
R4(config-if)# endŞimdi mroute tablosuna bakarsak, e0/2'nin OIL'de olduğunu görebiliriz.
Kod:
R4#sh ip mroute 239.1.1.1
IP Multicast Routing Table
<lines omitted for brevity>
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
t - LISP transit group
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 07:05:10/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Dense, 00:00:41/stopped, flags:
Ethernet0/1, Forward/Dense, 07:04:42/stopped, flags:
Ethernet0/0, Forward/Dense, 07:04:42/stopped, flags:
Ethernet1/0, Forward/Dense, 07:05:10/stopped, flags:
(10.1.1.1, 239.1.1.1), 00:05:31/00:01:19, flags: T
Incoming interface: Ethernet0/1, RPF nbr 10.1.3.1*
Outgoing interface list:
Ethernet0/2, Forward/Dense, 00:00:41/stopped, flags:
Ethernet1/0, Forward/Dense, 00:05:31/stopped, flags:
Ethernet0/0, Prune/Dense, 00:05:31/00:00:27, flags: ASenaryo 2.2 - Alıcıya yönelik PIM etkinleştirilmemiş.
Sorun Belirtileri
PC2'nin çoklu yayın akışını (10.1.1.1, 239.1.1.1) almadığı bildirildi.
Sorun Giderme
Bu, sorun gidermesi çok kolay olan çok yaygın bir senaryodur. Her zaman son atlama yönlendiricisinden başlarız. LHR'ye giriş yapıp show IP mroute 239.1.1.1 komutunu çalıştırdığımızda, hemen (*, G) girişi olmadığını görürüz, bu da bağlı alıcı olmadığı anlamına gelir.
Kod:
R8# sh ip mroute 239.1.1.1
Group 239.1.1.1 not foundEğer bağlı alıcıların olduğundan eminseniz, bağlı alıcıları görememenizin yalnızca iki nedeni vardır: ya alıcıya doğru PIM/IGMP etkinleştirilmemiştir ya da alıcının kendisi IGMP üyelik raporları göndermez.
Alıcıya doğru arayüzün PIM için etkinleştirilip etkinleştirilmediğini `show IP pim interface` komutuyla doğrulayabilirsiniz.
Senaryo 2.3 - Kaynağa doğru PIM etkinleştirilmemiş.
Sorun Belirtileri
Hem PC1 hem de PC2'nin çoklu yayın akışını (10.1.1.1, 239.1.1.1) almadığı bildirildi.
Sorun Giderme
Bu çok yaygın bir senaryo değil, ancak PIM'in çoklu yayın kaynağı için de etkinleştirilmesi gerektiğini hatırlatmak için burada belirtmemiz gerekiyor. PIM etkinleştirilmemişse, ilk atlama yönlendiricisi çoklu yayını hiç iletmez ve hiçbir alıcı hiçbir şey almaz.
Genellikle, alıcıların hiçbirinin belirli bir kaynaktan çoklu yayın almadığı söylendiğinde, sorunu kaynak segmentine indirgemek kolaydır.
Sorun giderme süreci aynıdır; öncelikle ilk atlama yönlendiricisinin mroute tablosunda bir giriş olup olmadığını kontrol ederiz. Eğer yoksa, bu, yönlendiricinin çoklu yayını alamadığı anlamına gelir çünkü kaynağa doğru olan arayüz PIM için etkinleştirilmemiştir.
Kod:
R1# sh ip mroute 239.1.1.1
Group 239.1.1.1 not foundBunu ayrıca `show IP pim interface` komutunu kullanarak da doğrulayabilirsiniz.