Edgecore AS5114-48X trên dentOS: SFP+ ở port 18 enumerate bình thường nhưng onlpdump vẫn báo RX_LOS

RX_LOS một mình chỉ nói rằng receiver không thấy đủ ánh sáng, nên trước khi đổ lỗi cho hộp máy: đầu xa báo gì? Nếu port bên kia có phơi bày DDM, đọc Tx power của nó và xác nhận laser thực sự đang bật và port không bị shut. Cũng đáng biết là hai bên có cùng loại optic và cùng chế độ sợi quang không - một module short reach đối diện một module long reach, hay sai loại sợi, đều trông y hệt thế này.

Và đã thử một module khác part number ở port 18 chưa, hay mới chỉ có mỗi con này chuyển qua chuyển lại giữa các port?

Đầu xa là một port 10G trên switch khác, cùng loại optic short reach ở cả hai bên. Port đó lên link thoải mái với một module khác qua đúng dây patch này, nên laser phía bên kia còn sống và tuyến cáp quang tốt từ đầu tới cuối. Port 18 đang admin up, và kết quả y hệt khi đảo ngược dây.

Phần khó chịu là những gì quan sát được tại chỗ: onlpdump chỉ cho presence cộng bitmask trạng thái, hết. Không có con số Rx nào ở phía dentOS để so với đầu xa, nên bị kẹt ở mức "something is not receiving" mà không biết là đầu nào.

Từ triệu chứng suy ra nguyên nhân, theo đúng thứ tự sẽ làm. Detection chỉ chứng minh đường I2C/EEPROM và phần MAC ổn, không hơn. Dòng kernel về inband/10gbase-r là phía host tự cấu hình cho chính nó - không có nghĩa là một photon nào đã tới. Với RX_LOS đang assert thì còn lại ba nghi phạm: sợi quang tối hoặc bị chéo, đầu xa không phát, và một receiver không hoạt động trên platform này.

Hai cái đầu đã được đẩy mạnh rồi, nên đừng gom bit nữa mà lấy một con số cụ thể. Switch nào in được digital diagnostics cũng được. Trên EXOS là show ports <port> transceiver information, cho ra nhiệt độ, điện áp nguồn, laser bias, Tx và Rx power và đánh dấu mọi giá trị vượt ngưỡng module, còn debug hal show optic port <port> thêm vendor, part number, serial, connector và bước sóng từ EEPROM. Từng săn một port 10G chết trên một X460-G2-24x-10G4 theo cách đó và thấy khoảng -26,78 dBm tại receiver, mức mà không receiver short hay long reach 10G nào khóa được.

Nếu đầu xa cho được một số đo Rx trong lúc module của bạn phát, ít nhất cũng biết được laser của nó có chạy hay không. Cái còn lại sau đó là platform không drive được đúng linh kiện này.

Cùng loại hộp ở đây, và trên platform này việc hỗ trợ module tính theo từng part, không theo chuẩn chung. Trên AS5114-48X của bên này, Avago AFBR-703SDZ-IN2 rev G2.3 lên không cần tune gì cả - platform báo nó là Intel Corp với serial AA1329A5UTA, dễ làm người ta bối rối lúc mới nhìn.

Hai part chưa bao giờ chạy được với bên này trên cùng switch, cùng sợi quang: Intel FTLX8571D3BCV-IT rev A giống của bạn, và một OPNEXT TRS5020EN-S301. Cả hai đều được detect, cả hai đều nằm y hệt như port 18 của bạn. Mượn một part biết chắc là tốt trước khi tốn thêm một buổi tối vào hệ thống cáp quang.

Đáng chính xác hóa điểm đó: RX_LOS là output loss-of-signal của chính module, định nghĩa trong SFF-8472, và lớp platform chỉ đưa nó ra thành status 0x00000004. Nó assert khi dưới ngưỡng LOS của receiver, nên chỉ nói cho bạn biết "not enough light" chứ không bao giờ nói vì sao. Đó cũng là lý do một lần đọc EEPROM hoàn toàn sạch và một đường quang chết vẫn cùng tồn tại mà không mâu thuẫn gì.

Lý do khác để cứ đòi cho được một con số Rx thật: suy hao nhìn qua CLI giống hệt như không tương thích. Một đồng nghiệp từng có một port Zyxel nằm quanh -25,69 dBm, và cách sửa là dây patch cộng một patch panel ai đó đã đấu lại ẩu, không phải module. Nếu không đọc được DDM ở phía dentOS, đọc từ đầu xa hoặc từ một host khác - chỉ một bitmask thôi sẽ không giải quyết được chuyện này.