EtherNet/IP Ağlarında Multicast Trafiği ve IGMP Snooping Ayarı

EtherNet/IP hattında “ağ yavaşladı, I/O bağlantıları ara ara kopuyor” şikâyetinin arkasında çoğu zaman tek bir mekanizma vardır: switch multicast I/O trafiğini tanımadığı için onu her porta taşırır (flooding). Kabloya, cihaza, firmware’e bakılır; asıl sorun switch yapılandırmasındadır. Aşağıda CIP mesajlaşma türlerinden başlayıp RPI’nin ağ yüküne etkisini, multicast bağlantıların neden sorun çıkardığını, IGMP snooping ve querier’ın doğru yerleşimini ve unicast–multicast tercihini anlatıyoruz. Sonda örnek bir bant hesabı ve switch kontrol listesi var.

CIP mesajlaşma türleri: implicit ve explicit

EtherNet/IP, CIP (Common Industrial Protocol) uygulama katmanını standart Ethernet ve TCP/IP üzerinde taşır. CIP iki tür mesajlaşma kullanır ve ağdaki davranışları birbirinden çok farklıdır:

Özellik	Explicit mesajlaşma	Implicit (I/O) mesajlaşma
Amaç	Parametre okuma/yazma, teşhis, yapılandırma	Çevrimsel I/O verisi
Taşıma	TCP 44818 (bazı servisler UDP 44818)	UDP 2222
Zamanlama	İstek–yanıt, düzensiz	RPI ile periyodik
Adresleme	Unicast	Unicast veya multicast

Endüstriyel ağ altyapısının tasarımını implicit trafik belirler. Bir I/O bağlantısında iki yön vardır: scanner’dan (genellikle PLC) adaptöre giden O→T (originator to target) ve adaptörden scanner’a dönen T→O (target to originator). O→T yönü unicast’tir; T→O yönü bağlantı ayarına göre unicast ya da multicast olabilir. Multicast T→O, aynı adaptör verisini birden fazla tüketicinin (örneğin iki PLC veya bir “listen only” bağlantısı) tek akıştan alabilmesi için tasarlanmıştır.

RPI ve paket hızının ağ yüküne etkisi

RPI (Requested Packet Interval), bir bağlantıda verinin hangi aralıkla gönderileceğini belirler. Her yön için saniyedeki paket sayısı yaklaşık 1000 / RPI(ms) kadardır. 10 ms RPI’li bir bağlantı her yönde saniyede 100 paket, toplamda 200 paket üretir.

EtherNet/IP cihazlarında asıl sınır çoğunlukla bant genişliği değil, cihazın saniyede işleyebildiği paket sayısıdır (pps). Bir iletişim modülünün ya da adaptörün belirli bir pps kapasitesi vardır; bu kapasite hem kendi bağlantılarının paketlerini hem de ona ulaşan istenmeyen trafiği kapsar. Gereksiz kısa RPI bu kapasiteyi boşa harcar. RPI’yi kontrol uygulamasının gerçek tepki ihtiyacına göre seçin: hızlı bir kesme pozisyonu ile bir tank seviyesi aynı RPI’yi istemez. Sahada en sık gördüğümüz ayar, bütün bağlantıların “nasılsa hızlı olsun” diye en kısa RPI’ye çekilmesidir. Rockwell Automation gibi üreticiler modül bazında pps ve bağlantı kapasitesini hesaplayan planlama araçları sunar; büyük projelerde bu hesap tasarım aşamasında yapılır, devreye almada değil.

Multicast I/O bağlantıları ve taşma (flooding) sorunu

Switch unicast çerçeveleri MAC adres tablosuna göre yalnız hedef porta iletir. Multicast çerçevelerde varsayılan davranış farklıdır: switch hangi portun bu gruba ilgi duyduğunu bilmiyorsa çerçeveyi aynı VLAN’daki tüm portlara gönderir. Yönetilmeyen switch’te bu davranışı değiştiremezsiniz.

Örnek bir hücre düşünün: 30 adaptörün multicast T→O akışları VLAN’daki her porta ulaşır. Bu trafikle hiç ilgisi olmayan HMI’lar, sürücüler, kameralar ve diğer adaptörler de her paketi alıp işlemek ve atmak zorunda kalır. İşlem kapasitesi sınırlı saha cihazlarında bu yük, kendi bağlantılarının paketlerini kaçırmalarına ve bağlantı zaman aşımına yol açar. Belirti tipiktir: hatta cihaz sayısı arttıkça başlayan, kökü tek bir cihazda bulunamayan rastgele kopmalar. Arıza bir cihazda değil, ağın tamamında.

EtherNet/IP multicast adresleri yönetimsel kapsamlı 239.192.x.x aralığından atanır ve multicast paketlerinin TTL değeri varsayılan olarak 1’dir; bu trafik router’dan geçmez, VLAN içinde kalır. Yani sorun VLAN sınırında durur. I/O trafiğini makine veya hücre bazında ayrı VLAN’lara bölmek, multicast etkisini sınırlamanın ilk adımıdır. VLAN planlamasının genel ilkeleri için kurumsal ağda VLAN tasarımı yazısına bakabilirsiniz.

IGMP snooping ve querier: doğru yapılandırma

IGMP snooping, switch’in cihazlar ile multicast router arasındaki IGMP mesajlarını dinleyerek hangi portun hangi multicast grubuna üye olduğunu öğrenmesidir. Scanner multicast bağlantı açtığında ilgili gruba IGMP üyelik raporu (membership report) gönderir; switch bu raporu görür ve grup trafiğini yalnız o porta iletir. Snooping davranışının ayrıntıları RFC 4541 içinde tanımlanmıştır.

Snooping tek başına yetmez. Üyelik bilgisinin güncel kalması için ağda periyodik IGMP sorgusu (query) gönderen bir querier bulunmalıdır. Querier yoksa cihazlar düzenli rapor göndermez; switch’teki üyelik kayıtları zaman aşımına uğrar (IGMPv2 varsayılanlarıyla yaklaşık 260 saniye) ve switch modeline göre trafik ya yeniden tüm portlara taşar ya da hiç iletilmez. İkinci durum sahada şöyle görünür: ağ kurulur, her şey çalışır, birkaç dakika sonra I/O bağlantıları kopar. Teşhisi zor bir arızadır, çünkü ilk testlerde her şey normaldir.

Querier yerleşiminde uyulacak kurallar:

• Her VLAN’da bir querier yeterlidir; birden fazla aday varsa en düşük IP adresine sahip olan seçilir. Hangisinin seçileceğini bilinçli belirleyin.
• Snooping yapan switch’ler querier’ın bulunduğu portu “multicast router portu” kabul eder ve tüm multicast trafiğini bu porta da iletir. Querier ağın ucundaki bir switch’te kalırsa bütün multicast trafiği omurga bağlantılarından o noktaya taşınır. Querier’ı I/O trafiğinin zaten toplandığı merkezi switch’e koyun.
• Ring veya STP topolojisinde topoloji değişikliği sırasında bazı switch’ler multicast trafiğini geçici olarak taşırır. Ring kurtarması ile bu taşma aynı anda olursa ring’e rağmen bağlantı kopmaları görülebilir; üreticinin topoloji değişikliği sonrası taşma davranışını kontrol edin.

Cisco IOS tabanlı endüstriyel switch’lerde örnek yapılandırma ve doğrulama komutları:

! Snooping global olarak açık olmalı (Catalyst ve IE ailesinde varsayılan)
ip igmp snooping

! Bu switch’i snooping querier olarak etkinleştir
ip igmp snooping querier
ip igmp snooping querier address 10.20.30.2

! I/O VLAN’ında SVI adresi (querier kaynağı)
interface Vlan30
 ip address 10.20.30.2 255.255.255.0

! Doğrulama
show ip igmp snooping querier
show ip igmp snooping groups vlan 30
show ip igmp snooping mrouter vlan 30

Konsolda ilk bakılacak yer show ip igmp snooping groups çıktısıdır: her multicast grubu yalnız ilgili scanner portlarıyla eşleşmelidir. Grup listesi boşsa ya querier çalışmıyor ya da cihazlar IGMP raporu göndermiyor. Yönetilmeyen switch’ler ve cihazların gömülü switch’leri bu filtrelemeyi yapamayabilir; zincir (daisy chain) bağlantılı uzun hatlarda multicast trafiğin gömülü switch’ler boyunca nasıl iletildiğini cihaz dokümanından kontrol edin.

Unicast mı multicast mı: bağlantı türü seçimi

Güncel EtherNet/IP scanner’ların çoğu T→O yönü için unicast bağlantıyı destekler; bağlantı türü mühendislik aracında her bağlantı için ayrı seçilir. Seçim kriterleri:

• Verinin tek bir tüketicisi varsa unicast seçin. Taşma riski ortadan kalkar, IGMP yapılandırmasına bağımlılık azalır.
• Aynı veriyi birden fazla controller tüketiyorsa (örneğin listen-only bağlantılar veya birden fazla PLC’nin aynı giriş modülünü izlemesi) multicast, adaptörün aynı veriyi birden fazla kez göndermesini önler; bu durumda IGMP snooping ve querier zorunludur.
• Bağlantı router veya firewall’dan geçecekse multicast TTL 1 nedeniyle uygun değildir; unicast kullanılır.
• Eski cihazlar yalnız multicast destekleyebilir. Bu cihazlar için ayrı VLAN ve snooping planlayın.

Örnek bant genişliği hesabı

Aşağıdaki hesap, mertebeyi göstermek için varsayımlara dayalı bir örnek hesaptır; gerçek projede değerleri cihaz verisinden hesaplayın.

Varsayımlar:
  Adaptör sayısı        : 30
  RPI                   : 10 ms  → yön başına 100 paket/s
  Çerçeve boyu (kabloda): ~150 bayt (başlıklar, preamble ve çerçeve arası boşluk dahil varsayım)

Scanner’a bağlı port:
  Paket hızı = 30 × 100 × 2 yön = 6.000 paket/s
  Bant       = 6.000 × 150 × 8   ≈ 7,2 Mbit/s

Multicast T→O, snooping YOK (her porta taşar):
  Her porta ulaşan istenmeyen trafik = 30 × 100 = 3.000 paket/s ≈ 3,6 Mbit/s

3,6 Mbit/s, 100 Mbit/s’lik bir port için önemsiz görünür. Sorun bant değil. Sorun paket sayısı. Her adaptör kendi bağlantısı için saniyede birkaç yüz paket işlerken, kendisiyle ilgisi olmayan saniyede 3.000 paketi de almak zorunda kalır. Hattaki adaptör sayısı arttıkça ya da RPI kısaldıkça bu yük doğrusal büyür. Cihazın veri sayfasındaki pps kapasitesini bu istenmeyen trafikle birlikte değerlendirin.

Switch yapılandırma kontrol listesi

• I/O trafiği makine/hücre bazında ayrı VLAN’larda; IT trafiği ve mühendislik PC’leri bu VLAN’larda değil.
• Multicast kullanılan her VLAN’da IGMP snooping açık ve tek, bilinçli seçilmiş bir querier var.
• Querier, I/O trafiğinin toplandığı merkezi switch’te; mrouter portları beklenen uplink’ler.
• show ip igmp snooping groups çıktısı scanner portlarıyla uyumlu; boş grup listesi yok.
• Bilinmeyen multicast trafiğinin davranışı (taşma veya engelleme) switch dokümanından doğrulanmış.
• Tek tüketicili bağlantılarda T→O unicast seçilmiş.
• RPI değerleri uygulama ihtiyacına göre belirlenmiş; modül pps kapasitesi hesaplanmış.
• Yönetilmeyen switch’ler multicast kullanılan VLAN’larda yok veya etkileri hesaba katılmış.
• Topoloji değişikliği sonrası multicast taşma davranışı ring testinde gözlenmiş.

Bu kontroller switch seçiminden bağımsız değildir; IGMP snooping ve querier desteği, endüstriyel switch seçimi sırasında veri sayfasında aranacak satırlardandır. Paket yakalama ve sayaç analiziyle teşhis için PROFINET arıza teşhisi adımları yazısındaki yöntem EtherNet/IP ağlarına da büyük ölçüde uyarlanabilir. EtherNet/IP ağının tasarımı ve PLC’ler arası bağlantı planlaması için endüstriyel Ethernet ve fabrika ağları ile PLC–PLC ve PLC–sunucu entegrasyonu sayfalarımıza göz atabilirsiniz. Protokolün spesifikasyonları ve kurulum kılavuzları ODVA tarafından yayımlanır.

Sık sorulan sorular

EtherNet/IP ağında IGMP snooping neden gereklidir?

Multicast I/O bağlantıları kullanılıyorsa switch, snooping olmadan bu trafiği VLAN’daki tüm portlara taşırır. Saha cihazları istenmeyen paketleri işlemek zorunda kalır ve kendi bağlantılarında zaman aşımı yaşayabilir.

IGMP querier olmadan snooping çalışır mı?

Kısa süre çalışıyor gibi görünür. Querier yoksa cihazlar periyodik üyelik raporu göndermez, switch’teki kayıtlar zaman aşımına uğrar ve trafik switch modeline göre ya tüm portlara taşar ya da hiç iletilmez.

Unicast T→O bağlantısı ne zaman tercih edilmeli?

Adaptör verisinin tek bir tüketicisi varsa veya bağlantı router ya da firewall üzerinden geçecekse unicast seçin. Multicast yalnız aynı veriyi birden fazla controller tüketiyorsa avantaj sağlar.

RPI değerini kısaltmak performansı artırır mı?

Yalnız uygulama gerçekten daha hızlı veri istiyorsa. Gereksiz kısa RPI, cihazların saniyede işleyebildiği paket kapasitesini tüketir ve ağdaki tüm bağlantıların kararlılığını düşürebilir.