前の話で、OSPF が距離ではなく帯域で測る理由は見えた。リンクの帯域そのものを物差しにできるのは、OSPF がリンクの状態を共有する設計だからだ。物差しの違いは、共有する内容の違いから来ていた。
仕組みはひととおり見えた。けれど、実機を前にすると、どこから見ればいいかわからない。隣を見つける挨拶も、地図を持ち寄る仕組みも、帯域を物差しにする設計も、それぞれの動作モデルは分かっている。それが show や debug の出力のどの列・どの行に出るのか、まだつながっていない。これは「1 つのコマンドで全部わかる」世界ではない。
全体像とは、観測の窓の並べ方そのものだった。
考えてみよう
OSPFが動いている実機を前にしたら、何を最初に打つだろうか。打ったコマンドの出力には、何が映っていてほしいだろうか。1 つのコマンドで全部わかるのか、それとも複数の出力を並べる必要があるのか。
1. ここまで観察してきた仕組みを並べる
OSPF は、リンクの状態を全員で共有するプロトコルだ。各ルータが自分の周りのリンクの状態を断片として全員に配り、受け取った側はそれを蓄積して地図にする。地図が揃ってから、各自が独立に最短経路を計算する。物差しは、リンクの帯域の逆数(cost)。距離ではなく、リンクの正直な性質を判定に使える。
シリーズの旅は、5 つの動詞として並ぶ。
- 転換した — 距離からリンクの状態へ
- 隣を見つけた — Hello で生かし続ける
- 地図を共有した —
LSAを集めてLSDBに - 物差しを変えた — hop ではなく帯域
- 統合した — 3 つの観測面で読み解く
最初の 4 つの動詞は、前の話までで見てきた。最後の「統合した」が、本話で出会う動詞だ。仕組みはひととおり見えた。けれど、全部わかったはずなのに、実機を前にすると、どこから見ればいいかわからない。その渇きに、ここから正面から向き合う。
2. 3 つの観測面を並べる
OSPF が動いている実機を前にしたとき、打てるコマンドはひとつではない。複数のコマンドが、それぞれ違う窓から OSPF を覗いている。本話では、その中から 3 つを並べる。
show ip ospf neighborは、いま誰と関係が成立しているかを見る窓。show ip route ospfは、SPF が出した最短経路を見る窓。debug ip ospfは、Hello /LSA/ SPF が動いている瞬間を覗く窓。
まず 1 つ目、show ip ospf neighbor。OSPF を喋るルータが、いま誰と neighbor 関係を成立させているかを表示するコマンドだ。出力は次のようになる。
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:38 10.1.1.2 Gi0/0
3.3.3.3 1 FULL/BDR 00:00:34 10.1.1.3 Gi0/0
各行が、1 つの neighbor との現在の関係を表す。Neighbor ID は相手のルータの識別子、Address は相手の IP アドレス、Interface は自分側でその相手と繋がっているインターフェースだ。State の列の前半 FULL が、相手と関係が成立している状態を示す。後半の /DR /BDR は、複数のルータが同じセグメントに繋がっているときに付く役割の修飾で、§3 で 1 度だけ予告する。Dead Time は、Hello が止まったと判定するまでのカウントダウン。Hello が届くたびにこの値はリセットされる。Dead Time が 0 になる前に Hello が届けば neighbor は生きていて、届かなければ neighbor は失効する。
「Hello が neighbor を生かし続ける」という動きは、この Dead Time が定期的にリセットされる出力行に表れている。
次に 2 つ目、show ip route ospf。OSPF を喋るルータが、SPF で計算した最短経路をルーティングテーブルに書き込んだ結果を表示するコマンドだ。出力は次のようになる。
R1#show ip route ospf
O 10.1.30.0/24 [110/3] via 10.1.1.2, 00:01:23, Gi0/0
O 10.2.1.0/24 [110/20] via 10.1.1.3, 00:00:42, Gi0/0
O から始まる行が OSPF が学習した経路だ。[110/3] の角括弧の右側の数字(3 の部分)は、前話で確立した cost。経路上のリンクの帯域を集約した値が、経路の選択基準として使われている。
「LSA を集めて LSDB に組み上げる地図」と「帯域を物差しにする cost」は、O で始まる行と [110/3] の右側の数字として、ここに表れている。
最後に 3 つ目、debug ip ospf。OSPF が動いている瞬間を、リアルタイムで流し見るコマンドだ。出力には、次のようなイベントが流れる(実機の IOS バージョンや debug の種別で表記は変わるため、ここではイベントの種別だけ抜粋する)。
Hello を受信した(隣との挨拶)
SPF を起動する(地図から最短を再計算する合図)
SPF の計算が終わった(計算結果がルーティングテーブルに反映される直前)
(画面上は OSPF: Rcv hello from ... OSPF: Schedule SPF ... OSPF: spf_intra: Done のような形で、英語のログ行として出力される)
Hello が定期的に交わされる瞬間、SPF が起動される瞬間、SPF の計算が終わった瞬間。「Hello で生かし続ける」動きも、「LSA を配って集める」動きも、「SPF が経路を計算する」動きも、ここでは現在進行形の実行ログとして画面に流れる。
(debug ip ospf は実機の動きをリアルタイムに出力するコマンドであり、本番運用では負荷の高さに注意して使う。本話ではイベント種別がログで見えるところまで扱い、debug のサブコマンドや出力フォーマットの細部は後続の上級編で受け取る。各行に出てくる area 0 という語は §3 で扱う)
この 3 つを並べると、それぞれが違う時間軸を映していることがわかる。
show ip ospf neighborは、いまの隣接の現在地show ip route ospfは、いまの経路の現在地debug ip ospfは、動いている瞬間
前のシリーズで RIP を観察したとき、別の 3 つの窓を並べた。show ip protocols(設定)、show ip route rip(現在地)、debug ip rip(動き)。プロトコルが変わると、コマンド名は変わる。窓の組み合わせも、プロトコル固有の事情で少しずつ変わる。OSPF は neighbor の生死が独立した観察対象になるため、「設定」の代わりに「隣接の現在地」を 3 観測面の 1 つに据える。
けれど、視点の組み立て方は持続している。「現在地を見る窓」と「動きを覗く窓」を並べるという構えは、新しいプロトコルでもそのまま使える。前のシリーズで身についた視点が、ここでも生きている。
3. area の輪郭 — 地図が大きくなりすぎたら区切る単位
ここまで見てきた OSPF の動作は、ひとつの地図(LSDB)を全員で共有することで成立していた。数台のルータが、自分の周りのリンクの状態を断片として配り合い、集まった断片で地図を組み上げ、各自が独立に最短経路を計算する。
この仕組みは、小規模なら気持ちよく動く。けれど、繋がるルータの数が 50 台、500 台と増えたらどうなるだろうか。
全員が「自分の周りのリンクの状態」を全員に配り続ける。受け取った全員が、全員分の断片を蓄積し続ける。ルータが増えれば、地図に書き込まれる情報の量も大きくなる。地図が大きくなれば、更新のやりとりも増え、SPF が計算する対象も広がる。
OSPF は地図そのものを区切る装置を持っている。地図が大きくなりすぎたら、area で区切る。
area という単位の中で、各ルータは自分の周りのリンクの状態を配り、地図を組み上げる。地図の共有は area の中だけで成立する。area が違う相手とは、地図の運び方が変わる。
OSPF には、area 0 という特別な area がある。area 0 はバックボーンと呼ばれ、中心となる area だ。地図が大きくなりすぎて複数の area に区切るときは、area 0 を中心に別の area が周りに並ぶ。本話のここまでで観察してきた仕組み(隣を見つける挨拶、地図を持ち寄る、帯域を物差しにする、3 つの窓で読み解く)は、この area の中で動いている。
本話では、area 0 の存在と動機(地図が大きくなりすぎたとき区切る中心)までで止める。area 0 の隣に別の area があるとき、地図はどう分かれているのか。area の境界では、何が運ばれて、何が運ばれないのか。これらの細部は、後続の上級編で扱う領域だ。
本話で見た 3 観測面のうち、show ip ospf neighbor の出力には Pri と State の列があった。Pri は priority のことで、State の修飾(/DR、/BDR のような表記)と組み合わさると、「このセグメントでの代表」のような役割が見えてくる。複数のルータが同じセグメントに繋がっているとき、全員が全員と neighbor を結ぶと数が爆発する。これを抑えるために、代表が選ばれる装置がある。選出の手順や priority の設定の細部は、後続の上級編で扱う。
4. 全体像とは、観測の窓の並べ方そのものだった
OSPF を実機の出力から読むときには、3 つの観測面を並べる。
show ip ospf neighborで、いま誰と関係が成立しているかを見るshow ip route ospfで、SPF が出した最短経路を見るdebug ip ospfで、動いている瞬間を覗く
3 つを並べると、neighbor の生死も、地図から計算された経路も、動いている瞬間も、同時に確認できる。1 つの窓だけでは、必ず景色のどれかが欠ける。3 つの窓があって初めて、OSPF が動いている全体像が立ち上がる。
「現在地を見る窓」と「動きを覗く窓」を並べる視点は、新しいプロトコルでもそのまま使える。プロトコルが変わると、コマンド名や窓の組み合わせは変わる。けれど、視点の組み立て方は持続する。
仕組みそのものは、実機に直接映らない。手元に届くのは、観測の窓を通った後の景色だ。窓を 1 つしか持たなければ、景色は部分的になる。窓を 3 つ並べると、景色が立体的に立ち上がる。
全体像とは、観測の窓の並べ方そのものだった。
これが、本シリーズの到達点だ。
転換した、隣を見つけた、地図を共有した、物差しを変えた、統合した。5 つの動詞が、シリーズの旅の終わりに揃った。
シリーズの旅は、ここで終わる。だが、地図の端からは、まだ 2 つの方向が見えている。
ひとつは、地図の端そのもの。area 0 の隣に別の area があるとき、地図はどう分かれているのか。area の境界では、何が運ばれて、何が運ばれないのか。この方向には、後続の上級編が待っている。
もうひとつは、地図そのものの端。OSPF はリンクの状態を全員で共有できる。けれど、それが成立するのは、ひとつの AS(Autonomous System、同じ管理ポリシーで運用される組織単位のネットワーク)のなかだけだ。AS という別の組織の境を越えると、地図そのものを共有することができない世界が、すぐ次に待っている。
AS を越える世界では、何が起きるのだろう。なぜ、リンクの状態を全員で共有することができないのだろう。
地図を共有できない場所で、どう道を伝えるのか。その問いは、次のプロトコルが正面から教えてくれる。
3 つの観測面の窓と 5 動詞の物語を、現場に持ち帰ってほしい。次の世界は、また別の旅になる。