Core show Commands

このページのゴール

障害や想定外の動作を確認するときに、最初から1つの原因へ決め打ちせず、目的に合ったshowコマンドを選び、設定状態と現在の実状態を分けながら確認できるようにします。

このページでは、次の基本コマンドを中心に扱います。

show running-config interface
show interfaces
show interfaces status
show ip interface brief
show mac address-table
show arp
show interfaces counters errors

重要なのは、コマンド名を暗記することではありません。

何を確認したいのか
↓
どの確認コマンドが最も直接的か
↓
得られた情報だけで何が言えるか
↓
何はまだ言えないか
↓
次に何を確認するか

という順序で判断できることが目的です。

このページで学ぶこと

• 設定状態と現在の実状態を分ける考え方
• インターフェースの管理状態と回線プロトコル状態を読む方法
• show interfaces statusを選ぶ場面
• show ip interface briefを選ぶ場面
• show running-config interfaceを選ぶ場面
• show interfacesで詳細状態とカウンタを確認する方法
• show mac address-tableでレイヤ2学習を確認する方法
• show arpでIPv4とMACアドレスの対応を確認する方法
• エラーカウンタを累積値として解釈する方法
• 複数のshow結果を相関して次の確認対象を決める方法

最初に設定状態と実状態を分ける

障害切り分けでは、設定が正しいことと、現在正常に動作していることを同一視しません。

たとえば、

interface GigabitEthernet0/1
 ip address 192.0.2.1 255.255.255.0
 no shutdown

という設定が存在していても、現在のインターフェースが正常とは限りません。

物理リンク断、対向装置停止、配線不良、トランシーバ異常などにより、設定は正しくても現在の実状態がダウンしている場合があります。

show running-config interfaceは設定状態を見る

対象インターフェースに投入されている設定そのものを確認したい場合は、show running-config interfaceが直接的です。

例：

SW1# show running-config interface GigabitEthernet1/0/10

interface GigabitEthernet1/0/10
 switchport access vlan 20
 switchport mode access
 spanning-tree portfast

この出力から分かるのは、対象インターフェースへ現在保存されている実動作状態ではなく、現在適用されている設定内容です。

設定にIPアドレスがあっても通信可能とは限らない

例：

R1# show running-config interface GigabitEthernet0/1

interface GigabitEthernet0/1
 ip address 192.0.2.1 255.255.255.0
 no shutdown

この設定だけを見て、

192.0.2.1で現在通信できる

とは断定できません。

次に現在の状態を確認する必要があります。

設定状態と実状態の基本的な対応

確認目的を次のように分けます。

何が設定されているか
→ show running-config interface

現在アップかダウンか
→ show interfaces
→ show ip interface brief
→ show interfaces status

レイヤ2でMACアドレスを学習しているか
→ show mac address-table

IPv4とMACアドレスの対応を確認できるか
→ show arp

管理状態は設定による停止状態

show ip interface briefなどでは、次のような表示を見ることがあります。

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/1     192.0.2.1       YES manual administratively down down

administratively downは、管理設定によってインターフェースが停止していることを示します。

代表的にはshutdown設定が関係します。

administratively downを物理障害と決めない

次の表示を見たとき、

Status
→ administratively down

最初に考えるのは物理ケーブル障害ではありません。

まず、

管理設定で停止している

という事実に着目します。

shutdown設定を確認する

設定確認：

R1# show running-config interface GigabitEthernet0/1

interface GigabitEthernet0/1
 shutdown

この場合、管理設定でインターフェースを停止しています。

管理停止の直接修正候補

意図せずshutdownされていることが原因であり、運用上有効化してよいと確認できた場合の直接的な設定は、

R1(config)# interface GigabitEthernet0/1
R1(config-if)# no shutdown

です。

ただし、試験問題では「何が直接修正候補か」を判断するのであり、実環境では変更前に設計・影響・承認を確認します。

StatusとProtocolは別の状態

show ip interface briefでは、代表的に次の2列を確認します。

Status
Protocol

例：

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/1     192.0.2.1       YES manual up                    up
GigabitEthernet0/2     192.0.2.5       YES manual up                    down
GigabitEthernet0/3     unassigned      YES unset  administratively down down

StatusとProtocolは同じ意味ではありません。

up/upは両方の状態が上がっている

例：

Status
→ up

Protocol
→ up

なら、インターフェース状態と回線プロトコル状態がともに上がっています。

ただし、これだけでアプリケーション通信全体まで正常と証明したことにはなりません。

administratively downは管理停止を示す

例：

Status
→ administratively down

Protocol
→ down

なら、最初に管理設定を確認します。

shutdownの有無が直接的な確認対象です。

up/downは追加確認が必要

例：

Status
→ up

Protocol
→ down

なら、

物理側の状態は上がっている

一方で、

回線プロトコル側は上がっていない

と読みます。

この状態だけから原因を1つへ固定しません。

up/downを対向装置電源断と断定しない

up/downを見たからといって、

対向装置の電源断

と即断するのは不適切です。

インターフェース種別や接続構成に応じて、追加確認が必要です。

show ip interface briefは一覧性が高い

複数のレイヤ3インターフェースについて、

IPアドレス
Status
Protocol

を短い一覧で確認したい場合、show ip interface briefが有効です。

例：

R1# show ip interface brief

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     192.0.2.1       YES manual up                    up
GigabitEthernet0/1     198.51.100.1    YES manual up                    down
GigabitEthernet0/2     unassigned      YES unset  administratively down down
Loopback0               203.0.113.1     YES manual up                    up

show ip interface briefは異常候補の絞り込みに向く

20本のルーテッドポートがある場合、最初から20本すべてにshow interfacesを実行するより、

show ip interface brief

で一覧を確認して、

想定外のIPアドレス
想定外のStatus
想定外のProtocol

があるインターフェースを絞る方が効率的です。

show ip interface briefだけでは詳細カウンタは見えない

show ip interface briefは一覧確認に優れますが、詳細なエラーカウンタを確認する目的には向きません。

詳細確認へ進む場合は、

show interfaces <interface>

などを使います。

show interfacesは詳細状態とカウンタを見る

例：

R1# show interfaces GigabitEthernet0/1

GigabitEthernet0/1 is up, line protocol is down
  Hardware is ...
  Internet address is 198.51.100.1/24
  MTU 1500 bytes, BW 1000000 Kbit/sec
  ...
  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
  ...
  0 output errors, 0 collisions, 0 interface resets

このコマンドでは、

インターフェース状態
回線プロトコル状態
アドレス情報
速度やMTUなどの情報
入出力カウンタ
エラーカウンタ

を詳細に確認できます。

show interfacesは単一インターフェースの詳細確認に向く

一覧から問題候補を絞った後、

show interfaces GigabitEthernet0/1

のように対象を限定して確認すると、

状態
カウンタ
エラー

を詳しく確認できます。

show interfacesでStatusとline protocolを読む

出力冒頭：

GigabitEthernet0/1 is up, line protocol is down

ここでは、

GigabitEthernet0/1 is up

と、

line protocol is down

を分けて読みます。

up/downという状態を1語の結果として暗記するのではなく、どちらが上がっていてどちらが下がっているかを確認します。

show interfaces statusはスイッチポート一覧に向く

アクセススイッチなどで、多数のポート状態を一覧比較したい場合はshow interfaces statusが便利です。

例：

SW1# show interfaces status

Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/1                      connected    10         a-full  a-1000 10/100/1000BaseTX
Gi1/0/2                      notconnect   20         auto    auto   10/100/1000BaseTX
Gi1/0/3                      connected    trunk      a-full  a-1000 10/100/1000BaseTX
Gi1/0/4                      disabled     30         auto    auto   10/100/1000BaseTX

show interfaces statusで確認する代表項目

代表的には、

Port
Status
Vlan
Duplex
Speed
Type

などを一覧で確認します。

目的は、スイッチ全体のポート状態を素早く比較して対象を絞ることです。

connectedは接続状態の確認情報

例：

Port
→ Gi1/0/1

Status
→ connected

なら、そのポートは接続状態として認識されています。

ただし、connectedだけで上位通信まで正常とは判断しません。

notconnectは未接続状態として扱う

例：

Port
→ Gi1/0/2

Status
→ notconnect

なら、現在接続状態を確認できていません。

原因は、

ケーブル
対向装置
対象ポート
物理層

など複数候補があり、notconnectだけで原因を一意化しません。

disabledは設定や保護動作の追加確認が必要

show interfaces statusで、

Status
→ disabled

などの状態を確認した場合、現在利用可能なconnected状態ではありません。

設定や関連機能の状態を追加確認します。

show interfaces statusはVLAN列も確認できる

例：

Port
→ Gi1/0/1

Status
→ connected

Vlan
→ 20

なら、ポート状態の一覧と合わせてVLAN列も確認できます。

ただし、詳細なVLAN設計やトランク設定そのものを改めて説明するのではなく、ここでは「想定と一致しているか」を確認情報として利用します。

DuplexとSpeedも一覧比較できる

例：

Duplex
→ a-full

Speed
→ a-1000

複数ポートを比較し、想定外の値があるポートを絞る材料として使えます。

1つの値だけで根本原因を確定せず、症状や他の確認結果と合わせます。

一覧コマンドから詳細コマンドへ進む

効率的な流れの例：

show interfaces status
↓
異常候補ポートを絞る
↓
show interfaces <interface>
↓
詳細状態とカウンタを確認
↓
show running-config interface <interface>
↓
設定状態と比較

最初からすべての詳細情報を見るのではなく、一覧から対象を絞る考え方が重要です。

show running-config interfaceは投入設定の確認に向く

例：

SW1# show running-config interface GigabitEthernet1/0/10

interface GigabitEthernet1/0/10
 switchport mode access
 switchport access vlan 20
 no shutdown

ここで分かるのは、

アクセスVLAN
switchport mode
shutdown有無

などの設定です。

running-configだけで現在状態を確定しない

設定：

switchport access vlan 20
no shutdown

があっても、

現在接続状態か
MACアドレスを学習しているか
実通信できるか

までは分かりません。

設定確認の後に、実状態を別コマンドで確認します。

アクセスVLAN 20なのに通信できない場合

設定：

show running-config interface GigabitEthernet1/0/10

で、

switchport access vlan 20

を確認したとします。

次に、

show interfaces status

でポート状態とVLAN列を確認し、

show mac address-table

で対象VLANのMAC学習を確認するなど、設定と実状態を分けて相関します。

MACアドレステーブルはレイヤ2学習を見る

スイッチがどのMACアドレスをどのポートで学習しているか確認する場合は、show mac address-tableを使います。

例：

SW1# show mac address-table

          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  20    0011.2233.4455    DYNAMIC     Gi1/0/10
  20    00aa.bbcc.ddee    DYNAMIC     Gi1/0/24

MACアドレステーブルではVLANとポートを対応付ける

例：

VLAN
→ 20

MACアドレス
→ 0011.2233.4455

Ports
→ Gi1/0/10

なら、VLAN 20でそのMACアドレスがGi1/0/10側に学習されていることを確認できます。

対象MACがあることはレイヤ2学習の証拠

対象ホストのMACアドレスが、

VLAN 20
Gi1/0/10

で学習されているなら、

少なくともスイッチがそのMACアドレスをそのVLANとポートの組み合わせで学習している

という確認情報になります。

MACアドレステーブルにないだけで原因を確定しない

対象MACアドレスが見つからない場合、

ホスト停止
ケーブル断
VLAN不一致
対象ポート誤り
まだフレームを受信していない
エントリがエージアウトした

など複数の可能性があります。

したがって、

MACアドレスがない
→ ケーブル断確定

とは判断しません。

MAC学習不在は「現在確認できない」という情報

適切な表現は、

現在のMACアドレステーブルで対象MACアドレスを確認できない

です。

そこから原因候補を絞るために、ポート状態やVLAN、対向装置の状態などを追加確認します。

show mac address-tableだけでリンク状態を確定しない

MACアドレス学習は有用な確認情報ですが、現在の物理リンク状態を直接表示するコマンドではありません。

リンク状態そのものは、

show interfaces
show interfaces status

などで確認します。

show arpはIPv4とMACアドレスの対応を見る

IPv4アドレスとMACアドレスの対応を確認する場合はshow arpを利用できます。

例：

R1# show arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.0.2.10              2   0011.2233.4455  ARPA   GigabitEthernet0/1

ARPテーブルで確認する内容

この例では、

IPv4アドレス
→ 192.0.2.10

Hardware Addr
→ 0011.2233.4455

Interface
→ GigabitEthernet0/1

という対応を確認できます。

ARPはMACアドレステーブルと同じではない

show arpとshow mac address-tableは目的が違います。

show arp
→ IPv4アドレスとMACアドレスの対応

show mac address-table
→ VLAN内で学習したMACアドレスとスイッチポートの対応

として分けます。

ARPエントリ不在だけでリモートホスト停止と断定しない

対象IPv4アドレスのARPエントリがない場合、

ARP解決がまだ成立していない

または、

現在エントリを保持していない

という確認情報になります。

これだけで、

隣接ホスト停止
ルーティング正常
物理障害

などを確定しません。

ARPエントリ不在は他のレイヤ3状態と組み合わせる

ARPエントリがない場合は、

対象インターフェース状態
IPアドレス設定
同一サブネット関係
必要なレイヤ3到達性

など、症状に応じた追加確認が必要です。

ここではルーティングテーブルの経路選択詳細には踏み込みません。

show interfacesのカウンタを読む

show interfacesでは、通信量やエラーに関する各種カウンタを確認できます。

例：

5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 2000 bits/sec, 3 packets/sec
...
3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored
...
0 output errors, 0 collisions, 0 interface resets

CRCは物理層関連の仮説を考える材料になる

CRCエラーは、受信フレームのエラーに関する確認情報です。

値が継続的に増える場合は、

ケーブル
コネクタ
トランシーバ
物理品質

など、物理層関連の原因仮説を強める材料になります。

CRCが1以上なら現在障害確定ではない

例：

3 CRC

という表示だけで、

現在ケーブル障害が発生中

とは断定しません。

カウンタが累積値である可能性を考えます。

カウンタは現在値だけでなく増加傾向を見る

1回目：

3 CRC

30秒後：

3 CRC

なら、少なくともその観測区間では増えていません。

一方、

3 CRC
↓
30秒後
↓
25 CRC

なら、現在もエラーが発生している可能性が高まり、物理層関連の仮説が強くなります。

カウンタの絶対値だけで原因を決めない

大きな値でも長期間の累積かもしれません。

小さな値でも短時間に急増しているなら現在の問題と関連する可能性があります。

見るべきなのは、

絶対値
増加傾向
観測時間
他の状態
症状発生時刻

です。

input errorsとCRCを相関する

例：

100 input errors
100 CRC

という結果なら、受信側エラーの中でCRCが大きく関係していることを確認できます。

ただし、出力の各カウンタが示す意味を混同せず、原因確定には追加確認を使います。

output errorsも別に確認する

受信側だけでなく、

output errors

も確認します。

入力側だけ異常なのか、出力側にも異常があるのかを分けると、確認範囲を絞りやすくなります。

show interfaces counters errorsで一覧確認する

スイッチで複数ポートのエラーカウンタを比較したい場合、環境によっては次のようなコマンドを利用できます。

SW1# show interfaces counters errors

出力例：

Port        Align-Err    FCS-Err    Xmit-Err    Rcv-Err
Gi1/0/1             0          0           0          0
Gi1/0/2             0         25           0         25
Gi1/0/3             0          0           0          0

一覧から異常候補ポートを絞り、

show interfaces Gi1/0/2

で詳細確認へ進めます。

カウンタ0でも通信全体正常とは限らない

エラーカウンタが0でも、

VLAN設定
管理停止
IPアドレス設定
ARP解決
上位経路

など別の問題はあり得ます。

エラーカウンタ
→ 0

を、

すべて正常

と読み替えません。

確認コマンドは目的ごとに使い分ける

目的とコマンドを対応させます。

設定そのもの
→ show running-config interface

インターフェース詳細
→ show interfaces

スイッチポート一覧
→ show interfaces status

レイヤ3インターフェース一覧
→ show ip interface brief

レイヤ2MAC学習
→ show mac address-table

IPv4とMACアドレス対応
→ show arp

「最も直接的なコマンド」を選ぶ

問題では、複数のコマンドが何らかの情報を返す場合でも、

質問された情報を最も直接確認できるコマンド

を選びます。

たとえば、

Gi1/0/10に投入されたswitchport設定

を確認したいなら、

show running-config interface Gi1/0/10

が直接的です。

詳細すぎるコマンドより一覧コマンドが適切な場合がある

20本のレイヤ3インターフェースから異常候補を探すなら、

show interfaces GigabitEthernet0/0
show interfaces GigabitEthernet0/1
...

と1本ずつ読むより、

show ip interface brief

で一覧確認して対象を絞る方が適切です。

一覧コマンドだけで原因確定しない

一覧は対象の絞り込みに向きます。

show ip interface brief
show interfaces status

で異常候補を見つけた後、

show interfaces <interface>
show running-config interface <interface>

などで詳細確認へ進みます。

設定と実状態を相関する

例：

show running-config interface Gi1/0/10
↓
switchport access vlan 20
no shutdown

show interfaces status
↓
Gi1/0/10 connected VLAN 20

show mac address-table
↓
VLAN 20で対象MACを学習

ここまで一致すれば、

設定
ポート状態
VLAN表示
MAC学習

が互いに整合していることを確認できます。

設定と実状態が食い違う場合

例：

running-config
→ no shutdown

show interfaces status
→ notconnect

なら、

管理設定では有効
現在は接続状態ではない

と分けて考えます。

この差から、物理接続や対向装置など追加確認へ進めます。

IP設定と現在状態を相関する

例：

show running-config interface GigabitEthernet0/1
↓
ip address 192.0.2.1 255.255.255.0
no shutdown

show ip interface brief
↓
GigabitEthernet0/1 192.0.2.1 up up

なら、

設定IP
管理状態
現在のStatus
Protocol

が期待と整合していることを確認できます。

up/upでもさらに上位確認が必要な場合がある

up/upは重要な確認情報ですが、

MAC学習
ARP解決
上位のレイヤ3到達性

など、症状によって追加確認が必要です。

up/upだけで「通信できない原因は存在しない」とは判断しません。

MAC学習とARPを相関する

同一セグメントのホストを確認する場面では、

show arp
↓
192.0.2.10 → 0011.2233.4455

と、

show mac address-table
↓
0011.2233.4455 → Gi1/0/10

を対応付けられる場合があります。

これにより、

IPv4
↓
MACアドレス
↓
スイッチポート

という確認情報をつなげられます。

ARPとMACアドレステーブルで対象範囲が違う

ARPエントリがある装置と、MACアドレステーブルを持つスイッチが同じ装置とは限りません。

そのため、

どの装置で
どの確認コマンドを実行しているか

を意識します。

1つの確認出力で根本原因を決めない

障害切り分けでは、

1つの値
↓
根本原因確定

としないことが重要です。

たとえば、

MACアドレステーブルに対象MACなし

だけでは、原因を確定できません。

症状に応じて確認レイヤを下から上へ整理する

例：

通信できない
↓
インターフェース状態
↓
スイッチポート状態
↓
MAC学習
↓
ARP対応
↓
必要な上位確認

のように、確認情報を段階的に積み上げます。

ただし、常に同じ固定順序でなければならないわけではありません。

症状に応じて最も情報量の多い確認から始めます。

既習機能固有の確認コマンドも組み合わせる

基本コマンドだけで十分でない場合は、対象機能に対応した既習のshowコマンドも使います。

たとえば、

VLAN
EtherChannel
CDP
LLDP

などの機能について、すでに学習した確認コマンドを症状に応じて組み合わせます。

ここでは各機能の設定内容そのものは再説明しません。

機能固有の確認コマンドを最初から乱用しない

問題がインターフェースの管理停止なら、

show running-config interface
show ip interface brief

の方が直接的です。

関係の薄い機能固有コマンドを大量に実行するより、

症状
↓
最も直接的な確認
↓
結果に応じて範囲拡大

と進めます。

シナリオ1：IPアドレス設定そのものを確認する

目的：

GigabitEthernet0/1に設定されたIPアドレスを確認したい

最初のコマンド：

show running-config interface GigabitEthernet0/1

理由：

設定そのもの

を確認したいからです。

シナリオ2：設定はあるが現在通信できない

確認：

show running-config interface GigabitEthernet0/1
↓
IPアドレス設定あり
no shutdown

次：

show ip interface brief

結果：

GigabitEthernet0/1
Status down
Protocol down

この場合、設定と実状態が一致していません。

さらに設定全体や現在適用状態を再確認します。

シナリオ3：administratively downを確認する

結果：

GigabitEthernet0/1 administratively down down

最初の着目点：

管理状態

です。

直接修正候補を問われるなら、

no shutdown

を考えます。

シナリオ4：up/downを確認する

結果：

GigabitEthernet0/1 is up, line protocol is down

判断：

インターフェース側はアップ
回線プロトコル側はダウン

です。

完全正常なup/upとして扱わず、回線プロトコル側の追加確認へ進みます。

シナリオ5：アクセススイッチ全体から異常ポートを探す

目的：

多数のスイッチポートから接続状態が異常なポートを絞る

最初のコマンド：

show interfaces status

理由：

Port
Status
Vlan
Duplex
Speed

を一覧比較できるからです。

シナリオ6：20本のルーテッドポートから異常候補を探す

目的：

IPアドレス
Status
Protocol

を一覧比較したい。

最初のコマンド：

show ip interface brief

です。

シナリオ7：Gi1/0/10のswitchport設定を確認する

目的：

どのswitchport設定が投入されているか

確認：

show running-config interface GigabitEthernet1/0/10

です。

show interfaces statusだけでは設定全文を確認できません。

シナリオ8：アクセスVLAN設定は正しいが通信できない

確認1：

show running-config interface GigabitEthernet1/0/10
↓
switchport access vlan 20

確認2：

show interfaces status
↓
Gi1/0/10 connected VLAN 20

確認3：

show mac address-table
↓
対象MACがVLAN 20で存在するか

設定と実状態を順に相関します。

シナリオ9：対象MACが見つからない

結果：

show mac address-table
↓
対象MACなし

適切な判断：

現在そのテーブルで対象MAC学習を確認できない

です。

ケーブル断確定
ホスト停止確定
VLAN誤り確定

とはしません。

シナリオ10：IPv4からMACアドレスを確認する

目的：

192.0.2.10に対応するMACアドレスを確認したい

コマンド：

show arp

です。

シナリオ11：ARPエントリがない

結果：

192.0.2.10のARPエントリなし

適切な判断：

現在ARP解決情報を確認できない
↓
インターフェース状態などを追加確認

です。

リモートホスト停止と即断しません。

シナリオ12：CRCが3ある

結果：

3 CRC

適切な判断：

累積値の可能性を考える
↓
時間を置いて再確認
↓
増加傾向を見る

です。

シナリオ13：CRCが短時間に増加する

1回目：

3 CRC

30秒後：

25 CRC

この場合、

現在も受信エラーが発生している可能性

が高まり、

ケーブル
トランシーバ
物理品質

などの仮説を強めます。

シナリオ14：インターフェースはアップだがCRCが増える

状態：

インターフェース
→ アップ

カウンタ：

CRC
→ 継続増加

判断：

アップだから物理問題なし

とはしません。

リンクがアップでも品質問題が存在する可能性があります。

シナリオ15：エラーカウンタが0

結果：

0 input errors
0 CRC
0 output errors

これは、

確認したエラーカウンタでは異常を確認していない

という情報です。

VLAN、IPアドレス、ARP、上位経路まで正常と証明したわけではありません。

シナリオ16：リモートIPへ届かない

症状：

リモートIPへ到達できない

まず、

show ip interface brief

で関連インターフェース状態を確認し、

必要に応じて、

show interfaces
show running-config interface
show arp

を相関します。

スイッチ区間なら、

show interfaces status
show mac address-table

も確認候補です。

シナリオ17：設定は正しいが実状態が異常

設定：

no shutdown

実状態：

notconnect

なら、

設定上は有効
現在接続を確認できない

と分けます。

物理接続や対向装置へ確認範囲を広げます。

シナリオ18：複数の確認情報が一致する

結果：

running-config
→ no shutdown

show interfaces status
→ connected

show mac address-table
→ 対象MAC学習あり

この場合、

管理設定
接続状態
レイヤ2学習

が互いに整合しています。

これでも必要に応じて上位確認は続けます。

よくある誤り

running-configが正しければ現在も正常と考える

設定状態と実状態は別です。

administratively downをケーブル障害と考える

まず管理設定による停止を確認します。

up/downを完全正常として扱う

StatusとProtocolの片方がダウンです。

show interfaces statusでIPアドレスを確認しようとする

IPアドレスとStatus、Protocolの一覧にはshow ip interface briefが適しています。

show ip interface briefで詳細カウンタまで確認しようとする

詳細カウンタはshow interfacesなどで確認します。

MACアドレステーブルに対象MACがなければケーブル断と決める

MAC学習不在の原因は複数あります。

ARPエントリがなければリモートホスト停止と決める

ARP不在だけで原因を一意化しません。

CRCが1以上なら現在物理障害と決める

累積値かもしれないため、増加傾向を確認します。

エラーカウンタが0ならすべて正常と考える

他レイヤや設定の問題は残り得ます。

1つの確認コマンドで根本原因まで決める

複数の確認情報を相関して仮説を絞ります。

問題での判断パターン

パターン1：設定そのものを確認したい

show running-config interface

を選びます。

パターン2：現在のIPアドレスとStatusとProtocolを一覧したい

show ip interface brief

を選びます。

パターン3：多数のスイッチポート状態を一覧したい

show interfaces status

を選びます。

パターン4：単一インターフェースの詳細状態とカウンタを確認したい

show interfaces <interface>

を選びます。

パターン5：MAC学習を確認したい

show mac address-table

を選びます。

パターン6：IPv4とMACアドレスの対応を確認したい

show arp

を選びます。

パターン7：administratively down

管理設定による停止

を最初に考えます。

パターン8：up/down

Status
→ up

Protocol
→ down

として追加確認へ進みます。

パターン9：MACアドレステーブルにエントリなし

現在対象MAC学習を確認できない

と判断し、原因は追加確認します。

パターン10：ARPエントリなし

現在ARP解決情報を確認できない

と判断し、他のレイヤ3状態と相関します。

パターン11：CRCが少数存在する

累積値の可能性
↓
増加傾向確認

と判断します。

パターン12：CRCが短時間に増える

現在の物理層問題仮説が強まる

として、ケーブルやトランシーバなどの確認へ進みます。

パターン13：設定と実状態が矛盾する

設定
↓
実状態

を別々に記録し、どちらが想定外かを特定します。

パターン14：リモートIPへ届かない

1つのコマンドだけで決めず、

インターフェース状態
MAC学習
ARP
必要な既習機能固有の確認コマンド

を症状に応じて相関します。

コマンド選択表

目的
→ コマンド

設定内容
→ show running-config interface

インターフェース詳細
→ show interfaces

スイッチポート一覧
→ show interfaces status

レイヤ3インターフェース一覧
→ show ip interface brief

MAC学習
→ show mac address-table

IPv4とMACアドレス対応
→ show arp

ポートエラーカウンタ一覧
→ show interfaces counters errors

障害切り分けの基本手順

1. 症状を明確にする
2. 設定状態と実状態のどちらを確認したいか決める
3. 一覧コマンドで異常候補を絞る
4. 詳細コマンドで対象を確認する
5. MACとARPなど必要なテーブルを確認する
6. カウンタは現在値と増加傾向を分けて見る
7. 1つの出力だけで原因を決めない
8. 複数の確認情報を相関する
9. 結果に応じて既習機能固有の確認コマンドへ広げる
10. まだ証明できていない範囲を明確にする

まとめ

基本showコマンドは、単にコマンド名と出力を暗記するのではなく、確認したい情報に応じて選択します。

show running-config interface
→ 設定状態

show interfaces
→ 詳細な実状態とカウンタ

show interfaces status
→ スイッチポート状態の一覧

show ip interface brief
→ レイヤ3インターフェースのIPアドレスとStatusとProtocol一覧

show mac address-table
→ レイヤ2のMAC学習

show arp
→ IPv4とMACアドレスの対応

最も重要なのは、

設定が正しい
≠
現在正常に動作している

と理解することです。

administratively down、up/down、MAC学習不在、ARPエントリ不在、CRCエラーなど、1つの表示だけで原因を確定せず、現在の状態・設定・テーブル・カウンタを相関して次の確認対象を決めます。