Bölüm 41:Ağ İzleme ve Yönetimi

Kararı denetleyici verdi. Ama o kararın tuttuğunu kimse ölçmediyse elde yalnızca bir varsayım var.

Paket geçti gitti. Geçtiği her cihaz onu bir sayaca ekledi ve o sayaçlar bir yere akıyor. Peki o sayacı kim okuyor?

İzlemek yönetimin yalnızca ilk adımı

Tek bir ağ, birbiriyle etkileşen binlerce donanım ve yazılım bileşeninden oluşur. Bu ölçekte hiçbir şey tek tek gözle izlenmez. Klasik tanım da izlemekle yetinmiyor; beş fiili birden sayıyor: izlemek, sınamak, yoklamak, yapılandırmak ve değerlendirmek.

Ağ yönetiminin mimarisi üç parçadan kurulur. En altta yönetilen cihaz durur: anahtar, yönlendirici, erişim sunucusu, köprü, hatta sıradan bir bilgisayar. Onun üstünde bir yönetim ajanı çalışır. Ajan cihazın bilgilerini alır, saklar ve merkeze aktarır; merkezden gelen değişikliği de cihaza o uygular. Üçüncü parça merkezdeki yönetim sunucusudur ve soruyu o sorar.

Cihazdan toplanan veriyi üç türe ayırabilirsin. Yapılandırma verisi cihazın nasıl ayarlandığını söyler. İşletim verisi o an ne yaptığını söyler. Sayaçlar üçüncü kümede, cihaz istatistiklerinin içinde durur.

Operatörün önünde üç yol var. Komut satırından arayüz yapılandırmayı tek bir cihazda yaptın; aynı işi binlerce cihazda elle yapmak ölçeklenmiyor. İkinci yol sayacı uzaktan sorgulamak ve değer yazmak. Üçüncüsü ise ağ genelinde yapılandırma yönetmeye yarıyor.

SNMP bir sayacı hangi adla sorar?

SNMP bu mimarinin protokol karşılığıdır: ajan uygulama, yönetici uygulama ve ağ yönetim sistemi. Mesajları UDP taşır ve iyi bilinen port numarası 161’dir; IANA 1024’ün altını bu sınıfa ayırmıştır. Ölçüm trafiğinin kendisi garantisiz bir taşımaya binmiş durumda.

Bilgi iki kipte taşınır. İstek/yanıt kipinde sunucu sorar, cihaz cevaplar. Trap kipinde cihaz kimse sormadan kendi haber verir. Mesaj türü altı tane.

Bu altısının içinde biri protokolün ne olduğunu değiştirir. SetRequest uzaktan bir değeri yazar; SNMP o anda okuma aracı olmaktan çıkar. Trap ise alarmın protokol düzeyindeki karşılığıdır.

Yazma yetkisi olan bir protokolün kimlik doğrulaması da olmalı — ve olmaması, SNMP’nin uzun süre taşıdığı yaranın kendisiydi. Sürümlerin tarihi bu tek sorunun etrafında dönüyor:

İlk iki sürümdeki topluluk dizesi teknik olarak bir paroladır ama pratikte bir paroladan beklenen hiçbir şeyi yapmaz: pakette düz metin gider, yani hattı dinleyen herkes okur. Üstüne bir de yaygın varsayılanları vardır — okuma için public, yazma için private. Bir ağ tarayıcısının ilk denediği şey tam olarak bu iki kelimedir, ve SetRequest yetkisi veren bir dizeyi bulmak cihazı yeniden yapılandırma yetkisi bulmak demektir.

v3 üçünü birden getirdi: göndereni doğrulayan bir kimlik denetimi, mesajın kurcalanmadığını gösteren bir MIC (bütünlük kodu) ve isteğe bağlı şifreleme. Ayrıca tekrar oynatmayı engellemek için her cihazın bir açılış sayacı ve zaman damgası taşıması şart koşuldu.

Buna rağmen sahada hâlâ bol miktarda v2c çalışıyor, çünkü kurulumu kolay ve pek çok cihaz onunla geliyor. Pratik kural şu: SNMP trafiğini ayrı bir yönetim ağında tut, ve SetRequest yetkisini gerçekten gerekmedikçe hiç açma.

Başlık da sabittir. PDU türü alanı mesajın hangi aileden geldiğini söyler; get ve set başlığında ayrıca Request ID, Error Status ve Error Index alanları durur.

get / set başlığı
+----------+------------+--------------+-------------+
| PDU türü | Request ID | Error Status | Error Index |
|  0 - 3   |            |    0 - 5     |             |
+----------+------------+--------------+-------------+

trap başlığı: PDU türü alanı burada 4 değerini taşır

Bir sayacın adresini veren şey ise MIB’dir. MIB, SNMP ile alınabilecek bilginin resmî tanımıdır: hangi sayacın hangi adla ve hangi anlamla durduğunu belge düzeyinde sabitler. Buradaki değişkenler noktalı bir sayı dizisiyle adlandırılır ve dizinin her basamağı ağacın bir dalına karşılık gelir.

1.3.6.1.2.1.7.1   →  UDPInDatagrams

Bu kimliğin karşılığı, cihazın aldığı UDP datagramlarını sayan 32 bitlik bir alandır. Yazımı SMI adlı veri tanımlama diline dayanır.

RFC’lerde tanımlı 400 MIB modülü var ve üreticiye özgü olanların sayısı bundan çok daha fazla. Ethernet benzeri arayüzlerin yönetilen nesneleri RFC 3635’te tanımlıdır. Anahtarlamalı ağlar için uzaktan izleme modülü ise RFC 2613’te durur ve SMON MIB adıyla anılır. Aynı sorgu böylece farklı markaların anahtarlarından aynı biçimde işletim bilgisi çeker: sıcaklık, bağlı kullanıcı sayısı, bağlantı hızı, cihazın çalışma süresi.

Yapamadığı da var. Bir Set tek cihaza tek değer yazar ve yarıda kalırsa geri alınmaz. NETCONF birden çok cihaz üzerinde atomik commit yapabilir: ya hepsinde uygulanır ya hiçbirinde. Mesajları XML ile kodlanır ve güvenli bir taşıma üstünden uzak yordam çağrısı olarak gider. <lock> işlemi yapılandırma deposunu kilitler; o sırada başka bir oturum aynı yere yazamaz. YANG ise protokol değil, veri modelleme dilidir.

Sayaç kimin geçtiğini bilmez

Port başına paket saymak yararlı grafikler üretir. Ama sayaç ne kadar geçtiğini bilir, kimin nereye gittiğini bilmez.

Cevap akış kavramında. Bir akış, bağlantı, ağ ve taşıma katmanı başlık alanlarının belli bir bileşimiyle tanımlanır. Akış kurallarını merkezî denetleyici yazıyordu; o kuralın yanında duran iki sayaç eşleşen paket ve bayt sayısını tutuyor. Kural birçok başlık alanına birden baktığı için sayacın hangi trafiği saydığı da o alanlarla tanımlanmış oluyor. Yönlendirme kararının kendisi ölçümü üretiyor.

Akış bilgisi toplamak için iki ayrı sistem geliştirildi. sFlow serbest lisanslı bir belirtim, NetFlow ise Cisco Systems’in protokolü. NetFlow zamanla IPFIX’e evrildi ve IETF standardı olarak geliştirildi.

Akış izleme paket akışlarını akış kaydına çevirir. Kayıt paketin kendisini taşımaz, akışın özetini taşır. Kapasite planlaması bunun en sıkıcı kullanımı. Asıl değeri, olağandışı trafiği ve başka türlü görünmeyecek saldırı trafiğini fark ettirmesinde.

Anahtar bu protokolleri desteklemiyorsa trafik dışarıdan alınır. Ayna port bir ya da birkaç portun trafiğini kopyalayıp tek bir porta verir. Oraya bağlanan analizör trafiğin kendisini görür, sayacını değil. Büyük bir üreticideki adı SPAN portudur. Standartlaşmış bir özellik de değildir: yetenek ve sınırlar üreticiye göre değişir, bazıları aynalanan trafiği ağ üstünden uzak bir alıcıya bile gönderir.

Fiber hatlarda ikinci bir yol var. Optik ayırıcı ışığın kopyasını çıkarır ve dışarıdaki bir makineye verir. Üçüncüsü prob: bir anahtar portuna takılır ve sürekli karışık modda çalışarak geçen trafiğin istatistiğini üretir.

Eşik olmadan veri bilgi olmaz

Bir ölçüm sisteminin ilk kararı zaman ölçeğidir. Birçok analizör yükü varsayılan olarak 1 saniyelik ortalamayla gösterir. Bu kısa bir pencere gibi durur ama değildir. Sonuna kadar dolu bir 10 Mbit/s Ethernet kanalı o saniyede kuramsal olarak 14.880 çerçeve taşır. Gigabit Ethernet 1.488.000 çerçeveye çıkar, tam 100 kat. 100 Gbit/s sistemde sayı 148.800.000 olur.

İzlenmesi gereken asgari küme üç kalemden ibaret: port kullanım oranı, yayın ve çoklu yayın hızı, bir de CRC hatası gibi temel hata istatistikleri. Hata sayacı, sorun yaşayan cihazı adres vermeden işaret eder.

Saha pratiğinde aşırı yük eşikleri şöyle konur. Sekiz saatlik iş günü ortalamasında %20, günün en yoğun saatinde %30, on beş dakikalık ortalamalarda %50. Otuz dakikalık bir örnekte %25 gördüysen bu, iş günü ortalaması için konan sınırın üstünde. Bunları önce anahtarları çekirdeğe bağlayan upstream portlarında izlersin; darboğaz oradadır. Kuyruk, trafiğin ortalamasıyla değil değişkenliğiyle büyüyordu; eşikler tam o değişkenliği yakalamak için farklı pencerelere konur.

Çok sayıda anahtardan düzenli istatistik toplayıp hepsine tek tek bakmayı denersen veride boğulursun. Toplamak kolay, yorumlamak zor. Bazı üreticiler bunun için sağlık raporu üretir ve yalnızca yeterince ciddi hata görülen cihazları listeler. Eşik, veriyi bilgiye çeviren şeydir.

Arıza tespiti ayrı bir hattan yürür. Sistem cihazlara düzenli aralıklarla yoklama paketi yollar; cihaz belli sayıda denemeden sonra cevap vermezse düştü işaretlenir ve haber verilir. IP ağlarında en basit biçimi ping’dir: yankı isteği gider, kaç tanesinin döndüğü sayılır. Cihazın kendi olay mesajları ise syslog olarak akar; logging buffered bellekte tutar, show logging gösterir, logging <host> başka bir makineye yollar.

Aynı fikri kendi makinende de görebilirsin. netstat komutu TCP/IP bağlantılarını, gönderilen ve alınan paket ayrıntılarını, yönlendirme tablosunu ve arayüz istatistiklerini basar.

$ netstat -e -s

Arayüz İstatistikleri
                              Alınan          Gönderilen
Bayt                     418.223.104          37.884.912
Tekli yayın paketi           412.771             298.140
Atılan                             0                   0
Hata                               0                   0

Bu tablo bir anahtar portunun küçük kopyası. MRTG, aynı sayaçları SNMP ile yoklayıp tarayıcıda görülebilen grafiklere çeviren yaygın bir yazılım. iperf ise ters yönde çalışır: ağı yüksek veri hızıyla zorlayan aktif bir sınayıcıdır. Wireshark ise canlı trafiği ya da kaydedilmiş bir pcap dosyasını okuyup istatistik çıkarır. Sayaç düzeyinde bakmakla paket düzeyinde bakmak birbirinin yerine geçmez, tamamlar.

Özet

Peki, ne öğrendik?

• Ağ yönetimi izlemekten geniştir: sınamak, yoklamak, yapılandırmak ve değerlendirmek aynı işin fiilleridir; mimari de yönetilen cihaz, ajan ve sunucudan kurulur.
• SNMP sayaçlara ortak bir ad verir: MIB hangi değerin hangi nesne kimliğiyle duracağını sabitler, bu yüzden aynı sorgu farklı markalardan aynı bilgiyi çeker.
• Trap alarmın protokol karşılığıdır: olağandışı olayı ajan kendi başlatır ve SetRequest protokolü okumanın yanında bir yazma aracına çevirir.
• Akış izleme sayacın söyleyemediğini söyler: kayıt paketi taşımaz, akışın özetini taşır ve trafiğin neyden oluştuğunu görünür kılar.
• Eşik veriyi bilgiye çevirir: ham grafik tek başına bir şey söylemez, anlamı hangi pencerede hangi oranın aşıldığına konan sınır üretir.

Buraya kadar ölçülen her şey tek bir yönetimin altındaydı: sayaçlar aynı merkeze aktı, eşiği de alarmı da aynı ekip yönetti. Bu ağdaki herkes birbirine güveniyor; peki paket bu sınırdan çıktığında ne o güven kalıyor ne de ortak bir harita; yolunu neye bakarak seçiyor?