OSPF の設計レビューをしていると、「なぜ OSPF プロセスを複数に分けているのか」という構成を見ることがあります。OSPF の process ID は neighbor 間で一致させる必要がないため、最初は単なるローカルな識別子のようにも見えます。
しかし、OSPF プロセスを分けることには明確な意味があります。私の理解では、OSPF プロセス分割の本質は、同一ルーター内に別 OSPF domain を作り、プロセス間を redistribution 境界として扱うことです。
この記事の結論
OSPF プロセスを分ける効果は、単に process ID を変えることではありません。
- LSDB を分けられる
- SPF 計算の単位を分けられる
- 経路を自動的に混ぜず、redistribution を明示できる
- redistribution 時に prefix-list、route-map、metric、tag で制御できる
- OSPF area とは別の制御境界を作れる
つまり、OSPF プロセス分割は、OSPF の area 設計では表現しづらい経路制御境界を作るための手段です。
OSPF process ID は neighbor 間で一致不要
まず前提として、OSPF の process ID はルーター内のローカルな識別子です。Cisco などでは router ospf 1 のように指定しますが、この 1 は neighbor との adjacency 形成条件ではありません。
隣接ルーターが router ospf 1、こちらが router ospf 100 でも、area、network type、hello/dead interval、認証、MTU などの条件が合っていれば neighbor は成立します。
ただし、運用上は process ID を揃えることがあります。これは技術的な必須条件ではなく、設定や運用資料を読みやすくするための管理上の判断です。
area 分割と process 分割は違う
OSPF には area という強力な設計要素があります。area は、同一 OSPF domain の中で LSDB と経路計算を階層化するための仕組みです。
一方、process 分割は、同一ルーター内で OSPF domain そのものを分けるような考え方です。area 分割と process 分割は似て見えますが、設計上の意味はかなり違います。
| 項目 | area 分割 | process 分割 |
|---|---|---|
| 位置づけ | 同一 OSPF domain 内の階層化 | 別 OSPF domain を同一ルーター内に作る |
| 経路の流れ | ABR を通じて OSPF の仕組みで伝播 | redistribution しない限り混ざらない |
| LSDB | area 単位で分かれる | process 単位で分かれる |
| 制御点 | area type、summarization、filtering など | redistribution、route-map、metric、tag など |
| 主な目的 | OSPF domain のスケールと階層化 | 経路制御境界の明示 |
プロセス分割で何が分離されるか
OSPF プロセスを分けると、それぞれのプロセスは独立した OSPF として動作します。
| 分離されるもの | 意味 |
|---|---|
| Neighbor | 各 process が別々に neighbor を持つ |
| LSDB | link-state 情報が process 間で直接共有されない |
| SPF 計算 | 経路計算が process ごとに行われる |
| OSPF route | redistribution しない限り別 process へ入らない |
| policy | process 間の redistribution で制御できる |
このため、OSPF プロセス分割は「経路を混ぜない状態を作り、必要なものだけ再配送する」ための構成として理解できます。
再配送境界としての価値
OSPF は BGP と比べると、経路 policy の表現力が限られます。BGP では AS、community、local preference、route-map などを使って細かい制御をしやすいですが、OSPF は link-state protocol であり、基本的には domain 内で同じ topology を共有する思想です。
そのため、OSPF 内で強い policy 境界を作りたい場合、area 設計だけでは足りないことがあります。このとき、OSPF process を分け、process 間を redistribution でつなぐと、再配送時に policy を適用できます。
| 制御項目 | 例 |
|---|---|
| prefix の選別 | 特定 prefix だけ別 process へ渡す |
| metric の変更 | redistribute 時に cost を調整する |
| route tag | 再配送された経路に tag を付け、再流入や loop を防ぐ |
| 経路集約 | 境界で summary route として扱う |
| 片方向制御 | 片方の process からだけ経路を渡す |
使いどころ
OSPF プロセス分割は、常に使うべきものではありません。むしろ、通常は area 設計で済むなら area 設計の方が素直です。
それでも、次のような場合には process 分割を検討する価値があります。
- 管理主体が異なる OSPF domain を同一ルーターで接続する場合
- 既存 network と新規 network の間に明確な経路制御境界を作りたい場合
- 一部 prefix だけを選別して OSPF domain 間で渡したい場合
- OSPF area 設計では表現しづらい policy 境界が必要な場合
- 検証環境や移行期間で、経路を段階的に混ぜたい場合
注意点
OSPF プロセス分割は便利ですが、設計を複雑にします。安易に使うと、かえってトラブルシュートが難しくなります。
| 注意点 | 内容 |
|---|---|
| 再配送 loop | 双方向 redistribution で同じ経路が戻ってくる可能性がある |
| 経路属性の劣化 | OSPF 内部経路が外部経路として扱われる場合がある |
| metric 設計 | process 間で cost の意味が変わることがある |
| 障害解析 | どの process で経路が見えているかを追う必要がある |
| 設定量の増加 | route-map、prefix-list、tag 制御が増える |
特に双方向 redistribution を行う場合は、route tag などで再流入を防ぐ設計が重要です。
OSPF が扱いづらく見える理由
OSPF は link-state protocol としては非常によくできています。一方で、policy routing 的な柔軟な経路制御を強く求めると扱いづらく感じます。
OSPF は、domain 内で topology を共有し、最短経路を計算することに向いた protocol です。BGP のように「経路を選んで、属性を付けて、policy で流す」ことを主目的にした protocol ではありません。
そのため、OSPF で強い policy 境界を作ろうとすると、area type、summarization、filtering、redistribution、process 分割といった複数の手段を組み合わせることになります。
この点は、OSPF の扱いづらさについての考察 ともつながります。
書籍
マスタリング TCP/IP ルーティング編
OSPF、経路制御、ルーティング設計の基礎を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
まとめ
OSPF プロセスを分ける効果は、同一ルーター内で OSPF の世界を分離し、process 間を redistribution 境界として扱えることです。
process ID は neighbor 間で一致させる必要はありません。あくまでルーター内のローカルな識別子です。
area 分割は同一 OSPF domain 内の階層化であり、process 分割は別 OSPF domain を作るような設計です。この違いを混同しないことが重要です。
プロセス分割は、経路制御の柔軟性を増やします。しかし同時に、redistribution loop、metric 設計、route tag、障害解析の複雑さも増やします。
したがって、OSPF プロセス分割は「なんとなく分ける」ものではなく、明確な経路制御境界を作りたいときに使う設計手段として扱うのがよいと思います。
