Interface / Cable総合診断

このページで学ぶこと

• Interface State
• Administrative Shutdown
• Physical Link Failure
• Diagnostic Workflow
• 確認情報 Correlation
• Hypothesis Verification
• 根本原因 選択

1. 最初にインターフェース状態を見る

総合診断では、いきなりCRCやケーブル長を見るのではなく、まずインターフェース状態を確認します。

Cisco IOSでは代表的に、

show interfaces

を使用します。

インターフェース状態によって、最初に考えるべき原因候補が大きく変わります。

代表的な状態を整理すると、

2. administratively downを読む

次の出力を考えます。

GigabitEthernet0/1 is administratively down,
line protocol is down

この場合、最初の原因候補は明確です。

ケーブル
光トランシーバー
EMI
距離

より先に、

インターフェースが管理的にshutdownされている

ことを確認します。

つまり、

administratively down
        ↓
管理状態を確認

です。

ここで重要なのは、

リンクがDown
      ↓
必ずケーブル障害

と決めつけないことです。

インターフェース状態そのものが強い確認情報になります。

3. down / downを読む

次は、

GigabitEthernet0/1 is down,
line protocol is down

という状態です。

これは、

物理リンクが成立していない方向を優先して調査する

ための重要な確認情報です。

原因候補には、これまでのPageで扱った、

• ケーブル未接続
• ケーブル種別
• ピン / ペア
• 光ファイバ 極性
• トランシーバー
• 距離
• 信号レベル
• 対向インターフェース状態

などがあります。

ただし、

down / down
      ↓
ケーブル断線確定

ではありません。

状態は調査方向を狭める情報であり、根本原因そのものではありません。

4. スイッチのnotconnect

Catalyst スイッチでは、

show interfaces status

でポート状態を確認できます。

たとえば、

Port      Status       Vlan   Duplex  Speed
Gi1/0/1   notconnect   1      auto    auto

なら、そのポートでは現在リンクが成立していません。

ただし、

notconnect
      ↓
ケーブル不良確定

ではありません。

考えられる候補には、

ケーブル未接続
対向機器停止
対向ポート Down
ピン / ペア問題
光トランシーバー / 光ファイバ問題
信号不足

などがあります。

notconnectは、

物理リンクが成立していない

という確認情報として使います。

5. up / upでも障害は存在する

次の出力を考えます。

GigabitEthernet1/0/1 is up,
line protocol is up

これはインターフェースが利用可能な状態であることを示します。

しかし、

up / up
      ↓
すべて正常

ではありません。

たとえば、

• デュプレックス不一致（Duplex Mismatch）
• CRC増加
• 信号レベル悪化
• 規格外距離
• 断続的なケーブル問題

などでは、リンクがUpのまま通信品質だけが悪化する場合があります。

したがって、

up / up
      ↓
物理リンク成立
      ↓
速度 / デュプレックス
エラーカウンター
信号
距離
などへ調査を進める

と考えます。

6. インターフェース状態で最初の仮説空間を狭める

総合診断では、

すべての原因候補を毎回同じ順番で確認する必要はありません。

状態から優先順位をつけます。

administratively down
        ↓
管理状態を優先

down / down
        ↓
物理リンク成立条件を優先

up / up
        ↓
速度 / デュプレックス
カウンター
信号等を優先

これが最初の分岐です。

7. 診断は「確認情報 → 仮説 → 追加確認」で進める

診断の基本形は次の通りです。

確認情報
   ↓
原因候補を作る
   ↓
候補を区別できる
次の確認情報を選ぶ
   ↓
結果を確認
   ↓
候補を支持 / 否定
   ↓
根本原因を絞る

たとえば、

インターフェース down/down

という確認情報だけでは、候補が多すぎます。

そこで、

銅線か光ファイバか

を確認します。

銅線なら、

ピン / ペア
距離
ケーブル
対向ポート

などへ進めます。

光ファイバなら、

極性
トランシーバー
Rx パワー
対向Tx

などへ進めます。

つまり、

次の確認によって候補を減らせるか

を考えます。

8. 「情報を集めること」と「診断すること」は違う

トラブルシューティングでは、

show interfaces
show interfaces status
DOM
ケーブルテスター

など、多くの情報を取得できます。

しかし、情報を大量に集めただけでは診断とは言えません。

たとえば、

CRC = 500
Rx パワー = -5 dBm
1000 / Full
ケーブル = 80 m

という値を全部取得しても、

どの値が症状に関係しているか

を判断しなければ意味がありません。

診断では、

症状
      ↓
必要な確認情報を選択
      ↓
結果を解釈
      ↓
次の確認へ

という順序を使います。

9. 1つの確認情報だけで根本原因を決めない

Page001〜005でも繰り返し確認した原則ですが、Page006ではこれを統合して使います。

たとえば、

CRC増加

だけでは、

ケーブル障害
EMI
コネクタ
NIC
デュプレックス

など複数候補があります。

また、

Rx Power Low Alarm

だけでも、

距離
コネクタ
光ファイバ Bend
リモート Tx
光ファイバ経路

など複数候補があります。

したがって、

1つの確認情報
      ↓
1つの根本原因

という考え方は使いません。

正しくは、

複数の確認情報
        ↓
同じ原因候補を支持
        ↓
他候補と比較
        ↓
最も整合する根本原因

です。

10. 相関して考える

次のシナリオを考えます。

インターフェース
up / up

速度 / デュプレックス
100 / Full

リモート
100 / Half

CRC
増加

レイトコリジョン
増加

この場合、

CRC増加

だけを見るより、

ローカル  Full
リモート Half
レイトコリジョン増加

を一緒に見ることが重要です。

複数の確認情報が、

デュプレックス不一致

という同じ仮説と整合しています。

したがってデュプレックス不一致は有力な根本原因候補になります。

11. 確認情報の相関表

代表的な組み合わせを整理します。

この表は丸暗記用ではありません。

重要なのは、

複数の確認情報が同じ仮説を支持しているか

です。

12. リモート側を見る

Ethernet リンクは両端で成立します。

したがってローカル側だけを見て原因を決めてはいけません。

確認対象には、

• リモート インターフェース状態
• リモート 管理状態
• リモート 速度
• リモート デュプレックス
• リモート トランシーバー
• リモート Tx パワー
• ケーブル / 光ファイバの接続状態

などがあります。

たとえばローカル側が、

100 Mbps / Full

だったとしても、リモート側が、

100 Mbps / Half

ならデュプレックス不一致です。

ローカルだけなら見逃します。

13. ローカルとリモートの情報を対応させる

特に光ファイバでは方向を意識します。

機器 A                     機器 B

A Tx ──────────────────────→ B Rx
A Rx ←────────────────────── B Tx

したがって、

機器 A Tx

に対応する確認対象は、

機器 B Rx

です。

逆方向は、

機器 B Tx
        ↓
機器 A Rx

です。

Page005で扱ったこの方向関係を使い、

どちらの方向で異常が起きているか

を絞ります。

ここでは光 パワーの仕組みを再講義せず、診断材料として利用します。

14. 仮説を「支持する確認情報」を探す

原因候補を立てたら、

その原因が正しいなら何が観測されるはずか

を考えます。

たとえば、

仮説
デュプレックス不一致

なら、

確認したい情報は、

ローカルデュプレックス
リモートデュプレックス
コリジョン関連カウンター
通信性能

です。

もし、

ローカル 100 / Full
リモート 100 / Half

なら仮説を強く支持します。

15. 仮説を「否定する確認情報」も探す

良い診断では、

自分の仮説に都合の良い情報だけを集めません。

反対に、

この仮説が間違っているなら
何が確認できるか

も考えます。

たとえばデュプレックス不一致を疑ったとします。

しかし確認すると、

ローカル
1000 / Full

リモート
1000 / Full

で両端一致しています。

さらにコリジョン関連カウンターも増えていません。

この場合、

デュプレックス不一致仮説の優先度を下げる

必要があります。

16. 仮説に固執しない

トラブルシューティングでよくある失敗が、

最初にケーブルだと思った
        ↓
最後までケーブルだけを疑う

ことです。

診断では、確認結果によって仮説を変えます。

ケーブルを疑う
      ↓
ケーブルテスター正常
      ↓
ペア問題の優先度を下げる
      ↓
別の確認情報へ進む

という動きが必要です。

重要なのは、

最初の予想を当てることではなく、確認情報によって候補を更新すること

です。

17. 仮説を比較する

次の症状を考えます。

リンクアップ
通信が非常に遅い

候補として、

A. デュプレックス不一致
B. ケーブル ペア問題
C. 距離超過
D. 光 信号問題

などを考えたとします。

しかし使用伝送媒体が銅線なら、

D. 光 信号問題

は対象外です。

さらに両端が、

100 / Full
100 / Half

なら、

デュプレックス不一致を強く支持します。

このように、

確認情報によって候補を減らす

ことが診断です。

18. 原因候補の優先順位をつける

すべての候補を同じ可能性として扱う必要はありません。

たとえば、

up/up
100 / Full vs 100 / Half
レイトコリジョン継続増加

なら、

デュプレックス不一致

は強く支持されています。

一方、

光ファイバ 極性問題

は銅線リンクなら成立しません。

また、

管理停止（管理停止）

もインターフェースがup/upなら成立しません。

つまり、

支持される候補
矛盾する候補
対象外の候補

に分けられます。

19. 「原因候補」と「根本原因」を区別する

診断途中では、

ケーブル
デュプレックス
信号
距離

などは原因候補です。

そこから十分な確認情報が集まり、

他の候補より明確に整合すると、

根本原因

として特定できます。

たとえば、

症状
リンクアップだが低速

ローカル
100 / Full

リモート
100 / Half

レイトコリジョン
継続増加

なら、

複数の情報がデュプレックス不一致と一致しています。

この段階では、

デュプレックス不一致を最も妥当な根本原因として選択

できます。

20. ケース1 ― administratively down

症状：

PCから通信不能

確認：

Router# show interfaces GigabitEthernet0/0

GigabitEthernet0/0 is administratively down,
line protocol is down

この時点で、

光ファイバ Rx パワー
CRC
ケーブル Length

を先に調べる必要はありません。

最も直接的な確認情報は、

administratively down

です。

したがって、このシナリオで最も整合する原因は、

インターフェースが管理的にshutdownされていること

です。

21. ケース2 ― 物理リンクが成立しない

症状：

スイッチ ポートがリンクアップしない

確認：

show interfaces status

Gi1/0/10  notconnect

さらに、

対向機器
電源ON

対向ポート
有効

銅線ケーブル
最近再終端した

とします。

ここから、

管理停止

の優先度は下がります。

このリンクではStraight-through ケーブルを想定しているとします。

期待するテスター結果：

1 → 1
2 → 2
3 → 3
6 → 6

ところがケーブルテスターでは、

ピン 1 = OK
ピン 2 = OK
ピン 3 = Open
ピン 6 = OK

が確認されました。

これは正常なStraight-through / Crossoverの違いではなく、

必要な導体が断線している明確な異常

です。

この場合、

ケーブル 配線 / 導体不良

が最も整合する根本原因になります。

22. ケース3 ― デュプレックス不一致

症状：

リンクアップ
Ping成功
ファイル転送が遅い
負荷時に性能悪化

確認：

ローカル
100 Mbps / Full

リモート
100 Mbps / Half

さらに、

レイトコリジョン
継続増加

しています。

この場合、

速度
100 = 100

デュプレックス
Full ≠ Half

です。

症状、デュプレックス状態、カウンターが同じ仮説を支持しています。

したがって、

デュプレックス不一致

が最も整合する根本原因です。

23. ケース4 ― CRC増加とEMI

症状：

特定の銅線リンクだけ不安定

確認：

インターフェース
up/up

速度 / デュプレックス
両端一致

CRC
継続増加

ケーブル
UTP

ケーブル経路
大型モーター付近

さらにケーブルを別経路に一時的に通したところ、

CRC増加が止まった

とします。

この場合、

デュプレックス不一致

は両端一致によって優先度が下がります。

一方、

UTP
強い電磁環境
経路変更で症状消失

という複数の確認情報が同じ方向を示しています。

したがって、

ケーブル経路の電磁環境による影響

が最も整合する根本原因になります。

24. ケース5 ― 光ファイバ 信号問題

症状：

光ファイバ リンクがFlap

確認：

対応距離
10 km

実測距離
2 km

距離は仕様範囲内です。

DOM：

機器 A Tx
Threshold内

機器 B Rx
Low Alarm

反対方向：

機器 B Tx
Threshold内

機器 A Rx
Threshold内

この場合、

距離超過

は実距離から優先度が下がります。

また異常は、

A → B方向

に偏っています。

したがって、

A→B方向の光ファイバ経路 / 接続側の損失

を根本原因候補として強く絞ることができます。

このPageでは具体的な清掃や交換操作までは行いません。

25. ケース6 ― 対応距離超過

症状：

光ファイバ リンクが断続的にDown

仕様：

対応距離
10 km

実構成：

実測距離
13 km

さらに、

Rx パワー
Low Warning付近

だったとします。

この場合、

13 km > 10 km

という仕様不整合と、

受信信号低下

という確認情報が同じ方向を示しています。

したがって、

対応距離超過

が非常に有力な根本原因になります。

26. ケース7 ― 大きなCRC累積値に惑わされない

症状：

現在の通信は正常

確認：

CRC = 25,000

だけを見ると異常に見えます。

しかし、

10:00 CRC = 25,000
10:30 CRC = 25,000

で増加していません。

さらに、

速度 / デュプレックス一致
リンク安定
通信正常

です。

この場合、

CRCの大きな累積値だけを現在障害の根本原因として選んではいけません。

過去に発生したエラーが残っている可能性があります。

現在の症状と時間的に相関する確認情報を探します。

27. ケース8 ― up/upから物理的な問題を除外しない

症状：

インターフェース up/up
通信が断続的に遅くなる

ここで、

up/up
      ↓
物理的な問題ではない

と判断するのは誤りです。

確認すると、

CRC
継続増加

速度 / デュプレックス
両端一致

だったとします。

さらに銅線ケーブルが、

対応距離超過

なら、

物理リンクは一応成立していても、

物理条件が通信品質へ影響している

可能性があります。

つまりup/upから分かるのは、

現在リンクが成立している

ことであり、

物理条件がすべて正常

ということではありません。

28. ケース9 ― 複数の異常が存在する場合

実際のトラブルシューティングでは、必ずしも原因が1つとは限りません。

たとえば、

ケーブル 距離
仕様超過

デュプレックス
Full / Half不一致

が同時に存在する可能性もあります。

その場合、

どちらか1つだけ選ぶ

のではなく、

確認された独立した不整合を分けて扱う

必要があります。

ただし試験問題で、

最も可能性の高い原因

や、

根本原因として最も適切

と問われる場合には、

提示された症状を最も直接説明できる確認情報

を優先します。

29. 次に何を見るべきかを判断する

診断問題では、

「原因は何か」

だけではなく、

次に何を確認するべきか

が問われる場合があります。

たとえば、

光ファイバ リンク
down/down

までしか分かっていない場合、

まだ原因は特定できません。

この状態で有効なのは、

トランシーバー状態
光ファイバ接続
対向ポート
光 Rx

などです。

一方、

administratively down

と判明しているのに、

CRC カウンターを確認する

のは優先順位が低いです。

つまり、

現在の確認情報から最も候補を減らせる次の確認を選ぶ

ことが重要です。

30. 良い確認と弱い確認

次のシナリオです。

リンクアップ
通信が遅い

候補：

デュプレックス不一致

このとき、

ケーブルの色を見る

より、

ローカル / リモートデュプレックスを確認する

方が仮説を直接検証できます。

これを、

識別力の高い確認

として考えます。

診断では、

取得できる情報

ではなく、

候補を区別できる情報

を優先します。

31. show interfacesから次の確認を決める

次の出力を考えます。

GigabitEthernet1/0/1 is up,
line protocol is up

Full-duplex, 1000Mb/s

815 input errors
790 CRC
0 collisions
0 late collision

ここから読み取れるのは、

インターフェース状態
up/up

ローカル 速度 / デュプレックス
1000 / Full

コリジョン系
0

CRC
多数

です。

さらに観測してCRCが継続増加しているなら、

受信フレームの物理 / Ethernet側の異常

を優先して確認します。

一方、

レイトコリジョン = 0

だけを理由にデュプレックス不一致を完全否定するのではなく、

必要ならリモート デュプレックスも確認します。

診断は、

1つのカウンターを条件分岐の絶対値として使わない

ことが重要です。

32. 同じ症状でも原因は異なる

「通信が遅い」という症状だけでも、

デュプレックス不一致
CRCを伴う物理問題
信号レベル
距離

など、複数の候補があります。

同様に、

リンクダウン

でも、

管理停止（管理停止）
ケーブル
ピン配置
リモート ポート
光ファイバ 信号

などがあります。

したがって、

症状
      ↓
原因

を暗記してはいけません。

正しくは、

症状
      ↓
インターフェース状態
      ↓
確認情報
      ↓
仮説
      ↓
追加確認
      ↓
根本原因

です。

33. 反証を使う

診断を高速化するには、

原因を支持する確認情報だけでなく、原因を否定する確認情報

を利用します。

たとえば、

仮説
距離超過

に対して、

対応距離
10 km

実測
500 m

なら、

距離超過仮説は大きく弱まります。

また、

仮説
デュプレックス不一致

に対して、

ローカル  Full
リモート Full

なら、

デュプレックス不一致の優先度を下げます。

これによって不要な確認を減らせます。

34. 「正常な確認情報」も重要

トラブルシューティングでは異常値ばかりに注目しがちです。

しかし、

両端デュプレックス一致
距離仕様内
Rx パワー Threshold内
ケーブルテスター正常

という正常な確認情報も重要です。

正常結果は、

その原因候補を
完全または部分的に除外する

ために使えます。

診断とは、

異常を探すだけではなく、候補を消す作業

でもあります。

35. 根本原因を選択する基準

複数の候補が残った場合は、

次の観点で比較します。

① 症状を説明できるか
② インターフェース状態と整合するか
③ 複数の確認情報が支持しているか
④ 反証となる情報がないか
⑤ 他の候補より直接的か

たとえば、

リンクアップだが遅い
ローカル Full
リモート Half
レイトコリジョン増加

なら、

デュプレックス不一致は、

• 症状を説明できる
• 状態と矛盾しない
• デュプレックス不一致という直接情報がある
• カウンターも整合する

ため、非常に強い候補です。

36. 根本原因特定後はここで止める

Page006の責任は、

根本原因を診断するところまで

です。

たとえば、

根本原因
デュプレックス不一致

まで到達した後の、

具体的にどのコマンドで直すか

や、

修正後にどの手順で再確認するか

は、このPageの責任ではありません。

同様に、

ケーブル不良
      ↓
ケーブルを交換する

という具体的修復操作も本講義の到達点にはしません。

Objective 1.1で重要なのは、

与えられた確認情報から問題を診断できること

です。

37. Page001〜005をどう使うか

Page006では、前のPageを次のように利用します。

これらを再講義するのではありません。

Page006では、

どの情報を使うべきか
      ↓
どう組み合わせるか
      ↓
どの原因が最も整合するか

を判断します。

38. Page006の総合診断フロー

インターフェース / ケーブルの問題では、次の流れで考えます。

障害発生
   │
   ▼
インターフェース状態確認
   │
   ├─ administratively down
   │        ↓
   │   管理状態を原因候補として確認
   │
   ├─ down/down または notconnect
   │        ↓
   │   物理リンク成立条件を確認
   │        │
   │        ├─ ケーブル / ピン / ペア
   │        ├─ リモート ポート
   │        ├─ 光ファイバ / 光トランシーバー
   │        └─ 信号
   │
   └─ up/up
            ↓
       実動作パラメータ /
       エラー / 信号を確認
            │
            ├─ 速度 / デュプレックス
            ├─ カウンターの傾向
            ├─ 距離
            └─ 信号レベル
            │
            ▼
        原因候補を作る
            │
            ▼
     ローカル / リモートを照合
            │
            ▼
       支持情報を確認
            │
            ▼
       反証情報を確認
            │
            ▼
      最も整合する
        根本原因を特定

39. よくある誤判断

「リンクダウンならケーブル」

誤りです。

administratively downなら管理状態が直接的な確認情報です。

物理リンクダウンでも、ケーブル以外にリモート ポート、光トランシーバー、信号など複数候補があります。

「リンクアップなら物理 Layerは正常」

誤りです。

デュプレックス不一致、CRC、距離、信号などの問題ではリンクアップのまま障害が起こる可能性があります。

「CRCが多ければケーブルが根本原因」

誤りです。

CRCは物理・Ethernet側の問題を疑う確認情報ですが、原因は複数あります。

「レイトコリジョンがあればデュプレックス不一致確定」

誤りです。

デュプレックス不一致は有力候補ですが、他の確認情報と組み合わせて判断します。

「Rx Low Alarmなら距離超過」

誤りです。

光ファイバ経路 損失、リモート Txなども候補です。

「最初に考えた原因を最後まで追う」

誤りです。

反証となる確認情報が得られたら、その仮説の優先度を下げます。

「異常値だけが役に立つ」

誤りです。

正常な結果は原因候補を除外するために使えます。

「確認情報をたくさん集めれば診断できる」

必ずしもそうではありません。

重要なのは、

候補を区別できる確認情報を選ぶこと

です。

40. CCNAでの判断ポイント

Objective 1.1の統合問題では、個々の用語知識だけでなく、

どの確認情報を組み合わせれば原因を特定できるか

が重要です。

問題文を読んだら、

① インターフェース状態
② 伝送媒体
③ ローカル / リモート
④ 速度 / デュプレックス
⑤ エラーカウンター
⑥ 距離
⑦ 信号レベル

の順に情報を整理します。

その後、

どの仮説を支持するか
どの仮説を否定するか

を考えます。

41. Page006で覚える診断パターン

パターンA

administratively down

→ 管理的shutdownを最優先で判断

パターンB

notconnect
対向ポート有効
再終端直後
ケーブルテスターで必要ピンがOpen

→ ケーブル 配線 / 導体問題

パターンC

up/up
100 / Full
vs
100 / Half
レイトコリジョン増加

→ デュプレックス不一致

パターンD

up/up
デュプレックス一致
CRC継続増加
UTP
強いEMI環境

→ 銅線の物理条件を重点確認

パターンE

光ファイバ
到達距離超過
Rx Low

→ 距離 / 光 損失が強く整合

パターンF

光ファイバ
到達距離範囲内

A Tx正常
B Rx正常

B Tx正常
A Rx Low

→ B→A方向の光ファイバ経路を重点確認

パターンG

CRC累積値は大きい
しかし現在増加なし

→ 現在障害の原因と即断しない

パターンH

仮説：デュプレックス不一致

ローカル Full
リモート Full
コリジョン系増加なし

→ デュプレックス不一致仮説の優先度を下げる

まとめ

インターフェース / ケーブル総合診断では、

1つのカウンターや1つの症状だけから原因を決めません。

最初にインターフェース状態を確認します。

administratively down
down/down
up/up
notconnect

によって、優先する確認対象を変えます。

次にPage001〜005で得た、

• ケーブル種別
• ピン / ペア
• 速度 / デュプレックス
• エラーカウンター
• 距離
• 信号レベル

を必要に応じて利用します。

そして、

確認情報
      ↓
原因候補
      ↓
候補を区別する追加確認
      ↓
ローカル / リモート比較
      ↓
支持する情報
      ↓
反証となる情報
      ↓
最も整合する根本原因

という流れで診断します。

最も重要なのは、

「それっぽい原因」を選ぶのではなく、複数の確認情報で原因候補を支持し、反証によって他の候補を落とすこと

です。

Page006の到達点は、

インターフェース状態を起点にPage001〜005の確認情報を相関し、インターフェース / ケーブルの問題の最も妥当な根本原因を特定できること

です。