MTR, network yöneticilerinin ağ hatalarını tespit ve teşhis edebilmelerini kolaylaştırmak için geliştirilmiş ve faydalı raporları sunmasını sağlayan çok güçlü bir araçtır. Bu araç temelinde traceroute komutunu kullanmakla beraber bu işlevsel özelliği biraz daha geliştirmiş ve bizlerin kullanımına sunulmuştur. Bu yazımda sizlere MTR raporlarına göre bir network yapısında oluşan sorunları, MTR raporlarındaki verilere dayanarak doğru bir şekilde nasıl yorumlayacağını göstereceğim.
Ağ Sorunlarını Teşhisi
Ping, traceroute ve mtr dahil olmak üzere ağ teşhis araçları, internette iki nokta arasındaki durumu ve trafiği test etmek için “ICMP” paketlerini kullanır. Bir kullanıcı Internet’te bir ana bilgisayara veri gönderdiğinde, ana makineye bir dizi ICMP paketi gönderilir ve karşı tarafda paketleri göndererek yanıt verir.
Kullanıcının istemcisi, İnternet’teki iki nokta arasındaki gidiş geliş süresini hesaplayabilir.
Buna karşılık, traceroute ve MTR gibi araçlar, paketin çıkış ve varış yeri arasında yaptığı atlama ve bu atlamalar arasında kullandığı rotaları görüntülemek için artışlar yaparak TTL‘leri gönderir. Geri dönüşlere göre neler olup neler bittiğini eğer aradaki cihaz gizlenmediyse görebilmek mümkündür. Trafiğin Internet üzerinden geçtiği rotanın basit bir gösterimini sunmak yerine MTR bize ara cihazların durumunu, bağlantıları ve yanıt verme süreleri ile ilgili ek bilgileri de toplar.
Bu ek bilgi nedeniyle, Internet’teki iki bilgisayar arasındaki bağlantının eksiksiz genel görünümünü edinmek için MTR kullanabilirsiniz. En basit hali ile MTR aşağıdaki şekilde kurulur
Debian/Ubuntu için
apt-get install mtr
Centos için
yum install mtr
Mac OSX için
brew install mtr
MTR Kullanarak Rapor Oluşturma
MTR, trafiğin bir görüntüsünü ana bilgisayardan diğerine götürdüğü için, onu yönlendirme aracı olarak düşünebilirsiniz. Ayrıca, İnternet’teki iki nokta arasındaki route, bulunduğunuz yere ve sizin yerinize yerleştirilmiş olan routerlara göre çok farklı olabilir.
Bu nedenle, sık sık bağlantı sorunları yaşayan tüm makineler veya mümkün olduğunca çok sayıda ana bilgisayar için MTR raporlarını her iki yönde de toplamanız önerilir. Tabi bu çoğu zaman mümkün olmayabilir.(Ev kullanıcısı iseniz vs)
Genel olarak özel bir sebebiniz yok ise MTR aracını aşağıdaki gibi kullanabilirsiniz
mtr -rw mertcangokgoz.com
Burada kullandığınız parametreler;
r Rapor oluşturmak için kullanılan komuttur.w Hostname çözümlemesi ve tam görünüm için kullanılmaktadır.
Ayrıca yukarıdaki komutlara ek aşağıdakilerinide kullanabilirsiniz
c kaç adet paketin gönderilip kayıt edileceğini belirtebilirsiniz. Kullanmazsanız ön tanımlı olarak 10 adet paket gönderir. 50 ila 100 arasında bir değer kullanabilirsiniz.i ağ tıkanıklığı sırasında meydana gelebilecek paket kaybını ortaya çıkarmak için kullanabileceğiniz hızlı paket gönderme yöntemimizdir.
mtr -rwc 60 -i 0.5 -rw 1.1.1.1
Örnek çıktı
Burada görüldüğü gibi Google dns olan 8.8.8.8 adresine mtr komutu verilmiş ve ön tanımlı olarak 10 adet paket gönderilmiştir. Komutu takiben, MTR çıktıyı üretir. Rapor oluşturması bir kaç saniye sürecektir. Bu durum bir kaç dakika kadar bile sürebilir bu gibi durumlarda panik yapmayın ve raporun sonuçlanmasını bekleyin.
Raporları Yorumlama
Herhangi bir ip adresine mtr başlatıp daha sonra ortaya çıkan duruma bakacak olursak yukarıda vermiş olduğumuz komut aracılığı ile 60 adet paket gönderdik. Bu paket gönderim işlemini -i 0.5 ile saniyenin yarısı ile yapacağız. Eğer –report kullanımına özen göstermezseniz mtr komutu hedef ip adresine ulaşmaya devam edecek.
MTR çıktısını analiz ederken, iki şey bizim için önemlidir bunlar kayıp(loss) ve gecikme(latency) İlk önce, kayıp hakkında biraz konuşmamız gerekiyor. Ardından gecikmeye ufaktan giriş yapacağız.
Belirli bir hop’da kayıp yüzdesini herhangi bir değer ile birlikte görürseniz, söz konusu router ile ilgili bir sorun olduğuna dair ufak bir sorun olduğunu düşünebilirsiniz. Ancak, bazı servis sağlayıcıları arasında MTR’nin kullandığı ICMP trafiğini sınırlamak yaygın bir uygulama olarak karşımıza çıkmaktadır.(evden bu testi yapıyorsanız göreceğiniz durumlardan biridir.) Bu, kayıp olmadığında bile paket kaybı olarak gözüktüğü için bizi yanıltabilir. Gördüğünüz kayıpların gerçek olup olmadığını veya hız sınırlamalarından hangisinin olduğunu belirlemek için sonraki hop göz atın. Bu hop % 0,01 oranında bir kayıp gösteriyorsa veya kayıp yoksa, ICMP hız sınırlaması olduğunu ve gerçek kayıpları yansıtmadığı anlamına gelecektir.
Türkiye’den bu çıktıya bakıyorsanız ilk bağlantı noktasından yaklaşık 3-4 tanesinde %100 kayıp ve ??? görmeniz normaldir çünkü bu aradaki cihazları gizleme amacı ile yapılmış bir durumdur. Önemli olmamakla birlikte yüksek ihtimalle sizin lokal ağdan çıkan trafik 2. hop’da bina yada mahalle dağıtıcısına oradan da bölge dağıtıcısına gidiyor gibi gözüküyor.(tahminen) Geriye kalan on üç hop giden trafik, beşinci ve yedinci hopa rağmen, hiçbir paket kaybı olmadığını da görüyoruz.
Kayıp birden fazla hop için devam ederse, bazı paket kaybı veya yönlendirme sorunları olduğuna işaret eder. Hız sınırlama ve paket kaybının aynı anda gerçekleşebileceğini unutmayın. Bu durumda, bir kayıpta en düşük yüzdeyi gerçek kayıp olarak almanız gerekmektedir.
Beşinci ve yedinci hopun muhtemelen bir miktar trafik kaybettiği varsayılabilir, çünkü sonraki hop paket kayıplarını bildirmeyecek. Bununla birlikte, kaybın bir kısmı son hopun sadece % 60’ını kaybettiğinden dolayı bu noktaların sınırlandırılmasından kaynaklanmakta olduğunu düşüneceğiz. Farklı miktarlarda kayıp gözlemlenirse, sonraki hoplara bakarak yorumunuzu yapın.
Detaylandırma
Bazı kayıplar dönüş yolundaki problemlerle de açıklanabilir. Paketler hatasız bir şekilde hedeflerine ulaşacak, ancak dönüş yolculuğunu yapmakta zorlanacaklardır. Bu raporda belirgin bir şekilde gözükecek, ancak MTR çıkışından anlamlandırmanız zor olabilir. Bu nedenle, bir sorunla karşılaştığınızda MTR raporlarını her iki yönde toplamak en iyisidir. ( intranet’de yapacağınız testler için önerilir.)
Ayrıca, bağlantılarınız da ki tüm paket kaybı olaylarını araştırmak veya raporlamak için biraz sorunlara katlanmanız gerekiyor. İnternet protokolleri, bazı ağ bozulmalarına karşı dirençli olacak şekilde tasarlanmıştır. (TCP) ve verilerin İnternet üzerinden aldığı yollar, yük, bakım olayları ve diğer yönlendirme sorunlarına tepki olarak dalgalanabilir. Eğer MTR raporunuz % 10’luk küçük miktarlarda kayıplar görüyorsanız, uygulama katmanı muhtemelen geçici olarak bu kaybı telafi edeceğinden kafanızı yormanıza gerek yok. Ancak kayıplar daha yüksek oranlarda meydana geliyor ise o zaman kafanızı yorabilirsiniz.
Ağ Gecikmelerini Anlamlandırma
MTR kullandık paket kayıplarını değerlendirmemize yardımcı oldu şimdi ise MTR ile hedef host arasındaki bir bağlantının gecikmesini de değerlendirmemiz gerekecek. Fiziksel kısıtlamalar nedeniyle gecikme, her zaman bir rotadaki hop sayısıyla bize artarak gözükür. Ancak, artışlar tutarlı ve doğrusal olmalıdır.
Maalesef, gecikme genellikle hem ana bilgisayarın bağlantılarına hem de fiziksel mesafesine bağlıdır. Sorunlu bağlantılar için MTR raporlarını değerlendirirken, belirli bir alandaki diğer ana bilgisayarlar arasındaki bilinen bağlantı hızları da göz önüne alınmalıdır.
Bağlantı kalitesi, belirli bir rota için yaşadığınız gecikme süresini de etkileyebilir. Tahmin edilebilir şekilde çevirmeli bağlantıların aynı hedefe giden kablo modem bağlantılarından çok daha yüksek bir gecikme süresi olacaktır.(modem vs fiber)
Gecikme miktarı 5 ve 6 hop arasında önemli ölçüde hem atlamalar yaparak devam etti ve yüksek kaldı. Bu, yedinci hop’dan sonra gidiş dönüş sürelerinin yüksek kalması nedeniyle ağ gecikme sorununa işaret edilebilir. Bu rapordan, sorunun nedenini belirlemek mümkün olmamakla birlikte, şişirilmiş bir yönlendirici durumunu veya sorun yaşanan bir yönlendiriciyi veya yaşanan bir hız limitlemesini tanımlayabiliriz.
Ne yazık ki, yüksek gecikme her zaman geçerli rota ile ilgili bir problem olduğu anlamına gelmez.
Gecikme, dönüş yolundaki bir sorundan da kaynaklanabilir. Geri dönüş rotası MTR raporunuzda görülmeyecek ve paketler belirli bir hedefe giden ve gelen tüm yollardan farklı yollar alabilecektir. Bu durumda, yaşanan bir kayıpta en düşük kayıp yüzdesini gerçek kayıp olarak almanız gerekmektedir.
Ayrıca yaptığınız testlerde ve oluşturduğunuz raporlarda sorunların her zaman çözümüne ulaşamayabilirsiniz. Bu gibi durumlarda network sağlayıcınızla veya kurum içerisinde sorun yaşıyorsanız network yöneticiniz ile direk olarak iletişime geçin.
Örnekler
Aşağıdaki örneklere bakarak durumu daha iyi anlayabilirsiniz. Örnekleri oluşturmak için herhangi bir test ortamı oluşturma imkanımın olmayışından dolayı teorik gideceğiz.
Hedef Ana Bilgisayar Ağı Yanlış Yapılandırılmış
Yanlış yapılandırılmış bir yönlendirici nedeniyle hedef ana bilgisayarda% 100 kayıp olduğu ortaya çıkıyor. İlk bakışta, paketlerin ana bilgisayara ulaşmadığı anlaşılıyor, ancak durum böyle değil.
Trafik, hedef ana bilgisayara ulaşıyor, ancak MTR raporu, hedef ana bilgisayar yanıt göndermediği için paketlerde loss olarak gösteriyor. Bu, sunucunun ICMP paketlerini DROP edilmesine neden olan yanlış yapılandırılmış ağ veya güvenlik duvarı kurallarının sonucu olabilir.
ICMP Hız Sınırlaması
ICMP Hız sınırlaması, görünür bir şekilde paket kaybına neden olabilir. Sonraki hoplar da devam etmeyen ve bir hop da paket kaybına neden olan durumdur, bu yaşanan kayıp ICMP sınırlamasından kaynaklanacaktır.
Zaman aşımları
Zaman aşımları çeşitli nedenlerle olabilir. Bazı yönlendiriciler ICMP’yi atacak ve çıkışlarda zaman aşımları atacaktır bu durumda yukarıdaki örneklerdeki gibi ??? olarak gösterilecektir. Alternatif olarak, dönüş yolunda bir sorunda olabilir.
Zaman aşımları, zorunlu olarak paket kaybının bir göstergesi değildir bu gibi durumlara bakarak haa burada sorun varmış diyemeyiz. Paketler, önemli paket kaybı veya gecikme olmadan hedeflerine ulaşmaya devam edeceklerdir. Zaman aşımları, QoS (hizmet kalitesi) amaçlarına yönelik paketleri kayba uğratan yönlendiricilere atfedilebilir veya zaman aşımlarına neden olan dönüş yollarıyla ilgili bazı sorunlar olabilir.
