Ağ İzlemede SNMP mi NetFlow mu: Seçim Neden Tartışmalı Kalır?

Ağ izleme, bir sistem yöneticisinin veya network mühendisinin en temel sorumluluklarından biri. Trafik yavaşladığında, bir uygulama yanıt vermediğinde veya güvenlik açığı şüphesi olduğunda, ilk baktığımız yerlerden biri network katmanı oluyor. Bu noktada elimizde iki güçlü, ancak farklı felsefelerle çalışan araç var: SNMP ve NetFlow. Hangisinin daha iyi olduğu sorusu, yirmi yıldır sektörde duyduğum ve hala net bir “bu daha iyi” cevabı olmayan bir tartışma konusu. Benim tecrübemde, bu iki teknolojiyi birbirinin yerine koymak değil, tamamlayıcı olarak kullanmak çoğu zaman en doğru çözümü sunuyor.

Bir üretim firmasının ERP’sinde, geciken sevkiyat raporlarının sebebini ararken, önce sunucu kaynaklarına baktım, sonra veritabanı sorgularına… Ancak asıl sorun network tarafında, farklı VLAN’lar arası iletişimde yaşanan yavaşlıklarda çıktı. Bu tür senaryolarda doğru izleme verilerine sahip olmak, sorunu kökünden çözmek için kritik önem taşıyor. Peki, SNMP mi yoksa NetFlow mu, nerede ve nasıl kullanılmalı? Bu yazıda kendi deneyimlerimden yola çıkarak bu ikilemi derinlemesine inceleyeceğim.

SNMP: Geleneksel Gözlemcinin Gücü ve Sınırlamaları

SNMP (Simple Network Management Protocol), adından da anlaşılacağı gibi, ağ cihazlarını yönetmek ve izlemek için tasarlanmış basit bir protokol. 90’lardan beri hayatımızda ve hala birçok cihazda varsayılan izleme yöntemi olarak kullanılıyor. Temelde cihazların Management Information Base (MIB) adı verilen veri yapılarını sorgulayarak çalışıyor. Bu MIB’ler, cihazın CPU kullanımı, bellek durumu, disk alanı, ağ arayüzlerinin durumu, gelen/giden trafik sayacı gibi birçok bilgiyi içeriyor.

Benim için SNMP, bir cihazın genel sağlık durumuna hızlıca bakmak için çok kullanışlı. Örneğin, bir switch’in bir portunun fiziksel olarak yukarıda mı, aşağıda mı olduğunu veya bir sunucunun CPU’sunun yüzde kaç kullanıldığını SNMP ile saniyeler içinde görebiliyorum. Özellikle SNMPv2c versiyonu, basit konfigürasyonu sayesinde hızlıca devreye alınabiliyor. Ancak bu basitliğin getirdiği bazı sınırlamalar da var.

# SNMPv2c ile bir cihazın arayüz bilgilerini sorgulama örneği
# 'public' community string'i ve 192.168.1.1 IP adresi varsayılmıştır.
# ifDescr, arayüz açıklamalarını listeler.
snmpwalk -v 2c -c public 192.168.1.1 .1.3.6.1.2.1.2.2.1.2

# Çıktı örneği:
# IF-MIB::ifDescr.1 = STRING: "lo"
# IF-MIB::ifDescr.2 = STRING: "eth0"
# IF-MIB::ifDescr.3 = STRING: "wlan0"

SNMP’nin en büyük dezavantajı, veriyi “polling” tabanlı toplaması. Yani, izleme sunucusu belirli aralıklarla (genellikle 1-5 dakika) cihazları sorgular. Bu da daha düşük granülerlik anlamına geliyor. Eğer anlık bir trafik artışı veya kısa süreli bir kesinti yaşanırsa, polling aralığına denk gelmezse bu durumu kaçırabiliriz. Polling aralığı geniş tutulduğunda, kısa süreli ama kritik ağ tıkanıklıkları aralığa denk gelmediği için ancak kullanıcı şikayetleri sonrası fark edilebilir. Ayrıca, v1 ve v2c versiyonlarındaki community string’lerin şifrelenmeden gönderilmesi ciddi bir güvenlik açığı oluşturuyor. SNMPv3 bu sorunları çözse de, konfigürasyonu çok daha karmaşık hale geliyor ve her cihazda desteklenmeyebiliyor.

NetFlow (ve IPFIX): Derinlemesine Trafik Analizi

NetFlow, Cisco tarafından geliştirilen ve daha sonra IETF standardı olan IPFIX (IP Flow Information Export) ile genelleşen, ağ trafiğini “akış” bazında analiz eden bir protokol. SNMP’nin aksine, NetFlow cihazın kendisinden trafiğin özetini (kaynak/hedef IP, portlar, protokol, bayt/paket sayısı gibi) bir kolektöre “export” etmesiyle çalışıyor. Bu, polling yerine push tabanlı bir model olduğu için çok daha detaylı ve anlık trafik görünürlüğü sağlıyor.

Benim için NetFlow, network’ün DNA’sını okumak gibi bir şey. Hangi kullanıcının hangi uygulamayı ne kadar kullandığını, hangi sunucunun dışarıya ne kadar trafik attığını, hatta bir DDoS saldırısının kaynağını ve hedefini anında görebiliyorum. Beklenmedik bir trafik artışı yaşandığında, NetFlow kayıtları hangi IP’lerin anormal istekler gönderdiğini hızlıca ortaya koyar. Bu detay seviyesi, SNMP’nin sadece “porttan ne kadar trafik geçti” bilgisinin çok ötesinde.

// Basitleştirilmiş bir NetFlow / IPFIX kaydı örneği
{
  "source_ip": "192.168.1.10",
  "destination_ip": "10.0.0.5",
  "source_port": 54321,
  "destination_port": 80,
  "protocol": 6, // TCP
  "bytes_in": 123456,
  "packets_in": 120,
  "start_time": "2026-06-02T10:00:00Z",
  "end_time": "2026-06-02T10:00:15Z",
  "interface_in": 1,
  "interface_out": 2
}

NetFlow’un gücü tartışılmaz, ancak onun da kendi sınırlamaları var. Birincisi, her ağ cihazı NetFlow export özelliğini desteklemiyor. Özellikle eski veya düşük maliyetli switch’lerde bu özelliği bulmak zor olabilir. İkincisi, NetFlow verisi toplamak ve analiz etmek için güçlü bir kolektör altyapısı gerekiyor. Gelen verinin hacmi çok büyük olabiliyor; saniyede binlerce akış kaydı işlemek, yüksek disk I/O ve CPU gereksinimi yaratıyor. Üçüncüsü, NetFlow doğrudan cihazın CPU veya bellek kullanımı gibi sistem seviyesi metriklerini sağlamaz; sadece trafikle ilgili bilgi verir. Kolektörün disk I/O’su yetersiz kaldığında kritik trafik verileri rahatlıkla kaybedilebilir; bu yüzden depolama katmanının kapasitesi en az toplama kadar önemlidir. Disk I/O performans sorunları ve çözümleri yazımda buna benzer bir durumu ele almıştım.

Temel Farklar ve Benim Gözümden Trade-off’lar

SNMP ve NetFlow arasındaki temel fark, topladıkları veri türü ve toplama yöntemlerinde yatıyor. SNMP, cihazın “sağlık durumu” ve “performans metrikleri” (CPU, RAM, port durumu, toplam trafik sayacı) hakkında bilgi verirken, NetFlow “kimin kimle ne konuştuğu” hakkında detaylı trafik akışı bilgisi sağlar. Bu ayrım, seçim yaparken dikkate almamız gereken en kritik nokta.

Bu tablo, aslında bir trade-off matrisi. Eğer sadece bir cihazın yaşayıp yaşamadığını ve portlarından ne kadar trafik geçtiğini merak ediyorsam, SNMP çok daha basit ve yeterli bir çözüm. Ama ağımda kimin kimle konuştuğunu, hangi uygulamanın bant genişliğini tükettiğini veya olası bir saldırının detaylarını öğrenmek istiyorsam, NetFlow’dan başka çarem kalmıyor. VLAN segmentasyonu yaparken trafik akışını NetFlow ile izlemeden kural devreye almamak, yanlış bir kuralın hangi trafiği kestiğini hızlıca görmeyi sağlar. Aksi takdirde, “ping atıyorum ama uygulamam çalışmıyor” şikayetleriyle boğuşmak zorunda kalırdım.

Gerçek Dünya Senaryolarında Uygulama ve Deneyimlerim

Tecrübelerimde, bu iki protokolü farklı senaryolarda nasıl kullandığıma dair birkaç örnek vermek istiyorum. Bu örnekler, seçimin neden karmaşık kaldığını daha iyi açıklayacaktır.

Senaryo 1: Basit Bir Ofis Ağı ve SNMP

Bir KOBİ’nin network altyapısını yönetirken, bütçe kısıtlamaları ve basitlik öncelikliydi. Elimde birkaç yönetilebilir switch ve bir firewall vardı. Bu cihazların port durumlarını, uplink hızlarını ve temel CPU/bellek kullanımlarını izlemek benim için yeterliydi. SNMPv2c ile bu işi kolayca hallettim. Her 5 dakikada bir polling yaparak temel metrikleri topladım ve Nagios gibi basit bir izleme sistemiyle alarmlar kurdum.

# eth0 arayüzünden geçen toplam bayt sayısını alma (OID değişebilir)
# Bu değer sürekli artar ve farkı alarak trafik hızını hesaplarız.
snmpget -v 2c -c public 192.168.1.1 IF-MIB::ifInOctets.2

# Çıktı örneği:
# IF-MIB::ifInOctets.2 = Counter32: 1234567890

Bu yaklaşım, “bir port down oldu mu?”, “internet hattında anormallik var mı?” gibi sorulara hızlı cevaplar sağlıyordu. Ancak, “X kullanıcısı neden interneti yavaşlatıyor?” gibi daha spesifik sorular geldiğinde, SNMP’nin yetersiz kaldığını gördüm. Sadece toplam trafiği görmek, detaylı bir analiz için yeterli değildi. Bu durum, SNMP’nin genel sağlık kontrolü için iyi, ancak derinlemesine trafik analizi için zayıf kaldığını gösteren tipik bir örnekti.

Senaryo 2: Büyük Ölçekli Üretim Ortamı ve NetFlow

Bir üretim firmasının ERP’sini geliştirirken, kritik operatör ekranlarının ve üretim hattı entegrasyonlarının (iSCSI tedarik zinciri gibi) ağ performansına bağımlılığı çok yüksekti. Burada sadece cihazların genel sağlığı değil, belirli bir üretim hattının, belirli bir sunucuyla olan iletişiminin ne kadar bant genişliği kullandığı veya anlık olarak herhangi bir anomali olup olmadığı hayati önem taşıyordu. O dönem, network ekibiyle birlikte, ana router ve switch’ler üzerinde NetFlow export’u etkinleştirdik.

# Linux üzerinde bir NetFlow kolektörü için nfdump veya benzeri bir araçla
# toplanan veriden belirli bir kaynak IP'den gelen trafiği sorgulama örneği.
# Bu bir komut değil, mantıksal sorgu örneğidir.
nfdump -r /data/nfcapd.202606021000 -A srcip -s ip/bytes -n 10 'src ip 172.16.0.10'

# Çıktı örneği:
# Date flow start        Duration Proto      Src IP Addr:Port          Dst IP Addr:Port   Packets    Bytes Flows
# 2026-06-02 10:00:05.123 10.000 TCP   172.16.0.10:45678 -> 10.0.0.5:8080      100    12000     1
# 2026-06-02 10:00:10.456 12.000 UDP   172.16.0.10:12345 -> 10.0.0.8:53        20      500     1

NetFlow verileri sayesinde, bir operatör ekranında yaşanan yavaşlamanın, network’teki anlık bir yüksek trafikten mi yoksa sunucudaki bir problemden mi kaynaklandığını çok daha hızlı anlayabildim. Hatta bir defasında, üretim ağına sızmaya çalışan bir iç tehdidi, anormal portlara giden yüksek NetFlow trafiği sayesinde tespit ettik. ZTNA (Zero Trust Network Access) mimarisini kurarken de, egress kontrolünü NetFlow verileriyle sürekli doğruladım. Hangi iç kaynağın dışarıdaki hangi hedefe ne kadar trafik attığını görmek, güvenlik politikalarının doğru çalıştığından emin olmamı sağladı. Zero Trust Network Access mimarisi ve uygulama adımları yazımda bu konuya daha detaylı değinmiştim.

Bu iki senaryo, SNMP ve NetFlow’un birbirinin yerine geçemeyecek kadar farklı kullanım alanlarına sahip olduğunu açıkça gösteriyor. Biri genel sağlık, diğeri detaylı trafik analizi için vazgeçilmez.

Güvenlik ve Performans Perspektifinden Değerlendirme

Ağ izleme çözümlerini seçerken sadece veri türüne değil, aynı zamanda güvenlik ve performans etkilerine de dikkat etmek gerekiyor. Her iki protokolün de kendine göre avantajları ve dezavantajları var.

SNMP Güvenliği: Daha önce de bahsettiğim gibi, SNMPv1 ve v2c versiyonları güvenlik açısından zayıf. community string’lerin şifrelenmeden ağda dolaşması, bir saldırganın snmpwalk gibi araçlarla cihaz hakkında hassas bilgiler edinmesine olanak tanır. Güvenlik denetimlerinde eski bir switch’in varsayılan public community string’i ile hala erişilebilir kaldığına sık rastlanır. Bu, potansiyel bir içeriden tehdidin tüm network haritasını çıkarmasına yetecek bir açıktır. SNMPv3 ise authentication (MD5/SHA) ve encryption (DES/AES) mekanizmaları sunarak bu güvenlik açıklarını kapatıyor, ancak konfigürasyonu daha zahmetli.

NetFlow Güvenliği: NetFlow verisinin kendisi, hangi IP adresinin hangi portlara ne kadar trafik attığı gibi hassas bilgiler içerdiği için dikkatle korunmalıdır. Kolektör sunucusunun güvenliği, toplanan verinin bütünlüğü ve gizliliği açısından kritik öneme sahiptir. Eğer bir saldırgan NetFlow kolektörüne erişim sağlarsa, ağdaki tüm trafik desenlerini ve potansiyel zafiyetleri görebilir. Bu nedenle, NetFlow kolektörleri genellikle izole edilmiş ağ segmentlerinde tutulur ve sıkı erişim kontrolleriyle korunur. Ayrıca, ZTNA (Zero Trust Network Access) mimarilerinde NetFlow, egress trafiğini izleyerek yetkisiz dışa açılan bağlantıları tespit etmek için güçlü bir kanıt aracı olarak kullanılır.

Performans Etkileri:

• SNMP: Polling sıklığına bağlı olarak ağ ve cihaz üzerinde bir yük oluşturur. Çok sık polling, özellikle düşük güçlü cihazlarda CPU yükünü artırabilir ve ağ bant genişliğini tüketebilir. Benim tecrübemde, yüzlerce cihazı saniyede bir polling yapmak, ortalama bir izleme sunucusunu ve ağ trafiğini zorluyordu. Bu durum, Linux’taki journald’nin RateLimitIntervalSec ayarı gibi, bir tür “kendi kendini koruma” mekanizması ihtiyacını doğuruyor.
• NetFlow: Ağ cihazında akışları işlemek ve kolektöre göndermek için CPU kaynaklarına ihtiyaç duyar. Özellikle yüksek trafik hacimli router’larda bu ek yük, cihazın ana görevlerini (routing) etkileyebilir. Kolektör tarafında ise, gelen binlerce akış kaydını depolamak, işlemek ve sorgulanabilir hale getirmek için yüksek disk I/O, bellek ve CPU kapasitesi gerekir. Bir defasında yüksek kapasiteli bir anahtarın üzerinde NetFlow’u etkinleştirdiğimde, CPU kullanımının belirgin biçimde arttığını ve bu durumun kritik routing operasyonlarını etkilemeye başladığını görmüştüm. Bu yüzden NetFlow’u etkinleştirmeden önce cihazın performans profilini dikkatlice değerlendirmek gerekiyor.

Her iki protokol de doğru yapılandırılmazsa kendi içinde performans darboğazları yaratabilir. Önemli olan, izleme ihtiyacımızı karşılayacak minimum kaynakla maksimum görünürlüğü sağlamaktır.

Benim Seçimim: Hibrit Yaklaşım ve Geleceğe Bakış

Tecrübemin bana öğrettiği bir şey varsa, o da teknoloji dünyasında genellikle tek bir “en iyi” çözümün olmadığıdır. SNMP ve NetFlow arasındaki seçim de tam olarak böyle bir durum. Benim net pozisyonum, bu iki protokolü birbirinin rakibi olarak değil, tamamlayıcısı olarak görmektir. Ağ izlemede en etkili yaklaşım, bir hibrit model kullanmaktır.

Hibrit Yaklaşımımın Temelleri:

1. Genel Sağlık ve Sistem Metrikleri için SNMP:

   • Tüm ağ cihazlarımın (switch’ler, router’lar, firewall’lar) ve sunucularımın (Linux servisleri, CPU, RAM, disk kullanımı) genel sağlık durumunu, port durumlarını ve toplam trafik sayaçlarını SNMPv3 ile belirli aralıklarla (genellikle 1-5 dakika) izlerim.
   • Bu verilerle temel alarmlar (port down, CPU %90 üzeri, disk doluluğu %80) oluştururum.
   • Kapasite planlaması için uzun dönemli trendleri bu veriler üzerinden takip ederim.

2. Derinlemesine Trafik Analizi ve Güvenlik için NetFlow/IPFIX:

   • Kritik router’lar ve anahtar switch’ler üzerinde NetFlow/IPFIX export’unu etkinleştiririm. Bu, özellikle VLAN’lar arası trafiği, şirket çıkışlarındaki akışları ve kritik sunucu farm’larındaki iletişimi izlemek için vazgeçilmezdir.
   • NetFlow verilerini kullanarak anormal trafik desenlerini (DDoS saldırıları, port taramaları, yetkisiz iç iletişimler) tespit ederim.
   • QoS (Quality of Service) politikalarının doğru çalışıp çalışmadığını doğrulamak için NetFlow verilerini analiz ederim. Örneğin, DSCP marking’in uçtan uca doğru iletildiğini bu verilerle kontrol edebilirim. Örneğin ses paketlerinin kalitesindeki bir düşüşün router’daki yanlış DSCP yeniden işaretlemesinden kaynaklandığı bu verilerle ortaya çıkabilir.
   • Uygulama bazında bant genişliği tüketimini izleyerek performans sorunlarının kaynağını hızlıca belirlerim.

Bu hibrit yaklaşım, bana hem ağ cihazlarımın genel sağlığı hakkında hızlı bir genel bakış sunuyor hem de gerektiğinde trafik akışının en ince detayına inme yeteneği veriyor. Tek bir araca bağlı kalmak yerine, her iki protokolün de güçlü yönlerini kullanarak ağımı daha kapsamlı bir şekilde izliyorum. Bu, “tek bir araçla her şeyi yaparım” yanılgısına düşmekten çok daha pratik ve güvenilir bir yöntem.

Geleceğe Bakış: Ağ izleme teknolojileri de sürekli gelişiyor. eBPF (extended Berkeley Packet Filter) gibi teknolojiler, Linux çekirdeği seviyesinde akış benzeri verileri toplama imkanı sunarak NetFlow’a benzer bir derinliği host seviyesinde sağlıyor. Ayrıca, yapay zeka ve makine öğrenimi algoritmaları, toplanan SNMP ve NetFlow verileri üzerinde çalışarak manuel eşik tanımlamalarına gerek kalmadan anormallikleri otomatik olarak tespit etme potansiyeli taşıyor. Benzer AI tabanlı anomali tespiti yaklaşımları başka alanlarda da işe yarıyor ve gelecekte ağ izleme çözümlerini daha proaktif ve öngörülü hale getirecek.

Net pozisyonum: Ağ izlemede “SNMP mi NetFlow mu?”