Switch SNMP Yapılandırması: SNMPv3, Trap ve Inform

Switch SNMP yapılandırması, switch’in port sayaçlarını ve durumunu bir izleme sistemine açması ve önemli bir olayda o sisteme kendiliğinden haber göndermesi için yapılan ayarlardır. İzleme sistemi switch’i düzenli aralıklarla yoklar ve trafik grafiğini bu yoklamalardan çizer. Olay anındaki haber ise trap ya da inform olarak gelir.

Bu rehberde lab switch’imde SNMP’yi kuruyorum ve dört şeyi ölçüyorum:

1. Yanlış kimlik. SNMPv3 yanlış parolaya eski yöntemden farklı ne cevap verir?
2. Sayaçlar. İzleme sistemi switch’ten tam olarak neyi okur, grafiği neyden çizer?
3. Adres kısıtı. Community string’e konan IP kısıtı bildirimleri de etkiler mi?
4. Onay. Inform, alıcı cevap vermeyince trap’ten farklı davranır mı?

Kümenin benzetmesiyle switch bir süpermarket şubesidir. Genel müdürlük şubenin sayaçlarını, örneğin kapıdaki müşteri sayacını, düzenli aralıklarla okur; bu, SNMP yoklamasıdır. Şubede alarm çalınca şube merkezi kendisi arar; bu da trap’tir. Inform, “aldınız mı?” diye onay isteyen alarmdır.

Bu yazı, switch yapılandırma rehberimizdeki kontrol listesinin 10. adımıdır ve Kurumsal Network Kurulumu hizmetimizin switch tarafına aittir. Aynı işi müşterilerimizin ağında nasıl yürüttüğümüzü switch kurulumu ve VLAN yapılandırma hizmeti sayfamızda anlattık.

SNMP’nin yönetici-ajan mekanizmasını, MIB ve OID kataloğunu ve sürümlerin farkını SNMP nedir yazımızda anlattık. Bu yazı o protokolün switch üzerindeki yapılandırmasıdır. Bir önceki adımda switch’in olay kayıtlarını log sunucusuna göndermiştik; onu switch syslog ayarı yazımızda anlattık.

Switch SNMP Yapılandırmasından Önce: İzleme Sistemi ve Community String

Switch’in açtığı sayaçları bir izleme sisteminin okuması gerekir. Bu rehber, izleme sistemini zaten kurduğunuzu varsayar; lab’da SNMP ile trafik grafiği çizen sistemi Cacti kurulumu rehberimizde kurduk.

İki ön koşul daha var:

• Community string daraltılmış olmalı. Lab switch’imde SNMP daha önce v2c community string ile açılmış ve switch sıkılaştırma turunda yalnız izleme sunucusunun adresine daraltılmıştı. Community string ağda düz metin gider; bunu pakette gösterdiğimiz ölçüm SNMP nedir yazısında.
• Komut kaydı kapalı olmalı. SNMPv3 kullanıcısını tanımlayan komut iki parola taşır. Switch’te komut kaydı açıksa bu satır parolalarıyla birlikte log sunucusuna gider; bunu switch syslog ayarı yazısının komut kaydı bölümünde ölçtük. Bu turu komut kaydı kapalıyken yaptım.

Switch SNMP Yapılandırması: SNMPv3 Kullanıcısı

Community string bir parola değil, düz metin giden bir etikettir. İzleme için bu yüzden bir v3 kullanıcısı tanımladım. Kullanıcı hazır salt okunur gruba giriyor, kimlik doğrulama SHA, şifreleme AES:

configure
snmp-server user izleme DefaultRead auth-sha IzlemeAuth2026 priv-aes128 IzlemePriv2026
exit

Konum ve iletişim alanları da doldurulmalı. Lab switch’imde ikisi snmp-server location ve snmp-server contact satırlarıyla daha önce yazılmıştı. Boş kalırsa izleme panelinde cihazın nerede durduğu ve kimin sorumlu olduğu görünmez.

Doğrulamayı log sunucusundan yaptım:

snmpget -v3 -l authPriv -u izleme -a SHA -A IzlemeAuth2026 -x AES -X IzlemePriv2026 192.168.10.2 1.3.6.1.2.1.1.5.0 1.3.6.1.2.1.1.6.0 1.3.6.1.2.1.1.4.0 1.3.6.1.2.1.1.3.0

iso.3.6.1.2.1.1.5.0 = STRING: "gmsw01"
iso.3.6.1.2.1.1.6.0 = STRING: "SistemKusu-Lab-Rack"
iso.3.6.1.2.1.1.4.0 = STRING: "noc@sistemkusu.com"
iso.3.6.1.2.1.1.3.0 = Timeticks: (1187800) 3:17:58.00

Dört değer sırasıyla switch’in adı, konumu, sorumlusu ve çalışma süresi. Cevap gelmesi yolun ve kimliğin doğru olduğunu gösterir.

Yanlış Kimliğe v3 Cevap Verir, v2c Susar

Sonra yanlış bilgiyle sordum. SNMP nedir yazısında yanlış community string ile atılan sorgunun cevapsız kaldığını ölçmüştük; v3’ten de aynı sessizliği bekleyebilirsiniz. Ölçüm bu beklentiyi v2c için doğruladı, v3 için doğrulamadı:

### v3, yanlış kimlik doğrulama parolası
snmpget: Authentication failure (incorrect password, community or key)
sure: .034 sn
### v3, tanımsız kullanıcı
snmpget: Unknown user name
### v2c, doğru community string, izin listesinde olmayan adres
Timeout: No Response from 192.168.10.2.
sure: 3.01 sn

v3 yanlış parolayı 34 milisaniyede açıkça reddetti ve tanımsız kullanıcıyı adıyla söyledi. Bu davranış cihaza göre değişir: lab’daki FortiGate yanlış v3 parolasına hiç cevap vermedi (FortiGate Firewall SNMP ayarı yazımızda ölçtük). v2c sorgusu ise community string doğru olduğu hâlde, adres izin listesinde olmadığı için cevapsız kaldı ve istemci üç saniyelik bekleme süresinin sonunda vazgeçti.

Fark teşhiste ortaya çıkar. v3’te hata mesajı neyin yanlış olduğunu söyler. v2c’de zaman aşımı yanlış community string’i, izin listesini, kapalı bir portu ve kopuk bir yolu aynı biçimde gösterir. Zaman aşımıyla reddin farkını port nedir yazımızda anlattık.

Switch SNMP Sayaçları: İzleme Sistemi Neyi Okur?

Kimlik doğrulandı. Şimdi izleme sisteminin asıl işine bakalım: port sayaçlarını okumak. Modeme giden Gi1/0/1 portunun arayüz numarası 1 çıktı. Aynı değerleri 60 saniye arayla iki kez sordum:

### okuma 1 19:11:53
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: "Gi1/0/1"
.1.3.6.1.2.1.2.2.1.8.1 = INTEGER: 1
.1.3.6.1.2.1.31.1.1.1.15.1 = Gauge32: 1000
.1.3.6.1.2.1.31.1.1.1.6.1 = Counter64: 79836
.1.3.6.1.2.1.31.1.1.1.10.1 = Counter64: 105335
.1.3.6.1.2.1.2.2.1.14.1 = Counter32: 0
.1.3.6.1.2.1.1.3.0 = Timeticks: (11900) 0:01:59.00
### okuma 2 19:12:53
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: "Gi1/0/1"
.1.3.6.1.2.1.2.2.1.8.1 = INTEGER: 1
.1.3.6.1.2.1.31.1.1.1.15.1 = Gauge32: 1000
.1.3.6.1.2.1.31.1.1.1.6.1 = Counter64: 84761
.1.3.6.1.2.1.31.1.1.1.10.1 = Counter64: 118259
.1.3.6.1.2.1.2.2.1.14.1 = Counter32: 0
.1.3.6.1.2.1.1.3.0 = Timeticks: (17900) 0:02:59.00

Satırlar sırasıyla şunlar:

1. Port adı (Gi1/0/1). İzleme panelindeki etiket buradan gelir.
2. Durum (1, yani up).
3. Hız (1000 Mbps).
4. Gelen ve giden bayt sayacı. 64 bitlik sayaçlardır, hızlı portlarda bile uzun süre taşmazlar.
5. Gelen hata sayacı (0). Artmaya başlarsa kabloya ya da karşı cihaza bakılır.
6. Switch’in çalışma süresi.

Sayaçlar anlık hız değildir, switch açıldığından beri birikmiş toplamdır. Hız, iki okumanın farkından hesaplanır. Şubenin kapı sayacı da saatte kaç müşteri geldiğini söylemez; onu iki okumanın farkı söyler. 60 saniyede gelen sayaç 4.925 bayt, giden sayaç 12.924 bayt arttı; yani port saniyede yaklaşık 82 bayt aldı ve 215 bayt gönderdi. Cacti gibi bir izleme sistemi grafiği tam olarak böyle çizer: beş dakikada bir okur ve farkı süreye böler.

Çalışma süresi satırı ayrıca okunmaya değer: 0:01:59. Switch ölçümden iki dakika önce yeniden başlamıştı ve sayaçlar sıfırdan saymaya başlamıştı. Çalışma süresinin geriye gitmesi sayacın sıfırlandığını gösterir. Farkı hesaplayan sistem bunu ayırt etmezse, yeniden başlatma anında grafikte anlamsız bir sıçrama görünür.

Switch SNMP Trap: Olay Anında Bildirim

Yoklama beş dakikada bir gelir; iki yoklama arasında olanı izleme sistemi ancak bir sonraki yoklamada öğrenir. Trap bu aralığı kapatır. Switch olay anında izleme sistemine kendisi haber verir. Trap’i aynı v3 kullanıcısıyla, şifreli gönderilecek biçimde tanımladım:

configure
snmp-server v3-host 192.168.1.46 izleme traps priv
exit

gmsw01#show snmp | include 192.168.1.46
192.168.1.46     Trap    izleme             Auth-Pri 162             15  3

Auth-Pri trap’in hem imzalı hem şifreli gideceğini, 162 de hedef portu gösterir.

Trap Alıcısı Trap’leri Sessizce Atabilir

Karşı tarafta trap’leri alacak bir program gerekir. Lab’da log sunucusuna Ubuntu’nun snmptrapd paketini kurdum. Bir giriş denemesi ve ikinci bir oturumla trap tetikledim ama hiçbir şey görmedim. Paket yakalaması switch’in trap gönderdiğini gösterdi. Sebep alıcıdaydı. Paket kurulur kurulmaz 162 numaralı portu dinlemeye başlamış, ilk trap geldiğinde servis ayağa kalkmış ve günlüğüne şunu yazmıştı:

snmptrapd[4007]: Warning: no access control information configured.
snmptrapd[4007]: This receiver will *NOT* accept any incoming notifications.

Erişim kuralı tanımlanmamış alıcı trap’i kabul etmiyor ve atıyor. Switch tarafında hiçbir hata görünmüyor. Alıcıya v3 kullanıcısını, switch’in motor kimliğiyle birlikte tanıttım:

createUser -e 0x<switch'in engine ID'si> izleme SHA IzlemeAuth2026 AES IzlemePriv2026
authUser log izleme

Motor kimliğini switch’te show running-config | include engineid satırı gösterir.

Trap Olayı Söyler, Ayrıntıyı Log Söyler

Alıcı düzelince üç olay ürettim:

1. Yanlış community string. İzleme sunucusu olmayan bir adresten yanlış community string ile sorgu attım.
2. Yanlış parola. Yanlış parolayla switch’e girmeyi denedim.
3. İkinci oturum. Bir yönetici oturumu açıkken ikincisini açtım.

Üç olay üç trap getirdi. Uzun üretici numaralarını ... ile kısalttım:

2026-09-27 04:54:21 <UNKNOWN> [UDP: [192.168.10.2]:54560->[192.168.1.46]:162]:
.1.3.6.1.2.1.1.3.0 = Timeticks: (1222531) 3:23:45.31	.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.6.3.1.1.5.5
2026-09-27 04:54:26 <UNKNOWN> [UDP: [192.168.10.2]:54560->[192.168.1.46]:162]:
.1.3.6.1.2.1.1.3.0 = Timeticks: (1223064) 3:23:50.64	.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.4.1....0.13
2026-09-27 04:54:36 <UNKNOWN> [UDP: [192.168.10.2]:54560->[192.168.1.46]:162]:
.1.3.6.1.2.1.1.3.0 = Timeticks: (1224002) 3:24:00.02	.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.4.1....0.1

Her trap iki bilgi taşıyor: switch’in çalışma süresi ve olayın kimliği. İlki standart kimlik doğrulama hatasıdır (...1.5.5); öteki ikisi üreticinin kendi numaralarıdır ve zamanları başarısız giriş ile ikinci oturumun log satırlarına denk düştü.

Başarısız giriş trap’inde ne kullanıcı adı var ne kaynak adres. Kullanıcı adı log satırında, kaynak adres hiçbirinde. Trap izleme sistemine “şu an bir şey oldu” der ve sizi log sunucusuna yollar. Şubedeki alarm da merkeze hangi kasada sorun olduğunu söylemez; onu şubenin olay defteri söyler.

Community’nin Adres Kısıtı Trap’i de Durdurur

Yukarıdaki trap’ler v3 kullanıcısıyla gitti. Aynı bildirimi v2c ile, switch’te zaten tanımlı olan community string ile göndermeyi denedim. O community yalnız izleme sunucusunun adresine (.45) açıktı; bildirim hedefi ise log sunucusuydu (.46). Community’nin adres kısıtı yalnız kimin okuyabileceğini belirliyor gibi görünür; bildirimin gideceği yeri etkilemesini beklemezsiniz.

Hedefi tanımladım ve yanlış parola ile ikinci oturum tetiklerini tekrarladım. Switch olayları üretti ve log sunucusuna yazdı:

<189> Sep 27 19:17:11 gmsw01-1 TRAPMGR[tRpcsrv.01000]: traputil.c(777) 706 %% Failed User Login with User ID: ilker.
<189> Sep 27 19:17:19 gmsw01-1 TRAPMGR[emWeb]: traputil.c(777) 716 %% Multiple Users: CPU      .

Ama 162 numaralı porta tek bir paket gitmedi; ne inform olarak tanımladığımda ne de trap olarak. Switch hata da vermedi. Sonra .46’ya açık geçici bir community tanımlayıp hedefi onunla kurdum:

configure
snmp-server community izlemeinform ro ipaddress 192.168.1.46
snmp-server host 192.168.1.46 informs timeout 5 retries 3 izlemeinform
exit

Aynı tetik bildirimi hemen ulaştırdı:

2026-09-27 19:19:49 <UNKNOWN> [UDP: [192.168.10.2]:52745->[192.168.1.46]:162]:

Community’nin adres kısıtı bu switch’te bildirimi de süzüyor. Hedefin adresi community’nin izin listesinde değilse bildirim hiç yola çıkmıyor. Tanımsız bir community’yi ise switch hiç kabul etmedi, hedefi yazarken Error:Community does not exist. dedi. Yani hata veren durum ile sessiz kalan durum ayrı. Community hiç yoksa uyarılırsınız, var ama kısıtlıysa uyarılmazsınız.

Şube benzetmesinde bu, alarm hattının yalnız merkezin bir numarasına açık olmasıdır. Alarm çalar, deftere yazılır, ama bölge müdürünün telefonu hiç çalmaz.

Trap mı Inform mu? Onay ve Tekrar

Trap tek seferlik bir bildirimdir; switch onu gönderir ve alıcının alıp almadığını bilmez. Inform ise alıcıdan onay bekler ve onay gelmezse yeniden göndermesi beklenir. Yukarıda kurduğum hedef zaten inform’du, 5 saniyelik bekleme ve 3 tekrarla:

gmsw01#show snmp | include 192.168.1.46
192.168.1.46     Inform  izlemeinform         2       162             5   3

Alıcı açıkken switch inform’u gönderdi ve alıcının onayı 4,3 milisaniye sonra döndü. Olay kimliğini ... ile kısalttım:

1790536831.560283 IP 192.168.10.2.52745 > 192.168.1.46.162:  C="izlemeinform" Inform(63)  .1.3.6.1.2.1.1.3.0=59781 ...
1790536831.564562 IP 192.168.1.46.162 > 192.168.10.2.52745:  C="izlemeinform" GetResponse(63)  .1.3.6.1.2.1.1.3.0=59781 ...

Alıcı kapalıyken iki biçimde denedim ve 43’er saniye izledim:

1. Port kapalı. Sunucu açık, alıcı durdurulmuş. Switch inform’u bir kez gönderdi, sunucu “bu portta kimse dinlemiyor” diye cevap verdi.
2. Paket sessizce düşüyor. Sunucunun güvenlik duvarı 162’ye gelen paketi cevapsız attı. Switch inform’u yine bir kez gönderdi.

İkisinde de tanımlı üç tekrarın hiçbiri gelmedi. Inform bu switch’te alıcı cevap verdiğinde onay alıyor, cevap vermediğinde trap’ten farkı kalmıyor. Bunun sebebini bulamadım; sonucu yazılım sürümüne özgü sayın ve kendi cihazınızda sınayın.

Benzetme burada kopuyor. “Aldınız mı?” diye soran bir alarm cevap alamayınca yeniden arar. Bu switch aramadı. Bildirimin ulaştığını switch’e bırakmayın, alıcı tarafında da denetleyin. İzleme sisteminde son bildirimin ne zaman geldiğine bakan bir kural ve periyodik bir deneme trap’i bu işi görür.

Switch SNMP Yapılandırmasında Sık Yapılan Hatalar

İzleme sistemi switch’i okuyamıyorsa ya da bildirim gelmiyorsa önce şunlara bakın:

• Komut kaydı açıkken SNMPv3 kullanıcısı tanımlamak. İki parola düz metin olarak log sunucusuna gider.
• Bildirim hedefini kısıtlı bir community ile tanımlamak. Hedefin adresi community’nin izin listesinde değilse bildirim hiç gitmez ve hata görünmez.
• Trap alıcısını kurup erişim kuralını yazmamak. Alıcı bildirimi sessizce atar.
• Inform’u teslim garantisi sanmak. Lab switch’im cevap alamayınca yeniden göndermedi.
• Sayacı anlık hız sanmak. Sayaç açılıştan beri birikir; hız iki okumanın farkıdır ve switch yeniden başlayınca sayaç sıfırlanır.
• Konum ve iletişim alanlarını boş bırakmak. İzleme paneli isimsiz kutulara döner.
• Trap’te kaynak adres aramak. Başarısız giriş trap’i kullanıcıyı da adresi de taşımıyor; ayrıntı log satırındadır.
• Kaydetmemek. Ayarlar yalnız çalışan yapılandırmada kalırsa switch ilk yeniden başlatmada onları kaybeder. Çalışan ve kalıcı yapılandırmanın farkını yönetilebilir switch ayarları yazımızda anlattık.

Sonuç: Switch SNMP’de Hata Vermeden Susar

Switch SNMP yapılandırması üç parçadır: izleme sistemine okuma yetkisi, olaylar için bir bildirim hedefi ve cihazın kim olduğunu söyleyen konum ve iletişim alanları. Lab switch’imde bu parçaların üçü de çalıştı, ama en öğretici sonuçlar switch’in sessiz kaldığı yerlerdeydi. Adres kısıtlı bir community ile tanımlanan hedefe bildirim hiç gitmedi. Inform cevap alamayınca yeniden denemedi. Başarısız giriş trap’i kaynak adres taşımadı.

Girişteki benzetmeye dönersek: genel müdürlük, süpermarket şubesinin sayaçlarını yoklamayla, olaylarını alarmla öğrenir. Alarm hattının gerçekten çalıştığını ise ancak arada bir deneme alarmı çaldırarak bilir; switch’te bunun karşılığı periyodik bir deneme trap’idir.

Rehberin sıradaki adımı VLAN’ları tanımlamak ve portları atamaktır; sıralamanın tamamı switch yapılandırma rehberimizde duruyor. SNMP’nin sürümlerini ve trap mekanizmasını SNMP nedir yazımızda ayrıntısıyla anlattık.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn