VPLSマルチホーミングの変更をL2 CEデバイスに通知する方法

次の設定があります。

2つのMXルーターが同じL2サイトに接続します。ループ保護/冗長性は、VPLSマルチホーミングを介して行われます。もう一方の端には2つのスイッチがあります（EX4200など）。

青いリンクに障害が発生した場合、2つのスイッチと残りのL2インフラストラクチャは、トラフィックが黄色のリンクを通過する必要があることを認識する必要があります（その結果、右側のEXスイッチを通過します）。

問題は、黄色のリンクを介してVPLSから到着するトラフィックがある場合にのみ、黄色のMACテーブルがいっぱいになることです。特定のMACアドレスからトラフィックを受信しない場合、そのアドレスのトラフィックは青いリンクを介して送信され、そのリンクが現在切断されていることは誰にもわかりません（リンクが物理的に故障した場合の左側のEXスイッチを除く）。

この問題を解決する良い解決策が見つかりません。

いくつかのアプローチ：

1. 青/黄色のリンクをポートファーストにしないことで、影響を多少軽減して、インターフェイスがダウン/アップしたときにスパニングツリーがトポロジ変更を送信できるようにすることができます。インターフェースが物理的にダウンしない場合、あなたは運が悪いです。一方、ポートが再びアップすると、スパニングツリーソリューションが問題を引き起こします。VPLSはサイトをオンラインにしますが、ポートはトラフィックを転送する前にSTP学習段階を通過する必要があります。

2. 2つのスイッチをスタックできます。残りのL2インフラストラクチャは常に同じスイッチ（スタック）に送信するため、これにより問題が解決します。それでも、スタックは、アクティブなVPLSインスタンスで他のアップリンクインターフェイスに切り替えるタイミングを知る必要があります。

3. 計画的なメンテナンスを行う場合（およびスタックがある場合）、プライマリリンクを手動で非アクティブにして、セカンダリリンクに切り替えることができます。次に、ルーター上の非アクティブなリンクのサイト設定を下げて、現在アクティブなサイトが新しいプライマリになるようにします。元に戻すときも同じです。理想的ではなく、予期しない停止に対しては機能しません。

これを解決する方法についてのご意見をお待ちしています。（EVPN / TRILLの待機はカウントされません。;））

1. PEに面するポートでCEを使用してPortfastを無効にします
2. CEネットワーク全体でRSTPを有効にする
3. インターフェイスコストのある「ブルーリンク」を優先

私の頭の中でこれをうまく処理すると、次のように反応するはずです：

青いリンクが停止すると、CEは青いインターフェイスからのBPDUの送受信を停止します。デフォルトのRSTP helloタイマーは2秒です。それは、そのリンクを「死んだ」と呼ぶ前に、3つの逃したhelloを待ちます。3つのhello（6秒）が失われると、STPツリーが再確立され、MACアドレスが古くなります。

これは、私がコメントと元の投稿を読んだ方法を除いて、PEをSTPに参加させたいように聞こえることを除いて、基本的に上記のオプション1です。すべてのCE間で独自のツリーを構築できるようにすることをお勧めします。

ネットワークはスムーズにフェイルオーバーし、クライアントネットワークは数秒後にそれに追随します。

これは答えが簡単すぎるように感じます...しかし、あなたの書き込みに基づいて私はそれを見ることができます。

どのような収束予算を探していますか？

VPLSループ防止を使用するという考えを捨てて、一意のサイトIDを実行する場合は、STPに戻ることができます。ハードウェアの活性化障害がない場合でも、BPDUを介したリンクの損失が発生します。

次に、TCN /転送時間（TCNが確認された後のMACタイムアウト）またはより大きなハンマー「mac aging-time」によって収束バジェットを調整できます。
フリップサイドは、ネットワークに未知のユニキャストが多くなることです。これは、ARPタイムアウトがTCN /転送時間以下になるようにすることで回避できます。

たぶんあなたが探している答えはわかりませんが、ここに銀の弾丸があるとすれば、それがありません。このシナリオでは、トリルまたはEVPNドラフトが役立つことはないと思います。VPLSまたはEVPNがホストポートに対するエンドツーエンドの権利である場合、これは修正されます。ただし、コアでVPLSをEVPNに置き換え、どちら側でも切断されたLANを維持するだけで同じ問題が発生します。

あなたが提供するオプションにこだわって、私は個人的にあなたのリストの＃1に従いますが、一般的なSTは使用しません。リンクがアップまたはダウンしたときに高速/スムーズな移行が可能になるため、RST（またはリンク間でVLANをロードバランスする必要がある場合はMST）を使用したいと思います。

これは、このアプローチに対するあなたの両方の懸念に対処します。

1. 「インターフェースが物理的にダウンしない」-RSTを実行している各デバイスは、（単にリレーするのではなく）BPDUを生成し、キープアライブとして使用されます。BPDUの受信に失敗すると、情報が期限切れになります。
2. 「トラフィックを転送する前にSTP学習段階を経る必要がある」-RSTは、タイマーを待たずにポートが転送状態に安全に移行できることをアクティブに確認できます。

また、デバイスの管理を単純化するだけなので、＃2を実行することも検討します。

おそらく、「失敗した」MXでイベントスクリプトを作成してリンクをダウンさせることができますか？点灯している輸送手段がある場合、それは機能しない可能性があります。

このように私が取り組んだほとんどのアプリケーションでは、移動するはずの削除MACが最終的にバックアップポート経由で着信し、古いFIBエントリが削除され、新しいポートがインストールされるような、双方向トラフィックがありました。

これらのEXesによって提供されるL2サイトがトラフィックを送信するだけの場合、私ができると思う唯一のことは、mac-table-aging-timeを許容可能な量に減らすことです。