このページでは、第4章「検証とトラブルシューティング」で学んだ内容を使い、 パケット解析と障害切り分けを実務に近い形で演習します。
第4章 実践演習
パケット解析と障害切り分け
「通信できません」という申告に対して、 構成図・コマンド・パケットキャプチャー・ログを確認し、 原因を根拠とともに説明できるかを確認します。
トラブルシューティングで重要なのは、 知っているコマンドを片っ端から実行することではありません。
「正常な範囲はどこまでか」 「どの確認結果から何を除外できるか」 「次に何を確認すれば原因を絞れるか」 を順番に考えることが重要です。
この実践演習で確認するスキル
- ARP・TCP・DNSパケットを読み取れる
- VLAN設定ミスをコマンド結果から特定できる
- STPのポート状態から通信経路を判断できる
- ルーティングテーブルから経路障害を判断できる
- DHCP・DNS・NATを段階的に切り分けられる
- 遅延・パケットロスの発生区間を絞り込める
- 調査結果と根拠を文章で報告できる
- 推測と確認済みの事実を分けて説明できる
演習の進め方
各ケースでは、利用者からの申告と調査結果が提示されます。 解答を見る前に、次の順番で考えてください。
本演習では、「最初から設定を全部見る」は禁止です。
与えられた情報から仮説を立て、 必要な確認だけを行うつもりで問題を解いてください。
採点基準：100点満点
正解だけでなく、理由まで説明できたかを確認してください。
共通ネットワーク構成
ある小規模オフィスでは、営業部・技術部・サーバーを VLANで分割しています。
演習ネットワーク
VLAN 10
192.168.10.10
STP
STP
VLAN 20
DHCP
NAT
TCP/443
192.168.30.10
DHCP / DNS
VLAN 20：192.168.20.0/24（技術部）
VLAN 30：192.168.30.0/24（サーバー）
R1：各VLANのデフォルトゲートウェイ
Server：DHCP・DNSサービスを提供
インターネット接続：R1でNAT
基本方針： 障害時は「端末 → L2 → L3 → サービス → 外部」の順に、 正常な地点を積み上げていきます。
WiresharkでWebアクセスを読み取る
PC-Aからブラウザで https://www.example.test/ へアクセスしました。
パケットキャプチャーには、次の通信が記録されています。
| No. | 送信元 | 宛先 | Protocol | Info |
|---|---|---|---|---|
| 1 | 192.168.10.10 | Broadcast | ARP | Who has 192.168.10.1? |
| 2 | 192.168.10.1 | 192.168.10.10 | ARP | 192.168.10.1 is at 00:11:22:33:44:55 |
| 3 | 192.168.10.10 | 192.168.30.10 | DNS | Standard query A www.example.test |
| 4 | 192.168.30.10 | 192.168.10.10 | DNS | A 203.0.113.50 |
| 5 | 192.168.10.10 | 203.0.113.50 | TCP | 51532 → 443 [SYN] |
| 6 | 203.0.113.50 | 192.168.10.10 | TCP | 443 → 51532 [SYN, ACK] |
| 7 | 192.168.10.10 | 203.0.113.50 | TCP | 51532 → 443 [ACK] |
課題1-1．No.1〜2では何を確認していますか
解答を見る
PC-Aがデフォルトゲートウェイ 192.168.10.1のMACアドレス をARPで確認しています。
No.1がARP Request、No.2がARP Replyです。
課題1-2．DNS名前解決は成功していますか
根拠：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答を見る
成功しています。
PC-AからDNSサーバーへ問い合わせが送られ、 DNSサーバーから 203.0.113.50 というAレコードの応答が返っているためです。
課題1-3．TCP接続はどこまで成功していますか
解答を見る
SYN → SYN/ACK → ACK が確認できています。
TCPの3ウェイハンドシェイクが完了しているため、 PC-AからWebサーバーのTCP/443まで接続できています。
PC-Bだけ通信できない
PC-Aは正常に通信できますが、 PC-Bからデフォルトゲートウェイへpingできません。
PC-Bの設定
SW2の確認結果
課題2-1．PC-BのIP設定に問題はありますか
解答を見る
提示された情報だけを見る限り、 PC-BのIPアドレス・サブネットマスク・デフォルトゲートウェイは VLAN 20の設計と一致しています。
課題2-2．最も疑わしい設定箇所はどこですか
解答を見る
SW2のトランクポートGi0/1です。
Allowed VLANが 10,30 となっており、VLAN 20が許可されていません。
そのため、PC-Bが所属するVLAN 20のフレームを トランクリンク経由で転送できません。
課題2-3．修正後に何を確認しますか
解答例を見る
- トランクのAllowed VLANに20が含まれたこと
- PC-Bから192.168.20.1へpingできること
- PC-Bから他VLANへの必要な通信ができること
- 既存のVLAN 10・30の通信に影響がないこと
- MACアドレステーブルにPC-BのMACが正しいVLANで学習されること
冗長リンク追加後にネットワークが不安定になった
SW1とSW2の間に冗長リンクを追加しました。 その直後から、一時的に通信が不安定になるという申告がありました。
課題3-1．SW2のGi0/2がDISCになっているのは異常ですか
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答を見る
正常です。
SW2にはSW1へ到達する冗長な経路があり、 Gi0/1がRoot Port、Gi0/2がAlternate Portとなっています。
RSTPがGi0/2をDiscarding状態にすることで、 Layer 2ループを防止しています。
課題3-2．Gi0/1が切断した場合、期待する動作は何ですか
解答を見る
Gi0/1の経路が利用できなくなった場合、 Alternate PortであるGi0/2が新しい転送経路として Forwardingへ移行することが期待されます。
課題3-3．STP障害で確認する情報を4つ挙げてください
② ＿＿＿＿＿＿
③ ＿＿＿＿＿＿
④ ＿＿＿＿＿＿
解答例を見る
- ルートブリッジが想定どおりか
- 各ポートのRoleとState
- Root Path Cost
- 物理リンクのUp/Down状態
- STPモードやVLANごとの状態
- Topology Changeの発生状況
「インターネットにつながらない」を切り分ける
PC-Bの利用者から、 「インターネットにつながらない」と連絡がありました。
次の調査結果を上から順番に確認してください。
確認1：PC-BのIP設定
確認2：ping
確認3：DNS
課題4-1．DHCPを最優先で疑うべきですか
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答を見る
いいえ。
PC-Bは192.168.20.21/24、 デフォルトゲートウェイ192.168.20.1、 DNSサーバー192.168.30.10を取得しています。
さらにデフォルトゲートウェイへ疎通できているため、 この時点ではDHCP障害を最優先で疑う必要はありません。
課題4-2．ルーティング障害の可能性は高いですか
解答を見る
優先度は低いと判断できます。
PC-Bから別VLANのDNSサーバーへ到達でき、 さらに外部IPアドレス8.8.8.8へもpingできています。
少なくともPC-Bから外部ネットワークまでの IP到達性は確認できています。
課題4-3．最も疑わしい障害箇所はどこですか
解答を見る
DNSサーバーまたはDNS名前解決処理 が最も疑わしい状態です。
DNSサーバー192.168.30.10自体へのIP疎通は成功していますが、 nslookupでは「Server failed」となっています。
したがって、 「ネットワーク的にDNSサーバーへ届かない」のではなく、 DNSサービスや上位DNSへの問い合わせなどを確認する段階です。
追加確認
DNSを修正したところ名前解決は成功しましたが、 Webサイトだけ表示できません。
課題4-4．Webサイトを表示できない原因を特定してください
解答を見る
ACL INTERNET-FILTER でVLAN 20から外部への TCP/443がdeny されています。
pingはICMPなので成功しますが、 HTTPS通信はTCP/443を使用するためWebサイトを表示できません。
「pingが通る＝すべてのアプリケーション通信が正常」 ではないことがポイントです。
通信はできるが遅い
PC-Aから業務サーバーへの通信は成功しますが、 利用者から「画面表示が遅い」と申告されています。
ping結果
SW1 uplinkの確認
課題5-1．「通信断」と判断してよいですか
解答を見る
完全な通信断ではありません。
応答しているパケットもありますが、 20％のパケットロスと大きな遅延の揺らぎが確認されています。
「通信できる／できない」の二択ではなく、 品質劣化として調査する必要があります。
課題5-2．SW1 Gi0/1で注目すべき値は何ですか
② ＿＿＿＿＿＿
③ ＿＿＿＿＿＿
解答を見る
- 850Mbps / 910Mbpsという高いトラフィック量
- input errors
- output drops
特にoutput dropsが増加し続けている場合、 インターフェースの送信処理でパケットが廃棄されている可能性があります。
課題5-3．次に何を確認しますか
解答例を見る
- input errors / output dropsが継続して増えるか確認する
- インターフェースの帯域使用率を時間軸で確認する
- 対向ポートのエラー・ドロップも確認する
- どの通信が帯域を使用しているか確認する
- 遅延やロスが発生する時間帯とトラフィック量を比較する
- 必要に応じてパケットキャプチャーで再送の有無を確認する
最終課題：障害調査報告を作成する
最後に、CASE 4の障害について、 上司または顧客へ報告する文章を作ってください。
技術用語だけを並べるのではなく、 事象・影響・確認結果・原因・対応・確認結果 を分けて整理します。
障害調査報告テンプレート
【影響範囲】
【確認結果】
【原因】
【対応】
【復旧確認】
報告例を見る
【事象】
技術部PCからインターネット上のWebサイトへHTTPS接続できない事象が発生しました。
【影響範囲】
VLAN 20に所属する技術部端末から、外部TCP/443宛ての通信に影響していました。
【確認結果】
PCのIPアドレス取得、デフォルトゲートウェイへの疎通、
DNSサーバーへの疎通、外部IPアドレスへのICMP疎通は正常でした。
DNS障害修正後は名前解決も正常となりましたが、
HTTPS通信のみ失敗していました。
【原因】
R1に適用されているACLで、
VLAN 20から外部宛てのTCP/443が拒否されていたことが原因です。
【対応】
通信要件を確認したうえでACLを修正し、
必要なHTTPS通信を許可しました。
【復旧確認】
VLAN 20の端末から対象WebサイトへHTTPS接続できること、
既存の許可・拒否通信へ意図しない影響がないことを確認しました。
実務で評価されるのは「原因を当てたこと」だけではありません。
どの確認結果から原因を絞り、 何を正常と判断し、 修正後に何を確認したのかまで説明できることが重要です。
自分の言葉で説明する課題
「ネットワーク障害が発生したとき、 どのような順番で調査しますか？」
次の言葉をすべて使い、1分程度で説明してください。
- 構成図
- 正常範囲
- ping
- ルーティング
- パケットキャプチャー
- 根拠
説明例を見る
ネットワーク障害が発生した場合は、まず構成図を確認し、 送信元から宛先までどの機器と経路を通るのかを整理します。
次にpingなどを使って、どこまで通信できているかを確認し、 正常範囲と異常範囲の境界を絞ります。 必要に応じてVLAN、STP、ルーティング、 DHCP・DNS・NATなどを確認します。
コマンド結果だけで判断できない場合は、 パケットキャプチャーを取得し、 ARP、DNS、TCPなどがどの段階まで成功しているかを確認します。
最後に、推測ではなく確認した事実を根拠として、 原因・対応・復旧確認結果を報告します。
自己採点と修了判定
| 得点 | 判定 | 次に行うこと |
|---|---|---|
| 90〜100点 | 十分理解できています | 第5章「実務への接続」へ進みましょう。 |
| 80〜89点 | 修了ライン | 間違えたケースだけ復習してから次へ進みましょう。 |
| 60〜79点 | もう一度復習 | 原因を当てるだけでなく、根拠を説明できるか確認しましょう。 |
| 59点以下 | 第4章を再確認 | 31〜40の記事を順番に復習してから再挑戦しましょう。 |
おすすめ修了基準：80点以上
ただし、点数以上に重要なのは 「なぜその原因と判断したのか」を自分の言葉で説明できることです。
第4章で身につけた障害切り分けの型
第4章で最も重要なのは、 個々のコマンドを暗記することではありません。
「どこまで正常か」を確認しながら、 障害地点を少しずつ絞り込む考え方 を身につけることです。
まとめ
- パケット解析ではARP・DNS・TCPを通信の流れとして確認する
- VLAN障害ではAccess VLANとTrunkのAllowed VLANを確認する
- STPではRoot Bridge、Port Role、Port State、Costを確認する
- ルーティング障害では送信経路だけでなく戻り経路も確認する
- DHCP・DNS・NATは、それぞれの処理段階を分けて確認する
- pingが成功してもTCP/UDPの業務通信が成功するとは限らない
- 遅延・パケットロスでは帯域使用率、エラー、ドロップを確認する
- 障害報告では、事象・影響・確認結果・原因・対応・復旧確認を整理する
障害切り分けとは「原因を予想する作業」ではなく、 確認結果を積み上げて原因候補を減らしていく作業です。
次は第5章「実務への接続」へ
第4章では、構成・コマンド・パケットを使って 技術的に障害を切り分ける方法を学びました。
第5章では、実際の案件で必要になる 構成図、パラメータシート、作業手順書、 試験、変更作業、障害報告、ベンダー問い合わせ へ進みます。
コメント