day one: データセンターの相互接続でのイーサネット vpn ......day one...

ジュニパープルーフオブコンセプトラボ（POC）

EVPN は、相互接続されたデータセンターで起きるネットワークの課題に対応する新しい標準ベースのテクノロジです。POC ラボトポロジーで行われる EVPN のテストでは、すべての構成から始めて、検証手順に移り、高可用性テストで終わります。本書では、あらゆることを学習し、反復できます。

ヴィクター・ガンジアン

DAY ONE: データセンターの相互接続でのイーサネット VPN の使用

Juniper Networks Books は、ネットワークの生産性と効率性に特化しています。ライブラリ全体の詳細については、www.juniper.net/books をご覧ください。

発行：Juniper Networks Books

DAY ONE: データセンターの相互接続でのイーサネット VPN の使用

今日の仮想化されたデータセンターは、通常、エンドユーザーへのアプリケーションの配信パフォーマンスが最適になり、サイトに障害が起きてもアプリケーションの可用性が高く保たれるように地理的に分散されたサイトに配置されます。これらのメリットを実現するには、仮想マシン（VM）が異なるサイト間を動的に移行できるように、レイヤー 2 接続をデータセンター間で拡張することが必要になります。これを、データセンター相互接続（DCI）といいます。DCI をサポートするには、仮想マシン間のトラフィックフローが移行前後で最短のパスで確実に転送され、すべての利用可能なリンクの帯域幅が有効に利用され、リンクまたはノードで障害が発生した場合にネットワークが迅速に復旧し、ダウンタイムを最小限に抑えられるように、基盤となるネットワークを頼りにすることにもなります。

EVPN は、相互接続されたデータセンターのネットワーク要件に対応することに特化された属性を持つ新しいテクノロジです。そして、『Day One:データセンターの相互接続でのイーサネット VPN の使用』は、ジュニパーのプルーフオブコンセプトラボ（POC ラボ）がお届けする、その名のとおりのプルーフオブコンセプト（コンセプトの証明）です。ここには、サンプルのトポロジー、あらゆる構成、検証テスト、いくつかの高可用性テストを掲載しています。

ISBN 978-1941441046

9 781941 441046

5 1 6 0 0

「EVPN は、最近、IETF が RFC 7432 として公開した標準です。その公開後わずか数日で、専門の Day One ブックが完成しました。ヴィクター・ガンジアンが執筆した本書は、データセンタービジネスを計画、導入、拡張するすべての人に役立ちます」

ジョン E. ドレイク、ジュニパーネットワークスディスティングイッシュドエンジニア、

『 RFC 7432:EVPN』共同執筆者

「イーサネット VPN（EVPN）は、サービスプロバイダや企業などの収益に直接影響を与える幅広いメリットをもたらします。ただし、新しいプロトコルを採用する場合は常に困難がつきまといます。この Day One ブックでは、EVPN の高度なコンセプトがどのように役立つかを示し、実用的なネットワークを作成するためにダウンロードできる検証済みの構成を提供しているため、EVPN テクノロジを容易に採用することができます。これは、EVPN テクノロジの学習と導入を検討しているすべてのエンジニアにとって必読書です」

サチン・ナトゥ、ジュニパーネットワークス、製品管理担当ディレクター

ヴィクター・ガンジアン

Day One:データセンターの相互接続でのイーサネット VPN の使用

第 1 章 :イーサネット VPN（EVPN）について . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

第 2 章：EVPN の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

第 3 章：検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

第 4 章：高可用性テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

おわりに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

© 2015 by Juniper Networks, Inc. All rights reserved. Juniper Networks、Junos、Steel-Belted Radius、NetScreen、および ScreenOS は、米国およびその他の国における Juniper Networks, Inc. の登録商標です。ジュニパーネットワークスのロゴ、Junos ロゴ、および JunosE は Juniper Networks, Inc. の商標です。文書に掲載されているその他の商標、サービスマーク、登録商標、登録サービスマークはすべて各所有者に帰属します。ジュニパーネットワークスは、本文書の一切の誤りについて責任を負いかねます。ジュニパーネットワークスは、事前の通知なく本文書を変更、修正、移転、改訂する権利を保持します。発行：Juniper Networks Books著者：ヴィクター・ガンジアンテクニカルレビュア -：スコット・アスター、ライアン・ビックハート、ジョン E. ドレイク、プラサンタ・グディパティ、ラッセル・ケリー、マット・メリン、ブラッド・ミッチェル、サチン・ナトゥ、ニティン・シング、ラメーシュ・ヤクカラ編集長：パトリック・エイムズ編集および校正：ナンシー・ケーベルイラストレーター：カレン・ジョイスJ-Net コミュニティ管理人：ジュリー・ワイダー

ISBN：978-1-936779-04-6（書籍）米国内発行：Vervante Corporation 社ISBN：978-1-936779-05-3（電子書籍）

バージョン履歴：v1、2015 年 3 月 2 3 4 5 6 7 8 9 10

著者紹介：ヴィクター・ガンジアンは現在、マサチューセッツ州ウエストフォードにあるジュニパープルーフオブコンセプトラボのシニアデータネットワークエンジニアを務めています。20 年にわたり、IP ルーティングとイーサネットスイッチングに関連するさまざまな技術に関する理解、設計、設定、テスト、トラブルシューティングにおいて、企業とサービスプロバイダのお客様を支援してきました。マサチューセッツ州メドフォードにあるタフツ大学で、電気工学の学士と修士号を取得しています。

著者謝辞：まず、本書の大幅な品質向上につながる有益なフィードバックをいただいたテクニカル・レビュアーの皆様に心よりお礼を申し上げます。また、私がこのテクノロジを理解する際に、数々の急な電話会議やメールでのやり取りで EVPN 関連の質問に答えてくれた、ジュニパーシステムテストグループのプラサンタ・グディパティ、ジュニパーデベロップメントエンジニアリングの EVPN の技術リードであるニティン・シングとマノイジュ・シャルマに感謝いたします。本書の作成にあたりアドバイスとご支援をいただいたパトリック・エイムズ編集長、編集および校正を担当されたナンシー・ケーベル氏、イラストレーターのカレン・ジョイス氏にも深くお礼を申し上げます。そして、いつも私を支え、本書の執筆に携わる機会を与えてくれたウェストフォード POC ラボの同僚に感謝いたします。

最後に、私が本書を完成するために必要な時間とスペースを確保できるよう、絶えずサポートし、励まし、根気強く見守ってくれた家族に感謝の言葉を送ります。

本書は、次のサイトからさまざまな形式でダウンロードできます。 http://www.juniper.net/dayone

iv

http://www.juniper.net/dayone

Day One へようこそ

本書は Juniper Networks Books が制作・発行する人気の Day One ブックライブラリの一冊です。

Day One ブックは、一日で必要な情報を理解できるように企画されたものです。このシリーズでは、Junos OS とジュニパーネットワークスの要点を、簡単な説明、ステップバイステップの手順、そしてわかりやすい実践例によって解説します。

Day One ライブラリには、わずかにボリュームの大きい This Week ブックも収録され、そのコンセプトとテストベッドのサンプルは 1 週間のセミナーにほぼ相当します。

いずれのシリーズも複数の形式でダウンロードできます。

無料の PDF 版は http://www.juniper.net/dayone でダウンロードできます。

iTunes ストアからは、iPhone および iPad 用の電子書籍版を入手できます。Juniper Networks Books で検索してください。

ご使用のデバイスの Kindle アプリを開いて Kindle ストアにアクセスすると、Kindle アプリが稼働するすべてのデバイス（Android、Kindle、iPad、PC または Mac）用の電子書籍版を入手できます。Juniper Networks Books で検索してください。

紙書籍版の価格はページ数に応じて 12～ 28 ドルで、Vervante Corporation 社（www.vervante.com）で購入できます。

Nook、iPad、さまざまな Android アプリでも PDF ファイルを表示できます。

v

http://www.juniper.net/dayonehttp://www.vervante.com

vi

このガイドの対象読者

本書は、他の VPN テクノロジの経験があり、複数のデータセンターの相互接続に関連するプロジェクトでの EVPN の使用を評価するために EVPN の機能を学ぶことに関心のあるネットワークエンジニアを対象にしています。本書が最も役立つのは、EVPN ネットワークの設計を担当するネットワークアーキテクトや EVPN ネットワークの保守を担当する管理者です。

本書を読む前に知っておくべきこと

本書を読む前に、操作コマンドを使ったり、Junos の設定を読み取って、理解し、変更するといった、Junos オペレーティングシステムの基本的な管理機能を使い慣れている必要があります。

本書では、読者についていくつかのことを想定しています。読者が次の要件を満たしていない場合、本書のチュートリアルや説明がラボでうまくいかないことがあります。

イーサネットスイッチングと IP ルーティングプロトコルの機能について高度な知識を持っている。

IP コアネットワーキングの知識を持ち、OSPF、MP-BGP、MPLS などのルーティングプロトコルを一緒に使用して、さまざまなタイプの VPN サービスを実装する方法を理解している。

RFC 4364 ベースの IP VPN や VPLS など、他の VPN テクノロジの知識を持っている。多くの EVPN コンセプトは IP VPN に由来するため、IP VPN はとりわけ重要で、トラフィックをルーティングするために、IP VPN は EVPN と併せて使用してします。

Day One ライブラリ（www.juniper.net/dayone）には、Junos の学習や MPLS、EVPN、IP ルーティングに関する本が多数揃っています。

本書を読んで学べること

この Day One ブックでは、EVPN の内部の機能について詳細に説明します。読み終えた時点で、EVPN の基盤となるテクノロジとメリットを概念的に理解していることでしょう。さらに、ネットワークで EVPN の設計、導入、保守を確実に行うために必要な実践的な知識を得ることもできます。


vii

完全な構成の入手

この POC ラボ Day One ブックで使用されている全デバイス用の構成ファイルは、本書のランディングページ（http://www.juniper.net/dayone）で入手できます。また、Day One Web サイトにログオンしない読者のために、Dropbox ダウンロード（https://dl.dropboxusercontent.com/u/18071548/evpn-configs.zip）も設定しました。この URL は、著者が管理しているものではないため、この本の出版期間中に変更されることがあります。

ジュニパーネットワークスプルーフオブコンセプト（POC）ラボ

ジュニパーワールドワイド POC ラボは、マサチューセッツ州ウェストフォードとカリフォルニア州サニーベールにあります。ラボには経験豊かなネットワークエンジニアのチームが配属され、フィールドセールスエンジニアおよびそのお客様と協力し、ジュニパー製品の特定の機能のデモやパフォーマンスのテストを行います。ネットワークのトポロジーとテストは、お客様ごとに固有の要件に基づいてカスタマイズされます。

用語

以下は、参考用、あるいは他のベンダーの装置からジュニパーネットワークスに移行するお客様向けの EVPN 関連の頭字語と用語のリストです。

BFD：Bidirectional Forwarding Detection（双方向フォワーディング検出）。近接または隣接する既知のルーティングプロトコル間で障害を迅速に検出するために使用される、シンプルな「Hello」プロトコルです。

BUM：Broadcast, Unknown unicast, and Multicast traffic（ブロードキャスト、宛先不明のユニキャスト、マルチキャストトラフィック）。原則として、複数宛先のトラフィックです。

DF：Designated Forwarder（代表フォワーダ）コアから CE へ BUM トラフィックの転送を担当する EVPN PE。

ES：Ethernet Segment（イーサネットセグメント）。CE デバイスと 1 台または複数の PE デバイス間のイーサネットリンク。マルチホームトポロジーでは、CE と PE 間のリンクのセットが単一の「イーサネットセグメント」と見なされます。各 ES には識別子が割り当てられます。

viii

ESI：Ethernet Segment Identifier（イーサネットセグメント識別子）。ES を示す、0x00 から 0xFFFFFFFFFFFFFFFFFFFF までの 10 オクテット値。CE デバイスが 2 台以上の PE に対してマルチホームである場合、ESI にはネットワーク内で一意、かつ予約済みでない値が設定される必要があります。シングルホーム CE の場合、予約済みの ESI 値である 0 が使用されます。「すべて FF」の ESI 値も予約済みです。

EVI：EVPN Instance（EVPN インスタンス）。EVPN サービスを作成する PE で定義されます。

イーサネットタグ識別子：EVPN インスタンス内のブロードキャストドメインを識別します。今回、ブロードキャストドメインは VLAN なので、イーサネットタグ識別子は VLAN ID になります。

IP VPN：BGP/MPLS IP VPN（RFC 4364）を使用して実装されるレイヤー 3 VPN サービス。

LACP：Link Aggregation Control Protocol（リンクアグリゲーション制御プロトコル）。複数のリンクまたはポートを単一の論理インターフェイスに束ねる管理および制御に使用されます。

LAG：Link Aggregation Group（リンクアグリゲーショングループ）。

MAC-VRF：MAC address Virtual Routing and Forwarding（MAC アドレス仮想ルーティングおよびフォワーディング）テーブル。これは、PE の EVI 用レイヤー 2 フォワーディングテーブルです。

MP2MP：Multipoint to Multipoint（マルチポイントツーマルチポイント）。

P2MP：Point to Multipoint（ポイントツーマルチポイント）。

PMSI：Provider Multicast Service interface（プロバイダマルチキャストサービスインターフェイス）。CE を宛先とする、同一 VPN 内の CE からリモート PE までのマルチキャストパケット配信に使用される PE の論理インターフェイス。

イーサネット VPN（EVPN とも略記されます）は、IP または IP/MPLS バックボーンネットワーク上の異なるレイヤー 2 ドメイン間に仮想マルチポイントブリッジ接続を提供する、標準準拠の新しいテクノロジです。IP VPN や VPLS などの他の VPN テクノロジと同様に、EVPN インスタンス（EVI）は、PE ルーターで顧客間での論理サービスの分離が維持されるように構成されます。PE は、イーサネットリンク上のルーター、スイッチ、またはホストになる CE デバイスに接続します。PE ルーターはマルチプロトコル BGP（MP-BGP）を使用してリーチャビリティ情報を交換し、カプセル化された顧客トラフィックが PE 間で転送されます。アーキテクチャの要素が他の VPN テクノロジと共通であるため、既存のサービス環境に EVPN をシームレスに導入し、統合することができます。

EVPN の特徴は、コントロールプレーンにおいて PE 間で MAC アドレスの学習が行われることです。新しい MAC アドレスが CE から検出されると、ローカルの PE によってすべてのリモート PE に MP-BGP MAC ルートを通じてアドバタイズされます。この方法は VPLS などの既存のレイヤー 2 VPN ソリューションとは異なります。既存の方法では、データプレーンで unknown ユニキャストをブラッディングして、MAC アドレスの学習を実行します。このコントロールプレーンベースの MAC の学習方法は、仮想レイヤー 2 ネットワーク上できめ細かな制御を可能し、本書で説明する EPVN の多くの優れた機能を実現する重要な要素になります。

第 1 章

イーサネット VPN（EVPN）について

10 Day One：データセンターの相互接続でのイーサネット VPN の使用

図 1.1 EVPN コントロールプレーンのハイレベル概説

サービスプロバイダや企業は、EVPN を使用して顧客に次世代型のレイヤー 2 VPN サービスを実装および提供することができます。EVPN は、E-LINE、E-LAN、E-TREE などの異なるトポロジーを使用して導入できる柔軟性を備えています。これにより、耐障害性、ロードバランシング、効率的な帯域利用の分野における既存のソリューションの限界を克服する、CE デバイスと PE デバイス間のマルチホーミングのオールアクティブモードを実現できます。コントロールプレーンベースの MAC 学習により、通信事業者は EVPN サイト間のレイヤー 2 MAC アドレス学習を制御するポリシーを適用でき、データプレーンで使用できるカプセル化のタイプに応じた多くの選択肢を提供することもできます。

EVPN の統合ルーティング /ブリッジング（IRB）機能では、顧客エッジノード間のレイヤー 2 およびレイヤー 3 接続が両方ともサポートされ、レイヤー 3 ゲートウェイ機能も組み込まれています。EVPN では、ホストとゲートウェイの両方の MAC および IP アドレス情報を MAC ルートに追加することで、データセンター内およびデータセンター間でサブネット内およびサブネット間の転送が最適化されます。この機能は、レイヤー 2 VPN、レイヤー 3 VPN、またはダイレクトインターネットアクセス（DIA）のサービスを提供し、既存顧客にクラウドによるコンピューティングやストレージの追加サービスを提供したいと考えるサービスプロバイダに特に役立ちます。

追加情報この Day One ブックの作成中に、申請されていた『BGP MPLS ベースのイーサネット VPN』のドラフト仕様が、IETF によって標準として採用され、RFC 7432 として公開されました。この文書は、http://tools.ietf.org/html/rfc7432/ で確認できます。EVPN の要件の詳細については、http://tools.ietf.org/html/rfc7209 を参照してください。

http://tools.ietf.org/html/rfc7432/http://tools.ietf.org/html/rfc7432/http://tools.ietf.org/html/rfc7209http://tools.ietf.org/html/rfc7209

第 1 章：イーサネット VPN（EVPN）について 11

DCI 対応 EVPN

EVPN はクラウドおよび仮想化サービスを提供するデータセンターを構築する通信業者が直面する多くの課題に対応し、現在、多くの注目を集めています。EVPN が主に利用されるのは、レイヤー 2 接続を異なるデータセンター間に拡張するデータセンター相互接続（DCI）です。地理的に多様なデータセンターは、通常、エンドユーザーへのアプリケーション配信のパフォーマンスが最適化され、サイトに障害が起きてもアプリケーションの可用性が高く保たれるように導入されます。

EVPN が対応する DCI 要件には、次のようなものがあります。

アクティブ /アクティブリンクをサポートする CE と PE 間のマルチホーミング

サービスの迅速な復旧

仮想マシン（VM）の移行または MAC モビリティのサポート

最適な転送パスを使用するレイヤー 3 ルーティングの統合

データセンターサイト間の複数宛先のトラフィックの帯域幅利用の最小化

複数のデータプレーンカプセル化のサポート

オールアクティブマルチホーミング

EVPN はオールアクティブマルチホーミングをサポートします。これにより、1 台の CE デバイスと複数の PE ルーターとの接続が可能になり、トラフィックはデバイス間のすべてのリンクを使用して転送されます。このため、CE で複数の PE ルーターに対するトラフィックの負荷分散が可能になります。さらに重要なことは、エイリアシングが可能になることです。つまり、リモート PE が複数のマルチホーム PE のうちたった 1 台の宛先しか学習していない場合でも、コアネットワーク上のマルチホーム PE に対してトラフィックの負荷を分散できるのです。また、EVPN には、オールアクティブマルチホームトポロジーでの BUM トラフィックのループを防ぐメカニズムも備わっています。


図 1.2 エイリアシングの概要

EVPN は、1 台の CE と 1 台の PE のみがリンクされる、シングルアクティブマルチホーミングもサポートします。これは、CE デバイスがすべてのマルチホームリンクにわたってトラフィックの負荷を分散できない場合や、ASIC の制限により PE デバイスが BUM トラフィックのループを防げない状況で使用できます。また、シングルアクティブマルチホーミングでは、既存の VPLS 導入から EVPN への移行も容易になります。

サービスの迅速な復旧

マルチホーミングは、アクセスリンクや PE ルーターの 1 台に障害が発生した際に冗長性を提供します。いずれの場合も、CE から PE へのトラフィックは、残存するアクティブなリンクを使用して転送されます。その他の宛先のトラフィックについては、各リモート PE でフォワーディングテーブルが更新され、トラフィックがマルチホームイーサネットセグメントに接続する残りのアクティブな PE に送信されます。EVPN は高速コンバージェンスメカニズムを備えているため、リモート PE の収束にかかる時間は、PE が学習した MAC アドレスの数に左右されません。

MAC モビリティ

データセンターでは、通常、コンピューティングの仮想化が採用され、稼働中の仮想マシンはハイパーバイザ間を動的に移動することができます。これをワークロードマイグレーションといいます。EVPN の MP-BGP コントロールプレーンでは MAC モビリティがサポートされ、PE で仮想マシンの MAC アドレスの移動を追跡できます。そのため、PE には常に MAC アドレスに関する最新のリーチャビリティ情報が保持されます。


例えば、仮想マシンは、同じデータセンター内またはリモートのデータセンターで別の PE ルーターを介して移動するように、移行先のハイパーバイザに移動することができます。移行が完了すると、仮想マシンはイーサネットパケットを送信し、ソース MAC アドレスの学習に基づいて、新しい PE の EVPN レイヤー 2 フォワーディングテーブルが更新されます。そして、PE が MAC ルートの更新をすべてのリモート PE に送信すると、次々とリモート PE のフォワーディングテーブルが更新されます。続いて、仮想マシンにとって当初ローカルだった PE は、それまでアドバタイズしていた MAC ルートを取り消します。

最適な転送パスを使用したレイヤー 3 ルーティングの統合

EVPN を使用すると、EVPN インスタンスの VLAN に関する IRB インターフェイスの構成を通じて、レイヤー 3 ルーティングをレイヤー 2 ドメインに統合することができます。そして、IRB インターフェイスは PE の IP VPN に配置されます。EVPN にあるホストは IRB インターフェイスをデフォルトゲートウェイとして使用します。これは、データセンター外の宛先や IP VPN の VRF を使用する他のデータセンターのサブネットへのルーティングに使用できます。

所定の PE 上で構成されている IRB IP と MAC アドレスは、EVPN のメンバーであるすべてのリモート PE によって共有されます。これをデフォルトゲートウェイの同期といいます。これは、仮想マシンが違う場所のデータセンターに移行する場合に役に立ちます。この場合、仮想マシンにとってローカルである PE は、学習されたデフォルトゲートウェイに代わってプロキシ ARP を実行し、仮想マシンのアウトバウンドトラフィックを宛先に向けて直接ルーティングします。このため、仮想マシンの元のデータセンターにあるデフォルトゲートウェイへトラフィックをバックホールする必要がなくなります。

また、PE は、ARP パケットや DHCP パケットをスヌーピングして、EVPN データセンターホストの IP アドレスを動的に学習します。次に、MAC ルートの更新を通じて、対応するホストルートをリモート EVPN PE にアドバタイズします。これをホストの MAC/IP の同期といいます。これにより、リモート EVPN PE は非対称 IRB フォワーディングを使用して、所定の宛先ホストにトラフィックを効率的にルーティングできるようになります。この実装では、コアにパケットを送信する前にレイヤー 2 ヘッダーが受信 PE によって書き換えられ、宛先の PE がパケットを転送する際にレイヤー 3 ルックアップをバイパスできます。


同様に、学習されたホストの IP アドレスも、VPN ルートの更新を通じて PE によってリモート IP VPN PE にアドバタイズされます。よって、リモート IP VPN PE はデータセンターホストに最も近い PE にトラフィックを転送できるようになります。インバウンドルーティングを最適化するこの方法は、MAC モビリティにも適用できます。例えば、仮想マシンが別のデータセンターに移行した場合に、移行先のデータセンターにある PE は、ARP スヌーピングによって新しいホストを学習し、VPN ルートの更新を IP VPN のすべてのメンバーに送信します。リモート IP VPN PE は、フォワーディングテーブルを更新し、仮想マシンの新しいデータセンターにある PE に直接トラフィックを転送できるようになります。これにより、仮想マシンの元のデータセンターにトラフィックをバックホールする必要がなくなります。

コアの BUM トラフィックの最小化

EVPN には、コアの BUM トラフィックの量を最小限に抑えるための機能がいくつか備わっています。まず、PE ルーターはデータセンターホストとデフォルトゲートウェイの IP アドレスを動的に学習するプロキシ ARP を実行します。これにより、データセンターサイト間の ARP トラフィックの量を軽減できます。さらに、EVPN では、サイト間で P2MP や MP2MP LSP などのマルチキャスト配信方法を効率的に共有して使用できます。

データプレーンの柔軟性

最後に、MAC 学習はコントロールプレーンで処理されることから、EVPN では PE 間でさまざまなデータプレーンカプセル化テクノロジを柔軟にサポートすることができます。特にイーサネットネットワークにおいては、コアで MPLS が実行されていない場合に EVPN を実装できるようになるため、これはとても重要です。代替となるデータプレーンカプセル化の一例に、GRE トンネルの使用があります。GRE トンネルは、カプセル化が必要な場合に IPSEC を使用してセキュリティーを確保することもできます。

追加情報 GRE トンネルを使用する EVPN DCI の詳細な例については、『Day One:Building Dynamic Overlay Service-Aware Networks』（ラッセル・ケリー著）の第 7 章を参照してください。この書籍は、Day One ライブラリ（http://www.juniper.net/dayone）、iTunes、Amazon で入手できます。

本書のテストネットワークでは、RSVP-TE 信号ラベルスイッチパス（LSP）を使用する IP/MPLS コアが、PE 間のトラフィックの転送に使用されています。コアでの MPLS テクノロジの使用が十分に理解され、導入された場合、高速再ルート（FRR）やトラフィックエンジニアリングなどの固有のメリットをすべて、特別な構成を追加することなく EVPN ネットワークに適用できます。



他のアプリケーション - NVO を使用した EVPN

EVPN は、シンプルな IP アンダーレイネットワーク上にネットワーク仮想化オーバーレイ（NVO）ソリューションが実装されたデータセンターのコントロールプレーンに最適です。NVO データセンター内の EVPN は、異なるハイパーバイザと物理ホスト上で稼働する仮想マシン間に仮想レイヤー 2 接続を実現します。トラフィックとアドレス空間を分離するマルチテナント要件は、1 つまたは複数の VLAN を別々の EVI にマッピングすることでサポートされます。

データプレーンでは、GRE カプセル化を用いる VXLAN、NVGRE、または MPLS を使用するネットワークオーバーレイトンネルを使用できます。この場合、VXLAN トンネルエンドポイント（VTEP）などのオーバーレイトンネルエンドポイントが PE に相当し、ハイパーバイザの vSwitch/vRouter や、トンネルエンドポイントゲートウェイの機能をサポートする物理ネットワークのデバイス上で稼働します。

このアプリケーションと EVPN DCI を組み合わせることで、異なるデータセンターに存在する仮想マシンと物理ホスト間でレイヤー 2 接続を拡張できます。各データセンターでは、オーバーレイトンネルが PE（または WAN エッジ）ルーター上の EVI で直接終端となります。そこで EVPN が実質的にサイト間のトンネルを「つなぎ合わせる」ことになります。

EVPN 実装の準備

ここまでで、EVPN が DCI で起きるネットワークの課題の多くにどのように対応しているかよく理解できたと思います。こうしたすべての EVPN 機能のしくみについて、興味をお持ちいただければ幸いです。

次の章では、テストネットワークトポロジーを検討し、EVPN の構成について詳しく説明します。次に、EVPN の動作を詳しく調べ、それが正常に機能しているかどうかを検証します。これはご自身のラボ作業で非常に役に立つでしょう。最後に、高可用性テストを実施し、EVPN トラフィックフローに対するリンクとノードの障害の影響を理解します。

テストが終了した時点では、参考にできる稼働中のネットワーク構成に加えて、EVPN の機能をしっかりと理解できていることでしょう。この知識を利用すれば、EVPN ネットワークの設計、テスト、トラブルシューティングを確実に行うことができます。

さあ、ラボに入りましょう。

この章ではまず、さまざまなデバイスとホストに対応できるように、テストネットワークトポロジーについて説明します。次に、EVPN の構成に進みます。不明な略語については、「用語」セクションを参照してください。

テストネットワーク

以下のセクションでは、EVPN DCI デモテストネットワークの構築に使用するコンポーネントについて説明しています。コンポーネントは、3 つのグループ（コア、アクセス、ホスト）に分かれています。

コア

コアの PE ルーターと P ルーターには、14.1R4 のプレリリースバージョンを実行するさまざまなモデルのジュニパー MX ルーターを使用します。ルーター PE11 と PE12 はデータセンター 1（DC1）に、ルーター PE21 と PE22 はデータセンター 2（DC2）に、PE31 はリモートサイトに配置します。リモートサイトは、仮想化されたサーバーやストレージなど、データセンター固有のデバイスがない一般的な場所に相当します。これは、支社サイトや、クライアントがデータセンターにアクセスする他のイントラネットサイトである可能性もあります。

第 2 章

EVPN の構成


図 2.1 テストネットワーク

第 2 章：EVPN の構成 19

IP/MPLS コアは、単一の自律型システムです。すべてのコアインターフェイスで OSPF が有効になっており、すべてのコアルーター間で IP 接続が実現しています。サイト間の顧客トラフィックを転送するために、すべての PE 間でフルメッシュの RSVP-TE LSP が構成されています。PE は、P1 ルートリフレクタを使用した MP-iBGP セッションを通じて、EVPN と IP VPN のプロトコルファミリーに対応したリーチャビリティ情報を交換します。実際の導入シナリオでは、冗長性のある構成でルートリフレクタを使用することが推奨されますが、この場合は単純化するために 1 台のルートリフレクタが使用されます。

データセンターにある PE は、2 つの EVPN インスタンス（EVI）で構成されています。1 つ目の EVI は VLAN 100 にマップされ、2 つ目の EVI は VLAN 200～ 202 にマップされています。DC2 の「VLAN 222」は表記ミスではありません。ローカル PE は、EVI で定義された VLAN ID 202 を、データセンターで使用される VLAN ID 222 に変換します。

各 PE では、IRB インターフェイスがそれぞれの VLAN に応じて構成され、その VLAN のホストのデフォルトゲートウェイに相当します。IRB インターフェイスの IP アドレスと MAC アドレスは、各データセンターの PE のセットと同じものです。各 VLAN に対応する IRB インターフェイスの構成は、EVI の構成時点でわかりますが、データセンター全体で同じである場合も、そうでない場合もあります。

各データセンターの PE は、IRB インターフェイスをすべて含む単一の IP VPN インスタンスを使用して構成されます。リモートサイトの PE31 も IP VPN のメンバーです。このため、PE は EVPN とリモートサイトのホスト間でトラフィックをルーティングすることができます。

各データセンターの PE のペアはそれぞれ共通の ESI で構成され、マルチホーミングをサポートします。この場合、ESI モードはオールアクティブに設定されます。つまり、CE に接続されるリンクは、トラフィックの負荷分散が可能になるように両方ともアクティブになるということです。

アクセス

各データセンターに 1 台の CE デバイスがあります。具体的に言うと、Junos バージョン 14.1X53-D10.4 が稼働する QFX5100-48S です。CE は、レイヤー 2 VLAN を使用して、PE とホストの EVI アクセスインターフェイス間を接続するように構成されています。CE は、異なる PE にそれぞれ終端がある 2 つのアップリンクから成る LAG バンドルを使用して構成されています。本書のトポロジーでは、すべてのリンクは常にアクティブになっています。


重要事項 EVPN をテストするために独自のネットワークを構築する場合は、この Day One ブックで使用されているデモネットワークを、自分で計画した設計に合うように、あるいは自分のラボで使用できるハードウェアを基準に適用することができます。例えば、P1 ルーターを取り除いたり、PE の 1 台をルートリフレクタにしたり、ルートリフレクタを冗長性のある構成にしたりすることもできます。冗長な PE でデータセンターを 1 か所のみ構成したり、アクセスレイヤーで LAG をサポートするデバイスを使用したりすることもできます。おわかりでしょうか。まず、本書の構成セクションと検証セクションを詳細に読んで、EVPN の機能を理解することをお勧めします。その後、ご自身のラボのネットワークに戻って実験することができます。本書はラボのトポロジーで簡単に再現できるように書かれているので、十分な装置がなくてもまったく問題はありません。

ホスト

テストネットワークでは、エミュレートされたホストと実際のホストの組み合わせが使用されています。各 Ixia テスターポートは、各データセンターの 4 つの VLAN でそれぞれ単一の IP ホストをエミュレートします。例外は Ixia 9/12 ポートです。これは VLAN 100 にあり、4 台のホストをエミュレートします。データセンターホストはそれぞれ、ローカル PE の EVI VLAN 上の IRB インターフェイスに対応するデフォルトゲートウェイを使用して構成されています。さらに、Ixia テスターポートは PE31 に接続され、リモートのホストやデバイスに相当します。

ラボのメモ Ixia インターフェイスは、IxOS 6.70.1050.14 EA-Patch2 が稼働する Ixia XM12 シャーシに搭載されています。IxNetwork アプリケーションのバージョン 7.31.911.19 EA は、ローカル PE のデフォルトゲートウェイを使用して、Ixia テスターインターフェイスをエミュレートされたホストとして構成するために使用されます。IxNetwork は、トラフィックフローの生成や、第 4 章の高可用性テストの実行時に復旧時間を測定するための統計の表示にも使用されます。

DC1 と DC2 にある Server 1 と Server 2 は、両方とも VMware ESXi 5.0 が稼働する Dell PowerEdge R815 サーバーです。各サーバーは、ローカルデータセンターの CE デバイスに接続されています。2 台の仮想マシンはそれぞれ CentOS を実行し、いつでもいずれかのサーバーに存在することができます。1 つ目の仮想マシンは VLAN 100 のホストとして構成され、2 つ目の仮想マシンは VLAN 201 のホストとして構成されています。これらの仮想マシンは、MAC モビリティに関連する EVPN のさまざまな機能を検証するために、VMware vMotion を使用してサーバー間を移動します。各サーバーは、NFS プロトコルを使用する共通のストレージエリアネットワーク（SAN）にも接続されています。これは、vMotion が正常に機能するために必要です。


構成

PE11 の構成に注目しましょう。他のデータセンターの PE の構成もよく似ているので、他の PE の構成要素についても適宜説明します。必要に応じて、図 2.1 を参照してください。

注 CLI に構成を直接コピーして貼り付けられるように、本書のカットアンドペースト版が用意されています。これは本書のランディングページ（http://www.juniper.net/dayone）のみから入手できます。

システム

MX は Trio チップベースの FPC でのみサポートされているため、EVPN では、MX が enhanced-ip モードで実行されている必要があります。この変更を実行した後には再起動が必要です。

chassis { network-services enhanced-ip;}

コア

コアネットワークの構成では、IP のリーチャビリティをアドバタイズおよび学習するすべてのインターフェイスで OSPF を、PE 間のデータ転送には RSVP-TE LSP による MPLS を、EVPN と IP VPN のシグナリングには MP-BGP を使用します。

1.まず、ルーター番号（ここでは 11）に基づくループバックインターフェイスを設定します。

interfaces { lo0 { unit 0 { family inet { address 11.11.11.11/32; } } }}

2.ループバックインターフェイスを基にグローバルルーター ID と BGP に使用する自律システム番号を定義します。

routing-options { router-id 11.11.11.11; autonomous-system 65000;}



3.コアインターフェイス（xe-1/2/0 と ae1 ）を構成します。インターフェイスがラベル付きパケットを送受信できるように、IP アドレスを割り当て、MPLS を有効にします。

chassis { aggregated-devices { ethernet { device-count 2; } }}

interfaces { xe-1/1/0 { gigether-options { 802.3ad ae1; } } xe-1/2/0 { unit 0 { family inet { address 10.11.1.11/24; } family mpls; } } xe-2/0/0 { gigether-options { 802.3ad ae1; } } ae1 { aggregated-ether-options { lacp { active; } } unit 0 { family inet { address 10.11.12.11/24; } family mpls; } }}

4.次に、ループバックとコアのインターフェイスで、OSPF、MPLS、RSVP プロトコルを有効にします。OSPF の下で、トラフィックエンジニアリングデータベース（TED）を作成する traffic-engineering を有効にします。TED は、後で RSVP-TE を使用してシグナリングと確立が行われる各 LSP のパスを決定するのに使用されます。


protocols { rsvp { interface xe-1/2/0.0; interface lo0.0; interface ae1.0; } mpls { interface ae1.0; interface xe-1/2/0.0; } ospf { traffic-engineering; area 0.0.0.0 { interface ae1.0; interface xe-1/2/0.0; interface lo0.0; } }}

5.その他の PE にそれぞれ LSP を作成します。これらの LSP は、EVPN サービスと IP VPN サービスの両方で使用されます。

protocols { mpls { label-switched-path from-11-to-12 { from 11.11.11.11; to 12.12.12.12; } label-switched-path from-11-to-21 { from 11.11.11.11; to 21.21.21.21; } label-switched-path from-11-to-22 { from 11.11.11.11; to 22.22.22.22; } label-switched-path from-11-to-31 { from 11.11.11.11; to 31.31.31.31; } }

6.最後に、ループバックアドレスが 1.1.1.1. である P1 に MP-BGP を構成します。ループバックアドレス間でセッションを確立するため、local-address を明示的に設定することは重要です。デフォルトでは、ネイバーに一番近いインターフェイスの IP アドレスが使用されます。

EVPN と IP VPN のプロトコルファミリーは、PE で構成されているサービスインスタンスに応じて設定されます。また、ルーターに障害が発生した場合にすばやく検出するために、BFD を有効にします（「第 4 章高可用性テスト - ノードの障害」のテストケースを参照してください）。


protocols { bgp { group Internal { type internal; family inet-vpn { any; } family evpn { signaling; } neighbor 1.1.1.1 { local-address 11.11.11.11; bfd-liveness-detection { minimum-interval 200; multiplier 3; } } } }}

アクセス

PE11 には、CE 10 に接続する単一のアクセスインターフェイスがあります。このインターフェイスは、異なる EVPN インスタンス（EVI）にマップされる複数の VLAN をやり取りします。この場合、EVI ごとに論理インターフェイスが構成されます。unit 100 にはインスタンス EVPN01 にマップされる VLAN 100 が 1 つ、unit 200 にはインスタンス EVPN-2 にマップされる VLAN が 3 つ含まれます。

EVPN マルチホーミングに必要な ESI は、10 オクテット値がネットワーク全体で一意である必要があります。EVPN の仕様によれば、最初のオクテットがタイプを表し、残りの 9 オクテットが ESI 値になります。現在、Junos では、10 オクテットのすべてに任意の値を設定できます。

このラボネットワークでは、ESI の第 1 バイトに 00 を設定します。これは、ESI 値の残りの 9 オクテットが静的に設定されることを意味します。マルチホーミングピア PE である PE 12 には、まったく同じ ESI 値を設定する必要があります。1 台の CE と 1 台の PE の間に単一の接続しかない場合、ESI はデフォルト値である 0 になります。

CE と PE の間で両方のマルチホームリンクが常にアクティブであることを示すには、オールアクティブのマルチホーミングモードを構成します。これにより、CE からリモート PE へのトラフィックが、2 台のマルチホーム PE の間で負荷分散されます。

注常に 1 つのマルチホームリンクだけがアクティブになるシングルアクティブモードもサポートされています。


アクセスインターフェイスは、リンクメンバーが単一の LAG として構成されます。その理由は、インターフェイスの初期化を制御するのに、アクセスレイヤーで LACP を有効にすることが望ましいためです。この構成は、物理インターフェイスレベルで設定されるホールドアップタイマーとともに使用され、リンクまたはノードの復旧の際にパケットの損失を最小限に抑えます。このメカニズムは、「第 4 章高可用性テスト」で実際に確認します。

LAG が正常に機能するためには、マルチホーム PE の両方の system-id に同じ値を設定する必要があります。これで CE が 1 台のデバイスに接続されているように見せかけ、LACP ネゴシエーションが成功します。

ここで重要な点は、PE11 ルーターと PE12 ルーターが、ESI 値に基づいてそれぞれのマルチホームリンクを識別することです。LAG の構成は、EVPN マルチホーミングから完全に独立しています。PE と CE の間に単一のリンクがある場合は必要ありません。例えば、ESI と VLAN が LAG のない xe-1/0/0 インターフェイスで構成されていたとしても、EVPN マルチホーミングソリューションはそのまま機能します。LAG 構成は、リンクがアップした場合のアクセスネットワークの耐障害性の向上を目的としています。

このラボトポロジーでは、それぞれの PE と CE の間にあるリンクは 1 つですが、LAG にバンドルされた複数リンクからなる構成もサポートされます。このような場合、各マルチホーム PE に共通する静的システム ID を含めて、それぞれの PE と CE の間に LAG を構成する必要があります。CE が LACP をサポートする場合は、リンクの両端で有効にする必要があります。

interfaces { xe-1/0/0 { hold-time up 180000 down 0; gigether-options { 802.3ad ae0; } }

ae0 { flexible-vlan-tagging; encapsulation flexible-ethernet-services; esi { 00:11:11:11:11:11:11:11:11:11; all-active; } aggregated-ether-options { lacp { system-id 00:00:00:00:00:01; } }


unit 100 { encapsulation vlan-bridge; vlan-id 100; family bridge; } unit 200 { family bridge { interface-mode trunk; vlan-id-list [ 200 201 202 ]; } } }}

以下の CE10 の構成は、LACP が有効な LAG バンドルとしてマルチホームリンクが構成されていることを示します。

interfaces { xe-0/0/0 { hold-time up 180000 down 0; ether-options { 802.3ad ae0; } } xe-0/0/1 { hold-time up 180000 down 0; ether-options { 802.3ad ae0; } } ae0 { aggregated-ether-options { lacp { active; } } unit 0 { family ethernet-switching { interface-mode trunk; vlan { members all; } } } }}


サービス

MX シリーズ用 Junos は、現在、2 つのタイプの EVPN サービス（VLAN ベースバンドルと VLAN アウェアバンドル）をサポートしています。VLAN ベースサービスは、単一のブリッジドメインにマップされる単一の VLAN をサポートします。VLAN アウェアバンドルサービスは、独立した VLAN および IP サブネットスペースで複数のテナントをサポートするため、最も代表的で推奨される DCI の導入オプションです。

これらのサービスは両方とも VLAN 変換をサポートします。つまり、異なる VLAN ID を異なるサイトで使用できます。PE ルーターは、ローカル VLAN ID とイーサネットタグ識別子（サービスで使用される VLAN ID）間の変換を行います。

各 VLAN は、VLAN 間のルーティングのために、EVI のホストに対応するデフォルトゲートウェイとして動作する IRB インターフェイスを使用して構成されます。IRB インターフェイスは、VLAN 間ルーティングができるように共通の IP VPN に配置されます。IP VPN では、他のデータセンター以外のネットワークとの往復ルーティングも可能です。

このラボネットワークでは、単一の IP VPN サービスが構成されています。実際には、レイヤー 3 トラフィックを分離するために、IP VPN VRF または inet.0 テーブルごとに異なる IRB インターフェイスを使用することができます。また、セキュリティーポリシーを適用するためにファイアウォールがデフォルトゲートウェイとして使用される場合など、レイヤー 3 統合機能が不要な EVPN を使用することもできます。

次の表 2.1 は、構成されたサービスとその詳細を示しています。ここでは、EVPN DCI ソリューションの機能を検証するために、さまざまな構成が使用されることがわかります。

表 2.1 EVPN サービスと IPVPN サービス

サービス名サービスタイプ VLAN 構成のメモ

EVPN-1 EVPN - VLAN ベース 100 DC1 と DC2 の PE は、同じデフォルトゲートウェイを使用して構成されています。

EVPN-2 EVPN - VLAN アウェアバンドル

200 DC1 と DC2 の PE は、同じデフォルトゲートウェイを使用して構成されています。

201 DC1 と DC2 の PE は、異なるデフォルトゲートウェイを使用して構成されています。

202 DC1 と DC2 の PE は、同じデフォルトゲートウェイを使用して構成されています。DC2 の PE は、正規化されたサービス VLAN ID 202 と DC2 のローカル VLAN ID 222 との間で VLAN を変換します。

IPVPN-1 IP VPN - VRF DC1 と DC2 のすべての PE とリモートサイトの PE31 で構成されています。


EVPN-1

EVPN-1 は VLAN ベース EVPN サービスであるため、instance-type evpn を使用して構成されます。異なる EVI 間でルーティングが重複しないように、ネットワーク全体で一意の値をルート識別子（RD）に設定する必要があります。推奨されるのはタイプ 1 RD で、値フィールドは、PE の IP アドレス（通常はループバックアドレス）の後に PE に固有の数値が続く値で構成されます。この場合、RD はルーティングインスタンスの下に設定されますが、代わりに routing-options route-distinguisher-id 設定を使用して、競合が発生しない RD を自動的に割り当てることができます。

vrf-target（ルートターゲット拡張コミュニティ）は、PE の EVI ルーティングテーブルへの MP-BGP ルート配信の制御に使用されます。ここには、AS 番号の後に EVPN サービスに固有の識別子が続く値が入ります。この場合のルートターゲットは、特定の EVI に関するすべてのデータセンター PE で同じ値に設定されます。

アクセスインターフェイス ae0.100 の VLAN 100 は、サービスにマップされた単一の VLAN です。これは、IRB インターフェイスである irb.100 を使用して構成されます。この IRB インターフェイスは、VLAN と静的 MAC アドレスに対応するデフォルトゲートウェイの IP アドレスを使用して構成されます。この場合、DC1 と DC2 の両方にあるすべての PE が、同じ IP アドレスと MAC アドレスを使用して構成されます。そのため、この EVI ではデフォルトゲートウェイの同期が不要であり、evpn default-gateway do-not-advertise 設定によって、PE は IRB に対応する MAC/IP バインディングをアドバタイズしないように指定されます。

ベストプラクティス構成を単純化し、コントロールプレーンの負担を軽減し、PE ノードに障害が起きた場合に復旧時間を最小限に抑えるために、所定の EVPN VLAN のすべての PE に同じ IP アドレスと MAC アドレスを設定します。

routing-instances { EVPN-1 { instance-type evpn; vlan-id 100; interface ae0.100; routing-interface irb.100; route-distinguisher 11.11.11.11:1; vrf-target target:65000:1; protocols { evpn { default-gateway do-not-advertise; } } }}


interfaces { irb { unit 100 { family inet { address 100.1.1.1/24; } mac 00:00:00:01:01:01; } }}

EVPN-2

EVPN-2 は VLAN アウェアバンドル EVPN サービスであるため、instance-type virtual-switch を使用して構成します。ルート識別子は一意の値に設定され、ルートターゲットはこの EVI に対応するトポロジー内のすべてのデータセンター PE で同じ値に設定されます。

VLAN 200～ 202 は、サービスにマップされているアクセスインターフェイス ae0.200 で構成されます。3 つの VLAN は bridge-domains でルーティングインスタンス内に構成されます。各 VLAN は、正規化 VLAN ID と IRB インターフェイスを使用して構成されます。extended-vlan-list は、すべての VLAN がコア全体で拡張されることを示しています。

ベストプラクティス EVI が単一の VLAN のみにマップされている場合でも、VLAN アウェアバンドルサービスを構成してください。このサービスは最も柔軟で、将来、EVI に VLAN を追加する必要が起きるなど、サービスを変更する場合に移行が容易になります。

VLAN 200 の irb.200 インターフェイスは、DC1 と DC2 の両方のすべての PE の同じデフォルトゲートウェイの IP アドレスと MAC アドレスを使用して構成されます。これは、前述の EVPN-1 VLAN 100 の構成と同様です。

VLAN 201 の irb.201 インターフェイスは、各データセンターで異なるデフォルトゲートウェイ IP アドレスと MAC アドレスを使用して構成されます。DC1 の 2 台の PE のデフォルトゲートウェイは、IP アドレス 201.1.1.1 と MAC アドレス 0xc9:01:01:01 を使用して構成されます。DC2 の 2 台の PE のデフォルトゲートウェイは、IP アドレス 201.1.1.2 と MAC アドレス 0xc9:01:01:02 を使用して構成されます。VLAN 201 のホストに相当する Ixia テスターポートは、図 2.1 のように、ローカルデータセンターのデフォルトゲートウェイを使用して構成されます。また、VLAN 201 の仮想マシンのホストは、最初は DC1 にあり、201.1.1.1 のデフォルトゲートウェイを使用して構成されます。「第 3 章：検証」では、この仮想マシンが DC2 に移動され、DC2 の PE ルーターが仮想マシンから受け取ったトラフィックをルーティングするかどうかを検証します。


routing-instances { EVPN-2 { instance-type virtual-switch; interface ae0.200; route-distinguisher 11.11.11.11:2; vrf-target target:65000:2; protocols { evpn { extended-vlan-list 200-202; default-gateway advertise; } } bridge-domains { V200 { vlan-id 200; routing-interface irb.200; } V201 { vlan-id 201; routing-interface irb.201; } V202 { vlan-id 202; routing-interface irb.202; } } }}

interfaces { irb { unit 200 { family inet { address 200.1.1.1/24; } mac 00:00:c8:01:01:01; } unit 201 { family inet { address 201.1.1.1/24; } mac 00:00:c9:01:01:01; } unit 202 { family inet { address 202.1.1.1/24; } mac 00:00:ca:01:01:01; } }}


VLAN 202 の irb.202 インターフェイスは、DC1 と DC2 の両方のすべての PE で同じデフォルトゲートウェイの IP アドレスと MAC アドレスを使用して構成されます。ただし、VLAN 変換を実証するために、DC1 で使用する VLAN ID は 202 にし、DC2 で使用する VLAN ID は 222 にします。この場合、DC2 の PE は、EVI で定義されたイーサネットタグ識別子（VLAN ID）を CE20 で解釈されたローカルの VLAN ID に変換します。これは、PE21 と PE22 のアクセスインターフェイスの構成にある vlan-rewrite パラメータを使用して行われます。

interfaces { ae0 { flexible-vlan-tagging; encapsulation flexible-ethernet-services; esi { 00:22:22:22:22:22:22:22:22:22; all-active; } aggregated-ether-options { lacp { system-id 00:00:00:00:00:02; } } unit 100 { encapsulation vlan-bridge; vlan-id 100; family bridge; } unit 200 { family bridge { interface-mode trunk; vlan-id-list [ 200 201 202 ]; vlan-rewrite { translate 222 202; } } } }}

IPVPN-1

instance-type vrf を使用する、IPVPN-1 という名前の単一の IP VPN インスタンスは、各 PE ルーターで構成されます。このサービスインスタンスにはデータセンター PE 上のすべての EVPN VLAN の IRB インターフェイスが含まれ、ローカル VRF には EVPN VLAN に対応する IP サブネットが追加されます。


図 2.2 EVPN IRB の IP VPN への配置

さらに重要なのは、PE が IRB を使用して構成される EVPN VLAN で新しいホスト IP アドレスを学習するたびに、対応するホストルートを VRF に自動的に追加することです。このホストルートはすべてのリモート PE にアドバタイズされ、他の EVPN VLAN やリモートサイトからのホスト宛てのトラフィックを最適に転送することができます。これについては、「第 3 章：検証 - レイヤー 3 の動作」で詳しく説明します。

routing-instances { IPVPN-1 { instance-type vrf; interface irb.100; interface irb.200; interface irb.201; interface irb.202; route-distinguisher 11.11.11.11:111; vrf-import IpVpnDiscardEvpnSubnets; vrf-export IpVpnAddCommunities; vrf-table-label; }}

IPVPN-1 ルーティングインスタンスのルート識別子は、トポロジーの各 PE でネットワーク全体で一意の値に設定されます。データセンター PE では、vrf-export ポリシーが、必要な VRF ルートターゲットコミュニティ（アドバタイズされるルートに対応する COMM-IPVPN-1）に加えて、コミュニティ COMM-EVPN を設定するように構成されています。これによって、実際にすべての EVPN サブネットとホストに対応する IP VPN ルートがタグ付けされます。EVPN MAC/IP アドバタイズメントルートにより同じルートが学習されているため、データセンター PE は、コミュニティ COMM-EVPN を使用する IP VPN を受け取っても、vrf-import ポリシーの reject によってそれを拒否します。冗長な IP VPN ルートを破棄することで、VRF テーブルエントリの数は少なくなります。これについては、「第 3 章：検証 - レイヤー 3 の動作」で詳しく説明します。


policy-options { prefix-list PL-EVPN { 100.1.1.0/24; 200.1.1.0/24; 201.1.1.0/24; 202.1.1.0/24; } policy-statement IpVpnAddCommunities { term 10 { from { prefix-list-filter PL-EVPN orlonger; } then { community add COMM-EVPN; community add COMM-IPVPN-1; accept; } } term 100 { then accept; } } policy-statement IpVpnDiscardEvpnSubnets { term 10 { from community COMM-EVPN; then reject; } term 100 { from community COMM-IPVPN-1; then accept; } } community COMM-EVPN members 65000:1234; community COMM-IPVPN-1 members target:65000:101;}

PE31 の構成

PE31 のローカル xe-0/1/0.0 インターフェイスは、IP サブネット 31.1.1/24 に対応し、IPVPN-1 に含まれます。データセンター PE からの PE 31 が受け取るすべての IP VPN ルートには、COMM-IPVPN-1 コミュニティと COMM-EVPN コミュニティの両方が含まれます。PE31 の IPVPN-1 ルーティングインスタンスは、ルートターゲットコミュニティの target:65000:101 を使用するすべてのルートを受け入れるように構成されているため、これらの IP VPN ルートをすべて VRF に配置します。COMM-EVPN コミュニティの 65000:1234 はまったく無視されます。


routing-instances { IPVPN-1 { instance-type vrf; interface xe-0/1/0.0; route-distinguisher 31.31.31.31:101; vrf-target target:65000:101; vrf-table-label; }}

PE31 は、データセンターの 2 台のマルチホーム PE から、所定のデータセンターホストの IP VPN ルートを受け取る場合があります。 2 台のデータセンター PE へのトラフィックの負荷を分散するには、PE31 の BGP の multipath を load-balance per-packet ポリシーと合わせて有効にします。これにより、Junos は、パケットフォワーディングエンジン（PFE）の BGP を通じて学習した所定の宛先に複数のネクストホップを設定できます。

bgp { group Internal { type internal; family inet-vpn { any; } multipath; neighbor 1.1.1.1 { local-address 31.31.31.31; bfd-liveness-detection { minimum-interval 200; multiplier 3; } } }}

policy-options { policy-statement lb { then { load-balance per-packet; } }}

routing-options { router-id 31.31.31.31; autonomous-system 65000; forwarding-table { export lb; }}


デフォルト構成

Junos リリース 14.1R4 以降、EVPN に必要な負荷分散と Chained Composite ネクストホップ機能が自動的に構成されるようになりました。

エイリアシングは、オールアクティブマルチホーミング構成の PE のペアに宛てたトラフィックフローの負荷分散を可能にする EVPN 機能です。例えば、PE11 が DC2 の宛先にトラフィックを送信する場合、PE21 と PE22 の両方が同じイーサネットセグメント（CE デバイス）に接続されていれば、トラフィックの負荷分散が可能です。エイリアシングは、EVPN VLAN 間のレイヤー 2 およびレイヤー 3 のトラフィックフローに適用されます。これについては、「第 3 章：検証」で詳しく説明します。

Chained Composite ネクストホップは、非対称 IRB フォワーディングと呼ばれるプロセスを使用して、異なる PE ごとに接続された EVPN VLAN 上のホストやデバイス間でトラフィックを効率的にルーティングするために必要です。本来、Chained Composite ネクストホップは、パケットで複数のネクストホップアクションを実行できるようにするものです。この場合、受信 PE が元のパケットのイーサネットヘッダーを書き換えて、フォワーディングする前に適切な MPLS ラベルをプッシュします。これにより、宛先 PE は送信時に VRF テーブルルックアップをバイパスできます。この機能については、「第 3 章：検証」の「レイヤー 3 の動作 – VLAN 間ルーティング」セクションで詳しく説明します。

デフォルト構成は、以下の CLI コマンドを使用して確認できます。

cse@PE11> show configuration routing-options forwarding table | display inheritance defaults #### ‘evpn-pplb’ was inherited from group ‘junos-defaults’##export evpn-pplb;#### ‘chained-composite-next-hop’ was inherited from group ‘junos-defaults’##chained-composite-next-hop { ## ## ‘ingress’ was inherited from group ‘junos-defaults’ ## ingress { ## ## ‘evpn’ was inherited from group ‘junos-defaults’ ## evpn; }}


cse@PE11> show configuration policy-options | display inheritance defaults#### ‘evpn-pplb’ was inherited from group ‘junos-defaults’##policy-statement evpn-pplb { ## ## ‘from’ was inherited from group ‘junos-defaults’ ## ## ## ‘evpn’ was inherited from group ‘junos-defaults’ ## from protocol evpn; ## ## ‘then’ was inherited from group ‘junos-defaults’ ## then { ## ## ‘load-balance’ was inherited from group ‘junos-defaults’ ## ‘per-packet’ was inherited from group ‘junos-defaults’ ## load-balance per-packet; }}

テストトポロジーで EVPN が構成されました。次は動作を検証しましょう。まず IP/MPLS コアで、サービスの基盤を提供するプロトコルが想定どおり機能していることを確認します。そして、EVPN サービスと IP VPN サービスが正しい状態にあり、トラフィックを転送する準備が整っていることを確認します。CLI から EVPN マルチホーミングの内部動作を詳しく調べて、EVPN と IP VPN のフォワーディングテーブルが設定される様子を理解し、ユニキャストとマルチキャストのトラフィックがどのように転送されるのかを学習します。その途中で、エイリアシングやレイヤー 3 トラフィックパスの最適化などの主要な機能を実証するトラフィックフローが生成されます。目標は、EVPN の多くの便利な機能を可能にする基本メカニズムを理解することです。

コア

コア内の動作は、他の VPN サービスの動作に似ています。ではさっそく、OSPF、BGP、RSVP-TE を含むさまざまな IP プロトコルが正常に稼働しているかどうか検証してみましょう。

まず、OSPF 隣接状態が Full であることを確認します。ここに問題があると、他のプロトコルも動作しません。以下は、PE11 の出力です。

cse@PE11> show ospf neighborAddress Interface State ID Pri Dead10.11.12.12 ae1.0 Full 12.12.12.12 128 3910.11.1.1 xe-1/2/0.0 Full 1.1.1.1 128 31

第 3 章

検証


次に、P1 への MP-BGP セッションの状態が確立（Established）されていることを確認します。サービスが正しく構成されていれば、IP VPN と EVPN のプライマリルーティングテーブルが、bgp.l3vpn.0 と bgp.evpn.0 としてそれぞれ表示されます。テーブルには、ルートリフレクタから受け取るすべてのルートが含まれます。さらに、セカンダリルーティングテーブルとして IPVPN-1.inet.0、EVPN-1.evpn.0、EVPN-2.evpn.0、__default_evpn__.evpn.0 が表示されます。P1 への BGP ベースの BFD セッションが Up であることも確認します。

cse@PE11> show bgp summaryGroups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendingbgp.l3vpn.0 21 21 0 0 0 0bgp.l3vpn.2 0 0 0 0 0 0bgp.evpn.0 46 46 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...1.1.1.1 65000 3187 3066 0 0 22:47:31 Establ bgp.l3vpn.0: 21/21/21/0 bgp.l3vpn.2: 0/0/0/0 bgp.evpn.0: 46/46/46/0 IPVPN-1.inet.0: 1/21/21/0 EVPN-1.evpn.0: 14/14/14/0 EVPN-2.evpn.0: 34/34/34/0 __default_evpn__.evpn.0: 1/1/1/0

cse@PE11> show bfd session Detect TransmitAddress State Interface Time Interval Multiplier1.1.1.1 Up 0.600 0.200 3

1 sessions, 1 clientsCumulative transmit rate 5.0 pps, cumulative receive rate 5.0 pps

PE11 からすべてのリモート PE への LSP が Up であることを確認します。同様に、PE11 で終端となっているリモート PE からの LSP も Up になっているはずです。

cse@PE11> show mpls lspIngress LSP: 4 sessionsTo From State Rt P ActivePath LSPname12.12.12.12 11.11.11.11 Up 0 * from-11-to-1221.21.21.21 11.11.11.11 Up 0 * from-11-to-2122.22.22.22 11.11.11.11 Up 0 * from-11-to-2231.31.31.31 11.11.11.11 Up 0 * from-11-to-31Total 4 displayed, Up 4, Down 0

第 3 章：検証 39

Egress LSP: 4 sessionsTo From State Rt Style Labelin Labelout LSPname11.11.11.11 22.22.22.22 Up 0 1 FF 3 - from-22-to-1111.11.11.11 12.12.12.12 Up 0 1 FF 3 - from-12-to-1111.11.11.11 31.31.31.31 Up 0 1 FF 3 - from-31-to-1111.11.11.11 21.21.21.21 Up 0 1 FF 3 - from-21-to-11Total 4 displayed, Up 4, Down 0

Transit LSP: 0 sessionsTotal 0 displayed, Up 0, Down 0

アクセス

では、PE11 と CE10 の間のインターフェイスが up になり、LACP が正常にネゴシエートされているかどうかを検証しましょう。ここに問題があると EVI が初期化できないので重要です。

cse@PE11> show interfaces terse | match ae0xe-1/0/0.100 up up aenet --> ae0.100xe-1/0/0.200 up up aenet --> ae0.200xe-1/0/0.32767 up up aenet --> ae0.32767ae0 up upae0.100 up up bridgeae0.200 up up bridgeae0.32767 up up multiservice

cse@PE11> show lacp interfaces ae0Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-1/0/0 Actor No No Yes Yes Yes Yes Fast Passive xe-1/0/0 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State xe-1/0/0 Current Fast periodic Collecting distributing

マルチホーミング

マルチホーミングは、データセンターネットワークの設計における重要な要件です。その理由は、マルチホーミングが備えている耐障害性によって、ノードやリンクに障害が起きた場合に必要なアプリケーションを確実に稼動させ続けることができるからです。また、PE と CE 間のすべてのリンクにおける双方向トラフィックを負荷分散し、BUM トラフィックの転送を最適化してレイヤー 2 のブロードキャストストームを防ぐことによって、帯域を効率的に利用することもできます。EVPN のこれらの特徴を可能にするメカニズムは、以下のセクションで説明します。


イーサネットセグメントの検出

第 2 章で説明したように、マルチホーミングは、アクセスインターフェイスの ESI 値を 2 台の PE で同じ値に設定することで構成されます。これによって、各マルチホーム PE から MP-BGP イーサネットセグメントルートのアドバタイズメントが開始され、自動的に相互検出が可能になります。

ES ルート（NLRI ルートタイプ 4）には、次の重要なフィールドが含まれています。

送信元ルーターの IP アドレス – アドバタイズ元 PE のループバックアドレス

ESI – ネットワーク全体で一意の 10 バイトのイーサネットセグメント識別子

ES インポートルートターゲット拡張コミュニティ - ESI から自動的に派生

EVPN の仕様によると、ES ルートは同じ ES に接続されている PE でしか受け入れることができません。そのため、ルートを受け入れる PE は、ES インポートコミュニティを評価して、同じ ES に接続されているマルチホームピア PE から送信されたルートかどうかを判断します。

ES インポートコミュニティは、9 バイトの ESI 値のうち 6 バイトのみをエンコードします。2 つの異なる ESI 値が同じ ES インポートコミュニティにひもづけられる可能性はありますが、それでもこの最初の段階でのフィルタリングによって、PE が処理する必要のあるルート数は大幅に減ります。その後、PE が代表フォワーダ（DF）を選択する際に、完全な ESI 値にマッチさせることができます（詳細は次のセクションを参照してください）。

ラボの例 – ES ルート

では、ラボのトポロジーの例に移りましょう。以下に示されているように、ES ルートは PE12 から PE11 に受け渡されます。この場合、es-import-target 値 11-11-11-11-11-11 は PE 11 で構成された ESI と一致しているため、PE11 は ES ルートを受け入れます。同様に、PE12 は PE11 の ES ルートアドバタイズメントを受け入れます。データセンター 2 の PE は、ES インポートコミュニティがローカルで構成されている ESI と一致していないため、これらのルートを破棄します。また、このラボのトポロジーでは、各データセンターにマルチホーム PE のペアがありますが、3 台以上のマルチホーム PE による構成もサポートされます。

cse@PE11> show route table bgp.evpn.0 detail | find “4:\1”4:12.12.12.12:0::111111111111111111:12.12.12.12/304 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 12.12.12.12:0 Next hop type: Indirect Address: 0x95c606c Next-hop reference count: 25 Source: 1.1.1.1

第 3 章：検証 41

Protocol next hop: 12.12.12.12 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: Local AS: 65000 Peer AS: 65000 Age: 20:37:39 Metric2: 1 Validation State: unverified Task: BGP_65000.1.1.1.1+179 AS path: I (Originator) Cluster list: 1.1.1.1 Originator ID: 12.12.12.12 Communities: es-import-target:11-11-11-11-11-11 Import Accepted Localpref: 100 Router ID: 1.1.1.1 Secondary Tables: __default_evpn__.evpn.0

All EVPN NLRI タイプ 4 ルートも、特定の EVI に対応するルートターゲットコミュニティを含まないため、セカンダリ __default_evpn__.evpn.0 テーブルに保存されています。以下の出力は、ローカル PE から送信されたタイプ 4 ES ルートと、PE12 から送信されて受け入れたルートを示しています。

cse@PE11> show route table __default_evpn__.evpn.0 | find 4:4:11.11.11.11:0::111111111111111111:11.11.11.11/304 *[EVPN/170] 04:40:23 Indirect4:12.12.12.12:0::111111111111111111:12.12.12.12/304 *[BGP/170] 04:40:04, localpref 100, from 1.1.1.1 AS path: I, validation-state: unverified > to 10.11.12.12 via ae1.0, label-switched-path from-11-to-12

代表フォワーダ

マルチホームピアのセットが互いに検出されると、PE の中から 1 台が、その ES の代表フォワーダ（DF）として選択されます。DF は、コアからの CE へのブロードキャスト、unknown ユニキャスト、マルチキャスト（BUM）トラフィックの送信を担当します。DF ではなくバックアップフォワーダである PE は、コアから受信した CE 宛ての BUM トラフィックをドロップします。

ラボの例 - DF

ラボトポロジーからの PE11 の EVPN-1 インスタンス情報は、PE11 が代表フォワーダ（Designated forwarder）であり、PE12 がバックアップフォワーダ（Backup forwarder）であることを示しています。

cse@PE11> show evpn instance EVPN-1 esi 00:11:11:11:11:11:11:11:11:11 extensiveInstance: EVPN-1

Number of ethernet segments: 2 ESI: 00:11:11:11:11:11:11:11:11:11


Status: Resolved by IFL ae0.100 Local interface: ae0.100, Status: Up/Forwarding Number of remote PEs connected: 1 Remote PE MAC label Aliasing label Mode 12.12.12.12 300688 300688 all-active Designated forwarder: 11.11.11.11 Backup forwarder: 12.12.12.12 Advertised MAC label: 300976 Advertised aliasing label: 300976 Advertised split horizon label: 299984

DF の選択は、ESI と EVI を組み合わせた区分ごとに実行されます。これにより、PE 間の BUM トラフィックの負荷分散が容易になります。この機能をサービスカービングといいます。そのため、EVI EVPN-2 では別途 DF の選択が行われ、PE11 が再び DF になっています。

cse@PE11> show evpn instance EVPN-2 esi 00:11:11:11:11:11:11:11:11:11 extensiveInstance: EVPN-2

Number of ethernet segments: 2 ESI: 00:11:11:11:11:11:11:11:11:11 Status: Resolved by IFL ae0.200 Local interface: ae0.200, Status: Up/Forwarding Number of remote PEs connected: 1 Remote PE MAC label Aliasing label Mode 12.12.12.12 300144 300144 all-active Designated forwarder: 11.11.11.11 Backup forwarder: 12.12.12.12 Advertised MAC label: 300080 Advertised aliasing label: 300080 Advertised split horizon label: 299984

EVPN の仕様によると、各マルチホーム PE は個別に同じアルゴリズムを実行して、DF を決

day one: データ センターの相互接続での イーサネット vpn ......day one...

Documents

day one: データセンターの相互接続でのイーサネット vpn ......day one...