Clever Geek Handbook

最もベテランのためのネットワーク。 マイクロ問題番号7。 EVPN





前のリリースから覚えているように、linkmeupプロバイダーはTier 2ステージに立っていました。 しかし、Linkmeupは、単にインターネットアクセスサービスまたはL2 / 3VPN（基本的にトラフィックのパイプ）を提供することに満足していません。 現在、クラウドストレージサービスは大きな需要があるため、linkmeupはリャザンに経済的な理由で位置する独自のデータセンターをいくつか取得しています。 この点で、私たちは新しいタスクに直面しました-データセンターを相互に接続し、顧客に当社の自動車販売店にある企業のストレージへのアクセスを提供する方法ですか？ MPLSはすでにコアネットワークで実行されているため、EVPN / MPLSを選択しました。 検討します。



このテクノロジーは、仮想L2ネットワークを介してデータセンターを結合する既存の方法の問題を解決します。 もちろん、この技術は他の種類のものではありませんが、これまでのところ、所有権の性質上、他の技術は考慮しません。 常に未来に目を向ける必要があります。今日はジュニパーMXのみでネットワークを構築しますが、プロバイダーとして、明日はASR9Kが2つないことを確信できません。 おそらく、EVPNで使用されているソリューションのいくつかは、複雑すぎて理解できないように思えます。 しかし、このテクノロジーが発明された理由、それが解決する問題、異なる方法で実装できるかどうかを忘れてはなりません。 名前には「micro-issue」という単語が含まれていますが、この記事が小さくてシンプルになるとは思わないでください。 それどころか、記事のボリュームは115,000文字（11のフォントで書かれた約60のA4ページ）を超えており、説明されている内容の多くは初めて完全に明白で理解できるものではありません。



この記事では、 VXLANではなくMPLS over MPLSを展開して実際に検討するという事実に読者の注意をすぐに向けたいと思います。 ただし、ご理解のとおり、EVPNはコントロールプレーンであるため、作業の原則は、MPLSの上でVXLANの上とほぼ同じになることですが、大きな違いがあります。 したがって、EVPN / VXLANをより詳しく知りたい場合は、 Brocadeなどのドキュメントを読むことができます。このトピックはよく取り上げられています 。また、 Nexusシリーズスイッチに関するシスコのドキュメントも参照できます 。 さて、EVPN / MPLSの研究を開始します。



記事の内容：
1.0。 VPLSを呼び出す

2.0。 EVPNテクノロジーの中核

3.0 テストと構成のための研究所

4.0。 タイプ3ルート

5.0。 タイプ2ルート

5.1。 MACアドレスの学習

6.0 タイプ1ルート

6.1。 マルチホームPEおよびESIラベルの自動検索

6.2。 MAC一括撤退

6.3。 エイリアスラベル

7.0タイプ4ルート

7.1 DF選択メカニズム

8.0。 EVPNのL3機能

8.1。 IRB同期

8.2。 ブリッジドメイン間のルーティング

8.3。 他のVRFおよび外部ネットワークへのアクセス

9.0。 まだ必要なのはなぜですか？

10.0 おわりに



VPLSを呼び出す



誰もがすでにL2VPNに関する問題を読んでおり、 VPLSとは何か、それは何に使われているのかを想像していると思います。 今日存在するVPLSの種類とそれらがどのように大きく異なるかを少しリフレッシュしましょう。





VPLS LDPシグナリング（Martini）は、構成とトラブルシューティングの両方の観点からVPLS機能を実装する最も単純なテクノロジーですが、同じVPLSドメインに属するPEルーターを自動的に検索する機能を備えていないため、管理が困難です。 したがって、1つのVPLSドメインに参加するすべてのPEルーターは、各PEルーターに手動で明示的に登録されます。 その結果、既存のVPLSドメインに新しいサイトを追加すると、このVPLSドメインのすべてのPEルーターの構成が変更されることになり、特にクライアントに5〜6個以上のサイトがある場合、あまり便利ではありません。 このテクノロジーの利点には、そのシンプルさと、BGPプロトコルに新しいアドレスファミリを追加する必要がないことが含まれます（テクノロジーが生まれた当時の古い機器の一部では、ソフトウェアを更新する必要があります）。 アラームシステム全体がLDPでのみ動作するため、この技術の動作はエンジニアが理解できるものであり、何かを再検討する必要はありません（結局、人間はほとんど怠mostlyな生き物です）。 しかし、最近の現実では、VPLSドメインにneyborを追加するときにすべてのPEカメラを常に実行するよりも、BGPに新しいアドレスファミリを一度追加するほうが便利だと思います（鉄の部分でソフトウェアを更新する必要がある場合でも）。



BGP-Autodiscoveryを使用したVPLS LDPシグナリング 。 最終的に、VPLS LDPシグナリングテクノロジの開発者は間違いを認識しました。他のPEの自動検索の欠如により、VPLS BGPシグナリングと比較してこのソリューションのスケーラビリティが大幅に制限されたため、このテクノロジにPEルータの自動検索を追加することが決定されました。 当然、彼らはLDPツールでこれを実現することに成功しなかったので、素晴らしい強力なBGPが使用され、それに別のアドレスファミリーが追加され（そしてそれはKomplella VPLSで使用されるアドレスファミリーとは異なりました）、新しい拡張l2vpn-idコミュニティが予約され 、新しいものが追加されましたFEC-FEC129（VPLS LDPはFEC128を使用します）。 そのため、このテクノロジーを使用する場合、PEルーターの検索はBGPプロトコルを使用して実行され、L2チャネルはLDPを介して既に通知されています。 私の意見では、開発者は以前誇りに思っていたものをすべて消し去り、あなたの機器がMartini + BGP ADおよびKompellaをサポートしているなら、私は後者を好むでしょう。



VPLS BGPシグナリング（Kompella） このテクノロジーは、以前の2つのテクノロジーとは大きく異なります。共通の目標は、プロバイダーのネットワークの上に仮想L2ネットワークを編成することです。 このタイプのVPLSは、シグナリングにBGPプロトコルを使用し、ネイバーの自動検索と仮想L2チャネルのシグナリングの両方を提供します。 その結果、スケーラブルなソリューションが得られ、プロバイダーネットワークでのVPLS BGPシグナリングの普及率が低いのは、この開発がジュニパーによって推進され、特定の時間まで、他のベンダーによってサポートされていなかったという事実と、テクノロジー自体の一見複雑さによるものと思われます1つのラベル配布モデル。



これらのテクノロジーはすべて同じ結果を提供します。プロバイダーのネットワーク上の仮想L2ネットワークの組織、これらのテクノロジーの実装方法と機能のみが異なります。これについては、SDSMの以前のリリースで読むことができます。 しかし、これらの技術には、運用中に特定の不便さを課し、開発者を悩ませるいくつかの一般的な問題があります。 このような問題は少なくとも3つあります。



1.マルチホームサイト（2つ以上のPEルーターに同時に接続されているサイト）がすべてのリンクを使用してトラフィックを送信する方法はありません（アクティブ/アクティブモードで動作）。



2.これらのテクノロジーは、外部ネットワークにアクセスするためのVPLSドメインへのBVI / IRBインターフェイスの通常の追加を除き、高度なL3機能を提供しません。



3. MACアドレスはデータプレーンレベルでのみ調査されるため、プロバイダーのネットワークでのBUMトラフィックのフラッドが増加します。



VPLSのこれらの欠点との戦いはすでに役に立たない-これは、すでに単純ではない技術を非常に複雑にします（たとえば、 P2MP LSPで使用されるNG-VPLS技術がありますが、実際の使用については聞いていません）。 そのため、これらの欠点を解消した新しい技術が発明されました。 今日はイーサネットVPN（EVPN）についてお話します。 この技術はVPLS BGPシグナリングの開発であるという意見があります。理解を簡単にするために、この記事ではEVPNとVPLS BGPシグナリングを比較することは不必要ではないと思います（以降、VPLS BGPシグナリングを意味するVPLSと単に記述します）。



私の個人的な意見では、このテクノロジーはL3VPNとVPLS BGPシグナリングのハイブリッドです。 そして、なぜ、あなたは記事を最後まで読んで理解するだろうと思います。 さあ行こう...



EVPNテクノロジーの中核



VPLSと同様に、EVPNはシグナリングにBGPのみを使用しますが、新しいNLRIを使用します： AFI 25 SAFI 70（Wiresharkの一部のバージョンはまだこのAFI / SAFIを認識せず、ダンプ時にAFI 25に不明なSAFIを書き込みます）。 新しいアドレスファミリの使用は、EVPNが標準のVPLSやスイッチのようにデータプレーンだけでなく、MACアドレスを調べるためにコントロールプレーンも使用するという事実によるものです。



小さな叙情的な余談：ブロケードスタイルの人はイラストが気に入らないかもしれませんが、これらのイラストの使用は、ジュニパーまたはシスコのスタイルでルーターとスイッチの指定を使用する場合、いくつかの図では判読できない混乱が発生しますが、 。 まあ、個人的に、私はそのような図面がより好きです（しかし、これは彼らが言うように、味と色...）。 以下は、ダイアグラム上のすべてのシンボルのリストです。



EVPNでMACアドレスがどのように学習されるかを見てみましょう。 この簡単なネットワークを使用します。



CE1がICMPパケットをCE2に送信したいと想像してください：



1. CE1にはCE2のMACアドレスがないため、CE1はCE2のアドレスを解決するためにブロードキャストARP要求を作成します。



2. CE1からブロードキャストパケットを受信したPE1は、ヘッダーを分析し、このブロードキャストドメイン内の他のすべてのPEルーターにこのパケットを転送する必要があることを理解します。 さらに、PE1はソースMACを対応するブリッジドメインのMACテーブルに書き込みます。



VPLSがある場合、PE1はそれ以上の操作を実行しません。 しかし、EVPNがあるため、PE1はBGP更新を生成します。この更新では、CE1のMACアドレスとVPNラベルを示し、他のすべてのPEルーターに（もちろん、ルーター経由で）送信します。



3. PE2およびPE3は、このブロードキャストパケットを受信し、接続されているすべてのCEルーターに送信します。 VPLSと同様に、EVPNにはスプリットホライズン機能があります。PEルーターから受信したパケットは、他のPEルーターには送信されません。



VPLSでは、PE2およびPE3は、PE1からパケットを受信すると、MACテーブルにCE1のMACアドレスを書き込み、PE1に向けてPWに関連付ける必要があります。 しかし、EVPNでは、PE1はすでにMAC +ラベルをアナウンスしているため、他のPEルーターから受信したパケットのソースアドレスからMACアドレスを調べる必要はありません。つまり、PE1とPE2はこのアナウンスメントを使用してMACアドレステーブルに書き込みます（はい、 IPv4プレフィックス付きのL3VPN）。



4. PE2は、このARP要求に対する応答をCE2から受信します。 MACアドレスCE1とその前のラベルはPE1 BGPから受信したアナウンスからすでにわかっているため、パケットはユニキャストによって直接PE1に送信されます。 さらに、PE2はCE2のMACアドレスをMACテーブルに書き込み、CE2のMACアドレスとラベルを示すBGP更新を生成し、他のPEルーターに送信します。



5. PE1はユニキャストパケットを受信し、MACテーブルを使用して適切なインターフェイスに送信します。



既に理解したように、EVPNはMACアドレスをルーティングアドレスとして使用します。 これは、L3VPN内のルートの分布と比較できます。



L2VPNの記事を読む人は誰でも、VPLSでは、BGPを使用したラベル配布がブロック単位で行われることを覚えていると思います。パケット受信者は（PEルーターの意味で）パケットがどのPEルーターから来たかを知り、MACアドレスをPWに関連付ける必要があるためですPEルーター。 EVPNはこれをもう必要としません。 これは、EVPNがL3VPN IPv4プレフィックスと同じ方法でMACアドレスを処理するためです。PEルーターは、接続されたCEルーターからデータプレーンを介して新しいMACアドレスを学習し、すぐにBGPを介してこのMACをアナウンスします。 BGPアナウンスメントでは、MPLSラベルとプロトコルネクストホップが指定されます（原則として、これはPEルーターのループバックです）。 その結果、他のすべてのPEルータは、パケットの送信先とラベルを知っています。



興味深い事実：VPLS（任意の形式）では、上記のシナリオでは、パケットはユニキャストでCE2からCE1に送信され、PE3に到達しないため、PE3はCE1のMACアドレスのみを認識します。 また、EVPNを使用する場合、PE3は両方のMACアドレスを学習します。CE1とCE2の両方は、最初はPE1からのアナウンスから学習し、2番目はPE2からのアナウンスから学習します。


テクノロジーの原理が明確であり、理論から実践へと移行し、例とともにEVPNの動作を確認できることを願っています。



テストと構成のための研究所



テストには、4つのvMXと3つのCisco IOL（L3）のスタンドを組み立てたUnetlabを使用しました 。 ご理解のとおり、vMXシステムはプロバイダーのネットワークをエミュレートするために使用され、CiscoはクライアントCEルーターとして使用されます。 誰もが興味を持っている場合、このラボはi5と12 GBのRAM（そのうち6つだけが占有され、CPU負荷は30％を超えない）を備えたごく普通のラップトップで起動されたため、EVPNを起動して操作できます。



スキームは次のとおりです。



ご承知のとおり、3台のPEルーター、1台のPルーターがあり、ルーターと3台のCEルーターでもあります。 便宜上、すべてのアドレス指定が図に示されています。



ジュニパーネットワークスでは、EVPNのルーティングインスタンスを2つの方法で構成できます。1つ目はタイプEVPNのインスタンス、2つ目はタイプ仮想スイッチのインスタンスです。 個人的には、2番目のオプションの方が好みです。これは柔軟性が高いためですが、わかりやすくするために、ラボでは両方の方法を使用します。 ただし、2つの方法の違いは構成だけではありません。



VLANベースのサービス -このタイプのEVPNの使用は、ブリッジドメインが互いに完全に分離されているという点で優れています。 ただし、各VLANは新しいルーティングインスタンスを実行する必要があります。 このシナリオでは、PEルーター間のトラフィックは、タグ付きタグまたはタグなしタグのいずれかを使用できます。 デフォルトでは、JunOSは元のタグでタグ付きトラフィックを送信します（もちろん、インターフェイスでタグを書き換えるルールが設定されていない限り）。



EVPNタイプのルーティングインスタンス構成は次のようになります。 



bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1 instance-type evpn; vlan-id 777; interface ge-0/0/2.200; interface ge-0/0/2.777; routing-interface irb.777; route-distinguisher 62.0.0.3:1; vrf-import VPN-1-IMPORT; vrf-export VPN-1-EXPORT; protocols { evpn { interface ge-0/0/2.777; } } bormoglotx@RZN-PE-3> show configuration interfaces ge-0/0/2 description "link to RZN-CE3-SW1"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; mac 50:01:00:03:00:04; unit 777 { encapsulation vlan-bridge; vlan-id 777; family bridge; }


タイプEVPNのインスタンスの構成では、次の行に注意してください。 



 bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1 | match vlan vlan-id 777;


この値は、正規化に使用されるタグを決定します。 つまり、vlan 777とvlan 200に加えて、上記の構成でこのEVPNインスタンスに接続する場合、タグ200、PEのパケットを受信すると、ルーターはこのタグ（タグ200）を削除し、新しいタグ-777をハングさせます。 PEは逆の順序で動作します-CEルータへのインターフェイス、この場合はge-0 / 0 / 2.200インターフェイス（上記の構成を参照、このCEルータは図には示されていません） ）



これは、EVPNが機能するための最小構成です（IGP、MPLSなど、基本的なネットワーク設定は忘れないでください。ここでは説明しません）。 ご覧のとおり、シグナリングにはBGPが使用されているため、 RDとRTを指定します。 すべてが通常通りです-RDはルートを一意にし、RTはルートのフィルタリングに使用されます。 すべてのPEルーターのインポートポリシーとエクスポートポリシーは同じですが、構成に関心がある人のために、私はそれをネタバレにします。



ポリシー設定 
 bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-IMPORT term DEFAULT-IMPORT { from { protocol bgp; community VPN-1; } then accept; } term REJECT { then reject; } bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-EXPORT term DEFAULT { then { community + VPN-1; accept; } } term REJECT { then reject; } bormoglotx@RZN-PE-3> show configuration policy-options community VPN-1 members target:6262:777;




VLAN対応サービス -この場合、仮想スイッチのタイプでルーティングインスタンスを1つだけ作成し、それにブリッジドメインを追加します。 クライアントに30のVLANがある場合、各VLANのインスタンスを作成する数百行に構成を配置する必要はありません-クライアント用に作成されたインスタンスに30のブリッジドメインを追加するだけで十分です。 この場合、RFCによると、vlanタグの存在は必須です。



仮想スイッチタイプのインスタンス構成は次のようになります。 



 bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-1 instance-type virtual-switch; interface ge-0/0/2.0; route-distinguisher 62.0.0.1:1; vrf-import VPN-1-IMPORT; vrf-export VPN-1-EXPORT; protocols { evpn { extended-vlan-list 777; } } bridge-domains { VLAN-777 { vlan-id 777; } } bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/2 description "link to RZN-CE1-SW1"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; mac 50:01:00:01:00:04; unit 0 { family bridge { interface-mode trunk; vlan-id-list 777; } }


JunOSは元のタグを使用してEVPNインスタンスからタグ付きトラフィックを送信するため、EVPNを使用する際に問題はないはずです。一方で、（期待どおりにすべてを実行している場合）仮想スイッチはありません。 いずれにせよ、テスト中に問題は見つかりませんでした。 ただし、注意点が1つあります。 ブリッジドメイン間でvlanを共有せずに、同じEVPNドメインで異なるタイプのインスタンスを使用し始める場合、正規化がトリックをすることを考慮することは価値があります。 たとえば、1つのPEルーターで、タイプEVPNのインスタンスに2つのvlan：777および1777を追加し、正規化にはvlan 777を使用します。もう一方の端からは、2つのブリッジドメイン-vlan 777およびvlan 1777を持つ仮想スイッチがあります。その結果、パケットはCEからvlan 1777に到着し、vlanは777に正規化され、仮想スイッチインスタンスではパケットはvlan 777に到着します。宛先ホストはvlan 1777、つまり別のブリッジドメインにあります。 その結果、1つのVLANのホスト間に接続性がありません。 または、イベントの開発の別のバリエーション-同じブリッジドメインで、正規化用に設計された異なるタグを構成しました。 このシナリオでは、PE1ではパケットが通常のタグ777で飛行し、PE2では通常のタグは1777になるため、接続もありません（まったく存在しません）。その結果、PE2は単に無効なVLAN番号を持つパケットを破棄します。



タイプ3ルート



現時点では、CEルーター間のパケット交換はまだ行われていません（もちろん、 CDP 、 LLDP 、およびその他の喜びはオフになっているため、余分なものが飛び去ることはありません）。したがって、PEルーターはMACアドレスを学習しませんでした。 これは確認できます： 



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


この結論から、このルーティングインスタンスにはインターフェースが1つしかなく、アクティブ状態であることがわかります。IRBインターフェースはありません（後で詳しく説明します）。 2つのネイバーがあります（スキームによれば、これらはPE2とPE3です）。また、まだMACアドレスを調査していません（ローカルはこのPEルーターにローカルのMACアドレスであり、リモートは隣接PEルーター）。



次に、このルーティングインスタンスのルーティングテーブルにあるルートを見てみましょう。 



 bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 RZN-VPN-1.evpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 3:62.0.0.1:1::777::62.0.0.1/304 *[EVPN/170] 01:33:42 Indirect 3:62.0.0.2:1::777::62.0.0.2/304 *[BGP/170] 01:10:22, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 299808 3:62.0.0.3:1::777::62.0.0.3/304 *[BGP/170] 01:10:01, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 299776


ルートは3つだけで、PE1の最初のローカルルートです。 これらのルートとは何ですか、なぜ必要なのですか？ 正しくしましょう。 EVPNには5種類のルートしかありません。





注：5番目のタイプのルートは、RFC法でまだ承認されていません。これまでのところ、 ドラフトでのみ説明されているため、この記事では検討しません。



上記の出力では、ルートの最初の数字が3であることがわかります 。これは、 Inclusive Multicast Ethernet Tag routeであることを意味します 。 このルートは各PEルーターによって生成され、 BUMトラフィックの送受信に使用されます。 ルートは次のフィールドで構成されています。



RD-誰もがそれが何であるかを理解していると思います。以下の発表では：62.0.0.3：1：

イーサネットタグIDはVLAN番号です。この場合、 777：

IPアドレスの長さ -次のフィールドで指定されたIPアドレスの長さ（この値は、ジュニパーの機器には表示されません）

発信元ルーターのIPアドレス -ルートの発信元のIPアドレス。通常はループバックPEルーターです。 この例では、 62.0.0.3です。



注： / 304はプレフィックスの長さです;ジュニパーネットワークスは自動的にすべてのEVPNルートに追加します;本質的には、意味的な負荷を運びません。 ジュニパーのWebサイトに記載されているように、この値は最大ルート長を意味し、正規表現を使用してルートを検索するときにこの機能を使用できます。 さて、将来を考慮しましょう。 


 3:62.0.0.3:1::777::62.0.0.3/304 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.3:1 PMSI: Flags 0x0: Label 299904: Type INGRESS-REPLICATION 62.0.0.3 Next hop type: Indirect Address: 0x95ca3d4 Next-hop reference count: 2 Source: 62.0.0.255 Protocol next hop: 62.0.0.3 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 6262 Peer AS: 6262 Age: 1:16:02 Metric2: 1 Validation State: unverified Task: BGP_6262.62.0.0.255+179 Announcement bits (1): 0-RZN-VPN-1-evpn AS path: I (Originator) Cluster list: 62.0.0.255 Originator ID: 62.0.0.3 Communities: target:6262:777 Import Accepted Localpref: 100 Router ID: 62.0.0.255 Primary Routing Table bgp.evpn.0


ルートをより詳しく見ると、次の行が表示されます。 



  PMSI: Flags 0x0: Label 299904: Type INGRESS-REPLICATION 62.0.0.3


PMSIはProvider Multicast Service Interfaceの略であり、Point-to-Multipoint LSPにすぎません。 この記事では、P2MP LSPがどのように機能するかについては考慮しません。これは非常に大きく複雑なトピックであるため、EVPNはp2mp LSP機能を使用してBUMトラフィックを転送するためです。 PE3はラベル299904を生成しました。これは、他のPEルーターがBUMトラフィックをPE3に送信するために使用できます。



タイプ3のルートは、各VLANに対して個別に生成されます。これは、イーサネットタグの言葉がその名前で言うことです。 2つのブリッジドメイン（たとえば、vlan 777とvlan 1777）がある場合、PEルーターは2つのタイプ3ルートを生成します-各vlan（ブリッジドメイン）に1つ。



EVPNルーティングテーブルには最初はタイプ3のルートしかないため、PEルーターは、どのラベルでブロードキャストパケットをリモートPEルーターに送信する必要があるかがわかります。



タイプ2ルート



次に、CE1とCE2の間でpingを実行します。 



 RZN-CE1-SW1#ping 10.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 7/8/11 ms


CE1がアドレス10.0.0.2を解決するためにARP要求を行ったため、1つのパケットが失われました。 次に、アドレスがMACテーブルに表示されたかどうかを見てみましょう。 



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


2つのMACアドレスが同時に現れました。1つはPE1のローカル（アドレスCE1）、もう1つはPE2から受信したアドレス（アドレスCE2）です。 



 bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 RZN-VPN-1.evpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.1:1::777::aa:bb:cc:00:06:00/304 *[EVPN/170] 00:05:23 Indirect 2:62.0.0.2:1::777::aa:bb:cc:00:07:00/304 *[BGP/170] 00:05:23, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 299808


これで、テーブルに2つの新しいルートが追加されました（ルートテーブル5の合計で、出力を減らすためにタイプ3のルートは表示されません）。 ルートはタイプ2-MAC / IPアドバタイズメントルートです。 このルートの形式は次のとおりです。





RD -Route Distinguisher、それがない場合、この場合は62.0.0.2:1です。

イーサネットセグメント識別子 -ESI識別子。これについては後で説明します。 JunOSは、この値を詳細または広範な出力でのみ表示します。ルートではゼロです： ESI：00：00：00：00：00：00：00：00：00：00：00 ;

イーサネットタグID -VLAN番号：777 ;

MACアドレスの長さ-MACアドレスの長さ。実際は常に48ビットであり、JunOSはこの値を表示しません。

MACアドレス -MACアドレス自体： aa：bb：cc：00：07：00 ;

IPアドレスの長さ -IPアドレスの長さ。IPv4の場合は32ビット、IPv6の場合は128です。このフィールドはオプションであり、値を含めることはできません（すべてゼロ）。 JunOSはこの値を表示しません。

IPアドレス -アドレス自体は、以下の出力では表示されません。 フィールドはオプションです。

MPLS Label1 | 2-ラベル自体を直接表示し、JunOSは詳細または詳細な出力でのみ表示します。 



 2:62.0.0.2:1::777::aa:bb:cc:00:07:00/304 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.2:1 Next hop type: Indirect Address: 0x95c9f90 Next-hop reference count: 4 Source: 62.0.0.255 Protocol next hop: 62.0.0.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 6262 Peer AS: 6262 Age: 26 Metric2: 1 Validation State: unverified Task: BGP_6262.62.0.0.255+179 Announcement bits (1): 0-RZN-VPN-1-evpn AS path: I (Originator) Cluster list: 62.0.0.255 Originator ID: 62.0.0.2 Communities: target:6262:777 Import Accepted Route Label: 300272 ESI: 00:00:00:00:00:00:00:00:00:00 Localpref: 100 Router ID: 62.0.0.255 Primary Routing Table bgp.evpn.0


前に書いたように、EVPNはMACアドレスをルーティングアドレスとして使用します。 PE2からのアナウンスメントから、PE1はvlan 777のMACアドレスaa：bb：cc：00：07：00に到達するためにそれを知っています（同じMACアドレスなので、vlan 777それは異なるVLANにあり、これらは異なるルートになります）、パケットに2つのラベルを付ける必要があります。300272（VPN）と62.0.0.2までのトランスポートラベルです。



注：Route Distinguisher、Protocol Next Hopなどのよく知られているフィールドに加えて、このアナウンスでゼロに設定されているESIフィールドがあります。 マルチホームサイトを使用する場合、このフィールドは非常に重要です。このシナリオでは、このフィールドは役割を果たしません。



L3VPNと同様に、EVPNはMAC、ネクストホップ、およびインスタンスごとのラベルを生成できます。



MACごと-MACアドレスごとに個別のラベルが生成されます。 ご存知のように、この種のラベル配布は無駄が多すぎます。



ネクストホップごと-CEまたはACごとがおそらくより正確になります。つまり、同じラベルが同じアタッチメント回路の背後にあるMACアドレスに対してのみ生成されます（つまり、同じPEルーターにルーティングインスタンス2つのCEルーターが接続されている場合、CE1から学習したMACアドレスの場合、PEルーターは1つのラベルを生成し、CE2から学習したMACアドレスの場合はもう1つ）



インスタンスごと -ルーティングインスタンス全体に対して1つのラベルが生成されます。つまり、すべてのルートが同じラベルを持ちます。 JunOSでは、拡張モードでEVPNインスタンスを表示すると、このラベルを見ることができます。



MACアドレスの学習



次に、PE1のMACテーブルを見てください。 



 bormoglotx@RZN-PE-1> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : RZN-VPN-1 Bridging domain : VLAN-777, VLAN : 777 MAC MAC Logical NH RTR address flags interface Index ID aa:bb:cc:00:06:00 D ge-0/0/2.0 aa:bb:cc:00:07:00 DC 1048575 1048575


フラグ列には、このアドレスがどのように学習されたかが示されます。MACアドレスaa：bb：cc：00：06：00にはDフラグのみがあります。これ以上フラグが表示されないため、このMACはローカルに接続されたCEルーターから学習されたと安全に言えます。 ただし、MACアドレスaa：bb：cc：00：07：00には2つのフラグ-DCがあります。 最初のフラグの意味はすでにわかっていますが、フラグCは、このアドレスがコントロールプレーンを介して学習されたことを意味します。



PE3のMACアドレステーブルを見ると、すべてのアドレスがコントロールプレーンを介してこのPEルーターによって学習され、単一のローカルMACアドレスがないことがわかります。 



 bormoglotx@RZN-PE-3> show evpn mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : RZN-VPN-1 Bridging domain : __RZN-VPN-1__, VLAN : 777 MAC MAC Logical NH RTR address flags interface Index ID aa:bb:cc:00:06:00 DC 1048574 1048574 aa:bb:cc:00:07:00 DC 1048575 1048575


注：気づいた場合、1つのケースではshow bridge mac-tableコマンドを使用し、2番目のshow evpn mac-tableコマンドを使用しました。 これは、異なるPEルーターではルーティングインスタンスの構成が異なるためです-最初のケースでは仮想スイッチ、2番目のEVPNで。


CE3からのトラフィックがまだないため、PE3でローカルに調査された単一のMACアドレスはありません。 CE3の前にpingを実行してこの状況を修正し、この表をもう一度見てみましょう。 



 RZN-CE1-SW1#ping 10.0.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 7/10/13 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 bormoglotx@RZN-PE-3> show evpn mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : RZN-VPN-1 Bridging domain : __RZN-VPN-1__, VLAN : 777 MAC MAC Logical NH RTR address flags interface Index ID aa:bb:cc:00:05:00 D ge-0/0/2.777 aa:bb:cc:00:06:00 DC 1048574 1048574 aa:bb:cc:00:07:00 DC 1048575 1048575


ご覧のとおり、データプレーンから学習したCE3 MACアドレスがPE3に表示されます。



通常のスイッチと同様に、EVPN MACテーブルのアドレスには特定の「有効期限」があり、デフォルトではこの期間は300秒です。 この間にこのMACが非アクティブで更新されなかった場合、ルートはテーブルから削除されます。 すべてが単純なようです-タイマーは機能しました-MACは削除されました。 しかし、すべてが見た目ほど単純ではありません。 これがどのように起こるか見てみましょう。



そのため、PE3はCE3のMACアドレスを学習し、BGPアナウンスメントでそれを他のPEルータに送信しました。 記録が300秒間更新されていないとします。 次に、PE3は指定されたMACアドレスをテーブルから削除する必要があります。 しかし、PE3は、このMACアドレスが背後にあるというすべてのネイバー情報を送信したことを覚えています。 このホストが移動した場合、またはすでにオフになっている場合はどうなりますか？ それで何？ ブラックホールのように、残りのPEルーターはCE3のパケットをPE3に送信しますか？ もちろん違います。 実際には、PEルーターがテーブルからローカルMACアドレスを削除すると、BGP Withdrawnメッセージが送信され、他のPEルーターがこのルートとMACアドレスをテーブルから削除するように強制されます。 見てみましょう。



最初の画面には、BGP UPDATEメッセージが表示されます。これは、MACアドレスを通知しますaa：bb：cc：00：07：00（写真はクリック可能）：







300秒後、別のBGP UPDATEメッセージが表示されます。これは、以前に指定されたMACアドレスへのルートをキャンセルする撤回メッセージです。







MACエージングタイムに加えて、EVPNにはMACアドレスの変更を通知するメカニズムがあります。 PEがルーターのCEからGratuitous ARPを受信すると、BGPアップデートが生成されます。これには、古いMACアドレスと新しいMACアドレスのアナウンスを示す撤回されたメッセージが含まれます。



ただし、MACアドレスに加えて、MAC / IPアドバタイズメントルートにオプションでホストIPアドレスを含めることができます。 EVPNにIRBルーティングインターフェイスを追加し、表示されたルートを確認します。 



 bormoglotx@RZN-PE-1> show configuration interfaces irb.777 family inet { address 10.0.0.254/24; } mac 02:00:00:00:00:02; bormoglotx@RZN-PE-1> *2:62.0.0.1:1::777::02* show route table RZN-VPN-1.evpn.0 match-prefix RZN-VPN-1.evpn.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.1:1::777::02:00:00:00:00:02/304 *[EVPN/170] 14:17:31 Indirect 2:62.0.0.1:1::777::02:00:00:00:00:02::10.0.0.254/304 *[EVPN/170] 14:17:31 Indirect


2つの新しいルートが登場しました。最初のルートはirb.777 MACアドレスのみで、2番目のルートはMAC + IPです。 Mac + IPアナウンスメントにはARPレコードの形式があり、同じEVPNドメインに参加しているすべてのPEルーターがARPレコードを同期するため、プロバイダーのネットワークを介したフラッドARPブロードキャスト要求の数が減少します。



次に、ルートを詳しく見てみましょう。 



 bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 match-prefix *2:62.0.0.1:1::777::02* detail RZN-VPN-1.evpn.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 2:62.0.0.1:1::777::02:00:00:00:00:02/304 (1 entry, 1 announced) *EVPN Preference: 170 Next hop type: Indirect Address: 0x940d804 Next-hop reference count: 7 Protocol next hop: 62.0.0.1 Indirect next hop: 0x0 - INH Session ID: 0x0 State: <Active Int Ext> Age: 14:21:34 Validation State: unverified Task: RZN-VPN-1-evpn Announcement bits (1): 1-BGP_RT_Background AS path: I Communities: evpn-default-gateway Route Label: 300144 ESI: 00:00:00:00:00:00:00:00:00:00


新しい拡張コミュニティevpn-default-gatewayがこのルートに登場しました。 これは、ルーティングインスタンスのメインゲートウェイであるルートのマーク方法です。 このルートは、各VLANに対して個別に生成されます。



なぜ2つのルートが生成されるのですか？ 実際には、MACアドレスのみが指定されている最初のルートがbringeドメインでのスイッチング専用に使用されますが、MAC + IPルートはすでにルーティングに使用されており、本質的にarpエントリです。 少し先に進み、トラフィックが他のVLANまたは外部ネットワークに流れる場合、ホストへのルートは同じ方法で生成されると書きます（もう1つのVLANをスキームに追加する場合、これを後で検討します）。



タイプ1ルート



これまで、タイプ1およびタイプ4のルートを無視しました。これらのルートはマルチホームサイトに使用されます。



注：記事の量が多すぎるため、マルチホームサイトでのEVPNの動作については詳しく説明しません。 誰かが興味を持ったら-コメントを書いて-このトピックに関する別の記事を書きます。


タイプ1ルートは次のとおりです。 





 1:62.0.0.2:0::112233445566778899aa::0/304 *[BGP/170] 00:00:56, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 299792


このルートには、MACアドレスに関する情報は含まれませんが、次のような非常に幅広い用途があります。





タイプ1ルートは、 EVIまたはESIごとにアドバタイズできます。 最初のアナウンスは、エイリアスタグをアナウンスするときに使用され、2番目は、任意のイーサネットセグメントのアナウンスされたMACアドレスの大量キャンセルの可能性のためです。



このルートの上記の機能について詳しく見ていきましょう。



マルチホームPEおよびESIラベルの自動検索



VPLSとは異なり、EVPNには、同じCEルーター（マルチホームサイト）に接続されたPEルーターの自動検出機能が含まれています。 EVPNの用語では、PE <-> CEジャンクションはイーサネットセグメントと呼ばれます。 各セグメントには、ESI（イーサネットセグメント識別子、グループ内の8ビットの10グループに記録された80ビット数）が割り当てられます。 シングルホームサイトの場合、この識別子は重要ではないため、自動的に0に割り当てられます。ただし、マルチホームサイトの場合、この識別子は非常に重要であり、EVPNドメイン全体で一意である必要があります（残念ながら、可能なESIの組み合わせの数は非常に大きく、2 ^ 80に等しくなります） 。 同じCEルーターに接続されたESには同じESIが必要です。範囲全体の2つの値は予約されており、管理上設定できません-これらはすべてゼロ（非マルチホーミングセグメントの識別子として使用）およびすべてFです。



上記の出力では、文字と数字の魔法のセット：112233445566778899aa： ESI以外の設定はありません物理インターフェイスのネットワーク管理者： 



 bormoglotx@RZN-PE-2> show configuration interfaces ge-0/0/4 description "link to RZN-MULTI-SW-1"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; esi { 11:22:33:44:55:66:77:88:99:aa; single-active; } mac 50:01:00:02:00:06; unit 111 { encapsulation vlan-bridge; vlan-id 111; family bridge; }


このルートは、ESIに加えて、非常に重要な意味を持ち、拡張コミュニティの形式で提示されます：esi-label。次のようになります。 



 bormoglotx@RZN-PE-2> show route table RZN-VPN-3.evpn.0 match-prefix *1:62* detail RZN-VPN-3.evpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 1:62.0.0.1:0::112233445566778899aa::0/304 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.1:0 Next hop type: Indirect Address: 0x95c0f28 Next-hop reference count: 20 Source: 62.0.0.255 Protocol next hop: 62.0.0.1 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 6262 Peer AS: 6262 Age: 2:50 Metric2: 1 Validation State: unverified Task: BGP_6262.62.0.0.255+179 Announcement bits (1): 0-RZN-VPN-3-evpn AS path: I (Originator) Cluster list: 62.0.0.255 Originator ID: 62.0.0.1 Communities: target:6262:111 esi-label:00049660(label 300640) <<<<<<community Import Accepted Localpref: 100 Router ID: 62.0.0.255 Primary Routing Table bgp.evpn.0


このルートには、このEVPNドメインに特有のネイティブ拡張コミュニティがあるため、evpnドメイン内のすべてのPEルーターは、このルートを対応するEVPNインスタンスのルーティングテーブルにインポートします。 



 bormoglotx@RZN-PE-3> show route table RZN-VPN-3.evpn.0 match-prefix *1:62* detail | match esi Communities: target:6262:111 esi-label:00049660(label 300640) Communities: target:6262:111 esi-label:00049680(label 300672)


なぜ必要なのですか？次のスキームを検討してください



。このシナリオでは、潜在的なL2ループがあります。CE1からのBUMトラフィックがPE2に到達すると、PE1を含む他のすべてのPEルーターに送信されるためです。 PE1には、BUMトラフィックを受信したCE1の方向のリンクもあります。また、PE1がCE1にパケットを送信すると、レベル2でループが発生します。ご存じのように、L2ヘッダーにはttlフィールドはありません。控えめに言っても、状況は不快です。これに対処する方法は？EVPNは、この目的のために自動的にDesignated Forwarder（DF）を使用します。彼の出方については後で検討しますが、今のところは彼の任命についてお話します。



DFには、このPEルーターがDFであるイーサネットセグメントにあるCEルーターに向けてブロードキャストフレームを送信する排他的な権利があります。他のすべての非DF ルーターは、BUMトラフィックをCEルーターに送信しません。



2つのシナリオがあります：シングルアクティブモードを使用する場合とアクティブアクティブ（すべてアクティブ）モードを使用する場合。



ご想像のとおり、シングルアクティブモードでは、片方の肩だけが機能し、もう片方の肩は予備です。メインレバレッジが低下した場合、トラフィックはバックアップに送られます。 1つのショルダーを使用して1つのVLANのトラフィックを転送することは可能ですが、トラフィックをすぐに1つのVLANの両方のショルダーに移動することはできません（または、そうでない場合-サポートに書き込み、明らかにバグを発見した、またはより可能性が高いのは、回路を組み立てたエンジニア、曲がった手）。



Active-ActiveモードまたはAll-Activeモードでは、CEからPEへのすべてのリンクが機能し、MC-LAGが対象になります。 MC-LAGテクノロジーの動作原理は、この記事では考慮されません。読者がすでにこのトピックを研究していることが理解されます。



最初のケースでは、すべてが単純です-DFが選択され、BUMを含むすべてのトラフィック交通、彼だけが転送されます。同時に、ESIラベルはアナウンスには存在しません（少なくともジュニパーの機器では）。RFCによれば、DF選択メカニズムの動作にエラーが発生した場合（両方のPEルータが突然自分自身を考慮する場合） DF）ループが形成されていません。



DF選択メカニズムの通常の動作中、片方の肩がブロックされるだけです。つまり、PEルーターはブロックされたリンクからMACアドレスを学習しないため、他のPEルーターには何も通知しません。ただし、BUMトラフィックが何らかの複雑な方法でこのルーターに到着した場合でも、単に破棄されます。



2番目のケースでは、もう少し複雑です。ここでは、DFも選択され、送信する権利がありますCEルーターに向かうBUMトラフィック-つまり、CEルーターに向かうトラフィックに問題はありません。CEルーターからBUMトラフィックを転送するときに問題が発生する場合があります。 CEルーターは、どのPEルーターDFでもまったく問題ではないため（より正確には、CEルーターは、集約インターフェースを備えた別のスイッチに単純に接続されていると見なします）、次の状況が可能です。 CE1からのブロードキャストパケットがDFではないPE1に到着するとします。 PE1はパケットを受信し、PE2を含む他のすべてのPEルーターに送信します。このセグメントのDFルーターであるPE2は、BUMを転送しますCEルーターに戻るトラフィック。はい、ループしました。これは、ESIラベルが便利な場所です。実際、PE2は、PE2にパケットを送信するときに、ESIラベル（ラベルの下部）と包括的マルチキャストラベルの2つのラベルをハングさせます。PE2はパケットを受信し、トップラベルを削除し、ESIラベルを検出します。これにより、このセグメントからのトラフィックが到着したため、CE1に向けてパケットをフラッディングする必要がないことがルーターに通知されます。しかし、なぜこのパケットをPE2に送信する必要があるのでしょうか？実際には、このトラフィックの受信元であるCE1に加えて、このトラフィックに関心を持つ他のCEルーターをPE2に接続できます。



図の略語：

IM-包括的マルチキャストラベル

ESI -ESIラベル

TL-トランスポートMPLSラベル


: PE1 PE2 , PE1 PE2 . , .


MAC Mass Withdrawal



この機能は、マルチホームCEルーターを接続するリンクの1つが脱落する場合を対象としています。 Active-Activeモードの場合、CEルーターからのトラフィックのバランスがとられるため、MACアドレスは両方のPEルーターから学習されます。リンクの1つが落ちた場合、PEルーターは、送信されたこのセグメントのすべてのルートをキャンセルする必要があります。 1000以上あると想像すると、BGPメッセージの急激な急増によってプロセッサ使用率が高くなり、コントロールプレーン全体に悪影響を与える可能性があります。はい。また、多数の回収メッセージを処理するのは、それほど簡単ではありません。したがって、PEルーターは、ESIごとに生成された、以前に送信されたタイプ1ルートのキャンセルについてのWithdrawnメッセージを送信します（詳細は後ほど）。このメッセージを受け取った後、他のPEルーターは、このセグメント（ES）に関連付けられているすべてのMACラベルの一致をクリアするか、このセグメントにトラフィックを転送できる別のルーターがある場合、そこから受信したルートを使用します（つまり、次にプロトコルを変更します） -hop）。このセグメントの最後のルーターが「死んだ」場合、このセグメントに関連付けられたMACアドレステーブルをクリアします。



ご存知のように、これはバックアップからバックアップにすばやく切り替えるために必要です。



エイリアスラベル



繰り返しますが、この機能はマルチホーミングCEに適用されます。All-ActiveモードのCEルーターからのトラフィックは、すべてのリンク間で分散する必要があります。バランシングはCEルーターとその開発者のみが知っているアルゴリズムによって行われるため、マルチホーミングCEルーターはすべての発信トラフィックを1つのインターフェースのみで送信する可能性があります。その結果、タイプ2ルートは1つのルーターPEからのみ送信されます。PE1からのみであると仮定します。



他のルーターはPE2を介して指定されたセグメントに到達する方法を知らないため、トラフィックはそのセグメントを通過せず、PEとCEルーター間の肩の単純な原因となります。これを行うために、各PEルーターは、イーサネットセグメントのエイリアスラベルをアナウンスします。他のPEルーターはタイプ1ルートを受信するため、PE1とPE2は同じESにリンクがあり、All-Activeモードで動作していることがわかります。受信したエイリアスラベルを使用して、他のPEルーターは、VPNラベルの代わりにPE2を通過するパケットを訪問して、PE1とPE2の両方を介してCEルーターにパケットを送信できます-EVI ごとに生成されたタイプ1ルートでPE2から受信したエイリアスラベル。



図の略語：

「S AL -エイリアシングラベル

EVPN - EVPNラベル

TL -トランスポートMPLSラベル


タイプ1ルートには、このPEルーターがこのイーサネットセグメントで動作するモード（シングルアクティブまたはオールアクティブ）を他のPEルーターに通知するフラグがあります。このフラグは、タイプ1ルートのアナウンスメントに追加される拡張コミュニティの一部です。フラグがアップしている場合、ルーターはシングルアクティブモードで動作し（フラグはシングルアクティブフラグと呼ばれます）、フラグがアップしていない場合、ルーターはAll-アクティブモード。以下は、フラグが立てられ、ラベルがないルートの例です。 



 bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 table __default_evpn__.evpn.0 detail match-prefix *112233445566778899aa::* __default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) * 1:62.0.0.1:0::112233445566778899aa::0/304 (1 entry, 1 announced) BGP group RR-NODES type Internal Route Distinguisher: 62.0.0.1:0 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [6262] I Communities: target:6262:111 esi-label:100000(label 0)


ただし、ルートはすでにタグ付けされており、Single-Activeフラグは発生していません。 



 bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 table __default_evpn__.evpn.0 detail match-prefix *62000000000000000001::* __default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) * 1:62.0.0.1:0::62000000000000000001::0/304 (1 entry, 1 announced) BGP group RR-NODES type Internal Route Distinguisher: 62.0.0.1:0 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [6262] I Communities: target:100:100 esi-label:000493a0(label 299936)


タイプ4ルート



次に、タイプ4のルートを見てみましょう。このルートは、前に書いたDFを選択するために必要です。このルートは次のとおりです。 



 bormoglotx@RZN-PE-2> show route table bgp.evpn.0 match-prefix *4:6* bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 4:62.0.0.1:0::112233445566778899aa:62.0.0.1/304 *[BGP/170] 01:07:57, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.3 via ge-0/0/0.0, Push 299808


このルートには、ルーティングインスタンスからエクスポートするように構成されたコミュニティが含まれないことに注意してください。 



 bormoglotx@RZN-PE-2> show route table bgp.evpn.0 match-prefix *4:6* detail bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) 4:62.0.0.1:0::112233445566778899aa:62.0.0.1/304 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.1:0 Next hop type: Indirect Address: 0x95c1954 Next-hop reference count: 14 Source: 62.0.0.255 Protocol next hop: 62.0.0.1 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Active Int Ext> Local AS: 6262 Peer AS: 6262 Age: 1:07:59 Metric2: 1 Validation State: unverified Task: BGP_6262.62.0.0.255+51796 AS path: I (Originator) Cluster list: 62.0.0.255 Originator ID: 62.0.0.1 Communities: es-import-target:33-44-55-66-77-88 Import Accepted Localpref: 100 Router ID: 62.0.0.255 Secondary Tables: __default_evpn__.evpn.0


これらのルートは、新しいコミュニティes-import-target：XX-XX-XX-XX-XX-XXを使用します。コミュニティ自体はESIから生成されます。このため、以下に示すように、識別子から48ビットが取得されます



。ESI：

11 : 22：33：44：55：66：77：88：99：aa



生成されたコミュニティ：

コミュニティ：es-import-target：33-44-55 -66-77-88



同じESI（より正確には、識別子の同じビット16〜64）を持つPEルーターのみがこのルートをインポートします。ご覧のように、この発表では、ルーティングインスタンスのインポートまたはエクスポートに指定されたRTはありません。つまり、タイプ4ルートはEVPN自体のルーティングテーブルには表示されません。それらは、テーブルbgp.evpn.0および__default_evpn __。Evpn.0でのみ確認できます。



たとえばaaaa334455667788aaaaなど、別のPEルーターにESIがある場合、ご想像のとおり、それらのコミュニティは同じになります。つまり、ルートもインポートされます。しかし、てないでください。すべてがすでに私たちに盗まれています。完全なESIがルート本体に示され、このルートはインポートされますが、無視されます。RTと同様に、es-import-targetはルートのフィルタリング専用です。以下は、タイプ4ルートとそのコミュニティです。 



 bormoglotx@RZN-PE-1> show route table bgp.evpn.0 match-prefix *4:62* detail | match "comm|\/304" 4:62.0.0.2:0::112233445566778899aa:62.0.0.2/304 (1 entry, 0 announced) Communities: es-import-target:33-44-55-66-77-88


興味深いケースは次の構成です。 



 bormoglotx@RZN-PE-1> show configuration interfaces ae1 | match esi | display set set interfaces ae1 esi 62:00:00:00:00:00:00:00:00:01 set interfaces ae1 esi all-active


すでに発表されているように、すべてゼロで構成される拡張コミュニティを取得していることを既に推測していると思います。 



 bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 table __default_evpn__.evpn.0 detail match-prefix *62000000000000000001:6* __default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) * 4:62.0.0.1:0::62000000000000000001:62.0.0.1/304 (1 entry, 1 announced) BGP group RR-NODES type Internal Route Distinguisher: 62.0.0.1:0 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [6262] I Communities: es-import-target:0-0-0-0-0-0


このため、すべてが壊れると想定しないでください。そのようなコミュニティでも、すべてが機能しますが、たとえば、ネットワークがxx：xx：00：00：00：00：00：00：00：01-xx：xx：00：00：00の範囲のESIを持つ場合：00：00：00：99：99、タイプ4のすべてのルートは同じコミュニティを持ちます。つまり、PEルーターは、タイプ4のすべてのルートを受け入れ、それらを必要としない場合でもルーティングテーブルにインストールします。しかし、私はあなたがそれを心配するべきではないと思います、プラス/マイナス100ルートの天気はしません（なぜそうしない-あなたが記事を最後まで読んだときに理解するでしょう）。



読者が気づいたかどうかはわかりませんが、1と4のようなルートではRDは少し奇妙に見えます。たとえば、PE2からのタイプ2ルート： 



 2:62.0.0.2:1::777::aa:bb:cc:00:07:00/304 *[BGP/170] 00:00:18, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 299792


次に、同じPE2からのタイプ1ルートを示します。 



 1:62.0.0.2:0::112233445566778899aa::0/304 *[BGP/170] 00:00:56, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 299792


PE2から、タイプ1ルートにはRD 62.0.0.2:07がありますが、タイプ2または3の同じPE2ルートから、ルーティングインスタンスで構成されているRD 62.0.0.2:1から到着します。RDはどうなりますか？この現象をテストするには、タイプEVPNの2つのルーティングインスタンスを作成し、完全に異なるRDを割り当てます。 



 bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-3 | match route route-distinguisher 62.0.0.1:3; bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-4 | match route route-distinguisher 9999:99;


次に、どのRDでタイプ1ルートがアナウンスされるかを見てみましょう。 



 bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 | match "1:6" 1:62.0.0.1:0::112233445566778899aa::0/304 1:62.0.0.1:0::aaaa334455667788aaaa::0/304


ルートのRDは、RZN-VPN-3またはRZN-VPN-4で設定されたものと一致しません。このRDはどこから来たのですか？JunOSは、ルーターIDまたはループバックアドレスから自動的に生成します。さらに、最初の値が優先されます。たとえば、現在はrouter-idがあります。 



 bormoglotx@RZN-PE-1> show configuration routing-options router-id router-id 62.0.0.1;


そして、この値はRDの最初の部分として取得され、2番目の部分はこのケースではゼロに設定されます。ルーターIDを思い出しましょう： 



 bormoglotx@RZN-PE-1> show configuration routing-options router-id router-id 62.62.62.62;


今どのルートが与えられているか見てみましょう： 



 bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 | match "1:6" 1:62.62.62.62:0::112233445566778899aa::0/304 1:62.62.62.62:0::aaaa334455667788aaaa::0/304


ご覧のとおり、JunOSはRD自体を生成しました。router-idを指定しないとどうなりますか？見てみましょう。 しかし、ループバックにさらに2、3のアドレスを掛けて、タスクを複雑にしましょう。 



 bormoglotx@RZN-PE-1> show configuration interfaces lo0 description "BGP & MPLS router-id"; unit 0 { family inet { address 10.1.1.1/32; address 62.0.0.1/32; address 62.62.62.62/32; } family iso { address 49.0000.0620.0000.0001.00;


今見てみましょう： 



 bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 | match " 1:(1|6)" 1:10.1.1.1:0::112233445566778899aa::0/304 1:10.1.1.1:0::aaaa334455667788aaaa::0/304


JunOSは最小のループバックIPアドレスを選択し、ルーターIDとして使用しました。これは、このタイプ1ルートがESIごとに生成されるためです。ルートがEVIごとに生成される場合、このルートがアナウンスされる元のネイティブインスタンスRDがあります。ただし、タイプ4ルートには常にルーター固有のRDがあります。これは、ESIごとに常に生成されるためです。



ESIごとのルート生成には、いくつかの特徴があります。ESI識別子から物理インターフェイスで構成可能です。このインターフェイスとすべての異なるEVPNインスタンスにたとえば10論理ユニット（VLANと言うことができます）がある場合、同じタイプ1ルートが異なるインスタンスで生成されることになります。 1つのルートのみが生成され、このルートに関心のあるすべてのインスタンスのRT-ksがハングアップする場合、10の同一のルート（それらの違いはRTのみになります）？



これがどのように機能するかを例で見てみましょう。物理インターフェイスのESI設定はここにあります： 



 bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/2 | match esi | display set set interfaces ge-0/0/2 esi 00:00:00:00:00:00:00:00:00:07 set interfaces ge-0/0/2 esi single-active


このインターフェイスは、evpnタイプの2つのインスタンスで使用されます。 



 bormoglotx@RZN-PE-1> show configuration routing-instances | display set | match ge-0/0/2. set routing-instances RZN-VPN-1 interface ge-0/0/2.0 set routing-instances eVPN-test interface ge-0/0/2.200


これらのインスタンスに対応するRTを見てみましょう（ポリシーを削除し、わかりやすくするためにvrf-targetでRTを登録しました）。 



 bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-1 | match target vrf-target target:62:1; bormoglotx@RZN-PE-1> show configuration routing-instances eVPN-test | match target vrf-target target:62:2;


次に、リフレクターで発表されたタイプ1ルートを見てみましょう。 



 bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 table __default_evpn__.evpn.0 match-prefix *1:6*:07:* detail __default_evpn__.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) * 1:62.0.0.1:0::07::0/304 (1 entry, 1 announced) BGP group RR-NODES type Internal Route Distinguisher: 62.0.0.1:0 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [6262] I Communities: target:62:1 target:62:2 esi-label:100000(label 0)


ご覧のとおり、ルートには2つのRT-kiがあります。ターゲット：62：1、これはRZN-VPN-1に対応し、ターゲット：62：2、eVPN-testに対応します。この機能により、収束時間が短縮されます。このリンクが落ちた場合、リンクがアタッチされているすべてのインスタンスで落ちます。この場合、2-x BGP Withdrawnメッセージの代わりに、1つだけが飛び去りますが、2つのRTがあります。



注：読者が希望する場合、タイプ1および4のルートは、EVPNマルチホーミングに関する別の記事で個別に検討されます。


DFセレクター



DF選択メカニズムを使用すると、異なるVLANに異なるDFを選択できるため、たとえば、異なるブリッジドメイン間でトラフィックのバランスを取ることができます-異なるVLANからのトラフィックは、同じEVPNインスタンス内のCEルーターへの異なるリンクを通過します。



ルータは、ESIおよび適切なコミュニティとともにタイプ4ルートアナウンスメントを送信し、DF選択タイマーを開始します。デフォルトでは、このタイマーは3秒に設定されています。変更できますが、セグメントのすべてのPEルータで同じである必要があります。そうでない場合、アルゴリズムが正しく機能しない可能性があります。



タイマーの期限が切れると、DF選択に参加するすべてのPEルーターが、最小アドレスから始まるセグメント内のすべてのPEルーターの完全なリストを構成します。リスト内の各PEルーターには、ゼロから始まる番号（i）が割り当てられます。



その後、DF数は式V mod N = iによって計算されます。ここで、VはVLANの数であり、Nはセグメント内のPEルータの数です。番号が計算の結果であり、このVLANのこのセグメントのDFになるPEルータ。



アドレス62.0.0.1および62.0.0.2のPEルーターが2つしかない場合、VLAN 777のDFを計算してみましょう。



両方のPEルーターがこのリストを作成します。 



 62.0.0.1 i=0 62.0.0.2 i=1


777 vlanがあるため、V = 777、N = 2です（セグメント内にルーターが2つしかないため）。ここで、777 mod 2 = 1を検討します。したがって、DFは62.0.0.2になります。



次に、セグメント内のPEルーターの数を3に増やして、再度カウントします。 



 62.0.0.1 i=0 62.0.0.2 i=1 62.0.0.3 i=2


777 mod 3 = 0、つまりDF 62.0.0.1を意味します。



ご想像のとおり、セグメントに2つのVLAN、たとえば777と778と2つのPEルーターがある場合、777ではDFはPE1になり、778 PE2になります。



たとえば、上記のスキームでvlan-id 777のDFになる人を確認しましょう。 



 bormoglotx@RZN-PE-2# run show evpn instance RZN-VPN-3 extensive | match "vlan|forward" VLAN ID: 777 Designated forwarder: 62.0.0.2 Backup forwarder: 62.0.0.1


vlan番号を778に変更し、DFが変更されるかどうかを確認します。 



 bormoglotx@RZN-PE-2# run show evpn instance RZN-VPN-3 extensive | match "vlan|forward" VLAN ID: 778 Designated forwarder: 62.0.0.1 Backup forwarder: 62.0.0.2


ご覧のとおり、このメカニズムは機能します。



evpnで機能するL3



現時点では、EVPNに存在するルートと、1つのブリッジドメイン内でトラフィックが送信される方法を把握しました。これは確かに優れていますが、このテクノロジーはデータセンターを接続するように設計されており、通常、通常のクライアントのように複数のVlanがデータセンターに存在し、トラフィックがそれらの間を移動することは論理的です（Vlan）。また、データセンターと外界との接続も必要です。次に、異なるvlane（ブリッジドメイン）間のパケットルーティングの仕組みを分析します。



IRB同期



しかし、EVPNに統合された奇妙で興味深いルーティングの世界に真っ向から飛び込む前に、デフォルトゲートウェイの同期という非常に重要なポイントを強調します。デフォルトゲートウェイコミュニティがIRBインターフェイスのアナウンスメントに追加される理由はまだわかりません。美しさのためではありません。このアイテムの名前に基づいて、デフォルトゲートウェイを同期する必要があるとすでに推測していると思います。同期とは何ですか、どのように発生し、なぜ必要なのですか？正しくしましょう。



まず、IRBインターフェイスでハングしているPE1、2、3のすべてのMACアドレスを見てみましょう。順番に、PE1： 



 bormoglotx@RZN-PE-1> show interfaces irb.777 | match mac MAC: 02:00:00:00:07:77 bormoglotx@RZN-PE-1> show interfaces irb.1777 | match mac MAC: 02:00:00:00:17:77


PE1 macでは、irbインターフェイスのアドレスは手動で構成されます。次に、PE2に進みましょう。 



 bormoglotx@RZN-PE-2> show interfaces irb.777 | match mac MAC: 02:00:00:02:07:77 bormoglotx@RZN-PE-2> show interfaces irb.1777 | match mac MAC: 02:00:00:02:17:77


そして、アドレスをIRBインターフェイスに割り当てることを許可しました。それでは、PE3を見てみましょう。 



 bormoglotx@RZN-PE-3> show interfaces irb | match curr Current address: 00:05:86:71:96:f0, Hardware address: 00:05:86:71:96:f0


ここでは、機器に配線する方法をそのままにしたため、MACの方がひどいです。



すべてのPEルーターは、デフォルトゲートウェイ（irb.777およびirb.1777）へのMAC + IPルートを通知します。 PEルーターは、default-gatewayコミュニティというラベルの付いたMAC + IPルートを受信すると、受信したリモートIRBインターフェイスのMACアドレスを独自のアドレスとして認識し始めます。結局のところ、複数のIPアドレスと1つのMACが存在するインターフェイスがある場合、それが反対にならないのはなぜですか-1つのIPと複数のMACアドレスですか？デフォルトゲートウェイの同期には、自動と手動の2種類があります。ここで自動同期を検討します。少し後で手動同期に戻ります。



次のコマンドを使用して、PEルーターで使用されているアドレスを確認できます（PE1を確認します）。 



 bormoglotx@RZN-PE-1> show bridge evpn peer-gateway-macs Routing instance : RZN-VPN-1 Bridging domain : VLAN-1777, VLAN : 1777 Installed GW MAC addresses: 02:00:00:02:17:77 Bridging domain : VLAN-777, VLAN : 777 Installed GW MAC addresses: 00:05:86:71:96:f0 02:00:00:02:07:77


PE1には2つのブリッジドメインがあり、それぞれに対してデフォルトゲートウェイが個別に同期されます。PE1とは異なり、PE3には1つのブリッジドメインと1つのIRBインターフェイスのみがあります。したがって、同期はVLAN-777ブリッジドメインに対してのみ実行されます。 



 bormoglotx@RZN-PE-3> show evpn peer-gateway-macs Routing instance : RZN-VPN-1 Bridging domain : __RZN-VPN-1__, VLAN : 777 Installed GW MAC addresses: 02:00:00:00:07:77 02:00:00:02:07:77


結果は次の図です。PE1のirb.777は3つのMACアドレスに応答するはずです。





そしてもちろん、IRBインターフェースが自身のMACではなくアドレス指定されたパケットに応答することを確認します。素朴な方法でやってみましょう-必要なMACアドレスに静的なARPエントリをCEルーターに書き込むだけです。CE1-1はVLAN-777ブリッジドメインのPE1に接続されているため、irb.777 MACアドレスを解決するときに、ネイティブirb.777-02：00：00：00：07：77 MACアドレスを受け取ります。PE1のirb.777のMACアドレスが02：00：00：00：07：77ではなく、02：00：00：02：07：77（であることを示すCE1-1に静的arpエントリを作成します。これは実際にはPE2のirb.777に属します）： 



 RZN-CE1-SW1#sh start | i arp arp 10.0.0.254 0200.0002.0777 ARPA RZN-CE1-SW1#show arp | i 10.0.0.254 Internet 10.0.0.254 - 0200.0002.0777 ARPA


CE1-1に示されているMACアドレスはPE2のirb.777に対応しているため、トラフィックがPE2に送られると想定するのは論理的です。トラフィックの行き先を確認するために、PE-shekのIRBインターフェイスに次のフィルターを掛けます。 



 [edit] bormoglotx@RZN-PE-2# show | compare [edit interfaces irb unit 777 family inet] + filter { + input irb777-counter; + } [edit interfaces IRB unit 1777 family inet] + filter { + input irb1777-counter; + } [edit] + firewall { + family inet { + filter irb777-counter { + term 1 { + then { + count irb777; + accept; + } + } + } + filter irb1777-counter { + term 1 { + then { + count irb1777; + accept; + } + } + } + } + }


ご覧のように、フィルターは単にIRBインターフェースで得られたものを考慮し、すべてのトラフィックを通過させます。この時点で、PE1とPE2の両方にゼロカウンターがあります。



PE1で： 



 bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 0 0


PE2の場合： 



 bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 0 0


それでは、CE1-1で10.0.0.254までの33個のicmpリクエストを開始しましょう（なぜ33なのでしょうか？ 



 RZN-CE1-SW1#ping 10.0.0.254 repeat 33 Type escape sequence to abort. Sending 33, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (33/33), round-trip min/avg/max = 1/2/6 ms


覚えているように、CE1-1は、ゲートウェイのデフォルトMACアドレスがローカルポピーirb.777 PE1ではなく、非常に重要なMAC irb.777 PE2であると見なします。



PE1のカウンターにあるものを確認します。 



 bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 3300 33


エラー、33パケットすべてがローカルIRBインターフェイスによって受信されました。PE2カウンターで何が起こっているのか見てみましょう。 



 bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 0 0


すべてゼロ。トラフィックは単にそこに行かず、ローカルPE1 IRBインターフェイスによって処理されました。



Wiresharkのスクリーンショットをいくつか提供します。 CE1-1からPE1へのパケットは次のとおりです。宛先としては、PE1のローカルirb.777インターフェイスのMACではなく、irb.777 PE2のMACアドレスです。ただし、注目すべき点は、PE1からの応答がどのアドレスからCE1-1に到着するのかを見てみましょう。PE1 は、ネイティブMACアドレスirb.777から応答を送信します。つまり、理解できるように、irb.777は他のirb.777インターフェイス（PE2およびPE3）のMACアドレス宛てのパケットのみを受け入れますが、PE1はパケット送信時に他の人のMACアドレスを送信元アドレスとして使用しません。これは非常に重要です。たとえば、デフォルトゲートウェイアドレスを解決するとき、IRBインターフェイスはネイティブMACアドレスのみを応答して示すためです。



















実験の純度については、CE1-1で、irb.777 MACアドレスがPE3のirb.777インターフェイスのMACアドレスと等しいことを指摘しています。 



 RZN-CE1-SW1#sh start | i arp arp 10.0.0.254 0005.8671.96f0 ARPA RZN-CE1-SW1#show arp | i 10.0.0.254 Internet 10.0.0.254 - 0005.8671.96f0 ARPA


当然、irb.777 PE3にもこのフィルターを掛けました。pingを開始して確認します。 



 RZN-CE1-SW1#ping 10.0.0.254 repeat 27 Type escape sequence to abort. Sending 27, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (27/27), round-trip min/avg/max = 1/2/5 ms


WIresharkを見て、CEを含むパケットが必要な宛先MACアドレスで送信されたことを確認します。PE1のカウンターを確認します。 











 bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 6000 60


PE1のirb.777はさらに27パケットを処理しましたが、PE3のカウンターはまだゼロです。 

 bormoglotx@RZN-PE-3> show firewall filter irb777-couter counter irb777 Filter: irb777-couter Counters: Name Bytes Packets irb777 0 0


これは、自動同期メカニズムを調べました。次に、手動同期に移りましょう。



一般的に、手動同期は単に必要ないという事実のため、単純に自動同期を無効にします。なんで？これで、すべてのPEでIRBインターフェイスの同じIPアドレスを設定しましたが、MACは異なります。 EVPNでIRBインターフェイスを構成する2番目の方法（推奨）は、同じブリッジドメインのすべてのIRBインターフェイスで同じIPアドレスとMACアドレスを使用することです。この状況では、どこでも同じMACであるため、IRBインターフェイスはすでに同期されています。したがって、default-gateway do-not-advertiseコマンドを指定して、IRBインターフェイスのMAC + IPルートの生成を禁止できます。



デフォルトゲートウェイの同期の大きなプラスは、サービスを中断することなくデータセンター間で仮想マシンを移動できることです（ポイントA（マシンの移動元）とZ（マシンの移動先）間の100ミリ秒未満の遅延など、特定の条件下で）。 ）仮想マシンを移動した後、そのarpにあるデフォルトゲートウェイのアドレスにパケットを外部ネットワークに送信し続けることができます。つまり、arpキャッシュをクリアする必要さえありません。当然、このMACが別の場所にある新しいBGP更新が生成されます。一般に、EVPNのVMモビリティのトピックについては、別のかなり大きな記事を書く必要があります。そのため、ここでは取り上げません。



これがなければ、EVPNのL3インターフェイスの動作メカニズムが理解されないため、上記のすべてがメモリに保存されたことを願っています。次に、ブリッジドメイン間のパケットの転送に直接進みます。



ブリッジドメイン間のパケットルーティング



パケットは1つのブリッジドメイン内でスイッチングされ、異なるブリッジドメイン間で（または外部ネットワークにアクセスするときに）ルーティングされることを前提としています。トラフィックをルーティングできるように、インスタンスにルーティングインターフェイスを追加する必要があります。 JunOSでは、ルーティングインターフェイスはIRB（Integrated Routing and Bridging）です。このインターフェイスにはタグが付けられておらず、vlanタグはそこに落ちるトラフィックから削除されます。通常のJunOSインターフェイスと同様に、IRBにはユニットがあります。 IRBインターフェースのユニット番号（実際には、物理​​インターフェースのユニット番号）は、このインターフェースが特定のVLANを参照することを意味するものではありません。たとえば、irb.777インターフェースはvlan 777に関連する必要はありませんが、同じブリッジドメイン内のvlan番号とユニットIRB番号が同じ場合は、構成ファイルを読む方が便利です。



テストには、以前と同じラボを使用しますが、図に示すように、ルーティングインターフェイスといくつかのCEルーターを追加します。



簡潔に、記事では、私はスキームで指定され、ホスト名を指定しないであろう、と略語を使用します。

RZN-CE1-SW1⇒CE1-1

RZN-CE1-SW2はCE1-2⇒ある

RZN-CE2-SW1⇒CE2-1

RZN- CE2-SW2⇒CE2-2

RZN-CE2-SW1⇒CE3


一見したところ、この回路の見た目は少し変わっていますが、すべてのPEルーターで同じIRBインターフェイスが使用されています。少なくとも2つの質問が必要だと思います-どのように機能するのか、なぜ必要なのか。これらの質問に答えてみましょう。



行きましょう。最初に、すでに調査したVPLSでメイン（またはデフォルトの）ゲートウェイがどのように機能するかを思い出しましょう。 IRBインターフェイスを作成するPEルーターがあります。同じIRBインターフェイスをいくつかのVRFに追加するか、GRTにリリースしますそのような必要がある場合。そのようなルーターが複数ある可能性があり、vrrpを使用してメインゲートウェイを予約しますが、マスターは引き続き1つです。つまり、VPLSでは、VPLSドメインの一部であるPEルーターにある外部ネットワークへの出口は1つしかありません。外部ネットワークへの唯一のアクセスであるため、他のすべてのPEルーターから外部に向けられたすべてのトラフィックはこのPEを通過します（意図的に壊れたvrrpの形で松葉杖を使用しない場合）。このスキームの欠点は明らかです-デフォルトゲートウェイが配置されるPE-keは、外部ネットワークに向けられたVPLSドメインのすべての発信トラフィックと、外部からVPLSドメインに入るすべてのトラフィックをダイジェストする必要があります。このPEに障害が発生し、VRRPが構築されていない場合、その後、一般的に他のネットワークや外部から遮断されます。奇妙なことに、このスキームには利点があります-それはシンプルです。どのエンジニアにとっても、上記のソリューションは、構成とトラブルシューティングの両方の点で明確になりますが、EVPNで使用されるソリューションについては言えません。



上記の欠点に加えて、別の重要なニュアンスがあります-上記のスキームでは、VPLSドメインを出入りするL3トラフィックを最適化できません。



EVPNは、L3インターフェイスを使用するまったく異なる方法を提供します。 CEルーターが外部ネットワーク、他のVLAN、またはインターネットにアクセスする場合、このCEルーターが接続されているPE-keでL3インターフェイスの形式のデフォルトゲートウェイを構成する必要があります。当然、各VLANには独自のゲートウェイが必要です。



RFCが、外部ネットワークにアクセスできるようにするために各PEルーターにIRBインターフェイスが必要であると明示的に述べていないことは注目に値します。ただし、EVPNのセットアップに関するジュニパーのドキュメントには、次のような行があります。



Initially when EVPN and Layer 3 gateway functionality were conceived, some basic assumptions were made, and RFC requirements were to be followed.



These were:



1. All PE's for an EVPN instance must have an IRB configured.



2. All PE's should have the same IP address for the GW. From the RFC, if there is a discrepancy between the GW IP addresses, an error is logged. Though it must be noted that different addresses can still be configured as both MAC/IP for advertisement to remote provider edge (PE) devices and are installed on all participating PE devices.


その結果、EVPN / MPLSを使用する場合、各PEルーターでL3インターフェイスを構成する必要があります。そうしないと、このサイトはvlanを終了しません。しかし、EVPN / VXLANにはそのような要件はありません（ちなみに、これはEVPN / VXLANとEVPN / MPLSの大きな違いです）



スキームに戻りましょう。 VLAN-777ドメインとVLAN-1777ドメインの2つのブリッジドメインがあります。 VLAN 1777には2つのCEルーターがあります。これらはCE1-2とCE2-2です。VLAN777には、CE1-1、CE2-1、CE3の3つのルーターがあります。当然、図に示されているすべてのCEルーター間の接続が必要です。



ただし、複数のブリッジドメインを相互に接続するには、1つのL3インターフェイスをルーティングインスタンスEVPNに追加するだけでは不十分です。また、L3インターフェイスを配置する必要のあるVRFタイプ（L3VPNに使用）を持つ各PEルーターにルーティングインスタンスを作成する必要があります。このようにして、2つのインスタンスをリンクします：VRFとEVPN（または仮想スイッチ）：



注：GRTで EVPNをリリースすることもできますが、これは良い考えではないと思われます。いずれにせよ、これはサポートされており、この機能を実装するかどうかは誰にでも任されています。


上記のように、ルーティングインスタンスをVRFタイプで構成し、それをEVPNに関連付ける必要があります。以下は、PE2での構成です-仮想スイッチおよび関連するVRF： 



 bormoglotx@RZN-PE-2> show configuration routing-instances RZN-VPN-1 instance-type virtual-switch; interface ge-0/0/2.0; interface ge-0/0/3.0; route-distinguisher 62.0.0.2:1; vrf-import VPN-1-IMPORT; vrf-export VPN-1-EXPORT; protocols { evpn { extended-vlan-list [ 777 1777 ]; } } bridge-domains { VLAN-1777 { vlan-id 1777; routing-interface irb.1777; } VLAN-777 { vlan-id 777; routing-interface irb.777; } } bormoglotx@RZN-PE-2> show configuration routing-instances VRF-VPN-1 instance-type vrf; interface irb.777; interface irb.1777; route-distinguisher 62.0.0.2:10002; vrf-target { import target:6262:10001; export target:6262:10001; } vrf-table-label;


PE3のVRFにはirb.1777インターフェイスがないことを除いて、同じVRFが他のPEルータで起動します。



タイプ2ルートにはオプションでホストIPアドレスを含めることができることはすでにわかっています。すでにMAC + IPルート自体を見ました：覚えている場合、IRBインターフェイスをEVPNに追加するとき、2つのルートを生成しました：ルーティングとMACに頼らずにブリッジドメイン内で到達できるように、IRBインターフェイスのMACアドレスのみ+デフォルトゲートウェイコミュニティが接続されたIP。 2番目のルートはルーティングに必要であり、arpレコードです。ただし、デフォルトゲートウェイだけでなく、MAC + IPルートも生成されます。このホストは、このホストが外部ネットワークまたは別のVLANにアクセスしようとした場合に表示されます。



ホストがVLANを終了するには何が必要ですか？ True-パケットをデフォルトゲートウェイに送信する必要があります。この場合、ブリッジドメインのゲートウェイの役割は、PEルーターのIRBインターフェイスによって果たされます。また、IRBインターフェイスにパケットを送信するには、ホストがこのIRBインターフェイスのMACアドレスを知る必要があります。したがって、最初に、ホストはIRBインターフェイスのMACアドレスを解決するためにarp要求を送信します。その時点で、IRBインターフェイスがこのPEルーター*に直接接続されているホスト（この場合はルーターCE）からarp要求を受信すると、タイプ2の2つのルートを生成します：MACアドレスとMAC + IPのみ-そしてそれらを送信しますEVPNルートの形式のBGPで。さらに、/ 32マスクを使用した通常のIPv4プレフィックスの形式の同じルートが、ローカルルートとしてEVPNに関連付けられたVRFにも表示されるため、次に、指定されたホストへのvpnv4ルートもBGPを介して送信されます（2番目が必要な理由-後でわかります）。実際、上記はvlane間でルーティングするときのEVPN操作の主な原則であり、異なるブリッジドメイン間またはEVPNと外部ネットワーク間のトラフィックフローを最適化できます。



arpエントリのテーブルは、各PEルーターで表示できます。PE2の例： 



 bormoglotx@RZN-PE-2> show bridge evpn arp-table INET MAC Logical Routing Bridging address address interface instance domain 10.0.1.2 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777 10.0.1.22 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777 10.0.1.222 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777 10.0.0.2 aa:bb:cc:00:07:00 irb.777 RZN-VPN-1 VLAN-777


* 10.0.1.22および10.0.1.222は、ダンプを削除するテスト中にハングしたCE2-2セカンダリアドレスです。



出力は、arp要求がどのインターフェイスから作成されたか、どのブリッジドメインおよびルーティングインスタンスを示しています。この情報は、同じMACアドレスが異なるvlanasにある可能性があるため、または上記の出力のように、同じ物理インターフェイス上に複数のアドレスがあり、当然ながら1つのMACアドレスを持つため、有用です。これらすべてのホストには、間違いなくVRFへのルートがあります。 



 bormoglotx@RZN-PE-2> show route table VRF-VPN-1.inet.0 active-path | match "(10.0.0.2\/)|(10.0.1.2{1,3}\/)" 10.0.0.2/32 *[EVPN/7] 00:09:38 10.0.1.2/32 *[EVPN/7] 09:11:03 10.0.1.22/32 *[EVPN/7] 02:02:40 10.0.1.222/32 *[EVPN/7] 01:54:26


理論から実践に移りましょう。CE3からCE1-2へのトラフィックの流れを分析しましょう。最初はvlan 777にあり、アドレスは10.0.0.3、2番目はvlan 1777にあり、アドレスは10.0.1.1です。 PE3には、ローカルインターフェイスirb.1777がないことを思い出させてください。



そのため、CE3は、異なるネットワーク上にあるCE1-2にパケットを送信したいと考えています。 CE3はメインゲートウェイのポピーアドレスを知らないため、このCEルーターでは他のネットワークへのメインゲートウェイであるアドレス10.0.0.254を解決するためにarp要求を行います。当然、CE3（および他のすべてのCEルーターでは、IRBインターフェイスへのデフォルトルートが登録されています）。 PE3はローカルIRBインターフェイスにアドレス指定されたCE3からarp要求を受信するため、PE3はMAC + IPルートを生成し、他のPEに送信します。さらに、ルート10.0.0.3/32がVRFにローカルルートとして表示されたため、PE3はBGP vpnv4ルートもアナウンスします。 



 bormoglotx@RZN-PE-3> show route advertising-protocol bgp 62.0.0.255 | match 10.0.0.3 * 10.0.0.3/32 Self 100 I 2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304


: , 2, MAC-, . , . PE MAC+IP . , — , , .


先に進みます。これで、CE3はデフォルトゲートウェイのMACアドレスを知っています。つまり、CE1-1に宛てられたパケットの送信先を知っています（ヘッダーのMACアドレスL2を意味します）。 CE3はパケットを形成し、L3ヘッダーの宛先アドレスはアドレスCE1-1（10.0.1.1）を示し、発信アドレスはCE3自身のアドレス（10.0.0.3）を示します。 L2ヘッダーでは、宛先アドレスはポピーアドレスirb.777で示され、発信アドレスは独自のMACアドレス（PEルーターへのインターフェースアドレス）です。



パケットはPE3に到着します。宛先MACアドレスはirb.777のローカルインターフェイスであるため、PE3はL2ヘッダーを削除し、EVPNインスタンスに関連付けられているVRFルーティングテーブルでIPルックアップを実行します。現在、このテーブルには4つのアクティブルートがあります。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 active-path VRF-VPN-1.inet.0: 4 destinations, 9 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[Direct/0] 00:20:05 > via irb.777 10.0.0.3/32 *[EVPN/7] 00:00:06 > via irb.777 10.0.0.254/32 *[Local/0] 04:04:34 Local via irb.777 10.0.1.0/24 *[BGP/170] 02:19:20, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)


10.0.0.0/24および10.0.0.3/32はPE3にローカルです（2つ目はirb.777のarp-requestで生成されたばかりです）が、PE1およびPE2からBGP経由でネットワーク10.0.1.0/24へのルートを取得します。



PE3と同じVRFがPE3と同じRTでPE1とPE2に作成されるため、PE3はPE1とPE2からすべてのアナウンスを受信します。それら（PE1およびPE2）では、irb.1777インターフェイスがこのVRFに追加されます。つまり、VRFルーティングテーブルにインポートされる通常のvpnv4ルートの形式で10.0.1.0/24 BGPネットワークへのルートをアナウンスします。 PE3。上記の出力はアクティブなルートのみを示しているため、アナウンスは1つだけです。もちろん、2つあります。1つはPE1から受信され、もう1つはPE2から受信されます。 PE1からのルートは、router-idが小さく、両方のPE-shekから受信した他のすべてのルートパラメータが完全に同一であるため、最良として選択されました。どのルートが最適に選択されるか-PE1またはPE2から-絶対に重要ではありません（たとえば、10のサイトがある場合、1つのネットワークへの9つのルートを受け取りますが、いずれにしても1つだけが選択されます）。とにかく受け取り時にVLAN-777ブリッジドメインからのトラフィックのBUM、PE1は、VLAN-1777ブリッジドメインのすべてのインターフェイスにフラッディングします。なぜ-さらに調べる。



IPルックアップ中に、PE3はプレフィックス10.0.1.0/24がPE1にあることを認識します。したがって、PE3はL3VPNを介してPE1にパケットを送信します。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.0/24 active-path VRF-VPN-1.inet.0: 4 destinations, 9 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 02:23:12, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)


等価パス（ECMP）でのトラフィックバランシングがPE3で有効になり、2つのルートがFIBにインストールされる可能性があります。つまり、トラフィックはPE2を通過できますが、これは先ほど書いたように重要ではありません-主なことはパケットがPEに行くことですローカルブリッジドメインVLAN-1777が存在するルーター（もちろん、VRF間に何らかの種類のハードリンクが構成されていない限り、そうすることはできません）。 PEにそのようなブリッジドメインがない場合、それからネットワーク10.0.1.0/24へのアナウンスはありません。



PE1はVRFのPE3からパケットを受信し、IPルックアップを行い、パケットがVLAN-1777ブリッジドメイン用であることを認識します。 



 bormoglotx@RZN-PE-1> show route table mpls.0 label 16 mpls.0: 22 destinations, 23 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 16 *[VPN/0] 02:25:02 to table VRF-VPN-1.inet.0, Pop


PE1はホスト10.0.1.1のMACアドレスを知らないため、このアドレスを解決するために、VLAN-1777ブリッジドメインのすべてのインターフェイスにarp要求が送信されます。より正確には、パケットの1つのコピーがCE1-2に送信され、2つ目のコピーがPE2の包括的マルチキャストラベルとともに送信されます。しかし、スプリットホライズン関数はどうでしょうか？結局、PEルーターから受信したパケットを他のPEルーターに送信すべきではありません。そして実際、ここで私たちは良心のtwinりなしにそれに違反します。実際、このパッケージはL3VPN経由で（つまり、実際にはPE1のEVPNに関して外部ネットワークから）入ってくるため、ここではスプリットホライズンルールは機能しません。しかし、パケットがEVPNから到着したことはわかっています。ブロードキャストストームは発生しますか？パケットはevpnから到着しましたが、異なるブロードキャストドメインから送信されました（CE3はvlan 777にあり、CE1-2はvlan 1777にあります）。これらは異なるブリッジドメインであるため、ブロードキャストストームはそれらの間で発生することはありません-パケットはブリッジドメイン間でルーティングされます。



CE1-2は宛先ホストであり、PE1に接続されているため、このarp要求に応答します。思い出してください、ホストからIRBインターフェイスにアドレス指定されたarpを受信した後、PEルーターはタイプ2 MAC + IPのルートを生成する必要があります。これに関して、PE1はMAC + IPおよびvpnv4ルートを生成します。 



 bormoglotx@RZN-PE-3> show route table RZN-VPN-1.evpn.0 match-prefix *10.0.1.1* RZN-VPN-1.evpn.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.1:1::1777::aa:bb:cc:00:09:00::10.0.1.1/304 *[BGP/170] 00:02:46, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 299792 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32 VRF-VPN-1.inet.0: 5 destinations, 10 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.1/32 *[BGP/170] 00:02:48, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)


PE1には、EVPNルーティングテーブルのホスト10.0.0.3とVRFルーティングテーブルの10.0.0.3/32へのMAC + IPルートがあります。同様に、PE3側から：ホスト10.0.1.1/32へのルートはepnおよびVRFルーティングテーブルにあります。現在、CE3とCE1-2の間のパケット交換を妨げるものはありません。ただし、注意点が1つあります。 PE1のVRFのルーティングテーブルを見てみましょう。 



 bormoglotx@RZN-PE-1> show route table VRF-VPN-1.inet.0 10.0.0.3/32 VRF-VPN-1.inet.0: 7 destinations, 15 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.3/32 *[EVPN/7] 00:24:37, metric2 1 > to 10.62.0.1 via ge-0/0/0.0, Push 300352, Push 299792(top) [BGP/170] 00:24:37, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 16, Push 299792(top)


PE1にはホスト10.0.0.3/32への2つのルートがありますが、PE3には10.0.1.1/32へのルートは1つしかありません。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32 VRF-VPN-1.inet.0: 6 destinations, 11 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.1/32 *[BGP/170] 02:25:44, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)


いくつかの奇妙なルートが、まだ不明なEVPNプロトコル、さらには7のプリファレンスでVRFに登場しており、BGPよりも優れています（また、ISIS、OSPFルートなどにも優先されます）。おかしいですよね。このルートは何ですか？彼がいなければすべてがうまくいくからです。実際、このルートは、L3VPNをバイパスして、EVPN間の直接トラフィック交換に必要です。それを詳しく見てみましょう： 



 bormoglotx@RZN-PE-1> show route table VRF-VPN-1.inet.0 10.0.0.3/32 protocol evpn detail VRF-VPN-1.inet.0: 7 destinations, 15 routes (7 active, 0 holddown, 0 hidden) 10.0.0.3/32 (2 entries, 1 announced) *EVPN Preference: 7 Next hop type: Indirect Address: 0x97f5f90 Next-hop reference count: 2 Next hop type: Router, Next hop index: 615 Next hop: 10.62.0.1 via ge-0/0/0.0, selected Label operation: Push 300352, Push 299792(top) Label TTL action: no-prop-ttl, no-prop-ttl(top) Load balance label: Label 300352: None; Label 299792: None; Session Id: 0x1 Protocol next hop: 62.0.0.3 Label operation: Push 300352 Label TTL action: no-prop-ttl Load balance label: Label 300352: None; Composite next hop: 0x95117b8 670 INH Session ID: 0x2 Ethernet header rewrite: SMAC: 02:00:00:00:07:77, DMAC: aa:bb:cc:00:05:00 TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800 Indirect next hop: 0x9860990 1048583 INH Session ID: 0x2 State: <Active NoReadvrt Int Ext> Age: 1:09 Metric2: 1 Validation State: unverified Task: RZN-VPN-1-evpn Announcement bits (1): 0-KRT AS path: I


この出力の次の行に興味があります。 



  Ethernet header rewrite: SMAC: 02:00:00:00:07:77, DMAC: aa:bb:cc:00:05:00 TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800


これは、パケットをCE3に送信するためにL2ヘッダーを追加する方法を示すだけです。送信元としてリストされているMACアドレスを見てみましょう：SMAC：00：05：86：71：1a：f0。これがパケットのソースである場合、PE1にある必要があることは論理的です。パケットがvlan 777に送信できるMACアドレスを推定してみましょう。これがirb.777インターフェースであると仮定することは論理的です。つまり、そのMACはL2ヘッダーにある必要があります。irb.777のMACアドレスが実際に何であるかを見てみましょう。 



 bormoglotx@RZN-PE-1> show interfaces irb.777 | match mac MAC: 02:00:00:00:07:77


そうです、PE1のローカルインターフェイスirb.777のMACアドレスはヘッダーに示されています。これは、推論が正しいことを意味します。宛先MACアドレスが誰に属しているかを特定しましょう：DMAC：aa：bb：cc：00：05：00？推測する価値はないと思います-MAC CE3でなければなりません。確認しましょう： 



 bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 match-prefix *10.0.0.3* RZN-VPN-1.evpn.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304 *[BGP/170] 00:05:18, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 299792


このMACは、ルートが示すホスト10.0.0.3に属します。信頼性のために、CE3に移動して、インターフェイス上のMACがPEの方向にどのようにあるかを見てみましょう。 



 RZN-CE3-SW1#sh ip int br | i 10.0.0.3 Ethernet0/0.777 10.0.0.3 YES NVRAM up up RZN-CE3-SW1#sh interfaces eth0/0.777 | i Hard Hardware is AmdP2, address is aabb.cc00.0500 (bia aabb.cc00.0500)


私たちが確立した住所の所属。ここで、関心のある出力部分の2行目を見てみましょう。 



 TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800


これらは、CE3に送信するときにイーサネットフレームの残りのフィールドに入力する必要がある値です。



つまり、このルートは、irb.777を含むイーサネットフレームをCE3ホストに送信する必要がある場合、L2ヘッダーに指定された値を追加し、2つのラベルを付ける必要があることを明確に示しています：Push 300352、Push 299792（上）、ge-interfaceにパケットを送信します0/0 / 0.0。すべてがシンプルです。



注：パッケージでのこのアクションは、複合ネクストホップの使用を意味します。そのため、EVPNを構成する場合、Juniperでchained-composite-next-hop機能を含めることが必須です。


 bormoglotx@RZN-PE-1> show configuration routing-options forwarding-table chained-composite-next-hop { ingress { evpn; } }


このルートはどこから来たのですか？PE3から送られたのでしょうか？PE3がリフレクターに通知する内容を確認しましょう。 



 bormoglotx@RZN-PE-3> show route advertising-protocol bgp 62.0.0.255 | match 10.0.0.3 * 10.0.0.3/32 Self 100 I 2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304


犯罪者はいません。アドレス10.0.0.3を含むルートは2つだけです。最初はvpnv4ルート、2番目はEVPNタイプ2です。



これは、このルートがPEルーターに対してローカルであることを意味します。わかった。このルートは、EVPN MAC + IPルートに基づいてローカルPEルーターによって生成されます。しかし、なぜPE3にはないのですか？通常の学習方法を使用すると、PE3にはirb.1777インターフェイスを持つブリッジドメインvlan 1777はなく（結局、CE1-2のパケットはそこから送信されるはずです）、関連付けられたVRFにirb.1777インターフェイスがないと結論付けることができます。また、ローカルインターフェイスがないため、ソースとしてどのMACアドレスを指定する必要がありますか？別のインターフェイスのアドレスは入力しません。そのため、このルートはPE3では使用できません。この理論を確認してみましょう-VRFのPE1でirb.777インターフェイスを非アクティブ化します。このインターフェイスからパケットがPE3に飛行する必要があります。



したがって、PE1へのルートは次のとおりです。 



 [edit] bormoglotx@RZN-PE-1# run show route table VRF-VPN-1.inet.0 10.0.0.3/32 VRF-VPN-1.inet.0: 8 destinations, 18 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.3/32 *[EVPN/7] 00:01:22, metric2 1 > to 10.62.0.1 via ge-0/0/0.0, Push 300352, Push 299792(top) [BGP/170] 00:04:41, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 16, Push 299792(top)


PE1のVRFでIRBインターフェイスを非アクティブ化します。 



 [edit] bormoglotx@RZN-PE-1# show | compare [edit routing-instances VRF-VPN-1] ! inactive: interface irb.777 { ... }


そして、10.0.0.3 / 32へのルートがあることを確認します。 



 [edit] bormoglotx@RZN-PE-1# run show route table VRF-VPN-1.inet.0 10.0.0.3/32 VRF-VPN-1.inet.0: 7 destinations, 13 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.3/32 *[BGP/170] 00:05:47, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.1 via ge-0/0/0.0, Push 16, Push 299792(top)


さて、pingが通過するかどうかを確認しましょう。 



 RZN-CE1-SW2#ping 10.0.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 11/14/21 ms


当然、pingは通過しましたが、トラフィックは双方向でL3VPNを通過します。しかし、このシナリオでも、交通ルートは最適化されていると言いたいです。設定からVLAN-777ブリッジドメインを削除した場合も同じことが起こります（この場合、irb.777はVRFのままですが、IRBインターフェイスを起動するには少なくとも1つの物理インターフェイスが必要なので、ダウン状態です。 IRBインターフェースが存在するブリッジドメインのアップ状態）。



しかし、CE3からのパッケージがCE1-2に到達したという事実に落ち着き、CE1-2はこのパッケージに回答したいと考えています。ここでは、CLIからの結論なしで実行できます。



そのため、CE1-2はパケットをメインゲートウェイのアドレスに送信します。このアドレスは既に知っています。 PE1は、VLAN-1777ブリッジドメインでパケットを受信します。 L2ヘッダーのパケットの宛先アドレスはirb.1777であるため、PE1はL2ヘッダーを削除し、VRFルーティングテーブルでIPルックアップを行います。ルーティングテーブルにはホスト10.0.0.3/32へのルートがあり、上記のように、2つのルートと最適なEVPNがあります。 PE1はL2ヘッダーを変更し、ラベルを切り、パケットをPE3に送信するだけです。



PE3はパケットを受信し、VLAN-777ブリッジドメインのMACテーブルでL2ルックアップを行う必要があることを示すラベルを確認し、その情報に従って、パケットをCE3に転送します。



実際、ここでは、パッケージがCE3からCE1-2に、またはその逆に移動するときに発生するプロセス全体を調べました。しかし、これらのノード間にトラフィックがまだなく、PEルーターがMACアドレスCE1-2およびCE3を認識していないときに、プロセスを調べました。アドレスが既知になり、ルートがすべてのPEに散らばった後、トラフィックは少し異なります。最終的にトラフィックがどのように進むかを簡単に見てみましょう：



CE3からCE1-2まで：



  1. CE3からのパケットは、PE3のブリッジドメインvlan 777に分類されます。
  2. PE3は、呼び出されたVRFでIPルックアップを行い、ホスト10.0.1.1/32への特定のルートを確認します。PE3にはローカルブリッジドメインVLAN 1777がないため、EVPNルートもありません。そのため、トラフィックはPE1のL3VPNを通過します。
  3. PE1はVRFでパケットを受信し、ラベルを削除し、1777ブリッジドメイン向けであることを確認します。
  4. PE1は、ブリッジドメインvlan 1777のMACテーブルに従って、パケットをCE2-1に送信します。




これで、パッケージはCE1-2からCE3の反対方向になります。



  1. CE1-2は、応答パケットをPE1に送信します。
  2. PE1はVRFでIPルックアップを行い、ホスト10.0.0.3/32へのルートを確認します。最適なルートはEVPNルートです。
  3. PE1は、新しいL2ヘッダーをハングアップし、関連付けられたVRFのルートのEVPNに含まれる情報に従って2ラベルスタックを追加します。
  4. PE3はPE1からパケットを受信し、ラベルを削除し、VLAN-777ブリッジドメインのMACテーブルでL2ルックアップを行う必要があることを確認します。
  5. 次に、PE3はパケットをCE3に転送します。




ご覧のとおり、パケットはわずかに異なる方法で反対方向に飛行します-これは非対称転送と呼ばれます。合理的な疑問が生じる-なぜ非対称なのか？実際、入力PEはVRFでIPルックアップを実行し、EVPNのVRFによって提供されたルートに基づいてパケットを送信しますが、出力PEはVRFでパケットを受信せず、EVPNインスタンスで送信します。最後の2つのスキームを比較すると、トラフィックの対称性と非対称性がはっきりとわかります。誰もがそれがどのように機能するかを理解したと思います。



分析したスキームは、IRBインターフェイスを対称的に使用するスキームと呼ばれます（異なるベンダーはこのスキームを異なる方法で呼び出す場合があり、示された用語はBrocadeでEVPNを設定するためのマニュアルから取られます）。非対称スキームは、すべてのPEルータに同じIRBインターフェイスがある場合、このPEルータに指定されたVLANがない場合でも同じです。非対称スキームの利点は、すべてのVRFにEVPNプロトコルルート（[EVPN / 7]）があり、トラフィックがL3VPNを経由せずに直接EVPNに戻ることです。この場合、irb.1777を回線のPE3に追加すると、非対称回線になります。



しかし、強調すべき点がもう1つあります。



ご存じのように、ARP要求はブロードキャストアドレスに送信され、その応答はヘッダーで指定された送信者のMACアドレスに転送されます。



上記のケースでは、CE1-2はPE1に直接接続され、すべてが正常に機能しました。PE1はarp要求を送信し、CE1-2はそれに応答しました。実際、問題はありませんでした。ただし、CE3がパケットをCE2-2に送信した場合、イベントの展開は少し異なります。まず、すべては前述のとおりです。



  1. PE3はVRFルーティングテーブルを調べ、PE1から受信したネットワーク10.0.1.0/24へのルートを確認します。
  2. PE3には、L3VPNを介してPE1にパケットを送信する以外のオプションはありません。
  3. PE1はパケットを受信し、L3ルックアップを作成して、VLAN-1777ブリッジドメインに転送します。irb.1777はまだCE2-2 MACアドレスを知らないため、CE2-2アドレス（10.0.1.2）を解決するためにarp要求を開始し、パケットをCE1-2およびPE2に送信します。
  4. アドレス10.0.1.2がCE1-2に属していないため、CE1-2はパケットをドロップします。PE2は、受信した要求をCE2-2に転送します。
  5. CE2-2はarp要求を受け入れ、PE1のirb.1777に属するMACアドレスにユニキャストで応答します。


しかし、PE1のirb.1777はCE2-2から応答を受け取りますか？デフォルトゲートウェイ間のMACアドレスの同期を思い出します。覚えてますか？したがって、PE2のirb.1777がirb.1777 PE1のMACアドレス宛てのパケットを受信することを理解しています。その結果、PE1は、送信量に関係なく要求に対する応答を受信しません。つまり、宛先IPアドレスを解決せず、CE2-2にパケットを送信できません。 EVPNがなければ、すべてがそうなります。



PE2のirb.1777はCE2-2からarpを受信したため、vpnv4プレフィックスと同様に、タイプ2ルート（MACおよびMAC + IP）を生成します。ご理解のとおり、PE1はBGP経由でCE2-2のMACアドレスを受信し、バッファ内にあったパケットを転送できるため、arpリクエストへの応答は不要になりました。 PE2に存在するCE2-2のトラフィックは、PE1を介してPE3ループに送られることがわかります。あまり好きではありません。ループは、PE3がすでに送信していて、PE1に送信するためのキューにあったパケットのみを受信しました。しかし、PE3はVRFのCE2-2へのより具体的なルートも導入したため、将来、トラフィックはルート10.0.1.0/24に沿ってPE1を通過せず、直接PE2に（ルート10.0.1.2/32に沿って、 VRFルーティングテーブル）。



この例では、すべてのIRBインターフェイスに異なるMACアドレスがあり、デフォルトゲートウェイの同期の必要性を暗示しています。 IRBインターフェイスを使用する場合の推奨オプションは、同じブリッジドメインのすべてのPEルータで同じMACアドレスとIPアドレスを使用することです。ご存知のように、MACアドレスがすべての場所で同じで、上記で説明したようにすべてが機能する場合、実際にはデフォルトゲートウェイの同期だけは必要ありません。



最終的には、どのような状況でも、IRBインターフェースの使用方法に関係なく

、同じIPで異なるMACアドレスを使用します。

同じIPアドレスとMACアドレスを使用すると

、EVPNドメイン内のすべてのPEルーターがMAC + IPルートとBGP vpnv4プレフィックスを受信します。つまり、別のCEルーターからパケットを送信する場合、このアドレスを解決するためにarpリクエストを送信する必要はありません。これにより、プロバイダーのネットワーク上のARPフラッディングを大幅に削減できます。



他のVRFおよび外部ネットワークへのアクセス



上記では、vlane間のトラフィックの流れを調べました。しかし、evpnに接続されていない他のVRFからのアクセスはどうでしょうか？



たとえば、EVPNに関連付けられていないVRFからホスト10.0.1.1/32に到達しようとします。新しいVRFを行いたくないので、簡単に行います。PE3ではインスタンスevpnを非アクティブ化し、VRFではirb.777を非アクティブ化し、新しいインターフェイスirb.0（20.0.0.1/24）を追加します。 



 [edit] bormoglotx@RZN-PE-3# show routing-instances RZN-VPN-1 ## ## inactive: routing-instances RZN-VPN-1 ## instance-type evpn; vlan-id 777; interface ge-0/0/2.777; routing-interface irb.777; route-distinguisher 62.0.0.3:1; vrf-import VPN-1-IMPORT; vrf-export VPN-1-EXPORT; protocols { evpn { interface ge-0/0/2.777; } } [edit] bormoglotx@RZN-PE-3# show routing-instances VRF-VPN-1 instance-type vrf; interface irb.0; inactive: interface irb.777; route-distinguisher 62.0.0.3:10003; vrf-target { import target:6262:10001; export target:6262:10001; } vrf-table-label; [edit] bormoglotx@RZN-PE-3# show interfaces irb.0 family inet { address 20.0.0.1/24;


ルーティングテーブルの内容を確認します。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 active-path VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top) 10.0.1.0/24 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top) 10.0.1.1/32 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top) 10.0.1.2/32 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top) 10.0.1.22/32 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top) 20.0.0.0/24 *[Direct/0] 00:00:03 > via irb.0 20.0.0.1/32 *[Local/0] 00:00:03 Local via irb.0


32個のルートがvpnv4プレフィックスの形ですぐに到着し、ルーティングテーブルに立つことを示すために、このVRFを特に無効にしました（ご覧のように、すべてのプレフィックスのテーブル内のルートのライフタイムは3秒と同じです）。



次に、PE1の背後にあるCE1-2（10.0.1.1）でIRBインターフェイス（20.0.0.1）からpingを実行します。 



 bormoglotx@RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source 20.0.0.1 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 56 data bytes !!!!! --- 10.0.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.828/7.872/10.368/1.655 ms


次に、PE2にあるホストCE2-2 10.0.1.2に移動します。 



 bormoglotx@RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source 20.0.0.1 10.0.1.2 PING 10.0.1.2 (10.0.1.2): 56 data bytes !!!!! --- 10.0.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.443/6.713/7.342/0.656 ms


再びルートに戻り、パッケージが異なる方法で進むかどうかを確認します。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32 VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.1/32 *[BGP/170] 00:03:50, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.2/32 VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.2/32 *[BGP/170] 00:03:52, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)


したがって、10.0.1.1までのトランスポートラベルは299776であり、10.0.1.2までは299792です。このLSPを見てみましょう。

ラベル299776は62.0.0.1（PE1）へのトランスポートラベルです。 



 bormoglotx@RZN-PE-3> show route 62.0.0.1/32 table inet.3 inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 62.0.0.1/32 *[LDP/9] 03:36:41, metric 1 > to 10.62.0.5 via ge-0/0/0.0, Push 299776


ラベル299776-62.0.0.2（PE2）までの輸送ラベル： 



 bormoglotx@RZN-PE-3> show route 62.0.0.2/32 table inet.3 inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 62.0.0.2/32 *[LDP/9] 03:36:45, metric 1 > to 10.62.0.5 via ge-0/0/0.0, Push 299792


ご覧のとおり、EVPNについてまったく何も知らないVRFからでも、トラフィックは最適な方法で進みます。EVPNからVRF、ネットワーク20.0.0.0/24へのリターントラフィックは、BGPを介して受信したルートに沿って進みます。 



 bormoglotx@RZN-PE-2> show route table VRF-VPN-1.inet.0 20.0.0.0/24 active-path VRF-VPN-1.inet.0: 10 destinations, 16 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 20.0.0.0/24 *[BGP/170] 00:06:44, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.3 via ge-0/0/0.0, Push 16, Push 299808(top)


VRF（irb.0 20.0.0.1）からEVPN（CE1-2 10.0.1.1）へのパケットパス：



リターントラフィックルート：



ただし、提示されているケースは単純です-ホスト10.0.1.1および10.0.1.2へのルートは既にルーティングテーブルにありました。ホストへのルートがない場合はどうなりますか？ここでは、すべてが最初のケースと同じように機能します（宛先ホストが存在するPEルータにブリッジドメインがない場合）。たとえば、現在特定のルートがない10.0.0.2に到達しましょう。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.2/32 bormoglotx@RZN-PE-3>


本当にルートはありませんが、10.0.0.0 / 24へのルートがあります。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.0/24 | match \/24 10.0.0.0/24 *[BGP/170] 00:13:14, localpref 100, from 62.0.0.255


トラフィックがこのルートを通るのは論理的です。pingを実行し、すべてが機能することを確認します：

bormoglotx @ RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source source 20.0.0.1 10.0.0.2 



 PING 10.0.0.2 (10.0.0.2): 56 data bytes !!!!! --- 10.0.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 6.135/7.206/7.806/0.663 ms


pingは正常に渡され、VRFでホスト10.0.0.2/32へのルートが取得されました。 



 bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.2/32 VRF-VPN-1.inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.2/32 *[BGP/170] 00:00:06, localpref 100, from 62.0.0.255 AS path: I, validation-state: unverified > to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)


それがどのように機能するかご理解いただければ幸いです。



まだ必要なのはなぜですか？



私の友人の一人がこのテクノロジーと呼んでいます-薬物中毒。 IRBインターフェースを使用するためのアルゴリズムは、作業の観点からだけでなく、なぜそれが必要なのかという観点からもわかりにくく、理解しにくい可能性があります。しかし、MPLSについて初めて聞いたとき、この技術は完全に理解されていたことを思い出してください。それはありそうもないと思います。



しかし、VPLSと同じようにできないのはなぜですか？ L3インターフェースの使用が上記で解決する問題について考えてみましょう。 EVPNは本質的にデータセンターを接続するように設計されました。単純なクライアントVPLSとは異なり、データセンターからのトラフィックは非常にまともです。したがって、次の場合を検討してください。







PE2にあるVPLSからの出口ポイントが1つあり、CE1がL3VPNに接続され、CE2がVPLSドメインに接続されているとします。ここで重要なことは、これらのグリッドは両方とも同じデータセンターに存在するが、それらの間のトラフィックはこのループを通過することです。





まず、サーバー2からのトラフィックは、PE2にあるVPLSドメインの出口に行き、PE2からL3VPNを介してPE1に戻ります。これらの2つのサーバーでさえ、同じスイッチに含まれたり、データセンター内の同じキャビネットに置かれたりする可能性があります。はい、これが何らかのトラフィックの少量である場合、手放します-おそらく、ここではゲームはろうそくの価値がありません。しかし、ビデオのストリーミング、FTPサーバーからのコンテンツのダウンロードなどの場合はどうでしょうか？次に、このトラフィック量はすべて、ネットワークのコアを介して2倍になり、帯域幅が本質的に「偽の」トラフィックで詰まるだけです。 L3 EVPN機能が解決するのはこのタスクです。ホストへの/ 32ルートを生成してVRFに渡すことにより、EVPNは異なるネットワーク間のトラフィックのフローを最適化します。上記のスキームでEVPNを使用する場合、PE1はserver1への/ 32ルートを生成しますトラフィックはPE1をローカルに通過し、コア全体をループしません。





そして、これはほんの一例です...



おわりに



ご覧のとおり、EVPNは単なるレベル2テクノロジーではありません。ルーティングとスイッチングは、このテクノロジーに深く統合されています。さらに、クライアントL2サービスを単純​​にリークしている場合、VRFへの統合で上記のスキームを使用する必要はありません。



ただし、この世界のすべての費用を支払う必要があり、EVPNも例外ではありません。技術が複雑で混乱しているという事実は問題ではありません、あなたはそれを理解する必要があります（結局、VPLSがかつて暗い森のように見えたとき-今ではすべてが論理的で理解できるように見えます（私にとっては））。問題の1つは、多数の/ 32とタイプ2の多数のルートであり、どちらが非現実的であるかを理解することができます。たとえば、サイズ/ 24の4つのネットワークがあると推定しましょう。大まかに言えば、これらは250のホストを持つネットワークです。すべてのホストが互いに通信するようにしたい場合は、1000ルート/ 32（250ルート/ 32と各ネットワークのタイプ2/24）を取得します。そして、そのようなドメインが10個ある場合は？その後、すでにマスク/ 32の10,000ルートがネットワーク上を飛行し、コントロールプレーンをロードします。さらに、仮想化システムを備えた最新のデータセンターの現実におけるこれらの数値は、記事に記載されている数値よりも2〜3桁大きくなります。ルートリフレクターは、グループエクスポートポリシーで許可されているすべてのルートをニューロンに送信することがわかっています。たとえば、リフレクターとのvpnv4セッションを持つトポロジにPE4ルーターを追加すると、リフレクターから10,000ルートすべてを受信しますが、実際には必要ありません。当然、PE4はRTを見てアナウンスを破棄しますが、この作業によりREプロセッサもロードされます。これに関するRFCの推奨事項はありません。ジュニパーネットワークスは、目的のアナウンスのみを受信するために、アドレスのルートターゲットファミリを使用することを推奨しています。しかし、私の実践では、この一連のアドレスからは、これまでのところ問題しか受けていません。ルーティングリフレクターは、グループエクスポートポリシーで許可されているすべてのルートをニューロンに送信すること。たとえば、リフレクターとのvpnv4セッションを持つトポロジにPE4ルーターを追加すると、リフレクターから10,000ルートすべてを受信しますが、実際には必要ありません。当然、PE4はRTを見てアナウンスを破棄しますが、この作業によりREプロセッサもロードされます。これに関するRFCの推奨事項はありません。ジュニパーネットワークスは、目的のアナウンスのみを受信するために、アドレスのルートターゲットファミリを使用することをお勧めします。しかし、私の実践では、この一連のアドレスからは、これまでのところ問題しか受けていません。ルーティングリフレクターは、グループエクスポートポリシーで許可されているすべてのルートをニューロンに送信すること。たとえば、リフレクターとのvpnv4セッションを持つトポロジにPE4ルーターを追加すると、リフレクターから10,000ルートすべてを受信しますが、実際には必要ありません。当然、PE4はRTを見てアナウンスを破棄しますが、この作業によりREプロセッサもロードされます。これに関するRFCの推奨事項はありません。ジュニパーネットワークスは、目的のアナウンスのみを受信するために、アドレスのルートターゲットファミリを使用することをお勧めします。しかし、私の実践では、この一連のアドレスからは、これまでのところ問題しか受けていません。その後、彼はリフレクターから10,000のルートすべてを受信しますが、実際には必要ありません。当然、PE4はRTを見てアナウンスを破棄しますが、この作業によりREプロセッサもロードされます。これに関するRFCの推奨事項はありません。ジュニパーネットワークスは、目的のアナウンスのみを受信するために、アドレスのルートターゲットファミリを使用することをお勧めします。しかし、私の実践では、この一連のアドレスからは、これまでのところ問題しか受けていません。その後、彼はリフレクターから10,000のルートすべてを受信しますが、実際には必要ありません。当然、PE4はRTを見てアナウンスを破棄しますが、この作業によりREプロセッサもロードされます。これに関するRFCの推奨事項はありません。ジュニパーネットワークスは、目的のアナウンスのみを受信するために、アドレスのルートターゲットファミリを使用することをお勧めします。しかし、私の実践では、この一連のアドレスからは、これまでのところ問題しか受けていません。



他のすべてに対して、単純な質問に答えます：ルーティングにMACアドレスが使用されないのはなぜですか？実際、IPv4アドレスとは異なり、より多くのMACアドレスがあり、グローバルに一意であり、ブロードキャストアドレスとマルチキャストアドレスの両方があり、プライベート（機器メーカーに関係なく管理者によって正確に手動で割り当てられた）MACアドレスもあります。使用-したくない！しかし、何らかの理由で、IPはNATなどのすべての松葉杖で使用されます。最も重要な理由の1つは、IPアドレスとは異なり、MACアドレスがサブネットに集約されないことです。このアドレスブロックが発行されるアドレスまたは組織の場所、および1つまたは別のメーカーに属する機器の場所。その結果、理論的にはMACアドレスは集約に役立つことがわかりましたが、生きているネットワークではこれを行うことはできませんたとえば、MACアドレス04：01：00：00：01：01はフロリダの海岸のどこかにある鉄片に属し、MACアドレスが04：01：00：00：01：02の金属片はリャザンに既にあるためです。



現在、FVには600,000以上の集約ルートがあります。 / 32個のアドレスのみがルーティングに使用された場合、ルーティングテーブルのサイズを想像してください。なぜこれについて書いているのですか？実際には、約10万のMACアドレスがある5-6のデータセンターが接続されている場合、EVPNルートのみを分散するためにコントロールプレーンにどのような負荷がかかるか想像してください（同じ量の/ 32については黙っています）。この問題には、たとえばPBBの使用などの解決策がありますが、彼らが言うように、これは完全に異なる話です...



誰かがより深く掘り下げることに興味がある場合、このトピックに関する情報へのリンクがあります：



→ 変更の全履歴を含む直接RFC 7432自体 ;

→ジュニパーEVPN;

→ジュニパーEVPN IRB ;

→Cisco EVPN PBB ;

→Cisco EVPN VXLAN ;

→Brocade EVPN。



SDSMの以前のすべての問題へのリンク：
12. . . . MPLS L2VPN

11.1. . №6. MPLS L3VPN

11. . . MPLS L3VPN

10. . . MPLS

9. . .

8.1 . №3. IBGP

8. . . BGP IP SLA

7. . . VPN

6. . .

5. : . NAT ACL

4. : . STP

3. : .

2. . パート2

1. . パート1 cisco

0. . .


著者から



記事の執筆、さまざまな機能のテスト、RFCおよびさまざまなベンダーから入手可能なその他の資料（シスコとジュニパーだけに限定されない）を読むのに2か月以上かかりました。ご覧のとおり、テストはジュニパーでのみ実施されました。他のベンダーでは、一部の機能の実装が上記のものとわずかに異なる場合があります。この記事が読者にとって明確で有用であることを願っています。記事にタイプミスや間違いを見つけた場合は、PMに連絡してください。さて、見てくれてありがとう...


More articles:


All Articles