TR / EN

NetXMS ile Çok Lokasyonlu Ağ Keşfi ve Otomatik Haritalama

Bir NMS ekranında bütün lokasyonları çizmek kolaydır; zor olan çizginin gerçek ve güncel bir ilişkiyi temsil etmesidir. Elle hazırlanan harita birkaç değişiklik sonra eskiyebilir, kontrolsüz otomatik keşif ise binlerce anlamsız düğüm oluşturabilir. İyi görünürlük, araçtan önce veri modeli gerektirir: lokasyon nedir, cihaz sahibi kimdir, hangi bağlantı tüneldir ve hangi alarm gerçekten aksiyon doğurur?

20 Temmuz 2026 tarihli çalışmada merkez, tesis, uzak ofis ve saha ağlarını NetXMS üzerinde ortak görünümde birleştirdik. Discovery zone ve yerel poller yaklaşımıyla çakışan adres alanlarını ayırdık; güvenilir seed node’lardan başladık. SNMP, ICMP ve agent verisini aynı değerde kabul etmedik. Otomatik topolojiyi lokasyon etiketleri ve elle onaylanan WAN ilişkileriyle zenginleştirerek operasyon ekibinin kullanabileceği bir haritaya dönüştürdük.

Sorunun ortaya çıkışı

Kurumun farklı sahalarında ayrı izleme araçları ve güncelliği belirsiz çizimler bulunuyordu. Bir tünel kesildiğinde hangi servislerin etkilendiği kişilerin hafızasından anlaşılabiliyordu. Merkezi ekibin hedefi tüm cihazları tek konsolda görmek, lokasyon bazında alarm üretmek ve WAN ilişkilerini haritada izlemekti. Ancak bazı sahalarda benzer özel adres blokları, düşük bant genişliği ve farklı yönetim standartları vardı.

İlk gereksinim listesi “otomatik keşif ve harita” kadar kısaydı. Bunu operasyonel sorulara çevirdik: hangi node yönetilecek, hangisi yalnızca erişilebilirlik göstergesi olacak, bağlantı hangi veriyle çıkarılacak, cihaz lokasyonu nereden gelecek ve alarm kime atanacak? Bu sorular cevaplanmadan yapılan keşif, teknik veri üretse de işletilebilir hizmet oluşturmayacaktı.

İlk belirtiler ve yanlış varsayımlar

En büyük yanlış varsayım, seed node eklenince NetXMS’in fiziksel ve mantıksal topolojiyi eksiksiz anlayacağıydı. SNMP komşuluk protokolleri kapalıysa, sanal tüneller standart tabloda görünmüyorsa veya kimlik bilgisi yetmiyorsa ilişki çıkarılamaz. ICMP yanıtı yalnızca erişilebilirliği gösterir; cihaz tipi, port bağı veya hizmet sahibi hakkında güvenilir bilgi vermez.

İkinci varsayım her lokasyonu merkezi sunucudan taramanın daha sade olduğuydu. Aynı adres blokları zone olmadan yanlış node eşleşmesi yaratabilir, WAN kesintisi bütün sahayı “down” gösterebilir ve merkezi poller tüneli gereksiz yorar. Otomatik haritada görülen her çizgiyi fiziksel kablo kabul etmek de hatalıdır; L2, L3, VPN ve manuel iş bağı farklı ilişki türleridir.

Teknik analiz

Mevcut IP planı lokasyon ve güven bölgesine göre ayrıştırıldı. Çakışan veya bağımsız adres alanları için zone tasarlandı; her zone’da güvenilir router, switch veya poller seed olarak belirlendi. SNMPv3 desteği olan cihazlarda kimlik doğrulamalı ve şifreli salt okunur profil kullanıldı. Eski cihaz istisnaları ayrı kapsam ve risk kaydıyla yönetildi. Agent, sunucu ölçümleri için; ICMP ise temel erişilebilirlik için konumlandırıldı.

Topoloji kaynakları önceliklendirildi: LLDP/CDP benzeri komşuluk, bridge ve forwarding tabloları, routing bilgisi, VPN arayüzü ve manuel doğrulanmış WAN bağlantıları. Her kaynağın güncellik ve güven seviyesi farklıydı. Otomatik bulunan node’ların adlandırma, lokasyon, cihaz sınıfı ve sahiplik alanları doldurulmadan alarm üretmesine izin verilmedi. Bağımlılık modeli, bir WAN kesintisinde alt cihaz alarm fırtınasını bastıracak şekilde sınandı.

Uygulanan çözüm veya önerilen mimari

Merkezi NetXMS sunucusu yönetim ve raporlama katmanı olarak kaldı; uzak sahalara gerektiği yerde poller yerleştirildi. Zone’lar adres kapsamını ve kimlik profillerini ayırdı. Keşif, bilinen seed node ve onaylı subnetlerle sınırlandı. Node şablonları cihaz sınıfına göre DCI, alarm eşiği ve sorumlu ekip atadı. Lokasyon nesneleri, kurumun genel merkez ve saha hiyerarşisini teknik VLAN yapısından bağımsız temsil etti.

Harita iki seviyede tasarlandı: yönetim için lokasyonların sağlık ve WAN durumunu gösteren sade görünüm, ağ ekibi için cihaz-port ilişkilerini içeren teknik görünüm. Tünel bilgisi otomatik kaynaktan güvenilir biçimde gelmiyorsa açıklamalı manuel bağ kullanıldı. Değişiklik sonrası günlük keşif ile haftalık doğrulama raporu ayrıldı. Alarm yönlendirme, bakım modu ve eskalasyon kuralları hizmet sahipleriyle test edildi.

Alternatifler ve karar gerekçesi

Tamamen elle çizilmiş diyagramlar sunum için temiz olabilir, fakat durum ve envanterle bağları zayıftır. Yalnızca otomatik topoloji ise veri eksik olduğunda karmaşık ve yanıltıcı görünür. Hibrit yöntem seçildi: cihaz ve standart komşuluklar otomatik, iş açısından kritik WAN ve hizmet bağımlılıkları doğrulanmış manuel ilişkilerle tutuldu. Otomasyonun bilmediğini uydurmasına izin verilmedi.

Her sahaya poller kurmak ek sunucu ve güncelleme yükü getirir; düşük gecikmeli, küçük ofislerde merkezi polling yeterli bırakıldı. SNMP yerine yalnızca agent kullanmak ağ cihazlarını kapsamazdı; yalnızca SNMP de uygulama seviyesini eksik bırakırdı. NetXMS tercihi mevcut yetkinlik ve entegrasyon ihtiyacına uyuyordu, ancak mimari ilkeler başka NMS ürünlerinde de geçerlidir.

Güvenlik ve operasyonel riskler

NMS, ağın ayrıntılı haritasını ve yönetim kimliklerini tuttuğu için yüksek değerli bir sistemdir. Yönetim arayüzü ayrı ağdan erişilmeli, MFA ve rol tabanlı yetki uygulanmalı, servis hesapları kasada saklanmalıdır. SNMP yazma yetkisi izleme için kullanılmamalıdır. Poller ile merkez arasındaki trafik şifrelenmeli; gerçek topoloji ekranları genel sunum veya blog içeriğinde paylaşılmamalıdır.

Yanlış eşikler alarm yorgunluğu, agresif polling ise cihaz ve WAN yükü üretir. NMS yedeği yalnızca veritabanını değil şablon, harita ve anahtar kurtarma süreçlerini kapsamalıdır. Otomatik keşifle bulunan bilinmeyen cihaz olay olarak ele alınmalı ama doğrudan tehdit sayılmamalıdır. Sürüm yükseltmeleri laboratuvarda denenmeli, poller uyumluluğu ve alarm teslimi uçtan uca kontrol edilmelidir.

Çıkarılan Dersler

Kontrol Listesi