要約

  • RBridgeニックネームはIS-IS IDを短く表す動的な16ビット値で、Mビットにより出口RBridgeまたは配送ツリーを指す。数値だけでは対象を確定できない。
  • 到達可能な競合申告が高い優先度を持てば、設定済みの値でも変更が必要になる。双方のLSP、訂正済みの比較規則、有効期間、転送結果を保存すべきである。

障害記録に0x2A10とだけ残っている。運用担当者は一台の装置を検索したつもりだった。ところが、時刻の近い二つのLSPには別々のIS-IS IDがあり、どちらも同じ値を申告している。直前に二つのTRILLキャンパスが接続されていた。

ここで重複しているのは装置ではない。異なる範囲で別々に選ばれていた短縮値が、境界の消失によって同じ競争に入ったのである。ニックネームを資産の主キーにした記録方式が、正しいプロトコル挙動をデータ異常へ変えてしまった。

Donald E. Eastlake 3rdは、この区別を追跡できる標準群に繰り返し関わった。RFC 6325の共同著者としてTRILLの基本仕様をまとめ、RFC 7176ではIS-IS上の符号化を、RFC 7780ではニックネーム選択の訂正を主導した。RFC 8397ではマルチレベルTRILLの一意ニックネーム方式を共著している。IETF Datatrackerの人物ページは本人名と公開文書の来歴を確認する資料である。ただし、いずれもIETFの共同成果であり、一人を実ネットワークの所有者や将来の決定者にする根拠ではない。

省略形には元の主語が必要だ

RFC 6325はRBridgeニックネームを、動的に割り当てられる16ビット量と定義する。目的はIS-IS IDを省略してTRILLヘッダーを小さくすることにある。短い値は元のIS-IS主体を置き換えるのではなく、特定のリンクステートの下で参照する。

通常は一つだが、一台のRBridgeが複数のニックネームを持つこともできる。再起動後には以前の値を再利用しようとするべきだ、と仕様は述べる。再利用の試行は予約ではない。停止中に別の到達可能なRBridgeが同じ値をより高い優先度で申告していれば、戻った側が以前の履歴を根拠に奪い返すことはできない。

さらに、出口フィールドの意味はMビットで変わる。既知ユニキャストでMが0なら、ネイティブフレームを取り出す出口RBridgeを指す。多宛先でMが1なら、選択された配送ツリーを指す。同じ16ビットを「装置番号」として保存すると、ノードとツリーの違いまで消える。

したがって、観測単位は数値ではない。Mビット、入口・出口の別、パケット種別、IS-IS申告者、範囲、観測時刻を含む一つの文として記録する必要がある。

Sub-TLVは申告の内訳を運ぶ

RFC 7176のNickname Sub-TLVには、Nickname.Pri、Tree Root Priority、Nicknameの組が並ぶ。外側のLSPには始点となるIS、シーケンス、寿命がある。これらを合わせて初めて、誰が何をどの強さで主張したかが分かる。

Nickname.Priは衝突時に値を保持する優先度であり、Tree Root Priorityは配送ツリーの根を選ぶための別の評価値だ。一つの「優先度」欄へまとめると、衝突の勝者とツリー選択を取り違える。

Nickname.Priの最上位ビットは設定値であることを示し、下位7ビットが数値優先度を表す。設定されたニックネームは自動選択値より有利だが、所有権ではない。より強い競合があれば、設定値を持つRBridgeも代替を選ばなければならない。

構成ファイルだけを証拠にしてはいけない。LSPの送信元、値、二種類の優先度、設定フラグ、受信時刻、データベース世代を一緒に保管すれば、設定意図とネットワークが実際に受理した状態を分離できる。

古い一文のままでは勝者が変わる

RFC 6325の初版には、ニックネーム衝突のタイブレークを記した一文に誤りがあった。RFC 7780の訂正では、まず数値の高い優先度が保持する。優先度が同じなら、7バイトのIS-IS ID、擬似ノードならLAN IDが数値的に高い側が勝ち、他方が新しい値を選ぶ。

仕様の更新履歴は運用証拠そのものである。古い規則を実装した解析器と訂正版を使う解析器は、同じ二つの申告から違う勝者を導き得る。「解決済み」という結果だけでは、どの比較をしたか検証できない。

衝突に参加する集合も固定ではない。IS-ISで到達不能なTRILL switchの申告は判定から除外する。一方、IS-ISで到達可能なら、データプレーンで到達不能という理由だけで無視してはならない。制御面の資格と、転送できるかどうかは別の証明である。

一度取得した後も監視は終わらない。到達可能な相手から同じ値の高優先度LSPを受ければ、ローカルがoverload状態でも再選択が必要になる。取得は終了証書ではなく、更新可能な期間の開始だ。

接続イベントが二つの正しさを衝突させる

分離していた二つのキャンパスでは、同じ値がそれぞれ一意でも矛盾しない。RFC 6325は、両者の合流時に一時的な衝突が起こることを想定する。相手側のLSPが届くと敗者が空いているように見える値を選び直す。収束まで複数回の再選択が必要な場合もある。

「空いているように見える」という条件が重要だ。判断は各RBridgeのリンクステート複製に依存し、更新順序は揃わない。収集基盤が最後の対応だけを残せば、異なる時刻にはどちらも妥当だったという因果関係が消える。

保存すべきなのは、合流前の範囲、境界変更、二つのLSP、IS-IS到達性、訂正版による勝敗、撤回、新しい申告、各再選択、FIBとツリーの更新、そして複数観測点での収束時刻である。

逆方向の例もある。RFC 7780によれば、適切なニックネームを一つも確保できないRBridgeは入口・出口・ツリー根にはなれないが、トランジットとしては動作できる。ニックネームがないことは、装置がないことの証明ではない。

一意性はキャンパスの外へ自動では出ない

RFC 8397の方式では、マルチレベルキャンパス全体で値を一意にし、境界RBridgeが個々の申告やブロックをレベル間へ伝える。対照となる集約ニックネーム方式では、別々のエリアで値を再利用し、境界でフィールドを書き換えられる。

つまり「一意」は、採用した割当方式とトポロジーの範囲を含む表現だ。世界唯一でも、永久でも、ハードウェアに刻まれた番号でもない。

境界から見える「所有」にも注意が要る。境界RBridgeはエリア内外のニックネームへ到達できることを代理で広告し、複数の境界が同じ範囲を示す場合がある。広告の始点を物理的な持ち主と読むと、経路集約を資産台帳へ誤変換することになる。

台帳には値ではなく期間を置く

機器の永続ID、ソフトウェアインスタンス、IS-IS IDは分けて管理する。その周囲に、ニックネームとの対応期間を置く。範囲、申告者、設定フラグ、数値優先度、ツリー根優先度、元LSP、開始時刻、終了理由が必要だ。

衝突は上書きせず、双方の生データ、到達性、訂正済み規則、勝者、敗者、代替値を残す。再起動では再利用を試みた事実と取得結果を分ける。マルチレベルでは境界が誰に代わってブロックを広告したかを記録する。

最後に制御面を実配送へ接続する。選ばれた申告はFIBに入ったか、値は出口とツリーのどちらだったか、RPFは通ったか、どのRBridgeが解封装したか、終端は受信したか。ニックネーム選択の成功をサービス成功へ膨らませてはならない。

出典