Edgecore AS9716-32D: sfputil, 400G QSFP-DD modülünü PDDF altında QSFP28 olarak çözümlüyor
Laboratuvarda bir çift AS9716-32D'yi PDDF platform katmanlı bir community SONiC imajı üzerinde 400G spine olarak ayağa kaldırıyoruz. Sorun optikler değil, karşı taraf sorunsuz link veriyor, ama switch'in onlar hakkında söylediği her şey yanlış.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- bu platform için PDDF'li community SONiC build'i
- ilk yuvada 400G QSFP-DD modülü (NeoPhotonics parçası)
Okumanın kendisi başarılı oluyor, modül listeleniyor, yuva QSFP28 olarak raporlanıyor:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsİşler tam da bu identifier satırında dağılıyor. Bu bir QSFP-DD parçası, yani aşağıdaki byte'lar CMIS yerine SFF-8636 alan setine göre çözümleniyor, ardından gelen alanlar da gürültü gibi okunuyor.
Şimdiye kadar kontrol ettiklerim:
- modülün kendisi sağlam, aynı parça başka bir platformda doğru okunuyor ve karşı uç ışığı görüyor;
- yeniden oturtmak ve başka bir yuvaya taşımak hiçbir şeyi değiştirmiyor, tüm 400G portları aynı davranıyor;
- PDDF device description'da bu yuvalar QSFP28 olarak tanımlanmış ve optoe1'e bağlanmış.
Son nokta tüm cevap mı, QSFP-DD yuvaları basitçe farklı bir optoe device mi istiyor, platform description'ı düzenlemek kabul gören çözüm mü, yoksa üstündeki bir katmanın da yuva tipini öğrenmesi mi gerekiyor?
Comments 4
Belirtin tam olarak binding'e işaret ediyor, optiklerde daha fazla aramaya gerek yok.
AS9716-32D için PDDF device description, 400G yuvalarını QSFP28 olarak tanımlıyor ve onları optoe1'e bağlıyor. optoe1, QSFP+ ve QSFP28'in kullandığı SFF-8636 EEPROM düzenini sunuyor, yani bir CMIS modülü yanlış haritadan okunuyor ve identifier'dan sonraki her şey gürültü gibi görünüyor. Gördüğün port tipi hiç tespit edilmiş değil, sadece description'da öyle yazıyor.
QSFP-DD, CMIS'i takip ediyor, CMIS de optoe3 tarafından sunuluyor. Çözüm, o yuvalar için PDDF device description'daki iki alanı da çevirmek: tipi QSFP28'den QSFP-DD'ye, driver'ı da optoe1'den optoe3'e. Bunu aynı cihazda 400G'lik bir NeoPhotonics parçasıyla doğruladım, değişiklikten sonra
sfputil show eeprommodülü düzgün çözümlenmiş olarak döndürüyor.İki uyarı var. Bu platform verisi, yani değişiklik build ettiğin imajın içinde değilse bir imaj yükseltmesi eski description'ı seve seve geri getirir. Bir de upstream'de tam olarak bu değişiklik onaylandı ama pull request merge edilmeden kapatıldı, çalışma daha sonraki bir değişikliğe katılmış, yani imajının bunu zaten taşıdığını varsayma. Önce kendi platformunun device description'ını oku, bir dakikada peşinde bir şey olup olmadığını anlarsın.
Herhangi bir platform dosyasına dokunmadan önce o portta ham dump'ı paylaş:
sudo sfputil show eeprom -d. Bütün byte'lar oradaysa ve sadece yorumlama bozuksa bu bir binding sorunu, modül sorunu değil, ve kimse RMA'dan bahsetmeye başlamadan önce bu ayrımı yapmak on dakikanı alır.Diğer yarısını zaten kendin cevaplamışsın. optoe1, QSFP+ ve QSFP28'in kullandığı SFF-8636 türü, yani bir CMIS modülü onun üzerinden okununca identifier'dan itibaren bozuk çıkıyor, tam olarak yapıştırdığın çıktı gibi. Description bir QSFP-DD yuvası için optoe1 dediği sürece modül tarafında şüphelenecek bir şey kalmıyor.
O yüzden o yuvalardan birinin PDDF device description'ının ilgili satırlarını da yapıştır. Bu bize sadece driver alanının mı yanlış olduğunu, yoksa deklare edilen yuva tipinin de mi yanlış olduğunu söyler.
Aynen oydu. Yuva tipini QSFP-DD'ye, driver'ı optoe3'e çevirdim, reload attım, modül artık düzgün çözümleniyor,
sfputil show eepromda yuvaya artık QSFP28 demiyor. Değişikliği çalışan switch'i yamamak yerine build ettiğimiz imaja koydum, tam olarak yukarıdaki upgrade meselesi yüzünden.Bunu daha sonra bulacaklar için dürüst bir not: bu sadece EEPROM'un nasıl okunduğunu düzeltiyor, başka bir şey değil. Bu platformdaki transceiver donanımının geri kalanının hâlâ kendi tuhaflıkları var, kutuyu tamamen çözülmüş sayamam.
Kalan tuhaflıklardan bahsetmişken, aynı platformda seni bekleyen bir tanesi daha var. Bizim SONiC master build çalıştıran AS9716-32D'de (x86_64-accton_as9716_32d-r0),
sudo sfputil show presencedolu portları Present olarak listeliyor ve EEPROM'larını sorunsuz okuyor,show interfaces transceiver presenceise her portu Not present olarak raporluyor. Syslog'da şu tekrarlanıyor:ve CLI üzerinden EEPROM okumak RuntimeError('PddfEeprom is not Programmed') ile başarısız oluyor. Bir reboot'tan sonra rastgele ortaya çıkıyor, hiçbir zaman kök neden paylaşılmadı, o yüzden orada güvendiğim tek presence kontrolü sfputil olarak kalıyor.
Alakasız ama aynı bölgeden: bu iki komutun 202012 branch'inde key isimlerinde anlaşamadığı da biliniyor, bu 202205'te temizlendi. Çıktıların içerik değil de sadece ifade bakımından farklıysa muhtemelen mesele budur.