Ağ tanılama yazılımı. Windows'ta ağ sorunlarını tanılayın ve düzeltin

Programlar zaman zaman yavaş çalışıyorsa, bilgisayarlar donuyor veya sunucuyla bağlantısı kesiliyorsa ve programcılar her şeyden ağın sorumlu olduğunu söylüyorsa ve ağ yöneticisi her şey için programların suçlanacağını söylüyorsa, bu makale size yöneliktir. .

Bu makalede sunulan materyal, yerel ağların "gizli kusurlarını" ve "darboğazlarını" belirlemede ProLAN şirketinin uzun vadeli pratik deneyiminin bir genellemesinden başka bir şey değildir.

"Gizli kusurları" tespit etme metodolojisinin tanımına geçmeden önce, terimleri tanımlamak istiyoruz: aslında yerel ağ olarak anlaşılan şey, yerel bir ağın teşhisi ve hangi ağın "iyi" olarak kabul edilmesi gerektiği. .

Çoğu zaman, yerel bir ağın teşhisi, yalnızca kablolama sisteminin test edilmesi anlamına gelir. Bu tamamen doğru değil. Kablolama sistemi, yerel bir ağın en önemli bileşenlerinden biridir, ancak teşhis açısından tek ve en zor değil. Kablolama sisteminin durumuna ek olarak, ağın kalitesi aktif ekipmanın durumundan (ağ kartları, hub'lar, anahtarlar), sunucu ekipmanının kalitesinden ve ağ işletim sisteminin ayarlarından önemli ölçüde etkilenir. Ek olarak, ağın işleyişi, içinde kullanılan uygulanan yazılımın çalışması için algoritmalara önemli ölçüde bağlıdır.

"Yerel ağ" terimiyle, yukarıdaki donanım ve yazılımın tüm kompleksini kastediyoruz; ve "yerel ağın teşhisi" terimi altında - uygulama yazılımının ağ üzerinde yetersiz çalışmasının nedenlerini belirleme süreci. Kullanıcıların bakış açısından belirleyici olan, ağdaki uygulama yazılımının kalitesidir. Veri iletim hatalarının sayısı, ağ kaynaklarının kullanım derecesi, ekipman performansı vb. gibi diğer tüm kriterler ikincildir. "İyi bir ağ", kullanıcıları nasıl çalıştığını fark etmeyen bir ağdır.

Uygulama yazılımının ağdaki yetersiz çalışmasının birkaç ana nedeni olabilir: kablo sisteminde hasar, aktif ekipmandaki kusurlar, ağ kaynaklarının (iletişim kanalı ve sunucu) tıkanıklığı, uygulama yazılımının kendisindeki hatalar. Çoğu zaman, bazı ağ kusurları diğerlerini gizler. Bu nedenle, uygulama yazılımının yetersiz çalışmasının nedeninin ne olduğunu güvenilir bir şekilde belirlemek için yerel ağ kapsamlı tanılamaya tabi tutulmalıdır. Kapsamlı teşhis, aşağıdaki çalışmanın (aşamaların) uygulanmasını içerir.

• Ağın fiziksel katmanındaki kusurların belirlenmesi: kablo sistemi, aktif ekipmanın güç kaynağı sistemi; dış kaynaklardan gelen gürültünün varlığı.
• Ağın iletişim kanalının mevcut yükünün ölçülmesi ve iletişim kanalının yükünün uygulama yazılımının yanıt süresi üzerindeki etkisinin belirlenmesi.
• Ağdaki çarpışmaların sayısını ölçmek ve oluşma nedenlerini bulmak.
• İletişim kanalı düzeyinde veri iletim hatalarının sayısının ölçülmesi ve oluşum nedenlerinin bulunması.
• Ağ mimarisindeki kusurların belirlenmesi.
• Mevcut sunucu yükünün ölçülmesi ve yük derecesinin uygulama yazılımının yanıt süresi üzerindeki etkisinin belirlenmesi.
Uygulama yazılımındaki, sunucu ve ağ bant genişliğinin verimsiz kullanımına neden olan kusurların belirlenmesi.

Bu makale çerçevesinde, yerel bir ağın karmaşık teşhisinin ilk dört aşamasını, yani: ağın veri bağlantısı katmanının teşhisini ele alacağız.

Ağ kablolama sistemini test etme metodolojisini ayrıntılı olarak açıklamayacağız. Bu sorunun önemine rağmen, çözümü önemsiz ve net: tam teşekküllü bir kablo sistemi sadece özel bir cihaz - bir kablo tarayıcı ile test edilebilir. Başka yolu yok. Kablo tarayıcıda AUTOTEST tuşuna tek bir basışla lokalize edilebilirlerse, ağ kusurlarını tespit etmek için hantal prosedürden geçmenin bir anlamı yoktur. Aynı zamanda cihaz, ağ kablolama sisteminin seçilen standarda uygunluğu için bir dizi test gerçekleştirecektir.

Özellikle bir tarayıcı kullanarak ağ kablolama sistemini test ederken genellikle unutuldukları için iki noktaya dikkatinizi çekmek istiyorum.

OTOTEST modu, kablodaki harici bir kaynak tarafından üretilen gürültü seviyesini kontrol etmenize izin vermez. Floresan lambadan, elektrik kablolarından, cep telefonundan, güçlü bir fotokopi makinesinden vb. gelen gürültü olabilir. Kablo tarayıcıların genellikle gürültü seviyesini belirlemek için özel bir işlevi vardır. Ağın kablolama sistemi yalnızca kurulum aşamasında tamamen kontrol edildiğinden ve kabloda öngörülemeyen bir şekilde gürültü meydana gelebileceğinden, ağın tam ölçekli bir kontrolü sırasında gürültünün tam olarak ortaya çıkacağına dair tam bir garanti yoktur. kurulum aşamasında.

Ağı bir kablo tarayıcı ile kontrol ederken, aktif ekipman yerine kablonun bir ucuna bir tarayıcı, diğer ucuna bir enjektör bağlanır. Kabloyu kontrol ettikten sonra tarayıcı ve enjektör kapatılır ve aktif ekipman bağlanır: ağ kartları, hub'lar, anahtarlar. Ancak, aktif ekipman ile kablo arasındaki temasın, tarayıcı ekipmanı ile kablo arasındaki kadar iyi olacağının garantisi yoktur. Kablo sistemini bir tarayıcı ile test ederken RJ-45 fişinde küçük bir kusurun görünmediği, ancak ağ bir protokol analizörü ile teşhis edildiğinde tespit edildiği durumlarla tekrar tekrar karşılaştık.

Önerilen metodoloji çerçevesinde, proaktif ağ teşhisinin şu anki ders kitabı yöntemini dikkate almayacağız ("Proaktif ağ teşhisi için metodoloji" kenar çubuğuna bakın). Proaktif teşhisin önemini sorgulamadan, sadece pratikte nadiren kullanıldığını not ediyoruz. Çoğu zaman (bu yanlış olsa da), ağ yalnızca yetersiz performansının olduğu dönemlerde analiz edilir. Bu gibi durumlarda, mevcut ağ hatalarının hızlı bir şekilde yerelleştirilmesi ve düzeltilmesi gerekir. Önerilen metodoloji, proaktif ağ tanılama metodolojisinin özel bir durumu olarak düşünülmelidir.

Ağ tanılama sürecinin organizasyonu

Bir ağı test etmek için kullanılan herhangi bir metodoloji, esasen sistem yöneticisinin emrinde olan araçlara bağlıdır. Bize göre, çoğu durumda ağ hatalarını tespit etmek için gerekli ve yeterli bir araç (kablo tarayıcı hariç) bir ağ protokolü analizörüdür. Arızanın meydana geldiği çarpışma alanına, en şüpheli istasyonlara veya sunucuya mümkün olduğunca yakın bağlanmalıdır (bkz. Kural # 3.3).

Ağ, daraltılmış bir omurgaya sahip bir mimariye sahipse ve omurga olarak bir anahtar kullanılıyorsa, çözümleyici, analiz edilen trafiğin içinden geçtiği anahtar bağlantı noktalarına bağlanmalıdır. Bazı programlarda, anahtardaki uzak bağlantı noktalarına bağlı bilgisayarlarda kurulu özel aracılar veya sondalar bulunur. Aracılar (SNMP aracıları ile karıştırılmamalıdır) genellikle bir kullanıcının bilgisayarında arka planda çalışan bir hizmet veya görevdir. Kural olarak, aracılar çok az bilgi işlem kaynağı tüketir ve bilgisayarlarına kurulu oldukları kullanıcıların çalışmalarına müdahale etmezler. Analizörler ve ajanlar anahtara iki şekilde bağlanabilir.

İlk yöntemde (bakınız Şekil 1a), analizör varsa anahtarın özel bir bağlantı noktasına (izleme bağlantı noktası veya ayna bağlantı noktası) bağlanır ve ilgili tüm anahtar bağlantı noktalarından gelen trafik sırayla ona gönderilir.

Şekil 1a. Anahtar üzerindeki tüm bağlantı noktalarından gelen yansıtma trafiği, sırayla, protokol çözümleyicisinin bağlı olduğu anahtar üzerindeki bağlantı noktasına yönlendirilir.

Anahtarın özel bir portu yoksa, o zaman analizör (veya ajan), en şüpheli istasyonlara veya sunucuya mümkün olduğunca yakın olan ilgili ağ etki alanlarının portlarına bağlanmalıdır (bkz. Şekil 1b). Bu bazen ek bir hub kullanımını gerektirebilir. Kural # 3.3'e göre, bu yöntem birinciye tercih edilir. Bunun istisnası, anahtar bağlantı noktalarından birinin tam çift yönlü modda çalışmasıdır. Bu durumda, bağlantı noktası önce yarım çift yönlü moda ayarlanmalıdır.

Şekil 1b. Protokol çözümleyicisi ve uzak aracılar, ağın ana etki alanlarını izler. Sunucu etki alanını tanılamak için ek bir hub kullanılır.

Piyasada saf yazılımdan donanım yazılımına kadar birçok farklı protokol analizörü vardır. Çoğu protokol analizörünün işlevsel kimliğine rağmen, her birinin belirli avantajları ve dezavantajları vardır. Bu bağlamda, etkin ağ teşhisini gerçekleştirmenin zor olacağı iki önemli fonksiyona dikkatinizi çekmek istiyoruz.

İlk olarak, protokol analizörü yerleşik trafik üretimine sahip olmalıdır (bkz. Kural # 3.4). İkinci olarak, protokol analizörü alınan çerçeveleri "kırpabilmelidir", yani tüm kareleri arka arkaya kabul etmez, örneğin, elde edilen sonuçların zorunlu müteakip tahmini ile her beşte bir veya her onuncu karede bir kabul eder. Bu işlev yoksa, güçlü bir ağ yükü ile, analizörün kurulu olduğu bilgisayarın performansı ne olursa olsun, ikincisi "askıda kalır" ve / veya çerçeveleri kaybeder. Bu özellikle Fast Ethernet ve FDDI gibi hızlı ağları teşhis ederken önemlidir.

Windows 95 ve Windows NT'de çalışan Network Instruments'tan tamamen yazılım protokolü analizörü Observer'ı kullanma örneğini kullanarak önerilen metodolojiyi göstereceğiz. Bizim açımızdan bu ürün, etkin ağ teşhisi için gerekli tüm fonksiyonlara sahiptir.

Bu nedenle, Ethernet ağınızdaki uygulama yazılımının yavaşladığını ve kusuru hızlı bir şekilde bulup düzeltmeniz gerektiğini varsayalım.

İlk adım

Ağ kullanımının ölçülmesi ve ağ yavaşlaması ile bağlantı tıkanıklığı arasında bir ilişki kurulması.

Ağ iletişim kanalının kullanımı, iletişim kanalının sinyalleri ilettiği sürenin yüzdesi veya başka bir deyişle, çerçeveler, çarpışmalar ve parazit tarafından işgal edilen iletişim kanalı bant genişliği oranıdır. "İletişim kanalının kullanımı" parametresi, ağ tıkanıklığı miktarını karakterize eder.

Ağ iletişim kanalı, paylaşılan bir ağ kaynağıdır, bu nedenle yükü, uygulama yazılımının yanıt süresini etkiler. Birincil zorluk, zayıf uygulama yazılımı performansı ile ağ kullanımı arasında bir ilişki olup olmadığını belirlemektir.

Protokol çözümleyicisinin, uygulama yazılımının yavaş çalıştığı çarpışma etki alanına kurulduğunu varsayalım. İletişim kanalının ortalama kullanım oranı %19, en yüksek olanı ise %82'ye ulaşıyor. Bu verilere dayanarak, ağdaki programların yavaş çalışmasının nedeninin iletişim kanalının tıkanıklığı olduğu konusunda güvenilir bir sonuca varmak mümkün müdür? Olası olmayan.

Ethernet ağının tatmin edici bir şekilde çalışması için, iletişim kanalının "trendde" (ortalama 15 dakikadan fazla) kullanımının% 20'yi geçmemesi ve "tepede" ( 1 dakikanın üzerinde ortalama) - %35-40. Verilen değerler, Ethernet ağında, iletişim kanalının kullanımı %40'ı aştığında, çarpışma sayısının önemli ölçüde artması ve buna bağlı olarak uygulama yazılımının yanıt süresinin artmasıyla açıklanmaktadır. Bu tür bir akıl yürütmenin genellikle doğru olmasına rağmen, bu tür önerilere koşulsuz olarak uyulması, ağdaki programların yavaş çalışmasının nedenleri hakkında yanlış bir sonuca yol açabilir. Belirli bir ağın özelliklerini dikkate almazlar, yani: uygulama yazılımının türü, ağ etki alanının uzunluğu, aynı anda çalışan istasyonların sayısı.

Özel durumunuzda iletişim kanalının izin verilen maksimum kullanımının ne olduğunu belirlemek için aşağıdaki kurallara uymanızı öneririz.

Kural #1.1.

Bir Ethernet ağında, herhangi bir zamanda, en fazla iki bilgisayar arasında veri alışverişi yapılıyorsa, ağın herhangi bir keyfi yüksek kullanımı kabul edilebilir.

Ethernet ağı, iki bilgisayar aynı anda iletişim kanalını ele geçirmek için birbirleriyle rekabet ederse, bir süre sonra birbirleriyle senkronize olacak ve sırayla iletişim kanalına kesinlikle girmeye başlayacak şekilde tasarlanmıştır. Bu durumda, aralarında neredeyse hiçbir çarpışma yoktur.

İş istasyonu ve sunucu yüksek performansa sahipse ve aralarında büyük miktarda veri alışverişi yapılıyorsa, iletişim kanalındaki kullanım (özellikle burst modunda) %80-90'a ulaşabilir. Bu kesinlikle ağı yavaşlatmaz, aksine, kaynaklarının uygulama yazılımı tarafından verimli bir şekilde kullanıldığını gösterir.

Bu nedenle, ağınızda iletişim kanalının kullanımı yüksekse, aynı anda kaç bilgisayarın veri alışverişi yaptığını belirlemeye çalışın. Bu, örneğin, yüksek kullanım süresi boyunca ilgili kanaldaki paketleri toplayarak ve kodunu çözerek yapılabilir.

Kural # 1.2.

Ağ iletişim kanalının yüksek kullanımı, bu özel yazılımın çalışması için "darboğaz" iletişim kanalı olduğunda, yalnızca belirli bir uygulama yazılımının çalışmasını yavaşlatır.

İletişim kanalına ek olarak, yetersiz performans veya yanlış sunucu ayarları, iş istasyonlarının düşük performansı, uygulama yazılımının kendisinin çalışması için etkisiz algoritmalar nedeniyle sistemde darboğazlar ortaya çıkabilir.

Sistemin yetersiz performansından iletişim kanalının ne ölçüde sorumlu olduğu aşağıdaki gibi öğrenilebilir. Bu uygulama yazılımının en toplu işlemini seçtikten sonra (örneğin bankacılık yazılımı için böyle bir işlem ödeme emri girmek olabilir), iletişim kanalı kullanımının böyle bir işlemin gerçekleştirilme süresini nasıl etkilediğini belirlemelisiniz.

Bunu yapmanın en kolay yolu, bir dizi protokol çözümleyicisinde (örneğin, Observer) bulunan trafik oluşturma özelliğini kullanmaktır. Bu fonksiyonun yardımıyla, üretilen yükün yoğunluğu kademeli olarak arttırılmalı ve arka planına karşı çalışma süresi ölçülmelidir. Arka plan yükünün %10'dan fazla olmayan artışlarla %0'dan %50-60'a çıkarılması tavsiye edilir.

Çok çeşitli arka plan yüklerinde işlemin yürütme süresi önemli ölçüde değişmiyorsa, sistemin darboğazı iletişim kanalı değildir. İşlem yürütme süresi arka plan yüküne bağlı olarak önemli ölçüde değişiyorsa (örneğin, iletişim kanalının %10 ve %20 kullanımında, işlemin yürütme süresi önemli ölçüde farklılık gösterecektir), o zaman büyük olasılıkla sorumlu olan iletişim kanalıdır. sistemin düşük performansı için ve yükünün değeri, uygulama yazılımının yanıt süresi için kritik öneme sahiptir. Yazılımın istenilen yanıt süresini bilerek, iletişim kanalının hangi kullanımının uygulama yazılımının istenilen yanıt süresine karşılık geldiğini kolaylıkla belirleyebilirsiniz.

Bu deneyde arka plan yükü %60-70'den fazla ayarlanmamalıdır. İletişim kanalı darboğaz olmasa bile, bu tür yükler altında etkin ağ bant genişliğinin azalması nedeniyle yürütme süresi uzayabilir.

Kural # 1.3.

İletişim kanalının izin verilen maksimum kullanımı, ağın uzunluğuna bağlıdır.

Ağ etki alanının uzunluğu arttıkça, izin verilen kullanım azalır. Ağın etki alanı ne kadar uzun olursa, çakışmalar o kadar geç algılanır. Ağ etki alanının uzunluğu küçükse, çarpışmalar, başlangıç ​​iletimi sırasında çerçevenin başlangıcındaki istasyonlar tarafından algılanacaktır. Ağın uzunluğu uzunsa, çarpışmalar daha sonra - çerçevenin kendisinin iletimi sırasında - tespit edilecektir. Sonuç olarak, paket iletim ek yükü (IP veya IPX) artar. Bir çarpışma ne kadar geç algılanırsa, ek yükün miktarı o kadar fazla olur ve paketin aktarılması o kadar uzun sürer. Sonuç olarak, uygulama yazılımının tepki süresi önemsiz de olsa artar.

Sonuçlar. Ağ teşhisi sonucunda, uygulama yazılımının yavaş çalışmasının nedeninin iletişim kanalının tıkanıklığı olduğunu belirlerseniz, ağ mimarisi değiştirilmelidir. Sıkışık ağ etki alanlarındaki istasyon sayısı azaltılmalı ve en büyük ağ yükünü oluşturan istasyonlar özel anahtar bağlantı noktalarına bağlanmalıdır.

İkinci aşama

Ağdaki çarpışma sayısının ölçümü.

Ağın etki alanındaki iki istasyon aynı anda veri iletiyorsa, etki alanında bir çarpışma meydana gelir. Çarpışmalar üç tiptir: yerel, uzak, geç.

Yerel çarpışma, girişin iletiminde veya iletim kaynağı etki alanındayken çerçevenin ilk 64 baytında ölçüm cihazının bağlı olduğu etki alanında kaydedilen bir çarpışmadır. Bükümlü çift (10BaseT) ve koaksiyel (10Base2) ağlar için yerel çarpışma algılama algoritmaları farklıdır.

10Base2 ağında, çerçeveyi ileten istasyon, iletişim kanalındaki voltaj seviyesini değiştirerek (ikiye katlayarak) yerel bir çarpışmanın meydana geldiğini belirler. Bir çarpışma tespit edildiğinde, verici istasyon iletişim kanalına bir dizi sıkışma sinyali gönderir, böylece etki alanındaki diğer tüm istasyonlar bir çarpışmanın meydana geldiğini bilir. Bu sinyal dizisinin sonucu, geçersiz bir CRC ile 64 bayttan daha kısa, hatalı biçimlendirilmiş çerçevelerin ağdaki görünümüdür. Bu çerçevelere çarpışma parçaları (runt) denir.

Bir 10BaseT ağında, bir istasyon, bir çerçeve iletirken bir alma çifti (Rx) üzerinde aktivite tespit ederse, yerel bir çarpışmanın meydana geldiğini belirler.

Uzak çarpışma, başka bir fiziksel ağ segmentinde (yani bir tekrarlayıcının arkasında) meydana gelen bir çarpışmadır. İstasyon, yanlış bir CRC ile yanlış oluşturulmuş bir kısa çerçeve alırsa ve iletişim kanalındaki voltaj seviyesi belirlenen sınırlar içinde kalırsa (10Base2 ağları için) uzak bir çarpışmanın meydana geldiğini kabul eder. 10BaseT / 100BaseT ağları için gösterge, alma ve gönderme çiftlerinde (Tx ve Rx) eşzamanlı aktivitenin olmamasıdır.

Geç çarpışma, istasyon çerçevenin ilk 64 baytını iletişim kanalına ilettikten sonra sabitlenen yerel bir çarpışmadır. 10BaseT ağlarında, geç çarpışmalar genellikle ölçüm cihazları tarafından CRC hataları olarak rapor edilir.

Yerel ve uzak çarpışmaların tespiti, kural olarak, henüz ağdaki kusurların varlığını göstermezken, geç çarpışmaların tespiti, etki alanındaki bir kusurun varlığının açık bir teyididir. Çoğu zaman bu, iletişim hatlarının aşırı uzunluğundan veya düşük kaliteli ağ ekipmanından kaynaklanır.

İletişim kanalının yüksek düzeyde kullanılmasına ek olarak, Ethernet ağındaki çarpışmalar, kablo sistemindeki ve aktif ekipmandaki kusurlardan ve ayrıca gürültü varlığından kaynaklanabilir.

İletişim kanalı sistemde darboğaz olmasa bile çarpışmalar önemsizdir ancak uygulama yazılımının çalışmasını yavaşlatır. Ayrıca, ana yavaşlama çerçeveyi yeniden iletme ihtiyacı gerçeğinden değil, bir çarpışma meydana geldikten sonra ağdaki her bilgisayarın bir geri çekilme algoritması gerçekleştirmesi gerektiği gerçeğinden kaynaklanmaktadır: bir sonraki giriş denemesinden önce. iletişim kanalı, önceki başarısız denemelerin sayısıyla orantılı olarak rastgele bir süre beklemek zorunda kalacaktır.

Bu bağlamda, çarpışmaların nedeninin ne olduğunu bulmak önemlidir - ağın yüksek kullanımı veya "gizli" ağ kusurları. Bunu belirlemek için aşağıdaki kurallara uymanızı öneririz.

Kural # 2.1.

Tüm ölçüm cihazları ağdaki toplam çarpışma sayısını doğru şekilde belirlemez.

Hemen hemen tüm yazılım protokolü analizörleri, yalnızca ağdaki bir parçayı, yani bir çarpışmanın sonucunu algılarlarsa, bir çarpışmanın varlığını kaydeder. Bu durumda, en yaygın çarpışma türü - çerçeve başlangıcının iletimi sırasında (yani, ilk çerçeve sınırlayıcıdan (SFD) önce) meydana gelir - yazılım ölçüm araçları tarafından algılanmaz, Ethernet yonga seti bu şekilde ağ kartları çalışır. Fluke'un LANMeter'i gibi donanım enstrümantasyonu, çarpışmaları en doğru şekilde algılar.

Kural # 2.2.

İletişim kanalının yüksek düzeyde kullanılmasına her zaman yüksek düzeyde çarpışmalar eşlik etmez.

Ağda aynı anda ikiden fazla istasyon çalışmıyorsa (bkz. Kural # 1.1) veya az sayıda istasyon aynı anda uzun çerçeve alışverişi yapıyorsa (özellikle çoğuşma modu için tipiktir) çarpışma hızı düşük olacaktır. Bu durumda, çerçeve iletiminin başlamasından önce, istasyonlar iletişim kanalındaki taşıyıcıyı "görür" ve çarpışmalar nadirdir.

Kural # 2.3.

Ağdaki bir kusurun işareti, düşük kanal kullanımının (%30'dan az), yüksek düzeyde çarpışmaların (%5'ten fazla) eşlik ettiği bir durumdur.

Kablolama sistemi daha önce bir tarayıcı ile test edilmişse, artan çarpışma seviyesinin en olası nedeni, harici bir kaynaktan kaynaklanan iletişim hattındaki gürültü veya iletim ortamı erişim algoritmasını doğru şekilde uygulamayan arızalı bir ağ kartıdır. (CSMA / CD).

Network Instruments, Observer protokol analizöründeki ağ hatalarının neden olduğu çarpışmaları tespit etme problemini orijinal olarak çözmüştür. Programa dahil edilen test, çarpışmaların meydana gelmesine neden olur: iletişim kanalına saniyede 100 paket yoğunluğuyla bir dizi paket gönderir ve meydana gelen çarpışmaların sayısını analiz eder. Aynı zamanda, birleşik grafik, ağdaki çarpışma sayısının iletişim kanalının kullanımına bağımlılığını gösterir.

Şüpheli (yavaş çalışan) istasyonların faaliyet anında ve yalnızca iletişim kanalının kullanımının %30'u aşması durumunda, çarpışmaların toplam çerçeve sayısı içindeki payını analiz etmek mantıklıdır. Üç çerçeveden biri bir çarpışma ile karşılaşırsa, bu ağda bir kusur olduğu anlamına gelmez.

Observer protokol analizöründe, Şekil 3'te gösterilen grafik, çarpışma sayısına ve iletişim kanalının gözlemlenen kullanımına bağlı olarak renk değiştirir.

Kural # 2.4.

Bir 10BaseT ağını teşhis ederken, protokol analizörü trafik oluşturmuyorsa tüm çarpışmalar uzak olarak kaydedilmelidir.

10BaseT ağını pasif olarak (trafik oluşturmadan) izlerseniz ve analizörün (ölçüm cihazı) bağlandığı noktada fiziksel segment iyiyse, tüm çarpışmalar uzak olarak kaydedilmelidir.

Yine de tam olarak yerel çarpışmalar görüyorsanız, bu üç şeyden biri anlamına gelebilir: ölçüm cihazının bağlı olduğu ağın fiziksel bölümü arızalıdır; ölçüm cihazının bağlı olduğu hub veya anahtarın portunda bir arıza var veya ölçüm cihazı yerel ve uzak çarpışmaları ayırt edemiyor.

Kural # 2.5.

Ağdaki çarpışmalar, anahtarın giriş arabelleklerindeki tıkanıklığın sonucu olabilir.

Giriş arabellekleri aşırı yüklendiğinde, ağ iş istasyonlarını "yavaşlatmak" için anahtarların çarpışmaları taklit ettiği unutulmamalıdır. Bu mekanizmaya "akış kontrolü" denir.

Kural # 2.6.

Ağdaki çok sayıda çarpışma (ve hata), yerel ağa bağlı bilgisayarların yanlış topraklanmasından kaynaklanabilir.

Ağa bağlı bilgisayarların ortak bir toprak noktası (sıfırlama) yoksa bilgisayar kasaları arasında potansiyel farkı oluşabilir. Kişisel bilgisayarlarda "koruyucu" zemin, "bilgi" zemini ile birleştirilir. Bilgisayarlar yerel bir ağ iletişim kanalı ile bağlı oldukları için aralarındaki potansiyel fark, iletişim kanalı üzerinden bir akımın ortaya çıkmasına neden olur. Bu akım, bilgilerin bozulmasına neden olur ve ağdaki çarpışmaların ve hataların nedenidir. Bu etkiye zemin döngüsü veya zeminler arası gürültü denir.

Benzer bir etki, bir koaksiyel kablo parçası birden fazla noktada topraklandığında ortaya çıkar. Bu genellikle ağ kartının T-konektörü bilgisayar kasası ile temas halindeyken olur.

Kesintisiz bir güç kaynağının kurulumunun açıklanan zorlukları ortadan kaldırmadığına dikkatinizi çekiyoruz. Bu sorunların ve çözümlerinin en ayrıntılı tartışması için APC (Amerikan Güç Dönüşümü) Güç Koruma El Kitabına bakın.

10Base2 ağlarında çok sayıda çarpışma ve hata bulunursa, yapılacak ilk şey koaksiyel kablo kılıfı ile bilgisayar kasaları arasındaki potansiyel farkı kontrol etmektir. Ağdaki herhangi bir bilgisayar için değeri birden fazla AC volt ise, ağ, bilgisayarların toprak hatlarının topolojisi ile uygun değildir.

Üçüncü sahne

Ağın bağlantı katmanındaki hata sayısının ölçümü.

Ethernet ağlarında, aşağıdaki hata türleri en yaygın olanıdır.

Kısa Çerçeve - Geçerli bir kontrol sırası ile 64 bayttan daha kısa (8 baytlık girişten sonra) bir çerçeve. Kısa çerçevelerin en olası nedeni, hatalı bir ağ kartı veya yanlış yapılandırılmış veya bozuk bir ağ sürücüsüdür.

Son zamanlarda, NE2000 ağ kartlarıyla Windows 95 çalıştıran nispeten yavaş bilgisayarlarda (486 / SX) bu tür çok sayıda hata gördük. Nedeni bizim için bilinmiyor.

Uzun çerçeve - 1518 bayttan uzun bir çerçeve. Uzun bir çerçevenin doğru veya yanlış bir kontrol sırası olabilir. İkinci durumda, bu tür çerçevelere genellikle jabber denir. Doğru kontrol sırası ile uzun kareler yakalamak, çoğunlukla ağ sürücüsünün yanlış çalıştığını gösterir; jabber hatalarını düzeltme - aktif ekipmanın arızalanması veya harici parazitin varlığı için.

Kontrol dizisi hataları (CRC hatası) - geçerli bir uzunlukta (64 ila 1518 bayt arasında), ancak yanlış bir kontrol dizisiyle (CRC alanında hata) iyi biçimlendirilmiş bir çerçeve.

Bir hizalama hatası, bayt sayısının katı olmayan bir dizi bit içeren bir çerçevedir.

Parlama (hayalet) - Ethernet çerçevelerinden farklı, ayırıcı (SFD) olmayan ve 72 bayttan uzun bir sinyal dizisi. Bu terim ilk olarak Fluke tarafından bir iletişim bağlantısındaki uzak çarpışmalar ve gürültü arasında ayrım yapmak için kullanılmıştır.

Parlama en sinsi hatadır, çünkü yazılım protokolü analizörleri tarafından başlangıç ​​iletim aşamasındaki çarpışmalarla aynı nedenle tanınmaz. Parlama, özel cihazlarla veya ağın stres testi yöntemi kullanılarak tespit edilebilir (bu yöntemden ilerideki yayınlarda bahsetmeyi planlıyoruz).

SNMP tabanlı ağ yönetim yazılımı dağıtıcılarının haklı öfkesine maruz kalma riskine rağmen, yine de ağ bağlantı katmanı hatalarının uygulama yanıt süresi üzerindeki etkisinin büyük ölçüde abartılı olduğunu iddia etmeye cesaret edebiliriz.

Genel kabul görmüş standarda göre, fiili bağlantı katmanı hatalarının sayısı, ağ üzerinden iletilen toplam çerçeve sayısının %1'ini geçmemelidir. Deneyimler, bu değerin yalnızca ağın kablo sisteminde bariz kusurların varlığında örtüştüğünü göstermektedir. Aynı zamanda, çok sayıda ağ arızasına neden olan aktif ekipmanın birçok ciddi kusuru, ağın veri bağlantı katmanında kendini göstermez (bkz. Kural # 3.8).

Kural #3.1.

Ağ hatalarını analiz etmeden önce, protokol analizör yazılımınızı çalıştıran bilgisayardaki ağ kartı ve kart sürücüsü tarafından ne tür hataların algılanabileceğini öğrenin.

Herhangi bir protokol analiz cihazının çalışması, ağ kartının ve sürücünün tüm ağ çerçevelerini alma moduna (rastgele mod) getirilmesine dayanır. Bu modda ağ kartı, normal modda olduğu gibi sadece yayın yapmakla kalmaz, ağdan geçen tüm çerçeveleri alır ve doğrudan ona hitap eder. Protokol analizörü, ağdaki olaylarla ilgili tüm bilgileri, tüm çerçeveleri alma modunda çalışan ağ kartı sürücüsünden alır.

Tüm ağ kartları ve ağ sürücüleri, protokol çözümleyicisine ağ hataları hakkında aynı ve eksiksiz bilgi sağlamaz. 3Com ağ kartları hiçbir şekilde hata bilgisi vermiyor. Böyle bir panoya bir protokol analizörü kurarsanız, tüm hata sayaçlarındaki değerler sıfır olacaktır.

Intel EtherExpress Pro yalnızca CRC ve hizalama hatalarını bildirir. SMC NIC'ler yalnızca kısa çerçeve bilgileri sağlar. NE2000, CRC hatalarını, kısa çerçeveleri, hizalama hatalarını, çarpışmaları tespit ederek neredeyse eksiksiz bilgi sağlar.

D-Link ağ kartları (örneğin, DFE-500TX) ve Kingstone (örneğin, KNE 100TX) raporu tamamlandı ve özel bir sürücü mevcutsa, ağdaki hatalar ve çarpışmalar hakkında kapsamlı bilgiler bile.

Bir dizi protokol çözümleyici satıcısı, en popüler ağ kartları için kendi sürücülerini sunar.

Kural # 3.2.

Hataların istasyonların belirli MAC adreslerine "bağlanmasına" dikkat edin.

Bir yerel ağı analiz ederken, hataların genellikle istasyonların belirli MAC adreslerine "bağlı" olduğunu fark etmişsinizdir. Ancak çerçevenin adres kısmında meydana gelen çarpışmalar, kamaşma, sıfır veri uzunluğuna sahip kısa çerçeve gibi tanınmayan durumlar belirli MAC adreslerine "bağlanamaz".

Ağda belirli MAC adresleriyle ilişkili olmayan birçok hata varsa, bunların kaynağı büyük olasılıkla etkin olmayan bir ekipmandır. Büyük olasılıkla, bu tür hatalar, çarpışmaların, ağ kablolama sistemindeki kusurların veya güçlü harici gürültünün sonucudur. Ayrıca, aktif ekipmanı besleyen voltajdaki düşük kalite veya kesintilerden de kaynaklanabilir.

Hataların çoğu istasyonların belirli MAC adreslerine bağlıysa, hatalı çerçeveler ileten istasyonların konumu, sayacın konumu (bkz. Kural # 3.3, # 3.4) ve ağ topolojisi arasında bir model belirlemeye çalışın.

Kural # 3.3.

Tek bir çarpışma alanı içinde, protokol analizörü tarafından tespit edilen hataların türü ve sayısı, ölçüm cihazının nereye bağlandığına bağlıdır.

Başka bir deyişle, bir koaksiyel kablo parçası, göbek veya göbek yığını içinde, bağlantı istatistikleri sayacın nereye bağlandığına bağlı olarak değişebilir.

Birçok ağ yöneticisine bu ifade, yedi katmanlı OSI modelinin ilkeleriyle çeliştiği için saçma görünebilir. Bu olayla ilk karşılaştığımızda biz de sonuca inanmadık ve ölçüm cihazının arızalı olduğuna karar verdik. Bu fenomeni tamamen yazılımdan yazılıma ve donanıma kadar farklı ölçüm cihazlarıyla test ettik. Sonuç aynıydı.

Aynı enterferans, enterferans kaynağının ve ölçüm cihazının göreli konumuna bağlı olarak bir CRC hatasına, parlamaya, uzaktan çarpışmaya veya hiç algılanmamasına neden olabilir. Aynı çarpışma, çakışan istasyonların ve ölçüm cihazının göreceli konumuna bağlı olarak uzak veya geç olarak kaydedilebilir. Yığındaki bir hub'da CRC hatası içeren bir çerçeve, aynı yığındaki başka bir hub'da işlenemez.

Bu buluşsal yöntemin bir sonucu, SNMP tabanlı ağ izleme programlarının ağ hatalarının istatistiklerini her zaman yeterince yansıtmadığı gerçeğidir. Bunun nedeni, aktif ekipmana yerleşik SNMP aracısının ağı her zaman yalnızca bir noktadan izlemesidir. Örneğin, ağ bir "akıllı" anahtara bağlı birkaç "aptal" hub yığınından oluşuyorsa, anahtarın SNMP aracısı bazen hub yığınındaki bazı hataları görmeyebilir.

Bu kuralın teyidi Fluke (www.fluke.com) ve Net3 Group'un (www.net3group.com) Web sunucularında bulunabilir.

Kural # 3.4.

Ağın bağlantı seviyesindeki hataları tespit etmek için, kendi trafik protokollerini oluşturan analizörün arka planına karşı ölçümler yapılmalıdır.

Trafik üretimi mevcut sorunları şiddetlendirir ve tezahürleri için koşullar yaratır. Trafik, düşük bir yoğunluğa sahip olmalıdır (100 kare / s'den fazla olmamalıdır) ve ağda çarpışmaların oluşumuna katkıda bulunmalıdır, yani. kısa (<100 байт) кадры.

Bir protokol analizörü veya başka bir teşhis aracı seçerken, öncelikle seçilen aracın belirli bir yoğunlukta trafik oluşturmak için yerleşik bir işlevi olduğu gerçeğine dikkat edilmelidir. Bu özellik, diğerlerinin yanı sıra, Network Instruments'tan Observer'da ve Cinco'dan NetXray'de (şimdi Network Associates) mevcuttur.

Kural # 3.5.

Gözlenen istatistikler ölçüm cihazının nereye bağlı olduğuna bağlıysa, o zaman hataların kaynağı büyük olasılıkla bu ağ alanının fiziksel seviyesindedir (nedeni kablo sistemi kusurları veya harici bir kaynaktan gelen gürültüdür). Aksi takdirde, hataların kaynağı bağlantı katmanında (veya daha yüksek) veya başka bir bitişik ağ etki alanında bulunur.

Kural # 3.6.

Toplam hata sayısındaki CRC hatalarının oranı büyükse, bu tür hataları içeren çerçevelerin uzunluğu belirlenmelidir.

Daha önce de belirttiğimiz gibi, CRC hataları, çarpışmalar, kablolama sistemindeki kusurlar, harici bir gürültü kaynağı ve hatalı alıcı-vericilerin bir sonucu olarak ortaya çıkabilir. CRC hatalarının bir başka olası nedeni, çerçevenin sonuna birkaç "boş" bayt ekleyen hatalı hub veya anahtar bağlantı noktaları olabilir.

Toplam hata sayısında CRC hatalarının büyük bir kısmı ile, bunların ortaya çıkma nedenini bulmanız tavsiye edilir. Bunu yapmak için, bir dizideki hatalı çekimler, aynı dizideki benzer iyi çekimlerle karşılaştırılmalıdır. Hatalı çerçeveler, iyi çerçevelerden önemli ölçüde daha kısaysa, bunlar büyük olasılıkla çarpışmaların sonuçlarıdır. Hatalı çerçeveler hemen hemen aynı uzunluktaysa, bozulmanın nedeni büyük olasılıkla bir dış gürültüdür. Kötü çerçeveler iyi çerçevelerden daha uzunsa, bunun nedeni büyük olasılıkla çerçevenin sonuna "boş" bayt ekleyen hub veya anahtarın kusurlu bağlantı noktasında yatmaktadır.

Hatalı ve doğru çerçevelerin uzunluğunu karşılaştırmanın en kolay yolu, analizör arabelleğinde CRC hatası olan bir dizi çerçeve toplamaktır.

Kural # 3.7.

Tablo1, 2. ve 3. aşamalar için hataların ve çarpışmaların nedenlerini özetlemektedir.

Tablo 1 - MEASURING TOOL tarafından kaydedilen hata ve çarpışma türleri
Hataların nedeni	Yerel çarpışmalar	Kaldırılan çarpışmalar	Geç çarpışmalar	Kısa atış	Uzun çerçeve	jabber	CRC hatası
Arızalı ağ kartı	> %5 sen<30%	> %5 sen<30%	Orada	Orada	Orada	Orada	Orada
Arızalı sürücü kartı				Orada	Orada	Orada	Orada
Arızalı hub, tekrarlayıcı, alıcı-verici	> %5 sen<30%	> %5 sen<30%	Orada			Orada	Orada
Aktif ekipmanın yanlış bağlanması	> %5 sen<30%	> %5 sen<30%	Orada			Orada
çok uzun kablo			Orada				Orada
4'ten fazla tekrarlayıcı veya kademeli hub			Orada
Bilgisayarların veya koaksiyel kablonun yanlış topraklanması	> %5 sen<30%	> %5 sen<30%	Orada			Orada	Orada
Kablolama ve pasif ekipmandaki kusurlar	> %5 sen<30%	> %5 sen<30%	Orada			Orada	Orada
Kablo sisteminin yakınında gürültü kaynağı	> %5 sen<30%	> %5 sen<30%	Orada			Orada	Orada
Not. U - iletişim kanalının kullanımı

Ağınızı ilk kez teşhis ediyorsanız ve sorun yaşıyorsanız, ağınızda yalnızca bir bileşenin arızalı olmasını beklememelisiniz.

Kusurları bulmanın en güvenilir yolu, bilgisayarların toprak hatlarının topolojisini (özellikle 10Base2 ağları için) iyice kontrol etmek için şüpheli istasyonları, hub'ları ve kablo yollarını tek tek kapatmaktır.

Kullanıcı etkinliğiyle ilgili olmayan öngörülemeyen zamanlarda ağ kesintileri meydana gelirse, bir kablo tarayıcı kullanarak kablodaki gürültü seviyesini kontrol edin. Tarayıcı yoksa, kablonun güçlü elektromanyetik radyasyon kaynaklarının yakınından geçmediğinden görsel olarak emin olun: yüksek voltajlı veya yüksek akımlı kablolar, flüoresan lambalar, elektrik motorları, kopyalama ekipmanı vb.

Kural # 3.8.

Bağlantı katmanında hata olmaması, ağınızdaki bilgilerin bozulmayacağını garanti etmez.

Bu bölümün başında, bağlantı katmanı hatalarının ağ performansı üzerindeki etkisinin büyük ölçüde abartıldığı belirtilmişti. Alt katman hatalarının sonucu çerçeve yeniden iletimidir. Ethernet ağının yüksek hızı (özellikle Fast Ethernet) ve modern bilgisayarların yüksek performansı nedeniyle, düşük seviyeli hatalar uygulama yazılımının yanıt süresini önemli ölçüde etkilemez.

Ağın yalnızca alt (kanal ve fiziksel) seviyelerindeki hataların ortadan kaldırılmasının, uygulama yazılımının yanıt süresini önemli ölçüde iyileştirmemize izin verdiği durumlarla çok nadiren karşılaştık. Sorunların çoğu, ağın kablo sistemindeki ciddi kusurlarla ilişkilendirildi.

Ağ kartlarında, yönlendiricilerde veya anahtarlarda daha düşük seviyelerdeki hatalar hakkında bilgi yokluğunda bilgilerin kaybolması veya bozulması gibi hatalar, ağdaki uygulama yazılımlarının çalışması üzerinde çok daha büyük bir etkiye sahiptir. "Bilgi" kelimesini kullanıyoruz çünkü bozulma anında veriler henüz çerçevelenmemiş.

Bu tür kusurların nedeni aşağıdaki gibidir. Bilgi, aktif ekipmanın - bir ağ kartı, yönlendirici veya anahtar - "derinlerinde" bozulur (veya kaybolur). Bu durumda, bu ekipmanın alıcı-verici birimi, önceden bozulmuş bilgilerin doğru kontrol sırasını (CRC) hesaplar ve ağ üzerinden doğru biçimlendirilmiş bir çerçeve iletilir. Doğal olarak, bu durumda hiçbir hata kaydedilmez. Aktif ekipmana yerleşik SNMP aracıları burada yardımcı olamaz.

Bazen, bozulmaya ek olarak bilgi kaybolur. Çoğu zaman ucuz ağ kartlarında veya Ethernet-FDDI anahtarlarında olur. İkinci durumda bilginin kaybolma mekanizması açıktır. Bir dizi Ethernet-FDDI anahtarında, hızlı bir bağlantı noktasından yavaş olana (veya tam tersi) bir geri bildirim yoktur, sonuç olarak, diğer bağlantı noktası hızlı giriş / çıkış arabelleklerinin tıkanıklığı hakkında bilgi almaz. (yavaş) bağlantı noktası. Bu durumda, yoğun trafik ile bağlantı noktalarından biri hakkındaki bilgiler kaybolabilir.

Deneyimli bir ağ yöneticisi, IPX ve TCP/IP protokollerinde veri bağlantı katmanındaki bilgileri korumaya ek olarak, bir sağlama toplamı kullanarak bilgileri korumanın mümkün olduğunu iddia edebilir.

Sağlama toplamı korumasına yalnızca uygulama yazılımının aktarım protokolü olarak TCP veya UDP kullanması durumunda tam olarak güvenilebilir. Yalnızca kullanıldıklarında, paketin tamamı bir sağlama toplamı ile korunur. IPX / SPX veya IP'nin kendisi "aktarım" olarak kullanılıyorsa, sağlama toplamı tarafından yalnızca paket başlığı korunur.

Sağlama toplamı korumasının varlığında bile, açıklanan bozulma veya bilgilerin kaybolması, uygulama yazılımının yanıt süresinde önemli bir artışa neden olur.

Koruma kurulu değilse, uygulama yazılımının davranışı tahmin edilemez olabilir.

Şüpheli ekipmanı değiştirmenin (kapatmanın) yanı sıra, bu tür kusurları belirlemenin iki yolu vardır.

İlk yöntem, şüpheli bir istasyon, yönlendirici veya anahtardan kareleri yakalamak, kodunu çözmek ve analiz etmektir. Bu kusur, öncesinde bir alt ağ katmanı hatası olmayan bir IP veya IPX paketinin yeniden iletimi ile belirtilir. Bazı protokol çözümleyicileri ve uzman sistemler, izleme analizi gerçekleştirerek veya paketlerin sağlama toplamını bağımsız olarak hesaplayarak görevi basitleştirir.

İkinci yöntem, ağ stres testi yöntemidir.

Sonuçlar. Bir ağın bağlantı katmanının teşhisinin ana görevi, ağda artan sayıda çarpışma ve hatanın varlığını tespit etmek ve hata sayısı, iletişim kanalının tıkanıklık derecesi, ağ arasındaki ilişkiyi bulmaktır. topoloji ve ölçüm cihazının bağlantı noktası. Tüm ölçümler, kendi trafik protokollerini oluşturan analizörün arka planına karşı yapılmalıdır.

Artan hata ve çarpışma sayısının iletişim kanalının tıkanıklığının bir sonucu olmadığı belirlenirse, çalışması sırasında artan sayıda hata olan ağ ekipmanı değiştirilmelidir.

Belirli ekipmanın çalışması ile hataların ortaya çıkması arasındaki ilişkiyi belirlemek mümkün değilse, o zaman kapsamlı bir kablo sistemi testi yapın, kablodaki gürültü seviyesini, bilgisayarların toprak hatlarının topolojisini, besleme voltajının kalitesi.

Bir ağ teşhisi yapılırken hangi parametrelerin izlenmesi gerekir? Proaktif Ağ Tanılama Tekniği

Proaktif teşhis tekniği aşağıdaki gibidir. Ağ yöneticisi, ağ performansını sürekli olarak veya uzun bir süre boyunca izlemelidir. Kurulum anından itibaren bu tür gözlemlerin yapılması arzu edilir. Bu gözlemlere dayanarak, yönetici, ilk olarak, gözlemlenen parametrelerin değerlerinin ağ kullanıcılarının çalışmalarını nasıl etkilediğini ve ikinci olarak, uzun bir süre boyunca nasıl değiştiklerini belirlemelidir: bir çalışma günü, hafta, ay, çeyrek. , yıl vs...

Gözlenebilir parametreler genellikle:

• ağ iletişim kanalının parametreleri - iletişim kanalının kullanımı, ağın her istasyonu tarafından alınan ve iletilen çerçevelerin sayısı, ağdaki hataların sayısı, yayın ve çok noktaya yayın çerçevelerinin sayısı, vb.;
sunucu işlem parametreleri - sunucu işlemcisinin kullanımı, bekleyen (bekleyen) disk isteklerinin sayısı, toplam önbellek arabellek sayısı, kirli önbellek arabelleklerinin sayısı, vb.

Uygulama yazılımının tepki süresi ile izlenen parametrelerin değerleri arasındaki ilişkiyi bilen ağ yöneticisi, verilen ağ için izin verilen maksimum parametre değerlerini belirlemelidir. Bu değerler teşhis aracında eşik olarak girilir. Ağın çalışması sırasında gözlemlenen parametrelerin değerleri eşik değerlerini aşarsa, teşhis aracı ağ yöneticisini bu olay hakkında bilgilendirecektir. Bu durum ağda bir sorun olduğunu gösterir.

İletişim kanalının ve sunucunun çalışmasını yeterince uzun süre gözlemleyerek, ağ işleminin çeşitli parametrelerinin (kaynakların kullanımı, hata sayısı vb.) Değerlerinde bir değişiklik eğilimi oluşturabilirsiniz. Yönetici, bu tür gözlemlere dayanarak, aktif ekipmanı değiştirme veya ağ mimarisini değiştirme ihtiyacı hakkında sonuçlar çıkarabilir.

Ağda bir sorun ortaya çıkarsa, yönetici, tezahürü anında kanal izinin bir dökümünü özel bir arabelleğe veya dosyaya yazmalı ve içeriğinin analizine dayanarak sorunun olası nedenleri hakkında sonuçlar çıkarmalıdır.

Bir ağ sorunuyla karşılaştığınızda, en yaygın çözüm, hataları tespit etmek ve düzeltmek için bir tanılama programı çalıştırmaktır. Ancak en yaygın ağ sorunları ping, tracert, ipconfig vb. basit komutlarla çözülebilir.

Bunu biliyor musun?
Emretmek "ipconfig" hem Windows hem de Linux / Unix makinelerinde IP adresine göre bir bilgisayar bulmak için kullanılabilir.

Aşağıdaki komutların tümü komut satırına girilmelidir. Windows'ta bir komut istemi açmak için aşağıdakilerden birini yapın:

• Başlat -> Tüm Programlar -> Donatılar -> Komut İstemi.
• Başlat -> Çalıştır ve programın adını girin cmd.exe
• Tuşlara basın kazan +r ve programın adını girin cmd.exe

Temel ağ bilgisine sahip herkes ipconfig komutunu bilir. Bu komut, bilgisayarın IP adresi ile birlikte DNS, DHCP, ağ geçidi ve alt ağ maskesi hakkında bilgi verir. Daha fazla sorun giderme komutları için IP adresi gereklidir. Bu komut varsayılan ağ geçidi 0.0.0.0'ı döndürürse, yönlendiricinizle ilgili bir sorununuz var demektir. Ağ sorunlarınızı gidermek için bu komutun başka bir varyasyonunu deneyebilirsiniz. Bu komutun bir diğer uzantısı ipconfig /flushdns komutudur. Herhangi bir yetkisiz IP adresi veya teknik arıza durumunda DNS önbelleğini temizler.

Emretmek "ping"

Ping, web'de kullanılan en önemli komutlardan biridir. Bu komut, ana bilgisayar ile hedef arasındaki bağlantıyı test etmek için kullanılır. Bu komutu kullanmanın ana avantajı, ağdaki sorunlu alanı bulmaktır. Ağdaki herhangi bir bilgisayara ping atarsanız, yönlendirici durumunu alırsınız. Ayrıca, ping isteğine dört yanıt alacaksınız. Yanıt almazsanız, bu ağ kartında bir sorun olduğunu gösterir.

Ping komutunu kullanmanın bir diğer avantajı da herhangi bir web sitesine / internete olan bağlantıyı test etme yeteneğidir. Bunun için ping komutundan sonra sitenin adını girmeniz gerekiyor. Web sitesinden yanıt alıyorsanız, pratikte sorun yok. Ancak yanıt alamazsanız, hatalı bir kablo, DSL modem veya ISP bağlantı sorununuz olabilir. Olasılığı daha da daraltmak ve sorunun temel nedenini bulmak için ping 4.2.2.1 yazın. Komut satırında yanıt alıyorsanız ancak yine de web sitesine erişemiyorsanız, DNS yapılandırma sorunlarınız var demektir.

tracert komutu, hedefe ulaşmak için gereken tüm veri yolunu döndürür. Cevap, hedefine ulaşmak için verilerin geçtiği geçiş noktalarının bir listesi olacaktır. Yakından bakarsanız, ağın her öğe ile değiştiğini göreceksiniz. Bu, her ağın hedefine ulaşana kadar verileri başka bir ağa ilettiği anlamına gelir. Ancak bazı noktalarda yıldız işaretleri görebilirsiniz, bu yıldızlar sorunlu bir ağı temsil eder.

Etki Alanı Adı Sistemi (DNS adresleri) temel olarak birçok ağ sorununun temel nedenidir.Bu IP adresleri, ağ cihazlarının İnternete veya bir ağa bağlanabilmesi için çalışması için gereklidir. Bu adreslerde sorun olması durumunda tüm ağın işlevleri engellenir. nslookup komutu, bir etki alanı adıyla ilişkili IP adreslerini listeler. IP adresi ile ilgili herhangi bir bilgi alamıyorsanız, bir DNS sorunu var demektir.

Ağlar söz konusu olduğunda, tek bir yönlendiriciye çok sayıda ana bilgisayar bağlanır. Bu nedenle, ağ sorunları olması durumunda her bir düğümün bağlantısını doğrulamak gibi göz korkutucu bir görev ortaya çıkar. Ancak aynı zamanda bağlantıların (TCP, UDP portları) aktif olup olmadığının kontrol edilmesi de önemlidir. Netstat komutu, yönlendiriciye bağlı tüm bilgisayarların bir listesini ve durumlarını döndürür. Bu durumu bilerek, hatalı veya kapalı veya boş durumda olan TCP/udp bağlantısının port numarasını (ve IP adresini) bileceksiniz.

"arp" komutu, IP'yi yerel ağ adreslerine dönüştürmekle ilgili sorunları belirlemek için kullanılan harici bir komuttur. "arp" tablosunda bulunabilecek en yaygın sorun, aynı IP adresinin iki sistem arasında paylaşılmasıdır. İki ana bilgisayar (biri kesinlikle yanlış olan) aynı IP adresini kullanıyor ve bu durumda yanlış ana bilgisayarın IP'ye yanıt verme olasılığı yüksektir. Bu, tüm ağınızı etkileyecektir. Eşleştirilmiş yerel ağlar olup olmadığını ve atanan IP adreslerinin doğruluğunu kontrol etmelisiniz. Bunu yapmak için, her ana bilgisayarın ağ adreslerini listelemelisiniz. Listenizi ve "arp" komut tablosunu karşılaştırarak, sorunlu ana bilgisayarı kolayca tanımlayabilirsiniz.

COP'yi teşhis etmek ve izlemek için kullanılan araçlar birkaç büyük sınıfa ayrılabilir:

- Ağ Yönetim Sistemleri- ağın düğümlerinin ve iletişim cihazlarının durumu hakkında ve ayrıca ağda dolaşan trafik hakkında veri toplayan TMN modeline göre oluşturulmuş merkezi yazılım sistemleri. Bu sistemler yalnızca ağı izlemek ve analiz etmekle kalmaz, aynı zamanda otomatik veya yarı otomatik modda ağ yönetimi eylemlerini gerçekleştirir - cihaz portlarını etkinleştirir ve devre dışı bırakır, köprülerin, anahtarların ve yönlendiricilerin adres tablolarındaki köprülerin parametrelerini değiştirir, vb. Kontrol sistemlerine örnekler, popüler sistemler HP OpenView, Sun NetManager, IBM NetView, Tivoli'dir. ISO tavsiyelerine göre, ağ yönetim sistemlerinin aşağıdaki işlevleri ayırt edilebilir:

Ağ yapılandırması ve adlandırma yönetimi - konumları, ağ adresleri ve tanımlayıcıları dahil ağ bileşenlerinin yapılandırılması, ağ işletim sistemlerinin parametrelerinin yönetilmesi, ağ şemasının sürdürülmesinden oluşur. Bu işlevler aynı zamanda nesneleri adlandırmak için de kullanılır.

Hata işleme - ağdaki arızaların ve arızaların sonuçlarının belirlenmesi, belirlenmesi ve ortadan kaldırılması.

Performans analizi - birikmiş istatistiksel bilgilere dayanarak, sistemin yanıt süresini ve trafik miktarını tahmin etmenin yanı sıra ağın gelişimini planlamaya yardımcı olur.

Güvenlik yönetimi - erişim denetimi ve veri bütünlüğü korumasını içerir. İşlevler, kimlik doğrulama prosedürünü, ayrıcalıkların kontrol edilmesini, şifreleme anahtarları için destek, ayrıcalıkların yönetimini içerir. Bu grup ayrıca parolaları, harici erişimi ve diğer ağlara bağlantıları yönetmek için önemli mekanizmalar içerir.

Ağ Hesabı - kullanılan kaynakların ve cihazların kaydını ve yönetimini içerir. Bu işlev, kullanım süresi ve kaynak ücretleri gibi kavramlarla çalışır.

- Sistem Yönetim Araçları) - genellikle kontrol sistemlerinin işlevlerine benzer işlevleri yerine getirir, ancak diğer nesnelerle ilgili olarak. İlk durumda, kontrol nesnesi ağdaki bilgisayarların yazılım ve donanımı, ikincisinde ise iletişim ekipmanıdır. Kontrollerin ana işlevleri aşağıda listelenmiştir:

Kullanılan donanım ve yazılımın muhasebeleştirilmesi. Sistem, ankete katılan bilgisayarlar hakkında otomatik olarak bilgi toplar ve donanım ve yazılım kaynakları veritabanında kayıtlar oluşturur. Bundan sonra yönetici, neye sahip olduğunu ve nerede olduğunu hızlı bir şekilde öğrenebilir. Örneğin, hangi bilgisayarların yazıcı sürücülerini güncellemesi gerektiğini, hangi bilgisayarların yeterli belleğe ve disk alanına sahip olduğunu vb. öğrenin.

Yazılım dağıtımı ve kurulumu. Anketi tamamladıktan sonra, yönetici yazılım dağıtım paketleri oluşturabilir - bu tür bir prosedürün maliyetini düşürmenin çok etkili bir yolu. Sistem ayrıca, dosya sunucularından çalışan uygulamaların merkezi olarak kurulmasına ve yönetilmesine izin vermenin yanı sıra, son kullanıcıların bu tür uygulamaları ağdaki herhangi bir iş istasyonundan çalıştırmasına olanak tanır.

Performansın ve ortaya çıkan sorunların uzaktan analizi. Yönetici, fareyi, klavyeyi uzaktan kontrol edebilir ve belirli bir ağ işletim sisteminin kontrolü altında ağda çalışan herhangi bir bilgisayarın ekranını görebilir. Yönetim sistemi veritabanı, sorunların uzaktan analiz edilebilmesi için genellikle ağdaki tüm bilgisayarlar için ayrıntılı yapılandırma bilgilerini depolar.

Sistem yönetimi araçlarına örnek olarak Microsoft'un Sistem Yönetim Sunucusu veya Intel'in LANDeskManager'ı verilebilir ve tipik ağ yönetimi araçları HPOpenView, SunNetManager ve IBMNetView'dir.

- Gömülü teşhis ve yönetim sistemleri (Gömülü sistemler) - Bu sistemler, iletişim ekipmanına kurulu yazılım ve donanım modülleri şeklinde ve işletim sistemlerine yerleşik yazılım modülleri şeklinde uygulanır. Tek bir cihaz için teşhis ve kontrol fonksiyonlarını yerine getirirler ve bu, merkezi kontrol sistemlerinden temel farkıdır. Bu araç sınıfının bir örneği, hataların tespiti üzerine bağlantı noktalarının otomatik olarak bölümlere ayrılması, bağlantı noktalarının hub'ın iç bölümlerine atanması ve diğer bazı işlevlerini uygulayan Distributed 5000 hub yönetim modülüdür. Tipik olarak, yerleşik yönetim modülleri, yönetim sistemlerine cihaz durumu bilgisi sağlamak için SNMP aracıları olarak işlev görür.

- Protokol analizörleri- Kontrol sistemlerinin aksine kablosuz olanlar da dahil olmak üzere ağlardaki trafiği izleme ve analiz etme işlevleriyle sınırlı olan yazılım veya donanım-yazılım sistemleridir. Protokol analizörleri tarafından bir dizi değerlendirme kriteri ayırt edilir:

- Ağ protokollerini çözebilme ve fiziksel arayüzler için destek.

- Yazılım arayüzünün kalitesi (yakalama arabelleği, filtreler, anahtarlar, filtre sonrası arama, istatistik aralığı).

- Çok kanallı varlığı.

- Trafik üretimi.

- PC ile entegrasyon imkanı.

- Ebat ve ağırlık.

- Sağlanan para ve hizmetler için değer.

- Kablo sistemlerinin teşhisi ve sertifikasyonu için donatım- Geleneksel olarak, bu ekipman dört ana gruba ayrılabilir: ağ monitörleri, kablo sistemlerinin sertifikasyonu için cihazlar, kablo tarayıcılar ve test cihazları (multimetreler).

Ağ monitörleri (ağ analizörleri olarak da adlandırılır), kabloları ve kablolama sistemlerini teşhis etmek ve onaylamak için referans ölçüm araçlarıdır. Bir örnek, HewlettPackard - HP 4195A ve HP 8510C'nin ağ analizörleridir. Ağ analizörleri, yüksek hassasiyetli bir frekans üreteci ve bir dar bantlı alıcı içerir. Farklı frekanslardaki sinyalleri verici çifte ileterek ve alıcı çiftteki sinyali ölçerek zayıflama ve SONRAKİ ölçülebilir. Ağ analizörleri, özel eğitimli teknik personel tarafından laboratuvarda kullanılmak üzere tasarlanmış yüksek hassasiyetli, büyük ölçekli ve pahalı (20 "000 doların üzerinde) cihazlardır.

Kablolama sistemlerinin sertifikalandırılmasına yönelik cihazların amacı, doğrudan adlarından kaynaklanmaktadır. Belgelendirme, kablolama sistemleri için uluslararası standartlardan birinin gerekliliklerine uygun olarak gerçekleştirilir.

Kablo tarayıcılar, bakır kablolama sistemlerini teşhis etmek için kullanılır. Bu cihazlar kablo uzunluğu, SONRAKİ, zayıflama, empedans, bağlantı şeması, elektriksel gürültü seviyesini belirlemenizi ve elde edilen sonuçları değerlendirmenizi sağlar. Bu cihazların fiyatları 1.000$ ile 3.000$ arasında değişmektedir. Bu sınıfın birçok cihazı vardır, örneğin Microtest Inc., Fluke Corp., Datacom Technologies Inc., Scope Communication Inc.'den tarayıcılar. Ağ analizörlerinden farklı olarak, tarayıcılar yalnızca özel olarak eğitilmiş teknik personel tarafından değil, aynı zamanda acemi yöneticiler tarafından bile kullanılabilir.

Test cihazları, kablolarda fiziksel kırılma olup olmadığını kontrol etmek için tasarlanmıştır. Bunlar kablo teşhisi için en basit ve en ucuz cihazlardır. Kablonun sürekliliğini belirlemenizi sağlarlar ancak arızanın nerede meydana geldiği sorusuna cevap vermezler.

Analiz ve teşhis için çok işlevli cihazlar. Son yıllarda, yerel ağların her yerde bulunmasıyla bağlantılı olarak, protokol analizörleri, kablo tarayıcılar ve hatta ağ yönetim yazılımının bazı yetenekleri gibi birkaç cihazın işlevlerini birleştiren ucuz taşınabilir cihazlar geliştirmek gerekli hale geldi. Microtest Inc. firmasından Compas, bu tür bir cihaz örneğidir. veya FlukeCorp'tan 675 LANMeter.

Fiber optik iletişim ağlarının her yerde bulunmasıyla bağlantılı olarak, fiber optik iletişim hatlarını test etmek için araçlar giderek daha önemli hale geliyor.

Görsel Hata Bulucu - VFL (Görsel Hata Bulucu) polariteyi kontrol etmek ve ayrıca kablodaki kabul edilemez bükülmeleri veya kırılmaları tespit etmek için kullanılabilir. VFL, yayılan akımı kablonun bir ucuna gönderen güçlü bir kızılötesi lazerdir. Bu durumda, VFL sürekliliği belirler, konektörlerin doğru bağlantısını tanımlar.

Optik Kayıp Analiz Cihazı - OLTS (Optik Kayıp Test Seti) iki bileşen içerir: bir ışık kaynağı ve bir optik sinyal güç ölçer. Bu tür teşhis aracını kullanarak fiberin bütünlüğünü kontrol edebilir ve kablonun belirlenmiş standartları karşıladığını doğrulayabilirsiniz. Birçok cihaz bu karşılaştırmayı otomatik olarak yapar.

Optik kabloyu test etmek için üçüncü tip cihazlar, optik sistemleri onaylayan cihazlardır - CTS (Sertifika Test Seti) - karmaşık bir OLTS. Bu ekipman sinyal kaybını ölçebilir ve hesaplayabilir, polariteyi kontrol edebilir, kablo uzunluğunu belirleyebilir, bunları yerleşik standart kitaplıkla karşılaştırabilir, bağlantı haritasını sunabilir. Alınan tüm bilgileri daha sonra bir bilgisayara aktarmak için kaydetmek de mümkündür, bu da derin bir analiz yapmaya ve bir rapor hazırlamaya yardımcı olacaktır. CTS, bir optik sinyal güç ölçer ve bir çift dalga boyu kaynağı dahil olmak üzere bir ana ünite ve birkaç uzak üniteden (her test kablosunun ucunda) oluşur.

Optik Alan Reflektometreleri (OTDR'ler), fiberin bir ucundan kısa bir ışık darbesi göndererek ve fiberin diğer ucundan yansıyan ışığı analiz ederek bir optik sinyaldeki güç kaybını karakterize etmek için kullanılan tanılama araçlarıdır. OTDR, okumaları kaydederek optik gücü, sinyal geçiş süresini belirler ve bu verileri bir grafik şeklinde görüntüler. Bu cihazlar, fiber parçaların uzunluğu, sinyal zayıflamasının tekdüzeliği, konektörlerin konumu dahil olmak üzere ağa dahil olan öğeleri ölçmenize olanak tanır. Böylece, grafiği analiz ederek veya OTDR cihazları tarafından oluşturulabilen bir olay tablosunu kullanarak yansıtıcı olayları (bağlantılar, fiber kopmaları) ve yansıtıcı olmayan olayları (bağlantılar, geçersiz veya stres bükülmeleri) görsel olarak bulmak mümkündür.

Şekil 1.3 - Optik Zaman Alanı Reflektometresi

Reflektometre MTS 8000 - fiber optik sistemler için yeni bir çok modüllü test platformudur. Bu cihaz bir reflektometre, bir optik test cihazı, bir optik güç ölçer, bir görsel kusur bulucu, bir optik mikroskop, bir optik kulaklık ve bir OTDR içerir. Acterna uzmanları tarafından geliştirilen yapıcı bir çözüm, MTS 8000'in çok sayıda çıkarılabilir optik modülle aynı anda kurulmasına olanak tanır, böylece kullanıcı, işin türüne bağlı olarak gerekli tüm özellikleri ölçebilir. MTS 8000'de kurulu işlemci, ağı önceden kurulmuş test setleriyle test etmenize olanak tanır. Cihazın dahili hafızası 8MB'dir. İlginç bir yeni özellik, 6 GB'a kadar kapasiteye sahip bir sabit sürücü takma yeteneğidir. Kolaylık ve operasyonel çalışma olasılığı için MTS 8000, FDD, CD-RW sürücüleri ve ayrıca USB bağlantı noktaları ile donatılmıştır.

- Uzman sistemler- bu tür sistemler, ağların anormal çalışmasının nedenlerini ve ağı çalışır duruma getirmenin olası yollarını belirleme konusunda insan bilgisi biriktirir. Uzman sistemler genellikle çeşitli ağ izleme ve analiz araçlarının ayrı alt sistemleri olarak uygulanır: ağ yönetim sistemleri, protokol analizörleri, ağ analizörleri. Bir uzman sistemin en basit çeşidi, içeriğe duyarlı bir yardım sistemidir. Daha karmaşık uzman sistemler, yapay zeka unsurlarına sahip sözde bilgi tabanlarıdır. Bir örnek, Distributed Sniffer System ürün ailesinden uzman ağ analiz sistemi Expert Analysis'dir.

Sistem, 1986'dan beri Genel Ağ uzmanları tarafından biriktirilen benzersiz bir bilgi tabanına ve çeşitli ağların kullanıcılarıyla çalışma deneyimine ve Stanford ve Massachusetts Üniversitelerinin yanı sıra Nippon Telephone and Telegraph (NTT)'deki grupların gelişimlerine dayanmaktadır.

Sistemin temel amacı, anormal olayları otomatik olarak tanımlayarak ve bunların çözümü için otomatik olarak yöntemler üreterek kesinti süresini azaltmak ve ağ darboğazlarını ortadan kaldırmaktır. Uzman analiz sistemi, üç kategoriye ilişkin teşhis bilgisi sağlar:

Belirti, ağ yöneticisinin ek dikkat etmesi gereken ağdaki bir olaydır (örneğin, bir ağ düğümüne erişirken fiziksel bir hata veya bir dosyanın tek bir yeniden iletimi). Bu mutlaka kısmi bir performans kaybının meydana geldiği anlamına gelmez, ancak yüksek bir sıklıkta yöneticinin dikkatini gerektirir.

Tanılama, ağ yöneticisi tarafından zorunlu bir analiz gerektiren bir semptomun tekrarlanmasıdır. Tipik olarak tanı, ağdaki ciddi bir sorunu (örneğin, yinelenen bir ağ adresi) karakterize eden durumları tanımlar. Teşhis aşamasında, ağ performansının kısmen düşmesine neden olan olay, operatör ve yöneticinin anlayabileceği bir dile çevrilir.

Açıklama - Her belirti veya tanı için analiz sisteminin bağlama duyarlı uzman kararı. Açıklama, mevcut durumun birkaç olası nedeninin bir tanımını, böyle bir sonucun gerekçesini ve bunların ortadan kaldırılması için önerileri içerir.

Expert Analysis otomatik analiz sistemi, aşağıdaki adımlardan oluşan benzersiz bir çoklu görev paket analiz teknolojisine dayanmaktadır.

Ağda dolaşan paketler sürekli olarak yakalanır ve halka yakalama arabelleğine (ilk görev) yerleştirilir.

Aynı zamanda, birkaç protokol analiz görevi (her bir protokol ailesi için bir tane) yakalama arabelleğini tarar ve tek bir dahili formatta bilgi üretir.

Standartlaştırılmış bilgiler bir grup uzman göreve gönderilir. Bu programların her biri yalnızca kendi dar alanında, örneğin istemci ile NetWare sunucusu arasındaki etkileşim protokolü bilgisinde uzmandır. Bir uzman, kendi ilgi alanıyla ilgili bir olay bulursa, BlackboardKnowledgeBase adlı nesne yönelimli bir ağ veritabanında ilgili bazı nesneler (örneğin, "IBSO sunucusunun Konuğu") oluşturur ve bunu ilgili alt öğeyle ilişkilendirir. seviye nesneleri. Sonuç, belirli bir protokolle ilgili tüm ağ nesnelerini ve bunlar arasındaki tüm olası ilişkileri ISO / OSI modelinin yedi katmanında görüntüleyen karmaşık bir yapıdır.

Veritabanının durumunu sürekli olarak analiz eden ve anormal ağ işleyişi (semptomlar veya teşhisler) hakkında mesajlar yayınlayan ikinci bir grup uzman görevi vardır. Toplamda, ExpertAnalysis sistemi, kısmi ağ performansı kaybına yol açan 200'den fazla farklı olayı işler.

Böyle bir çoklu görev analiz sistemi, analiz cihazı pazarında benzersizdir, teşhis, onarım ve izleme için uzman sistemlerin gereksinimlerini karşılar ve teşhisin güvenilirliğini garanti eder. Bununla birlikte, dikkate alınan ES, pahalı üst düzey sistemler kategorisine aittir ve bu nedenle, çok çeşitli kullanıcılar için mevcut değildir.

Yapay zeka unsurlarına sahip bir başka ES örneği de programdır. OptiView Protokol Uzmanı Fluke Networks tarafından geliştirilmiştir ve 10/100/1000 Ethernet dağıtılmış analiz ve izleme sistemleri ailesinin bir üyesidir. Sistemin amacı, Uzman Analizi gibi, kesinti süresini azaltmak ve ağ darboğazlarını ortadan kaldırmaktır.

Söz konusu sistem, algılanan tüm olayları OSI ağ modelinin seviyelerine göre sınıflandırır:

Uygulama katmanı: Aşırı ARP, Aşırı BOOTP, NFS yeniden iletimi, tüm ICMP hataları, HTTP Alma Yanıtı, Yavaş Sunucu Bağlantısı, Yavaş Sunucu Yanıtı;

Aktarım katmanı: TCP/IP sağlama toplamı hatası, TCP/IP yeniden iletimi, TCP/IP hızlı yeniden iletimi, TCP/IP sıfır penceresi, TCP/IP donmuş penceresi, TCP/IP uzun ack, TCP/IP SYN saldırısı;

Ağ katmanı: yinelenen IP veya IPX adresi, IP TTL süresi doluyor, IP geçersiz kaynak adresi, ISL Yasadışı VLAN Kimliği, kararsız MST, HSRP darbesi / istifası;

Bağlantı katmanı: yasadışı MAC kaynak adresi, yayın / çok noktaya yayın fırtınaları, fiziksel hatalar.

Söz konusu sistem, bir ağ bileşeninde gizli bir kusur veya darboğazın varlığını gösterebilen, görünümleri hakkında mesajlar veren, ancak düzeltilmesi için önerilerde bulunmayan çok çeşitli sorunları tanır. Bu nedenle, teşhisin doğruluğunu garanti etmek için, bu sistemin kullanıcısının ağ alanında yüksek düzeyde bilgi sahibi olması gerekli bir koşuldur. Ayrıca, sistemin yüksek maliyeti, çoğu bilgisayar ağında yaygın olarak uygulanmasına katkıda bulunmaz.

Birçok kullanıcı periyodik olarak bir veya başka bir ağ sorunuyla karşılaşır. Buradaki durumlar farklı olabilir. Örneğin, bağlantı kalitesi bozulabilir ve bireysel sunucular kullanılamaz hale gelebilir. Bu tür arızalar, örneğin borsada işlem yapan tüccarlar, ağ oyunlarındaki oyuncular vb. çevrimiçi hizmetlerin kullanıcıları için kritik olabilir. Örneğin, bilgisayarlardan yalnızca birinin erişime sahip olduğu ortaya çıktı. İnternet, vb. Bu gibi birçok durumda, ağ bağlantısını teşhis etmek ve bir veya başka bir uzak düğümün çalışabilirliğini kontrol etmek gerekir.

⇡ Yerleşik Windows Araçları - Ping ve Tracert Yardımcı Programları

Windows işletim sistemi, ağ sağlığını tanılamak için birkaç yardımcı program sağlar, ancak en yaygın olarak kullanılanları Ping ve Tracert'tir. Ping programı, belirtilen ana bilgisayara bir istek gönderir ve isteğin gönderilmesi ile yanıtın alınması arasındaki süreyi (RTT, İngilizce Gidiş Dönüş Süresinden) kaydeder, başka bir deyişle yardımcı program, sunucunun yanıt süresini belirlemenizi sağlar. faiz. Ne kadar küçük olursa, bu sunucuyla veri alışverişinin o kadar hızlı olduğu açıktır. Tracert, belirtilen ana bilgisayara bir test paketi gönderir ve paketin istenen ana bilgisayara giderken geçtiği tüm ara yönlendiriciler ve bunların her birinin minimum, maksimum ve ortalama yanıt süreleri hakkında bilgi görüntüler. Bu, paketin ne kadar "uzun" yol kat ettiğini ve veri iletimiyle ilişkili en büyük gecikmelerin hangi bölümde olduğunu tahmin etmenize olanak tanır. Ping ve Tracert sonuçları ne anlama geliyor? Örneğin, uzak bir sunucudan yanıt gelmemesi, sunucunun şu anda kullanılamadığını veya sunucu yöneticisinin yankı isteklerini engellediğini gösterebilir (sunucunun diğer hizmetleri normal şekilde çalışabilirken). Uzak sunucuların yanıt süresi (RTT) çok uzunsa ve konumlarına bağlı değilse, büyük olasılıkla bağlantınızın kalitesi düşüktür ve sağlayıcınızla iletişime geçmelisiniz. Bununla birlikte, İnternet bağlantısını maksimum performans için ayarlayarak bir miktar hız kazancı elde edilebilir, bunun için TweakMASTER gibi özel optimize edici yardımcı programları kullanmak daha iyidir, ancak bu tamamen farklı bir konudur. İlgilenilen sunucuya çok "uzun" yol (yani, sunucuya bağlantı yolunda çok sayıda ara yönlendirici) genellikle onunla iletişimde yavaşlamaya neden olur. Bu kritikse, rota uzunluğunu kısaltmak için seçenekler aramaya çalışmak mantıklıdır. Örneğin, oyun sunucuları söz konusu olduğunda, ISP'nizin sunucusuna mümkün olduğunca "yakın" olanları tercih edebilirsiniz. Yardımcı programlar, test paketlerinin sağlayıcınızın sunucusunun ötesine geçmediğini gösteriyorsa, büyük olasılıkla kendi tarafında sorunlar vardır veya bunlar belki de planlanmış önleyici çalışmalardır. Ping ve Tracert yardımcı programları zor değildir, ancak teknik olarak kullanımı çok uygun değildir. Bir ping testi veya izlemesi çalıştırmak için, bir komut istemi penceresi açmanız ve muhtemelen her seferinde hatırlamanız veya yardıma başvurmanız gereken parametrelerle birlikte bir komut girmeniz gerekecektir. Örneğin, www.site düğümünün sağlığını kontrol etmek için komut satırına komutu girmeniz gerekecektir. www.siteye ping atmak ve belirli bir düğüme giden paketlerin yolunu bulmak için - komut www.site izleme... Bu komutların sonuçları aşağıda sunulmuştur ve birkaç metin satırını temsil etmektedir. Bu komutları "Başlat"> "Çalıştır" menüsünden çalıştırabileceğinizi unutmayın, ancak bu durumda program penceresi, çalışması tamamlandıktan hemen sonra otomatik olarak kapanacak ve tüm sonuçlar kaybolacaktır.

Paketlerin ağ üzerindeki "yolculuğunu" izleyebilen ve sunucu IP adresi hakkında ek bilgi sağlayabilen özel yardımcı programları kullanmak çok daha uygundur. Bu tür yardımcı programlar, ağ sorunlarının kaynağını hızlı bir şekilde analiz etmek ve belirlemek için çok yararlı olabilir. Bu yazıda bu tür yardımcı programların kullanımına odaklanacağız.

⇡ Teşhis hizmetleri

İlk olarak, özel çevrimiçi hizmetleri kullanarak ağ teşhisi için alternatif bir seçenek hakkında kısaca konuşalım. Bunlara örnek olarak WhatIsMyIPAddress.com ve Yougetsignal.com ile Whois hizmeti verilebilir. WhatIsMyIPAddress.com hizmetini kullanarak, bilmiyorsanız veya dinamik olarak sahipseniz harici IP adresinizi öğrenebilirsiniz. Paketleri bilgisayarınız ve bu sunucu arasında da yönlendirebilirsiniz. Yapması çok kolay, "IP Tools" menüsünden "Visual Traceroute" fonksiyonunu seçmeniz, harici IP adresinizi girmeniz ve "Visual Traceroute" butonuna tıklamanız yeterli.

Ana bilgisayar adı, coğrafi koordinatlar ve dünya haritası üzerindeki konum dahil olmak üzere ilgilenilen IP adresi hakkında birkaç ayrıntı bulmak için IP arama aracını da kullanabilirsiniz. Bu neden gerekli? Örneğin, kaydettiyseniz, sisteminize izinsiz girişin kaynağına erişmek için. Yougetsignal.com hizmetinde bulunan "Visual Trace Route Tool" özelliğini kullanarak sunucu URL veya IP adresini girip "Host Trace" butonuna tıklayarak da takip edebilirsiniz. Sonuç olarak, hizmet, paketlerin yolunu dünya haritasında ve ayrıca toplam geçiş sayısını ve her birinin belirli bir ülkeye ait olduğunu gösteren bir ara sunucu listesi şeklinde gösterecektir. "Ağ Konumu Aracı" işlevini etkinleştirerek, herhangi bir sunucunun coğrafi konumunu IP adresine göre öğrenebilirsiniz. Ve "WHOIS arama Aracı" işlevini kullanarak, WHOIS bilgi servisinden sunucu hakkında bilgi alabilirsiniz.

Whois hizmeti, ilgilenilen sunucunun yanıt süresinin ("Ping" işlevi) belirlenmesine, sunucuya yapılan isteğin yolunun belirlenmesine ve veri göndermede kaç tane ve hangi ara İnternet sunucularının, yönlendiricilerin ve diğer cihazların yer aldığını bulmaya yardımcı olacaktır. sunucuya ve sunucudan (Tracert).

Ek olarak, "IP Arama" işlevini kullanarak, IP adresini ana bilgisayar adına göre (veya tam tersi) öğrenebilirsiniz ve "Whois" işlevi, belirtilen etki alanının boş veya meşgul olup olmadığını size söyleyecektir. Alan adı meşgulse, sahibini ve onunla nasıl iletişim kuracağınızı tanımlayabilirsiniz (örneğin, bu alan adını satın almak istiyorsanız).

"Benim için hiçbir şey işe yaramaz" yazmadan önce, sizin için özel olarak neyin işe yaramadığını bulmaya çalışın.

Foruma / VKontakte'ye bir mesaj bırakmaya karar verirseniz, mesajın teknik destek servisine resmi bir itiraz olarak kabul edilmediğini, TP servis irtibatlarının sitenin ana sayfasında olduğunu lütfen unutmayın.

Lütfen yazmadan önce son sayfadaki en az birkaç ileti dizisini okuyun - bu sorun zaten çözülmüş veya çözülüyor olabilir!

Teşhis komutları:

* Daha önce açılmış bir "komut satırı" penceresinde yürütülür. (Başlat -> Tüm Programlar -> Donatılar -> Komut İstemi)
Windows Vista / 7 için: Win + R ===> cmd ===> Girin
Windows NT / 2000 / XP / VISTA için: "Başlat" - "Çalıştır" - "cmd"
Windows 95/98 için: "Başlat" - "Çalıştır" - "komut".

Metni kopyalama: bu pencereye sağ tıklayın - "düzenle" - "seç" ve "düzenle" - "kopyala".

ipconfig / hepsi
nslookup
ping [ana bilgisayar adresi (örn. ya.ru)] [-n 20]
yollama [ana bilgisayar adresi]
tracert [ana bilgisayar adresi]

ipconfig / all, ağ arayüzü ayarlarını gösterir.
Orada belirtilen her şey kullanıcının notuna göre kontrol edilmelidir (not eskiyse, teknik destek tarafından verilen verilerle kontrol edin). Bağlantı nasıl kurulur, web sitesine bakın

ping [-t] belirtilen ana bilgisayardan gelen yanıt süresini gösterir. Büyük gecikmeler, dolaylı olarak yavaş bir kaynağın göstergesi olarak hizmet edebilir (meşgul kanal, zayıf donanım kaynağı ve benzer sorunlar). [-t] anahtarı, kullanıcı "Ctrl + C" tuşlarına basarak kesmeden önce komutu yürütmek için kullanılır. Varsayılan olarak, bu anahtar olmadan, ping yalnızca dört kez yürütülür ve bu her zaman yeterli değildir.

pathping Ana bilgisayara giden tüm yol boyunca yanıt süresini ve bırakılan paketlerin sayısını gösterir.

iz bırakmayan
Sorunları grafiksel olarak görüntülemek için yerel ağdan PingPlotter programını indirebilirsiniz.

nslookup
DNS çalışmasını kontrol edin.

Algoritma kontrol ediliyor: "Ağ kablosu bağlı değil" hatası

1. Ağ kartındaki kablo bağlantısını kontrol edin
2. Ekrana giden kablonun bütünlüğünü kontrol edin.
3. Tech'i arayın. destek.

Ağ kablosu takılı, ancak gelen paket yok.

1. Ağ kartındaki kablo bağlantısını kontrol edin (kabloyu çıkarıp yuvaya takabilirsiniz).
2. Varsa, tüm güvenlik duvarlarını (güvenlik duvarları) devre dışı bırakın.
3. Ağ geçidine ping atın (adresi bağlantı ayarlarından veya kontrol panelindeki bağlantı bilgilerinden alın).
4. Tech'i arayın. destek.

Ağ kablosu bağlı, gelen paketler var, ancak dahili hizmetlere gitmeyin:

1. Varsa, tüm güvenlik duvarlarını (güvenlik duvarları) devre dışı bırakın.
2. DNS çalışmasını kontrol edin (nslookup).
3. Bu sunucularla bağlantıyı kontrol edin (ping)
4. Merkezi sunucularla iletişimi kontrol edin. (ping online.vo, ping 192.168.0.250, ağ geçidi adresinize ping atın)
5. Tarayıcı ayarlarını kontrol edin
5.1. Internet Explorer -> "Araçlar" menüsü -> "İnternet Seçenekleri" -> "Bağlantı" -> "Ağ Ayarları" -> "proxy sunucusu kullan" onay kutusunun devre dışı bırakılıp bırakılmadığını kontrol edin
6. Tech'i arayın. destek.

DNS kontrolü:

nslookup server komutu bu sunucunun ip adresini döndürmelidir. Örneğin, "nslookup vo47.ru" komutu "193.106.108.68" adresini döndürmelidir.

Teşhis Komutları

Emretmek	Randevu	Başlatma biçimi	Örnek
ipconfig	Ağ arayüzü ayarlarını gösterir	ipconfig / hepsi
netstat	Rota tablosunu gösterir	netstat -nr
nslookup	Bilgisayarın DNS adını IP adresine dönüştürmek için DNS sunucusunu sorgular (belirtilmemişse Windows ayarlarından alınır) veya tam tersi	nslookup DNS Adı veya IP Adresi DNS Sunucusu IP Adresi	nslookup vo47.ru nslookup ya.ru 193.106.108.67
ping atmak	Başka bir bilgisayarla bağlantıyı ve yanıt verme durumunu kontrol eder. Bağlantı hızını ölçmek için bir araç değildir.	ping atmak DNS-adı_veya_IP-adresi	ping www.vo47.ru ping 193.106.108.97
iz bırakmayan	Ping ile aynı, ancak tüm ara düğümler için bilgi çıktısı ile	iz -d DNS-adı_veya_IP-adresi	tracert -d cs47.ru
yol verme	tracert ile aynı, ancak daha ayrıntılı ve kayıp yüzdesinin bir göstergesi ile	yol verme DNS-adı_veya_IP-adresi	vk.com'a yol verme