🧘🏻 😛 🆑 EVPNマルチホーミング ✴️ 🎶 ☄️

EVPNの記事で、マルチホーミングについて触れました。このトピックは多くの人々にとって興味深いものであったため、今日の前回の記事の続きでは、EVPNマルチホーミングとは何か、どのように機能するかを検討します。

EVPNマルチホーミングは、シングルアクティブとアクティブアクティブの2つのモードで動作します。本日は主に、より複雑で興味深いオプションであるアクティブ-アクティブに焦点を当てます。これは、シングル-アクティブが本質的にアクティブ-アクティブの非常に単純化されたバージョンだからです。

この記事は、EVPNの一般的な知識（作業の基本原則、VPLSとの違いなど）を既に持っている人を対象としています。そうしないと、記事の内容を理解することが難しくなります。

注：vMXを使用してEVE-NGで実験台を組み立てました：Pルーターとスイッチが5台のLinuxマシンの最終ホストとしてPEルーターvMX 16.1のようなvMXバージョン14.1を実行する方法。私がラップトップで収集した最後のラボとは異なり、このラボではリソースが非常に必要です。実際、vMX 16.1は2つの仮想マシンで実行され、合計4つのCPUと8GBのRAMを必要とします。そのため、この記事で紹介するラボにはサーバー上に約35 GBのRAMが必要ですが、稼働状態ではラボ全体で23 GBを少し超えるRAMを使用したことに注意してください（このラボを急に自宅に設置したい場合は、この点に留意する必要があります）。

このトポロジを検討します。

構成では、vlan対応の方法、つまり仮想スイッチを使用します。この方法は、少なくとも私にとって最も柔軟で興味深いものです。 3つのEVPNインスタンス（EVPNインスタンスのEVI）が各PEルーター上に作成され、その構成は3つすべてのPEでほぼ同じです。違いはRD、RT、およびVlan番号のみです。 EVPNマルチホーミングの機能の一部を明確に示すためにのみ、他に2つのインスタンスが追加されています。

EVPNインスタンスの構成は次のとおりです。

bormoglotx@RZN-PE-1> show configuration routing-instances vSwitch-eVPN-1 instance-type virtual-switch; interface ae3.777; route-distinguisher 62.0.0.1:1; vrf-target target:42000:1; protocols { evpn { extended-vlan-list 777; } } bridge-domains { BRIDGE-777 { vlan-id 777; } }

複雑なことはありません。タイプが仮想スイッチのRT、RD、およびvlan-id 777のブリッジドメインが1つだけのインスタンス。同じvlanがevpn protocol vlanの拡張リストにリストされます。テストには、他に何も必要ありません。

それでは、インターフェースの構成に移りましょう。 RZN-PE-3では、すべてがシンプルで洗練されています。

 bormoglotx@RZN-PE-3> show configuration interfaces ae0 description "RZN-SW-3 | ae0"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; aggregated-ether-options { lacp { active; periodic fast; } } unit 777 { description eVPN-1; encapsulation vlan-bridge; family bridge { interface-mode trunk; vlan-id-list 777; } }

777 VLANのみが許可されるトランクインターフェイスとして機能する単純な集合体。

ただし、PEデータはRZN-SW-1にマルチホームされるため、PE1およびPE2では、構成はPE3とは多少異なります。

 bormoglotx@RZN-PE-1> show configuration interfaces ae3 description "RZN-SW-1 | ge-0/0/0 | ae3<<>>ae0 "; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; esi { 00:00:00:00:00:00:00:00:00:01; all-active; } aggregated-ether-options { lacp { active; periodic fast; system-id 02:00:00:00:00:01; } } unit 777 { description eVPN-1; encapsulation vlan-bridge; family bridge { interface-mode trunk; vlan-id-list 777; } }

ここでは、登場したESI識別子に興味があります。忘れた人（または知らなかった人）を思い出させてください-この識別子は手動で割り当てる必要があります（MC-LAGを使用する場合は自動的に生成できます）。同じセグメントに接続されているすべてのインターフェイスでは、この識別子は同じでなければなりません。

注：ここで示されているsystem-idの目的については、記事の最後で説明します。

この例では、単純な識別子00：00：00：00：00：00：00：00：00：01を選択しました。その値は私たちにとって大きな役割を果たさないため、主なことは予約された値（すべてゼロおよびすべてのユニット）、および他のセグメントですでに設定されているESI値の値と交差しませんでした。つまり、大まかに言えば、ESIはEVPNが起動されるネットワーク全体で一意でなければなりません。非マルチホーミングセグメントの場合、この識別子は何の役割も果たさず、自動的に0に設定されます。当然、非マルチホーミングPEルーターであっても、リンク上でゼロ以外のESI値を処理および設定できますが、これは不必要なルートの生成を伴うだけです。つまり、実際には問題はありません。ただし、ハンドルによって設定されたこのESI値が、別のジョイントまたは他のジョイントで既に構成されているESIの値と一致する場合、問題が発生します。

EVPNには5つのタイプのルートがあります（前回はタイプ5を考慮していませんでしたが、このトピックについてはEVPN / VxLANの記事で取り上げます）。

タイプ2はMAC / IPルートです。このルートは、PEルーターに、ルートで指定された特定のMACアドレスにユニキャストパケットを送信する場所とラベルを伝えます。 L3VPNでのvpnv4プレフィックスのアナウンスに本質的に似ています。ルートには、ホストIPアドレスも含まれる場合があります。

タイプ3は、包括的マルチキャストルートです。このルートは、BUMトラフィックを送信する場所とラベルをPEルーターに伝えます。

タイプ1と4は、EVPNマルチホーミング機能を提供する主要なルートです。さらに検討します。

したがって、0番目の時点で、EVPNを開始するとすぐに、ルーターはタイプ3のルートを互いに送信し始め、BUMトラフィックを交換できるようになります。これは、マルチホーミングのないシナリオに当てはまります。セグメント内の2つのルーターが同じセグメントを見ているため、タイプ1と4のルートを取得します。なぜタイプ3のルートが必要なのか、すでに知っているはずなので、タイプ1と4のルートに注目します。

上で書いたように、EVPNを起動したばかりで、vSwitch-eVPN-1インスタンス転送テーブルにMACアドレスが存在しないことからわかるように、ホスト間でトラフィック交換は行われていません。

 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 brief Intfs IRB intfs MH MAC addresses Instance Total Up Total Up Nbrs ESIs Local Remote vSwitch-eVPN-1 1 1 0 0 2 1 0 0

提示された出力では、マルチホームセグメントがあることがわかります。このセグメントに関する情報を見つけるために、前のコマンドの広範な出力を検討します。

 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 extensive Instance: vSwitch-eVPN-1 Route Distinguisher: 62.0.0.1:1 Per-instance MAC route label: 299792 Per-instance multicast route label: 299776 MAC database status Local Remote MAC advertisements: 0 0 MAC+IP advertisements: 0 0 Default gateway MAC advertisements: 0 0 Number of local interfaces: 1 (1 up) Interface name ESI Mode Status ae3.777 00:00:00:00:00:00:00:00:00:01 all-active Up Number of IRB interfaces: 0 (0 up) Number of bridge domains: 1 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label 777 1 1 Extended Enabled 299776 Number of neighbors: 2 62.0.0.2 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 2 62.0.0.3 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 0 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by IFL ae3.777 Local interface: ae3.777, Status: Up/Forwarding Number of remote PEs connected: 1 Remote PE MAC label Aliasing label Mode 62.0.0.2 300208 300208 all-active Designated forwarder: 62.0.0.2 Backup forwarder: 62.0.0.1 Last designated forwarder update: May 07 06:59:19 Advertised MAC label: 300112 Advertised aliasing label: 300112 Advertised split horizon label: 302752

この結論は、EVPNインスタンスに関する完全な情報を提供します。一部のフィールドは既に明確になっているはずです。この結論によれば、ESI 00：00：00：00：00：00：00：00：00：01があり、アクティブ-アクティブモードで動作します：

 Number of local interfaces: 1 (1 up) Interface name ESI Mode Status ae3.777 00:00:00:00:00:00:00:00:00:01 all-active Up

以下は、このEVPNドメインに参加している各PEルーターの出力です。

  Number of neighbors: 2 62.0.0.2 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 2

RZN-PE-2からの上記の情報から判断すると、タイプ3の1つのルートとタイプ1の2つのルートを取得します。これは完全に真実ではありません。これらのルートに加えて、RZN-PE-2は別のタイプ4ルートを提供しますが、後でここに表示されない理由を確認します。

しかし、現時点でRZN-PE-3から取得できるタイプ3ルートは1つだけです。

 62.0.0.3 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 0

このPEルーターはマルチホームではないため、これは論理的なものであり、これまでに知る必要があるのはタイプ3のルートだけです。後で、ポピーを学習すると、このルーターはタイプ2アナウンスの送信を開始しますが、これまでのところ、ポピーは学習していません。デフォルトゲートウェイが構成されている場合、（インスタンスに追加されたirbインターフェイスの数に応じて）タイプ2のルートがまだあります。

EVIについて上記で説明した情報に加えて、出力は、ESI 00：00：00：00：00：00：00：00：00：01指定されたフォワーダーが選択され、エイリアスラベルが示されているセグメントについて：

  Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by IFL ae3.777 Local interface: ae3.777, Status: Up/Forwarding Number of remote PEs connected: 1 Remote PE MAC label Aliasing label Mode 62.0.0.2 300208 300208 all-active Designated forwarder: 62.0.0.2 Backup forwarder: 62.0.0.1

現時点では、結論の多くは明確ではありません。 EVPNマルチホーミングの原理を理解するには、少なくとも次の問題に対処する必要があります。

1.マルチホームPEルーターが、タイプ1および4の追加ルートのアナウンスを開始する理由は何ですか。

2. DFとは何であり、その選挙はどうですか。

3.タイプ1のルートがすでに2つある理由。

4.上記の出力のエイリアスラベルとは何ですか。

しかし、私はこれらと他のいくつかの質問にさらに答えようとします。

マルチホーミングの問題。

最初に、アクティブ/アクティブモードでマルチホーミングを有効にした場合に発生する問題の概要を説明します。当然、EVPNはまだL2VPNであるため、最も深刻な問題はループ（よく、またはループ）です。実際、この問題を解決すれば、テクノロジーは同じVPLSよりも優れていることになります。これは、オールアクティブモードでは動作方法がまったくわからないためです。すべてのマルチホームPEルーターがクライアントからポピーを学習するわけではないため、もう1つの重要な問題はトラフィックバランシングです。他の問題はそれほど重要ではありません。むしろ、他の問題があるとしましょう。しかし、それらの存在は技術を実行不可能にしません。

これらの問題がEVPNでどのように解決されるかを見てみましょう。

ファイティングループにはさまざまな対策があります。最初は、当然のことながらスプリットホライズンです。他のPEルーターから（つまり、カーネルから）受信したフレームは、カーネルに再度送信されません。ただし、ループが発生する可能性のあるネットワークの主な場所は、マルチホームCEスイッチを複数のPEルーターに接続することであるため、当然これは十分ではありません。このセグメントのループを排除するために、指定フォワーダーとスプリットホライズンラベルが使用されますが、最初に最初に行います。

DFとは何ですか、なぜ必要なのですか？

ループの最初のシナリオ：リモートPEルーターがCE BUMからトラフィック（たとえば、通常のarp要求）を受信し、他のすべてのPEに送信することを想像してください（これがPE3であると仮定します）。 2つのPEルーター（PE1とPE2）は同じセグメントを見て、両方がPE3からBUMトラフィックを受信するため、トラフィックの2つのコピーがこのセグメントに到着し、コアを含むすべてのネットワークをループし始めます。

EVPNでこの現象に対抗するために、各マルチホームセグメントに対して、指定フォワーダー（特定のVLAN内の特定のセグメントへのBUMトラフィックの転送を担当するノード）が選択されます。他のすべてのルーターは、セグメントにいくつ存在しても、ルーター/スイッチのCEにBUMトラフィックを送信する権利がありません（このVLANのこのESIで）。

DF選択アルゴリズム：

1.最初に、すべてのPEルーターは、指定されたセグメントに接続されているルーターの数と、そのアドレスが何であるか（ループバック）を理解する必要があります。

2.タイマーが期限切れになると（デフォルトは3秒）、DFの選択に参加しているすべてのPEルータのリストが形成され、最小アドレスから最大アドレスで終わります。アドレスのリストには0から番号が付けられます。

3.式V mod N = iに従って、特定のセグメントおよびVLANのDFが計算されます。

4. DFによって選択されたルーターは、CE側へのBUMトラフィックの送信を有効にし、他のすべての非DFルーターは、このVLANのこのセグメントのルーター/スイッチのCE側へのBUMトラフィックをブロックし続けます。

理論的には、すべてが単純ですが、順番に見てみましょう。

最初に、同じセグメント内に他の誰がリンクを持っているかをルーターがどのように理解するかという質問に答えます（そして、ルーターはありますか）。このために、タイプ4のルートがあります。このルートを見てみましょう。

 bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *4:6* vSwitch-eVPN-1.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

EVPNインスタンスのルーティングテーブルには、そのようなルートはありません。実際には、インスタンスで構成されたインポートに対応する拡張コミュニティを持つルートのみがこのテーブルに分類されます。たとえば、vSwitch-eVPN-1の場合：

 bormoglotx@RZN-PE-1> show configuration routing-instances vSwitch-eVPN-1 vrf-target target:42000:1;

タイプ4ルートには、インポート用に設定されたコミュニティとは異なるものがあることがわかります。これは、evpnのルートは、EVIごととESIごとの2つの方法で生成できるためです。

EVIごと -このルートは特定のインスタンスによって生成されます

ESIごと -このルートは、特定のインスタンスではなく、このESIにリンクを持つすべての接続のルーターによって生成されます。同じセグメントを複数のevpnインスタンスに含めることができます（たとえば、ae3.777インターフェイスがEVPN1インスタンスに追加され、ae3.778がEVPN2に追加されますが、これらは異なるユニットですが、ESIはインターフェイス全体に対して完全に構成されているため、データを意味しますインターフェイスは異なるEVIにありますが、同じESIになります。

EVIごとに生成されるルートには、これらのルートがアドバタイズされるネイティブRTおよびRDインスタンスが必要です（または、エクスポートポリシーによってさらにハングアップされる場合、つまり管理者が手動で追加する場合は、他のRT）。タイプ2および3のルートは常にEVIごとに生成されます。つまり、これらのルートがアナウンスされるルートには常にネイティブRDおよびRTインスタンスがあります。しかし、ESIごとに生成されたルートの場合、すべてはやや複雑であり、ルートのタイプに依存します。

ただし、タイプ4のルートを引き続き扱います。

このルートは常にESIごとに生成されます。このルートのRDは、ルーターID（指定されている場合）またはループバックアドレス（このルートはEVPNインスタンスのいずれにも適用されないため）からルーターによって自動的に生成されます。 RTも手動で指定されませんが、ESIから生成され、同じESIを持つルーターのみがこのルートをインポートします。そのため、記事の冒頭で先に検討した結論で、マルチホームネイバーがタイプ4のルートをアナウンスすることはわかりません。

注：一般に、RTにはESIビットの一部のみが使用され、RTの生成に使用される同じESIビットを持つすべてのPEがこのルートをインポートするため、これは完全に真実ではありません。

注：JunOSは、RDの2番目の部分のヌル値を使用して、ESIごとのルートのRDを生成します：62.0.0.1： 0 。

では、タイプ4ルートをどこで探すべきでしょうか？ JunOSにはいくつかのルーティングテーブルがあります。 EVPNルートは最初にbgp.evpn.0テーブルに分類され、そこからすでに他のルーティングテーブル（セカンダリテーブル）にインポートされています。したがって、このルートはbgp.evpn.0テーブルにあり、そこから__default_evpn __。Evpn.0テーブルにエクスポートされます。

 bormoglotx@RZN-PE-1> show route table __default_evpn__.evpn.0 match-prefix *4:6* __default_evpn__.evpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 4:62.0.0.1:0::01:62.0.0.1/304 ES *[EVPN/170] 02:57:15 Indirect 4:62.0.0.2:0::01:62.0.0.2/304 ES *[BGP/170] 02:57:16, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1

前述のとおり、RDはルーターによって自動的に生成されます。RZN-PE-1からのルートでは62.0.0.1:07（ルートはこのルーターに対してローカルであるため、間接的にネクストホップ）、RZN-PE-からのルートでは62.0.0.2:07 2。このPEルーターはマルチホームではないため、RZN-PE-3からのルートはありません。さらに、PE-3にはそのようなESIがないため、このルーターはこれらのルートをインポートしませんが、リフレクターはそれらを誠実に提供します。

 bormoglotx@RZN-PE-3> show route table __default_evpn__.evpn.0 bormoglotx@RZN-PE-3>

 bormoglotx@RZN-P-1> show route advertising-protocol bgp 62.0.0.3 | match 4:62 4:62.0.0.1:0::01:62.0.0.1/304 4:62.0.0.2:0::01:62.0.0.2/304

次に、このルートをより詳細に分析します。

 bormoglotx@RZN-PE-1> show route table __default_evpn__.evpn.0 match-prefix *4:6* next-hop 62.0.0.2 detail __default_evpn__.evpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) 4:62.0.0.2:0::01:62.0.0.2/304 ES (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.2:0 Next hop type: Indirect, Next hop index: 0 Address: 0xb1e55f0 Next-hop reference count: 20 Source: 62.0.0.100 Protocol next hop: 62.0.0.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 42000.62 Peer AS: 42000.62 Age: 2:58:04 Metric2: 1 Validation State: unverified Task: BGP_42000.62.62.0.0.100 Announcement bits (1): 0-__default_evpn__-evpn AS path: I (Originator) Cluster list: 62.0.0.100 Originator ID: 62.0.0.2 Communities: es-import-target:0-0-0-0-0-0 Import Accepted Localpref: 100 Router ID: 62.0.0.100 Primary Routing Table bgp.evpn.0

特に犯罪的なものはありません-ほとんどのフィールドはBGPルートに固有のものです。しかし、ここのコミュニティラインでは、通常、たとえばドメインID、オリジンまたはターゲットコミュニティを見ることに慣れています。全く異なるコミュニティがあります。

EVPNコミュニティ専用に予約されています。上で書いたように、このルートはESIごとに排他的に生成され、このルートを必要とするPEルータのみがそれを受信する必要があります。また、ルート送信者と同じESIにリンクがあるPEカメラにのみ必要です。したがって、このルートのコミュニティはESIに基づいて生成され、es-import-target：0-0-0-0-0-0-0という形式になります。

私たちのケースでは、すべてゼロであり、特にこのようなESIを使用して、このコミュニティには2番目の部分にのみゼロを含めることができることを示しています（最初の部分は予約されており、 RFCの読み取りに関心のある0x06（タイプ）と0x02（サブタイプ）に等しい）これはEVPNのパフォーマンスには影響しません。その結果、当社のラボネットワークでは、RZN-PE-1とRZN-PE-2のみがこのルートをインポートします。

そして、ESI自体はどこにあるのでしょうか？識別子はルート自体で直接指定されます：4：62.0.0.2：0 :: 01 ：62.0.0.2/304 ES、空のオクテット（ゼロ）のみが省略されます（ipv6など）。また、2つのルーターのリンクが異なるセグメントにあるかどうかを推測するのは難しくありませんが、それらの識別子は最初が00 ：00：00：00：00：00：00：00：00： 01であり、 10 ：00：00：00です。：00：00：00：00：00： 01 2番目の場合、ルートは両方のルーターによってインポートされます。コミュニティでは、初期フィルタリングのみが発生します。ルート自体は、ルートで指定されたESIが、このルートを受信したルーター自体のESIと一致する場合にのみ使用されます。一致しない場合、ルートはドロップされます。

ルーターは、それがマルチホームであることを認識するとすぐに（インターフェイス構成のESIのゼロ以外の値によってこれを理解します）、タイプ4のルートの送信を開始して、すべての隣接ルーターがネットワーク上の存在を認識します。

ルートがネットワーク上に散らばった後、RZN-PE-1とRZN-PE-2は、それらが同じESIに接続されていることを学習します。両方のルーターは、残りのPEルーターからのタイプ4ルートを3秒間待機し（デフォルト）、その後、タイプ4ルートから受信したルートに基づいて、このセグメントに接続されているすべてのノードのリストを作成し、すべてのノードでこのリストは同じになります私たちの場合はこれです：

62.0.0.1 i = 0

62.0.0.2 i = 1

その後、ルーターは式V mod N = iに従ってDFになる人の計算を開始します。ここで、Vはvlanの数、Nはセグメント内のPEルーターの数です。番号が計算の結果であり、このVLANのこのセグメントのDFになるPEルータ。ご存じのように、各VLANには独自のDFがあります。BUMトラフィックのバランスがとれています。

3つのEVPNインスタンスがラボで構成され、1つのVLANが各インスタンスに対応し、777、778、および779 VLANを使用しました。2つのマルチホームPEがあるため、ノードの数は2です。このセグメントでは777 VLANのDFを取得します779はRZN-PE-2を選択し、778-RZN-PE-1の場合は確認が簡単です。

 bormoglotx@RZN-PE-1> show configuration routing-instances | display set | match interface set routing-instances vSwitch-eVPN-1 interface ae3.777 set routing-instances vSwitch-eVPN-2 interface ae3.778 set routing-instances vSwitch-eVPN-3 interface ae3.779

 bormoglotx@RZN-PE-1> show configuration interfaces ae3 | display set | match vlan-id set interfaces ae3 unit 777 family bridge vlan-id-list 777 set interfaces ae3 unit 778 family bridge vlan-id-list 778 set interfaces ae3 unit 779 family bridge vlan-id-list 779

 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 designated-forwarder Instance: vSwitch-eVPN-1 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Designated forwarder: 62.0.0.2

 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-2 designated-forwarder Instance: vSwitch-eVPN-2 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Designated forwarder: 62.0.0.1

 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-3 designated-forwarder Instance: vSwitch-eVPN-3 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Designated forwarder: 62.0.0.2

このスキームには長所と短所があります。最も明らかなマイナスは、DF選択メカニズム自体です。 ESI Xへのリンクを持つセグメントに新しいルーターが表示されるか、ESI Xへのリンクがルーター上で落ちる/復元されるとすぐに、DFはこのセグメントに対して再計算されます。さらに、最悪の状況は、DFルーター上のESI Xの方向のリンクの損失です。残りのルーターは、デバイスのCE側へのBUMトラフィックの送信をブロックするため、DFドロップを検出し、新しいDFを計算するために、BUMトラフィックは、現時点ではすべてが非DFであるため、セグメントのすべてのPEルーターによってドロップされます。しかし、新しいDF選択手順を説明するRFCドラフトがあります。しかし、これまでのところ、すべてが説明どおりに機能しています。

vlan対応の方法とvlan-bundleの方法のDFの選択はわずかに異なることに注意してください。仮想スイッチは複数のブリッジドメインを終了できるため、この場合のDFの選択は各VLANに対して個別に行われるのではなく、すべてのvlaneに対して同時に行われ、計算では設定された最小のVLAN番号が使用されます。たとえば、仮想スイッチに30.778と779を追加しますが、最小数のVLANを基準にすると、このセグメントのDFはPE1-62.0.0.1になることが簡単に計算できます。

 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 extensive | match "domain|extended|forwarder" Number of bridge domains: 4 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label 30 1 1 Extended Enabled 300384 777 1 1 irb.1 Extended Enabled 300384 778 1 1 Extended Enabled 300384 779 1 1 Extended Enabled 300384 Designated forwarder: 62.0.0.1 Backup forwarder: 62.0.0.2 Last designated forwarder update: May 24 08:12:13

30番目のVLANを削除します。現在、最小のVLAN番号は777です。つまり、DFはPE2-62.0.0.2になります。

  bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 extensive | match "domain|extended|forwarder" Number of bridge domains: 4 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label 777 1 1 irb.1 Extended Enabled 300384 778 1 1 Extended Enabled 300384 779 1 1 Extended Enabled 300384 Designated forwarder: 62.0.0.2 Backup forwarder: 62.0.0.1 Last designated forwarder update: May 24 08:14:52

: , Backup forwarder Backup Designated forwarder (BDF). BDF non-DF . EVPN ( OSPF DR BDR) — DF , non-DF BDF. DF.

これで、タイプ4のルートが必要な理由とその外観がわかりました。

しかし、DFを選択した場合、1つのタイプのループのみを獲得しました。ただし、CEルーターがルーターの非DF側へのトラフィックの送信を開始すると、ループが発生する可能性があります。たとえば、RZN-PE-1が非DFの場合、RZN-SW-1からBUMトラフィックを受信します。ループを取得します。CEからBUMトラフィックを受信したRZN-PE-1は、このトラフィックを他のPEに送信します。 -RZN-PE-2を含むshk。このセグメントのDFであるRZN-PE-2は、良心の閃きを伴わずに、RZN-SW-1にトラフィックを送り返します。結果はループでした。

そして、ループはトラフィックを中断しませんが、前後に飛行します。

これを回避するには、ESIごとに生成されたタイプ1ルートが必要です。

しかし、タイプ4のルートとは異なり、少なくともESIごとに生成されるタイプ1のルートは、EVIごとに、このルートに関心のあるインスタンスまたは複数のインスタンスのネイティブコミュニティを示します（そして、その理由は後でわかります）：

 bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *1:6* vSwitch-eVPN-1.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:62.0.0.1:1::01::0/304 AD/EVI *[EVPN/170] 1d 00:09:01 Indirect 1:62.0.0.2:0::01::FFFF:FFFF/304 AD/ESI *[BGP/170] 03:20:10, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1 1:62.0.0.2:1::01::0/304 AD/EVI *[BGP/170] 1d 00:09:01, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1

タイプ1のESIごとのルートが必要なのはなぜですか？

タイプ1ルートにはいくつかの機能があります。

タイプ1のESIごとに生成されたルートには、スプリットホライズンラベルと呼ばれるmplsラベルを指定する拡張コミュニティが含まれます。

 bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *FFFF* detail vSwitch-eVPN-1.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) 1:62.0.0.2:0::01::FFFF:FFFF/304 AD/ESI (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.2:0 Next hop type: Indirect, Next hop index: 0 Address: 0xb1e55f0 Next-hop reference count: 20 Source: 62.0.0.100 Protocol next hop: 62.0.0.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 42000.62 Peer AS: 42000.62 Age: 3:20:48 Metric2: 1 Validation State: unverified Task: BGP_42000.62.62.0.0.100 Announcement bits (1): 0-vSwitch-eVPN-1-evpn AS path: I (Originator) Cluster list: 62.0.0.100 Originator ID: 62.0.0.2 Communities: target:42000:1 target:42000:2 target:42000:3 esi-label:all-active (label 302656) Import Accepted Localpref: 100 Router ID: 62.0.0.100 Primary Routing Table bgp.evpn.0

ラベルは次の行にあります。

 Communities: target:42000:1 target:42000:2 target:42000:3 esi-label:all-active (label 302656)

これは、上記のループを打ち負かすのにどのように役立ちますか？これで、DFルーターにBUMトラフィックを送信する非DFルーターは、このコミュニティで指定されたラベルをラベルスタックに追加します。つまり、次の図を取得します。PEルーターは、ESI Xを持つセグメントからBUMトラフィックを受信しました。これは非DFルーターです。 ESI Xにリンクがある他のPEルーターを含む、EVPNドメイン内の他のすべてのPEにこのトラフィックを転送する必要があります。トラフィックは通常どおりすべてのPEルーターに送信されます。IMタグを使用しますが、ルーターはDFです。 ESI Xセグメントの場合、ルーターは最初にスプリットホライズンラベルを配置し、次にIMラベルを配置します。これは、このパケットがESI Xから来たことをDFルーターに示し、このセグメントに送り返す必要はありません。論理的パケットがDFルーター側に送信される場合にのみこのラベルを追加する必要があります。非DFルーターはこのトラフィックをESI Xセグメントに送信しないためです。

ルーターのDF側からは、次のように

なります：ルーターがIMタグとS = 1のパケットを受信した場合（つまり、タグの一番下が考慮され、このタグがスタックの最後である場合）、ルーターはこのEVPNで接続されているすべてのCEスイッチ/ルーターにパケットを送信しますインスタンス。

ルータがIMタグとS = 0のパケットを受信した場合（つまり、このタグがスタックの最後ではない場合）、トップタグが削除され、2番目のmplsルックアップが実行されます。 2回目の検索を行うと、ルーターはS = 1のSplit Horizonラベルを確認します。これに基づいて、ルーターはすべてのCEルーター/スイッチの方向にパケットをフラッディングします。ただし、トラフィックの受信元と同じセグメントにあるものを除きます。

問題が発生します。なぜこのルートはESIごとに生成されますが、タイプ4のルートとは異なり、ネイティブコミュニティインスタンス（または、この場合のように、いくつかのインスタンス）がありますか？事実は、このルートにはスプリットホライズンラベルだけが含まれているわけではありません。コミュニティのesi-label：all-active（ラベル302656）に注目すると、セグメントタイプがall-activeまたはsingle-activeとして指定されていることがわかります。この情報は、PEによってトラフィックのバランスをとることができるかどうかを理解するために他のPEに必要ですが（後で詳しく説明します）、エイリアスラベルを使用する方法もあります。

このルートのもう1つの重要な機能は、迅速な収束を保証することです。たとえば、リンクはCEデバイスに向かって落ちました。このリンクはすべて、追加されたすべてのインスタンスで落ちたというのが論理的です。つまり、このセグメントに対してPEによってアナウンスされたすべてのルートをキャンセルする必要があります。つまり、ルーターは撤回メッセージの送信を開始し、このESIへのリンクがあったすべてのインスタンスからアナウンスされたMAC / IPルートをキャンセルする必要があります。無効です。そして、そのようなルートが数千ある場合は？したがって、withdrawメッセージのヒープを送信する代わりに、ルーターはタイプ1ルートをキャンセルします。これにより、他のすべてのPEルーターは、このPEルーターを介してこのセグメントにアクセスできなくなったことを認識します。これはMAC Mass Withdrawと呼ばれます。特に障害が発生したインターフェイスの背後に数千のMACアドレスがある場合、ルータは1000の代わりに1つのメッセージを迅速に処理するのが簡単であり、これにより収束時間が大幅に短縮されます。

シナリオでこのルートにネイティブコミュニティがある理由は明らかだと思います：PE3にはESI 00：00：00：00：00：00：00：00：00：01がなく、コミュニティが生成された場合、ルートに関してはタイプ4の場合、PE-3はコミュニティをチェックしてこのルートを単純にドロップします。

注：ESIごとに生成されたタイプ1のルートに気づいた場合、タグの代わりにすべてのユニットが示されます：1：62.0.0.2：0 :: 01 :: FFFF：FFFF / 304 AD / ESI。これはジュニパーの気まぐれではなく、すべてがRFCに準拠しています。タイプ1ルートでは、ESIごとに生成される場合、可能な最大値はtag-idフィールドに示される必要があり（このフィールドには32ビットが割り当てられます）、mplsラベルは0に設定されます

したがって、EVPNはループを回避し、迅速な収束の可能性を提供します。しかし、結論の冒頭で思い出すと、近隣ルーターが2つのタイプ1ルートを私たちにアナウンスしていることがわかりました。そのため、タイプ1ルートもEVIごとに生成できます。

EVIごとに生成されるタイプ1ルートが必要なのはなぜですか？

 bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0* vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:62.0.0.1:1::01::0/304 AD/EVI *[EVPN/170] 1d 00:20:59 Indirect 1:62.0.0.2:1::01::0/304 AD/EVI *[BGP/170] 1d 00:20:59, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1

このルートは、エイリアシングラベルをアナウンスするために使用されます。

 bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0* detail next-hop 62.0.0.2 vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 1:62.0.0.2:1::01::0/304 AD/EVI (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.2:1 Next hop type: Indirect, Next hop index: 0 Address: 0xb1e55f0 Next-hop reference count: 20 Source: 62.0.0.100 Protocol next hop: 62.0.0.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 42000.62 Peer AS: 42000.62 Age: 1d 0:20:26 Metric2: 1 Validation State: unverified Task: BGP_42000.62.62.0.0.100 Announcement bits (1): 0-vSwitch-eVPN-1-evpn AS path: I (Originator) Cluster list: 62.0.0.100 Originator ID: 62.0.0.2 Communities: target:42000:1 Import Accepted Route Label: 300208 Localpref: 100 Router ID: 62.0.0.100 Primary Routing Table bgp.evpn.0

ルートラベル：300208はエイリアスラベルであり、タイプ2ルートで指定されたサービスラベルとともに、トラフィックの転送に使用できます。タイプ2ルートからのサービスラベルを既に持っているのに、なぜこのラベルが必要なのですか？事実は、すべて同じEVPNがL2VPNサービスを提供するということです。つまり、クライアントはルーターとしてではなくスイッチとして、実績のあるハードウェアで私たちに接続します。また、クライアントからのPEルーターがデータプレーンを介してMACアドレスを学習したことを思い出してください。つまり、マルチホームCEがPEルーターの1つにのみパケットを送信する状況は理論的には可能です（理由は異なる場合があります-機器自体のバグからバランシングアルゴリズムまで）。したがって、1台のルーターのみがルーター/スイッチのCEからMACアドレスを学習し、MAC / IPアナウンスを送信します。

転送テーブルを見ると、RZN-PE-2（現時点では777 vlanのDF）の一部のMACがデータプレーンで調べられていることがわかります（矢印で示されているアドレスに注意してください）。

 bormoglotx@RZN-PE-2> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 DC 1048585 1048585 00:05:86:71:87:f0 D ae3.777 00:50:79:66:68:0c D ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0d D ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0e D ae3.777

当時、RZN-PE-1上の上記のMACは、データプレーンでは調査されていませんでした。

 bormoglotx@RZN-PE-1> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 DC 1048586 1048586 00:05:86:71:87:f0 D ae3.777 00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0e D ae3.777

何が得られますか？RZN-PE-2のみがRZN-SW-1のホストのMACアドレスを学習し、このケシを含むMAC / IPルート（この場合は2つのルートも含む）を送信すると、状況が判明しました。RZN-PE-3の転送テーブルを見ると、コントロールプレーンを介して学習したこれらすべてのポピーが表示されます。

 bormoglotx@RZN-PE-3> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 D ae0.777 00:05:86:71:87:f0 DC 1048580 1048580 00:50:79:66:68:0c DC 1048580 1048580 <<<<<<<<<<<<<< 00:50:79:66:68:0d DC 1048580 1048580 <<<<<<<<<<<<<< 00:50:79:66:68:0e DC 1048580 1048580

しかし、RZN-PE-3で得られるものを見ると、RZN-PE-1とRZN-PE-2を含むルートが非対称になっていることが明らかです。RZN-PE-1で発表されたルートは次のとおりです。

 bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.1 vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.1:1::777::00:05:86:71:87:f0/304 MAC/IP *[BGP/170] 00:07:34, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299824 2:62.0.0.1:1::777::00:50:79:66:68:0e/304 MAC/IP *[BGP/170] 00:01:25, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299824

そして、ここにRZN-PE-2によって発表されたルートがあります：

 bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.2 vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.2:1::777::00:05:86:71:87:f0/304 MAC/IP *[BGP/170] 00:07:36, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840 2:62.0.0.2:1::777::00:50:79:66:68:0c/304 MAC/IP <<<<<<<<<<<<<< *[BGP/170] 00:01:32, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840 2:62.0.0.2:1::777::00:50:79:66:68:0d/304 MAC/IP <<<<<<<<<<<<<< *[BGP/170] 00:01:36, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840 2:62.0.0.2:1::777::00:50:79:66:68:0e/304 MAC/IP *[BGP/170] 00:01:27, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840

ご覧のとおり、2つのポピーはRZN-PE-2を介してのみ表示されます。 RZN-PE-3に犯罪者がいない場合、RZN-PE-1はこのMACでRZN-PE-2からルートも受信します。 RZN-PE-1は、RZN-PE-2を介してこれらのホストにトラフィックを送信する必要があることがわかりました。しかし、EVPN開発者がこのような単純でありふれた間違いを省いたと考えるのは愚かでしょう。タイプ2（MAC / IP）ルートには、このMACアドレスが属するESIが含まれます。 RZN-PE-1はタイプ2ルートを受信し、直接接続されているセグメントを通してMACが見えることを確認します。したがって、RZN-PE-1はネクストホップトンネルをRZN-PE-2の方向に、物理リンクをESIの方向に配置します。

 bormoglotx@RZN-PE-1> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 DC 1048586 1048586 00:05:86:71:87:f0 D ae3.777 00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0e D ae3.777

MACアドレスはae3.777論理インターフェイスを介して表示され、ポピーはリモートPEからコントロールプレーンを介して動的に学習されたことをフラグが示していることが、転送テーブルで確認できます。その結果、RZN-PE-1はデータプレーンを介してこのMACアドレスを学習しなかったにもかかわらず、直接リンクでRZN-SW-1にトラフィックを転送します。

しかし、別の質問が生じます-RZN-PE-3でこのMACがRZN-PE-2を介してのみ表示される場合、RZN-PE-1は指定されたMACアドレスを持つMAC / IPルートをアナウンスしなかったため、RZN-PE-3はなぜRZN-PE-1を介して特定のポピーアドレスにパケットを送信しますか？これがエイリアスラベルの出番です。

RZN-PE-3は、（ESIごとに生成されたタイプ1ルートから）RZN-PE-1とRZN-PE-2が同じセグメントに接続され、Active-Activeモードで動作することを知っています。この場合、バランスを取るために、RZN-PE-3はサービスラベルとして機能するエイリアスラベルを使用できます。その結果、RZN-PE-3は、タイプ2ルートで指定されたラベルを使用して、RZN-SW-1の背後にあるホスト宛てのトラフィックを送信できます。また、サービスの代わりにエイリアシングラベルを使用して、RZN-PE-1タイプ1ルート

で示されるラベルRZN-PE-3で見られるように、各インスタンスのマルチホームネイバーごとにエイリアシングラベルが示されます。

 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048580 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.1 300112 300112 all-active 62.0.0.2 300208 300208 all-active

 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-2 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048583 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.1 0 302240 all-active 62.0.0.2 0 302272 all-active

 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-3 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048588 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.2 0 302624 all-active 62.0.0.1 0 302560 all-active

mpls.0テーブルでは、このラベルにはIngress-Aliasingというラベルが付いています。

 bormoglotx@RZN-PE-1> show route table mpls.0 label 302560 mpls.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 302560 *[EVPN/7] 03:49:28, routing-instance vSwitch-eVPN-3, route-type Ingress-Aliasing to table vSwitch-eVPN-3.evpn-mac.0

Juniper機器は、EVIごとにMAC / IPルートのポピーアドレスのラベルを生成します（つまり、インスタンス全体に1つ）。そして最も興味深いのは、エイリアシングラベルがmac-labelとまったく同じになることです。これは、以下の出力から確認できます。

 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048580 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.1 300112 300112 all-active 62.0.0.2 300208 300208 all-active

ご覧のとおり、MACラベル=エイリアスラベル。JunOSがMACアドレスのラベルをEVIごとに生成するという事実は、次の結論を証明しています。

 bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 next-hop 62.0.0.1 match-prefix *2:6* detail | match label Route Label: 300112 Route Label: 300112 Route Label: 300112 Route Label: 300112

タイプ2の4つのルートがRZN-PE-1でアナウンスされ、すべて同じラベルが付けられています。しかし、質問が発生します。エイリアスラベルがmacラベルと等しい場合、なぜエイリアスラベルを発表する必要があるのでしょうか。実際、これはジュニパーの機器の特徴であり、他のベンダー（Cisco、Brocade、Huawei、ALu）はこの問題に対して異なるビジョンを持ち、タグを異なる方法で生成する可能性があります。

エイリアスタグを使用するときに問題があるかどうかを推定しましょう。この状況を考慮してください。 RZN-PE-3ルーターは、RZN-PE-1およびRZN-PE-2からタイプ1 EVIごとのルートを受信し、両方のルーターへのエイリアシングラベルを認識します。ただし、ESIごとのタイプ1からRZN-PE-3へのルートはまだありません。 RZN-PE-3がエイリアシングラベルを使用してトラフィックのバランスを取り始めると、たとえば、マルチホームルーターがシングルアクティブモードで動作し、パッシブノードに送信されたトラフィックの一部が単純にドロップする場合が発生する可能性があります。つまり、理論的には、RZN-PE-3はトラフィックのバランスを取り始めることができますが、実際にはこれを実行できるかどうかはわかりません。になる方法この状況でのルーターの動作は、RFCによって明確に規制されています。ルーターは、マルチホーミングモードを示すESIごとに生成されたタイプ1ルートを受信するまで、タイプ1 EVIごとのルートで受信したエイリアシングラベルを使用してこのセグメントにトラフィックを送信しないでください。

このタグは、シングルアクティブスクリプトで通知できます。この場合、マルチホームPEカメラでトラフィックのバランスを取るために使用されるのではなく、メインショルダーが落ちたときに自動的にアクティブになる転送テーブルへのバックアップパスを設定するために使用されます。

EVPNにMC-LAGが必要ですか？

LAGを使用してマルチホームCEをPEカメラに接続するスキームを検討しました。さらに、PEルーターの場合、バドルに追加される物理インターフェイスは1つだけですが、CE側からは1つのLAGがあり、そのインターフェイスは両方のPEシェクの側面に追加されます。つまり、何らかの種類のMC-LAGエミュレーション、スイッチは同じプロバイダーノードに接続されていると判断し、バンドルの両方のメンバーのトラフィックを分散します。設定の観点からは、次のようになります

。RZN-SW-1の側から、1つのLAGインターフェイスを設定します。

 bormoglotx@RZN-SW-1> show configuration interfaces ae0 description "LAG to RZN-PE-1/2 | ae0<<>>ae3"; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; aggregated-ether-options { lacp { active; periodic fast;

両方のPEルーターへのリンクが追加されます。

 bormoglotx@RZN-SW-1> show configuration interfaces ge-0/0/0 description "RZN-PE-1 | ae1<<>>ae3"; gigether-options { 802.3ad ae0; } bormoglotx@RZN-SW-1> show configuration interfaces ge-0/0/1 description "RZN-PE-2 | ae2<<>>ae3"; gigether-options { 802.3ad ae0; }

PEルーター側では、このようなシナリオでMC-LAGを構成する必要がありますが、EVPN / MPLSなしで行います。PEでは、CEへのLAGを収集し、CEへのPEシェックのMACアドレスが同じになるように同じシステムIDを指定します（そうでない場合、CEスイッチはMACフラッピングを検出します）。

 bormoglotx@RZN-PE-1> show configuration interfaces ae3 description "RZN-SW-1 | ge-0/0/0 | ae3<<>>ae0 "; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; esi { 00:00:00:00:00:00:00:00:00:01; all-active; } aggregated-ether-options { lacp { active; periodic fast; system-id 02:00:00:00:00:01;

 bormoglotx@RZN-PE-2> show configuration interfaces ae3 description "RZN-SW-1 | ae3<<>>ae0 | MC-LAG with RZN-PE-2"; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; esi { 00:00:00:00:00:00:00:00:00:01; all-active; } aggregated-ether-options { lacp { active; periodic fast; system-id 02:00:00:00:00:01;

これで、バンドルのステータスを確認できます。

RZN-SW-1の側面から：

 bormoglotx@RZN-SW-1> show lacp interfaces ae0 Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/0/0 Current Fast periodic Collecting distributing ge-0/0/1 Current Fast periodic Collecting distributing

PEルーターの側面から：

 bormoglotx@RZN-PE-1> show lacp interfaces ae3 Aggregated interface: ae3 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/4 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/4 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/0/4 Current Fast periodic Collecting distributing

 bormoglotx@RZN-PE-2> show lacp interfaces ae3 Aggregated interface: ae3 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/4 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/4 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/0/4 Current Fast periodic Collecting distributing

PEルーター側には単純に物理インターフェイスがありますが、CE側には単純な静的LAG（LACPなし）が存在する可能性があります。

2番目の接続オプションは、すべての結果（ICCP、ICL）を伴う標準MC-LAGを介したものです。最初のオプションが2番目のオプションよりもはるかに単純であることを否定することは困難です。また、MC-LAGが他のサービス用に不可欠であるか、すでに構成されている場合を除き、特に、すべてアクティブモードのMC-LAGにもICLが必要な場合は、個人的にEVPN / MPLSおよびMC-LAGを使用する理由はありません今それを破る）。

MC-LAGを使用したEVPNの利点には、EVPNに加えて、このジャンクションで冗長性を備えた他のサービスも実装できるという事実が含まれます（たとえば、バックアップサイトを備えたVPLSまたはバックアップノイバーを備えたL2CKT-すべてのハードウェアがEVPNをサポートしているわけではありません）。ただし、マイナスの点では、通常、MC-LAGは2つのニューブに制限されていることを区別できます（EVPNマルチホーミングは、アクティブ/アクティブモードで2つ以上のPEシェックをサポートします）。 PE間のリンクの必要性、テクノロジー自体（MC-LAGを意味する）の妥当性、そしておそらく構成の増加分をマイナスとして追加できます。

その結果、EVPNには完全なマルチホーミング機能が含まれており、VPLSの制限を回避することができます。EVPN Active-Activeマルチホーミングの唯一の問題は、クライアントからのトラフィックのシェーピングに関する問題です。クライアントが100Mbpsでバンドを購入し、インターフェイスに50Mbosを設定した場合、通常の操作中に必要な合計バンドを取得しますが、肩の1つが外れるとすぐに、クライアントは2倍の速度を切るのであなたに不平を言う権利があります回。しかし、Active-Activeを使用したL2VPNマルチホーミングを顧客が要求する頻度はどれくらいですか？

おそらく、この記事で説明したかったのはこれだけです。

ご清聴ありがとうございました。

EVPNマルチホーミング

マルチホーミングの問題。

DFとは何ですか、なぜ必要なのですか？

タイプ1のESIごとのルートが必要なのはなぜですか？

EVIごとに生成されるタイプ1ルートが必要なのはなぜですか？

EVPNにMC-LAGが必要ですか？

More articles: