dentOS üzerindeki Edgecore AS5114-48X: port 18'deki SFP+ düzgün enumerate oluyor ama onlpdump RX_LOS'ta kalıyor

RX_LOS tek başına sadece alıcının yeterli ışık görmediğini söylüyor, o yüzden kutuyu suçlamadan önce: karşı uç ne raporluyor? Peer port DDM sunuyorsa, Tx gücünü oku ve lazerin gerçekten açık olduğunu ve portun shut olmadığını doğrula. İki tarafın da aynı optik tipi ve fiber modunda olup olmadığını bilmekte de fayda var - kısa menzilli bir modülün uzun menzilli birine bakması, ya da yanlış fiber, tam olarak buna benziyor.

Ve port 18'de farklı bir parça numarasına sahip ikinci bir modül denedin mi, yoksa sadece bu tek modülü mü portlar arasında taşıdın?

Karşı uç başka bir switch'te bir 10G port, iki tarafta da aynı kısa menzilli optikler. O port tam olarak aynı patch kordon üzerinden farklı bir modülle sorunsuz link kuruyor, yani peer lazer canlı ve fiber yolu uçtan uca iyi. Port 18 admin up, ve kordon ters çevrilince de aynı sonucu alıyorum.

Can sıkıcı olan kısım yerel olarak gözlemleyebildiğim şey: onlpdump bana presence artı status bitmask veriyor, hepsi bu. dentOS tarafında karşı uçla karşılaştıracak bir Rx rakamım yok, yani hangi ucun olduğunu bilmeden "bir şey almıyor" noktasında sıkışıp kalıyorum.

Benim çalışacağım sırayla, belirtiden sebebe. Tespit sadece I2C/EEPROM yolunu ve MAC tesisatını kanıtlıyor, başka hiçbir şeyi değil. inband/10gbase-r hakkındaki kernel satırı host tarafının kendini konfigüre etmesi - tek bir fotonun ulaştığı anlamına gelmiyor. RX_LOS aktifken geriye üç şüpheli kalıyor: karanlık ya da çapraz bir fiber, transmit etmeyen bir karşı uç, ve bu platformda çalışmayan bir alıcı.

İlk ikisini zaten sıkı bir şekilde zorladın, o yüzden bit toplamayı bırak ve bir rakam al. Dijital diagnostik basan herhangi bir switch işini görür. EXOS'ta bu show ports <port> transceiver information, sıcaklık, besleme gerilimi, lazer bias'ı, Tx ve Rx gücünü veriyor ve modül eşiklerinin dışındaki her değeri işaretliyor, debug hal show optic port <port> ise EEPROM'dan vendor, parça numarası, seri numarası, konnektör ve dalga boyunu ekliyor. Bir X460-G2-24x-10G4'te ölü bir 10G portu bu şekilde kovaladım ve alıcıda kabaca -26,78 dBm buldum, ki hiçbir 10G kısa ya da uzun menzilli alıcı buna kilitlenemez.

Karşı uç, senin modülün transmit ederken sana bir Rx okuması verebiliyorsa, en azından onun lazerinin çalışıp çalışmadığını öğrenirsin. Ondan sonra geriye kalan, platformun bu belirli parçayı sürmemesi olur.

Burada da aynı kutu, ve bu platformda modül desteği standarda göre değil parçaya göre. Bizim AS5114-48X'imizde Avago AFBR-703SDZ-IN2 rev G2.3 hiç ayar yapmadan ayağa kalkıyor - platform onu AA1329A5UTA seri numarasıyla Intel Corp olarak raporluyor, ki bu ilk bakışta insanları şaşırtıyor.

Aynı switch'te aynı fiberde bizde hiç çalışmayan iki parça: senin elindeki Intel FTLX8571D3BCV-IT rev A, ve bir OPNEXT TRS5020EN-S301. İkisi de tespit edildi, ikisi de tam olarak senin port 18'in gibi oturdu. Fiber altyapısına bir akşam daha harcamadan önce bilinen iyi bir parça ödünç al.

O bit hakkında kesin olmakta fayda var: RX_LOS, SFF-8472'de tanımlandığı gibi modülün kendi loss-of-signal çıkışı, platform katmanı da bunu sadece status 0x00000004 olarak yüzeye çıkarıyor. Alıcının LOS eşiğinin altında aktif oluyor, yani sana "yeterli ışık yok" der, nedenini asla söylemez. Tertemiz bir EEPROM okumasıyla ölü bir optik yolun çelişkisizce bir arada var olmasının nedeni de bu.

Gerçek bir Rx rakamında ısrar etmenin diğer nedeni: zayıflama CLI'dan bakınca uyumsuzlukla birebir aynı görünüyor. Bir meslektaşımın Zyxel portu -25,69 dBm civarında oturuyordu, ve çözüm modül değil, patch kordon artı birinin üzerinde çalıştığı bir patch paneldi. dentOS tarafında DDM okuyamıyorsan, karşı uçtan ya da bir host'tan oku - tek başına bir bitmask bunu çözmeyecek.