ネットワークのトラブルシューティング方法論:系統的アプローチ

方法論のマットレスの理由

問題:

ソリューション:

ハプハザードのトラブルシューティングのコスト:

はじめに:ネットワークに適用される科学的方法

ネットワークのトラブルシューティングは、基本的に科学的方法の演習です。

オブザーブ
仮説を形成する
仮説をテストする
結果の分析
修正の実装
検証

この記事では、一般的な下落を防ぐネットワークトラブルシューティングのための構造フレームワークを提供します。

確認バイアス(最初の推測をサポートする証拠だけを探します)
診断なしでランダムな変化(「スプレーと祈り」のアプローチ)
根本原因の代わりに症状を修正
試したものを文書化することなく、円のデバッグ

5つの主要な質問

技術的な診断に潜入する前に、これらの5つの重要な質問に答えて、調査範囲を絞り込みます。

質問1:最近何が変化したのか?

変更管理ログの確認
コンフィギュレーション管理システムで最近のコミットを確認する
「昨日働いているの?」

質問2:誰が影響を受けますか?

1つの装置: ローカルの問題と同様に(NIC、ケーブル、設定)
1つのサブネット: ゲートウェイ、DHCP、スイッチの問題
みんな: コアインフラ、ISP、ワイドスプレッドの問題
特定のアプリ: アプリケーションサーバ、ファイアウォールルール、またはDNS

↓

質問3:定数または断続的ですか?

定数: 故障(ケーブルカット、誤設定、ダウンサービス)
タイムベース: 営業時間、スケジュールされたプロセスの間の混雑
断続的/ランダム: 複式アパートの不一致、ハードウェア、断続的なリンク失敗

↓

質問4:それを再生産できますか?

はい: 診断が容易 (仮説をテストできます)
いいえ: 監視/ログを設定し、再発を待ちます

↓

質問5: 他の側面が見えるのは何ですか。

クライアントの視点とサーバーの視点
ソースと目的地のパケットキャプチャ
対称ルーティング? 送信対. 受信のための異なるパス?

OSIモデルベースの診断アプローチ

OSIモデルはトラブルシューティングのための構造化されたフレームワークを提供します。レイヤー1(物理)上方、またはレイヤー7(アプリケーション)下方から、症状に応じて動作します。

ボトムアップアプローチ(層1→層7)

使用する場合:

層 1: 物理的

↓

レイヤー2:データリンク

↓

層3:ネットワーク

↓

層4:輸送

↓

レイヤー5-7:セッション/プレゼンテーション/アプリケーション

トップダウンアプローチ(層7→層1)

使用する場合:

例:

レイヤー7(SharePointサービスが稼働していますか?) DNS は IP を正しいかを解決し、必要な場合にのみダウンします。

決定ツリー:レイヤー1、2、3ですか?

このクイック診断ツリーを使用して、どのレイヤーが失敗しているかを識別します。

ローカルホスト(127.0.0.1)をpingできますか?

↓ いいえ

問題:オペレーティングシステム/ソフトウェアの問題

↓ はい

自分のIPアドレスをpingできますか?

↓ NO

問題:層1/2 -ローカルネットワークインターフェイス

↓ YES

デフォルトのゲートウェイをpingできますか?

↓ NO

問題:層1/2 - ローカルネットワーク

↓ YES

IPアドレスでリモートホストをpingできますか?

↓ NO

問題: 層 3 - ルーティング

↓ YES

DNS(nslookup hostname)を解決できますか?

↓ NO

問題: DNS の構成

↓ YES

アプリケーションポート(telnetホストポート)に到達できますか?

↓ NO

問題: 防火壁/港の妨害

↓ YES

ネットワークがOK - アプリケーション層の問題

分離の技術

根本原因に関する仮説がある場合、これらの分離技術を使用して確認または拒否します。

1. 部品を系統的に取り替えて下さい

ヒント:

有名なよいケーブルが付いているスワップパッチケーブル
別のスイッチポートのテスト
異なるNIC(またはUSBネットワークアダプタ)を試してください
異なるクライアントデバイスからのテスト
異なるVLAN/サブネットに移動

2. 複数のポイントでのパケットキャプチャ

ソース、中間点、宛先でトラフィックをキャプチャして、パケットがドロップまたは変更された場所を特定します。

# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com

# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com

# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue

3. ループバックのテスト

外部変数を単一デバイス内の接続をテストすることで排除します。

# Test TCP stack without network
ping 127.0.0.1

# Test application listening locally
telnet localhost 80

# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing

4. 既知のベースラインの比較

作業システムに対する構成と動作を比較します。

# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
     <(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff <(ssh router1 "show ip route") \
     <(ssh router2 "show ip route")

トラブルシューティング中にドキュメント

適切な文書は、それを実現せずに複数の時間を試すと、円のデバッグを防ぐことができます。

テンプレートのトラブルシューティング

Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01

Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds

Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found

Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

Time to Resolution: 25 minutes

なぜドキュメントマター:

リアルワールド・ケース・スタディ

事例1:「ネットワークはスロー」(実際には:TCPウィンドウの排気)

シンプトム

データベースのアプリケーション応答時間は、<100ms〜5秒に分解されます。「ネットワークレイテンシ」を非難

初期仮定(間違った)

ネットワーク輻輳
WANリンク飽和
ファイアウォールボトルネック

診断プロセス

ピンテスト:
帯域幅テスト(iperf):
パケットキャプチャ:
サーバー点検:

根本原因

データベースサーバ OS バッファは、帯域幅 × 遅延製品に対しても小型化しました。 TCPウィンドウは、送信者を強制的に待機します。

ソリューション

# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216

レッスン学習

想定しない:

ケーススタディ2:断続的なコネクティビティ(実際には:デュプレックス・ミスマッチ)

Symptom

サーバー接続は、特に負荷下で、ランダムにドロップします。時には、完全に反応しなくなることがあります。

Initial Assumptions (Wrong)

故障 NIC
悪いケーブル
ハードウェアの問題の切り替え

Diagnostic Process

インターフェイス点検:
エラーカウンター:
レイトの衝突:

Root Cause

自動交渉は失敗しました。サーバーは双方向通信を交渉し、スイッチは半二重に戻って落ちました。両側が同時に送信しようとすると、衝突は負荷下でのみ発生します。

Resolution

! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full

Lesson Learned

両端をチェック:

ケーススタディ3:「特定のウェブサイトにリーチできない」(実際には:MTU/PMTUDブラックホール)

Symptom

一部のウェブサイト(Google、Yahoo)を閲覧できますが、他のウェブサイト(銀行ウェブサイト、会社ポータル)では閲覧できません。小さな HTTP リクエストが機能し、大きなページがタイムアウトしました。

Initial Assumptions (Wrong)

DNSの問題
特定のサイトをブロックファイアウォール
ISPルーティングの問題

Diagnostic Process

DNSの解像度:
ピンテスト:
小さいHTTP (要求カール):
大きいダウンロード:
MTUテスト:ping -M do -s 1472ping -M do -s 1473
ICMPの監視:

Root Cause

VPN トンネルは MTU を 1400 に減らしましたが、ファイアウォールは ICMP 「フラグメンテーションニーズ」メッセージをブロックしました。パスMTUディスカバリー(PMTUD)は、MTUの黒い穴を作るために動作できませんでした。小さいパケットは、DFビットセットの大きなパケットがサイレントに落ちていました。

Resolution

! Implemented TCP MSS clamping on router
interface Tunnel0
 ip tcp adjust-mss 1360

! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big

Lesson Learned

サイズの問題:

ケーススタディ4:VoIP品質の問題(実際には:QoSの構成)

Symptom

音声通話は、音声、断続的なドロップアウトが刻まれていました。営業時間(午前9時～午後5時)にのみ発生します。

Initial Assumptions (Wrong)

十分な帯域幅
VoIPサーバーの積み過ぎ
ISP接続品質

Diagnostic Process

帯域幅テスト:
QoSの点検:
急な点検:
パケットキャプチャ:

Root Cause

QoSの方針は存在しましたが、帯域幅の配分は後方にありました:最高効果は60%を得ました、声は5%を得ました。データトラフィックが増加した営業時間中は、キューオーバーフローにより音声パケットが低下しました。

Resolution

! Corrected QoS policy
policy-map WAN-QOS
 class VOICE
  priority percent 33
 class VIDEO
  bandwidth percent 25
 class CRITICAL-DATA
  bandwidth percent 20
 class class-default
  bandwidth percent 22

Lesson Learned

時間ベースの問題 = 容量:

Symptom によるコマンド参照

シンプトム	レイヤー	コマンドを実行する	探すべきこと
リンクライトなし	層 1	`show interfaces ethtool eth0`	状態: 、キャリア無し、ケーブルのunplugged
パケットロス	層 1/2	`show interfaces show interfaces counters errors`	CRCのエラー、ラン、巨人、衝突、遅延衝突
ゲートウェイをpingできません	レイヤー2	`arp -a show mac address-table show spanning-tree`	ARPエントリーなし、MACは学習しない、STPブロック
リモートサブネットに到達できません	層 3	`traceroute show ip route show ip route summary`	ルートを欠く、次のホップ、ルーティングループが間違っている
接続拒否	層 4	`telnet host port netstat -an tcpdump`	聴くことのないサービス, ファイアウォールブロック, TCP RST
スローパフォーマンス	層 4+ (44)	`ping (RTT) iperf3 tcpdump show interfaces`	高レイテンシ、帯域幅制限、TCPの送金、ゼロウィンドウ
hostname を解決できません	層 7	`nslookup dig cat /etc/resolv.conf`	DNSサーバーが到達不能で、DNSの設定が間違っている、NXDOMAIN
断続的な低下	Layer 1/2	`ping -f (flood) show logging show interfaces`	複式アパートの不一致、ケーブル、STPの再構成失敗
他の人ではなく、時々働く	複数の	`Extended ping Packet capture Interface statistics`	負荷分散問題、ECMPのasymmetry、州のテーブルのoverflow

Escalate のとき

ベンダー TAC またはシニアエンジニアにエスカレーションするときを知っている。ときにエスカレート:

知識ベースでトラブルシューティングの手順をすべて疲れていました
問題は、あなたが持っていないアクセス/許可を必要とします
問題は、ベンダーソフトウェアのバグやハードウェアの不具合を含む
業務への影響は極めて重要で時間感度が高い
複数のチームがコラボレーションする必要があります(アプリケーション+ネットワーク+サーバー)

エスカレーションの前に:

完全な症状の説明
発行開始時刻
診断コマンドの実行と出力
設定バックアップ
パケットキャプチャ(関連する場合)
すでに試したこと

パーソナルナレッジベースの構築

トラブルシューティングは学習機会です。個人的な知識ベースを構築する:

1. トラブルシューティングジャーナルを作成する

# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md  # Index of all issues

# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation

2. コマンドチートシートを作成する

トラブルシューティング中に素早く参照するためのシナリオで頻繁に使用されるコマンドを整理します。

3. ネットワークを文書化

トポロジー図(レイヤー2とレイヤー3)
IPアドレススキームの文書
VLANの割り当て
標準構成(テンプレート)
既知のベースライン(問題前のインターフェイス統計)

避けるべき共通の反パターン

××DON'T:診断なしでランダムな変化を作る

問題を理解しずに構成を変更すると、多くの場合、物事が悪化したり、実際の問題をマスクしたりします。

DON'T:ネットワークを障害で常に仮定して下さい

多くの場合、「ネットワークの問題」は、アプリケーション、サーバー、またはクライアント側の問題です。非難を受け入れる前に証拠を収集します。

〇 DON'T:トラブルシューティング手順の文書化をスキップする

既に行ったテストを繰り返す時間を無駄にするか、試した同僚に説明できないか。

〇 DON'T: 断続的な問題を無視する

断続的な問題は、多くの場合、障害の早期警告兆候です。重要になる前にそれらを調査します。

〇 DON'T: 根本原因の代わりに症状を修正

デバイスを再起動すると、サービスを復元する可能性がありますが、再起動が必要なWHYが見つからない場合、問題は再発します。

概要:システム障害チェックリスト

✓ 始める前に

5つの重要な質問に答える(変更されたこと) 誰が影響を受けますか? 定数または断続的? Reproducibleか。反対側は何が見えますか?
初期症状とユーザーレポートの収集
最近の変更やメンテナンスの確認

✓ トラブルシューティング中に

OSIレイヤー(ボトムアップまたはトップダウン)による作業方法論
テスト時に1変数を一度に変更する
すべてのテストと結果の文書化
パケットキャプチャを使用して実際のトラフィックの動作を確認します
既知のベースラインと比較

✓ 決断の後

実際に問題を解決した問題を修正
文書の根本原因と解像度
知識ベースの更新
設定が変更された場合、ドキュメントの更新
考慮: 監視は、この先ほどキャッチした?

コンテンツ

ネットワークのトラブルシューティングは、科学と芸術の両方です。科学は、診断ツールを正しく使用し、プロトコルを理解する、系統的な方法論に従います。体験からパターンを認識し、エスカレーションをするときに知る、症状に基づいて最初に実行するテストがわかっています。

この記事で概説した系統的アプローチに従うことで、正しい質問をすることで、OSIモデルを操作し、手順を文書化し、各問題から学習することで、トラブルシューティングでより効率的になり、無駄な時間と誤った修正につながる一般的な落とし穴を回避します。

覚えている:

最終更新日: 2026年2月2日 | 投稿者: Baud9600 テクニカルチーム