ZXA10 OLT trong LibreNMS: không có dBm transceiver trên trang port, và sensor fan với PSU biến mất
Chúng tôi poll một dàn OLT ZTE ZXA10 hỗn hợp từ LibreNMS và có hai thứ đang sai. Tôi nghi là chúng không liên quan tới nhau, nhưng không chắc.
- ZTE ZXA10 C300 trên V2.1.0, vẫn đang chạy ở một POP cũ
- ZTE ZXA10 C620 trên V2.0.30, cộng một C650 và một C650E
- một ZTE ZXA10 C320 trước đây vẫn chạy tốt
- uplink SFP và SFP+, bên dưới là card GPON
Vấn đề thứ nhất: trang port không hề có sensor transceiver nào cả. Không công suất thu hay phát tính bằng dBm, không nhiệt độ module, không điện áp cấp nguồn, không dòng bias laser. Đó là những con số tôi cần để bắt được một connector bẩn trước khi thuê bao bắt đầu gọi điện.
Vấn đề thứ hai: các sensor trạng thái từng chạy tốt trên C320, gồm fan, nguồn và trạng thái card, âm thầm biến mất sau một lần rediscovery. Không có lỗi trong log, không có gì fail cả, chúng đơn giản là không còn trên thiết bị nữa.
Đi dò từng hộp bằng tay, dữ liệu quang rõ ràng có nằm đâu đó trong MIB, nhưng một OID trả lời được trên platform này lại không trả về gì trên platform khác:
snmpwalk -v2c -c <community> <olt> .1.3.6.1.4.1.3902.1015.3.1.13.1Đã thử:
- rediscovery và poll đầy đủ trên từng thiết bị
- so sánh một C650 trả lời gì với một C300 trả lời gì trên cùng OID
- kiểm tra xem cage rỗng có phải là lý do discovery bỏ cuộc không
Các chỉ số quang thực sự nằm ở đâu trên dòng ZXA10, và điều gì khiến một sensor trạng thái biến mất lúc discovery mà không log lại gì cả?
Comments 5
Cả hai đều đã biết, và đúng như bạn đoán, chúng không liên quan tới nhau.
Bảng optical bạn nhận được phụ thuộc vào platform, và hai bảng đó không bao giờ cùng tồn tại trên một hộp. C300 đời cũ, test ở đây trên V2.1.0, expose zxAnOpticalModuleMonTable:
C620 trên V2.0.30, C650 và C650E thì expose zxAnOpticalModuleInfoTable thay vào đó:
Bảng nào cũng đưa cho bạn đúng bốn chỉ số: công suất rx và tx tính bằng dBm, nhiệt độ module, điện áp cấp nguồn, dòng bias laser. Giá trị thô cần nhân hệ số 0.001. Cũng cần lọc hai giá trị sentinel, nếu không mọi cage rỗng trong chassis sẽ báo động với bạn: một port không hỗ trợ hoặc một cage chưa lắp trả lời 2147483647, còn một port tối trả lời -80000. Sự hiện diện của card hoàn toàn không thuộc về phần polling quang, đó là một sensor trạng thái operational-status riêng biệt, nó bỏ qua các slot chưa lắp.
Chuyện fan, PSU và trạng thái card biến mất bên bạn là một bug khác. Các entry trạng thái trong YAML của platform bị thiếu key value:, và không có nó thì discovery kết cục đọc tên bảng như thể đó là một cột, chẳng tìm được gì dùng được rồi âm thầm bỏ sensor đó, không báo lỗi ở đâu cả, đó là lý do vì sao bạn chỉ nhận ra nó qua sự vắng mặt. Đặt lại key đó đã khôi phục sáu sensor trên bộ C320 test ở đây.
Cảnh báo trước khi bạn tính toán dựa vào nó: cái này đang nằm trong một change vẫn còn mở chứ chưa merge, và review đã cắt bớt phần theo dõi lỗi ethernet ra khỏi nó vì coi là ngoài phạm vi. Coi nó như một patch bạn tự mang theo, không phải một fix để chờ đợi.
Cho xem sysDescr mà từng hộp đó báo về. C300, C320, C620, C650 và C650E không phải cùng một họ xét theo optical MIB, nên một OID trả lời được trên vài cái và im lặng trên số còn lại là chuyện bình thường chứ không phải lỗi.
Đăng đoạn cuối của một lần walk từ hai cái khác nhau nhiều nhất, C300 và một trong các C650, trên cái OID bạn đã thử. Nếu một cái trả lời còn cái kia trống rỗng, đó là toàn bộ câu chuyện rồi và cách sửa là theo từng platform.
Cũng nên tách riêng hai vấn đề của bạn ra. Sensor fan và PSU bị thiếu là vấn đề định nghĩa discovery, chẳng liên quan gì tới việc OLT implement bảng optical nào.
Xác nhận khoảng trống đó từ phía bên kia. Tôi từng hỏi về cùng dòng này trên 25.8.0-dev: một OLT GPON C320, và thứ tôi cần là graph trên các port GPON ở cả hai đầu, trên OLT và trên ONU - mức công suất rx và tx, mỗi link đo được dài bao nhiêu, utilisation từng port - cộng thêm liệu một template cho dòng này đã tồn tại ở đâu đó chưa.
Nó bị đóng lại mà không ai đăng OID, một lần walk hay một phương pháp nào, nên tất cả những gì nó ghi lại là coverage out-of-the-box cho dòng C320 chỉ là một phần. Nhìn lại thì lẽ ra tôi nên đính kèm một lần walk vào request. Nếu dù sao bạn cũng đang xây cái này, mức công suất quang của ONU là phần chưa ai làm và khá nhiều người trong chúng ta sẽ dùng tới nó.
Đúng với những gì dàn máy của tôi thể hiện. C300 trả lời trên .1.3.6.1.4.1.3902.1015.3.1.13.1 và không trả về gì trên OID kia, C620 và C650 thì ngược lại, còn C650E hành xử giống C650.
Giá trị trả về là số nguyên cần nhân hệ số 0.001, đúng như mô tả. Những cái ban đầu trông như rác giờ đã hợp lý: 2147483647 trên các cage chúng tôi chưa bao giờ lắp, và -80000 trên hai port có đầu xa đang tắt nguồn. Cả hai sentinel đều có thật ở đây, nên ai viết threshold dựa trên số thô sẽ nhận một danh sách cảnh báo ồn ào kinh khủng.
Cũng kiểm tra YAML của platform và bên tôi cũng thiếu đúng key value: đó. Sẽ tự mang patch đó cục bộ vì change vẫn còn đang mở. Tách hai vấn đề ra là phần tôi làm sai ngay từ đầu.
Một điều cần nhớ khi xây cái này: dữ liệu DOM ở đâu cũng chỉ là một tập con, không riêng gì ZTE.
Trong SONiC một CISCO-AVAGO AFBR-89CDDZ-CS3 QSFP28 đọc EEPROM không gặp trục trặc gì, và TRANSCEIVER_INFO, TRANSCEIVER_DOM_SENSOR cộng TRANSCEIVER_STATUS đều điền đầy đủ identity cộng nhiệt độ, điện áp, bias và công suất từng lane, nhưng nhóm control và status thì hoàn toàn vắng mặt: get_rx_los, get_tx_fault, get_tx_disable, get_lpmode và get_power_override trả về rỗng trong database view, nên nếu cần mấy bit đó bạn phải tự đi hỏi platform API lấy.
Cùng bài học từ phía firewall. Trên PAN-OS, show transceiver-detail all in ra khối diagnostic, và trường đầu tiên cần đọc là diagnostic-monitor. Nếu nó ghi No, module không implement digital optical monitoring và mọi giá trị trả về đều là N/A. Chẳng có gì hỏng ở đó cả, chỉ đơn giản là không có gì để đọc. Đáng để mã hoá sự khác biệt đó trong alerting của bạn để một module không có DOM không trông giống một port đã chết.