要約

  • 従来のポイントツーポイント IS-IS は、Hello を聞いただけで相手を到達可能と扱えた。RFC 5303 の Down、Initializing、Up は、未受信、一方向受信、相互受信の認識を別々に表す。
  • Neighbor System ID と Extended Local Circuit ID は返答を正しい装置と回線へ束縛する。ただし Up が証明するのは IIH の往復であり、LSDB 同期、FIB 反映、データ転送、サービス到達ではない。

まずデータベースが十八時間ずれる条件を読む

RFC 5303 が挙げる最初の故障は、リンク復旧またはシステム再起動の後に起こる。CSNP が失われ、そのリンクがネットワークを分ける唯一の切断集合である場合、両側のリンクステートデータベースは LSP の完全な更新周期まで同期しないことがある。上限は十八時間だ。

ここで Hello 受信そのものは偽ではない。隣接が存在していても、その後段の同期開始を示すパケットが失われた。つまり、「隣接あり」を「同じ世界像を持つ」に拡張したところで誤りが生じる。

第二の故障は一方向断である。通常、一方だけが隣接を広告すれば SPF はそのリンクを使わない。しかし同じ二台の間に並列リンクがあると、SPF はなお到達経路を計算できる。故障を検知していない側は、動かない向きへトラフィックを送る可能性がある。全体の到達性が、個別メンバーの異常を覆い隠す。

第三の故障では、物理層の接続先が変わっても link-down が出ない。別のシステムや同じシステムの別回線向けパケットを受け取り、古い隣接へ誤って関連付ける可能性がある。受信は事実でも、相手と回線の同一性は未証明である。

RFC 5303 は 2008 年の Standards Track 文書で、Informational だった RFC 3373 を前進させるための小改訂である。現行製品の欠陥や導入状況を示す資料ではない。本稿が扱うのは、状態表示にどの証拠を含め、何を含めないかという設計原則だ。

二つの状態機械を一つに畳まない

Point-to-Point Three-Way Adjacency オプションでは、Down はそのオプションを含む IIH をまだ受け取っていない状態、Initializing は受け取ったが相手が自分の IIH を聞いているか不明な状態、Up は相手の受信を知った状態である。

これは ISO 10589 の隣接状態と同一でも同等でもない。隣接は二つの状態を同時に持ち得る。ISH の受信が ISO 側の状態を変えても、三方向状態は対応する IIH を受けるまで Down に残る。監視画面で両者を一つの丸へ統合すれば、追加された証拠を自ら捨てることになる。

遷移表も単なる Up/Down より多くを語る。ローカル Up で相手から Down を受ければ Initializing へ戻る。ローカル Down で相手から Up を受ければ、「Neighbor restarted」を理由に隣接を削除し得る。双方の認識差はノイズではなく、時間順序の資料である。

それでも Up の意味は限定的だ。相手がこちらの IIH を受けていることを意味するだけで、CSNP の到達、LSP の一致、FIB への収容、パケットの双方向通過、アプリケーション応答は保証しない。後続の各主張には別の観測が必要になる。

小さな番号の再利用から回線の固有名へ

相互に聞こえていても、物理的に別の回線へつながっていれば結論は誤る。RFC 5303 は Neighbor System ID と Neighbor Extended Local Circuit ID を利用する。値が存在し、ローカルの System ID または拡張回線 ID と一致しなければ、PDU は破棄される。

従来の表現には暗黙の 256 インターフェース問題があった。LAN に関する実際の制限はより狭い条件だが、ポイントツーポイント回線では回線 ID が再利用されていた。主用途が遠端の変化検出だったためだ。ところが、リンクが同じ小番号を持つ別ポートへ移動すると、再利用が変化を隠す。

Extended Local Circuit ID は四オクテットで、回線作成時に割り当てられ、そのシステム内の全回線で一意でなければならない。従来 ID との対応は不要だ。これは収容量の拡大だけではなく、返答を再利用ラベルではなく実際の回線へ結び付けるための名前空間である。

ただし証明強度は均一ではない。対応システムは三方向状態を必ず含めるが、ほかの識別フィールドは SHOULD である。欠けていても処理は進む。したがって、単なる三方向 Up と、相手システムおよび回線 ID の照合済み Up は、運用上別クラスとして記録すべきだ。

互換性は弱い証拠を受け入れる明示的な政策

未対応システムは新オプションを無視し、自分の IIH には含めない。対応側がオプションなしの IIH を受け取ると、リンクは双方向に機能すると仮定し、旧手順を使う。段階移行には必要な設計だが、強い証拠が得られたことにはならない。

そのため台帳には、ローカル対応の有無だけでなく、オプション送信、相手からの返送、状態値、識別フィールドの存在と一致、旧手順へのフォールバックを残す必要がある。メンテナンス後も隣接が維持されている一方、返答からオプションが消えたなら、可用性ではなく証拠水準が劣化している。

認証も別の列だ。RFC 5304 と RFC 5310 の暗号認証は、受け入れた鍵の保持者からのメッセージであることや完全性を扱う。誤配線、LSDB 収束、データ転送を一括で証明しない。RFC 5880 の BFD は高速な双方向転送検出という別の観測対象を持つ。複数の機構を一つの「健全」に圧縮しないことが重要だ。

この分析が断定しないこと

特定製品が現在この失敗を起こす、特定運用者が未対応である、あるいは十八時間の不整合が実際に発生したとは断定しない。現状評価には実装、設定、IIH、識別フィールド、データベース比較、転送試験の証拠が要る。

三方向機構を有効にしても、旧隣接とのフォールバック、推奨フィールドの欠落、鍵管理の不備、後段同期の失敗は残り得る。一方で、サービスまで証明しないからといって、片方向故障と誤回線束縛を検出する価値が失われるわけでもない。

適切な境界はこうなる。受信は返送を証明しない。返送は回線を名指ししなければ同一性を証明しない。正しい回線で握手が成立しても、データベースと利用者結果は自分の証拠を持たなければならない。

出典