nxos_ssh'te NAPALM get_optics, QSFP-100G-CWDM4 modülleri için sadece lane 1 DOM döndürüyor
Birkaç Nexus 9000 fabric'i için port başına optik telemetriyi monitoring'e bağlıyorum. Toplama NAPALM üzerinden çalışıyor, ve dayandığım getter get_optics().
- Nexus 9000 leaf ve spine çiftleri
- fabric link'lerinde QSFP-100G-CWDM4 modülleri
- nxos_ssh sürücülü NAPALM, SSH transport, henüz NX-API etkin değil
Dört lane'li bir 100G modülde getter tam olarak tek bir kanal geri veriyor:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}Switch'in kendisinde veri açıkça var - show interface transceiver details dört lane'in tamamı için Rx power, Tx power ve bias current yazdırıyor - yani bu platformdan çok parser gibi görünüyor.
Kontrol ettiklerim:
- sorguladığım her QSFP-100G-CWDM4 portunda aynı sonuç, yani tek bir garip modül değil
- SFP+ portları doğru geri geliyor, ki raporlanacak tek bir lane varken bu mantıklı
- sürücünün optik parsing'ini baştan sona okudum ve sadece ilk DOM bloğunun hiç alınıyor gibi görünüyor
NX-OS'te NAPALM üzerinden gerçekten lane başına DOM toplayan var mı, yoksa herkes switch çıktısını kendisi mi kazıyor?
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
Tam olarak hangi NAPALM sürümü, ve o leaf'ler hangi NX-OS train'inde? nxos_ssh'teki optik kodu birden fazla kez yeniden çalışıldı, ve switch'teki transceiver çıktısı da train'ler arasında aynı şekilde biçimlendirilmiyor, yani kimse buna bug demeden önce iki yarı da önemli.
Kendi parser'ını yazmaya gitmeden önce yapmaya değer bir şey: SFP+ portlarından birinde get_optics()'i çağır ve o yapıyı CWDM4 olanın yanına koy. İkisi de aynı iskeletle geri gelip sadece değerler farklıysa, sürücü metni düzgün yürüyor ve eşleştiği ilk bloktan sonra basitçe vazgeçiyor. Şekilleri farklıysa, QSFP portlarında lane başına bölüme hiç ulaşmıyor demektir. Bunlar iki farklı düzeltme, ve SFP+ çıktısı ikisini ayırt etmenin en ucuz yolu.
Her iki toplayıcıda da PyPI'dan güncel sürüm, ve leaf'ler ile spine'lar aynı NX-OS train'inde oturuyor, yani nereye yöneltirsem yönelteyim aynı şeyi geri alıyorum - tek bir garip cihaz değil.
İstediğin SFP+ karşılaştırmasını yaptım. Her iki durumda da aynı iskelet: index 0'da tek bir eleman olan physical_channels.channel, üç değer de dolu. Tek lane'li bir modül için doğru cevap, CWDM4 için yanlış cevap. Yani parser, çıktının lane başına kısmını bulmakta başarısız olmuyor, bir bloğu eşleştiriyor, dolduruyor ve orada duruyor. Kodu okuduğumda görünen de tam olarak buydu, sadece birinin yanlış okumadığımı doğrulamasını istedim.
Bu, senin tarafındaki bir şeyden çok sürücüdeki bir boşluk. nxos_ssh'e karşı optik parsing'i yeniden yazan açık bir pull request var: yürüyüş index 0'da durmak yerine her lane physical_channels.channel altında kendi elemanı olarak geri geliyor, ve her eleman kendi Rx seviyesini, Tx seviyesini ve laser bias current'ını getiriyor. Onunla gelen fixture'lar dört lane'li bir QSFP-100G-CWDM4 üzerine kurulu, yani tam olarak senin modülüne karşı yazılmış. Onu sadece bir lab cihazında çalıştırdım, o yüzden bunu bir production toplayıcı için bir tavsiye değil, denenecek bir şey olarak al.
Yükleyebileceğin bir sürüme inene kadar, pragmatik yol 100G portları için getter'ı atlayıp
show interface transceiver details'i kendin parse etmek, sonra her lane'i kendi serisi olarak monitoring'e itmek. Sahiplenilecek biraz daha fazla kod, ama sinyalin dörtte üçünü çöpe atmayı bırakıyorsun.Hangi yolu seçersen seç, lane başına alarm kur. Bir CWDM4'te bozulan tek bir lane, sadece lane 1'i izliyorsan hiç görünmeden tüm linki aşağı çeker.
Lane başına görünürlük, Nexus'ta insanların beklediğinden daha önemli.
4x25G'ye bölünmüş bir QSFP-100G-SR4-S'li bir Nexus 9000'de bir Cloud Scale kusuruna takıldık. Dört 25G porttan sadece biri isteniyordu, diğer üçü kapalı kaldı, ve önemsediğimiz o hiç link vermedi. Bizi bundan kurtaran şey, önce tüm grubu ayağa kaldırmaktı - dört alt arayüzün her birinde
no shutdown- lane 1'in oturmasına izin verip sonra üç yedeği tekrar kapatmak. Oradayken grup genelinde FEC'i de aynı tut; tek bir lane'deki tuhaf bir ayar nazikçe o lane'de kalmıyor.Demek istediğim, dashboard'larında sadece lane 1 varken bir 100G portunun yaptığının çoğuna karşı körsün. Ekstra parsing sahiplenmeye değer.