VxLANの概要





本日は、別の興味深いテクノロジーであるVxLANについて説明します。VxLANは、どのような動物で、どのような動物と一緒に食べられるのか、そして実際に必要ですか。 このテクノロジーの私の知り合いは、ハイパーバイザーの研究から始まりました-私は絶えずVxLANという用語に出会いましたが、それが何であり、どのように機能するのかわかりませんでした。 ある晴れた日、それでも私はそれがどんな動物であるかを読むことにしました。 いくつかの記事を読んだ後、この技術はハイパーバイザーの運命であり、トランスポートと間接的な関係があることを読んで、技術の基本的な側面を自分で学び、確実に息を吐きました(ただし、後で判明したように、VxLANはトランスポートと非常に直接的な関係があります) その後、私はテクノロジーを安全に忘れて、EVPNに飛び込み始めた1年後に再び戻ってきました。ほとんどの記事とマニュアルは、特にEVPNとVxLANの共生に関するものでした。 特に英語を話す場合、この技術に関する多くの文献があります。 この記事では、このテクノロジーの基本について説明し、実際にどのように構成および機能するかを説明します。 しかし、MPLSから始めましょう...



私にとって、IP / MPLSネットワークを運用するエンジニアとして、このテクノロジーで最も重要なのは、第2レベルおよび第3レベル(L2CKT、VPLS、L3VPN、6PEなど)の仮想ネットワークを編成する能力です。 あらゆる種類のトラフィック、エンジニアリング、fastreouts。ただし、これらはエンジニアにトラフィック管理の点で非常に大きな機会を与え、9桁の場所の数を増やします(理論的には、ほとんどすべてがネットワークアーキテクチャの複雑化につながり、その結果、クラッシュを解決するための期間が長くなります) IP / MPLSネットワーク展開自体が目的です。 mplsは、VPNの作成方法がわからない場合、大規模プロバイダーおよび小規模プロバイダーにとって、このような人気のあるテクノロジーおよび事実上の標準になりますか? もちろん違います。 そうですね、トラフィックエンジニアリングを導入するためにネットワークの再描画を開始することはまずありません。



IP / MPLSネットワークは、通常、ジュニパーMXやCisco ASR9K / 99(いずれにせよ、IP / MPLSネットワークのコア)などの高性能ルーター上に構築されます。 原則として、そのような機器はデータセンターでは一般的ではなく、通常、このレベルのルーターがデータセンターに設置されている場合、それらはDCIまたはアップリンクが編成されるPEシェックまたはボーダーボードのような役割を果たします。 問題は主に機器のコストです。スイッチの1つのポートのコストは、ルーターの同様のポートのコスト(スループット、スロットごとのポート密度などの同様の指標)よりもはるかに低くなります。 データセンターには通常、1/10/40 / 100G(ToR / EoR / Spine / Leafの機器のタイプに応じて)の容量を持つ高密度のポートを備えた高性能のノンブロッキングまたは部分ノンブロッキングスイッチがあります。たとえば、Cisco Nexus、AristaまたはJuniperの非常に見栄えの良い製品です。



ただし、同じCisco Nexus 9KはMPLSドメインでの使用には適していません。ラベル配布プロトコル、またはMPLSがサポートしているように見えるが、まだfibサイズなどの制限があるJuniper QFXをサポートしていないためです。 つまり、実際には、ジュニパーQFX上に構築されたデータセンターでMPLSを起動することは理論的には可能ですが、実際にはこれは最良のソリューションではありません-ある時点で、この機器の機能に出くわすことになります(この瞬間はすぐに来るでしょう)。



一方、データセンターには、L2接続とジオリザーブの両方を必要とする多くのシステムがあります。 MPLSを使用せずにネットワークの異なる部分にあるサーバー間でL2接続を提供する方法 一般的に、掘り下げると、この問題を解決するためのいくつかの異なるオプションがあります。 記事のタイトルから容易に推測できるように、これらのニーズに合わせて特別に調整されたテクノロジーについて説明します。VxLANは、通常のIPネットワークの上に地理的に拡張されたL2ネットワークを構築でき、今日はデータセンターの事実上の標準です。



IP / MPLSネットワーク上で組織されたサービスは、何らかの形でトンネリングされます-いずれにしても、私たちは何かをトンネリングしています。 たとえば、ポイントAとBの間のシンプルなL3VPNを考えてみましょう。最も単純なバージョンでは、Cトンネルまたは迂回トンネル/バイパストンネルのオプションがなく、2つのラベルのスタックがあります-下部、サービスラベル、上部のトランスポートです。 当然、トンネルのポイントAとBの間に何らかのサービスを配置するには、これらの同じポイントAとBの間にエンドツーエンドトンネル自体が必要です。LDP/ RSVP-TE LSPは、IP / MPLSでそのようなトンネルとして機能します。 さらに、このトラフィックトンネル内にクライアントトラフィックを転送するために設計された別のトンネルを配置することを誰も禁止していません。



その結果、別のトンネルをトンネルするトンネルを取得します。 つまり、最終的には、1つのネットワーク(クライアントネットワーク)が別のネットワーク(プロバイダーネットワーク)の上に構築されていることがわかります。 プロバイダーのネットワークは、アンダーレイネットワークと呼ばれます。 本質的に、これはオーバーレイネットワーク(VPN)を構築するための基盤です。 アンダーレイネットワークの上に展開されたクライアントネットワークはオーバーレイネットワークであり、既存のオーバーレイテクノロジーの一部(たとえば、同じL3VPN)を使用して構築されます。 つまり、VPLS / L2CKT / L3VPNなどでは、IP / MPLSネットワークがアンダーレイとして使用され、同じMPLSがオーバーレイとして使用されます。



しかし、MPLSがなく、L2VPN(より正確にはVPLS)が必要な場合はどうなりますか? 前にも言ったように、これを可能にするさまざまなテクノロジーがありますが、VxLANは停止します。 このテクノロジーは、UDPと組み合わせて、IPネットワーク上でMPLSタグを使用せずに仮想L2マルチポイントネットワーク(本質的にVPLSのアナログ)を編成できます(IP / MPLSネットワーク上でも機能します-テクノロジーにとってIP接続のみが重要であることが後でわかります) 。 たとえば、アンダーレイでトンネルとして機能するものや、オーバーレイでサービスマークとして使用されるものなど、多数の質問がすぐに発生します。 これらおよびその他の質問にさらに回答します。



したがって、VxLANは仮想拡張可能ローカルエリアネットワークです。 文献では、MAC-in-UDPの別の名前を見つけることができます。 これは同じVxLANであり、2番目の名前はテクノロジーの本質をよりよく説明しています。 ご想像のとおり、VxLANは、通常のイーサネットフレームをUDPセグメントにパックし、IPネットワークを介してこの形式で転送できるようにする技術です。 これまでのところ、明確なことはほとんどないと思いますので、もう少し詳しく見ていきましょう。



IP / MPLSネットワークでは、ルーターには通常、特定の目的があります。たとえば、PE、P、またはASBRなどです。 PEルーターはマルチサービス集約ノードです。 簡単に言えば、これらはクライアントサービスが接続されるノードです-IP / MPLSネットワーク上で実装されるL2 / 3VPN、VPLS、およびその他のVPNサービスは、これらのノード上で開始および終了します(ラストマイルスイッチおよびオプション) A / B / Cは現在検討していません)。 IP / MPLSネットワークの2番目の重要な要素はPレベルのルーターです-基本的にトラフィックの脱穀機(特にFree Coreがある場合)であり、VPNサービスの組織に関与していることすら認識していません。



VxLANテクノロジーにもこのようなノードがあり、それらは本質的に同じ機能を実行しますが、少しだけ異なる方法で呼び出されます。 PEルーターの類似物はVTEP-仮想トンネルエンドポイントです。 VTEPはサービス集約のハブであり、VTEPはToR / EoR /リーフスイッチまたはPEルーターだけでなく、必要なソフトウェアがあれば通常のサーバーにもできます(たとえば、VMWareはこれを実行できます)。 IP / MPLSと同様に、VTEPトンネルはVTEPで開始および終了します。 レベルPルーターの類似物は、クライアントを終了せず、単にIPトラフィックを転送するルーター/スイッチです-これらのスイッチは、通常、VxLANネットワーク内のトンネルの存在さえも知りません(たとえば、ゲートウェイがそれらに運ばれなかった場合)。



例で何かを説明することは常に簡単です。したがって、VxLANの基本原則に移る前に、私たち全員にとって非常に重要でよく知られているもう1つの技術であるVLANを思い出してください。



VLANは、ネットワークを第2レベルでセグメント化するための技術です。 ご存知のように、標準スイッチは、転送テーブル(彼自身が作業中に作成した)に基づいてフレームの転送を行います。転送テーブルは、フレームのMAC宛先アドレスだけでなく、そのタグも考慮します。 VLANとVRFを類推すると、各Vlanは最も簡単に個別の仮想エンティティ、つまり仮想スイッチと見なされます。 シスコでvlan 100コマンドを発行して、vlanタグ100で仮想スイッチを作成します。作成した各仮想スイッチには、特定のインターフェイスセットがあります(一部のインターフェイスでvlanを許可することにより、特定の仮想スイッチにポートを追加します)。アドレスとポート(show mac-address-table dynamic vlan 100コマンドで表示されます)。



理論的には、vlanタグのあるフレームがスイッチのあるポートに到着すると、フレームをさらに送信する決定は、対応する仮想スイッチのアドレスのmacテーブルに基づいて行われると想像できます。 タグが100のフレームを受信すると、タグが100の仮想スイッチのMACテーブルに基づいて、このフレームの転送に関する決定が行われます。



フレームを受信すると(BroadcatまたはUnicastのフレームは関係ありません)、従来のスイッチはすべてのポートにフラッディングします。 スイッチがパケットを特定のポートまたはポートのグループにフラッディングしない理由がある場合、これを行いません。スイッチが確実にわかっていれば、宛先MACが特定のポートにない、またはこのフレームを特定のポートに送信する必要がある、またはポートは不要です(たとえば、igmp-snoopingが有効になっている場合)、スイッチはこのポート(またはポート)にフレームをフラッディングしません。 フレームを受信するとき、スイッチには少なくとも、このフレームを送信元のポートにフラッディングしない理由があります。これは、水平線を分割するための一般的なルールです。 スイッチがMAC宛先アドレスが特定のポートに存在することを確認している場合、フレームは1つの特定のポートにのみ送信されます。 上記に基づいて、論理スイッチは次の形式で表すことができます。



写真からわかるように、vlanタグ100に付属するフレームが仮想スイッチ100に落ち、別の仮想スイッチ、つまり200などのように、別の仮想スイッチにちょうど入ることができないことが論理的です。仮想スイッチ間に直接接続はありません。 ルーティングインターフェイスを作成するとき、仮想スイッチが他の仮想スイッチと通信できるインターフェイスを作成します。仮想インターフェイスは、ルーティングインターフェイスも備えています。つまり、vlane間でパケットをルーティングします。



この図は、VLAN-100およびVLAN-200仮想スイッチに、これらの仮想スイッチが通信できるルーティングインターフェイスがあることを示しています。 同時に、L3インターフェイスはVLAN-N仮想スイッチ用に構成されていません-つまり、この仮想スイッチは他の仮想スイッチ(この例では、VLAN-100およびVLAN-200)と通信できません。 クラシックL2ネットワークのVLAN番号はグローバルです-たとえば、10台のスイッチのL2ドメインがある場合、VLAN番号はドメイン全体でグローバルです。



ただし、スイッチの動作原理を理解するには、これがスイッチの単純化された論理モデルであることを理解する必要があります。 また、Vlanは仮想スイッチとして想像できますが、実際にはそうではありません。 つまり、vlan 100またはvlan 200の個別のスイッチングテーブルはありません。当然、特定のvlanで調査したポピーを見ることができます(同じケシが異なるvlanに存在することがわかります)。しかし、これは別のテーブルが機器上のこのVLANに割り当てられることを意味しません。 スイッチには、設定されているVLANの数に関係なく、単一の転送テーブルがあります。 単純に、受信したフレームがあふれると、スイッチはこのフレームを特定のポートに送信する必要がないことを認識します。 たとえば、eth1 / 1ポートがvlan 200のアクセスポートであり、eth1 / 2ポートがトランクポートであるが、vlan 100が許可されていない場合、フレーム(物理的)はこれらのタグ100でフレームをフラッディングしません。 100番目のVLANにこれらのポートの背後にホストがないことを確実に知っています。 物理的には、これはそのように起こりますが、これらのポートがvlan 100の仮想スイッチに属していないため、フレームを送信できないことを想像するのは論理的に簡単です。

注:この概念を最新のルーターのブリッジドメインに適用しようとするべきではありません-これは本質的に独自の法則を持つ異なる世界であり、VLAN番号は本質的にリンク上でのみ重要です。 説明されているものはすべて、拡張VLANスペースをサポートしないクラシックスイッチに対応しています。 ブリッジドメインについて(JunOSに関連して)別の記事を書きました。 誰でも興味があるなら、IOX-XRについても同様の記事を書くことができます。


つまり、次のものがあります。vlanタグによって定義され、ポートのセットを持つ仮想スイッチがあります。 まったく同じ概念がVxLANの根底にあります。 VxLANでのみ、vlanタグの役割はVxLANネットワーク識別子(仮想ネットワーク識別子とも呼ばれる)またはVNIによって実行されます。 12ビット長のvlanタグとは異なり(つまり、1つのL2ドメインに最大4096個のVLANが存在できます)、VNIの長さは24ビットです。つまり、16,777,214個の一意の値を取ることができます。 vlanタグと同様に、VNIはVxLANドメイン全体に固有です。 つまり、ホストAがVTEP Aの背後にあり、ホストBがVTEP Bの背後にある場合、両方のVTEPでこれらのホストは同じVNIに属するインターフェースの背後になければなりません。ではありません。 すべてがVLANに似ています-ホストがvlan 100にあり、他のホストがvlan 200にある場合、これらのホスト間にL2接続がないためです。

注:1つのノード内でのみ一意であるMPLSタグとは異なり、VNIはVxLANドメイン全体にグローバルに関連していることを理解することが非常に重要です。 そのため、VxLANまたはVPLS(MPLSを使用)を使用する場合、L2ネットワークの増加を計算することは非常に困難です。 絶対値は自然であり、VxLANを指します。 ただし、VPLSで異なるクライアントに同じラベルを使用できる場合(たとえば、PE 1のVPLSドメイン1がラベル299001を使用する場合、これはPE 2のVPLSドメイン2が同じラベル299001を使用できないことを意味しません) 。 ただし、VxLANを使用する場合、このような番号は機能しません。 PE1とPE2の両方で同じVNIを使用する場合、PE1に接続されたクライアントはPE2に接続されたクライアントと通信できます。


前に書いたように、VLANを作成するとき、基本的に仮想スイッチを作成してから、必要に応じていくつかのポートとルーティングインターフェイスを追加します。 しかし、どのポートを追加しますか? 物理ポートを使用する必要がありますか? または、仮想のものを使用できますか? たとえば、GREなどのプロトコルを思い出してください。 GREトンネルを作成すると、論理インターフェイスが作成されます(たとえば、JunOSのgre-0 / 0/0)。 同様に、VxLANトンネルを作成すると、スイッチにトンネルインターフェイスが表示されます(たとえば、JunOSのvtep.xxx)。 後で見るように、このインターフェイスはトランキングされ、タグ付きフレームとタグなしフレームの両方を伝送できます。 いくつかのボックスに登ってVPLSのポピーアドレスのテーブルを見る機会がある場合、ポピーの一部は物理ポートではなく、論理lsiインターフェイス(JunOSの例を使用)からは見えないことがわかります。 Lsiインターフェイスは、PEルータへのトンネル(VPLS用語では疑似回線)にすぎません。 より悪いVxLANトンネルは何ですか? VxLANは同じ原理を使用します-トンネルのシグナリングのみが異なります。



その結果、スイッチはトランクポートとしてVxLANトンネルを使用し、実際のポートと同様にパケットがフラッディングされ、それを通してポピーが検査されることがわかりました。 つまり、複数のリモートVTEPがある場合、スイッチロジックは次のようになります。



ただし、冒頭で述べたように、ポートに受信フレームをポートまたはポートのグループにフラッディングしない理由がある場合、これは行われません。 デフォルトでは、フレームは到着したポートだけに送信されるわけではありません-これは水平線を分割するための単純なルールです。 VxLANでは、このルールも機能しますが、いくつかの微妙な違いがあります。



物理ポートを介してフレームを受信するとします。 このシナリオでは、すべてが正常です-スイッチは、パケットをすべてのポートにフラッディングします(フレームの受信元ポートを除く)。 しかし、フレームがVxLANトンネルを介して受信された場合はどうなりますか? VxLANトンネルから完全に接続されたトポロジはすべてのVTEPの間に作成されるため、他のVTEPがすでにこのフレームを受信して​​いるため、トンネルから受信したフレームを他のVxLANトンネルに再度フラッディングする必要はありません-これは完全に接続されたトポロジの本質です。



しかし、どのポートでフレームをフラッディングする必要があるのか​​、どのポートで必要でないのかをどのように理解するのでしょうか? これを行うには、VxLANトンネルであるポートを仮想グループに結合し(スプリットホライズングループと呼びましょう)、このグループのメンバーであるポートからフレームを受信した場合、フレームはこのグループに含まれる他のポートにフラッディングしません。 当然、機器を使用すると、ハブアンドスポークトポロジなどのこの動作を変更できます。 ただし、このようにしないでください。ブロードキャストストームは「面白い」ことです。



この記事の最初の部分を要約すると、VxLANはVLANの拡張アナログです。つまり、仮想L2ネットワークです。仮想L2ネットワークはそれらの間で分割され、これらのネットワーク間のトラフィックは切り替えることができません-これにはルーティングが必要です。 VLANと同様に、VxLANには、仮想L2ネットワークの識別子として機能するアナログVLANタグ、VxALNネットワーク識別子(VNI)があります。 VNIの長さは24ビットであるため、1つのドメインで1600万を超える仮想L2ネットワークを使用できます。 VLANタグと同様に、VNIはL2(VxLAN)ドメイン全体でグローバルに一意です。 MACアドレスは、フラッドアンドラーニング方式を使用して調査されます。スイッチはすべてのポートにフレームをフラッディングし(フラッディングしないポートと以前にソートした理由)、送信元MACアドレスの転送テーブルを埋めます。次に、リモートVTEPとシグナリングトンネルを検索する方法について説明します。



そのため、記事の冒頭で書いたように、vpnは何かを通して何かをトンネリングしています。 IP / MPLSでは、IP / MPLSネットワークがアンダーレイとして使用され、同じMPLSがオーバーレイとして使用されます。これらは、何かを通り抜けることができる唯一のテクノロジーではありません。 GREプロトコルに戻りましょう。これは、ポイントAとBの間に仮想p2pリンクを作成するオーバーレイテクノロジーです。このプロトコルは、元のIPパケットを新しいIPパケットにカプセル化し、これらのヘッダー間に独自のGREヘッダーを挿入します。



VxLANはもう少し複雑ですが、これには説明があります。 GREと同様に、VxLANヘッダーが元のイーサネットフレームに追加されます。このヘッダーの長さは8バイトであり、フラグと予約フィールドに加えて、前述のVNIを保持します。つまり、理解しているように、このヘッダーは、スイッチがこのパケットがリモート側でどのVNIに属しているかを判別できるようにするために必要です。つまり、本質的にVLANタグの役割を果たします。次は?GREの場合のように、元のフレームをIPパケットのVxLANヘッダーでパッケージ化することは論理的です。しかし、問題があります。ご想像のとおり、IPプロトコルヘッダーにはプロトコルフィールドがあります。このフィールドは、このIPパケットにどのアップストリームプロトコルがパッケージ化されているかを管理します。 GREヘッダーはプロトコル番号47ですが、VxLANには番号がありません。つまり、本質的に、VxLANをIPに直接パックすることは可能ですが、これにより、中継ノードと宛先ノードの両方でパケットの処理が困難になります。そのため、GTPなどのVxLANパケットは、プロトコルフィールドのないUDPにあらかじめパッケージ化されています。そして、受信したUDPセグメントをIPパケットにパックすることを妨げるものは何もありません。 VxLANでは、UDPポート4789が特別に割り当てられました。



問題は-なぜUDPなのか?なぜTCPではなく、より信頼性が高く、セッションのタイムアウトが地獄のようになっているなどです。実際、TCPはまったく異なるニーズに合わせて設計されており、そのタスクはアプリケーションデータの配信が保証されているため、リモート側でパケットの受信を確認し、伝送速度を制御するメカニズムです。クライアントもTCPを使用する場合、問題は明確に表示されます。その結果、TCP over TCPを取得します-あまり良い音ではありません。パケットが失われると想像してください。ご存知のように、VTEP-A << >> VTEP-Bのアンダーレイセッションのコンテキストでも、SERVER-A << >> SERVER-Bのオーバーレイセッションの一部としても失われます。また、TCPでパケットを失うと、受信の確認応答がないため、再送信が自然に発生します。その結果、再送信はアンダーレイセッションとオーバーレイセッションの両方で発生します。つまり、判明アンダーレイTCPセッションはリレーパケットに加えて駆動を開始し、オーバーレイTCPセッションもリレーします。その結果、このようなシナリオでは、再送信が頻繁に発生し、必然的に速度が低下し、最終的にはプラスではなくマイナスのみになります。さらに、UDPを支持するもう1つの重要な要因は、TCPが常にp2pセッションであり、p2mpにできない場合、UDPはセッションを確立しないという事実です。しかし、なぜそれが必要なのかは後でわかります。TCPが常にp2pセッションであり、p2mpであってはならない場合-ただし、後でそれが必要な理由を見つける必要があります。TCPが常にp2pセッションであり、p2mpであってはならない場合-ただし、後でそれが必要な理由を見つける必要があります。



VxLANヘッダー自体の形式は次のとおりです。実際、ここで必要なのはVNIフィールドのみです。上で書いたように、UDPセグメントをIPにパックして送信することを妨げるものは何もありません...しかし、どこに?祖父の村ではありません。 VxLANトンネルはスイッチバックループバック間に構築されるため、アドレスはスイッチ自身のループバックになります。しかし、VTEPの役割を実行するリモートスイッチのループバックをどのように知るのでしょうか?つまり、隣人を見つけるためのメカニズムが必要です。近隣を見つけるためのメカニズムは、自動または手動です(手動が近隣の検索とも呼ばれる場合)。 VxLANにはいくつかの動作モードがあります。それらを順番に考えてみましょう。静的(ユニキャスト)VxLAN



















最も簡単なオプションは、リモートVTEPの静的な表示です。このモードはVPLS Martiniに似ています。すべては、VNI構成では、指定されたVNIのクライアントを終了するすべてのリモートVTEPのアドレスを静的に設定する必要があるという事実に帰着します。このようなシナリオでは、VTEPは、IPヘッダーで宛先アドレス(VTEPによって手動で指定されたアドレス)として示します。当然、3つ以上のVTEPがある場合、フラッディング中に少なくとも2つのパケット宛先ポイントがあります。 IPヘッダーに複数の受信者を指定することはできないため、最も簡単な解決策は、発信VTEPでVxLANパケットを複製し、構成で指定されたリモートVTEPにユニキャストで送信することです。このパケットを受信すると、リモートVTEPはそれをカプセル化解除し、パケットがどのVNIに属しているかを判別してから、指定されたVNIのすべてのポートに転送します(より正確には、スイッチの解析で前述したように)。さらに、すべてのMACアドレスはソースMACフィールドに基づいてスイッチによって学習されることがわかっているため、VTEPパケットのVxLANのカプセル化を解除した後、MACアドレスは、このパケットの受信元であるVTEPへのトンネルを持つ元のイーサネットヘッダーの発信アドレスとして指定されます。以前に書かれたように、VxLANトンネルはスイッチを単純なトランクポートとして認識します。



このアプローチの欠点は明らかです-これはネットワークの負荷の増加です。BUMトラフィックは発信VTEPで複製され、ユニキャストは構成ネットワークで指定されたすべてに送信されるため、VTEPを追加または削除する場合、他のすべてのVTEPの構成を編集して手動で削除または追加する必要がありますneybor(neyborov)。自動化の時代に、静的な表示のニューブを使用することはなんとなく奇妙です。それでも、このアプローチには生命の権利があります。たとえば、openvswitchは、少なくとも現時点では静的に定義されたネイバーでしか動作しません(正しくない場合は修正します)。



このモードが機能するためには、すべてのVTEPのループバック間の接続の存在のみが必要です。実際の部分では、このモードでのVxLANの構成と操作について詳しく説明します。



マルチキャストVxLAN



この操作モードは、前のものとは異なり、リモートVTEPを自動的に検出でき、ブロードキャストレプリケーションは発信VTEPではなくアンダーレイで発生します。マルチキャストを使用して、リモートVTEPの複製と検索の両方が行われます。ここで、すべてのニューロンを手動で指定する必要はありませんが、特定のVNI(または複数のVNI)に関連付けられるマルチキャストグループの種類を指定する必要があります。グループがVNIに接続された後、スイッチ(より正確にはVTEP、単純なサーバーである可能性があるため)がこのグループのリッスンを開始します。しかし、これは私たちに何を与えますか?他のVTEPが同じことを行うのは論理的です(もちろん、VNIマルチキャストグループの対応を正しく指定しない限り)-指定したグループをリッスンします。また、このグループのアドレスにパケットを送信すると、すべてのVTEPがパケットを受信します。この機能により、パケットを複製し、リモートVTEPを検索できます。



その結果、すべてが単純に機能します-VTEPはVxLANパケットを形成し、それ自体をソース(IPヘッダーのループバック)として示し、宛先アドレスはこのVNI用に設定されたマルチキャストグループのアドレスと同じに設定されます-つまり、VTEPもこのためのソートになりますグループ。その後、通常の、そして最愛のマルチキャストが私たちのために働きます。他のすべてのVTEPはこのグループをリッスンするため、すべてVEP LANパケットを受信します。元のフレームのカプセル化を解除し、ポピーを調べます(このVTEPグループのsorsはそれ自体を示しているため、リモートVTEPがMACを発信VTEPへのトンネルに関連付けることは難しくありません)。



さて、UDPでのVxLANカプセル化と質問-なぜUDPなのか?ご理解のとおり、1つのソースと複数の受信者というp2mp接続を取得しました。 TCPは、セッションをまったくインストールしないUDPとは異なり、p2mpセッションを確立できません。



原則として、VTEPは同時にマルチキャストグループ(または構成に応じて複数のグループ)の受信者およびソースであるため、ベストプラクティスは双方向以上のPIMと見なされます。当然、水平分割ルールもここで機能します。VxLANトンネルを介して受信したパケットは、VxLANトンネルに送り返されません。



このシナリオの最初のオプションと比較すると、BUMトラフィックはアンダーレイに複製され、当然、より少ない帯域幅を使用します。さらに、今では手でニューロンを設定する必要はありません。このモードでは、リモートVTEP over IPおよびマルチキャストサポートへの接続が必要です。何かがうまくいかなかった場合(ここでそれがバラバラになっていることを理解しているなら、何もありません)-最初にVNIマルチキャストグループを正しく構成したかどうかを確認します。これをどのように構成するか、実際の例を分析します。



EVPN / VxLAN



3番目のオプションは、これも最も興味深く、スケーラブルですが、VxLANのコントロールプレーンとしてEVPNを使用することです。 EVPNが誰か知らない場合は、以前の記事を読むことをお勧めします。MPLS/ EVPNの概念に関連していますが、仕事の基本原則はVxLAN / EVPNにも有効です。今日は、EVPN / VxLANを掘り下げません。主要なポイントに限定します。



上で書いたように、EVPNの基礎は、偉大で強力な(または長い間苦労している)BGPプロトコルです。これにより、VTEP間のポピーを研究し、近隣を検索できます。この獣はあらゆるルートを運ぶことができ、リンク状態情報を送信することもできるので(どのような進歩があったのか)、MACアドレスに関する情報を転送する必要がありますか? EVPNでは、アドレスの個別のサブファミリーがl2vpnファミリーに割り当てられます(AFI 25)。これにより、MACアドレスをルーティングアドレスのアナログに変換し、BGPアナウンスで送信することができました。つまり、L3VPNで行われるのと同じ方法です。 BGP NLRIでEVPN / MPLSを使用する場合、MACアドレス自体が送信されました(もちろん、RT / RD /ネクストホップなどを忘れないでください)およびMPLSラベル。ラベルは必要ありません。MPLSはありません。 VNIがあるので、必要ありません!唯一の問題は、BGPメッセージのラベルの代わりにVNIをエンコードする方法です。



EVPN NLRIがラベルに誤って3バイト割り当てられることはありません。つまり、24ビットです。これはVNIを指定するのに理想的です。したがって、BGPアナウンスメントのラベルの代わりに、VNI識別子が論理的にラベルの代わりになりました。解決する必要がある唯一の問題は、指定されたEVPNルートを受信するスイッチが、MPLSラベルではなく、MPLSラベルフィールドでエンコードされたVNIであることをどのように見つけるかです。実際、デフォルトではラベルがあり、このフィールドの値をラベルとして使用して、スイッチは完全に正しくなります。 Wiresharkでダンプを削除すると、VNIではなくMPLSタグが表示されます(タグをエンコードする場合、最後の4ビットは使用されないため、WiresharkはフィールドがVNI 100ではなくラベル6でエンコードされていると考えています):この問題を解決するために、特別な拡張コミュニティが使用されますこのルートは、特にvxlanカプセル化に使用する必要があります。







そして、ラベル用に予約されたフィールドを10進法に変換すると、VNIが得られます:残りの動作原理はほぼ同じです-同じ5種類のルート(正直に言うと、ルートは現在8種類ですが、そのうちのいくつかはまだドラフト状態です)。デフォルトでは、カーネルにマルチキャストがない場合、最初のバージョンで検討したように、発信ノード(発信VTEP)でのレプリケーションが機能します。ただし、マルチキャストが存在する場合、複製は発信ノードではなく、さらにどこかで実行されます(原則として、RP経由よりもソースへのパスが短い場合は、RP上で、または他のポイントで)。







ケシの研究についても言いたいと思います。EVPNの利点は何ですか?原則として、最初の行のどこでも次の内容のフレーズを記述します-EVPNはデータプレーンからコントロールプレーンにケシのアドレスの調査を転送します。それは非常に誇り高き進歩的なように聞こえますが、考えてみましょう、本当にそうですか?まず、Client-VTEPセクションでのケシの調査は、原則として、データプレーンで行われます。次に、スイッチがフレームを受信するとどうなりますか?そうです、それはすべてのポートにそれをフラッディングします。ただし、クライアントがまったくない(スイッチによる)ポートは除きます。



EVPNの概念は次の動作を意味します-リモートVTEPの一部がデータプレーンを介してMACアドレスを学習すると、このケシが示されているBGPメッセージを生成し、ピアに送信します。このBGPメッセージを受信した他のすべてのVTEPは、受信したMACを転送テーブルにインストールします。これにより何が得られますか?そして、スイッチが宛先MACの正確な場所を知っているため、すべてではなく1つのポートのみにフレームを送信する理由がスイッチにあるという事実。しかし、彼がコントロールプレーンから学んだことは、私たちにとって絶対に重要ではありません。



しかし、スイッチの動作モデルに何か変更はありますか?もしそうなら、変更の規模はどれくらいですか?はい、スイッチはフレームを受信して​​MACアドレスを調べ、このポピーを示すBGPメッセージを生成してピアに送信します。つまり、そのようなMacが背後にあることを全員に通知します。ただし、スイッチが宛先MACの場所をまだ知らない場合、受信フレームをすべてのポートに論理的にフラッディングします。つまり、flood-and-learnメソッドを使用したポピーの研究はどこにも行かず、さらにEVPNでも、ポピーの研究は依然としてFloodメソッドで機能しますが、データプレーンから学習したポピーがコントロールプレーンを介してスイッチ間で転送されるようになりました。その結果、EVPNはケシの調査で洪水の量を大幅に減らすことができますが、それを完全になくすことはできません。



EVPNは他に何を提供しますか?この技術により、近隣の自動検索機能が提供されるため、ネットワークエンジニアの生活を簡素化できます。



EVPNのもう1つの非常に重要な機能は、シングルアクティブとオールアクティブの両方のマルチホーミングです(さらに、MC-LAGとは異なり、1台のサーバーが複数のスイッチを監視できます)。マルチホーミングは、ベンダー独自の手段(MLAG-Arista、vPC-Cisco Nexus)、またはEVPNの標準的な手段のいずれかで編成できます。最初のケースは今私たちにとって興味深いものではありません-EVPNで配線されたマルチホーミングメカニズムについて説明しましょう。原則として、それはすべて、L2ループを取り除く方法に帰着します(All-Activeでは、これはSingle-Activeでは必要ありません)-エイリアシングと障害発生時の収束の加速はすでに美しく機能的なキットです。既にご存知のように、このために、セグメントでDFが選択されています-これは、BUMトラフィックをクライアントに送信する権限を持つノードです。他のすべてのノードは、クライアント宛のBUMトラフィックを単にドロップします。しかし、問題はその後になりますクライアントがブロードキャストフレームを非DFノードに向けて送信し、DF側に転送するとき。さらにDFがフレームをクライアントに返すと論理的になり、ループが発生します。



EVPN / MPLSでは、スタックにESIタグを追加するだけでこの問題は解決されました。スタックにそのようなタグがある場合、DFはトラフィックを受信したセグメントにトラフィックを送り返しません。ただし、VxLANにはタグがありません。どうする?ここでは、ループに対する保護のメカニズムが少し変更されています。



EVPN / MPLSの場合と同様に、同じセグメントを見るインターフェースは同じ識別子(ESI)を持つ必要があります。タイプ4のルートを交換した後、ノードはESIパートナーを見つけ(MC-LAGとは異なり、3つ以上あります)、DFを選択します。これにより、ブロードキャストトラフィックがセグメントに送信されます。ラベルはありませんが、ESIによってネイバーのアドレスはわかっているため、ブロードキャストフレームを受信するとき、スイッチは最初にパケットが到着した(つまり、どのトンネルから)アドレスを調べます。 ESIネイバーとして指定されているVTEPからパケットが到着した場合、フレームはクライアント側に送信されません。通常、このメカニズムは鉄レベルで実装され、ローカルバイアスと呼ばれます。私の以前の記事で、DFとマルチホーミングの一般的な選択のニュアンスについて読むことができます。



また、EVPNの疑いのない利点には、障害発生時に高速コンバージェンスを提供する前述のカジュアルメカニズム(一括撤回)、MACが片方の肩からしか見えない場合のサーバー側へのトラフィックの分散(エイリアシング)、拡張L3機能、エニーキャストGW、機能などがありますサービスを停止せずに仮想マシンを転送します。



コントローラを使用したVxLAN



別の動作モードは、コントローラからの制御です。このようなシナリオでは、VTEP構成はコントローラーのアドレスを指定するように削減され、ネイバーおよびその他の関連機能の検索はコントローラーによって実装されます。原理的にはどのように動作するかは誰もが理解していると思うので、実際にはこのモードを考慮しません。これをすべて実証するには、コントローラー自体を起動する必要があります。



書かれたすべてを要約します。 VxLANは、(マルチキャストがなくても)アンダーレイとして単純なIPネットワークを使用します。つまり、VTEPループバック間のIP接続がエンドツーエンドトンネルの役割を果たします。トンネリングプロトコルとして、udpはVxLANと組み合わせて使用​​され、オーバーレイネットワークを作成します。近隣検索は、手動(選択の構成で指定)または自動-マルチキャスト(VNIをマルチキャストグループにマッピング)およびEVPNを使用するか、専用コントローラーを使用して自動で実行できます。



元のL2パケットをVxLANにカプセル化してIPファクトリーを介して転送する方法を考え出した後、どのようなオーバーヘッドが発生するかを計算する必要があります。はい、考慮すべき重要な詳細を忘れていました。RFCには、フレームの受信時に元のvlanタグを削除する必要があり、タグのないフレームはすでにVxLANにパックされている必要があります。また、たとえばCisco NexusまたはJuniper QFXの場合、デフォルトで機能します。これは、rewrite-sおよびタグ変換をラップせずに、異なるVTEPで異なる数のVLANを使用できるようにするために行われます。つまり、大まかに言えば、vlanをスイッチに対してローカルにします。たとえば、VTEP Aでは、VNI 100はvlan 100に対応し、VTEP Bでは、VNI 100はvlan 200に対応します。この構成のVxLANトンネルは上昇しますが、vlanタグを削除しない場合、次に、VTEPの1つでVLANをブロードキャストしないと(たとえば、VTEP Bでは、200タグは受信時に100でブロードキャストされ、逆に100タグは200タグに転送されます)、何も機能しません。実際の部分では、同じVNIで、異なるVTEP上に異なるVLANがあることがわかります。

: , ( vlan-bundle VNI – – VxLAN -, VTEP , , .


したがって、次のヘッダーがあると考えています:



8バイト(VxLANヘッダー)+ 8バイト(UDPヘッダー)+ 20バイト(IPv4ヘッダー)+ 14バイト(外部L2ヘッダー)= 50バイト(クライアントタグを保存する場合は54)。



はい、どういうわけか、かなりのオーバーヘッド。しかし、ネットワークがジャンボフレームを使用する場合、このヘッダーはそれほど大きくありません。一方、NVGREを使用する場合、このテクノロジーにはかなり大きなオーバーヘッドがあります:4バイト(カプセル化後に残るクライアントタグ)+ 8バイト(GRE)+ 20バイト(IPv4)+ 14バイト(L2)= 46バイトまたはVPLS :4バイト(内部MPLSタグ)+ 4バイト(外部MPLSタグ)+ 14バイト(L2ヘッダー)= 22バイト(vlanタグ正規化の使用時またはクライアントタグの保存時は26バイト)。



















有名な映画で言われているように、FRRトリガーやBGP-LUタグなどは考慮しません。「それで、状態は悪化しません」。



いずれの場合でも、サーバーが64バイトのパケットを交換する場合、テクノロジーは素晴らしいものになりますが、4000〜9000バイトのサイズのパケットを使用する場合、すべてが見た目ほど怖くはありません。



その結果、従来のL2ネットワークと比較してVxLANの利点をリストします(使用するタイプに関係なく)



。1. STPファミリのプロトコルは不要です。

2.ノードまたはリンクに障害が発生した場合の高速収束。

3. L2ドメインの数の増加(4K対16M);

4.等価パス上のトラフィックバランシング(ECMP)。

5. L2は複数のサイトに拡張できます。

6.新しいvlanを追加するとき、すべてのスイッチを登ってそれらの上に目的のvlanをドラッグする必要はありません(tsiska構文のinfernal設定を忘れないでください-addキーワードのないスイッチポートトランク-そして、これに出会ったことはありません)設定はVTEPでのみ行われます。



実際問題として、これについて理論と結び付けて、今日から実践に移ります。



多くの人から、なぜ記事で常にJunOS構文のみを使用するのかと聞かれます。そして真実が理由です、私は思った。今日、私たちの研究室には、6月ではなく、Tsiskiすらありません。今日はアリスタを掘り下げますが、なぜですか?さて、Tsiskodzhunovのファンのために、この機器の設定が比較のために記事で紹介されます。

この記事に掲載されている画像はすべてクリック可能です。




実用的な部分



3つのテストすべてで、このようなトポロジを検討します。つまり、最も単純なクローゼトポロジ(1つのスパインと3つのリーフ)があります。このようなトポロジでは、ダンプを削除してトラフィック交換全体を確認するのが最も簡単な方法です(2つ目のスパインを追加するため、ECMPがあり、一度に2つのリンクでダンプを削除する必要があります)。スパインの側面から、lldpに3つのリーフすべてが表示されます。









Spine-1#show lldp neighbors Last table change time : 0:09:43 ago Number of table inserts : 3 Number of table deletes : 0 Number of table drops : 0 Number of table age-outs : 0 Port Neighbor Device ID Neighbor Port ID TTL Et1 Leaf-1 Ethernet1 120 Et2 Leaf-2 Ethernet1 120 Et3 Leaf-3 Ethernet1 120
      
      





通常の形式のIGP-ISIS / OSPF / EIGRPを開始しませんでした。BGPはこの目的に使用されました-eBGP ipv4セッションはスパインノードとリーフノードの間でストレッチされました。

 Spine-1#show ip bgp summary BGP summary information for VRF default Router identifier 62.0.0.10, local AS number 65000 Neighbor Status Codes: m - Under maintenance Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc 10.0.1.1 4 65001 14 16 0 0 00:09:23 Estab 3 3 10.0.2.1 4 65002 14 16 0 0 00:09:21 Estab 3 3 10.0.3.1 4 65003 14 16 0 0 00:09:19 Estab 3 3
      
      





BGPには、接続されているすべてのネットワークの再配布が含まれます(通常、VxLANが機能するにはループバックのみが必要ですが、後でルーティングをテストするためにすべてを発表しました)。 将来、構成を変更します-新しいアドレスファミリの追加、マルチキャストの起動など。各テストは上記のクリーントポロジから開始します(前のテストで作成されたすべての構成は削除されるため、実行内容と実行理由が明確になります。 )

さて、平凡なことから始めましょう:



静的(ユニキャスト)VxLAN





順番に行きましょう。 VLAN 100を作成し、サーバーへのインターフェイスで有効にします。

  vlan 100 name VNI-1 ! interface Ethernet5 description Server-1 switchport trunk allowed vlan 100 switchport mode trunk
      
      





ここで、vlan 100を何らかのvniに関連付ける必要があります(長い間考えないように、vni 100を選択しました-少なくとも1つ、少なくとも1600万を取得できます-問題ではありません)。 これを行うには、仮想インターフェイスvxlan1を作成します。

 interface Vxlan1 vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vlan 100 vni 100 vxlan vlan 100 flood vtep 62.0.0.2 62.0.0.3
      
      





vxlan 1は、VxLANトンネルを終端するように設計されたトンネルインターフェイスです。 シスコでは、同様のインターフェイスはnve(ネットワーク仮想化インターフェイス)と呼ばれ、Junosではvtepです(解読する必要はありませんが、考えてみてください)が、ご存じのとおり、名前には意味的な負荷しかありません-操作の原理はこれから変わりません。



vxlanインターフェイス構成では、どのvniがマッピングされているのかを示します。

 vxlan vlan 100 vni 100
      
      





この例では、vlan 100はVNI 100にあります。

静的なVxLANがあるため、すべてのリモートVTEPを指定する必要があります。これは、vxlanインターフェイス設定の最後の行で確認できます。

  vxlan vlan 100 flood vtep 62.0.0.2 62.0.0.3
      
      





この図は、Server-3の方向では、Vlan 300は使用されないが、Vlan 300が使用されることを示しています。したがって、Leaf-3の構成は多少異なります。

 vlan 300 name VNI-1 ! interface Ethernet5 description Server-1 switchport trunk allowed vlan 300 switchport mode trunk ! interface Vxlan1 vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vlan 300 vni 100 vxlan vlan 300 flood vtep 62.0.0.1 62.0.0.2
      
      





それだけです。 次に、すべてが巻き上げられていることを確認します。

現時点では、すべてが落ち着いています-転送テーブルにケシがないことで示されるように、ホスト間のトラフィック交換はありませんでした。

 Leaf-1#show mac address-table vlan 100 unicast Mac Address Table ------------------------------------------------------------------ Vlan Mac Address Type Ports Moves Last Move ---- ----------- ---- ----- ----- --------- Total Mac Addresses for this criterion: 0
      
      





すべてのvtepsは静的に登録されていますが:

 Leaf-1#show vxlan flood vtep VXLAN Flood VTEP Table -------------------------------------------------------------------------------- VLANS Ip Address ----------------------------- ------------------------------------------------ 100 62.0.0.2 62.0.0.3
      
      





交換はまだ行われていないため、スイッチはまだそれらを認識していません。

 Leaf-1#show vxlan vtep Remote VTEPS for Vxlan1: Total number of remote VTEPS: 0
      
      





ここでは、ベンダーによって動作が異なります。NexusまたはQFXは、IPでアクセス可能な場合、リモートVTEPが表示されることをすぐに示します。 Aristaは、交換が行われた後にのみ、リモートVTEPの存在を表示します。

合計で、私たちによって設定されたVNIに関するこのような要約情報があります(1つあります)。

 Leaf-1#show interfaces vxlan 1 Vxlan1 is up, line protocol is up (connected) Hardware is Vxlan Source interface is Loopback0 and is active with 62.0.0.1 Replication/Flood Mode is headend with Flood List Source: CLI Remote MAC learning via Datapath Static VLAN to VNI mapping is [100, 100] Note: All Dynamic VLANs used by VCS are internal VLANs. Use 'show vxlan vni' for details. Static VRF to VNI mapping is not configured Headend replication flood vtep list is: 100 62.0.0.3 62.0.0.2
      
      





この結論で実際に何が言えるでしょうか? vxlanトンネルのsorsとしてアドレス62.0.0.1のloopback0を使用します。フラッドフレームは、CLIで指定したリモートVTEPのリスト、vlan 100がVNI 100に静的にマップし、最後に設定したVTEPのリストに従って発生します。



Leaf-2では、すべてがほぼ同じです(ピアのリストのみが異なり、これは論理的です)。Leaf-3では、これまで見てきたように、結論を示します。 ご覧のように、リーフ3では、vlan 300は同じvni 100にマッピングされます。

 Leaf-3#show vxlan vni 100 VNI to VLAN Mapping for Vxlan1 VNI VLAN Source Interface 802.1Q Tag --------- ---------- ------------ --------------- ---------- 100 300 static Ethernet5 300 Note: * indicates a Dynamic VLAN
      
      





 Leaf-3#show interfaces vxlan 1 Vxlan1 is up, line protocol is up (connected) Hardware is Vxlan Source interface is Loopback0 and is active with 62.0.0.3 Replication/Flood Mode is headend with Flood List Source: CLI Remote MAC learning via Datapath Static VLAN to VNI mapping is [300, 100] Note: All Dynamic VLANs used by VCS are internal VLANs. Use 'show vxlan vni' for details. Static VRF to VNI mapping is not configured Headend replication flood vtep list is: 300 62.0.0.1 62.0.0.3
      
      





サーバー間でpingを実行し、回線が正常に起動するかどうかを確認します。

 bormoglotx@ToR> ping logical-system Server-1 source 100.0.0.1 100.0.0.2 rapid PING 100.0.0.2 (100.0.0.2): 56 data bytes !!!!! --- 100.0.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 59.807/119.973/338.390/109.381 ms
      
      





 bormoglotx@ToR> ping logical-system Server-1 source 100.0.0.1 100.0.0.3 rapid PING 100.0.0.3 (100.0.0.3): 56 data bytes !!!!! --- 100.0.0.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 64.941/89.089/157.432/35.149 ms
      
      





Pingパス-トンネルを介した接続があります。 スイッチのMACアドレステーブルを見てみましょう。

 Leaf-1#show vxlan address-table dynamic vlan 100 Vxlan Mac Address Table ---------------------------------------------------------------------- VLAN Mac Address Type Prt VTEP Moves Last Move ---- ----------- ---- --- ---- ----- --------- 100 0005.8671.1e02 DYNAMIC Vx1 62.0.0.2 1 0:00:36 ago 100 0005.8671.1e03 DYNAMIC Vx1 62.0.0.3 1 0:00:32 ago Total Remote Mac Addresses for this criterion: 2
      
      





2つのMACアドレスは動的に学習され、トンネルインターフェイス、より正確には、リーフ2およびリーフ3へのVxLANトンネルを介して表示されます。

ポピーアドレスのテーブル自体は次のようになります。

 Leaf-1#show mac address-table vlan 100 unicast Mac Address Table ------------------------------------------------------------------ Vlan Mac Address Type Ports Moves Last Move ---- ----------- ---- ----- ----- --------- 100 0005.8671.1e01 DYNAMIC Et5 1 0:00:54 ago 100 0005.8671.1e02 DYNAMIC Vx1 1 0:00:54 ago 100 0005.8671.1e03 DYNAMIC Vx1 1 0:00:50 ago Total Mac Addresses for this criterion: 3
      
      





どちらの場合も、タイマーが表示されます。 一定時間(デフォルトでは非アクティブの300秒)後、ポピーは削除されます-ここではすべてが標準です。



トラフィック交換が行われた後、Leaf-1は2つの隣接ノードを検出しました。

 Leaf-1#show vxlan vtep Remote VTEPS for Vxlan1: 62.0.0.2 62.0.0.3 Total number of remote VTEPS: 2
      
      





しかし、リーフ3(およびリーフ2)は、1つのネイバーのみを認識します。

 Leaf-3#show vxlan vtep Remote VTEPS for Vxlan1: 62.0.0.1 Total number of remote VTEPS: 1
      
      





サーバー2と3の間でトラフィック交換が行われなかったため、これは論理的で正常です。



次に、Leaf-1とSpine-1の間のリンクのダンプを削除したときの外観を見てみましょう。

交換全体は次のとおりです。



最初に、サーバーはARP要求を生成し、スイッチはそれをすべてのリモートVTEPに送信する必要があります。 前に確認したように、ユニキャストによるパッケージのさらなる配布により、発信ノードで複製が行われます。







これらのサーバーの1つは、受信したパケットを単にドロップします。これは、この要求が宛先ではないため、2番目のサーバーが安全に応答するためです。



その後、両方のサーバーは互いのMACアドレスを認識し、トラフィックの交換を開始できます。この場合はICMPです。



次に、VRRPを使用して外部ネットワークにアクセスするためのゲートウェイを作成します。

 Leaf-1#show running-config interfaces vlan 100 interface Vlan100 ip address 100.0.0.252/24 vrrp 100 priority 128 vrrp 100 authentication text vlan100 vrrp 100 ip 100.0.0.254
      
      





 Leaf-2#show running-config interfaces vlan 100 interface Vlan100 ip address 100.0.0.253/24 vrrp 100 priority 64 vrrp 100 authentication text vlan100 vrrp 100 ip 100.0.0.254
      
      





 Leaf-1#show vrrp group 100 interface vlan 100 Vlan100 - Group 100 VRF is default VRRP Version 2 State is Master Virtual IPv4 address is 100.0.0.254 Virtual MAC address is 0000.5e00.0164 Mac Address Advertisement interval is 30s VRRP Advertisement interval is 1s Preemption is enabled Preemption delay is 0s Preemption reload delay is 0s Priority is 128 Authentication text, string "vlan100" Master Router is 100.0.0.252 (local), priority is 128 Master Advertisement interval is 1s Skew time is 0.500s Master Down interval is 3.500s
      
      





次に、ゲートウェイに対してサーバーping 3を実行します。

 bormoglotx@ToR> ping logical-system Server-3 source 100.0.0.3 100.0.0.254 rapid PING 100.0.0.254 (100.0.0.254): 56 data bytes !!!!! --- 100.0.0.254 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 56.915/75.978/134.126/29.286 ms
      
      





ゲートウェイが利用可能です。 grtにvlanインターフェイスがあるため、BGPを介してこのアドレスをアナウンスすることにより、他のネットワークに到達できます。たとえば、独自のリーフ3のループバックです。

 bormoglotx@ToR> ping logical-system Server-3 source 100.0.0.3 62.0.0.3 rapid PING 62.0.0.3 (62.0.0.3): 56 data bytes !!!!! --- 62.0.0.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 93.210/111.745/138.930/16.970 ms
      
      





このシナリオでのトラフィックパスは次のとおりです。デフォルトルートによるサーバーからのパケットは、リーフ3に到達します。 ポピーは宛先アドレスとして指定されているゲートウェイアドレスであるため、Leaf-3はVxLANトンネルを介してLeaf-1に到達し、このトンネルを通過するパケットはLeaf-1に送信されます。 次に、Leaf-1はパケットのカプセル化を解除し、宛先アドレスが62.0.0.3であることがわかります。これは、bgpを介してgrtで認識されるルートです。 次に、パケットはリーフ3にルーティングされます。 Leaf-3ループバックからの応答も同じ方法で返されます。



ご覧のとおり、VxLANテクノロジー、特に-Static(ユニキャスト)VxLANは、フェルトブーツと同じくらいシンプルで、カラシニコフ突撃ライフルのように信頼性が高くなっています。 さて、実際に破るために何がありますか?



例として、シスコとジュニパーの構成を紹介します。



Cisco Nexusでは、すべてが多かれ少なかれAristaの構成に似ています-いずれの場合でも、アプローチは同じです。

nveインターフェイス(vxlanのアナログ)を作成します。望ましいインターフェイスはvlanです。

 vlan 100 name VNI-100 vn-segment 100
      
      





 interface nve1 no shutdown source-interface loopback0 member vni 100 ingress-replication protocol static peer-ip 62.0.0.2 peer-ip 62.0.0.3
      
      





次に、このVLANをクライアントに向けて解決し、すべての準備が整いました。 当然、これはNexusなので、必要な機能を含めることを忘れないでください:

 interface Ethernet1/2 description Server-1 | LS-3 switchport mode trunk switchport trunk allowed vlan 100
      
      





 feature bgp feature vn-segment-vlan-based feature lldp feature nv overlay
      
      







ジュニパーQFXでは、すべてが少し異なります(それはジュニパーです)。 スイッチオプション階層で、VxLANトンネルのsorsとリモートVTEPのアドレスを指定します。

 switch-options { vtep-source-interface lo0.0; remote-vtep-list [ 62.0.0.2 62.0.0.3 ]; }
      
      





 vlans { VLAN400 { vlan-id 400; vxlan { vni 16000100; ingress-node-replication; } } }
      
      





次に、このVLANをクライアントに向けて解決し、すべての準備が整いました。



私たちはそれを理解したと思います。 2番目のオプションに移りましょう。マルチキャストを使用して、ネイバーを自動的に検索し、BUMトラフィックを複製します。



マルチキャストVxLAN



ご想像のとおり、最初にPIMを実行する必要があります。 この機能を実行するにはトポロジ内の理想的な場所があるため、RPとしてSpineを使用します。 静的RPを見せびらかすことはせず、スパインは1つしかありません。



 ip pim rp-address 62.0.0.10 ! interface Ethernet1 ip pim sparse-mode
      
      





最初のテストで行った構成全体を削除したので、目的のVLAN(Leaf-1 / 2で100 VLAN、Leaf-3で300 VLAN)を再度作成し、サーバー側に許可する必要があります(構成は表示しません) 、あなたはすでに彼を見た)。

次に、vxlanインターフェイスを作成します。

 interface Vxlan1 vxlan multicast-group 230.0.0.100 vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vlan 100 vni 100
      
      





前回同様、vlan 100はvni 100に対応します(Leaf-3では、vlan 300はvni 100に対応します)。 次に、vni 100をmgroup 230.0.0.100に関連付ける必要があります。 結果のチェーンは、vlan 100 >> vni 100 >>> mgroup 230.0.0.100です。



これが構成全体です。 構成が正常に機能することを確認します。 すべての葉のある近所がRPに登ったかどうかを見てみましょう。

 Spine-1#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Mode 10.0.1.1 Ethernet1 00:03:53 00:01:20 sparse 10.0.2.1 Ethernet2 00:03:55 00:01:19 sparse 10.0.3.1 Ethernet3 00:03:52 00:01:21 sparse
      
      





素晴らしい、ニューボーが見えます。 vxlanの概要情報を確認します。

 Leaf-1#show interfaces vxlan 1 Vxlan1 is up, line protocol is up (connected) Hardware is Vxlan Source interface is Loopback0 and is active with 62.0.0.1 Replication/Flood Mode is multicast Remote MAC learning via Datapath Static VLAN to VNI mapping is [100, 100] Note: All Dynamic VLANs used by VCS are internal VLANs. Use 'show vxlan vni' for details. Static VRF to VNI mapping is not configured Multicast group address is 230.0.0.100
      
      





指定されたレプリケーションとフラッドの方法が既にあります-マルチキャスト、および削除されたすべてのVTEPをリストするシートの代わりに-マルチキャストグループのみ。 Leaf-3の場合、すべてが同様であり、VLAN番号に合わせて調整されます。

 Leaf-3#show vxlan vtep Remote VTEPS for Vxlan1: Total number of remote VTEPS: 0 Leaf-3#show interfaces vxlan 1 Vxlan1 is up, line protocol is up (connected) Hardware is Vxlan Source interface is Loopback0 and is active with 62.0.0.3 Replication/Flood Mode is multicast Remote MAC learning via Datapath Static VLAN to VNI mapping is [300, 100] Note: All Dynamic VLANs used by VCS are internal VLANs. Use 'show vxlan vni' for details. Static VRF to VNI mapping is not configured Multicast group address is 230.0.0.100
      
      





ルールに従ってVxLANがマルチキャストでどのように機能するかをすでに知っているため、vxlanインターフェイスを設定し、vlan << >> VNIアソシエーションを追加した後、リーフはグループ230.0.0.100に参加する必要があります。

 Leaf-1#show ip mroute PIM Bidirectional Mode Multicast Routing Table RPF route: U - From unicast routing table M - From multicast routing table PIM Sparse Mode Multicast Routing Table Flags: E - Entry forwarding on the RPT, J - Joining to the SPT R - RPT bit is set, S - SPT bit is set, L - Source is attached W - Wildcard entry, X - External component interest I - SG Include Join alert rcvd, P - (*,G) Programmed in hardware H - Joining SPT due to policy, D - Joining SPT due to protocol Z - Entry marked for deletion, C - Learned from a DR via a register A - Learned via Anycast RP Router, M - Learned via MSDP N - May notify MSDP, K - Keepalive timer not running T - Switching Incoming Interface, B - Learned via Border Router RPF route: U - From unicast routing table M - From multicast routing table 230.0.0.100 0.0.0.0, 0:00:05, RP 62.0.0.10, flags: W Incoming interface: Ethernet1 RPF route: [U] 62.0.0.10/32 [200/0] via 10.0.1.0 Outgoing interface list: Loopback0
      
      





エントリ(*、G)が表示されます。つまり、Leaf-1はマルチキャストグループ230.0.0.100からトラフィックを受信することを望んでおり、誰がこのグループのソースになるかは関係ありません。 トラフィック交換がなかったため、スイッチの転送テーブルにもポピーはありません。

 Leaf-1#show vxlan address-table Vxlan Mac Address Table ---------------------------------------------------------------------- VLAN Mac Address Type Prt VTEP Moves Last Move ---- ----------- ---- --- ---- ----- --------- Total Remote Mac Addresses for this criterion: 0
      
      





既知のリモートVTEPがないため、次のようになります。

 Leaf-1#show vxlan vtep Remote VTEPS for Vxlan1: Total number of remote VTEPS: 0
      
      





サーバー間でpingを実行し、接続自体の事実を確認し、それに応じて、VTEPテーブル内のポピーの存在を確認します。

 bormoglotx@ToR> ping logical-system Server-1 100.0.0.2 rapid PING 100.0.0.2 (100.0.0.2): 56 data bytes !!!!! --- 100.0.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 57.521/69.366/82.147/10.469 ms
      
      





 bormoglotx@ToR> ping logical-system Server-1 100.0.0.3 rapid PING 100.0.0.3 (100.0.0.3): 56 data bytes !!!!! --- 100.0.0.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 59.762/81.369/164.374/41.505 ms
      
      





接続性はありますが、以下の結論から判断すると、リーフ1は2つのリモートVTEPを見つけました。

 Leaf-1#show vxlan vtep Remote VTEPS for Vxlan1: 62.0.0.2 62.0.0.3 Total number of remote VTEPS: 2
      
      





サーバー2および3のアドレスがvxlanトンネルを介して表示されるのは論理的です。

 Leaf-1#show vxlan address-table vlan 100 Vxlan Mac Address Table ---------------------------------------------------------------------- VLAN Mac Address Type Prt VTEP Moves Last Move ---- ----------- ---- --- ---- ----- --------- 100 0005.8671.1e02 DYNAMIC Vx1 62.0.0.2 1 0:00:47 ago 100 0005.8671.1e03 DYNAMIC Vx1 62.0.0.3 1 0:00:41 ago Total Remote Mac Addresses for this criterion: 2
      
      





しかし、前のテストでは上記のすべてがすでに見られたようです。違いはどこですか? さらに違い。 リーフ1はグループ230.0.0.100のアドレスにトラフィックを送信したため、このスイッチがこのグループのソースになったことがわかります。

 Spine-1#show ip pim upstream joins Neighbor address: 10.0.1.1 Via interface: Ethernet1 (10.0.1.0) Group: 230.0.0.100 Joins: 62.0.0.1/32 SPT Prunes: No prunes included
      
      





次に、リーフ3に移動して、このスイッチがリッスンするグループを確認します。

 Leaf-3#show ip mroute PIM Bidirectional Mode Multicast Routing Table RPF route: U - From unicast routing table M - From multicast routing table PIM Sparse Mode Multicast Routing Table Flags: E - Entry forwarding on the RPT, J - Joining to the SPT R - RPT bit is set, S - SPT bit is set, L - Source is attached W - Wildcard entry, X - External component interest I - SG Include Join alert rcvd, P - (*,G) Programmed in hardware H - Joining SPT due to policy, D - Joining SPT due to protocol Z - Entry marked for deletion, C - Learned from a DR via a register A - Learned via Anycast RP Router, M - Learned via MSDP N - May notify MSDP, K - Keepalive timer not running T - Switching Incoming Interface, B - Learned via Border Router RPF route: U - From unicast routing table M - From multicast routing table 230.0.0.100 0.0.0.0, 0:03:48, RP 62.0.0.10, flags: W Incoming interface: Ethernet1 RPF route: [U] 62.0.0.10/32 [200/0] via 10.0.3.0 Outgoing interface list: Loopback0 62.0.0.1, 0:01:50, flags: S Incoming interface: Ethernet1 RPF route: [U] 62.0.0.1/32 [200/0] via 10.0.3.0 Outgoing interface list: Loopback0
      
      





ここでは、以前のタイプ(*、G)のレコードが表示されています(スイッチがグループ230.0.0.100をリッスンしていること、およびソースが誰であるかはわかりません)。 しかし、2番目のエントリはすでにフォーム(S、G)を持っています。これは、スイッチがアドレスsors 62.0.0.1でグループ230.0.0.100をリッスンしていることを示しています。



ダンプを見て、交換全体を見てみましょう。いわば、ライブです。



全体の交換は、最初の場合と少し異なります。 最初に、メッセージがマルチキャストグループアドレスに送信されます。



ダンプでは、PIM RegisterおよびRegister-stopメッセージが明確に表示されます。つまり、マルチキャストは最も純粋な形式で動作します。



次に、リモートサーバーからの応答が表示されますが、すでにユニキャストです。



それでは、トラフィック交換が続きます。



次に、図に別のサーバーを追加します-サーバー-4、リーフ-3に接続し、VNI 200に配置します。

Leaf-3の構成は少し変更されています。

 Leaf-3(config-if-Vx1)#show active interface Vxlan1 vxlan multicast-group 230.0.0.100 vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vlan 200 vni 200 vxlan vlan 300 vni 100
      
      





両方のVNIが同じマルチキャストグループを使用することに注意してください。



VxLANインターフェイスの情報を確認すると、2つのVNIがあることがわかります。

 Leaf-3#show interfaces vxlan 1 Vxlan1 is up, line protocol is up (connected) Hardware is Vxlan Source interface is Loopback0 and is active with 62.0.0.3 Replication/Flood Mode is multicast Remote MAC learning via Datapath Static VLAN to VNI mapping is [200, 200] [300, 100] Note: All Dynamic VLANs used by VCS are internal VLANs. Use 'show vxlan vni' for details. Static VRF to VNI mapping is not configured Multicast group address is 230.0.0.100
      
      





Vlan 200はVNI 200にマップされ、Vlan 300はVNI 100にマップされます。これらは同じポートを参照します。

 Leaf-3#show vxlan vni VNI to VLAN Mapping for Vxlan1 VNI VLAN Source Interface 802.1Q Tag --------- ---------- ------------ --------------- ---------- 100 300 static Ethernet5 300 200 200 static Ethernet5 200 Note: * indicates a Dynamic VLAN
      
      





次に、L3インターフェイスを作成します。 Leaf-1 / 2では、vrrpを使用してvlan 100インターフェイスを作成し(前のテストのように構成を再度提供しません)、Leaf-3ではVNI 200のゲートを作成します。

 Leaf-3#show running-config interfaces vlan 200 interface Vlan200 ip address 200.0.0.254/24 Leaf-3#show vlan id 200 VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 200 VNI-200 active Cpu, Et5, Vx1
      
      





その結果、スキームは次の形式を取得しました。



VNI間のルーティングが機能するかどうかを確認しましょう。

 bormoglotx@ToR> ping logical-system Server-4 source 200.0.0.3 100.0.0.3 PING 100.0.0.3 (100.0.0.3): 56 data bytes 64 bytes from 100.0.0.3: icmp_seq=0 ttl=61 time=155.736 ms 64 bytes from 100.0.0.3: icmp_seq=1 ttl=61 time=117.702 ms 64 bytes from 100.0.0.3: icmp_seq=2 ttl=61 time=120.800 ms 64 bytes from 100.0.0.3: icmp_seq=3 ttl=61 time=127.033 ms ^C --- 100.0.0.3 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 117.702/130.318/155.736/15.055 ms
      
      





現時点のトラフィックパスは次のようになっています。Server-3から、トラフィックはデフォルトルートで、デフォルトゲートウェイアドレスを持つMacへのルート3を経由して飛行します。 パケットを受信したスイッチは、パケットのカプセル化を解除し、(インターフェイスで)自分宛であることを確認すると、IPルックアップが発生します。 ホスト100.0.0.3はネットワーク100.0.0.0/24に存在するため、宛先ネットワークはそこで終了するため、トラフィックはリーフ1に送信されます(VRRPマスターはリーフ1に存在します)。 Spineを介したIPネットワークでは、パケットはLeaf-1に到達します。 IPパケット(VxLANではなく純粋なIP)を受信したスイッチは、宛先アドレスを見て、VxLANトンネルを介してリーフ3に到達していることを認識します。 パケットはVxLANにカプセル化され、リーフ3に送信されます。 リーフ3は、パケットを受信し、カプセル化を解除し、宛先アドレスが100.0.0.3であることを確認します。これは、eth5インターフェイスを介して接続され、バンにタグを掛けてサーバー側に送信します。 これはルーティングが失敗したため、同じインターフェイス上にある2つのサーバーがIPファクトリ全体を介して通信しているためです。



シスコとジュニパーの同様のサービスの構成例については、前のセクションと同様に:

ネクサスでは、すべてが再びアリスタのようです。 また、目的のVLANを作成し、VNIに関連付けます。

 vlan 100 name VNI-16000100 vn-segment 16000100
      
      





また、nveインターフェイスで、vniに接続するマルチキャストグループを指定します

 interface nve1 no shutdown source-interface loopback0 overlay-encapsulation vxlan member vni 16000100 mcast-group 225.0.0.100
      
      





当然、PIM機能を有効にし、目的のインターフェイスで直接PIM自体を有効にします。 次に、vlanがクライアントに向けて登録され、すべてが開始されます。

 interface Ethernet1/2 description Server-1 | LS-3 switchport mode trunk switchport trunk allowed vlan 100
      
      







Juniper QFXでは、最初に目的のインターフェイス(Lo0を含む)でpimを有効にし、一部のFPC(PIMが機能するために必要)でトンネルサービスを有効にする必要があります。

 pim { rp { static { address 62.0.0.10; } } interface xe-0/0/1.0 { mode sparse; } interface lo0.0 { mode sparse; } interface xe-0/0/2.0 { mode sparse;
      
      





 chassis { fpc 0 { pic 0 { tunnel-services { bandwidth 40g; } } } }
      
      





さらに、構成は次のようになります。

 {master:0}[edit] bormoglotx@LEAF-101# show switch-options vtep-source-interface lo0.0;
      
      





 {master:0}[edit] bormoglotx@LEAF-101# show vlans BRIDGE-4093 { vlan-id 4093; vxlan { vni 4093; multicast-group 230.0.40.93; } }
      
      





次に、このVLANをクライアントに向けて解決します。



私たちもそれを理解したと思うので、先に進みます。



EVPN / VxLAN



以前の構成を忘れて、もう一度やり直します。



VLAN 100を作成し、サーバーへのインターフェイスで有効にします。

 Leaf-1#show running-config section vlan 100 vlan 100 name VNI-1 ! interface Ethernet5 description Server-1 switchport trunk allowed vlan 100 switchport mode trunk
      
      





ここでvxlanインターフェイスを再度作成しますが、vxlnaトンネルの発信インターフェイスのみを指定する必要があり(通常これはループバックの1つです)、vlan 100をvni 100に関連付けます。

 interface Vxlan1 vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vlan 100 vni 100
      
      





次に、bgpに移動します。 拡張コミュニティを転送する機能を追加し、evpnアドレスファミリを有効にして、Spine-1であるneuborを追加します。

 router bgp 65001 neighbor 10.0.1.0 remote-as 65000 neighbor 10.0.1.0 description Spine-1 neighbor 10.0.1.0 soft-reconfiguration inbound all neighbor 10.0.1.0 send-community extended neighbor 10.0.1.0 maximum-routes 100 redistribute connected ! vlan 100 rd 65001:100 route-target import 65002:100 route-target import 65003:100 route-target export 65001:100 redistribute learned ! address-family evpn neighbor 10.0.1.0 activate ! address-family ipv4 neighbor 10.0.1.0 activate
      
      





ループバック(ibgp / ebgpマルチホップ)でevpnセッションを発生させることは可能ですが、ebgpを使用しているため、セッションを発生させる場所に違いはありません。スパインへのリンクをドロップすると、すべてが停止します。 2つのスパインがある場合、トラフィックは2番目のスパインに完全に切り替わります。さらに、2つのアドレスファミリを持つ1つのセッションしかありません。これにより、セッションの数が減ります(トラブルシューティングと悪用が間違いなく容易になります)。



VLAN階層は、通常のbgp設定から除外されます。この構成セクションは、evpnインスタンス(EVI)を作成します。ここではすべてがシンプルです-rd(クライアントが交差するvlan番号を使用できるように)、rtを指定し、明確にするために各VTEPのコミュニティを作成しました。したがって、インポート用の2つのコミュニティがあります。1つはLeaf-2からのルートを受け入れ、もう1つはLeaf-3からのルートを受け入れます。redistribute learnコマンドは、スイッチがデータプレーンを介してポピーを認識するとすぐに、bgpを介してそれを通知するという事実に責任があります。同様に、L3インターフェイスの再配布を有効にする必要があります。しかし、これはすでにアリスタの仕様です。たとえば、ジュニパーネットワークスはそのようなコマンドを必要としません。



これで設定が完了しました。他のノードでは、vni 100のMaple Leaf-3のvlan 300を除き、構成は同じです。



最後に設定したことを確認しましょう:

 Leaf-1#show interfaces vxlan 1 Vxlan1 is up, line protocol is up (connected) Hardware is Vxlan Source interface is Loopback0 and is active with 62.0.0.1 Replication/Flood Mode is headend with Flood List Source: EVPN Remote MAC learning via EVPN Static VLAN to VNI mapping is [100, 100] Note: All Dynamic VLANs used by VCS are internal VLANs. Use 'show vxlan vni' for details. Static VRF to VNI mapping is not configured Headend replication flood vtep list is: 100 62.0.0.3 62.0.0.2
      
      





ここではすべてが論理的であり、ソースはアドレス62.0.0.1のloopback0です。レプリケーションとフラッドでは、EVPNを使用してコンパイルされたノードのリストを使用します。Vlan 100は、VNI 100に静的にマッピングされます。最後に、EVPNを使用してコンパイルされたリモートVTEPの同じリストが表示されます。リモートVTEPのリストで同じアドレスを確認できます。

 Leaf-1#show vxlan vtep Remote VTEPS for Vxlan1: 62.0.0.2 62.0.0.3 Total number of remote VTEPS: 2
      
      





スイッチは、Leaf-2 / 3がVxLANドメイン内のネイバーであることをどのように知るのですか?これには、タイプ3のEVPNルートが使用されます。

 Leaf-1#show bgp evpn route-type ? auto-discovery Filter by Ethernet Auto-Discovery (AD) route (Type 1) ethernet-segment Filter by Ethernet Segment Route (Type 4) imet Filter by Inclusive Multicast Ethernet Tag Route (Type 3) <<<< mac-ip Filter by MAC/IP advertisement route (Type 2)
      
      





1つのルートはローカルです。私たち自身がそれを生成し、他の2つはリモートVTEPからの包括的マルチキャストイーサネットタグルートです。

 Leaf-1#show bgp evpn route-type imet BGP routing table information for VRF default Router identifier 62.0.0.1, local AS number 65001 Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP S - Stale, c - Contributing to ECMP, b - backup % - Pending BGP convergence Origin codes: i - IGP, e - EGP, ? - incomplete AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 65001:100 imet 62.0.0.1 - - - 0 i * > RD: 65002:100 imet 62.0.0.2 62.0.0.2 - 100 0 65000 65002 i * > RD: 65003:100 imet 62.0.0.3 62.0.0.3 - 100 0 65000 65003 i
      
      





いずれかのルートの詳細情報を見てみましょう。

 Leaf-1#show bgp evpn route-type imet vni 100 next-hop 62.0.0.2 detail BGP routing table information for VRF default Router identifier 62.0.0.1, local AS number 65001 BGP routing table entry for imet 62.0.0.2, Route Distinguisher: 65002:100 Paths: 1 available 65000 65002 62.0.0.2 from 10.0.1.0 (62.0.0.10) Origin IGP, metric -, localpref 100, weight 0, valid, external, best Extended Community: Route-Target-AS:65002:100 TunnelEncap:tunnelTypeVxlan VNI: 100
      
      





AS-PATH(オーバーレイとしてebgpを使用すると、ポップアップアドレスがどの自律で編成され、アドレスのアナウンスが通過したかを確認できます)、ネクストホッププロトコル(ebgpがあり、Spineがこれらのネクストホップを変更しないことを忘れないでください、そうでない場合はオプションBがあり、VxLANカプセル化(TunnelEncap:tunnelTypeVxlanが同じコミュニティです)を使用し、ルートがVNI 100に属していることを確認します。



今のところ、フレームをフラッディングする場所(自動的に構築したトンネルと関連するVNI)。これまでのところ、トラフィック交換は行われておらず、ポピーアドレステーブルは空です。

 Leaf-1#show mac address-table unicast vlan 100 Mac Address Table ------------------------------------------------------------------ Vlan Mac Address Type Ports Moves Last Move ---- ----------- ---- ----- ----- --------- Total Mac Addresses for this criterion: 0
      
      





pingを実行して接続を確認します。

 bormoglotx@ToR> ping logical-system Server-1 100.0.0.2 rapid PING 100.0.0.2 (100.0.0.2): 56 data bytes !!!!! --- 100.0.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 72.731/94.632/115.048/13.476 ms
      
      





 bormoglotx@ToR> ping logical-system Server-1 100.0.0.3 rapid PING 100.0.0.3 (100.0.0.3): 56 data bytes !!!!! --- 100.0.0.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 67.071/99.286/177.772/40.933 ms
      
      





すばらしい、トラフィックが流れています。次に、スイッチングテーブルの内容を確認します。

 Leaf-1#show mac address-table Mac Address Table ------------------------------------------------------------------ Vlan Mac Address Type Ports Moves Last Move ---- ----------- ---- ----- ----- --------- 100 0005.8671.9101 DYNAMIC Et5 1 0:00:36 ago 100 0005.8671.9102 DYNAMIC Vx1 1 0:00:35 ago 100 0005.8671.9103 DYNAMIC Vx1 1 0:00:19 ago Total Mac Addresses for this criterion: 3
      
      





3つのケシが現れ、そのうち2つがVxLANトンネルを通して見えます。これらのポピーが見えるトンネルを見てみましょう:

 Leaf-1#show vxlan address-table Vxlan Mac Address Table ---------------------------------------------------------------------- VLAN Mac Address Type Prt VTEP Moves Last Move ---- ----------- ---- --- ---- ----- --------- 100 0005.8671.9102 EVPN Vx1 62.0.0.2 1 0:01:03 ago 100 0005.8671.9103 EVPN Vx1 62.0.0.3 1 0:00:48 ago Total Remote Mac Addresses for this criterion: 2
      
      





すべてが論理的でシンプルです。ただし、EVPNがあるため、ポピーアドレスのアナウンスが必要です。bgpでわかっていることを見てみましょう。

 Leaf-1#show bgp evpn route-type mac-ip BGP routing table information for VRF default Router identifier 62.0.0.1, local AS number 65001 Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP S - Stale, c - Contributing to ECMP, b - backup % - Pending BGP convergence Origin codes: i - IGP, e - EGP, ? - incomplete AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 65001:100 mac-ip 0005.8671.9101 - - - 0 i * > RD: 65001:100 mac-ip 0005.8671.9101 100.0.0.1 - - - 0 i * > RD: 65002:100 mac-ip 0005.8671.9102 62.0.0.2 - 100 0 65000 65002 i * > RD: 65003:100 mac-ip 0005.8671.9103 62.0.0.3 - 100 0 65000 65003 i
      
      





2つのルートはローカルです-ASパスから理解することは難しくありません。2つはリモートノードから受信されます。



トラフィック交換ダンプをもう一度見てみましょう:しかし、すべてが機能する前に、VTEPはIMルートを交換する必要があります。これらのメッセージは、BGPセッションの確立直後(または構成でVN​​Iをオンにした後)に送信されるため、提示されたダンプには表示されません。理解するために、これらのメッセージの1 つがどのように見えるかを示します。メッセージでは、VNI 100があることがわかります(ダンプにラベル6が表示される理由を思い出してください)。また、レプリケーションはノード62.0.0.1で発生し、トンネリングには使用する必要がありますVxLAN











次に、サーバー間のトラフィックの交換に直接戻ります。ここでは、静的VxLANの場合と同様に、発信ノードでレプリケーションが発生するため、すべてが最初のケースとほぼ同じです(マルチキャストがある場合、レプリケーションに使用できることを思い出してください):次に、ARP要求への応答が表示されます:ただし、これに加えて、BGPアップグレードメッセージがダンプに表示されます。前に書いたように、スイッチがデータプレーンを通じて何らかのMACアドレスを学習した場合、このMACアドレスを示すBGPメッセージを生成します。















これらのルートは3つすべてのスイッチ上にあるため、3つのスイッチすべてに、表に示されているホストのポピーがあります。つまり、最後の2つのケースでは、ポピーの調査はデータプレーンでのみ行われました。覚えている場合、Server-1ノードとServer-2およびServer-3の間でトラフィックを交換したとき、Leaf-2およびLeaf-3スイッチのみがありました。 1つのリモートポピーは、Leaf-1の背後にあるサーバーポピーです。サーバー2と3の間には交換がなかったため、お互いのポピーも知りませんでした。将来、サーバー2がパケットをサーバー3に送信したい場合、リーフ2はサーバー3の存在場所を知らないため、トラフィックはブロードキャストを通過します。EVPNでは、リーフ2とリーフ3には、これらのポピーをBGP経由で受信するためのブーティーが既にあります。



シスコとジュニパーで同様のサービスを設定する例:



Cisco NexusでVLANを作成し、任意のVNIに関連付けます。

 vlan 100 name VNI-100 vn-segment 100
      
      





次に、nveインターフェイスを作成し、BGP(ホスト到達可能性プロトコルbgp)のシグナリングに使用するものを示します。

 interface nve1 no shutdown source-interface loopback0 host-reachability protocol bgp member vni 100 ingress-replication protocol bgp
      
      





イングレス複製プロトコルbgp行は、複製方法について説明しています。この場合、BGPを介して受信したVTEPデータに基づいて、発信ノードで複製が行われます。

次に、evpnインスタンス(EVI)を作成します。

 evpn vni 100 l2 rd 65001:100 route-target import 65001:100 route-target import 65002:100 route-target import 65003:100 route-target export 65001:100
      
      





さて、今度はクライアントに向けて目的のVLANを解決し、作業を確認します。



Juniper QFXでは、構成は次のようになります(bgp設定は表示されません)





 {master:0} bormoglotx@LEAF-101> show configuration vlans BRIDGE-4093 { vlan-id 4093; vxlan { vni 15000001; ingress-node-replication; } } BRIDGE-4094 { vlan-id 4094; vxlan { vni 16000001; ingress-node-replication; } }
      
      





スイッチオプションの構成:

 {master:0} bormoglotx@LEAF-101> show configuration switch-options vtep-source-interface lo0.0; route-distinguisher 62.0.0.101:1; vrf-import VNI-IMPORT; vrf-target export target:42000:9999;
      
      





この構成では、リモートVTEPからルートを受信するRDとRT、およびESIごとに生成されたタイプ1ルートでハングするRTを指定します。



インポートに使用されるポリシーの内容:

 bormoglotx@LEAF-101> show configuration policy-options policy-statement VNI-IMPORT term DC-DEFAULT { from { protocol bgp; community DC-DEFAULT-SW; } then accept; } term VNI-16000001 { from { protocol bgp; community VNI16000001; } then accept; } term VNI-15000001 { from { protocol bgp; community VNI15000001; } then accept; } then reject;
      
      





さて、もちろんevpnプロトコルの構成:

 {master:0} bormoglotx@LEAF-101> show configuration protocols evpn encapsulation vxlan; extended-vni-list [ 15000001 16000001 ]; multicast-mode ingress-replication; vni-options { vni 15000001 { vrf-target export target:1500:1; } vni 16000001 { vrf-target export target:1600:1; } }
      
      





この階層では、各VNIに対応するrtと、許可されるVNIを示します。



次に、目的のVLANをクライアント側に解決し、パフォーマンスを確認します。



そして、この前向きなメモで、おそらくこの記事を終了します。次の記事では、独自のテクノロジーであるArista MLAGおよびNexus vPCの例を使用してEVPN / VxLANマルチホームを解析し、Juniper QFXの例を使用してEVPNを使用したマルチホームを試みます。



ご質問/追加/説明がある場合-電報で私に書いてください。ご清聴ありがとうございました。



All Articles