Adapter QSA trong cage QSFP28 của SONiC: optic 10G lên link nhưng không báo DDM
Bên mình đang tái sử dụng cả đống optic 10G trên một whitebox switch chạy SONiC, nên vài cage QSFP28 được gắn adapter kiểu QSA (10GTek QSA-100A) mang module SFP+ 10G thường. Về cơ khí và điện thì ổn. Phía quản lý mới là chỗ đổ vỡ.
- switch: whitebox 1U, SONiC build riêng cho platform đó
- adapter: 10GTek QSA-100A, cage QSFP28 sang SFP+
- optic: module SFP+ 10G lấy ra từ một access switch đã ngừng dùng
- cùng những optic đó đọc bình thường trong một cage SFP+ gốc trên một hộp khác
Những gì thấy trên các port đã adapt:
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Đã thử:
- đổi sang adapter thứ hai và optic thứ hai, hành vi giống hệt;
- chuyển cặp đó sang một cage QSFP28 khác, kết quả như nhau;
- xác nhận optic báo đầy đủ diagnostics ở một port SFP+ gốc chỗ khác.
Dữ liệu diagnostics bị thiếu là thứ mà một adapter passive đơn giản là không mang được, hay đây là vấn đề ở phần mềm switch? Và nếu là phần mềm, chỗ sửa thuộc về đâu: lớp platform hay code transceiver generic?
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
Trước khi ai đó đào sâu vào code platform, một câu hỏi tách đôi chuyện này ra. Cắm một module QSFP28 gốc vào đúng cage đó: có lấy được diagnostics ra không, hay DDM chết trên port đó bất kể cắm gì vào?
Nếu part gốc đọc bình thường, cage và đường I2C vẫn khỏe và toàn bộ chuyện này quy về việc port driver diễn giải những gì tới qua adapter như thế nào. Nếu part gốc cũng trả về trống rỗng, dừng đọc phần còn lại của thread đi, bạn đang gặp một lỗi khác và nó chẳng liên quan gì tới adapter cả.
Khác biệt khá nổi tiếng và cũng khá nhàm chán trong management interface, và adapter không phải kẻ có tội ở đây.
Ở phía SFP có hai địa chỉ I2C tham gia: dữ liệu định danh nằm ở 0x50, memory map diagnostics ở 0x51. Một part QSFP giữ tất cả dưới 0x50 và với tới phần còn lại bằng cách chuyển page. Nên một driver được báo rằng cage này là QSFP sẽ đi tìm page ở đúng một địa chỉ và không bao giờ hỏi 0x51 điều gì cả. Định danh trả về đủ hợp lý để port lên được, còn diagnostics thì đơn giản là không bao giờ resolve, đúng y hình dạng những gì bạn đã đăng.
Chỗ sửa thuộc về lớp platform, không phải optic, cũng không phải adapter. Mỗi platform tự đóng gói implementation SfpUtil riêng của nó; ở chỗ của bạn, port đó phải được khai báo là một cage SFP thay vì QSFP. Cho tới khi ai đó làm điều này, DDM/DOM trên các port đã adapt vẫn trống. Sau đó module sẽ được đọc theo đúng cách như trong một cage SFP+ gốc.
Một link sống mà chẳng có gì phía sau trong diagnostics chính là hình dạng của phần mềm sai trên các port này. Không phải hình dạng của một optic cận biên.
Đáng nêu tên các chuẩn ra, vì như vậy sự tách bạch sẽ rõ ràng. Phía SFP là SFF-8472, nơi diagnostics nằm trong memory map riêng của nó, với tới bằng địa chỉ thứ hai. QSFP và QSFP28 theo SFF-8636, còn các part mới hơn theo CMIS, nơi mọi thứ treo dưới một địa chỉ duy nhất, đứng sau một page select.
Adapter không thể bắc cầu qua chuyện đó. Nó là một linh kiện cơ khí và điện thuần túy passive, dây management chạy thẳng xuyên qua nó và không gì dịch chúng trên đường đi. Nên host phải được báo trước là mô hình memory nào trong hai cái đó áp dụng, trước khi nó đọc dù chỉ một byte, và adapter không có cách nào báo cho nó biết điều đó.
Để so sánh, cùng loại vấn đề trên phần cứng Dell ONIE còn cắn đau hơn. Một QSA 407-BBRO với một SFP+ 10GBASE-SR 407-BBOU bên trong (SFP-10GSR-85), trong port 40G của một S4048-ON và trong bất kỳ port nào của một S6010-ON, cả hai đều chạy OpenSwitch OPX 3.1 dev2:
opx-ethtool nhận diện đúng loại media, đánh dấu transceiver enabled và qualified, admin state up, tốc độ hỗ trợ 1000, 10000 và 40000 Mbps, và port vẫn cứ không bao giờ lên, dù cấu hình speed, duplex hay autoneg kiểu gì, kể cả để mặc định. Có người mở một enhancement request trên repository OPX platform-config, đề nghị làm cho QSA chạy được ở đây, và chẳng ai từng trả lời cả. Nó vẫn còn nằm mở tới giờ.
Không phải vendor lock, cũng không phải optic hỏng. Cage đó đơn giản là chưa bao giờ được network OS đưa vào adapter mode, và không tổ hợp cấu hình interface nào làm được điều đó thay cho bạn.
Có liên quan, nhưng đừng gộp hai trường hợp này làm một. Bài gốc có một link chạy được nhưng thiếu diagnostics: data path vẫn ổn, chỉ có management read là sai, và patch platform SfpUtil sẽ sửa được. Trường hợp Dell là một port không bao giờ lên được, vì port profile cho cage đó ngay từ đầu chưa bao giờ được áp dụng. Cái đó nằm ở một lớp thấp hơn và cần bản sửa riêng của nó.
Ai đó vội vàng khớp triệu chứng có thể đốt cả một ngày viết lại code transceiver trong khi port của họ down vì một lý do hoàn toàn không liên quan.
Một kiểu khác của "the adapter is a software feature" thay vì cơ khí. Trên một Z9264F-ON chạy OS10 10.5.2.7, dùng adapter QSA28 cho media SFP+ 10G nghĩa là đưa port vào đúng port-group profile mà một cáp breakout 4x10G dùng:
Port-group profile trên platform đó tác động lên từng cặp port QSFP28, nên áp dụng nó sẽ vô hiệu hóa port đối tác của mỗi cặp. Một QSA28 là một interface đơn lẻ mà vẫn phải trả cái giá kiểu breakout: 64 port dùng được biến thành 32. Cả user guide của OS10 lẫn spec sheet optic của Dell đều không tài liệu hóa một chế độ QSA đơn port.
Nếu cần nhiều 10G gốc trên hộp đó, tính trước tổn thất 2:1 hoặc đặt riêng một switch 10G khác trong rack.
Trước khi ai đó đặt cả một khay mấy thứ này, mình sẽ đưa hai điều vào danh sách kiểm tra. Network OS có khai báo hỗ trợ QSA cho đúng platform đó hay không, và nếu có, bật nó lên tốn cái giá gì: port, diagnostics, hay một profile kéo theo cả cage bên cạnh sập cùng. Vừa khít không bao giờ là vấn đề, adapter loại nào trong số này cũng cắm vào cage không kêu ca gì.
Các trường hợp trong thread này chỉ khác nhau ở mức phần mềm đi xa tới đâu. Trên SONiC bạn có thứ tự sửa được, khai báo port là SFP và diagnostics quay lại. Trên các platform Dell ở trên, bạn đang chờ code platform của người khác, và đổi adapter hay optic sẽ chẳng nhúc nhích được gì cả.