人の手で経路を書き続ける運用は、規模が増えても経路が変わっても、すぐ追いつかなくなる。動的ルーティングが解こうとしているのは、その追いつかなさそのものだ。最初の素朴な答えに RIP という名前が与えられていることも、輪郭だけ受け取った。

ルータ自身が経路を覚える、と書いた。けれど、具体的にはどうやって、何を、誰から覚えるのか。網全体の地図を持っているのか。誰かが配っているのか。それとも、もっと素朴な仕組みなのか。

CORE-RT-01 にログインして show ip route rip を叩くと、自分が手で書いていない経路が、行頭に R の印をつけて並んでいる。この行は、いつ、誰が書いたのだろう。

RIP の動作は、隣に聞くだけだ。隣が知っている宛先のリストを受け取り、自分は隣まで 1 歩なので、その先までは距離 +1。これを互いにやり合うだけで、辞書は網全体に広がっていく。

SALES-RT-01 が「私は 10.1.30.0/24 を直接知っている。距離は 0」と伝えると、CORE-RT-01 はそれを受け取り、距離に +1 して「10.1.30.0/24 は SALES-RT-01 経由で 1 hop」と自分の辞書に書き込む。BRANCH-RT-A がその先にいれば、SALES-RT-01 経由で 2 hop になる。距離が 0 → 1 → 2 と積み上がる。そして show ip protocols(設定)・show ip route rip(いまの辞書)・debug ip rip(流れている update)の 3 つは、それぞれ見ているものが違う。

考えてみよう

隣のルータが「私は 10.1.30.0/24 を直接知っているよ」と教えてくれたとする。あなたは、その隣と 1 本のリンクで隣り合っている。あなたの辞書には、その 10.1.30.0/24 宛の行を、どのくらいの距離で書くのが筋だろうか。距離 0 か、1 か、それとも隣が伝えてきた距離をそのまま受け取るのか。5 秒だけ、自分の頭で先に答えを置いてみてほしい。この話の中核は、その小さな足し算で動いている。

1. 隣に聞くというだけのこと

CORE-RT-01 で show ip route rip を叩く。画面に並んでいるのは、こんな行だ。

CORE-RT-01# show ip route rip
     10.0.0.0/24 is subnetted, 4 subnets
R       10.1.30.0 [120/1] via 10.1.1.2, 00:00:08, GigabitEthernet0/1
R       10.2.1.0  [120/2] via 10.1.1.2, 00:00:08, GigabitEthernet0/1
R       10.2.2.0  [120/3] via 10.1.1.2, 00:00:08, GigabitEthernet0/1

行頭の R が、RIP 由来の印だ。スタティックで見ていた S(static)とは行頭の文字が違うだけで、3 軸読み(行頭の印 / プレフィックス / 渡し先)はそのまま使える。プレフィックスは 10.1.30.0/24 や 10.2.1.0/24、渡し先は via 10.1.1.2。けれど、これを手で書いた覚えはない。

スタティックは自分が書いたから辞書に並ぶ。では、この R の行は、いったい誰が書いたのか。

隣のルータ — 10.1.1.2 の側にいる SALES-RT-01 — が、自分の辞書のうち隣に伝える分を CORE-RT-01 に渡した。CORE-RT-01 はそれを受け取り、自分の辞書に書き込んだ。R のこの 3 行で起きているのは、それだけのことだ。

SALES-RT-01 のすぐ後ろ(10.1.30.0/24 側)には、営業フロアのネットワークが直接つながっている。SALES-RT-01 にとって、そのプレフィックスは「自分の足元」だ。直接接続なので、距離は 0 と数える。

SALES-RT-01 は、その「自分が直接知っている宛先のリスト」を、隣の CORE-RT-01 に向かって定期的に送り出す。「私は 10.1.30.0/24 を距離 0 で知っているよ」と。

CORE-RT-01 は、その update を GigabitEthernet0/1 で受け取る。受け取ったら、そのままコピーするわけではない。自分は SALES-RT-01 と 1 本のリンクで隣り合っているので、SALES-RT-01 経由でその宛先に届くには、距離に +1 する必要がある。SALES-RT-01 が「距離 0」と言ったから、CORE-RT-01 の辞書には「距離 1」と書き込まれる。

show ip route rip の最初の行にある [120/1] の 1 が、その「距離 1」だ。120 の方は別の仕組みに関わる数字なので、いまは脇に置いて、行末まで読み飛ばしてかまわない。/1 の方を、ここでは「距離」として読む。

2. 距離が 0 → 1 → 2 と積み上がる

SALES-RT-01 の先に、支店ルータ BRANCH-RT-A がつながっている構成を想像してほしい。BRANCH-RT-A の足元には、10.2.1.0/24 の支店セグメントがある。

3 台のルータが、こう並んでいる。

CORE-RT-01 ─── SALES-RT-01 ─── BRANCH-RT-A ─── 10.2.1.0/24
              (隣)            (その先)

それぞれが、まず「自分の足元(直接接続)」を距離 0 で持っている。

• SALES-RT-01 は 10.1.30.0/24 を距離 0 で知っている
• BRANCH-RT-A は 10.2.1.0/24 を距離 0 で知っている
• CORE-RT-01 も自分の足元(10.1.50.0/24)を距離 0 で持っている

ここから、隣どうしが update を送り合う。

第 1 段: SALES-RT-01 と BRANCH-RT-A の会話

BRANCH-RT-A が SALES-RT-01 に対して update を送る。「私は 10.2.1.0/24 を距離 0 で知っているよ」。SALES-RT-01 はそれを受け取り、隣まで 1 歩なので +1 して、自分の辞書に「10.2.1.0/24 は BRANCH-RT-A 経由で 1 hop」と書き込む。

第 2 段: SALES-RT-01 と CORE-RT-01 の会話

SALES-RT-01 は次の update のときに、自分の辞書のうち隣に伝える分を、CORE-RT-01 に向かって送る。中身は、こんな並びだ。

• 10.1.30.0/24 を距離 0 で知っている(自分の足元)
• 10.2.1.0/24 を距離 1 で知っている(BRANCH-RT-A 経由)

CORE-RT-01 は両方を受け取り、それぞれに +1 する。

• 10.1.30.0/24 は SALES-RT-01 経由で 1 hop
• 10.2.1.0/24 は SALES-RT-01 経由で 2 hop

CORE-RT-01 から見ると、SALES-RT-01 まで 1 歩、その先の BRANCH-RT-A の足元まで 2 歩。show ip route rip の 2 行目に並んでいた [120/2] の 2 が、ちょうどこの「2 hop」だ。

第 3 段: もう 1 台先に支店があれば

show ip route rip の 3 行目には R 10.2.2.0 [120/3] という行も並んでいた。これは、BRANCH-RT-A の先にもう 1 台の支店ルータ BRANCH-RT-B がつながっていて、その足元に 10.2.2.0/24 があるときの構成だ。

CORE-RT-01 ─── SALES-RT-01 ─── BRANCH-RT-A ─── BRANCH-RT-B ─── 10.2.2.0/24
   3 hop          2 hop           1 hop          0 hop(足元)

BRANCH-RT-B が「10.2.2.0/24 を距離 0」と言うと、BRANCH-RT-A は受け取って +1 で「距離 1」、SALES-RT-01 はさらに +1 で「距離 2」、CORE-RT-01 はさらに +1 で「距離 3」と積み上がる。

CORE-RT-01 は、BRANCH-RT-B のことも、その向こうの 10.2.2.0/24 のことも、直接は知らない。CORE-RT-01 が見ているのは、隣の SALES-RT-01 だけだ。SALES-RT-01 が「2 hop で 10.2.2.0/24 に届くよ」と言ってきたから、CORE-RT-01 は「じゃあ私からは 3 hop」と書いた。SALES-RT-01 がどうやってその 2 hop を知ったかは、CORE-RT-01 にとっては関係がない。

ルータは、網全体の地図を持っているわけではない。隣が知っていることだけを、距離を 1 増やして受け取っている。それでも、隣の隣の、そのまた隣の宛先まで、距離の数字だけはちゃんと積み上がっていく。網全体を見渡す賢者がいるわけではなく、隣どうしが少しずつ伝え合うだけで、辞書は勝手に網全体に広がる。

このやり方には、家族名がついている。距離ベクタ(distance vector)。「どの方向(どの隣)へ、距離いくつで届くか」だけを隣に伝え合う動的ルーティングの一族の名前で、RIP はその代表だ。距離の数え方は、宛先までに通過するルータの数 — hop count と呼ばれる。RIP が経路を測る基準は、これひとつだけだ。

隣から隣へ +1 ずつ受け取る動きを 伝播 と呼ぶ。網全体の地図がなくても、update の連鎖だけで距離は伝播していく。

距離ベクタの動作は、3 つの素朴なルールでできている。(1) 自分の足元(直接接続)は距離 0。(2) 隣から「距離 N で届く」という update を受け取ったら、隣まで 1 歩なので +1 して、自分の辞書には「距離 N+1」と書く。(3) これを互いにやり合うだけで、隣の隣の宛先まで距離が積み上がっていく。

3. update が定期的に流れている

ここまで、距離が積み上がる絵で動作を見てきた。その update は、いつ、どのくらいの頻度で流れているのだろうか。

show ip protocols で CORE-RT-01 の RIP 設定を確認すると、こういう行が並ぶ。

CORE-RT-01# show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 12 seconds
  Invalid after 180 seconds, ... flushed after 240
  ...
  Interface             Send  Recv
  GigabitEthernet0/0      2     2
  GigabitEthernet0/1      2     2
  Routing for Networks:
    10.1.1.0
    10.1.50.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.1.1.2             120      00:00:18

注目したいのは、最初の方の 2 行だ。

• Sending updates every 30 seconds, next due in 12 seconds
• Invalid after 180 seconds, ... flushed after 240

最初の行は、update を出す周期だ。30 seconds と書いてあるが、ここで覚えておきたいのは数字そのものより、時間の桁感の方だ。update は、数十秒オーダーで定期的に隣へ流れている。すべてが一斉ではなく、ルータごとに少しずつタイミングをずらしながら継続している。

2 行目は、受け取った update が更新されないまま、どのくらいで「古い」「捨てる」と扱われるかの目安だ。数分オーダーで、古い経路は自然に消えていく。具体的な秒数の意味と、それが何のためにあるのかは、別の角度からこの先で見る(ここでは深入りしない)。

update の中身そのものを、ほんの少しだけ覗いてみる。debug ip rip を叩くと、実際の通信の流れが画面に出力される。

*Apr 27 12:00:00.123: RIP: received v2 update from 10.1.1.2 on GigabitEthernet0/1
*Apr 27 12:00:00.124:      10.1.30.0/24 via 0.0.0.0 in 0 hops
*Apr 27 12:00:00.125:      10.2.1.0/24  via 0.0.0.0 in 1 hops
*Apr 27 12:00:30.456: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (10.1.1.1)
*Apr 27 12:00:30.457:      10.1.50.0/24 via 0.0.0.0, metric 1, tag 0

最初の 3 行は、CORE-RT-01 が SALES-RT-01(10.1.1.2)から update を受け取った瞬間の記録だ。中身は、これまでの絵で追ってきた通り。「10.1.30.0/24 を 0 hops で」「10.2.1.0/24 を 1 hops で」。SALES-RT-01 から見た距離が、そのまま乗ってきている。これを受け取ってから +1 して、自分の辞書には「1 hops」「2 hops」と書く。

下の 2 行は、その 30 秒後に CORE-RT-01 が今度は自分の側から送り出した update だ。「10.1.50.0/24 を metric 1 で」と隣に伝えている。

debug ip rip は、本番運用では負荷が高い。RIP の通信は数十秒オーダーで続くから、debug を流しっぱなしにするとログが大量に出力され、CPU の負担になる場合がある。本番のルータでは、ごく短時間だけ流して止める、あるいはラボや検証環境で使うのが筋になる。ここで覗いた数行も、実機がいまどんな通信を続けているかの手触りを得るためのもので、運用ツールとして常用するものではない。

4. 3 つの観測面 — 設定 / 現在地 / 動きの演出

ここまで使ってきた 3 つのコマンドを並べて、それぞれが何を見ているのかを区別したい。これは、この先で RIP に出会ったとき、どのコマンドで何を確認するかを混同しないための、運用の地図になる。

それぞれが答える問いは違う。

show ip protocols が答えるのは、「いま、このルータで RIP はどう動くように設定されているか」だ。Sending updates every 30 seconds という行は、設計値・設定値そのもの。Routing for Networks に挙がっているのは乗せると決めたネットワーク。Interface ... Send ... Recv の表は、どのインターフェースで受送信するか。いま起きていることではなく、そう動く設計になっていることを見せている。

show ip route rip が答えるのは、「いま、このルータの辞書には、RIP 由来でどの行が並んでいるか」だ。行頭の R、距離、渡し先、最後の更新時刻。スタティックの段で身につけた 3 軸読み(行頭の印 / プレフィックス / 渡し先)が、そのまま使える。いまの辞書の状態を見せている。

debug ip rip が答えるのは、「いま、このルータは隣とどんな update を交わしているか」だ。1 通ずつの中身がリアルタイムで流れる。本番運用では負荷が高いから、常用するものではない。経路が思ったように学べていない場面で短時間だけ流すと、隣から実際にどんな update が届いているか、自分が何を送り出しているかが、画面のログで追える。いま流れている動きを見せている。

これを混同すると、「設定を確認したいのに show ip route rip を見る」「辞書の状態を見たいのに debug のログを待つ」といった、ちぐはぐな操作になる。それぞれが別の問いに答えるコマンドだという感覚を、区別しておきたい。

R の行の正体 — 隣からの update が +1 で書き込まれた結果

CORE-RT-01 で show ip route rip を叩いて並ぶ R の 3 行は、誰が書いたのか。

隣のルータが「自分が知っている宛先のリスト」を update として送り、受け取った側が「隣まで 1 歩なので +1」して自分の辞書に書き込んだ — それが、R の行が並んでいる正体だった。

設計は show ip protocols、現在地は show ip route rip、動きは debug ip rip と区別する。明日、誰かのルータで R の行を見たときには、「隣から +1 で受け取った行だ」と読み、見たい対象に応じてコマンドを取り出せるようにしておきたい。

距離ベクタの素朴な景色には、本物の感動がある。一方で、距離だけで測る世界には、まだ確かめていないことが残っている。

距離は、どこまで遠くまで積み上がれるのだろう。0 → 1 → 2 → 3 と積み上がる流れは見えた。10 でも、20 でも、100 でも、ずっと続けられるのだろうか。それとも、どこかで「これ以上は届かない」と決められた境界があるのだろうか。

もうひとつ。隣が「10.1.30.0/24 を距離 0 で知っているよ」と教えてくれていたのが、ある日、リンクが落ちて使えなくなったとする。そのとき、消えたという情報は、隣にちゃんと伝わるのだろうか。互いに「隣が言っていた古い経路」を信じ合って、何かおかしなことが起きないだろうか。

素朴さは強い。けれど、何を測れて何を測れないかは、その測定基準そのものが決めてしまう。距離だけで測る世界が抱える 2 つの壁を、この先で観察する。