IGMP
İnternet Group Management Protokol)
Last updated
İnternet Group Management Protokol)
Last updated
IGMP; Multicast yayınlara erişmek isteyen kullanıcıların bu yayınlara yani multicast gruplara bağlanmak ve ilgili trafiği almak için kullandığı bir protocoldür. IGMP hem kullanıcı cihazlarda hemde yönlendirici cihazda aktif halde olmalıdır.
Bir kullanıcı belirli bir multicast grubuna ait yayını almak istediğinde ,bu multicast grubuna yönelik IGMP join isteğini kendi alanındaki yönlendiriciye gönderir. Eğer yönlendiricinin kullanıcıyı karşılayan arayüzünde icmp aktifleştirilmemişse istek gözardı edilir ve kullanıcı yayın alamaz.
Kullanıcı cihazlarında icmp, yayına ulaşmak için kullanılan programlar vasıtasıyla çalıştırılır. Örneğin bir video yayınına ulaşmak istediğimizde o yayına ait multicast grup adresini bilgisayarımıza video yöneticiye yazdığımızda program ilgili multicast gruba yönelik icmp join isteğini otomatik olarak gönderir.
IGMP sadece kullanıcı cihazlarıyla yönlendirici arasında çalışan Layer 3 bir protocoldür. Dolayısıyla aradaki Layer 2 ağ anahtarlarını igmp desteklemesi gerekmez. Ancak multicast verimliliği için layer 2 ağ anahtarlarının bu paketleri incelemesi gereklidir. Bu durumda ağ anahtarları igmp paketlerinin içeriğini inceler.
Kendileri igmp çalıştırmaz Igmpnin hala kullanılan 3 versiyonu vardır. RFC 112 ile tanımlanan igmp version 1 en eski versiyondur ve artık nadiren kullanılmaktadır. RFC 2236 igmp version 2 yi tanımlamıştır. Günümüzde yoğun olarak kullanılmaktadır
RFC 3376 ile tanımlanır ve genellikle SSM (Source Specific Multicast) ağlarda kullanılır.
İGmp version1 nin artık nadiren kullanılmasının sebebi, Bu versiyonun kullanıcıya multicast yayına bağlandıktan sonra artık yayını istemediğinde ,yayını istemediğini belirtmesine izin vermemesidir. Dolayısıyla kullanıcı yayını istememesine rağmen multicast trafik ağda akmaya devam eder. Kullanıcı yayını almayıp paketleri düşürse de bu durum ağda verimsizilik oluşturur.
İGMPv2 ile birlikte igmp leave özelliği kullanılmaya başlanmış
Ve kullanıcıların artık yayını istemediğini ivedilikle yönlendiriciye göstermesi imkanı sağlamıştır. Igmp ipv4 protokolü üzerine çalışır.
Ve igmp versiyonundan bağımsız olarak ipv4 başlığındaki protocol numarası 2 olarak tanımlanmıştır. Igmp paketleri ipv4 ttl (time to live ) değeri 1 olarak gönderir.
TTL; ipv4 başlığında 8 bitlik bir alandır. Ve alacağı değer ipv4 paketini gönderen tarafından belirlenir. İpv4 paketi alıcısına ulaşana kadar her yönlendirici değerini 1 eksiltir ve TTL değeri 0’a düşerse paketler göz ardı edilerek. Daha fazla işleme tabi tutulmaz.
Şekilde herbir alanın ne ifade ettiği ve nasıl kullanıldığı açıklanmıştır.
Type : Bu alan kullanıcılar ve yönlendiricler tarafından bu igmp mesajının hangi tipte olduğunu belirlemek için kullanılır. 5 farklı değer alabilir. Birincisi igmpv2 membership report
IGMPv2 Membership Report:
Type değeri hexedecimal olarak 16. Kullanıcılar tarafından IGMPv2'de bir multicast gruba bağlanmak istediklerini belirtmek için kullanılır.
Type değeri hexedecimal olarak 12.IGMPv1 kullanıcıları tarafından bir multicast gruba bağlanmak istediklerini belirtmek için kullanılır.
IGMPv2 Leave Group:
Type değeri hexedecimal olarak 17. IGMPv2 kullanıcıları tarafından artık daha önce bağlandıkları yayından ayrılmak istediklerini belirtmek için kullanılır.
General Membership Query
Type değeri hexedecimal olarak 11. yönlendiriciler tarafından IGMP aktifleştirilmiş arayüzlerinden bağlı bulunduğu ağda, herhangi bir multicast yayına isteyen kullanıcı olup olmadığını sorgulamak için kullanılır. Bu mesaj 224.0.0.1'e (tüm multicast alıcıları adresi) group alanı 0.0.0.0 olarak belirtilerek gönderilir. Burada amaç bu sorgunun herkese ve her multicast gruba yönelik olduğunu belirtmektir.
General Specific Query
Type değeri hexedecimal olarak 11. yönlendiriciler tarafından IGMPv2 leave paketleri alındığında ,belirli bir multicast grubunda başka kullanıcı kalıp kalmadığını belirlemek için yapılan sorgudur.
Maksimum Response Type =>Bu alan sadece genel bir gruba özel sorgu yani query tiplerinde kullanıcının ne kadar süre içinde bağlanma isteğini gönderebileceğini belirtir. Saniyenin 10 da 1i birim olarak alınır.
Checksum :>Bu alan igmp mesajının yol boyunca herhangi bir değişikliğe uğrayıp uğramadığını kontrolü için kullanılır.
Grup Adres :>Bu alan bir multicat gruba bağlanmak için üyelik raporu yani join isteği gönderildiğinde ya da bir multicast gruptan ayrılmak için leave mesajı gönderildiğinde ilgili multicast grubunun ipv4 adresi olarak belirlenir. Ipv4 adresleri 32 bit olduğu için bu alan 4 byte olarak belirlenmiştir.
IGMP, bir yerel ağda kullanıcı ve yönlendirici arasında kullanıcılar hangi yayını istiyor,bir multicast grupta başka kullanıcı kaldı mı gibi sorulara verimli bir şekilde cevap vermek için tasarlanmıştır. Bu amaçla kullanıcıların bir multicast grubuna yönelik gruba bağlanma ve ayrılma isteklerinin yanı sıra, daha önce belirtildiği gibi yönlendiriciler belirli aralıklara genel sorgu paketleri gönderir.
Ayrıca her leave mesajı aldığında,o grupta başka kullanıcı kalıp kalmadığını kontrol etmek için gruba özel sorgu gönderir, hiç cevap alamazsa o gruba yönelik yayını iletmeyi durdurur.
Bu sorgulara sadece bir kullanıcının cevap vermesi trafiğin devamı için yeterlidir. Ancak bu mekanizma bazı sorunlar yaratabilir.
Örneğin belirli bir multicast grubun 50 kullanıcısı var ve bunların 1'i ayrılma isteği göndermiş olduğu durum değerlendirilirse, yönlendirici bu leave mesajı üzerine bu gruba yönelik sorgu gönderecek ve diğer 49 kullanıcı bu sorguya cevap verecektir ve bu durum her kullanıcı ayrıldığında tekrarlanacaktır.
Bu verimsizliği önlemek için IGMP kullanıcıları yönlendiriciler tarafından sorgu mesajlarındaki max response time alanını kullanarak her biri bu süre içerisinde rastlantısal bir süre belirler ve belirledikleri süre içerisinde başka bir kullanıcının bağlanma isteğini görürlerse, sorguya cevap vermezler.
Böylelikle örnekteki durumda sadece en düşük süreyi belirleyen kullanıcıya cevap verecek diğer 48 kullanıcı sorguya cevap vermeyecek, gereksiz bağlanma istekleri önlenmiş olacaktır.
Bu mekanizma gereksiz leave mesajlarının da önüne geçer. Aynı örnek üzerinden devam edersek, sorgu mesajına cevap veren kullanıcı,belirli bir süre sonra artık bu multicast grubundan ayrılmak isterse leave mesajı göndermek zorundadır, ancak diğer 48 kullanıcıdan herhangi bir ayrılmak isterse, leave mesajı göndermeden ayrılabilecektir.
Bir yerel ağda, daha doğru bir söylemle bir broadcast domain'de birden fazla yönlendirici varsa sorgu mesajlarını hangi yönlendiricinin göndereceğini belirlemek için bir querier (sorgulayıcı) seçimi yapılır.
Bir subnet'te en düşük arayüz ipv4 adresine sahip yönlendirici, o subnet için querier olur. Diğer yönlendiriciler, 224.0.0.1 adresine querier tarafından sorgu mesajları gönderildiği sürece sessiz kalır.
Igmpv2 de bir kullanıcı belirli bir multicast gruba yönelik üyelik sorgu raporu gönderdiğinde bu multicast trafiğin yayının hangi kaynaktan gelmesi gerektiğine yönelik bir seçimde bulunamaz çünkü igmpv2 paket yapısında kaynak belirtebileceği bir alan yoktur. Igmpv3; Kullanıcıya kaynak belirtebilme hatta istediği ya da istemediği kaynakların listesini belirtebildiği özelliği eklenmesiyle geliştirilmiştir. Igmpv3te kullanıcılar bir multicast grubuna bağlanmak için gönderdikleri üyelik raporunda 2 ayrı mod kullanabilirler. Include modu olarak bilinen modda kullanıcılar multicast trafiğinin gelmesini istedikleri kaynak ip adresini ya da adreslerini specific olarak belirtirler. Bunun tersi olarak exclude modda ise kullanıcılar multicast trafiği almak istemedikleri kaynak ip adres ya da adreslerini belirtir.
Bu durumda belirttikleri ip adresten dışındaki kaynaklardan ip adresi alabilirler.
Eğer excluded modda çalışırken kaynak ip adresi belirtmezlerse bu herhangi bir kaynaktan gelen trafiği Kabul edecekleri anlamına gelirki bu durum birebir olarak igmpv2 çalışma modudur.
Igmp kullanılan versiyondan bağımsız olarak kullanıcı ile yönlendirici arasında çalışan ve ipv4 protokolü üzerinde çalışan bir protokoldür. Ancak tipik bir yerel ağ tasarımında kullanıcılar önce erişim seviyesini yereldeki ağ anahtarlarına bağlanırlar ve kullanıcılar igmp paketleri bu anahtarların üzerinden geçerek yönlendiriciye iletir. Ağ anahtarları her ne kadar igmp paketlerini ne kaynak ne de hedef ip adresleri olmasalar da bu paketleri incelemek durumundadırlar.
Bu yerel ağda multicast verimliliği için zorunlu bir uygulamadır. Igmp snoofing çalıştırılmazsa ağ anahtarları gelen multicast trafiği ile vlandaki tüm portlara gönderecektir. Dolayısıyla multicast trafiği istenmeyen kullanıcılarda bu trafiği kendi cihazlarının ağ kartlarında görecekler.
Her ne kadar bu paketleri göz ardı etselerde bu durum hem cihazlarda hem de trafiği istemeyen kullanıcıların bant genişliklerinde olumsuz etki oluşturacaktır.
İgmp snoofing olarak bilinen RFC 4541 ile tanımlanmış olan bu yöntemde ağ anahtarları kullanıcılardan gelen igmp join mesajlarını inceler. Ve ilgili multicast kurulu mac adresini kullanıcının port numarası ile birlikte kendi mac adresi tablosuna ekler.Aslında bu davranış biçimi normal mac adres tablosu çalışma mantığına aykırıdır. Çünkü ağ anahtarları mac adres tablolarına kullanıcılardan gelen unicast framlerinin kaynak mac adreslerini gelen portu vlan numarası ile birlilte saklayarak doldururlar. Ancak multicast ip ve mac adresleri hiçbir zaman bir ip paketinin ya da Ethernet framenin kaynak bölümünde bulunmazlar.
Her zaman hedef bölümünde bulunurlar. Bu nedenle igmp snoofing gelen frameleri değil igmp join mesajlarını inceleyerek ilgili multicast kurulu mac adresini kullanıcın port numarası ile birlikte kendi mac adresi tablosuna ekler. Dolayısıyla bir multicast paket geldiğinde trafik sadece daha önceden mac adres tablosunda bu multicast trafik için tanımlanmış portlara gönderilecek ve gereksiz kaynak israfının önüne geçilmiş olacaktır.
MLD den bahsedecek olursak ; MLD == Multicast Listener Discovery Protocoldür.
Ipv6 yönlendiricilerin multicast dinleyicilerine doğrudan bağlı arabirimlerinde çok noktaya yayım, veri paketleri alacabilecek biçimde yapılandırılmış düğümlerin keşfedilmesini sağlar. Protocol özellikle hangi çok noktaya yayın adreslerini komşu düğümler için ilgi çekici olduğunu keşfeder. Ve bu bilgiyi çok noktaya yayın veri paketlerinin akışı hakkında kararlar alan etkin çok noktaya yayın yönlendirme protokolüne sağlar.
