サイト内で同一の iESI、サイト間では一意：Junos ステッチング

二対のゲートウェイが二つのデータセンターを担い、設計にいくつの interconnect ESI 値が必要かを誰かが決めなければなりません。答えはゲートウェイグループごとに一つであり、fabric ごとに一つでもゲートウェイごとに一つでもありません。これを誤ると、設定済みに見えるのに誤った forwarder を選ぶ fabric ができたり、別々に保つはずだった二つのサイトが統合されたりします。このルールと例外は、ゲートウェイ一覧のそばに書き留める価値があります。

二つのスコープ、二つのルール

サイト内では、冗長な interconnect ゲートウェイが一つの multihomed エンドポイントとして動作するため、単一の interconnect ESI を共有します。その peer は、二つの独立したメンバーではなく一つの論理メンバーを見る必要があります。共有値の要点はまさにそこです。

サイト間では、各ゲートウェイグループが独自の値を取ります。同じ識別子を共有する二つのデータセンターは、コントロールプレーン上で一つの multihomed グループになり、これは WAN をまたぐステッチング設計が通常意図するものではありません。一つのグループに入った二つのサイトは、互いの障害モードも継承します。

サイト内：グループに一つの ID

ペアには両方の peer で同じ値を、同じサービスコンテキストで与え、チャットのスレッドではなくネットワークの識別子台帳に記録します。二つのメンバー間の不一致は、メンバー一つのグループと明白なアラームがない状態を生む障害モードです。動作しているセッションを信じる前に、両方のメンバーを比較してください。

サポートされるモデルは all-active です。同じリファレンスは、このステッチング ID に対して single-active 運用、自動導出の LACP 識別子、source-bmac オプションを除外しているため、それらのいずれかを前提とした設計は、識別子を選ぶ前に見直す必要があります。この制約は設計の入力であり、脚注ではありません。

サイト間：異なる値、または意図的な統合

サイトごとに一意の値を使えば、二つのゲートウェイグループは分離されたままです。意図が本当に一つの multihomed グループをサイト間に広げることなら、それはレイテンシ、障害、転送に関する独自の影響を持つ別のアーキテクチャであり、識別子の選択ではなくアーキテクチャとして決めるべきです。保守ウィンドウの前に、その決定を書面で求めてください。

意図した区別を計画に書き込み、後から動作するサイトのテンプレートをコピーするエンジニアが、その識別子まで持ち込まないようにします。

peer ステートメントは ID の一部です

グループ内の各ゲートウェイは、loopback アドレスでローカルの peer を列挙し、その関係は個々の MAC-VRF の中ではなくグローバルの EVPN レベルに存在します。これを誤った階層に置くことは、commit は通るがグループを決して形成しない設定を作るよくある方法です。リファレンスの階層を一度読み、それに従ってください。

ステートメント名も移りました。Juniper は 24.2R1 で interconnect peer-gateways ステートメントの名前を変更し、24.4R1 でデータセンター interconnect 向けの interconnect 固有の形式を復元しました。したがって中間リリースから取ったスニペットは、配備済みのバージョンが受け付けない名前を使うことがあり、またその逆もあります。スニペットがどのリリース由来かを、スニペット自体のそばに記録してください。

iESI を共有してもできないこと

route target、VNI、ローカルの EVPN インスタンスを代わりに定義することはありません。それらは両側で一致しなければならない別個の設定のままであり、識別子が一致しても route target が一致しない場合、グループは形成されるが何も運ばない状態になります。これらの設定の両側を同じパスで比較してください。

peer の到達性や designated forwarder の選出を証明するものでもありません。通常のケースで unicast と必要な broadcast および multicast の動作を試し、次にゲートウェイを一つ外して、残ったメンバーがグループを単独で担うことを確認してください。

その二回目の実行こそが、グループが実在することを証明します。

観測されたメンバーシップとサービスコンテキストをテスト結果と共に保管します。後日の識別子変更は、文字列の見た目の修正ではなく、実際のところ multihoming の変更としてレビューできます。結果だけが、識別子が図面のとおりに動作している唯一の証拠です。