経路制御の設計 — 静的ルートで固めるか動的ルーティングを入れるか

経路制御の設計で最初に向き合う判断は「静的ルートだけで構築を完結させるか、動的ルーティングプロトコルを導入するか」だが、この選択は構成の規模や変更頻度を無視したまま進められることが多い。静的ルートは管理が簡単に見えて、実際には変更のたびにエントリが積み重なり、半年を過ぎたころには全体像を把握できる担当者がいなくなる。一方、動的ルーティングを入れれば済むかというとそうではなく、障害時に経路変動の追跡が困難になるという別の問題が生まれる。本記事では、静的で足りる条件と動的が必要な境界を具体的な規模感とともに整理し、経路広告の絞り方・優先順位の設計・障害時の追跡可能性まで、構築担当者が現場で判断できる軸を示す。

静的ルートを積み増して経路が誰にも読めなくなる構造

変更のたびに追加されるだけで整理されない理由

静的ルートの管理が行き詰まるのは、エントリの「削除」が発生しにくい運用文化に起因することが多い。新しいサブネットが追加されるたびにルートを足すが、旧サブネットが廃止されてもエントリは残り続ける。削除によって何かが壊れるリスクを誰も引き受けたくないからだ。現場では「念のため残しておく」という判断が繰り返され、ルーティングテーブルに死んだエントリが混在するようになる。これが積み重なると、次の担当者が全エントリを精査するコストが高くなり、さらに「触らない」という選択が増える。こうして自己強化的に可読性が失われていく構造が出来上がる。

重複エントリと矛盾経路が生む予期しない動作

同一宛先に対してネクストホップが異なる2つの静的ルートが共存した場合、どちらが有効になるかはメトリクスとAD（Administrative Distance）値による。しかしメトリクスを意識して設定された静的ルートは少なく、意図しないロードバランスや非対称経路が発生することがある。特に問題になるのはフェイルオーバーを想定した二重経路を静的で組んだ場合で、片方の回線が落ちても経路テーブルからエントリが自動的に消えないため、通信が断続的に失敗し続ける。この状態はpingで確認しにくく、TCPセッションが不定期に切断されるという形で現れる。15台以上の機器が絡む構成では、このような矛盾経路を目視で発見することは現実的でない。

規模が閾値を超えたところで起きること

L3スイッチやルータの台数が8〜10台を超えたあたりから、静的ルートによる管理の手間が急増するという話を現場でよく聞く。それ以下であれば設計ドキュメントと突き合わせながら全エントリを追えるが、10台を超えると変更の連鎖——一か所変えると別の機器でも変更が必要になる——が複雑になり、変更漏れが発生しやすくなる。さらに拠点が2か所以上に分かれると、拠点間の経路整合性を確認する作業が比例的に増える。この閾値を意識せずに静的ルートで押し切ろうとした構成が、後に大規模な再設計を余儀なくされるケースは少なくない。

動的ルーティングが要る構成と静的で足りる構成の判断

静的ルートで十分な構成の条件

静的ルートが適切に機能するのは、接続先の数が限られており変更頻度が低い構成だ。具体的には、L3機器が5台以下で拠点が1か所、サブネットの追加・廃止が月に1回以下という環境であれば、静的ルートだけでも十分に管理できる。また、障害時の自動切り替えを必要としない場合——系切り替えを手動オペレーションで許容している場合——は、動的ルーティングを入れる複雑さのほうがリスクになることがある。小規模なDMZや閉域のメンテナンスネットワークでは、あえて静的ルートに限定することで構成の見通しをよくするという設計判断も合理的だ。

動的ルーティングが必要な構成の条件

動的ルーティングが必要になる判断基準は主に3点ある。第一は、経路の自動収束が必要な冗長構成——アクティブ/スタンバイ構成でリンクダウン時に自動で切り替わることを要件としている場合。第二は、ネットワークの規模が継続的に拡大する予定があり、静的ルートの管理コストが線形以上に増加することが見込まれる場合。第三は、クラウド（AWS Transit GatewayやAzure Route Server）との接続でBGPが事実上必須とされている場合だ。この3点のうち1つでも該当すれば、動的ルーティングの導入を前提として設計を組み立てたほうがよい。

判断の境界を示す問い

どちらを選ぶか迷ったとき、有効な問いは「この経路は6か月後も同じ構成でいるか」だ。答えが「おそらくそうだ」であれば静的ルートが候補に入る。「拡張・統合・移行が控えている」ならば動的ルーティングへの移行コストを今から織り込んだほうがよい。また、「担当者が変わっても運用できるか」という問いも重要で、静的ルートは設計意図が設定ファイルに残らないため引き継ぎコストが高い。動的ルーティングはプロトコルの動作仕様という共通言語があるため、設定の意味を追いやすいという利点がある。

比較表: 静的ルート／IGP（OSPF等）／BGPの選択基準

以下の比較表は、3つの経路制御方式を構築設計の観点から整理したものだ。運用規模・収束速度・設計の複雑さという軸で判断の材料にしてほしい。

比較項目	静的ルート	IGP（OSPF・EIGRPなど）	BGP
適した規模感	L3機器5台以下・単拠点	社内ネットワーク〜中規模マルチサイト（10〜50台程度）	ISP接続・クラウド統合・AS間経路制御
経路収束速度	手動変更のみ（自動収束なし）	数秒〜数十秒（Hello/Deadタイマー依存）	秒〜分単位（セッション設定依存）
設定・運用の複雑さ	低い（エントリ追加のみ）	中程度（エリア設計・コスト設計が必要）	高い（ポリシー・フィルタ設計が必須）
経路の自動切り替え	なし（IP SLA等の補助が必要）	リンクダウン検知で自動収束	セッションダウン検知で収束（タイマー調整要）
広告範囲の制御	制御不要（静的のため）	エリア設計・LSAフィルタリング	Route Map・Prefix Listで精密制御
クラウド接続との親和性	低い（手動管理が必要）	クラウドVPN側はサポート外が多い	高い（AWS・AzureともにBGP標準）
障害時の経路追跡	追いやすい（変化しないため）	LSDBの確認が必要・トポロジ変化を追う	BGPテーブル・パスアトリビュートの読解が必要

経路の優先順位と切り替わり方をどこで決めるか

Administrative Distanceとメトリクスを明示的に設計する

複数の経路制御方式が混在する環境では、AD値が経路の優先順位を決定する。静的ルートのデフォルトAD値は1（直接接続は0）で、OSPFの110やeBGPの20より低い。この仕組みを理解せずにフローティングスタティックルートを設定しようとして、「なぜか静的ルートが優先されてしまう」という問題に直面するケースがある。設計段階で「どのプロトコルをどの優先度で使うか」を明示的にドキュメント化し、意図しない経路優先が発生しない構成にしておくことが重要だ。AD値の設定はルータのモデルやベンダーによってデフォルト値が異なることもあるため、設計書に使用する機器の前提を明記しておく必要がある。

フローティングスタティックルートの適切な使い方

フローティングスタティックルートは、動的ルーティングが有効な場合はそちらを優先させ、プロトコルが落ちたときだけ静的経路にフォールバックするという設計パターンだ。AD値を動的プロトコルより高く設定することで実現する。この設計は小規模なバックアップ回線に有効だが、OSPFセッションが落ちた原因が機器障害ではなく設定変更ミスだった場合に、意図しないフォールバックが発生するリスクがある。設計時にフォールバック条件を明確に定義し、監視アラートと組み合わせて運用する必要がある。フォールバック経路が使われていることに気づかないまま数時間が経過するという事態は、ログと監視が整備されていれば防げる問題だ。

デフォルトルートの配布と例外経路の扱い

デフォルトルート（0.0.0.0/0）の配布方法を誤ると、想定外のトラフィックが特定のリンクに集中するという問題が起きる。動的ルーティング環境でデフォルトルートをOSPFで再配布する場合、配布元の機器が落ちると全拠点でインターネット接続が断絶する。この設計リスクを避けるには、配布元を冗長化するか、配布条件にトラッキング（対象IPへの到達確認）を組み合わせる必要がある。例外的な経路——特定のサービスだけ別の経路を通す要件——は、ポリシールーティングで吸収するのか経路制御の設計で吸収するのかを設計段階で決めておかないと、後から複雑な静的エントリを追加することになる。

経路広告の範囲を拠点・クラウド・DMZでどう絞るか

不必要な経路広告がもたらす設計上のリスク

動的ルーティングを導入した際に経路フィルタリングを設計しないまま構築を進めると、管理用サブネットや内部サービスのアドレスが意図せず全拠点・全機器に広告される状態になる。これはセキュリティ上の問題であるだけでなく、ルーティングテーブルのサイズが不必要に増大し、経路変動時の収束が遅くなる原因にもなる。特にOSPFをバックボーンとして使っている構成で経路集約（サマリ）を設計せずに進めると、個々のホスト経路（/32）が全ルータに溢れるという事態が起きやすい。現場では「最初に集約設計をしなかったため、後から変更できない」という状況に直面することがある。

クラウド接続での経路フィルタリング設計

AWSのVPN接続やAzure ExpressRouteにBGPで接続する場合、クラウド側に広告する経路を絞ることは設計上の必須事項だ。クラウドベンダーのドキュメントでは広告可能な経路数に上限が設けられており（例: AWS VGWはデフォルト100経路まで）、それを超えると接続が不安定になる。また、オンプレミス側の内部管理セグメントをクラウドに広告するリスクも考慮する必要がある。Prefix Listを使って広告経路を明示的に許可リスト化するアプローチが、セキュリティと可視性の両面で有効だ。許可リスト方式にしておけば、将来サブネットを追加した際に意図せず広告されることを防ぎやすい。

DMZと内部セグメントの境界設計

DMZは外部公開サービスが置かれるセグメントであり、内部の基幹系ネットワークとは経路的に分離して設計することが基本だ。動的ルーティングをDMZまで延伸すると、内部の経路情報がDMZのルータに流れ込む可能性がある。この問題を避けるには、DMZと内部ネットワークの境界でルーティングプロトコルを終端し、必要な経路だけを静的ルートまたは再配布で橋渡しするという設計が有効だ。再配布を使う場合は、配布する経路にPrefixフィルタをかけることが前提になる。「とりあえず全経路を再配布」という設定は、後から境界を引き直す作業が大変になる典型的なアンチパターンだ。

動的化して障害時に経路が追えなくなる境界

動的ルーティングが障害調査を難しくするケース

動的ルーティングを導入すると、障害発生時に「現在の経路」と「設計上の経路」が一致しているかどうかを確認する必要が生まれる。静的ルートならば設定ファイルを見ればよかったが、動的では現在のルーティングテーブルをリアルタイムで確認する作業が加わる。さらに、経路が意図せず収束している状態——コストの変化や隣接関係の変動による迂回——は、パフォーマンス劣化として現れることがあり、pingや疎通確認だけでは気づきにくい。このような状態を早期に検出するには、経路変動をログに残すしくみが不可欠だ。Syslogへの経路変動出力とルーティングプロトコルのデバッグログを定期的に収集する設計を組み込んでおく必要がある。

「動的にしたのに手動で直している」という状態の発生

動的ルーティングを導入した構成で、障害対応のたびに担当者が手動で静的ルートを追加して対処するという状況が起きることがある。これは動的ルーティングの設計が不完全で、特定の障害シナリオで想定通りに収束しないため、やむを得ず静的ルートで上書きする対応が繰り返されているケースだ。この状態になると、動的ルーティングと静的ルートが混在した複雑な構成が出来上がり、かえって追跡が難しくなる。このような問題を防ぐには、設計段階で主要な障害シナリオを列挙し、各シナリオでどの経路がどう変化するかを検証しておく必要がある。3〜5シナリオを机上でトレースするだけでも、設計の抜けを見つけやすくなる。

経路追跡が可能な設計の条件

障害時に経路を追跡しやすい構成には共通の特徴がある。第一に、経路変動のログが時刻とともにSyslogに集約されていること。第二に、各機器の現在のルーティングテーブルを一覧で確認できる監視基盤があること。第三に、ルーティングプロトコルの隣接関係（OSPFのネイバー、BGPのセッション）が監視アラートに組み込まれていること。この3点が揃っていない構成では、障害発生から原因特定まで数時間を要することがある。特に夜間・休日に発生した経路変動は、ログがなければ翌日に原因を追うことが困難になる。設計段階でログ収集とアラート設定を経路設計と同時に定義しておくことが重要だ。

経路設計チェックリスト

以下のチェックリストは、経路制御の設計・レビュー時に確認すべき判断項目をまとめたものだ。設計の初期段階と本番導入前のレビュー時の両方で活用してほしい。

1. 規模と変更頻度の確認: L3機器の台数・拠点数・想定するサブネット変更頻度を確認し、静的ルートで管理可能な規模かどうかを判断した。
2. 冗長要件の定義: 経路障害時に自動切り替えが要件か、手動対応で許容できるかを明文化した。
3. AD値とメトリクスの設計: 複数プロトコルが混在する場合、どのプロトコルをどの優先度で使うかをドキュメントに明記した。
4. フォールバック経路の設計: フローティングスタティックルートまたはバックアップ経路を設定している場合、フォールバック発生条件を定義し監視アラートと紐づけた。
5. デフォルトルートの配布設計: デフォルトルートをどこから・どのプロトコルで配布するかを決定し、配布元の冗長性を確認した。
6. 経路広告範囲のフィルタリング: 広告する経路をPrefix Listまたはルートフィルタで明示的に制御し、管理セグメントや不要な内部経路が外部・クラウドに漏れないことを確認した。
7. クラウド接続の経路上限確認: クラウドVPN・専用線接続において、ベンダーが定める経路数上限を超えないことを確認した。
8. DMZ・内部セグメントの境界設計: DMZと内部ネットワーク間でルーティングプロトコルを終端し、再配布する場合はPrefixフィルタを設定した。
9. 主要障害シナリオのトレース: リンクダウン・機器障害・プロトコルセッション断のシナリオで、経路がどう変化するかを机上で確認した。
10. ログ・監視の設計: 経路変動のSyslog出力・ルーティングプロトコルの隣接関係監視・アラート設定を経路設計と同時に定義した。
11. 設計ドキュメントの整備: 全経路設計（静的・動的を問わず）を1か所にまとめたネットワーク構成図と経路設計書を作成し、担当者が変わっても追跡できる状態にした。