最適化を行わない EVPN in VLAN マルチキャスト

EVPN ファブリックの物理トポロジ

Figure 1は、典型的な IP CLOS 物理トポロジを示しています。通常、2つのボーダーリーフデバイス (BL) と複数のリーフデバイス (数百台) があります。また、EVPN ファブリック内のデバイス間の物理的な接続のために、EVPN アンダーレイに参加する2つ (または4つ) のリーンスパイン (LS) デバイスもあります。

通常、ファブリック内では、マルチキャストソースとホストはリーフデバイスの背後に存在します。

Figure 1: 典型的な IP CLOS 物理トポロジ

論理トポロジー

この章の最適化されていないマルチキャストの手順Figure 2を説明するために、evpn ネットワークが BL およびリーフデバイスのみで構成している論理トポロジを示しています。通常、リーンスパインレイヤーはアンダーレイだけで役立ち、EVPN では構成されていません。

まず、シングルホームのホストについて説明します。リーフ-6 から200リーフへのリーフデバイスは、アクセスリンクを持ち、その背後にホストがあります。原則と手順について説明するには、リーフ-1 からリーフ5までを使用します。残りのリーフデバイスにも同じ手順が適用されます。

Figure 2: 論理 Singlehomed トポロジー

最適化を行わないサブネット内マルチキャスト

このセクションでは、’1 つの VLAN (L2 スイッチングマルチキャスト) で DC ファブリック内のサブネット内マルチキャスト転送の手順を確認してみましょう。このトポロジでは、VLAN、VLAN-101 は1つだけです。一般的に、マルチキャスト転送に関して4つの動作セットについて検討する必要があります。EVPN デバイスの設定は、後ほどこの章に記載されています。

• ソースとリスナーは存在しません

• ソースは存在せず、リスナーが存在している

• ソースは存在しますが、リスナーは存在しません。

• ソースとリスナーが存在する

No Sources and Listeners Exist

これは、マルチキャストリスナーやソースがまだ開始されていないファブリックであるということで、非常に簡単です。

Sources Do Not Exist but Listeners Exist

この場合、リスナー (ホスト3とホスト5でFigure 3表されるホスト) は、特定のグループ (235.1.1.1 など) のトラフィックに興味を持っています。そのグループに対してマルチキャストトラフィックが開始されていない’ため、リスナーはトラフィックを受信しません。

Sources Exist but No Listeners Exist

マルチキャストソース (235.1.1.1 で表されるFigure 3) がグループ G1 のトラフィックを送信し始めていて、そのグループ用のリスナーがまだ存在しない場合を考えてみましょう。サブネット内のマルチキャスト転送では、マルチキャストトラフィックを受信するリーフ-1 は、その VLAN 上のレイヤー2アクセスインターフェイスすべてにトラフィックを転送 (L2 スイッチ) します。(Host 2 に向かって)。(SH) また、リーフ-1 はスプリットホライズンに基づいて、そのトラフィックを Host-1 に転送することはできません。(アクセス分割-HRZN)

Figure 3: レイヤー2マルチキャストトラフィックフラッディング

でFigure 3は、リーフ-1 は入口レプリケーションを使用して、トラフィックを evpn core へと、すべての Evpn PEs に転送します。トラフィックが送信される PEs は、VLAN (vlan-101’ ) に参加しているリモートの pes によって決まります。(コア-IMET-早送り)

VLAN 内でのリーフの参加は、3s から受信された EVPN タイプによって決まります。リーフ-5 ホスト、VLAN-101 を除くすべての LEAFs を見ることができます。したがって、リーフ-5 は VLAN-101 のタイプ3を送信しません。マルチキャストトラフィックは、BLs とリーフ5以外のすべての LEAFs に対して複製されます。(コア-IMET-スキップ)

EVPN core からトラフィックを受信したすべてのリーフおよび BL デバイスは、このトラフィックをすべてのアクセスインターフェイスに転送します。また、にFigure 3示すようにリスナーが存在しているかどうかにかかわらず、リーフ-2 は、ホスト3とホスト4に転送されます。リーフ-3 は、ホスト5へと進みます。VLAN にリスナーが存在しない場合でも、マルチキャストトラフィックが‘どこ’に殺到しているかを確認することができます。

大量のトラフィックがどこでも大量に送信されると、コアの帯域幅の使用率に影響を与える場合があります。また、ファブリック内のさまざまな EVPN デバイスのアクセスインターフェイスに悪影響を及ぼすことがあるため、これは望ましくはありません。「氾濫」は、最適化されていない EVPN マルチキャストの特性の1つです。後の章では、最適化手順がこのフラッディング問題を解決する方法について説明します。

Sources Exist and Listeners Exist

ソースがグループ G1 のトラフィックを送信していて、235.1.1.1 と言っていて、ファブリックには、にFigure 4示すようなリスナーがある場合を考えてみましょう。そのため、Host-3 と Host-5 は、group G1 のトラフィックに関心を示しています。リスナーの目的は、IGMP レポートを送信することによって、ホストによって伝達されます。リスナーの関心は、 Figure 4ホスト上に緑色の丸で示されています。

これらの IGMP ホストは、IGMP レポート (*、G1) を送信して、任意のソースからの G1 グループのトラフィックに関心を持つようにしています。前のセクションで説明したように、マルチキャストトラフィックをどこでもあふれさせることで、ファブリック内の関心のあるリスナーに到達し、それを使用します。

Figure 4: リスナーによる L2 マルチキャストトラフィックフラッディング

EVPN マルチキャストトポロジにおけるサブネット内マルチホーミング

EVPN 導入のメリットの1つとして、イーサネットセグメント識別子 (ESI) を備えたマルチホーミング機能があります。ESI は、特定の ESI をホストするデバイスがその ESI 上のマルチホームであることを考慮して、さまざまな EVPN デバイス上のリンクセットをグループ化するのに役立ちます。これは、BGP EVPN タイプ1とタイプ4ルートを交換するデバイスと、ESI の multihomedness を deducing することによって実現されます。

通常、ESI としてグループ化された一連のリンクは、アグリゲート型イーサネット lag (AE) インターフェイス内の CE で終了します。全体的には、EVPN ESI パラダイムにより、マルチホーム PEs から CE に向かう冗長性とロードバランシング機能が確保されます。CE の AE インターフェイスバンドルにより、マルチホームの拡張に向けて冗長性と負荷分散機能が保証されます。

全体的には、マルチホームリスナーの場合、その目的は、リスナーが同じトラフィックのコピーを何も受信していないことを確認することです。マルチホームのソースの場合、目的は、トラフィックがソースにループバックされないようにすることです。でFigure 5Evpn マルチホーミングの論理トポロジを検討してください。

Figure 5: 論理的なマルチホームトポロジ

ESI を使用した EVPN マルチホーミングは、L2 の機能です。そのため、ESI (EVPN インスタンスあたりの VLAN 当たり) のマルチホームとして2つの PEs が検討されています。このセクションでは、リーフデバイスのマルチホームの仕組みについて説明します。PIM L3 (外部マルチキャストと呼ばれます) を実行している BL デバイスは、後の章で詳しく説明されています。

ここでは、BUM 転送ルールを示すために、このことを説明するものとします。

• リスナーはマルチホームのリーフの背後にあり、ソースはシングルホームです。

• ソースはマルチホームのリーフよりも遅れています。

• ソースは、別の ESI でマルチホームリスナーを持つリーフの背後にあります。

マルチホームのリーフデバイスとソースの背後にあるリスナーは Singlehomed

2つのリーフFigure 6デバイス (リーフとリーフ) が Host-5 へのマルチホームになっているトポロジについて考えてみましょう。マルチホームホスト-5 からリーフ-3、およびリーフ4では、1つの LEAFs に障害が発生した場合、トラフィックはできるだけ早くもう一方のリーフから再開されます (弾力性)。また、複数のユニキャストフローがリーフ-1 からホスト5へ向かう場合、一部のフローはリーフ-3 を介して送信されます。その他はリーフ-4 (ロードバランシング) になります。

Figure 6: マルチホーム Pe の背後のリスナー

マルチキャストトラフィックの場合、EVPN core からのトラフィックが lest とリーフ4の両方によって送信されないことに注意する必要があります。これにより、Host-5 の重複が発生します。(重複すると、トラフィック損失よりもマルチキャストアプリケーションの問題が悪化します)。

リーフリーフは、リーフ-1 とリーフ-4 の両方でマルチキャストトラフィックを溢れさせることができます。トラフィックを受信するのは LEAFs です。ただし、トラフィックを ESI インターフェイスに転送するのは、マルチホームの関係を実現したリーフ1つだけです。

これを実現するために、マルチホームの LEAFs は、その ESI 上でマルチホーム化されている ESI の中での DF を決定します。この決定は、タイプ4ルートに基づいて DF 選挙アルゴリズム (MOD ベース、ローカル優先など) を実行することによって行われます。この決定が完了すると、ESI 用のマルチホーム Pe として選択され、その ESI 用のマルチホーム pes が、(非 DF) としてマークされます。

マルチキャストトラフィックが EVPN core から到着した場合、転送ルールは以下のようになります。

• 単一のホームアクセスインターフェイスでは、トラフィックを氾濫させることができます。

• マルチホームアクセスインターフェイスでは、DF として選択すると、トラフィックが氾濫します。

• マルチホームアクセスインターフェイスでは、NDF’としてマークされている場合、トラフィックを溢れさせることはありません。

リーフFigure 6-3 およびリーフ-4 では、ホスト-5 に対して ESI までマルチホームになっています。そのため、DF の選挙を実行します。「リーフ-3」と言うと、DF とリーフが ESI では NDF として選ばれます。リーフがコア (リーフから複製された入口) からトラフィックを受信すると、ESI (古典-df-NDF)の DF であるため、ホスト-5 にフラッドします。

リーフ-4 では、EVPN core からトラフィックを受信しても、ESI を NDF (古典-DF-ndf)としてマークしているため、ホストへのトラフィックが過負荷になることはありません。したがって、Host-5 は重複を受信しません。しかし、リーフはシングルホームアクセスインターフェイスであるため、Host 6 へのトラフィックをフラッディングしています。

マルチホーム・リーフ・デバイスの背後にあります。

Consider Figure 7は、リーフ-1 が NDF であり、リーフは DF である ESI を介して、2つのリーフデバイスに対してマルチキャストされています。送信元が通信を開始すると、AE インターフェイスハッシュによって、LAG バンドルのいずれかのメンバーでトラフィックを送信できます。したがって、Host-1 はリーフ-1 またはリーフ-2 にトラフィックを送信できます。

マルチ’キャストトラフィックがリーフに送信されたとしましょう。このシナリオに対する特別な処理が行われていない場合は、前述の(古典-DF-NDF)手順に基づいて以下の問題が発生します。リーフ-1 はコアへのトラフィックを送信します。2つのリーフは、コアからこのトラフィックを受信すると、選択された DF であるインターフェイスを大量に過負荷にしてしまいます。

この場合、リーフ-2 は Host-1 に対して選択された DF であるため、ソースへの転送が終了します。これは適切な動作ではありません。そのため、リーフ-2 が、マルチホーム化されている ESI のトラフィックをリーフ-1 に送信しないように、特別な処理が必要です。

MPLS は、このようなシナリオを処理するために水平分割ラベルを持っています。この問題は VXLAN でどのように解決できますか?

リーフ-2 がパケットがリーフから送信されたことを推定できたら、リーフ-2 が転送をプログラムして、パケットがリーフから着信した場合、リーフ-1 でマルチホーム化されているインターフェイス上の転送をスキップすることが可能になります。詳細’についてご確認ください。

Figure 7: マルチホーム Pe の背後のソース

リーフは、リーフの送信元 VTEP IP (S VTEP など) を使用してマルチキャストパケットを送信します。リーフ-2 は、リーフ-1 VTEP が、BGP タイプ3ルートから送信元 VTEP であることを認識しています。

リーフ-2 はアクセスインターフェイス/ESIs を示し、リーフ-1 でマルチホーム化されたリーフインターフェイスリストを作成します。その後、リーフ-2 は、パケットが SVTEP-1 を使用して到着したときに、このマルチホームインターフェイスリストへの転送をリーフ-1 でスキップするように、転送するルールを作成します。このような転送ルールは、リーフがマルチホームである各リーフに対して構築されます。’ここでは、これを(DST ローカルバイアス)と呼んでいます。

転送がプログラムされると、リーフ-2 が S-VTEP-1 からのトラフィックを受信したときに、トラフィックはマルチホームインターフェイスには送信されず、ホスト-3 およびホスト4にあふれます (これらのインターフェイスはリーフによるマルチホームではないためです)。

ソースが、マルチホームリスナーを持つリーフの背後にある

マルチホーム転送ルールに目を通し、全体的なマルチキャスト L2 転送ルールを書き直しする前に、EVPN リーフデバイスがローカルソースを持ち、異なるインターフェイス/ESIs にあるマルチホームインターフェイスを持つ、もう1つのトポロジを検討する必要があります。

ここにFigure 8示されているトポロジは、1つのシングルホームインターフェイス上にマルチキャストソースを持ち、リーフで共有されるマルチホームインターフェイス上のリスナーホスト3を示していることを考慮してください。選択に基づいて、’リーフ-1 が NDF であり、リーフが ESI の DF であることを伝えます。

Figure 8: マルチホームリスナーの背後のソース

前に説明した2つのルールごとに、コアからトラフィックを受信しても、トラフィックを非マルチホームのインターフェイスリストにリーフ-1 で転送することはありません。そのため、2つのトラフィックをホスト3に転送することはできません。

リーフ-1 は、ホスト3に対してオーバライドされています。これは、私たちの状況とは言えません。リーフ-2 は、 (DST ローカルバイアス) のために、トラフィックを Host 3 に転送しません。これは、マルチホームインターフェイスで受信したトラフィックがソースにループバックしてしまうことを防ぐためです。しかし、リーフ-3 は、 (古典-DF-NDF)ルールに基づいて host 3 に転送できません。ホスト3はトラフィックをどのように取得しますか?

このシナリオに対処するため’に、(古典-DF-NDF) ルールからわずかに逸脱してみましょう。リーフがローカルアクセスインターフェイスからトラフィックを受信すると、ターゲットインターフェイス上に DF があるかどうかに関係なく、他のすべてのローカルアクセスインターフェイスにトラフィックをあふれさせます。これは「(SRC ローカルバイアス)」と呼ばれることもあります。

でFigure 8は、アクセスインターフェイスから送信元からトラフィックを受信するリーフ-1 は、DF/NDF に関係なく、すべてのアクセスインターフェイスを過負荷にしてしまいます。そのため、リーフ-1 は、アクセスインターフェイスから受信したトラフィック以降、インターフェイスに対しては、トラフィックをホスト3に転送します。そのため、ホスト3はリーフからのトラフィックを受信します。

リーフ-2 リーフ-1 からのトラフィックを受信すると、s VTEP が s VTEP IP リーフ-1 に決定され、MH インターフェイスリストへ‘の転送がリーフ-1’ (DST ローカルバイアス)にスキップされます。したがって、リーフ-2 はホスト3に転送されません。リーフ-2 は、葉-1 のマルチホームインターフェイスではないため、ホスト4に転送されます。

すべてを組み合わせて、VLAN 間のマルチキャストを実現

この章でこれまでに説明した転送ルールに基づい’て、 visàは、転送ルールを vis してサンプルトポロジ内の動作を関連付けてみましょう。統計については、「トラフィックの検証」セクションを参照してください。

リーフFigure 9 -1 では、host-1 と MH に対応する、マルチインターフェイスの NDF として機能します。リーフ-3 は、MH インターフェイス上の DF であり、ホスト5に向かいます。Host-1 はマルチキャストトラフィックの送信元です。Host-1 は、AE バンドルのハッシュに基づいて、リーフ-1 または2のいずれかにトラフィックを送信できます。たとえば、リーフ-1 に送信しているとしましょう。

ここで、リーフ-1 は以下のアクションを実行します。

• Host 1 にトラフィックを送信しません (アクセス分割-HRZN)

• 受信は、すべてのリモート Pe へのトラフィックを VTEP 経由でレプリケートします (コア-IMET は一致しません)。

• VLAN-101 のタイプ3として、リーフに送信されません。(コア-IMET-スキップ)

• ホスト2へのトラフィックを、シングルホームインターフェイス (SH) で送信します。

• ホスト3に送信されます。ただし、これは NDF であり、アクセストラフィック (SRC ローカルバイアス) です

Figure 9: 転送ルール

2つは、コアからのトラフィックを受信するために、以下のアクションを実行します。

• コアにトラフィックを送りません (コア分割-HRZN)

• ホスト4へのトラフィックを、シングルホームインターフェイスであるために送信します。(SH)

• Host 1 (DST ローカルバイアス) にトラフィックを送信しません。

• ホスト 3 (DST ローカルバイアス) にトラフィックを送信しません。

リーフからのトラフィック受信時には、以下のアクションが実行されます。

• そのインターフェースに DF があるため、ホスト-5 に送信します (古典-DF-NDF)。

リーフ-4 は、コアからの受信トラフィックで、以下のアクションを実行します。

• は、NDF (古典・ DF-NDF) であるため、ホスト-5 への送信は行いません。

• このトラフィックは、シングルホームインターフェイス (SH) であるため、Host 6 に転送します。

• リーフ-5 は、VLAN-1 をホストしていないため、コアからのトラフィックを受信しません。

EVPN でのマルチキャストトラフィックの全体的な転送ルール

この章で前述したルールを強化して、マルチホームを考慮してみましょう。

(古典-DF-NDF)

• I マルチホームになっていない PE から、EVPN core からトラフィックを受信した場合

• 単一のホームアクセスインターフェイスでは、トラフィックを氾濫させることができます。

• マルチホームアクセスインターフェイスでは、DF として選択された場合、トラフィックを氾濫させる

• マルチホームアクセスインターフェイスでは、NDF’としてマークされている場合、トラフィックを氾濫させることはありません。

(DST-ローカルバイアス)

• Pe が EVPN core から渡されると、PE X としてマルチホームを

• 単一のホームアクセスインターフェイスでは、トラフィックを氾濫させることができます。

• PE-X’でマルチホーム化されたマルチホームアクセスインターフェイスでは、DF/NDF に関係なく、トラフィックを溢れさせることはありません。

• PE でマルチホーム化されていないマルチホームアクセスインターフェイス上では、私がそのインターフェイスを DF している場合、フラッドします。

• PE X でマルチホーム化されていないマルチホームアクセスインターフェイスでは、そのインターフェイスを使用しているかどうかを過負荷にしてはなりません。

(SRC ローカルバイアス)

• アクセスインターフェイスからトラフィックが着信した場合:

• DF/NDF に関係なく、他のすべてのアクセスインターフェイスを氾濫させる。

• VLAN をホストするすべての PEs に受信すると、コアへ複製されます。

転送の m トラフィックに対する上記の手順 (2) および (3) は、通常、ローカルバイアスと呼ばれています。名前が示すとおり、ローカルアクセスインターフェイスでトラフィックが受信されると、リーフデバイスは、DF/NDF に関係なく他のアクセスインターフェイスに転送するための偏りを与えられます。リモートマルチホームデバイスは、DF/NDF に関係なく、マルチホームアクセスインターフェイスに転送されません。そのため、ローカル PE には、リモート PE を転送するための優先順位が与えられています (そのため、ローカルバイアスという用語が指定されています)。

ローカルバイアスのこれらのルールは、EVPNoVXLAN のみに適用されることに注意してください。EVP-NoMPLS を使用すると、ESI ごとに水平分割ラベルを使用して、マルチホームのシナリオに対応できます。

章のまとめ

この章では、シングルホームおよびマルチホームトポロジにおけるさまざまな BUM 転送ルールを解説しました。ここでは、EVPN ファブリック内のどこでも、コアおよびすべてのアクセスインターフェイスにマルチキャストトラフィックがあふれていることを示しました。マルチホーム転送ルールによって、リスナーが重複を受信したり、ループバックしたりしないようにすることができます。これらのルールは、ESI/NDF ステータスとして、そのトラフィックがマルチホームである PE から受信されたものかどうか、トラフィックがアクセスインターフェイスに到着しているかどうかを考慮しています。

Assisted Replicationされた複製の章受信レプリケーションに関する課題と、それをどのようにして軽減できるかについて説明します。構成と検証については後で解説します。

構成

Figure 10は参照トポロジです。

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

’ここでは、この章で説明されているマルチホーム機能の構成と検証に重点を置きます。 EVPNoVXLAN および使用するコマンドについても取り上げています。このセクションでは、EVPN in VLAN マルチキャストトラフィック転送動作、特に最適化が不要な場合にどこでもあふれていることを確認します。

EVPN Base Configuration in DC Fabric Topologyに記載されている基本的なアンダーレイとオーバーレイの設定は、このセクションには十分です。Vlan-101 (vlan id 101、VNI 101) に焦点を当てています。リーフ-5 は VLAN-101/VNI-101 をホストしていないことに注意してください。

トラフィックの検証

101 225.1.1.1 のグループに対して、10 pps (1 秒あたりのパケット数) でマルチキャストトラフィックの送信を開始します。ここまでのように、受信者がこのトラフィックの受信に関して実際に関心を表しているものはないことに注意してください。

のFigure 11RT 統計情報からわかるように、host-1 は 10 pps でトラフィックを送信します。これは、VLAN-101 (host-2 から host-6) の一部である DC 内のすべてのホストで受信されますが、そのトラフィックに関心があるわけではありません。VLAN-101 の一部ではない、ホスト-7 だけでは、トラフィックに対応していません。Host-8 はファブリックの外部にあり、今は無視してかまいません。

Figure 11: RT 統計

Multicast Traffic Outputs - LEAF-1

ホスト-1 はリーフ-1 およびリーフ-2 へのマルチホームになっています。したがって、ホスト-1 からリーフ-2 へのトラフィックは負荷分散され、リーフ-2 またはリーフに到達できる場合があります。この場合、マルチキャストトラフィックはアクセスインターフェイスである ae0 で受信されます。

受信インターフェースでトラフィックがあふれていなくても、ae 0.0: (アクセス分割-HRZN)

リーフ-1 では、他のシングルホームアクセスインターフェイスである xe-0/0/4 へのトラフィックが Host 2 に転送されます。(SH)

トラフィックは、すべてのマルチホームアクセスインターフェイス (リーフ-1 の ae) で転送されます。 DF/NDF ステータス (SRC ローカルバイアス) に関係なく、以下のようになります。

また、マルチキャストトラフィックは、BL-1 (101.101.101.101) および BL-2 (102.102.102.102) 方向に VTEPs に転送されます。

さらに、VTEPs 上でリーフ-2 (106.106.106.106)、リーフ-3 (107.107.107.107)、およびリーフ-4 (108.108.108.108) に転送されます。(コア-IMET-早送り)

次のようなトラフィックは、リーフ-5 (109.109.109.109) VTEP に向かって転送されません (コア-IMET-SKIP)。

Multicast Traffic Outputs - LEAF-2

Ae0 のマルチキャストトラフィックは、マルチホームアクセスインターフェイスで転送されるのではありませんが、この2つのインターフェイスでは、ソース PE (リーフ-1) がこれらのインターフェイスの ESI (夏時間) 上のマルチホームピアになっています。これにより、マルチホーム化されたソース、Host-1 にトラフィックがループすることはなく、マルチホームホストに対するトラフィック重複も発生しません。

トラフィックは、xe-0/0/4.0 (SH) で、シングルホームホスト、ホスト4に転送されます。

このトラフィックは、VTEPs 上では送信されません。VTEPs は、次ホップのオーバーフローの一部ですが、コアから着信する BUM トラフィックのスプリット・ホライズンルールによって、トラフィックがコアに送信されないようにしています。(コア分割-HRZN)

Multicast Traffic Outputs - LEAF-3

これは、NDF (古典・ DF-NDF) であるため、このリーフに到着したトラフィックは、マルチホームアクセスインターフェイス、ae 0.0 では転送されません。これにより、マルチホームホスト、ホスト5は、重複したトラフィックを受信しなくなります。

また、トラフィックは VTEPs (コアスプリット HRZN) にも送信されていません。

Multicast Traffic Outputs - LEAF-4

3.4.1 に着信するマルチキャストトラフィックは、マルチホームアクセスインターフェイスの ae 0.0 で転送されます。これは DF であり、リーフはマルチホームピアではないためです。以下のセクションを参照してください。(古典-DF-NDF).

トラフィックは、xe-0/0/3.0 (SH) で、単一のホームホスト、Host-6 にも転送されます。

このトラフィックは、VTEPs (コアスプリット HRZN) 上には送信されません。

Multicast Traffic Outputs - LEAF-5

リーフ-5 は、VLAN-101 をホストしないため、リーフからのトラフィックはまったく受信されません。

Multicast Traffic Outputs –BL-1 and BL-2

2つのボーダーリーフデバイスの動作は、VLAN 間のトラフィック転送に関する章に到達した場合にのみ、非常に重要になります。そのため、これらのデバイス上のトラフィック転送動作は無視されます。

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

Verifying the Flood Routes

各 VLAN について、vlan のすべてのアクセスインターフェイスと、その vlan に対してタイプ3ルートを受信した EVPN ピアに対応する VTEPs を使用して、1つの PE ではフラッドの次ホップが構築されます。この次ホップは、VLAN 内のマルチキャストトラフィックを氾濫させるために使用します。

たとえば、リーフ-1 では、次のような VTEPs が構成されています。

• BL-1 (vtep 32770)

• BL-2 (vtep 32774)

• リーフ-2 (vtep 32769)

• リーフ-3 (vtep 32772)

• リーフ-4 (vtep 32771)

その他の PEs での次ホップ情報のフラッドは、上記のようなものになります。

Verification of Multihoming State

ES をホストする各 PE では、ES の DF 選挙が行われます。

このため、アクティブ/アクティブイーサネットセグメントがリーフ-1 およびリーフ-2 にマルチホーム化されている場合、00:11:11:11:11:11:11:11:11:11 および00:22:22:22:22:22:22:22:22:22 では、2 (106.106.106.106) という DF が選ばれることになります。

00:33:33:33:33:33:33:33:33:33、リーフ-4 (108.108.108.108) が DF として選択されているのは、アクティブ/アクティブイーサネットセグメントからリーフ-3 およびリーフ4までのマルチホーム用です。

ほとんどの場合、リーフ-1 にある1つの ESI の状態が単独で検証されます。他の ESIs とその他の PEs の状態はほぼ同じで、読者のための課題として残されています。

DF Verification

リーフ’として DF/NDF の状態を確認してみましょう。

Verification For ESI Status in Detail

以下のコマンドを使用して、ES の DF 選挙に関する詳細を確認することができます。

Verifying ESI State: Forwarding/Blocked

では’、ESI 状態を検証してみましょう。

リーフ-1: マルチホームアクセスインターフェイスと ae01 の DF ではないため、BUM トラフィック用に“ブロック”モードにしてマークし、2 (DF) を使用して、これらのインターフェイス“を”転送モードにマークします。

このインターフェイスのマルチホームになっている PE は、出力に表示することもできます。この情報は、コアから送られるトラフィックに対して DST ローカルバイアスを適用する際に、この PE で使用されます。