障害対応で使えるネットワーク切り分け手順

2026年7月19日

「システムにつながらないので、ネットワークを確認してください」

ネットワークエンジニアとして働いていると、このような依頼を受けることがあります。

しかし、情報が少ない状態でルーターやスイッチの設定を眺めても、原因を効率的に特定することはできません。

ネットワーク障害への対応で重要なのは、コマンドをたくさん知っていることではなく、確認する順番を決めて、正常な範囲と異常な範囲を切り分けることです。

この記事では、ネットワーク障害が発生したときに使える基本的な切り分け手順を、図・コマンド例・実践ケースを交えて解説します。

この記事の対象者

ネットワークエンジニアとして実務経験が1〜3年程度ある人
監視や手順書作業から、障害対応へステップアップしたい人
pingやtracerouteは知っているが、使う順番が分からない人
障害の原因と影響範囲を説明できるようになりたい人

この記事で身につくこと

ネットワーク障害を順序立てて確認する方法
レイヤーごとの代表的な確認項目
Windows・Linux・Cisco機器で使える確認コマンド
原因が分からない段階での報告方法
切り分け結果を障害報告にまとめる方法

結論：障害対応では「範囲・レイヤー・比較」で切り分ける

ネットワーク障害を効率的に切り分けるための基本は、次の3つです。

1．影響範囲を確認する

1台だけ発生しているのか
同じ部署やフロアで発生しているのか
拠点全体で発生しているのか
特定のシステムだけ利用できないのか

2．下位レイヤーから確認する

ケーブルやポートは正常か
VLANやMACアドレスの学習は正常か
IPアドレスやルーティングは正常か
DNSやTCPポートは正常か
アプリケーションは正常か

3．正常な通信と比較する

正常な端末と異常な端末
正常時のログと障害時のログ
正常な拠点と障害が発生している拠点
往路と復路
IPアドレス指定とホスト名指定

障害対応は、原因をいきなり当てる作業ではありません。

正常であることを一つずつ確認し、原因の候補を減らしていく作業

と考えると、進めやすくなります。

ネットワーク障害の基本切り分けフロー

障害発生から原因特定までの全体像

flowchart TD
    A[障害受付] --> B[発生時刻・症状・対象を確認]
    B --> C{影響範囲はどこか}

    C -->|1台だけ| D[端末・ケーブル・IP設定を確認]
    C -->|同一フロア・同一VLAN| E[スイッチ・VLAN・STPを確認]
    C -->|拠点全体| F[デフォルトゲートウェイ・WAN・DNSを確認]
    C -->|特定サービスだけ| G[ポート・ACL・FW・サーバーを確認]

    D --> H[レイヤー1から順番に確認]
    E --> H
    F --> H
    G --> H

    H --> I{原因箇所を絞り込めたか}
    I -->|はい| J[暫定復旧・恒久対応]
    I -->|いいえ| K[パケット・ログ・正常環境と比較]
    K --> I

    J --> L[復旧確認・影響確認]
    L --> M[障害報告・再発防止]

図のように、最初に確認するべきなのは機器の設定ではなく、誰が・いつから・何を利用できないのかです。

手順0：作業を始める前に情報を保存する

障害対応では、早く復旧させることが求められます。

一方で、原因を確認する前に機器を再起動したり、設定を変更したりすると、原因特定に必要な情報が消えることがあります。

作業前に、最低限次の情報を保存しましょう。

保存する情報

障害の発生時刻
最初に申告された時刻
対象ユーザー・端末・拠点
具体的なエラーメッセージ
正常に利用できていた最終時刻
直前に行った作業や設定変更
機器のログ
インターフェース状態
CPU・メモリー・トラフィック
ルーティングテーブル
ARP・MACアドレステーブル
現在の設定

作業前の原則

確認 → 記録 → 仮説 → 検証 → 変更 → 結果確認

「とりあえず再起動する」は、最後の手段です。

再起動が必要な場合も、ログや状態を保存し、影響範囲と復旧方法を確認してから実施します。

手順1：障害の症状を具体化する

「ネットワークにつながらない」という申告だけでは、切り分けを開始できません。

利用者に確認し、症状を具体的な言葉へ変換します。

最初に確認する質問

確認項目	質問例
発生時刻	いつから発生していますか
対象	誰の、どの端末で発生していますか
接続方法	有線LAN、無線LAN、VPNのどれですか
対象サービス	すべて利用不可ですか、特定システムだけですか
再現性	常に発生しますか、断続的ですか
エラー内容	画面にどのようなメッセージが表示されますか
正常な利用者	周囲の人は同じシステムを利用できますか
直前の変更	移動、配線変更、端末交換、設定変更はありましたか

曖昧な申告を具体化する例

申告：
「インターネットにつながらない」

具体化：
「PC-AからWebサイトをホスト名で開けない。
IPアドレスを指定した通信は成功する。
同じフロアのPC-Bでは正常に利用できる」

ここまで具体化できれば、端末固有のDNS設定や名前解決を優先して調査できます。

手順2：影響範囲を切り分ける

影響範囲を確認すると、調査する場所を大幅に絞れます。

影響範囲から疑う場所を判断する

flowchart LR
    A[障害発生] --> B{何台で発生しているか}

    B -->|1台| C[端末固有]
    B -->|複数台| D{共通点はあるか}
    B -->|全体| E[共通設備]

    C --> C1[NIC]
    C --> C2[IP設定]
    C --> C3[端末FW]
    C --> C4[ケーブル]

    D -->|同じスイッチ| D1[ポート・上位リンク]
    D -->|同じVLAN| D2[VLAN・STP・GW]
    D -->|同じ拠点| D3[WAN・拠点ルーター]
    D -->|同じサービス| D4[DNS・FW・サーバー]

    E --> E1[コアルーター]
    E --> E2[共通FW]
    E --> E3[DNS]
    E --> E4[回線・クラウド]

影響範囲と原因候補

影響範囲	優先して疑う場所
端末1台だけ	ケーブル、NIC、IP設定、端末ファイアウォール
同じ島・フロア	アクセススイッチ、上位リンク、VLAN
同じVLAN	VLAN設定、SVI、デフォルトゲートウェイ、STP
拠点全体	拠点ルーター、WAN回線、共通DNS
全社	コア機器、共通ファイアウォール、DNS、クラウド
特定システムだけ	サーバー、ロードバランサー、ACL、TCPポート
外部サイトだけ	インターネット回線、NAT、プロキシ、DNS

ポイント

複数の利用者に共通する設備を探します。

例えば、障害が発生している端末がすべて同じフロアにあるなら、個々の端末よりも、そのフロアのアクセススイッチや上位リンクを優先して確認します。

手順3：レイヤー1―物理接続を確認する

ネットワーク障害では、設定だけでなく物理的な原因も多くあります。

設定確認へ進む前に、ケーブルやインターフェースの状態を確認します。

主な確認項目

端末やネットワーク機器の電源
LANケーブルの接続
ポートのリンクランプ
インターフェースのup／down
ケーブルの断線や抜け
光トランシーバーの状態
CRCエラーや入力エラー
Speed／Duplexの不一致
上位リンクの状態

物理レイヤーの確認範囲

flowchart LR
    PC[利用者PC] -->|LANケーブル| SW1[アクセススイッチ]
    SW1 -->|アップリンク| SW2[コアスイッチ]
    SW2 -->|接続回線| RT[ルーター・FW]
    RT --> WAN[WAN・インターネット]

    PC -.確認.-> A[NIC・リンクランプ]
    SW1 -.確認.-> B[ポート状態・エラー]
    SW2 -.確認.-> C[トランク・光レベル]
    RT -.確認.-> D[回線・インターフェース]

Cisco機器の確認コマンド例

show interfaces status
show ip interface brief
show interfaces
show interfaces counters errors
show logging

確認結果の見方

状態	主な意味
up／up	物理・プロトコルともに動作
down／down	ケーブル、対向機器、光、物理ポートなどを疑う
up／down	レイヤー2設定やプロトコルの不整合を疑う
administratively down	shutdown設定を確認する
CRCエラー増加	ケーブル、光、ノイズ、Duplexなどを疑う
input error増加	受信側の物理問題やフレーム異常を疑う
output drop増加	輻輳やキュー不足を疑う

ただし、機種やOSによってコマンドと表示内容は異なります。実機の公式コマンドリファレンスを確認してください。

手順4：レイヤー2―VLAN・MAC・ARPを確認する

物理接続が正常でも、適切なVLANに所属していなければ通信できません。

レイヤー2では、フレームが同一セグメント内を正しく転送されているかを確認します。

主な確認項目

アクセスポートのVLAN
トランクポートの許可VLAN
Native VLAN
MACアドレスの学習
STPの状態
EtherChannelの状態
Port Security
ARPの解決状態

Cisco機器の確認コマンド例

show vlan brief
show interfaces switchport
show interfaces trunk
show mac address-table
show spanning-tree
show etherchannel summary
show port-security interface <interface>
show arp

レイヤー2の通信で確認する場所

sequenceDiagram
    participant PC as 利用者PC
    participant ASW as アクセスSW
    participant CSW as コアSW
    participant GW as デフォルトGW

    PC->>ASW: ARP Request
    ASW->>CSW: VLAN内へ転送
    CSW->>GW: ARP Request
    GW-->>CSW: ARP Reply
    CSW-->>ASW: ARP Reply
    ASW-->>PC: ARP Reply

    Note over PC,GW: ARPが解決できなければ、<br/>VLAN・STP・ポート・GWを確認

切り分けの考え方

MACアドレスを学習していない場合

端末からフレームが届いていない
VLANが異なる
ポートがブロックされている
ケーブルやNICに問題がある
MACアドレステーブルの確認箇所が間違っている

ARPがIncompleteの場合

対象IPの端末が存在しない
同一セグメントに到達できていない
VLANが一致していない
対象端末が応答していない
セキュリティ機能によって遮断されている

ARPだけを見て結論を出さず、MACアドレステーブルやVLAN設定と組み合わせて確認します。

手順5：レイヤー3―IPアドレスとルーティングを確認する

次に、端末のIP設定とルーティングを確認します。

端末で確認する項目

IPアドレス
サブネットマスク
デフォルトゲートウェイ
DNSサーバー
DHCPによる取得状況
重複IPアドレス
ルーティングテーブル

Windowsの確認コマンド

ipconfig /all
route print
arp -a
Get-NetAdapter
Get-NetIPConfiguration

ipconfigでは、端末に設定されているIPアドレス、サブネットマスク、デフォルトゲートウェイなどを確認できます。(Microsoft Learn)

Linuxの確認コマンド

ip addr
ip link
ip route
ip neigh

Cisco機器の確認コマンド

show ip interface brief
show ip route
show arp
show ip cef <destination-ip>
show access-lists

pingは近い場所から遠い場所へ実行する

いきなり外部サーバーへpingを実行するのではなく、通信経路に沿って確認します。

図5：pingを実行する順番

flowchart LR
    A[127.0.0.1<br/>TCP/IP機能] --> B[自端末IP<br/>NIC設定]
    B --> C[デフォルトGW<br/>同一セグメント]
    C --> D[拠点内サーバー<br/>社内ルーティング]
    D --> E[遠隔拠点・外部IP<br/>WAN・インターネット]
    E --> F[ホスト名<br/>DNSを含む確認]

Windowsでの確認例

ping 127.0.0.1
ping <自端末のIPアドレス>
ping <デフォルトゲートウェイ>
ping <接続先のIPアドレス>
ping <接続先のホスト名>

Ciscoの公式資料では、pingはICMP Echoを利用し、相手への到達性、往復遅延、パケット損失などを確認する手段として説明されています。(Cisco)

結果から分かること

結果	疑う場所
127.0.0.1に失敗	端末のTCP/IP機能
自端末IPに失敗	NIC・OS・IP設定
デフォルトGWに失敗	ケーブル、VLAN、ARP、GW
GWには成功し、遠隔IPに失敗	ルーティング、WAN、ACL
IPには成功し、ホスト名に失敗	DNS
pingは成功し、Webだけ失敗	TCPポート、FW、プロキシ、サーバー

pingの注意点

pingが失敗しても、必ずしも通信経路が停止しているとは限りません。

ファイアウォールや機器の設定によって、ICMPだけが拒否されている可能性があります。また、中継機器がICMPへの応答を制限している場合もあります。

そのため、pingだけで「ネットワーク障害」と断定せず、実際に使用するTCPポートやアプリケーションでも確認します。

手順6：tracerouteで経路を確認する

宛先までの通信が失敗する場合は、tracerouteを使って、どの経路を通っているかを確認します。

Windows

tracert -d <宛先IPアドレス>

Linux

traceroute -n <宛先IPアドレス>

Cisco IOS

traceroute <宛先IPアドレス>

pingが宛先への到達性を確認するのに対し、tracerouteはパケットが通る経路や、どの付近で通信が途切れているかを調べるために使用できます。(Cisco)

tracerouteによる経路確認

flowchart LR
    PC[PC<br/>192.168.10.20] --> GW[拠点GW<br/>192.168.10.1]
    GW --> WAN1[WANルーターA]
    WAN1 --> WAN2[WANルーターB]
    WAN2 --> FW[データセンターFW]
    FW --> SV[業務サーバー]

    WAN2 -- 応答なし --> X[この付近を重点確認]

tracerouteの注意点

途中のホップがアスタリスクになっても、その機器で障害が発生しているとは限りません。

中継機器がtracerouteへの応答を返さなくても、後続の通信を正常に転送している場合があります。

確認するべきポイントは次のとおりです。

最終宛先まで到達するか
正常時と経路が変わっていないか
特定地点から先がすべて応答しないか
往路と復路で異なる経路になっていないか
遅延が継続的に発生しているか

手順7：DNSの名前解決を確認する

IPアドレス指定では通信できるものの、ホスト名指定では通信できない場合、DNSを優先して確認します。

IP通信と名前解決の切り分け

flowchart TD
    A[システムへ接続できない] --> B{IPアドレス指定で接続できるか}

    B -->|できる| C[ネットワーク経路は概ね正常]
    C --> D[DNSを確認]
    D --> E{正しいIPが返るか}
    E -->|返らない| F[DNS設定・レコード・到達性]
    E -->|返る| G[キャッシュ・プロキシ・アプリ設定]

    B -->|できない| H[経路・ACL・ポート・サーバーを確認]

Windows

nslookup <ホスト名>
ipconfig /displaydns

Linux

dig <ホスト名>
nslookup <ホスト名>
cat /etc/resolv.conf

確認項目

DNSサーバーのIPアドレスは正しいか
DNSサーバーへ到達できるか
正しいIPアドレスが返されるか
内部用と外部用のレコードが混在していないか
古いキャッシュが残っていないか
CNAMEの参照先が正しいか
複数のDNSサーバーで結果が異ならないか

DNSサーバーを指定して確認する例

nslookup example.internal 192.168.10.53

名前解決の切り分けでは、問い合わせ先のDNSサーバーを明示すると、端末設定の問題とDNSサーバー側の問題を分けやすくなります。

キャッシュ削除は調査結果を変化させる操作です。最初から削除するのではなく、現在のキャッシュや応答結果を記録したうえで実施します。

手順8：TCP・UDPポートを確認する

pingが成功しても、業務システムへ接続できるとは限りません。

WebシステムであればTCP 443、SSHであればTCP 22など、実際に使用するポートへの接続を確認します。

Windows

Test-NetConnection <接続先> -Port 443

詳細表示：

Test-NetConnection <接続先> -Port 443 -InformationLevel Detailed

Linux

nc -vz <接続先> 443
curl -vk https://<接続先>/
ss -antp

結果の考え方

状態	主な原因候補
ping成功・ポート接続成功	アプリケーション、認証、ブラウザーなど
ping成功・ポート接続失敗	FW、ACL、サーバー待受、ロードバランサー
SYN送信後、応答なし	経路、FW、サーバー停止、復路
RSTが返る	宛先到達済み、ポート未待受など
TCP接続後に切断	TLS、認証、アプリケーション処理
一部端末だけ失敗	端末FW、プロキシ、送信元制御

図8：TCP接続確認の基本

sequenceDiagram
    participant C as クライアント
    participant F as FW・ネットワーク
    participant S as サーバー

    C->>F: SYN
    F->>S: SYN
    S-->>F: SYN/ACK
    F-->>C: SYN/ACK
    C->>F: ACK
    F->>S: ACK

    Note over C,S: 3ウェイハンドシェイク成立
    C->>S: アプリケーション通信

SYNを送信しているのに応答が返ってこない場合は、ファイアウォールだけでなく、戻りのルートやサーバー側の待受状態も確認します。

手順9：ACL・ファイアウォール・NATを確認する

特定の送信元、宛先、プロトコルだけが通信できない場合は、ACLやファイアウォールの可能性があります。

確認項目

送信元IPアドレス
宛先IPアドレス
プロトコル
送信元・宛先ポート
通信方向
適用インターフェース
ACLの評価順序
暗黙のdeny
ファイアウォールのセッション
NAT変換
戻りのルート
ログのdeny記録

Cisco機器の確認例

show access-lists
show ip interface
show ip nat translations
show ip nat statistics
show logging

5タプルで整理する

通信を確認するときは、次の5つを明確にします。

送信元IP
宛先IP
送信元ポート
宛先ポート
プロトコル

例

送信元IP：192.168.10.20
宛先IP：192.0.2.50
送信元ポート：動的ポート
宛先ポート：443
プロトコル：TCP

「サーバーにつながらない」だけでは、ファイアウォールのログを正確に検索できません。

手順10：パケットキャプチャーで事実を確認する

各機器の設定やログだけで判断できない場合は、パケットキャプチャーを使用します。

パケットキャプチャーで確認できること

ARP要求・応答
DNS問い合わせ・応答
ICMPの要求・応答
TCPのSYN・SYN/ACK・RST
再送
重複ACK
TLS通信の開始状況
応答時間
クライアントとサーバーのどちらが切断したか

Wiresharkでは、表示フィルターを使用して、確認対象のパケットだけを絞り込めます。(Wireshark)

よく使うWireshark表示フィルター

arp
icmp
dns
ip.addr == 192.0.2.50
tcp.port == 443
tcp.flags.syn == 1
tcp.flags.reset == 1
tcp.analysis.retransmission

Linuxのtcpdump例

tcpdump -ni any host 192.0.2.50

ポートを指定する場合：

tcpdump -ni any host 192.0.2.50 and port 443

ファイルへ保存する場合：

tcpdump -ni any host 192.0.2.50 -w incident.pcap

パケットが消える場所を探す

flowchart LR
    A[クライアントで取得] -->|SYNあり| B[クライアントから送信済み]
    B --> C[FW内側で取得]
    C -->|SYNあり| D[FWまで到達]
    D --> E[サーバー側で取得]
    E -->|SYNなし| F[FW・途中経路で遮断]
    E -->|SYNあり| G{SYN/ACKは返るか}
    G -->|返らない| H[サーバー・OS・待受を確認]
    G -->|返る| I[復路・FWセッションを確認]

キャプチャーの基本原則

1か所だけで取得するのではなく、可能であれば通信経路の複数地点で取得します。

例えば、クライアント側でSYNを確認でき、サーバー側で確認できなければ、その間のネットワークで通信が失われています。

サーバー側でSYNとSYN/ACKを確認できるのに、クライアント側でSYN/ACKを確認できなければ、復路の経路やファイアウォールを疑います。

実践ケース：業務システムへ接続できない

次の障害を例に、実際の切り分け手順を確認します。

障害申告

営業部のPCから、社内業務システムを開けない。
ブラウザーには「接続がタイムアウトしました」と表示される。

ステップ1：影響範囲を確認する

確認結果：

営業部の複数端末で発生
他部署では正常
営業部の端末からインターネットは利用可能
業務システム以外の社内システムは利用可能

この時点で、次の可能性が高くなります。

営業部VLANから業務システムへの通信制御
営業部VLAN固有のルーティング
ファイアウォールポリシー
業務システム側の送信元IP制限

ステップ2：名前解決を確認する

nslookup business-system.example.internal

結果：

Name:    business-system.example.internal
Address: 192.0.2.50

正しいIPアドレスが返っているため、DNSは原因候補から外します。

ステップ3：デフォルトゲートウェイを確認する

ping 192.168.10.1

結果：

Reply from 192.168.10.1

端末からデフォルトゲートウェイまでの通信は正常です。

ステップ4：宛先IPへの到達性を確認する

ping 192.0.2.50

結果：

Request timed out.

ただし、ICMPが拒否されている可能性があるため、pingだけでは判断しません。

ステップ5：TCP 443を確認する

Test-NetConnection 192.0.2.50 -Port 443

結果：

TcpTestSucceeded : False

他部署の正常な端末で同じ確認を実行します。

TcpTestSucceeded : True

これにより、サーバー全体の停止ではなく、営業部ネットワーク固有の問題である可能性が高くなります。

ステップ6：ファイアウォールログを確認する

5タプルを整理します。

送信元：営業部VLAN 192.168.10.0/24
宛先：業務システム 192.0.2.50
プロトコル：TCP
宛先ポート：443

ファイアウォールログを確認したところ、営業部VLANからのTCP 443がdenyされていました。

直前のポリシー変更で、営業部VLANの許可ルールが削除されていたことが判明しました。

ステップ7：復旧と確認

承認を得たうえでルールを修正し、次を確認します。

営業部の複数端末から接続できる
他部署の通信に影響がない
ファイアウォールで許可ログが記録される
業務システムの操作が正常に完了する
監視アラートが発生していない

切り分け結果

原因：
ファイアウォールのポリシー変更時に、
営業部VLANから業務システムへの許可ルールが削除されていた。

暫定対応：
許可ルールを復元し、通信を再開した。

恒久対応：
ポリシー変更前後の差分確認と、
部署別の疎通試験を変更手順へ追加する。

障害対応でよくある失敗

1．最初からすべての機器へログインする

影響範囲を確認せず、ルーターやスイッチの設定を順番に眺めると、調査に時間がかかります。

最初に、端末固有、VLAN単位、拠点単位、全体障害のどれかを判断します。

2．pingだけで正常・異常を判断する

pingは便利ですが、ICMPだけを確認しています。

実際のサービスがTCP 443を使用しているなら、TCP 443への接続も確認する必要があります。

3．変更履歴を確認しない

障害の直前に設定変更、配線変更、バージョンアップが行われている場合、その変更が重要な手掛かりになります。

ただし、「変更があったから、それが原因」と決めつけず、切り戻しや比較によって検証します。

4．往路だけを確認する

通信は行きと戻りの両方が必要です。

クライアントからサーバーへのルートが存在しても、サーバーからクライアントへの戻りのルートがなければ通信は成立しません。

5．調査と変更を同時に行う

設定を変更しながら調査すると、どの操作で状態が変化したか分からなくなります。

変更前後で次を記録しましょう。

変更前の状態
実施した操作
変更後の状態
疎通結果
ログの変化

6．原因確定まで報告しない

障害対応では、原因が分からない段階でも報告が必要です。

重要なのは、推測を事実のように伝えないことです。

原因が分からない段階での報告方法

障害報告では、次の4つを分けて伝えます。

障害対応中の報告構成

flowchart LR
    A[事実] --> B[影響]
    B --> C[現在の対応]
    C --> D[次の確認]
    D --> E[次回報告]

初動報告の例

現在、営業部の複数端末から社内業務システムへ
接続できない事象を確認しています。

インターネットおよび他の社内システムは利用可能であり、
現時点では営業部ネットワークから対象システムへの通信に
問題がある可能性を調査しています。

現在、通信経路とファイアウォールログを確認しています。
新しい情報が判明次第、改めて報告します。

原因を断定してはいけない例

ファイアウォールが原因です。

まだ確認できていない段階では、次のように伝えます。

現在の確認結果から、ファイアウォールを含む通信制御部分に
原因がある可能性を調査しています。

障害対応メモのテンプレート

■発生日時
YYYY年MM月DD日 HH:MM

■検知日時
YYYY年MM月DD日 HH:MM

■申告者
部署・氏名

■対象
端末、ユーザー、拠点、VLAN、システム

■症状
何が、どのように利用できないか

■影響範囲
対象人数、対象部署、対象サービス

■正常な範囲
利用できる端末、部署、サービス

■直前の変更
設定変更、配線変更、メンテナンス

■確認結果
時刻：
確認内容：
結果：
判断：

■原因
確定した事実を記載

■暫定対応
復旧のために実施した内容

■恒久対応
再発防止策

■復旧日時
YYYY年MM月DD日 HH:MM

現場で使える切り分けチェックリスト

障害受付

　□　発生時刻を確認した
　□　症状を具体化した
　□　エラーメッセージを保存した
　□　対象ユーザーと端末を確認した
　□　正常だった最終時刻を確認した
　□　直前の変更作業を確認した

影響範囲

　□　1台だけか複数台か確認した
　□　同じVLAN・フロア・拠点か確認した
　□　他のサービスが利用できるか確認した
　□　正常な端末との違いを確認した

レイヤー1・2

　□　ケーブルとリンク状態を確認した
　□　インターフェースエラーを確認した
　□　VLANを確認した
　□　MACアドレスの学習を確認した
　□　ARPを確認した
　□　STP・EtherChannelを確認した

レイヤー3

　□　IPアドレスを確認した
　□　サブネットマスクを確認した
　□　デフォルトゲートウェイを確認した
　□　ルーティングを確認した
　□　戻りのルートを確認した
　□　tracerouteを正常環境と比較した

DNS・アプリケーション

　□　IP指定とホスト名指定を比較した
　□　DNS応答を確認した
　□　対象TCP・UDPポートを確認した
　□　ACL・FWログを確認した
　□　NAT・セッションを確認した
　□　サーバーの待受状態を確認した

復旧後

　□　複数端末で復旧を確認した
　□　関連サービスへの影響を確認した
　□　監視状態を確認した
　□　変更内容を記録した
　□　原因と対応を報告した
　□　再発防止策を整理した

英語ドキュメントを検索するときのキーワード

海外ベンダーの資料やナレッジベースを検索するときは、製品名と症状を組み合わせます。

検索例

interface input errors troubleshooting
VLAN connectivity issue
ARP incomplete troubleshooting
TCP SYN no response
asymmetric routing firewall
DNS resolution intermittent
packet loss troubleshooting
site-to-site VPN tunnel down

障害対応でよく使う英単語

英語	意味
unreachable	到達不能
timeout	タイムアウト
intermittent	断続的
packet loss	パケット損失
latency	遅延
retransmission	再送
dropped	破棄された
mismatch	不一致
outage	サービス停止・障害
workaround	暫定回避策
root cause	根本原因
affected users	影響を受けた利用者