NAPALM get_optics trên nxos_ssh chỉ trả về DOM của lane 1 cho module QSFP-100G-CWDM4
Tôi đang gắn telemetry quang theo từng port vào hệ thống giám sát cho vài fabric Nexus 9000. Việc thu thập chạy qua NAPALM, và getter tôi dùng là get_optics().
- các cặp leaf và spine Nexus 9000
- module QSFP-100G-CWDM4 trên các link fabric
- NAPALM với driver nxos_ssh, transport SSH, chưa bật NX-API
Với một module 100G bốn lane, getter chỉ trả về đúng một channel:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}Bản thân switch rõ ràng có đủ dữ liệu - show interface transceiver details in ra Rx power, Tx power và bias current cho cả bốn lane - nên có vẻ đây là lỗi parser chứ không phải do platform.
Những gì đã kiểm tra:
- kết quả giống nhau trên mọi port QSFP-100G-CWDM4 tôi poll, nên không phải một module cá biệt
- port SFP+ trả về đúng, điều này hợp lý vì chỉ có một lane để báo cáo
- đọc qua phần parsing optics của driver thì có vẻ chỉ khối DOM đầu tiên từng được lấy
Có ai thực sự đang thu thập DOM theo từng lane qua NAPALM trên NX-OS không, hay cuối cùng ai cũng phải tự scrape output của switch?
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
Chính xác là phiên bản NAPALM nào, và các leaf đó đang chạy train NX-OS nào? Code xử lý optics trong nxos_ssh đã được viết lại hơn một lần, và output transceiver trên switch cũng không có format giống hệt nhau giữa các train, nên cả hai yếu tố đều quan trọng trước khi ai đó gọi đây là bug.
Một việc đáng làm trước khi tự viết parser riêng: gọi get_optics() trên một port SFP+ rồi đặt cấu trúc đó cạnh cấu trúc của CWDM4. Nếu cả hai trả về cùng một khung mà chỉ khác giá trị, driver đang đọc text đúng và chỉ đơn giản là dừng lại sau khối đầu tiên khớp được. Nếu hình dạng khác nhau, nó chưa bao giờ chạm tới phần per-lane trên port QSFP cả. Đó là hai hướng sửa khác nhau, và output của SFP+ là cách rẻ nhất để phân biệt chúng.
Cả hai collector đều dùng bản release hiện tại lấy từ PyPI, và leaf với spine cùng nằm trên một train NX-OS, nên trỏ vào đâu tôi cũng nhận về kết quả giống nhau, không phải do một máy cá biệt.
Đã làm phép so sánh SFP+ như bạn yêu cầu. Cùng một khung trong cả hai trường hợp: physical_channels.channel với đúng một phần tử ở index 0, cả ba giá trị đều được điền đầy đủ. Đúng với module một lane, sai với CWDM4. Vậy nên parser không phải là không tìm thấy phần per-lane của output, nó khớp một khối, điền vào rồi dừng lại ở đó. Đúng như những gì tôi thấy khi đọc code, chỉ là muốn có ai đó xác nhận là mình không đọc sai.
Đây là lỗ hổng trong driver chứ không phải do phía bạn. Có một pull request đang mở cho nxos_ssh viết lại phần parsing optics: mỗi lane trả về như một phần tử riêng dưới physical_channels.channel thay vì dừng ở index 0, và mỗi phần tử mang theo Rx level, Tx level và laser bias current riêng. Bộ fixture đi kèm được xây trên một module QSFP-100G-CWDM4 bốn lane, nên nó được viết đúng theo module của bạn. Tôi mới chỉ chạy nó trên một máy lab, nên coi đây là thứ đáng thử chứ chưa phải khuyến nghị cho collector production.
Trong lúc chờ nó vào một bản release có thể cài đặt, cách thực dụng là bỏ qua getter cho port 100G và tự parse
show interface transceiver details, rồi đẩy mỗi lane vào giám sát như một series riêng. Tốn thêm chút code phải tự quản lý, nhưng bạn sẽ không còn vứt bỏ ba phần tư tín hiệu nữa.Dù đi theo hướng nào, cũng nên cảnh báo theo từng lane. Một lane xuống cấp trên CWDM4 sẽ kéo lùi cả link mà chẳng bao giờ lộ ra nếu bạn chỉ theo dõi lane 1.
Khả năng nhìn thấy theo từng lane quan trọng trên Nexus hơn người ta tưởng.
Chúng tôi từng vấp phải một lỗi Cloud Scale trên Nexus 9000 với module QSFP-100G-SR4-S tách thành 4x25G. Chỉ cần một trong bốn port 25G, ba port còn lại để tắt, và đúng port cần dùng thì không bao giờ lên link. Cách thoát ra là bật cả nhóm lên trước -
no shutdowntrên cả bốn sub-interface - để lane 1 ổn định, rồi tắt lại ba port dự phòng. Cũng nên giữ FEC giống nhau trên cả nhóm trong lúc đó; một setting lệch trên một lane sẽ không lịch sự ở yên trên lane đó đâu.Ý là, nếu dashboard chỉ có lane 1 thì bạn gần như mù trước phần lớn những gì một port 100G đang làm. Bỏ công parse thêm là xứng đáng.