show interfacesの見方｜CRC・late collisions・output dropsの読み方

show interfacesは長い出力ですが、最初から全行を読もうとしなくて大丈夫です。まず状態と成立速度を見て、その後に「どの数が、どの期間に増えたか」へ進みます。

CRCが132と表示されても、いま132回起きたとは限りません。図のSW1とSW2を一組として、累積値と増分を分ける読み方を説明します。表示や数え方は機種・OSによるため、対象製品の定義も合わせて確認します。

最初は、状態・速度・増えている数だけを見る

最初のis up, line protocol is upで現在の状態を読み、Full-duplex, 1000Mb/sで送受信方式と成立速度を見ます。細かなエラー数の前に、どの状態の口を調べているかを押さえます。

次はLast clearingです。エラーやパケットのカウンターは、起点から積み上げた数です。いつからの数字かを読まないと、過去の一度の異常を今の障害と取り違えることがあります。

用語の補足：カウンター・累積・増分とは？

カウンターは数を記録する欄です。累積は起点からの合計、増分は2回の取得値の差です。途中で再起動や値のクリアがあると、単純に引き算できないことがあります。

説明用の抜粋：
GigabitEthernet1/0/1 is up, line protocol is up
  MTU 1500 bytes, BW 1000000 Kbit/sec
  Full-duplex, 1000Mb/s
  Last clearing of "show interface" counters never
  5 minute input rate 1000000 bits/sec, 100 packets/sec
  5 minute output rate 2000000 bits/sec, 200 packets/sec
  2000000 packets input, 1500000000 bytes
  132 input errors, 132 CRC, 0 frame, 0 overrun, 0 ignored
  Total output drops: 20

inputはこの口で受信した側、outputは送信した側です。packetsは個数、bytesは量。5 minute input rateは5分平均の通信量で、累積のパケット数とは違います。下の表はこの違いを読む順に並べています。

BWは経路計算などで使う帯域情報で、今の実測通信量ではありません。成立速度の1000Mb/s、設定情報のBW、平均通信量のrateを分ければ、似た単位が並んでも役割を見失いません。

up/upと、設定で停止した状態を分ける

up/upは、インターフェースとline protocolがどちらもupという表示です。administratively downなら、設定で停止しています。復旧を考える前に、停止が意図されたものかを調べます。

down/downならリンク未成立などが候補になりますが、接続口の種類によって意味が変わります。downという一語から、ケーブルだけを原因に決めることはできません。

line protocolは、そのインターフェースで使う通信方式としての状態です。物理側がupでも、こちらがdownという組み合わせがあります。表示をそのまま保存し、対象の口の種類と仕様に沿って読みます。

全ポートから対象を探すときはshow interfaces status、一つの口の詳細にはshow interfaces 対象名を使えます。err-disabledなら、状態に加えて停止理由のログへ進みます。状態が違えば、次に見る材料も違います。

エラーの名前を、受信側・送信側に分けて読む

CRCは、受信したEthernetフレームの誤りを検出した数です。SW1で増えていても、SW1の受信口だけでなく、途中のケーブルやモジュール、SW2の送信側も候補になります。数えた場所と原因の場所は同じとは限りません。

表のruntsは短すぎるフレーム、giantsは許容長を超えるフレームを見る項目です。どの長さから数えるかは製品の定義と設定を合わせて読みます。

input errorsは受信エラーの総括です。内訳が重複して数えられる場合もあり、各欄を単純に足せば必ず一致するわけではありません。まず、どの種類が観測期間に増えているかを特定します。

late collisionsが増えるなら、duplexの不一致なども調べます。正常な全二重Ethernetは衝突を前提にしません。片側だけを固定せず、両端の設定と実際の動作値を比べる理由がここにあります。

仕様の確認：Cisco：NICとの接続とduplexの問題。

10時と10時1分の差を計算する

CRCが132という一回の取得だけでは、今増えているか分かりません。10時に120、10時1分に132なら、この60秒の増分は12です。132全部が一分間に起きたという意味ではありません。

入力パケット数も同じ時刻の差を取ります。例では2,000,000−1,980,000で20,000です。接続口と期間をそろえて初めて、エラーの増分と通信量を対応させられます。

show clock
show interfaces GigabitEthernet1/0/1
（観測時間を置いて同じ出力を取得）
show clock
show interfaces GigabitEthernet1/0/1

参考として12÷20,000×100を計算すると0.06%です。これは計算の説明例で、全機種に共通の合格基準ではありません。数え方、業務への影響、現場の基準を合わせて判断します。

途中に再起動やclear countersがあれば、単純な引き算が成立しないことがあります。値を消す前に保存し、他の調査や監視への影響も確認します。起点のそろった二回の記録が、今の変化を見る材料になります。

平均レートが低くても、瞬間的に詰まることがある

output dropsは、送信側で破棄された量を調べる入口です。5分平均が低くても、数秒だけ通信が集中すると、出口へ送り切れずに捨てられることがあります。短い山を平均値がならしてしまうためです。

データが出口から出るまで待つ場所をキューと呼びます。短時間の集中をバーストと呼び、キューへ入り切るかやQoSの条件が関係します。QoSは混雑時の優先順位や量を制御する仕組みです。

用語の補足：キューって何？

送りたいデータが出口から出るまで待つ場所です。短時間に集中したデータが入り切らないと、破棄される場合があります。優先順位などを決めるQoSの設定も確認対象です。

dropの増加時刻を、出口速度、通信の集中、キュー、QoSの記録へ対応させます。平均が低いという一つの値から、混雑がなかったとは判断できません。

load-intervalは平均レートの表示期間に関する設定です。CRCの累積を一分ごとの数へ変えるものではありません。通信量の時系列と、同じ時間窓のカウンター増分を使い分けると、瞬間的な問題も追いやすくなります。

仕様の確認：Cisco：ポートとインターフェースの調査。

対向の出力と、同じ時刻で比べて報告する

SW1でCRCが増えたら、図で対向のSW2と途中の部品を特定します。両端の速度、duplex、ログ、カウンターを同じ時間帯で取り、今回の症状と対応する変化を探します。

報告は「エラーが多い」より、「SW1 Gi1/0/1で60秒間にCRCが12増加。対向はSW2 Gi1/0/24、両端は1000/full」と書くと、調査対象と数字の意味が伝わります。値は実際の取得結果で埋めます。

この記録と、「ケーブルが原因かもしれない」という推測は分けます。分かったことと候補を混ぜなければ、次の人は何を追加で調べるかを決められます。

是正後も同じ条件で取得し、増分と再発ログ、業務通信を比べます。show interfacesは、一枚の数字から故障名を決めるためではなく、時間と対向をそろえて変化を調べるために使います。

このテーマを続けて学ぶ

show versionの見方。ネットワークエンジニア必須コマンド→

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳・IT未経験からSIerへ転職。ネットワークエンジニアとして、金融系・オフィス系ネットワークの設計・構築に携わり、PL・PMも経験。自身の未経験転職と現場経験をもとに、仕事内容・技術・キャリア・求人選びをわかりやすく解説しています。

YouTube登録者5,000人 Xフォロワー5,000人

執筆者プロフィール・編集方針