Ağ arızalarının yeri katman katman belirlenmelidir: fiziksel bağlantı, Katman 2 iletimi, IP yolu ve uygulama hizmetleri. Yönlendiriciler, anahtarlar, sunucular ve alıcı-vericiler farklı görevler üstlenir; bu nedenle hepsine “bir yeniden başlatmayı deneyin” yaklaşımıyla müdahale edilemez. Önce etkinin kapsamını ve zamanını kaydedin, ardından bir uygulama sorununu kopuk fiber veya arızalı cihazla karıştırmamak için hedefli testler kullanın.
İlk soru: Kimler etkileniyor ve ne zaman başladı?
Yalnızca bir terminalde sorun olduğunda izlenecek kontrol yolu, bir katın tamamında veya tüm tesiste sorun olduğunda izlenecek yoldan farklıdır. Normal çalışan ve sorunlu cihazların ağa erişim noktalarını karşılaştırın; kablolama, güç beslemesi, yapılandırma veya yazılımda değişiklik yapılıp yapılmadığını sorun. Belirtileri, hata mesajlarını ve zamanı kaydedin; bu bilgiler ortak düğümün belirlenmesine yardımcı olur.
Kanıt toplamadan önce tüm cihazları tekrar tekrar yeniden başlatmayın. Yeniden başlatma sayaçları sıfırlayabilir veya sorunu geçici olarak gizleyebilir, ancak nedenini açıklamaz. Üretim sistemlerinde önce etki değerlendirilmeli, mevcut yapılandırmalar ve günlükler korunmalı, ardından gerekli işlemler planlanmalıdır.
Fiziksel katman: Güç beslemesi ve bağlantı kararlı kalabiliyor mu?
Terminallerin ve ağ cihazlarının güç beslemesini, portlarını, ağ kablolarını ve optik modüllerini kontrol edin. Bağlantı ışığının yanmamasının nedeni kablo, devre dışı bırakılmış bir port, hız uyuşmazlığı veya uzak uçtaki güç kesintisi olabilir; bu durum mutlaka anahtarın bozuk olduğu anlamına gelmez. Bir bağlantı sık sık yeniden kuruluyorsa hata sayaçlarını ve güç durumunu kaydedin; planlı değiştirme işlemlerinde sağlam olduğu bilinen kablo veya portları kullanın.
Fiber optik alıcı-vericilerde ayrıca tek modlu veya çok modlu uyumu, dalga boyu, gönderme ve alma yönü ile izin verilen optik güç kontrol edilmelidir. Optik port ışığının yanması, IP hizmetlerinin çalıştığı anlamına gelmediği gibi optik güçte kesinlikle yeterli marj bulunduğu anlamına da gelmez. Temizlemeden önce uç yüzeyini inceleyin ve optik porta doğrudan bakmayın; hangi değişikliğin etkili olduğunu değerlendirmeyi kolaylaştırmak için her seferinde yalnızca bir koşulu değiştirin.
Katman 2: Terminal doğru ağa bağlanıyor mu?
Portun beklenen VLAN ağına ait olup olmadığını, üst bağlantının ilgili VLAN için geçişe izin verip vermediğini ve MAC öğreniminin normal olup olmadığını kontrol edin. Arayüz istatistiklerindeki CRC hataları fiziksel iletim sorununa işaret edebilir; paket düşmeleri ise tıkanıklıkla da ilişkili olabilir. Sayaçlardaki her artış aynı nedene bağlanmamalıdır.
Bir döngü, anormal yayın trafiğine ve MAC tablosu kayıtlarının sürekli değişmesine neden olabilir. Bu durum saptandığında kablo takmaya devam etmek yerine sorunlu bağlantıyı önceden belirlenmiş plana göre izole edin, koruma protokolünü ve topolojiyi kontrol edin. Bir VLAN yapılandırma hatası, port ışığı normal olduğu hâlde terminallerin birbirini bulamaması şeklinde ortaya çıkabilir.
Katman 3: Adresler ve rotalar tutarlı mı?
Terminalin IP adresini, maskesini, ağ geçidini ve adres çakışmalarını kontrol edin. Önce yerel ağı doğrulayın, ardından ağ kesimleri arasındaki yolu kontrol edin. Bir yönlendiricinin rotaları, erişim politikaları veya adres çevirisi, belirli bir yöndeki iletişimi etkileyebilir. Bir yönde erişilebilirlik, ters yöndeki yolun da doğru olduğunu garanti etmez.
Ping'in başarısız olmasının nedeni, test trafiğinin politika gereği kısıtlanması da olabilir; bu nedenle cihazın doğrudan çevrimdışı olduğuna karar verilemez. Komşu tablolarını, rotaları, cihaz günlüklerini ve izin verilen iş uygulaması testlerini birlikte değerlendirerek karar verin. DNS düzgün çalışmadığında alan adı üzerinden erişim başarısız olurken doğrudan adresle erişim başarılı olabilir; ancak uygulamanın alan adına veya bir sertifikaya bağımlı olup olmadığını yine de doğrulamak gerekir.
Uygulama: Sunucu gerçekten hizmet sağlıyor mu?
Bir sunucu ağ yoklamalarına yanıt verebilir; ancak uygulama başlatılmamış olabilir, yanlış adreste dinliyor olabilir, kaynak yetersizliği yaşayabilir veya arızalı bir veritabanına bağımlı olabilir. Hizmet durumunu, portları, günlükleri ve kaynak kullanımını kontrol edin; ağ yalnızca verilerin yol boyunca iletilmesinden sorumludur ve uygulama içindeki hataları kendiliğinden düzeltmez.
Sorun giderildikten sonra yalnızca bağlantıyı değil, gerçek kullanıcı işlemlerini de doğrulayın. Nedeni, yapılan müdahaleyi ve yeniden test sonuçlarını bir bakım raporuna kaydedin; normal çalışma için bir referans durumu saklayın. Rotaların, güvenlik duvarlarının veya üretim yapılandırmalarının değiştirilmesi gerektiğinde önce yedek alın ve geri dönüş planı hazırlayın; sırf “çalışsın” diye tüm erişimleri koşulsuz açmayın.
Arıza yalnızca yüksek yük altında ortaya çıkıyorsa yalnızca boşta test yapmak yerine trafik ve kaynak kullanım eğrilerini karşılaştırın. Test trafiği de üretim ağına kontrolsüz biçimde gönderilmemelidir; teşhis işleminin kendisinin tıkanıklığa neden olmaması için kapsamı ve hızı belirleyin.
Çince teknik makaleden çevrilmiştir. Kaynağın ilk yayımlanma tarihi: 2020-05-20. Kaynağın son güncellenme tarihi: 2026-10-13T23:18:15+08:00. Çince kaynağı okuyun
