SONiC'te bir QSFP28 kafesindeki QSA adaptörü: 10G optik link veriyor ama DDM bildirmiyor
SONiC çalıştıran bir whitebox switch'te bir yığın 10G optiği yeniden kullanıyoruz, bu yüzden birkaç QSFP28 kafesine QSA tarzı adaptörler (10GTek QSA-100A) takılmış, bunlar sıradan 10G SFP+ modülleri taşıyor. Mekanik ve elektriksel olarak sorun yok. İşler management tarafında dağılıyor.
- switch: 1U whitebox, o platform için derlenmiş SONiC
- adaptörler: 10GTek QSA-100A, QSFP28 kafesten SFP+'a
- optikler: kullanımdan kaldırılmış bir access switch'ten çıkarılmış 10G SFP+ modülleri
- aynı optikler başka bir cihazda native bir SFP+ kafesinde normal okunuyor
Adapte edilmiş portlarda gördüğüm:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portŞimdiye kadar denediklerim:
- ikinci bir adaptör ve ikinci bir optik taktım, davranış aynı;
- çifti farklı bir QSFP28 kafesine taşıdım, sonuç aynı;
- optiklerin başka yerde native bir SFP+ portunda tam diagnostik bildirdiğini doğruladım.
Eksik diagnostik verisi, pasif bir adaptörün taşıyamayacağı bir şey mi, yoksa bu switch yazılımı tarafında mı? Ve yazılımsa, düzeltme nereye ait: platform katmanına mı, yoksa genel transceiver koduna 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 7
Kimse platform koduna dalmadan önce, meseleyi ikiye bölen bir soru. Aynı kafese native bir QSFP28 modülü tak: ondan diagnostik alıyor musun, yoksa o port neye taksan DDM'i ölü mü veriyor?
Native parça düzgün okuyorsa, kafes ve I2C yolu sağlam demektir ve her şey port sürücüsünün adaptörden geleni nasıl yorumladığına iniyor. Native parça da boş dönüyorsa, konunun geri kalanını okumayı bırak, elindeki farklı bir arıza ve adaptörlerle hiçbir ilgisi yok.
Management arayüzünde iyi bilinen ve oldukça sıkıcı bir fark, ve suçlu burada adaptör değil.
SFP tarafında devrede iki I2C adresi var: kimlik verisi 0x50'de yaşıyor, diagnostik haritası 0x51'de. Bir QSFP parçası ise hepsini 0x50'nin altında tutuyor ve gerisine sayfa değiştirerek ulaşıyor. Yani kafesin QSFP olduğu söylenmiş bir sürücü, tek bir adreste sayfa aramaya gidiyor ve 0x51'e hiçbir şey sormuyor. Kimlik, portun gelmesine yetecek kadar makul dönüyor, diagnostik ise hiç çözülmüyor - tam olarak paylaştığının şekli bu.
Düzeltme platform katmanına ait, optiğe ya da adaptöre değil. Her platform kendi SfpUtil uygulamasını gönderiyor; seninkinde o port QSFP yerine bir SFP kafesi olarak beyan edilmek zorunda. Biri bunu yapana kadar, adapte edilmiş portlarda DDM/DOM boş kalır. Sonrasında modül, native bir SFP+ kafesindeki gibi okunur.
Arkasında diagnostikte hiçbir şey olmayan canlı bir link, bu portlarda hatalı yazılımın nasıl göründüğüdür. Sınırda bir optiğin göründüğü şey değildir.
Standartları adıyla anmakta fayda var, çünkü o zaman ayrım netleşiyor. SFP tarafı SFF-8472; burada diagnostik, ikinci adresten erişilen kendi bellek haritasında yaşıyor. QSFP ve QSFP28 ise SFF-8636'yı, daha yeni parçalar da CMIS'i izliyor; burada her şey bir page select'in arkasında tek bir adrese asılı.
Adaptör bunun köprüsünü kuramaz. Pasif bir mekanik ve elektriksel parça; management telleri onun içinden düz geçiyor ve yolda hiçbir şey onları çevirmiyor. Yani host'a, tek bir byte okumadan önce iki bellek modelinden hangisinin geçerli olduğu söylenmek zorunda, ve adaptörün bunu söylemenin hiçbir yolu yok.
Karşılaştırma için, Dell ONIE donanımında aynı sınıf problem daha sert ısırıyor. İçinde 407-BBOU 10GBASE-SR SFP+ (SFP-10GSR-85) olan bir 407-BBRO QSA, bir S4048-ON'un 40G portlarında ve bir S6010-ON'un herhangi bir portunda, ikisi de OpenSwitch OPX 3.1 dev2 çalıştırıyor:
opx-ethtool medyayı doğru tanımlıyor, transceiver'ı enabled ve qualified, admin state up, desteklenen hızlar 1000, 10000 ve 40000 Mbps olarak işaretliyor, ve port yine de gelmiyor - hangi hız, duplex ya da autoneg yapılandırılmış olursa olsun, varsayılanlar dahil. Biri bunu OPX platform-config deposunda "buradaki QSA'yı çalışır hale getirin" başlığıyla bir geliştirme talebi olarak açmış, kimse hiç yanıtlamamış. Hâlâ açık duruyor.
Ne bir vendor lock ne de kötü bir optik. O kafes basitçe network OS tarafından hiçbir zaman adaptör moduna alınmıyor, ve hiçbir arayüz ayarı kombinasyonu bunu senin için yapmayacak.
İlgili, ama iki vakayı birbirine katma lütfen. Orijinal gönderide olan, eksik diagnostikli çalışan bir link: veri yolu sorunsuz, sadece management okuması yanlış, ve platform SfpUtil'ini yamalamak bunu düzeltiyor. Dell vakası ise hiç gelmeyen bir port, çünkü o kafes için port profili baştan hiç uygulanmıyor. Bu bir katman aşağıda duruyor ve kendi düzeltmesini istiyor.
Aceleyle belirtileri eşleştiren biri, portu tamamen alakasız bir nedenle down'dayken transceiver kodunu yeniden yazarak bir gün harcayabilir.
"Adaptör mekanik değil bir yazılım özelliğidir" fikrinin bir başka çeşidi. OS10 10.5.2.7 altındaki bir Z9264F-ON'da, 10G SFP+ medyası için QSA28 adaptörleri kullanmak, portu 4x10G breakout kablosunun kullandığı aynı port-group profiline koymak demek:
O platformda port-group profilleri QSFP28 port çiftleri üzerinde etki ediyor, yani onu uygulamak her çiftin eş portunu devre dışı bırakıyor. QSA28 tek bir arayüz ama yine de breakout şeklinde bir bedel ödüyorsun: 64 kullanılabilir port 32'ye iniyor. Ne OS10 kullanıcı kılavuzları ne de Dell optik spec sayfası tek portluk bir QSA modunu belgeliyor.
O cihazda çok sayıda native 10G'ye ihtiyacın varsa, 2:1 kaybını baştan planla ya da rack'e ayrı bir 10G switch koy.
Kimse bunlardan bir tepsi sipariş etmeden önce, listeye iki kontrol koyardım. Network OS, tam olarak o platform için QSA desteğini beyan ediyor mu, ve ediyorsa, onu açmak sana neye mal oluyor: portlara mı, diagnostiğe mi, yoksa komşu kafesi de beraberinde aşağı çeken bir profile mi. Sığma hiçbir zaman sorun değil, bu adaptörlerin her biri kafese itirazsız giriyor.
Bu konudaki vakalar sadece yazılımın ne kadar ileri gittiğinde farklılaşıyor. SONiC'te kendin düzeltebileceğin bir şey var, portu SFP olarak beyan et ve diagnostik geri gelir. Yukarıdaki Dell platformlarında ise başkasının platform kodunu bekliyorsun, ve adaptör ya da optik değiştirmek bunu hiç kıpırdatmaz.