メインコンテンツまでスキップ

6.3. Routing Locator Reachability (ルーティングロケータ到達可能性)

6.3. Routing Locator Reachability (ルーティングロケータ到達可能性)

現在, Routing Locator (ルーティングロケータ, RLOC) の到達可能性を判定するためのいくつかのメカニズムが定義されています:

  1. ETR は, ITR からのカプセル化データパケットの LISP ヘッダ内の Locator-Status-Bits を検査できます。ETR が ITR としても機能し, 元の ITR サイトにトラフィックを返送する必要がある場合, このステータス情報を使用して RLOC の選択を支援できます。

  2. ITR は, 使用している RLOC に対する ICMP Network Unreachable または Host Unreachable メッセージを受信する可能性があります。これは RLOC が失敗した可能性があることを示します。ICMP メッセージを信頼することが常に望ましいとは限りませんが, それらを完全に無視することも望ましくないことに注意してください。実装は, これらの状況を処理する際の現在のベストプラクティスに従うことが推奨されます。

  3. グローバルルーティングシステムに参加している ITR は, RLOC IP アドレスに一致する BGP Routing Information Base (ルーティング情報ベース, RIB) ルートが存在するかどうかに基づいて RLOC が失敗しているかどうかを判定できます。

  4. ITR は宛先ホストから ICMP Port Unreachable メッセージを受信する可能性があります。これは, ITR が相互運用メカニズム [RFC6832] を使用しようとし, LISP カプセル化データが LISP 機能を持たないサイトに送信されたときに発生します。

  5. ITR は, 以前に送信した Map-Request に応答して ETR が返した Map-Reply を受信する可能性があります。Map-Reply の RLOC 送信元アドレスは up 状態である可能性が高いです。ETR が Map-Reply を ITR に送信できたためです。

  6. ETR が ITR からカプセル化パケットを受信すると, パケットの外部ヘッダ内の送信元 RLOC は up 状態である可能性が高いです。

  7. ITR/ETR ペアは, このセクションで説明する Locator 到達可能性アルゴリズム, つまり Echo-Noncing または RLOC-Probing を使用できます。

LISP カプセル化データパケットの Locator-Status-Bits を検査して Locator のアップ/ダウン到達可能性を決定する場合, ETR はカプセル化 ITR からそのサイトのすべての ETR の到達可能性に関する最新のステータスを受信します。送信元サイトの CE ベースの ITR は, 次の方法でサイト IGP を使用して相互の到達可能性を判定できます:

o 通常の状況では, 各 ITR はサイト IGP にデフォルトルートをアドバタイズします。

o ITR が故障したり, PE への上りリンクが故障したりすると, そのデフォルトルートはタイムアウトするか撤回されます。

したがって, 各 ITR は他の ITR がまだデフォルトルートをアドバタイズしているかどうかを観察でき, それに応じて Locator-Status-Bits を設定できます。

Map-Reply にリストされている RLOCs は序数 0 から n-1 で番号付けされます。LISP カプセル化パケットの Locator-Status-Bits は, 最下位ビットから 0 から n-1 として番号付けされます。例えば, Map-Reply の 3 番目の位置の RLOC が失敗した場合 (序数は 2), サイト内のすべての ITR は, カプセル化パケットに設定する Locator-Status-Bits フィールドの 3 番目の最下位ビット (xxxx x0xx) をクリアします。

ETR がカプセル化解除するとき, Locator-Status-Bits フィールドの変化をチェックします。あるビットが 1 から 0 に変わると, ETR が ITR としても機能する場合, ダウンとマークされた RLOC へのパケットのカプセル化を停止します。対応する Locator-Status-Bit が 1 に戻ったときにのみ, その RLOC の使用を再開します。Locator-Status-Bits は各 EID-Prefix の Locator-Set に関連付けられています。したがって, Locator が到達不可能な場合, 最後の Map-Reply で返されたリスト内のその Locator の位置に対応する Locator-Status-Bit は, その EID-Prefix に対してゼロに設定されます。

サイト内の ITR が CE ルータに展開されていない場合でも, Locator が IGP に注入されていれば, IGP を使用して Locator の到達可能性を判定できます。これは通常, ループバックインターフェイスに /32 アドレスを構成するときに行われます。

ITR が ICMP Network Unreachable または Host Unreachable メッセージを到達不可能性を判定する手段として使用する場合, Map-Reply の Locator リストに記述されている Locator の使用を停止します。ただし, この方法は信頼性が低いです。多くのネットワークオペレータが ICMP Destination Unreachable の生成をオフにしているためです。

ITR が実際に ICMP Network Unreachable または Host Unreachable メッセージを受信した場合, ITR がカプセル化したデータパケットを開始したホストに対して, 自ら ICMP Destination Unreachable メッセージを生成できます。

さらに, BGP 対応の ITR は RIB を一方的にチェックして, マッピングエントリの Locator-Set の locator アドレスが何らかのプレフィックスに一致するかどうかを確認できます。見つからず, BGP が Default-Free Zone (DFZ) で実行されている場合, Locator-Status-Bits が Locator が up であることを示していても, その Locator を使用しないことを決定できます。この時点で, ITR からその Locator が割り当てられた ETR へのパスは利用できません。詳細については [LOC-ID-ARCH] を参照してください。

オプションで, ITR は Locator に Map-Request を送信でき, Map-Reply が返された場合, その Locator が到達可能であると判定されます。明らかに, このようなプローブを送信すると, アクティブフローのためにトンネルルータが生成する制御メッセージの数が増加するため, アドバタイズされた Locator が到達可能であると仮定されます。

この仮定は実際に依存関係を作成します: Locator の到達不可能性は ICMP Host Unreachable メッセージの受信によって検出されます。Locator が到達不可能であると判定された場合, アクティブトラフィックには使用されなくなります。これは, Map-Reply で Priority 255 でその Locator をリストするのと同じ効果があります。

ITR は, 到達不可能な Locator の到達可能性を定期的に Request を送信することでテストできます。Request と Reply の両方はレート制限されなければなりません。Locator 到達可能性テストは, データパケットを使用して実行されることはありません。それはエンドツーエンドセッションのパケット損失のリスクを増加させるためです。

ETR がパケットをカプセル化解除するとき, カプセル化 ITR から自分自身に到達可能であることを知ります。パケットがまさにそのパスを経由して到着したためです。ほとんどの場合, ETR は ITR にも到達できますが, パスが非対称である可能性があるため, これを仮定することはできません。ITR から ETR への一方向トラフィックがある場合, ITR は戻りトラフィックの欠如を ETR が到達不可能であることの指標として使用すべきではありません。代わりに, 到達可能性を判定するために他のメカニズムを使用しなければなりません。