静的ルートとは

詳細な図解

静的ルートを読むときの前提

静的ルート（Static route）は、宛先prefixとNext-hopを管理者が明示的に設定する経路です。OSPFやBGPのように隣接関係から自動学習する経路ではないため、意図、所有者、削除条件が設計資料に残っていないと、後から意味を判断しにくくなります。

小規模拠点、暫定移行、特定宛先の固定出口、クラウド接続、管理ネットワークへの到達でよく使います。便利な一方で、広すぎるprefixや古いNext-hopが残ると、障害時に意図しない経路へ通信を流します。

設計資料には、宛先prefix、Next-hop、出力interface、優先度、用途、期限、戻し条件を残します。

宛先prefixと優先度を見る

静的ルートは、ルートテーブル内で最長一致と優先度の影響を受けます。default routeより具体的な静的ルートを入れると、その宛先だけ出口が変わります。逆に広い静的ルートを入れると、想定外の通信まで吸い込むことがあります。

同じ宛先に動的経路も存在する場合は、Administrative Distanceやmetric、クラウド側の優先順位を確認します。バックアップ用の静的ルートなら、通常時に使われない条件も証跡化します。

• 宛先prefixを長い順に並べて重複を確認する。
• 動的経路、default route、伝搬経路との優先関係を見る。
• 常用かバックアップかを記録する。

Next-hopの実在性を確認する

静的ルートは設定できても、Next-hopへ到達できなければ通信は進みません。Next-hopのIPが同一セグメントにあるか、ARP解決できるか、トンネルやattachmentが生きているかを分けて確認します。

クラウドでは、Next-hopがInternet Gateway、NAT Gateway、Transit Gateway、仮想アプライアンスなどになることがあります。ルート行だけではなく、参照先リソースの状態、関連付け、セキュリティ制御も確認します。

• Next-hopへの疎通とARP解決を確認する。
• 参照先リソースの状態と関連付けを見る。
• 出力interfaceと実際の出口を突合する。

移行作業と一時経路の注意

移行中の静的ルートは、切替時刻、対象通信、戻し条件が曖昧だと恒久設定として残りがちです。一時的に広い経路を入れる場合は、削除予定、承認者、削除確認の証跡を必ず残します。

障害対応で追加した経路は、原因切り分けが終わった後に設計へ戻すか、正式な設計変更として扱うかを決めます。応急処置のまま放置すると、将来の動的経路変更やクラウド接続追加と衝突します。

• 追加理由、期限、削除条件を変更記録へ入れる。
• 切替前後の経路表と疎通結果を保存する。
• 応急処置を恒久設定にしない判断日を決める。

変更証跡と引き継ぎ

静的ルート変更では、行きの経路だけでなく戻り経路、NAT、FW policy、監視対象への影響も確認します。片方向だけ通る状態を避けるため、送信元と宛先を入れ替えた確認も必要です。

引き継ぎでは、なぜ動的経路ではなく静的ルートにしたのか、誰が所有する経路か、障害時に削除してよいかを残します。関連語としてルートテーブル、Next-hop、デフォルトゲートウェイ、BGP、OSPFを並べると判断しやすくなります。

• 変更前後のconfig差分と経路表を保存する。
• 戻り経路とFWログを同じ時刻で確認する。
• 所有者、期限、削除可否を台帳に残す。

関連語

同じ主要カテゴリの用語

ネットワークの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能