OSPF 最大メトリック：ブランチを削除せずにトランジットを避けさせる

二つのオフィスは、自らのトラフィックとごくわずかな他のトラフィックだけを運ぶべきブランチを介して接続されています。ブランチは両方のサイトへの経路を必要とし、どちらのサイトもブランチを両者間の経路として優先すべきではありません。ブランチをトポロジから削除すればトランジットの問題は解決しますが、要件は破られます。ブランチは依然として両方のサイトに到達する必要があり、両方のサイトも依然としてブランチに到達する必要があるからです。

必要なのは、ルーティング プロトコルで表現される優先度であり、ブランチを完全に到達可能なままにして、そこを通るあらゆるものにとって悪い選択にするものです。ルータが見ている順序で問題をたどってください。

避けたい経路から始める

トポロジを図面が見る姿ではなく、プロトコルが見る姿で描きます。どのインターフェイスが隣接を形成し、どれが同じエリアにあり、ブランチが優先された場合にそれらの隣接のどれが二つのオフィス間のトラフィックを運ぶのか。これは三つの別々の問いであり、図面はそのどれにも確実には答えません。

次に代替経路を見つけます。オフィス間の唯一の経路がブランチを通るなら、トラフィックをそこから動かせるメトリックはありません。トラフィックの行き先がないからです。冗長性はこの設計の細部ではなく、前提条件です。紙の上にしか存在しない二番目の経路は数えられません。

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

これら三つのビューは異なる問いに答えます。誰が隣接しているか、どのインターフェイスが参加しどのコストで参加するか、デバイスが現在どの経路を選択しているか。トンネルの導入は四つ目を加えます。図面の線はその上で隣接が形成された証拠ではなく、形成された隣接は転送が同じ経路をたどる証拠ではありません。トンネル設計でこそ、この隙間が最もよく現れます。

最大メトリックが広告するもの

RFC 6987 は、非スタブ リンクを最大リンク メトリックで広告するルータを説明しています。最大リンク メトリックは 0xffff と定義されます。ルータは自身とそのリンクを依然として記述しますが、範囲の上限で値付けするため、他のすべてのルータはそれを経由する経路を高コストと計算します。

これは router-LSA の変更であり、トポロジの削除ではありません。区別は重要です。router-LSA をフラッシュするとトポロジ情報そのものが取り下げられ、ルータとその背後のプレフィックスに到達するために必要な関係も取り下げられる可能性があります。広告を保持して価格を上げれば、それらの関係は保たれます。これがこの手法と削除の違いのすべてです。

RFC 6987 の仕組みは、エリア タイプや指定ルータの選出とも無関係です。スタブ エリアはエリア境界でリンク状態広告の一種を遮断し、スタブ ルータは自身のリンクに値付けします。似た言葉ですが、無関係な仕組みです。

到達可能性が残り、トランジットが残らない理由

他のルータは依然としてブランチの接続プレフィックスへの経路を持ちます。ブランチがそれらを広告し続け、リンクも存在し続けるからです。変わるのは、ブランチを通ってどこか別の場所へ向かうあらゆる経路の総コストです。プレフィックスは移動せず、ルータを通過する価格だけが変わります。

送信元または宛先がブランチ自体であるトラフィックには、高コストのリンクは依然として唯一の妥当な経路上にあるため、使用されます。二つのオフィス間のトラフィックには、代替経路がコストで勝ち、ブランチはトポロジから消えることなく転送の判断から外れます。二つの方向、二つの異なる答え、そしてそのどちらも仕組みが働いている証拠です。

これが想定ではなく検証すべき動作です。ブランチが生成する router-LSA を見て、次にブランチの背後の宛先と別のオフィスの宛先に対して別のルータが選択する経路を見ます。二つの答えは異なるはずで、異ならないならメトリックの変更は思っている判断に届いていません。

最後の経路の問題

同じ RFC は、この手法が使用を禁止しないことを明示しています。代替経路が失敗すると、ルータはブランチを通る高コストの経路に戻ります。それは依然として有効な経路であり、プロトコルは経路がないことより高コストな経路を好むからです。

そのフォールバックを受け入れられるかは、導入前に答えるべきポリシーの問いです。小さなアップリンク上のブランチが突然オフィス間トラフィックを運ぶのは、停止より悪いことがあり、保守ウィンドウ中にはまさに望むことでもあります。どちらの答えも正当であり、沈黙は正当ではありません。

要件が優先度ではなく厳格な禁止であるなら、メトリックの設計だけではそれを生み出せません。意図に合った転送の強制と、それでもトラフィックが到着した場合の定義済みの動作が必要です。経路を使用可能と広告してからトラフィックを落とすと、ルーティング ループより診断が難しいブラック ホールができます。

OSPFv3 では、RFC は R ビットをトランジット参加を除外する別の方法として論じています。最大メトリック手法と同じ最後の経路の動作を継承すると仮定せず、二つのアドレス ファミリ間で設定を同じ機能であるかのようにコピーしないでください。

正常時と障害時の両方で証明する

二回テストします。一回は両方の経路が利用可能な状態で、もう一回は優先経路を削除した状態です。最初のテストは優先度が機能していることを示し、二回目は優先度を守れないときにネットワークがどう振る舞うかを示します。二回目を省略すると、重要な半分が未検証のままになります。

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

データベース ビューは広告されたメトリックを示し、経路検索は選択されたネクスト ホップを示し、トレースはパケットが実際にどこへ行ったかを示します。この三つが一致すれば、正しく見える設定ではなく、検証済みの設計があります。

その後、優先経路を復元し、ブランチが自分のトラフィックだけを運ぶ状態に戻ったことを確認します。復元の手順は後片付けではなくテストの一部です。次の変更までしか機能しない設計は設計ではないからです。フォールバックを含む両方の結果を書き留めてください。二番目の結果こそ、誰かが午前三時に必要とする答えです。