Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
Multicast; canlı video, finansal market feed’leri ve low-latency yayınlarda kritik. PIM-SM (Sparse Mode) ortamlarında sorunların büyük kısmı şu 5 köke iner: (1) IGMP join yok, (2) RP mapping/reachability, (3) RPF hatası, (4) (*,G)/(S,G) state oluşmuyor, (5) ACL/VRF/NAT etkisi.
Aşağıdaki 7 adım, sahada “kaynak mı alıcı mı?” ayrımını hızlı yapıp kök nedeni daraltmak için optimize edilmiştir.
1) Kaynak mı alıcı mı? Hızlı yön ayrımı (sanity check)
Amaç: Sorunu “downstream (alıcı)” mı yoksa “upstream (kaynak/RP)” mı olduğunu ayır.
Not: Multicast’a “ping” her platformda anlamlı olmayabilir. Ama hızlı bir sanity check olarak “paket çıkıyor mu/geliyor mu” ayrımına yardım eder. En sağlıklısı: kaynak tarafında UDP gönder + alıcıda capture.
Örnek:
ping 239.1.1.1 source 10.1.1.10 repeat 5Yorum:
- Alıcı tarafında “hiçbir şey yoksa” önce IGMP membership ve RPF/ACL kontrolüne gidin.
- Kaynak paket üretiyor mu? SPAN/capture ile doğrulayın (7. adım).
2) IGMP Topology & Membership (alıcı tarafı)
Amaç: Host gerçekten IGMP join atıyor mu? SVI/Interface doğru mu?
show ip igmp groups
show ip igmp interface GigabitEthernet1/0/1Şüpheli durumlar
- Hiç group yok → host join atmıyor, VLAN yanlış, IGMP querier yok (L2’de)
- Interface IGMP disabled → SVI/port yanlış
Hızlı aksiyon
- L2 switch’te IGMP snooping / querier kontrolü
- Host/VLAN/ACL/endpoint FW kontrolü
3) RPF (Reverse Path Forwarding) kontrolü — en sık kök neden
Amaç: Router “kaynağa dönüş yolu”nu doğru interface’ten görüyor mu?
show ip mroute 239.1.1.1
show ip route <source-ip>Şüpheli
RPF fail/ “incoming interface mismatch”- Source’a giden en iyi route yanlış next-hop’tan gidiyor
Hızlı aksiyon
- IGP’de source prefix yönünü düzelt (OSPF/ISIS/BGP)
- Gerekirse source’a static route ile RPF’i düzelt (geçici çözüm)
Kural: Multicast’ta “unicast routing doğru değilse multicast asla düzgün olmaz.”
4) RP (Rendezvous Point) mapping + reachability
Amaç: RP doğru mu ve her yerde aynı mı görünüyor?
show ip pim rp
show ip pim rp mapping
show ip pim neighborŞüpheli
- RP mapping yok / farklı router’larda farklı RP
- RP’ye unicast reachability yok (loopback advertise edilmemiş)
- Auto-RP/BSR mesajları ACL ile engelleniyor
Hızlı aksiyon
- RP loopback’in IGP’de announce edildiğini doğrula
- PIM neighbor ilişkileri ve kontrol-plane ACL’leri gözden geçir
5) PIM State: (*,G) ve (S,G) oluşuyor mu?
Amaç: Tree kuruldu mu? Join’lar nereye gidiyor?
show ip mroute
show ip pim sparse-mode interface
show ip mroute 224.0.0.0/4Beklenen
- İlk aşamada genelde
(*,G)görülür (RP tree) - Kaynağa geçişte
(S,G)oluşur (SPT switch)
Şüpheli
- (*,G) yok → IGMP/RP mapping/RPF tarafına dön
- (S,G) yok → kaynak/RP path, SPT switch veya RPF sorunu
6) ACL / NAT / VRF etkileri (sessiz killer)
Amaç: Multicast trafiği “policy” ile düşüyor mu?
show access-lists
show running-config | include igmp|pim|access-listŞüpheli
- ACL’ler IGMP (proto 2) veya UDP multicast’ı drop ediyor
- VRF ortamında multicast “VRF scope” yanlış
- NAT: Multicast NAT’lanmaz; yanlış policy/inspection multicast’ı bozabilir
Hızlı aksiyon
- Multicast için IGMP + UDP/224.0.0.0/4 izinleri netleştir
- VRF’te multicast routing konfigürasyon scope’unu doğrula
7) İnline doğrulama: SPAN / packet capture / NetFlow
Amaç: Paket gerçekten geliyor mu, nerede kayboluyor?
SPAN örneği:
monitor session 1 source interface Gi1/0/1
monitor session 1 destination interface Gi1/0/48Yorum
- SPAN’da multicast görülüyorsa ama alıcı alamıyorsa → genelde RPF / state / L2 snooping
- SPAN’da hiç yoksa → sorun ingress tarafında (kaynak çıkmıyor, upstream drop)
📌 Hızlı İpuçları / Common Pitfalls
- RP loopback IGP’de düzgün advertise edilmezse: “RP unreachable” klasik arızadır.
- L2’de IGMP snooping/querier yoksa join’lar boşa gider veya flood olur.
- MTU/fragmentation: GRE/IPsec üstünde multicast sık patlar (özellikle jumbo/overhead).
- Timer’ları değiştirmeden önce state ve RPF’i düzelt; timer tuning çoğu zaman “yanlış ilacı” verir.
Cem Kemal Erbaş sitesinden daha fazla şey keşfedin
Subscribe to get the latest posts sent to your email.
