nxos_ssh上のNAPALM get_opticsがQSFP-100G-CWDM4モジュールでレーン1のDOMしか返さない
Nexus 9000ファブリック数台向けに、ポート単位の光テレメトリを監視に組み込んでいます。収集はNAPALM経由で、使っているgetterはget_optics()です。
- Nexus 9000のleaf/spineペア
- ファブリックリンク上のQSFP-100G-CWDM4モジュール
- nxos_sshドライバのNAPALM、SSHトランスポート、NX-APIはまだ有効化していない
4レーンの100Gモジュールでは、このgetterはちょうど1チャンネル分しか返してきません:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}スイッチ自体には明らかにデータがあります。show interface transceiver detailsは4レーン全部のRx power、Tx power、bias currentを表示するので、プラットフォームというよりパーサー側の問題に見えます。
確認済みのこと:
- ポーリングしているQSFP-100G-CWDM4ポートはすべて同じ結果で、1つだけおかしいモジュールというわけではない
- SFP+ポートは正しく返ってきていて、報告すべきレーンが1つしかないことを考えれば辻褄が合う
- ドライバのオプティクスパース処理を読んでみたが、最初のDOMブロックしか拾っていないように見える
NX-OS上でNAPALM経由してレーン単位のDOMを実際に収集している人はいるのでしょうか、それとも結局みんなスイッチの出力を自分でスクレイピングしているのでしょうか。
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
正確にはNAPALMのバージョンはどれで、そのleafはどのNX-OSトレインに乗っていますか。nxos_sshのオプティクス周りのコードは何度か書き直されていますし、スイッチ側のトランシーバ出力もトレインごとにフォーマットが同じとは限らないので、バグと呼ぶ前にはどちらも押さえておく必要があります。
自前でパーサーを書く前にやっておく価値があることが1つあります。SFP+ポートの1つでget_optics()を呼んで、その構造をCWDM4のものと並べてみてください。両方とも骨格が同じで値だけ違うなら、ドライバはテキストの走査自体は問題なくできていて、最初に一致したブロックの後で単に諦めているだけです。形が違うなら、QSFPポートではそもそもレーン単位のセクションに到達すらしていません。この2つは修正の仕方が違うので、SFP+の出力を見るのが両者を見分ける一番安上がりな方法です。
両方のコレクタともPyPIの最新リリースで、leafとspineも同じNX-OSトレインに乗っているので、どこに向けても同じ結果が返ってきます。1台だけおかしいというわけではありません。
言われたSFP+の比較をやってみました。どちらも骨格は同じで、physical_channels.channelにindex 0の要素が1つだけあり、3つの値はすべて埋まっています。1レーンのモジュールとしては正しい答えですが、CWDM4としては間違った答えです。つまりパーサーは出力のレーン単位の部分を見つけられていないのではなく、1つのブロックに一致してそれを埋めた時点で止まっています。コードを読んだときに見えていたのもまさにそれで、自分の読み違いでないことを誰かに確認してほしかっただけです。
これはあなた側の問題ではなく、ドライバ側の欠落です。nxos_ssh向けにオプティクスのパース処理を書き直すオープンなプルリクエストがあって、そこではindex 0で走査が止まる代わりに各レーンがphysical_channels.channel配下の独立した要素として返り、それぞれの要素が自分自身のRxレベル、Txレベル、laser bias currentを持ちます。付属のフィクスチャは4レーンのQSFP-100G-CWDM4を元に作られているので、まさにあなたのモジュールに合わせて書かれています。私はラボの機材でしか動かしていないので、本番のコレクタへの推奨というより試す価値のあるものとして受け取ってください。
インストールできるリリースに載るまでの間、実用的なやり方は100Gポートについてはgetterを使わず
show interface transceiver detailsを自分でパースし、各レーンを監視に個別のシリーズとして送り込むことです。抱えるコードは少し増えますが、信号の4分の3を捨てずに済みます。どちらの道を選ぶにせよ、アラートはレーン単位にしてください。CWDM4で1レーンが劣化しても、見ているのがレーン1だけならまったく表面化しないまま、リンク全体を引きずり倒します。
レーン単位の可視性はNexusでは思われている以上に重要です。
QSFP-100G-SR4-Sを4x25Gに分割したNexus 9000で、Cloud Scale側の不具合に引っかかったことがあります。4つの25Gポートのうち欲しかったのは1つだけで、残り3つはshutしたままにしていたのですが、必要な方のポートが一向にリンクしませんでした。抜け出せたきっかけは、まずグループ全体を上げること、つまり4つのサブインターフェースそれぞれに
no shutdownをかけてレーン1を落ち着かせ、それから残り3つを改めてshutし直すことでした。作業中はグループ全体でFECも揃えておいてください。1レーンだけ設定が違っても、行儀よくそのレーンだけにとどまってはくれません。要は、ダッシュボードにレーン1しかないと、100Gポートがやっていることの大部分が見えていないということです。余分なパース処理を抱える価値はあります。