Ağ Dokümantasyonu: Topoloji, IPAM ve Port Haritası Nasıl Tutulur?

Ağ dokümantasyonu ilk kurulum günü eksiksizdir; ilk değişiklikle birlikte eskimeye başlar. Birkaç yıl sonra elde kalan, kimsenin güvenmediği bir Visio çizimi ve “o portu eski sistem yöneticisi biliyordu” türünden kurum hafızasıdır. Aşağıda kurumsal ağ için yaşayan bir doküman setinin neleri içermesi gerektiğini, bu bilginin nerede tutulacağını ve cihazlardan doğrulanarak nasıl güncel kalacağını anlatıyoruz.

Eksik dokümantasyonun operasyonel bedeli

Bedel en çok kriz anında ödenir. Bir uplink koptuğunda hangi binaların etkilendiğini, IP çakışmasında adresin hangi porttaki cihaza ait olduğunu ya da operatöre arıza kaydı açarken devre numarasını aramak, arızanın kendisinden uzun sürebilir. Daha az görünen bedeller de var:

• Her değişiklik öncesi mevcut durumu yeniden keşfetmeye harcanan mühendislik zamanı
• Kullanılmadığı sanılan bir VLAN’ın veya IP bloğunun silinmesiyle gelen beklenmedik kesintiler
• Yeni ekip üyelerinin veya dış destek firmasının ağı öğrenme süresinin uzaması
• Denetimde ağ segmentlerinin ve güvenlik sınırlarının kanıtlanamaması

Amaç her şeyi belgelemek değildir. Operasyon ve değişiklik kararı için gereken asgari bilgi güvenilir biçimde tutulur. Güvenilmeyen doküman, hiç olmayan dokümandan daha tehlikelidir; çünkü yanlış karara güven verir. Yanlış kayıt sessizce yanıltır.

Minimum doküman seti: topoloji, IPAM, VLAN, port haritası

Orta ölçekli bir kurumsal ağ için asgari set ve her parçanın cevapladığı operasyonel soru aşağıda:

Bu sete iki tamamlayıcı kayıt eklenir: cihaz envanteri (model, seri numarası, yazılım sürümü, destek sözleşmesi) ve yönetim erişim bilgisi (yönetim IP’si, out-of-band yolu, konsol sunucusu portu). Parolalar ve paylaşılan anahtarlar doküman setinde değil, parola kasasında tutulur; dokümanda yalnızca kasadaki kaydın adı yer alır. Sahada sık rastladığımız manzara, paylaşımlı klasördeki bir tabloda düz metin enable parolasıdır. Bu bir dokümantasyon değil, açıktır.

VLAN ve adres planının tasarımı ayrı bir konu; burada mevcut planın kaydını tutmaya odaklanıyoruz. Tasarım tarafı için kurumsal ağda VLAN tasarımı yazısına bakabilirsiniz.

Fiziksel ve mantıksal topoloji diyagramları

Okunamayan diyagramların bir numaralı nedeni, her şeyi tek sayfaya sığdırma çabasıdır. Diyagramları katmana göre ayırın:

• Kampüs/lokasyon görünümü: Binalar, sistem odaları ve aralarındaki omurga bağlantıları; WAN ve internet çıkışları.
• Fiziksel görünüm: Kabinet bazında cihazlar, uplink port numaraları, fiber/bakır tipi, port-channel üyeleri.
• L2 görünümü: Trunk’lar ve taşıdıkları VLAN’lar, STP kök köprüsü ve yedek kök, MLAG/stack ilişkileri.
• L3 görünümü: Alt ağlar, gateway’ler (SVI, HSRP/VRRP sanal IP’si), yönlendirme protokolü alanları, VRF’ler ve firewall geçişleri.

Her diyagramın sürüm tarihi, sahibi ve kaynak verisi olmalı. Port numarası, IP adresi gibi sık değişen ayrıntıları diyagrama elle yazmak yerine kaynak-doğruluk sisteminden almak, diyagramın eskime hızını düşürür. Fiziksel tarafta kablo ve port etiketleri standart bir şemaya göre yapılmazsa port haritası sahayla hiçbir zaman eşleşmez; uygulanabilir bir yöntem için TIA-606 ile kablo ve port etiketleme yazısına bakın.

IPAM ve DCIM: NetBox ile kaynak-doğruluk yaklaşımı

Elektronik tablo ve çizim tabanlı dokümantasyon küçük ağlarda iş görür, ama ilişkiyi tutamaz. Bir IP adresinin hangi arayüzde olduğunu, o arayüzün hangi kabloyla hangi patch panele gittiğini tek kayıtta göremezsiniz. NetBox gibi açık kaynaklı IPAM/DCIM araçları bu ilişkileri veri modeli olarak tutar: site, kabinet, cihaz, arayüz, kablo, prefix, IP adresi, VLAN ve devre birbirine bağlı nesnelerdir. Bu yaklaşımın adı “source of truth”tur (kaynak-doğruluk). Ağın olması gereken durumu burada tanımlanır, cihazlar ve diyagramlar bununla karşılaştırılır.

Pratikte iki yaklaşım birlikte yaşar: veriler (IP, VLAN, port, kablo) NetBox’ta, üst düzey mimari diyagramlar çizim aracında. NetBox’a veri girişi genellikle mevcut tablolardan toplu içe aktarmayla başlar; sonrasında her yeni değişiklik önce NetBox’a işlenir. REST API, izleme veya konfigürasyon yedekleme araçlarının cihaz listesini buradan çekmesini sağlar:

curl -s -H "Authorization: Token $NETBOX_TOKEN" \
  -H "Accept: application/json" \
  "https://netbox.kurum.local/api/dcim/interfaces/?device=sw-b1-k2-01&limit=100"

Örnekteki Token başlığı NetBox’ın klasik API token biçimidir; yeni sürümler farklı bir token biçimi ve Bearer başlığı da sunar, kullandığınız sürümün REST API dokümantasyonunu kontrol edin. Bu bağlantı kurulunca Oxidized ile konfigürasyon yedekleme veya izleme sistemine cihaz eklemek ayrı bir iş olmaktan çıkar. Envanterde olmayan cihaz yedeklenmez, izlenmez. Bu da envanteri tutmak için en güçlü teşviktir.

Dokümanı cihazdan doğrulamak: LLDP/CDP ve ARP/MAC tabloları

Doküman ile gerçek durum arasındaki farkı bulmanın en güvenilir yolu bilgiyi doğrudan cihazdan almaktır. Cisco IOS/IOS XE’de konsolda ilk bakılacak komutlar:

show cdp neighbors detail          ! Cisco komşuları, port ve IP
show lldp neighbors detail         ! LLDP destekli tüm komşular
show interfaces status             ! port durumu, VLAN, hız, açıklama
show interfaces trunk              ! trunk’lar ve izin verilen VLAN’lar
show vlan brief                    ! VLAN ve erişim portları
show mac address-table interface GigabitEthernet1/0/12
show ip arp 10.20.30.45            ! L3 cihazda IP–MAC eşlemesi

Switch’ler arası bağlantılar LLDP/CDP ile doğrulanır: komşuluk tablosu dokümandaki uplink port numaralarıyla birebir eşleşmeli. Uç cihazlarda eşleme iki aşamalıdır: L3 cihazdaki ARP tablosu IP adresini MAC adresine, erişim switch’indeki MAC tablosu MAC adresini porta bağlar. MAC bir trunk portunda görünüyorsa cihaz o switch’te değildir. Zincir aşağıdaki switch’te devam eder.

Elle yapıldığında bu karşılaştırma zahmetlidir. Cihaz çıktısını alıp NetBox API’sindeki kablolama ve arayüz kayıtlarıyla karşılaştıran basit bir Python betiği farkları rapor halinde verir. Port açıklamalarının (description) standart bir biçimde yazılması eşlemeyi ciddi ölçüde kolaylaştırır; “test”, “yeni” ya da boş açıklama, sahada dokümantasyonun çöktüğünün ilk işaretidir.

Güncel tutma süreci ve sahiplik

Dokümantasyonu güncel tutan araç değil, süreçtir. İşleyen bir modelin dört bileşeni vardır:

1. Sahiplik: Her doküman bileşeninin (IPAM, port haritası, diyagramlar) adı belli bir sahibi vardır. Sahip her şeyi kendisi girmez; doğruluğundan sorumludur.
2. Değişiklik bağlantısı: Değişiklik kaydı doküman güncellemesi tamamlanmadan kapatılmaz. Değişiklik planında “güncellenecek doküman” satırı bulunur; yürütme tarafı için ağda değişiklik penceresi planlama yazısındaki şablon bu satırı içerir.
3. Otomatik toplama: Cihazdan otomatik alınabilen bilgiler (seri numarası, sürüm, arayüz durumu, LLDP komşuları) elle girilmez; düzenli toplanır ve SoT ile karşılaştırılır.
4. Periyodik denetim: Belirli aralıklarla örneklem üzerinden saha doğrulaması yapılır: rastgele seçilen portların, kabloların ve IP’lerin dokümanla eşleşmesi kontrol edilir.

Sapmanın ana kaynağı, sahada yapılan küçük acil değişikliklerdir: gece bir portun VLAN’ını değiştirmek, geçici bir statik rota eklemek. Bunlar için hafif bir kayıt yolu (kısa form veya ticket şablonu) tanımlanmazsa sapma birikir. “Geçici” değişiklik kalıcı olur.

Doküman denetimi kontrol listesi

• Minimum doküman setinin her bileşeni mevcut ve sahibi tanımlı mı?
• Diyagramlarda sürüm tarihi ve kaynak verisi yazıyor mu; son güncelleme son değişiklikten sonra mı?
• IPAM’deki prefix’ler, L3 cihazlardaki yönlendirme tablosu ve SVI’lar ile eşleşiyor mu?
• VLAN listesindeki her VLAN cihazlarda tanımlı mı; cihazlarda tanımlı ama listede olmayan VLAN var mı?
• LLDP/CDP komşulukları dokümandaki switch’ler arası bağlantılarla birebir aynı mı?
• Rastgele seçilen bir örneklem portun bağlı cihazı port haritasıyla eşleşiyor mu?
• Her WAN ve internet hattı için devre numarası, operatör destek iletişimi ve sözleşme bilgisi güncel mi?
• Envanterdeki tüm cihazlar izleme ve konfigürasyon yedekleme kapsamında mı?
• Parolalar dokümanda değil, parola kasasında mı tutuluyor?

Mevcut ağın keşfi, doküman setinin çıkarılması ve kaynak-doğruluk modeline geçiş planı için kurumsal network danışmanlığı hizmetimiz; dokümanın periyodik doğrulamasını bakım döngüsüne bağlamak için ağ bakım, izleme ve periyodik kontrol hizmetimiz başlangıç noktasıdır.

Sık sorulan sorular

Ağ dokümantasyonu için NetBox kullanmak zorunlu mu?

Hayır. Küçük ağlarda iyi tutulmuş tablolar ve diyagramlar yeterli olabilir. Cihaz, port ve IP sayısı arttıkça nesneler arası ilişkiyi tutan ve API sunan bir kaynak-doğruluk aracı, elle senkronizasyon yükünü belirgin biçimde azaltır.

Dokümantasyon ne sıklıkla güncellenmeli?

Her değişiklikle birlikte. Değişiklik kaydı doküman güncellenmeden kapatılmaz. Buna ek olarak cihazlardan otomatik toplanan verilerle düzenli karşılaştırma ve örneklem üzerinden periyodik saha doğrulaması yapılır.

Bir IP adresinin hangi porta bağlı olduğunu nasıl bulurum?

L3 cihazda ARP tablosundan IP adresinin MAC adresini bulun, ardından erişim switch’lerinin MAC adres tablosunda bu MAC’in öğrenildiği portu arayın. MAC bir trunk portunda görünüyorsa zincir bir alt switch’te devam eder.

Parolalar ağ dokümantasyonunda tutulabilir mi?

Hayır. Parolalar ve paylaşılan anahtarlar erişimi denetlenen bir parola kasasında saklanır; dokümantasyonda yalnızca kasadaki ilgili kaydın adı veya referansı yer alır.