Aruba 2530-48Gペア、新設の200m OM4区間: J4858Cモジュールのセルフテストは正常なのにport 51がDown
少し前に2棟の建物間に200mのOM4バックボーンを敷設してもらっていて、それをすでに手元にある機材で開通させようとしています。両端とも2530で、モジュールもどちらもHPE純正パーツですが、リンクがどうしても上がりません。
- Aruba 2530-48Gが2台
- J4858C 1000SXが2個、各側のport 51
- 新設のOM4約200m、施工業者は良好と認定済み
- パッチパネルからスイッチまではDigitus DK-2533-01のOM2 LCジャンパー
show tech transceiversではそのポートについてこう出ます:
Port 51 Down Auto 1000FDx 1000SX multiすでにやったこと:
- 両方のスイッチでモジュールのセルフテストを実行、どちらも合格
- 両側で
interface 51 enable、変化なし、ポートはDownのまま - 2つのモジュールをスイッチ間で入れ替えたが、どちらの向きでも結果は同じ
- パネル側とスイッチ側の両方でジャンパーを再装着
2つの説の間で行き詰まっています: 両方のモジュールが箱から出した時点で不良品なのか、それともOM4トランクに挿したOM2ジャンパーが原因で殺しているのか。どちらの可能性が高く、どちらかを実際に証明するには次に何をテストすればいいでしょうか?
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
これ以上理屈をこねる前に、リンクを短くしてください。片方のスイッチをもう片方のところまで持っていき、両方のJ4858Cを挿して、1本のパッチコードだけでつないでください - ジャンパー1本、パネルなし、敷設済みファイバーなし。それでport 51がUpになれば、両方のモジュールと両方のスイッチポートを一気に潔白にしたことになり、残るのはその先です: 敷設済みファイバー、パネル、カプラ、終端です。
自分が担当したケースもそうやって解決しました。同じ2530-48Gのペア、同じJ4858C、port 51は敷設区間ではDownで、2個のモジュールを1本のコードで背中合わせにした途端Upになりました。その証拠があれば光モジュールを疑うのはやめますが、そのテストが何を買ってくれるのかははっきりさせておいてください。それはその区間を切り分けるだけで、それ以上ではありません。トレースのどの部分が悪いのか、パネルなのか、融着なのか、コネクタなのか、それとも単に違う対で通されているだけなのかは、誰かがパワーメータかOTDRを当てるまで未解決のままです。
ついでに、OM2説は脇に置いておくことをお勧めします。200mの1000SXでは、ジャンパーのグレードがあなたを止めている原因ではありませんし、そもそもOM3とOM4は相互互換です。グレードを混ぜるのは行儀が良くないので自分ならその作り方で新しい設備は組みませんが、それはあなたが追いかけている不具合の原因ではありません。
背中合わせのテストが通ったら、ファイバーを敷設した業者のところに戻って、ファイバーごとに損失と長さ付きの認定結果を書面で求めてください。彼ら自身のテストはリンクが良好だと宣言していたわけで、何かが見過ごされたか、あなたが通っているのとは別の対を測定したかのどちらかです - それが、戻ってやり直すよう伝えるときに立つべき足場になります。
まず最初に、どちらもDownと表示される2つの別の障害を切り分けてください。管理上ダウンしている、あるいは設定ミスのポートは一つの問題で、有効になっているのに受信側に光がまったく来ていないポートはまったく別の問題です。すでに
interface 51 enableを実行してもDownのままなので、レイヤー1の話であり設定は選択肢から外れます。絞り込みに役立つことが2つあります。2台のスイッチの間には物理的に何がありますか - パッチパネルはいくつ、スプライストレイはあるか、区間を届かせるために誰かが追加したカプラはあるか? それと業者の認定レポートは、ファイバーごとの実際の損失値付きのものを持っていますか、それとも「テストしたら良好だった」という口頭だけですか?
あとデュプレックスジャンパーが両方のパネルで同じ配線になっていないかも確認してください。両端でストレートだとTXがTXに入ってしまい、それはあなたが説明している状況とまさに一致します。
2台のスイッチを同じ部屋に持ち込めない場合のための同じテストの変形版です: モジュールを自分自身にループバックさせてください。同じデュプレックスモジュールのTXからRXへパッチコードをつなぎ、ハイパワーな部品であれば受信機を焼かないようインラインにアッテネータを入れます。ポートが上がれば、ホストポートとモジュールは電気的にも光学的にも問題なく、原因は対向側、ファイバー、あるいはペアリングにあります。
スイッチ間でリンクを拒否していたFIBOのSFP+を挿したMES3324Fでまさにこれをやりました - ループは即座に上がり、探す先がモジュールから区間へと移りました。一つ注意点があります: セルフループはBiDiモジュールでは無意味です、TXとRXが違う波長だからです。その場合は代わりにペアになったモジュール同士をループさせてください。
次のバッチのために、壁に近づける前にモジュールをテストしてください。EEPROMとDDM(ベンダー、パートナンバー、温度、TXとRXのパワー)を読み、パワーメータでTXパワーを測定し、アッテネータで感度を確認し、上に書いたようにループさせ、それから実際のターゲットレートでトラフィックを流してエラーカウンタを見てください - 手元にホストがあれば
ethtool -mとiperf3で最後の2つはカバーできます。本当に重要なリンクについては、NRZで1e-12を下回ることを確認できるだけの長さのPRBS-31 BERランがモジュールを証明するものです。単一の測定器ですべてを検証できるわけではありません。もう一つ、WISP勢から借りた習慣で、これに2回救われました: サービス投入前にすべてのモジュールをウォームリブート、コールドリブート、再装着にさらしてください。挿した時点ではリンクするのに電源サイクル後に死んで戻ってくる部品があります - 典型例がGLC-T-OEMで、再装着した後にしか上がりません - それと実際とは違うリンク状態を報告するものもあります。屋根の上で見つけるより作業台で見つける方がずっと安上がりです。