show interfaces の出力は行数が多いので、見る順番を決めておくと速く読めます。最初に状態の1行目、次にカウンター、最後にレートです。
もう一つ押さえておきたいのが、カウンターは累積値だという点です。CRCが1万件あっても、それが3年分なのか今日の分なのかで意味がまったく変わります。判断に使うのは絶対値ではなく増分です。
このページはネットワークエンジニアの仕事内容の各論です。担当工程の全体像を先に確認する場合はそちらへ。
出力を読む順番
Switch# show interfaces GigabitEthernet1/0/24- 1行目の状態
物理層とデータリンク層のどちらが落ちているかを確認します。 - Last clearing of counters
カウンターの起点がいつかを確認します。ここを見ずに数値を語ると誤ります。 - input errorsとその内訳
CRC、runts、giants、frame、overrun、ignoredのどれが増えているかを見ます。 - output dropsとcollisions
送信側の輻輳と、デュプレックス関連の事象を見ます。 - 5 minute rate
直近の帯域使用量。設計値と比べます。
1行目の状態表示
| 表示 | 状態 | 疑うところ |
|---|---|---|
| up / line protocol is up | 正常 | 通信できないならL3以上 |
| up / line protocol is down | 物理は生きているが上位が確立していない | カプセル化、キープアライブ、対向設定、VLANの有無 |
| down / line protocol is down | 信号が来ていない | ケーブル、光モジュール、対向のshutdown |
| administratively down | 人が shutdown した |
configと作業記録の照合 |
up / downの組み合わせを読み分けられるかで、現地へ行くかどうかが変わります。 物理が上がっているなら、ケーブルを見に行っても解決しません。
show interfaces statusとの使い分け
show interfacesは1ポートを深く見るコマンド、show interfaces statusは全ポートの状態を1行ずつ並べて見るコマンドです。障害対応では、まずstatusで範囲を絞り、疑わしいポートだけshow interfacesで掘るほうが早く終わります。
| Status欄の値 | 意味 | 次に見るところ |
|---|---|---|
| connected | リンクが上がり、通信できる状態 | 正常。Duplex・Speed欄が想定どおりか |
| notconnect | ケーブル未接続、または対向が落ちている | 結線、対向ポートのshutdown、SFPの有無 |
| err-disabled | 保護機能がポートを落とした状態 | show interfaces status err-disabled で理由を確認 |
| disabled | 設定でshutdownされている | 意図した停止か、直前の変更履歴 |
| monitoring | SPANの宛先ポートになっている | ミラー設定。通常の通信には使えない |
Vlan欄が番号かtrunkかで、そのポートがアクセスかトランクかも同時に分かります。構成図と突き合わせるときは、ここを先に見ると誤解が減ります。
エラーカウンターが示すもの
| カウンター | 意味 | 増えているときに疑うもの |
|---|---|---|
| CRC | フレームチェックシーケンスの不一致 | ケーブル・コネクタの劣化、光モジュール、電気的ノイズ、デュプレックス不一致 |
| runts | 規定の最小サイズ未満のフレーム | コリジョン、デュプレックス不一致、対向のNIC不良 |
| giants | 許容サイズを超えたフレーム | MTU設定の不一致、タグ付きフレームの扱い |
| frame | CRC不一致かつバイト境界にそろっていない | 物理層の異常。CRCと同じ方向で見る |
| overrun / ignored | 受信側の処理・バッファが追いつかない | 過負荷、バースト、機器の性能上限 |
| input errors | 上記の合計値 | 内訳を見ないと原因は絞れない |
ポイントはinput errorsの数字だけを見ないことです。これは内訳の合計なので、CRCが増えているのかoverrunが増えているのかで、疑う場所が物理側かトラフィック側かに分かれます。
デュプレックス不一致のときの出方
片側が全二重、もう片側が半二重になっていると、リンクは上がるのに通信が遅く不安定になります。このとき両端で増えるカウンターが違います。
| 側 | 増えるカウンター | 理由 |
|---|---|---|
| 半二重側 | late collisions、collisions | 相手が待たずに送るため、送信中に衝突が起きる |
| 全二重側 | CRC、runts、input errors | 相手の衝突で壊れたフレームを受け取る |
late collisionsが出ていたら、まずデュプレックス不一致を疑います。 通常のcollisionsと違い、late collisionは正常な半二重通信ではほとんど発生しません（ケーブル長の規格超過でも出ます）。
確認は show interfaces status のDuplex列を両端で見比べます。片側がa-full（オートネゴシエーションの結果）、もう片側がfull（固定）という組み合わせは要注意です。片側だけ固定すると、オート側は半二重と判断します。
output dropsは異常とは限らない
output dropsは、送信キューが溢れて破棄した数です。これは物理故障ではなく輻輳の指標なので、増えていること自体が即障害というわけではありません。
- 短時間のバースト（バックアップ、ファイル転送）で一時的に増えることがある
- 継続的に増え続けているなら、帯域不足かQoS設計の見直し対象
- アップリンクで増えているなら、集約している下位の合計と比べて帯域が足りていない可能性がある
- 業務影響が出ているかを、利用部門の申告と時刻で突き合わせる
アップリンクの帯域の考え方はアップリンクとダウンリンクの違いにまとめています。
累積値ではなく増分で見る
- 起点を確認する
「Last clearing of “show interface” counters」を見ます。neverなら機器の起動時からの累積です。 - 1回目を取得する
時刻を付けて出力を保存します。 - 一定時間を空けて2回目を取得する
5分から10分あけて、同じコマンドで取得します。 - 差分を出す
増えているカウンターだけを抜き出します。ここで初めて「いま起きていること」が分かります。 - 必要なら基準をそろえる
clear countersでリセットしてから観測すると差分が読みやすくなりますが、それまでの累積は消えます。実行前に出力を保存し、必要なら承認を取ってください。
※ここに、実際にカウンターの増分から原因を特定した障害対応の経過という元インフラエンジニアとしての実体験を追加すると強い。
show interfaces historyで「いつから増えたか」を見る
show interfacesのカウンターは起動またはclear counters以降の累積値です。数字が大きくても、それが今朝からなのか半年前からなのかは分かりません。時間の情報が要るときは、次の3つを使い分けます。
- show interfaces <interface> history
対応している機種・バージョンでは、直近の使用率をグラフで表示します。増加が始まったおおよその時刻をその場で当たれます。対応状況は機種によって異なるため、まず打てるかどうかを確認してください。 - load-intervalを短くして増分を取る
入出力レートの既定は5分平均です。load-interval 30にすると30秒平均になり、作業中の変化を追いやすくなります。値を変えたことは作業記録に残します。 - 監視ツールの時系列を見る
SNMPやテレメトリで取得しているなら、そちらのグラフのほうが確実です。機器側は「今どうなっているか」、監視側は「いつからか」と役割を分けます。
報告に書くのは「カウンターがいくつか」ではなく「いつから、どのくらいの速さで増えているか」です。取得した時刻とタイムゾーンを必ず添えます。
報告に書く項目
- 機器名、インターフェース名、取得時刻（1回目・2回目の両方）
- 1行目の状態（up/down、line protocol）
- カウンターの起点（Last clearingの値）
- 増えたカウンターの名前と増分（累積値ではなく差分）
- 両端のSpeed / Duplexの設定値と実測値
- 対向機器側の同じ情報
関連する記事
まとめ
show interfaces は、1行目の状態、カウンターの起点、input errorsの内訳、output drops、レートの順に読みます。CRCやrunts、giantsはそれぞれ疑う場所が違うので、合計値のinput errorsだけを見ても原因は絞れません。late collisionsが出ていればデュプレックス不一致を疑い、両端のDuplex列を見比べます。そしてカウンターは累積値なので、時刻を付けて2回取得し、増分で判断してください。clear counters を使うなら、実行前に出力を保存しておきます。
