前話で、AS という管理境界の存在に出会った。世界はひとつの大地図ではなく、たくさんの AS が境を持って隣り合う構造で動いていた。OSPF はその AS の内側を担当するプロトコルとして、規格そのものに書かれていた。

けれど、前話の最後には 4 つの問いが残っていた。

AS の境では、何が起きるのだろう。 AS と AS は、どうやって経路を伝え合うのだろう。 OSPF はなぜ、そのまま AS の外には伸ばせないのだろう。 地図を全員で持つことが、AS の境ではどこで成り立たなくなるのだろう。

本話で、3 つ目と 4 つ目の問いに向き合う。

仮に、AS 65001 で動いている OSPF を、隣の AS 65002 にもそのまま広げようとしたら、最初に何が起きるだろうか。

3 つの前提が、AS の境で同時に崩れた。

考えてみよう

仮に、AS 65001 で動いている OSPF を、隣の AS 65002 にもそのまま広げようとしたら、最初に何が起きると思うだろうか。動くか動かないかではなく、最初にぶつかる場所として、何が思い浮かぶだろうか。隣の AS が地図を見せてくれない? 経路の決め方の方針が違う? それとも、もっと別の場所?

1. OSPF が動けたのは、3 つの前提が揃っていたから

前のシリーズで OSPF を学んだとき、世界はそれだけで完結しているように見えていた。area の中のすべてのルータが同じ link-state database を持ち、その地図から最短経路を計算する。仕組みは綺麗に揃っていた。

ところが、その「綺麗さ」は、当たり前に動いていたわけではなかった。OSPF が動くためには、当たり前のように見えていた前提が、3 つあった。

前提 1: 地図を共有してくれる仲間。

OSPF は、area 内のすべてのルータが同じ link-state database を持つことを動作の前提にしている。隣のルータも同じ LSDB を同期してくれる範囲でのみ、地図共有は始まる。内側のリンク状態を渡さないルータが混ざると、地図共有は最初の一歩で止まる。

前提 2: 揃った管理ポリシー。

OSPF が動く範囲では、経路の決め方の方針が単一で揃っている。どの経路を載せるか、コストをどう計算するか、どの LSA を受け取るか — 同じ基準で動いている範囲でだけ、地図は意味を持つ。別の基準で経路を決めたいルータが混ざると、地図の上の数字の比較ができなくなる。

前提 3: 扱える規模。

OSPF は AS の中の規模で設計されている。area の中の経路情報、AS の中のルータ数 — その範囲で SPF 計算と LSDB の保持が現実的に回る、という想定。世界全体の規模を扱うことは、最初から目指されていない。

前話で受け取った「OSPF は AS の内側を担当するプロトコル」という規格上の宣言は、この 3 つの前提が成り立つ範囲でこそ、OSPF は綺麗に動く、と読み直せる。

AS 65001 の OSPF を、隣の AS 65002 にもそのまま広げようとすると、多くの場合、最初に浮かぶのは「隣の AS が地図を見せてくれないかもしれない」という場所だ。それは正解の 1 つになる。けれど、ぶつかるのはひとつの場所だけではない。3 つの前提のすべてが、AS の境では同時に崩れる。

2. 3 つの前提が崩れる場所 — AS の境で同時に立つ

AS の境で起きることを、3 つの前提崩壊として 1 つずつ並べる。それぞれが OSPF のどの前提を崩すかも、同時に並べる。

崩壊 1 — 共有しない

OSPF の前提 1 は「地図を共有してくれる仲間」だった。AS の境を越えると、その前提が崩れる。

隣の AS は、自分の中身を渡したくない。どのリンクがどう繋がっているか、内側でどの経路をどう運んでいるか — 内側の地図(LSDB に相当する情報)は、隣の AS には共有しない。

これは前話で受け取った話そのものだ。「自分の管理範囲は自分で決める」という性質の帰結として、内側を全部渡したら自律が薄まってしまう。だから AS は、内側を見せないし、見せさせない。

OSPF は隣も同じ LSDB を持つ前提で動く。内側のリンク状態を渡さない隣との間では、最初の前提が成り立たない。地図共有は、最初の一歩で止まる。

崩壊 2 — ポリシーが揃わない

OSPF の前提 2 は「揃った管理ポリシー」だった。AS の境を越えると、その前提も崩れる。

AS の現代的な定義は、前話で見たとおり「単一の運用ルールで動く範囲」だった。AS 65001 の中では、経路の決め方の方針が揃っている。AS 65002 の中でも、経路の決め方の方針が揃っている。けれど、AS 65001 と AS 65002 では、方針が違う。

どの経路を流すか。どの方向を優先するか。どの経路は外に出さないか。それぞれの AS は、自分の方針で経路を決めたい。これは前話で見た「自分の運用ルールを自分で決める」の話そのもの。

ここで AS 65001 の OSPF を AS 65002 まで伸ばすと、両方の AS の方針が同じ地図に流れ込み、どちらの AS も「どの経路を出すか / どの経路を受けるか」を自分の境界で保ちにくくなる。両方の AS が「自分の方針で決めたい」という性質を、両方とも諦めることになる。

OSPF は単一の方針の下で動くプロトコル。揃わない方針が同じ地図に流れ込むと、地図そのものが意味を成さなくなる。

崩壊 3 — 規模

OSPF の前提 3 は「扱える規模」だった。AS の境を越えるどころか、世界全体に広げようとした瞬間、規模が爆発する。

現役の AS は、桁感としては数万を超えるオーダーで世界を構成している。世界中で運ばれているプレフィックス(IP アドレスの範囲)は、数十万のオーダーに達する。

それらすべてを 1 枚の link-state database に収めようとすると、地図そのものが膨らみすぎる。

膨らんだ地図の上で SPF を回すと、計算が重くなりすぎる。LSA(地図の更新情報)がひとつでも届くたびに、世界中のルータが同じ計算を回し直すことになる。どこかでひとつのリンクが落ちただけで、世界中で収束計算が走る。それが収束しきる前に、また別の場所でリンクが落ちる。終わらない再計算の中で、地図はそもそも安定しない。

OSPF は AS の中の規模で設計されている。世界全体の規模を扱うことは、最初から目指されていない。

3 つの崩壊は、独立にあるのではない

3 つは、OSPF の 3 つの前提と 1 対 1 で対応している。

• 前提 1: 地図を共有してくれる仲間 ↔ 崩壊 1: 共有しない
• 前提 2: 揃った管理ポリシー ↔ 崩壊 2: ポリシーが揃わない
• 前提 3: 扱える規模 ↔ 崩壊 3: 規模

OSPF の動作が依拠していた 3 つの前提が、AS の境で同時に崩れる。

たとえば、仮に隣の AS が内側のリンク状態を見せる仕組みがあったとしても — 崩壊 1 が解決しても — 残り 2 つは別の理由で立ちはだかる。ポリシーは依然として混ざる(崩壊 2)し、世界規模ではリンクの状態を抱える経路情報の集合が膨らみすぎる(崩壊 3)。逆に、仮に世界全体の規模をなんとかして扱えたとしても、隣の AS は内側のリンクの状態を見せないし、ポリシーは揃わない。

3 つの場所は、それぞれが別の前提の崩壊として、別々に立ちはだかる。

3. AS の中と AS の間は、構造そのものが違う

3 つの前提崩壊の裏側には、もっと大きな構造的な対比がある。

AS の中は、こんな世界として動いている。

全体の地図を見渡せる前提がある。area の中のすべてのルータが、同じ link-state database を共有していた。経路の決め方の方針も揃っている。AS の中で誰がどんな経路を流すかは、ひとつの方針の下で決まる。扱う規模も、AS の中に収まっている。そして OSPF は、その地図の上で「物差しで一番短い道を選ぶ」という、シンプルな仕事をしている。

AS の間は、まったく別の世界として動いている。

全体の地図を見渡せる前提がない。隣の AS は内側を見せない。経路の決め方の方針も揃わない。各 AS は自分の方針で経路を流したい。扱う規模も、世界全体に広がる。全体の地図を見渡せない世界で、しかも各自の方針が違う世界で、しかも世界規模の数の AS が並んでいる世界で、経路の伝え合いを成立させる必要がある。

• AS の中 = 全体の地図を見渡せる前提 + 同じ運用ルール + 収まる規模 + 物差しで一番短い道を選ぶ
• AS の間 = 内側を見せない前提 + 各自の運用ルール + 想定外の規模

構造そのものが違う。

どちらが優れているとか、劣っているとかではない。どちらも世界の作りに沿って、自然な姿として動いている。AS の中では地図共有の発想が成立する。AS の間では地図共有の発想は最初から目指されていない。

3 つの前提崩壊をなんとかするためには、AS の中で動いていた発想とは違う、別の発想で経路を伝え合う仕組みが必要になる。リンクの状態を全員で共有する発想ではない。全体を見渡す発想ではない。物差しで一番短い道を選ぶ発想ではない。

その組み立て方の中身は、本話の射程外だ。次の話に持ち越す。

現場で、OSPF の 3 つの前提崩壊を読む

現場で OSPF の限界の話に出会ったら、「規模が大きいから動かない」だけだと、3 つの崩壊のうち 1 つしか見ていないことになる。残り 2 つ — 隣の AS は内側のリンクの状態を見せない、ポリシーが揃わない — は、規模をどう解決しても残る。3 つの崩壊を順に並べて、それぞれが OSPF のどの前提を崩しているかまで言えると、リンクの状態を全員で共有する発想がどこまで通用するかが見えてくる。

show ip ospf neighbor で関係が見える範囲、show ip ospf database で同じ地図が共有されている範囲は、すべて AS の中の話だ。AS の境を越えた経路情報は OSPF のテーブルには載らない。

AS の境界からは、もうひとつの問いが立ち上がる。リンクの状態の共有とは違う発想で経路を伝え合う仕組みが必要だ、ということまでは見えた。では、その発想とは、具体的にどんな姿をしているのだろう。AS と AS は、どんな関係を結んで経路を伝え合っているのだろう。内側のリンクの状態を共有しない者同士で経路を伝え合うとは、どんな組み立て方になっているのだろう。

その問いに、次のプロトコル — AS の境を越えるために組み上がった仕組み — が答える。次は、リンクの状態の共有とは違う発想の最初の姿に向き合う。