隣のルータに聞いて +1 で受け取るだけで、経路の辞書が網全体に広がっていく。距離ベクタは、それくらい素朴な仕組みだった。3 台のルータで距離が 0 → 1 → 2 と積み上がる流れを追ったとき、本物の感動があった。
けれど、ふたつの問いが残った。
ひとつ目。距離は、どこまで遠くまで積み上がれるのか。10 でも、20 でも、100 でも、ずっと続けられるのか。それとも、どこかで「これ以上は届かない」と決められた境界があるのか。
ふたつ目。隣のルータが「私は 10.1.30.0/24 を距離 0 で知っているよ」と教えてくれていた経路が、ある日、リンクが落ちて使えなくなったとする。そのとき、経路が消えたという事実は、隣にちゃんと伝わるのか。互いに「隣が言っていた古い経路」を信じ合って、何かおかしなことが起きないか。
RIP の素朴さには、2 つの壁がある。1 つ目は「16 hop 以上は届かない」と決められた hop 上限。2 つ目は count-to-infinity。どちらも「距離だけで測る」という発想の構造的な帰結だ。
考えてみよう
3 台のルータ(CORE-RT-01 / SALES-RT-01 / BRANCH-RT-A)の先に、支店をどんどん増やしていったとしよう。距離は 4, 5, 6, 7, ... とずっと積み上がっていけるのか。それとも、どこかで「これ以上は届かない」と決められた境界があるのか。5 秒だけ、予想してみてほしい。
1. 16 という壁
CORE-RT-01、SALES-RT-01、BRANCH-RT-A の先に、BRANCH-RT-B、-C、-D … と支店ルータを並べていく。
CORE-RT-01 ─── SALES-RT-01 ─── BRANCH-RT-A ─── BRANCH-RT-B ─── BRANCH-RT-C ─── ...
3 hop 2 hop 1 hop 0 hop ...
各支店ルータの足元には、それぞれ別のセグメントがぶら下がっている。BRANCH-RT-B の足元には 10.2.2.0/24、-C の足元には 10.2.3.0/24、-D の足元には 10.2.4.0/24、…。
CORE-RT-01 から見ると、距離は 0 → 1 → 2 → 3 → 4 と積み上がっていく。「隣が知っている距離に +1 して自分の辞書に書く」を、ただ繰り返しているだけだ。距離が 10 でも、12 でも、14 でも、宛先にはまだ届く。
ところが、距離が 15 を超えた瞬間、景色が変わる。
CORE-RT-01 で show ip route rip を叩いてみると、こうなる。
CORE-RT-01# show ip route rip
10.0.0.0/24 is subnetted, 多数の subnets
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 10.2.3.0 [120/4] via 10.1.1.2, 00:00:08, GigabitEthernet0/1
...
R 10.2.14.0 [120/15] via 10.1.1.2, 00:00:08, GigabitEthernet0/1
(10.2.15.0 / 10.2.16.0 ... は届かないとして扱われ、テーブルからは消える)
[120/15] までは並んでいる。けれど、その先(本来なら [120/16] と続くはずの行)はテーブルから消えている。距離が 15 を超える経路は、CORE-RT-01 の辞書には登録されない。
これは、Cisco IOS の表示の都合で切られているわけでも、実機のメモリが足りないわけでもない。RIP は規格として、hop count = 16 を「届かない」とみなすルールを持っている。RFC 1058 §3.4 と RFC 2453 §3.5 のどちらにも、「16 hops or higher are considered infinity」とはっきり書かれている。16 hop 以上は、無限大とみなす。届かない、と決める。
そう決められているから、到達できる上限は 15 hop になる。これより遠い宛先は、RIP の世界では「あるはずなのに届かない」場所として扱われる。
なぜ、よりによって 16 なのか。10 でも、20 でも、100 でもなく、なぜこの数字なのか。
16 という数字は、単に「大きすぎる網が扱えない」という制限であるだけではない。距離ベクタが構造的に抱えるもうひとつの問題を有限時間で打ち切るための、装置でもある。
本話で最初に受け取る 限界 は、この 16 hop の上限だ。
2. リンク断、古い情報が逆流する
split horizon などの緩和策を一度脇に置いた、安全装置が何もない最小モデルで追う。実機の Cisco IOS では緩和策が標準で効いているが、§3 で split horizon の動機を読むために、まず素の動きを見る。
SALES-RT-01 の足元にある 10.1.30.0/24 のリンクが落ちたとする。SALES-RT-01 は自分の足元の経路が消えたため、辞書から 10.1.30.0/24 を消す。
リンクが落ちたら、自分の足元の経路は失われる。
問題は、この瞬間、隣の CORE-RT-01 がまだ気づいていないことだ。CORE-RT-01 の辞書には、まだ「10.1.30.0/24 は SALES-RT-01 経由で 1 hop」と書かれている。さらに奥の BRANCH-RT-A の辞書にも「10.1.30.0/24 は CORE-RT-01 経由で 2 hop」と書かれている。
リンク断という事実を知っているのは、まだ SALES-RT-01 一人だけだ。
数十秒に一度の定期的な update のタイミングで、CORE-RT-01 は SALES-RT-01 に向かって、自分の辞書のうち隣に伝える分を送る。
その update の中には、こんな行が入っている。
「私は 10.1.30.0/24 を距離 1 で知っているよ」
これは古い情報だ。CORE-RT-01 はもともと SALES-RT-01 経由で 10.1.30.0/24 に届くと思っていたから、その「距離 1」は SALES-RT-01 経由を前提にしていた。SALES-RT-01 の足元のリンクが落ちた今となっては、その経路はもう使えない。
けれど CORE-RT-01 は、それをまだ知らない。古い情報を含んだ update を、いつも通り隣に送ってしまう。
SALES-RT-01 はそれを受け取る。
自分の辞書からは、たった今、10.1.30.0/24 を消したばかりだ。「もう自分の足元にはない」と知っている。ところが、隣の CORE-RT-01 から「私は 10.1.30.0/24 を距離 1 で知っているよ」という update が届いた。
SALES-RT-01 は、「自分の足元では消えたけど、CORE-RT-01 経由なら距離 1 + 1 = 2 hop で届く」と判断する。そして「隣が知っている距離に +1 して自分の辞書に書く」を適用し、辞書に「10.1.30.0/24 は CORE-RT-01 経由で距離 2」と書き込む。
でも、実際にはどこにも届かない。CORE-RT-01 はもともと SALES-RT-01 経由で行こうとしていたから、CORE-RT-01 経由でたどっても結局 SALES-RT-01 に戻ってきて、その足元のリンクは落ちている。
辞書には「距離 2」と書かれているのに、パケットは届かない。SALES-RT-01 自身は、その齟齬に気づけない。隣が「届く」と言った情報に、ただ +1 をしただけだから。
次の update で、今度は SALES-RT-01 が CORE-RT-01 に向かって、自分の辞書のうち隣に伝える分を送る。中身は、こうなっている。
「私は 10.1.30.0/24 を距離 2 で知っているよ」
CORE-RT-01 はそれを受け取る。CORE-RT-01 の辞書には、これまで「10.1.30.0/24 は SALES-RT-01 経由で距離 1」と書かれていた。けれど、いま隣の SALES-RT-01 が「距離 2 になった」と言っている。CORE-RT-01 は素直に更新する。「10.1.30.0/24 は SALES-RT-01 経由で距離 3」(隣が言った 2 に +1)。
その次の update で、今度は CORE-RT-01 が BRANCH-RT-A に向かって「距離 3」を伝える。BRANCH-RT-A は受け取って +1 で「距離 4」に更新。
往復のたびに、距離が +1 ずつ積み上がっていく。
[t=0] リンク断: SALES-RT-01 自分の辞書から消す。CORE-RT-01 / BRANCH-RT-A はまだ持っている
[t=1] CORE-RT-01 → SALES-RT-01 へ「距離 1 で知ってる」古い情報の逆流
SALES-RT-01 受け取って「CORE-RT-01 経由で距離 2」と書き込む
[t=2] SALES-RT-01 → CORE-RT-01 へ「距離 2」
CORE-RT-01 受け取って「距離 3」に更新
[t=3] CORE-RT-01 → BRANCH-RT-A へ「距離 3」、BRANCH-RT-A は「距離 4」
[t=4] ... 互いに参照し合って 5, 6, 7, 8, 9, 10, ... と積み上がる
[t=N] 距離が 16 に到達 → 「届かない」として打ち切り、各ルータは辞書から消す
実際にはどこにも届かないのに、辞書の中の数字だけが、2, 3, 4, 5, 6, 7, ... と積み上がっていく。
3. count-to-infinity という構造
隣どうしが古い情報を参照し合って、距離が無限に向かって数え上がっていく現象は、count-to-infinity と呼ばれる。
距離が積み上がっていって、ついに 16 に到達したら、各ルータは「もう届かない」と判断して、自分の辞書から消す。これで count-to-infinity は終わる。
もし infinity の打ち切り装置がなければ、距離は際限なく増え続ける。各ルータの辞書には、ずっと届かない経路が、距離 17, 18, 19, ... と書き込まれ続ける。
だから、16 = infinity は、二重の意味を持っている。
- (1) 大きすぎる網が扱えない、規格の制限。RIP では 15 hop を超える経路は表現できない。
- (2) count-to-infinity を有限時間で打ち切る、装置。リンク断後に古い情報が逆流して距離が無限に増えるのを、16 で強制的に止める。
この 2 つは、別々の事情ではない。同じ「16」という数字が、両方を兼ねている。RFC 1058 の起草者は、最初から距離ベクタの構造的な弱点(count-to-infinity)をどう抑えるかを考えて、infinity を有限の値(16)として規格に組み込んだ。「なぜ 16 なのか」という問いの答えのひとつは、ここにある。16 は網の大きさを制限する数字であると同時に、距離ベクタが抱える構造的な問題を有限時間で止める打ち切り値でもあった。
split horizon という名前の緩和策がある。動作は単純だ。「教えてもらった経路を、その教えてくれた相手には教え返さない」。
count-to-infinity の起点になっていたのは、CORE-RT-01 が SALES-RT-01 から教わった 10.1.30.0/24 の経路を、SALES-RT-01 に向かって返してしまっていたところだった。「私は距離 1 で知っているよ」と返したから、SALES-RT-01 は古い情報を信じてしまった。
split horizon が有効なら、CORE-RT-01 は SALES-RT-01 から教わった経路を SALES-RT-01 には返さない。これで、古い情報の逆流を抑える方向で動く。Cisco IOS では標準で有効になっていて、特別な設定をしない限り、勝手に効いている。
ただし、split horizon だけで全ての count-to-infinity を防げるわけではない。三角形の topology などで抜けてしまう場合があり、それを補う他の緩和策が組み合わされて使われる。
この 2 つの壁(16 = infinity の規格の制限と、count-to-infinity の構造)は、距離ベクタという素朴な仕組みに最初から組み込まれていたものだ。
4. 素朴さと限界は、同じ距離ベクタの表と裏
隣に聞いて +1 で自分の辞書に書く。これを互いにやり合うだけで、辞書は網全体に広がっていく。本物の感動があった。
一方で、距離が積み上がっていけるのは 15 まで。16 = infinity で打ち切られる。リンクが落ちて経路が消えても、古い情報が逆流して距離が際限なく増えていく count-to-infinity が起こる。
素朴さも、2 つの壁も、同じ「距離だけで測る」という単一の発想から構造的に生まれている。
隣とやり取りする情報が距離(hop count)1 種類しかないからこそ、隣どうしが少しずつ伝え合うだけで網全体の辞書が組み上がる。
同時に、距離は「どれだけ遠いか」しか語れない。リンクが今生きているか、地図のどこに穴が空いたかは、距離の数字には溶けない。経路が消えた事実すら、距離の数字でしか伝えられない。だから infinity という数字を打ち切り装置として置き、15 という上限を引く必要があった。
距離だけしか伝えないから、辞書は広がる。距離だけしか伝えないから、消えたものは数字でしか伝えられない。観察と伝播の先に、ここで見えたのは 限界 だ。
明日、show ip route rip で 15 という数字を見たときに思い出すこと
距離は、15 まで積み上がれる。16 = infinity で「届かない」として打ち切られる。これは規格として固定された数字で、距離ベクタの構造的な要請として組み込まれた装置でもある。
経路が消えたという事実は、距離の数字でしか伝えられない。だから古い情報の逆流が起きうる。距離が際限なく増えていく count-to-infinity が現れる。16 で強制的に打ち切る装置がなければ、理論上は無限に増え続ける。
明日、ルータで show ip route rip を眺めて、[120/15] という距離の行を見たときには、この 15 という数字が単に大きい値ではなく、距離ベクタが抱えていた 2 つの壁の境界線だと判断してほしい。[120/15] の隣に並ぶはずだった [120/16] の行が存在しないのには、RFC 1058 / RFC 2453 が hop count = 16 を infinity と決めたという、構造的な理由がある。
距離だけでは測れない場面が、現実の網にはある。リンクの帯域、遅延、リンクが今生きているか / 落ちているか — そうした情報は、距離の数字には溶けない。
なら、距離以外の何で測れば、この限界の先へ行けるのか。
その問いは、この先で待っている。