Katman 3 endüstriyel Ethernet anahtarının yönetiminde, “cihazın yönetilebilir olması” ile “hizmet trafiğinin doğru iletilmesi” konularını birbirinden ayırmalısınız. Web sayfasına giriş yapılabilmesi yalnızca bu yönetim yoluna erişilebildiği anlamına gelir; tüm VLAN'ların, rotaların, sonraki atlamaların ve erişim kurallarının normal olduğunu kanıtlamaz. Sorun giderirken kanıt toplamak için hizmetin gerçek yolu izlenmeli, ardından her bağlantı kesildiğinde cihazı yeniden başlatmak yerine dar kapsamlı ve geri alınabilir değişiklikler yapılmalıdır.
1. Yönetim erişimi ve hizmet verileri farklı yollar izler
Bir yönetim bilgisayarı anahtarın yönetim adresine eriştiğinde, verinin uç noktası cihazın kendi yönetim hizmetidir; sahadaki bir terminal başka bir alt ağdaki sunucuya eriştiğinde ise verilerin cihaz tarafından dışarı iletilmesi gerekir. Bu iki trafik türü farklı VLAN'lardan, kurallardan ve arayüzlerden geçebilir. CPU'nun yönetim isteklerine yanıt verebilmesi, hizmet çıkışının normal olduğu anlamına gelmez; yönetim erişiminin kesilmesi de tüm donanımsal iletimin aynı anda durduğu anlamına gelmeyebilir.
Önce arızanın belirli bir hizmeti, belirli bir alt ağı mı yoksa tüm sahayı mı etkilediğini doğrulayın; kaynağı, hedefi, oluşma zamanını ve sürekli olup olmadığını kaydedin. Durumu yalnızca “ağ çalışmıyor” diye özetlemeyin. Birden fazla kişinin aynı yapılandırmayı aynı anda değiştirmesini önlemek için yönetim hesaplarının yetkilerini ayırın; teslim edilen modelin desteklediği güvenli yönetim yöntemlerine öncelik verin ve düz metinle uzaktan erişimi güvenilmeyen ağlara açmayın.
2. Alt ağlar arası iletişim başarısız olursa önce erişilebilirlik durumunu kontrol edin
Terminalin doğru adres, maske ve ağ geçidine sahip olması; erişim portunun da trafiği doğru Katman 2 kapsamına yerleştirmesi gerekir. İlgili Katman 3 arayüzü kullanılabilir durumda olmalı ve cihazda hedefle eşleşen bir rota da bulunmalıdır. Bu temel koşullar sağlanmıyorsa kuyruk önceliğini değiştirmek veya daha fazla yönetim işlevini etkinleştirmek sorunu çözmez.
Yönlendirme tablosunda hedefe giden bir yol bulunduktan sonra, sonraki atlama çözümlemesini ve çıkışı da kontrol etmeniz gerekir. Sonraki atlama, paketin o anda teslim edilmesi gereken komşu cihazdır; mutlaka son sunucu değildir. IPv4, komşu IP ile MAC arasındaki ilişkiyi çoğunlukla ARP aracılığıyla kurar. Çözümleme başarısız olduğunda yerel bağlantıyı ve yapılandırmayı kontrol etmeniz gerekebilir; belirtiyi daha karmaşık bir yol sorunu olarak gizleyecek başka bir varsayılan rotayı hemen eklememelisiniz.
Giriş, hedefe giden yol, sonraki atlama, erişim kuralları ve çıkış durumunu aynı zaman penceresinde eşleştirin; ardından sunucunun dönüş yolunu kontrol edin. Sıradan erişim denetimi kuralları yalnızca tek yöne izin verebilir; terminalin veya sunucunun kendi koruması da istekleri reddedebilir. Anahtarın arızalı olduğu şüphesi destekleyici kanıt gerektirir; yalnızca tek bir uygulama zaman aşımına dayanarak sonuca varmayın.
3. Yalnızca kümülatif toplamlara değil, sayaç değişimlerine bakın
Port istatistikleri genellikle kümülatif bayt, paket ve çeşitli hata veya atma sayılarını saklar. İki örnekleme anı arasındaki değişimleri karşılaştırmak, arıza sırasında neler olduğunu daha iyi açıklar. Büyük bir kümülatif hata sayısı çok eski bir zamandan kalmış olabilir; buna karşılık, şu anda artmaya devam eden az sayıdaki hata da daha fazla dikkat gerektirebilir. Önce arayüz indeksleri, gerçek portlar ve ölçüm yönleri eşleştirilmelidir; iki farklı portun değerlerini karşılaştırmayın.
Öğretici örnekte, aynı çıkışın bayt sayısı 10 saniye içinde 125,000,000 bayt artar. Yaklaşık 100 Mbit/s ortalama hız elde etmek için değişimi 8 ile çarpıp 10 değerine bölün. Bu, söz konusu sürenin ortalamasıdır; tepe değer değildir ve uygulamanın etkin veri aktarım hızına eşit değildir. Cihaz yeniden başlatılırsa, sayaçlar sıfırlanırsa veya sayaç süreksizliği oluşursa bu fark doğrudan gerçek hız olarak değerlendirilemez; yüksek hızlı portlarda sayaç bit genişliğini ve aracın işleme yöntemini de kontrol etmelisiniz.
4. Hataları, atılan paketleri ve uygulama zaman aşımlarını ayırt edin
Bağlantıdaki alım hatalarının ve çıkışta paket atılmasının nedenleri aynı değildir. İlki fiziksel iletim, arayüz veya çerçevelerle ilgili olabilir; ikincisi ise tıkanıklık, kurallar, kaynaklar ya da modele özgü istatistik tanımlarıyla da ilişkili olabilir. Önce ilgili sayaç tanımlarını okuyun, ardından optik modül bilgilerini, port hızını, kuyrukları ve günlükleri birbiriyle ilişkilendirin. Tek bir “atma” gördüğünüz için otomatik olarak kablonun bozuk olduğuna karar veremezsiniz.
Düşük bir ortalama port kullanım oranı da ani trafik artışlarından kaynaklanan kuyruklanma olmadığını kanıtlamaz. Gerektiğinde, yetkilendirilmiş koşullarda örnekleme sıklığını artırın veya uygun paket yakalama yöntemlerini kullanın; ancak port yansıtma yoluyla kopyalanıp gözlemlenen trafiğin de kapasite ve seçim kapsamı sınırları vardır. Yansıtma portu paket yakalamıyorsa bu, yansıtmanın kendisinden kaynaklanan bir eksiklik olabilir; çapraz kontrol yapmadan asıl hizmetin hiçbir şey göndermediğini ileri süremezsiniz.
5. Feichang Technology yönetim işlevleri nasıl bakım kanıtına dönüşür?
Feichang Technology Yönetilebilir, endüstriyel ray tipi 10G 4 fiber portlu 8 bakır portlu Katman 3 anahtar Ayrıntılarda yönetim erişimi, port istatistikleri, günlükler, optik modül bilgileri ve ilgili Katman 3 işlevleri listelenir; bunlar cihaz durumu ve hizmet yollarına ilişkin bakım kayıtları oluşturmak için kullanılabilir. Hangi alanların gerçekten okunabildiği, yenileme döngüsü ve alarm yöntemi teslim edilen modele, aygıt yazılımına ve kılavuza göre belirlenmelidir; üçüncü taraf MIB tanımları her öğenin desteklendiğini kanıtlayamaz.
Farklı kişilerin aynı arızayı karşılaştırabilmesi için yapılandırma yedeklerini, zaman eşitleme durumunu, port tanımlayıcılarını ve aygıt yazılımı sürümünü birlikte kaydedin. Günlük zamanı ile paket yakalama zamanı tutarsız olduğunda, farklı olayları tek bir nedene bağlamamak için önce kanıtların zaman ilişkisini kalibre edin. Sırf gösterge panelindeki sayıları iyileştirmek için özgün hata kayıtlarını gelişigüzel temizlemeyin.
6. Optimizasyon, doğrulanmış bir değişiklik olmalıdır
Net bir hipotez oluşturduktan sonra, her seferinde gerekçeli tek bir yapılandırma öğesini değiştirin ve değişiklik öncesindeki ve sonrasındaki hizmet performansı ile cihaz durumunu kaydedin. Rotalar, VLAN'lar veya erişim kuralları söz konusu olduğunda onaylı bir değişiklik zaman aralığı ve geri alma planı belirleyin; çalışan bir kontrol ağında protokolleri gelişigüzel kapatmayın veya erişim izinlerini genişletmeyin. Yeniden başlatma, belirtiyi geçici olarak değiştirebilir; ancak sahadaki önemli kanıtların kaybolmasına yol açar.
Kabul kontrolünde yalnızca yönetim sayfasına değil, başlangıçta başarısız olan hizmetin düzelip düzelmediğine, başlangıçta kısıtlanan hizmetin hâlâ kısıtlı olup olmadığına ve dönüş yolu ile yönetim kanalının sağlam kalıp kalmadığına da bakılmalıdır. Hangi bölümün durumunun anormal olduğunu, bunun nasıl doğrulandığını, nasıl düzeltildiğini ve sonucun nasıl yeniden elde edildiğini açıklayabilmek, ağın akıllıca optimize edildiğini belirsiz biçimde söylemekten daha güvenilirdir.
Referans notu: Arayüz sayaçları ve süreksizliğin ele alınması için başvurulan kaynak: RFC 2863 . Şekiller genel ilke şemalarıdır, örnekler model ölçümleri değildir ve belirli sayaç tanımları cihaz dokümantasyonuyla karşılaştırılarak kontrol edilmelidir.
Çince teknik makaleden çevrilmiştir. Kaynağın ilk yayımlanma tarihi: 2024-03-06. Kaynağın son revizyon tarihi: 2026-10-13T11:20:43+08:00. Çince kaynağı okuyun
