支援の複製
最適化されてEVPN Intra-VLAN Multicast Without Optimizationでは、受信レプリケーション、DF/NDF 転送、ローカルバイアスルールなど、データ転送のマルチキャストに関するさまざまな手順について説明しました。
通常、データセンターには、ポート密度が低く、転送/処理機能が少なく、コストが低い、ラック収納 (TOR/葉) スイッチがいくつか搭載されています。たとえば、QFX5110 はこのようなデバイスです。リーフの役割に適しています。
また、データセンターの物理トポロジーは、以下Figure 1のコンポーネントに類似しているように見えます。
リーフレイヤー: VM ホスト、ベアメタルサーバー (BMS) などに接続する、いくつかの LEAFs (QFX 5110s) があります。
境界のリーフ: 境界の葉 (ボーダー) デバイス (QFX10K) と呼ばれるリーフデバイスがいくつかあり、ゲートウェイ (MX-GW) 経由で DC ファブリックを外部環境に接続するために使用されます。
リーンスパイン: 参加する EVPN デバイスの物理的な相互接続に使用されるリーンスパインデバイス (LS) (QFX10K) はいくつかあります。これらのリーンスパインデバイスは、物理相互接続としてのみ機能し、アクセスインターフェイスはホストせず、通常、EVPN オーバーレイには参加しません。これらは、BGP アンダーレイの一部になっています。
受信レプリケーションの特性と課題
マルチキャストソースが、さまざまなフローのトラフィックを送信する場合、たとえば、IPTV アプリケーションでは、通常、トラフィックレートは (1 フロー当たり4Mbps の順序で) 非常に高くなります (例えば、HD ストリームなど)。リーフで大量のトラフィックが受信された場合、リーフ-1 は、そのファブリック内の他のすべての PEs にトラフィックを複製しなければなりません。これを実現するために、アクセスインターフェイスで受信するパケットリーフごとに、リモート PE ごとに1つのコピーを複製し、にFigure 2示すように evpn core を介して送信します。
1000は、フローあたり 4 Mbps で、ファブリック内の 200 Pe については、リーフ-1 から送信されます (1000 * 200 * 4 Mbps = 800Gbps)。ここで2つの状況が発生します。
リーフ-1 は容量の少ないデバイスであるため、incom からのトラフィックフローの200コピー (PE ごとに1つ) を作成することが負担となります。これにより、受信が melt になる可能性があります。
オーバーレイトラフィックは 200 Pe に分散された 800 Gbps ですが (論理トポロジーでは、PE あたり 4 Gbps)、リーフ-1 は物理リンク上のすべての 800 Gbps トラフィックをリーフ-1 と LS-1 で送信します。その後、LS-1 は、これらのパケットをそれぞれ 4 Gbps のその他の各 Pe に転送します。LS-1 からリーフ’までのリンクは、4Gbps を伝送します。これは予期されているものであり、問題にはなりません。しかし、リーフ-1 と LS-1 間のリンクは、他のアプリケーションやトラフィックドロップのためのスペースがないまま、過剰に使用されています。
この状況は、1つのマルチキャストソースによって示されています。もし、他の LEAFs の背後にある複数のソースが、高レートでトラフィックを送信している場合、リーフから LS へのリンクがチョークになるため、多くの LEAFs が影響を受けることになります。
支援の複製
上記のシナリオを使用し’て、その問題を緩和するために実行できることがあるかどうかを見てみましょう (i) リーフ-1 を複数の pe にレプリケートすることはできず、トラフィックは高レートで受信され、(2) リーフと LS-1 の間のリンクの使用率は、アンダーレイ内のすべての PEs 宛てのパケットです。
’LS-1 (通常はハイエンドデバイス) を使用すると、他の PEs への複製‘を’支援できるのであれば、いいと思いますか? はい。LS-1 が、他の PEs への複製の負荷を使用してリーフ-1 をサポートしている場合、上記の問題の両方が解決されます。その方法については、
’たとえば、リーフ-1 はパケットの1つのコピーのみを LS-1 に送信し、ls-1 は、ファブリック内の他の evpn デバイスに複製を行います。リーフ-1 は LS-1 に1つのパケットのみを送信する必要があるため、リーフ-1 とリーフ-1 と LS-1 間のリンクを通過するパケット数は200によって小さくなります。
もちろん、LS-1 は、そのような複製をサポート‘’する機能と設定を備えている必要があります。また、LS-1 は、この機能を他の EVPN デバイスと交換する必要があり、その他のデバイスはレプリケーションの責任を LS-1 にオフロードすることになります。トラフィックの転送先となるトンネルもコーディネートされます。
支援する複製を入力します。この章では、支援複製(AR)、その特性、およびテーブルにもたらすメリットについて説明します。これにより、負荷と複雑さが軽減されます。後の章では、最適化されたマルチキャストを導入して、AR がマルチキャストトラフィックに適した方法で DC ファブリックを効果的に動作させる方法についても説明します。
An Important Thing to Note
AR 機能はオプションです。つまり、AR を導入して、マルチキャストトラフィックを最適化できるようにすることは必須ではありません (これについては後の章で取り上げています)。お客様によっては、まず、マルチキャストトラフィックがファブリックで最適化されていることを確認してから、ロードとリンクの帯域幅の使用率の問題に対処します。しかし、アカデミックの理由により、この章では、EVPN マルチキャストのさまざまなメカニズムについて理解しているという点で、AR はよく見られます。
支援する複製の構成要素
次にFigure 4示すように、ファブリックには AR ソリューションの3つのコンポーネントがあります。
AR リーフの役割
AR Replicator の役割
RNVE の役割 (通常のネットワーク仮想化機器): AR 機能をサポートしていないデバイス
このトポロジーの AR リーフは LEAFs となり、AR Replicator の役割は LS-1 および LS-2 になります。LS-1 および LS-2 (AR 年以前) は、ファブリックのアンダーレイアップに参加します。AR を使用すると、これらのデバイスはオーバーレイでも AR replicator の追加の役割を実行します。このようにすることで、ハードウェアの導入が不要になり、既存のデバイスを使用して、前述の受信レプリケーションの2つの困難な問題を解決することができます。
リーフ-1、リーフ-2、リーフ-3、およびリーフ-4 は、AR リーフとして設定されています。(AR-L)
BL-1 および BL 2 は、AR リーフとして設定されています。
Ar-R1 と AR-R2 は、AR として設定されています。
(AR-R)リーフ設定はありません。これにより、RNVE というリーフ5が実現します。
ファブリックでの支援レプリケーションの要件
EVPN Pe は、構成 (AR/Replicator) を使用して特定の AR ロールとして指定するか、またはその不足に合わせて設定する必要があります。(RNVE)
EVPN デバイスは、他の AR デバイスの存在とその役割を検知できなければなりません。
AR 対応デバイス (このため、ar および AR レプリケーター) は、RNVE デバイス (したがって、AR 対応デバイス) に対応している必要があります。
Ar リーフ Pe は、固有のトラフィックを AR に送信するために、ar に対して AR トンネルを構築することができます。
AR-Replicator Pe は、既存の赤外線トンネルを使用して、複製したマルチキャストトラフィックを他の AR リーフデバイスと RNVEs に送信できるようにする必要があります。
AR と AR は、RNVEs からのトラフィックを受信するために、既存の赤外線トンネルを使用できるようにする必要があります。
EVPN マルチホーミングの動作と転送は、IR と同等の機能を備えていることが保証されます。
複製のロードバランスを実現するために、複数の AR Replicator の役割をサポートする準備が必要です。AR リーフ・デバイスは、複数の AR Replicator デバイスの間でロード・バランシングが可能でなければなりません。一般的なお客様の導入では、ロードバランシングと耐障害性を実現するために、2台または4台の AR レプリケーターがファブリックに配置されます。
ファブリックでの補助複製のためのトンネル構築
AR/AR は、レプリケーターとして、現在のタイプ3の通常の赤外線に加え、AR タイプ3ルートを提供しています。Ar タイプ3のルートパラメーターは、AR から AR までの AR トンネルを構築する際に使用されます。
また、ar-R1 と AR-R2 から AR タイプ3のルートを受け取ることによって、レプリケーターを取得すると、複製物の存在を推測し、レプリケーターへの AR トンネルを構築しています。1-4
AR リーフは、AR トンネルで負荷分散機能を構築する方法によって、複数のレプリケーターを検出します。そのため、一部のフローは、レプリケーションのために AR-R1 に送信されます。その他は、AR-R2 となります。
AR リーフと AR の RNVE は、既存のタイプ3ルートに基づいて、互いに赤外線トンネルを構築します。
AR リーフと AR は、次の2つの理由から赤外線トンネルを維持します。(1) リーフは、AR-R から複製されたトラフィックを受信するため、(2)、何らかの理由で AR トンネルが失敗した場合に IR にフォールバックするためのものです。
手動レプリケーショントラフィック転送ルール
Assisted Replication Traffic Forwarding with Traffic Arriving From Behind AR-LEAF
リーフのアクセスインターフェイスでフローに対するマルチキャストトラフィックが受信されると、リーフは、AR-R1 などのレプリケーターのいずれかの複製物にトラフィックを送信します。リーフ-1 では、このトラフィックのコピーを1つだけ AR トンネル上の AR-R1 に送信します。
Ar-R1 は、AR トンネル上のトラフィックを受信すると、このパケットを他の AR リーフ、その他の、その他の RNVEs (リーフ-2、リーフ-3、リーフ-4、BL-1、BL-2)、(AR-2)、および (リーフ 5) に複製します。複製されたトラフィックは、RNVEs の Afs および赤外線トンネル上のその上に送信します。
受信 Pe は、この複製されたトラフィックを既存の赤外線トンネルで取得します。したがって、既存の赤外線トンネルと同じように動作します。そのため、赤外線トンネル上でマルチキャストトラフィックを受信し、それをアクセスインターフェイスに転送します。
Assisted Replication Traffic Forwarding with Traffic Arriving From Behind RNVE
マルチキャストトラフィックが RNVE のアクセスインターフェイス (リーフ) で受信されると、RNVE 自体が各トラフィックを複製して、赤外線トンネル上のその他のすべての LEAFs、x4、BLs (従来の入口の複製) に送信します。RNVE には ar および ar トンネルがないことに注意してください。
AR レプリケーターは、RNVE からこのトラフィックを受信することで、複製が行われないようにする必要があります。AR replicator は、複製するトラフィック (AR リーフの背後) と、複製しない (RNVE の背後) トラフィックを区別できますか。AR-1 は、トラフィックが受信されたトンネルタイプを確認することで、その数値を出力しています。そのため、トラフィックが AR トンネルに着信した場合、他の PEs に複製され、赤外線トンネルに到着しても複製が行われません。
カーディナル AR/IR トンネル転送ルールの概要
AR-Replicator
AR-R で、トラフィックが AR トンネルに到着した場合、複製:
IR トンネルで、複製されたトラフィックをリーフ、RNVE、および AR に送信します。
AR-R では、トラフィックが赤外線トンネルに着信した場合、複製はしないでください。
AR-LEAF
リーフ-1 のアクセストラフィックについて、1つのコピーを AR-R に送信します。
リーフでは、赤外線で受信するトラフィック、前方アクセス (既存の動作)
RNVE: 既存の赤外線転送と受信ルールが適用される
マルチホーミング環境での支援レプリケーション
EVPN Multihoming Local Bias Refresher
最適化してEVPN Intra-VLAN Multicast Without Optimizationマルチキャスト転送で’は、マルチホームトポロジにおける evpn multicast フォワーディングの章で説明することになります。こちら’はクイックバージョンです。リーフ’-1 とリーフFigure 5-2 が esi-1 でマルチホームになっていること、およびマルチキャストトラフィックがリーフ-1 で ESI-1 に到着しているとしましょう。リーフからマルチホームにパケットを複製する場合、リーフ-2 は重複/ループが発生するため、ESI-1 を転送してはなりません。どのようにして ESI-1 での転送を回避するのか?
リーフ-2 はパケットの送信元 IP を確認し、リーフ-1 から発生したことを確認します。このことに基づいて、リーフ-1 でマルチホーム化された ESIs には転送されません。この場合、ESI-1 になります。リーフ-2 は、他のシングルホームインターフェイスを転送し、リーフ-1 のマルチホームではない他の ESIs にも対応します。
Assisted Replication In a Multihomed Environment – AR-R Should Retain the Src-IP of the Replicated Packet
前述したように、ファブリックに AR を導入する場合、AR が複製および送信するパケットに注意する必要があります。つまり、複製されたパケットの送信元 IP は、ローカルバイアスが正常に機能するように、リーフ-1 として保持しておくことが最重要事項と言えます。
AR-R が独自の IP (AR-IP-HTTPS) を Src IP として設定した場合、リーフ-2 は、そのパケットが (AR-R (コア) からのパケットであり、リーフ-1 ではないことを認識しているため) に送信されます。
この場合、リーフ-2 は、複製されたパケットがリーフ-1 (マルチホーム) から発生しているか、または (マルチホームでない) から発生しているかを実際には確認できないため、1つの場所にあります。リーフ-2 は、これをコアから受信した通常の BUM パケットとして扱い、それを esi に転送します (これは ESI に DF しているため、MH では重複/ループが発生します)。
AR-Replicator が受信パケットの Src IP を複製されたパケットに保持することは、必ずしも可能であるとは限りません (プラットフォームによっては)。
AR-R の手動による複製機能は、1つの VTEP (AR トンネル) でパケットを受信し、それを他の VTEPs (IR トンネル) で複製することを目的としています。AR デバイスが次 VTEP の従来の転送手順でパケットを複製して送信する場合、一部のプラットフォームでは、AR デバイスで Src として独自の IP、(AR-IP) のみを配置できます。
通常、PE 受信でアクセス時にトラフィックをレプリケートすると、外部 VXLAN ヘッダーの Src IP を独自の IP として、複数のコピーを構築してリモートの Pe に送信します。AR 年以前は、コアに到着するパケットを変換し、保持された Src IP を使用してコアに返送する必要はありませんでした。
基本的に、受信したレプリケーションは、常にアクセスインターフェイスから着信パケットを取得し、外部ヘッダーにあるコアタイムスタンプに向けてレプリケートしていました。Addi の機能を追加するのは、コアインターフェイスから受信パケットを取得し、それをコアインターフェイス自体に複製しながら、受信パケット’s のソース ip として src ip をスタンプすることもできない場合があります。
特別な処理が行われ、これが固有の転送動作であるため、一部のプラットフォームにはリーフ-1 の Src IP を保持する容量がありません。
改善された支援複製手順をレスキューに
AR は、前述のセクションで説明されている一部のプラットフォームにおいて Src IP を維持できないという制限により、AR の採用を排除できないという大きなメリットをもたらします。このような状況を処理して対処するためにリーフ/Replicator デバイスが何らかの問題を発生させることができれば、それは価値があります。幸いにも、これを解決することができ、拡張されたレプリケーションと呼ばれています。
Capability Exchange
タイプ 3 AR route では、AR は拡張コミュニティー値によって Src IP を維持する機能を提供しています。コミュニティーで基地-arモードを‘使用する’ということは、リーフの src ip を維持し、コミュニティー内の‘拡張 AR’モードの価値を保つことができることを‘意味します。リーフ ip を保持することはできません。’
AR-R Capable of Retaining the Source-IP of LEAF-1
AR-R が Src-IP を維持できるようになっていれば、すべてがうまくいっています。AR は、ベースの AR モードになっていることを示すコミュニティー値を適切に送信します。Exchange をベースにした場合、AR リーフデバイスと AR-Replicatordevices は、すでに説明した、プレーンなバニラ AR プロシージャの手順に従っています。マルチホームのシナリオにも適しています。
リーフの発信元 IP は、リーフからパケットを受信したときに、複製されたパケットとして残ります。葉-2 は、パケットの Src IP をリーフ-1 にするためのものです。これにより、ローカルバイアスを実行し、ESI で転送をスキップします。
AR-R Not Capable of Retaining the Source-IP of LEAF-1
AR-R が Src-IP を保持できない場合、AR-R は、拡張-AR モードになっていることを示すコミュニティー値を設定します。このコミュニティのお客による AR リーフデバイスは、エンハンスモードになっています。この拡張シリーズモードの場合、にFigure 6示すように、Ar-R と ar の両方で余分な手順が必要になります。
Ar Figure 6-R deduces では、どの Ar リーフ PE が VLAN 上でマルチホームであるかを示しています。この情報は利用可能であり、ESIs に対して提供されている EVI ごとの Type 1 のルートから推測することができます。MAC エイリアシングは、この情報を既に使用しています。
AR-R deduces がマルチホーム化されると、リーフ-1 からのトラフィックを受信し、その後、他の LEAFs に複製した場合、AR-R は複製されたパケットをリーフ2だけに送信します。そのため、リーフのマルチホームピアはマルチホームになります。
AR-R はリーフへの送信をスキップしているため、そのトラフィックをリーフに送信するその他の手段が必要です。このため、AR リーフは、アクセストラフィックのコピー1部を複製物に送信し、別のコピーを IR トンネル上で1つのリーフに複製します。(その VLAN 上の MH ピア) この場合、このトラフィックを送信するために必要な他のシングルホームインターフェイスを持つことがあるため、このことはリーフに送信する必要があります。
リーフがリーフからのトラフィックを受信すると、パケットの Src IP が表示され、必要な’ことができます (DST ローカルバイアス)。リーフ-2 はすでにリーフ-1 から直接受信しているため、ローカルバイアスを実行し、ESI リンクでは送信せず、シングルホームインターフェイスを転送できます。
このようにして、AR のメリットを実現する際には、マルチホーミングシナリオでも処理されるようになりました。
全体的にサポートする複製手順
AR-Replicator:
AR-R で、トラフィックが AR トンネルに到着した場合、レプリケート
IR トンネルで、複製されたトラフィックをリーフ、RNVE、および AR に送信します。
AR-R で、トラフィックが赤外線トンネルに着信した場合、複製を行わない
AR-LEAF:
リーフ-1 のアクセストラフィックについて、1つのコピーを AR-1 に送信します。
リーフ-1, IR でのトラフィック受信、前方アクセス (既存の動作)
RNVE: 既存の赤外線転送と受信ルールが適用される
Enhanced-AR Additional Forwarding Rules, in Addition to Base-AR mode:
AR-R は複製されたパケットのリーフへの送信をスキップします。
リーフ-1 はリーフ-2 への余分なコピーを作成し、赤外線トンネルを介して送信します。
章のまとめ
この章では、援助された複製、そのメリット、基本的な手順、EVPN MH シナリオによるプラットフォームの制限、およびそれを検知して収容する手順を紹介しています。
AR を使用することで、ローエンドのリーフデバイスから機能を備えたハイエンド・レプリケーターのデバイスへのレプリケーションの負荷を効果的に転送し、リーフのレプリケーションの負荷を軽減し、LEAFs とリーンスパインの間のリンク帯域幅の過度な使用を回避できます。既存のアンダーレイスパインは、Replicator の追加の役割を果たします。
マルチホーミング環境では、AR には基本とエンハンスの2つのモードがあります。タイプ 3 AR ルートでは、拡張コミュニティーとの機能交換が行われています。
リーフの Src の IP アドレスが保持されているベース-AR モードでは、マルチホーミングの手順が、元のリーフの Src IP が AR によって保持されているときに重複が発生しないように自動的に機能します。
リーフの Src IP が保持されていない拡張-AR モードでは、拡張 AR プロシージャに従って、重複が発生しないようにしています。これを実現するには、複製されたパケットをマルチホームピアに送信し、受信した PE で1つのコピーを AR-R に、もう1つのコピーをマルチホームピアだけに送信します。
以降の章では’、マルチキャストの最適化に向けた最初のステップについて説明します。Ob によって最初に、アクセス側へのトラフィックを最適化する方法と、コアへのトラフィックを最適化する方法を提供します。
EVPN Base Configuration in DC Fabric Topologyでは、この章とEVPN Intra-VLAN Multicast Without Optimizationされていません。どこでもマルチキャストトラフィックを氾濫させていました。そのため、トラフィックはすべての送信 Pe およびアクセスインターフェイスに送られます。また、出力 Pe はアクセスインターフェイスに送信します。
すでに述べたように、AR またはその手順の概念を理解することは、次の章でさまざまなマルチキャストの最適化に進むための前提条件ではありません。最適化の各機能を導入する際に、AR が最適化とともに導入されている場合にどのように適合するかを説明します。