Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

マルチホーミングを使用した EVPN in Multicast の最適化

 

EVPN のマルチキャスト最適化により、帯域幅の節約、リーフデバイスのレプリケーション/処理負荷の軽減という点で、いくつかのメリットが得られます。IGMP の結合状態をアクセスインターフェイスで追跡することで (マルチキャストレポートから構築されます)、EVPN core (リモート BGP タイプ 6 SMET ルート) では、EVPN デバイスは、その背後のリスナーを持つインターフェイス/Pe のみに対して、それぞれのトラフィックを選択的に転送します。

レポートと SMET したルートに基づく状態と転送を追跡すると、EVPN マルチホーミングを使用したシナリオが可能になり、マルチホーム EVPN デバイス間で状態を同期するために追加の手順が必要になります。この章では、EVPN マルチホーミングで IGMP スヌーピングを有効にする際の課題について説明し、これらの課題に対処する手順について説明します。

EVPN マルチホーミングの問題 (IGMP スヌーピング)

最初に’検討しFigure 1てみましょう。ここでは、リーフ-3、リーフ-4、およびリーフ-5 が ESI でマルチホームになっています。

リーフ’-4 が DF で、リーフ-3 とリーフ5が非 DFs であるとしましょう。リーフ-2 およびリーフは、他のシングルホーム Pe です。

Figure 1: マルチホーミングのシナリオでの IGMP の覗き見
マルチホーミングのシナリオでの IGMP の覗き見

ここで問題について説明’するために、リーフ-1 が受信で、それが受信する (imet) 転送を実行することを検討してみましょう。したがって、リーフ-1 は、タイプ 6 smet したルートに基づいて選択的に転送するのではなく、コアへのトラフィックをフラッディングしています。

Host 5 は、group G のトラフィックに関心のある IGMP ホストであるとします。そのため、IGMP (*、G) レポートを送信します。集約インターフェイス (AE) バンドル上で3つの LEAFs に対してマルチホーム化された CE は、そのレポートをマルチホームのいずれかの LEAFs に送信することがあります。これは、送信元 IP、宛先 IP、発信元 MAC などから構成される組に基づいて、CE がパケットに対して実行するハッシュによるものです。それでは’、CE が IGMP (*, G) レポートをリーフに送信するとしましょう。

(*, G) レポートを受信すると、(*, G) 用の IGMP 状態が作成され、G for core またはその他のアクセスインターフェイスからトラフィックが着信すると、トラフィックが CE に転送されるため、ホスト-5 になります。しかし、この例では、リーフは、EVPN マルチホーミングの各手順では非 DF になっています。レポートは、リーフ-4 またはリーフ5に到達しなかったため、(*, G) の IGMP 状態を作成しません。

リーフが、包括転送を使用して group G のトラフィックの送信を開始すると、マルチホームの LEAFs はすべて、コアからのトラフィックを受信します。(古典-df-NDF)ルールでは、DF だけがトラフィックをアクセスインターフェイスに転送します。ここでは、リーフ-4 が DF になっています。

しかし、リーフ-4 は (*, G) の IGMP 状態を持たないため、リーフ4はトラフィックを転送しません。しかし、リーフは、(*, G) の IGMP 状態を持っていますが、マルチホームリンクの非 DF であるため、トラフィックを転送しません。リーフ-5 は、IGMP であるということではありません。これは、NDF でもあります。

このため、マルチホーム Pe がホストにトラフィックを転送するようになっていません。これは明らかに望ましくない状況です。

一部のグループで CE のハッシュタプルが使用されている場合、一部の IGMP レポートがリーフに到達した場合、DF (リーフ) は、(*, G) 状態を作成し、コアからのトラフィックが到達すると CE と Rcv-1 にトラフィックを転送します。これは定常状態で保持されます。

しかし、問題はまだ残っています。リーフ-4 がダウンした場合、またはリーフ4のマルチホームインターフェイスがダウンした場合、リーフ-3 が DF として選ばれる可能性があります。リーフは IGMP (*, G) 状態になっていないため、トラフィックを転送しません。レポートの更新は、非 DF さんに送信される場合があります。これは、以前と同じ状態になる場合があります。

選択的な転送によるマルチホーミングの問題

[包括的な転送] の問題は、EVPN core からのトラフィックがすべてのマルチホームピアに到達したときに、IGMP 状態を持つリーフ3が非 DF であり、DF に IGMP 状態を持たないリーフ4が原因で、受信側に転送されないということです。’S レビュー Figure 2を行います。

Figure 2: 選択的転送によるマルチホーミングシナリオによる IGMP の覗き見
選択的転送によるマルチホーミングシナリオによる IGMP の覗き見

このことは、選択的転送にも問題になります。「リーフ-3」と「リーフ-6」が BGP、アクセス時に学習した状態を反映するためにルートが 6 SMET していた場合、リーフ-1 はマルチキャストトラフィックをリーフ-3 およびリーフ-6 にのみ転送します。この例では、リーフ-3 は、グループの IGMP 状態を持っていますが、非 DF であるため、受信側にトラフィックを転送するわけではありません。

「包括的な転送」と IGMP スヌーピング機能 (言い換えれば、BUM フラッディングの手順) では、トラフィックがリーフによってあふれ、すべての送信リーフデバイスに到達するため、これが問題になることはありません。DF であるリーフは、トラフィックをホストに転送します。

Igmp の覗き見と選択 (smet) 転送によって‘’あらゆる問題が解消されるので、この問題を解決するために役立つ # pn ルートタイプに関する以下のセクションで、igmp スヌーピングと evpn マルチホーミングによって発生するこの特定の状況に対処することは、価値のあることです。

マルチホーミング PEs で IGMP 状態を同期するには、タイプ-7 結合-同期ルートを BGP します。

ここで説明されている問題に対処するには、グループ G をマルチホーム PEs 間で同期するための IGMP 状態を必要とします。IGMP 状態がマルチホーム Pe の間で同期された場合、DF は (*, G) 状態になり、そのためトラフィックがレシーバーに転送されます。

ESI インターフェイス上で学習された特定のグループの IGMP 状態は、BGP タイプ-7 結合ルートを使用することで、同じ ESI をホストする他の MH ピアと同期します。この exchange に基づいて、マルチホーム EVPN PEs は、グループの IGMP 状態とインストールの転送状態を同期させることができます。これにより、関連するマルチホーム Pe が、その ESI の DF を選択するためにトラフィックを転送するための位置になります。

Figure 3: BGP Type-7 IGMP Join-Sync Route 制御プレーンの手順
BGP Type-7 IGMP Join-Sync Route 制御プレーンの手順

Figure 3は、IGMP レポートのリーフは3に達しています。イベント-[1] の一部として、リーフ-3 は、VLAN、グループ、ESI 情報とともに BGP タイプ-7 を使用します。このタイプ7のルートは、リーフとリーフの間のみでインポートされます。そのため、これらの LEAFs は ESI をホストしています。その他の LEAFs は、このタイプ7のルートをインポートしません。

2番のタイプ7のルートを受け取ると、リーフインターフェイスをマルチホーム ESI インターフェイス (イベント-[2]) として送信インターフェースを使用して、その特定のグループ用に IGMP 状態を構築します。このようにして、グループ G の IGMP 状態はマルチホーム PEs 間で同期されます。

VLAN について学習した IGMP の状態を理解することで、最適化の章で説明したように、 EVPN Intra-VLAN Multicast with Optimizationに記載されている手順は、グループ/VLAN のタイプ6ルートのマルチホーム PEs になります。(イベント-[3])。

EVPN Type-7 NLRI Route

タイプ-7 ルートは、ルート識別子、VLAN、マルチキャストグループ、ソース、ESI、および発信元 IP で構成されています。このルートは、拡張されたコミュニティーで ESI 値も伝達します。これにより、ESI をホストする PEs だけが、このタイプ7のルートをインポートするようになります。

タイプ-7 ルートは、EVI と呼ばれるコミュニティーも備えています。このコミュニティでは、IGMP 状態を同期する必要がある EVPN インスタンスを特定します。タイプ2およびタイプ6ルートで追加された一般的なルートターゲットは追加されません。ここでは、タイプ7のルートを、対象の特定の ESI をホストする PEs のみにインポートすることを目的としています。

Figure 4: タイプ-7 ルートヘッダー
タイプ-7 ルートヘッダー

Tracking of Type-7 Routes from Peers

EVPN PE は、特定の ESI で受信した IGMP レポートに基づいて、ローカル IGMP の状態を作成します。同一の ESI の背後に複数のホストがあり、グループのレポートを送信している場合があります。レポートが異なるマルチホームピアに着陸している場合があります。この場合、アクセス側 ESI インターフェイスから IGMP レポートを受信した PEs は、タイプ-7 から生成されます。

1つのリーフで IGMP 状態タイムアウトが発生した場合、その状態をすぐに削除してはなりません。代わりに、同一の VLAN/Group/ESI/EVI に対して、他のリモートタイプ7のルーティングが提供されているかどうかを確認する必要があります。その場合、元のタイプ7は引き出されますが、IGMP の状態は維持されます。

Type-7 Withdraw Semantics

IGMP の状態がタイムアウトになると、タイプ7のルートが撤回され’ます (ホストが ESI 上の状態を更新していない場合)。タイプ7の withdraw を受け取るリーフデバイスは、状態のクリアに注意する必要があります。このタイプ7の withdraw は、ESI リンクがダウンしているか、またはオリジネータノード自体が停止していることが原因である可能性があります。受信のための PE は、それが実際にステートタイムアウトになっていることを確認してから、状態をクリアするか、トラフィックドロップが発生することを確認する必要があります。

タイプ-6 SMET は、収束を改善するためにルートを満たすようになっています。

通常、このタイプ7のルートを受け取るのは、コアからトラフィックを取り込み、トラフィックをアクセスに転送することが想定されているため、タイプ-6 でなければなりません。ただし、DF ノードに障害が発生した場合、または DF 上の ESI リンクが失敗した場合は、新しい DF を選択し、タイプ 6 SMET ルートを生成する必要があります。また、受信する PE リストに新しい DF が含まれている必要があります。これにより、BGP メッセージ交換が発生するため、遅延がかなり長くなる可能性があります。

これは、非 DF Pe が、定常状態の受信からトラフィックをプルするが、非 DF であることによってアクセスを転送しないように、タイプ 6 SMET 準拠のルートを生成した場合にも緩和できます。その後、DF に障害が発生すると、新しい DF が選択されると、すでにコアから到達したトラフィックがあることになります。そのため、新しい DF が必要なのは、トラフィックをアクセスに転送することです。その結果、コンバージェンスが大幅に向上します。

Figure 5: BGP Type-7 IGMP Join-Sync ルート制御プレーンの手順よりも優れたコンバージェンス
BGP Type-7 IGMP Join-Sync ルート制御プレーンの手順よりも優れたコンバージェンス

Figure 5は、すべてのマルチ–ホーム PEs、リーフ-4、およびリーフ-5 –のタイプ 6 smet が、グループのルートを満たしています。これにより、リスト内のマルチホームのすべての Pe を含むリーフが生成されます。したがって、非 DF Pe はトラフィックを受信しても、ESI インターフェイスに転送されませんが、フォワーダーが行われるようになるとすぐに転送を再開できます。

まとめ-IGMP 結合-同期およびマルチキャスト転送

このスキームでは、レポートがマルチホームセグメントに到着する場所に関係なく、ESI のすべてのマルチホーム Pe がグループ G の IGMP 状態を持ち、トラフィックを DF PE によって受信者に転送する準備が整っています。タイプ7のルートは、受信 PE が適切な IGMP 状態を、関連する VLAN、EVI、ESI に対して正確に作成できる情報を伝達します。

Figure 6: IGMP 状態同期に基づくトラフィック転送
IGMP 状態同期に基づくトラフィック転送

ESI 上のマルチホーム Pe はすべて、group G の IGMP 状態を持ちます。少なくとも、ESI の DF PE はタイプ6のルートを元にしていますが、より優れたコンバージェンスを実現するために、非 DF PEs は、タイプ6とプルトラフィックを発生させます。IGMP 状態がすでに BGP タイプ7の結合同期ルートと同期しているため、コアにトラフィックが到着すると、トラフィックはアクセス ESI インターフェイスに転送されます。

また、IGMP 同期状態はコヒーレントであるため、ピアタイプ-7s の追跡も必要不可欠です。タイプ7のルートの引き取りは、引き出しの原因を特定するために慎重に処理する必要があります。その後、IGMP の状態のクリア/保持に進みます。

IGMPv2 に関する問題

前のセクションでは、IGMP (*, G) レポート状態をマルチホームの PEs で同期する方法について説明しました。このセクションでは、マルチホーム化されたシナリオで IGMP Leave メッセージを処理する際に、特別な考慮事項があるという問題について説明します。

IGMP Leave 入門

(*, G) の IGMP レポートメッセージを使用して、特定のグループ G のリスナー利息を伝達するのと同様に、IGMP Leave メッセージは、ホストによるグループのリスナーの関心の引き出しを伝えるために使用されます。

IGMP Leave メッセージがスイッチによって受信された場合、トラフィックが受信者に送信されないように、転送に使用される IGMP (*, G) 状態をクリアする必要があります。スイッチは、その状態をクリアする前に、グループに他のホストが存在しないことを確認する必要があります。

このため、このスイッチは、グループ G の最後のメンバークエリ (LMQ) を送信して、他の興味深いホストからのレポートを確認します。スイッチが、特定の期間 (LMQ 間隔) までグループ G のレポートを受信しない場合は、(*, G) の状態がクリアされます。間隔の前に他のホストがレポートを送信した場合、その状態は保持されます。

「退席中」の遅延とは?

マルチキャストアプリケーションは、望ましくないトラフィックに非常に敏感です。たとえば、IPTV ホストでは、group G1 の IGMP レポートを送信して、トラフィックを受信することで、チャネル1が求められる場合があります。アクセスインターフェイスの帯域幅によって、1つのチャネルからのトラフィックにプロビジョニングが提供されているとします。ユーザーが channel 2 に切り替えると、ホストは、グループ G2 のための Leave を送信し、グループの IGMP レポートを送信することによって、channel 1 の利息を引き出します。

スイッチは、G1 用の Leave メッセージを処理する必要があり、その他のリスナーが存在する場合は、そのリスナーが他にない場合は、G1 の状態をクリアし、G1 への転送を中止します。この後、グループ G2 の IGMP レポートを受信すると、スイッチは (*, G2) の状態を作成し、G2 の転送トラフィックを開始しなければなりません。

何らかの理由で、スイッチが G1 の状態をクリアするのに時間がかかり、両方のグループに対して G2 と転送のトラフィックが発生した場合、プロビジョニングされた帯域幅は、両方のチャネルを実行するには不十分であるか、IPTV ホストでひずみが発生する可能性があります。また、ホストが2つのグループのトラフィックを処理できない場合もあります。

全体的に、スイッチは、「退席中」のメッセージを受信してすぐに対応できるようになります。また、リスナーが存在しない場合は状態をクリアしてください。このような状態のクリアの遅延は、「 Leave Latency 」と呼ばれ、IPTV および株式相場のアプリケーションを検討するうえで重要となる要素です。

Leave メッセージがワイヤ‘’で失われたり、処理されなかったりすると、トラフィックはリスナーに転送されます。このスイッチでは、IGMP レポートが定期的に受信されない場合、60秒ごとに、IGMP タイムアウト間隔の後、たとえば、210秒後に状態をクリアします。

そのため、Leave メッセージが失われたり、処理されなかったりすると、IGMP タイムアウトが発生するまでトラフィックがフローを継続します。IPTV に遅延が発生しているのは、そのようなホストの感度により、IGMP 学習率よりも慎重に考慮されています。

IGMPv2 の微妙な特性により、メッセージを残す

IGMP レポートメッセージには、ホストの送信元としてソース IP、宛先 IP フィールド、およびホストが関与するマルチキャストグループアドレス G があります。

ただし、IGMP Leave メッセージは宛先 IP フィールドを224.0.0.2 としており、ウィズドロウする必要があるグループは Leave メッセージのペイロード内に存在しています。これまで、この理由は IGMPv2 に該当しています。IGMPv2 ホストは広く普及しており、正常に機能しているため、このような方法になっています。

Why is This Relevant to Optimized Multicast with Multihoming?

前述したように、CE は、送信元 Ip、宛先 Ip、送信元 MAC などに基づいて、受信したパケットをハッシュします。レポートの宛先 IP フィールドは Leave メッセージのアドレスと同じではないため、レポートはマルチホーム EVPN PE に送信されますが、Leave メッセージは別のマルチホーム EVPN PE に送信されます。

IGMPv3

次のセクションでは、224.0.0.2 の宛先アドレスを持つメッセージを残すことによって発生する課題について説明します。IGMPv3 は、IGMPv3 report と IGMPv3 Leave メッセージがペイロードに含まれ、レポートと Leave メッセージの両方の宛先アドレスが224.0.0.22 であるため、この問題の原因にはなりません。ここで、この違いが重要な理由を理解することができます。

How Does This Cause a Problem in a Multihoming Scenario?

Figure 7は、IGMP レポートがリーフに送信される場合があります。その後、group G のトラフィックに関心がない場合、(*, G) という単位を送信します。この IGMP Leave は、Leave の宛先 IP アドレスフィールドが224.0.0.2 であり、IGMP レポートの場合はグループそのものであるため、同じグループに対して同一のポートで送信される場合があります。これは、CE にパケットの宛先 IP アドレスが含まれているためです。ハッシュのタプルを計算しています。

Figure 7: IGMPv2 に関する問題マルチホーミングのシナリオを残す
IGMPv2 に関する問題マルチホーミングのシナリオを残す

これ’について詳しく見ていきましょう。でFigure 7は、アクセスインターフェイスで igmp レポートを受信し、igmp (*, G) 状態 (ローカルで学習済み) を作成し、タイプ7のルートを発行しました。リーフ-4 とリーフ-5 はタイプ7をインポートし、IGMP (*, G) 状態を作成します (リモートで学習)。そこまでは問題ありません。

Leave メッセージがリーフ5に到達した場合のシナリオを考えてみましょう。ここで期待される動作は何でしょうか。LMQ は、CE に送信してレポートを要請する必要があります。また、特定の間隔を経過する前にレポートが到着しなかった場合、グループ G に対してトラフィック転送が停止するように、すべてのマルチホーム Pe (特に DF) から状態をクリアする必要があります。

オプションとは? 既存の IGMP Leave processing 処理ルールだけを開始する場合は、聴覚終了時に残りの5人が LMQ を送信します。ホストが不要になった場合はどうなるでしょうか。レポートが初めて着陸したリーフは、Leave を聞いていません。そのため、リーフ-3 は210秒の状態をクリアせず、タイプ-7 はその長さでも提供されたままです。

リーフ-5 は、アクセス時に Leave メッセージを受信した場合には流束になりますが、リモート学習された状態にもなっています。1つ目のタイプ-7 ルートの作成者ではないため、リーフはタイプ-7 をウィズドロウできません。問題はさらに複雑になります。リーフ-5 は、リーフ-3 からのリモートタイプ7があるため、状態を保持します。「リーフ-4」と DF は、変換された IGMP (*, G) 状態を維持し、210秒間転送を維持します。

概して、ホストが Leave を送信し、それが実際にマルチホームの PE セットに達したとしても、Leave latency は210秒のままになっています。これは、明らかに望ましくない、マルチホーミングおよび最適化機能を備えています。

別のホストが LMQ の前にレポートを送信し、このレポートを別の PE (リーフ-4) に配信すると、これはさらに複雑になります。この時点で、リーフ-4 とリーフはローカル学習の状態を持っていますが、リーフ5はリモートで学習した状態と処理を行うことになっています。このシナリオでは、状態は、すべての PEs 上で IGMP (*, G) の状態が維持されるように調整する必要があります。

このため、この Leave の処理シナリオについては、IGMP 結合の同期に対応する必要があります。この問題は、Leave を同期する必要があるため、既存の IGMP Leave 取り扱い手順だけに依存して、解決するのが困難です。また、IGMP 結合 (*, G) は、BGP ルートに変換でき、交換される状態ではありませんが、Leave メッセージは実際には状態ではなくイベントです。

Leave メッセージを使用すると、以前に学習した状態がクリアされます。そのため、これは Leave があったリーフに対してはイベントとして表示されます。従来、BGP は、状態の追加/削除/更新を通知します。この Leave メッセージは BGP ルートと状態を引き取りするものと考えられていますが、その状態が発生していないという事実によって、州の引出を伝えることが難しくなっています。

このイベントは、退室遅延が許容範囲内であることを確認するために、グループのアクセス ESI インターフェースで最新のアクティビティと同期するように、マルチホームの PEs にも伝達する必要があります。また、最もよく使用されているのは、遅延がなくても、最も一般的なもの (i) IGMP Join、Leave、(ii)、Join、その後に別のジョインが続くことを意味します。

この問題を解決するには、Type-8 の Leave Sync ルートと呼ばれる別の BGP ルートを導入します。マルチホーム Pe がグループの状態 (*、G) に関して互いに同期していることを示します。

BGP Type-8 Leave Sync ルートによる IGMP 状態の調整

前のセクションで説明されている問題に’対処するには、このアプローチについて見ていきましょう。このソリューションの目的は次のとおりです。

  • アクセスから結合を受信するときは、IGMP 結合状態をすべてのマルチホーム Pe 間で同期させる必要があります。

  • マルチホーム設定でアクセスから休暇を受信した場合、すべてのマルチホームピアで LMQ タイマーが開始され、DF さんによって LMQ がアクセスに送信されなければなりません。

  • LMQ タイマーに達するまで結合が受信されない場合、IGMP 状態はすべてのマルチホームピアで削除される必要があります。

  • LMQ タイマーが満了する前に上書き IGMP 結合が受信された場合、IGMP 状態はすべてのマルチホームピア上で保持されている必要があります。

Figure 8は、ホスト-5 からリーフ (3) へのアクセスでジョインが受信され、タイプ-7 結合同期ルートを使用してマルチホームピア間で状態が同期されました。次に、’ホスト-5 は igmp leave を送信し、この igmp LEAVE はリーフ-5 (イベント-[1]) で受信されることになります。

Figure 8: BGP Type-8 Leave Sync ルート
BGP Type-8 Leave Sync ルート

Leave の受信時に、リーフ-5 はタイプ-8 ルート (イベント-[2]) を開始します。これは、タイプ-7 (VLAN、ESI、グループ、ソース、送信元 IP など) と同じである NLRI フィールドを使用しています。タイプ-8 の発信トリガーは Leave メッセージですが、このルートを引き取りするトリガーはありません。したがって、 ‘リーフ-5 は、同期後の’ leave の目的が提供された後、ルートを取り出すタイマーを開始します。

その他のマルチホームピアは、リーフ-3 とリーフ4において、タイプ8を受け取ります。これに基づいて、すべてのマルチホーム Pe は send LMQ を送信し、LMQ タイマーを開始します。この LMQ はマルチキャストメッセージであるため、DF は ESI で LMQ を送信するだけです。(イベント-[3])。

この LMQ タイマーを使用して、2つのイベントが発生する可能性があります。

  • イベント-A: このグループの LAN では、LMQ が期限切れになる前に、結合が受信されません。

  • イベント-B: このグループの LAN での参加は、LMQ の期限が切れる前に受信されます。

Event-A: No Joins Received on LAN in Response to LMQ (Join + Leave)

Figure 9lmq を送信し、lmq タイマーを開始した後、マルチホームのピアは、そのグループの IGMP レポートが更新されたかどうかを確認します。レポートが受信されず、LMQ タイマーが期限切れになった場合 (イベント-[1])。

Figure 9: イベント A: LMQ への応答で、LAN 上で結合が受信されませんでした。
イベント A: LMQ への応答で、LAN 上で結合が受信されませんでした。

Figure 9は、タイプ-7 の withdraws の送信者がタイプ7のルート (イベント-[2]) を所有しています。タイプ7のリモートルートの引き取りでは、マルチホームピアが IGMP 状態を削除して、アクセスへの転送トラフィックを停止します。(イベント-[3])。

ローカル状態に応じて、そのグループの VLAN にその他の関心があるアクセスインターフェイスがなければ、マルチホームデバイスは以前に送信されたタイプ6ルートを撤回します。(イベント-[4])。

Type-8 ルートを使用すると、状態がクリアされ、リーフ-5 withdraws がタイプ-8 ルート (イベント-[5]) を回避して古い残留タイプ-8 が発生しないようにします。そのため、そのフローのすべての状態をクリアします。

Event-B: Join Received Before LMQ Timer Expires (Join + Leave + Join)

Figure 10lmq を送信し、lmq タイマーを開始した後、マルチホームのピアは、そのグループの IGMP レポートが更新されたかどうかを確認するまでしばらく待機します。LMQ タイマーが満了する前に、別のホストが LAN 上で IGMP レポートを送信するとします。このレポートは、タイプ-7、リーフ-3 の以前の発信者、またはリーフ4という新しいオリジネータに到着することがあります。

Figure 10: イベント B: LMQ を期限切れにする前に LAN で参加を受信
イベント B: LMQ を期限切れにする前に LAN で参加を受信

If Refresh Report Arrived on LEAF-3, the Earlier Type-7 Originator

リーフ-3 は、アクセス時に更新されたレポートを受信すると、LMQ タイマーを停止します。タイプ7のルートを_notにウィズドロウします。その後、その他のマルチホームピアでは、LMQ タイマーが期限切れになると、グループのリモートタイプ7があるかどうかがチェックされます。グループにはリモートタイプ7があるため、マルチホームのピアは IGMP 状態を維持し、トラフィックの転送を継続します。

If Refresh Report Arrived on LEAF-4, Which Is Not the Earlier Type-7 Originator

アクセス時に更新されたレポートを受信すると、リーフ4が LMQ タイマーを停止します。また、他のマルチホームピアと同期されるタイプ7のルートも元にしています。’リモートタイプ7のルートを受信すると、その他のマルチホームのピアはそれをテーブルにインポートします。

LMQ が期限切れになると (レポートが更新されなかった後)、リーフ3で送信されたタイプ7をウィズドロウします。しかし、少なくとも1つのリモートタイプ-7 (リーフ-4 から) が存在するため、リーフ-3 は IGMP 状態を保持します。

さらに、「LMQ」が満了すると、少なくとも1つのリモートタイプ-7 (リーフから 4) が存在することになります。そのため、リーフ-5 は IGMP 状態も維持します。

最適化されたマルチキャストを実現するためのすべての組み合わせ

Figure 11元のトポロジを繰り返して、全体像を戻します。マルチホームホストであるホスト-3 とホスト5は、トラフィックに関心があります。マルチホームのリーフデバイスは、IGMP 状態を同期し、正しい転送が行われるようにします。この章の「トラフィック検証」セクションでは、このシナリオの詳細を示しています。

Figure 11: 最適化されたマルチキャスト転送
最適化されたマルチキャスト転送

章のまとめ

この章では、マルチホームトポロジにおける multicast の最適化に関連する微妙な違いについて解説しています。これを実現するために、ESI リンク上で受信した IGMP レポートを、ESI をホストするマルチホームピア間で同期させる方法について詳しく説明しています。また、コンバージェンスのために、マルチホームピアによってタイプ6ルートの供給を調査しています。

また、目的としては、IGMP Leave メッセージが、IGMP レポートを受信した PE とは異なり、タイプ-8 ルートによってどのように解決されるのかという問題が生じていました。

タイプ-6/7/8 では、コアとアクセスにおけるマルチキャストの最適化を実現しています。マルチホームの課題にも対応しています。Assisted Replication with SMETでは、これらの最適化と AR の組み合わせによって、両方のメリットを最大限に活用する方法をご紹介します。

構成

Figure 12リファレンストポロジを示しています。

Figure 12: リファレンストポロジ
リファレンストポロジ

Configuration

このセクションでは、EVPN Intra-VLAN Multicast with Optimizationで行われた設定を十分にご紹介します。

トラフィックの検証

すでに開始している既存のトラフィックを、 EVPN Intra-VLAN Multicast with Optimization、host-1 からの最適化章、host-6 の受信機を使用します。ホスト3では、リーフ-1 およびリーフ-2 にマルチホーム化されています。ここ’では、マルチキャストグループの受信者を開始します。225.1.1.1 では、VLAN-101 を使用します。

Figure 13RT 統計情報を見ると、10 Pps で Host 1 によって送信されたトラフィックが、関心のあるシングルホームレシーバーによって受信されるようになっていることがわかります。ホスト-6、関心のあるマルチホームレシーバーホスト-3、レガシーデバイス (VLAN-101 のホスト-7)。

Figure 13: RT 統計
RT 統計

Multicast Traffic Outputs - LEAF-1

これまでと同様に、負荷分散のマルチキャストトラフィックは、ae0 上でアクセスインターフェイスで受信されます。リーフ-1 は、このトラフィックを、関心のある IGMP レシーバーを学習したアクセスインターフェイス ae 1.0 で転送するようになりました。SRC ローカルバイアスルールは、DF/NDF ステータスに関係なく、リーフ-1 が ae 1.0 のトラフィックを転送できることを思い出してください。

マルチキャストトラフィックは、VTEPs 上で、境界リーフ PEs (101.101.101.101 および 102.102.102.102) およびリーフ-5 (109.109.109.109) へと転送されます。また、目的のレシーバーがあるので、VTEPs からリーフ-2 (106.106.106.106) およびリーフ-4 (108.108.108.108) へのトラフィックも送信されます。

関心のある受信者がいないリーフ-3 (107.107.107.107) は、依然としてトラフィックを対応しています。

Multicast Traffic Outputs - LEAF-2

アクセス側 IGMP スヌーピング機能を使用すると、リーフで受信したマルチキャストトラフィックをシングルホームインターフェイス、xe-0/0/4.0、または ae 0.0 (レシーバーなし) に転送できなくなります。

マルチホームアクセスインターフェイス ae が1.0 にはレシーバーがありますが、このインターフェイスでマルチキャストトラフィックが転送されないようにするため、DST ローカルバイアスルールがあることを思い出してください。これにより、マルチホームホストにトラフィックの複製が行われなくなります。 Host 2:

Multicast Traffic Outputs - LEAF-4, LEAF-5, and BL Devices

これらのデバイスでのトラフィック転送動作は変更されていません。そのため、出力は簡潔にするために省略されています。

詳細な制御プレーンの検証

Verification of EVPN Join-Sync with Multihomed Receivers

Host-3 はマルチホーム化されているため、IGMP レポートはリーフ-1 または2つのどちらにも到達できます。その場合は、リーフ-1 に到達します。

IGMP’レポートをスヌーピングして、リーフ-1 で igmp グループメンバーシップが VLAN-101 インターフェイス ae 1.0 で学習されたことを確認してみてください。

リーフが、ローカルに学習した EVPN タイプ7の結合同期ルートであることを確認します。マルチホームインターフェイス ae に対応する IGMP グループメンバーシップ:

リーフ-1 からの、この EVPN タイプ7ジョイン同期ルートが処理されていることと、ae 1.0 のリモートメンバーシップを学習したことを確認します。

Verification of EVPN IGMP Proxy State with Multihomed Receivers

Group 225.1.1.1 のローカル IGMP メンバーシップを学習しているリーフ-2 (EVPN Type 7 Join Sync ルート経由) を確認し、ローカル EVPN IGMP プロキシの状態を構築して、タイプ 6 IGMP プロキシルートからマルチキャストトラフィックの受信に関心があることをリモートエクステントに通知します。コミュニティ.

また、リーフ-2 は、リーフ-4 ( EVPN Intra-VLAN Multicast with Optimizationチャプター) およびリーフ-1 (現在) のタイプ6に基づいてリモートプロキシの状態を学習することにも注意してください。

同様に、ローカル IGMP 結合により、リーフ-1 はグループ225.1.1.1 の Type 6 ルートも生成します。リーフ-1 は、リーフ-4 ( EVPN Intra-VLAN Multicast with Optimization chapter) およびリーフ-2 (現在) のタイプ6に基づいてリモートプロキシの状態を学習します。

すべてのリモート Pe が EVPN タイプ6ルートを処理し、リーフ-1 およびリーフとして、グループの対象のリモート EVPN レシーバーとして学習することを確認します。このことは、リーフ-4 のタイプ-6 の最適化章で、このことをEVPN Intra-VLAN Multicast with Optimizationで行っていました。そのため、これは読者のための課題として残されています。

Verification of Multicast Forwarding State

225.1.1.1 のグループに対して作成されたマルチキャスト転送状態と2つ目は、関心のあるマルチホームインターフェイス ae 1.0 が含まれていることを確認します。

リーフ-1 で、リーフ-4 (vtep) に加えて、リーフ-2 (vtep) が group 225.1.1.1 の EVPN core next ホップにも追加されていることを確認します。さらに、BL-1 (vtep)、BL-2 (vtep. 32774)、およびリーフ-5 (vtep. 32773) は、このグループの EVPN core next ホップにも存在することに注意してください。

グループ225.1.1.1 に対して作成されたマルチキャスト転送状態が更新されていることを確認します。これで、上記の EVPN core の次ホップが含まれるようになりました。