0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

NW障害時の手順

0
Posted at

1.初動対応:まず切り分けの軸を立てる

最初の5分でやるべきことは「どこが悪いかの当たりをつける」こと。
以下の4軸で状況を分類すると、後の調査が一気に早くなる。

  • 範囲 — 全社 / 拠点単位 / VLAN単位 / 特定端末のみ
  • 症状 — 通信不可 / 遅延 / 断続的 / 特定サービスのみ
  • 影響レイヤ — L1(物理)/ L2(VLAN)/ L3(ルーティング)/ L4-7(アプリ)
  • 発生タイミング — 定時作業直後 / 機器更新直後 / 無操作時に突然

この4つを最初に押さえると、後続の調査が迷わない。

2.物理層(L1)チェック:最速で切り分けできる部分

ネットワーク障害の3〜4割は物理層が原因。

  • ケーブル抜け・断線・曲げ破損
    → スイッチのポートLED(Link/Act)を確認
  • PoE機器の電力不足
    → AP・IP電話が落ちていないか
  • スイッチの電源・ファン異常
    → 再起動や温度異常ログ
  • 光モジュールの不良
    → Tx/Rxパワー値を確認(閾値以下なら交換)
    物理層は「見ればわかる」ので、最初に確認すると時間短縮になる。

3.L2(VLAN・STP)チェック:範囲が広い障害の定番

拠点全体やフロア単位で落ちている場合はL2を疑う。

  • VLAN設定の不整合
    → Trunkポートの許可VLANが一致しているか
  • STPループ
    → CPU高負荷、MACアドレステーブルが揺れる、pingが断続的
  • MACフラッピング
    → ループ検知ログが出ていないか
  • BPDUガード発動
    → 誤接続でポートがerr-disableになっていないか

L2障害は「広範囲・断続的・CPU高負荷」が特徴。

4.L3(ルーティング)チェック:特定セグメント間だけ通信不可のとき

L3は「どこまで届くか」で切り分けるのが鉄則。

  • デフォルトゲートウェイへping
    → NGならそのセグメントのGW(L3SW/Router)が怪しい
  • 他セグメントへのtraceroute
    → どこで止まるかでルート不整合を特定
  • ルーティングテーブルの不整合
    → OSPF/BGPの経路が落ちていないか
  • VRRP/HSRPのフェイルオーバー異常
    → Active/Standbyの切替が正常か

特に「経路が揺れる」「特定宛先だけ遅い」はL3の典型。

5.DNS・DHCP・FW(L4-7)チェック:アプリだけ落ちているとき

ネットワークは生きているのにサービスだけ落ちるケース。

  • DNS障害
    → 名前解決だけ失敗する(IP直打ちは通る)
  • DHCP障害
    → 新規端末だけ通信不可(IP取得できない)
  • FW/UTMの誤検知・ポリシー変更
    → 特定ポートだけ塞がる
  • プロキシ障害
    → Webだけ遅い・繋がらない

アプリ層は「特定サービスだけ死ぬ」ことが多い。

6.ログ・監視からの深掘り:原因特定の決め手

以下のログを優先的に確認すると、原因に直結しやすい。

  • スイッチ/ルータのsyslog(リンクダウン、STP、ルート変動)
  • FW/UTM のログ(Deny、IPS、帯域制御)
  • APコントローラのログ(大量接続、チャネル干渉)
  • 監視ツール(Hinemos/Zabbix等)
    → CPU/メモリ/インターフェース利用率の急上昇
  • トラフィック統計
    → 特定端末の異常通信(ウイルス・暴走アプリ)

ログは「時刻一致」が最重要。障害発生時刻と照らし合わせる。

7.応急処置:復旧を優先する場合の判断

原因特定より復旧が優先されるケースでは、以下の順で対応。

  • 影響範囲の切り離し(ループ発生セグメントの遮断)
  • 冗長構成の切替(VRRP/HSRP、LAG、冗長FW)
  • 問題機器の再起動(CPU高負荷時は有効)
  • 該当ポートのshutdown/no shutdown
  • 問題端末の隔離(暴走通信の疑い)

応急処置後は必ず「恒久対策」をセットで考える。

8.復旧後の対応:再発防止と情報整理

障害対応は復旧して終わりではなく、ここからが本番。

  • 原因の一次・二次切り分け
  • 恒久対策の検討(設定見直し、冗長化、監視強化)
  • 作業記録の整理(時系列・ログ・対応内容)
  • 関係者への報告(影響範囲・原因・再発防止策)
  • 変更管理への登録(設定変更があった場合)

特に「時系列の整理」は後で必ず役に立つ。

9.実務で使える“NW障害チェックリスト”

  • 物理層(ケーブル・電源・PoE・光)
  • L2(VLAN、STP、MACフラップ)
  • L3(GW、ルーティング、VRRP/HSRP)
  • DNS/DHCP
  • FW/UTM
  • プロキシ
  • 監視アラート
  • 直前の作業有無
  • 特定端末の暴走通信
  • 冗長構成の切替状況
    この順で見れば、ほぼ確実に原因に辿り着ける。

以上です。

「なりたい自分の、その先へ」
エンジニアファーストの会社、助け合いの共同体、ワークスタイルは多様、集まり帰る場所のある会社

株式会社CRE-COエンジニアリングサービス
https://www.cre-co.jp/
伊藤 俊広

私たちと一緒に働きませんか?
https://en-gage.net/cre-co/

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?