MRV OptiSwitch OS906: デマーケーションサイトでSFPのパーツナンバーとRXパワーを表示するCLIコマンドはどれか
客先への回線引き渡しはMRV OptiSwitchのデマーケーションボックスで行っていて、ほとんどはOS906ですが、古い構成にOS904とOS912も少し残っています。回線がdownまたはフラッピングしているというチケットが来たとき、誰かを現地に走らせる前にSSH経由で2つのことを知りたいです。ポートに実際に挿さっているモジュールが何か(施工業者が何を取り付けたか記録している人は誰もいません)、そして受信パワーです。それがわかれば光が自分たち側で止まっているのか先方側で止まっているのか言えます。
- 客先のデマーケーションポイントにMRV OptiSwitch OS906、一部の古いサイトにOS904とOS912
- 汎用の1G SFP、ベンダーは混在、現場のクルーが車に積んでいたもの次第
- 自社POPまでのシングルモード区間
ここまでにわかった唯一のことは、空のケージがはっきりと答えを返すということです:
Failed to get EEPROM Data, SFP is not inserted
つまり、モジュールが存在しないのか、挿さっているのに黙っているだけなのかは少なくとも区別できます。まだできないのは、挿さっているモジュールのベンダー、パーツナンバー、波長を表示することと、TX/RXパワーを読むことです。
試したこと:
show port配下のCLIヘルプを辿ってみたが、正しいサブコマンドを明らかに見つけそこねた- ラボのOS904に動作確認済みのモジュールを挿して出力が変わるか見てみたが、結果は同じで何も変わらなかった
OptiSwitchでEEPROMの内容とリアルタイムの光レベルを見せてくれるコマンドはどれでしょうか。CLIが既に答えを持っているはずのサイトに、パワーメーターを持った人を送り込みたくはありません。
Comments 5
2つのコマンドでカバーできて、望み通りにきれいに分かれています。片方はモジュールが自分自身について申告している内容、もう片方はリアルタイムの読み値です。
show port sfp-paramsはEEPROMのフィールドをダンプします。ベンダー、パーツナンバー、シリアル、波長、モジュールが申告する公称レート、ファイバ種別ごとに持っているリーチ値、それに識別子とコネクタのバイトです。これで施工業者が実際に何を取り付けたか、そしてそのリーチがそもそも区間に合っているかがわかります。show port sfp-diag <portnumber>がリアルタイムの半分です。両方の温度単位でのモジュール温度、供給電圧、送信側のバイアス電流(mA)、そして2つの光パワーで、それぞれdBmとmWの両方で表示されます。先方のオペレーターに伝えるべき数値は、dBmでのRX値です。まずsfp-paramsからやってください。ショートリーチの部品を見ているのかロングホールの部品を見ているのかわからないうちは、dBmの読み値だけでは大した意味がありません。
あなたが既に見つけた文字列は覚えておく価値があります。
Failed to get EEPROM Data, SFP is not insertedはケージが空であることを意味し、モジュールは挿さっているのに読めないのとは別の障害です。これを大量のデマーケーションボックスに対してスクリプト化するなら、そこがマッチさせるべき行です。これらのボックスにある残りのコマンド一式:
detailはコンフィグレーションとポートの状態を、2つのstatisticsコマンドはパケット・バイト・エラーのカウンタを返し、monitorの方がリアルタイム表示版です。そしてrateは秒数を指定するとその時間窓でのスループットを返します。
実際に証明しようとしているのはどちら側で、区間の反対側には何がありますか。両端ともOptiSwitchなら、それぞれでsfp-paramsを引いてベンダー、パーツナンバー、波長を直接比較でき、その比較は片端にロングリーチのモジュール、もう片端にショートリーチのモジュールが入っているという典型的なケースを捕まえてくれます。
反対側が客先か別のオペレーターのものなら、dBmの数値を伝える前に先方のモジュール詳細をチケットに入れてもらってください。そうしないと、そもそも光学的に成立するはずのなかったリンクについて1週間も言い争うことになります。そして出力が得られたら、空で返ってくるのは1ポートだけなのか、それともボックス上の全ポートなのか。それは別々の2つの問題です。
こちらの方向からたどり着いた人向けに言っておくと、Ciscoルーターでも同じ種類の問題があります。ISR 4451では、Catalystで慣れた
show interface transceiverという打ち方をしても何も出てきません。ルーターがその構文を受け付けないので、プラットフォームにDOMが全くないと結論づける人が出てきます。実際にはあります。代わりにhardware moduleのツリー経由で取得します:返ってくるのはモジュールの温度、送信側の供給電圧とバイアス電流、それから両方のパワー値です。ここで扱った死んだリンクでは、GLC-LH-SMDが送信側でおよそ-7.1dBm、受信側で-32.2dBmを示していて、これはぎりぎり成立する区間ではなく、完全な暗闇です。原因はルーターではなく先方かファイバ経路にあります。
私が目安にしているおおまかなスケールでは、建物内の短い区間はだいたい-3から-8dBmに収まり、ロングリーチは距離に応じて変わり、およそ-30dBmを下回ると何も届いていません。そしてファイバのせいにする前に、
show loggingの%TRANSCEIVER-3-NOT_SUPPORTED、あるいはshow interfaceでメディアタイプがunknownと表示されていないか確認してください。どちらであっても、それはルーターがモジュールを拒否したことを意味します。コレクションにもう1つプラットフォームを。Avaya VSP 7000では1つのコマンドで済みます:
スイッチがケージ内のモジュールから読み取った内容を表示し、トラブルシューティングの章ではその出力を使ってそのデバイスがサポート対象と見なされるかどうかを判断します。
厄介なのは、適合モジュールのリストがその章には載っていないことです。それは別のトランシーバ設置ドキュメントNN47202-302の方にあり、物理的な取り付け・取り外し手順と一緒になっています。モジュールがfailedまたはunsupportedと返ってきた場合、文書化されている答えはそのリストに載っている何かに交換することです。