LibreNMS không tìm thấy optical sensor nào trên OLT ZTE ZXA10 C300/C320 và cũng không có interface ONU nào cả
Mình phụ trách access layer tại một ISP nhỏ, và mình muốn hai OLT GPON của bọn mình hiện trong monitoring giống như mọi thứ khác. Danh sách mong muốn không có gì lạ: chassis nóng bao nhiêu, tải CPU và RAM, counter theo từng cổng, và phần mình thực sự quan tâm, phía quang. Nghĩa là Rx/Tx dBm cho chính các cổng OLT và một con số Rx cho mỗi ONU thuê bao.
- ZTE ZXA10 C300 và ZXA10 C320, SNMP v2c community chỉ đọc
- LibreNMS 25.8.0-dev, poller tự host tại chỗ
- uplink SFP và SFP+ trên cả hai OLT
Ra khỏi hộp là mình chẳng có gì về quang cả:
# discovery completes, device is green, but:
# - no transceiver Rx/Tx power sensors are discovered for either OLT
# - ONU interfaces do not exist in IF-MIB, only the OLT's own ports
snmpwalk -v2c -c <community> <olt> IF-MIB::ifDescrNhững gì mình đã làm:
- xác nhận bản thân SNMP vẫn khỏe, đồ thị traffic trên uplink và cổng PON vẫn vẽ đúng
- rediscover thiết bị sau mỗi lần đổi và kiểm tra các bảng sensor chuẩn, toàn bộ đều trống
- tìm một template có sẵn cho dòng C320 và không thấy gì phủ được cổng GPON hay optic ONU
Vậy các hộp này thực sự publish cái đó ở cây nào, cho cả cổng của chính chúng lẫn cho từng ONU, và có ai đưa được nó vào LibreNMS theo kiểu sống sót qua một lần upgrade chưa?
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
Bản ngắn gọn: chẳng có gì về quang trên các OLT này sống trong MIB chuẩn cả, tất cả nằm trong cây enterprise riêng của ZTE, 3902.
Bắt đầu với cái dễ, nhiệt độ chassis ở .1.3.6.1.4.1.3902.1015.2.1.3.2. Có một định nghĩa sensor PHP lưu hành đâu đó cho nó với ngưỡng 65/55/15/5 độ. Đừng tin ngay những con số đó, kiểm tra chúng so với mức chassis của bạn thực sự chạy trước khi nối alerting vào.
Phía ONU mới là việc thật sự. IF-MIB chỉ mô tả các interface của OLT, và một cổng PON đơn có thể mang tới 128 ONU, nên chẳng có gì để treo một interface lên cả. Cái người ta cuối cùng làm là dựng index từ shelf, slot, port và số ONU đóng gói vào một số nguyên:
và dùng nó với cây ONU:
Cây đó mang mức RX của ONU và bộ đếm byte Counter64, nên traffic theo từng ONU cũng ra từ cùng một lần walk đó.
Hai lời cảnh báo. Đây là một đống patch của người dùng, chẳng có gì lên được upstream, nên giữ bản sao của bạn ở đâu đó để áp lại được sau một lần update. Và một OLT với hơn 300 ONU nhân số sensor của bạn lên khoảng mười lần, và poller sẽ để ý tới điều đó. Ở quy mô đó, hãy đưa dữ liệu ONU vào Components thay vì vào interface bình thường.
Hai câu hỏi trước khi ai đó viết template cho bạn.
Bạn đã walk cái gì ngoài các MIB chuẩn chưa? Trên dòng ZXA10, dữ liệu đáng quan tâm không nằm trong IF-MIB, nên một bảng sensor trống là kết quả đúng như mong đợi chứ không phải bug. Đăng lên cái bạn nhận được từ
Nếu cái đó trả về một giá trị, bạn có cơ sở để làm tiếp và phần còn lại chỉ là tính toán index.
Thứ hai: có bao nhiêu ONU trên mỗi cổng PON, và tổng cộng bao nhiêu trên mỗi chassis? Con số đó quyết định bạn muốn sensor bình thường hay thứ gì đó nhẹ hơn, và nó thay đổi lời khuyên khá nhiều.
Đúng là nó. Walk 3902 bằng tay trả về giá trị ngay lập tức, và sau khi nối nó vào, giờ mình có temperature, CPU, memory, bandwidth, error counter và RX dBm cho cả cổng OLT lẫn ONU.
Lời cảnh báo về quy mô cũng không phải lý thuyết suông. C300 mang hơn 300 ONU, và thời gian chạy poller cho thiết bị đó dài ra thấy rõ một khi mỗi ONU biến thành sensor, nên dữ liệu theo từng ONU đang được chuyển sang Components và chỉ optic của OLT ở lại như sensor bình thường. Mình vẫn gọi đây là một phần chứ chưa xong hẳn: nó chạy được, nhưng đó là bộ patch của riêng mình, và chẳng có gì cho C320 là làm sẵn cả.
Khác vendor, nhưng cùng bài học từ phía mình: một khi một hộp đưa cho bạn con số, hãy kiểm tra chúng với đầu xa trước khi dựng alerting dựa trên đó.
Bọn mình có hai link 20 km dùng SFP+ không phải Juniper giữa một EX4550 và một cặp EX3300. Cả hai link đều truyền traffic bình thường, nhưng trên EX4550
show interfaces diagnostics opticsin ratrong khi đầu EX3300 của cùng sợi quang đó báo 0.1196 mW / -9.22 dBm. Đó là một lỗi scaling của Junos trên EX4550, PR1007055, đã sửa trong 12.3R8. Cho tới khi bọn mình upgrade, bọn mình coi chỉ số trên EX4550 chỉ là trang trí và dùng số liệu ở đầu xa.
Nghe lại qua người khác nên cứ tham khảo nhẹ thôi: trên ICX 7450 và ICX 7550, optical monitoring được cho là trống trơn với các part number do Ruckus cung cấp 33211-100 và 33210-100, trong khi hàng tương đương coded Brocade trong cùng chassis lại báo bình thường, được track là FI-264785 với bản sửa dự kiến quanh bản build 08.0.95j. Đáng để
show optictrước khi ai đó bắt đầu cắm lại module.