Edgecore AS9716-32D: sfputil giải mã module QSFP-DD 400G thành QSFP28 dưới PDDF
Bọn mình đang dựng một cặp AS9716-32D làm spine 400G trong lab, chạy image SONiC cộng đồng với lớp platform PDDF. Quang học không phải vấn đề, đầu bên kia lên link bình thường, nhưng mọi thứ switch báo về chúng đều sai.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- bản build SONiC cộng đồng với PDDF cho platform này
- module QSFP-DD 400G (hàng NeoPhotonics) trong khe đầu tiên
Việc đọc thì thành công, module được liệt kê, nhưng khe lại được báo là QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsChính dòng identifier đó là chỗ vỡ trận. Đây là hàng QSFP-DD, nên các byte bên dưới đang bị giải mã theo tập trường SFF-8636 thay vì CMIS, và các trường tiếp theo đọc lên chỉ toàn nhiễu.
Đã kiểm tra:
- bản thân module vẫn tốt, cùng loại đó đọc đúng trên platform khác và đầu kia thấy ánh sáng;
- rút cắm lại và chuyển sang khe khác không đổi gì, tất cả các port 400G đều hành xử giống hệt nhau;
- trong mô tả thiết bị PDDF, các khe này được khai là QSFP28 và bind vào optoe1.
Điểm cuối đó có phải là toàn bộ câu trả lời không, khe QSFP-DD có đơn giản là cần một thiết bị optoe khác, và sửa mô tả platform có phải cách được chấp nhận để fix không, hay còn thứ gì ở tầng trên cũng cần biết loại khe?
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 4
Triệu chứng của bạn khớp chính xác với chuyện binding, nên không cần soi thêm quang học nữa.
Mô tả thiết bị PDDF cho AS9716-32D khai các khe 400G là QSFP28 và bind chúng vào optoe1. optoe1 phơi ra layout EEPROM SFF-8636 mà QSFP+ và QSFP28 dùng, nên một module CMIS bị đọc qua sai bản đồ và mọi thứ sau identifier trông như nhiễu. Loại port bạn thấy hoàn toàn không phải được phát hiện ra, nó chỉ đơn giản là những gì mô tả ghi.
QSFP-DD theo chuẩn CMIS, và CMIS được phục vụ bởi optoe3. Cách fix là đảo cả hai trường trong mô tả thiết bị PDDF cho các khe đó: loại từ QSFP28 sang QSFP-DD, và driver từ optoe1 sang optoe3. Mình đã kiểm chứng trên đúng cái máy đó với một hàng NeoPhotonics 400G, và sau khi đổi thì
sfputil show eepromtrả về module được giải mã đúng.Hai điều cần lưu ý. Đây là dữ liệu platform, nên một lần nâng cấp image sẽ vui vẻ đặt lại mô tả cũ trừ khi thay đổi nằm trong image bạn tự build. Và ở upstream, đúng thay đổi này đã được duyệt nhưng pull request lại bị đóng mà không merge, phần việc đó được gộp vào một thay đổi sau, nên đừng cho rằng image của bạn đã có sẵn nó. Đọc mô tả thiết bị cho platform của bạn trước, chỉ một phút là biết có đang đuổi theo cái gì không.
Trước khi đụng vào bất kỳ file platform nào, dán ra bản dump thô:
sudo sfputil show eeprom -dtrên port đó. Nếu tất cả các byte đều có mặt và chỉ phần diễn giải bị sai, đây là vấn đề binding chứ không phải vấn đề module, và cái phân biệt đó đáng bỏ mười phút ra trước khi ai đó bắt đầu nói tới RMA.Nửa còn lại thì bạn tự trả lời rồi. optoe1 là kiểu SFF-8636 dùng cho QSFP+ và QSFP28, nên một module CMIS đọc qua nó ra kết quả méo mó ngay từ identifier trở đi, đúng y như output bạn dán lên. Một khi mô tả đã ghi optoe1 cho một khe QSFP-DD thì chẳng còn gì để nghi ngờ ở phía module nữa.
Vậy dán luôn các dòng liên quan trong mô tả thiết bị PDDF cho một trong các khe đó. Cái đó cho biết chỉ trường driver sai hay cả loại khe khai báo cũng sai.
Đúng là nó. Đổi loại khe sang QSFP-DD, driver sang optoe3, reload, và module giờ giải mã đúng,
sfputil show eepromkhông còn gọi khe đó là QSFP28 nữa. Mình đưa thay đổi vào image tự build thay vì patch trực tiếp switch đang chạy, chính vì cái điểm nâng cấp nói ở trên.Một lời thật lòng cho ai tìm thấy cái này sau: nó chỉ fix cách EEPROM được đọc, không hơn. Phần còn lại của đường ống transceiver trên platform này vẫn còn những tật riêng, mình không dám nói máy đã ổn hoàn toàn.
Vì bạn nhắc tới mấy tật còn sót lại, đây là cái đang chờ bạn trên cùng platform này. Trên AS9716-32D (x86_64-accton_as9716_32d-r0) của bọn mình chạy bản SONiC master,
sudo sfputil show presenceliệt kê các port đã cắm module là Present và đọc EEPROM của chúng bình thường, trong khishow interfaces transceiver presencelại báo mọi port là Not present. Syslog lặp đi lặp lại:và đọc EEPROM qua CLI thì fail với RuntimeError('PddfEeprom is not Programmed'). Nó xuất hiện ngẫu nhiên sau một lần reboot và chưa ai từng đăng được nguyên nhân gốc, nên sfputil vẫn là cách kiểm tra presence duy nhất mình còn tin ở đó.
Không liên quan nhưng cùng khu vực: hai lệnh đó cũng được biết là không khớp tên khóa trên nhánh 202012, cái đã được dọn lại ở 202205. Nếu output của bạn chỉ khác cách gọi tên chứ không khác nội dung, thì chắc chỉ là vậy thôi.