Nokia 7705でLibreNMSのディスカバリがColumn 'channels' cannot be nullで落ちてDOMを収集しない
LibreNMSでNokia 7705の収容ルータを何台かポーリングしていて、いつもの理由で光DOMも取りたいと思っていました。回線が劣化してユーザーが気づく前にそれを捕まえるためです。ところがこれらの機器ではディスカバリが最後まで終わりません。
- TiMOSで動くNokia 7705
- LibreNMS 26.3.1
- ポートには普通のシングルレーン1G SFP、ベンダー混在、一部は古い
- SNMPはそれ以外健全: インターフェース、CPU、メモリ、トラフィックは全部問題なくポーリングできる
ディスカバリは毎回ここで止まります:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'channels' cannot be null
結果はルータ全体でトランシーバのエントリも光センサーもゼロになります。悪いポートが1つあって残りは動く、ではなく、機器全体が空で返ってきます。
試したこと:
- その機器単体でディスカバリを再実行、同じ場所で同じエラー
- 機器を削除して再登録、作成はされるがディスカバリはまた同じ場所で落ちる
- 同じ環境の他ベンダーはトランシーバもDOMも正常にディスカバリできているので、こちら側のデータベースが壊れているようには見えない
これは既知のTiMOSディスカバリの問題でしょうか、そしてこれらのルータでトランシーバのディスカバリを丸ごと無効にする以外に何かできることはあるでしょうか?
Comments 3
既知の問題で、あなたのデータベースの問題ではありません。
TiMOSのディスカバリコードはTIMETRA-PORT-MIB::tmnxPortSFPNumLanesからレーン数を取ってきて、得られた値をそのまま
channelsカラムに入れますが、このカラムはNULLを受け付けません。よくある原因は古いシングルレーンの光モジュールで、エージェントがそのオブジェクトを一切埋めないため、ポートがinsertにnullを渡し、insertが失敗し、その失敗が機器全体のトランシーバディスカバリを道連れにします。だから癖のあるモジュール1つではなく、全ポート分が失われるのです。抜け道は2つあります。一番きれいなのはLibreNMSを進めることです。アップストリームで取り込まれた変更はLibreNMS/OS/Timos.php内でこの値をガードしていて、レーン数が欠落または空なら1チャンネルとして読み、それ以外は整数に強制します。今のリリースから動けないなら、同じガードを手動でそのファイルに入れてください。数行の変更ですが、そこにあることを忘れると次のアップデートで消えます。
何かパッチする前に、ルータ上でTIMETRA-PORT-MIB::tmnxPortSFPNumLanesをたどってみてください。何も返さないポートがinsertを殺している犯人で、そこにどの光モジュールが挿さっているか知っておく価値があります。
両方とも確認できました、ありがとうございます。
そのOIDをたどってみると、一番古い1G光モジュールのポートはレーン数について何も返さず、新しいものは全部1と答えます。つまりnullは説明の通り、引き継いだモジュールから来ています。
そのチェックが入ったビルドに移行したら、ディスカバリは7705全台で最後まで終わるようになり、トランシーバはそれぞれ1チャンネルとして表示され、光センサーもグラフ化されています。ルータ側は何も変えていませんし、除外したポートもありません。
ディスカバリが最後まで終わるようになった今、想定しておくべきことが2つあります。
Nokia機器のDDMは、モジュールEEPROM内のケーパビリティフラグでゲートされています。これは各シリーズ共通の社内方針で、7210 SASのインターフェースガイドに一番はっきり書かれています。プラットフォームはそのフラグを一度も立てていないモジュールについても平気で診断値を表示しますが、同じ段落でその数値を検証も確認もしていないとも書いています。あなたの機種とは違いますが理屈は同じです。サードパーティ光モジュールから出てくるもっともらしいRX/TXの数値は、校正が正しいことの証明にはなりません。
もう半分はモジュール自体の話です。GLC-SX-MMにはA2hページがないので、どんなポーラーが読んでも何もありません。GLC-SX-MMDにはあり、DがDiagnosticsの意味です。1つのグラフがずっと平らで空のままなら、ポーラーを疑う前にそこを確認してください。