Interface Error / Collision

このページで学ぶこと

• Collision Counter
• Late Collision
• CRC / FCS Error
• Input Errors
• Frame Error
• Runts / Giants
• Counter Trend Analysis

1. カウンターは「値」だけでなく「増え方」を見る

インターフェースカウンターの多くは累積値です。

たとえば、

100 input errors
80 CRC

と表示されていたとしても、その80件のCRCが、

• 直近1分で発生した
• 1か月前に発生した
• カウンターを最後にクリアしてから少しずつ蓄積した

のどれなのかで意味が大きく変わります。

そのためカウンターを見るときは、

カウンターの種類
      ＋
現在値
      ＋
一定時間での増加量

を確認します。

たとえば、

時刻 10:00
CRC = 100

時刻 10:10
CRC = 100

なら、この10分間ではCRCは増えていません。

一方、

時刻 10:00
CRC = 100

時刻 10:10
CRC = 180

なら、現在もCRCエラーが継続して発生していると判断できます。

2. 「大きな累積値」と「現在進行中の障害」を区別する

次の状態を考えます。

CRC Errors = 10,000

一見すると重大な障害に見えます。

しかし、

Last clearing of "show interface" counters
2 years ago

であり、さらに10分間監視しても、

CRC
10,000 → 10,000

のままなら、10,000という累積値だけでは現在も障害が継続しているとは判断できません。

逆に、

CRC
5 → 25 → 70

と短時間で継続増加しているなら、現在の通信と関連する可能性が高くなります。

したがって、

カウンターが大きい
        ↓
即座に障害確定

ではありません。

基本は、

現在値を確認
      ↓
基準時点を取る
      ↓
一定時間後に再確認
      ↓
増加しているカウンターを特定

です。

3. show interfacesでカウンターを確認する

Cisco IOSでは、代表的に、

show interfaces

を使用してインターフェースの状態やカウンターを確認できます。

例：

Switch# show interfaces GigabitEthernet1/0/1

GigabitEthernet1/0/1 is up, line protocol is up
  Full-duplex, 1000Mb/s

  125 input errors, 120 CRC, 0 frame, 0 overrun, 0 ignored
  0 output errors, 42 collisions, 18 late collision

この出力を見たとき、

input errors   = 125
CRC            = 120
frame          = 0
collisions     = 42
late collision = 18

と読み取れます。

しかし、この時点ではまだ原因を断定しません。

次に、

どのカウンターが増えているか

を確認します。

4. コリジョンカウンター

コリジョンは、Ethernet フレームの送信中に他の送信信号と衝突したことを表します。

半二重 Ethernetでは、複数機器が同じ伝送媒体を共有して送信するため、コリジョンが発生する可能性があります。

したがって、

半二重
＋
少数のコリジョン

だけで、

障害確定

とは判断しません。

たとえば、

半二重
トラフィック負荷が高い
コリジョンが少し増加

という状況なら、半二重 Ethernetの動作として発生している可能性があります。

5. 全二重でコリジョンが増える場合

全二重では、送信と受信を同時に行えます。

ポイントツーポイントの全二重 Ethernetでは、通常コリジョンは発生しません。

したがって、

全二重
      ＋
コリジョンカウンターが継続増加

なら、正常な全二重リンクとしては不自然です。

この場合は、

ローカルデュプレックス
リモートデュプレックス
実際のリンク状態
物理条件

などを確認します。

Page003で扱った、

Full
vs
Half

というデュプレックス不一致も候補の1つです。

ただしコリジョンカウンターだけで、

デュプレックス不一致確定

とは判断しません。

6. コリジョンは「1件でも異常」ではない

半二重環境ではコリジョン自体がEthernetの動作として発生し得ます。

そのため、

コリジョン = 1

を見ただけで、

ケーブル故障

や、

デュプレックス不一致

と判断してはいけません。

見るべきなのは、

• 半二重 / 全二重
• トラフィック量
• コリジョンの増加傾向
• レイトコリジョンの有無
• 他のエラーカウンター

です。

特に、

半二重
＋
負荷上昇時
＋
通常コリジョン

と、

全二重
＋
コリジョン継続増加

では意味が異なります。

7. レイトコリジョン

レイトコリジョンは、フレーム送信開始後、通常のコリジョン検出範囲を超えた後に検出されたコリジョンです。

従来型Ethernetでは、最初の512 bit-timesを超えてから検出されたコリジョンをレイトコリジョンとして扱います。

これは正常なコリジョンとは異なり、適切に設計・設定されたEthernetリンクでは通常期待されないカウンターです。

レイトコリジョンが継続して増えているなら、原因候補として、

• デュプレックス不一致
• ケーブル / Segmentの物理条件
• NICやインターフェース側の問題

などを調査します。

ケーブル距離そのものの判断はPage005で扱います。

8. デュプレックス不一致とレイトコリジョン

Page003で、

側 A
全二重

側 B
半二重

というデュプレックス不一致を扱いました。

この状態では半二重側が送信している最中でも、全二重側は送信可能だと判断して送信することがあります。

その結果、半二重側でレイトコリジョンが観測される場合があります。

したがって、

レイトコリジョン継続増加
      ↓
両端Duplex確認

は有効な診断手順です。

ただし、

レイトコリジョン
= デュプレックス不一致

と一対一で決めつけません。

物理条件など、他の原因でも発生する可能性があります。

9. CRC / FCSエラー

Ethernet フレームには、フレームが通信途中で破損していないか確認するためのFCS（Frame Check Sequence）があります。

送信側はフレーム内容を基に検査値を作成し、受信側も受信データから検査値を計算します。

正常なら、

送信側のFCS
=
受信側で計算した値

になります。

一方、

送信側のFCS
≠
受信側で計算した値

なら、受信フレームが正常ではないと判断できます。

Ciscoのインターフェース 出力では、この種のエラーがCRC / FCS関連カウンターとして表示されます。

10. CRCエラーから分かること

CRC / FCSエラーが継続増加している場合、フレームが正常な状態で受信されていないということが分かります。

ただし、

CRC増加
      ↓
ケーブル断線確定

とはなりません。

CRC / FCSエラーの原因候補には、

• ケーブルやコネクタなどの物理問題
• 電磁的なノイズ
• NIC / インターフェース問題
• デュプレックス不一致
• その他の伝送問題

などがあります。

そのためCRCは、物理・Ethernet側に問題がある可能性を示す重要な確認情報として使います。

11. CRCだけで原因を決めない

次のカウンターを考えます。

1000 input errors
950 CRC

CRCが非常に多いため、物理 / Ethernet側の問題を強く疑えます。

しかし、この数字だけでは、

ケーブルが壊れている

のか、

コネクタに問題がある

のか、

デュプレックス不一致

なのかまでは判断できません。

したがって、

CRC増加を確認
      ↓
物理 / Ethernet問題を疑う
      ↓
他のカウンター・Duplex・ケーブル条件と比較
      ↓
原因候補を絞る

と進めます。

12. 入力エラー

show interfacesには、

input errors

というカウンターがあります。

Cisco IOSでは入力エラーは、受信時に発生した複数種類のエラーをまとめて示すカウンターとして扱われます。

関連するカウンターには、たとえば、

• Runts
• Giants
• no buffer
• CRC
• フレーム
• オーバーラン
• ignored（無視された受信）

などがあります。

したがって、

入力エラー = 500

という値だけでは、どの種類の異常が中心なのか分かりません。

13. 入力エラーでは内訳を見る

次の出力を考えます。

500 input errors, 480 CRC, 0 frame, 0 overrun, 20 ignored

この場合、

入力エラー = 500

だけを見るのではなく、

CRC     = 480
ignored = 20

という内訳を確認します。

一方、

500 input errors, 0 CRC, 450 frame, 0 overrun, 50 ignored

なら、同じ500 入力エラーでも状況が異なります。

つまり、

入力エラー
      ↓
関連カウンターの内訳確認

が基本です。

なお、1つの受信フレームが複数のエラー条件へ該当する場合などがあるため、入力エラーと個別カウンターを単純に足し算・引き算して必ず一致すると考えないようにします。

14. フレームエラー

Ciscoのshow interfacesで表示されるframe カウンターは、Ethernet フレームが正しく受信されなかったことを示すカウンターの1つです。

従来のCisco IOSの定義では、CRCエラーを持ち、かつOctet境界が正しくないフレームなどのアライメントエラー（Alignment Error）に関連します。

したがって、

frame カウンター継続増加

は、

• コリジョン関連
• ケーブル / インターフェースなどの物理問題
• NIC問題
• デュプレックス不一致

などを調査する材料になります。

ただしプラットフォームによってカウンター名称や集計方法に違いがあるため、フレームエラーという名称だけから原因を一意に決めないことが重要です。

15. CRCとフレームエラーを比較する

CRC / FCSエラーとフレームエラーは似ていますが、完全に同じ意味ではありません。

たとえば、

input errors 312
CRC          180
frame         42

なら、受信フレームに複数種類の異常が発生していることが分かります。

ここで、

CRCがあるからケーブル確定

や、

frameがあるからデュプレックス不一致確定

とは判断しません。

複数カウンターの組み合わせとして評価します。

16. Runts

Runtは、Ethernetの最小フレームサイズより小さい受信フレームに関連するカウンターです。

一般的なEthernetの最小フレームサイズは64 Bytesです。

Cisco Catalystの代表的なshow interfaces定義では、64 Bytes未満で、かつbad CRCを持つ受信フレームがruntsとして計上されます。

したがって、

フレームサイズ < 64 Bytes
＋
CRC異常

という状態が代表的なRuntです。

ただし、プラットフォームやソフトウェアによってカウンターの定義・集計方法が異なる場合があります。

そのため、

小さいフレーム
= 必ずRunt カウンター

とすべての機種で固定的に考えないことも重要です。

Runtsが継続増加している場合は、

• コリジョン
• NIC / インターフェース異常
• フレーム生成側の問題
• その他のEthernet物理問題

などを確認します。

特に共有型の半二重 Ethernetでは、コリジョンによってRuntが発生することがあります。

一方、現在のスイッチ型EthernetでRuntsが継続増加しているなら、正常な状態として無視せず追加調査します。

17. Giants

Giantは、インターフェースが想定する最大フレームサイズを超えたフレームに関連するカウンターです。

ただしここでは、

1518 Bytesを超えたら
すべて必ず異常

と単純に覚えてはいけません。

Ethernetでは、

• VLANタグ
• Jumbo フレーム
• プラットフォームのカウンター定義

などによって扱いが変わります。

Ciscoの一部Catalystではgiants カウンターが、最大フレームサイズを超え、さらにFCSエラーを持つフレームとして扱われる場合もあります。

そのためPage004では、

Giants継続増加
      ↓
フレームサイズ
NIC / インターフェース
物理リンク
プラットフォームのカウンター定義

を確認する、と理解します。

18. Runts / Giantsはサイズだけで原因を断定しない

次の状態を考えます。

runts  = 200
giants = 80

この値から、

ケーブル断線

と直接判断することはできません。

Runts / Giantsは、異常なフレームサイズや受信状態を示す確認情報です。

そのため、

Runts / Giants増加
      ↓
フレームサイズやCRC状態を確認
      ↓
NIC / インターフェース / 物理リンクを調査

と進めます。

19. カウンター同士の関係を整理する

Page004で扱う主なカウンターを整理します。

この表は、カウンター → 原因を一対一で暗記する表ではありません。

重要なのは、

カウンター
      ↓
関連する原因候補
      ↓
他の確認情報と照合

という使い方です。

20. カウンターの増加傾向分析

カウンター診断で最も重要なのが増加傾向です。

たとえば、

10:00
CRC = 20

10:05
CRC = 20

10:10
CRC = 20

なら、観測中にCRCは増えていません。

一方、

10:00
CRC = 20

10:05
CRC = 60

10:10
CRC = 130

なら、現在進行中のエラーとして優先して調査します。

同じ考え方は、

• コリジョン
• レイトコリジョン
• 入力エラー
• フレーム
• Runts
• Giants

にも使えます。

21. トラフィック量も考慮する

カウンター増加量を見るときは、可能であればトラフィック量も考慮します。

たとえば、

1時間でCRC 1件増加
トラフィックは非常に大量

と、

1分でCRC 500件増加
トラフィックは少ない

では、後者の方が異常度は高いと考えられます。

したがって、

カウンター値だけ

ではなく、

増加速度
＋
トラフィック状況

も診断材料になります。

Page004では厳密なエラー率計算までは要求しませんが、カウンターをトラフィック状況から切り離して評価しないことが重要です。

22. Last clearingを確認する

show interfacesではプラットフォームによって、

Last clearing of "show interface" counters

のような情報を確認できます。

これによって、現在のカウンターがどの程度の期間に蓄積したものかを判断できます。

たとえば、

CRC = 500
Last clearing = 00:05:00

と、

CRC = 500
Last clearing = 1 year ago

では意味がまったく異なります。

カウンターの増加傾向分析では、

いつから蓄積したカウンターか

も確認します。

23. ケース1 ― 全二重でコリジョン増加

インターフェース
全二重

10:00
collisions = 20

10:10
collisions = 80

全二重ではコリジョンは通常期待されません。

したがって、

両端Duplex
      ↓
インターフェース状態
      ↓
物理条件

を追加確認します。

Page003で扱ったデュプレックス不一致も原因候補です。

24. ケース2 ― レイトコリジョン増加

10:00
late collision = 0

10:05
late collision = 15

10:10
late collision = 40

レイトコリジョンが現在も増えています。

この場合、

デュプレックス状態
物理条件
NIC / インターフェース

などを確認します。

ここで、

レイトコリジョンがある
      ↓
必ず距離超過

とは判断しません。

距離の詳細判断はPage005へ残します。

25. ケース3 ― CRCだけが継続増加

10:00
input errors = 100
CRC          = 95

10:10
input errors = 300
CRC          = 295

入力エラーとCRCがほぼ同じ傾向で増えています。

この場合、受信フレームのFCS異常を中心に物理・Ethernet側を調査するという判断ができます。

ただし、

ケーブル
コネクタ
ノイズ
NIC
Duplex

など複数候補があるため、CRCだけで原因を固定しません。

26. ケース4 ― 入力エラーだけを見ると情報不足

input errors = 500

だけでは情報が足りません。

内訳を見ると、

500 input errors
0 CRC
420 frame
0 overrun
80 ignored

だったとします。

この場合、

入力エラーが500

という事実より、

frameが継続増加している

ことの方が、原因候補を絞るうえで重要です。

したがって、集約カウンター → 個別カウンターの順で掘り下げます。

27. ケース5 ― 過去のエラーで現在は正常

CRC = 10,000

しかし、

10分観測
10,000 → 10,000

です。

さらに現在、

リンクアップ
トラフィック正常
新規エラー増加なし

なら、10,000という累積値だけを理由に現在障害中と判断しません。

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

このように、

絶対値

よりも、

現在の増加傾向

が重要になる場合があります。

28. ケース6 ― 複数カウンターが同時に増加

次の出力を考えます。

Switch# show interfaces GigabitEthernet1/0/1

312 input errors
180 CRC
42 frame
25 runts
15 giants

さらに一定時間後、

520 input errors
310 CRC
80 frame
45 runts
25 giants

となりました。

複数の受信エラーカウンターが継続増加しています。

この場合、

コリジョンが0だから
物理層は正常

とは判断できません。

むしろ、

CRC
フレーム
Runts
Giants

という複数の確認情報から、NIC / ケーブル / インターフェース / フレームサイズなど、物理 / Ethernet側を追加確認するのが適切です。

29. 物理系カウンターとキューのドロップを混同しない

インターフェースには多くのカウンターがあります。

そのすべてがケーブル障害を表すわけではありません。

たとえば、

Total output drops

は、送信キューやオーバーサブスクリプション（Oversubscription）など、トラフィック処理側の問題で増えることがあります。

一方、

CRC
レイトコリジョン
フレームエラー
Runts

などは、インターフェース / ケーブル Issueを調べる際の重要な確認材料になります。

したがって、

カウンターが増えている
      ↓
全部ケーブル障害

とは考えません。

カウンターが何を数えているかを理解してから診断に使います。

30. カウンターから原因を直接断定しない

Page004で最も重要な原則です。

カウンターは、原因そのものではなく、原因候補を絞るための確認情報です。

たとえば、

CRC増加

から、

ケーブル障害確定

とは判断しません。

同様に、

レイトコリジョン増加

から、

デュプレックス不一致確定

とも判断しません。

正しい流れは、

異常カウンターを確認
        ↓
増加傾向を確認
        ↓
カウンターの意味から
原因候補を作る
        ↓
他の確認情報と照合する
        ↓
候補を絞る

です。

31. Page004の診断フロー

インターフェース エラーを調査するときは、次の順番で整理します。

インターフェース異常
      │
      ▼
show interfaces
      │
      ▼
異常カウンターを確認
      │
      ├─ コリジョン
      │      ↓
      │   デュプレックス状態を確認
      │
      ├─ レイトコリジョン
      │      ↓
      │   デュプレックス / 物理条件を確認
      │
      ├─ CRC / FCS
      │      ↓
      │   物理層 / Ethernet側を確認
      │
      ├─ 入力エラー
      │      ↓
      │   個別カウンターの内訳確認
      │
      └─ ラント / ジャイアント / フレームエラー
             ↓
          フレームサイズ / NIC /
          Interface / 物理リンクを確認
      │
      ▼
一定時間後に再確認
      │
      ▼
継続増加しているカウンターを特定
      │
      ▼
原因候補を絞る

Page004ではここまでです。

複数Pageの確認情報を組み合わせた最終的な総合診断はPage006で扱います。

32. よくある誤判断

「コリジョンが1件でもあれば異常」

誤りです。

半二重ではコリジョンが発生し得ます。

デュプレックス状態と増加傾向を確認します。

「全二重でもコリジョンは普通に発生する」

誤りです。

正常な全二重 ポイントツーポイント Ethernetではコリジョンは通常期待されません。

全二重でコリジョンが継続増加する場合は追加調査が必要です。

「レイトコリジョンなら必ずデュプレックス不一致」

誤りです。

デュプレックス不一致は重要な原因候補ですが、物理条件やNICなど他の原因もあります。

「CRCが増えたらケーブル断線」

誤りです。

CRC / FCSエラーは受信フレームの検査失敗を示しますが、ケーブル、コネクタ、ノイズ、NIC、デュプレックスなど複数の原因候補があります。

「入力エラーだけ見れば原因が分かる」

誤りです。

入力エラーは複数の受信エラーを含むため、CRC、frame、runts、no bufferなどの内訳を確認します。

「Runtsは小さいフレーム、Giantsは大きいフレームなので原因もすぐ分かる」

誤りです。

Ciscoの代表的なRunts定義では、最小フレームサイズ未満だけでなくbad CRCも条件になります。

また、Giantsもプラットフォームによってカウンター定義が異なります。

サイズだけから原因を断定しません。

「カウンター値が大きければ現在も障害中」

誤りです。

カウンターは累積値です。

現在も増加しているか確認します。

「カウンターが0なら物理層は完全に正常」

誤りです。

1種類のカウンターが0だからといって、他の物理問題をすべて除外できるわけではありません。

33. CCNAでの判断ポイント

問題文やshow interfaces 出力が提示されたら、まず次を確認します。

① Duplex
② コリジョン
③ レイトコリジョン
④ 入力エラー
⑤ CRC / FCS
⑥ フレーム
⑦ Runts / Giants
⑧ カウンターが増えているか

そして、

カウンター A = 非ゼロ

という一点だけではなく、

カウンター Aが継続増加
カウンター Bも同時増加
デュプレックス状態
物理条件

を組み合わせます。

特に、

Last clearing

や、

一定時間後のカウンター

が与えられた場合は、現在進行中のエラーかどうかを判断するための重要な情報です。

34. Page004で覚える診断パターン

パターンA

全二重
コリジョン継続増加

→ 異常として両端Duplexや物理条件を確認

パターンB

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

→ デュプレックス不一致や物理条件を確認

パターンC

CRC / FCS継続増加

→ 物理 / Ethernet側の複数原因候補を調査

パターンD

入力エラー増加

→ CRC / frame / runts / no buffer等の内訳を確認

パターンE

CRC = 10,000
しかし10分間増加なし

→ 累積値だけで現在障害中とは判断しない

パターンF

フレーム
Runts
Giants
が同時に継続増加

→ フレームサイズ / NIC / インターフェース / 物理リンクを追加確認

まとめ

インターフェースカウンターは、Ethernet障害を診断するための重要な確認材料です。

ただし、カウンターは原因を直接示すものではありません。

コリジョンは半二重では発生し得ますが、全二重で継続増加するなら異常を疑います。

レイトコリジョンはデュプレックス不一致や物理条件などを確認する手掛かりになります。

CRC / FCSエラーは受信フレームが正常なFCS検証を通らなかったことを示しますが、ケーブル、ノイズ、NIC、デュプレックスなど複数の原因候補があります。

入力エラーは集約的なカウンターとして扱われるため、runts、giants、no buffer、CRC、フレーム、オーバーラン、ignoredなどの関連カウンターを確認します。

Cisco Catalystの代表的な定義では、Runtsは64 Bytes未満かつbad CRCを持つ受信フレームとして計上されます。ただしカウンター定義はプラットフォームによって異なる場合があります。

Runts / Giants / フレームエラーも、フレームサイズや物理 / Ethernet側を調査するための確認情報です。

そして最も重要なのが、カウンターの増加傾向です。

Page004で身につける診断手順は、

show interfacesを確認
        ↓
異常カウンターを特定
        ↓
カウンターの意味を確認
        ↓
一定時間での増加傾向を確認
        ↓
複数カウンターを比較
        ↓
原因候補を絞る

です。

カウンターを見て原因を即断するのではなく、種類・増加傾向・他の確認情報を組み合わせる。

これがインターフェース エラー / コリジョン診断の基本です。