EX4200, bir Junos yükseltmesinden sonra SFP+ EEPROM'u mis-programmed olarak bildiriyor, bir MX960 ise hâlâ DOM gösteriyor
EX4200'lerden iki ucunda da third party optikler olan birkaç 80 km DWDM span'i çalıştırıyoruz, çünkü vendor markalı DWDM parçaları bütçeye asla sığmayacaktı. Yıllarca sorun olmadı. EX kutuları Junos 12.3'e taşındıktan sonra optikler hâlâ aynı portlarda oturuyor, span'ler de hâlâ var, ama switch modüllerin optik olduğunu kabul etmeyi tamamen kesti.
- EX4200, Junos 12.3 (aynı şasi üzerinde 11.4'te DOM sorunsuz çalışıyordu)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- Aynı span'in uzak ucunda bir MX960, aynı parça numarası, DOM hâlâ eksiksiz
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableMessages log, modül takıldığında tam olarak tek bir satır basıyor: SFP+ of type 0 EEPROM is Mis Programmed.
Şimdiden ekarte ettiklerim:
- optiği yeniden oturttum ve aynı şasideki başka bir porta taşıdım, değişiklik yok;
- laboratuvarda yedek bir EX3300 ve bir QFX5100 denedim, ikisi de aynı şekilde davranıyor, yani bu tek bir bozuk kutu değil;
- uzak ucu tekrar kontrol ettim, MX960 aynı siparişten aynı parça için tam diagnostics veriyor.
Yani EX driver'ı, eski sürümün basitçe görmezden geldiği bir şeyi EEPROM'da mı zorluyor? Öyleyse, optiğin kendisine yapılabilecek bir şey var mı, yoksa bu tedarikçiyle yapılması gereken bir konuşma mı?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
O log satırı genel bir homurdanma değil, driver'ın sana hangi kontrolün başarısız olduğunu söylemesi.
A0 sayfasının 3 ila 10 baytları, SFF-8472'de tanımlanan transceiver compliance kodlarını tutuyor - 10GBASE-SR, LR, ER, SONET kodları, Fibre Channel olanlar ve benzerlerini söyleyen bitler. Bu tür optikte sekiz baytın tamamı sıfır, mesajın buna type 0 demesinin sebebi de bu. Spec, o alanda bir yerde en az bir bitin set edilmesini bekliyor; tamamı sıfır olan bir compliance alanı geçerli bir modül tanımı değil. Eski EX kodu hiç bakmıyordu ve doğrudan diagnostics sayfasını parse etmeye geçiyordu, yeni driver ise önce alanı doğruluyor, sonra modülü bilinen bir 10G optik olarak ele almayı reddediyor. Unknown cable ve eksik DOM'un sebebi bu. MX hattı aynı check'i aynı yolda çalıştırmıyor, aynı parçanın orada hâlâ çalışmasının sebebi de tam olarak bu.
Kimseyle tartışmadan önce kanıtla: shell'e in, o portta xcvrpeek page A0 çalıştır, sonra offset 3'ten 10'a kadar bak. Hepsi sıfırsa dava kapanır.
Bunu yerinde onarmak genelde burada çöküyor. Teorik olarak xcvrpoke aynı byte'ları geri yazıyor. Pratikte pek çok vendor A0 sayfasını kilitliyor, yazma da EIO döndürüyor, switch tarafından bu konuda yapabileceğin bir şey yok. Geriye kalan tedarikçi: ya gerçek compliance kodlarıyla programlanmış optikler gönderiyorlar, ya da A0'ı kilitsiz gönderip bitleri kendin ayarlamana izin veriyorlar. İkisini de yapamıyorlarsa, bu bir Junos kılığına girmiş bir tedarikçi sorunu.
Kimse tahmine başlamadan önce netleştirmekte fayda olan iki şey var.
Önce, her kutudaki tam sürüm. EX'in 12.3'e gittiğini söylüyorsun, peki MX960'da ne çalışıyor? Hâlâ daha eski bir train'deyse iki kutu gerçekten karşılaştırılabilir değil ve fark henüz sana hiçbir şey söylemiyor.
İkincisi, MX tarafındaki parça harfiyen aynı partiden aynı SFPP-C51-80-10GD mi, yoksa farklı bir siparişten aynı model mi? Partiler kimsenin isteyeceğinden daha fazla farklılık gösteriyor.
show interfaces diagnostics optics'i iki uçtan da paylaş, üstüne optiği çıkarıp yeniden taktığında messages log'un bastığı her şeyi, sadece alıntıladığın tek satırı değil.İki uçta da aynı parça, SFPP-C51-80-10GD, aynı sipariş, ardışık serial'ler.
MX960'da
show interfaces diagnostics opticstam seti veriyor: sıcaklık, laser bias current, TX power, RX power. EX4200'de aynı komut interface header'ını basıyor, sonra unknown cable satırını, başka hiçbir şey yok. Optiği yeniden takmak, hangi portu kullanırsam kullanayım, logdaSFP+ of type 0 EEPROM is Mis Programmedüretiyor, başka bir şey değil.Beni rahatsız eden kısım, yükseltmeden önce tam olarak bu optiğin tam olarak bu şasi ve portta tek kelime şikayet etmeden DOM raporlamış olması.
Eklemek gerek: bunun read-only yarısı çitin öbür tarafında da var. Cisco'da
show idprom interface <if> detail, hiç shell cambazlığı yapmadan identification byte'larını döküyor, bu da modüller bir Juniper kutusuna yaklaşmadan önce yedek bir switch'te bir partiyi kontrol etmek için kullanışlı.Okumak her yerde zararsız. Host'tan yazmak farklı bir hayvan: xcvrpoke internal bir araç, modülleri onarmanın desteklenen bir yolu değil, belirtildiği gibi zaten neredeyse yarı yarıya vendor lock tarafından engelleniyor. Onu EEPROM'da neyin yanlış olduğunu kanıtlamak için kullan, sonra o kanıtı sana optikleri satana ver.
Aynı sınıf sorun, tamamen farklı bir semptom, biri buraya aramadan gelirse diye.
Bir EX4600'ün ge-0/0/1'ine markasız bir 1G BiDi WDM SFP taktık ve interface basitçe yoktu.
show interfaces terse'de eksikti, ona karşı çalıştırılan her komuterror: device ge-0/0/1 not foundile döndü. LogOPTIC State changed for port: 0/0/1diyordu, sonraFibre channel transceiver plugged in without Fibre channel configuration!!. EEPROM, Junos modülü Gigabit Ethernet yerine bir Fibre Channel transceiver olarak sınıflandıracak şekilde kodlanmıştı, yani onun için hiç Ethernet interface oluşturulmadı. Hiçbir miktar konfigürasyon bunu düzeltmez; doğru kodlanmış bir modül düzeltir.Ve bu sadece pazarın ucuz ucunda olmuyor. Citrix markalı bir 10G SFP+ partisi vardı, NetScaler MPX ve SDX cihazlarına boot'ta vendor'ın kendi parçalarında
*** Unsupported SFP+/SFP type !logu attırıyordu. İyi birimler etikette bir A2 revizyon işareti taşıyor, kötü olanlar RMA'ya gitti. Kötü kodlama her fiyat noktasında oluyor.Doğrulandı, kesin offset'ler için teşekkürler.
Kontrol ettiğim bu SFPP-C51-80-10GD birimlerinin her birinde, hâlâ kutusunda duranlar dahil, A0 sayfasında xcvrpeek offset 3'ten 10'a kadar sıfır gösteriyor. xcvrpoke direkt EIO ile geri dönüyor, yani A0 kilitli ve bizim tarafımızda kurtarılacak bir şey yok.
Byte offset'leri ve alıntılanan log satırıyla tedarikçiye geri döndüm. Kabul ettiler ve partiyi gerçek compliance kodlarıyla yeniden kodluyorlar; MX960'da oturanlar oldukları yerde kalıyor, çünkü o platformda kimse şikayet etmiyor. Yukarıdaki açıklamayı cevap olarak işaretliyorum.