リンクが確立しない:チェックリスト
リンクアップしないポートは、光学関連のチケットとして最も多く、試行錯誤で解決されることが最も多いものでもあります。このチェックリストは、コストの低さと不具合を見つける頻度の高さの順に確認項目を並べたものです。順番どおりに実施してください。各ステップは、リンクを修復するか、原因のカテゴリーをまるごと除外するかのどちらかになります。
1. モジュールはそもそも認識されているか
- ホスト側:
show interfaces <if> transceiver(またはNOS での相当コマンド)。何も表示されない場合→モジュールが正しく装着されていない、ケージが無効化されている、あるいはホストが EEPROM を読み取れていません。 - しっかり挿し直します。別のポートで試します。CodingBox のベンチでモジュールを試します(Check transceiver)——ベンチでは読み取れるのにスイッチでは読み取れない場合、ポート側を疑ってください。
2. 受け入れられているか
- ステータスがunsupported / invalid / Mod_Inv / errdisable →ホストが識別情報を認識していません。この状態ではレーザーがホストによって無効化されていることが多く、故障していなくても対向側の Rx は −40 dBm を示します。
- 対処法:ホスト側でサードパーティ光モジュールを許可するか、識別情報をコーディングします→ベンダーロック。
3. 送信器はオンになっているか
- ポートは administratively up になっているか? レーザーをシャットダウンする機能(UDLD、ループ保護、「リンクが確立するまでレーザーオフ」など)はテストのために無効化されているか?
- SFP クラス:TX_DISABLE のピン/ビットがクリアされている(A2h バイト 110)、TX_FAULT なし。QSFP:バイト 86 の Tx disable がクリア。CMIS:モジュールステートが Ready、データパスが Activated(CMIS の問題)。
- ベンチでの確認:CodingBox の DDM でTx パワーを確認します——Tx が有効なのに −40 dBm であれば、モジュールは故障しています。
4. 対向側に光は届いているか
両端の Rx パワーを読み取ります(DDM のレベル)。
| Rx の値 | 意味 | 次の対応 |
|---|---|---|
| 両端とも −40 dBm(下限) | どちらの方向にも光が届いていない | 光ファイバーの断線、パッチコードの抜け、Tx/Rx の入れ違い、BiDi ペアの誤り |
| 片端だけ −40 dBm | 片方向だけ光がない | 対向側の Tx が故障または無効化、あるいはペアの片方の光ファイバーが断線 |
| 受信感度未満(例:PIN 受信器で −25 dBm) | 光はあるが弱すぎる | コネクターの汚れ、波長帯の誤り、バジェット超過→ステップ6 |
| 過入力を超過(> −3…0 dBm) | 光が強すぎる | 短距離区間に長距離用光モジュール→アッテネーターを使用 |
| 両端とも正常範囲内 | 光は問題ない | 問題は光学系にない→ステップ7 |
5. 両端は物理的に一致しているか
- 同じファイバー種別(シングルモードかマルチモードか)、同じ波長/BiDi ペア、CWDM モジュールが正しい合波器ポートに接続、APC と UPC の混在なし、MPO の極性とピン配置が正しい、Tx→Rx の入れ違いがない→物理的な不整合。
6. バジェットは収まっているか
- 経路上のすべてのコネクターを検査・清掃します(検査 → 清掃 → 再検査)。
- 設置時のベースラインと比較するか、バジェットを計算します:単位と換算、CWDM の合分波器とリンクバジェット。
- それでも低い場合→区間を OTDR で測定します(リンクフラッピング)。
7. 速度、FEC、モードは一致しているか
- 両端で同じ速度とFEC(25G以上/PAM4 では RS-FEC が必須)。DAC で AN とリンクトレーニングが有効。両方のホストポートでブレークアウトが設定されている。銅線 SFP の SGMII と 1000BASE-X の違い→速度とレート、FEC とリンクトレーニング。
- モジュール自身のレートコードが、意図したレートと一致している(バイト 12/コンプライアンスコード)。
8. モジュールは動作を許可されているか
- 電力クラスとポートの対応能力。モジュールが LowPwr のまま保持されていないか。過温度→電力と熱。
9. 交換による切り分け
- 各端で順番に動作確認済みのモジュールに交換します。
- ループバック:モジュール自身の Tx と Rx を短いパッチコードで接続します(長距離用モジュールの場合は先にアッテネーターをかませます)——ループバックでリンクアップすれば、モジュールとポートは正常であることが証明され、原因は設備側か対向側にあります。
- パッチコードを交換し、次にポートを交換します。
10. ログを読む
両端のインターフェースカウンターと syslog には、通常どの層の問題かが示されます。LOS、unsupported、FEC uncorrectable、speed mismatch、power exceeds などです。メッセージを症状索引と照合してください。
CodingBox では
ベンチでの2つの読み取りだけで、上記のほとんどは1分で片付きます。識別情報、波長、ファイバー種別/伝送距離、レートコード(ステップ2、5、7)には Check transceiver を、Tx/Rx パワーとフラグ(ステップ3〜4)には DDM を使います。ベンチでモジュールが健全であれば、モジュールを疑うのはやめて設備側を見直してください。
上記のステップは、モジュール挿入時にホスト自身が行う処理をなぞったものです。ピン、バイト、タイミングを伴うホスト側のシーケンスはホストが行うことにあります。
ポートの LED を正しく読み取る方法(アンバー、点滅、モードボタン)と、ポートを物理的に特定する方法:ポートの命名と LED。
モジュールが正常だと確認でき、設備側が疑わしい場合——発生頻度別の障害一覧、測定器の特徴、対処法:光ファイバー設備の障害。測定器そのものについては:試験と測定。