EVPN in VLAN マルチキャスト (最適化あり)

IGMP スヌーピングを使用した EVPN

L2 スイッチのマルチキャスト最適化については、EVPN を技術として使用することで、リモートデバイス経由での L2 ドメインのストレッチが可能になるということです。EVPN リーフデバイスは、アクセスインターフェイスで L2 スイッチの役割を果たします。EVPN リーフデバイスで IGMP スヌーピングが有効になってFigure 1います (を参照)。マルチキャストトラフィックは、その背後にリスナーを持つインターフェイスだけに送信されます。

Figure 1: IGMP スヌーピングを使用した EVPN

PE2’が EVPN とFigure 1IGMP スヌーピングによって設定されているとしましょう。/参照元から送信されたマルチキャストトラフィックが PE2 over EVPN に到達した場合、 ‘PE2’は IGMP レポート (listener の利息) を受信しているため、 ‘インターフェイス’a からのみマルチキャストトラフィックを転送します。

トラフィックが他のアクセスインターフェイス b、c、d にあふれていない。

PE2 は、ブリッジドメインで IGMP スヌーピングが有効になっている EVPN デバイスです。PE2 snoops メンバーシップ情報をアクセスインターフェイスに表示し、関連付けを追跡します。コアまたはアクセスインターフェイスからマルチキャストトラフィックが受信された場合、IGMP 状態が学習されたインターフェイスでのみトラフィックがあふれてしまいます。

IGMP スヌーピングの入門

このセクションでは、’10 年以上にわたり、スイッチングの世界に広く導入されている L2 マルチキャストの最適化手法について説明します。アクセスインターフェイスでのこのマルチキャスト最適化は、IGMP スヌーピングによって実現されます。このことは、L2 スイッチングの世界で広く使用されています。これは、トラフィックの背後にあるインターフェイスにのみ通信を転送する必要がある場合に行います。

典型的な L2 スイッチング環境では、マルチキャストトラフィックは常にすべてのインターフェイス上で転送されます。S Figure 2’トポロジでは、スイッチは5つのアクセスインターフェイスを備えています。a、b、c、d、x のようになります。スイッチ上で設定された L2 スイッチングマルチキャスト最適化がないということです。

Figure 2: IGMP スヌーピングの必要性

’対になると仮定すると、group G のトラフィックに関心があり、(*, G) の IGMP レポートが送信されます。IGMP は、ホストと隣接するルーター/スイッチによって、マルチキャストグループメンバーシップを確立するために使用されるプロトコルです。Group G の IGMP レポートを使用すると、ホストは LAN 上の最も近いスイッチ/ルーターに対する group G のリスナーの関心を表します。

マルチキャスト最適化を行わないスイッチでは、ソースが x 上で group G のトラフィックの送信を開始したときに、ホスト– 2、3、および4がその–グループにとって関心がないにもかかわらず、4つのすべてのインターフェイスにトラフィックを氾濫させます。

別のケースでは、グループのリスナーがなく、送信元がトラフィックを送信しても、スイッチは次の4つのすべてのインターフェイスにトラフィックを氾濫させます。a、b、c、d です。これは明らかに望ましくありません。

ここで’、スイッチが IGMP スヌーピングによって設定されているとしましょう。IGMP スヌーピングを使用すると、インターフェイス a で IGMP レポート/結合を受信した (snooped) ときに、(*, G) レポートを snoop に記録し、インターフェイス a を使用して G 用に関連する IGMP 状態を作成します。

Figure 3: IGMP スヌーピングを使用した、最適化された L2/マルチキャスト転送

When マルチキャストトラフィックがインターフェイス‘x’で受信されます。 group G で‘は、インターフェイス’‘a’用に保持した (*, G) 状態に基づいて、インターフェイス a にトラフィックを転送します。(アクセス-SNOOP) したがって、インターフェイス b、c、d へのトラフィックの不必要なフラッディングは回避されます。

また、インターフェイス (a、b、c、d) から IGMP レポートがない場合や、インターフェイス‘x’でトラフィックが受信された場合、igmp スヌーピングが有効になっていると、スイッチはインターフェイスのいずれにもトラフィックを転送しません (a、b、c、d)。

通常、スイッチには複数のポートがあります。スイッチで IGMP スヌーピングが有効になっていると、インターフェイスの帯域幅の使用量が大幅に減少します。また、グループにとって関心のないホストには、不要なトラフィックが含まれています。言うまでもなく、スイッチの複製によって冗長コピーを作成すると、IGMP スヌーピングが減少します。

スイッチは、 ‘Igmp 汎用クエリ’を定期的に送信して、ホストからの igmp レポートによって、リスナーの関心を要請します。ホストが特定のフロー G に関心を持っていない場合、ホストは IGMP Leave メッセージを送信します。IGMP Leave メッセージを受信すると、このスイッチは特定‘のグループ g’のグループ固有のクエリを送信し、グループ g に関心のある他のホストがあるかどうかを確認します。

このため、このスイッチは最後のメンバーシップクエリ‘’と呼ばれるタイマーを開始します。タイマーが期限切れになると、スイッチはインターフェイスでのリスナーの関心がないことが確認されました。これに基づいて、インターフェイスのグループの IGMP 状態を削除します。

コアに向けたマルチキャスト転送の選択

ここまでは、アクセス側でのマルチキャストトラフィック最適化について説明してきました。受信レプリケーションを使用してコアにあふれているトラフィックも最適化されますが、それには、背後にリスナーを持つ PEs だけがトラフィックを受け取るということが不可欠です。これはEvpn 選択的マルチキャスト転送と呼ばれています。

すべてFigure 4のリーフデバイスで vlan vlan-101/vni-101 が有効になっている場所を検討してください。リーフ-3 にはグループ G のリスナーはありません。しかし、リーフのように、グループ G の背後にリスナーが存在しない場合、どうすればよいでしょうか。

受信型のレプリケーションフラッドのリストでFigure 4これらの leafs を除外する入口 PE は、group G のマルチキャスト転送を選択して実現します。これにより、コア帯域幅を節約し、トラフィック処理のオーバーヘッド’からリスナーを分離していないリーフを除外できます。

Figure 4: 選択的マルチキャスト転送

選択的転送を使用するFigure 4場合、リーフ-1 では、送信元からリーフ-2 およびリーフ-4 へのみトラフィックを L2 に切り替えることができます。さらに、リーフは、リスナーが存在するアクセスインターフェイスのマルチキャストトラフィックのみを氾濫させることになります (アクセスを IGMP スヌーピング (アクセス-SNOOP)が可能です)。したがって、リーフ-2 は、ホスト-4 ではなく、Host-3 にのみトラフィックを送信します。リーフ-4 では、ホスト6にのみトラフィックをフラッディングしています。他のアクセスインターフェイスがトラフィックを伝送することはありません。また、コア上でトラフィックを受信するその他のリーフデバイスはありません。

次の3種類のメリットがあります。

• ’リーフによる入口の複製の負荷が大幅に軽減されるのは、たとえば、200 leafs に送信するために、2つの leafs にトラフィックを複製するような場合です。

• コア帯域幅の使用率が大幅に低下しています。個々に複製されたパケットは、不要なリーフデバイスに移動しなければならないので、ドロップするだけで済みます。

• リーフとその他の LEAFs は、リスナーを持たないため、この不要なトラフィックの処理が行われず、その他のタスクに対応できるようになります。

リーフの背後にあるホストがグループ G とジョインされた場合、受信はグループ G のトラフィックをリーフに送信します。同様に、ホストがグループ G の IGMP Leave を送信すると、受信はグループ G のトラフィックをリーフに送信しなくなります。言い換えると、受信したグループ G のトラフィックは、そのリーフの背後にあるグループにとってリモートリスナーの関心がある限り、リーフにのみ転送されます。

選択的なマルチキャスト転送の基本手順

’ここでは、選択的なマルチキャスト転送を実現するメカニズムについて説明します。この章の最初の「IGMP スヌーピング入門」のセクションで説明されているように、EVPN のリーフデバイスは、レポートを snoop に記録し、IGMP 状態をインターフェイスに関連付けます。

BGP Type-6 SMET (Selective Multicast Ethernet Tag) Route

EVPN リーフデバイスは、VLAN 上のアクセスインタフェースから G1 というグループのレポートを受信したときに、BGP EVPN タイプ-6 NLRI (G1) を発信します。このタイプ6ルートは、にFigure 5示すように、ルート-識別子、イーサネットタグ、マルチキャストグループアドレス、および発信元 IP アドレスを含みます。

Figure 5: タイプ-6 ルートフィールド

また、このルートは EVPN インスタンスを識別する RT のターゲットコミュニティーも配信します。これにより、関連する EVPN インスタンスをホストする EVPN Pe のみがこのルートをインポートするようになります。

E タグフィールドは、グループアドレスに対するリスナーの関心がある VLAN を伝達します。VLAN V-101 のグループ G では、目的のリスナーを持つリーフデバイスがほとんどまたはいくつか存在している場合があります。これらの各リーフデバイスは、このタイプ-6 ルートを発信します。ルート識別と発信元 IP アドレスが異なるので、受信することで、特定の関心のあるリーフデバイスを明確に特定し、それに応じて選択的な Floodlist を構築することができます。

「アウトゴーイング interface list (石油)」という言葉は、特定のグループ宛てのマルチキャストトラフィックが出てくるリストインタフェースを指すために使用されていました。討論では、入口でのグループの石油は、そのグループの特定の関心のあるリーフデバイスを指す VTEP インターフェイスになります。

この BGP タイプ-6 ルートは、アクセス時に受信した IGMP レポートを EVPN に相当するものと見なすことができます。そのため、このタイプ6ルートは EVPN core での IGMP (*, G1) レポートに相当します。

Figure 6リーフ-2 では、IGMP (*、G1) レポートを vlan-101 のホスト3からアクセスから受信した場合、vlan vlan-101 およびグループ G1 に Evpn タイプ-6 ルートが提供されます。同様に、リーフ-4 は、VLAN-101 上のグループ G1 のタイプ-6 も発生します。

Figure 6: BGP EVPN タイプ-6 ルート

リーフ-1 は、リーフ-2 およびリーフ-4 から group G1 のタイプ-6 ルートをインポートします。さらに、リーフ-1 は、1つ目のオイルにリーフ2およびリーフ4のみを含む、G1 用に特別に使用されたマルチキャストスヌーピング転送エントリをインストールします。グループのトラフィックが送信元から G1 で到着すると、そのトラフィックは G1 のこの特定のマルチキャスト転送エントリをヒットし、選択的に複製されてリーフ2とリーフ4のみで行われるようになります。

An Example with Two Different Groups G1 and G2

Figure 72つの異なるグループ (G1、G2 など) に関心のあるホストを示しています。Host-3 と host-5 は、グループ G1 に関心を持ち、Host 2 とホスト6はグループ G2 に関心を持っています。グループ G1 のタイプ-6 ルートは、リーフ-2 およびリーフ-3 によって開始されており、グループ G2 の場合はリーフ-1 およびリーフ4によって発生します。

入口 PE リーフ-1’の視点から見ると、G2 の石油はリーフ4を含み、Host 2 へのアクセスインターフェイス‘x’にもなります。受信 PE は、葉-4 への VTEP インターフェイスと、Host 2 へのアクセスインターフェイス‘x’を備えた石油を構築します。グループ G2 のトラフィックは、リーフ-4 以外の200リーフデバイスに送信されず、 ‘x’の方向へ向かいます。これは重要な最適化で、àvis は、最適化の章セクションで、 EVPN Intra-VLAN Multicast Without Optimizationを vis しています。

Figure 7: 2つの異なるグループ G1 および G2

Fab ric のどこにもリスナーがないFigure 7グループ G3 (非表示) があるとします。受信したリーフ-1 は、G3 に対してタイプ6のルートを受け取らないため、G3 の場合、特定の転送エントリはインストールされません。送信元がリーフ-1 に向かうためにトラフィックを G3 に送信した場合、リーフ-1 は、トラフィックをコアに向かって G3 に転送することはできません。

多くの場合、複数のグループに対して送信されるボリュームマルチキャストトラフィックが大量に発生していますが、そのようなグループのアクティブリスナーは存在しません。マルチキャスト転送の選択方式では、大量のトラフィックがコアへと送信されることはありません。そのため、このようなグループでは、200のリーフデバイスのいずれにも大容量が送られないため、コア帯域幅を大幅に節約できます。

BGP Type-6 NRLI SMET Route and Selective Multicast Forwarding

EVPN タイプ3ルートは、このルートトラフィックに基づいて、たとえば、リスナーの関心に関係なくリーフデバイスに‘あふれ’た場合など、包括的な方法で転送されるため、包括的マルチキャストイーサネットタグ(imet) ルートとも呼ばれます。

EVPN タイプ6のルートは、選択的マルチキャストイーサネットタグ(smet) ルートと呼ばれます。

ここでは、条件を微妙に使用することで、次のような違いがあります。

• SMET したルート: これは、特定の VLAN の特定のグループ G に対するリスナーの関心がある場合に、EVPN リーフデバイスが発信する BGP タイプ 6 NLRI ルートを示します。

• 選択的マルチキャスト (SMET) 転送 (SMET 転送と呼ばれることもあります): これは入口 EVPN PE の機能であり、グループの特定のマルチキャストスヌーピング転送エントリー、リーフデバイスに特化した EVPN’タイプ6個のルートをベースにしています。 vteps は、リーフデバイスから聞くことができます。(コア-SMET-早送り)

• IGMP スヌーピングと選択的 (SMET) 転送は、マルチキャストトラフィックを最適化する手法です。コアで最適化されたマルチキャスト転送が適切に機能するようにするに‘は’ 、 ‘上記’の a と b の両方に適したデバイスをサポートすることが不可欠です。たとえば、リスナーに接続する EVPN デバイスは、少なくとも SMET ルート機能をサポートする必要があります。入口である EVPN デバイスは、SMET れたルート機能と選択的なマルチキャスト (SMET) 転送パラダイムの両方をサポートする必要があります。

タイプ6のルートはリーフからスパインに送信されるため、コアを介して定期的に IGMP レポートを更新することは避けられません。アクセスインターフェイスでは、リスナーがグループ G の IGMP Leave を送信すると、リーフはグループ固有のクエリを送信して、そのグループに他のリスナーが存在しないようにします。リーフは、リスナーの利息がなくなったことを確定すると、アドバタイズされたタイプ-6 ルートを withdraws します。その結果、リストから削除されたリモートリーフによって、オイルの入口更新が行われます。

アクセス側のグループの IGMP スヌーピング状態は、G のリスナーレポートを受信する各 L2 インターフェイスを追跡します。ここで言及しているのは、グループ G のタイプが-6 であり、リーフにおけるその VLAN 上でのリスナーの関心を示しているということです。

リスナーの関心がある場所にアクセス L2 インターフェースが少なくとも1つある限り、group G のタイプ-6 ルートが生成されます。また、グループ G の対象となるリスナーが存在する VLAN にアクセス L2 インタフェースがない場合は、その VLAN のグループ G のタイプ6を撤回します。

ここまでは、最適化された転送を示したシングルホームのシナリオについて説明してきました。マルチホーミングでは、マルチEVPN Intra-Multicast Optimization with Multihomingで検討している課題があります。

EVPN Multicast Flags Community: SMET Feature Capability Exchange

多くの場合、実用的なシナリオでは、選択的 (SMET) 転送をサポートするデバイスとそれをサポートしていないものを混在させています。また、一部のリーフデバイスで IGMP スヌーピングが有効になっていない場合もあります。したがって、参加する EVPN デバイスを相互運用できるように、機能を交換する必要があります。

このため、EVPN マルチキャストフラグ拡張コミュニティー (MF-COM) は、入口 PE が機能をサポートしておらず’’、相互運用にも対応できないデバイスを収容できるようにするために、ファブリック内の evpn デバイスの機能を交換するのに役立つように導入されました。EVPN MF-COM のヘッダーをご覧いただけFigure 8ます。

Figure 8: EVPN MF-COM ヘッダー

IGMP スヌーピングが有効になっている n EVPN デバイスとBGP smet 6 は、evpn Multicast Flags (evpn-MF) と呼ばれる BGP 拡張コミュニティーを evpn タイプ3ルートに追加します。

さらに、このデバイスはコミュニティーのオクテットの最下位ビット (LSB) を1に設定して、SMET れた機能のサポートを提案します。IGMP スヌーピングをサポートし、BGP SMET したデバイスは、EVPN-MF コミュニティを追加し、オクテットの LSB を1に設定する必要があります。

また、デバイスが IGMP スヌーピングに対応していない場合、BGP smet がサポートされていません。ルートタイプ-6 _ を満たすか、リスナーに関係なくトラフィックを氾濫させる場合は、evpn-mf コミュニティの追加をスキップするか、または evpn-mf コミュニティを追加します

このコミュニティが EVPN タイプ3ルートで交換されると、参加する PEs には、すべてのトラフィックに対してどのリーフデバイスに含めるべきかを示す情報と、どの LEAFs を選択して転送する必要があるかが示されます。

選択的なマルチキャスト転送のためのその他の手順

Forward L2-switched Traffic to L3-PIM Spines

リーフがグループ G1 のアクセスインターフェースからトラフィックを受信する場合、リーフはそのグループのタイプが6である EVPN PE デバイスのみにトラフィックを選択的に転送する必要があります。

グループ G1 のタイプ-6 を持つリーフデバイスにトラフィックを転送するだけでなく、受信はトラフィックを L3 デバイスに転送する必要があります。グループのリモートリスナーが存在しない場合でも、トラフィックは L3 デバイスにのみ送信する必要があります。

この根拠は次のとおりです。L3 (PIM) デバイスは、ソース VLAN から他のレシーバー Vlan へのサブネット間のルーティングを実行します (VLAN 間マルチキャストについては、チャプターEVPN Intra-Multicast Optimization with Multihomingで詳細に説明されています)。そのため、L3 デバイスは、送信元 VLAN で常にトラフィックを獲得し、受信する必要があります。また、PIM DR の L3 デバイスでは、マルチキャストソースを PIM に登録する必要があります。そのため、トラフィックは常に L3 デバイスに到達する必要がありFigure 9ます (を参照)。

Figure 9: L3-PIM デバイスを含める

How Is a L3-PIM Device Detected?

最後のセクションでは、受信は、グループ G1 のトラフィックを L3 (PIM) デバイスに転送します。この L3 (PIM) デバイスは、BGP タイプ3ルートで、EVPN-MF コミュニティーの LSB をリセットした、L3 PIM デバイスによって検知されます。

これは、L3 デバイスが IGMP スヌーピングで有効になっているため、タイプ6のルートを満たすことができ、選択された転送に対応できるようになっています。しかし、L3 (PIM) デバイスは、VLAN 間のルーティングを行い、RP でマルチキャストソースを登録するために、トラフィックを処理する必要があります。

このため、L3-PIM は EVPN-MF コミュニティの追加をスキップするか、EVPN-MF コミュニティを追加しますが、オクテットの LSB の桁は0にリセットされます。このようなタイプ3のリーフ受信 PE は、この L3 デバイスへのすべてのトラフィックを溢れさせます。

Accommodating Devices That Do Not Support Snooping/SMET Route

特定の導入環境では、IGMP スヌーピングによって有効になっていないリーフデバイスがいくつか存在することがあります。また、IGMP スヌーピングが有効になっている EVPN リーフデバイスがある場合もありますが、そのデバイスには発信元 BGP タイプ6ルートがサポートされていません。

このような従来のリーフデバイスは、リモートリスナーの興味深いマルチキャストを他の Pe に伝達することはありません。IGMP’スヌーピングをサポートしていないFigure 10レガシーデバイスがリーフ5にあるとしましょう。

Figure 10: レガシーデバイスを含む

しかし、このような従来のリーフデバイスは、グループのトラフィックに関してリスナーを使用している場合があります。タイプ6のルートは生成されないため、受信には、このようなレガシー Pe の背後にあるリスナーがあるかどうかを確認する方法はありません。受信したトラフィックがレガシー PEs に転送されない場合、レガシー PEs の背後にあるリスナーはトラフィックを取得しません。そのため、受信は従来の Pe にトラフィックを氾濫させる必要があるため、このようにして、最適化したマルチキャスト手順をサポートしていないデバイスとの互換性を確保する必要があります。

How is a Legacy Device Detected?

前のセクションでは、受信すると、group G1 のトラフィックが従来のリーフデバイスに転送されていることがわかりました。この従来のリーフは、BGP タイプ3ルートで EVPN-MF コミュニティーが存在しないことで検知されます。

受信デバイスは、タイプ3からリーフデバイスを学習するときに、このコミュニティをチェックします。入口では、EVPN が存在しないことが検出されると、それがレガシーデバイスであることを受信者が推測します。このことをベースにした受信は、常にこのレガシーデバイスへのトラフィックを氾濫させるようになっています。

Figure 10G1 では、リーフ-1 は石油、リーフ-2、リーフ-4、BLs、およびリーフ-5 で使用されます。その背後にリスナーを’持たないその他の leafs は、石油の一部ではありません。

Forwarding Prefix for L3-PIM and Legacy Devices to Flood Traffic

前に説明した特別なケースでは、トラフィックを氾濫させるために、すべてのグループに for_ トラフィックを引き出すために、224/4 のデフォルトのマルチキャストプレフィックスルートが、L3/PIM とレガシーデバイスを含むオイルとともに設置しています。これにより、特定のルートエントリ’がインストールされていないフローのトラフィックが発生します (たとえば、235.1.1.1) は、このプレフィックス224/4 をヒットし、L3 デバイスに到達します。グループ235.1.1.1 のリスナーが存在する場合、235.1.1.1 の石油には L3-PIM とレガシーデバイスが含まれます。

Flood 224/24 Groups (for example, OSPF/LDP Hellos) Everywhere

224.0.0.5、224.0.0.13 などの、よく知られている特別なマルチキャストグループを検討します。これらは、さまざまな目的でよく知られているマルチキャストグループです。たとえば、224.0.0.5 は、PIM 224.0.0.13 の OSPF/los のマルチキャストグループとして使用されています。このような既知のグループは、224.0.0.0/24 の範囲 (224.0.0.1 ~ 224.0.0.255) として指定されています。

リーフデバイスはそのようなグループに対してタイプ6から開始されないため、このようなグループに送信されるトラフィックはどこでもあふれています。たとえば、リーフ-1 とリーフ-2 の背後にある L3 OSPF デバイスがある場合があります。OSPF デバイスは、お互いを相互に認識している必要があります。これらの hello メッセージは、LEAFs によって相互に転送されなければなりません。そのため、受信 PE は、ファブリック内のすべての PEs で次ホップにある、224.0.0.0/24 個の固有の転送エントリーをインストールします。この問題は、構成を必要とせずに発生します。

Flood User-configured Groups Everywhere

場合によっては、リスナーの存在する任意の場所にマルチキャストグループをどこでもあふれさせたいと考えているかもしれません。これらのグループは、224/24 の範囲に含まれていない可能性があります。通信事業者がどこでもトラフィックをあふれさせるグループ230.1.1.1 があるとします。これを実現するには、受信の構成を行う必要があります。構成には、トラフィックがあふれている必要があるグループのリストが含まれています。アクセスまたはコア上でのリスナーに関係なく、トラフィックが230.1.1.1 に到達すると、トラフィックはどこにでもあふれてしまいます。

選択的マルチキャスト転送のルール

そのため、グループ G1 へのトラフィックの選択的マルチキャスト転送ルールは、次のように強化されています。

• L2 がグループのマルチキャストトラフィックを、そのグループに対して開始した EVPN PEs に向かって転送します。 BGP タイプ-6 SMET のルートは G1 です。

• L2 は、サブネット間のマルチキャストを目的として、グループ G1 のマルチキャストトラフィックを L3-スパインデバイスに転送し、PIM for RP を使用してマルチキャストソースを登録します。

• L2 は、グループ G1 のマルチキャストトラフィックを、IGMP スヌーピングが有効になっていない従来のリーフデバイス、または BGP タイプ6でサポートしていない場合はルート発信者に転送します。

• L2 が、224.0.0/24 の範囲内のグループのマルチキャストトラフィックをファブリック内のすべての EVPN PEs に転送します。

• L2 が、ユーザーが構成したグループのマルチキャストトラフィックを、ファブリック内のすべての EVPN PEs に転送します。

章のまとめ

この章では、IGMP を使用してマルチキャストを最適化し、選択的に転送する方法について説明しています。大量のトラフィックがある大規模なマルチキャスト導入では、これらの最適化によって、関連する EVPN デバイスのコアとアクセスの両方に帯域幅を節約するとともに、レプリケーションやパケット処理の負荷にも対応できる重要な役割を果たしています。

また、SMET した種類6のルートと、レガシーデバイスとの相互運用性を実現する方法についても、さまざまなシグナリング手順を紹介しています。ここでは、PEs のリストを作成する際に、EVPN デバイスが使用するさまざまな外れ値について説明しました。そのため、L3 デバイス、レガシーデバイスなどのように、また、リンクローカルマルチキャストアドレス224/4 に必要な特殊な転送ルールも採用されています。

IGMP スヌーピングが有効になっているときに、SMET た転送が有効になります。一部のグループは、どこにでもあふれている必要がある場合があります。これは、通信事業者が、トラフィックを氾濫させる必要があるグループアドレスをさらおう選択できる構成によって実現できます。

マルチEVPN Intra-Multicast Optimization with Multihoming多重方式による最適化では、マルチホームのシナリオで最適化されています。

構成

のリファレンストポロジーが示されFigure 11ています。

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

EVPN 向けの VLAN 内マルチキャストトラフィック最適化を確認し’たら、IGMP スヌーピングと選択的 (smet) の転送と観察を可能にして、トラフィック転送を最適化する方法について見てみましょう。

IGMP スヌーピングを構成する

EVPN PEs で IGMP スヌーピングをオンにします。BD/VLAN レベルで IGMP スヌーピングを有効にすると、タイプ-6 ルートの発信元を選択して選択的 (SMET) します。転送も有効です。

リーフ-5 で VLAN-101 を構成します。ただし、IGMP スヌーピングをサポートしていないレガシーデバイスをシミュレートすることを目的としているため、リーフ5の Vlan で IGMP スヌーピングを有効にすることはありません。

開始する前に、トラフィックと RT 上のレシーバーを停止し、以下のデバイスに以下の構成スニペットを読み込んでください。

リーフ-1、リーフ-2、リーフ-3、リーフ-4:

BL-1, BL-2:

VLAN-101 をリーフに構成する-5

この構成スニペットをリーフ5に読み込む:

トラフィックの検証

ホスト1から、VLAN-101 の group 225.1.1.1 のマルチキャストトラフィック送信を開始します。

ホスト-6 (シングルホーム-4) では、マルチキャストグループのレシーバーを開始します。225.1.1.1 は VLAN-101 に対応します。

Traffic Statistics on Router Tester

のFigure 12RT 統計情報を見ると、10 Pps で Host-1 によって送信されたトラフィックが、関心のある受信機、host-6、および VLAN-101 のレガシーデバイス (host-7) によってのみ受信していることがわかります。

Figure 12: RT 統計

Multicast Traffic Outputs - LEAF-1

以前は、負荷分散マルチキャストトラフィックがリーフ-1 のアクセスインターフェイス ae0 に到着していました。しかし、リーフから受信したマルチキャストトラフィックは、受信者がいないため、リーフ-1 上のアクセスインターフェイスで転送されなくなり、アクセス側の帯域幅の無駄を回避できます。

マルチキャストトラフィックは、VTEPs 上で、境界リーフ PEs (101.101.101.101 および 102.102.102.102) およびリーフ-5 (109.109.109.109) へと転送されます。

また、トラフィックは、関心のある受信者を持つリーフ-4 (108.108.108.108) に向かって VTEP に送信されます。

関心のある受信者がいないリーフ-2 (106.106.106.106) とリーフ-3 (107.107.107.107) は、トラフィックをスペアにします。

Multicast Traffic Outputs - LEAF-4

アクセス側 IGMP スヌーピング機能により、リーフに到着したマルチキャストトラフィックがシングルホームインターフェイス (xe-0/0/3.0) で転送されるようになりましたが、受信側を持たないマルチホームインターフェイス ae 0.0 では転送されません。

Multicast Traffic Outputs - LEAF-5

リーフは、レガシーデバイスとして構成され、VLAN-101 を使用しているため、トラフィックを受信し、アクセスインターフェース (xe-0/0/2.0) にフラッディングを実行しています。この場合、受信機はありません。

Multicast Traffic Outputs – BL-1 and BL-2

ここでも、EVPN Intra-VLAN Multicast Without Optimizationするまで、これらのデバイス上のトラフィック転送の動作は無視されます。

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

Verification of Base EVPN IGMP Snooping State

VLAN-101 で、すべての EVPN PEs (リーフ-5 を除く) で IGMP スヌーピングが有効になっていることを確認します。

リーフ-2、リーフ-3、リーフ-4、BL-1、および BL-2 でも同様の出力を見ることができます。

ここで’は、igmp スヌーピングを使用している標準リーフ Evpn PEs によってアドバタイズされているタイプ3ルートが、igmp プロキシをサポート“”するビットセットを使用して、マルチキャストフラグ拡張コミュニティーを伝達していることを確認してみましょう。

マルチキャストフラグが設定されていない場合、非 IGMP スヌーピング対応のリーフ-5 がタイプ3ルートを引き続き提供し“ていること”を確認します。拡張コミュニティーのマルチキャストフラッグでは、ビットリセットをサポートしています。

IGMP スヌーピングおよび L3 (非マルチキャスト) で有効になっているボーダーリーフ EVPN PEs (BL-1 および BL) を確認します。マルチキャストフラグを使用せずにタイプ3ルートをアドバタイズ“するか、” igmp プロキシをサポートするマルチキャストフラグの拡張コミュニティー:

スヌーピング対応型のリーフ Pe によってマルチキャスト転送テーブルがプログラミングされ、不明なマルチキャスト受信トラフィックがすべて、境界リーフ Pe と非 IGMP スヌーピング対応の PEs を経由するようになっていることを確認します。

Verification of EVPN IGMP Proxy State with Remote Receivers

リーフ-4 で、igmp レポートをスヌーピングすることで、VLAN-101 インターフェイス xe-0/3.0 で IGMP グループメンバーシップが学習されたことを確認します。

グループ225.1.1.1 のローカル IGMP メンバーシップを学習しているリーフ-4 を確認し、ローカル EVPN IGMP プロキシの状態を構築して、以下のタイプ 6 IGMP プロキシルートを作成します。グループのマルチキャストトラフィック受信に関心があることをリモートエクステントに通知します。

すべてのリモート Pe でこの EVPN タイプ-6 が処理されていることを確認します。リーフ4が関心のあるリモート EVPN 受信者であることを学習します。

リモートレシーバーによるマルチキャスト転送状態の検証

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

他のすべての PEs で、リーフ-4 (vtep 32771) が group 225.1.1.1 の EVPN core ネクストホップに追加されていることを確認します。さらに、BL-1 (vtep. 32770) では、BL-2 (vtep) とリーフ-5 (vtep 32773) がグループの EVPN core next ホップにも存在することに注意してください。

Group 225.1.1.1 に対して作成されたマルチキャスト転送状態に、上記の EVPN core next ホップが含まれていることを確認します。