IWAN パート 1:PfRv3 設計の考慮事項(Dmytro Muzychko)

    本ページは英語ドキュメントを翻訳したものです。

     


     

     3 つ目の設計課題(Virgilio Spaziani)

    アプリケーションが異なれば、遅延、ジッター、パケット損失に関するニーズも異なるので、ルーティングに関する決定に各アプリケーションが関係するのは当然です。ただし従来のルーティング プロトコルでは、このようなレベルでメトリックを考慮してルートの計算をすることはできません。そこで、トラフィックをよりインテリジェントに WAN 経由で送る、新しいソフトウェア定義型 WAN(SD-WAN)ソリューションが市場に登場しています。その 1 つに、シスコ インテリジェント WAN(IWAN)があります。IWAN の中核となるのは、PfRv3 と DMVPN です。この記事では、2016 年 10 月時点での、これらのテクノロジーに関連する設計上の考慮事項について説明します。

     

    PfRv3 は、旧リリース(旧 OER(Optimized Edge Routing))の単なるアップデート バージョンではありません。これは一から記述された完全に新しいコードです。旧リリースからの最大の改良点は、設定が簡素化されたことです。

     

    IWAN DMVPN 関連の設計の考慮事項

    PfRv3 は、GRE ヘッダーを使用してパケットに独自の情報を挿入しているため、DMVPN をオーバーレイとして使用する必要があります。そのため、お客様の IWAN ソリューションを設計するときは、DMVPN について考慮する必要があります。

    Blog38-figure+1.png

    図 1

     

    • ブランチ サイトの各物理 WAN 回線は、IWAN のパスと呼ばれる、別個の DMVPN クラウドのメンバーである必要があります。ただし、DMVPN オーバーレイは、共通のアンダーレイ ネットワークを、独立した異なるアイランドに分割します。各ブランチで、同じ MPLS レイヤ 3 VPN プロバイダー上に 2 つの冗長回線があると仮定しましょう。 ハブのプライマリ回線に障害が発生したらどうなるでしょうか。従来のルーティングでオーバーレイがなければ、ブランチは影響を受けず、ハブに向かうトラフィックにローカルのプライマリ回線を使用し続けます。しかし、IWAN では、ブランチはセカンダリ回線のみを使用して始動します。これは、回線が、共通のアンダーレイ ネットワークから別の DMVPN オーバーレイに分離されたことが原因です。
    • ブランチの所在国で IPsec 暗号化に関わる法規制が課されている場合は、使用中のサービスに応じた別の手段を探す必要があります。 たとえば、IPsec を使用しない MPLS、ネットワーク全体で認められる暗号化レベルが設定されたインターネットベースの VPN、アプリケーション自体に暗号化機能をオフロードできるサービスなどがあります。
    • DMVPN 内のマルチキャスト トラフィックが原因となって、ハブ サイトに容量の問題が発生する可能性があります。各マルチキャスト ストリームは、リスナーのあるスポークに向かうトンネルごとに複製されるからです。アンダーレイ トランスポートがマルチキャスト ルーティングに使用されている場合、トンネルをバイパスしてマルチキャスト トラフィックを引き続きネイティブに送信することをお勧めします。

     

    IWAN PfRv3 関連の設計の考慮事項

    次に、ソリューションの PfRv3 部分を確認していきましょう。

     

    • 現在の IWAN 2.1 では、同じ境界ルータ(BR)の複数の DMVPN クラウド(パス)をハブで終端させることは認められていません。これによるブランチ サイトへの影響はありません。 ネットワーク設計者は、図 2 のように、ハブでパスごとに別のルータを設定するように計画する必要があります。

    Blog38-figure+2.png

    図 2

     

    • ブランチには、同じ DMVPN クラウドに接続された複数の BR を置くことはできません。ただし、この制約はハブ サイトには適用されません。図 3 を参照してください。

    Blog38-figure+3.png

    図 3

    • PfRv3 では、メインのハブ サイトが 1 つだけ認められています。他のハブ サイトは「PfRv3 トランジット サイト」と呼ばれます。メインのハブとトランジット サイト間のトラフィック、または異なるトランジット サイト間のトラフィックは PfRv3 による制御がされておらず、従来のルーティングに従うことに注意してください。
    • PfRv3 は対称ルーティングを保証できないため、アプリケーションの中には、複数のルータがあるサイトで NBAR2 によって誤検出されるものもあります。アプリケーション名ではなく、DCSP マーキングに基づいて PfRv3 ポリシーを設計することをお勧めします。
    • ハブのマスター コントローラ(MC)の耐障害性を設計する際は、フェールオーバーがステートレスであることに注意してください。そのため、すべてのサイトでバックアップ ハブ MC への接続が再確立され、すべての PfRv3 関連情報が学習し直されることにも注意が必要です。プライマリとバックアップ ハブ MC の間は動的に同期しないため、設定を手動で同期させる必要があります。
    • BR と MC 間の PfRv3 接続は、IWAN が使用する DMVPN トンネル経由では確立できないため、ハブ MC の耐障害性を設計する際には、ハブの BR が IWAN トンネルをバイパスして冗長 MC に到達できるようにする必要があります
    • ブランチ MC は、BR と隣接関係にあるレイヤ 3 でなければなりません。言い換えると、ブランチ MC が BR からホップ数回分離れた場所にあることは認められていません。図 4 を参照してください。ただし、この制約はハブ サイトには適用されません。

    Blog38-figure+4.png

    図 4

     

     

    以上が、PfRv3 の設計における最も重要な考慮事項です。これさえ押さえておけば、IWAN ソリューションの設計を始めることができます。IWAN の導入には、次の記事で取り上げるルーティング設計の考慮事項も加味する必要があります。

     

    著者について

    pic Dmytro Muzychko.png

    Dmytro(Dima) Muzychko は、Verizon 社の主席設計エンジニアで、主に規格外の顧客要件を扱っています。サービス プロバイダーのネットワーキングに関する経験があり、特にルーティング・スイッチングや仮想化、最近では SD-WAN に重点を置いています。Dima のプロフェッショナルとしての言葉を引用します。問題を解決するにはインテリジェンスが必要だが、問題を起こさないためには知恵が必要だ。ネットワーク設計という作業は、まさに後者そのものだ」。

    Dima は現在、Routing & Switching の CCIE と CCDE を保有し、コンピュータ テクノロジーの修士号を取得しています。

     

     

    次の方法で、このテーマについてさらに学んだり情報を交換したりすることができます。

    CLNBanner