LibreNMSがZTE ZXA10 C300/C320 OLTで光センサーを検出できずONUインターフェースも一切ない
小さなISPでアクセス層を担当していて、うちの2台のGPON OLTを、他の機器と同じようにモニタリングに出したいと思っています。欲しいものは特に変わったものではなく、シャーシの温度、CPUとRAMの負荷、ポートごとのカウンタ、そして自分が本当に気にしている部分、光の状態です。つまりOLTポート自体のRx/Tx dBmと、加入者ONUごとのRx値です。
- ZTE ZXA10 C300とZXA10 C320、SNMP v2c読み取り専用コミュニティ
- LibreNMS 25.8.0-dev、同じサイトでセルフホストのポーラー
- 両方のOLTにSFPとSFP+のアップリンク
初期状態では光関連は何も出てきません:
# 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::ifDescrすでにやったこと:
- SNMP自体は健全であることを確認、アップリンクとPONポートのトラフィックグラフは正しく描画される
- 変更のたびにデバイスを再ディスカバリし、標準のセンサーテーブルを確認したが、すべて空
- C320ファミリー向けの既製テンプレートを探したが、GPONポートやONUの光情報をカバーするものは見つからなかった
この手の機器は実際どのツリーにそれを公開しているのでしょうか、自分のポート分もONUごとの分も含めて。そしてアップグレードを生き延びる形でLibreNMSに組み込んだ人はいるのでしょうか。
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
手短に言うと、これらのOLTで光関連のものは標準MIBには一切なく、すべてZTEの private enterprise tree 3902の中にあります。
簡単なほうから始めましょう。シャーシ温度は .1.3.6.1.4.1.3902.1015.2.1.3.2 です。これ用のPHPセンサー定義が出回っていて、しきい値は65/55/15/5度です。それを鵜呑みにせず、アラートを配線する前に自分のシャーシが実際にどの温度で動いているか照らし合わせてください。
本当に手間がかかるのはONU側です。IF-MIBはOLT自身のインターフェースしか記述しておらず、1つのPONポートは最大128台のONUを収容できるので、インターフェースとして吊るせるものがありません。みんな結局やっているのは、shelf、slot、port、ONU番号を1つの整数に詰め込んでインデックスを組み立てることです:
そしてそれをONUツリーに対して使います:
そのツリーにはONUのRXレベルとCounter64のバイトカウンタが入っているので、ONUごとのトラフィックも同じwalkから取れます。
2つ注意点があります。これは利用者たちが積み重ねたパッチの山で、upstreamに取り込まれたものは何もないので、アップデート後に再適用できるようどこかに控えを保管しておいてください。そして300台を超えるONUを抱えるOLTでは、センサー数がだいたい10倍になり、ポーラーがそれに気づきます。その規模になったら、ONUのデータは普通のインターフェースではなくComponentsに入れてください。
誰かがテンプレートを書く前に、2つ質問です。
標準MIB以外の何かをwalkしてみましたか。ZXA10ファミリーでは、面白いデータはIF-MIBには入っていないので、センサーテーブルが空なのはバグというより想定どおりの結果です。次のコマンドの返り値を貼ってください。
それで値が返ってくれば脈ありで、残りはインデックスの算数だけです。
2つ目です。PONポートあたり何台のONUがあり、シャーシ全体では何台になりますか。この数字次第で、普通のセンサーにするかもっと軽いものにするかが決まり、アドバイスもかなり変わってきます。
それが答えでした。3902を手でwalkするとすぐに値が返ってきて、配線してみたところ、今では温度、CPU、メモリ、帯域、エラーカウンタ、そしてOLTポートとONUの両方のRX dBmが取れています。
規模についての警告も机上の空論ではありませんでした。C300は300台を優に超えるONUを抱えていて、すべてのONUをセンサー化した途端、そのデバイスのポーラー実行時間が目に見えて伸びました。なのでONUごとのデータはComponentsに移し、OLTの光関連だけを普通のセンサーとして残すことにしています。それでも解決したというよりは部分的にできたという言い方をしたいところです。動いてはいますが自分独自のパッチ一式であって、C320向けに既製で使えるものは何もありません。
ベンダーは違いますが、自分の側でも同じ教訓があります。機器が数値を返してくれるようになったら、それを元にアラートを組む前に対向側と突き合わせてください。
EX4550と2台のEX3300の間で、非Juniper製SFP+を使った20kmリンクが2本ありました。両方のリンクともトラフィックは通っていましたが、EX4550側で
show interfaces diagnostics opticsを実行すると次のように表示されました。一方、同じファイバーのEX3300側は 0.1196 mW / -9.22 dBm と報告していました。これはEX4550側のJunosのスケーリング不具合で、PR1007055として、12.3R8で修正されています。アップグレードするまでは、EX4550側の値は飾りとして扱い、対向側の値を使っていました。
伝聞なので軽く受け止めてほしいのですが、ICX 7450とICX 7550では、Ruckus供給の型番33211-100と33210-100について光モニタリングが空欄のままになる一方、同じシャーシ内のBrocadeコードの同等品は正常に報告するとのことで、FI-264785として追跡されており、修正はだいたい08.0.95jビルド前後を見込んでいるそうです。モジュールを挿し直し始める前に
show opticを実行する価値はあります。