Alcatel-Lucent G-010S-P GPON stick'li CRS328: sadece TX, RX yok, dalga boyu 33685 nm gösteriyor
Evdeki FTTH hattımı operatörün ONT'sinden alıp kendi router'ımdaki bir GPON stick'e taşıyorum, böylece fiber doğrudan rack'e giriyor ve iki kutu yerine bir kutuda kalıyorum. Stick tanınıyor, port ayağa kalkıyor, ve sonra hiçbir şey geri gelmiyor.
- MikroTik CRS328-24P-4S+, stick sfp-sfpplus1'de
- Alcatel-Lucent G-010S-P GPON ONU
- Bell Canada FTTH, duvar kutusundan fiber doğrudan modüle giriyor
- port sabitlendi, autoneg kapalı:
/interface/ethernet set sfp-sfpplus1 auto-negotiation=no speed=1G-baseXTX sayaçları yükseliyor, RX sayaçları sıfırda kalıyor, modül sayfası da şöyle okunuyor:
wavelength: 33685.00nmŞimdiye kadar yaptıklarım:
- konnektörü yeniden oturttum ve temizledim, ikinci bir SFP+ kafes denedim
- fiberi tamamen çıkardım - dalga boyu değeri takılıyken de takılı değilken de değişmiyor
- yavaş bir ranging işi olabilir diye portu bir saat 1G'de sabit bıraktım
Yani: 33685.00nm bu stick'teki optiğin öldüğüne kanıt mı, yoksa switch bir GPON modülü için o EEPROM alanını yanlış mı çözümlüyor? Ve bir SFP ONU'nun range yapmasına izin verilmeden önce operatör tarafında olması gereken bir şey var 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
Gönderinizde iki ayrı şey var ve sadece biri arıza.
33685.00nm bir ölçüm değil, bir çözümleme (decoding) hatası. Bu stick'ler çift dalga boylu - upstream'de 1310, downstream'de 1490 - switch de EEPROM'dan tek lazerli sıradan bir transceiver'mış gibi tek bir wavelength alanı okuyor. Aynı sayıyı sorunsuz trafik taşıyan bir stick'te de görürsünüz, yani teşhis olarak işe yaramaz. Bir kenara bırakın.
Tek yönlü trafik ise cihazın kendisi. Ben bunu aynı switch'te, bir CRS328-24P-4S+'ta yaşadım: G-010S-P gönderiyordu ama hiçbir zaman bir şey almadı, hat da aynı aileden başka bir modül taktığım anda ayağa kalktı - genişletilmiş sıcaklık varyantı olan bir O-010S-P. Aynı hesap, aynı fiber, config değişikliği yok. Yani ilk stick ya arızalıydı ya da o hat için yanlış varyanttı.
Test ederken portu sabit tutun, yoksa ikinci bir değişken eklemiş olursunuz:
Seri numarasında ALCLFAB olduğuna ve hesap zaten bir SFP ONU'ya geçirildiğine göre, operatör tarafınız tamam. Bu işte bir akşam daha harcamadan önce elinizde ikinci bir stick bulundurun.
Optiği hatalı ilan etmeden önce sıkıcı yarısını kontrol edin. Birçok FTTH hesabında bir SFP ONU, operatörün kutusu için doğrudan bir yerine koyma değildir: hesabın onun için elle yeniden provizyonlanması gerekir, bazı operatörler de sadece seri numarasında kendi vendor prefix'ini taşıyan bir modülü kabul eder. Hiçbir şeyin geri gelmediği bir TX, abone tarafından bakınca yetkilendirilmemiş bir ONU'nun tam olarak göründüğü şeydir.
Stick'in vendor ve seri için ne raporladığını paylaşın, WAN tarafında ne yapılandırdığınızı da söyleyin - VLAN tag, PPPoE ya da DHCP.
Seri numarası ALCLFAB ile başlıyor, burada bir işletme FTTH hesabında istedikleri prefix de bu. Hesap SFP ONU için elle de yeniden yapılandırıldı - bu bir telefon görüşmesi gerektirdi, ilk hat ne istediğim hakkında hiçbir fikri yoktu.
Router tarafında SFP portunda VLAN 35 var, üzerinde de bir PPPoE client. Client discovery'yi hiç geçemiyor. RX sayaçları hâlâ sıfır, okuma da fiber takılı olsun olmasın 33685.00nm'de değişmeden duruyor.
Wavelength konusunu biraz daha açayım: switch'in okuduğu alan SFF-8472 bölgesinde yaşıyor ve tek lazerli bir modül için tanımlanmış. Bir GPON ONU'nun burst-mode bir vericisi ve farklı dalga boylarında bir alıcısı var, yani oraya yazılacak tek bir doğru değer yok, vendorlar da işine gelen neyse onu yazıyor. Standartta host'u o byte'ı yazdırmadan önce mantık kontrolüne (sanity check) zorlayan hiçbir şey yok, beş haneli nanometrelerle sonuçlanmanızın sebebi de bu.
Aynı mantık bu stick'lerdeki optik güç satırları için de geçerli. PON tarafının nasıl gittiğini bilmeniz gerekiyorsa bunu switch'in diagnostik sayfasından değil, ONU'nun kendi durumundan alın.
Bunun host tarafının bir MikroTik tuhaflığı olmadığını da belirtmekte fayda var. 7210 SAS ailesinde vendor dokümantasyonu bu konuda açık sözlü: erken sürümler DDM'i hiç uygulamamış, yani portlar bunu destekleyen modüllerle bile optik güç ya da sıcaklık göstermiyor, hangi sürümün sizin varyantınıza bu işlevi eklediğini kontrol etmeniz söyleniyor. Vendor'ın kendisinin sağlamadığı modüller için de aynı kılavuz diagnostiklerin gösterilebileceğini ama biçimlerinden ya da doğruluğundan sorumluluk almadığını söylüyor.
Modül EEPROM'unda da platformun bir SFP'yi DDM özellikli sayıp saymayacağına karar veren bir yetenek bayrağı var, bu bayrağı ayarlamayan modüller de kimsenin doğrulamadığı, gerçekçi görünen sayılar basmaya devam edebiliyor. Orada bunu
show port <port> detailile okuyorsunuz. O kutudaki üçüncü parti bir değeri bir ipucu olarak görürüm, asla bir ölçüm olarak değil - sizin 33685'inizin de aşağı yukarı hak ettiği muamele bu.Konuyu kapatayım: ikinci bir stick sorunu çözdü. Bir O-010S-P taktım, PPPoE client bir dakika içinde VLAN 35'te ayağa kalktı, operatör tarafında değişiklik yok, port config'inde de dokunulan bir şey yok. Eski G-010S-P başka bir kafeste de aynı sadece-TX işini yapıyor, yani bana kalırsa ölü.
Ve evet - çalışan modül de 33685.00nm raporluyor. O sayının peşinde bir hafta geçirmediğime sevindim.