要約

  • 経路プロトコルが道の長さを表せなければ、回線が動いていても遠隔サービスへの接続が失われうる。
  • 障害後には、古い経路が通信を誤った方向へ導くことがある。RFC 1058の16はそのカウントを区切る値で、即時復旧の約束ではない。

長すぎる経路は、存在しないのと同じになる

遠隔拠点で従業員が受発注システムを使おうとする場面を考えたい。経路がRIPの上限を超えると、ゲートウェイはそれを有効な道として広告できない。回線が動いているのに接続が失敗することがある。別の故障では、宛先を撤回したゲートウェイに隣の装置が経路を戻し続ける。いずれも規則を説明する仮例であり、1988年の実事故を示すものではない。RFC 1058が記録するのは仕組みである。

1988年の仕様は、その状態に意図的に低い停止点を置いた。RFC 1058ではメトリック1から15までを利用可能とし、16を到達不能とした。16は物理的な無限距離ではない。経路を広告できる状態と、撤回すべき状態との間に置かれたプロトコル上の境界だ。

その代わり、RIPではメトリックが15を超える有効な経路を表せない。Hedrickの文書は、中規模ネットワークを対象とするプロトコルと説明し、直径が15を超えるネットワークでは実用性が乏しいという設計者の見方を記録している。上限が低ければ、古い情報が無限カウントを続けられる回数も少なくなる。

上限は故障を終わらせるが、なくしはしない

RFC 1058は16を完全な解決策として扱わない。無限カウントを収束上の問題として説明し、スプリットホライズン、ポイズンリバース、トリガー更新を取り上げる。それでも防止は完全ではない。トリガー更新が間に合わず、古い経路情報が残る可能性があるため、無限カウントは起こりうると明記されている。

故障が有限の段階で終わるからといって、途中が無害とは限らない。メトリックが16に達するまで、ゲートウェイは誤った経路へパケットを送ることがある。16が示すのは制御プレーンが利用可能とみなすのをやめる時点であり、それ以前に全パケットが届いたという証明ではない。

RFC 2453はRIPバージョン2でも16を無限大として残し、ループやプロトコルの限界を記している。RFC 1812はRIPを歴史的なルーティングプロトコルとして扱う。仕組みの仕様が明確でも、あらゆるトポロジーに適しているとは限らない。

ネットワーク規模も設計の一部だった

16は古い定数に見えるかもしれない。しかしRFCの論理は、より実務的だ。無限大が大きすぎれば障害後のカウントが長引く一方、小さすぎれば通常の経路まで排除してしまう。設計者はネットワーク直径と、誤った情報が残ったときの収束時間を天秤にかけた。

したがって、この数値はパケット形式の詳細である以上に運用上の前提だった。RIPを選んだネットワーク運営者は、トポロジーの範囲も受け入れた。範囲を超えた経路は、タイマーを調整してもメトリック16のままでは有効にならない。表現能力の端に到達したということだ。

上限値は、可能な状態の一部を範囲外とすることで障害の広がりを抑える。その費用を負うのは誰か。収束機構か、設計を変える運営者か、それとも経路を表現できない利用者か。1988年のRIPでは、その選択が見えやすかった。16は、地図が道を知っていると主張するのをやめる場所だった。

一次資料：RFC 1058、RFC 2453、RFC 1812。